Bug 9920 - Sun Quad Ethernet PCI card prohibits boot
Sun Quad Ethernet PCI card prohibits boot
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
6.2
sparc Linux
medium Severity medium
: ---
: ---
Assigned To: David Miller
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-03-02 09:51 EST by Paul Kronenwetter
Modified: 2008-05-01 11:37 EDT (History)
0 users

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


Attachments (Terms of Use)

  None (edit)
Description Paul Kronenwetter 2000-03-02 09:51:00 EST
With a Sun QFE card installed in the (a) PCI slot, the machine will not
boot.  The portion of the kernel the error comes from is
arch/sparc64/psycho.c in the routine: static int __init
pbm_intmap_match(...)

Here's the boot log:

Netra t1 (UltraSPARC-IIi 440MHz), No Keyboard
OpenBoot 3.10.24 ME, 512 MB memory installed, Serial #12707634.
Ethernet address 8:0:20:c1:e7:32, Host ID: 80c1e732.

Boot device: linux  File and args:
SILO boot:
Uncompressing image...
Loading initial ramdisk....
|
Remapping the kernel... done.
Booting Linux...
pbm_intmap_match: bus 04, devfn 01: IRQ
[00037800.00000000.00000000.00000002] not found in interrupt-map
Program terminated
ok

The machine works perfectly without the QFE card installed.  The error is
exhibited by the latest beta kernel (2.3.48) as well.

I'm wondering if it's a problem of:
1) I never loaded Solaris on the box and Solaris does some magical
configuration on the card that may make it work.
2) There's a setting in the NVRAM that could be set differently.

Relevent parts of the diag-mode output:
...
Probing /pci@1f,0/pci@1,1 at Device 1  network
Probing /pci@1f,0/pci@1,1 at Device 2  scsi disk tape
Probing /pci@1f,0/pci@1,1 at Device 3  network
Probing /pci@1f,0/pci@1 at Device 1  pci
Probing /pci@1f,0/pci@1/pci@1 at Device 0  Nothing there
Probing /pci@1f,0/pci@1/pci@1 at Device 1  Nothing there
...
Probing /pci@1f,0/pci@1/pci@1 at Device e  ide disk cdrom
Probing /pci@1f,0/pci@1/pci@1 at Device f  pci
Probing /pci@1f,0/pci@1/pci@1/pci@f at Device 0  pci108e,1000 SUNW,qfe
Probing /pci@1f,0/pci@1/pci@1/pci@f at Device 1  pci108e,1000 SUNW,qfe
Probing /pci@1f,0/pci@1/pci@1/pci@f at Device 2  pci108e,1000 SUNW,qfe
Probing /pci@1f,0/pci@1/pci@1/pci@f at Device 3  pci108e,1000 SUNW,qfe
Probing /pci@1f,0/pci@1/pci@1/pci@f at Device 4  Nothing there
Probing /pci@1f,0/pci@1/pci@1/pci@f at Device 5  Nothing there
...

/pci@1f,0/pci@1,1 devices 1 and 3 are the internal HME ports, which work
fine.  /pci@1f,0/pci@1/pci@1/pci@f is the qfe card (of course).

I will be trying this whole thing in an Ultra 10/PCI machine to see if it's
particular to the Netra-T1.

Please let me know if there's any additional information I can
supply!

Thanks!
-Paul
paul.kronenwetter@lmco.com
Comment 1 Paul Kronenwetter 2000-03-02 13:00:59 EST
It does appear to work on a Sun Ultra 10.  The OPENPROM version of the 10 is
3.19.
Comment 2 Bill Nottingham 2000-03-29 11:06:59 EST
What does the prom say if you do:

printenv pcia-probe-list
printenv pcib-probe-list

?
Comment 3 Paul Kronenwetter 2000-03-29 11:16:59 EST
Netra T1
ok printenv pcia-probe-list
pcia-probe-list =     1
ok printenv pcib-probe-list
pcib-probe-list =     1,2

Ultra 10:
ok printenv pcia-probe-list
pcia-probe-list =     1,2,3,4
ok printenv pcib-probe-list
pcib-probe-list =     1,2,3
Comment 4 Bill Nottingham 2000-03-29 11:20:59 EST
Do 'setenv pcib-probe-list "1,2,3"'; does that solve the problem?
Comment 5 Paul Kronenwetter 2000-03-29 11:25:59 EST
No.  Here's what it said after SILO booted the 6.2beta CD:

boot: text
Uncompressing image...
Loading initial ramdisk....
/
Remapping the kernel... done.
No alarm was installed for f005649c
Booting Linux...
pbm_intmap_match: bus 04, devfn 01: IRQ [00037800.00000000.00000000.00000002] no
t found in interrupt-map
Program terminated
ok
Comment 6 Bill Nottingham 2000-03-29 11:42:59 EST
Hm, it looks like it might be a problem with the device not being
enabled in the PROM pci probe, but I don't know the specifics of the various sun
boxes to know *what* it should be set to - davem? Or is it
something else?
Comment 7 David Miller 2000-03-29 19:02:59 EST
Please supply "prtconf -pv" and "cat /proc/pci" output for the
Netra-T1 machine before inserting the QFE card.

Next, insert the card into the Netra-T1, and at the firmware prompt
execute the following:

ok cd /pci@1f,0/pci@1/pci@1/
ok .properties

And record the output generated by the ".properties" command.

Please email this to me privately at davem@redhat.com because
the voluminous output does not belong in this bug report, and
I will summarize what I learn from this debugging info here anyways.

Thank you.
Comment 8 David Miller 2000-03-29 19:03:59 EST
I'm sorry, a clarification on the previous request for debugging.
The proper firmware commands to run is:

ok cd /pci@1f,0/pci@1/
ok .properties

(I listed 'pci@1' too many times in the device path previously.)

Thanks.
Comment 9 Paul Kronenwetter 2000-05-12 11:20:59 EDT
Dave,

  I'm sorry about this but - the machine has finally been fixed and was
reassigned.  It's no longer available for the resolution of this bug.  If I come
across another T1 and a QFE card, I'll let you know.

Thanks so much!
-Paul
Comment 10 Paul Kronenwetter 2000-05-17 11:00:59 EDT
Whoa - I can use the machine for a little while...  I'm installing Red Hat 6.2
on it and updating the kernel to 2.2.14-12... Status in a little while as I need
to extract the QFE card from the Ultra 10 it's currently living in...

-Paul
Comment 11 Paul Kronenwetter 2000-05-17 11:16:59 EDT
Problem is still exhibited by 2.2.14-12.  Will dig up patch from previous mail
message and test...
Comment 12 Paul Kronenwetter 2000-05-17 15:47:59 EDT
Patch allows system to boot, card is recognized and can configure ports.
However no traffic flows in.  A ping originating from the system generates
traffic but it can't see the arp response.

-Paul
Comment 13 Stephen John Smoogen 2003-01-24 15:11:01 EST
Red Hat no longer has a port of the Sparc Linux port and does not seem to have
the resources to continue bug fixing the older versions. With Red Hat Linux 6.2
being end of lifed in March, this ticket is better to be closed.

Please look at the Aurora Linux project http://auroralinux.org/ which seems to
have a working port for various Sparc machines.

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