Bug 447143
Summary: | [IOMAP] ns83820 module refuses to load with 2.6.25 kernel; PCI interrupt disabled | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Ben Webb <ben> |
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | low | ||
Version: | 9 | CC: | nhorman, zzybaloobah |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-07-15 08:24:45 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Attachments: |
Description
Ben Webb
2008-05-18 08:19:33 UTC
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. |