[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <fd22832c-9dd8-7667-ff5d-075d5fdbec78@bigon.be>
Date: Wed, 5 Dec 2018 02:07:10 +0100
From: Laurent Bigonville <bigon@...on.be>
To: netdev@...r.kernel.org
Subject: Re: [sky2 driver] 88E8056 PCI-E Gigabit Ethernet Controller not
working after suspend
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@...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(?)
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
Powered by blists - more mailing lists