* [BUG somewhere] 2.6.0-test8 irq.c, IRQ_INPROGRESS ? [not found] <Pine.LNX.4.10.10009211329001.1627-100000@penguin.transmeta.com> @ 2003-10-23 3:18 ` M.H.VanLeeuwen 2003-10-23 3:25 ` Linus Torvalds 2003-10-23 4:30 ` [PATCH] 2.6.0-test8 ISAPNP ne.c initialization M.H.VanLeeuwen 1 sibling, 1 reply; 9+ messages in thread From: M.H.VanLeeuwen @ 2003-10-23 3:18 UTC (permalink / raw) To: torvalds; +Cc: linux-kernel Hi, I'm seeing an NMI Watchdog detected LOCKUP go away when I revert this patch previously added into test8. Any help appreciated. Martin diff -Nru a/arch/i386/kernel/irq.c b/arch/i386/kernel/irq.c --- a/arch/i386/kernel/irq.c Fri Oct 17 14:43:50 2003 +++ b/arch/i386/kernel/irq.c Fri Oct 17 14:43:50 2003 @@ -378,7 +380,7 @@ spin_lock_irqsave(&desc->lock, flags); switch (desc->depth) { case 1: { - unsigned int status = desc->status & ~IRQ_DISABLED; + unsigned int status = desc->status & ~(IRQ_DISABLED | IRQ_INPROGRESS); desc->status = status; if ((status & (IRQ_PENDING | IRQ_REPLAY)) == IRQ_PENDING) { desc->status = status | IRQ_REPLAY; EIP is at .text.lock.8390+0x39/0x63 which is in ei_start_xmit() in 8390.c at the first spin_lock_irqsave(). I hand copied the data from the console, what else is interesting/necessary? First notices after booting into test8 and the system went silent when starting X, since /home is NFS mounted go generate network and IDE activity. Reproducible by doing all 3 of these (any 2 and the system stays alive, longer than I want to wait) 1. ping flood A->B 2. ping flood B->A 3. find and grep for garbage from IDE on B's /dev/md/X filesystem System B is SMP dual Celeron 466Mhz. Eth interface: isapnp: Scanning for PnP cards... isapnp: Card 'SMC EZ Card (1660)' isapnp: 1 Plug & Play card detected total pnp: Device 00:01.00 activated. ne.c: ISAPnP reports Generic PNP at i/o 0x220, irq 5. ne.c:v1.10 9/23/94 Donald Becker (becker@scyld.com) Last modified Nov 1, 2000 by Paul Gortmaker NE*000 ethercard probe at 0x220: 00 e0 29 3c 1f 11 eth0: NE2000 found at 0x220, using IRQ 5. IDE interface: PIIX4: IDE controller at PCI slot 0000:00:07.1 PIIX4: chipset revision 1 PIIX4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio HPT366: onboard version of chipset, pin1=1 pin2=2 HPT366: IDE controller at PCI slot 0000:00:13.0 HPT366: chipset revision 1 HPT366: 100% native mode on irq 18 ide2: BM-DMA at 0xdc00-0xdc07, BIOS settings: hde:pio, hdf:pio ide3: BM-DMA at 0xe800-0xe807, BIOS settings: hdg:pio, hdh:pio hde: WDC WD400BB-32AUA1, ATA DISK drive ide2 at 0xd400-0xd407,0xd802 on irq 18 hdg: ST340810A, ATA DISK drive ide3 at 0xe000-0xe007,0xe402 on irq 18 hde: max request size: 128KiB hde: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(66) /dev/ide/host2/bus0/target0/lun0: p1 p2 p3 p4 < p5 p6 p7 p8 p9 > hdg: max request size: 128KiB hdg: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(66) /dev/ide/host3/bus0/target0/lun0: p1 p2 p3 p4 < p5 p6 p7 p8 p9 > /proc/interrupts (currently running 2.6.0-test8) CPU0 CPU1 0: 52531411 84 IO-APIC-edge timer 1: 10288 1 IO-APIC-edge i8042 2: 0 0 XT-PIC cascade 5: 1908410 66015823 IO-APIC-edge NE2000 8: 1 0 IO-APIC-edge rtc 12: 56098 1 IO-APIC-edge i8042 16: 3663003 0 IO-APIC-level r128@PCI:1:0:0 18: 162982 300769 IO-APIC-level ide2, ide3 NMI: 52531430 52531316 LOC: 52544445 52544450 ERR: 42 MIS: 999 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [BUG somewhere] 2.6.0-test8 irq.c, IRQ_INPROGRESS ? 2003-10-23 3:18 ` [BUG somewhere] 2.6.0-test8 irq.c, IRQ_INPROGRESS ? M.H.VanLeeuwen @ 2003-10-23 3:25 ` Linus Torvalds 2003-10-23 3:29 ` Linus Torvalds ` (2 more replies) 0 siblings, 3 replies; 9+ messages in thread From: Linus Torvalds @ 2003-10-23 3:25 UTC (permalink / raw) To: M.H.VanLeeuwen; +Cc: Kernel Mailing List, marcelo.tosatti On Wed, 22 Oct 2003, M.H.VanLeeuwen wrote: > > I'm seeing an NMI Watchdog detected LOCKUP go away when I revert this patch > previously added into test8. Yes, the thing is buggy. It's not correct for "disable_irq_nosync()" users, and reverting it is the right thing to do. Thanks for the report. Marcelo, please note if you played with this in 2.4.x.. Linus ------ > diff -Nru a/arch/i386/kernel/irq.c b/arch/i386/kernel/irq.c > --- a/arch/i386/kernel/irq.c Fri Oct 17 14:43:50 2003 > +++ b/arch/i386/kernel/irq.c Fri Oct 17 14:43:50 2003 > @@ -378,7 +380,7 @@ > spin_lock_irqsave(&desc->lock, flags); > switch (desc->depth) { > case 1: { > - unsigned int status = desc->status & ~IRQ_DISABLED; > + unsigned int status = desc->status & ~(IRQ_DISABLED | IRQ_INPROGRESS); > desc->status = status; > if ((status & (IRQ_PENDING | IRQ_REPLAY)) == IRQ_PENDING) { > desc->status = status | IRQ_REPLAY; > > EIP is at .text.lock.8390+0x39/0x63 which is in ei_start_xmit() in 8390.c > at the first spin_lock_irqsave(). > > I hand copied the data from the console, what else is interesting/necessary? > > First notices after booting into test8 and the system went silent when starting X, > since /home is NFS mounted go generate network and IDE activity. > > Reproducible by doing all 3 of these (any 2 and the system stays alive, longer > than I want to wait) > > 1. ping flood A->B > 2. ping flood B->A > 3. find and grep for garbage from IDE on B's /dev/md/X filesystem > > System B is SMP dual Celeron 466Mhz. > > Eth interface: > > isapnp: Scanning for PnP cards... > isapnp: Card 'SMC EZ Card (1660)' > isapnp: 1 Plug & Play card detected total > pnp: Device 00:01.00 activated. > ne.c: ISAPnP reports Generic PNP at i/o 0x220, irq 5. > ne.c:v1.10 9/23/94 Donald Becker (becker@scyld.com) > Last modified Nov 1, 2000 by Paul Gortmaker > NE*000 ethercard probe at 0x220: 00 e0 29 3c 1f 11 > eth0: NE2000 found at 0x220, using IRQ 5. > > > IDE interface: > > PIIX4: IDE controller at PCI slot 0000:00:07.1 > PIIX4: chipset revision 1 > PIIX4: not 100% native mode: will probe irqs later > ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:pio > ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio > HPT366: onboard version of chipset, pin1=1 pin2=2 > HPT366: IDE controller at PCI slot 0000:00:13.0 > HPT366: chipset revision 1 > HPT366: 100% native mode on irq 18 > ide2: BM-DMA at 0xdc00-0xdc07, BIOS settings: hde:pio, hdf:pio > ide3: BM-DMA at 0xe800-0xe807, BIOS settings: hdg:pio, hdh:pio > hde: WDC WD400BB-32AUA1, ATA DISK drive > ide2 at 0xd400-0xd407,0xd802 on irq 18 > hdg: ST340810A, ATA DISK drive > ide3 at 0xe000-0xe007,0xe402 on irq 18 > hde: max request size: 128KiB > hde: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(66) > /dev/ide/host2/bus0/target0/lun0: p1 p2 p3 p4 < p5 p6 p7 p8 p9 > > hdg: max request size: 128KiB > hdg: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(66) > /dev/ide/host3/bus0/target0/lun0: p1 p2 p3 p4 < p5 p6 p7 p8 p9 > > > /proc/interrupts (currently running 2.6.0-test8) > > CPU0 CPU1 > 0: 52531411 84 IO-APIC-edge timer > 1: 10288 1 IO-APIC-edge i8042 > 2: 0 0 XT-PIC cascade > 5: 1908410 66015823 IO-APIC-edge NE2000 > 8: 1 0 IO-APIC-edge rtc > 12: 56098 1 IO-APIC-edge i8042 > 16: 3663003 0 IO-APIC-level r128@PCI:1:0:0 > 18: 162982 300769 IO-APIC-level ide2, ide3 > NMI: 52531430 52531316 > LOC: 52544445 52544450 > ERR: 42 > MIS: 999 > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [BUG somewhere] 2.6.0-test8 irq.c, IRQ_INPROGRESS ? 2003-10-23 3:25 ` Linus Torvalds @ 2003-10-23 3:29 ` Linus Torvalds 2003-10-23 11:24 ` Marcelo Tosatti 2003-10-23 11:30 ` Mikael Pettersson 2 siblings, 0 replies; 9+ messages in thread From: Linus Torvalds @ 2003-10-23 3:29 UTC (permalink / raw) To: M.H.VanLeeuwen; +Cc: Kernel Mailing List, marcelo.tosatti On Wed, 22 Oct 2003, Linus Torvalds wrote: > > It's not correct for "disable_irq_nosync()" users, and reverting it is the > right thing to do. Thanks for the report. [ Btw, the 8390-based network drivers are likely the only thing to actually be able to trigger it, so thanks again for the good bug report. ] Linus ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [BUG somewhere] 2.6.0-test8 irq.c, IRQ_INPROGRESS ? 2003-10-23 3:25 ` Linus Torvalds 2003-10-23 3:29 ` Linus Torvalds @ 2003-10-23 11:24 ` Marcelo Tosatti 2003-10-23 11:30 ` Mikael Pettersson 2 siblings, 0 replies; 9+ messages in thread From: Marcelo Tosatti @ 2003-10-23 11:24 UTC (permalink / raw) To: Linus Torvalds; +Cc: M.H.VanLeeuwen, Kernel Mailing List, marcelo.tosatti, viro On Wed, 22 Oct 2003, Linus Torvalds wrote: > > On Wed, 22 Oct 2003, M.H.VanLeeuwen wrote: > > > > I'm seeing an NMI Watchdog detected LOCKUP go away when I revert this patch > > previously added into test8. > > Yes, the thing is buggy. > > It's not correct for "disable_irq_nosync()" users, and reverting it is the > right thing to do. Thanks for the report. > > Marcelo, please note if you played with this in 2.4.x.. 2.4.23-pre8 does clear IRQ_INPROGRESS in setup_IRQ() (it fixes the IDE setup hang viro mentioned). disable_irq_nosync() doesnt care about IRQ_INPROGRESS. I cant figure out why does the change breaks... ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [BUG somewhere] 2.6.0-test8 irq.c, IRQ_INPROGRESS ? 2003-10-23 3:25 ` Linus Torvalds 2003-10-23 3:29 ` Linus Torvalds 2003-10-23 11:24 ` Marcelo Tosatti @ 2003-10-23 11:30 ` Mikael Pettersson 2003-10-23 14:31 ` Linus Torvalds 2 siblings, 1 reply; 9+ messages in thread From: Mikael Pettersson @ 2003-10-23 11:30 UTC (permalink / raw) To: Linus Torvalds; +Cc: M.H.VanLeeuwen, Kernel Mailing List, marcelo.tosatti Linus Torvalds writes: > On Wed, 22 Oct 2003, M.H.VanLeeuwen wrote: > > > > I'm seeing an NMI Watchdog detected LOCKUP go away when I revert this patch > > previously added into test8. > > Yes, the thing is buggy. > > It's not correct for "disable_irq_nosync()" users, and reverting it is the > right thing to do. Thanks for the report. > > Marcelo, please note if you played with this in 2.4.x.. > > Linus > > ------ > > diff -Nru a/arch/i386/kernel/irq.c b/arch/i386/kernel/irq.c > > --- a/arch/i386/kernel/irq.c Fri Oct 17 14:43:50 2003 > > +++ b/arch/i386/kernel/irq.c Fri Oct 17 14:43:50 2003 > > @@ -378,7 +380,7 @@ > > spin_lock_irqsave(&desc->lock, flags); > > switch (desc->depth) { > > case 1: { > > - unsigned int status = desc->status & ~IRQ_DISABLED; > > + unsigned int status = desc->status & ~(IRQ_DISABLED | IRQ_INPROGRESS); It seems 2.4.23-pre8 included something like this apparently broken change (see diff from -pre7 below). Should it be reverted? --- linux-2.4.23-pre7/arch/i386/kernel/irq.c 2003-10-23 13:17:43.700067608 +0200 +++ linux-2.4.23-pre8/arch/i386/kernel/irq.c 2003-10-23 13:17:10.071202512 +0200 @@ -1036,7 +1036,7 @@ if (!shared) { desc->depth = 0; - desc->status &= ~(IRQ_DISABLED | IRQ_AUTODETECT | IRQ_WAITING); + desc->status &= ~(IRQ_DISABLED | IRQ_AUTODETECT | IRQ_WAITING | IRQ_INPROGRESS); desc->handler->startup(irq); } spin_unlock_irqrestore(&desc->lock,flags); ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [BUG somewhere] 2.6.0-test8 irq.c, IRQ_INPROGRESS ? 2003-10-23 11:30 ` Mikael Pettersson @ 2003-10-23 14:31 ` Linus Torvalds 0 siblings, 0 replies; 9+ messages in thread From: Linus Torvalds @ 2003-10-23 14:31 UTC (permalink / raw) To: Mikael Pettersson; +Cc: M.H.VanLeeuwen, Kernel Mailing List, marcelo.tosatti On Thu, 23 Oct 2003, Mikael Pettersson wrote: > > It seems 2.4.23-pre8 included something like this apparently broken > change (see diff from -pre7 below). Should it be reverted? No, that one is correct. IRQ_INPROGRESS should indeed be cleared when the first handler is installed. It's only clearing it at enable_irq() that is wrong. Also, the "disable_irq()" function _should_ look something like this: void disable_irq(unsigned int irq) { irq_desc_t *desc = irq_desc + irq; disable_irq_nosync(irq); if (desc->action) synchronize_irq(irq); } ie it should only do synchronize_irq() if a handler exists. That fixes a potential problem with drivers doing multiple disable_irq()/enable_irq() while no handler has been assigned yet. Linus ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] 2.6.0-test8 ISAPNP ne.c initialization [not found] <Pine.LNX.4.10.10009211329001.1627-100000@penguin.transmeta.com> 2003-10-23 3:18 ` [BUG somewhere] 2.6.0-test8 irq.c, IRQ_INPROGRESS ? M.H.VanLeeuwen @ 2003-10-23 4:30 ` M.H.VanLeeuwen 2003-11-03 23:43 ` Adam Belay 1 sibling, 1 reply; 9+ messages in thread From: M.H.VanLeeuwen @ 2003-10-23 4:30 UTC (permalink / raw) To: torvalds; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 1668 bytes --] Hi, The level of isapnp_init was moved to after apci sometime ago. Since it is now after net_dev_init, ISA PNP NICs fail to initialized at boot. This is particularily problematic for NFS root filesystems like mine, or none modular systems. I've been patching my kernel since at least 2.5.65 with the attached... This fix allows ISA PNP NIC cards to work during net_dev_init, and still leaves isapnp_init after apci_init, though I don't know if it is the right thing todo, it works for me... Comments from Alan Cox a long while back: >We must initialise ACPI before ISAPnP because we need PCI and ACPI to >know what system resources we must not hit. How about moving the >net_dev_init to later? Here is the ordering of initcall from System.map file w/ my changes on 2.6.0-test8. c044a700 t __initcall_acpi_pci_link_init c044a704 t __initcall_acpi_power_init c044a708 t __initcall_acpi_system_init c044a70c t __initcall_acpi_event_init c044a710 t __initcall_acpi_scan_init c044a714 t __initcall_pnp_init c044a718 t __initcall_pnp_system_init c044a71c t __initcall_device_init c044a720 t __initcall_as_slab_setup c044a724 t __initcall_deadline_slab_setup c044a728 t __initcall_input_init c044a72c t __initcall_i2c_init c044a730 t __initcall_pci_acpi_init c044a734 t __initcall_pci_legacy_init c044a738 t __initcall_pcibios_irq_init c044a73c t __initcall_pcibios_init c044a740 t __initcall_isapnp_init c044a744 t __initcall_chr_dev_init c044a748 t __initcall_net_dev_init c044a74c t __initcall_i8259A_init_sysfs c044a750 t __initcall_init_timer_sysfs c044a754 t __initcall_time_init_device I assume System.map is the place to see initcall ordering? Martin [-- Attachment #2: test8.isapnp.patch --] [-- Type: text/plain, Size: 577 bytes --] --- linux-2.6.0-test8.virgin/drivers/pnp/isapnp/core.c Sat Sep 27 23:17:52 2003 +++ linux-2.6.0-test8/drivers/pnp/isapnp/core.c Sat Sep 27 23:20:18 2003 @@ -1160,7 +1160,7 @@ return 0; } -device_initcall(isapnp_init); +fs_initcall(isapnp_init); /* format is: noisapnp */ --- linux-2.6.0-test8.virgin/net/core/dev.c Sat Oct 18 09:36:27 2003 +++ linux-2.6.0-test8/net/core/dev.c Wed Oct 22 23:22:57 2003 @@ -3018,7 +3018,7 @@ return rc; } -subsys_initcall(net_dev_init); +fs_initcall(net_dev_init); EXPORT_SYMBOL(__dev_get); EXPORT_SYMBOL(__dev_get_by_flags); ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] 2.6.0-test8 ISAPNP ne.c initialization 2003-10-23 4:30 ` [PATCH] 2.6.0-test8 ISAPNP ne.c initialization M.H.VanLeeuwen @ 2003-11-03 23:43 ` Adam Belay 2003-11-04 6:04 ` M.H.VanLeeuwen 0 siblings, 1 reply; 9+ messages in thread From: Adam Belay @ 2003-11-03 23:43 UTC (permalink / raw) To: M.H.VanLeeuwen; +Cc: torvalds, linux-kernel On Wed, Oct 22, 2003 at 11:30:39PM -0500, M.H.VanLeeuwen wrote: > Hi, > > The level of isapnp_init was moved to after apci sometime ago. Since it is now > after net_dev_init, ISA PNP NICs fail to initialized at boot. This is particularily > problematic for NFS root filesystems like mine, or none modular systems. > I've been patching my kernel since at least 2.5.65 with the attached... > > This fix allows ISA PNP NIC cards to work during net_dev_init, and still > leaves isapnp_init after apci_init, though I don't know if it is the right > thing todo, it works for me... > > Comments from Alan Cox a long while back: > >We must initialise ACPI before ISAPnP because we need PCI and ACPI to > >know what system resources we must not hit. How about moving the > >net_dev_init to later? > -->snip > -device_initcall(isapnp_init); > +fs_initcall(isapnp_init); I'm concerned that moving isapnp further down will spark some new problems. Also this would be far later in the init cycle than most buses. -->snip > -subsys_initcall(net_dev_init); > +fs_initcall(net_dev_init); -->snip How about something like this? (untested) The patch removes the legacy probing function from dev.c and gives it its own initcall later in the cycle. Any testing would be appreciated. I also have some patches that update the probing code in some of these drivers so that they don't have to use legacy techniques but they need to be updated to test9. This fix is probably the least intrusive. --- a/drivers/net/Space.c 2003-10-25 18:42:56.000000000 +0000 +++ b/drivers/net/Space.c 2003-11-01 22:15:01.000000000 +0000 @@ -422,7 +422,7 @@ extern int loopback_init(void); /* Statically configured drivers -- order matters here. */ -void __init probe_old_netdevs(void) +int __init net_olddevs_init(void) { int num; @@ -450,8 +450,12 @@ #ifdef CONFIG_LTPC ltpc_probe(); #endif + + return 0; } +device_initcall(net_olddevs_init); + /* * The @dev_base list is protected by @dev_base_lock and the rtln * semaphore. --- a/include/linux/netdevice.h 2003-10-25 18:44:45.000000000 +0000 +++ b/include/linux/netdevice.h 2003-11-01 22:11:04.000000000 +0000 @@ -494,7 +494,6 @@ extern struct net_device *dev_base; /* All devices */ extern rwlock_t dev_base_lock; /* Device list lock */ -extern void probe_old_netdevs(void); extern int netdev_boot_setup_add(char *name, struct ifmap *map); extern int netdev_boot_setup_check(struct net_device *dev); extern struct net_device *dev_getbyhwaddr(unsigned short type, char *hwaddr); --- a/net/core/dev.c 2003-10-25 18:43:39.000000000 +0000 +++ b/net/core/dev.c 2003-11-02 16:10:51.000000000 +0000 @@ -3007,8 +3007,6 @@ dev_boot_phase = 0; - probe_old_netdevs(); - open_softirq(NET_TX_SOFTIRQ, net_tx_action, NULL); open_softirq(NET_RX_SOFTIRQ, net_rx_action, NULL); ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] 2.6.0-test8 ISAPNP ne.c initialization 2003-11-03 23:43 ` Adam Belay @ 2003-11-04 6:04 ` M.H.VanLeeuwen 0 siblings, 0 replies; 9+ messages in thread From: M.H.VanLeeuwen @ 2003-11-04 6:04 UTC (permalink / raw) To: Adam Belay; +Cc: torvalds, linux-kernel Adam Belay wrote: > > How about something like this? (untested) I had the same reservation with re-ordering inits... Removed my patch, added this one, compiled and booted; works for me. Thanks, Martin > > The patch removes the legacy probing function from dev.c and gives it its > own initcall later in the cycle. Any testing would be appreciated. I > also have some patches that update the probing code in some of these > drivers so that they don't have to use legacy techniques but they need > to be updated to test9. This fix is probably the least intrusive. > > --- a/drivers/net/Space.c 2003-10-25 18:42:56.000000000 +0000 > +++ b/drivers/net/Space.c 2003-11-01 22:15:01.000000000 +0000 > @@ -422,7 +422,7 @@ > extern int loopback_init(void); > > /* Statically configured drivers -- order matters here. */ > -void __init probe_old_netdevs(void) > +int __init net_olddevs_init(void) > { > int num; > > @@ -450,8 +450,12 @@ > #ifdef CONFIG_LTPC > ltpc_probe(); > #endif > + > + return 0; > } > > +device_initcall(net_olddevs_init); > + > /* > * The @dev_base list is protected by @dev_base_lock and the rtln > * semaphore. > --- a/include/linux/netdevice.h 2003-10-25 18:44:45.000000000 +0000 > +++ b/include/linux/netdevice.h 2003-11-01 22:11:04.000000000 +0000 > @@ -494,7 +494,6 @@ > extern struct net_device *dev_base; /* All devices */ > extern rwlock_t dev_base_lock; /* Device list lock */ > > -extern void probe_old_netdevs(void); > extern int netdev_boot_setup_add(char *name, struct ifmap *map); > extern int netdev_boot_setup_check(struct net_device *dev); > extern struct net_device *dev_getbyhwaddr(unsigned short type, char *hwaddr); > --- a/net/core/dev.c 2003-10-25 18:43:39.000000000 +0000 > +++ b/net/core/dev.c 2003-11-02 16:10:51.000000000 +0000 > @@ -3007,8 +3007,6 @@ > > dev_boot_phase = 0; > > - probe_old_netdevs(); > - > open_softirq(NET_TX_SOFTIRQ, net_tx_action, NULL); > open_softirq(NET_RX_SOFTIRQ, net_rx_action, NULL); ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2003-11-04 6:01 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <Pine.LNX.4.10.10009211329001.1627-100000@penguin.transmeta.com> 2003-10-23 3:18 ` [BUG somewhere] 2.6.0-test8 irq.c, IRQ_INPROGRESS ? M.H.VanLeeuwen 2003-10-23 3:25 ` Linus Torvalds 2003-10-23 3:29 ` Linus Torvalds 2003-10-23 11:24 ` Marcelo Tosatti 2003-10-23 11:30 ` Mikael Pettersson 2003-10-23 14:31 ` Linus Torvalds 2003-10-23 4:30 ` [PATCH] 2.6.0-test8 ISAPNP ne.c initialization M.H.VanLeeuwen 2003-11-03 23:43 ` Adam Belay 2003-11-04 6:04 ` M.H.VanLeeuwen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).