Bug 9721 - wake on lan fails with sky2 module
wake on lan fails with sky2 module
Status: RESOLVED PATCH_ALREADY_AVAILABLE
Product: Drivers
Classification: Unclassified
Component: Network
All Linux
: P1 normal
Assigned To: Jeff Garzik
:
Depends on:
Blocks: 9243
  Show dependency treegraph
 
Reported: 2008-01-09 13:05 UTC by Markus Doits
Modified: 2008-01-14 13:56 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.24-rc7
Tree: Mainline
Regression: Yes


Attachments
patches the reported issues in sky2 (patch by Stephen Hemminger) (2.03 KB, patch)
2008-01-14 13:56 UTC, Markus Doits
Details | Diff

Description Markus Doits 2008-01-09 13:05:32 UTC
Latest working kernel version: 2.6.23.12
Earliest failing kernel version: 2.6.24-rc6 (not tested earlier kernel, 2.6.24-rc7 still failing)
Distribution: Ubuntu 8.04 (but Kernel build from Kernel.org and system modifiet to make wake on lan work, i.e. network cards are not shutted down on poweroff)
Hardware Environment: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 20) onboard Asus P5W DH motherboard, uses module SKY2
Software Environment:
Problem Description:

When enabling wake on lan with: 'ethtool -s eth0 wol' i get the following status:

21:56:29 ~ # sudo ethtool eth0
Settings for eth0:
	Supported ports: [ TP ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Supports auto-negotiation: Yes
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Advertised auto-negotiation: Yes
	Speed: 100Mb/s
	Duplex: Full
	Port: Twisted Pair
	PHYAD: 0
	Transceiver: internal
	Auto-negotiation: on
	Supports Wake-on: pg
	Wake-on: g    <---- wol enabled
	Current message level: 0x000000ff (255)
	Link detected: yes

but after shutting down the pc doesn't wake up when magic packet is sent.

the status lights of the network card are still on (so the card seems to be online).

same system with only changed kernel to 2.6.23.12 and same procedure like above: wake on lan works.

Steps to reproduce: enable wol on your network card using SKY2 module and it doesn't work too?

if you need more information, just tell me, it's my first bug report.
regards
Comment 1 Anonymous Emailer 2008-01-09 16:03:03 UTC
Reply-To: akpm@linux-foundation.org


(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Wed,  9 Jan 2008 13:05:34 -0800 (PST)
bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=9721
> 
>            Summary: wake on lan fails with sky2 module
>            Product: ACPI
>            Version: 2.5
>      KernelVersion: 2.6.24-rc7
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: Power-Sleep-Wake
>         AssignedTo: acpi_power-sleep-wake@kernel-bugs.osdl.org
>         ReportedBy: supersud501@yahoo.de

This post-2.6.23 regression was assigned to ACPI but is quite possibly a
net driver problem?

> 
> Latest working kernel version: 2.6.23.12
> Earliest failing kernel version: 2.6.24-rc6 (not tested earlier kernel,
> 2.6.24-rc7 still failing)
> Distribution: Ubuntu 8.04 (but Kernel build from Kernel.org and system modifiet
> to make wake on lan work, i.e. network cards are not shutted down on poweroff)
> Hardware Environment: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit
> Ethernet Controller (rev 20) onboard Asus P5W DH motherboard, uses module SKY2
> Software Environment:
> Problem Description:
> 
> When enabling wake on lan with: 'ethtool -s eth0 wol' i get the following
> status:
> 
> 21:56:29 ~ # sudo ethtool eth0
> Settings for eth0:
>         Supported ports: [ TP ]
>         Supported link modes:   10baseT/Half 10baseT/Full 
>                                 100baseT/Half 100baseT/Full 
>                                 1000baseT/Half 1000baseT/Full 
>         Supports auto-negotiation: Yes
>         Advertised link modes:  10baseT/Half 10baseT/Full 
>                                 100baseT/Half 100baseT/Full 
>                                 1000baseT/Half 1000baseT/Full 
>         Advertised auto-negotiation: Yes
>         Speed: 100Mb/s
>         Duplex: Full
>         Port: Twisted Pair
>         PHYAD: 0
>         Transceiver: internal
>         Auto-negotiation: on
>         Supports Wake-on: pg
>         Wake-on: g    <---- wol enabled
>         Current message level: 0x000000ff (255)
>         Link detected: yes
> 
> but after shutting down the pc doesn't wake up when magic packet is sent.
> 
> the status lights of the network card are still on (so the card seems to be
> online).
> 
> same system with only changed kernel to 2.6.23.12 and same procedure like
> above: wake on lan works.
> 
> Steps to reproduce: enable wol on your network card using SKY2 module and it
> doesn't work too?
> 
> if you need more information, just tell me, it's my first bug report.
> regards
> 
> 
> -- 
> Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.

Comment 2 Len Brown 2008-01-10 17:32:26 UTC
it is possible to git-bisect to find the commit
that broke this between 2.6.23 and 2.6.24-rc?

Also, with 2.6.23 did WOL work with "acpi=off",
and if yes, does it still work with "acpi=off" in 2.6.24-rc?
Comment 3 Rafael J. Wysocki 2008-01-11 13:13:51 UTC
> http://bugzilla.kernel.org/show_bug.cgi?id=9721

On Friday, 11 of January 2008, supersud501 wrote:
> 
> Stephen Hemminger wrote:
> > On Wed, 9 Jan 2008 16:03:00 -0800
> > Andrew Morton <akpm@linux-foundation.org> wrote:
> > 
> >> (switched to email.  Please respond via emailed reply-to-all, not via the
> >> bugzilla web interface).
> >>
> >> On Wed,  9 Jan 2008 13:05:34 -0800 (PST)
> >> bugme-daemon@bugzilla.kernel.org wrote:
> >>
> >>> http://bugzilla.kernel.org/show_bug.cgi?id=9721
> >>>
> >>>            Summary: wake on lan fails with sky2 module
> >>>            Product: ACPI
> >>>            Version: 2.5
> >>>      KernelVersion: 2.6.24-rc7
> >>>           Platform: All
> >>>         OS/Version: Linux
> >>>               Tree: Mainline
> >>>             Status: NEW
> >>>           Severity: normal
> >>>           Priority: P1
> >>>          Component: Power-Sleep-Wake
> >>>         AssignedTo: acpi_power-sleep-wake@kernel-bugs.osdl.org
> >>>         ReportedBy: supersud501@yahoo.de
> >> This post-2.6.23 regression was assigned to ACPI but is quite possibly a
> >> net driver problem?
> >>
> >>> Latest working kernel version: 2.6.23.12
> >>> Earliest failing kernel version: 2.6.24-rc6 (not tested earlier kernel,
> >>> 2.6.24-rc7 still failing)
> >>> Distribution: Ubuntu 8.04 (but Kernel build from Kernel.org and system modifiet
> >>> to make wake on lan work, i.e. network cards are not shutted down on poweroff)
> >>> Hardware Environment: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit
> >>> Ethernet Controller (rev 20) onboard Asus P5W DH motherboard, uses module SKY2
> >>> Software Environment:
> >>> Problem Description:
> >>>
> >>> When enabling wake on lan with: 'ethtool -s eth0 wol' i get the following
> >>> status:
> >>>
> >>> 21:56:29 ~ # sudo ethtool eth0
> >>> Settings for eth0:
> >>>         Supported ports: [ TP ]
> >>>         Supported link modes:   10baseT/Half 10baseT/Full 
> >>>                                 100baseT/Half 100baseT/Full 
> >>>                                 1000baseT/Half 1000baseT/Full 
> >>>         Supports auto-negotiation: Yes
> >>>         Advertised link modes:  10baseT/Half 10baseT/Full 
> >>>                                 100baseT/Half 100baseT/Full 
> >>>                                 1000baseT/Half 1000baseT/Full 
> >>>         Advertised auto-negotiation: Yes
> >>>         Speed: 100Mb/s
> >>>         Duplex: Full
> >>>         Port: Twisted Pair
> >>>         PHYAD: 0
> >>>         Transceiver: internal
> >>>         Auto-negotiation: on
> >>>         Supports Wake-on: pg
> >>>         Wake-on: g    <---- wol enabled
> >>>         Current message level: 0x000000ff (255)
> >>>         Link detected: yes
> >>>
> >>> but after shutting down the pc doesn't wake up when magic packet is sent.
> >>>
> >>> the status lights of the network card are still on (so the card seems to be
> >>> online).
> >>>
> >>> same system with only changed kernel to 2.6.23.12 and same procedure like
> >>> above: wake on lan works.
> >>>
> >>> Steps to reproduce: enable wol on your network card using SKY2 module and it
> >>> doesn't work too?
> >>>
> >>> if you need more information, just tell me, it's my first bug report.
> >>> regards
> >>>
> > 
> > 
> > Wake from power off works on 2.6.24-rc7 for me.
> > Wake from suspend doesn't because Network Manager, HAL, or some other
> > user space tool gets confused.
> > 
> > I just rechecked it with Fujitsu Lifebook, which has sky2 (88E8055).
> > There many variations of this chip, and it maybe chip specific problem
> > or ACPI/BIOS issues.  If you don't enable Wake on Lan in BIOS, the
> > driver can't do it for you. Also, check how you are shutting down.
> > 
> > Also since the device has to restart the PHY, it could be a switch
> > issue if you have some fancy pants switch doing intrusion detection
> > or something, but I doubt that.
> > 
> > Is it a clean or fast shutdown, most distributions mark network
> > devices as down on shutdown, but if the distribution does something 
> > stupid like remove the driver module, then the driver is unable to setup Wake On Lan.
> > The wake on lan setup is done in one place in the driver, add
> > a printk to see if it is ever called.
> > 
> > 
> 
> 
> I tried ACPI wakeup with /proc/acpi/alarm (like i described in my last 
> mail) and it worked... so ACPI wakeup seems to work.
> 
> i'll try to do the printk-thing when i find some time to mess around 
> with the sources (maybe tomorrow). if someone has some brief 
> instructions (maybe a link to a helpfull site for kernel debugging) for 
> me i would be thankfull and could provide some more info faster.
> 
> some steps for me to identify the source of the problem (is it really 
> sky2?) would be really helpfull...

Please do the tests requested at:
http://bugzilla.kernel.org/show_bug.cgi?id=9721#c2,
thanks.

Comment 4 Markus Doits 2008-01-11 14:43:02 UTC

Rafael J. Wysocki wrote:
>> http://bugzilla.kernel.org/show_bug.cgi?id=9721
> 
> On Friday, 11 of January 2008, supersud501 wrote:
>> Stephen Hemminger wrote:
>>> On Wed, 9 Jan 2008 16:03:00 -0800
>>> Andrew Morton <akpm@linux-foundation.org> wrote:
>>>
>>>> (switched to email.  Please respond via emailed reply-to-all, not via the
>>>> bugzilla web interface).
>>>>
>>>> On Wed,  9 Jan 2008 13:05:34 -0800 (PST)
>>>> bugme-daemon@bugzilla.kernel.org wrote:
>>>>
>>>>> http://bugzilla.kernel.org/show_bug.cgi?id=9721
>>>>>
>>>>>            Summary: wake on lan fails with sky2 module
>>>>>            Product: ACPI
>>>>>            Version: 2.5
>>>>>      KernelVersion: 2.6.24-rc7
>>>>>           Platform: All
>>>>>         OS/Version: Linux
>>>>>               Tree: Mainline
>>>>>             Status: NEW
>>>>>           Severity: normal
>>>>>           Priority: P1
>>>>>          Component: Power-Sleep-Wake
>>>>>         AssignedTo: acpi_power-sleep-wake@kernel-bugs.osdl.org
>>>>>         ReportedBy: supersud501@yahoo.de
>>>> This post-2.6.23 regression was assigned to ACPI but is quite possibly a
>>>> net driver problem?
>>>>
>>>>> Latest working kernel version: 2.6.23.12
>>>>> Earliest failing kernel version: 2.6.24-rc6 (not tested earlier kernel,
>>>>> 2.6.24-rc7 still failing)
>>>>> Distribution: Ubuntu 8.04 (but Kernel build from Kernel.org and system modifiet
>>>>> to make wake on lan work, i.e. network cards are not shutted down on poweroff)
>>>>> Hardware Environment: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit
>>>>> Ethernet Controller (rev 20) onboard Asus P5W DH motherboard, uses module SKY2
>>>>> Software Environment:
>>>>> Problem Description:
>>>>>
>>>>> When enabling wake on lan with: 'ethtool -s eth0 wol' i get the following
>>>>> status:
>>>>>
>>>>> 21:56:29 ~ # sudo ethtool eth0
>>>>> Settings for eth0:
>>>>>         Supported ports: [ TP ]
>>>>>         Supported link modes:   10baseT/Half 10baseT/Full 
>>>>>                                 100baseT/Half 100baseT/Full 
>>>>>                                 1000baseT/Half 1000baseT/Full 
>>>>>         Supports auto-negotiation: Yes
>>>>>         Advertised link modes:  10baseT/Half 10baseT/Full 
>>>>>                                 100baseT/Half 100baseT/Full 
>>>>>                                 1000baseT/Half 1000baseT/Full 
>>>>>         Advertised auto-negotiation: Yes
>>>>>         Speed: 100Mb/s
>>>>>         Duplex: Full
>>>>>         Port: Twisted Pair
>>>>>         PHYAD: 0
>>>>>         Transceiver: internal
>>>>>         Auto-negotiation: on
>>>>>         Supports Wake-on: pg
>>>>>         Wake-on: g    <---- wol enabled
>>>>>         Current message level: 0x000000ff (255)
>>>>>         Link detected: yes
>>>>>
>>>>> but after shutting down the pc doesn't wake up when magic packet is sent.
>>>>>
>>>>> the status lights of the network card are still on (so the card seems to be
>>>>> online).
>>>>>
>>>>> same system with only changed kernel to 2.6.23.12 and same procedure like
>>>>> above: wake on lan works.
>>>>>
>>>>> Steps to reproduce: enable wol on your network card using SKY2 module and it
>>>>> doesn't work too?
>>>>>
>>>>> if you need more information, just tell me, it's my first bug report.
>>>>> regards
>>>>>
>>>
>>> Wake from power off works on 2.6.24-rc7 for me.
>>> Wake from suspend doesn't because Network Manager, HAL, or some other
>>> user space tool gets confused.
>>>
>>> I just rechecked it with Fujitsu Lifebook, which has sky2 (88E8055).
>>> There many variations of this chip, and it maybe chip specific problem
>>> or ACPI/BIOS issues.  If you don't enable Wake on Lan in BIOS, the
>>> driver can't do it for you. Also, check how you are shutting down.
>>>
>>> Also since the device has to restart the PHY, it could be a switch
>>> issue if you have some fancy pants switch doing intrusion detection
>>> or something, but I doubt that.
>>>
>>> Is it a clean or fast shutdown, most distributions mark network
>>> devices as down on shutdown, but if the distribution does something 
>>> stupid like remove the driver module, then the driver is unable to setup Wake On Lan.
>>> The wake on lan setup is done in one place in the driver, add
>>> a printk to see if it is ever called.
>>>
>>>
>>
>> I tried ACPI wakeup with /proc/acpi/alarm (like i described in my last 
>> mail) and it worked... so ACPI wakeup seems to work.
>>
>> i'll try to do the printk-thing when i find some time to mess around 
>> with the sources (maybe tomorrow). if someone has some brief 
>> instructions (maybe a link to a helpfull site for kernel debugging) for 
>> me i would be thankfull and could provide some more info faster.
>>
>> some steps for me to identify the source of the problem (is it really 
>> sky2?) would be really helpfull...
> 
> Please do the tests requested at:
> http://bugzilla.kernel.org/show_bug.cgi?id=9721#c2,
> thanks.
> 

allright, didn't see that before, sorry, here are the results:

kernel 2.6.23.12 acpi=off: when shutting down the system doesn't 
poweroff (of course), but pressing the powerbutton does the trick. and 
wake on lan: WORKS

kernel 2.6.24-rc7 acpi=off: computer doesn't power off, either (so 
acpi=off works), but wol still DOESN'T work :(

so no acpi-problem?

Comment 5 Rafael J. Wysocki 2008-01-11 15:08:19 UTC
On Friday, 11 of January 2008, supersud501 wrote:
> 
> Rafael J. Wysocki wrote:
> >> http://bugzilla.kernel.org/show_bug.cgi?id=9721

> allright, didn't see that before, sorry, here are the results:
> 
> kernel 2.6.23.12 acpi=off: when shutting down the system doesn't 
> poweroff (of course), but pressing the powerbutton does the trick. and 
> wake on lan: WORKS
> 
> kernel 2.6.24-rc7 acpi=off: computer doesn't power off, either (so 
> acpi=off works), but wol still DOESN'T work :(
> 
> so no acpi-problem?

No, I don't think it's an ACPI problem.

Since it seems to be 100% reproducible, it would be very helpful if you could
use git-bisect to identify the offending commit.

Comment 6 Markus Doits 2008-01-12 04:25:28 UTC

Rafael J. Wysocki wrote:
> On Friday, 11 of January 2008, supersud501 wrote:
>> Rafael J. Wysocki wrote:
>>>> http://bugzilla.kernel.org/show_bug.cgi?id=9721
> 
>> allright, didn't see that before, sorry, here are the results:
>>
>> kernel 2.6.23.12 acpi=off: when shutting down the system doesn't 
>> poweroff (of course), but pressing the powerbutton does the trick. and 
>> wake on lan: WORKS
>>
>> kernel 2.6.24-rc7 acpi=off: computer doesn't power off, either (so 
>> acpi=off works), but wol still DOESN'T work :(
>>
>> so no acpi-problem?
> 
> No, I don't think it's an ACPI problem.
> 
> Since it seems to be 100% reproducible, it would be very helpful if you could
> use git-bisect to identify the offending commit.
> 

I'll do the git-bisect (just downloading linux-2.6.git), but i forgot to 
mention one little thing: i'm using x64 version of kernel - does this 
play an important role?

Comment 7 Rafael J. Wysocki 2008-01-12 11:11:10 UTC
> http://bugzilla.kernel.org/show_bug.cgi?id=9721

On Saturday, 12 of January 2008, supersud501 wrote:

> I'll do the git-bisect (just downloading linux-2.6.git), but i forgot to 
> mention one little thing: i'm using x64 version of kernel - does this 
> play an important role?

No, it doesn't.

Comment 8 Markus Doits 2008-01-13 05:22:22 UTC

Rafael J. Wysocki wrote:

> 
> Since it seems to be 100% reproducible, it would be very helpful if you could
> use git-bisect to identify the offending commit.
> 

allright, bisect found the offending commit, here's what i've done:

first i started bisect with the following command (since i assumed it is 
a net-driver problem):

git-bisect start 'v2.6.24-rc6' 'v2.6.23' '--' 'drivers/net/'

after building many kernels and saying good/bad if wol worked/didn't 
work etc. it identified the following commit:

# bad: [ac93a3946b676025fa55356180e8321639744b31] sky2: enable PCI 
config writes

and refs/bisect/bad gives:

14:16:53 /usr/src/linux-2.6/.git # cat refs/bisect/bad
ac93a3946b676025fa55356180e8321639744b31


need some more info?

Comment 9 Markus Doits 2008-01-13 07:08:52 UTC

supersud501 wrote:
> 
> 
> Rafael J. Wysocki wrote:
> 
>>
>> Since it seems to be 100% reproducible, it would be very helpful if 
>> you could
>> use git-bisect to identify the offending commit.
>>
> 
> allright, bisect found the offending commit, here's what i've done:
> 
> first i started bisect with the following command (since i assumed it is 
> a net-driver problem):
> 
> git-bisect start 'v2.6.24-rc6' 'v2.6.23' '--' 'drivers/net/'
> 
> after building many kernels and saying good/bad if wol worked/didn't 
> work etc. it identified the following commit:
> 
> # bad: [ac93a3946b676025fa55356180e8321639744b31] sky2: enable PCI 
> config writes
> 
> and refs/bisect/bad gives:
> 
> 14:16:53 /usr/src/linux-2.6/.git # cat refs/bisect/bad
> ac93a3946b676025fa55356180e8321639744b31
> 
> 
> need some more info?
> 

i just checked it: commented out the passage of the commit in kernel 
2.6.24-rc7-git4 and compiled it: wol WORKS. so this one line is causing 
my wol-disturbance...


but i noticed another "bug" on 2.6.24-rc7-git with sky2: dmesg shows a 
lot of lines every 5 seconds:

[...]
[  357.400462] sky2 0000:02:00.0: error interrupt status=0xc0000000
[  362.442039] printk: 41 messages suppressed.
[  362.442043] sky2 0000:02:00.0: error interrupt status=0x80000000
[  367.439151] printk: 18 messages suppressed.
[  367.439156] sky2 0000:02:00.0: error interrupt status=0x80000000
[  372.436267] printk: 30 messages suppressed.
[  372.436271] sky2 0000:02:00.0: error interrupt status=0x80000000
[  377.350236] printk: 19 messages suppressed.
[...]

since i do not notice any errors (yet) i'll wait till next rc, maybe it 
will be gone then...

but i'm happy wol works again on 2.6.24 :)

Comment 10 Anonymous Emailer 2008-01-13 11:27:26 UTC
Reply-To: akpm@linux-foundation.org

On Sun, 13 Jan 2008 16:08:38 +0100 supersud501 <supersud501@yahoo.de> wrote:

> 
> 
> supersud501 wrote:
> > 
> > 
> > Rafael J. Wysocki wrote:
> > 
> >>
> >> Since it seems to be 100% reproducible, it would be very helpful if 
> >> you could
> >> use git-bisect to identify the offending commit.
> >>
> > 
> > allright, bisect found the offending commit, here's what i've done:
> > 
> > first i started bisect with the following command (since i assumed it is 
> > a net-driver problem):
> > 
> > git-bisect start 'v2.6.24-rc6' 'v2.6.23' '--' 'drivers/net/'
> > 
> > after building many kernels and saying good/bad if wol worked/didn't 
> > work etc. it identified the following commit:
> > 
> > # bad: [ac93a3946b676025fa55356180e8321639744b31] sky2: enable PCI 
> > config writes
> > 
> > and refs/bisect/bad gives:
> > 
> > 14:16:53 /usr/src/linux-2.6/.git # cat refs/bisect/bad
> > ac93a3946b676025fa55356180e8321639744b31
> > 
> > 
> > need some more info?
> > 
> 
> i just checked it: commented out the passage of the commit in kernel 
> 2.6.24-rc7-git4 and compiled it: wol WORKS. so this one line is causing 
> my wol-disturbance...
> 
> 

So simply reverting this:

commit ac93a3946b676025fa55356180e8321639744b31
Author: Stephen Hemminger <shemminger@linux-foundation.org>
Date:   Mon Nov 5 15:52:08 2007 -0800

    sky2: enable PCI config writes
    
    On some boards, PCI configuration space access is turned off by default.
    The 2.6.24 driver doesn't turn it on, and should have.
    
    Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
    Signed-off-by: Jeff Garzik <jeff@garzik.org>

diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
index c27c7d6..4f41a94 100644
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -2791,6 +2791,9 @@ static void sky2_reset(struct sky2_hw *hw)
 	sky2_write8(hw, B0_CTST, CS_RST_SET);
 	sky2_write8(hw, B0_CTST, CS_RST_CLR);
 
+	/* allow writes to PCI config */
+	sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
+
 	/* clear PCI errors, if any */
 	pci_read_config_word(pdev, PCI_STATUS, &status);
 	status |= PCI_STATUS_ERROR_BITS;

fixes this regression?

If so, we should revert that change.

> but i noticed another "bug" on 2.6.24-rc7-git with sky2: dmesg shows a 
> lot of lines every 5 seconds:
> 
> [...]
> [  357.400462] sky2 0000:02:00.0: error interrupt status=0xc0000000
> [  362.442039] printk: 41 messages suppressed.
> [  362.442043] sky2 0000:02:00.0: error interrupt status=0x80000000
> [  367.439151] printk: 18 messages suppressed.
> [  367.439156] sky2 0000:02:00.0: error interrupt status=0x80000000
> [  372.436267] printk: 30 messages suppressed.
> [  372.436271] sky2 0000:02:00.0: error interrupt status=0x80000000
> [  377.350236] printk: 19 messages suppressed.
> [...]
> 
> since i do not notice any errors (yet) i'll wait till next rc, maybe it 
> will be gone then...

That's not good.  is this new behaviour?

Comment 11 Markus Doits 2008-01-13 12:28:25 UTC

Andrew Morton wrote:
> 
> So simply reverting this:
> 
> commit ac93a3946b676025fa55356180e8321639744b31
> Author: Stephen Hemminger <shemminger@linux-foundation.org>
> Date:   Mon Nov 5 15:52:08 2007 -0800
> 
>     sky2: enable PCI config writes
>     
>     On some boards, PCI configuration space access is turned off by default.
>     The 2.6.24 driver doesn't turn it on, and should have.
>     
>     Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
>     Signed-off-by: Jeff Garzik <jeff@garzik.org>
> 
> diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
> index c27c7d6..4f41a94 100644
> --- a/drivers/net/sky2.c
> +++ b/drivers/net/sky2.c
> @@ -2791,6 +2791,9 @@ static void sky2_reset(struct sky2_hw *hw)
>  	sky2_write8(hw, B0_CTST, CS_RST_SET);
>  	sky2_write8(hw, B0_CTST, CS_RST_CLR);
>  
> +	/* allow writes to PCI config */
> +	sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
> +
>  	/* clear PCI errors, if any */
>  	pci_read_config_word(pdev, PCI_STATUS, &status);
>  	status |= PCI_STATUS_ERROR_BITS;
> 
> fixes this regression?
> 
> If so, we should revert that change.
> 


yes, it does.


>> but i noticed another "bug" on 2.6.24-rc7-git with sky2: dmesg shows a 
>> lot of lines every 5 seconds:
>>
>> [...]
>> [  357.400462] sky2 0000:02:00.0: error interrupt status=0xc0000000
>> [  362.442039] printk: 41 messages suppressed.
>> [  362.442043] sky2 0000:02:00.0: error interrupt status=0x80000000
>> [  367.439151] printk: 18 messages suppressed.
>> [  367.439156] sky2 0000:02:00.0: error interrupt status=0x80000000
>> [  372.436267] printk: 30 messages suppressed.
>> [  372.436271] sky2 0000:02:00.0: error interrupt status=0x80000000
>> [  377.350236] printk: 19 messages suppressed.
>> [...]
>>
>> since i do not notice any errors (yet) i'll wait till next rc, maybe it 
>> will be gone then...
> 
> That's not good.  is this new behaviour?
> 
> 

at least on 2.6.23.12 i doesn't happen, so it's now for me in 
2.6.24-rc7-git4 (but again, not testet in earlier versions of 2.6.24).

since i do not feel any sideeffects yet after using it for ~6 hours 
(besides a really long dmesg-output), it's just a little bit annoying.

if there's a way to identify the source of the problem besides of 
bisecting, just say so and i will take a look into it the next days. if 
bisecting is the only (time-consuming) way you have to wait at least 
until the next weekend :)

Comment 12 Anonymous Emailer 2008-01-13 12:56:52 UTC
Reply-To: akpm@linux-foundation.org

On Sun, 13 Jan 2008 21:27:40 +0100 supersud501 <supersud501@yahoo.de> wrote:

> 
> 
> Andrew Morton wrote:
> > 
> > So simply reverting this:
> > 
> > commit ac93a3946b676025fa55356180e8321639744b31
> > Author: Stephen Hemminger <shemminger@linux-foundation.org>
> > Date:   Mon Nov 5 15:52:08 2007 -0800
> > 
> >     sky2: enable PCI config writes
> >     
> >     On some boards, PCI configuration space access is turned off by default.
> >     The 2.6.24 driver doesn't turn it on, and should have.
> >     
> >     Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
> >     Signed-off-by: Jeff Garzik <jeff@garzik.org>
> > 
> > diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
> > index c27c7d6..4f41a94 100644
> > --- a/drivers/net/sky2.c
> > +++ b/drivers/net/sky2.c
> > @@ -2791,6 +2791,9 @@ static void sky2_reset(struct sky2_hw *hw)
> >  	sky2_write8(hw, B0_CTST, CS_RST_SET);
> >  	sky2_write8(hw, B0_CTST, CS_RST_CLR);
> >  
> > +	/* allow writes to PCI config */
> > +	sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
> > +
> >  	/* clear PCI errors, if any */
> >  	pci_read_config_word(pdev, PCI_STATUS, &status);
> >  	status |= PCI_STATUS_ERROR_BITS;
> > 
> > fixes this regression?
> > 
> > If so, we should revert that change.
> > 
> 
> 
> yes, it does.
> 

OK, thanks.  I queued up the revert and shall wait to hear from
Stephen/David/Jeff on this.

> 
> >> but i noticed another "bug" on 2.6.24-rc7-git with sky2: dmesg shows a 
> >> lot of lines every 5 seconds:
> >>
> >> [...]
> >> [  357.400462] sky2 0000:02:00.0: error interrupt status=0xc0000000
> >> [  362.442039] printk: 41 messages suppressed.
> >> [  362.442043] sky2 0000:02:00.0: error interrupt status=0x80000000
> >> [  367.439151] printk: 18 messages suppressed.
> >> [  367.439156] sky2 0000:02:00.0: error interrupt status=0x80000000
> >> [  372.436267] printk: 30 messages suppressed.
> >> [  372.436271] sky2 0000:02:00.0: error interrupt status=0x80000000
> >> [  377.350236] printk: 19 messages suppressed.
> >> [...]
> >>
> >> since i do not notice any errors (yet) i'll wait till next rc, maybe it 
> >> will be gone then...
> > 
> > That's not good.  is this new behaviour?
> > 
> > 
> 
> at least on 2.6.23.12 i doesn't happen, so it's now for me in 
> 2.6.24-rc7-git4 (but again, not testet in earlier versions of 2.6.24).
> 
> since i do not feel any sideeffects yet after using it for ~6 hours 
> (besides a really long dmesg-output), it's just a little bit annoying.
> 
> if there's a way to identify the source of the problem besides of 
> bisecting, just say so and i will take a look into it the next days. if 
> bisecting is the only (time-consuming) way you have to wait at least 
> until the next weekend :)

2.6.23 also has this warning in sky2_err_intr() but it doesn't trigger
there.  Rafael, I think we'd have to class this as a post-2.6.23
regression.


Comment 13 Rafael J. Wysocki 2008-01-13 13:23:22 UTC
On Sunday, 13 of January 2008, Andrew Morton wrote:
> 
> 2.6.23 also has this warning in sky2_err_intr() but it doesn't trigger
> there.  Rafael, I think we'd have to class this as a post-2.6.23
> regression.

Yes, it's been being tracked already.

Comment 14 Rafael J. Wysocki 2008-01-13 13:25:40 UTC
I wonder if commit 84cd2dfb04d23a961c5f537baa243fa54d0987ac
"sky2: remove check for PCI wakeup setting from BIOS" has anything to do with
it, btw.

supersud501, can you please check if the bug is still present in the current
Linus' tree?

Comment 15 Markus Doits 2008-01-13 14:53:29 UTC

Rafael J. Wysocki wrote:
> I wonder if commit 84cd2dfb04d23a961c5f537baa243fa54d0987ac
> "sky2: remove check for PCI wakeup setting from BIOS" has anything to do with
> it, btw.
> 
> supersud501, can you please check if the bug is still present in the current
> Linus' tree?
> 

I checked it (after git pulling the dir), and it still doesn't work. but 
the dmesg-output wasn't filled with those errors i reported before anymore.

after removing that one commit ("enable PCI config writes") wol works 
again, but the dmesg output is filled too! so that seems to be the 
source of the full dmesg-output. here a little bit more of the 
dmesg-output (but maybe i should open a new bug report?)

[...] rmmod sky2 --->

[ 1182.964000] sky2 eth0: disabling interface
[ 1183.255862] ACPI: PCI interrupt for device 0000:02:00.0 disabled

	modprobe syk2 -->

[ 1192.951021] ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 19 (level, 
low) -> IRQ 19
[ 1192.951034] PCI: Setting latency timer of device 0000:02:00.0 to 64
[ 1192.951618] sky2 0000:02:00.0: v1.20 addr 0xf89fc000 irq 19 Yukon-EC 
(0xb6) rev 2
[ 1192.951636] sky2 0000:02:00.0: ignoring stuck error report bit
[ 1192.952425] sky2 eth0: addr 00:18:f3:fe:93:11

	ifdown eth0 && ifup eth0 -->

[ 1207.425171] sky2 eth0: enabling interface
[ 1209.806138] printk: 97 messages suppressed.
[ 1209.806143] sky2 0000:02:00.0: error interrupt status=0x80000010
[ 1209.807184] sky2 eth0: Link is up at 100 Mbps, full duplex, flow 
control rx
[ 1209.807502] sky2 0000:02:00.0: error interrupt status=0x80000000
[ 1210.621117] sky2 0000:02:00.0: error interrupt status=0xc0000000
[ 1210.660325] sky2 0000:02:00.0: error interrupt status=0x80000000
[ 1210.996873] sky2 0000:02:00.0: error interrupt status=0xc0000000
[ 1211.645470] printk: 1 messages suppressed.
[ 1211.645474] sky2 0000:02:00.0: error interrupt status=0xc0000000
[ 1216.656564] printk: 328 messages suppressed.
[ 1216.656569] sky2 0000:02:00.0: error interrupt status=0x80000000
[ 1221.653677] printk: 17 messages suppressed.
[ 1221.653681] sky2 0000:02:00.0: error interrupt status=0x80000000

--> every 5 sec a new error
[...]


-------------

and i noticed one more thing (i thought would just happen occasionally):

everytime wol does not work (sending the magic packet does nothing), i 
have to cut off my pc completely from power because otherwise (powering 
it up by power button) it hangs endless on hard-disk-dedection (s-ata). 
other users with my mobo report same issues from time to time, but mine 
seems to be 100% reproducable.

reenabling wol by removing the commit fixes this problem, too. the next 
new bug report i think.

-------------


btw, if anyone could tell me a way to rebuild only some modules (so i 
get the .ko file directly and can replace it by hand in 
/lib/modules/...) i could hack around a little bit too in sky2.c (or so) 
without the need to reinstall the whole kernel in order to test it...

Comment 16 Stephen Hemminger 2008-01-14 08:42:08 UTC
On Sun, 13 Jan 2008 11:27:12 -0800
Andrew Morton <akpm@linux-foundation.org> wrote:

> On Sun, 13 Jan 2008 16:08:38 +0100 supersud501 <supersud501@yahoo.de> wrote:
> 
> > 
> > 
> > supersud501 wrote:
> > > 
> > > 
> > > Rafael J. Wysocki wrote:
> > > 
> > >>
> > >> Since it seems to be 100% reproducible, it would be very helpful if 
> > >> you could
> > >> use git-bisect to identify the offending commit.
> > >>
> > > 
> > > allright, bisect found the offending commit, here's what i've done:
> > > 
> > > first i started bisect with the following command (since i assumed it is 
> > > a net-driver problem):
> > > 
> > > git-bisect start 'v2.6.24-rc6' 'v2.6.23' '--' 'drivers/net/'
> > > 
> > > after building many kernels and saying good/bad if wol worked/didn't 
> > > work etc. it identified the following commit:
> > > 
> > > # bad: [ac93a3946b676025fa55356180e8321639744b31] sky2: enable PCI 
> > > config writes
> > > 
> > > and refs/bisect/bad gives:
> > > 
> > > 14:16:53 /usr/src/linux-2.6/.git # cat refs/bisect/bad
> > > ac93a3946b676025fa55356180e8321639744b31
> > > 
> > > 
> > > need some more info?
> > > 
> > 
> > i just checked it: commented out the passage of the commit in kernel 
> > 2.6.24-rc7-git4 and compiled it: wol WORKS. so this one line is causing 
> > my wol-disturbance...
> > 
> > 
> 
> So simply reverting this:
> 
> commit ac93a3946b676025fa55356180e8321639744b31
> Author: Stephen Hemminger <shemminger@linux-foundation.org>
> Date:   Mon Nov 5 15:52:08 2007 -0800
> 
>     sky2: enable PCI config writes
>     
>     On some boards, PCI configuration space access is turned off by default.
>     The 2.6.24 driver doesn't turn it on, and should have.
>     
>     Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
>     Signed-off-by: Jeff Garzik <jeff@garzik.org>
> 
> diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
> index c27c7d6..4f41a94 100644
> --- a/drivers/net/sky2.c
> +++ b/drivers/net/sky2.c
> @@ -2791,6 +2791,9 @@ static void sky2_reset(struct sky2_hw *hw)
>  	sky2_write8(hw, B0_CTST, CS_RST_SET);
>  	sky2_write8(hw, B0_CTST, CS_RST_CLR);
>  
> +	/* allow writes to PCI config */
> +	sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
> +
>  	/* clear PCI errors, if any */
>  	pci_read_config_word(pdev, PCI_STATUS, &status);
>  	status |= PCI_STATUS_ERROR_BITS;
> 
> fixes this regression?
> 
> If so, we should revert that change.
> 
> > but i noticed another "bug" on 2.6.24-rc7-git with sky2: dmesg shows a 
> > lot of lines every 5 seconds:
> > 
> > [...]
> > [  357.400462] sky2 0000:02:00.0: error interrupt status=0xc0000000
> > [  362.442039] printk: 41 messages suppressed.
> > [  362.442043] sky2 0000:02:00.0: error interrupt status=0x80000000
> > [  367.439151] printk: 18 messages suppressed.
> > [  367.439156] sky2 0000:02:00.0: error interrupt status=0x80000000
> > [  372.436267] printk: 30 messages suppressed.
> > [  372.436271] sky2 0000:02:00.0: error interrupt status=0x80000000
> > [  377.350236] printk: 19 messages suppressed.
> > [...]
> > 
> > since i do not notice any errors (yet) i'll wait till next rc, maybe it 
> > will be gone then...
> 
> That's not good.  is this new behaviour?
> 

No, reverting that change will break other systems (including mine).

Comment 17 Anonymous Emailer 2008-01-14 12:50:50 UTC
Reply-To: akpm@linux-foundation.org

On Mon, 14 Jan 2008 08:39:26 -0800
Stephen Hemminger <shemminger@linux-foundation.org> wrote:

> > diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
> > index c27c7d6..4f41a94 100644
> > --- a/drivers/net/sky2.c
> > +++ b/drivers/net/sky2.c
> > @@ -2791,6 +2791,9 @@ static void sky2_reset(struct sky2_hw *hw)
> >  	sky2_write8(hw, B0_CTST, CS_RST_SET);
> >  	sky2_write8(hw, B0_CTST, CS_RST_CLR);
> >  
> > +	/* allow writes to PCI config */
> > +	sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
> > +
> >  	/* clear PCI errors, if any */
> >  	pci_read_config_word(pdev, PCI_STATUS, &status);
> >  	status |= PCI_STATUS_ERROR_BITS;
> > 
> > fixes this regression?
> > 
> > If so, we should revert that change.
> > 
> > > but i noticed another "bug" on 2.6.24-rc7-git with sky2: dmesg shows a 
> > > lot of lines every 5 seconds:
> > > 
> > > [...]
> > > [  357.400462] sky2 0000:02:00.0: error interrupt status=0xc0000000
> > > [  362.442039] printk: 41 messages suppressed.
> > > [  362.442043] sky2 0000:02:00.0: error interrupt status=0x80000000
> > > [  367.439151] printk: 18 messages suppressed.
> > > [  367.439156] sky2 0000:02:00.0: error interrupt status=0x80000000
> > > [  372.436267] printk: 30 messages suppressed.
> > > [  372.436271] sky2 0000:02:00.0: error interrupt status=0x80000000
> > > [  377.350236] printk: 19 messages suppressed.
> > > [...]
> > > 
> > > since i do not notice any errors (yet) i'll wait till next rc, maybe it 
> > > will be gone then...
> > 
> > That's not good.  is this new behaviour?
> > 
> 
> No, reverting that change will break other systems (including mine).

Reverting which change?  ac93a3946b676025fa55356180e8321639744b31?

Linus has very clearly stated on multiple occasions that patches which
fix machine A and break machine B will be reverted.  For good reasons.
I don't have a copy of those reasons handy, but it should be a well-known
thing.

If you're really interested we can cc him for a reminder, but the effects
of that upon ac93a3946b676025fa55356180e8321639744b31 might be quick.  And
terminal.

Comment 18 Stephen Hemminger 2008-01-14 12:55:51 UTC
On Mon, 14 Jan 2008 12:50:50 -0800 (PST)
bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=9721
> 
> 
> 
> 
> 
> ------- Comment #17 from anonymous@kernel-bugs.osdl.org  2008-01-14 12:50 -------
> Reply-To: akpm@linux-foundation.org
> 
> On Mon, 14 Jan 2008 08:39:26 -0800
> Stephen Hemminger <shemminger@linux-foundation.org> wrote:
> 
> > > diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
> > > index c27c7d6..4f41a94 100644
> > > --- a/drivers/net/sky2.c
> > > +++ b/drivers/net/sky2.c
> > > @@ -2791,6 +2791,9 @@ static void sky2_reset(struct sky2_hw *hw)
> > >  	sky2_write8(hw, B0_CTST, CS_RST_SET);
> > >  	sky2_write8(hw, B0_CTST, CS_RST_CLR);
> > >  
> > > +	/* allow writes to PCI config */
> > > +	sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
> > > +
> > >  	/* clear PCI errors, if any */
> > >  	pci_read_config_word(pdev, PCI_STATUS, &status);
> > >  	status |= PCI_STATUS_ERROR_BITS;
> > > 
> > > fixes this regression?
> > > 
> > > If so, we should revert that change.
> > > 
> > > > but i noticed another "bug" on 2.6.24-rc7-git with sky2: dmesg shows a 
> > > > lot of lines every 5 seconds:
> > > > 
> > > > [...]
> > > > [  357.400462] sky2 0000:02:00.0: error interrupt status=0xc0000000
> > > > [  362.442039] printk: 41 messages suppressed.
> > > > [  362.442043] sky2 0000:02:00.0: error interrupt status=0x80000000
> > > > [  367.439151] printk: 18 messages suppressed.
> > > > [  367.439156] sky2 0000:02:00.0: error interrupt status=0x80000000
> > > > [  372.436267] printk: 30 messages suppressed.
> > > > [  372.436271] sky2 0000:02:00.0: error interrupt status=0x80000000
> > > > [  377.350236] printk: 19 messages suppressed.
> > > > [...]
> > > > 
> > > > since i do not notice any errors (yet) i'll wait till next rc, maybe it 
> > > > will be gone then...
> > > 
> > > That's not good.  is this new behaviour?
> > > 
> > 
> > No, reverting that change will break other systems (including mine).
> 
> Reverting which change?  ac93a3946b676025fa55356180e8321639744b31?
> 
> Linus has very clearly stated on multiple occasions that patches which
> fix machine A and break machine B will be reverted.  For good reasons.
> I don't have a copy of those reasons handy, but it should be a well-known
> thing.

But if the patch is nested in a bunch of other changes, so pulling it
out alone is not acceptable.


Comment 19 Markus Doits 2008-01-14 13:52:13 UTC
patch that fixes the issue:

> ------------------------------------------------------
> Subject: sky2: wake-on-lan configuration issues
> From: Stephen Hemminger <shemminger@linux-foundation.org>
> 
> This patch disables config mode access after clearing PCI settings.
> 
> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
> Tested-by: supersud501 <supersud501@yahoo.de>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
> 
>  drivers/net/sky2.c |    9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff -puN drivers/net/sky2.c~sky2-wake-on-lan-configuration-issues drivers/net/sky2.c
> --- a/drivers/net/sky2.c~sky2-wake-on-lan-configuration-issues
> +++ a/drivers/net/sky2.c
> @@ -621,6 +621,7 @@ static void sky2_phy_power(struct sky2_h
>  	static const u32 phy_power[] = { PCI_Y2_PHY1_POWD, PCI_Y2_PHY2_POWD };
>  	static const u32 coma_mode[] = { PCI_Y2_PHY1_COMA, PCI_Y2_PHY2_COMA };
>  
> +	sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
>  	reg1 = sky2_pci_read32(hw, PCI_DEV_REG1);
>  	/* Turn on/off phy power saving */
>  	if (onoff)
> @@ -632,7 +633,8 @@ static void sky2_phy_power(struct sky2_h
>  		reg1 |= coma_mode[port];
>  
>  	sky2_pci_write32(hw, PCI_DEV_REG1, reg1);
> -	reg1 = sky2_pci_read32(hw, PCI_DEV_REG1);
> +	sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
> +	sky2_pci_read32(hw, PCI_DEV_REG1);
>  
>  	udelay(100);
>  }
> @@ -2432,6 +2434,7 @@ static void sky2_hw_intr(struct sky2_hw 
>  	if (status & (Y2_IS_MST_ERR | Y2_IS_IRQ_STAT)) {
>  		u16 pci_err;
>  
> +		sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
>  		pci_err = sky2_pci_read16(hw, PCI_STATUS);
>  		if (net_ratelimit())
>  			dev_err(&pdev->dev, "PCI hardware error (0x%x)\n",
> @@ -2439,12 +2442,14 @@ static void sky2_hw_intr(struct sky2_hw 
>  
>  		sky2_pci_write16(hw, PCI_STATUS,
>  				      pci_err | PCI_STATUS_ERROR_BITS);
> +		sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
>  	}
>  
>  	if (status & Y2_IS_PCI_EXP) {
>  		/* PCI-Express uncorrectable Error occurred */
>  		u32 err;
>  
> +		sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
>  		err = sky2_read32(hw, Y2_CFG_AER + PCI_ERR_UNCOR_STATUS);
>  		sky2_write32(hw, Y2_CFG_AER + PCI_ERR_UNCOR_STATUS,
>  			     0xfffffffful);
> @@ -2452,6 +2457,7 @@ static void sky2_hw_intr(struct sky2_hw 
>  			dev_err(&pdev->dev, "PCI Express error (0x%x)\n", err);
>  
>  		sky2_read32(hw, Y2_CFG_AER + PCI_ERR_UNCOR_STATUS);
> +		sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
>  	}
>  
>  	if (status & Y2_HWE_L1_MASK)
> @@ -2817,6 +2823,7 @@ static void sky2_reset(struct sky2_hw *h
>  	}
>  
>  	sky2_power_on(hw);
> +	sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
>  
>  	for (i = 0; i < hw->ports; i++) {
>  		sky2_write8(hw, SK_REG(i, GMAC_LINK_CTRL), GMLC_RST_SET);

thx for your help
Comment 20 Markus Doits 2008-01-14 13:56:58 UTC
Created attachment 14455 [details]
patches the reported issues in sky2 (patch by Stephen Hemminger)

Note You need to log in before you can comment on or make changes to this bug.