Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 5 Dec 2002 10:42:06 +0100
From:      "Oliver Blasnik" <oliver.blasnik@de.tiscali.com>
To:        "Jake Burkholder" <jake@locore.ca>
Cc:        <freebsd-sparc@FreeBSD.ORG>
Subject:   Re: pci quad hme ethernet card
Message-ID:  <005b01c29c42$93cc75a0$2100a8c0@xpath1000>
References:  <20021203124613.L35729@locore.ca> <010d01c29b74$65d3b4c0$2100a8c0@xpath1000> <20021204140045.S35729@locore.ca>

next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.

------=_NextPart_000_0058_01C29C4A.F4EED140
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Jake,

[PCI QFE]
> > > and let us know if it works for you.

> Hmm.  Yes its a similar patch with some other changes.  The netra is a
> very quirky box, so it may be that additional hacks are required.  Please
> send dmesg output if you have any problems.

Still doesn't work. As you see in the dmsg, each of the hme on this qfe
gets the same irq assigned (which is "1" now instead "0", because of the
codechange "+1"?). But thats it, looks as no routing through the bridge
("hme0: device timeout" after configure). Because of this I think the
atapci0 won't work, too, but it's nothing connected to it so theres no
chance to check it out. Taking a deeper look, atapci0 gets irq 0 assigned
after the last changes...

[PCI func>0]
> I've had conflicting reports as to wether this actually works.  We've
> tried a hack in the MD code to deal with the missing function 0, but
> appparently there are still phy problems that stop the interface from
> working. 

Did it? It does work for me, thats interesting. The only thing I
was wondering about was that double-phy on hme0, but its because there is
an onboard-rj45 connector avail on the _mainboard_, and this one isn't the
one you connect the cables to ;)

I'd recommend to switch pci bus detection / device assignment to another
scheme on sparc systems - as other ppl on the list also don't get it that
the "real hme0" gets assigned to "hme4" like in my case after adding a
additional card. It breaks connectivity and possibly hardwired rules.

> we can't really do this so late in the release cycle without a good 
> idea of how it affects other platforms.

Sure. As it only effects this one board of the Sun products, is there
an unique identifier (chipset?) to base a quirk of?

> Jake

Oliver

------=_NextPart_000_0058_01C29C4A.F4EED140
Content-Type: text/plain;
	name="demsg-netra-t1-qfe.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="demsg-netra-t1-qfe.txt"

Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights =
reserved.
FreeBSD 5.0-CURRENT #3: Wed Dec  4 20:12:57 CET 2002
    root@free64.de.tiscali.com:/usr/src/sys/sparc64/compile/S64NEW
Preloaded elf kernel "/boot/kernel/kernel" at 0xc0390000.
Timecounter "tick"  frequency 440016734 Hz
cpu0: Sun Microsystems UltraSparc-IIi Processor (440.02 MHz CPU)
Model: SUNW,UltraSPARC-IIi-cEngine
Initializing GEOMetry subsystem
nexus0: <OpenFirmware Nexus device>
pcib0: <U2P UPA-PCI bridge> on nexus0
pcib0: Sabre, impl 0, version 0, ign 7c0 DVMA map: 0xc0000000 to =
0xdfffffff
pci0: <PCI bus> on pcib0
pcib1: <APB PCI-PCI bridge> at device 1.0 on pci0
pci1: <PCI bus> on pcib1
pcib2: <PCI-PCI bridge> at device 1.0 on pci1
pci3: <PCI bus> on pcib2
atapci0: <CMD 646 ATA controller> port =
0x1020-0x102f,0x1018-0x101b,0x1010-0x1017,0x1008-0x100b,0x1000-0x1007 =
irq 0 at device 14.0 on pci3
ata2: at 0x1000 on atapci0
ata3: at 0x1010 on atapci0
pcib3: <PCI-PCI bridge> at device 15.0 on pci3
pci4: <PCI bus> on pcib3
pci4: <bridge, PCI-unknown> at device 0.0 (no driver attached)
hme0: <Sun HME 10/100 Ethernet> mem 0x2800000-0x2807fff irq 1 at device =
0.1 on pci4
hme0: Ethernet address: 08:00:20:da:36:4e
miibus0: <MII bus> on hme0
ukphy0: <Generic IEEE 802.3u media interface> on miibus0
ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
pci4: <bridge, PCI-unknown> at device 1.0 (no driver attached)
hme1: <Sun HME 10/100 Ethernet> mem 0x4800000-0x4807fff irq 1 at device =
1.1 on pci4
hme1: Ethernet address: 08:00:20:da:36:4e
miibus1: <MII bus> on hme1
ukphy1: <Generic IEEE 802.3u media interface> on miibus1
ukphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
pci4: <bridge, PCI-unknown> at device 2.0 (no driver attached)
hme2: <Sun HME 10/100 Ethernet> mem 0x6800000-0x6807fff irq 1 at device =
2.1 on pci4
hme2: Ethernet address: 08:00:20:da:36:4e
miibus2: <MII bus> on hme2
ukphy2: <Generic IEEE 802.3u media interface> on miibus2
ukphy2:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
pci4: <bridge, PCI-unknown> at device 3.0 (no driver attached)
hme3: <Sun HME 10/100 Ethernet> mem 0x8800000-0x8807fff irq 1 at device =
3.1 on pci4
hme3: Ethernet address: 08:00:20:da:36:4e
miibus3: <MII bus> on hme3
ukphy3: <Generic IEEE 802.3u media interface> on miibus3
ukphy3:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
pcib4: <APB PCI-PCI bridge> at device 1.1 on pci0
pci2: <PCI bus> on pcib4
ebus0: revision 0x01
ebus0: <PCI-EBus2 bridge> mem =
0xf1000000-0xf17fffff,0xf0000000-0xf0ffffff at device 1.0 on pci2
ebus0: <auxio> addr =
0x140072f000-0x140072f003,0x140072c000-0x140072c003,0x140072a000-0x140072=
a003,0x1400728000-0x1400728003,0x
1400726000-0x1400726003 (no driver attached)
ebus0: <power> addr 0x1400724000-0x1400724003 irq 37 (no driver =
attached)
ebus0: <SUNW,pll> addr 0x1400504000-0x1400504002 (no driver attached)
ebus0: <su> addr 0x14003803f8-0x14003803ff irq 28 (no driver attached)
ebus0: <su> addr 0x14003602f8-0x14003602ff irq 20 (no driver attached)
ebus0: <ecpp> addr =
0x1400700000-0x140070000f,0x140030015c-0x140030015d,0x1400340278-0x140034=
0287 irq 34 (no driver attached)
ebus0: <fdthree> addr =
0x1400720000-0x1400720003,0x1400706000-0x140070600f,0x14003203f0-0x140032=
03f7 irq 39 (no driver attached)
eeprom0: <EBus EEPROM/clock> addr 0x1400000000-0x1400001fff on ebus0
eeprom0: model mk48t59
eeprom0: hostid 80da364e
ebus0: <flashprom> addr 0x1000000000-0x10000fffff (no driver attached)
ebus0: <watchdog> addr 0x1400200000-0x140020003f irq 4 (no driver =
attached)
ebus0: <display7seg> addr 0x1400200040 (no driver attached)
ebus0: <beeper> addr 0x1400722000-0x1400722003 (no driver attached)
ebus0: <flashprom> addr 0x1000400000-0x10005fffff (no driver attached)
ebus0: <flashprom> addr 0x1000800000-0x10009fffff (no driver attached)
ebus0: <i2c> addr 0x1400600000-0x1400600003 irq 40 (no driver attached)
ebus0: <i2c> addr 0x1400100000-0x1400100003 irq 27 (no driver attached)
ebus0: <SUNW,lom> addr 0x1400400000-0x1400400063 (no driver attached)
hme4: <Sun HME 10/100 Ethernet> mem 0xe0000000-0xe0007fff irq 33 at =
device 1.1 on pci2
hme4: Ethernet address: 08:00:20:da:36:4e
miibus4: <MII bus> on hme4
ukphy4: <Generic IEEE 802.3u media interface> on miibus4
ukphy4:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy5: <Generic IEEE 802.3u media interface> on miibus4
ukphy5:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
sym0: <875> port 0xc00000-0xc000ff mem =
0xe000a000-0xe000afff,0xe0008000-0xe00080ff irq 32 at device 2.0 on pci2
sym0: No NVRAM, ID 7, Fast-20, SE, parity checking
hme5: <Sun HME 10/100 Ethernet> mem 0xe0010000-0xe0017fff irq 26 at =
device 3.1 on pci2
hme5: Ethernet address: 08:00:20:da:36:4e
miibus5: <MII bus> on hme5
ukphy6: <Generic IEEE 802.3u media interface> on miibus5
ukphy6:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
Timecounters tick every 10.000 msec
Waiting 2 seconds for SCSI devices to settle
da0 at sym0 bus 0 target 0 lun 0
da0: <SEAGATE ST318404LSUN18G 4207> Fixed Direct Access SCSI-3 device=20
da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing =
Enabled
da0: 17274MB (35378533 512 byte sectors: 255H 63S/T 2202C)
da1 at sym0 bus 0 target 1 lun 0
da1: <SEAGATE ST318203LSUN18G 034A> Fixed Direct Access SCSI-2 device=20
da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing =
Enabled
da1: 17274MB (35378533 512 byte sectors: 255H 63S/T 2202C)
Mounting root from ufs:/dev/da0a


------=_NextPart_000_0058_01C29C4A.F4EED140--


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-sparc" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?005b01c29c42$93cc75a0$2100a8c0>