Bug 171744
| Summary: | [PATCH] Fix wake(8) command not sending proper WOL packet | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Stephen Workman <workman.stephen> | ||||||||||
| Component: | kern | Assignee: | Cy Schubert <cy> | ||||||||||
| Status: | Closed DUPLICATE | ||||||||||||
| Severity: | Affects Only Me | CC: | hcb, hiren, net, sbruno, yongari | ||||||||||
| Priority: | Normal | ||||||||||||
| Version: | 9.0-RELEASE | ||||||||||||
| Hardware: | Any | ||||||||||||
| OS: | Any | ||||||||||||
| See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218579 | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Stephen Workman
2012-09-18 14:30:10 UTC
Responsible Changed From-To: freebsd-bugs->hiren Grab. Stephen, I just tried: wake <target_mac> wake <local_interface> <target_mac> and both worked just fine. Am I missing anything here? Are you experiencing any driver specific issues? cheers, Hiren It's been awhile but, I don't believe it's a driver issue. Probably more of a WOL implementation issue since there are various interpretations of how it's supposed to work. I know Linux' implementation uses the destination MAC rather than broadcasting. I have a few Windows machines I've tried to wake using the original version of FreeBSD's "wake" and neither responds - but they do when their own MAC is in the destination field of the ethernet frame. Perhaps a command line switch to alter the behaviour of wake? wake -d interface lladdr ... On Mon, May 13, 2013 at 7:05 PM, hiren panchasara <hiren@freebsd.org> wrote: > Stephen, > > I just tried: > wake <target_mac> > wake <local_interface> <target_mac> > > and both worked just fine. > > Am I missing anything here? Are you experiencing any driver specific > issues? > > cheers, > Hiren > Cy looked into WoL recently and I don't have the bandwidth/hardware. Created attachment 158062 [details]
WOL implementation for bge.
This patch works. The only caveat is that when the system is shut down, e.g. halt -p, it will reboot (even without the cable connected), after which you can power off for good. I'm not sure if my hardware (Acer laptop) is at fault or if I'm missing something in the patch. Other than that it works flawlessly.
Created attachment 158065 [details]
Same patch but for stable/10
WOL patch for stable/10 bge.
I can't say who is the master of bge(4) anymore. But if we can't get anyone to review this, I'll probably just commit it to head. (In reply to Sean Bruno from comment #7) I recall I got similar patches from various users, FreeBSD developers in the past. I'm afraid that WOL on Broadcom controllers require considerable amount of driver improvements before turning on PME in PCI configuration space. For instance, I think driver has to: - Make sure to let firmware know current driver state. Broadcom controllers with ASF/IPMI features require handshaking with the firmware for load/unload/reset/suspend/resume/wol events. - Not all controllers support WOL so it should explicitly enable WOL capability based on ASIC/Chip ids(i.e. Old controllers with TBI wouldn't work/support WOL) or firmware capability. - If WOL is activated for 1000baseT, it will draw too much current from PCI/PCIe bus which in turn will completely shutdown controller or shall damage your motherboard or controller. Even if the controller uses less current with 1000baseT link, it will consume much more power than 10/100Mbps link and it costs a lot if you have to manage large number of systems. AFAIK, Broadcom controllers seem to require manual speed down to 10/100Mbps before entering into WOL state. - Suspend/resume should be fixed before enabling WOL. You should be able to wake your box by sending a magic packet after suspend. bge(4) is one of few controllers that suspend/resume does not reliably work due to lack of publicly available firmware interface. I guess the hard part is to understand/know what are required steps to make firmware know various host driver state(i.e. reset, suspend, resume, wol etc) in different stage. It seems various bge(4) controllers require different firmware interactions and undocumented register accesses not to draw more current that mentioned in PCI specification. Unfortunately public data sheet is almost useless in this regard. It does not mention interactions between host driver and its firmware/APE. The patch may work on consumer grade controllers which lacks ASF/IPMI features but I think WOL shouldn't be blindly enabled for bge(4) controllers. If you limit WOL for specifically tested ASIC/Chip ids I'm fine with the patch though. Alternatively we can add a sysctl variable which controls driver's WOL (default off) and have end users control the feature. In that case we probably need a man update for possible damage on over-current triggered by WOL. As stated before the patch works but Pyun makes some good points. *** Bug 177184 has been marked as a duplicate of this bug. *** Created attachment 191146 [details]
Updated patch for if_bge.
This patch resolves the advertised speed issue. As per standard and recommended for bge cards it now listens at 100 Mb.
However the problem still remains that halt -p following WOL to boot the machine will result in reboot and not poweroff. (Though subsequent to normal reboot poweroff will work.)
DUP of 218579. *** This bug has been marked as a duplicate of bug 218579 *** |
