* Re: [Fastboot] Re: Re: tg3: issue for reboot/kexec
From: Khalid Aziz @ 2005-08-18 18:35 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: linux-pm, Fastboot mailing list, netdev
In-Reply-To: <1124389821.2274.11.camel@lyra.fc.hp.com>
[-- Attachment #1: Type: text/plain, Size: 3728 bytes --]
On Thu, 2005-08-18 at 12:30 -0600, Khalid Aziz wrote:
> On Thu, 2005-06-30 at 17:52 -0600, Eric W. Biederman wrote:
> > Greg KH <greg@kroah.com> writes:
> >
> > > On Thu, Jun 30, 2005 at 05:21:45PM -0600, Eric W. Biederman wrote:
> > >> However I have gotten feedback a couple of times that
> > >> driver writers tend to prefer using reboot notifiers. In part
> > >> because shutdown functions don't exist for non-pci devices.
> > >
> > > That's a very lame excuse. All busses should have shutdown functions.
> > > And any device that is just bypassing all of the existing bus logic is
> > > still tying into the driver core directly (which is a bad thing by
> > > itself, but that's a different matter.) And there's a shutdown method
> > > there too.
> > >
> > > So there is no excuse to not use it. Please, if they complain, point
> > > them to me :)
> >
> > Ok.
> >
> > Then there is still my complaint and device_shutdown doesn't get called
> > on module removal which means it really doesn't get implemented. Perhaps
> > with kexec now being in the mainline kernel this will get better.
> >
> > Currently I have the following patch outstanding against the e1000
> > driver because on reboot on some boxes it card revisions
> > it places the card into a sleep state the driver initialization
> > routing cannot get the card out of.
> >
> > And yes the e1000 is bad and is using a reboot_notifier.
> >
> > Eric
> >
> > e1000_main.c | 2 +-
> > 1 files changed, 1 insertion(+), 1 deletion(-)
> >
> > diff -uNr linux-2.4.29-kexec-apic-virtwire-on-shutdownx86_64/drivers/net/e1000/e1000_main.c linux-2.4.29-e1000-no-poweroff-on-reboot/drivers/net/e1000/e1000_main.c
> > --- linux-2.4.29-kexec-apic-virtwire-on-shutdownx86_64/drivers/net/e1000/e1000_main.c Tue Feb 15 14:17:09 2005
> > +++ linux-2.4.29-e1000-no-poweroff-on-reboot/drivers/net/e1000/e1000_main.c Wed Feb 16 05:49:00 2005
> > @@ -2777,7 +2777,7 @@
> > case SYS_POWER_OFF:
> > while((pdev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, pdev))) {
> > if(pci_dev_driver(pdev) == &e1000_driver)
> > - e1000_suspend(pdev, 3);
> > + e1000_suspend(pdev, (event == SYS_DOWN)?0:3);
> > }
> > }
> > return NOTIFY_DONE;
>
> I have found that I can not walk reboot_notifier list in all cases
> before kexec'ing a new kernel. For instance, when handling INIT on ia64,
> we are running in interrupt context and atleast some of the reboot
> notifier callbacks call schedule(). Calling schedule() is not gonna work
> when we are running in interrupt context. I have the same concern for
> when panic gets called in interrupt context. So I added a shutdown
> function to e1000 driver instead. Patch is attached. This patch has
> worked for me.
>
> As soon as I have all the issues sorted out with kexec'ing on INIT on
> ia64, I will post a fully updated kexec patch for ia64. I now have kexec
> working solid on INIT with e1000 driver and it can handle multiple back
> to back INITs and come up in kexec'd kernel every time. I am now trying
> to sort some issues out with tg3 driver (another driver with no shutdown
> routine :(
>
Sorry, forgot to remove the last hunk that is already in 2.6.12. Updated
patch attached.
--
Khalid
====================================================================
Khalid Aziz Open Source and Linux Organization
(970)898-9214 Hewlett-Packard
khalid.aziz@hp.com Fort Collins, CO
"The Linux kernel is subject to relentless development"
- Alessandro Rubini
[-- Attachment #2: e1000_shutdown.patch --]
[-- Type: text/x-patch, Size: 3472 bytes --]
diff -urNp hpte-2.6/drivers/net/e1000/e1000_main.c hpte-2.6.init/drivers/net/e1000/e1000_main.c
--- hpte-2.6/drivers/net/e1000/e1000_main.c 2005-07-08 13:57:55.000000000 -0600
+++ hpte-2.6.init/drivers/net/e1000/e1000_main.c 2005-07-21 09:42:17.000000000 -0600
@@ -211,6 +211,7 @@ static void e1000_restore_vlan(struct e1
static int e1000_notify_reboot(struct notifier_block *, unsigned long event, void *ptr);
static int e1000_suspend(struct pci_dev *pdev, uint32_t state);
+static void e1000_shutdown(struct device *dev);
#ifdef CONFIG_PM
static int e1000_resume(struct pci_dev *pdev);
#endif
@@ -257,6 +258,8 @@ MODULE_PARM_DESC(debug, "Debug level (0=
* loaded. All it does is register with the PCI subsystem.
**/
+#define REBOOT_NOTIFIER 0
+
static int __init
e1000_init_module(void)
{
@@ -266,10 +269,15 @@ e1000_init_module(void)
printk(KERN_INFO "%s\n", e1000_copyright);
+#if (!REBOOT_NOTIFIER)
+ e1000_driver.driver.shutdown = e1000_shutdown;
+#endif
ret = pci_module_init(&e1000_driver);
+#if REBOOT_NOTIFIER
if(ret >= 0) {
register_reboot_notifier(&e1000_notifier_reboot);
}
+#endif
return ret;
}
@@ -285,7 +293,9 @@ module_init(e1000_init_module);
static void __exit
e1000_exit_module(void)
{
+#if REBOOT_NOTIFIER
unregister_reboot_notifier(&e1000_notifier_reboot);
+#endif
pci_unregister_driver(&e1000_driver);
}
@@ -3197,6 +3207,71 @@ e1000_suspend(struct pci_dev *pdev, uint
return 0;
}
+static void
+e1000_shutdown(struct device *dev)
+{
+ struct pci_dev *pdev = to_pci_dev(dev);
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct e1000_adapter *adapter = netdev->priv;
+ struct e1000_hw *hw = &adapter->hw;
+ uint32_t ctrl;
+
+ netif_device_detach(netdev);
+
+ if(netif_running(netdev)) {
+ e1000_irq_disable(adapter);
+ del_timer(&adapter->tx_fifo_stall_timer);
+ del_timer(&adapter->watchdog_timer);
+ del_timer(&adapter->phy_info_timer);
+
+#ifdef CONFIG_E1000_NAPI
+ netif_poll_disable(netdev);
+#endif
+ adapter->link_speed = 0;
+ adapter->link_duplex = 0;
+ netif_carrier_off(netdev);
+ netif_stop_queue(netdev);
+ }
+
+ ctrl = E1000_READ_REG(hw, CTRL);
+
+ /* Must reset the PHY before resetting the MAC */
+ if((hw->mac_type == e1000_82541) || (hw->mac_type == e1000_82547)) {
+ E1000_WRITE_REG_IO(hw, CTRL, (ctrl | E1000_CTRL_PHY_RST));
+ mdelay(5);
+ }
+
+ /* Issue a global reset to the MAC. This will reset the chip's
+ * transmit, receive, DMA, and link units. It will not effect
+ * the current PCI configuration. The global reset bit is self-
+ * clearing, and should clear within a microsecond.
+ */
+ switch(hw->mac_type) {
+ case e1000_82544:
+ case e1000_82540:
+ case e1000_82545:
+ case e1000_82546:
+ case e1000_82541:
+ case e1000_82541_rev_2:
+ /* These controllers can't ack the 64-bit write when issuing the
+ * reset, so use IO-mapping as a workaround to issue the reset
+ */
+ E1000_WRITE_REG_IO(hw, CTRL, (ctrl | E1000_CTRL_RST));
+ break;
+ case e1000_82545_rev_3:
+ case e1000_82546_rev_3:
+ /* Reset is performed on a shadow of the control register */
+ E1000_WRITE_REG(hw, CTRL_DUP, (ctrl | E1000_CTRL_RST));
+ break;
+ default:
+ E1000_WRITE_REG(hw, CTRL, (ctrl | E1000_CTRL_RST));
+ break;
+ }
+
+ pci_disable_device(pdev);
+ pci_set_power_state(pdev, 0);
+}
+
#ifdef CONFIG_PM
static int
e1000_resume(struct pci_dev *pdev)
[-- Attachment #3: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [Fastboot] Re: Re: tg3: issue for reboot/kexec
From: Eric W. Biederman @ 2005-08-18 18:42 UTC (permalink / raw)
To: Khalid Aziz; +Cc: linux-pm, Fastboot mailing list, netdev
In-Reply-To: <1124389821.2274.11.camel@lyra.fc.hp.com>
[-- Attachment #1: Type: text/plain, Size: 1485 bytes --]
Khalid Aziz <khalid_aziz@hp.com> writes:
> On Thu, 2005-06-30 at 17:52 -0600, Eric W. Biederman wrote:
>
> I have found that I can not walk reboot_notifier list in all cases
> before kexec'ing a new kernel. For instance, when handling INIT on ia64,
> we are running in interrupt context and atleast some of the reboot
> notifier callbacks call schedule(). Calling schedule() is not gonna work
> when we are running in interrupt context. I have the same concern for
> when panic gets called in interrupt context. So I added a shutdown
> function to e1000 driver instead. Patch is attached. This patch has
> worked for me.
Thanks. I will look at your e1000 driver and see if it works on
the hardware I have here. You changes are at least to places
that could have fixed the problem I am seeing.
For the panic case calling any of the shutdown/reboot notifier bits
is actually wrong. That kernel that takes over needs to cope with
hardware left in any state.
> As soon as I have all the issues sorted out with kexec'ing on INIT on
> ia64, I will post a fully updated kexec patch for ia64. I now have kexec
> working solid on INIT with e1000 driver and it can handle multiple back
> to back INITs and come up in kexec'd kernel every time. I am now trying
> to sort some issues out with tg3 driver (another driver with no shutdown
> routine :(
In the normal case (not kexec on panic) user space should down the interfaces
before calling kexec. Is your user space doing that?
Eric
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH] fix dst_entry leak in icmp_push_reply()
From: Patrick McHardy @ 2005-08-18 18:42 UTC (permalink / raw)
To: Ollie Wild; +Cc: linux-kernel, Maillist netdev
In-Reply-To: <43042D94.4030303@rincewind.tv>
Ollie Wild wrote:
> Patrick McHardy wrote:
>
>> Ollie Wild wrote:
>>
>>> If the ip_append_data() call in icmp_push_reply() fails,
>>> ip_flush_pending_frames() needs to be called. Otherwise, ip_rt_put()
>>> is never called on inet_sk(icmp_socket->sk)->cork.rt, which prevents
>>> the route (and net_device) from ever being freed.
>>
>> Your patch doesn't fit your description, the else-condition you're
>> adding triggers when the queue is empty, so what is the point?
>
> Since we're only calling ip_append_data() once here, the two conditions
> are identical.
You're right, I misread your patch. It would be easier to understand
if you just checked the return value of ip_append_data, as done in
udp.c or raw.c.
^ permalink raw reply
* Re: [PATCH] fix dst_entry leak in icmp_push_reply()
From: Patrick McHardy @ 2005-08-18 18:59 UTC (permalink / raw)
To: Ollie Wild; +Cc: linux-kernel, Maillist netdev
In-Reply-To: <4304D763.4090001@rincewind.tv>
[-- Attachment #1: Type: text/plain, Size: 634 bytes --]
Ollie Wild wrote:
> That said, I appreciate that the if-else condition doesn't seem quite
> right. The problem is, the icmp_push_reply() routine is implicitly
> using the queue as a success indicator. I put the
> ip_flush_pending_frames() call inside the else block because I wanted to
> guarantee that one of ip_push_pending_frames() and
> ip_flush_pending_frames() is always called. Both will do proper cleanup.
>
> I'm open to suggestions if you think there's a cleaner way to implement
> this.
Checking the return value of ip_append_data seems cleaner to me.
Patch attached.
Signed-off-by: Patrick McHardy <kaber@trash.net>
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 844 bytes --]
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -349,12 +349,12 @@ static void icmp_push_reply(struct icmp_
{
struct sk_buff *skb;
- ip_append_data(icmp_socket->sk, icmp_glue_bits, icmp_param,
- icmp_param->data_len+icmp_param->head_len,
- icmp_param->head_len,
- ipc, rt, MSG_DONTWAIT);
-
- if ((skb = skb_peek(&icmp_socket->sk->sk_write_queue)) != NULL) {
+ if (ip_append_data(icmp_socket->sk, icmp_glue_bits, icmp_param,
+ icmp_param->data_len+icmp_param->head_len,
+ icmp_param->head_len,
+ ipc, rt, MSG_DONTWAIT) < 0)
+ ip_flush_pending_frames(icmp_socket->sk);
+ else if ((skb = skb_peek(&icmp_socket->sk->sk_write_queue)) != NULL) {
struct icmphdr *icmph = skb->h.icmph;
unsigned int csum = 0;
struct sk_buff *skb1;
^ permalink raw reply
* Re: [PATCH] fix dst_entry leak in icmp_push_reply()
From: Ollie Wild @ 2005-08-18 19:05 UTC (permalink / raw)
To: Patrick McHardy; +Cc: linux-kernel, Maillist netdev
In-Reply-To: <4304DA99.2080205@trash.net>
Patrick McHardy wrote:
>Checking the return value of ip_append_data seems cleaner to me.
>Patch attached.
>
>
Works for me.
Thanks,
Ollie
^ permalink raw reply
* Re: [Fastboot] Re: Re: tg3: issue for reboot/kexec
From: Khalid Aziz @ 2005-08-18 19:06 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: linux-pm, Fastboot mailing list, netdev
In-Reply-To: <m1wtmjulxe.fsf@ebiederm.dsl.xmission.com>
[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]
On Thu, 2005-08-18 at 12:42 -0600, Eric W. Biederman wrote:
> Khalid Aziz <khalid_aziz@hp.com> writes:
> > As soon as I have all the issues sorted out with kexec'ing on INIT on
> > ia64, I will post a fully updated kexec patch for ia64. I now have kexec
> > working solid on INIT with e1000 driver and it can handle multiple back
> > to back INITs and come up in kexec'd kernel every time. I am now trying
> > to sort some issues out with tg3 driver (another driver with no shutdown
> > routine :(
>
> In the normal case (not kexec on panic) user space should down the interfaces
> before calling kexec. Is your user space doing that?
Yes, I am down'ing the interface from userspace in normal kexec case,
but that does not happen on INIT on ia64.
--
Khalid
====================================================================
Khalid Aziz Open Source and Linux Organization
(970)898-9214 Hewlett-Packard
khalid.aziz@hp.com Fort Collins, CO
"The Linux kernel is subject to relentless development"
- Alessandro Rubini
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH] fix dst_entry leak in icmp_push_reply()
From: David S. Miller @ 2005-08-18 21:32 UTC (permalink / raw)
To: aaw; +Cc: kaber, linux-kernel, netdev
In-Reply-To: <4304DBFB.5010906@rincewind.tv>
From: Ollie Wild <aaw@rincewind.tv>
Date: Thu, 18 Aug 2005 12:05:31 -0700
> Patrick McHardy wrote:
>
> >Checking the return value of ip_append_data seems cleaner to me.
> >Patch attached.
> >
> >
> Works for me.
Applied, thanks everyone.
^ permalink raw reply
* Re: overflows in /proc/net/dev
From: David S. Miller @ 2005-08-18 21:32 UTC (permalink / raw)
To: cw; +Cc: Sebastian.Classen, linux-kernel, netdev
In-Reply-To: <20050818163358.GA19554@taniwha.stupidest.org>
From: Chris Wedgwood <cw@f00f.org>
Date: Thu, 18 Aug 2005 09:33:58 -0700
> I thought the concensurs here was that because doing reliable atomic
> updates of 64-bit values isn't possible on some (most?) 32-bit
> architectures so we need additional locking to make this work which is
> undesirable? (It might even be a FAQ by now as this comes up fairly
> often).
That's correct.
^ permalink raw reply
* Possible race with br_del_if()
From: Ryan Harper @ 2005-08-18 21:40 UTC (permalink / raw)
To: shemminger; +Cc: netdev
Hello,
I've encountered several oops when adding and removing interfaces from
bridges while using Xen. Most of the details are available [1]here.
The short of it is the following sequence:
CPU0 CPU1
add_del_if() unregister_netdevice()
br_del_if() notifier_call_chain(NETDEV_UNREGISTER)
del_nbp()
br_stp_disable_port() // port->state == BR_STATE_DISABLED
br_device_event() // dev->br_port != NULL yet
// event is NETDEV_UNREGISTER
br_del_if()
sysfs_remove_dir(p)
kobject_del()
dget(dentry)
BUG_ON(!atomic_read(&dentry->d_count)
This sequence doesn't happen all of the time. In many cases, CPU0 moves
along right into destroy_nbp() which sets dev->br_port = NULL, and
be_device_event check (p == NULL) hits and a second br_del_if() isn't
called.
The attached patch is a workaround for the double case, but I'm not sure
if is the right way to deal with this issue, or if it any issue at all.
1. http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=90
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
ryanh@us.ibm.com
diffstat output:
br_if.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
---
Simple workaround for double call to br_del_if().
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
--- linux-2.6.12/net/bridge/br_if.c 2005-06-17 14:48:29.000000000 -0500
+++ linux-2.6.12-xen0-smp/net/bridge/br_if.c 2005-08-18 15:17:27.302615846 -0500
@@ -382,7 +382,7 @@
{
struct net_bridge_port *p = dev->br_port;
- if (!p || p->br != br)
+ if (!p || p->br != br || p->state == BR_STATE_DISABLED)
return -EINVAL;
br_sysfs_removeif(p);
^ permalink raw reply
* [git patches] 2.6.x net driver fixes
From: Jeff Garzik @ 2005-08-18 21:48 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton; +Cc: Netdev List, Linux Kernel
[-- Attachment #1: Type: text/plain, Size: 196 bytes --]
Please pull from the 'upstream-fixes' branch of
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
to receive the fixes described in the attached diffstat/changelog/patch.
[-- Attachment #2: netdev-2.6.txt --]
[-- Type: text/plain, Size: 9508 bytes --]
drivers/net/8139cp.c | 7 ++++++
drivers/net/dm9000.c | 52 ++++++++++++++++++++++++-------------------------
drivers/net/ioc3-eth.c | 8 +++----
3 files changed, 37 insertions(+), 30 deletions(-)
commit 2ae2d77cfa424587014cb34a89eed0ff2149fd5c
Author: Ben Dooks <ben-netdev@fluff.org>
Date: Sat Jul 23 17:29:38 2005 +0100
[PATCH] DM9000 - incorrect ioctl() handling
The DM9000 driver is responding to ioctl() calls it should not be. This
can cause problems with the wireless tools incorrectly indentifying the
device as wireless capable, and crashing under certain operations.
This patch also moves the version printk() to the init call, so that
you only get it once for multiple devices, and to show it is loaded
if there are no defined dm9000s
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
commit 9ef9ac51cc5fa5f5811230b5fb242536b636ff47
Author: Ben Dooks <ben-netdev@fluff.org>
Date: Sat Jul 23 17:25:18 2005 +0100
[PATCH] DM9000 - spinlock fixes
Fix DM9000 driver usage of spinlocks, which mainly came to light
when running a kernel with spinlock debugging. These come down to:
1) Un-initialised spin lock
2) Several cases of using spin_xxx(lock) and not spin_xxx(&lock)
3) move the locking around the phy reg for read/write to only
keep the lock when actually reading or writing to the phy.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
commit a4cf0761493495681d72dcc0b34efb86e94a5527
Author: Pierre Ossman <drzeus-list@drzeus.cx>
Date: Mon Jul 4 00:22:53 2005 +0200
[PATCH] 8139cp - redetect link after suspend
After suspend the driver needs to retest link status in case the cable
has been inserted or removed during the suspend.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
commit 852ea22ab24df4c64c0211c3b6d6358eb0e759f9
Author: Ralf Baechle <ralf@linux-mips.org>
Date: Tue Aug 2 11:01:27 2005 +0100
[PATCH] IOC3 fixes
- Using the right register clearly improves chances of getting the MII
code and thus the driver working at all.
- On startup check the media type before setting up duplex or we might
spend the first 1.2s with a wrong duplex setting.
- Get rid of whitespace lines.
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
diff --git a/drivers/net/8139cp.c b/drivers/net/8139cp.c
--- a/drivers/net/8139cp.c
+++ b/drivers/net/8139cp.c
@@ -1897,6 +1897,7 @@ static int cp_resume (struct pci_dev *pd
{
struct net_device *dev;
struct cp_private *cp;
+ unsigned long flags;
dev = pci_get_drvdata (pdev);
cp = netdev_priv(dev);
@@ -1910,6 +1911,12 @@ static int cp_resume (struct pci_dev *pd
cp_init_hw (cp);
netif_start_queue (dev);
+
+ spin_lock_irqsave (&cp->lock, flags);
+
+ mii_check_media(&cp->mii_if, netif_msg_link(cp), FALSE);
+
+ spin_unlock_irqrestore (&cp->lock, flags);
return 0;
}
diff --git a/drivers/net/dm9000.c b/drivers/net/dm9000.c
--- a/drivers/net/dm9000.c
+++ b/drivers/net/dm9000.c
@@ -48,6 +48,10 @@
* net_device_stats
* * introduced tx_timeout function
* * reworked locking
+ *
+ * 01-Jul-2005 Ben Dooks <ben@simtec.co.uk>
+ * * fixed spinlock call without pointer
+ * * ensure spinlock is initialised
*/
#include <linux/module.h>
@@ -148,7 +152,6 @@ static int dm9000_probe(struct device *)
static int dm9000_open(struct net_device *);
static int dm9000_start_xmit(struct sk_buff *, struct net_device *);
static int dm9000_stop(struct net_device *);
-static int dm9000_do_ioctl(struct net_device *, struct ifreq *, int);
static void dm9000_timer(unsigned long);
@@ -322,7 +325,7 @@ static void dm9000_timeout(struct net_de
/* Save previous register address */
reg_save = readb(db->io_addr);
- spin_lock_irqsave(db->lock,flags);
+ spin_lock_irqsave(&db->lock,flags);
netif_stop_queue(dev);
dm9000_reset(db);
@@ -333,7 +336,7 @@ static void dm9000_timeout(struct net_de
/* Restore previous register address */
writeb(reg_save, db->io_addr);
- spin_unlock_irqrestore(db->lock,flags);
+ spin_unlock_irqrestore(&db->lock,flags);
}
@@ -387,8 +390,6 @@ dm9000_probe(struct device *dev)
int i;
u32 id_val;
- printk(KERN_INFO "%s Ethernet Driver\n", CARDNAME);
-
/* Init network device */
ndev = alloc_etherdev(sizeof (struct board_info));
if (!ndev) {
@@ -405,6 +406,8 @@ dm9000_probe(struct device *dev)
db = (struct board_info *) ndev->priv;
memset(db, 0, sizeof (*db));
+ spin_lock_init(&db->lock);
+
if (pdev->num_resources < 2) {
ret = -ENODEV;
goto out;
@@ -541,7 +544,6 @@ dm9000_probe(struct device *dev)
ndev->stop = &dm9000_stop;
ndev->get_stats = &dm9000_get_stats;
ndev->set_multicast_list = &dm9000_hash_table;
- ndev->do_ioctl = &dm9000_do_ioctl;
#ifdef DM9000_PROGRAM_EEPROM
program_eeprom(db);
@@ -612,7 +614,7 @@ dm9000_open(struct net_device *dev)
/* set and active a timer process */
init_timer(&db->timer);
- db->timer.expires = DM9000_TIMER_WUT * 2;
+ db->timer.expires = DM9000_TIMER_WUT;
db->timer.data = (unsigned long) dev;
db->timer.function = &dm9000_timer;
add_timer(&db->timer);
@@ -845,15 +847,6 @@ dm9000_get_stats(struct net_device *dev)
return &db->stats;
}
-/*
- * Process the upper socket ioctl command
- */
-static int
-dm9000_do_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
-{
- PRINTK1("entering %s\n",__FUNCTION__);
- return 0;
-}
/*
* A periodic timer routine
@@ -864,21 +857,11 @@ dm9000_timer(unsigned long data)
{
struct net_device *dev = (struct net_device *) data;
board_info_t *db = (board_info_t *) dev->priv;
- u8 reg_save;
- unsigned long flags;
PRINTK3("dm9000_timer()\n");
- spin_lock_irqsave(db->lock,flags);
- /* Save previous register address */
- reg_save = readb(db->io_addr);
-
mii_check_media(&db->mii, netif_msg_link(db), 0);
- /* Restore previous register address */
- writeb(reg_save, db->io_addr);
- spin_unlock_irqrestore(db->lock,flags);
-
/* Set timer again */
db->timer.expires = DM9000_TIMER_WUT;
add_timer(&db->timer);
@@ -1098,9 +1081,14 @@ dm9000_phy_read(struct net_device *dev,
{
board_info_t *db = (board_info_t *) dev->priv;
unsigned long flags;
+ unsigned int reg_save;
int ret;
spin_lock_irqsave(&db->lock,flags);
+
+ /* Save previous register address */
+ reg_save = readb(db->io_addr);
+
/* Fill the phyxcer register into REG_0C */
iow(db, DM9000_EPAR, DM9000_PHY | reg);
@@ -1111,6 +1099,9 @@ dm9000_phy_read(struct net_device *dev,
/* The read data keeps on REG_0D & REG_0E */
ret = (ior(db, DM9000_EPDRH) << 8) | ior(db, DM9000_EPDRL);
+ /* restore the previous address */
+ writeb(reg_save, db->io_addr);
+
spin_unlock_irqrestore(&db->lock,flags);
return ret;
@@ -1124,9 +1115,13 @@ dm9000_phy_write(struct net_device *dev,
{
board_info_t *db = (board_info_t *) dev->priv;
unsigned long flags;
+ unsigned long reg_save;
spin_lock_irqsave(&db->lock,flags);
+ /* Save previous register address */
+ reg_save = readb(db->io_addr);
+
/* Fill the phyxcer register into REG_0C */
iow(db, DM9000_EPAR, DM9000_PHY | reg);
@@ -1138,6 +1133,9 @@ dm9000_phy_write(struct net_device *dev,
udelay(500); /* Wait write complete */
iow(db, DM9000_EPCR, 0x0); /* Clear phyxcer write command */
+ /* restore the previous address */
+ writeb(reg_save, db->io_addr);
+
spin_unlock_irqrestore(&db->lock,flags);
}
@@ -1202,6 +1200,8 @@ static struct device_driver dm9000_drive
static int __init
dm9000_init(void)
{
+ printk(KERN_INFO "%s Ethernet Driver\n", CARDNAME);
+
return driver_register(&dm9000_driver); /* search board and register */
}
diff --git a/drivers/net/ioc3-eth.c b/drivers/net/ioc3-eth.c
--- a/drivers/net/ioc3-eth.c
+++ b/drivers/net/ioc3-eth.c
@@ -499,7 +499,7 @@ static int ioc3_mdio_read(struct net_dev
ioc3_w_micr((phy << MICR_PHYADDR_SHIFT) | reg | MICR_READTRIG);
while (ioc3_r_micr() & MICR_BUSY);
- return ioc3_r_micr() & MIDR_DATA_MASK;
+ return ioc3_r_midr_r() & MIDR_DATA_MASK;
}
static void ioc3_mdio_write(struct net_device *dev, int phy, int reg, int data)
@@ -1291,7 +1291,6 @@ static int ioc3_probe(struct pci_dev *pd
dev->features = NETIF_F_IP_CSUM;
#endif
- ioc3_setup_duplex(ip);
sw_physid1 = ioc3_mdio_read(dev, ip->mii.phy_id, MII_PHYSID1);
sw_physid2 = ioc3_mdio_read(dev, ip->mii.phy_id, MII_PHYSID2);
@@ -1300,6 +1299,7 @@ static int ioc3_probe(struct pci_dev *pd
goto out_stop;
mii_check_media(&ip->mii, 1, 1);
+ ioc3_setup_duplex(ip);
vendor = (sw_physid1 << 12) | (sw_physid2 >> 4);
model = (sw_physid2 >> 4) & 0x3f;
@@ -1524,7 +1524,7 @@ static void ioc3_get_drvinfo (struct net
struct ethtool_drvinfo *info)
{
struct ioc3_private *ip = netdev_priv(dev);
-
+
strcpy (info->driver, IOC3_NAME);
strcpy (info->version, IOC3_VERSION);
strcpy (info->bus_info, pci_name(ip->pdev));
@@ -1550,7 +1550,7 @@ static int ioc3_set_settings(struct net_
spin_lock_irq(&ip->ioc3_lock);
rc = mii_ethtool_sset(&ip->mii, cmd);
spin_unlock_irq(&ip->ioc3_lock);
-
+
return rc;
}
^ permalink raw reply
* Re: Possible race with br_del_if()
From: Stephen Hemminger @ 2005-08-18 22:12 UTC (permalink / raw)
To: Ryan Harper; +Cc: netdev
In-Reply-To: <20050818214036.GH10593@us.ibm.com>
On Thu, 18 Aug 2005 16:40:36 -0500
Ryan Harper <ryanh@us.ibm.com> wrote:
> Hello,
>
> I've encountered several oops when adding and removing interfaces from
> bridges while using Xen. Most of the details are available [1]here.
> The short of it is the following sequence:
Doesn't the mutex in RTNL work right? or are you calling
routines with out asserting it?
> CPU0 CPU1
> add_del_if() unregister_netdevice()
> br_del_if() notifier_call_chain(NETDEV_UNREGISTER)
> del_nbp()
> br_stp_disable_port() // port->state == BR_STATE_DISABLED
> br_device_event() // dev->br_port != NULL yet
> // event is NETDEV_UNREGISTER
> br_del_if()
> sysfs_remove_dir(p)
> kobject_del()
> dget(dentry)
> BUG_ON(!atomic_read(&dentry->d_count)
>
> This sequence doesn't happen all of the time. In many cases, CPU0 moves
> along right into destroy_nbp() which sets dev->br_port = NULL, and
> be_device_event check (p == NULL) hits and a second br_del_if() isn't
> called.
>
> The attached patch is a workaround for the double case, but I'm not sure
> if is the right way to deal with this issue, or if it any issue at all.
>
> 1. http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=90
>
^ permalink raw reply
* Re: overflows in /proc/net/dev
From: Stephen Hemminger @ 2005-08-18 22:13 UTC (permalink / raw)
To: David S. Miller; +Cc: cw, Sebastian.Classen, linux-kernel, netdev
In-Reply-To: <20050818.143248.58283961.davem@davemloft.net>
On Thu, 18 Aug 2005 14:32:48 -0700 (PDT)
"David S. Miller" <davem@davemloft.net> wrote:
> From: Chris Wedgwood <cw@f00f.org>
> Date: Thu, 18 Aug 2005 09:33:58 -0700
>
> > I thought the concensurs here was that because doing reliable atomic
> > updates of 64-bit values isn't possible on some (most?) 32-bit
> > architectures so we need additional locking to make this work which is
> > undesirable? (It might even be a FAQ by now as this comes up fairly
> > often).
>
> That's correct.
Also width of fields in /proc/net/dev can't change without potentially
breaking ABI of applications.
^ permalink raw reply
* Re: Possible race with br_del_if()
From: Ryan Harper @ 2005-08-18 22:23 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20050818151202.6fe6ded4@dxpl.pdx.osdl.net>
* Stephen Hemminger <shemminger@osdl.org> [2005-08-18 17:11]:
> On Thu, 18 Aug 2005 16:40:36 -0500
> Ryan Harper <ryanh@us.ibm.com> wrote:
>
> > Hello,
> >
> > I've encountered several oops when adding and removing interfaces from
> > bridges while using Xen. Most of the details are available [1]here.
> > The short of it is the following sequence:
>
> Doesn't the mutex in RTNL work right? or are you calling
> routines with out asserting it?
unregister_netdevice asserts RTNL, add_del_if() in br_ioctl.c doesn't
seem to do so. I don't see it down dev_get_by_index() path either. It
looks like any caller of add_del_if() isn't asserting RTNL. The two
callers I see are:
br_dev_ioctl() in br_ioctl.c
old_dev_ioctl() in br_ioctl.c
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
ryanh@us.ibm.com
^ permalink raw reply
* Re: Possible race with br_del_if()
From: Stephen Hemminger @ 2005-08-18 22:35 UTC (permalink / raw)
To: Ryan Harper; +Cc: netdev
In-Reply-To: <20050818222323.GI10593@us.ibm.com>
On Thu, 18 Aug 2005 17:23:23 -0500
Ryan Harper <ryanh@us.ibm.com> wrote:
> * Stephen Hemminger <shemminger@osdl.org> [2005-08-18 17:11]:
> > On Thu, 18 Aug 2005 16:40:36 -0500
> > Ryan Harper <ryanh@us.ibm.com> wrote:
> >
> > > Hello,
> > >
> > > I've encountered several oops when adding and removing interfaces from
> > > bridges while using Xen. Most of the details are available [1]here.
> > > The short of it is the following sequence:
> >
> > Doesn't the mutex in RTNL work right? or are you calling
> > routines with out asserting it?
>
> unregister_netdevice asserts RTNL, add_del_if() in br_ioctl.c doesn't
> seem to do so. I don't see it down dev_get_by_index() path either. It
> looks like any caller of add_del_if() isn't asserting RTNL. The two
> callers I see are:
>
> br_dev_ioctl() in br_ioctl.c
> old_dev_ioctl() in br_ioctl.c
But the pat to br_dev_ioctl() is via the socket ioctl and that
should already have gotten RTNL.
dev_ioctl
rtnl_lock()
dev_ifsioc()
dev->do_ioctl --> br_dev_ioctl
^ permalink raw reply
* Re: Possible race with br_del_if()
From: Ryan Harper @ 2005-08-18 22:56 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20050818153531.61f62ac0@dxpl.pdx.osdl.net>
* Stephen Hemminger <shemminger@osdl.org> [2005-08-18 17:36]:
> On Thu, 18 Aug 2005 17:23:23 -0500
> Ryan Harper <ryanh@us.ibm.com> wrote:
>
> > * Stephen Hemminger <shemminger@osdl.org> [2005-08-18 17:11]:
> > > On Thu, 18 Aug 2005 16:40:36 -0500
> > > Ryan Harper <ryanh@us.ibm.com> wrote:
> > >
> > > > Hello,
> > > >
> > > > I've encountered several oops when adding and removing interfaces from
> > > > bridges while using Xen. Most of the details are available [1]here.
> > > > The short of it is the following sequence:
> > >
> > > Doesn't the mutex in RTNL work right? or are you calling
> > > routines with out asserting it?
> >
> > unregister_netdevice asserts RTNL, add_del_if() in br_ioctl.c doesn't
> > seem to do so. I don't see it down dev_get_by_index() path either. It
> > looks like any caller of add_del_if() isn't asserting RTNL. The two
> > callers I see are:
> >
> > br_dev_ioctl() in br_ioctl.c
> > old_dev_ioctl() in br_ioctl.c
>
> But the pat to br_dev_ioctl() is via the socket ioctl and that
> should already have gotten RTNL.
>
>
> dev_ioctl
> rtnl_lock()
> dev_ifsioc()
> dev->do_ioctl --> br_dev_ioctl
Hrm. OK. It sounds like both paths are doing the right thing w.r.t
asserting RTNL, but br_device_event() still gets called with:
1) dev->br_port != NULL
2) dev->br_port->state = BR_STATE_DISABLED
3) event = NETDEV_UNREGISTER
which results in br_del_if() being called a second time on the same
port.
Some of the other cases (NETDEV_FEAT_CHANGE, NETDEV_CHANGE) do a state
check before calling a subsequent function. Does it make sense for
br_del_if() to be called on a port whose state is BR_STATE_DISABLED?
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
ryanh@us.ibm.com
^ permalink raw reply
* [git] netdev-2.6 queue updated
From: Jeff Garzik @ 2005-08-19 3:34 UTC (permalink / raw)
To: netdev, akpm; +Cc: linux-kernel
I finally got around to creating something that has been missing since
BitKeeper disappeared, and something that Andrew has been wanting
from me for a while: an amalgamation of all the netdev branches that
I maintain internally.
First, a bit of background. Most patches I receive are dumped into the
'upstream' branch of netdev-2.6.git. However, some patches require more
development or review before they are ready for upstream. In such cases,
patches are divided into branches by category: chelsio (new 10gb driver
from Chelsio Comm), e100 (e100 changes some users complained about),
sis190 (resurrected SiS190 driver), ieee80211-wifi (wireless layer
rewrite), etc.
All these branches are terribly useful to me. Dividing the changes up in
this manner means that some less-cooked changes can stay in the git
repository, while I can forward important changes to Andrew/Linus
immediately. The downside is that this system leaves people with a
confusing set of branches.
The solution is something that I maintained during the BitKeeper days,
the "ALL" branch. As the name implies, this branch contains all the
branches in netdev-2.6.git. The creation of this branch also facilitates
the creation of a single downloadable patch (see below) that users can
easily patch into their kernel, without having to learn git.
To Andrew Morton specifically: Please replace all git-netdev-* patches
with the content of the 'ALL' branch. You can simply pull the 'ALL'
branch, and ignore all others.
The following is the current contents of the netdev queue's ALL branch,
which is a superset of all other branches in the repository:
git users: 'ALL' branch of
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
Patch:
http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.13-rc6-git10-netdev1.patch.bz2
drivers/net/wireless/ieee802_11.h | 78
Documentation/networking/README.ipw2100 | 246
Documentation/networking/README.ipw2200 | 290
Documentation/networking/cxgb.txt | 352 +
Documentation/networking/phy.txt | 288
MAINTAINERS | 13
drivers/net/Kconfig | 51
drivers/net/Makefile | 4
drivers/net/Space.c | 6
drivers/net/bonding/bond_alb.c | 17
drivers/net/chelsio/Makefile | 11
drivers/net/chelsio/common.h | 314
drivers/net/chelsio/cphy.h | 148
drivers/net/chelsio/cpl5_cmd.h | 145
drivers/net/chelsio/cxgb2.c | 1256 +++
drivers/net/chelsio/elmer0.h | 151
drivers/net/chelsio/espi.c | 346 +
drivers/net/chelsio/espi.h | 68
drivers/net/chelsio/gmac.h | 134
drivers/net/chelsio/mv88x201x.c | 252
drivers/net/chelsio/pm3393.c | 826 ++
drivers/net/chelsio/regs.h | 468 +
drivers/net/chelsio/sge.c | 1684 +++++
drivers/net/chelsio/sge.h | 105
drivers/net/chelsio/subr.c | 812 ++
drivers/net/chelsio/suni1x10gexp_regs.h | 213
drivers/net/e100.c | 225
drivers/net/forcedeth.c | 577 +
drivers/net/hamradio/baycom_epp.c | 3
drivers/net/hamradio/baycom_par.c | 3
drivers/net/hamradio/baycom_ser_fdx.c | 3
drivers/net/hamradio/baycom_ser_hdx.c | 3
drivers/net/hamradio/mkiss.c | 3
drivers/net/ixgb/ixgb.h | 2
drivers/net/ixgb/ixgb_ee.c | 170
drivers/net/ixgb/ixgb_ethtool.c | 59
drivers/net/ixgb/ixgb_hw.h | 9
drivers/net/ixgb/ixgb_main.c | 53
drivers/net/loopback.c | 22
drivers/net/pci-skeleton.c | 6
drivers/net/phy/Kconfig | 49
drivers/net/phy/Makefile | 9
drivers/net/phy/cicada.c | 134
drivers/net/phy/davicom.c | 195
drivers/net/phy/lxt.c | 179
drivers/net/phy/marvell.c | 140
drivers/net/phy/mdio_bus.c | 99
drivers/net/phy/phy.c | 690 ++
drivers/net/phy/phy_device.c | 572 +
drivers/net/phy/qsemi.c | 143
drivers/net/s2io-regs.h | 85
drivers/net/s2io.c | 3098 +++++----
drivers/net/s2io.h | 364 -
drivers/net/sis190.c | 1842 +++++
drivers/net/skge.c | 63
drivers/net/skge.h | 19
drivers/net/sky2.c | 2686 ++++++++
drivers/net/sky2.h | 1935 +++++
drivers/net/smc91x.c | 159
drivers/net/smc91x.h | 9
drivers/net/tokenring/abyss.c | 2
drivers/net/tokenring/proteon.c | 104
drivers/net/tokenring/skisa.c | 104
drivers/net/tokenring/tms380tr.c | 37
drivers/net/tokenring/tms380tr.h | 8
drivers/net/tokenring/tmspci.c | 4
drivers/net/tulip/Kconfig | 12
drivers/net/tulip/Makefile | 1
drivers/net/tulip/media.c | 36
drivers/net/tulip/timer.c | 1
drivers/net/tulip/tulip.h | 8
drivers/net/tulip/tulip_core.c | 34
drivers/net/tulip/uli526x.c | 1770 +++++
drivers/net/wireless/Kconfig | 106
drivers/net/wireless/Makefile | 6
drivers/net/wireless/airo.c | 65
drivers/net/wireless/atmel.c | 62
drivers/net/wireless/hostap/Kconfig | 71
drivers/net/wireless/hostap/Makefile | 5
drivers/net/wireless/hostap/hostap.c | 1198 +++
drivers/net/wireless/hostap/hostap.h | 57
drivers/net/wireless/hostap/hostap_80211.h | 96
drivers/net/wireless/hostap/hostap_80211_rx.c | 1091 +++
drivers/net/wireless/hostap/hostap_80211_tx.c | 524 +
drivers/net/wireless/hostap/hostap_ap.c | 3288 +++++++++
drivers/net/wireless/hostap/hostap_ap.h | 261
drivers/net/wireless/hostap/hostap_common.h | 435 +
drivers/net/wireless/hostap/hostap_config.h | 55
drivers/net/wireless/hostap/hostap_cs.c | 1030 +++
drivers/net/wireless/hostap/hostap_download.c | 766 ++
drivers/net/wireless/hostap/hostap_hw.c | 3445 ++++++++++
drivers/net/wireless/hostap/hostap_info.c | 499 +
drivers/net/wireless/hostap/hostap_ioctl.c | 4102 ++++++++++++
drivers/net/wireless/hostap/hostap_pci.c | 473 +
drivers/net/wireless/hostap/hostap_plx.c | 645 +
drivers/net/wireless/hostap/hostap_proc.c | 448 +
drivers/net/wireless/hostap/hostap_wlan.h | 1033 +++
drivers/net/wireless/ipw2100.c | 8641 ++++++++++++++++++++++++++
drivers/net/wireless/ipw2100.h | 1195 +++
drivers/net/wireless/ipw2200.c | 7361 ++++++++++++++++++++++
drivers/net/wireless/ipw2200.h | 1770 +++++
drivers/net/wireless/orinoco.c | 89
drivers/net/wireless/strip.c | 2
drivers/net/wireless/wavelan_cs.c | 26
drivers/net/wireless/wavelan_cs.h | 6
drivers/net/wireless/wavelan_cs.p.h | 17
drivers/net/wireless/wl3501.h | 4
drivers/net/wireless/wl3501_cs.c | 11
drivers/usb/net/Makefile | 2
drivers/usb/net/zd1201.c | 16
include/linux/etherdevice.h | 6
include/linux/ethtool.h | 4
include/linux/mii.h | 9
include/linux/pci_ids.h | 1
include/linux/phy.h | 360 +
include/net/ieee80211.h | 9
include/net/ieee80211_crypt.h | 86
net/Kconfig | 1
net/Makefile | 1
net/ieee80211/Kconfig | 69
net/ieee80211/Makefile | 11
net/ieee80211/ieee80211_crypt.c | 259
net/ieee80211/ieee80211_crypt_ccmp.c | 470 +
net/ieee80211/ieee80211_crypt_tkip.c | 708 ++
net/ieee80211/ieee80211_crypt_wep.c | 272
net/ieee80211/ieee80211_module.c | 273
net/ieee80211/ieee80211_rx.c | 1205 +++
net/ieee80211/ieee80211_tx.c | 447 +
net/ieee80211/ieee80211_wx.c | 471 +
129 files changed, 65323 insertions(+), 2247 deletions(-)
Adrian Bunk:
net/ieee80211/ieee80211_tx.c: swapped memset arguments
net/ieee80211/: make two functions static
fix IEEE80211_CRYPT_* selects
ieee80211: remove pci.h #include's
ieee80211: fix recursive ipw2200 dependencies
hostap update
include/net/ieee80211.h must #include <linux/wireless.h>
Al Viro:
ieee80211_module.c::store_debug_level() cleanup
zd1201 fixes
Andrew Morton:
ipw2100 old gcc fix
wireless-device-attr-fixes
wireless-device-attr-fixes-2
Andy Fleming:
This patch adds a PHY Abstraction Layer to the Linux Kernel, enabling
Brandon Enochs:
hostap update
Christoph Lameter:
A new 10GB Ethernet Driver by Chelsio Communications
Chuck Ebbert:
loopback: #ifdef the TSO code
loopback: optimize stats
loopback: whitespace cleanup
Dave Hansen:
hostap update
Francois Romieu:
sis190: resurrection
sis190: netconsole support.
sis190: ethtool/mii support.
sis190: add MAINTAINER entry.
sis190: merge some register related information from SiS driver.
sis190: remove hardcoded constants.
sis190: initialisation of MAC address.
sis190: the size of the Rx buffer is constrained
sis190: extract bits definition from SiS driver.
sis190: add endian annotations.
sis190: allow a non-hardcoded ID for the PHY.
sis190: dummy read is required by the status register
sis190: new PHY detection code.
sis190: PHY identifier for the K8S-MX motherboard.
sis190: compare the lpa to the local advertisement
Henrik Brix Andersen:
hostap update
James Ketrenos:
Add ipw2100 wireless driver.
Add ipw2200 wireless driver.
Jar:
hostap update
Jeff Garzik:
[netdrvr smc91x] use __iomem addresses in eeprom read/write changes
[NET] ieee80211 subsystem
[wireless] ipw2100: fix build after applying SuSE cleanups
wireless: fix ipw warning; add is_broadcast_ether_addr() to linux/etherdevice.h
ieee80211: trim trailing whitespace
[wireless ipw2200] trim trailing whitespace
[wireless hostap] trim trailing whitespace
Fix numerous minor problems with new phy subsystem.
phy subsystem: more cleanups
ieee80211: remove last uses of compat define WLAN_CAPABILITY_BSS
Jiri Benc:
ieee80211: cleanup
ieee80211: fix ipw 64bit compilation warnings
Jochen Friedrich:
tms380tr: move to DMA API
John W. Linville:
bonding: ALB -- allow slave to use bond's MAC address if its own MAC address conflicts
Jouni Malinen:
Add HostAP wireless driver.
hostap update
hostap update
hostap update
hostap update
hostap update
hostap update
hostap: Start using net/ieee80211.h
hostap: Replace crypto code with net/ieee80211 version
hostap: Fix skb->cb use for TX meta data
hostap: Remove experimental PCI bus master/DMA code
hostap: Use void *hw_priv instead of #ifdef in local data
hostap: Remove extra defines
hostap: Replace hostap_ieee80211_hdr with ieee80211_hdr
hostap: Use ieee80211 WLAN_FC_GET_{TYPE,STYPE}
ieee80211: Fix frame control pver mask
ieee80211: Capability field is called ESS, not BSS
hostap: Capability field is called ESS, not BSS
hostap: Replace WLAN_FC_ defines with ieee80211 ones
ladis@linux-mips.org:
smc91x: get/set eeprom
Malli Chilakala:
e100: Added cpu cycle saver microcode for 8086:[1209/1229]
e100: Driver version, white space, comments & other
ixgb: Set RXDCTL:PTHRESH/HTHRESH to zero
ixgb: Fix unnecessary link state messages
ixgb: Use netdev_priv() instead of netdev->priv
ixgb: Fix Broadcast/Multicast packets received statistics
ixgb: Fix data output by ethtool -d
ixgb: Ethtool cleanup patch from Stephen Hemminger
ixgb: Remove unused functions
ixgb: Redefined buffer_info-dma to be dma_addr_t instead of uint64
ixgb: Driver version, white space, comments
Manfred Spraul:
forcedeth: Jumbo Frame Support
forcedeth: Improve ethtool support
forcedeth: rewritten tx irq handling
forcedeth: 64-bit DMA support
forcedeth: Add set_mac_address support
forcedeth: write back original mac address during ifdown
Marcelo Feitoza Parisi:
Use time_before in hamradio drivers
Pavel Machek:
ipw2100: remove commented-out code
ipw2100: assume recent kernel
ipw2100: kill dead macros
ipw2100: small cleanups
Pavel Roskin:
hostap update
Peer Chen:
[netdrvr] add 'uli526x' driver (a tulip clone)
[netdrvr tulip] Remove ULi-specific code from generic tulip driver
Peter Hagervall:
orinoco: Sparse fixes
raghavendra.koushik@neterion.com:
S2io: Code cleanup
S2io: Hardware fixes
S2io: Software fixes
S2io: Removed memory leaks
S2io: Performance improvements
S2io: Support for runtime MTU change
S2io: Timer based slowpath handling
S2io: VLAN support
S2io: Support for Xframe II NIC
S2io: Support for bimodal interrupts
S2io: New link handling scheme for Xframe II
S2io: Miscellaneous fixes
S2io: Errors found during review
Richard Purdie:
hostap update
Scott Bardone:
Update Chelsio gige net driver.
Stephen Hemminger:
skge: stop bogus sensor messages
skge: fibre vs copper detection cleanup
skge: increase receive flush threshold default
skge: turn on link status LED
sky2: new experimental Marvell Yukon2 driver
Tobias Klauser:
drivers/net/wireless/ipw2100: Use the DMA_32BIT_MASK constant
drivers/net/wireless/ipw2200: Use the DMA_32BIT_MASK constant
Victor Fusco:
drivers/net/pci-skeleton.c: MODULE_PARM -> module_param
^ permalink raw reply
* Re: [resend][PATCH net-drivers-2.4 12/16] e1000: Modified e1000_clean:: exit poll
From: Jeff Garzik @ 2005-08-19 6:22 UTC (permalink / raw)
To: Malli Chilakala; +Cc: netdev
In-Reply-To: <Pine.LNX.4.44.0504282004300.30085-100000@isotope.jf.intel.com>
Malli Chilakala wrote:
> Modified e1000_clean:: exit poll if no Tx and work_done == 0
>
> Signed-off-by: Mallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com>
> Signed-off-by: Ganesh Venkatesan <ganesh.venkatesan@intel.com>
> Signed-off-by: John Ronciak <john.ronciak@intel.com>
Applied e1000 patches 1-12 to 2.4.x. Stopped at this patch.
Patch 13 was corrupted, so that's where the import stopped.
But nonetheless... 2.4.x netdev patches are flowing again!
Jeff
^ permalink raw reply
* Re: [PATCH 2.4.30] pcnet32: fix resource leak with loopback test
From: Jeff Garzik @ 2005-08-19 6:22 UTC (permalink / raw)
To: Don Fry; +Cc: tsbogend, netdev
In-Reply-To: <20050429214956.GA1074@us.ibm.com>
applied
^ permalink raw reply
* Re: Fw: [Bugme-new] [Bug 4223] New: sis900 kernel oop at boot
From: Jeff Garzik @ 2005-08-19 8:04 UTC (permalink / raw)
To: Herbert Xu; +Cc: Andrew Morton, netdev, mangus, webvenza
In-Reply-To: <20050305084537.GA12678@gondor.apana.org.au>
Herbert Xu wrote:
> Hi:
>
> Here is the version that moves the necessary code above register_netdev
> instead of using init. It's against netdev-2.6.
>
>
>>Feb 15 18:26:20 saturno kernel: Unable to handle kernel NULL pointer
>>dereference at virtual address 0000000e
>>Feb 15 18:26:20 saturno kernel: printing eip:
>>Feb 15 18:26:20 saturno kernel: e1113417
>>Feb 15 18:26:20 saturno kernel: *pde = 00000000
>>Feb 15 18:26:20 saturno kernel: Oops: 0000 [#1]
>>Feb 15 18:26:20 saturno kernel: PREEMPT
>>Feb 15 18:26:20 saturno kernel: Modules linked in: sis900 nvidia 8250_pci 8250
>>serial_core psmouse
>>Feb 15 18:26:20 saturno kernel: CPU: 0
>>Feb 15 18:26:20 saturno kernel: EIP: 0060:[<e1113417>] Tainted: P
>>VLI
>>Feb 15 18:26:20 saturno kernel: EFLAGS: 00010296 (2.6.10-M7)
>>Feb 15 18:26:20 saturno kernel: EIP is at sis900_check_mode+0x17/0xa0 [sis900]
>
>
> OK, this happened because we got preempted before sis900_mii_probe
> finished setting the sis_priv->mii. Theoretically this can happen
> with SMP as well but I suppose the number of SMP machines with sis900
> is fairly small.
>
> Anyway, the fix is to make sure that sis900_mii_probe is done before
> the device can be opened. This patch does it by moving the setup
> before register_netdevice.
>
> Since the netdev name is not available before register_netdev, I've
> changed the relevant printk's to use pci_name instead. Note that
> one of those printk's may be called after register_netdev as well.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Is this patch still needed?
Jeff
^ permalink raw reply
* Re: Fw: [Bugme-new] [Bug 4223] New: sis900 kernel oop at boot
From: Herbert Xu @ 2005-08-19 8:08 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Andrew Morton, netdev, mangus, webvenza
In-Reply-To: <430592A7.30101@pobox.com>
On Fri, Aug 19, 2005 at 04:04:55AM -0400, Jeff Garzik wrote:
> Herbert Xu wrote:
> >Hi:
> >
> >Here is the version that moves the necessary code above register_netdev
> >instead of using init. It's against netdev-2.6.
> >
> >
> >>Feb 15 18:26:20 saturno kernel: Unable to handle kernel NULL pointer
> >>dereference at virtual address 0000000e
> >>Feb 15 18:26:20 saturno kernel: printing eip:
> >>Feb 15 18:26:20 saturno kernel: e1113417
> >>Feb 15 18:26:20 saturno kernel: *pde = 00000000
> >>Feb 15 18:26:20 saturno kernel: Oops: 0000 [#1]
> >>Feb 15 18:26:20 saturno kernel: PREEMPT
> >>Feb 15 18:26:20 saturno kernel: Modules linked in: sis900 nvidia 8250_pci
> >>8250
> >>serial_core psmouse
> >>Feb 15 18:26:20 saturno kernel: CPU: 0
> >>Feb 15 18:26:20 saturno kernel: EIP: 0060:[<e1113417>] Tainted: P
> >>VLI
> >>Feb 15 18:26:20 saturno kernel: EFLAGS: 00010296 (2.6.10-M7)
> >>Feb 15 18:26:20 saturno kernel: EIP is at sis900_check_mode+0x17/0xa0
> >>[sis900]
> >
> >
> >OK, this happened because we got preempted before sis900_mii_probe
> >finished setting the sis_priv->mii. Theoretically this can happen
> >with SMP as well but I suppose the number of SMP machines with sis900
> >is fairly small.
> >
> >Anyway, the fix is to make sure that sis900_mii_probe is done before
> >the device can be opened. This patch does it by moving the setup
> >before register_netdevice.
> >
> >Since the netdev name is not available before register_netdev, I've
> >changed the relevant printk's to use pci_name instead. Note that
> >one of those printk's may be called after register_netdev as well.
> >
> >Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> Is this patch still needed?
Nope, because you applied this months ago :)
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* 2.6.13-rc6-mm1: drivers/net/s2io.c: compile error with gcc 4.0
From: Adrian Bunk @ 2005-08-19 15:02 UTC (permalink / raw)
To: Andrew Morton, Raghavendra Koushik, jgarzik; +Cc: linux-kernel, netdev
In-Reply-To: <20050819043331.7bc1f9a9.akpm@osdl.org>
On Fri, Aug 19, 2005 at 04:33:31AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.13-rc5-mm1:
>...
> -git-netdev-chelsio.patch
> -git-netdev-e100.patch
> -git-netdev-sis190.patch
> -git-netdev-smc91x-eeprom.patch
> -git-netdev-ieee80211-wifi.patch
> -git-netdev-upstream.patch
> +git-netdev-all.patch
>
> And a consolidated netdev tree
>...
This patch causes the following compile error with gcc 4.0:
<-- snip -->
...
CC drivers/net/s2io.o
In file included from drivers/net/s2io.c:65:
drivers/net/s2io.h: In function 'readq':
drivers/net/s2io.h:765: error: invalid lvalue in assignment
drivers/net/s2io.h:766: error: invalid lvalue in assignment
drivers/net/s2io.c: In function 'init_shared_mem':
drivers/net/s2io.c:541: warning: cast from pointer to integer of different size
drivers/net/s2io.c:544: warning: cast to pointer from integer of different size
drivers/net/s2io.c:550: warning: cast from pointer to integer of different size
drivers/net/s2io.c:553: warning: cast to pointer from integer of different size
make[2]: *** [drivers/net/s2io.o] Error 1
<-- snip -->
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [E1000-devel] Page Allocation Failure with e1000 using jumbo frame
From: Jesse Brandeburg @ 2005-08-19 16:51 UTC (permalink / raw)
To: Ming Zhang; +Cc: E1000, iet-dev, netdev
In-Reply-To: <1124326404.5546.215.camel@localhost.localdomain>
included netdev...
On Wed, 17 Aug 2005, Ming Zhang wrote:
>
> Hi folks
>
> We ran into this problem when running jumbo frame with iscsi over e1000.
> the MTU1500 is fine while jumbo frame can stably reproduce this error.
>
> when meet this error, as reported in iet list, the box still has >600MB
> ram free. also the slab is not heavily used.
>
> any idea on this?
So, what we do know is that your kernel memory manager is (for whatever
unknown reason) having trouble finding contiguous 2^3 pages (32kB) chunks
of memory. This occurs because we need to give our hardware 16kB
contiguous (currently, we actually have a patch for this in internal
testing) which means that when we do dev_alloc_skb, it allocates 16kB + 16
bytes reserve, plus 2 bytes NET_IP_ALIGN, which takes us into the 32kB
slab (power of two roundup)
I guess we need to approach the memory manager guys and ask them why the
current kernels are having so much trouble getting contiguous memory.
Also, recently thanks to David Miller's discussions on socket charge, we
understand that we're getting hit hard by using such a big buffer.
Netdev any ideas?
Jesse
> attached partial email on iet list.
>
> -----------------------------------
> In either case it only seems to be an issue with jumbo frames. I'm
> also reasonably sure the box isn't actually running out of memory -
> I'm running the same test right this minute on the actual disk array
> with MTU=1500 on both ends and my target box has 642988k free.
> Running it again with MTU=9000 generates the error right away and I
> see 642696k free during this test run.
>
> >> generate the Page Allocation Failure messages after running for a few
> >> minutes on a 'real' device and almost instantly using 'nullio'.
> >>
> > and this happen instantly? can u check the RAM usage? also can u check
> > the slabtop? maybe here are memory leak?
>
> I'm not familiar enough with slabtop to interpret its output but
> here's the summary section:
>
> Active / Total Objects (% used) : 250586 / 281397 (89.1%)
> Active / Total Slabs (% used) : 6301 / 6310 (99.9%)
> Active / Total Caches (% used) : 83 / 124 (66.9%)
> Active / Total Size (% used) : 30053.05K / 33686.83K (89.2%)
> Minimum / Average / Maximum Object : 0.01K / 0.12K / 128.00K
>
> Bryn
>
>
>
> the detail msg.
>
> -------- Forwarded Message --------
> > From: Bryn Hughes <linux@nashira.ca>
> > To: iet-dev <iscsitarget-devel@lists.sourceforge.net>
> > Subject: [Iscsitarget-devel] Page Allocation Failure
> > Date: Tue, 16 Aug 2005 14:49:29 -0700
> > Today I started doing testing with a larger volume and jumbo frames.
> > I'm running bonnie with a 8G test set on a 100G volume and since I
> > enabled jumbo frames I've been seeing this in dmesg over and over
> > again:
> >
> >
> > istd1: page allocation failure. order:3, mode:0x20
> > [<c0148b33>] __alloc_pages+0x343/0x3c0
> > [<c011cd58>] scheduler_tick+0x198/0x400
> > [<c014b602>] kmem_getpages+0x32/0xa0
> > [<c014c35e>] cache_grow+0xbe/0x180
> > [<c014c58d>] cache_alloc_refill+0x16d/0x240
> > [<c014c95a>] __kmalloc+0x6a/0x70
> > [<c02ba3e0>] alloc_skb+0x40/0xf0
> > [<f924471e>] e1000_alloc_rx_buffers+0x6e/0x3a0 [e1000]
> > [<f9243ee8>] e1000_clean_rx_irq+0x1e8/0x4d0 [e1000]
> > [<c02df856>] ip_queue_xmit+0x306/0x540
> > [<f92436da>] e1000_clean+0x9a/0x150 [e1000]
> > [<c02c0cf9>] net_rx_action+0xd9/0x1b0
> > [<c01267d2>] __do_softirq+0x82/0x100
> > [<c0126885>] do_softirq+0x35/0x40
> > [<c01066db>] do_IRQ+0x3b/0x70
> > [<c0104b86>] common_interrupt+0x1a/0x20
> > [<c0205a0c>] __copy_user_intel+0x2c/0xb0
> > [<c0205b9a>] __copy_to_user_ll+0x5a/0x80
> > [<c0205c76>] copy_to_user+0x36/0x60
> > [<c02bc689>] memcpy_toiovec+0x29/0x50
> > [<c02bcc5b>] skb_copy_datagram_iovec+0x4b/0x210
> > [<c02f7690>] tcp_v4_do_rcv+0xf0/0x110
> > [<c02b93e4>] __release_sock+0x54/0x70
> > [<c02e62c3>] tcp_recvmsg+0x4b3/0x750
> > [<c0148601>] buffered_rmqueue+0xf1/0x210
> > [<c01488b5>] __alloc_pages+0xc5/0x3c0
> > [<c02b9d38>] sock_common_recvmsg+0x48/0x70
> > [<c02b61e1>] sock_recvmsg+0x131/0x170
> > [<c02f0566>] tcp_transmit_skb+0x426/0x760
> > [<c012a2e7>] __mod_timer+0xf7/0x130
> > [<c02b993c>] sk_reset_timer+0xc/0x20
> > [<c02f12e6>] tcp_write_xmit+0x176/0x2c0
> > [<c0136120>] autoremove_wake_function+0x0/0x50
> > [<c03055a5>] inet_ioctl+0x45/0xf0
> > [<f9379d00>] is_data_available+0x30/0x50 [iscsi_trgt]
> > [<f9379e33>] do_recv+0xc3/0x1c0 [iscsi_trgt]
> > [<c030535a>] inet_sendmsg+0x4a/0x70
> > [<f9243ee8>] e1000_clean_rx_irq+0x1e8/0x4d0 [e1000]
> > [<c02c0cf9>] net_rx_action+0xd9/0x1b0
> > [<c0136120>] autoremove_wake_function+0x0/0x50
> > [<c01267d2>] __do_softirq+0x82/0x100
> > [<c014820a>] rmqueue_bulk+0x7a/0x90
> > [<c0148085>] prep_new_page+0x55/0x60
> > [<c0148601>] buffered_rmqueue+0xf1/0x210
> > [<c0162b38>] do_readv_writev+0x1e8/0x250
> > [<c01488b5>] __alloc_pages+0xc5/0x3c0
> > [<f93777c8>] cmnd_recv_pdu+0xb8/0x210 [iscsi_trgt]
> > [<f937607c>] tio_add_pages+0x7c/0xe0 [iscsi_trgt]
> > [<f9378375>] scsi_cmnd_start+0x3c5/0x490 [iscsi_trgt]
> > [<f937754f>] cmnd_insert_hash+0xff/0x140 [iscsi_trgt]
> > [<c02b9d86>] sock_common_setsockopt+0x26/0x40
> > [<c011b470>] try_to_wake_up+0x2b0/0x300
> > [<f937a38f>] recv+0x36f/0x420 [iscsi_trgt]
> > [<f937adb3>] process_io+0x23/0xa0 [iscsi_trgt]
> > [<f937b109>] istd+0x99/0x100 [iscsi_trgt]
> > [<f937b070>] istd+0x0/0x100 [iscsi_trgt]
> > [<c0135c65>] kthread+0xa5/0xf0
> > [<c0135bc0>] kthread+0x0/0xf0
> > [<c0102455>] kernel_thread_helper+0x5/0x10
> >
> >
> > Any idea what would be causing this?
> >
> >
> > SLES9/kernel 2.6.12.3
> > IET 0.4.11
> > e1000 6.1.16
> >
>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> E1000-devel mailing list
> E1000-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/e1000-devel
>
>
>
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply
* Re: Page Allocation Failure with e1000 using jumbo frame
From: Ming Zhang @ 2005-08-19 17:01 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: E1000, iet-dev, netdev
In-Reply-To: <Pine.WNT.4.63.0508190940210.3796@jbrandeb-desk.amr.corp.intel.com>
This is first reported on IET list and then i redo the test with vanilla
2.6.12.4 kernel and everything went fine.
so i suspect if there are special case caused by vendor kernel.
is this 32KB ATOMIC ram allocation request only available in jumbo frame
case? since the regular MTU case goes fine.
ming
On Fri, 2005-08-19 at 09:51 -0700, Jesse Brandeburg wrote:
> included netdev...
>
>
> On Wed, 17 Aug 2005, Ming Zhang wrote:
>
> >
> > Hi folks
> >
> > We ran into this problem when running jumbo frame with iscsi over e1000.
> > the MTU1500 is fine while jumbo frame can stably reproduce this error.
> >
> > when meet this error, as reported in iet list, the box still has >600MB
> > ram free. also the slab is not heavily used.
> >
> > any idea on this?
>
>
> So, what we do know is that your kernel memory manager is (for whatever
> unknown reason) having trouble finding contiguous 2^3 pages (32kB) chunks
> of memory. This occurs because we need to give our hardware 16kB
> contiguous (currently, we actually have a patch for this in internal
> testing) which means that when we do dev_alloc_skb, it allocates 16kB + 16
> bytes reserve, plus 2 bytes NET_IP_ALIGN, which takes us into the 32kB
> slab (power of two roundup)
>
> I guess we need to approach the memory manager guys and ask them why the
> current kernels are having so much trouble getting contiguous memory.
> Also, recently thanks to David Miller's discussions on socket charge, we
> understand that we're getting hit hard by using such a big buffer.
>
> Netdev any ideas?
>
> Jesse
>
>
> > attached partial email on iet list.
> >
> > -----------------------------------
> > In either case it only seems to be an issue with jumbo frames. I'm
> > also reasonably sure the box isn't actually running out of memory -
> > I'm running the same test right this minute on the actual disk array
> > with MTU=1500 on both ends and my target box has 642988k free.
> > Running it again with MTU=9000 generates the error right away and I
> > see 642696k free during this test run.
> >
> > >> generate the Page Allocation Failure messages after running for a few
> > >> minutes on a 'real' device and almost instantly using 'nullio'.
> > >>
> > > and this happen instantly? can u check the RAM usage? also can u check
> > > the slabtop? maybe here are memory leak?
> >
> > I'm not familiar enough with slabtop to interpret its output but
> > here's the summary section:
> >
> > Active / Total Objects (% used) : 250586 / 281397 (89.1%)
> > Active / Total Slabs (% used) : 6301 / 6310 (99.9%)
> > Active / Total Caches (% used) : 83 / 124 (66.9%)
> > Active / Total Size (% used) : 30053.05K / 33686.83K (89.2%)
> > Minimum / Average / Maximum Object : 0.01K / 0.12K / 128.00K
> >
> > Bryn
> >
> >
> >
> > the detail msg.
> >
> > -------- Forwarded Message --------
> > > From: Bryn Hughes <linux@nashira.ca>
> > > To: iet-dev <iscsitarget-devel@lists.sourceforge.net>
> > > Subject: [Iscsitarget-devel] Page Allocation Failure
> > > Date: Tue, 16 Aug 2005 14:49:29 -0700
> > > Today I started doing testing with a larger volume and jumbo frames.
> > > I'm running bonnie with a 8G test set on a 100G volume and since I
> > > enabled jumbo frames I've been seeing this in dmesg over and over
> > > again:
> > >
> > >
> > > istd1: page allocation failure. order:3, mode:0x20
> > > [<c0148b33>] __alloc_pages+0x343/0x3c0
> > > [<c011cd58>] scheduler_tick+0x198/0x400
> > > [<c014b602>] kmem_getpages+0x32/0xa0
> > > [<c014c35e>] cache_grow+0xbe/0x180
> > > [<c014c58d>] cache_alloc_refill+0x16d/0x240
> > > [<c014c95a>] __kmalloc+0x6a/0x70
> > > [<c02ba3e0>] alloc_skb+0x40/0xf0
> > > [<f924471e>] e1000_alloc_rx_buffers+0x6e/0x3a0 [e1000]
> > > [<f9243ee8>] e1000_clean_rx_irq+0x1e8/0x4d0 [e1000]
> > > [<c02df856>] ip_queue_xmit+0x306/0x540
> > > [<f92436da>] e1000_clean+0x9a/0x150 [e1000]
> > > [<c02c0cf9>] net_rx_action+0xd9/0x1b0
> > > [<c01267d2>] __do_softirq+0x82/0x100
> > > [<c0126885>] do_softirq+0x35/0x40
> > > [<c01066db>] do_IRQ+0x3b/0x70
> > > [<c0104b86>] common_interrupt+0x1a/0x20
> > > [<c0205a0c>] __copy_user_intel+0x2c/0xb0
> > > [<c0205b9a>] __copy_to_user_ll+0x5a/0x80
> > > [<c0205c76>] copy_to_user+0x36/0x60
> > > [<c02bc689>] memcpy_toiovec+0x29/0x50
> > > [<c02bcc5b>] skb_copy_datagram_iovec+0x4b/0x210
> > > [<c02f7690>] tcp_v4_do_rcv+0xf0/0x110
> > > [<c02b93e4>] __release_sock+0x54/0x70
> > > [<c02e62c3>] tcp_recvmsg+0x4b3/0x750
> > > [<c0148601>] buffered_rmqueue+0xf1/0x210
> > > [<c01488b5>] __alloc_pages+0xc5/0x3c0
> > > [<c02b9d38>] sock_common_recvmsg+0x48/0x70
> > > [<c02b61e1>] sock_recvmsg+0x131/0x170
> > > [<c02f0566>] tcp_transmit_skb+0x426/0x760
> > > [<c012a2e7>] __mod_timer+0xf7/0x130
> > > [<c02b993c>] sk_reset_timer+0xc/0x20
> > > [<c02f12e6>] tcp_write_xmit+0x176/0x2c0
> > > [<c0136120>] autoremove_wake_function+0x0/0x50
> > > [<c03055a5>] inet_ioctl+0x45/0xf0
> > > [<f9379d00>] is_data_available+0x30/0x50 [iscsi_trgt]
> > > [<f9379e33>] do_recv+0xc3/0x1c0 [iscsi_trgt]
> > > [<c030535a>] inet_sendmsg+0x4a/0x70
> > > [<f9243ee8>] e1000_clean_rx_irq+0x1e8/0x4d0 [e1000]
> > > [<c02c0cf9>] net_rx_action+0xd9/0x1b0
> > > [<c0136120>] autoremove_wake_function+0x0/0x50
> > > [<c01267d2>] __do_softirq+0x82/0x100
> > > [<c014820a>] rmqueue_bulk+0x7a/0x90
> > > [<c0148085>] prep_new_page+0x55/0x60
> > > [<c0148601>] buffered_rmqueue+0xf1/0x210
> > > [<c0162b38>] do_readv_writev+0x1e8/0x250
> > > [<c01488b5>] __alloc_pages+0xc5/0x3c0
> > > [<f93777c8>] cmnd_recv_pdu+0xb8/0x210 [iscsi_trgt]
> > > [<f937607c>] tio_add_pages+0x7c/0xe0 [iscsi_trgt]
> > > [<f9378375>] scsi_cmnd_start+0x3c5/0x490 [iscsi_trgt]
> > > [<f937754f>] cmnd_insert_hash+0xff/0x140 [iscsi_trgt]
> > > [<c02b9d86>] sock_common_setsockopt+0x26/0x40
> > > [<c011b470>] try_to_wake_up+0x2b0/0x300
> > > [<f937a38f>] recv+0x36f/0x420 [iscsi_trgt]
> > > [<f937adb3>] process_io+0x23/0xa0 [iscsi_trgt]
> > > [<f937b109>] istd+0x99/0x100 [iscsi_trgt]
> > > [<f937b070>] istd+0x0/0x100 [iscsi_trgt]
> > > [<c0135c65>] kthread+0xa5/0xf0
> > > [<c0135bc0>] kthread+0x0/0xf0
> > > [<c0102455>] kernel_thread_helper+0x5/0x10
> > >
> > >
> > > Any idea what would be causing this?
> > >
> > >
> > > SLES9/kernel 2.6.12.3
> > > IET 0.4.11
> > > e1000 6.1.16
> > >
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> > _______________________________________________
> > E1000-devel mailing list
> > E1000-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/e1000-devel
> >
> >
> >
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply
* Re: Page Allocation Failure with e1000 using jumbo frame
From: Andi Kleen @ 2005-08-19 17:02 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: Ming Zhang, E1000, iet-dev, netdev
In-Reply-To: <Pine.WNT.4.63.0508190940210.3796@jbrandeb-desk.amr.corp.intel.com>
> I guess we need to approach the memory manager guys and ask them why the
> current kernels are having so much trouble getting contiguous memory.
Because memory fragments.
The only long term reliable way is to not allocate buffers > PAGE_SIZE.
The stack supports paged skbs for that.
-Andi
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply
* Re: Page Allocation Failure with e1000 using jumbo frame
From: Nivedita Singhvi @ 2005-08-19 17:03 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: Ming Zhang, E1000, iet-dev, netdev
In-Reply-To: <Pine.WNT.4.63.0508190940210.3796@jbrandeb-desk.amr.corp.intel.com>
Jesse Brandeburg wrote:
> included netdev...
>
>
> On Wed, 17 Aug 2005, Ming Zhang wrote:
>
>>
>> Hi folks
>>
>> We ran into this problem when running jumbo frame with iscsi over e1000.
>> the MTU1500 is fine while jumbo frame can stably reproduce this error.
>>
>> when meet this error, as reported in iet list, the box still has >600MB
>> ram free. also the slab is not heavily used.
>>
>> any idea on this?
>
>
>
> So, what we do know is that your kernel memory manager is (for whatever
> unknown reason) having trouble finding contiguous 2^3 pages (32kB)
> chunks of memory. This occurs because we need to give our hardware 16kB
> contiguous (currently, we actually have a patch for this in internal
> testing) which means that when we do dev_alloc_skb, it allocates 16kB +
> 16 bytes reserve, plus 2 bytes NET_IP_ALIGN, which takes us into the
> 32kB slab (power of two roundup)
>
> I guess we need to approach the memory manager guys and ask them why the
> current kernels are having so much trouble getting contiguous memory.
> Also, recently thanks to David Miller's discussions on socket charge, we
> understand that we're getting hit hard by using such a big buffer.
>
> Netdev any ideas?
Interesting you should mention this, I just mentioned it
in the context of another thread like 3 seconds ago.
I've talked to Martin Bligh in the past about having the
VM do something sane about these to improve the situation - I'll
go kick, er, ping him again...
The current status is "try not to do that" (large contig allocs).
If anyone has any good ideas, speak up :)
thanks,
Nivedita
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ 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