[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aee0afc3-d1d8-4c3c-94db-c9910798ce38@bigon.be>
Date: Fri, 30 Nov 2018 12:16:16 +0100
From: Laurent Bigonville <bigon@...on.be>
To: Stephen Hemminger <stephen@...workplumber.org>
Cc: netdev@...r.kernel.org
Subject: Re: [sky2 driver] 88E8056 PCI-E Gigabit Ethernet Controller not
working after suspend
Le 10/10/18 à 21:09, Stephen Hemminger a écrit :
> On Wed, 10 Oct 2018 03:16:40 +0200
> Laurent Bigonville <bigon@...on.be> wrote:
>
>> Le 9/10/18 à 22:09, Stephen Hemminger a écrit :
>>> On Tue, 9 Oct 2018 19:30:30 +0200
>>> Laurent Bigonville <bigon@...on.be> wrote:
>>>
>>>> Hello,
>>>>
>>>> On my desktop (Asus MB with dual Ethernet port), when waking up after
>>>> suspend, the network card is not detecting the link.
>>>>
>>>> I have to rmmod the sky2 driver and then modprobing it again.
>>>>
>>>> lspci shows me:
>>>>
>>>> 04:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E
>>>> Gigabit Ethernet Controller (rev 12)
>>>> 05:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E
>>>> Gigabit Ethernet Controller (rev 12)
>>>>
>>>> An idea what's wrong here?
>>>>
>>>> Kind regards,
>>>>
>>>> Laurent Bigonville
>>>>
>>> I used to have that motherboard (about 8 years ago). Long dead by now.
>>>
>>> There was some issue with how the power management worked. Forgot the workaround,
>>> you might have to dig in the mailing list archive.
>> I've made some test and it seems that this was working in 4.14 and then
>> broken in 4.15 (using the debian kernel pkg), so it was working not that
>> long ago:
>>
>> The only commit I see to the sky2 driver is the following:
>>
>> commit e99e88a9d2b067465adaa9c111ada99a041bef9a
>> Author: Kees Cook <keescook@...omium.org>
>> Date: Mon Oct 16 14:43:17 2017 -0700
>>
>> treewide: setup_timer() -> timer_setup()
>>
>> This converts all remaining cases of the old setup_timer() API into
>> using
>> timer_setup(), where the callback argument is the structure already
>> holding the struct timer_list. These should have no behavioral changes,
>> since they just change which pointer is passed into the callback with
>> the same available pointers after conversion. It handles the following
>> examples, in addition to some other variations.
>>
>>
> Probably something in PCI power management could.
I can still reproduce this in 4.19, any could have a look at this? Or
any other pointer I can look at?
After the suspend, the interface shows the following:
6: enp5s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast
state DOWN mode DEFAULT group default qlen 1000
link/ether 00:26:18:XX:XX:XX brd ff:ff:ff:ff:ff:ff
But the link led on the port is on (and the activity led is blinking),
so that would say that the interface is powered(?)
Powered by blists - more mailing lists