Bug 447143 - [IOMAP] ns83820 module refuses to load with 2.6.25 kernel; PCI interrupt disabled
[IOMAP] ns83820 module refuses to load with 2.6.25 kernel; PCI interrupt disa...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
9
i686 Linux
low Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-18 04:19 EDT by Ben Webb
Modified: 2009-07-15 04:24 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-15 04:24:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
lspci -vvv when 2.6.24.7-92.fc8.i686 kernel booted, ns83820 nic working (22.24 KB, text/plain)
2008-06-24 17:24 EDT, Mark Kaepplein
no flags Details
lspci -vvv when 2.6.25.6-27.fc8.i686 kernel booted, ns83820 nic fails (22.78 KB, text/plain)
2008-06-24 17:30 EDT, Mark Kaepplein
no flags Details
64-bit resource on 32-bit kernel fix (1.12 KB, text/plain)
2008-07-25 19:36 EDT, Chuck Ebbert
no flags Details

  None (edit)
Description Ben Webb 2008-05-18 04:19:33 EDT
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.
Comment 1 Ben Webb 2008-06-06 21:53:51 EDT
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).
Comment 2 Mark Kaepplein 2008-06-24 17:24:57 EDT
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
Comment 3 Mark Kaepplein 2008-06-24 17:30:09 EDT
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
Comment 4 Ben Webb 2008-07-03 16:37:47 EDT
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
Comment 5 Ben Webb 2008-07-18 01:04:54 EDT
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?
Comment 6 SteveB 2008-07-22 15:35:46 EDT
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
Comment 7 SteveB 2008-07-23 16:19:17 EDT
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
Comment 8 Chuck Ebbert 2008-07-25 19:36:08 EDT
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.
Comment 9 Chuck Ebbert 2008-07-25 20:30:40 EDT
backported patch in: -64.fc8 and -102.fc9
Comment 10 Fedora Update System 2008-08-04 09:43:40 EDT
kernel-2.6.25.14-107.fc9 has been submitted as an update for Fedora 9
Comment 11 Fedora Update System 2008-08-06 08:17:51 EDT
kernel-2.6.25.14-108.fc9 has been submitted as an update for Fedora 9
Comment 12 Fedora Update System 2008-08-07 19:52:45 EDT
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
Comment 13 Ben Webb 2008-08-08 16:30:56 EDT
The updated kernel (kernel-2.6.25.14-108.fc9.i686) fixes this problem on my system. Thanks!
Comment 14 Fedora Update System 2008-08-12 14:19:45 EDT
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.
Comment 15 Bug Zapper 2009-06-09 20:57:23 EDT
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
Comment 16 Bug Zapper 2009-07-15 04:24:45 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.