| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20160317075202.16b14ed6@arm.com>
Date: Thu, 17 Mar 2016 07:52:02 +0000
From: Marc Zyngier <marc.zyngier@....com>
To: Bert Lindner <bert@....net>
Cc: Andreas Färber <afaerber@...e.de>,
Robin Murphy <robin.murphy@....com>,
Maxime Ripard <maxime.ripard@...e-electrons.com>,
<linux-sunxi@...glegroups.com>,
<linux-arm-kernel@...ts.infradead.org>, <netdev@...r.kernel.org>,
Giuseppe Cavallaro <peppe.cavallaro@...com>
Subject: Re: 4.5.0 on sun7i-a20-olinuxino-lime2: libphy: PHY
stmmac-0:ffffffff not found (regression from rc7)
On Thu, 17 Mar 2016 00:56:40 +0100
Bert Lindner <bert@....net> wrote:
> On 2016-03-16 18:42, Marc Zyngier wrote:
> > On 16/03/16 15:10, Bert Lindner wrote:
> >> On 2016-03-16 14:10, Andreas Färber wrote:
> >>> Am 16.03.2016 um 13:09 schrieb Robin Murphy:
> >>>> On 16/03/16 11:39, Marc Zyngier wrote:
> >>>>> On 16/03/16 11:19, Bert Lindner wrote:
> >>>>>> Hopefully this is the correct place and way to report this.
> >>>
> >>> The main discussion is on netdev list actually, CC'ed.
> >>>
> >>>>>> For the board sun7i-a20-olinuxino-lime2, there seems to be a problem
> >>>>>> with the eth0 PHY in mainline kernel 4.5.0 that developed since
> >>>>>> 4.5.0-rc7. Ethernet does not work, although eth0 is reported:
> >>>>>>
> >>>>>> root@...e2-079f:~# ip a l eth0
> >>>>>> 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
> >>>>>> default qlen 1000
> >>>>>> link/ether 02:c9:05:02:07:9f brd ff:ff:ff:ff:ff:ff
> >>>>>>
> >>>>>> Difference reported in dmesg:
> >>>>>>
> >>>>>> 4.5.0-rc7:
> >>>>>> [ 9.379279] NET: Registered protocol family 10
> >>>>>> [ 10.217148] RX IPC Checksum Offload disabled
> >>>>>> [ 10.217195] No MAC Management Counters available
> >>>>>> [ 10.217627] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> >>>>>> [ 15.206250] sun7i-dwmac 1c50000.ethernet eth0: Link is Up -
> >>>>>> 1Gbps/Full - flow control off
> >>>>>> [ 15.206360] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> >>>>>>
> >>>>>> 4.5.0:
> >>>>>> [ 9.767125] NET: Registered protocol family 10
> >>>>>> [ 10.357405] libphy: PHY stmmac-0:ffffffff not found
> >>>>>> [ 10.362382] eth0: Could not attach to PHY
> >>>>>> [ 10.366557] stmmac_open: Cannot attach to PHY (error: -19)
> >>>>>>
> >>>>>> .config is identical for both, also after make oldconfig, apart from
> >>>>>> comment with version number. DTB file is also identical between the two
> >>>>>> versions.
> >>>>>>
> >>>>>> Kernels are compiled on the board itself. /proc/version string:
> >>>>>> Linux version 4.5.0-rc7 (root@...e2-079f) (gcc version 4.9.1
> >>>>>> (Ubuntu/Linaro 4.9.1-16ubuntu6) ) #1 SMP Mon Mar 7 11:57:25 UTC 2016
> >>>>>> Linux version 4.5.0 (root@...e2-079f) (gcc version 4.9.1 (Ubuntu/Linaro
> >>>>>> 4.9.1-16ubuntu6) ) #1 SMP Tue Mar 15 11:39:01 UTC 2016
> >>>>>>
> >>>>>> Please let me know if more info is needed, if I should post complete
> >>>>>> .config, test compile with a particular config or patch, etc. Part of
> >>>>>> .config below.
> >>>>>
> >>>>> Can you please try reverting 88f8b1b ("stmmac: Fix 'eth0: No PHY found'
> >>>>> regression") and report whether or not this changes anything? This seems
> >>>>> to be the only stmac patch between -rc7 and release...
> >>>>
> >>>> Sounds like the same thing as the giant ongoing discussion thread here:
> >>>>
> >>>> http://thread.gmane.org/gmane.linux.drivers.devicetree/159007/focus=402830
> >>>
> >>> v4 fixes for 4.5 are here:
> >>>
> >>> https://patchwork.ozlabs.org/patch/598195/ (revert)
> >>> https://patchwork.ozlabs.org/patch/598196/
> >>>
> >>> v2 fixes for linux-next here:
> >>>
> >>> https://patchwork.ozlabs.org/patch/598331/ (revert)
> >>> https://patchwork.ozlabs.org/patch/598332/
> >>>
> >>> Please let Peppe know whether they work for you guys.
> >>
> >> Hi guys - I can confirm 4.5.0 minus 88f8b1b works for me:
> >>
> >> root@...e2-079f:~# cat /proc/version
> >> Linux version 4.5.0-minus-88f8b1b (root@...e2-079f) (gcc version 4.9.1
> >> (Ubuntu/Linaro 4.9.1-16ubuntu6) ) #2 SMP Wed Mar 16 12:50:03 UTC 2016
> >>
> >> From dmesg output:
> >> [ 9.731730] NET: Registered protocol family 10
> >> [ 10.516893] RX IPC Checksum Offload disabled
> >> [ 10.516948] No MAC Management Counters available
> >> [ 10.517374] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> >> [ 15.505548] sun7i-dwmac 1c50000.ethernet eth0: Link is Up -
> >> 1Gbps/Full - flow control off
> >> [ 15.505660] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> >>
> >> .. and connected over ethernet.
> >
> > Good to know, thanks. Could you also give the potential fix a go (as
> > mentioned by Andreas)? Just to make sure that whatever gets merged next
> > will actually fix the issue.
>
> Yes sure, it took a while because I had to travel. Confirmed, the
> v4-for-4.5 fix works well for me, on sun7i-a20-olinuxino-lime2:
>
> root@...e2-079f:~# cat /proc/version
> Linux version 4.5.0-598195-598196-v4 (root@...e2-079f) (gcc version
> 4.9.1 (Ubuntu/Linaro 4.9.1-16ubuntu6) ) #1 SMP Wed Mar 16 16:44:22 UTC 2016
>
> dmesg:
> [ 8.245273] NET: Registered protocol family 10
> [ 9.297406] RX IPC Checksum Offload disabled
> [ 9.297460] No MAC Management Counters available
> [ 9.297951] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> [ 16.285658] sun7i-dwmac 1c50000.ethernet eth0: Link is Up -
> 1Gbps/Full - flow control rx/tx
> [ 16.285798] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>
> The board is connected to my laptop rather than to a switch, so that
> might be where the flow control message comes from (not sure). Anyway
> ethernet works.
Cool, many thanks for taking the time to test and report.
Hopefully Giuseppe will get this merged quickly enough in mainline, and
it should then trickle into a 4.5-stable release (cc-ing stable on
these patches would probably be a good idea, BTW).
> I'm less familiar with linux-next - not sure what base to test against,
> I understand it is being redefined almost daily.
You can consider -next as a daily view of what mainline could become.
An over-sized crystal ball, in a way... ;-) Given that the regression
exists in mainline, there was no real point testing with -next.
Thanks again,
M.
--
Jazz is not dead. It just smells funny.
Powered by blists - more mailing lists