Timeout message from bge(4)
Matthias Scheler
Hello,
I'm trying to use a 3Com 3C996B-T with NetBSD 2.0E on a sparc64 system:
bge0 at pci1 dev 1 function 0: Broadcom BCM5701 Gigabit Ethernet
bge0: interrupting at ivec 0
bge0: firmware handshake timed out, val = 4b657654
bge0: ASIC BCM5701 B5 (0x0105), Ethernet address 00:0a:5e:1e:97:d5
brgphy0 at bge0 phy 1: BCM5701 1000BASE-T media interface, rev. 0
The timeout message appears every time the driver tries to talk to the
card which therefore doesn't work. Is anybody using a 3Com 3C996B-T
successfully which would make it a NetBSD-sparc64 problem?
Kind regards
--
Matthias Scheler http://scheler.de/~matthias/
Andrey Petrov
>
> Hello,
>
> I'm trying to use a 3Com 3C996B-T with NetBSD 2.0E on a sparc64 system:
>
> bge0 at pci1 dev 1 function 0: Broadcom BCM5701 Gigabit Ethernet
> bge0: interrupting at ivec 0
> bge0: firmware handshake timed out, val = 4b657654
> bge0: ASIC BCM5701 B5 (0x0105), Ethernet address 00:0a:5e:1e:97:d5
> brgphy0 at bge0 phy 1: BCM5701 1000BASE-T media interface, rev. 0
>
> The timeout message appears every time the driver tries to talk to the
> card which therefore doesn't work. Is anybody using a 3Com 3C996B-T
> successfully which would make it a NetBSD-sparc64 problem?
>
Looks like interrupts are not delivered/processed correctly. I suspect
interrupt vector number was not determined correctly. It would be
interesting to look at firmware configuration (prtconf -pv) and complete
bootlog. Also DEBUG kernel might notify about 'spurious' interrupts and
has interrupt disgnostics so I'd use that one.
Andrey
Matthias Scheler
> Looks like interrupts are not delivered/processed correctly. I suspect
> interrupt vector number was not determined correctly. It would be
I can neither find that command under NetBSD nor is it recognized by
the OBP. Are you talking about the Solaris command?
> ... and complete bootlog.
Here it is:
NetBSD 2.0E (SHERIDAN) #0: Tue May 18 19:30:36 CEST 2004
tr...@lyssa.zhadum.de:/src/sys/compile/SHERIDAN
total memory = 1024 MB
avail memory = 993 MB
bootpath: /pci@1f,4000/scsi@3,0/disk@0,0
mainbus0 (root): SUNW,Ultra-60: hostid 80a929ed
cpu0 at mainbus0: SUNW,UltraSPARC-II @ 450.016 MHz, version 0 FPU
cpu0: 32K instruction (32 b/l), 16K data (32 b/l), 4096K external (64 b/l)
psycho0 at mainbus0 addr 0xfffb4000
SUNW,psycho: impl 0, version 4: ign 7c0 bus range 0 to 0; PCI bus 0
DVMA map: fe000000 to ffffe000
IOTSB: 819ba000 to 819c2000
pci0 at psycho0
pci0: i/o space, memory space enabled
ebus0 at pci0 dev 1 function 0
ebus0: Sun Microsystems, Inc. PCIO Ebus2, revision 0x01
auxio0 at ebus0 addr 726000-726003, 728000-728003, 72a000-72a003, 72c000-72c003, 72f000-72f003
power at ebus0 addr 724000-724003 not configured
SUNW,pll at ebus0 addr 504000-504002 not configured
sc at ebus0 addr 500000-500007 not configured
sab0 at ebus0 addr 400000-40007f ipl 43: rev 3.2
sabtty0 at sab0 port 0: console i/o
sabtty1 at sab0 port 1
com0 at ebus0 addr 3083f8-3083ff ipl 41: ns16550a, working fifo
kbd0 at com0
com1 at ebus0 addr 3062f8-3062ff ipl 42: ns16550a, working fifo
ms0 at com1
lpt0 at ebus0 addr 3043bc-3043cb, 300398-300399, 700000-70000f ipl 34
fdthree at ebus0 addr 3023f0-3023f7, 706000-70600f, 720000-720003 ipl 39 not configured
clock0 at ebus0 addr 0-1fff: mk48t59
flashprom at ebus0 addr 0-fffff not configured
audiocs0 at ebus0 addr 200000-2000ff, 702000-70200f, 704000-70400f, 722000-722003 ipl 35 ipl 36: CS4231A
audio0 at audiocs0: full duplex
hme0 at pci0 dev 1 function 1: Sun Happy Meal Ethernet, rev. 1
hme0: interrupting at ivec 3021
hme0: Ethernet address 08:00:20:a9:29:ed
qsphy0 at hme0 phy 1: QS6612 10/100 media interface, rev. 1
qsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
esiop0 at pci0 dev 3 function 0: Symbios Logic 53c875 (ultra-wide scsi)
esiop0: using on-board RAM
esiop0: interrupting at ivec 20
scsibus0 at esiop0: 16 targets, 8 luns per target
esiop1 at pci0 dev 3 function 1: Symbios Logic 53c875 (ultra-wide scsi)
esiop1: using on-board RAM
esiop1: interrupting at ivec 26
scsibus1 at esiop1: 16 targets, 8 luns per target
psycho1 at mainbus0 addr 0xfffc6000
SUNW,psycho: impl 0, version 4: ign 7c0 bus range 128 to 128; PCI bus 128
pci1 at psycho1
pci1: i/o space, memory space enabled
bge0 at pci1 dev 1 function 0: Broadcom BCM5701 Gigabit Ethernet
bge0: interrupting at ivec 0
bge0: firmware handshake timed out, val = 4b657654
bge0: ASIC BCM5701 B5 (0x0105), Ethernet address 00:0a:5e:1e:97:d5
brgphy0 at bge0 phy 1: BCM5701 1000BASE-T media interface, rev. 0
brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
timer0 at mainbus0 addr 0xfff9fc00 irq vectors 7ec and 7ed
SUNW,afb at mainbus0 addr 0xfebc0000 not configured
pcons at mainbus0 not configured
Kernelized RAIDframe activated
scsibus0: waiting 2 seconds for devices to settle...
scsibus1: waiting 2 seconds for devices to settle...
sd0 at scsibus0 target 0 lun 0: <FUJITSU, MAA3182SCX, 2411> disk fixed
sd0: 17482 MB, 9041 cyl, 19 head, 208 sec, 512 bytes/sect x 35803490 sectors
sd0: sync (50.00ns offset 16), 16-bit (40.000MB/s) transfers, tagged queueing
sd1 at scsibus0 target 1 lun 0: <FUJITSU, MAA3182SC, 2411> disk fixed
sd1: 17267 MB, 9041 cyl, 19 head, 204 sec, 516 bytes/sect x 35090420 sectors
sd1: sync (50.00ns offset 16), 16-bit (40.000MB/s) transfers, tagged queueing
sd1: no disk label
root on sd0a dumps on sd0b
root file system type: ffs
Andrey Petrov
> On Tue, May 18, 2004 at 11:39:46AM -0700, Andrey Petrov wrote:
> > Looks like interrupts are not delivered/processed correctly. I suspect
> > interrupt vector number was not determined correctly. It would be
> > interesting to look at firmware configuration (prtconf -pv) ...
>
> I can neither find that command under NetBSD nor is it recognized by
> the OBP. Are you talking about the Solaris command?
Yes, that's for solaris. For netbsd: grab
ftp://ftp.netbsd.org/pub/incoming/matt/ofdump.c and then compile
and run it as ofdump -l and post the output.
Andrey
Allen Briggs
> > I'm trying to use a 3Com 3C996B-T with NetBSD 2.0E on a sparc64 system:
> >
> > bge0 at pci1 dev 1 function 0: Broadcom BCM5701 Gigabit Ethernet
> > bge0: interrupting at ivec 0
> > bge0: firmware handshake timed out, val = 4b657654
> > bge0: ASIC BCM5701 B5 (0x0105), Ethernet address 00:0a:5e:1e:97:d5
> > brgphy0 at bge0 phy 1: BCM5701 1000BASE-T media interface, rev. 0
> >
> > The timeout message appears every time the driver tries to talk to the
> > card which therefore doesn't work. Is anybody using a 3Com 3C996B-T
> > successfully which would make it a NetBSD-sparc64 problem?
>
> Looks like interrupts are not delivered/processed correctly.
I think there's a bit more going on. I'm pretty sure that fvdl
had earlier versions of bge working on sparc64. I have had problems
(perhaps the same) with a similar (perhaps the same) card on XScale.
I started looking into them, but didn't get very far. At the time,
I was thinking that it was a memory/cache coherency problem, but
I didn't get as far as confirming that.
In my case, it was really looking like the card just wasn't responsive
to much at all.
-allen
--
Allen Briggs bri...@wasabisystems.com
Wasabi Systems, Inc. http://www.wasabisystems.com/
Matthias Scheler
Andrey Petrov <pet...@NetBSD.org> writes:
> ... run it as ofdump -l and post the output.
[Caching 40 nodes and 356 properties]
f0029970: /SUNW,Ultra-60
f002cbb4: /packages
f0033d38: /terminal-emulator
f0036a74: /deblocker
f0037150: /obp-tftp
f0041f10: /disk-label
f005b764: /SUNW,builtin-drivers
f006923c: /sun-keyboard
f002cc24: /chosen
f002cc90: /openprom
f002cd20: /client-services
f002cdc8: /options
f002ce38: /aliases
f004ca84: /memory@0,80000000
f004d064: /virtual-memory
f005fd74: /pci@1f,4000
f00614f4: /ebus@1
f0061a30: /auxio@14,726000
f0061af0: /power@14,724000
f0061b80: /SUNW,pll@14,504000
f0061c14: /sc@14,500000
f0061cc8: /se@14,400000
f00635f8: /su@14,3083f8
f0064e58: /su@14,3062f8
f0064f74: /ecpp@14,3043bc
f0065074: /fdthree@14,3023f0
f0066b58: /eeprom@14,0
f0066c40: /flashprom@10,0
f006db3c: /SUNW,CS4231@14,200000
f007756c: /network@1,1
f007ed34: /scsi@3
f0082b18: /disk
f00836dc: /tape
f0084408: /scsi@3,1
f00881ec: /disk
f0088db0: /tape
f00605f0: /pci@1f,2000
f0089c50: /ethernet@1
f00611fc: /counter-timer@1f,1c00
f006d538: /SUNW,UltraSPARC-II@1c,0
f006e14c: /SUNW,afb@1f,0
And here is some output of "obdump -p":
[Caching 40 nodes and 356 properties]
f0029970: /SUNW,Ultra-60
energystar-v2
idprom 01800800 20a929ed 00000000 a929eda9 .... .)......)..
0010: 00000000 00000000 00000000 00000000 ................
reset-reason 532d504f 5200.... ........ ........ S-POR.
interrupt-map 0000003c 00000000 00000000 f005fd74 ...<...........t
0010: 80000033 0000003a 00000000 00000000 ...3...:........
0020: f005fd74 80000034 ........ ........ ...t...4
interrupt-map-mask 0000003e 00000000 00000000 ........ ...>........
#interrupt-cells 00000001 ........ ........ ........ 1
#address-cells 00000002 ........ ........ ........ 2
breakpoint-trap 0000007f ........ ........ ........ ....
#size-cells 00000002 ........ ........ ........ 2
model 53554e57 2c353031 2d343435 3000.... "SUNW,501-4450"
name 53554e57 2c556c74 72612d36 3000.... "SUNW,Ultra-60"
clock-frequency 06b4b0fa ........ ........ ........ 112.505MHz
banner-name 53756e20 556c7472 61203630 20555041 Sun Ultra 60 UPA
0010: 2f504349 2028556c 74726153 50415243 /PCI (UltraSPARC
0020: 2d494920 3435304d 487a2900 ........ -II 450MHz).
device_type 75706100 ........ ........ ........ "upa"
[...]
--------------------------------------------------------------------------------
f0089c50: /pci@1f,2000/ethernet@1
assigned-addresses 83800810 00000000 00100000 00000000 ................
0010: 00010000 82800830 00000000 00110000 .......0........
0020: 00000000 00010000 ........ ........ ........
power-consumption 00000000 007270e0 ........ ........ .....rp.
reg 00800800 00000000 00000000 00000000 ................
0010: 00000000 03800810 00000000 00000000 ................
0020: 00000000 00010000 02800830 00000000 ...........0....
0030: 00000000 00000000 00010000 ........ ............
compatible 70636931 3465342c 31363435 2e313062 "pci14e4,1645.10b
0010: 372e3130 30362e31 3500.... ........ 7.1006.15"
001a: 70636931 3465342c 31363435 2e313062 "pci14e4,1645.10b
002a: 372e3130 303600.. ........ ........ 7.1006"
0031: 70636931 3062372c 31303036 00...... "pci10b7,1006"
003e: 70636931 3465342c 31363435 2e313500 "pci14e4,1645.15"
004e: 70636931 3465342c 31363435 00...... "pci14e4,1645"
005b: 70636963 6c617373 2c303230 30303000 "pciclass,020000"
006b: 70636963 6c617373 2c303230 3000.... "pciclass,0200"
name 65746865 726e6574 00...... ........ "ethernet"
66mhz-capable
fast-back-to-back
devsel-speed 00000001 ........ ........ ........ ....
class-code 00020000 ........ ........ ........ ....
interrupts 00000001 ........ ........ ........ ....
max-latency 00000000 ........ ........ ........ ....
min-grant 00000040 ........ ........ ........ ...@
subsystem-vendor-id 000010b7 ........ ........ ........ ....
subsystem-id 00001006 ........ ........ ........ ....
revision-id 00000015 ........ ........ ........ ....
device-id 00001645 ........ ........ ........ ...E
vendor-id 000014e4 ........ ........ ........ ....
Matthias Scheler
Allen Briggs <bri...@wasabisystems.com> writes:
> In my case, it was really looking like the card just wasn't responsive
> to much at all.
So it was broken? Was that a 3Com 3C996B-T or another BCM 570x based card?
Allen Briggs
> So it was broken? Was that a 3Com 3C996B-T or another BCM 570x based card?
I think it was a 3Com 3C996B-T -- BCM 5701-based. I have it around
here somewhere. Worked in x86, failed on an XScale. It just never
seemed to get any interrupts, if I recall correctly. A lot of the
initialization is done by writing to the card, so it was hard to
see how much of that was actually working. I think I could assign
an address to the card, but it would soon start getting timeouts,
fail to stop properly, and just be pretty hosed. As I recall, I
put some code to printf() to the console in the interrupt routine
and never saw those. I also seem to recall that calling the
interrupt routine from the timeout was not fruitful, either, but
I'm not so sure about that anymore. It's been a while since I
played with it.
Andrey Petrov
> On Tue, May 18, 2004 at 07:29:33PM +0000, Matthias Scheler wrote:
> > So it was broken? Was that a 3Com 3C996B-T or another BCM 570x based card?
>
> I think it was a 3Com 3C996B-T -- BCM 5701-based. I have it around
> here somewhere. Worked in x86, failed on an XScale. It just never
> seemed to get any interrupts, if I recall correctly. A lot of the
> initialization is done by writing to the card, so it was hard to
> see how much of that was actually working. I think I could assign
> an address to the card, but it would soon start getting timeouts,
> fail to stop properly, and just be pretty hosed. As I recall, I
> put some code to printf() to the console in the interrupt routine
> and never saw those. I also seem to recall that calling the
> interrupt routine from the timeout was not fruitful, either, but
> I'm not so sure about that anymore. It's been a while since I
> played with it.
>
In any case I'd start checking if interrupt routing set properly,
adding printf to card's interrupt handler and MD interrupt receiving
routine it shouldn't be hard to find out.
With Matthias' dmesg 'ivec 0' doesn't look right, I'll look why so,
but it'll take some time as I don't have card.
Andrey
Matthias Scheler
Allen Briggs <bri...@wasabisystems.com> writes:
> On Tue, May 18, 2004 at 07:29:33PM +0000, Matthias Scheler wrote:
>> So it was broken? Was that a 3Com 3C996B-T or another BCM 570x based card?
> I think it was a 3Com 3C996B-T -- BCM 5701-based. I have it around
> here somewhere. Worked in x86, failed on an XScale. It just never
> seemed to get any interrupts, if I recall correctly.
I wonder if the PXE boot ROM on the card which of course only works on
a x86 system does performs initialization which our driver doesn't.
Allen Briggs
> I wonder if the PXE boot ROM on the card which of course only works on
> a x86 system does performs initialization which our driver doesn't.
Possible, but I am pretty sure that it was successfully used on
non-x86 (sparc64) when it was first ported to NetBSD.
Andrey Petrov
Quick google search didn't uncover anything.
Andrey