NetBSD Problem Report #33073
From www@netbsd.org Mon Mar 13 22:20:12 2006
Return-Path: <www@netbsd.org>
Received: by narn.netbsd.org (Postfix, from userid 31301)
id 3E32363B863; Mon, 13 Mar 2006 22:20:12 +0000 (UTC)
Message-Id: <20060313222012.3E32363B863@narn.netbsd.org>
Date: Mon, 13 Mar 2006 22:20:12 +0000 (UTC)
From: michael@moria.de
Reply-To: michael@moria.de
To: gnats-bugs@netbsd.org
Subject: isp0: unable to load dma (22)
X-Send-Pr-Version: www-1.0
>Number: 33073
>Category: port-alpha
>Synopsis: isp0: unable to load dma (22)
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: thorpej
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Mon Mar 13 22:25:00 +0000 2006
>Closed-Date: Sun Jul 18 19:36:16 +0000 2021
>Last-Modified: Fri Jul 23 21:40:01 +0000 2021
>Originator: Michael Haardt
>Release: 3.0
>Organization:
>Environment:
A PWS 500au with two SCSI disks, one IDE CDROM, 1,5 GB RAM and a Matrox video card.
>Description:
Trying to boot the machine diskless loads the kernel, it starts recognizing devices, but then says:
isp0: unable to load dma (22)
sysinst starts, but I can not access any disks, thus being unable to install the system.
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback
State-Changed-By: tnn@NetBSD.org
State-Changed-When: Sun, 18 Jul 2021 14:23:59 +0000
State-Changed-Why:
Do you still have this machine and could you try to pull some of the RAM so it has less than 1 GB?
Responsible-Changed-From-To: port-alpha-maintainer->thorpej
Responsible-Changed-By: thorpej@NetBSD.org
Responsible-Changed-When: Sun, 18 Jul 2021 19:33:08 +0000
Responsible-Changed-Why:
Take.
State-Changed-From-To: feedback->closed
State-Changed-By: thorpej@NetBSD.org
State-Changed-When: Sun, 18 Jul 2021 19:36:16 +0000
State-Changed-Why:
This would have been significantly mitigated by:
----------------------------
revision 1.21
date: 2007-03-13 18:40:14 -0700; author: mhitch; state: Exp; lines: +9 -3;
branches: 1.21.36; 1.21.38; 1.21.40;
Contrary to the comment in cia_dma_get_tag(), there are machines with cia
that have over 1.0G. Allow direct dma requests to fall back to SGMAPs.
my PWS 500au with 1.5G of memory now works with dma operations.
----------------------------
...but a more comprehensive fix was made in:
----------------------------
revision 1.35
date: 2021-07-16 17:30:39 -0700; author: thorpej; state: Exp; lines: +92 -30; commitid: hTyTdpdUfhyl2h1D;
Back in rev 1.21, mhitch@ fixed an issue with his 1.5GB RAM PWS 500au
by using a fall-back to the ISA DMA window if DMA was out of range for
the 1G @ 1G PCI DMA window. Alas, the ISA DMA window is pretty small
(8M @ 8M), and it's possible to starve it with PCI devices that might
have, for example, large control data structures there.
So, instead, if the system has more than 1G of RAM, use Window 3
(previously unused) as a SGMAP window 1G @ 3G, and set that as the
fall-back if the direct-mapped window fails.
----------------------------
...of alpha/pci/cia_dma.c
From: Michael Haardt <michael@moria.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-alpha/33073 (isp0: unable to load dma (22))
Date: Mon, 19 Jul 2021 22:05:25 +0200
tnn@NetBSD.org wrote:
> Synopsis: isp0: unable to load dma (22)
>
> State-Changed-From-To: open->feedback
> State-Changed-By: tnn@NetBSD.org
> State-Changed-When: Sun, 18 Jul 2021 14:23:59 +0000
> State-Changed-Why:
> Do you still have this machine and could you try to pull some of the RAM so it has less than 1 GB?
I believe I still have this machine, but I need to check if it
still works and setup NetBSD for it. Give me a few days.
Michael
From: Michael Haardt <michael@moria.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-alpha/33073 (isp0: unable to load dma (22))
Date: Tue, 20 Jul 2021 23:09:57 +0200
thorpej@NetBSD.org wrote:
> Synopsis: isp0: unable to load dma (22)
>
> State-Changed-From-To: feedback->closed
> State-Changed-By: thorpej@NetBSD.org
> State-Changed-When: Sun, 18 Jul 2021 19:36:16 +0000
> State-Changed-Why:
> This would have been significantly mitigated by:
>
> ----------------------------
> revision 1.21
> date: 2007-03-13 18:40:14 -0700; author: mhitch; state: Exp; lines: +9 -3;
> branches: 1.21.36; 1.21.38; 1.21.40;
> Contrary to the comment in cia_dma_get_tag(), there are machines with cia
> that have over 1.0G. Allow direct dma requests to fall back to SGMAPs.
> my PWS 500au with 1.5G of memory now works with dma operations.
> ----------------------------
I have my PWS 500au running again and tried to install NetBSD 9.2 booting
from NFS. I could access the disk, label it, make a filesystem and unpack
some sets, but in the middle of doing so this happened (serial console):
Status: Running
Command: progress -zf /mnt2//base.tgz tar --chroot -xpf -
--------------------------------------------------------------------------------
[ 164.4571095] isp0: unable to load DMA (35)orrectable error.
[ 164.5127761] sd0(isp0:0:0:0): adapter resource shortageror.
[ 165.5752672] isp0: unable to load DMA (35)orrectable error.
[ 165.6216871] sd0(isp0:0:0:0): adapter resource shortageror.
[ 161.5229999] Warning: received processor correctable error.
[ 161.5885140] Warning: received processor correctable error.
[ 161.6540279] Warning: received processor correctable error.
[ 161.7195428] Warning: received processor correctable error.
> ...but a more comprehensive fix was made in:
>
> ----------------------------
> revision 1.35
> date: 2021-07-16 17:30:39 -0700; author: thorpej; state: Exp; lines: +92 -30; commitid: hTyTdpdUfhyl2h1D;
> Back in rev 1.21, mhitch@ fixed an issue with his 1.5GB RAM PWS 500au
> by using a fall-back to the ISA DMA window if DMA was out of range for
> the 1G @ 1G PCI DMA window. Alas, the ISA DMA window is pretty small
> (8M @ 8M), and it's possible to starve it with PCI devices that might
> have, for example, large control data structures there.
>
> So, instead, if the system has more than 1G of RAM, use Window 3
> (previously unused) as a SGMAP window 1G @ 3G, and set that as the
> fall-back if the direct-mapped window fails.
> ----------------------------
>
> ...of alpha/pci/cia_dma.c
Should I still try removing 512 MB from the machine to see if it works
fine with 1 GB? Given the date, I guess this change is not yet in 9.2.
Is there a newer instkernel to try that includes this change?
Michael
From: Jason Thorpe <thorpej@me.com>
To: gnats-bugs@netbsd.org
Cc: Jason Thorpe <thorpej@netbsd.org>,
gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org,
michael@moria.de
Subject: Re: port-alpha/33073 (isp0: unable to load dma (22))
Date: Tue, 20 Jul 2021 19:41:40 -0700
> On Jul 20, 2021, at 2:15 PM, Michael Haardt <michael@moria.de> wrote:
>=20
> Should I still try removing 512 MB from the machine to see if it works
> fine with 1 GB? Given the date, I guess this change is not yet in 9.2.
> Is there a newer instkernel to try that includes this change?
Yah, no need to remove memory -- problem pretty well understood.
Looks like the instkernel here will have the change:
=
http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/202107200810Z/alpha/installa=
tion/instkernel/
-- thorpej
From: Jason Thorpe <thorpej@me.com>
To: gnats-bugs@netbsd.org
Cc: Jason Thorpe <thorpej@netbsd.org>,
gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org,
michael@moria.de
Subject: Re: port-alpha/33073 (isp0: unable to load dma (22))
Date: Tue, 20 Jul 2021 19:42:41 -0700
> On Jul 20, 2021, at 2:15 PM, Michael Haardt <michael@moria.de> wrote:
>=20
> Should I still try removing 512 MB from the machine to see if it works
> fine with 1 GB? Given the date, I guess this change is not yet in 9.2.
> Is there a newer instkernel to try that includes this change?
FWIW, unlikely that I'll be back-porting any of these changes to 9.2... =
there have been significant changes to the alpha port since 9.x.
-- thorpej
From: Michael Haardt <michael@moria.de>
To: Jason Thorpe <thorpej@me.com>
Cc: gnats-bugs@netbsd.org, Jason Thorpe <thorpej@netbsd.org>,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: port-alpha/33073 (isp0: unable to load dma (22))
Date: Wed, 21 Jul 2021 20:14:50 +0200
> Looks like the instkernel here will have the change:
>
> http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/202107200810Z/alpha/installation/instkernel/
Thanks, I booted that and installed NetBSD. With 9.2, ethernet media
auto selection worked. With HEAD it no longer does:
[ 337.1011682] tlp0: transmit timeout
# ifconfig tlp0
tlp0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ec_capabilities=0x1<VLAN_MTU>
ec_enabled=0
address: 00:00:f8:76:0e:39
media: Ethernet autoselect instance 1 (none)
inet 10.128.0.15/8 broadcast 10.255.255.255 flags 0
Manually configuring it helps:
# ifconfig tlp0 media 100baseTX-FDX
# ifconfig tlp0
tlp0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ec_capabilities=0x1<VLAN_MTU>
ec_enabled=0
address: 00:00:f8:76:0e:39
media: Ethernet 100baseTX full-duplex instance 1
status: active
inet 10.128.0.15/8 broadcast 10.255.255.255 flags 0x1<TENTATIVE>
I see nothing odd during booting, but wonder if "auto" should have been
propagated from nsphy0 to tlp0:
[ 1.0000000] cia0 at mainbus0: DECchip 2117x Core Logic Chipset (Pyxis), pass 2
[ 1.0000000] cia0: extended capabilities: 0x1<BWEN>
[ 1.0000000] cia0: using BWX for PCI config access
[ 1.0000000] pci0 at cia0 bus 0
[ 1.0000000] pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
[ 1.0000000] tlp0 at pci0 dev 3 function 0: DECchip 21143 Ethernet, pass 3.0
[ 1.0000000] tlp0: interrupting at dec 550 irq 0
[ 1.0000000] tlp0: DEC, Ethernet address 00:00:f8:76:0e:39
[ 1.0000000] nsphy0 at tlp0 phy 5: DP83840 10/100 media interface, rev. 1
[ 1.0000000] nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
[ 1.0000000] tlp0: 10baseT, 10baseT-FDX, 10base2, 10base5
The speed during unpacking the sets is only around 250-300 KiB/s.
My switch says:
Pkts64Octets 550
Pkts65to127Octets 43,441
Pkts128to255Octets 126,463 <-- only small packets?
Pkts256to511Octets 49
Pkts512to1023Octets 32
Pkts1024to1518Octets 0
During unpacking, I see a flood of "Warning: received processor
correctable error." Is there any additional information which component
of the system may be causing that?
Anyway: The DMA problems are gone and unpacking the sets to the disk
finishes. I guess none of the above is related to port-alpha/33073,
but I wanted to mention it nevertheless. Thanks for fixing this one!
Michael
From: Jason Thorpe <thorpej@me.com>
To: Michael Haardt <michael@moria.de>
Cc: gnats-bugs@netbsd.org,
Jason Thorpe <thorpej@netbsd.org>,
gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: port-alpha/33073 (isp0: unable to load dma (22))
Date: Wed, 21 Jul 2021 11:27:09 -0700
> On Jul 21, 2021, at 11:14 AM, Michael Haardt <michael@moria.de> wrote:
>=20
> I see nothing odd during booting, but wonder if "auto" should have =
been
> propagated from nsphy0 to tlp0:
>=20
> [ 1.0000000] cia0 at mainbus0: DECchip 2117x Core Logic Chipset =
(Pyxis), pass 2
> [ 1.0000000] cia0: extended capabilities: 0x1<BWEN>
> [ 1.0000000] cia0: using BWX for PCI config access
> [ 1.0000000] pci0 at cia0 bus 0
> [ 1.0000000] pci0: i/o space, memory space enabled, rd/line, =
rd/mult, wr/inv ok
> [ 1.0000000] tlp0 at pci0 dev 3 function 0: DECchip 21143 Ethernet, =
pass 3.0
> [ 1.0000000] tlp0: interrupting at dec 550 irq 0
> [ 1.0000000] tlp0: DEC, Ethernet address 00:00:f8:76:0e:39
> [ 1.0000000] nsphy0 at tlp0 phy 5: DP83840 10/100 media interface, =
rev. 1
> [ 1.0000000] nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, =
auto
> [ 1.0000000] tlp0: 10baseT, 10baseT-FDX, 10base2, 10base5
Huh... can you provide the tlp-related boot messages from 9.2 as well? =
This bug is almost certainly my fault, but seeing the previous output =
would be helpful in figuring out how I broke it :-)
If you could gather that up and then file a new bug report for the tlp =
issue, I would really appreciate it!
> During unpacking, I see a flood of "Warning: received processor
> correctable error." Is there any additional information which =
component
> of the system may be causing that?
I guess this is probably due to a flaky memory module. We would need to =
decode the machine check logout frame. I'll investigate this.
> Anyway: The DMA problems are gone and unpacking the sets to the disk
> finishes. I guess none of the above is related to port-alpha/33073,
> but I wanted to mention it nevertheless. Thanks for fixing this one!
Ok, good news, thanks for confirming!
-- thorpej
From: Tobias Nygren <tnn@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-alpha/33073 (isp0: unable to load dma (22))
Date: Wed, 21 Jul 2021 20:56:37 +0200
FWIW autonegotiation works fine in -current on a similar Tulip on
PC164SX. It uses the same phy; the only difference I can see is:
-DECchip 21143 Ethernet, pass 3.0
+DECchip 21140A Ethernet, pass 2.2
cia0 at mainbus0: DECchip 2117x Core Logic Chipset (Pyxis), pass 2
cia0: extended capabilities: 0x1<BWEN>
cia0: using BWX for PCI config access
pci0 at cia0 bus 0
pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
tlp0 at pci0 dev 6 function 0: DECchip 21140A Ethernet, pass 2.2
tlp0: interrupting at eb164 irq 11
tlp0: DEC DE500-AA, Ethernet address 00:00:f8:1a:4c:02
nsphy0 at tlp0 phy 5: DP83840 10/100 media interface, rev. 0
nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
tlp0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ec_capabilities=0x1<VLAN_MTU>
ec_enabled=0
address: 00:00:f8:1a:4c:02
media: Ethernet autoselect (100baseTX full-duplex)
status: active
From: Jason Thorpe <thorpej@me.com>
To: gnats-bugs@netbsd.org
Cc: Jason Thorpe <thorpej@netbsd.org>,
gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org,
michael@moria.de
Subject: Re: port-alpha/33073 (isp0: unable to load dma (22))
Date: Wed, 21 Jul 2021 12:17:38 -0700
> On Jul 21, 2021, at 12:00 PM, Tobias Nygren <tnn@netbsd.org> wrote:
>=20
> The following reply was made to PR port-alpha/33073; it has been noted =
by GNATS.
>=20
> From: Tobias Nygren <tnn@NetBSD.org>
> To: gnats-bugs@netbsd.org
> Cc:=20
> Subject: Re: port-alpha/33073 (isp0: unable to load dma (22))
> Date: Wed, 21 Jul 2021 20:56:37 +0200
>=20
> FWIW autonegotiation works fine in -current on a similar Tulip on
> PC164SX. It uses the same phy; the only difference I can see is:
> -DECchip 21143 Ethernet, pass 3.0
> +DECchip 21140A Ethernet, pass 2.2
Yah, the media handling is a little different on the 21143 vs 21140. =
(Actually the media handling can be bonkers on all of the DEC Tulip =
variants, and I'm still in therapy for it all these years later...)
> cia0 at mainbus0: DECchip 2117x Core Logic Chipset (Pyxis), pass 2
> cia0: extended capabilities: 0x1<BWEN>
> cia0: using BWX for PCI config access
> pci0 at cia0 bus 0
> pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
> tlp0 at pci0 dev 6 function 0: DECchip 21140A Ethernet, pass 2.2
> tlp0: interrupting at eb164 irq 11
> tlp0: DEC DE500-AA, Ethernet address 00:00:f8:1a:4c:02
> nsphy0 at tlp0 phy 5: DP83840 10/100 media interface, rev. 0
> nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
...but this is an excellent data point :-)
-- thorpej
From: Michael Haardt <michael@moria.de>
To: Jason Thorpe <thorpej@me.com>
Cc: gnats-bugs@netbsd.org, Jason Thorpe <thorpej@netbsd.org>,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: port-alpha/33073 (isp0: unable to load dma (22))
Date: Wed, 21 Jul 2021 22:04:33 +0200
> > I see nothing odd during booting, but wonder if "auto" should have been
> > propagated from nsphy0 to tlp0:
> >
> > [ 1.0000000] cia0 at mainbus0: DECchip 2117x Core Logic Chipset (Pyxis), pass 2
> > [ 1.0000000] cia0: extended capabilities: 0x1<BWEN>
> > [ 1.0000000] cia0: using BWX for PCI config access
> > [ 1.0000000] pci0 at cia0 bus 0
> > [ 1.0000000] pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
> > [ 1.0000000] tlp0 at pci0 dev 3 function 0: DECchip 21143 Ethernet, pass 3.0
> > [ 1.0000000] tlp0: interrupting at dec 550 irq 0
> > [ 1.0000000] tlp0: DEC, Ethernet address 00:00:f8:76:0e:39
> > [ 1.0000000] nsphy0 at tlp0 phy 5: DP83840 10/100 media interface, rev. 1
> > [ 1.0000000] nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> > [ 1.0000000] tlp0: 10baseT, 10baseT-FDX, 10base2, 10base5
>
> Huh... can you provide the tlp-related boot messages from 9.2 as well? This bug is almost certainly my fault, but seeing the previous output would be helpful in figuring out how I broke it :-)
>
> If you could gather that up and then file a new bug report for the tlp issue, I would really appreciate it!
Ok, here is the output from NetBSD 9.2:
[ 1.0000000] cia0 at mainbus0: DECchip 2117x Core Logic Chipset (Pyxis), pass 2
[ 1.0000000] cia0: extended capabilities: 0x1<BWEN>
[ 1.0000000] cia0: using BWX for PCI config access
[ 1.0000000] pci0 at cia0 bus 0
[ 1.0000000] pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
[ 1.0000000] tlp0 at pci0 dev 3 function 0: DECchip 21143 Ethernet, pass 3.0
[ 1.0000000] tlp0: interrupting at dec 550 irq 0
[ 1.0000000] tlp0: DEC, Ethernet address 00:00:f8:76:0e:39
[ 1.0000000] nsphy0 at tlp0 phy 5: DP83840 10/100 media interface, rev. 1
[ 1.0000000] nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
[ 1.0000000] tlp0: 10baseT, 10baseT-FDX, 10base2, 10base5
Looks identical to me, but the difference is that it works:
# ifconfig tlp0
tlp0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ec_capabilities=1<VLAN_MTU>
ec_enabled=0
address: 00:00:f8:76:0e:39
media: Ethernet autoselect instance 1 (none)
status: active
inet 10.128.0.15/24 broadcast 10.128.0.255 flags 0x0
I submitted port-alpha/56321 for this.
>> [Warning: received processor correctable error.]
>>
> I guess this is probably due to a flaky memory module. We would need to decode the machine check logout frame. I'll investigate this.
Ok, I will try to identify if it is the RAM and if so, keep the bad ones
for possibly trying a later version of the report, but again that could
take some time.
It is an abandoned machine that has been sitting there for like 15 years,
pretty much since the original bug report, so running any test is not
an issue.
Michael
From: Jason Thorpe <thorpej@me.com>
To: Michael Haardt <michael@moria.de>
Cc: gnats-bugs@netbsd.org,
Jason Thorpe <thorpej@netbsd.org>,
gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: port-alpha/33073 (isp0: unable to load dma (22))
Date: Thu, 22 Jul 2021 22:00:44 -0700
> On Jul 21, 2021, at 11:14 AM, Michael Haardt <michael@moria.de> wrote:
>=20
>> Looks like the instkernel here will have the change:
>>=20
>> =
http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/202107200810Z/alpha/installa=
tion/instkernel/
>=20
> Thanks, I booted that and installed NetBSD. With 9.2, ethernet media
> auto selection worked. With HEAD it no longer does:
>=20
> [ 337.1011682] tlp0: transmit timeout
> # ifconfig tlp0
> tlp0: flags=3D0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> ec_capabilities=3D0x1<VLAN_MTU>
> ec_enabled=3D0
> address: 00:00:f8:76:0e:39
> media: Ethernet autoselect instance 1 (none)
> inet 10.128.0.15/8 broadcast 10.255.255.255 flags 0
Hm=E2=80=A6 can you send me the output of =E2=80=9Cifconfig -m tlp0=E2=80=9D=
? I have a hunch, but that bit of output would help confirm if I=E2=80=99=
m looking under the right rock.
Thanks!
-- thorpej
From: Michael Haardt <michael@moria.de>
To: Jason Thorpe <thorpej@me.com>
Cc: gnats-bugs@netbsd.org, Jason Thorpe <thorpej@netbsd.org>,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: port-alpha/33073 (isp0: unable to load dma (22))
Date: Fri, 23 Jul 2021 23:36:21 +0200
> Hm=E2=80=A6 can you send me the output of =E2=80=9Cifconfig -m tlp0=E2=80=
=9D ? I have a hunch, but that bit of output would help confirm if I=E2=80=
=99m looking under the right rock.
That does not look changed to 9.2. Right after booting the HEAD installker=
nel
and exiting sysinst:
tlp0: flags=3D0x8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
ec_capabilities=3D0x1<VLAN_MTU>
ec_enabled=3D0
address: 00:00:f8:76:0e:39
media: Ethernet autoselect instance 1 (none)
supported Ethernet media:
media 10baseT
media 10baseT mediaopt full-duplex
media 10base2
media 10base5
media none instance 1
media 10baseT instance 1
media 10baseT mediaopt full-duplex instance 1
media 100baseTX instance 1
media 100baseTX mediaopt full-duplex instance 1
media autoselect instance 1
Once I manually set it to 100baseTX, I can set it back to autoselect
and it will continue working and also continues to show "status: active".
Michael
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home