Hi to LKML,
I'm experiencing some troubles with WOL with my nForce NIC.
The problem is simple - after setting WOL mode to magic packet my PC
won't wake up. I've noticed there were some changes about this in new
kernel, but no luck for me.
I'm using 2.6.18 kernel, vanilla. I've tried this with Windows Vista RC1
(build 5600) and WOL works correctly. My NIC is integrated on MSI K8N
Neo4-FI
Is there any way how can I help with developement of this feature?
# lspci -v
00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller
(rev a3)
Subsystem: Micro-Star International Co., Ltd. Unknown device
7125
Flags: bus master, 66MHz, fast devsel, latency 0
Capabilities: [44] HyperTransport: Slave or Primary Interface
Capabilities: [e0] HyperTransport: MSI Mapping
00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
Subsystem: Micro-Star International Co., Ltd. Unknown device
7125
Flags: bus master, 66MHz, fast devsel, latency 0
00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
Subsystem: Micro-Star International Co., Ltd. Unknown device
7125
Flags: 66MHz, fast devsel, IRQ 11
I/O ports at fc00 [size=32]
I/O ports at 4c00 [size=64]
I/O ports at 4c40 [size=64]
Capabilities: [44] Power Management version 2
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
(prog-if 10 [OHCI])
Subsystem: Micro-Star International Co., Ltd. Unknown device
7125
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 50
Memory at fe02f000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)
(prog-if 20 [EHCI])
Subsystem: Micro-Star International Co., Ltd. Unknown device
7125
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 233
Memory at feb00000 (32-bit, non-prefetchable) [size=256]
Capabilities: [44] Debug port
Capabilities: [80] Power Management version 2
00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) (prog-if 8a
[Master SecP PriP])
Subsystem: Micro-Star International Co., Ltd. Unknown device
7125
Flags: bus master, 66MHz, fast devsel, latency 0
I/O ports at e000 [size=16]
Capabilities: [44] Power Management version 2
00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller
(rev f3) (prog-if 85 [Master SecO PriO])
Subsystem: Micro-Star International Co., Ltd. Unknown device
7125
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 217
I/O ports at 09f0 [size=8]
I/O ports at 0bf0 [size=4]
I/O ports at 0970 [size=8]
I/O ports at 0b70 [size=4]
I/O ports at cc00 [size=16]
Memory at fe02b000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller
(rev f3) (prog-if 85 [Master SecO PriO])
Subsystem: Micro-Star International Co., Ltd. Unknown device
7125
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 225
I/O ports at 09e0 [size=8]
I/O ports at 0be0 [size=4]
I/O ports at 0960 [size=8]
I/O ports at 0b60 [size=4]
I/O ports at b800 [size=16]
Memory at fe02a000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2)
(prog-if 01 [Subtractive decode])
Flags: bus master, 66MHz, fast devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
I/O behind bridge: 0000a000-0000afff
Memory behind bridge: fde00000-fdefffff
Prefetchable memory behind bridge: fdf00000-fdffffff
00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
Subsystem: Micro-Star International Co., Ltd. Unknown device
7125
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 217
Memory at fe029000 (32-bit, non-prefetchable) [size=4K]
I/O ports at b400 [size=8]
Capabilities: [44] Power Management version 2
00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
(prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 00009000-00009fff
Memory behind bridge: fdd00000-fddfffff
Prefetchable memory behind bridge:
00000000fdc00000-00000000fdc00000
Capabilities: [40] Power Management version 2
Capabilities: [48] Message Signalled Interrupts: 64bit+
Queue=0/1 Enable+
Capabilities: [58] HyperTransport: MSI Mapping
Capabilities: [80] Express Root Port (Slot+) IRQ 0
Capabilities: [100] Virtual Channel
00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
(prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 00008000-00008fff
Memory behind bridge: fdb00000-fdbfffff
Prefetchable memory behind bridge:
00000000fda00000-00000000fda00000
Capabilities: [40] Power Management version 2
Capabilities: [48] Message Signalled Interrupts: 64bit+
Queue=0/1 Enable+
Capabilities: [58] HyperTransport: MSI Mapping
Capabilities: [80] Express Root Port (Slot+) IRQ 0
Capabilities: [100] Virtual Channel
00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
(prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
I/O behind bridge: 00007000-00007fff
Memory behind bridge: fd900000-fd9fffff
Prefetchable memory behind bridge:
00000000fd800000-00000000fd800000
Capabilities: [40] Power Management version 2
Capabilities: [48] Message Signalled Interrupts: 64bit+
Queue=0/1 Enable+
Capabilities: [58] HyperTransport: MSI Mapping
Capabilities: [80] Express Root Port (Slot+) IRQ 0
Capabilities: [100] Virtual Channel
00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
(prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=05, subordinate=05, sec-latency=0
I/O behind bridge: 00006000-00006fff
Memory behind bridge: f4000000-fbffffff
Prefetchable memory behind bridge:
00000000d0000000-00000000dff00000
Capabilities: [40] Power Management version 2
Capabilities: [48] Message Signalled Interrupts: 64bit+
Queue=0/1 Enable+
Capabilities: [58] HyperTransport: MSI Mapping
Capabilities: [80] Express Root Port (Slot+) IRQ 0
Capabilities: [100] Virtual Channel
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration
Flags: fast devsel
Capabilities: [80] HyperTransport: Host or Secondary Interface
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Address Map
Flags: fast devsel
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
DRAM Controller
Flags: fast devsel
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Miscellaneous Control
Flags: fast devsel
01:08.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev
06)
Subsystem: Creative Labs CT4832 SBLive! Value
Flags: bus master, medium devsel, latency 32, IRQ 58
I/O ports at ac00 [size=32]
Capabilities: [dc] Power Management version 1
01:08.1 Input device controller: Creative Labs SB Live! Game Port (rev
06)
Subsystem: Creative Labs Gameport Joystick
Flags: bus master, medium devsel, latency 32
I/O ports at a800 [size=8]
Capabilities: [dc] Power Management version 1
05:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce
6600] (rev a2) (prog-if 00 [VGA])
Flags: bus master, fast devsel, latency 0, IRQ 58
Memory at f4000000 (32-bit, non-prefetchable) [size=64M]
Memory at d0000000 (64-bit, prefetchable) [size=256M]
Memory at fa000000 (64-bit, non-prefetchable) [size=16M]
[virtual] Expansion ROM at f8000000 [disabled] [size=128K]
Capabilities: [60] Power Management version 2
Capabilities: [68] Message Signalled Interrupts: 64bit+
Queue=0/0 Enable-
Capabilities: [78] Express Endpoint IRQ 0
Capabilities: [100] Virtual Channel
Capabilities: [128] Power Budgeting
--
Martin Filip
e-mail: [email protected]
ICQ#: 31531391
jabber: [email protected]
www: http://www.smoula.net
_________________________________________
/ BOFH Excuse #230: Lusers learning curve \
\ appears to be fractal /
-----------------------------------------
\ ,__,
\ (oo)____
(__) )\
||--|| *
On Wednesday 27 September 2006 18:50, Martin Filip wrote:
> Hi to LKML,
>
> I'm experiencing some troubles with WOL with my nForce NIC.
> The problem is simple - after setting WOL mode to magic packet my PC
> won't wake up. I've noticed there were some changes about this in new
> kernel, but no luck for me.
>
> I'm using 2.6.18 kernel, vanilla. I've tried this with Windows Vista RC1
> (build 5600) and WOL works correctly. My NIC is integrated on MSI K8N
> Neo4-FI
On my nForce4 CK804 it's disabled by default, I bet this is your problem:
[root] 19:33 [~] ethtool lan
Settings for lan:
Supported ports: [ MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: external
Auto-negotiation: on
Supports Wake-on: g
Wake-on: d
Link detected: yes
Read the manpage for ethtool. HTH.
--
Cheers,
Alistair.
Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
On 2006.09.27 19:50:41 +0200, Martin Filip wrote:
> Hi to LKML,
>
> I'm experiencing some troubles with WOL with my nForce NIC.
> The problem is simple - after setting WOL mode to magic packet my PC
> won't wake up. I've noticed there were some changes about this in new
> kernel, but no luck for me.
>
> I'm using 2.6.18 kernel, vanilla. I've tried this with Windows Vista RC1
> (build 5600) and WOL works correctly. My NIC is integrated on MSI K8N
> Neo4-FI
>
> Is there any way how can I help with developement of this feature?
Did you check that WOL was enabled? I need to re-activate it after each
boot (I guess that's normal, not sure though).
The output of "ethtool eth0" should show:
Supports Wake-on: g
Wake-on: g
Also, I remember a bugzilla entry in which it was said that the MAC was
somehow reversed by the driver. I that is still the case (I can't find
the bugzilla entry right now), you might just reverse the MAC address in
your WOL packet to workaround the bug.
HTH
Bj?rn
Hi,
no.. I don't think it's my problem
# ethtool eth0
Settings for eth0:
Supported ports: [ MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: external
Auto-negotiation: on
Supports Wake-on: g
Wake-on: g
Link detected: yes
Alistair John Strachan p??e v St 27. 09. 2006 v 19:35 +0100:
> On Wednesday 27 September 2006 18:50, Martin Filip wrote:
> > Hi to LKML,
> >
> > I'm experiencing some troubles with WOL with my nForce NIC.
> > The problem is simple - after setting WOL mode to magic packet my PC
> > won't wake up. I've noticed there were some changes about this in new
> > kernel, but no luck for me.
> >
> > I'm using 2.6.18 kernel, vanilla. I've tried this with Windows Vista RC1
> > (build 5600) and WOL works correctly. My NIC is integrated on MSI K8N
> > Neo4-FI
>
> On my nForce4 CK804 it's disabled by default, I bet this is your problem:
>
> [root] 19:33 [~] ethtool lan
> Settings for lan:
> Supported ports: [ MII ]
> Supported link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Full
> Supports auto-negotiation: Yes
> Advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Full
> Advertised auto-negotiation: Yes
> Speed: 100Mb/s
> Duplex: Full
> Port: MII
> PHYAD: 1
> Transceiver: external
> Auto-negotiation: on
> Supports Wake-on: g
> Wake-on: d
> Link detected: yes
>
> Read the manpage for ethtool. HTH.
>
--
Martin Filip
e-mail: [email protected]
ICQ#: 31531391
jabber: [email protected]
www: http://www.smoula.net
_______________________________________
/ BOFH Excuse #410: Electrical conduits \
\ in machine room are melting. /
---------------------------------------
\ ,__,
\ (oo)____
(__) )\
||--|| *
Hi,
Bj?rn Steinbrink p??e v St 27. 09. 2006 v 20:38 +0200:
> Did you check that WOL was enabled? I need to re-activate it after each
> boot (I guess that's normal, not sure though).
> The output of "ethtool eth0" should show:
>
> Supports Wake-on: g
> Wake-on: g
>
Yes, of course :)
> Also, I remember a bugzilla entry in which it was said that the MAC was
> somehow reversed by the driver. I that is still the case (I can't find
> the bugzilla entry right now), you might just reverse the MAC address in
> your WOL packet to workaround the bug.
Hey! this is really crazy :) but it works! To bo honest - I really do
not know what crazy bug could cause problems like this. I thought it's
NIC thing to manage all the work about WOL. I thought OS only sets NIC
into "WOL mode".
But seeing this - one packet for windows and one magic packet for linux
driver - I really do not get it.
--
Martin Filip
e-mail: [email protected]
ICQ#: 31531391
jabber: [email protected]
www: http://www.smoula.net
_________________________________________
/ BOFH Excuse #338: old inkjet cartridges \
\ emanate barium-based fumes /
-----------------------------------------
\ ,__,
\ (oo)____
(__) )\
||--|| *
Martin Filip <[email protected]> :
[...]
> no.. I don't think it's my problem
Is is similar to http://bugzilla.kernel.org/show_bug.cgi?id=6398 ?
--
Ueimor
On Wed, Sep 27, 2006 at 10:48:45PM +0200, Francois Romieu wrote:
> Martin Filip <[email protected]> :
> [...]
> > no.. I don't think it's my problem
>
> Is is similar to http://bugzilla.kernel.org/show_bug.cgi?id=6398 ?
Shot in the dark, but do either the cited bug or the one reported
in this thread exhibit the "MAC address byte swapping" behavior to
which forcedeth is prone?
Just checkin'...
John
--
John W. Linville
[email protected]
On Wed, 27 Sep 2006 22:38:06 +0200
Martin Filip <[email protected]> wrote:
> Hi,
>
> Bj__rn Steinbrink p____e v St 27. 09. 2006 v 20:38 +0200:
>
> > Did you check that WOL was enabled? I need to re-activate it after each
> > boot (I guess that's normal, not sure though).
> > The output of "ethtool eth0" should show:
> >
> > Supports Wake-on: g
> > Wake-on: g
> >
> Yes, of course :)
>
> > Also, I remember a bugzilla entry in which it was said that the MAC was
> > somehow reversed by the driver. I that is still the case (I can't find
> > the bugzilla entry right now), you might just reverse the MAC address in
> > your WOL packet to workaround the bug.
>
> Hey! this is really crazy :) but it works! To bo honest - I really do
> not know what crazy bug could cause problems like this. I thought it's
> NIC thing to manage all the work about WOL. I thought OS only sets NIC
> into "WOL mode".
>
> But seeing this - one packet for windows and one magic packet for linux
> driver - I really do not get it.
>
Are you saying that byte-reversing the MAC address make WOL work correctly?
What tool do you use to send the packet, and how is it being invoked?
Do we know if this reversal *always* happens with this driver, or only
sometimes?
Thanks.
Hi Andrew,
On 2006.09.27 16:57:04 -0700, Andrew Morton wrote:
> On Wed, 27 Sep 2006 22:38:06 +0200
> Martin Filip <[email protected]> wrote:
>
> > Hi,
> >
> > Bj__rn Steinbrink p____e v St 27. 09. 2006 v 20:38 +0200:
> >
> > > Did you check that WOL was enabled? I need to re-activate it after each
> > > boot (I guess that's normal, not sure though).
> > > The output of "ethtool eth0" should show:
> > >
> > > Supports Wake-on: g
> > > Wake-on: g
> > >
> > Yes, of course :)
> >
> > > Also, I remember a bugzilla entry in which it was said that the MAC was
> > > somehow reversed by the driver. I that is still the case (I can't find
> > > the bugzilla entry right now), you might just reverse the MAC address in
> > > your WOL packet to workaround the bug.
> >
> > Hey! this is really crazy :) but it works! To bo honest - I really do
> > not know what crazy bug could cause problems like this. I thought it's
> > NIC thing to manage all the work about WOL. I thought OS only sets NIC
> > into "WOL mode".
> >
> > But seeing this - one packet for windows and one magic packet for linux
> > driver - I really do not get it.
> >
>
> Are you saying that byte-reversing the MAC address make WOL work correctly?
>
> What tool do you use to send the packet, and how is it being invoked?
>
> Do we know if this reversal *always* happens with this driver, or only
> sometimes?
>
> Thanks.
searching bugzilla was more succesful this time (somehow bugzillas hate
me, so I need a bunch of tries every time), the bug I meant was #6604.
The bugreport says that it should work with 0.57 though (which is in
2.6.18 AFAICT), I'll go and see if it works for me...
Bj?rn
On 2006.09.28 02:04:48 +0200, Bj?rn Steinbrink wrote:
>
> Hi Andrew,
>
>
> On 2006.09.27 16:57:04 -0700, Andrew Morton wrote:
> > On Wed, 27 Sep 2006 22:38:06 +0200
> > Martin Filip <[email protected]> wrote:
> >
> > > Hi,
> > >
> > > Bj__rn Steinbrink p____e v St 27. 09. 2006 v 20:38 +0200:
> > >
> > > > Did you check that WOL was enabled? I need to re-activate it after each
> > > > boot (I guess that's normal, not sure though).
> > > > The output of "ethtool eth0" should show:
> > > >
> > > > Supports Wake-on: g
> > > > Wake-on: g
> > > >
> > > Yes, of course :)
> > >
> > > > Also, I remember a bugzilla entry in which it was said that the MAC was
> > > > somehow reversed by the driver. I that is still the case (I can't find
> > > > the bugzilla entry right now), you might just reverse the MAC address in
> > > > your WOL packet to workaround the bug.
> > >
> > > Hey! this is really crazy :) but it works! To bo honest - I really do
> > > not know what crazy bug could cause problems like this. I thought it's
> > > NIC thing to manage all the work about WOL. I thought OS only sets NIC
> > > into "WOL mode".
> > >
> > > But seeing this - one packet for windows and one magic packet for linux
> > > driver - I really do not get it.
> > >
> >
> > Are you saying that byte-reversing the MAC address make WOL work correctly?
> >
> > What tool do you use to send the packet, and how is it being invoked?
> >
> > Do we know if this reversal *always* happens with this driver, or only
> > sometimes?
> >
> > Thanks.
>
> searching bugzilla was more succesful this time (somehow bugzillas hate
> me, so I need a bunch of tries every time), the bug I meant was #6604.
>
> The bugreport says that it should work with 0.57 though (which is in
> 2.6.18 AFAICT), I'll go and see if it works for me...
... 5 reboots later ...
It still breaks with 2.6.18.
Not touching WOL from Linux at all, rebooting and turning the box off
during POST, WOL works using the real MAC address.
Booting 2.16.17.x or 2.6.18, turning on WOL and finally shutting down
the box, I need to send the WOL packet with the MAC address reversed.
Bj?rn
On 2006.09.28 02:40:53 +0200, Bj?rn Steinbrink wrote:
> On 2006.09.28 02:04:48 +0200, Bj?rn Steinbrink wrote:
> >
> > Hi Andrew,
> >
> >
> > On 2006.09.27 16:57:04 -0700, Andrew Morton wrote:
> > > On Wed, 27 Sep 2006 22:38:06 +0200
> > > Martin Filip <[email protected]> wrote:
> > >
> > > > Hi,
> > > >
> > > > Bj__rn Steinbrink p____e v St 27. 09. 2006 v 20:38 +0200:
> > > >
> > > > > Did you check that WOL was enabled? I need to re-activate it after each
> > > > > boot (I guess that's normal, not sure though).
> > > > > The output of "ethtool eth0" should show:
> > > > >
> > > > > Supports Wake-on: g
> > > > > Wake-on: g
> > > > >
> > > > Yes, of course :)
> > > >
> > > > > Also, I remember a bugzilla entry in which it was said that the MAC was
> > > > > somehow reversed by the driver. I that is still the case (I can't find
> > > > > the bugzilla entry right now), you might just reverse the MAC address in
> > > > > your WOL packet to workaround the bug.
> > > >
> > > > Hey! this is really crazy :) but it works! To bo honest - I really do
> > > > not know what crazy bug could cause problems like this. I thought it's
> > > > NIC thing to manage all the work about WOL. I thought OS only sets NIC
> > > > into "WOL mode".
> > > >
> > > > But seeing this - one packet for windows and one magic packet for linux
> > > > driver - I really do not get it.
> > > >
> > >
> > > Are you saying that byte-reversing the MAC address make WOL work correctly?
> > >
> > > What tool do you use to send the packet, and how is it being invoked?
As I like replying to myself, I of course intentionally forgot to answer
this question... *sigh*
I used etherwake this time, but tried with a self-made tool (which works
with my Broadcom NIC) when I discovered the bug report.
etherwake 01:23:45:67:89:ab -- works when I shutdown during POST
etherwake ab:89:67:45:23:01 -- works when WOL was enabled with ethtool
> > > Do we know if this reversal *always* happens with this driver, or only
> > > sometimes?
I only tried 2.6.18 twice this time, but when I wrote my own tool to do
it, I had probably 20-30 power on -> ethtool -> poweroff cycles before I
decided to look into Bugzilla. As it looked like being fixed already and
I did use the nForce NIC for testing only, I didn't spend any further
time on it back then.
Regards,
Bj?rn
On Thu, 28 Sep 2006 02:40:53 +0200
Bj__rn Steinbrink <[email protected]> wrote:
> On 2006.09.28 02:04:48 +0200, Bj__rn Steinbrink wrote:
> >
> > Hi Andrew,
> >
> >
> > On 2006.09.27 16:57:04 -0700, Andrew Morton wrote:
> > > On Wed, 27 Sep 2006 22:38:06 +0200
> > > Martin Filip <[email protected]> wrote:
> > >
> > > > Hi,
> > > >
> > > > Bj__rn Steinbrink p____e v St 27. 09. 2006 v 20:38 +0200:
> > > >
> > > > > Did you check that WOL was enabled? I need to re-activate it after each
> > > > > boot (I guess that's normal, not sure though).
> > > > > The output of "ethtool eth0" should show:
> > > > >
> > > > > Supports Wake-on: g
> > > > > Wake-on: g
> > > > >
> > > > Yes, of course :)
> > > >
> > > > > Also, I remember a bugzilla entry in which it was said that the MAC was
> > > > > somehow reversed by the driver. I that is still the case (I can't find
> > > > > the bugzilla entry right now), you might just reverse the MAC address in
> > > > > your WOL packet to workaround the bug.
> > > >
> > > > Hey! this is really crazy :) but it works! To bo honest - I really do
> > > > not know what crazy bug could cause problems like this. I thought it's
> > > > NIC thing to manage all the work about WOL. I thought OS only sets NIC
> > > > into "WOL mode".
> > > >
> > > > But seeing this - one packet for windows and one magic packet for linux
> > > > driver - I really do not get it.
> > > >
> > >
> > > Are you saying that byte-reversing the MAC address make WOL work correctly?
> > >
> > > What tool do you use to send the packet, and how is it being invoked?
> > >
> > > Do we know if this reversal *always* happens with this driver, or only
> > > sometimes?
> > >
> > > Thanks.
> >
> > searching bugzilla was more succesful this time (somehow bugzillas hate
> > me, so I need a bunch of tries every time), the bug I meant was #6604.
> >
> > The bugreport says that it should work with 0.57 though (which is in
> > 2.6.18 AFAICT), I'll go and see if it works for me...
>
> ... 5 reboots later ...
>
> It still breaks with 2.6.18.
>
> Not touching WOL from Linux at all, rebooting and turning the box off
> during POST, WOL works using the real MAC address.
>
> Booting 2.16.17.x or 2.6.18, turning on WOL and finally shutting down
> the box, I need to send the WOL packet with the MAC address reversed.
>
Could I re-ask these questions?
Are you saying that byte-reversing the MAC address make WOL work correctly?
What tool do you use to send the packet, and how is it being invoked?
Do we know if this reversal *always* happens with this driver, or only
sometimes?
On Thu, 28 Sep 2006 03:01:33 +0200
Bj?rn Steinbrink <[email protected]> wrote:
> On 2006.09.28 02:40:53 +0200, Bj?rn Steinbrink wrote:
> > On 2006.09.28 02:04:48 +0200, Bj?rn Steinbrink wrote:
> > >
> > > Hi Andrew,
> > >
> > >
> > > On 2006.09.27 16:57:04 -0700, Andrew Morton wrote:
> > > > On Wed, 27 Sep 2006 22:38:06 +0200
> > > > Martin Filip <[email protected]> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Bj__rn Steinbrink p____e v St 27. 09. 2006 v 20:38 +0200:
> > > > >
> > > > > > Did you check that WOL was enabled? I need to re-activate it after each
> > > > > > boot (I guess that's normal, not sure though).
> > > > > > The output of "ethtool eth0" should show:
> > > > > >
> > > > > > Supports Wake-on: g
> > > > > > Wake-on: g
> > > > > >
> > > > > Yes, of course :)
> > > > >
> > > > > > Also, I remember a bugzilla entry in which it was said that the MAC was
> > > > > > somehow reversed by the driver. I that is still the case (I can't find
> > > > > > the bugzilla entry right now), you might just reverse the MAC address in
> > > > > > your WOL packet to workaround the bug.
> > > > >
> > > > > Hey! this is really crazy :) but it works! To bo honest - I really do
> > > > > not know what crazy bug could cause problems like this. I thought it's
> > > > > NIC thing to manage all the work about WOL. I thought OS only sets NIC
> > > > > into "WOL mode".
> > > > >
> > > > > But seeing this - one packet for windows and one magic packet for linux
> > > > > driver - I really do not get it.
> > > > >
> > > >
> > > > Are you saying that byte-reversing the MAC address make WOL work correctly?
> > > >
> > > > What tool do you use to send the packet, and how is it being invoked?
>
> As I like replying to myself, I of course intentionally forgot to answer
> this question... *sigh*
>
> I used etherwake this time, but tried with a self-made tool (which works
> with my Broadcom NIC) when I discovered the bug report.
>
> etherwake 01:23:45:67:89:ab -- works when I shutdown during POST
> etherwake ab:89:67:45:23:01 -- works when WOL was enabled with ethtool
OK, I use etherwake too.
> > > > Do we know if this reversal *always* happens with this driver, or only
> > > > sometimes?
>
> I only tried 2.6.18 twice this time, but when I wrote my own tool to do
> it, I had probably 20-30 power on -> ethtool -> poweroff cycles before I
> decided to look into Bugzilla. As it looked like being fixed already and
> I did use the nForce NIC for testing only, I didn't spend any further
> time on it back then.
What I'm angling towards is: "is this just a driver bug"?
On 2006.09.27 18:36:25 -0700, Andrew Morton wrote:
> On Thu, 28 Sep 2006 03:01:33 +0200
> Bj?rn Steinbrink <[email protected]> wrote:
>
> > > > > Do we know if this reversal *always* happens with this driver, or only
> > > > > sometimes?
> >
> > I only tried 2.6.18 twice this time, but when I wrote my own tool to do
> > it, I had probably 20-30 power on -> ethtool -> poweroff cycles before I
> > decided to look into Bugzilla. As it looked like being fixed already and
> > I did use the nForce NIC for testing only, I didn't spend any further
> > time on it back then.
>
> What I'm angling towards is: "is this just a driver bug"?
I just took a peek at the code.
The version on bugzilla (last attachment, comment #22), which was
reported to work correctly, has the MAC address reversal hardcoded.
The driver in 2.6.18 has some logic to detect if it should reverse the
MAC address. So it looks like a hardware oddity/bug that the driver
wants to fix but fails. I'll see what happens if I force address
reversal and if I can decipher anything, but probably someone else will
have to cast the runes...
Bj?rn
On 2006.09.28 04:04:38 +0200, Bj?rn Steinbrink wrote:
> On 2006.09.27 18:36:25 -0700, Andrew Morton wrote:
> > On Thu, 28 Sep 2006 03:01:33 +0200
> > Bj?rn Steinbrink <[email protected]> wrote:
> >
> > > > > > Do we know if this reversal *always* happens with this driver, or only
> > > > > > sometimes?
> > >
> > > I only tried 2.6.18 twice this time, but when I wrote my own tool to do
> > > it, I had probably 20-30 power on -> ethtool -> poweroff cycles before I
> > > decided to look into Bugzilla. As it looked like being fixed already and
> > > I did use the nForce NIC for testing only, I didn't spend any further
> > > time on it back then.
> >
> > What I'm angling towards is: "is this just a driver bug"?
>
> I just took a peek at the code.
>
> The version on bugzilla (last attachment, comment #22), which was
> reported to work correctly, has the MAC address reversal hardcoded.
> The driver in 2.6.18 has some logic to detect if it should reverse the
> MAC address. So it looks like a hardware oddity/bug that the driver
> wants to fix but fails. I'll see what happens if I force address
> reversal and if I can decipher anything, but probably someone else will
> have to cast the runes...
OK, please excuse me wasting your time, it's late over here... I've
actually been looking at Linus' git tree (pulled yesterday) while
writing that mail, not 2.6.18.
2.6.18 does _not_ contain the address reversal detection.
Using the git tree instead of 2.6.18 WOL works as expected, without
having to reverse the MAC address.
Bj?rn
On Thu, 28 Sep 2006 04:24:47 +0200
Bj?rn Steinbrink <[email protected]> wrote:
> On 2006.09.28 04:04:38 +0200, Bj?rn Steinbrink wrote:
> > On 2006.09.27 18:36:25 -0700, Andrew Morton wrote:
> > > On Thu, 28 Sep 2006 03:01:33 +0200
> > > Bj?rn Steinbrink <[email protected]> wrote:
> > >
> > > > > > > Do we know if this reversal *always* happens with this driver, or only
> > > > > > > sometimes?
> > > >
> > > > I only tried 2.6.18 twice this time, but when I wrote my own tool to do
> > > > it, I had probably 20-30 power on -> ethtool -> poweroff cycles before I
> > > > decided to look into Bugzilla. As it looked like being fixed already and
> > > > I did use the nForce NIC for testing only, I didn't spend any further
> > > > time on it back then.
> > >
> > > What I'm angling towards is: "is this just a driver bug"?
> >
> > I just took a peek at the code.
> >
> > The version on bugzilla (last attachment, comment #22), which was
> > reported to work correctly, has the MAC address reversal hardcoded.
> > The driver in 2.6.18 has some logic to detect if it should reverse the
> > MAC address. So it looks like a hardware oddity/bug that the driver
> > wants to fix but fails. I'll see what happens if I force address
> > reversal and if I can decipher anything, but probably someone else will
> > have to cast the runes...
>
> OK, please excuse me wasting your time, it's late over here... I've
> actually been looking at Linus' git tree (pulled yesterday) while
> writing that mail, not 2.6.18.
> 2.6.18 does _not_ contain the address reversal detection.
> Using the git tree instead of 2.6.18 WOL works as expected, without
> having to reverse the MAC address.
>
hm, OK, thanks. Ayaz, do you think 5070d3408405ae1941f259acac7a9882045c3be4 is
a suitable thing for 2.6.18.x?
> > > I just took a peek at the code.
> > >
> > > The version on bugzilla (last attachment, comment #22), which was
> > > reported to work correctly, has the MAC address reversal hardcoded.
> > > The driver in 2.6.18 has some logic to detect if it should reverse the
> > > MAC address. So it looks like a hardware oddity/bug that the driver
> > > wants to fix but fails. I'll see what happens if I force address
> > > reversal and if I can decipher anything, but probably someone else will
> > > have to cast the runes...
> >
> > OK, please excuse me wasting your time, it's late over here... I've
> > actually been looking at Linus' git tree (pulled yesterday) while
> > writing that mail, not 2.6.18.
> > 2.6.18 does _not_ contain the address reversal detection.
> > Using the git tree instead of 2.6.18 WOL works as expected, without
> > having to reverse the MAC address.
> >
>
> hm, OK, thanks. Ayaz, do you think 5070d3408405ae1941f259acac7a9882045c3be4 is
> a suitable thing for 2.6.18.x?
Hi,
you never sleep guys, do you :) I've just tried patch from bugzilla.
(here is version twaked to be usable with 2.6.18
http://www.smoula.net/download/forcedeth.c) and it looks like it's
working correctly with correct ordered MAC.
--
Martin Filip
e-mail: [email protected]
ICQ#: 31531391
jabber: [email protected]
www: http://www.smoula.net
_______________________________
< BOFH Excuse #100: IRQ dropout >
-------------------------------
\ ,__,
\ (oo)____
(__) )\
||--|| *
-----Original Message-----
From: Andrew Morton [mailto:[email protected]]
Sent: Wednesday, September 27, 2006 8:39 PM
To: Bj?rn Steinbrink
Cc: Martin Filip; [email protected]; Ayaz Abdulla; [email protected]
Subject: Re: forcedeth - WOL [SOLVED]
On Thu, 28 Sep 2006 04:24:47 +0200
Bj?rn Steinbrink <[email protected]> wrote:
> On 2006.09.28 04:04:38 +0200, Bj?rn Steinbrink wrote:
> > On 2006.09.27 18:36:25 -0700, Andrew Morton wrote:
> > > On Thu, 28 Sep 2006 03:01:33 +0200
> > > Bj?rn Steinbrink <[email protected]> wrote:
> > >
> > > > > > > Do we know if this reversal *always* happens with this
> > > > > > > driver, or only sometimes?
> > > >
> > > > I only tried 2.6.18 twice this time, but when I wrote my own
> > > > tool to do it, I had probably 20-30 power on -> ethtool ->
> > > > poweroff cycles before I decided to look into Bugzilla. As it
> > > > looked like being fixed already and I did use the nForce NIC for
> > > > testing only, I didn't spend any further time on it back then.
> > >
> > > What I'm angling towards is: "is this just a driver bug"?
> >
> > I just took a peek at the code.
> >
> > The version on bugzilla (last attachment, comment #22), which was
> > reported to work correctly, has the MAC address reversal hardcoded.
> > The driver in 2.6.18 has some logic to detect if it should reverse
> > the MAC address. So it looks like a hardware oddity/bug that the
> > driver wants to fix but fails. I'll see what happens if I force
> > address reversal and if I can decipher anything, but probably
> > someone else will have to cast the runes...
>
> OK, please excuse me wasting your time, it's late over here... I've
> actually been looking at Linus' git tree (pulled yesterday) while
> writing that mail, not 2.6.18. 2.6.18 does _not_ contain the address
> reversal detection. Using the git tree instead of 2.6.18 WOL works as
> expected, without having to reverse the MAC address.
>
hm, OK, thanks. Ayaz, do you think 5070d3408405ae1941f259acac7a9882045c3be4 is a suitable thing for 2.6.18.x?
There are a few forcedeth patches (mac addr, NAPI, cleanup, etc) in that commit list and the mac address changes could be put into 2.6.18.x
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------