Description of problem: When using the 2.6.25 or 2.6.25.3 kernels with Fedora 9 on a system containing an NS83820 NIC, the module refuses to load. But the same NIC works fine on the system if it is booted with the Fedora 8 kernel (2.6.24.7-92.fc8) instead. ACPI logs show in the former case that the corresponding PCI interrupt has been disabled. Version-Release number of selected component (if applicable): kernel-2.6.25.3-18.fc9.i686 How reproducible: Always. Steps to Reproduce: 1. Boot a system with an NS83820 NIC. 2. Try to 'insmod ns83820' Actual results: insmod fails with the following in /var/log/messages: May 17 01:34:46 pipe kernel: ns83820: probe of 0000:02:0a.0 failed with error -12 Expected results: insmod succeeds (as it does with the Fedora 8 kernel) with the following: May 17 08:29:34 pipe kernel: eth0: ns83820.c: 0x22c: 622a1385, subsystem: 1385:622a May 17 08:29:34 pipe kernel: eth0: ns83820 v0.23: DP83820 v1.2: 00:40:f4:47:05:33 io=0xfaffd000 irq=16 f=sg Additional info: System contains two NICs, configured as eth0 and eth1. lspci output: 02:0a.0 Ethernet controller: National Semiconductor Corporation DP83820 10/100/1000 Ethernet Controller 02:0c.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78) Successful ifup of eth0 and eth1 (with Fedora 8 kernel) yields in /var/log/messages: May 17 08:29:34 pipe kernel: ns83820.c: National Semiconductor DP83820 10/100/1000 driver. May 17 08:29:34 pipe kernel: ACPI: PCI Interrupt 0000:02:0a.0[A] -> GSI 19 (level, low) -> IRQ 16 May 17 08:29:34 pipe kernel: eth0: ns83820.c: 0x22c: 622a1385, subsystem: 1385:622a May 17 08:29:34 pipe kernel: eth0: ns83820 v0.23: DP83820 v1.2: 00:40:f4:47:05:33 io=0xfaffd000 irq=16 f=sg May 17 08:29:34 pipe kernel: ACPI: PCI Interrupt 0000:02:0c.0[A] -> GSI 18 (level, low) -> IRQ 17 May 17 08:29:34 pipe kernel: 3c59x: Donald Becker and others. May 17 08:29:34 pipe kernel: 0000:02:0c.0: 3Com PCI 3c905C Tornado at f8912c00. Boot with Fedora 9 kernels (kernel-2.6.25.3-18.fc9.i686 or kernel-2.6.25-14.fc9.i686) yields instead: May 17 01:34:46 pipe kernel: ns83820.c: National Semiconductor DP83820 10/100/1000 driver. May 17 01:34:46 pipe kernel: ACPI: PCI Interrupt 0000:02:0a.0[A] -> GSI 19 (level, low) -> IRQ 19 May 17 01:34:46 pipe kernel: ACPI: PCI interrupt for device 0000:02:0a.0 disabled May 17 01:34:46 pipe kernel: ns83820: probe of 0000:02:0a.0 failed with error -12 May 17 01:34:46 pipe kernel: ACPI: PCI Interrupt 0000:02:0c.0[A] -> GSI 18 (level, low) -> IRQ 18 May 17 01:34:46 pipe kernel: 3c59x: Donald Becker and others. May 17 01:34:46 pipe kernel: 0000:02:0c.0: 3Com PCI 3c905C Tornado at f8902c00. Please let me know if you need additional system information to diagnose this problem.
Same thing with the latest kernel, kernel-2.6.25.4-30.fc9.i686: Jun 6 15:46:57 pipe kernel: ns83820.c: National Semiconductor DP83820 10/100/1000 driver. Jun 6 15:46:57 pipe kernel: ACPI: PCI Interrupt 0000:02:0a.0[A] -> GSI 19 (level, low) -> IRQ 19 Jun 6 15:46:57 pipe kernel: ACPI: PCI interrupt for device 0000:02:0a.0 disabled Jun 6 15:46:57 pipe kernel: ns83820: probe of 0000:02:0a.0 failed with error -12 Still works just fine with the FC8 kernel (2.6.24).
Created attachment 310188 [details] lspci -vvv when 2.6.24.7-92.fc8.i686 kernel booted, ns83820 nic working Working with irq=21 f=sg
Created attachment 310190 [details] lspci -vvv when 2.6.25.6-27.fc8.i686 kernel booted, ns83820 nic fails GSI 19 (level, low) -> IRQ 19 results in probe failure, error: -12
Still does not work with the latest update, kernel-2.6.25.9-76.fc9.i686: Jul 3 13:33:23 pipe kernel: ns83820.c: National Semiconductor DP83820 10/100/1000 driver. Jul 3 13:33:23 pipe kernel: ACPI: PCI Interrupt 0000:02:0a.0[A] -> GSI 19 (level, low) -> IRQ 19 Jul 3 13:33:23 pipe kernel: ACPI: PCI interrupt for device 0000:02:0a.0 disabled Jul 3 13:33:23 pipe kernel: ns83820: probe of 0000:02:0a.0 failed with error -12
Exactly the same problem still occurs with kernel-2.6.25.10-86.fc9.i686. Is there any other information you need about this system to make any progress on the bug, or things I can do to attempt to pinpoint it?
I see the same behavior with FC8. Last worked in 2.6.24.xxxx, fails consistently in 2.6.25.xxx. Hardware (2 machines) are Athlon XP 3200/Epox 8KRAI or Athlon 64 3500+/MSI 7093. Both with Netgear GA621 fiber/gigabit cards. I tried putting some debugging statements in ns83820.c: (in function static init __devinit ns83820_init_one) printk(KERN_INFO "in init_one before pci_set_master \n"); pci_set_master(pci_dev); addr = pci_resource_start(pci_dev, 1); printk(KERN_INFO "in init_one addr %lx \n", addr); dev->base = ioremap_nocache(addr, PAGE_SIZE); printk(KERN_INFO "in init_one base %p \n", (dev->base)); yields the following in /var/log/messages: kernel: ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 20 (level, low) -> IRQ 20 kernel: in init_one before pci_set_master kernel: in init_one addr fdcff000 This address agrees with lspci -v for both working (2.6.24) and non-working (2.6.25) kernels. The other hardware platform gives a different address, but still consistent with lspci -v kernel: in init_one base 00000000 HUH? kernel: ACPI: PCI interrupt for device 0000:02:00.0 disabled kernel: ns83820: probe of 0000:02:00.0 failed with error -12 My guess is that it executes this line of code: if (!dev->base || !dev->tx_descs || !dev->rx_info.descs) goto out_disable; and does the goto.... which then fails the card. I can do some limited debugging... obviously I can put debugging comments in the driver and compile a kernel... Thanks, Steve
I've traced the problem into ioremap.c and have a "work around". I added some debugging code at line 119 in __ioremap() in /usr/src/linux/arch/x86/mm/ioremap.c last_addr = phys_addr + size - 1; printk(KERN_INFO "SB ioremap phys = %lx size = %lx last = %lx \n", (unsigned long) phys_addr, size, last_addr); if (last_addr < phys_addr) printk(KERN_INFO "SB ioremap, last < phys\n"); produces (in /var/log/messages): SB ioremap phys = fdcff000 size = 1000 last = fdcfffff SB ioremap, last < phys !!!!!!!!!!! Note that the comparison (last_addr < phys_addr) returns TRUE! Now, the next line in __ioremap is the test: if (!size || last_addr < phys_addr) return NULL; which returns NULL (hence dev->base in ns83820.c = NULL) The workaround is to add an explicit typecast: if (!size || last_addr < (unsigned long) phys_addr) return NULL; Now, the ns83820 module loads fine. The 2 remaining questions are: 1) phys_addr is of type resource_size_t (u64?), " *__ioremap(resource_size_t phys_addr, " last_addr is of type unsigned long " unsigned long pfn, offset, last_addr, vaddr;" Shouldn't those be the same? What else is (possibly) broken in __ioremap.c? 2) How does this get fixed upstream? Steve
Created attachment 312697 [details] 64-bit resource on 32-bit kernel fix This patch should fix the problem. It's already in 2.6.26.
backported patch in: -64.fc8 and -102.fc9
kernel-2.6.25.14-107.fc9 has been submitted as an update for Fedora 9
kernel-2.6.25.14-108.fc9 has been submitted as an update for Fedora 9
kernel-2.6.25.14-108.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-7043
The updated kernel (kernel-2.6.25.14-108.fc9.i686) fixes this problem on my system. Thanks!
kernel-2.6.25.14-108.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.