Hi,

>> So does that mean that, in the current state in 2.0 and in current, it
>> works, but has issues when forwarding?
>
> wm in general had issues with forwarding. The router which was causing the
> problem was an x86 (just making sure we're clear that there wasn't a
> macppc-specific issue here).

The macppc issue I saw was that when I tried to turn on hardware 
checksumming, the card would cease to be able to talk.

> The problem has been fixed in -current, and I believe it is fixed in 3.0.
> I'm not sure if the change was pulled into 2.0 or not. So I think it
> should work w/o IP4CSUM when forwarding in 2.0, and if the fix was pulled
> in, it will work wiht IP4CSUM when forwarding.

Hmmm. What kind of problems were there? I have an i386 router which runs 
1.6.2 and has five wm devices, forwards directly for most of them to the 
other ports, and does NAT to the world. Never had any forwarding problems, 
even running multiple gigabit stuff simultaneously and with hardware 
handshaking on. The cards in the i386 are the same kind as I have in a 
macppc machine, which is why I considered this a macppc specific problem.

Were there, perhaps, other problems with older versions of wm* cards?

Here's the dmesg from the i386:

wm4 at pci4 dev 6 function 0: Intel i82540EM 1000BASE-T Ethernet, rev. 2
wm4: interrupting at irq 14
wm4: Ethernet address 00:07:e9:10:7b:28
makphy4 at wm4 phy 1: Marvell 88E1011 Gigabit PHY, rev. 3
makphy4: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto

And the one from the macppc machine:

wm0 at pci0 dev 13 function 0: Intel i82540EM 1000BASE-T Ethernet, rev. 2
wm0: interrupting at irq 23
wm0: Ethernet address 00:07:e9:0e:48:8c
makphy0 at wm0 phy 1: Marvell 88E1011 Gigabit PHY, rev. 3
makphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto

(they're exactly the same model / age / batch card)

John Klos