Re: [sky2 driver] 88E8056 PCI-E Gigabit Ethernet Controller not working after suspend

[Laurent Bigonville <bigon@bigon.be>]

Le 30/11/18 à 12:16, Laurent Bigonville a écrit :
> Le 10/10/18 à 21:09, Stephen Hemminger a écrit :
>> On Wed, 10 Oct 2018 03:16:40 +0200
>> Laurent Bigonville <bigon@bigon.be> wrote:
>>
>>> Le 9/10/18 à 22:09, Stephen Hemminger a écrit :
>>>> On Tue, 9 Oct 2018 19:30:30 +0200
>>>> Laurent Bigonville <bigon@bigon.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@chromium.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(?)

I've investigated a bit more and passing disable_msi=1 to the driver 
fixes this issue, the card is operational after suspend now. The module 
is still using pci_enable_msi() which seems deprecated, not sure that's 
relevant.

If I can trust the logs, I'm seeing quite some changes related to MSI 
between v4.14 and v4.15