Re: wm devices don't work under current amd64

[Kengo NAKAHARA]

Hi,

Sorry for the long long delay...

On 2016/07/06 15:55, Masanobu SAITOH wrote:
>   I got a Latitude E6400 via an auction. I tried -current and it
> worked with MSI. While checking your dmesg, I noticed that you
> didn't use ACPI. I tried without ACPI and I could reproduce the
> problem. Without ACPI, any ioapic isn't attached. knakaraha said
> it might be the reason of the problem. Perhaps the problem is
> not only for Latitude E6400 but for all systems which don't use
> ACPI and use MSI/MSI-X. It can be fixed.

I borrow Latitude E6400 from msaitoh@n.o, and test below commit.
http://mail-index.netbsd.org/source-changes/2017/04/14/msg083553.html

The wm works well without ACPI.
# Thank you nonaka@n.o

Could you try latest kernel?


Thanks,

-- 
//
Internet Initiative Japan Inc.

Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit

Kengo NAKAHARA 

Re: wm devices don't work under current amd64

[Christos Zoulas]

In article ,
Tom Ivar Helbekkmo   wrote:
>Tom Ivar Helbekkmo  writes:
>
>> Christos Zoulas  writes:
>>
>>> Right now it seems to be a good time to upgrade for example...
>>
>> That's what I'm hoping for - I started a couple of hours ago.  :)
>
>Didn't go so well.  My main machine does routing between several VLANs,
>using Quagga to manage the routing, NPF and ALTQ for traffic management,
>and OpenVPN for tunnels from remote devices, all the while offering a
>number of network services internally.
>
>After updating to a fresh current, attempting to enable NPF will crash
>the machine, as will starting OpenVPN.  The latter causes a crash the
>moment it tries to create a tun interface.
>
>Unfortunately, these crashes only cause a traceback to quickly scroll
>past on the console, instead of the proper core dump I'm used to.  Not
>sure what has caused this change...

Ouch must be the pserialize on pfil. Let me upgrade too.

christos

Re: wm devices don't work under current amd64

[Tom Ivar Helbekkmo]

Tom Ivar Helbekkmo  writes:

> Christos Zoulas  writes:
>
>> Right now it seems to be a good time to upgrade for example...
>
> That's what I'm hoping for - I started a couple of hours ago.  :)

Didn't go so well.  My main machine does routing between several VLANs,
using Quagga to manage the routing, NPF and ALTQ for traffic management,
and OpenVPN for tunnels from remote devices, all the while offering a
number of network services internally.

After updating to a fresh current, attempting to enable NPF will crash
the machine, as will starting OpenVPN.  The latter causes a crash the
moment it tries to create a tun interface.

Unfortunately, these crashes only cause a traceback to quickly scroll
past on the console, instead of the proper core dump I'm used to.  Not
sure what has caused this change...

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

Re: wm devices don't work under current amd64

[Tom Ivar Helbekkmo]

Christos Zoulas  writes:

> Right now it seems to be a good time to upgrade for example...

That's what I'm hoping for - I started a couple of hours ago.  :)

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

Re: wm devices don't work under current amd64

[Christos Zoulas]

On Jan 21,  8:13am, t...@hamartun.priv.no (Tom Ivar Helbekkmo) wrote:
-- Subject: Re: wm devices don't work under current amd64

| I guess I worded that a bit clumsily.  :)  I meant that there seem to be
| a number of rather deep changes going on, accompanied by more reports of
| crashes than I'm used to seeing on current-users.

Yes, YMMV. I update one of my 2 internet gateways at home to current weekly
so I find many of those issues. Right now it seems to be a good time to upgrade
for example...

christos

Re: wm devices don't work under current amd64

[Tom Ivar Helbekkmo]

Christos Zoulas  writes:

> I don't know about that. It is pretty stable with me...

I guess I worded that a bit clumsily.  :)  I meant that there seem to be
a number of rather deep changes going on, accompanied by more reports of
crashes than I'm used to seeing on current-users.

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

Re: wm devices don't work under current amd64

[Christos Zoulas]

In article ,
Tom Ivar Helbekkmo   wrote:
>Christos Zoulas  writes:
>
>> Perhaps we want a lock?
>
>OK, that makes sense - and might explain why my problem returned.
>(Especially as it's not quite the same as before, and the differences
>may well be locking related.)  But should I pursue this on 7.99.39, or
>should I upgrade to the latest -current, and see what happens then?
>I've been reluctant to upgrade, lately, because I'm under the impression
>that -current is extremely unstable -- and I don't really have time
>right now to have my primary systems crash on a daily basis...  :)

I don't know about that. It is pretty stable with me...

christos

Re: wm devices don't work under current amd64

[Tom Ivar Helbekkmo]

Christos Zoulas  writes:

> Perhaps we want a lock?

OK, that makes sense - and might explain why my problem returned.
(Especially as it's not quite the same as before, and the differences
may well be locking related.)  But should I pursue this on 7.99.39, or
should I upgrade to the latest -current, and see what happens then?
I've been reluctant to upgrade, lately, because I'm under the impression
that -current is extremely unstable -- and I don't really have time
right now to have my primary systems crash on a daily basis...  :)

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

Re: wm devices don't work under current amd64

[Christos Zoulas]

In article ,
Tom Ivar Helbekkmo   wrote:
>Tom Ivar Helbekkmo  writes:
>
>> Masanobu SAITOH  writes:
>>
>>>  Please test the latest -current. knakahara found a problem:
>>
>> That worked fine!  No longer any need for the tcpdump hack.  :)
>>
>> (I didn't get the latest -current; I just added those patches to 7.99.39.)
>
>Correction: it works *almost* fine.  Turns out that those patches alone
>let my main amd64 system boot without the tcpdump hack, and work well
>as, among other things, an NFS server.  However, another amd64 system
>that doesn't use VLANs, and is an NFS client, is unable to write to NFS
>file systems if it runs a kernel with the patch applied.
>
>Patch on NFS server, not on client: no problem.
>Patch on NFS server and client: writing to NFS hangs.
>Patch on NFS client, not on server: writing to NFS hangs.
>
>I guess the patch depends on other changes after 7.99.39...
>
>Just to be sure we agree what we're discussing, this is the patch:

Perhaps we want a lock?

Index: if_vlan.c
===
RCS file: /cvsroot/src/sys/net/if_vlan.c,v
retrieving revision 1.94
diff -u -u -r1.94 if_vlan.c
--- if_vlan.c   13 Jan 2017 06:11:56 -  1.94
+++ if_vlan.c   20 Jan 2017 22:05:49 -
@@ -313,10 +313,11 @@
ifv->ifv_encaplen = ETHER_VLAN_ENCAP_LEN;
ifv->ifv_mintu = ETHERMIN;
 
-   if (ec->ec_nvlans++ == 0) {
+   mutex_enter(ec->ec_lock);
+   if (ec->ec_nvlans == 0) {
if ((error = ether_enable_vlan_mtu(p)) >= 0) {
if (error) {
-   ec->ec_nvlans--;
+   mutex_exit(ec->ec_lock);
return error;
}
ifv->ifv_mtufudge = 0;
@@ -348,6 +349,8 @@
 IFCAP_CSUM_TCPv6_Tx|IFCAP_CSUM_TCPv6_Rx|
 IFCAP_CSUM_UDPv6_Tx|IFCAP_CSUM_UDPv6_Rx);
 }
+   ec->ec_nvlans++;
+   mutex_exit(ec->ec_lock);
/*
 * We inherit the parent's Ethernet address.
 */
@@ -403,8 +406,10 @@
case IFT_ETHER:
{
struct ethercom *ec = (void *)p;
+   mutex_enter(ec->ec_lock);
if (--ec->ec_nvlans == 0)
(void)ether_disable_vlan_mtu(p);
+   mutex_exit(ec->ec_lock);
 
ether_ifdetach(ifp);
/* Restore vlan_ioctl overwritten by ether_ifdetach */

Re: wm devices don't work under current amd64

[Tom Ivar Helbekkmo]

Tom Ivar Helbekkmo  writes:

> However, another amd64 system that doesn't use VLANs, and is an NFS
> client, is unable to write to NFS file systems if it runs a kernel
> with the patch applied.

Don't mind me - after a little while, the problem returned on this
system, even without the patch.  So I've got something else going on.

Sorry about the false alarm!

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

Re: wm devices don't work under current amd64

[Tom Ivar Helbekkmo]

Tom Ivar Helbekkmo  writes:

> Masanobu SAITOH  writes:
>
>>  Please test the latest -current. knakahara found a problem:
>
> That worked fine!  No longer any need for the tcpdump hack.  :)
>
> (I didn't get the latest -current; I just added those patches to 7.99.39.)

Correction: it works *almost* fine.  Turns out that those patches alone
let my main amd64 system boot without the tcpdump hack, and work well
as, among other things, an NFS server.  However, another amd64 system
that doesn't use VLANs, and is an NFS client, is unable to write to NFS
file systems if it runs a kernel with the patch applied.

Patch on NFS server, not on client: no problem.
Patch on NFS server and client: writing to NFS hangs.
Patch on NFS client, not on server: writing to NFS hangs.

I guess the patch depends on other changes after 7.99.39...

Just to be sure we agree what we're discussing, this is the patch:

--- sys/net/if_ethersubr.c  10 Jan 2017 05:42:34 -  1.234
+++ sys/net/if_ethersubr.c  13 Jan 2017 06:11:56 -  1.235
@@ -1475,10 +1475,6 @@
int error;
struct ethercom *ec = (void *)ifp;
 
-   /* Already have VLAN's do nothing. */
-   if (ec->ec_nvlans != 0)
-   return 0;
-
/* Parent does not support VLAN's */
if ((ec->ec_capabilities & ETHERCAP_VLAN_MTU) == 0)
return -1;
--- sys/net/if_vlan.c   15 Dec 2016 09:28:06 -  1.93
+++ sys/net/if_vlan.c   13 Jan 2017 06:11:56 -  1.94
@@ -313,10 +313,12 @@
ifv->ifv_encaplen = ETHER_VLAN_ENCAP_LEN;
ifv->ifv_mintu = ETHERMIN;
 
-   if (ec->ec_nvlans == 0) {
+   if (ec->ec_nvlans++ == 0) {
if ((error = ether_enable_vlan_mtu(p)) >= 0) {
-   if (error)
+   if (error) {
+   ec->ec_nvlans--;
return error;
+   }
ifv->ifv_mtufudge = 0;
} else {
/*
@@ -329,7 +331,6 @@
ifv->ifv_mtufudge = ifv->ifv_encaplen;
}
}
-   ec->ec_nvlans++;
 
/*
 * If the parent interface can do hardware-assisted

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

Re: wm devices don't work under current amd64

[Masanobu SAITOH]

On 2017/01/14 2:03, Tom Ivar Helbekkmo wrote:

Masanobu SAITOH  writes:


 Please test the latest -current. knakahara found a problem:


That worked fine!  No longer any need for the tcpdump hack.  :)

(I didn't get the latest -current; I just added those patches to 7.99.39.)


Good :)


-tih




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: wm devices don't work under current amd64

[Masanobu SAITOH]

On 2017/01/14 6:43, Jarle Greipsland wrote:

Masanobu SAITOH  writes:

On 2016/11/28 17:16, Masanobu SAITOH wrote:

Hello, Jarle.

On 2016/11/27 0:45, Jarle Greipsland wrote:

[ ... ]

Was this problem ever fixed?


 Perhaps no. I've added a lot of changes into if_wm.c, but I've not
touched vlan related stuff.



 Please test the latest -current. knakahara found a problem:

[ ... ]

cvs rdiff -u -r1.234 -r1.235 src/sys/net/if_ethersubr.c
cvs rdiff -u -r1.93 -r1.94 src/sys/net/if_vlan.c

As far as I can tell, with these changes, the problem is gone.


Thank you for the verification.


-jarle




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: wm devices don't work under current amd64

[Jarle Greipsland]

Masanobu SAITOH  writes:
> On 2016/11/28 17:16, Masanobu SAITOH wrote:
>> Hello, Jarle.
>>
>> On 2016/11/27 0:45, Jarle Greipsland wrote:
[ ... ]
>>> Was this problem ever fixed?
>>
>>  Perhaps no. I've added a lot of changes into if_wm.c, but I've not
>> touched vlan related stuff.
> 
> 
>  Please test the latest -current. knakahara found a problem:
[ ... ]
>> cvs rdiff -u -r1.234 -r1.235 src/sys/net/if_ethersubr.c
>> cvs rdiff -u -r1.93 -r1.94 src/sys/net/if_vlan.c
As far as I can tell, with these changes, the problem is gone.

-jarle
-- 
"We apologize for the error in last week's paper in which we stated that
 Mr. Arnold Dogbody was a defective in the police force. We meant, of course,
 that Mr. Dogbody is a detective in the police farce."
-- Correction notice in the Ely Standard, a British newspaper

Re: wm devices don't work under current amd64

[Tom Ivar Helbekkmo]

Masanobu SAITOH  writes:

>  Please test the latest -current. knakahara found a problem:

That worked fine!  No longer any need for the tcpdump hack.  :)

(I didn't get the latest -current; I just added those patches to 7.99.39.)

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

Re: wm devices don't work under current amd64

[Masanobu SAITOH]

On 2016/11/28 17:16, Masanobu SAITOH wrote:

Hello, Jarle.

On 2016/11/27 0:45, Jarle Greipsland wrote:

Masanobu SAITOH  writes:

Hi.

On 2016/03/07 21:12, Tobias Nygren wrote:

On Mon, 7 Mar 2016 20:57:02 +0900
Masanobu SAITOH  wrote:


One of the possibility is that the multicast filter table and broadcast
bit in a register aren't set correctly on ICH9.


I'm not sure if this is relevant to the discussion, but I have a wm(4)
device (8086:1502) on -current that does not work after boot. It comes
to life only after running "tcpdump -n -i wm0" once. I am using vlan(4),
but haven't checked if that makes any difference. I usually run the
tcpdump command then forget about it until the next reboot.


 It must be a bug! Could you tell me how you set up network interface include
vlan? (e.g. part of /etc/rc.conf, /etc/ifconfig.xxx, and the output of 
"ifconfig -a)


Was this problem ever fixed?


 Perhaps no. I've added a lot of changes into if_wm.c, but I've not
touched vlan related stuff.



 Please test the latest -current. knakahara found a problem:


Module Name:src
Committed By:   msaitoh
Date:   Fri Jan 13 06:11:56 UTC 2017

Modified Files:
src/sys/net: if_ethersubr.c if_vlan.c

Log Message:
 Fix a bug that the parent interface's callback wasn't called when the vlan
interface is configured. A callback function uses VLAN_ATTACHED() function
which check ec->ec_nvlans, the value should be incremented before calling the
callback. This bug was added in if_vlan.c rev. 1.83 (2015/11/19).


To generate a diff of this commit:
cvs rdiff -u -r1.234 -r1.235 src/sys/net/if_ethersubr.c
cvs rdiff -u -r1.93 -r1.94 src/sys/net/if_vlan.c



--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: wm devices don't work under current amd64

[Masanobu SAITOH]

Hello, Jarle.

On 2016/11/27 0:45, Jarle Greipsland wrote:

Masanobu SAITOH  writes:

Hi.

On 2016/03/07 21:12, Tobias Nygren wrote:

On Mon, 7 Mar 2016 20:57:02 +0900
Masanobu SAITOH  wrote:


One of the possibility is that the multicast filter table and broadcast
bit in a register aren't set correctly on ICH9.


I'm not sure if this is relevant to the discussion, but I have a wm(4)
device (8086:1502) on -current that does not work after boot. It comes
to life only after running "tcpdump -n -i wm0" once. I am using vlan(4),
but haven't checked if that makes any difference. I usually run the
tcpdump command then forget about it until the next reboot.


 It must be a bug! Could you tell me how you set up network interface include
vlan? (e.g. part of /etc/rc.conf, /etc/ifconfig.xxx, and the output of 
"ifconfig -a)


Was this problem ever fixed?


 Perhaps no. I've added a lot of changes into if_wm.c, but I've not
touched vlan related stuff.

 I've struggled to make I219 work for month but the work have not
finished yet.

 I also resumed working ixg(4) sync with FreeBSD last week and it'll
take a few or more weeks to finish. Until finishing the work, I won't
come back to any wm bugfixes. So if someone can spend time to fix vlan
and I219 problem of wm(4), please do!

 Regards.



 I am experiencing very similar
problems with -current as of yesterday.  My system is a
SuperMicro X7SPA-HF used as a router with a non-vlan interface
towards my ISP (wm1), and a vlan'ed interface for a number of
internal networks (wm0).

An old kernel 7.99.21 from October last year works fine:
[ ... ]
ppb0 at pci0 dev 28 function 0: vendor 8086 product 2940 (rev. 0x02)
ppb0: PCI Express capability version 1  x4 @ 2.
5GT/s
pci1 at ppb0 bus 1
pci1: i/o space, memory space enabled, rd/line, wr/inv ok
ppb1 at pci0 dev 28 function 4: vendor 8086 product 2948 (rev. 0x02)
ppb1: PCI Express capability version 1  x1 @ 2.
5GT/s
pci2 at ppb1 bus 2
pci2: i/o space, memory space enabled, rd/line, wr/inv ok
wm0 at pci2 dev 0 function 0: Intel i82574L (rev. 0x00)
wm0: for TX interrupting at msix0 vec 0 affinity to 0
wm0: for RX interrupting at msix0 vec 1 affinity to 1
wm0: for RX interrupting at msix0 vec 2 affinity to 2
wm0: for LINK interrupting at msix0 vec 3
wm0: PCI-Express bus
wm0: 2048 words (8 address bits) SPI EEPROM, version 1.9.0, Image Unique ID 

wm0: Ethernet address 00:xx:xx:xx:xx:xx
makphy0 at wm0 phy 1: Marvell 88E1149 Gigabit PHY, rev. 1
makphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-FDX, auto
ppb2 at pci0 dev 28 function 5: vendor 8086 product 294a (rev. 0x02)
ppb2: PCI Express capability version 1  x1 @ 
2.5GT/s
pci3 at ppb2 bus 3
pci3: i/o space, memory space enabled, rd/line, wr/inv ok
wm1 at pci3 dev 0 function 0: Intel i82574L (rev. 0x00)
wm1: for TX interrupting at msix1 vec 0 affinity to 0
wm1: for RX interrupting at msix1 vec 1 affinity to 1
wm1: for RX interrupting at msix1 vec 2 affinity to 2
wm1: for LINK interrupting at msix1 vec 3
wm1: PCI-Express bus
wm1: 512 words (8 address bits) SPI EEPROM, version 1.9.0, Image Unique ID 

wm1: Ethernet address 00:yy:yy:yy:yy:yy
makphy1 at wm1 phy 1: Marvell 88E1149 Gigabit PHY, rev. 1
makphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-FDX, auto

With a current kernel from yesterday (7.99.42) however, the vlan
interfaces on wm0 do not work.  The dmesg also looks slightly different
(the interrupt routing seems different):

ppb0 at pci0 dev 28 function 0: vendor 8086 product 2940 (rev. 0x02)
ppb0: PCI Express capability version 1  x4 @ 2.
5GT/s
pci1 at ppb0 bus 1
pci1: i/o space, memory space enabled, rd/line, wr/inv ok
ppb1 at pci0 dev 28 function 4: vendor 8086 product 2948 (rev. 0x02)
ppb1: PCI Express capability version 1  x1 @ 2.
5GT/s
pci2 at ppb1 bus 2
pci2: i/o space, memory space enabled, rd/line, wr/inv ok
wm0 at pci2 dev 0 function 0: Intel i82574L (rev. 0x00)
wm0: for TX and RX interrupting at msix0 vec 0 affinity to 1
wm0: for TX and RX interrupting at msix0 vec 1 affinity to 2
wm0: for LINK interrupting at msix0 vec 2
wm0: PCI-Express bus
wm0: 2048 words (8 address bits) SPI EEPROM, version 1.9.0, Image Unique ID 

wm0: Ethernet address 00:xx:xx:xx:xx:xx
makphy0 at wm0 phy 1: Marvell 88E1149 Gigabit PHY, rev. 1
makphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-FDX, auto
ppb2 at pci0 dev 28 function 5: vendor 8086 product 294a (rev. 0x02)
ppb2: PCI Express capability version 1  x1 @ 
2.5GT/s
pci3 at ppb2 bus 3
pci3: i/o space, memory space enabled, rd/line, wr/inv ok
wm1 at pci3 dev 0 function 0: Intel i82574L (rev. 0x00)
wm1: for TX and RX interrupting at msix1 vec 0 affinity to 1
wm1: for TX and RX interrupting at msix1 vec 1 affinity to 2
wm1: for LINK interrupting at msix1 vec 2
wm1: PCI-Express bus
wm1: 512 words (8 address bits) SPI EEPROM, version 1.9.0, Image Unique ID 

wm1: Ethernet address 

Re: wm devices don't work under current amd64

[Jarle Greipsland]

Masanobu SAITOH  writes:
> Hi.
> 
> On 2016/03/07 21:12, Tobias Nygren wrote:
>> On Mon, 7 Mar 2016 20:57:02 +0900
>> Masanobu SAITOH  wrote:
>>
>>> One of the possibility is that the multicast filter table and broadcast
>>> bit in a register aren't set correctly on ICH9.
>>
>> I'm not sure if this is relevant to the discussion, but I have a wm(4)
>> device (8086:1502) on -current that does not work after boot. It comes
>> to life only after running "tcpdump -n -i wm0" once. I am using vlan(4),
>> but haven't checked if that makes any difference. I usually run the
>> tcpdump command then forget about it until the next reboot.
> 
>  It must be a bug! Could you tell me how you set up network interface include
> vlan? (e.g. part of /etc/rc.conf, /etc/ifconfig.xxx, and the output of 
> "ifconfig -a)

Was this problem ever fixed?  I am experiencing very similar
problems with -current as of yesterday.  My system is a
SuperMicro X7SPA-HF used as a router with a non-vlan interface
towards my ISP (wm1), and a vlan'ed interface for a number of
internal networks (wm0).

An old kernel 7.99.21 from October last year works fine:
[ ... ]
ppb0 at pci0 dev 28 function 0: vendor 8086 product 2940 (rev. 0x02)
ppb0: PCI Express capability version 1  x4 @ 2.
5GT/s
pci1 at ppb0 bus 1
pci1: i/o space, memory space enabled, rd/line, wr/inv ok
ppb1 at pci0 dev 28 function 4: vendor 8086 product 2948 (rev. 0x02)
ppb1: PCI Express capability version 1  x1 @ 2.
5GT/s
pci2 at ppb1 bus 2
pci2: i/o space, memory space enabled, rd/line, wr/inv ok
wm0 at pci2 dev 0 function 0: Intel i82574L (rev. 0x00)
wm0: for TX interrupting at msix0 vec 0 affinity to 0
wm0: for RX interrupting at msix0 vec 1 affinity to 1
wm0: for RX interrupting at msix0 vec 2 affinity to 2
wm0: for LINK interrupting at msix0 vec 3
wm0: PCI-Express bus
wm0: 2048 words (8 address bits) SPI EEPROM, version 1.9.0, Image Unique ID 

wm0: Ethernet address 00:xx:xx:xx:xx:xx
makphy0 at wm0 phy 1: Marvell 88E1149 Gigabit PHY, rev. 1
makphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-FDX, auto
ppb2 at pci0 dev 28 function 5: vendor 8086 product 294a (rev. 0x02)
ppb2: PCI Express capability version 1  x1 @ 
2.5GT/s
pci3 at ppb2 bus 3
pci3: i/o space, memory space enabled, rd/line, wr/inv ok
wm1 at pci3 dev 0 function 0: Intel i82574L (rev. 0x00)
wm1: for TX interrupting at msix1 vec 0 affinity to 0
wm1: for RX interrupting at msix1 vec 1 affinity to 1
wm1: for RX interrupting at msix1 vec 2 affinity to 2
wm1: for LINK interrupting at msix1 vec 3
wm1: PCI-Express bus
wm1: 512 words (8 address bits) SPI EEPROM, version 1.9.0, Image Unique ID 

wm1: Ethernet address 00:yy:yy:yy:yy:yy
makphy1 at wm1 phy 1: Marvell 88E1149 Gigabit PHY, rev. 1
makphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-FDX, auto

With a current kernel from yesterday (7.99.42) however, the vlan
interfaces on wm0 do not work.  The dmesg also looks slightly different
(the interrupt routing seems different):

ppb0 at pci0 dev 28 function 0: vendor 8086 product 2940 (rev. 0x02)
ppb0: PCI Express capability version 1  x4 @ 2.
5GT/s
pci1 at ppb0 bus 1
pci1: i/o space, memory space enabled, rd/line, wr/inv ok
ppb1 at pci0 dev 28 function 4: vendor 8086 product 2948 (rev. 0x02)
ppb1: PCI Express capability version 1  x1 @ 2.
5GT/s
pci2 at ppb1 bus 2
pci2: i/o space, memory space enabled, rd/line, wr/inv ok
wm0 at pci2 dev 0 function 0: Intel i82574L (rev. 0x00)
wm0: for TX and RX interrupting at msix0 vec 0 affinity to 1
wm0: for TX and RX interrupting at msix0 vec 1 affinity to 2
wm0: for LINK interrupting at msix0 vec 2
wm0: PCI-Express bus
wm0: 2048 words (8 address bits) SPI EEPROM, version 1.9.0, Image Unique ID 

wm0: Ethernet address 00:xx:xx:xx:xx:xx
makphy0 at wm0 phy 1: Marvell 88E1149 Gigabit PHY, rev. 1
makphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-FDX, auto
ppb2 at pci0 dev 28 function 5: vendor 8086 product 294a (rev. 0x02)
ppb2: PCI Express capability version 1  x1 @ 
2.5GT/s
pci3 at ppb2 bus 3
pci3: i/o space, memory space enabled, rd/line, wr/inv ok
wm1 at pci3 dev 0 function 0: Intel i82574L (rev. 0x00)
wm1: for TX and RX interrupting at msix1 vec 0 affinity to 1
wm1: for TX and RX interrupting at msix1 vec 1 affinity to 2
wm1: for LINK interrupting at msix1 vec 2
wm1: PCI-Express bus
wm1: 512 words (8 address bits) SPI EEPROM, version 1.9.0, Image Unique ID 

wm1: Ethernet address 00:yy:yy:yy:yy:yy
makphy1 at wm1 phy 1: Marvell 88E1149 Gigabit PHY, rev. 1
makphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-FDX, auto

With this kernel, I have to do a tcpdump of one or two packets on
wm0 until it starts to work, as suggest by tnn@ in his message
from March.

Any idea what might be the problem?
-jarle

Re: wm devices don't work under current amd64

[Tom Ivar Helbekkmo]

Tom Ivar Helbekkmo  writes:

> Now I can build a kernel that'll try to use MSI with the wm0 on it.

With the updated BIOS, and ACPI enabled, MSI works fine on my wm0.  :)

Note to self: always update the BIOS *first*, then look for other
possible problems.

-tih
-- 
Elections cannot be allowed to change anything.  --Dr. Wolfgang Schäuble

Re: wm devices don't work under current amd64

[Tom Ivar Helbekkmo]

Masanobu SAITOH  writes:

>  I tried the latest -current and it didn't crash. Could you retry?

Never mind - I fixed it: I thought I'd upgraded the BIOS on this laptop
recently, but it turns out it was running a really old one.  Flashing
the latest version available from Dell fixed the ACPI problem.

Now I can build a kernel that'll try to use MSI with the wm0 on it.

-tih
-- 
Elections cannot be allowed to change anything.  --Dr. Wolfgang Schäuble

Re: wm devices don't work under current amd64

[Masanobu SAITOH]

On 2016/07/06 18:06, Tom Ivar Helbekkmo wrote:

Masanobu SAITOH  writes:


 I got a Latitude E6400 via an auction. I tried -current and it
worked with MSI. While checking your dmesg, I noticed that you
didn't use ACPI. I tried without ACPI and I could reproduce the
problem. Without ACPI, any ioapic isn't attached. knakaraha said
it might be the reason of the problem. Perhaps the problem is
not only for Latitude E6400 but for all systems which don't use
ACPI and use MSI/MSI-X. It can be fixed.


That's very interesting - but if I understand correctly, you're booting
that E6400 with ACPI enabled in the kernel.  When I try that, it crashes
very early in the boot process, dropping into KDB.  Could it have one or
more corrupt ACPI data structures in the BIOS -- and is there any way to
fix this, if so?


 I tried the latest -current and it didn't crash. Could you retry?


-tih




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: wm devices don't work under current amd64

[Tom Ivar Helbekkmo]

Masanobu SAITOH  writes:

>  I got a Latitude E6400 via an auction. I tried -current and it
> worked with MSI. While checking your dmesg, I noticed that you
> didn't use ACPI. I tried without ACPI and I could reproduce the
> problem. Without ACPI, any ioapic isn't attached. knakaraha said
> it might be the reason of the problem. Perhaps the problem is
> not only for Latitude E6400 but for all systems which don't use
> ACPI and use MSI/MSI-X. It can be fixed.

That's very interesting - but if I understand correctly, you're booting
that E6400 with ACPI enabled in the kernel.  When I try that, it crashes
very early in the boot process, dropping into KDB.  Could it have one or
more corrupt ACPI data structures in the BIOS -- and is there any way to
fix this, if so?

-tih
-- 
Elections cannot be allowed to change anything.  --Dr. Wolfgang Schäuble

Re: wm devices don't work under current amd64

[Masanobu SAITOH]

Hi.

 Sorry for the long delay.

On 2016/03/10 4:26, SAITOH Masanobu wrote:

Hi, Tom.

On 2016/03/10 4:12, Tom Ivar Helbekkmo wrote:

SAITOH Masanobu  writes:


 You mean your machine works with INTx but it doesn't work on MSI, right?


That is correct.


If so, could you show the full dmesg of the machine?


Appended below.


 And, did you test if your machine's problem does occur "without" vlan?


This is the laptop, which doesn't use vlans.  The other machine, the
Poweredge 2650, is my main server, and does all its networking over a
vlan trunk on its wm0 interface.  I suspect that its problem is
different, since it works with a -current from October 10th, whereas the
laptop doesn't.

dmesg output from the laptop after making its wm0 use INTx instead of MSI:


 Thank you for your quick reply. I had two ICH9 motherboard but I discarded
them because both of them were broken... Now I have no any ICH9 machine.
I have some ICH8s and one ICH10. All of them worked, so I had thought that
ICH9 worked.

 I'm sorry that I'm busy because AsiaBSDCon starts today and I'll be absent
the next one week from Tokyo. I would be happy if someone(TM) debug
and test with variety of ICH9 machines.

 Regards.



Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016
The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.

NetBSD 7.99.26 (DEJAH) #5: Wed Mar  9 17:36:37 CET 2016

r...@barsoom.hamartun.priv.no:/usr/obj/sys/arch/amd64/compile.amd64/DEJAH
total memory = 4083 MB
avail memory = 3945 MB
rnd: seeded with 128 bits
timecounter: Timecounters tick every 10.000 msec
Kernelized RAIDframe activated
timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
Dell Inc. Latitude E6400
mainbus0 (root)
cpu0 at mainbus0
cpu0: Intel(R) Core(TM)2 Duo CPU T9600  @ 2.80GHz, id 0x1067a
pci0 at mainbus0 bus 0: configuration mode 1
pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
pchb0 at pci0 dev 0 function 0: vendor 8086 product 2a40 (rev. 0x07)
agp0 at pchb0: can't find internal VGA config space
ppb0 at pci0 dev 1 function 0: vendor 8086 product 2a41 (rev. 0x07)
ppb0: PCI Express capability version 1  x16 @ 
2.5GT/s
pci1 at ppb0 bus 1
pci1: i/o space, memory space enabled, rd/line, wr/inv ok
vga0 at pci1 dev 0 function 0: vendor 10de product 06eb (rev. 0xa1)
wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation)
wsmux1: connecting to wsdisplay0
drm at vga0 not configured
wm0 at pci0 dev 25 function 0: 82801I mobile (AMT) LAN Controller (rev. 0x03)
wm0: interrupting at irq 11
wm0: PCI-Express bus
wm0: 2048 words FLASH
wm0: Ethernet address 00:26:b9:cd:21:c2
makphy0 at wm0 phy 2: Marvell 88E1149 Gigabit PHY, rev. 1
makphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-FDX, auto
uhci0 at pci0 dev 26 function 0: vendor 8086 product 2937 (rev. 0x03)
uhci0: interrupting at irq 10
usb0 at uhci0: USB revision 1.0
uhci1 at pci0 dev 26 function 1: vendor 8086 product 2938 (rev. 0x03)
uhci1: interrupting at irq 3
usb1 at uhci1: USB revision 1.0
uhci2 at pci0 dev 26 function 2: vendor 8086 product 2939 (rev. 0x03)
uhci2: interrupting at irq 11
usb2 at uhci2: USB revision 1.0
ehci0 at pci0 dev 26 function 7: vendor 8086 product 293c (rev. 0x03)
ehci0: interrupting at irq 11
ehci0: BIOS has given up ownership
ehci0: EHCI version 1.0
ehci0: companion controllers, 2 ports each: uhci0 uhci1 uhci2
usb3 at ehci0: USB revision 2.0
hdaudio0 at pci0 dev 27 function 0: HD Audio Controller
hdaudio0: interrupting at irq 3
hdafg0 at hdaudio0: vendor 111d product 76b2
hdafg0: DAC00 2ch: Speaker [Built-In], HP Out [Jack]
hdafg0: DAC01 2ch: Speaker [Jack]
hdafg0: DIG02 2ch: SPDIF Out [Jack]
hdafg0: 2ch/0ch 44100Hz 48000Hz 88200Hz 96000Hz 192000Hz PCM16 PCM20 PCM24 AC3
audio0 at hdafg0: full duplex, playback, capture, mmap, independent
ppb1 at pci0 dev 28 function 0: vendor 8086 product 2940 (rev. 0x03)
ppb1: PCI Express capability version 1  x1 @ 
2.5GT/s
pci2 at ppb1 bus 11
pci2: i/o space, memory space enabled, rd/line, wr/inv ok
ppb2 at pci0 dev 28 function 1: vendor 8086 product 2942 (rev. 0x03)
ppb2: PCI Express capability version 1  x1 @ 
2.5GT/s
pci3 at ppb2 bus 12
pci3: i/o space, memory space enabled, rd/line, wr/inv ok
iwn0 at pci3 dev 0 function 0: vendor 8086 product 4235 (rev. 0x00)
iwn0: interrupting at irq 10
iwn0: MIMO 3T3R, MoW, address 00:21:6a:ba:79:e2
iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 
36Mbps 48Mbps 54Mbps
ppb3 at pci0 dev 28 function 2: vendor 8086 product 2944 (rev. 0x03)
ppb3: PCI Express capability version 1  x1 @ 
2.5GT/s
pci4 at ppb3 bus 13
pci4: i/o space, memory space enabled, rd/line, wr/inv ok

Re: wm devices don't work under current amd64

[Tom Ivar Helbekkmo]

I wrote:

> This is the laptop, which doesn't use vlans.  The other machine, the
> Poweredge 2650, is my main server, and does all its networking over a
> vlan trunk on its wm0 interface.  I suspect that its problem is
> different, since it works with a -current from October 10th, whereas
> the laptop doesn't.

I was right.  The 2650 behaves like the machine Tobias Nygren described,
and his workaround works for it, too.  So, to summarize:

The Dell Latitude E6400 laptop has an 82801I (8086:10f5) that needs a
kludge in if_wm.c to keep it from using MSI.  On MSI, it generates no
interrupts during use, and thus cannot receive incoming packets.  With
INTx signalling, it works fine.

The Dell PowerEge 2650 server has an i82541GI (8086:1076) that after
boot and configuration (whether or not I use VLANs) needs to be briefly
put into promiscuous mode for the interface to start working.  It does
not use MSI; it already has that kludge in place in if_wm.c, due to an
erratum from Intel warning against using it.

Here are my hacks to get these two machines to boot amd64-current
without any manual intervention:

For the E6400:

--- if_wm.c 9 Feb 2016 08:32:11 -   1.391
+++ if_wm.c 10 Mar 2016 08:44:18 -
@@ -1525,7 +1525,7 @@
 *  82571 & 82572: Errata 63
 */
if ((sc->sc_type <= WM_T_82541_2) || (sc->sc_type == WM_T_82571)
-   || (sc->sc_type == WM_T_82572))
+   || (sc->sc_type == WM_T_82572) || (sc->sc_type == WM_T_ICH9))
pa->pa_flags &= ~PCI_FLAGS_MSI_OKAY;
 
if ((sc->sc_type == WM_T_82575) || (sc->sc_type == WM_T_82576)

On the 2650, I appended this to the last ifconfig.* file to be read:

!/bin/sleep 5
!/usr/sbin/tcpdump -i wm0 -c 5

I could probably do without the sleep, and limit the dump to one packet.

-tih
-- 
Elections cannot be allowed to change anything.  --Dr. Wolfgang Schäuble

Re: wm devices don't work under current amd64

[Tom Ivar Helbekkmo]

SAITOH Masanobu  writes:

>  I'm sorry that I'm busy because AsiaBSDCon starts today and I'll be
> absent the next one week from Tokyo.

Enjoy!  I'll play some more with this stuff while you're away, and see
if I can narrow down the problem with the 2650 a bit.

-tih
-- 
Elections cannot be allowed to change anything.  --Dr. Wolfgang Schäuble

Re: wm devices don't work under current amd64

[SAITOH Masanobu]

Hi, Tom.

On 2016/03/10 4:12, Tom Ivar Helbekkmo wrote:
> SAITOH Masanobu  writes:
> 
>>  You mean your machine works with INTx but it doesn't work on MSI, right?
> 
> That is correct.
> 
>> If so, could you show the full dmesg of the machine?
> 
> Appended below.
> 
>>  And, did you test if your machine's problem does occur "without" vlan?
> 
> This is the laptop, which doesn't use vlans.  The other machine, the
> Poweredge 2650, is my main server, and does all its networking over a
> vlan trunk on its wm0 interface.  I suspect that its problem is
> different, since it works with a -current from October 10th, whereas the
> laptop doesn't.
> 
> dmesg output from the laptop after making its wm0 use INTx instead of MSI:

 Thank you for your quick reply. I had two ICH9 motherboard but I discarded
them because both of them were broken... Now I have no any ICH9 machine.
I have some ICH8s and one ICH10. All of them worked, so I had thought that
ICH9 worked.

 I'm sorry that I'm busy because AsiaBSDCon starts today and I'll be absent
the next one week from Tokyo. I would be happy if someone(TM) debug
and test with variety of ICH9 machines.

 Regards.


> Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
> 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016
> The NetBSD Foundation, Inc.  All rights reserved.
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California.  All rights reserved.
> 
> NetBSD 7.99.26 (DEJAH) #5: Wed Mar  9 17:36:37 CET 2016
>   
> r...@barsoom.hamartun.priv.no:/usr/obj/sys/arch/amd64/compile.amd64/DEJAH
> total memory = 4083 MB
> avail memory = 3945 MB
> rnd: seeded with 128 bits
> timecounter: Timecounters tick every 10.000 msec
> Kernelized RAIDframe activated
> timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
> Dell Inc. Latitude E6400  
> mainbus0 (root)
> cpu0 at mainbus0
> cpu0: Intel(R) Core(TM)2 Duo CPU T9600  @ 2.80GHz, id 0x1067a
> pci0 at mainbus0 bus 0: configuration mode 1
> pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
> pchb0 at pci0 dev 0 function 0: vendor 8086 product 2a40 (rev. 0x07)
> agp0 at pchb0: can't find internal VGA config space
> ppb0 at pci0 dev 1 function 0: vendor 8086 product 2a41 (rev. 0x07)
> ppb0: PCI Express capability version 1  x16 
> @ 2.5GT/s
> pci1 at ppb0 bus 1
> pci1: i/o space, memory space enabled, rd/line, wr/inv ok
> vga0 at pci1 dev 0 function 0: vendor 10de product 06eb (rev. 0xa1)
> wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation)
> wsmux1: connecting to wsdisplay0
> drm at vga0 not configured
> wm0 at pci0 dev 25 function 0: 82801I mobile (AMT) LAN Controller (rev. 0x03)
> wm0: interrupting at irq 11
> wm0: PCI-Express bus
> wm0: 2048 words FLASH
> wm0: Ethernet address 00:26:b9:cd:21:c2
> makphy0 at wm0 phy 2: Marvell 88E1149 Gigabit PHY, rev. 1
> makphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
> 1000baseT-FDX, auto
> uhci0 at pci0 dev 26 function 0: vendor 8086 product 2937 (rev. 0x03)
> uhci0: interrupting at irq 10
> usb0 at uhci0: USB revision 1.0
> uhci1 at pci0 dev 26 function 1: vendor 8086 product 2938 (rev. 0x03)
> uhci1: interrupting at irq 3
> usb1 at uhci1: USB revision 1.0
> uhci2 at pci0 dev 26 function 2: vendor 8086 product 2939 (rev. 0x03)
> uhci2: interrupting at irq 11
> usb2 at uhci2: USB revision 1.0
> ehci0 at pci0 dev 26 function 7: vendor 8086 product 293c (rev. 0x03)
> ehci0: interrupting at irq 11
> ehci0: BIOS has given up ownership
> ehci0: EHCI version 1.0
> ehci0: companion controllers, 2 ports each: uhci0 uhci1 uhci2
> usb3 at ehci0: USB revision 2.0
> hdaudio0 at pci0 dev 27 function 0: HD Audio Controller
> hdaudio0: interrupting at irq 3
> hdafg0 at hdaudio0: vendor 111d product 76b2
> hdafg0: DAC00 2ch: Speaker [Built-In], HP Out [Jack]
> hdafg0: DAC01 2ch: Speaker [Jack]
> hdafg0: DIG02 2ch: SPDIF Out [Jack]
> hdafg0: 2ch/0ch 44100Hz 48000Hz 88200Hz 96000Hz 192000Hz PCM16 PCM20 PCM24 AC3
> audio0 at hdafg0: full duplex, playback, capture, mmap, independent
> ppb1 at pci0 dev 28 function 0: vendor 8086 product 2940 (rev. 0x03)
> ppb1: PCI Express capability version 1  x1 @ 
> 2.5GT/s
> pci2 at ppb1 bus 11
> pci2: i/o space, memory space enabled, rd/line, wr/inv ok
> ppb2 at pci0 dev 28 function 1: vendor 8086 product 2942 (rev. 0x03)
> ppb2: PCI Express capability version 1  x1 @ 
> 2.5GT/s
> pci3 at ppb2 bus 12
> pci3: i/o space, memory space enabled, rd/line, wr/inv ok
> iwn0 at pci3 dev 0 function 0: vendor 8086 product 4235 (rev. 0x00)
> iwn0: interrupting at irq 10
> iwn0: MIMO 3T3R, MoW, address 00:21:6a:ba:79:e2
> iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
> iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
> iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 
> 36Mbps 48Mbps 54Mbps
> ppb3 at pci0 dev 28 function 2: vendor 8086 product 2944 (rev. 0x03)
> 

Re: wm devices don't work under current amd64

[Tom Ivar Helbekkmo]

SAITOH Masanobu  writes:

>  You mean your machine works with INTx but it doesn't work on MSI, right?

That is correct.

> If so, could you show the full dmesg of the machine?

Appended below.

>  And, did you test if your machine's problem does occur "without" vlan?

This is the laptop, which doesn't use vlans.  The other machine, the
Poweredge 2650, is my main server, and does all its networking over a
vlan trunk on its wm0 interface.  I suspect that its problem is
different, since it works with a -current from October 10th, whereas the
laptop doesn't.

dmesg output from the laptop after making its wm0 use INTx instead of MSI:

Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016
The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.

NetBSD 7.99.26 (DEJAH) #5: Wed Mar  9 17:36:37 CET 2016

r...@barsoom.hamartun.priv.no:/usr/obj/sys/arch/amd64/compile.amd64/DEJAH
total memory = 4083 MB
avail memory = 3945 MB
rnd: seeded with 128 bits
timecounter: Timecounters tick every 10.000 msec
Kernelized RAIDframe activated
timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
Dell Inc. Latitude E6400  
mainbus0 (root)
cpu0 at mainbus0
cpu0: Intel(R) Core(TM)2 Duo CPU T9600  @ 2.80GHz, id 0x1067a
pci0 at mainbus0 bus 0: configuration mode 1
pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
pchb0 at pci0 dev 0 function 0: vendor 8086 product 2a40 (rev. 0x07)
agp0 at pchb0: can't find internal VGA config space
ppb0 at pci0 dev 1 function 0: vendor 8086 product 2a41 (rev. 0x07)
ppb0: PCI Express capability version 1  x16 @ 
2.5GT/s
pci1 at ppb0 bus 1
pci1: i/o space, memory space enabled, rd/line, wr/inv ok
vga0 at pci1 dev 0 function 0: vendor 10de product 06eb (rev. 0xa1)
wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation)
wsmux1: connecting to wsdisplay0
drm at vga0 not configured
wm0 at pci0 dev 25 function 0: 82801I mobile (AMT) LAN Controller (rev. 0x03)
wm0: interrupting at irq 11
wm0: PCI-Express bus
wm0: 2048 words FLASH
wm0: Ethernet address 00:26:b9:cd:21:c2
makphy0 at wm0 phy 2: Marvell 88E1149 Gigabit PHY, rev. 1
makphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-FDX, auto
uhci0 at pci0 dev 26 function 0: vendor 8086 product 2937 (rev. 0x03)
uhci0: interrupting at irq 10
usb0 at uhci0: USB revision 1.0
uhci1 at pci0 dev 26 function 1: vendor 8086 product 2938 (rev. 0x03)
uhci1: interrupting at irq 3
usb1 at uhci1: USB revision 1.0
uhci2 at pci0 dev 26 function 2: vendor 8086 product 2939 (rev. 0x03)
uhci2: interrupting at irq 11
usb2 at uhci2: USB revision 1.0
ehci0 at pci0 dev 26 function 7: vendor 8086 product 293c (rev. 0x03)
ehci0: interrupting at irq 11
ehci0: BIOS has given up ownership
ehci0: EHCI version 1.0
ehci0: companion controllers, 2 ports each: uhci0 uhci1 uhci2
usb3 at ehci0: USB revision 2.0
hdaudio0 at pci0 dev 27 function 0: HD Audio Controller
hdaudio0: interrupting at irq 3
hdafg0 at hdaudio0: vendor 111d product 76b2
hdafg0: DAC00 2ch: Speaker [Built-In], HP Out [Jack]
hdafg0: DAC01 2ch: Speaker [Jack]
hdafg0: DIG02 2ch: SPDIF Out [Jack]
hdafg0: 2ch/0ch 44100Hz 48000Hz 88200Hz 96000Hz 192000Hz PCM16 PCM20 PCM24 AC3
audio0 at hdafg0: full duplex, playback, capture, mmap, independent
ppb1 at pci0 dev 28 function 0: vendor 8086 product 2940 (rev. 0x03)
ppb1: PCI Express capability version 1  x1 @ 
2.5GT/s
pci2 at ppb1 bus 11
pci2: i/o space, memory space enabled, rd/line, wr/inv ok
ppb2 at pci0 dev 28 function 1: vendor 8086 product 2942 (rev. 0x03)
ppb2: PCI Express capability version 1  x1 @ 
2.5GT/s
pci3 at ppb2 bus 12
pci3: i/o space, memory space enabled, rd/line, wr/inv ok
iwn0 at pci3 dev 0 function 0: vendor 8086 product 4235 (rev. 0x00)
iwn0: interrupting at irq 10
iwn0: MIMO 3T3R, MoW, address 00:21:6a:ba:79:e2
iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 
36Mbps 48Mbps 54Mbps
ppb3 at pci0 dev 28 function 2: vendor 8086 product 2944 (rev. 0x03)
ppb3: PCI Express capability version 1  x1 @ 
2.5GT/s
pci4 at ppb3 bus 13
pci4: i/o space, memory space enabled, rd/line, wr/inv ok
ppb4 at pci0 dev 28 function 3: vendor 8086 product 2946 (rev. 0x03)
ppb4: PCI Express capability version 1  x1 @ 
2.5GT/s
pci5 at ppb4 bus 14
pci5: i/o space, memory space enabled, rd/line, wr/inv ok
uhci3 at pci0 dev 29 function 0: vendor 8086 product 2934 (rev. 0x03)
uhci3: interrupting at irq 10
usb4 at uhci3: USB revision 1.0
uhci4 at pci0 dev 29 function 1: vendor 8086 product 2935 (rev. 0x03)
uhci4: interrupting at irq 3
usb5 at uhci4: USB revision 1.0
uhci5 at pci0 dev 29 function 2: vendor 8086 product 2936 (rev. 0x03)
uhci5: interrupting at 

Re: wm devices don't work under current amd64

[SAITOH Masanobu]

Hi.

On 2016/03/10 2:40, Tom Ivar Helbekkmo wrote:
> Masanobu SAITOH  writes:
> 
>>  A bug must be exist. sborrill@ repored vlan related probem before. One of
>> the problem is that I can't reproduce the problem with my machines...
>> If I can reproduce the problem with my machine, I can fix it...
> 
> Well, I know a bit more about the problem with the laptop, now.  It's
> something to do with MSI.  I observed that the (non-working) kernel had
> logged exactly one MSI interrupt, which I figured was the one from the
> autoconfiguration.  There's a place in if_wm.c where MSI is masked out
> for a couple of versions of the Intel chip.  Adding the version in the
> Dell Latitude E640 laptop to that list, so it fell back to traditional
> IRQ handling, made the interface start working properly:
> 
>   if ((sc->sc_type <= WM_T_82541_2) || (sc->sc_type == WM_T_82571)
>   || (sc->sc_type == WM_T_82572) || (sc->sc_type == WM_T_ICH9))
>   pa->pa_flags &= ~PCI_FLAGS_MSI_OKAY;

 You mean your machine works with INTx but it doesn't work on MSI, right?
If so, could you show the full dmesg of the machine?

 And, did you test if your machine's problem does occur "without" vlan?


> (The WM_T_ICH9 is the one in the laptop.)  No idea yet about the Dell
> Poweredge 2650.  I'll see if I can take a closer look at that tomorrow.
> 
> -tih



-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: wm devices don't work under current amd64

[Tom Ivar Helbekkmo]

Masanobu SAITOH  writes:

>  A bug must be exist. sborrill@ repored vlan related probem before. One of
> the problem is that I can't reproduce the problem with my machines...
> If I can reproduce the problem with my machine, I can fix it...

Well, I know a bit more about the problem with the laptop, now.  It's
something to do with MSI.  I observed that the (non-working) kernel had
logged exactly one MSI interrupt, which I figured was the one from the
autoconfiguration.  There's a place in if_wm.c where MSI is masked out
for a couple of versions of the Intel chip.  Adding the version in the
Dell Latitude E640 laptop to that list, so it fell back to traditional
IRQ handling, made the interface start working properly:

if ((sc->sc_type <= WM_T_82541_2) || (sc->sc_type == WM_T_82571)
|| (sc->sc_type == WM_T_82572) || (sc->sc_type == WM_T_ICH9))
pa->pa_flags &= ~PCI_FLAGS_MSI_OKAY;

(The WM_T_ICH9 is the one in the laptop.)  No idea yet about the Dell
Poweredge 2650.  I'll see if I can take a closer look at that tomorrow.

-tih
-- 
Elections cannot be allowed to change anything.  --Dr. Wolfgang Schäuble

Re: wm devices don't work under current amd64

[John Nemeth]

On Mar 8,  8:29am, Tom Ivar Helbekkmo wrote:
} John Nemeth  writes:
} 
} > The 2924 is an old switch so it may behave funny.
} 
} Yeah, the most common problem with these old Ciscos is that the
} autoconfiguration randomly fails -- sometimes after having worked well
} again and again for a long time.
} 
} > Could you set both ends to auto/auto and see what happens?
} 
} In this case, they managed to both decide on 100/full -- and
} communication fails in the same way.

 This tells us that the hardware is fundamentally sound, i.e.
it is receiving data and acting on it.  That tends to indicate that
it is a driver issue.  msaitoh@ is our driver expert, so I'm going
to bow out.

}-- End of excerpt from Tom Ivar Helbekkmo

Re: wm devices don't work under current amd64

[Swift Griggs]

On Tue, 8 Mar 2016, Tom Ivar Helbekkmo wrote:

The 2924 is an old switch so it may behave funny.

Yeah, the most common problem with these old Ciscos is that the
autoconfiguration randomly fails -- sometimes after having worked well
again and again for a long time.


Those are the same switches that almost never autonegotiate properly with 
Sun HME (happy meal ethernet) cards. Every time I encounter them used with 
Sun hardware they are hard set to max speed @ full duplex. In the case of 
Sun gear, you had to hard set both the switch and the NIC. It was rather 
painful.


-Swift

Re: wm devices don't work under current amd64

[Tom Ivar Helbekkmo]

John Nemeth  writes:

> The 2924 is an old switch so it may behave funny.

Yeah, the most common problem with these old Ciscos is that the
autoconfiguration randomly fails -- sometimes after having worked well
again and again for a long time.

> Could you set both ends to auto/auto and see what happens?

In this case, they managed to both decide on 100/full -- and
communication fails in the same way.

-tih
-- 
Elections cannot be allowed to change anything.  --Dr. Wolfgang Schäuble

Re: wm devices don't work under current amd64

[Tom Ivar Helbekkmo]

Masanobu SAITOH  writes:

>  Is it possible to test with 7.0(RELEASE) and the latest snapshot
> of netbsd-7 branch?

I just did, and the wm0 interface of my Dell Aptitude E6400 laptop works
just fine with both of those.  A final clean boot from a 7.99.26 install
CD once again fails to get the interface to work.

-tih
-- 
Elections cannot be allowed to change anything.  --Dr. Wolfgang Schäuble

Re: wm devices don't work under current amd64

[Tom Ivar Helbekkmo]

Masanobu SAITOH  writes:

> If I can reproduce the problem with my machine, I can fix it...

I'd be happy to apply a patch to create some debug output, for instance...

-tih
-- 
Elections cannot be allowed to change anything.  --Dr. Wolfgang Schäuble

Re: wm devices don't work under current amd64

[Tom Ivar Helbekkmo]

Masanobu SAITOH  writes:

> On 2016/03/07 21:12, Tobias Nygren wrote:
>> [...]
>> I'm not sure if this is relevant to the discussion, but I have a wm(4)
>> device (8086:1502) on -current that does not work after boot. It comes
>> to life only after running "tcpdump -n -i wm0" once.

That's interesting -- I'll try that on my Dell 2650, and see what
happens.  It didn't do anything for the Dell E6400 laptop, though.

>  It must be a bug! Could you tell me how you set up network interface
> include vlan? (e.g. part of /etc/rc.conf, /etc/ifconfig.xxx, and the
> output of "ifconfig -a)

For my part, I simply do this (vlan0 being my primary internal LAN, and
vlan1 being the glue net facing my ISP):

/etc/ifconfig.wm0:

up
media 100baseTX mediaopt full-duplex
!sleep 30

/etc/ifconfig.vlan0:

create
vlan 10 vlanif wm0
inet 193.71.27.8 prefixlen 27
inet 193.71.27.5 prefixlen 27 alias
inet 193.71.27.1 prefixlen 27 alias

/etc/ifconfig.vlan1:

create
vlan 11 vlanif wm0
inet 81.0.129.41 prefixlen 30
!route -q add default 81.0.129.42

/etc/ifconfig.vlan2:

create
vlan 12 vlanif wm0
inet 172.27.201.1 prefixlen 24

/etc/ifconfig.vlan3:

create
vlan 13 vlanif wm0
inet 172.27.202.1 prefixlen 24

-tih
-- 
Elections cannot be allowed to change anything.  --Dr. Wolfgang Schäuble

Re: wm devices don't work under current amd64

[Masanobu SAITOH]

Hi, Tom.

On 2016/03/07 21:34, Tom Ivar Helbekkmo wrote:

Masanobu SAITOH  writes:


  Is the port connecting 100BaseT switch or gigabit switch.


It's connected to a Cisco 2924 VLAN switch, and both the switch port and
the wm0 device on the laptop are explicitly configured for 100/full.


I see.


  Are you using dhcpcd? Have you tried with static IPv4 address?


Yes, and yes.  When I manually configure it for an address on the VLAN
that's actually on that port, and try to ping a neighbor, I can see this
(using tcpdump on the neighbor):

13:24:21.596308 ARP, Request who-has hamartun-gw.hamartun.priv.no tell 
172.27.202.50, length 46
13:24:21.596326 ARP, Reply hamartun-gw.hamartun.priv.no is-at 00:13:72:f7:00:06 
(oui Unknown), length 28

However, the ARP response is never received, so it just keeps trying.


And, could you try "ping6 ff02::1%wm0" and check if any reply
comes from other machine?


dejah# ping6 ff02::1%wm0
PING6(56=40+8+8 bytes) fe80::226:b9ff:fecd:21c2%wm0 --> ff02::1%wm0
16 bytes from fe80::226:b9ff:fecd:21c2%wm0, icmp_seq=0 hlim=64 time=0.037 ms
16 bytes from fe80::226:b9ff:fecd:21c2%wm0, icmp_seq=1 hlim=64 time=0.017 ms
16 bytes from fe80::226:b9ff:fecd:21c2%wm0, icmp_seq=2 hlim=64 time=0.017 ms
16 bytes from fe80::226:b9ff:fecd:21c2%wm0, icmp_seq=3 hlim=64 time=0.017 ms
16 bytes from fe80::226:b9ff:fecd:21c2%wm0, icmp_seq=4 hlim=64 time=0.017 ms
16 bytes from fe80::226:b9ff:fecd:21c2%wm0, icmp_seq=5 hlim=64 time=0.016 ms
^C
--- ff02::1%wm0 ping6 statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.016/0.020/0.037/0.008 ms

That's just the host itself answering, right?


Yes. Only host itself.


If I do this on the
(working) iwn0 WiFi interface, I get more responses, with much longer
RTTs, and "(DUP!)" messages.  I assume that's neighbours answering?


 Yes, those replies are from neighbors.

 A bug must be exist. sborrill@ repored vlan related probem before. One of
the problem is that I can't reproduce the problem with my machines...
If I can reproduce the problem with my machine, I can fix it...


-tih




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: wm devices don't work under current amd64

[Tom Ivar Helbekkmo]

Masanobu SAITOH  writes:

>  Is the port connecting 100BaseT switch or gigabit switch.

It's connected to a Cisco 2924 VLAN switch, and both the switch port and
the wm0 device on the laptop are explicitly configured for 100/full.

>  Are you using dhcpcd? Have you tried with static IPv4 address?

Yes, and yes.  When I manually configure it for an address on the VLAN
that's actually on that port, and try to ping a neighbor, I can see this
(using tcpdump on the neighbor):

13:24:21.596308 ARP, Request who-has hamartun-gw.hamartun.priv.no tell 
172.27.202.50, length 46
13:24:21.596326 ARP, Reply hamartun-gw.hamartun.priv.no is-at 00:13:72:f7:00:06 
(oui Unknown), length 28

However, the ARP response is never received, so it just keeps trying.

> And, could you try "ping6 ff02::1%wm0" and check if any reply
> comes from other machine?

dejah# ping6 ff02::1%wm0
PING6(56=40+8+8 bytes) fe80::226:b9ff:fecd:21c2%wm0 --> ff02::1%wm0
16 bytes from fe80::226:b9ff:fecd:21c2%wm0, icmp_seq=0 hlim=64 time=0.037 ms
16 bytes from fe80::226:b9ff:fecd:21c2%wm0, icmp_seq=1 hlim=64 time=0.017 ms
16 bytes from fe80::226:b9ff:fecd:21c2%wm0, icmp_seq=2 hlim=64 time=0.017 ms
16 bytes from fe80::226:b9ff:fecd:21c2%wm0, icmp_seq=3 hlim=64 time=0.017 ms
16 bytes from fe80::226:b9ff:fecd:21c2%wm0, icmp_seq=4 hlim=64 time=0.017 ms
16 bytes from fe80::226:b9ff:fecd:21c2%wm0, icmp_seq=5 hlim=64 time=0.016 ms
^C
--- ff02::1%wm0 ping6 statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.016/0.020/0.037/0.008 ms

That's just the host itself answering, right?  If I do this on the
(working) iwn0 WiFi interface, I get more responses, with much longer
RTTs, and "(DUP!)" messages.  I assume that's neighbours answering?

-tih
-- 
Elections cannot be allowed to change anything.  --Dr. Wolfgang Schäuble

Re: wm devices don't work under current amd64

[Masanobu SAITOH]

Hi.

On 2016/03/07 21:12, Tobias Nygren wrote:

On Mon, 7 Mar 2016 20:57:02 +0900
Masanobu SAITOH  wrote:


One of the possibility is that the multicast filter table and broadcast
bit in a register aren't set correctly on ICH9.


I'm not sure if this is relevant to the discussion, but I have a wm(4)
device (8086:1502) on -current that does not work after boot. It comes
to life only after running "tcpdump -n -i wm0" once. I am using vlan(4),
but haven't checked if that makes any difference. I usually run the
tcpdump command then forget about it until the next reboot.


 It must be a bug! Could you tell me how you set up network interface include
vlan? (e.g. part of /etc/rc.conf, /etc/ifconfig.xxx, and the output of 
"ifconfig -a)


wm0 at pci0 dev 25 function 0: PCH2 LAN (82579LM) Controller (rev. 0x06)
wm0: interrupting at msi0 vec 0
wm0: PCI-Express bus
wm0: 2048 words FLASH
wm0: Ethernet address xx:xx:xx:xx:xx:xx
ihphy0 at wm0 phy 2: i82579 10/100/1000 media interface, rev. 3
ihphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: wm devices don't work under current amd64

[Tobias Nygren]

On Mon, 7 Mar 2016 20:57:02 +0900
Masanobu SAITOH  wrote:

> One of the possibility is that the multicast filter table and broadcast
> bit in a register aren't set correctly on ICH9.

I'm not sure if this is relevant to the discussion, but I have a wm(4)
device (8086:1502) on -current that does not work after boot. It comes
to life only after running "tcpdump -n -i wm0" once. I am using vlan(4),
but haven't checked if that makes any difference. I usually run the
tcpdump command then forget about it until the next reboot.

wm0 at pci0 dev 25 function 0: PCH2 LAN (82579LM) Controller (rev. 0x06)
wm0: interrupting at msi0 vec 0
wm0: PCI-Express bus
wm0: 2048 words FLASH
wm0: Ethernet address xx:xx:xx:xx:xx:xx
ihphy0 at wm0 phy 2: i82579 10/100/1000 media interface, rev. 3
ihphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto

Re: wm devices don't work under current amd64

[Masanobu SAITOH]

Hi, Tom.

On 2016/03/07 20:42, Tom Ivar Helbekkmo wrote:

Masanobu SAITOH  writes:


  0) Did you check /var/log/message if device timouts occured?


No timeouts.  Everything behaves as if there were no incoming traffic.


  1) Is Intel AMT set to enable by BIOS?


No, it's not.


  2) Could you show me the output of "ifconfig -v wm0"


wm0: flags=0x8843 mtu 1500
capabilities=7ff80
capabilities=7ff80
capabilities=7ff80
enabled=0
ec_capabilities=7
ec_enabled=0
address: 00:26:b9:cd:21:c2
media: Ethernet 100baseTX full-duplex


 Is the port connecting 100BaseT switch or gigabit switch.


status: active
input: 0 packets, 0 bytes


 Strange.


output: 20 packets, 2608 bytes, 9 multicasts
inet 169.254.22.67 netmask 0x broadcast 169.254.255.255


 Are you using dhcpcd? Have you tried with static IPv4 address?
And, could you try "ping6 ff02::1%wm0" and check if any reply
comes from other machine?

 One of the possibility is that the multicast filter table and broadcast
bit in a register aren't set correctly on ICH9.

 Regards.


inet6 fe80::226:b9ff:fecd:21c2%wm0 prefixlen 64 scopeid 0x1


  Is it possible to test with 7.0(RELEASE) and the latest snapshot
of netbsd-7 branch?


I'll burn a couple of CDs, and try those tonight.

-tih




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: wm devices don't work under current amd64

[Tom Ivar Helbekkmo]

Masanobu SAITOH  writes:

>  0) Did you check /var/log/message if device timouts occured?

No timeouts.  Everything behaves as if there were no incoming traffic.

>  1) Is Intel AMT set to enable by BIOS?

No, it's not.

>  2) Could you show me the output of "ifconfig -v wm0"

wm0: flags=0x8843 mtu 1500
capabilities=7ff80
capabilities=7ff80
capabilities=7ff80
enabled=0
ec_capabilities=7
ec_enabled=0
address: 00:26:b9:cd:21:c2
media: Ethernet 100baseTX full-duplex
status: active
input: 0 packets, 0 bytes
output: 20 packets, 2608 bytes, 9 multicasts
inet 169.254.22.67 netmask 0x broadcast 169.254.255.255
inet6 fe80::226:b9ff:fecd:21c2%wm0 prefixlen 64 scopeid 0x1

>  Is it possible to test with 7.0(RELEASE) and the latest snapshot
> of netbsd-7 branch?

I'll burn a couple of CDs, and try those tonight.

-tih
-- 
Elections cannot be allowed to change anything.  --Dr. Wolfgang Schäuble

Re: wm devices don't work under current amd64

[Masanobu SAITOH]

Hi.

On 2016/03/07 19:35, Tom Ivar Helbekkmo wrote:

I've recently set up a Dell E6400 laptop with NetBSD, and it's working
great - over WiFi.  The built-in wm ethernet interface doesn't work.  It
can send packets out, but can't receive anything.


 0) Did you check /var/log/message if device timouts occured?
 1) Is Intel AMT set to enable by BIOS?
 2) Could you show me the output of "ifconfig -v wm0"


 I tried booting Linux
on the laptop, and it has no trouble with it.  Here's the device:

wm0 at pci0 dev 25 function 0: 82801I mobile (AMT) LAN Controller (rev. 0x03)
wm0: interrupting at msi0 vec 0
wm0: PCI-Express bus
wm0: 2048 words FLASH
wm0: Ethernet address 00:26:b9:cd:21:c2
makphy0 at wm0 phy 2: Marvell 88E1149 Gigabit PHY, rev. 1
makphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-FDX, auto

I first tried installing from a CD containing the NetBSD/amd64 install
image from October 10th (7.99.21).  After that failed to work for the wm
device, I built a new image, using a current from March 4th (7.99.26).
That also failed to work, but it doesn't get kernel panics relating to
arp on the WiFi, so the laptop is working nicely enough without wm0.


 Is it possible to test with 7.0(RELEASE) and the latest snapshot
of netbsd-7 branch?

 Thanks in advance.



However, since I'd built a newer current anyway, I tried upgrading
another Dell box, a 2650 that I use as a server.  It also has wm type
networking devices, which work just fine with 7.99.21.  Surprisingly,
upgrading to 7.99.26 broke them.  The hardware is different, of course:

wm0 at pci6 dev 7 function 0: Intel i82541GI 1000BASE-T Ethernet
(rev. 0x05)
wm0: interrupting at ioapic2 pin 0
wm0: 32-bit 66MHz PCI bus
wm0: 512 words (16 address bits) SPI EEPROM
wm0: Ethernet address 00:13:72:f7:00:06
igphy0 at wm0 phy 1: Intel IGP01E1000 Gigabit PHY, rev. 0
igphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-FDX, auto

I also use this wm0 differently from the plain use I've attempted with
the laptop: this server runs 802.1q VLAN trunking on wm0, and acts as a
router (with pf firewall) between a number of VLANs.  The failures of
the wm devices on the two machines may thus have different causes,
related to either the different hardware, or the difference in use.

Grateful for any hints, things to try, etc.  :)

-tih




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)