* Re: InfiniBand/RDMA merge plans for 2.6.24
From: Shirley Ma @ 2007-09-14 18:36 UTC (permalink / raw)
To: Roland Dreier; +Cc: general, linux-kernel, netdev, netdev-owner
In-Reply-To: <adazlzpjkk6.fsf@cisco.com>
> IPoIB CM handles this properly by gathering together single pages in
> skbs' fragment lists.
>
> - R.
Then can we reuse IPoIB CM code here?
Thanks
Shirley
^ permalink raw reply
* Re: [git patches] net driver fixes
From: Dan Williams @ 2007-09-14 18:31 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Andrew Morton, Linus Torvalds, netdev, LKML
In-Reply-To: <46EAD049.4020107@garzik.org>
On Fri, 2007-09-14 at 14:17 -0400, Jeff Garzik wrote:
> Dan Williams wrote:
> > WTF? why would the default be to _not_ propagate carrier state? Are
> > there some mitigating circumstances that require this driver to not
> > notify the stack of carrier on/off? Userspace stuff really should know
> > about the carrier state, and this disables it by default.
>
>
> The commit explains that...
I admit that I probably don't understand the system architecture of
where ehea would be used, but would this
cause /sys/class/net/ethX/carrier to be TRUE even if the device has no
carrier? That seems quite wrong IMHO. When does ehea not have a
carrier? And in that case, does sysfs say 1 or 0 for the carrier?
Dan
^ permalink raw reply
* Re: e1000 driver and samba
From: Francois Romieu @ 2007-09-14 18:26 UTC (permalink / raw)
To: L F; +Cc: netdev
In-Reply-To: <780b6f780709131904j41148fb4p827e87530b15d6e9@mail.gmail.com>
L F <lfabio.linux@gmail.com> :
[...]
> Now, the machine worked when it was using an onboard Realtek 8169
> chipset on a 945G board from ASUS, but it worked slowly. I upgraded to
> a P965 chipset, started using the realtek driver for the 8110B on that
> board.. and started getting consistent samba errors. I therefore
> killed the onboard LAN, switched to the Intel board, tried both the
> 7.6.5 driver on the Intel website AND the driver in the 2.6.20+
> kernels - 7.2.x IIRC - and it fails, less than it did with the
> realtek, but it fails. Switching back and forth between 2.6.18,
> 2.6.20.x and 2.6.22.x yielded no improvements. I could use some help,
> because I refuse to believe that there isn't a reliable PCIexpress
> gigeth/samba combo available.
> For further reference, the kernel versions are those mentioned above,
> compiled with gcc-3.4.6 and gcc-4.1.2 (current on debian-testing),
> with no improvement between the two.
> Any and all indications appreciated.
For the 8169 or the 8110, try 2.6.23-rc6 +
http://www.fr.zoreil.com/people/francois/misc/20070903-2.6.23-rc5-r8169-test.patch
--
Ueimor
^ permalink raw reply
* [PATCH] mv643xx_eth: Fix tx_bytes stats calculation
From: Dale Farnsworth @ 2007-09-14 18:23 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev
Reported by Corey Minyard <cminyard@mvista.com>
---
drivers/net/mv643xx_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
index 1799eee..6a117e9 100644
--- a/drivers/net/mv643xx_eth.c
+++ b/drivers/net/mv643xx_eth.c
@@ -1222,7 +1222,7 @@ static int mv643xx_eth_start_xmit(struct sk_buff *skb, struct net_device *dev)
spin_lock_irqsave(&mp->lock, flags);
eth_tx_submit_descs_for_skb(mp, skb);
- stats->tx_bytes = skb->len;
+ stats->tx_bytes += skb->len;
stats->tx_packets++;
dev->trans_start = jiffies;
^ permalink raw reply related
* Re: [git patches] net driver fixes
From: Jeff Garzik @ 2007-09-14 18:17 UTC (permalink / raw)
To: Dan Williams; +Cc: Andrew Morton, Linus Torvalds, netdev, LKML
In-Reply-To: <1189793598.2508.4.camel@xo-3E-67-34.localdomain>
Dan Williams wrote:
> WTF? why would the default be to _not_ propagate carrier state? Are
> there some mitigating circumstances that require this driver to not
> notify the stack of carrier on/off? Userspace stuff really should know
> about the carrier state, and this disables it by default.
The commit explains that...
Jeff
^ permalink raw reply
* Re: [git patches] net driver fixes
From: Dan Williams @ 2007-09-14 18:13 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Andrew Morton, Linus Torvalds, netdev, LKML
In-Reply-To: <20070913053022.GA16891@havoc.gtf.org>
On Thu, 2007-09-13 at 01:30 -0400, Jeff Garzik wrote:
> Please pull from 'upstream-linus' branch of
> master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-linus
>
> to receive the following updates:
>
> drivers/net/atl1/atl1_main.c | 19 +++++++------------
> drivers/net/ehea/ehea.h | 5 ++++-
> drivers/net/ehea/ehea_main.c | 16 ++++++++++++++--
> drivers/net/phy/phy.c | 4 ++--
> drivers/net/phy/phy_device.c | 4 ++--
> drivers/net/sky2.c | 9 ++++++++-
> drivers/net/spider_net.c | 12 ++++--------
> 7 files changed, 41 insertions(+), 28 deletions(-)
>
> Hans-Jürgen Koch (1):
> Fix a lock problem in generic phy code
>
> Ishizaki Kou (1):
> spidernet: fix interrupt reason recognition
>
> Jan-Bernd Themann (2):
> ehea: propagate physical port state
> ehea: fix last_rx update
>
> Luca Tettamanti (1):
> atl1: disable broken 64-bit DMA
>
> Stephen Hemminger (1):
> sky2: restore multicast list on resume and other ops
>
> diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c
> index 3c1984e..f23e13c 100644
> --- a/drivers/net/atl1/atl1_main.c
> +++ b/drivers/net/atl1/atl1_main.c
> @@ -2203,21 +2203,20 @@ static int __devinit atl1_probe(struct pci_dev *pdev,
> struct net_device *netdev;
> struct atl1_adapter *adapter;
> static int cards_found = 0;
> - bool pci_using_64 = true;
> int err;
>
> err = pci_enable_device(pdev);
> if (err)
> return err;
>
> - err = pci_set_dma_mask(pdev, DMA_64BIT_MASK);
> + /*
> + * 64-bit DMA currently has data corruption problems, so let's just
> + * use 32-bit DMA for now. This is a big hack that is probably wrong.
> + */
> + err = pci_set_dma_mask(pdev, DMA_32BIT_MASK);
> if (err) {
> - err = pci_set_dma_mask(pdev, DMA_32BIT_MASK);
> - if (err) {
> - dev_err(&pdev->dev, "no usable DMA configuration\n");
> - goto err_dma;
> - }
> - pci_using_64 = false;
> + dev_err(&pdev->dev, "no usable DMA configuration\n");
> + goto err_dma;
> }
> /* Mark all PCI regions associated with PCI device
> * pdev as being reserved by owner atl1_driver_name
> @@ -2282,7 +2281,6 @@ static int __devinit atl1_probe(struct pci_dev *pdev,
>
> netdev->ethtool_ops = &atl1_ethtool_ops;
> adapter->bd_number = cards_found;
> - adapter->pci_using_64 = pci_using_64;
>
> /* setup the private structure */
> err = atl1_sw_init(adapter);
> @@ -2299,9 +2297,6 @@ static int __devinit atl1_probe(struct pci_dev *pdev,
> */
> /* netdev->features |= NETIF_F_TSO; */
>
> - if (pci_using_64)
> - netdev->features |= NETIF_F_HIGHDMA;
> -
> netdev->features |= NETIF_F_LLTX;
>
> /*
> diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
> index d67f97b..8d58be5 100644
> --- a/drivers/net/ehea/ehea.h
> +++ b/drivers/net/ehea/ehea.h
> @@ -39,7 +39,7 @@
> #include <asm/io.h>
>
> #define DRV_NAME "ehea"
> -#define DRV_VERSION "EHEA_0073"
> +#define DRV_VERSION "EHEA_0074"
>
> /* eHEA capability flags */
> #define DLPAR_PORT_ADD_REM 1
> @@ -402,6 +402,8 @@ struct ehea_mc_list {
>
> #define EHEA_PORT_UP 1
> #define EHEA_PORT_DOWN 0
> +#define EHEA_PHY_LINK_UP 1
> +#define EHEA_PHY_LINK_DOWN 0
> #define EHEA_MAX_PORT_RES 16
> struct ehea_port {
> struct ehea_adapter *adapter; /* adapter that owns this port */
> @@ -427,6 +429,7 @@ struct ehea_port {
> u32 msg_enable;
> u32 sig_comp_iv;
> u32 state;
> + u8 phy_link;
> u8 full_duplex;
> u8 autoneg;
> u8 num_def_qps;
> diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
> index db57474..717b129 100644
> --- a/drivers/net/ehea/ehea_main.c
> +++ b/drivers/net/ehea/ehea_main.c
> @@ -53,17 +53,21 @@ static int rq3_entries = EHEA_DEF_ENTRIES_RQ3;
> static int sq_entries = EHEA_DEF_ENTRIES_SQ;
> static int use_mcs = 0;
> static int num_tx_qps = EHEA_NUM_TX_QP;
> +static int prop_carrier_state = 0;
>
> module_param(msg_level, int, 0);
> module_param(rq1_entries, int, 0);
> module_param(rq2_entries, int, 0);
> module_param(rq3_entries, int, 0);
> module_param(sq_entries, int, 0);
> +module_param(prop_carrier_state, int, 0);
> module_param(use_mcs, int, 0);
> module_param(num_tx_qps, int, 0);
>
> MODULE_PARM_DESC(num_tx_qps, "Number of TX-QPS");
> MODULE_PARM_DESC(msg_level, "msg_level");
> +MODULE_PARM_DESC(prop_carrier_state, "Propagate carrier state of physical "
> + "port to stack. 1:yes, 0:no. Default = 0 ");
WTF? why would the default be to _not_ propagate carrier state? Are
there some mitigating circumstances that require this driver to not
notify the stack of carrier on/off? Userspace stuff really should know
about the carrier state, and this disables it by default.
Dan
> MODULE_PARM_DESC(rq3_entries, "Number of entries for Receive Queue 3 "
> "[2^x - 1], x = [6..14]. Default = "
> __MODULE_STRING(EHEA_DEF_ENTRIES_RQ3) ")");
> @@ -467,7 +471,7 @@ static struct ehea_cqe *ehea_proc_rwqes(struct net_device *dev,
> else
> netif_receive_skb(skb);
>
> - dev->last_rx = jiffies;
> + port->netdev->last_rx = jiffies;
> } else {
> pr->p_stats.poll_receive_errors++;
> port_reset = ehea_treat_poll_error(pr, rq, cqe,
> @@ -814,7 +818,9 @@ int ehea_set_portspeed(struct ehea_port *port, u32 port_speed)
> ehea_error("Failed setting port speed");
> }
> }
> - netif_carrier_on(port->netdev);
> + if (!prop_carrier_state || (port->phy_link == EHEA_PHY_LINK_UP))
> + netif_carrier_on(port->netdev);
> +
> kfree(cb4);
> out:
> return ret;
> @@ -869,13 +875,19 @@ static void ehea_parse_eqe(struct ehea_adapter *adapter, u64 eqe)
> }
>
> if (EHEA_BMASK_GET(NEQE_EXTSWITCH_PORT_UP, eqe)) {
> + port->phy_link = EHEA_PHY_LINK_UP;
> if (netif_msg_link(port))
> ehea_info("%s: Physical port up",
> port->netdev->name);
> + if (prop_carrier_state)
> + netif_carrier_on(port->netdev);
> } else {
> + port->phy_link = EHEA_PHY_LINK_DOWN;
> if (netif_msg_link(port))
> ehea_info("%s: Physical port down",
> port->netdev->name);
> + if (prop_carrier_state)
> + netif_carrier_off(port->netdev);
> }
>
> if (EHEA_BMASK_GET(NEQE_EXTSWITCH_PRIMARY, eqe))
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index e323efd..0cc4369 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -755,7 +755,7 @@ out_unlock:
> */
> void phy_start(struct phy_device *phydev)
> {
> - spin_lock(&phydev->lock);
> + spin_lock_bh(&phydev->lock);
>
> switch (phydev->state) {
> case PHY_STARTING:
> @@ -769,7 +769,7 @@ void phy_start(struct phy_device *phydev)
> default:
> break;
> }
> - spin_unlock(&phydev->lock);
> + spin_unlock_bh(&phydev->lock);
> }
> EXPORT_SYMBOL(phy_stop);
> EXPORT_SYMBOL(phy_start);
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index e275df8..49328e0 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -644,7 +644,7 @@ static int phy_probe(struct device *dev)
> if (!(phydrv->flags & PHY_HAS_INTERRUPT))
> phydev->irq = PHY_POLL;
>
> - spin_lock(&phydev->lock);
> + spin_lock_bh(&phydev->lock);
>
> /* Start out supporting everything. Eventually,
> * a controller will attach, and may modify one
> @@ -658,7 +658,7 @@ static int phy_probe(struct device *dev)
> if (phydev->drv->probe)
> err = phydev->drv->probe(phydev);
>
> - spin_unlock(&phydev->lock);
> + spin_unlock_bh(&phydev->lock);
>
> return err;
>
> diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
> index e6d937e..5d812de 100644
> --- a/drivers/net/sky2.c
> +++ b/drivers/net/sky2.c
> @@ -149,6 +149,8 @@ static const char *yukon2_name[] = {
> "FE", /* 0xb7 */
> };
>
> +static void sky2_set_multicast(struct net_device *dev);
> +
> /* Access to external PHY */
> static int gm_phy_write(struct sky2_hw *hw, unsigned port, u16 reg, u16 val)
> {
> @@ -2900,8 +2902,10 @@ static int sky2_set_settings(struct net_device *dev, struct ethtool_cmd *ecmd)
> sky2->autoneg = ecmd->autoneg;
> sky2->advertising = ecmd->advertising;
>
> - if (netif_running(dev))
> + if (netif_running(dev)) {
> sky2_phy_reinit(sky2);
> + sky2_set_multicast(dev);
> + }
>
> return 0;
> }
> @@ -2994,6 +2998,7 @@ static int sky2_nway_reset(struct net_device *dev)
> return -EINVAL;
>
> sky2_phy_reinit(sky2);
> + sky2_set_multicast(dev);
>
> return 0;
> }
> @@ -4171,6 +4176,8 @@ static int sky2_resume(struct pci_dev *pdev)
> dev_close(dev);
> goto out;
> }
> +
> + sky2_set_multicast(dev);
> }
> }
>
> diff --git a/drivers/net/spider_net.c b/drivers/net/spider_net.c
> index 590b12c..82d837a 100644
> --- a/drivers/net/spider_net.c
> +++ b/drivers/net/spider_net.c
> @@ -1441,17 +1441,14 @@ static void
> spider_net_handle_error_irq(struct spider_net_card *card, u32 status_reg)
> {
> u32 error_reg1, error_reg2;
> - u32 mask_reg1, mask_reg2;
> u32 i;
> int show_error = 1;
>
> error_reg1 = spider_net_read_reg(card, SPIDER_NET_GHIINT1STS);
> error_reg2 = spider_net_read_reg(card, SPIDER_NET_GHIINT2STS);
> - mask_reg1 = spider_net_read_reg(card, SPIDER_NET_GHIINT1MSK);
> - mask_reg2 = spider_net_read_reg(card,SPIDER_NET_GHIINT2MSK);
>
> - error_reg1 &= mask_reg1;
> - error_reg2 &= mask_reg2;
> + error_reg1 &= SPIDER_NET_INT1_MASK_VALUE;
> + error_reg2 &= SPIDER_NET_INT2_MASK_VALUE;
>
> /* check GHIINT0STS ************************************/
> if (status_reg)
> @@ -1679,11 +1676,10 @@ spider_net_interrupt(int irq, void *ptr)
> {
> struct net_device *netdev = ptr;
> struct spider_net_card *card = netdev_priv(netdev);
> - u32 status_reg, mask_reg;
> + u32 status_reg;
>
> status_reg = spider_net_read_reg(card, SPIDER_NET_GHIINT0STS);
> - mask_reg = spider_net_read_reg(card, SPIDER_NET_GHIINT0MSK);
> - status_reg &= mask_reg;
> + status_reg &= SPIDER_NET_INT0_MASK_VALUE;
>
> if (!status_reg)
> return IRQ_NONE;
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: wireless vs. network namespaces
From: Johannes Berg @ 2007-09-14 17:59 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: netdev, linux-wireless
In-Reply-To: <m1bqc52ria.fsf-T1Yj925okcoyDheHMi7gv2pdwda3JcWeAL8bYrjMMd8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3904 bytes --]
On Fri, 2007-09-14 at 09:31 -0600, Eric W. Biederman wrote:
> > Now that the network namespace work is in net-2.6.24, I'm wondering how
> > wireless will be handling this. Is there any benefit at all to a
> > wireless device supporting network namespaces?
>
> Good question. Network namespaces are designed as a general tool
> so if we can support network namespaces in the wireless stack without
> killing ourselves there should be value in it.
Right.
> > Should we, for now, set the new NETIF_F_NETNS_LOCAL flag for all
> > mac80211 devices?
> >
> > If we do want to support moving, then we'll have to make cfg80211
> > (preferably, though mac80211 might be easier at first) migrate *all*
> > virtual interfaces associated with the same wiphy because otherwise
> > we'll get into trouble when moving one virtual interface and then
> > somebody in the other namespace changes its operating channel.
>
> Ok. This appears at least to be an atomicity issue and possibly more.
Yeah, good point, it'd have to move them all at once.
> I don't currently understand the way the wireless interfaces interact
> well enough to make a judgement call.
>
> There are two basic usage models I can currently think of.
> 1) Super chroot. Where a group of processes has distinct mount,
> network, uts, ipc, and pid namespaces. So in this case on the
> inside we will only see processes that only belong to our own
> network namespace. So in this scenario you get whatever the person
> who sets up the environment gives you.
>
> If one of the network devices only allows access to a subset of
> the wireless networking (say just sending packets but not
> controlling the radio aspects) I can see and advantage in only
> having that device in the restricted network namespace.
Right now, there's no way to disallow that, but yes, I can see value in
it as well.
> 2) Advanced routing. Where someone is doing some weird thing like
> testing sending packets and receiving them on the same machine.
Not sure I see a point in that with wireless.
> Currently creation of a network namespace requires CAP_SYS_ADMIN
> and for device movement we only require CAP_NET_ADMIN. So these are
> all privileged operations. So the scenario you are concerned about
> may just be a "don't do that then".
Ok. Sounds good to me. All the radio config requires CAP_SYS_ADMIN as
well.
> If this doesn't give you enough information to make the call can
> you describe for me how the separation of wireless network interfaces
> work?
Well, basically what we have is one physical device that sends/receives
packets. We have multiple options then:
* some hardware (no drivers at this time) support multiple virtual
devices to associate to multiple different access points, each has a
different MAC address too
* more importantly, if you have an access point you can put any group
of associated stations into a sort of VLAN based on which encryption
keys they use for multicast traffic. Each of these VLANs shows up as
a local device as well.
* Then there's some things like having a monitor interface that sees
all traffic etc. but that's not too interesting.
* You could have an AP along with a WDS device to enable bridging
between multiple APs over wireless, not really interesting either in
this context
I can mainly see the first and the second points having value in
separation. With the first, pending drivers that have multi-MAC address
support you could give each namespace one device that can associate to
some different AP [1]. And then you could have VLANs on an AP where each
VLAN "ends" in a different namespace.
johannes
[1] though actually, right now, they couldn't associate to the same AP
without having weird bugs in mac80211... I have plans to fix this
though.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [BUG] tg3 cannot do PXE (loses MAC address) after soft reboot
From: Michael Chan @ 2007-09-14 18:52 UTC (permalink / raw)
To: Ingo Oeser; +Cc: Lucas Nussbaum, netdev
In-Reply-To: <200709141014.20635.netdev@axxeo.de>
On Fri, 2007-09-14 at 10:14 +0200, Ingo Oeser wrote:
> Michael Chan schrieb:
> > On Thu, 2007-09-13 at 21:28 +0200, Lucas Nussbaum wrote:
> > > Erm, Wouldn't it be possible to print a warning when the driver loads,
> > > saying that the firmware is outdated ?
> >
> > It's possible, but would require the driver to parse the version string.
> > The driver currently reports the version string for information and for
> > the human to parse it.
>
> Yes, but most humans don't know all valid firmware versions of their
> components.
>
> Is it enough to parse the first number in the firmware via simple_strtoul()?
No, it's not. We need to check the number after the '.' and possibly an
alphabet at the end as well. Worse yet, the version may be different
for different chips.
We'll see if we can come up with a simple way to detect the problem.
^ permalink raw reply
* RE: [ofa-general] InfiniBand/RDMA merge plans for 2.6.24
From: Sean Hefty @ 2007-09-14 17:45 UTC (permalink / raw)
To: 'Roland Dreier'; +Cc: general, linux-kernel, netdev
In-Reply-To: <adatzpyl1mm.fsf@cisco.com>
>OK -- just to make sure I'm understanding what you're saying: have you
>confirmed that your proposed patches actually fix the issue?
Not directly. I cannot easily test kernel patches on our larger, production
clusters. We've seen the issue with specific applications on 512 and 1024
cores, but I've only been able to test the patch on a 48-core cluster. I have
verified that it successfully increases the timeout to where it *should* work,
but cannot absolutely confirm that it will fix the problem. I'm unlikely to
know that until the production clusters move to an OFED release (1.3?)
containing this patch.
- Sean
^ permalink raw reply
* Re: [PATCH][NETNS] Use list_for_each_entry_continue_reverse in setup_net
From: Eric W. Biederman @ 2007-09-14 17:33 UTC (permalink / raw)
To: Pavel Emelyanov; +Cc: Linux Containers, Linux Netdev List
In-Reply-To: <46EA3AB4.7060904-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
Pavel Emelyanov <xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org> writes:
> I proposed introducing a list_for_each_entry_continue_reverse
> macro to be used in setup_net() when unrolling the failed
> ->init callback.
>
> Here is the macro and some more cleanup in the setup_net() itself
> to remove one variable from the stack :) Minor, but the code
> looks nicer.
>
> Signed-off-by: Pavel Emelyanov <xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
Acked-by: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Eric
^ permalink raw reply
* Re: [PATCH 0/9 Rev3] Implement batching skb API and support in IPoIB
From: David Miller @ 2007-09-14 17:24 UTC (permalink / raw)
To: billfink
Cc: hadi, jheffner, rick.jones2, krkumar2, gaagaan, general, herbert,
jagana, jeff, johnpol, kaber, mcarlson, mchan, netdev,
peter.p.waskiewicz.jr, rdreier, Robert.Olsson, shemminger, sri,
tgraf, xma
In-Reply-To: <20070914032055.8f96449b.billfink@mindspring.com>
From: Bill Fink <billfink@mindspring.com>
Date: Fri, 14 Sep 2007 03:20:55 -0400
> TSO disabled performance is always better than equivalent TSO enabled
> performance. With TSO enabled, the optimum performance is indeed at
> a TX/RX interrupt coalescing value of 75 usec. With TSO disabled,
> performance is the full 10-GigE line rate of 9910 Mbps for any value
> of TX/RX interrupt coalescing from 15 usec to 105 usec.
Note that the systems where the coalescing tweaking if often necessary
are the heavily NUMA'd systems where cpu to device latency can be
huge, like the big SGI ones which is where we had to tweak things in
the tg3 driver in the first place.
On most systems, as you saw mostly in the non-TSO case, the
value choosen for the most part is arbitrary and not critical.
^ permalink raw reply
* Re: [PATCH v3] Make the pr_*() family of macros in kernel.h complete
From: Randy Dunlap @ 2007-09-14 17:13 UTC (permalink / raw)
To: Satyam Sharma
Cc: Medve Emilian-EMMEDVE1, akpm, linux-kernel, netdev, i2c,
linux-omap-open-source
In-Reply-To: <a781481a0709140941w4ec76582j40ee53a189b99b05@mail.gmail.com>
On Fri, 14 Sep 2007 22:11:59 +0530 Satyam Sharma wrote:
> > > -----Original Message-----
> > > From: Medve Emilian-EMMEDVE1
> > > Sent: Wednesday, September 12, 2007 11:40 AM
> > > To: linux-kernel@vger.kernel.org; netdev@vger.kernel.org;
> > > i2c@lm-sensors.org; linux-omap-open-source@linux.omap.com
> > > Cc: Medve Emilian-EMMEDVE1
>
> ... no maintainer explicitly copied on the original mail who'd push this in.
> Little thing, but LKML is too noisy, so you need to Cc: folks explicitly ...
>
> > > Subject: [PATCH v3] Make the pr_*() family of macros in
> > > kernel.h complete
> > >
> > > Other/Some pr_*() macros are already defined in kernel.h, but
> > > pr_err() was defined
> > > multiple times in several other places
> > >
> > > Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
>
> I think it's a useful cleanup, patch looks good to me ...
>
> Reviewed-by: Satyam Sharma <satyam@infradead.org>
I like it too.
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
(since I still haven't seen reviewed-by in SubmittingPatches)
> [ Original diff is at: http://lkml.org/lkml/diff/2007/9/12/182/1 ]
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: e1000 driver and samba
From: Kok, Auke @ 2007-09-14 17:18 UTC (permalink / raw)
To: L F; +Cc: netdev
In-Reply-To: <780b6f780709131904j41148fb4p827e87530b15d6e9@mail.gmail.com>
L F wrote:
> Folks,
> I've been playing with multiple gigabit ethernet drivers to get samba
> 3.0.25+ to work reliably. The situation is as follows.
> I have a network, one of the machines on the network is a
> server/firewall. It contains an Intel PRO1000 dual port PCI Express
> card and runs Debian-testing.
> The machine is running shorewall 3.4.5 and at present, one port of the
> PRO1000 is configured as the WAN port, the other is bridged to a tap
> device for virtualbox and is running as the LAN port.
> Samba 3.0.25+ will either lose connection or - more worrisomely -
> corrupt data in files upon sustained traffic.
> One of the tests that consistently fails is mounting a samba share
> onto any WinXP client, then trying to unzip a file from the
> mounted/mapped drive into the drive itself (i.e. unzipping
> Z:\Stuff\qqq.zip to Z:\Stuff\qqq\* ).
> If the zip file is of any significant size, one of two things will
> happen. Either the client will complain about losing connection to the
> share - with a corrisponding error in the samba logs - or everything
> will be fine.. except the files will be corrupt.
> The unusual thing is that going through the TAP interface from a
> Virtualbox machine yields no problems even when transferring tens of
> GBs of data.
> Copying a large file (500MB+) also has the same effect.
> Now, the machine worked when it was using an onboard Realtek 8169
> chipset on a 945G board from ASUS, but it worked slowly.
this slowness might have been masking the issue
> I upgraded to
> a P965 chipset, started using the realtek driver for the 8110B on that
> board.. and started getting consistent samba errors. I therefore
> killed the onboard LAN, switched to the Intel board, tried both the
> 7.6.5 driver on the Intel website AND the driver in the 2.6.20+
> kernels - 7.2.x IIRC - and it fails, less than it did with the
> realtek, but it fails. Switching back and forth between 2.6.18,
> 2.6.20.x and 2.6.22.x yielded no improvements. I could use some help,
> because I refuse to believe that there isn't a reliable PCIexpress
> gigeth/samba combo available.
I have not yet seen other reports of this issue, and it would be interesting to
see if the stack or driver is seeing errors. Please post `ethtool -S eth0` after
the samba connection resets or fails.
Just as a precaution, try a different ethernet cable. Even the switch in between
the target and you might have issues.
I know our lab folks do plenty of samba testing but I will see if they can run a
stress test against a smb target in the way that you describe.
Cheers,
Auke
^ permalink raw reply
* Re: [PATCH v3] Make the pr_*() family of macros in kernel.h complete
From: Satyam Sharma @ 2007-09-14 16:41 UTC (permalink / raw)
To: Medve Emilian-EMMEDVE1
Cc: akpm, linux-kernel, netdev, i2c, linux-omap-open-source
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E270155578C@az33exm24.fsl.freescale.net>
> > -----Original Message-----
> > From: Medve Emilian-EMMEDVE1
> > Sent: Wednesday, September 12, 2007 11:40 AM
> > To: linux-kernel@vger.kernel.org; netdev@vger.kernel.org;
> > i2c@lm-sensors.org; linux-omap-open-source@linux.omap.com
> > Cc: Medve Emilian-EMMEDVE1
... no maintainer explicitly copied on the original mail who'd push this in.
Little thing, but LKML is too noisy, so you need to Cc: folks explicitly ...
> > Subject: [PATCH v3] Make the pr_*() family of macros in
> > kernel.h complete
> >
> > Other/Some pr_*() macros are already defined in kernel.h, but
> > pr_err() was defined
> > multiple times in several other places
> >
> > Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
I think it's a useful cleanup, patch looks good to me ...
Reviewed-by: Satyam Sharma <satyam@infradead.org>
[ Original diff is at: http://lkml.org/lkml/diff/2007/9/12/182/1 ]
^ permalink raw reply
* Re: 2.6.23-rc4-mm1 list_add corruption in networking code
From: Randy Dunlap @ 2007-09-14 16:25 UTC (permalink / raw)
To: Mathieu Desnoyers, netdev; +Cc: Andrew Morton, linux-kernel
In-Reply-To: <20070914140803.GA26161@Krystal>
[adding netdev]
On Fri, 14 Sep 2007 10:08:03 -0400 Mathieu Desnoyers wrote:
> Hi Andrew,
>
> My P4 is crashing about once a day, started with 2.6.23-rc4-mm1, with
> errors that seems related to network code. Here is the latest BUG:
> (sorry, my console log cuts it at 80 cols)
>
> Mathieu
>
> [ 4590.836342] list_add corruption. prev->next should be next (c1df4a10), but w
> [ 4590.864914] ------------[ cut here ]------------
> [ 4590.878687] Kernel BUG at c0263cbc [verbose debug info unavailable]
> [ 4590.897389] invalid opcode: 0000 [#1] PREEMPT SMP
> [ 4590.911721] last sysfs file: /block/sda/size
> [ 4590.924453] Modules linked in: snd_hda_intel usbserial rtc pl2303 skge sky2
> [ 4590.945324]
> [ 4590.949752] Pid: 3283, comm: cc1 Not tainted (2.6.23-rc4-mm1-testssmp #334)
> [ 4590.970525] EIP: 0060:[<c0263cbc>] EFLAGS: 00010082 CPU: 0
> [ 4590.986895] EIP is at __list_add+0x5c/0x60
> [ 4590.999111] EAX: 00000070 EBX: c2b3b4e8 ECX: 00000001 EDX: 00000203
> [ 4591.017812] ESI: c2b3b4e8 EDI: 00000202 EBP: c3eb7b34 ESP: c3eb7b1c
> [ 4591.036511] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 )
> [ 4591.052621] Process cc1 (pid: 3283, ti=c3eb6000 task=c2073ea0 task.ti=c3eb60
> [ 4591.073917] Stack: c04dcd50 c1df4a10 c2b3b4e8 c2b3b4e8 c05b3d00 00000006 c3e
> [ 4591.098997] c1df49e0 c20a499c c3eb7b58 c03afdaf c20a499c c054d4e0 c05
> [ 4591.149154] Call Trace:
> [ 4591.156974] [<c010971a>] show_trace_log_lvl+0x1a/0x30
> [ 4591.172332] [<c01097d8>] show_stack_log_lvl+0xa8/0xe0
> [ 4591.187685] [<c01098da>] show_registers+0xca/0x250
> [ 4591.202264] [<c0109b75>] die+0x115/0x280
> [ 4591.214247] [<c0109d71>] do_trap+0x91/0xc0
> [ 4591.226748] [<c010a119>] do_invalid_op+0x89/0xa0
> [ 4591.240808] [<c0423e7a>] error_code+0x72/0x78
> [ 4591.254091] [<c03aee41>] __napi_schedule+0x51/0xb0
> [ 4591.268667] [<c03afdaf>] netif_rx+0x14f/0x160
> [ 4591.281946] [<c02de090>] loopback_xmit+0x60/0x70
> [ 4591.296006] [<c03b02fb>] dev_hard_start_xmit+0x22b/0x300
> [ 4591.312142] [<c03b2695>] dev_queue_xmit+0x295/0x350
> [ 4591.326979] [<c03ceaa9>] ip_output+0x199/0x330
> [ 4591.340519] [<c03cdf96>] ip_queue_xmit+0x1c6/0x3e0
> [ 4591.355104] [<c03dec4b>] tcp_transmit_skb+0x3db/0x770
> [ 4591.370462] [<c03df9c3>] tcp_write_wakeup+0xf3/0x150
> [ 4591.385562] [<c03e18fb>] tcp_send_probe0+0xb/0xe0
> [ 4591.399885] [<c03e23dc>] tcp_write_timer+0x13c/0x720
> [ 4591.414982] [<c013af80>] run_timer_softirq+0x120/0x190
> [ 4591.430600] [<c0136d53>] __do_softirq+0x93/0x120
> [ 4591.444662] [<c0136e85>] do_softirq+0xa5/0xb0
> [ 4591.457943] [<c0137084>] irq_exit+0x54/0x60
> [ 4591.470704] [<c010b425>] do_IRQ+0x45/0x80
> [ 4591.482951] [<c0108fce>] common_interrupt+0x2e/0x34
> [ 4591.497798] [<c016d791>] file_read_actor+0xe1/0x100
> [ 4591.512641] [<c016e134>] do_generic_mapping_read+0x1f4/0x440
> [ 4591.529815] [<c016fbfe>] generic_file_aio_read+0xbe/0x1c0
> [ 4591.546217] [<c019138e>] do_sync_read+0xce/0x110
> [ 4591.560282] [<c0191be4>] vfs_read+0x94/0x130
> [ 4591.573310] [<c019212d>] sys_read+0x3d/0x70
> [ 4591.586075] [<c0108596>] syscall_call+0x7/0xb
> [ 4591.599357] =======================
> [ 4591.610015] INFO: lockdep is turned off.
> [ 4591.621713] Code: 5c 24 04 c7 04 24 00 cd 4d c0 e8 40 e1 ec ff 0f 0b eb fe 8
> [ 4591.679092] EIP: [<c0263cbc>] __list_add+0x5c/0x60 SS:ESP 0068:c3eb7b1c
> [ 4591.698884] Kernel panic - not syncing: Fatal exception in interrupt
>
> I get the same type of errors with or without my own patches (this crash
> happened with my patches)
>
> Here is my config:
>
> #
> # Automatically generated make config: don't edit
> # Linux kernel version: 2.6.23-rc4-mm1
> # Fri Sep 14 09:03:16 2007
> #
> CONFIG_X86_32=y
> CONFIG_GENERIC_TIME=y
> CONFIG_GENERIC_CMOS_UPDATE=y
> CONFIG_CLOCKSOURCE_WATCHDOG=y
> CONFIG_GENERIC_CLOCKEVENTS=y
> CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
> CONFIG_LOCKDEP_SUPPORT=y
> CONFIG_STACKTRACE_SUPPORT=y
> CONFIG_SEMAPHORE_SLEEPERS=y
> CONFIG_X86=y
> CONFIG_MMU=y
> CONFIG_ZONE_DMA=y
> CONFIG_QUICKLIST=y
> CONFIG_GENERIC_ISA_DMA=y
> CONFIG_GENERIC_IOMAP=y
> CONFIG_GENERIC_BUG=y
> CONFIG_GENERIC_HWEIGHT=y
> CONFIG_ARCH_MAY_HAVE_PC_FDC=y
> CONFIG_DMI=y
> CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
>
> #
> # General setup
> #
> CONFIG_EXPERIMENTAL=y
> CONFIG_LOCK_KERNEL=y
> CONFIG_INIT_ENV_ARG_LIMIT=32
> CONFIG_LOCALVERSION="-testssmp"
> # CONFIG_LOCALVERSION_AUTO is not set
> CONFIG_SWAP=y
> CONFIG_SYSVIPC=y
> CONFIG_SYSVIPC_SYSCTL=y
> CONFIG_POSIX_MQUEUE=y
> # CONFIG_BSD_PROCESS_ACCT is not set
> # CONFIG_TASKSTATS is not set
> # CONFIG_USER_NS is not set
> CONFIG_AUDIT=y
> CONFIG_AUDITSYSCALL=y
> CONFIG_AUDIT_TREE=y
> # CONFIG_IKCONFIG is not set
> CONFIG_LOG_BUF_SHIFT=17
> # CONFIG_CONTAINERS is not set
> CONFIG_SYSFS_DEPRECATED=y
> CONFIG_RELAY=y
> # CONFIG_BLK_DEV_INITRD is not set
> # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
> CONFIG_SYSCTL=y
> CONFIG_IMMEDIATE=y
> CONFIG_EMBEDDED=y
> CONFIG_UID16=y
> CONFIG_SYSCTL_SYSCALL=y
> CONFIG_KALLSYMS=y
> CONFIG_KALLSYMS_ALL=y
> # CONFIG_KALLSYMS_EXTRA_PASS is not set
> CONFIG_HOTPLUG=y
> CONFIG_PRINTK=y
> CONFIG_BUG=y
> CONFIG_ELF_CORE=y
> CONFIG_BASE_FULL=y
> CONFIG_FUTEX=y
> CONFIG_ANON_INODES=y
> CONFIG_EPOLL=y
> CONFIG_SIGNALFD=y
> CONFIG_TIMERFD=y
> CONFIG_EVENTFD=y
> CONFIG_SHMEM=y
> CONFIG_VM_EVENT_COUNTERS=y
> CONFIG_SLUB_DEBUG=y
> # CONFIG_SLAB is not set
> CONFIG_SLUB=y
> # CONFIG_SLOB is not set
> CONFIG_PROC_PAGE_MONITOR=y
> CONFIG_PROC_KPAGEMAP=y
> # CONFIG_DISABLE_IMMEDIATE is not set
> CONFIG_RT_MUTEXES=y
> # CONFIG_TINY_SHMEM is not set
> CONFIG_BASE_SMALL=0
> CONFIG_MODULES=y
> CONFIG_MODULE_UNLOAD=y
> # CONFIG_MODULE_FORCE_UNLOAD is not set
> # CONFIG_MODVERSIONS is not set
> # CONFIG_MODULE_SRCVERSION_ALL is not set
> CONFIG_KMOD=y
> CONFIG_STOP_MACHINE=y
> CONFIG_BLOCK=y
> CONFIG_LBD=y
> # CONFIG_BLK_DEV_IO_TRACE is not set
> CONFIG_LSF=y
> # CONFIG_BLK_DEV_BSG is not set
>
> #
> # IO Schedulers
> #
> CONFIG_IOSCHED_NOOP=y
> CONFIG_IOSCHED_AS=y
> CONFIG_IOSCHED_DEADLINE=y
> CONFIG_IOSCHED_CFQ=y
> CONFIG_DEFAULT_AS=y
> # CONFIG_DEFAULT_DEADLINE is not set
> # CONFIG_DEFAULT_CFQ is not set
> # CONFIG_DEFAULT_NOOP is not set
> CONFIG_DEFAULT_IOSCHED="anticipatory"
>
> #
> # Processor type and features
> #
> # CONFIG_TICK_ONESHOT is not set
> # CONFIG_NO_HZ is not set
> # CONFIG_HIGH_RES_TIMERS is not set
> CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
> CONFIG_SMP=y
> CONFIG_X86_PC=y
> # CONFIG_X86_ELAN is not set
> # CONFIG_X86_VOYAGER is not set
> # CONFIG_X86_NUMAQ is not set
> # CONFIG_X86_SUMMIT is not set
> # CONFIG_X86_BIGSMP is not set
> # CONFIG_X86_VISWS is not set
> # CONFIG_X86_GENERICARCH is not set
> # CONFIG_X86_ES7000 is not set
> CONFIG_PARAVIRT=y
> CONFIG_XEN=y
> CONFIG_VMI=y
> # CONFIG_M386 is not set
> # CONFIG_M486 is not set
> # CONFIG_M586 is not set
> # CONFIG_M586TSC is not set
> # CONFIG_M586MMX is not set
> # CONFIG_M686 is not set
> # CONFIG_MPENTIUMII is not set
> CONFIG_MPENTIUMIII=y
> # CONFIG_MPENTIUMM is not set
> # CONFIG_MPENTIUM4 is not set
> # CONFIG_MCORE2 is not set
> # CONFIG_MK6 is not set
> # CONFIG_MK7 is not set
> # CONFIG_MK8 is not set
> # CONFIG_MCRUSOE is not set
> # CONFIG_MEFFICEON is not set
> # CONFIG_MWINCHIPC6 is not set
> # CONFIG_MWINCHIP2 is not set
> # CONFIG_MWINCHIP3D is not set
> # CONFIG_MGEODEGX1 is not set
> # CONFIG_MGEODE_LX is not set
> # CONFIG_MCYRIXIII is not set
> # CONFIG_MVIAC3_2 is not set
> # CONFIG_MVIAC7 is not set
> # CONFIG_X86_GENERIC is not set
> CONFIG_X86_CMPXCHG=y
> CONFIG_X86_L1_CACHE_SHIFT=5
> CONFIG_X86_XADD=y
> CONFIG_RWSEM_XCHGADD_ALGORITHM=y
> # CONFIG_ARCH_HAS_ILOG2_U32 is not set
> # CONFIG_ARCH_HAS_ILOG2_U64 is not set
> CONFIG_GENERIC_CALIBRATE_DELAY=y
> CONFIG_X86_WP_WORKS_OK=y
> CONFIG_X86_INVLPG=y
> CONFIG_X86_BSWAP=y
> CONFIG_X86_POPAD_OK=y
> CONFIG_X86_GOOD_APIC=y
> CONFIG_X86_INTEL_USERCOPY=y
> CONFIG_X86_USE_PPRO_CHECKSUM=y
> CONFIG_X86_TSC=y
> CONFIG_X86_CMOV=y
> CONFIG_X86_MINIMUM_CPU_FAMILY=4
> # CONFIG_HPET_TIMER is not set
> CONFIG_NR_CPUS=8
> CONFIG_SCHED_SMT=y
> CONFIG_SCHED_MC=y
> # CONFIG_PREEMPT_NONE is not set
> # CONFIG_PREEMPT_VOLUNTARY is not set
> CONFIG_PREEMPT=y
> CONFIG_PREEMPT_BKL=y
> CONFIG_X86_LOCAL_APIC=y
> CONFIG_X86_IO_APIC=y
> CONFIG_X86_MCE=y
> CONFIG_X86_MCE_NONFATAL=y
> # CONFIG_X86_MCE_P4THERMAL is not set
> CONFIG_VM86=y
> # CONFIG_TOSHIBA is not set
> # CONFIG_I8K is not set
> # CONFIG_X86_REBOOTFIXUPS is not set
> # CONFIG_MICROCODE is not set
> # CONFIG_X86_MSR is not set
> # CONFIG_X86_CPUID is not set
>
> #
> # Firmware Drivers
> #
> # CONFIG_EDD is not set
> # CONFIG_DELL_RBU is not set
> CONFIG_DCDBAS=m
> CONFIG_DMIID=y
> # CONFIG_NOHIGHMEM is not set
> CONFIG_HIGHMEM4G=y
> # CONFIG_HIGHMEM64G is not set
> CONFIG_VMSPLIT_3G=y
> # CONFIG_VMSPLIT_3G_OPT is not set
> # CONFIG_VMSPLIT_2G is not set
> # CONFIG_VMSPLIT_2G_OPT is not set
> # CONFIG_VMSPLIT_1G is not set
> CONFIG_PAGE_OFFSET=0xC0000000
> CONFIG_HIGHMEM=y
> CONFIG_ARCH_FLATMEM_ENABLE=y
> CONFIG_ARCH_SPARSEMEM_ENABLE=y
> CONFIG_ARCH_SELECT_MEMORY_MODEL=y
> CONFIG_ARCH_POPULATES_NODE_MAP=y
> CONFIG_SELECT_MEMORY_MODEL=y
> CONFIG_FLATMEM_MANUAL=y
> # CONFIG_DISCONTIGMEM_MANUAL is not set
> # CONFIG_SPARSEMEM_MANUAL is not set
> CONFIG_FLATMEM=y
> CONFIG_FLAT_NODE_MEM_MAP=y
> CONFIG_SPARSEMEM_STATIC=y
> # CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set
> CONFIG_SPLIT_PTLOCK_CPUS=4
> # CONFIG_RESOURCES_64BIT is not set
> CONFIG_ZONE_DMA_FLAG=1
> CONFIG_BOUNCE=y
> CONFIG_NR_QUICK=1
> CONFIG_VIRT_TO_BUS=y
> # CONFIG_HIGHPTE is not set
> # CONFIG_MATH_EMULATION is not set
> CONFIG_MTRR=y
> # CONFIG_EFI is not set
> CONFIG_IRQBALANCE=y
> CONFIG_SECCOMP=y
> # CONFIG_HZ_100 is not set
> CONFIG_HZ_250=y
> # CONFIG_HZ_300 is not set
> # CONFIG_HZ_1000 is not set
> CONFIG_HZ=250
> CONFIG_KEXEC=y
> # CONFIG_CRASH_DUMP is not set
> CONFIG_PHYSICAL_START=0x100000
> # CONFIG_RELOCATABLE is not set
> CONFIG_PHYSICAL_ALIGN=0x100000
> CONFIG_HOTPLUG_CPU=y
> CONFIG_COMPAT_VDSO=y
> CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
>
> #
> # Power management options (ACPI, APM)
> #
> CONFIG_PM=y
> # CONFIG_PM_LEGACY is not set
> # CONFIG_PM_DEBUG is not set
> CONFIG_PM_SLEEP_SMP=y
> CONFIG_PM_SLEEP=y
> CONFIG_SUSPEND_SMP_POSSIBLE=y
> CONFIG_SUSPEND=y
> CONFIG_HIBERNATION_SMP_POSSIBLE=y
> # CONFIG_HIBERNATION is not set
> CONFIG_ACPI=y
> CONFIG_ACPI_SLEEP=y
> CONFIG_ACPI_PROCFS=y
> CONFIG_ACPI_PROC_EVENT=y
> CONFIG_ACPI_AC=y
> CONFIG_ACPI_BATTERY=y
> CONFIG_ACPI_BUTTON=y
> CONFIG_ACPI_FAN=y
> # CONFIG_ACPI_DOCK is not set
> CONFIG_ACPI_PROCESSOR=y
> CONFIG_ACPI_HOTPLUG_CPU=y
> CONFIG_ACPI_THERMAL=y
> # CONFIG_ACPI_ASUS is not set
> # CONFIG_ACPI_TOSHIBA is not set
> CONFIG_ACPI_BLACKLIST_YEAR=0
> # CONFIG_ACPI_DEBUG is not set
> CONFIG_ACPI_EC=y
> CONFIG_ACPI_POWER=y
> CONFIG_ACPI_SYSTEM=y
> CONFIG_X86_PM_TIMER=y
> CONFIG_ACPI_CONTAINER=y
> # CONFIG_ACPI_SBS is not set
> # CONFIG_APM is not set
>
> #
> # CPU Frequency scaling
> #
> # CONFIG_CPU_FREQ is not set
>
> #
> # CPU idle PM support
> #
> # CONFIG_CPU_IDLE is not set
>
> #
> # Bus options (PCI, PCMCIA, EISA, MCA, ISA)
> #
> CONFIG_PCI=y
> # CONFIG_PCI_GOBIOS is not set
> # CONFIG_PCI_GOMMCONFIG is not set
> # CONFIG_PCI_GODIRECT is not set
> CONFIG_PCI_GOANY=y
> CONFIG_PCI_BIOS=y
> CONFIG_PCI_DIRECT=y
> CONFIG_PCI_MMCONFIG=y
> # CONFIG_PCIEPORTBUS is not set
> CONFIG_ARCH_SUPPORTS_MSI=y
> # CONFIG_PCI_MSI is not set
> # CONFIG_PCI_DEBUG is not set
> CONFIG_HT_IRQ=y
> CONFIG_ISA_DMA_API=y
> CONFIG_ISA=y
> # CONFIG_EISA is not set
> # CONFIG_MCA is not set
> # CONFIG_SCx200 is not set
> # CONFIG_PCCARD is not set
> # CONFIG_HOTPLUG_PCI is not set
>
> #
> # Executable file formats
> #
> CONFIG_BINFMT_ELF=y
> CONFIG_BINFMT_AOUT=y
> CONFIG_BINFMT_MISC=y
>
> #
> # Networking
> #
> CONFIG_NET=y
>
> #
> # Networking options
> #
> CONFIG_PACKET=y
> # CONFIG_PACKET_MMAP is not set
> CONFIG_UNIX=y
> CONFIG_XFRM=y
> # CONFIG_XFRM_USER is not set
> # CONFIG_XFRM_SUB_POLICY is not set
> # CONFIG_XFRM_MIGRATE is not set
> # CONFIG_NET_KEY is not set
> CONFIG_INET=y
> CONFIG_IP_MULTICAST=y
> # CONFIG_IP_ADVANCED_ROUTER is not set
> CONFIG_IP_FIB_HASH=y
> # CONFIG_IP_PNP is not set
> # CONFIG_NET_IPIP is not set
> # CONFIG_NET_IPGRE is not set
> # CONFIG_IP_MROUTE is not set
> # CONFIG_ARPD is not set
> # CONFIG_SYN_COOKIES is not set
> # CONFIG_INET_AH is not set
> # CONFIG_INET_ESP is not set
> # CONFIG_INET_IPCOMP is not set
> # CONFIG_INET_XFRM_TUNNEL is not set
> # CONFIG_INET_TUNNEL is not set
> CONFIG_INET_XFRM_MODE_TRANSPORT=y
> CONFIG_INET_XFRM_MODE_TUNNEL=y
> CONFIG_INET_XFRM_MODE_BEET=y
> # CONFIG_INET_LRO is not set
> CONFIG_INET_DIAG=m
> CONFIG_INET_TCP_DIAG=m
> # CONFIG_TCP_CONG_ADVANCED is not set
> CONFIG_TCP_CONG_CUBIC=y
> CONFIG_DEFAULT_TCP_CONG="cubic"
> # CONFIG_TCP_MD5SIG is not set
> # CONFIG_IP_VS is not set
> # CONFIG_IPV6 is not set
> # CONFIG_INET6_XFRM_TUNNEL is not set
> # CONFIG_INET6_TUNNEL is not set
> # CONFIG_NETWORK_SECMARK is not set
> CONFIG_NETFILTER=y
> # CONFIG_NETFILTER_DEBUG is not set
>
> #
> # Core Netfilter Configuration
> #
> CONFIG_NETFILTER_NETLINK=y
> CONFIG_NETFILTER_NETLINK_QUEUE=m
> CONFIG_NETFILTER_NETLINK_LOG=m
> # CONFIG_NF_CONNTRACK_ENABLED is not set
> # CONFIG_NF_CONNTRACK is not set
> # CONFIG_NETFILTER_XTABLES is not set
>
> #
> # IP: Netfilter Configuration
> #
> CONFIG_IP_NF_QUEUE=y
> # CONFIG_IP_NF_IPTABLES is not set
> # CONFIG_IP_NF_ARPTABLES is not set
> # CONFIG_IP_DCCP is not set
> # CONFIG_IP_SCTP is not set
> # CONFIG_TIPC is not set
> # CONFIG_ATM is not set
> # CONFIG_BRIDGE is not set
> # CONFIG_VLAN_8021Q is not set
> # CONFIG_DECNET is not set
> # CONFIG_LLC2 is not set
> # CONFIG_IPX is not set
> # CONFIG_ATALK is not set
> # CONFIG_X25 is not set
> # CONFIG_LAPB is not set
> # CONFIG_ECONET is not set
> # CONFIG_WAN_ROUTER is not set
>
> #
> # QoS and/or fair queueing
> #
> # CONFIG_NET_SCHED is not set
>
> #
> # Network testing
> #
> # CONFIG_NET_PKTGEN is not set
> # CONFIG_NET_TCPPROBE is not set
> # CONFIG_HAMRADIO is not set
> # CONFIG_IRDA is not set
> # CONFIG_BT is not set
> # CONFIG_AF_RXRPC is not set
>
> #
> # Wireless
> #
> # CONFIG_CFG80211 is not set
> # CONFIG_WIRELESS_EXT is not set
> # CONFIG_MAC80211 is not set
> CONFIG_IEEE80211=m
> CONFIG_IEEE80211_DEBUG=y
> CONFIG_IEEE80211_CRYPT_WEP=m
> CONFIG_IEEE80211_CRYPT_CCMP=m
> # CONFIG_IEEE80211_CRYPT_TKIP is not set
> # CONFIG_IEEE80211_SOFTMAC is not set
> # CONFIG_RFKILL is not set
>
> #
> # Device Drivers
> #
>
> #
> # Generic Driver Options
> #
> CONFIG_STANDALONE=y
> CONFIG_PREVENT_FIRMWARE_BUILD=y
> CONFIG_FW_LOADER=m
> # CONFIG_DEBUG_DRIVER is not set
> # CONFIG_DEBUG_DEVRES is not set
> # CONFIG_SYS_HYPERVISOR is not set
> CONFIG_CONNECTOR=y
> CONFIG_PROC_EVENTS=y
> # CONFIG_MTD is not set
> CONFIG_PARPORT=y
> CONFIG_PARPORT_PC=y
> # CONFIG_PARPORT_SERIAL is not set
> # CONFIG_PARPORT_PC_FIFO is not set
> # CONFIG_PARPORT_PC_SUPERIO is not set
> # CONFIG_PARPORT_GSC is not set
> # CONFIG_PARPORT_AX88796 is not set
> # CONFIG_PARPORT_1284 is not set
> CONFIG_PNP=y
> # CONFIG_PNP_DEBUG is not set
>
> #
> # Protocols
> #
> # CONFIG_ISAPNP is not set
> # CONFIG_PNPBIOS is not set
> CONFIG_PNPACPI=y
> CONFIG_BLK_DEV=y
> CONFIG_BLK_DEV_FD=y
> # CONFIG_BLK_DEV_XD is not set
> # CONFIG_PARIDE is not set
> # CONFIG_BLK_CPQ_DA is not set
> # CONFIG_BLK_CPQ_CISS_DA is not set
> # CONFIG_BLK_DEV_DAC960 is not set
> # CONFIG_BLK_DEV_UMEM is not set
> # CONFIG_BLK_DEV_COW_COMMON is not set
> CONFIG_BLK_DEV_LOOP=m
> # CONFIG_BLK_DEV_CRYPTOLOOP is not set
> # CONFIG_BLK_DEV_NBD is not set
> # CONFIG_BLK_DEV_SX8 is not set
> # CONFIG_BLK_DEV_UB is not set
> # CONFIG_BLK_DEV_RAM is not set
> # CONFIG_CDROM_PKTCDVD is not set
> # CONFIG_ATA_OVER_ETH is not set
> # CONFIG_XEN_BLKDEV_FRONTEND is not set
> CONFIG_MISC_DEVICES=y
> # CONFIG_IBM_ASM is not set
> # CONFIG_PHANTOM is not set
> # CONFIG_EEPROM_93CX6 is not set
> # CONFIG_SGI_IOC4 is not set
> # CONFIG_TIFM_CORE is not set
> # CONFIG_SONY_LAPTOP is not set
> # CONFIG_THINKPAD_ACPI is not set
> CONFIG_IDE=y
> CONFIG_IDE_MAX_HWIFS=4
> CONFIG_BLK_DEV_IDE=y
>
> #
> # Please see Documentation/ide.txt for help/info on IDE drives
> #
> # CONFIG_BLK_DEV_IDE_SATA is not set
> # CONFIG_BLK_DEV_HD_IDE is not set
> CONFIG_BLK_DEV_IDEDISK=y
> CONFIG_IDEDISK_MULTI_MODE=y
> CONFIG_BLK_DEV_IDECD=y
> # CONFIG_BLK_DEV_IDETAPE is not set
> # CONFIG_BLK_DEV_IDEFLOPPY is not set
> # CONFIG_BLK_DEV_IDESCSI is not set
> # CONFIG_BLK_DEV_IDEACPI is not set
> # CONFIG_IDE_TASK_IOCTL is not set
> CONFIG_IDE_PROC_FS=y
>
> #
> # IDE chipset support/bugfixes
> #
> CONFIG_IDE_GENERIC=y
> # CONFIG_BLK_DEV_PLATFORM is not set
> # CONFIG_BLK_DEV_CMD640 is not set
> # CONFIG_BLK_DEV_IDEPNP is not set
>
> #
> # PCI IDE chipsets support
> #
> CONFIG_BLK_DEV_IDEPCI=y
> CONFIG_IDEPCI_SHARE_IRQ=y
> CONFIG_IDEPCI_PCIBUS_ORDER=y
> # CONFIG_BLK_DEV_OFFBOARD is not set
> CONFIG_BLK_DEV_GENERIC=y
> # CONFIG_BLK_DEV_OPTI621 is not set
> CONFIG_BLK_DEV_RZ1000=y
> CONFIG_BLK_DEV_IDEDMA_PCI=y
> # CONFIG_BLK_DEV_AEC62XX is not set
> # CONFIG_BLK_DEV_ALI15X3 is not set
> # CONFIG_BLK_DEV_AMD74XX is not set
> # CONFIG_BLK_DEV_ATIIXP is not set
> # CONFIG_BLK_DEV_CMD64X is not set
> # CONFIG_BLK_DEV_TRIFLEX is not set
> # CONFIG_BLK_DEV_CY82C693 is not set
> # CONFIG_BLK_DEV_CS5520 is not set
> # CONFIG_BLK_DEV_CS5530 is not set
> # CONFIG_BLK_DEV_CS5535 is not set
> # CONFIG_BLK_DEV_HPT34X is not set
> # CONFIG_BLK_DEV_HPT366 is not set
> # CONFIG_BLK_DEV_JMICRON is not set
> # CONFIG_BLK_DEV_SC1200 is not set
> CONFIG_BLK_DEV_PIIX=y
> # CONFIG_BLK_DEV_IT8213 is not set
> # CONFIG_BLK_DEV_IT821X is not set
> # CONFIG_BLK_DEV_NS87415 is not set
> # CONFIG_BLK_DEV_PDC202XX_OLD is not set
> # CONFIG_BLK_DEV_PDC202XX_NEW is not set
> # CONFIG_BLK_DEV_SVWKS is not set
> # CONFIG_BLK_DEV_SIIMAGE is not set
> # CONFIG_BLK_DEV_SIS5513 is not set
> # CONFIG_BLK_DEV_SLC90E66 is not set
> # CONFIG_BLK_DEV_TRM290 is not set
> # CONFIG_BLK_DEV_VIA82CXXX is not set
> # CONFIG_BLK_DEV_TC86C001 is not set
> # CONFIG_IDE_ARM is not set
>
> #
> # Other IDE chipsets support
> #
>
> #
> # Note: most of these also require special kernel boot parameters
> #
> # CONFIG_BLK_DEV_4DRIVES is not set
> # CONFIG_BLK_DEV_ALI14XX is not set
> # CONFIG_BLK_DEV_DTC2278 is not set
> # CONFIG_BLK_DEV_HT6560B is not set
> # CONFIG_BLK_DEV_QD65XX is not set
> # CONFIG_BLK_DEV_UMC8672 is not set
> CONFIG_BLK_DEV_IDEDMA=y
> # CONFIG_BLK_DEV_HD is not set
>
> #
> # SCSI device support
> #
> # CONFIG_RAID_ATTRS is not set
> CONFIG_SCSI=y
> CONFIG_SCSI_DMA=y
> # CONFIG_SCSI_TGT is not set
> # CONFIG_SCSI_NETLINK is not set
> CONFIG_SCSI_PROC_FS=y
>
> #
> # SCSI support type (disk, tape, CD-ROM)
> #
> CONFIG_BLK_DEV_SD=y
> # CONFIG_CHR_DEV_ST is not set
> # CONFIG_CHR_DEV_OSST is not set
> # CONFIG_BLK_DEV_SR is not set
> CONFIG_CHR_DEV_SG=y
> # CONFIG_CHR_DEV_SCH is not set
>
> #
> # Some SCSI devices (e.g. CD jukebox) support multiple LUNs
> #
> # CONFIG_SCSI_MULTI_LUN is not set
> # CONFIG_SCSI_CONSTANTS is not set
> # CONFIG_SCSI_LOGGING is not set
> # CONFIG_SCSI_SCAN_ASYNC is not set
> CONFIG_SCSI_WAIT_SCAN=m
>
> #
> # SCSI Transports
> #
> # CONFIG_SCSI_SPI_ATTRS is not set
> # CONFIG_SCSI_FC_ATTRS is not set
> # CONFIG_SCSI_ISCSI_ATTRS is not set
> # CONFIG_SCSI_SAS_LIBSAS is not set
> # CONFIG_SCSI_SRP_ATTRS is not set
> CONFIG_SCSI_LOWLEVEL=y
> # CONFIG_ISCSI_TCP is not set
> # CONFIG_BLK_DEV_3W_XXXX_RAID is not set
> # CONFIG_SCSI_3W_9XXX is not set
> # CONFIG_SCSI_7000FASST is not set
> # CONFIG_SCSI_ACARD is not set
> # CONFIG_SCSI_AHA152X is not set
> # CONFIG_SCSI_AHA1542 is not set
> # CONFIG_SCSI_AACRAID is not set
> # CONFIG_SCSI_AIC7XXX is not set
> # CONFIG_SCSI_AIC7XXX_OLD is not set
> # CONFIG_SCSI_AIC79XX is not set
> # CONFIG_SCSI_AIC94XX is not set
> CONFIG_SCSI_DPT_I2O=m
> # CONFIG_SCSI_ADVANSYS is not set
> # CONFIG_SCSI_IN2000 is not set
> # CONFIG_SCSI_ARCMSR is not set
> # CONFIG_MEGARAID_NEWGEN is not set
> # CONFIG_MEGARAID_LEGACY is not set
> # CONFIG_MEGARAID_SAS is not set
> # CONFIG_SCSI_HPTIOP is not set
> # CONFIG_SCSI_BUSLOGIC is not set
> # CONFIG_SCSI_DMX3191D is not set
> # CONFIG_SCSI_DTC3280 is not set
> # CONFIG_SCSI_EATA is not set
> # CONFIG_SCSI_FUTURE_DOMAIN is not set
> # CONFIG_SCSI_GDTH is not set
> # CONFIG_SCSI_GENERIC_NCR5380 is not set
> # CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
> # CONFIG_SCSI_IPS is not set
> # CONFIG_SCSI_INITIO is not set
> # CONFIG_SCSI_INIA100 is not set
> # CONFIG_SCSI_PPA is not set
> # CONFIG_SCSI_IMM is not set
> # CONFIG_SCSI_NCR53C406A is not set
> # CONFIG_SCSI_STEX is not set
> # CONFIG_SCSI_SYM53C8XX_2 is not set
> # CONFIG_SCSI_IPR is not set
> # CONFIG_SCSI_PAS16 is not set
> # CONFIG_SCSI_PSI240I is not set
> # CONFIG_SCSI_QLOGIC_FAS is not set
> # CONFIG_SCSI_QLOGIC_1280 is not set
> # CONFIG_SCSI_QLA_FC is not set
> # CONFIG_SCSI_QLA_ISCSI is not set
> # CONFIG_SCSI_LPFC is not set
> # CONFIG_SCSI_SEAGATE is not set
> # CONFIG_SCSI_SYM53C416 is not set
> # CONFIG_SCSI_DC395x is not set
> # CONFIG_SCSI_DC390T is not set
> # CONFIG_SCSI_T128 is not set
> # CONFIG_SCSI_U14_34F is not set
> # CONFIG_SCSI_ULTRASTOR is not set
> # CONFIG_SCSI_NSP32 is not set
> # CONFIG_SCSI_DEBUG is not set
> # CONFIG_SCSI_SRP is not set
> CONFIG_ATA=y
> # CONFIG_ATA_NONSTANDARD is not set
> CONFIG_ATA_ACPI=y
> # CONFIG_SATA_AHCI is not set
> # CONFIG_SATA_SVW is not set
> CONFIG_ATA_PIIX=y
> # CONFIG_SATA_MV is not set
> # CONFIG_SATA_NV is not set
> # CONFIG_PDC_ADMA is not set
> # CONFIG_SATA_QSTOR is not set
> # CONFIG_SATA_PROMISE is not set
> # CONFIG_SATA_SX4 is not set
> # CONFIG_SATA_SIL is not set
> # CONFIG_SATA_SIL24 is not set
> # CONFIG_SATA_SIS is not set
> # CONFIG_SATA_ULI is not set
> # CONFIG_SATA_VIA is not set
> # CONFIG_SATA_VITESSE is not set
> # CONFIG_SATA_INIC162X is not set
> # CONFIG_PATA_ALI is not set
> # CONFIG_PATA_AMD is not set
> # CONFIG_PATA_ARTOP is not set
> # CONFIG_PATA_ATIIXP is not set
> # CONFIG_PATA_CMD640_PCI is not set
> # CONFIG_PATA_CMD64X is not set
> # CONFIG_PATA_CS5520 is not set
> # CONFIG_PATA_CS5530 is not set
> # CONFIG_PATA_CS5535 is not set
> # CONFIG_PATA_CYPRESS is not set
> # CONFIG_PATA_EFAR is not set
> # CONFIG_ATA_GENERIC is not set
> # CONFIG_PATA_HPT366 is not set
> # CONFIG_PATA_HPT37X is not set
> # CONFIG_PATA_HPT3X2N is not set
> # CONFIG_PATA_HPT3X3 is not set
> # CONFIG_PATA_IT821X is not set
> # CONFIG_PATA_IT8213 is not set
> # CONFIG_PATA_JMICRON is not set
> # CONFIG_PATA_LEGACY is not set
> # CONFIG_PATA_TRIFLEX is not set
> # CONFIG_PATA_MARVELL is not set
> # CONFIG_PATA_MPIIX is not set
> # CONFIG_PATA_OLDPIIX is not set
> # CONFIG_PATA_NETCELL is not set
> # CONFIG_PATA_NS87410 is not set
> # CONFIG_PATA_OPTI is not set
> # CONFIG_PATA_OPTIDMA is not set
> # CONFIG_PATA_PDC_OLD is not set
> # CONFIG_PATA_QDI is not set
> # CONFIG_PATA_RADISYS is not set
> # CONFIG_PATA_RZ1000 is not set
> # CONFIG_PATA_SC1200 is not set
> # CONFIG_PATA_SERVERWORKS is not set
> # CONFIG_PATA_PDC2027X is not set
> # CONFIG_PATA_SIL680 is not set
> # CONFIG_PATA_SIS is not set
> # CONFIG_PATA_VIA is not set
> # CONFIG_PATA_WINBOND is not set
> # CONFIG_PATA_WINBOND_VLB is not set
> # CONFIG_PATA_PLATFORM is not set
> # CONFIG_MD is not set
> # CONFIG_FUSION is not set
>
> #
> # IEEE 1394 (FireWire) support
> #
> # CONFIG_FIREWIRE is not set
> CONFIG_IEEE1394=y
>
> #
> # Subsystem Options
> #
> # CONFIG_IEEE1394_VERBOSEDEBUG is not set
>
> #
> # Controllers
> #
>
> #
> # Texas Instruments PCILynx requires I2C
> #
> CONFIG_IEEE1394_OHCI1394=y
>
> #
> # Protocols
> #
> # CONFIG_IEEE1394_VIDEO1394 is not set
> # CONFIG_IEEE1394_SBP2 is not set
> # CONFIG_IEEE1394_ETH1394_ROM_ENTRY is not set
> # CONFIG_IEEE1394_ETH1394 is not set
> # CONFIG_IEEE1394_DV1394 is not set
> CONFIG_IEEE1394_RAWIO=y
> # CONFIG_I2O is not set
> CONFIG_MACINTOSH_DRIVERS=y
> # CONFIG_MAC_EMUMOUSEBTN is not set
> CONFIG_NETDEVICES=y
> # CONFIG_NETDEVICES_MULTIQUEUE is not set
> CONFIG_DUMMY=m
> # CONFIG_BONDING is not set
> # CONFIG_MACVLAN is not set
> # CONFIG_EQUALIZER is not set
> CONFIG_TUN=m
> # CONFIG_VETH is not set
> # CONFIG_NET_SB1000 is not set
> # CONFIG_ARCNET is not set
> # CONFIG_PHYLIB is not set
> CONFIG_NET_ETHERNET=y
> CONFIG_MII=y
> # CONFIG_HAPPYMEAL is not set
> # CONFIG_SUNGEM is not set
> # CONFIG_CASSINI is not set
> # CONFIG_NET_VENDOR_3COM is not set
> # CONFIG_LANCE is not set
> # CONFIG_NET_VENDOR_SMC is not set
> # CONFIG_NET_VENDOR_RACAL is not set
> # CONFIG_NET_TULIP is not set
> # CONFIG_AT1700 is not set
> # CONFIG_DEPCA is not set
> # CONFIG_HP100 is not set
> # CONFIG_NET_ISA is not set
> CONFIG_NET_PCI=y
> # CONFIG_PCNET32 is not set
> # CONFIG_AMD8111_ETH is not set
> # CONFIG_ADAPTEC_STARFIRE is not set
> # CONFIG_AC3200 is not set
> # CONFIG_APRICOT is not set
> # CONFIG_B44 is not set
> # CONFIG_FORCEDETH is not set
> # CONFIG_CS89x0 is not set
> # CONFIG_DGRS is not set
> # CONFIG_EEPRO100 is not set
> # CONFIG_E100 is not set
> # CONFIG_FEALNX is not set
> # CONFIG_NATSEMI is not set
> # CONFIG_NE2K_PCI is not set
> # CONFIG_8139CP is not set
> CONFIG_8139TOO=y
> CONFIG_8139TOO_PIO=y
> # CONFIG_8139TOO_TUNE_TWISTER is not set
> # CONFIG_8139TOO_8129 is not set
> # CONFIG_8139_OLD_RX_RESET is not set
> # CONFIG_SIS900 is not set
> # CONFIG_EPIC100 is not set
> # CONFIG_SUNDANCE is not set
> # CONFIG_TLAN is not set
> # CONFIG_VIA_RHINE is not set
> # CONFIG_SC92031 is not set
> # CONFIG_NET_POCKET is not set
> CONFIG_NETDEV_1000=y
> # CONFIG_ACENIC is not set
> # CONFIG_DL2K is not set
> # CONFIG_E1000 is not set
> # CONFIG_E1000E is not set
> # CONFIG_NS83820 is not set
> # CONFIG_HAMACHI is not set
> # CONFIG_YELLOWFIN is not set
> # CONFIG_R8169 is not set
> # CONFIG_SIS190 is not set
> CONFIG_SKGE=m
> CONFIG_SKY2=m
> # CONFIG_SKY2_DEBUG is not set
> # CONFIG_VIA_VELOCITY is not set
> # CONFIG_TIGON3 is not set
> # CONFIG_BNX2 is not set
> # CONFIG_QLA3XXX is not set
> # CONFIG_ATL1 is not set
> CONFIG_NETDEV_10000=y
> # CONFIG_CHELSIO_T1 is not set
> # CONFIG_CHELSIO_T3 is not set
> # CONFIG_IXGB is not set
> CONFIG_S2IO=m
> # CONFIG_S2IO_NAPI is not set
> # CONFIG_MYRI10GE is not set
> # CONFIG_NETXEN_NIC is not set
> # CONFIG_MLX4_CORE is not set
> # CONFIG_TR is not set
>
> #
> # Wireless LAN
> #
> # CONFIG_WLAN_PRE80211 is not set
> # CONFIG_WLAN_80211 is not set
>
> #
> # USB Network Adapters
> #
> # CONFIG_USB_CATC is not set
> # CONFIG_USB_KAWETH is not set
> # CONFIG_USB_PEGASUS is not set
> # CONFIG_USB_RTL8150 is not set
> # CONFIG_USB_USBNET_MII is not set
> # CONFIG_USB_USBNET is not set
> # CONFIG_WAN is not set
> CONFIG_XEN_NETDEV_FRONTEND=y
> # CONFIG_FDDI is not set
> # CONFIG_HIPPI is not set
> # CONFIG_PLIP is not set
> # CONFIG_PPP is not set
> # CONFIG_SLIP is not set
> # CONFIG_NET_FC is not set
> # CONFIG_SHAPER is not set
> # CONFIG_NETCONSOLE is not set
> # CONFIG_NETPOLL is not set
> # CONFIG_NET_POLL_CONTROLLER is not set
> # CONFIG_ISDN is not set
> # CONFIG_PHONE is not set
>
> #
> # Input device support
> #
> CONFIG_INPUT=y
> # CONFIG_INPUT_FF_MEMLESS is not set
> CONFIG_INPUT_POLLDEV=m
>
> #
> # Userland interfaces
> #
> CONFIG_INPUT_MOUSEDEV=y
> CONFIG_INPUT_MOUSEDEV_PSAUX=y
> CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
> CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
> # CONFIG_INPUT_JOYDEV is not set
> # CONFIG_INPUT_TSDEV is not set
> # CONFIG_INPUT_EVDEV is not set
> # CONFIG_INPUT_EVBUG is not set
>
> #
> # Input Device Drivers
> #
> CONFIG_INPUT_KEYBOARD=y
> CONFIG_KEYBOARD_ATKBD=y
> # CONFIG_KEYBOARD_SUNKBD is not set
> # CONFIG_KEYBOARD_LKKBD is not set
> # CONFIG_KEYBOARD_XTKBD is not set
> # CONFIG_KEYBOARD_NEWTON is not set
> # CONFIG_KEYBOARD_STOWAWAY is not set
> CONFIG_INPUT_MOUSE=y
> CONFIG_MOUSE_PS2=y
> CONFIG_MOUSE_PS2_ALPS=y
> CONFIG_MOUSE_PS2_LOGIPS2PP=y
> CONFIG_MOUSE_PS2_SYNAPTICS=y
> CONFIG_MOUSE_PS2_LIFEBOOK=y
> CONFIG_MOUSE_PS2_TRACKPOINT=y
> # CONFIG_MOUSE_PS2_TOUCHKIT is not set
> # CONFIG_MOUSE_SERIAL is not set
> # CONFIG_MOUSE_APPLETOUCH is not set
> # CONFIG_MOUSE_INPORT is not set
> # CONFIG_MOUSE_LOGIBM is not set
> # CONFIG_MOUSE_PC110PAD is not set
> # CONFIG_MOUSE_VSXXXAA is not set
> # CONFIG_INPUT_JOYSTICK is not set
> # CONFIG_INPUT_TABLET is not set
> # CONFIG_INPUT_TOUCHSCREEN is not set
> # CONFIG_INPUT_MISC is not set
>
> #
> # Hardware I/O ports
> #
> CONFIG_SERIO=y
> CONFIG_SERIO_I8042=y
> # CONFIG_SERIO_SERPORT is not set
> # CONFIG_SERIO_CT82C710 is not set
> # CONFIG_SERIO_PARKBD is not set
> # CONFIG_SERIO_PCIPS2 is not set
> CONFIG_SERIO_LIBPS2=y
> # CONFIG_SERIO_RAW is not set
> # CONFIG_GAMEPORT is not set
>
> #
^ permalink raw reply
* Re: [ofa-general] InfiniBand/RDMA merge plans for 2.6.24
From: Roland Dreier @ 2007-09-14 16:18 UTC (permalink / raw)
To: Michael Chan; +Cc: Steve Wise, netdev, linux-kernel, general, anilgv, uri
In-Reply-To: <1189724358.9540.113.camel@dell>
> > I've been meaning to track down the bnx2 iscsi offload patch to look
> > and see if this issue is addressed, since the same problem seems to
> > exist: it seems an iscsi connection and a main stack tcp connection
> > might share the same 4-tuple unless something is done to avoid that
> > happening.
> iSCSI does not do passive listens, only active connections to the
> target. But you're right, the port space is still shared between iSCSI
> and the main stack. We currently rely on user apps binding to the main
> stack to reserve certain ephemeral ports, and telling the iSCSI driver
> which ports to use.
Got it... I wasn't thinking that clearly, but it is clear that a full
4-tuple collision with only active connections is quite unlikely. I
guess you would have to make both an offloaded and a non-offloaded
iSCSI connection to the same target and get really unlucky with
ephemeral port allocation. So in practice I guess it's not an issue
at all with your driver yet.
However, do you have any plans to support iSCSI offload for targets?
Also, looking at the first CNIC patch, I can't help but notice that
you seem to have at least some support for iWARP there. How does the
CNIC look? Does it share the same interface/addresses as the
non-offload NIC, or does it create a completely separate netdevice?
I want to make sure that whatever solution we come up with for cxgb3
doesn't cause problems for you. And of course if you have a better
idea than what Steve has come up with, that would be great :)
- R.
^ permalink raw reply
* Re: InfiniBand/RDMA merge plans for 2.6.24
From: Roland Dreier @ 2007-09-14 16:09 UTC (permalink / raw)
To: Shirley Ma; +Cc: general, linux-kernel, netdev, netdev-owner
In-Reply-To: <OFAE678C61.64C333F1-ON87257355.007A0B34-88257355.004E6EAD@us.ibm.com>
> The patch is just needed to pick up broadcast MTU size instead of hard
> coding 2K right now. SKB allocation shouldn't be different with Ethernet
> Jambo Frame and IPoIB-CM which 64K MTU. I don't understand why it's
> different. Could you please explain this?
It's exactly the same problem as ethernet jumbo frames. A web search
for '"order 1" failure e1000' might be interesting.
IPoIB CM handles this properly by gathering together single pages in
skbs' fragment lists.
- R.
^ permalink raw reply
* Re: [PATCH v2] iw_cxgb3: Support "iwarp-only" interfaces to avoid 4-tuple conflicts.
From: Roland Dreier @ 2007-09-14 16:06 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: Steve Wise, sean.hefty, netdev, linux-kernel, general
In-Reply-To: <20070914130941.GG18517@2ka.mipt.ru>
> Maybe you should automatically create an alias each time new interface
> is added so that admin would not care about proper aliases?
I agree that makes much more sense from a user interface point of
view. Unfortunately an alias without an address doesn't make sense,
so there doesn't seem to be a way to implement that.
- R.
^ permalink raw reply
* Re: [PATCH] tehuti: driver for Tehuti 10GbE network adapters
From: Jeff Garzik @ 2007-09-14 15:59 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: davem, akpm, netdev, baum
In-Reply-To: <20070914153629.GA9140@gospo.rdu.redhat.com>
Andy Gospodarek wrote:
> On Tue, Sep 11, 2007 at 12:40:34PM -0400, Andy Gospodarek wrote:
>> This introduces support for a line of 10GbE adapters made by Tehuti
>> Networks. An attempt to get this included was made a few months ago and
>> since the driver has been re-factored based on Jeff's suggestions.
>>
>> You can download a patch against Jeff's netdev-2.6#upstream tree here:
>>
>> http://git.greyhouse.net/gospo/tehuti-netdev-26-upstream.patch
>>
>> and I setup a git tree last night based off Linus' tree. You can sync
>> with that here if you like:
>>
>> http://git.greyhouse.net/gospo/tehuti-2.6.git
>>
>
> I moved this to:
>
> git://git.greyhouse.net/gospo/tehuti-2.6.git
>
> since I got some complaints that the http-based git tree wasn't working
> well.
Maybe you forgot git-update-server-info, after pushing ?
Jeff
^ permalink raw reply
* Re: [PATCH] tehuti: driver for Tehuti 10GbE network adapters
From: Andy Gospodarek @ 2007-09-14 15:36 UTC (permalink / raw)
To: jeff, davem, akpm, netdev; +Cc: andy, baum
In-Reply-To: <20070911164033.GA3754@gospo.rdu.redhat.com>
On Tue, Sep 11, 2007 at 12:40:34PM -0400, Andy Gospodarek wrote:
>
> This introduces support for a line of 10GbE adapters made by Tehuti
> Networks. An attempt to get this included was made a few months ago and
> since the driver has been re-factored based on Jeff's suggestions.
>
> You can download a patch against Jeff's netdev-2.6#upstream tree here:
>
> http://git.greyhouse.net/gospo/tehuti-netdev-26-upstream.patch
>
> and I setup a git tree last night based off Linus' tree. You can sync
> with that here if you like:
>
> http://git.greyhouse.net/gospo/tehuti-2.6.git
>
I moved this to:
git://git.greyhouse.net/gospo/tehuti-2.6.git
since I got some complaints that the http-based git tree wasn't working
well.
^ permalink raw reply
* Re: wireless vs. network namespaces
From: Eric W. Biederman @ 2007-09-14 15:31 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, linux-wireless
In-Reply-To: <1189763513.3974.26.camel-YfaajirXv214zXjbi5bjpg@public.gmane.org>
Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> writes:
> Now that the network namespace work is in net-2.6.24, I'm wondering how
> wireless will be handling this. Is there any benefit at all to a
> wireless device supporting network namespaces?
Good question. Network namespaces are designed as a general tool
so if we can support network namespaces in the wireless stack without
killing ourselves there should be value in it.
> Should we, for now, set the new NETIF_F_NETNS_LOCAL flag for all
> mac80211 devices?
>
> If we do want to support moving, then we'll have to make cfg80211
> (preferably, though mac80211 might be easier at first) migrate *all*
> virtual interfaces associated with the same wiphy because otherwise
> we'll get into trouble when moving one virtual interface and then
> somebody in the other namespace changes its operating channel.
Ok. This appears at least to be an atomicity issue and possibly more.
I don't currently understand the way the wireless interfaces interact
well enough to make a judgement call.
There are two basic usage models I can currently think of.
1) Super chroot. Where a group of processes has distinct mount,
network, uts, ipc, and pid namespaces. So in this case on the
inside we will only see processes that only belong to our own
network namespace. So in this scenario you get whatever the person
who sets up the environment gives you.
If one of the network devices only allows access to a subset of
the wireless networking (say just sending packets but not
controlling the radio aspects) I can see and advantage in only
having that device in the restricted network namespace.
2) Advanced routing. Where someone is doing some weird thing like
testing sending packets and receiving them on the same machine.
Currently creation of a network namespace requires CAP_SYS_ADMIN
and for device movement we only require CAP_NET_ADMIN. So these are
all privileged operations. So the scenario you are concerned about
may just be a "don't do that then".
If this doesn't give you enough information to make the call can
you describe for me how the separation of wireless network interfaces
work?
Eric
^ permalink raw reply
* Re: [PATCH][NETNS] Use list_for_each_entry_continue_reverse in setup_net
From: Eric W. Biederman @ 2007-09-14 14:41 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Pavel Emelyanov, Linux Netdev List, Linux Containers, devel,
Daniel Lezcano
In-Reply-To: <20070914144938.3ba643a5@oldman>
Stephen Hemminger <shemminger@linux-foundation.org> writes:
> On Fri, 14 Sep 2007 11:39:32 +0400
> Pavel Emelyanov <xemul@openvz.org> wrote:
>
>> I proposed introducing a list_for_each_entry_continue_reverse
>> macro to be used in setup_net() when unrolling the failed
>> ->init callback.
>>
>> Here is the macro and some more cleanup in the setup_net() itself
>> to remove one variable from the stack :) Minor, but the code
>> looks nicer.
>>
>> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
>
> Maybe it is time to just eliminate the init hook from the API.
> It has very few users, and there is no reason the setup needed
> could be done before or after registering in most cases.
I guess only have 5 out of the 29 users I have in my full patchset
is few. But that is to be expected because so far only the core
has been converted.
I looked again at the initialization to see if you had a point about
the initialization but in every instance I looked at the function
was performing work that needed to happen during the creation of
each network namespace. So the work very much needs to be done there.
Ok looking some more I can see why this isn't obvious yet. copy_net_ns
hasn't been merged yet, and that is where we create new network namespaces.
And call setup_net on each new network namespace.
I will take a look at that patch and see if I can come up with a
safe version of it to merge to allow for a little more transparency.
> struct net *copy_net_ns(unsigned long flags, struct net *old_net)
> {
> struct net *new_net = NULL;
> int err;
>
> get_net(old_net);
>
> if (!(flags & CLONE_NEWNET))
> return old_net;
>
> err = -EPERM;
> if (!capable(CAP_SYS_ADMIN))
> goto out;
>
> err = -ENOMEM;
> new_net = net_alloc();
> if (!new_net)
> goto out;
>
> mutex_lock(&net_mutex);
> err = setup_net(new_net);
> if (err)
> goto out_unlock;
>
> net_lock();
> list_add_tail(&new_net->list, &net_namespace_list);
> net_unlock();
>
>
> out_unlock:
> mutex_unlock(&net_mutex);
> out:
> put_net(old_net);
> if (err) {
> net_free(new_net);
> new_net = ERR_PTR(err);
> }
> return new_net;
> }
Eric
^ permalink raw reply
* Re: [patch] sunrpc: make closing of old temporary sockets work (was: problems with lockd in 2.6.22.6)
From: J. Bruce Fields @ 2007-09-14 14:29 UTC (permalink / raw)
To: Wolfgang Walter; +Cc: Neil Brown, netdev, nfs, linux-kernel, trond.myklebust
In-Reply-To: <200709141112.30634.wolfgang.walter@studentenwerk.mhn.de>
On Fri, Sep 14, 2007 at 11:12:30AM +0200, Wolfgang Walter wrote:
> Am Mittwoch, 12. September 2007 21:55 schrieb J. Bruce Fields:
> > On Wed, Sep 12, 2007 at 09:40:57PM +0200, Wolfgang Walter wrote:
> > > On Wednesday 12 September 2007, J. Bruce Fields wrote:
> > > > On Wed, Sep 12, 2007 at 04:14:06PM +0200, Neil Brown wrote:
> > > > > So it is in 2.6.21 and later and should probably go to .stable for
> > > > > .21 and .22.
> > > > >
> > > > > Bruce: for you :-)
> > > >
> > > > OK, thanks! But, (as is alas often the case) I'm still confused:
> > > > > if (!test_and_set_bit(SK_OLD, &svsk->sk_flags))
> > > > > continue;
> > > > > - if (atomic_read(&svsk->sk_inuse) || test_bit(SK_BUSY,
> > > > > &svsk->sk_flags)) + if (atomic_read(&svsk->sk_inuse) > 1
> > > > > + || test_bit(SK_BUSY, &svsk->sk_flags))
> > > > > continue;
> > > > > atomic_inc(&svsk->sk_inuse);
> > > > > list_move(le, &to_be_aged);
> > > >
> > > > What is it that ensures svsk->sk_inuse isn't incremented or SK_BUSY set
> > > > after that test? Not all the code that does either of those is under
> > > > the same serv->sv_lock lock that this code is.
> > >
> > > This should not matter - SK_CLOSED may be set at any time.
> > >
> > > svc_age_temp_sockets only detaches the socket, sets SK_CLOSED and then
> > > enqueues it. If SK_BUSY is set its already enqueued and svc_sock_enqueue
> > > ensures that it is not enqueued twice.
> >
> > Oh, got it. And the list manipulation is safe thanks to sv_lock. Neat,
> > thanks. Can you verify that this solves your problem?
>
> Patch works fine here.
Great, thanks again!
--b.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: [PATCH] ucc_geth: fix compilation
From: Kumar Gala @ 2007-09-14 14:07 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev@ozlabs.org list, netdev, Anton Vorontsov
In-Reply-To: <20070913152333.GA2381@localhost.localdomain>
On Sep 13, 2007, at 10:23 AM, Anton Vorontsov wrote:
> Currently qe_bd_t is used in the macro call -- dma_unmap_single,
> which is a no-op on PPC32, thus error is hidden today. Starting
> with 2.6.24, macro will be replaced by the empty static function,
> and erroneous use of qe_bd_t will trigger compilation error.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
Jeff, I'm going to pick this up via the powerpc.git tree since its
currently only broken in our for-2.6.24 branch (because of other
changes in there). Any issues?
- k
>
> Reposting this to include netdev in Cc.
>
> drivers/net/ucc_geth.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
> index 12e01b2..9a38dfe 100644
> --- a/drivers/net/ucc_geth.c
> +++ b/drivers/net/ucc_geth.c
> @@ -2148,7 +2148,7 @@ static void ucc_geth_memclean(struct
> ucc_geth_private *ugeth)
> for (j = 0; j < ugeth->ug_info->bdRingLenTx[i]; j++) {
> if (ugeth->tx_skbuff[i][j]) {
> dma_unmap_single(NULL,
> - ((qe_bd_t *)bd)->buf,
> + ((struct qe_bd *)bd)->buf,
> (in_be32((u32 *)bd) &
> BD_LENGTH_MASK),
> DMA_TO_DEVICE);
> --
> 1.5.0.6
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* TSO, TCP Cong control etc
From: jamal @ 2007-09-14 13:44 UTC (permalink / raw)
To: Bill Fink
Cc: David Miller, jheffner, rick.jones2, krkumar2, gaagaan, general,
herbert, jagana, jeff, johnpol, kaber, mcarlson, mchan, netdev,
peter.p.waskiewicz.jr, rdreier, Robert.Olsson, shemminger, sri,
tgraf, xma
In-Reply-To: <20070914032055.8f96449b.billfink@mindspring.com>
Ive changed the subject to match content..
On Fri, 2007-14-09 at 03:20 -0400, Bill Fink wrote:
> On Mon, 27 Aug 2007, jamal wrote:
>
> > Bill:
> > who suggested (as per your email) the 75usec value and what was it based
> > on measurement-wise?
>
> Belatedly getting back to this thread. There was a recent myri10ge
> patch that changed the default value for tx/rx interrupt coalescing
> to 75 usec claiming it was an optimum value for maximum throughput
> (and is also mentioned in their external README documentation).
I would think such a value would be very specific to the ring size and
maybe even the machine in use.
> I also did some empirical testing to determine the effect of different
> values of TX/RX interrupt coalescing on 10-GigE network performance,
> both with TSO enabled and with TSO disabled. The actual test runs
> are attached at the end of this message, but the results are summarized
> in the following table (network performance in Mbps).
>
> TX/RX interrupt coalescing in usec (both sides)
> 0 15 30 45 60 75 90 105
>
> TSO enabled 8909 9682 9716 9725 9739 9745 9688 9648
> TSO disabled 9113 9910 9910 9910 9910 9910 9910 9910
>
> TSO disabled performance is always better than equivalent TSO enabled
> performance. With TSO enabled, the optimum performance is indeed at
> a TX/RX interrupt coalescing value of 75 usec. With TSO disabled,
> performance is the full 10-GigE line rate of 9910 Mbps for any value
> of TX/RX interrupt coalescing from 15 usec to 105 usec.
Interesting results. I think J Heffner made a very compelling
description the other day based on your netstat results at the receiver
as to what is going on (refer to the comments on stretch ACKs). If the
receiver is fixed, then youd see better numbers from TSO.
The 75 microsecs is very benchmarky in my opinion. If i was to pick a
different app or different NIC or run on many cpus with many apps doing
TSO, i highly doubt that will be the right number.
> Here's a retest (5 tests each):
>
> TSO enabled:
>
> TCP Cubic (initial_ssthresh set to 0):
[..]
> TCP Bic (initial_ssthresh set to 0):
[..]
>
> TCP Reno:
>
[..]
> TSO disabled:
>
> TCP Cubic (initial_ssthresh set to 0):
>
[..]
> TCP Bic (initial_ssthresh set to 0):
>
[..]
> TCP Reno:
>
[..]
> Not too much variation here, and not quite as high results
> as previously.
BIC seems to be on average better followed by CUBIC followed by Reno.
The difference this time maybe because you set the ssthresh to 0
(hopefully every run) and so Reno is definetely going to perform less
better since it is a lot less agressive in comparison to other two.
> Some further testing reveals that while this
> time I mainly get results like (here for TCP Bic with TSO
> disabled):
>
> [root@lang2 ~]# nuttcp -M1460 -w10m 192.168.88.16
> 4958.0625 MB / 10.02 sec = 4148.9361 Mbps 100 %TX 99 %RX
>
> I also sometimes get results like:
>
> [root@lang2 ~]# nuttcp -M1460 -w10m 192.168.88.16
> 5882.1875 MB / 10.00 sec = 4932.5549 Mbps 100 %TX 90 %RX
>
not good.
> The higher performing results seem to correspond to when there's a
> somewhat lower receiver CPU utilization. I'm not sure but there
> could also have been an effect from running the "-M1460" test after
> the 9000 byte jumbo frame test (no jumbo tests were done at all prior
> to running the above sets of 5 tests, although I did always discard
> an initial "warmup" test, and now that I think about it some of
> those initial discarded "warmup" tests did have somewhat anomalously
> high results).
If you didnt reset the ssthresh on every run, could it have been cached
and used on subsequent runs?
> > A side note: Although the experimentation reduces the variables (eg
> > tying all to CPU0), it would be more exciting to see multi-cpu and
> > multi-flow sender effect (which IMO is more real world).
>
> These systems are intended as test systems for 10-GigE networks,
> and as such it's important to get as consistently close to full
> 10-GigE line rate as possible, and that's why the interrupts and
> nuttcp application are tied to CPU0, with almost all other system
> applications tied to CPU1.
Sure, good benchmark. You get to know how well you can do.
> Now on another system that's intended as a 10-GigE firewall system,
> it has 2 Myricom 10-GigE NICs with the interrupts for eth2 tied to
> CPU0 and the interrupts for CPU1 tied to CPU1. In IP forwarding
> tests of this system, I have basically achieved full bidirectional
> 10-GigE line rate IP forwarding with 9000 byte jumbo frames.
In forwarding a more meaningful metric would be pps. The cost per packet
tends to dominate the results over the cost/byte.
9K jumbo frames at 10G is less than 500Kpps - so i dont see that machine
you are using sweating at all. To give you a comparison on a lower end
opteron a single CPU i can generate with batching pktgen 1Mpps; Robert
says he can do that even without batching on an opteron closer to what
you are using. So if you want to run that test, youd need to use
incrementally smaller packets.
> If there's some other specific test you'd like to see, and it's not
> too difficult to set up and I have some spare time, I'll see what I
> can do.
Well, the more interesting tests would be to go full throttle on all
CPUs you have and target one (or more) receivers. i.e you simulate a
real server. Can the utility you have be bound to a cpu? If yes, you
should be able to achieve this without much effort.
Thanks a lot Bill for the effort.
cheers,
jamal
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox