Most recent kernel where this bug did not occur: 2.6.20 Distribution: Debian Unstable Hardware Environment: PC, CPU: Intel E6600, mainboard: Asus P5B-V Software Environment: AMD64 Problem Description: This was first reported to the Debian BTS and the netdev ML: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=441232 http://marc.info/?t=118918345400007&r=1&w=2 With recent kernels my on-board network adapter does not work any more. This is a Marvell Gigabit Ethernet Controller on an Asus P5B-V mainboard. The last working kernel was 2.6.20. All following kernels (.21.x, .22.x, .23-rc5) have exposed the same problem. The key problem seems to be the following lines in dmesg: ------------------------------------------------------------------------ ACPI: PCI Interrupt 0000:04:04.0[A] -> GSI 19 (level, low) -> IRQ 19 PCI: Unable to reserve mem region #1:4000@ff9f8000 for device 0000:04:04.0 skge 0000:04:04.0: cannot obtain PCI resources ACPI: PCI interrupt for device 0000:04:04.0 disabled skge: probe of 0000:04:04.0 failed with error -16 ------------------------------------------------------------------------ With previous kernels there were the following messages about resource collisions, however I did never notice a problem with said SATA controller - everything was working fine AFAICT. ------------------------------------------------------------------------ PCI: Cannot allocate resource region 2 of device 0000:02:00.0 PCI: Cannot allocate resource region 3 of device 0000:02:00.0 PCI: Device 0000:02:00.0 not available because of resource collisions ahci: probe of 0000:02:00.0 failed with error -22 JMB363: IDE controller at PCI slot 0000:02:00.0 PCI: Device 0000:02:00.0 not available because of resource collisions ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 16 JMB363: BIOS configuration fixed. ------------------------------------------------------------------------ Steps to reproduce: Boot kernel >= 2.6.21, modprobe skge fails with aforementioned dmesg output.
Created attachment 12957 [details] dmesg output with kernel 2.6.23-rc5 skge fails to load
Created attachment 12958 [details] Output of 'lspci -vvxxx' with kernel 2.6.23-rc5
Created attachment 12959 [details] dmesg output with kernel 2.6.20 Everything seems to work alright with this kernel.
Could you try the linux firmware test kit to print out any PCI region issues. See: http://www.linuxfirmwarekit.org/download.php
Created attachment 13047 [details] Results from Firmware Test Kit r3 I'm attaching an archive with all result files produced by an automatic run of the Firmware Test Kit. If you want me to run additional tests please tell me.
What is lspci output on 2.6.20, it looks like the PCI bridge isn't setup right.
Okay, here is the conflict, looks like an ACPI/BIOS issue because these resources are assigned before device ever starts: Inside the lspci: 04:04.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 14) Subsystem: ASUSTeK Computer Inc. Marvell 88E8001 Gigabit Ethernet Controller (Asus) Region 0: Memory at ff9f8000 (32-bit, non-prefetchable) [size=16K] Inside the ACPI decode from firmware test: Device (RMSC) { Name (_HID, EisaId ("PNP0C02")) Name (_UID, 0x10) Name (CRS, ResourceTemplate () { ... Memory32Fixed (ReadWrite, 0xFF9FA000, // Address Base 0x00001000, // Address Length So some ACPI reserved region is in the middle of the Ethernet device's space. Please ask Len Brown or other ACPI experts. Reassigning bug to ACPI maintainers
Created attachment 13056 [details] Output of 'lspci -vvxxx' with kernel 2.6.20 In case it's still relevant.
Any update on this problem please. Thanks.
Hi, Jan Will you please enable the PCI debug function in kernel configuration and try to boot the system with the option of initcall_debug debug ? After the system is booted, please attach the dmesg . Thanks.
Created attachment 13781 [details] dmesg with PCI_DEBUG and initcall_debug
Hi, Jan Thanks for the info. What Steffen said in comment #7 is very right and this is resource conflict. Ethernet device wants to request the memory resource of 0xff9f8000-0xff9fBFFF.But the range of 0xFF9FA000-0xFF9FAFFF is reserved by the device of PNP0C02. So the Ethernet can't request the memory resource and report the error message. This is caused by the commit of a8c78f7fb1571764f48b8af5459abdd2c66a765f, which reserves system board iomem resources as well as ioport resources for PNP device. This patch is quite reasonable. This patch isn't merged into the 2.6.20 so ethernet can request the resource successfully. But the patch is merged into 2.6.21-2.6.23, so the ethernet device can't request the memory resource. Of course the ethernet can work well if the boot option of "pnpacpi=off" is added. The bug is caused by broken BIOS and it is appropriate to fix it by BIOS update.