Re: [patch 0/6] sky2 driver update (v1.11)
On Sat, 13 Jan 2007 14:03:29 +0100 Tino Keitel [EMAIL PROTECTED] wrote: On Tue, Jan 02, 2007 at 20:10:15 +0100, Tino Keitel wrote: [...] Btw., I just built 2.6.20-rc3 with patches 4 and 5 and wake on LAN now works. Thanks for your work. Hi, I had some failures during resume from suspend with 2.6.20-rc3 and -rc4. I enabled pm_trace and it looks like the sky2 driver is the culprit: hash matches drivers/base/power/resume.c:56 hash matches device :01:00.0 $ lspci | grep 01:00.0 01:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 22) I removed the patches and had no resume failure so far. Regards, Tino What kind of failures, did the system just not come up? Did you have WOL enabled or not? The new code checks for pci_ errors on resume and it could be that the errors were always there. -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/6] sky2 driver update (v1.11)
On Mon, Jan 15, 2007 at 10:21:49 -0800, Stephen Hemminger wrote: On Sat, 13 Jan 2007 14:03:29 +0100 Tino Keitel [EMAIL PROTECTED] wrote: On Tue, Jan 02, 2007 at 20:10:15 +0100, Tino Keitel wrote: [...] Btw., I just built 2.6.20-rc3 with patches 4 and 5 and wake on LAN now works. Thanks for your work. Hi, I had some failures during resume from suspend with 2.6.20-rc3 and -rc4. I enabled pm_trace and it looks like the sky2 driver is the culprit: hash matches drivers/base/power/resume.c:56 hash matches device :01:00.0 $ lspci | grep 01:00.0 01:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 22) I removed the patches and had no resume failure so far. Regards, Tino What kind of failures, did the system just not come up? Yes, screen stayed dark and machine was dead. However, it was hardly reproducable. I set up a suspend/resume loop for an hour without failures. Then, when I just wanted to suspend for a while, resume failed. Did you have WOL enabled or not? I had WOL enabled. Regards, Tino - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/6] sky2 driver update (v1.11)
On Tue, Jan 02, 2007 at 20:10:15 +0100, Tino Keitel wrote: [...] Btw., I just built 2.6.20-rc3 with patches 4 and 5 and wake on LAN now works. Thanks for your work. Hi, I had some failures during resume from suspend with 2.6.20-rc3 and -rc4. I enabled pm_trace and it looks like the sky2 driver is the culprit: hash matches drivers/base/power/resume.c:56 hash matches device :01:00.0 $ lspci | grep 01:00.0 01:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 22) I removed the patches and had no resume failure so far. Regards, Tino - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/6] sky2 driver update (v1.11)
On Tue, 26 Dec 2006 16:44:24 -0500 Jeff Garzik [EMAIL PROTECTED] wrote: Stephen Hemminger wrote: Patches are in order of severity. 1-3 are bug fixes, 4 is a cleanup of the power state code, and 5 adds wake on lan support. IMHO, it is bad security policy to allow wake on lan to enabled by default. The sky2 driver doesn't do WOL until enabled with ethtool. While in general I agree with you on the security principle, this seems like it might break working setups. WOL is a partnership between the motherboard and NIC. The motherboard must support WOL, or its useless. And since the motherboard must support WOL, it normally has an on/off switch in BIOS. As such, you're overriding the admin's chosen BIOS setting here. Jeff But there is no way to read the BIOS settings. If BIOS was being smart enough to actually, setup the chip, then I can look at chip registers on startup and see if it is enabled there. -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/6] sky2 driver update (v1.11)
On Mon, Jan 01, 2007 at 10:36:44 -0800, Stephen Hemminger wrote: On Tue, 26 Dec 2006 16:44:24 -0500 Jeff Garzik [EMAIL PROTECTED] wrote: Stephen Hemminger wrote: Patches are in order of severity. 1-3 are bug fixes, 4 is a cleanup of the power state code, and 5 adds wake on lan support. IMHO, it is bad security policy to allow wake on lan to enabled by default. The sky2 driver doesn't do WOL until enabled with ethtool. While in general I agree with you on the security principle, this seems like it might break working setups. WOL is a partnership between the motherboard and NIC. The motherboard must support WOL, or its useless. And since the motherboard must support WOL, it normally has an on/off switch in BIOS. As such, you're overriding the admin's chosen BIOS setting here. Jeff But there is no way to read the BIOS settings. If BIOS was being smart enough to actually, setup the chip, then I can look at chip registers on startup and see if it is enabled there. Some computers even don't have such a BIOS settings (like my Mac mini). Btw., I just built 2.6.20-rc3 with patches 4 and 5 and wake on LAN now works. Thanks for your work. Regards, Tino - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/6] sky2 driver update (v1.11)
IMHO, it is bad security policy to allow wake on lan to enabled by default. The sky2 driver doesn't do WOL until enabled with ethtool. While in general I agree with you on the security principle, this seems like it might break working setups. WOL is a partnership between the motherboard and NIC. The motherboard must support WOL, or its useless. And since the motherboard must support WOL, it normally has an on/off switch in BIOS. As such, you're overriding the admin's chosen BIOS setting here. But there is no way to read the BIOS settings. true. If BIOS was being smart enough to actually, setup the chip, then I can look at chip registers on startup and see if it is enabled there. If the BIOS doesn't setup the chip, WOL won't work if you plug in the power cord (instead of just using atx poweroff) and is thus nearly useless. Correct? So I'd propose to read the chip registers and set them to the state they were in on bootup. Kind regards, Gerd - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/6] sky2 driver update (v1.11)
Stephen Hemminger wrote: Patches are in order of severity. 1-3 are bug fixes, 4 is a cleanup of the power state code, and 5 adds wake on lan support. IMHO, it is bad security policy to allow wake on lan to enabled by default. The sky2 driver doesn't do WOL until enabled with ethtool. While in general I agree with you on the security principle, this seems like it might break working setups. WOL is a partnership between the motherboard and NIC. The motherboard must support WOL, or its useless. And since the motherboard must support WOL, it normally has an on/off switch in BIOS. As such, you're overriding the admin's chosen BIOS setting here. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 0/6] sky2 driver update (v1.11)
Patches are in order of severity. 1-3 are bug fixes, 4 is a cleanup of the power state code, and 5 adds wake on lan support. IMHO, it is bad security policy to allow wake on lan to enabled by default. The sky2 driver doesn't do WOL until enabled with ethtool. -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html