# eth0 not working after kernel upgrade (IRQ conflict?) SOLVED

## infinity9

i recently upgraded my kernel from 2.6.26-r4 to 2.6.31-r6, and finally got it to boot without a kernel panic.  however, i now have two pieces of hardware that don't work with this kernel: my sound card, and my network adapter.  the latter is a priority.

i have a broadcom netextreme gigabit ethernet adapter, with which i use the tg3 driver built into the kernel.  whenever i boot into 2.6.31, i get the message "SIOCSIFFLAGS: Device or resource busy" when eth0 is starting up; this doesn't happen with 2.6.26.  dmesg leads me to believe an IRQ conflict is involved:

dmesg:

```

[    1.495611] tg3.c:v3.99 (April 20, 2009)

[    1.519534] tg3 0000:06:00.0: PCI INT A -> GSI 0 (level, low) -> IRQ 0

[    1.545059] tg3 0000:06:00.0: wake-up capability disabled by ACPI

[    1.568932] tg3 0000:06:00.0: PME# disabled

[    1.598538] eth0: Tigon3 [partno(BCM95705A50) rev 3003] (PCI:33MHz:32-bit) MAC address 00:e0:b8:81:db:93

[    1.622976] eth0: attached PHY is 5705 (10/100/1000Base-T Ethernet) (WireSpeed[0])

[    1.647797] eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]

[    1.672776] eth0: dma_rwctrl[763f0000] dma_mask[64-bit]

```

```

[    3.400427] i801_smbus 0000:00:1f.3: PCI INT B -> GSI 0 (level, low) -> IRQ 0

[    3.424954] ACPI: I/O resource 0000:00:1f.3 [0x20a0-0x20bf] conflicts with ACPI region SMBI [0x20a0-0x20af]

[    3.450001] ACPI: This conflict may cause random problems and system instability

[    3.475100] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver

```

```

[   41.508269] tg3 0000:06:00.0: firmware: using built-in firmware tigon/tg3_tso5.bin

[   41.508285] tg3 0000:06:00.0: wake-up capability disabled by ACPI

[   41.508292] tg3 0000:06:00.0: PME# disabled

[   41.521120] tg3 0000:06:00.0: wake-up capability disabled by ACPI

[   41.521128] tg3 0000:06:00.0: PME# disabled

[   41.564908] tg3 0000:06:00.0: wake-up capability disabled by ACPI

[   41.564917] tg3 0000:06:00.0: PME# disabled

[   41.586960] tg3 0000:06:00.0: wake-up capability disabled by ACPI

[   41.586969] tg3 0000:06:00.0: PME# disabled

[   42.289329] tg3 0000:06:00.0: wake-up capability disabled by ACPI

[   42.289337] tg3 0000:06:00.0: PME# disabled

[   47.962820] pci 0000:01:00.0: power state changed by ACPI to D0

[   47.962830] pci 0000:01:00.0: PCI INT A -> GSI 0 (level, low) -> IRQ 0

```

lspci:

```

00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 03)

06:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5705_2 Gigabit Ethernet (rev 03)

```

i tried adding "acpi_enforce_resources=lax" to /boot/grub/grub.conf after finding similar situations on google, but this didn't do anything.  any help would be appreciated.

----------

## USTruck

Hello,

Can you test with another net driver like : Broadcom NetXtremeII support.

About acpi : what about your motherboard/chipset/Processor , can you enable acpi (full by module or inside ?)

----------

## infinity9

USTruck, thanks for your reply.

only the Tigon3 driver has ever worked with my network card; it autodetects whenever i install gentoo on this machine.  just to be sure, i tried the Broadcom NetExtremeII driver, and it didn't work.

as for acpi, of course it's enabled--i doubt it would show up in dmesg if it weren't.  here's my kernel config:

```

#

# Power management and ACPI options

#

CONFIG_PM=y

CONFIG_PM_DEBUG=y

# CONFIG_PM_VERBOSE is not set

CONFIG_CAN_PM_TRACE=y

CONFIG_PM_TRACE=y

CONFIG_PM_TRACE_RTC=y

CONFIG_PM_SLEEP=y

CONFIG_SUSPEND=y

# CONFIG_PM_TEST_SUSPEND is not set

CONFIG_SUSPEND_FREEZER=y

CONFIG_HIBERNATION_NVS=y

CONFIG_HIBERNATION=y

CONFIG_PM_STD_PARTITION=""

CONFIG_ACPI=y

CONFIG_ACPI_SLEEP=y

# CONFIG_ACPI_PROCFS is not set

# CONFIG_ACPI_PROCFS_POWER is not set

CONFIG_ACPI_SYSFS_POWER=y

# CONFIG_ACPI_PROC_EVENT is not set

CONFIG_ACPI_AC=y

CONFIG_ACPI_BATTERY=y

CONFIG_ACPI_BUTTON=y

CONFIG_ACPI_VIDEO=m

CONFIG_ACPI_FAN=y

CONFIG_ACPI_DOCK=y

CONFIG_ACPI_PROCESSOR=y

CONFIG_ACPI_THERMAL=y

# CONFIG_ACPI_CUSTOM_DSDT is not set

CONFIG_ACPI_BLACKLIST_YEAR=2001

# CONFIG_ACPI_DEBUG is not set

# CONFIG_ACPI_PCI_SLOT is not set

CONFIG_X86_PM_TIMER=y

# CONFIG_ACPI_CONTAINER is not set

# CONFIG_ACPI_SBS is not set

# CONFIG_APM is not set

```

acpi also shows up in /proc/interrupts, but when i compare that file between kernel versions, they're entirely different:

2.6.26 /proc/interrupts:

```

           CPU0       

  0:       8092   IO-APIC-edge      timer

  1:        186   IO-APIC-edge      i8042

  9:          6   IO-APIC-fasteoi   acpi

 12:        123   IO-APIC-edge      i8042

 14:       8474   IO-APIC-edge      ide0

 16:          0   IO-APIC-fasteoi   tifm_7xx1, mmc0, mmc1, mmc2, radeon@pci:0000:01:00.0

 18:          3   IO-APIC-fasteoi   ohci1394

 19:       1612   IO-APIC-fasteoi   eth0

 21:          0   IO-APIC-fasteoi   Intel ICH6

 22:          0   IO-APIC-fasteoi   uhci_hcd:usb4, uhci_hcd:usb5

 23:        577   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3

NMI:          0   Non-maskable interrupts

LOC:       7645   Local timer interrupts

TRM:          0   Thermal event interrupts

SPU:          0   Spurious interrupts

ERR:          0

MIS:          0

```

2.6.31 /proc/interrupts:

```

           CPU0       

  0:      19862    XT-PIC-XT        timer

  1:        249    XT-PIC-XT        i8042

  2:          0    XT-PIC-XT        cascade

  3:          1    XT-PIC-XT      

  4:          1    XT-PIC-XT      

  5:          1    XT-PIC-XT      

  6:          1    XT-PIC-XT      

  7:          1    XT-PIC-XT      

  8:        115    XT-PIC-XT        rtc0

  9:       1338    XT-PIC-XT        acpi

 10:          2    XT-PIC-XT      

 11:          2    XT-PIC-XT      

 12:        134    XT-PIC-XT        i8042

 14:       4063    XT-PIC-XT        ide0

NMI:          0   Non-maskable interrupts

TRM:          0   Thermal event interrupts

MCE:          0   Machine check exceptions

MCP:          1   Machine check polls

ERR:          0

```

i think this is linked to the cause of my problem, but i'm not sure what to do about it.  is this due to a specific kernel config setting(s)?

----------

## USTruck

Hello

This is due by your bios, it can remap some irq and pci  like : lspci -M

```
00: Primary host bus

        1e.0 Bridge to 26-26

        1c.5 Bridge to 20-20

        1c.4 Bridge to 1a-1a

        1c.3 Bridge to 14-14

        1c.2 Bridge to 0e-0e

        1c.1 Bridge to 08-08

        1c.0 Bridge to 03-03

        03.0 Bridge to 02-02

02: Entered via 00:03.0

08: Entered via 00:1c.1

14: Entered via 00:1c.3

20: Entered via 00:1c.5

ff: Secondary host bus (?)
```

You see that some busses are 'binded' to another, and thus IRQ to.

Can you test with kernel parameter : pci=assign-busses

If it's work, look about 'IRQ and DMA remap' under kernel config (to remove pci=assign-busses)

Probably it's a source of your problem about acpi and net cards

----------

## infinity9

pci=assign-busses didn't change anything, unfortunately.

i ran lspci -M while running both kernels, and again got two different results.

2.6.26 lspci -M:

```

Summary of buses:

00: Primary host bus

        1e.0 Bridge to 06-07

        01.0 Bridge to 01-01

01: Entered via 00:01.0

06: Entered via 00:1e.0

        09.0 Bridge to 07-0a <crossing bug>

```

2.6.31 lspci -M:

```

Summary of buses:

00: Primary host bus

   1e.0 Bridge to 06-0a

   01.0 Bridge to 01-01

01: Entered via 00:01.0

06: Entered via 00:1e.0

   09.0 Bridge to 07-0a

```

odd that the output under 2.6.26 says something about a bug, even though it's the kernel that actually works.  also, i didn't find anything called "IRQ and DMA remap" in the kernel config; are you sure that's the name of the option?

i'm now sure that this issue has something to do with busses.  i realized that it's not just my net and sound that don't work, but my usb ports don't work either.  figuring this issue out will likely fix all of these problems at the same time.

----------

## cach0rr0

did your kernel update include a udev update as well?

if so, try nuking /etc/udev/rules.d/70-persistent-net.rules and reboot. 

If still no joy, see if the device is even listed in /proc/net/dev

----------

## Muso

You might have to symlink net.lo to net.eth0 in /dev if it no longer exists.

----------

## USTruck

Hello

About 2.26 error message ; probably your chipset can't be handle correctly by kernel 

About kernel config (I'am under 64 Bit !!)

Processor : X86_MPPARSE

Bus Option (PCI) : DMAR ; DMRA_DEFAULT_ON; INTR_REMAP

But what about your Motherboard (chipset), Processor ..... Probably some of Gentoo user have this and solve!

lspci | grep USB -> USB2 Enhanced Host Controller or USB Host Controller (USB Host = usb1 only)

Remember if you set EHCI (usb2) under kernel do not miss to set OHCI (usb1) and if you have intel or Via chipset probably set UHCI too

Another way, it's possible that kernel config migration from 2.26 to 2.31 became wrong ?

Under 2.26 kernel boot go to 2.31 source

make mrproper, make oldconfig and finaly  make menuconfig

That change some ?

----------

## infinity9

cach0rr0, i did also update udev when updating my kernel.  you can imagine my frustration at seeing a message telling me to update my kernel whenever i boot 2.6.26, despite the updated kernel being the one with issues.

deleting 70-persistent-net.rules had no effect.  here's my /proc/net/dev under 2.6.26:

```

Inter-|   Receive                                                |  Transmit

 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed

    lo:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0

  eth0: 2418625    2545    0    0    0     0          0         0   419218    3014    0    0    0     0       0          0

  sit0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0

  ppp0: 2350569    2504    0    0    0     0          0         0   338862    2966    0    0    0     0       0          0

```

under 2.6.31, all the lines have nothing but zeroes because eth0 isn't even starting, and the ppp0 line isn't present because it needs eth0 to start.

----------

## USTruck

Hello

Some info : https://forums.gentoo.org/viewtopic-t-801641-highlight-.html

Direct link : http://www.kernel-seeds.org/settings-01.html

And : http://www.kernel-seeds.org/settings-05.html

----------

## cach0rr0

 *infinity9 wrote:*   

> 
> 
> under 2.6.31, all the lines have nothing but zeroes because eth0 isn't even starting, and the ppp0 line isn't present because it needs eth0 to start.

 

Even without eth0 started, if the driver is functioning correctly it should show in /proc/net/dev

PoC:

```

laptop02 linux # awk '{print $1}' /proc/net/dev

Inter-|

face

lo:

dummy0:

wlan0:36400802

# modprobe -v atl1e

insmod /lib/modules/2.6.32-zen7/kernel/drivers/net/atl1e/atl1e.ko

laptop02 linux # awk '{print $1}' /proc/net/dev

Inter-|

face

lo:

dummy0:

wlan0:36403750

eth0:

```

So here's my next thought - build your NIC driver as a module

Do not set it to autoload

boot up

Then do a "modprobe -v <module name>" and check dmesg for errors. 

If we manually modprobe it, it should be much easier to diagnose.

----------

## infinity9

 *Quote:*   

> 
> 
> Even without eth0 started, if the driver is functioning correctly it should show in /proc/net/dev
> 
> 

 

oh, the eth0 line is definitely there in /proc/net/dev, it just has a bunch of zeroes after it.

i don't think it's a driver issue, but i'll try building the tg3 driver as a module and see what happens.

----------

## infinity9

what do i do to keep the module from being autoloaded?

----------

## cach0rr0

 *infinity9 wrote:*   

> what do i do to keep the module from being autoloaded?

 

blacklist it. 

Used to be in /etc/modprobe.conf, nowadays i think it's in /etc/modprobe.d/blacklist.conf

a line such as this (for my atl1e driver)

```

blacklist atl1e

```

literally that's it. 

But yeah, dmesg after modprobe would be interesting, as would checking dmesg after just doing

```

ifconfig eth0 up

```

I would expect it to upchuck errors. If we're not seeing it upchuck errors at all, I'd be inclined to say it's a config issue rather than driver issue.

----------

## infinity9

modprobing gives me the exact same dmesg output as in the first post:

```

[   73.817546] tg3.c:v3.99 (April 20, 2009)

[   73.817566] tg3 0000:06:00.0: PCI INT A -> GSI 0 (level, low) -> IRQ 0

[   73.819102] tg3 0000:06:00.0: wake-up capability disabled by ACPI

[   73.819109] tg3 0000:06:00.0: PME# disabled

[   73.843597] eth0: Tigon3 [partno(BCM95705A50) rev 3003] (PCI:33MHz:32-bit) MAC address 00:e0:b8:81:db:93

[   73.843602] eth0: attached PHY is 5705 (10/100/1000Base-T Ethernet) (WireSpeed[0])

[   73.843606] eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]

[   73.843609] eth0: dma_rwctrl[763f0000] dma_mask[64-bit]

```

i'm sure this is a config issue.  note that dmesg says "wake up capability disabled by ACPI", and also says that there's a conflict between ACPI and "I/O resource 0000:00:1f.3", the smbus (see first post).  furthermore, both tg3 and i801_smbus say something about IRQ 0 in dmesg.

----------

## krinn

 *infinity9 wrote:*   

> 
> 
> acpi also shows up in /proc/interrupts, but when i compare that file between kernel versions, they're entirely different:
> 
> 2.6.26 /proc/interrupts:
> ...

 

I cut off a lot just to still see samples of what you have said.

Yes, it's definitively a kernel configuration problem, you have acpi present but you're kernel only use 16 irq while todays computer can handle far more. With so few irq available many cards will have to share the same irq and they don't really love that. 

Your problem isn't ACPI but APIC (funny, just mixed letters): http://en.wikipedia.org/wiki/Advanced_Programmable_Interrupt_Controller

Notice also how your kernel 2.6.31 named your irq handler: XT-PIC-XT versus the IO-APIC-fastoi from the 2.6.26 (that also show irq 23 in use, the limit isn't there in that case).

I'm not sure how the option is named, please check (if i'm right) for 

cat /usr/src/linux/.config | grep CONFIG_HPET_TIMER

If not, i'm sure someone could point you out the right option to enable the new APIC.

Once done, all should come back to normal by magic you'll see.

----------

## infinity9

boom!  problem solved.

HPET timer support was already enabled; what i had to do was enable "Local APIC support on uniprocessors" and the sub-option "IO-APIC support on uniprocessors" under "Processor type and features".  everything works like a charm, as predicted.

thanks for the help.

----------

