Subject: Re: tlp(4) is unable to detect phy.
To: None <tech-kern@NetBSD.org>
From: Jochen Kunz <firstname.lastname@example.org>
Date: 07/19/2004 10:50:55
On Mon, 19 Jul 2004 00:07:58 -0700
Matt Thomas <email@example.com> wrote:
> On Jul 18, 2004, at 3:07 PM, Charles M. Hannum wrote:
> > It looks like the FreeBSD dc driver (which OpenBSD copied) always
> > calls mii_attach(), so the fact that the SROM contents are bogus
> > doesn't matter.
> > Does the following patch help?
Yes, this did it. See below. The machine is now booting via the build in
tlp(4). I sugest you commit this. tlp(4) attaches even when it finds no
phy, leading to dereferencing a NULL pointer and thus a kernel panic
later when the interface is brought up. Quite unkind. With this patch it
only can get better.
Thanks for your help.
> Probably not, since OpenBSD reporting that the internal phy is
> being using. In short, there is *no* phy to find.
Looks like you confused the output from the DE500 PCI card (PCI dev 2)
with the on board DECchip 21143 (PCI dev 20). The on board tlp(4) has a
Level One LXT970. I know this for sure because I saw the LXT970 chip on
the CPU board. :-)
dino0 at phantomas0 hpa 0xfff80000 path 8/0 irq 28 ipl 1: Dino V3.1
pci0 at dino0
pci0: i/o space, memory space enabled
tlp0 at pci0 dev 2 function 0: DECchip 21143 Ethernet, pass 3.0
tlp0: interrupting at irq 3
tlp0: DEC DE500-BA, Ethernet address 08:00:2b:c4:0c:19
tlp0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
esiop0 at pci0 dev 19 function 0: Symbios Logic 53c875 (ultra-wide scsi)
esiop0: using on-board RAM
esiop0: interrupting at irq 4
scsibus0 at esiop0: 16 targets, 8 luns per target
tlp1 at pci0 dev 20 function 0: DECchip 21143 Ethernet, pass 4.1
tlp1: interrupting at irq 1
tlp1: Ethernet address 00:10:83:03:fd:7a
lxtphy0 at tlp1 phy 1: LXT970 10/100 media interface, rev. 1
lxtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
lasi0 at phantomas0 hpa 0xffc00000 path 8/16 irq 27: rev 3.0