Re: [BISECTED] v4.5-rc1 phylib regression
On Tue, Jan 26, 2016 at 03:54:13PM -0800, Florian Fainelli wrote: > On 26/01/16 14:09, Andrew Lunn wrote: > >>> Nope, not an option. Only a small number of DTB actually use c22 or > >>> c45. The majority of devices have no compatible at all. Why should > >>> they, the binding documentation says it is optional! > >> > >> So one thing that can be done is to just have a whitelist in the > >> driver that we add the known phy compatibles to, with a nice comment > >> above that this should only be for legacy device trees. > > > > So you mean drivers/of/of_mdio.c:of_mdiobus_child_is_phy() > > has a white list like: > > > > "brcm,40nm-ephy" > > "marvell,88E", > > "marvell,88e1116", > > "marvell,88e1118", > > "marvell,88e1149r", > > "marvell,88e1310", > > "marvell,88E1510", > > "marvell,88E1514", > > "moxa,moxart-rtl8201cp", > > > > Yes, that would work. > > > > We should also update the binding documentation to limit what is legal > > in the compatible string. > > Agreed, and while at it, take the opportunity to make the compatible > string clause 22/45 mandatory properties so we do not multiply the > whitelist. Hi Florian I just posted the whitelist code. Making clause 22/45 mandatory is going further than a fix. So i've left this out for the moment. We can add it to net-next later. Andrew
Re: [BISECTED] v4.5-rc1 phylib regression
On 26/01/16 14:09, Andrew Lunn wrote: >>> Nope, not an option. Only a small number of DTB actually use c22 or >>> c45. The majority of devices have no compatible at all. Why should >>> they, the binding documentation says it is optional! >> >> So one thing that can be done is to just have a whitelist in the >> driver that we add the known phy compatibles to, with a nice comment >> above that this should only be for legacy device trees. > > So you mean drivers/of/of_mdio.c:of_mdiobus_child_is_phy() > has a white list like: > > "brcm,40nm-ephy" > "marvell,88E", > "marvell,88e1116", > "marvell,88e1118", > "marvell,88e1149r", > "marvell,88e1310", > "marvell,88E1510", > "marvell,88E1514", > "moxa,moxart-rtl8201cp", > > Yes, that would work. > > We should also update the binding documentation to limit what is legal > in the compatible string. Agreed, and while at it, take the opportunity to make the compatible string clause 22/45 mandatory properties so we do not multiply the whitelist. Thanks! -- Florian
Re: [BISECTED] v4.5-rc1 phylib regression
> > Nope, not an option. Only a small number of DTB actually use c22 or > > c45. The majority of devices have no compatible at all. Why should > > they, the binding documentation says it is optional! > > So one thing that can be done is to just have a whitelist in the > driver that we add the known phy compatibles to, with a nice comment > above that this should only be for legacy device trees. So you mean drivers/of/of_mdio.c:of_mdiobus_child_is_phy() has a white list like: "brcm,40nm-ephy" "marvell,88E", "marvell,88e1116", "marvell,88e1118", "marvell,88e1149r", "marvell,88e1310", "marvell,88E1510", "marvell,88E1514", "moxa,moxart-rtl8201cp", Yes, that would work. We should also update the binding documentation to limit what is legal in the compatible string. Andrew
Re: [BISECTED] v4.5-rc1 phylib regression
On Tue, Jan 26, 2016 at 1:36 PM, Andrew Lunn wrote: > On Tue, Jan 26, 2016 at 12:46:31PM -0800, Florian Fainelli wrote: >> On 26/01/16 10:14, Olof Johansson wrote: >> > +devicet...@vger.kernel.org instead. >> > >> > On Tue, Jan 26, 2016 at 10:08 AM, Olof Johansson wrote: >> >> On Tue, Jan 26, 2016 at 9:53 AM, Andrew Lunn wrote: >> I hate to bikeshed, but I'm not sure if "generic-mdio" is too... >> generic? Will someone writing a DT be thinking "well, this is a >> generic mdio PHY, I should set it"? "mdio-device"? >> "generic-nonphy-mdio"? Neither of those seem much better. >> >>> >> >>> How about 'not-a-phy'? >> >> >> >> "mdio,not-a-phy" or "mdio,non-phy" will scope it a bit, especially if >> >> you expect other generic mdio properties that can do with a namespace. >> >> Really not a fan of having to add an additional boolean property to >> differentiate an Ethernet PHY from something else, the proper solution >> would really be to enforce the use of the c22 or c45 compatible string >> as the least compatible string to be used, but I am assuming this is not >> necessarily an option here with DTBs out there. > > Nope, not an option. Only a small number of DTB actually use c22 or > c45. The majority of devices have no compatible at all. Why should > they, the binding documentation says it is optional! So one thing that can be done is to just have a whitelist in the driver that we add the known phy compatibles to, with a nice comment above that this should only be for legacy device trees. I.e. in addition to the c22 or c45 strings. You can even fix up existing trees, and do a pr_warn() for these cases to ask people to update their DT. There's no strict requirement to do so though, so the kernel still *has* to work with the old ones. >> What plays in favor of this boolean property is that the very concept of >> MDIO devices has been recently introduced, so presumably, there are not >> that many DTBs out there which would be affected... > > In kernel, 0. I have one out of kernel, which i hope to contribute > once we decide on the new binding for DSA. > >> The only other idea I had was to force the MDIO device creation to be >> dependent on finding a matching compatible string provided by a driver >> (yikes). > > Complex. There are ordering issues, since the driver can be loaded a > long time after of_mdiobus_register() is called, yet it needs to be > of_mdiobus_register() which decides if a device is a PHY or not. > > I think the bool is the only practical solution. -Olof
Re: [BISECTED] v4.5-rc1 phylib regression
On Tue, Jan 26, 2016 at 12:46:31PM -0800, Florian Fainelli wrote: > On 26/01/16 10:14, Olof Johansson wrote: > > +devicet...@vger.kernel.org instead. > > > > On Tue, Jan 26, 2016 at 10:08 AM, Olof Johansson wrote: > >> On Tue, Jan 26, 2016 at 9:53 AM, Andrew Lunn wrote: > I hate to bikeshed, but I'm not sure if "generic-mdio" is too... > generic? Will someone writing a DT be thinking "well, this is a > generic mdio PHY, I should set it"? "mdio-device"? > "generic-nonphy-mdio"? Neither of those seem much better. > >>> > >>> How about 'not-a-phy'? > >> > >> "mdio,not-a-phy" or "mdio,non-phy" will scope it a bit, especially if > >> you expect other generic mdio properties that can do with a namespace. > > Really not a fan of having to add an additional boolean property to > differentiate an Ethernet PHY from something else, the proper solution > would really be to enforce the use of the c22 or c45 compatible string > as the least compatible string to be used, but I am assuming this is not > necessarily an option here with DTBs out there. Nope, not an option. Only a small number of DTB actually use c22 or c45. The majority of devices have no compatible at all. Why should they, the binding documentation says it is optional! > What plays in favor of this boolean property is that the very concept of > MDIO devices has been recently introduced, so presumably, there are not > that many DTBs out there which would be affected... In kernel, 0. I have one out of kernel, which i hope to contribute once we decide on the new binding for DSA. > The only other idea I had was to force the MDIO device creation to be > dependent on finding a matching compatible string provided by a driver > (yikes). Complex. There are ordering issues, since the driver can be loaded a long time after of_mdiobus_register() is called, yet it needs to be of_mdiobus_register() which decides if a device is a PHY or not. I think the bool is the only practical solution. Andrew
Re: [BISECTED] v4.5-rc1 phylib regression
On 26/01/16 10:14, Olof Johansson wrote: > +devicet...@vger.kernel.org instead. > > On Tue, Jan 26, 2016 at 10:08 AM, Olof Johansson wrote: >> On Tue, Jan 26, 2016 at 9:53 AM, Andrew Lunn wrote: I hate to bikeshed, but I'm not sure if "generic-mdio" is too... generic? Will someone writing a DT be thinking "well, this is a generic mdio PHY, I should set it"? "mdio-device"? "generic-nonphy-mdio"? Neither of those seem much better. >>> >>> How about 'not-a-phy'? >> >> "mdio,not-a-phy" or "mdio,non-phy" will scope it a bit, especially if >> you expect other generic mdio properties that can do with a namespace. Really not a fan of having to add an additional boolean property to differentiate an Ethernet PHY from something else, the proper solution would really be to enforce the use of the c22 or c45 compatible string as the least compatible string to be used, but I am assuming this is not necessarily an option here with DTBs out there. What plays in favor of this boolean property is that the very concept of MDIO devices has been recently introduced, so presumably, there are not that many DTBs out there which would be affected... The only other idea I had was to force the MDIO device creation to be dependent on finding a matching compatible string provided by a driver (yikes). -- Florian
Re: [BISECTED] v4.5-rc1 phylib regression
+devicet...@vger.kernel.org instead. On Tue, Jan 26, 2016 at 10:08 AM, Olof Johansson wrote: > On Tue, Jan 26, 2016 at 9:53 AM, Andrew Lunn wrote: >>> I hate to bikeshed, but I'm not sure if "generic-mdio" is too... >>> generic? Will someone writing a DT be thinking "well, this is a >>> generic mdio PHY, I should set it"? "mdio-device"? >>> "generic-nonphy-mdio"? Neither of those seem much better. >> >> How about 'not-a-phy'? > > "mdio,not-a-phy" or "mdio,non-phy" will scope it a bit, especially if > you expect other generic mdio properties that can do with a namespace. > > Probably time to add devicetree-discuss. Doing so. > > > -Olof
Re: [BISECTED] v4.5-rc1 phylib regression
On Tue, Jan 26, 2016 at 9:53 AM, Andrew Lunn wrote: >> I hate to bikeshed, but I'm not sure if "generic-mdio" is too... >> generic? Will someone writing a DT be thinking "well, this is a >> generic mdio PHY, I should set it"? "mdio-device"? >> "generic-nonphy-mdio"? Neither of those seem much better. > > How about 'not-a-phy'? "mdio,not-a-phy" or "mdio,non-phy" will scope it a bit, especially if you expect other generic mdio properties that can do with a namespace. Probably time to add devicetree-discuss. Doing so. -Olof
Re: [BISECTED] v4.5-rc1 phylib regression
> I hate to bikeshed, but I'm not sure if "generic-mdio" is too... > generic? Will someone writing a DT be thinking "well, this is a > generic mdio PHY, I should set it"? "mdio-device"? > "generic-nonphy-mdio"? Neither of those seem much better. How about 'not-a-phy'? Andrew
Re: [BISECTED] v4.5-rc1 phylib regression
On Tue, Jan 26, 2016 at 5:34 AM, Andrew Lunn wrote:
> On Tue, Jan 26, 2016 at 02:14:35PM +0200, Aaro Koskinen wrote:
>> Hi,
>>
>> On Tue, Jan 26, 2016 at 05:46:24AM +0100, Andrew Lunn wrote:
>> > On Mon, Jan 25, 2016 at 05:45:21PM +0200, Aaro Koskinen wrote:
>> > > I get the below crash on OCTEON (with octeon_mgmt interface, genphy)
>> > > always during systemd boot.
>> >
>> > I think i know what is going on now.
>> >
>> > What does your phy look like in DT?
>>
>> It's using the in-kernel DT:
>>
>> arch/mips/boot/dts/cavium-octeon/octeon_3xxx.dts
>>
>> The management interface is "mix0: ethernet@10710". The phy entry
>> might be bogus for this specific board, and I don't have MARVELL_PHY
>> enabled...
>
> phy1: ethernet-phy@1 {
> cavium,qlm-trim = "4,sgmii";
> reg = <1>;
> compatible = "marvell,88e1149r";
> marvell,reg-init = <3 0x10 0 0x5777>,
> <3 0x11 0 0x00aa>,
> <3 0x12 0 0x4105>,
> <3 0x13 0 0x0a60>;
> };
>
> Dove Cubox is the other board which Olof has problems with. It has
>
> ðphy {
> compatible = "marvell,88e1310";
> reg = <1>;
> };
>
> The issue here is the compatible string. The binding says:
>
> Optional Properties:
>
> - compatible: Compatible list, may contain
> "ethernet-phy-ieee802.3-c22" or "ethernet-phy-ieee802.3-c45" for
> PHYs that implement IEEE802.3 clause 22 or IEEE802.3 clause 45
> specifications. If neither of these are specified, the default is to
> assume clause 22. The compatible list may also contain other
> elements.
>
> If the phy's identifier is known then the list may contain an entry
> of the form: "ethernet-phy-id." where
> - The value of the 16 bit Phy Identifier 1 register as
> 4 hex digits. This is the chip vendor OUI bits 3:18
> - The value of the 16 bit Phy Identifier 2 register as
> 4 hex digits. This is the chip vendor OUI bits 19:24,
> followed by 10 bits of a vendor specific ID.
>
> We are in a grey area, it does not say you can specifically exactly
> what PHY you have, but it also does not rule it out, since "may also
> contain other elements".
>
> When adding support for generic MDIO device, like switches, i have to
> differentiate between PHYs and generic MDIO devices in DT. What i
> implemented is:
>
> /*
> * Return true if the child node is for a phy. It must either:
> * o Compatible string of "ethernet-phy-idX.X"
> * o Compatible string of "ethernet-phy-ieee802.3-c45"
> * o Compatible string of "ethernet-phy-ieee802.3-c22"
> * o No compatibility string
> *
> * A device which is not a phy is expected to have a compatible string
> * indicating what sort of device it is.
> */
> static bool of_mdiobus_child_is_phy(struct device_node *child)
> {
>
> The last rule is the issue. Before this patch, saying
> "marvell,88e1149r" would be totally ignored, never used. The PHY
> drivers don't have an of_device_id table to match against. Now it
> means the device is a generic MDIO device, and use the compatible
> string to find the correct driver for it.
>
> The first part of the fix is clear. If we have a generic MDIO device,
> but somebody asks for a PHY device, return an error. I've not checked
> the code paths yet, but i expect the generic MDIO device is being
> returned, container_of() into a phydev, and then the non-existent
> mutex is lock. The code already have a flag to indicate if it is a PHY
> or not, so it looks like a check is missing somewhere.
>
> The harder problem, is what to do with these compatible strings, and
> how to decide if we have a generic MDIO device, or a PHY. Grep'ing the
> DTS files, it seems to be an issue for octeon_68xx.dts,
> octeon_3xxx.dts, k2e-evm.dts, k2he-evm.dts, k2l-evm.dts,
> kirkwood-dockstar.dts, moxart-uc7112lx.dts, dove-cubox.dts and maybe
> others my grep foo missed.
>
> This is too many to ignore. Having a useless compatible string for a
> PHY needs to be supported. So i guess i need a bool property,
> "generic-mdio", and assume anything without that is a PHY.
>
> Florian, are you O.K. with this?
General solution of having a boolean property to indicate that the
mdio device is not a phy sounds good to me. Alternatively, have a
generic compatible that all non-phys must set (same way as you're
expecting the ethernet-phy-id* above). Either way is alright with me.
I hate to bikeshed, but I'm not sure if "generic-mdio" is too...
generic? Will someone writing a DT be thinking "well, this is a
generic mdio PHY, I should set it"? "mdio-device"?
"generic-nonphy-mdio"? Neither of those seem much better.
-Olof
Re: [BISECTED] v4.5-rc1 phylib regression
On Tue, Jan 26, 2016 at 02:14:35PM +0200, Aaro Koskinen wrote:
> Hi,
>
> On Tue, Jan 26, 2016 at 05:46:24AM +0100, Andrew Lunn wrote:
> > On Mon, Jan 25, 2016 at 05:45:21PM +0200, Aaro Koskinen wrote:
> > > I get the below crash on OCTEON (with octeon_mgmt interface, genphy)
> > > always during systemd boot.
> >
> > I think i know what is going on now.
> >
> > What does your phy look like in DT?
>
> It's using the in-kernel DT:
>
> arch/mips/boot/dts/cavium-octeon/octeon_3xxx.dts
>
> The management interface is "mix0: ethernet@10710". The phy entry
> might be bogus for this specific board, and I don't have MARVELL_PHY
> enabled...
phy1: ethernet-phy@1 {
cavium,qlm-trim = "4,sgmii";
reg = <1>;
compatible = "marvell,88e1149r";
marvell,reg-init = <3 0x10 0 0x5777>,
<3 0x11 0 0x00aa>,
<3 0x12 0 0x4105>,
<3 0x13 0 0x0a60>;
};
Dove Cubox is the other board which Olof has problems with. It has
ðphy {
compatible = "marvell,88e1310";
reg = <1>;
};
The issue here is the compatible string. The binding says:
Optional Properties:
- compatible: Compatible list, may contain
"ethernet-phy-ieee802.3-c22" or "ethernet-phy-ieee802.3-c45" for
PHYs that implement IEEE802.3 clause 22 or IEEE802.3 clause 45
specifications. If neither of these are specified, the default is to
assume clause 22. The compatible list may also contain other
elements.
If the phy's identifier is known then the list may contain an entry
of the form: "ethernet-phy-id." where
- The value of the 16 bit Phy Identifier 1 register as
4 hex digits. This is the chip vendor OUI bits 3:18
- The value of the 16 bit Phy Identifier 2 register as
4 hex digits. This is the chip vendor OUI bits 19:24,
followed by 10 bits of a vendor specific ID.
We are in a grey area, it does not say you can specifically exactly
what PHY you have, but it also does not rule it out, since "may also
contain other elements".
When adding support for generic MDIO device, like switches, i have to
differentiate between PHYs and generic MDIO devices in DT. What i
implemented is:
/*
* Return true if the child node is for a phy. It must either:
* o Compatible string of "ethernet-phy-idX.X"
* o Compatible string of "ethernet-phy-ieee802.3-c45"
* o Compatible string of "ethernet-phy-ieee802.3-c22"
* o No compatibility string
*
* A device which is not a phy is expected to have a compatible string
* indicating what sort of device it is.
*/
static bool of_mdiobus_child_is_phy(struct device_node *child)
{
The last rule is the issue. Before this patch, saying
"marvell,88e1149r" would be totally ignored, never used. The PHY
drivers don't have an of_device_id table to match against. Now it
means the device is a generic MDIO device, and use the compatible
string to find the correct driver for it.
The first part of the fix is clear. If we have a generic MDIO device,
but somebody asks for a PHY device, return an error. I've not checked
the code paths yet, but i expect the generic MDIO device is being
returned, container_of() into a phydev, and then the non-existent
mutex is lock. The code already have a flag to indicate if it is a PHY
or not, so it looks like a check is missing somewhere.
The harder problem, is what to do with these compatible strings, and
how to decide if we have a generic MDIO device, or a PHY. Grep'ing the
DTS files, it seems to be an issue for octeon_68xx.dts,
octeon_3xxx.dts, k2e-evm.dts, k2he-evm.dts, k2l-evm.dts,
kirkwood-dockstar.dts, moxart-uc7112lx.dts, dove-cubox.dts and maybe
others my grep foo missed.
This is too many to ignore. Having a useless compatible string for a
PHY needs to be supported. So i guess i need a bool property,
"generic-mdio", and assume anything without that is a PHY.
Florian, are you O.K. with this?
Thanks
Andrew
Re: [BISECTED] v4.5-rc1 phylib regression
Hi, On Tue, Jan 26, 2016 at 05:46:24AM +0100, Andrew Lunn wrote: > On Mon, Jan 25, 2016 at 05:45:21PM +0200, Aaro Koskinen wrote: > > I get the below crash on OCTEON (with octeon_mgmt interface, genphy) > > always during systemd boot. > > I think i know what is going on now. > > What does your phy look like in DT? It's using the in-kernel DT: arch/mips/boot/dts/cavium-octeon/octeon_3xxx.dts The management interface is "mix0: ethernet@10710". The phy entry might be bogus for this specific board, and I don't have MARVELL_PHY enabled... A.
Re: [BISECTED] v4.5-rc1 phylib regression
On Mon, Jan 25, 2016 at 05:45:21PM +0200, Aaro Koskinen wrote: > Hi, > > I get the below crash on OCTEON (with octeon_mgmt interface, genphy) > always during systemd boot. Hi Aaro I think i know what is going on now. What does your phy look like in DT? Thanks Andrew
Re: [BISECTED] v4.5-rc1 phylib regression
On Mon, Jan 25, 2016 at 05:45:21PM +0200, Aaro Koskinen wrote: > Hi, > > I get the below crash on OCTEON (with octeon_mgmt interface, genphy) > always during systemd boot. > > Bisected to: > > commit a9049e0c513c4521dbfaa302af8ed08b3366b41f > Author: Andrew Lunn > Date: Wed Jan 6 20:11:26 2016 +0100 > > mdio: Add support for mdio drivers. > > [ 250.179887] CPU 2 Unable to handle kernel paging request at virtual > address , epc == 81637bac, ra == 81637b7c > [ 250.218161] Oops[#1]: > [ 250.224970] CPU: 2 PID: 850 Comm: systemd-network Not tainted > 4.5.0-rc1-octeon-distro.git-test #1 > [ 250.251569] task: 800031188000 ti: 80002f8e8000 task.ti: > 80002f8e8000 > [ 250.251586] $ 0 : 81639774 > > [ 250.251595] $ 4 : 8174 > 0001 > [ 250.251604] $ 8 : 0001 81106100 > 00010001 > [ 250.251613] $12 : 813eb81c 8150be18 > > [ 250.251622] $16 : 800031290fc0 800031290fc4 > 800031188000 > [ 250.251631] $20 : 0002 0001 800031290fc8 > 80002f8eba40 > [ 250.251640] $24 : 0038 81105fb0 > > [ 250.251649] $28 : 80002f8e8000 80002f8eb740 00fff7857f88 > 81637b7c > [ 250.251651] Hi: 431bde82d7b50717 > [ 250.251653] Lo: c8de2ac3222855ea > [ 250.251668] epc : 81637bac __mutex_lock_slowpath+0x7c/0x190 > [ 250.251675] ra: 81637b7c __mutex_lock_slowpath+0x4c/0x190 > [ 250.251684] Status: 10108ce3 KX SX UX KERNEL EXL IE > [ 250.251686] Cause : 008c (ExcCode 03) > [ 250.251688] BadVA : > [ 250.251690] PrId : 000d0409 (Cavium Octeon+) > [ 250.251699] Modules linked in: pata_octeon_cf libata autofs4 > [ 250.251704] Process systemd-network (pid: 850, > threadinfo=80002f8e8000, task=800031188000, tls=00fff75ba700) > [ 250.251782] Stack : 800031290fc8 0001 > 83f9bca0 > [ 250.251782] 800031290c00 81856558 800031290fc0 > 800031225000 > [ 250.251782] 0001 800031008800 > 814b6284 > [ 250.251782] 81639774 81175dc4 800031290c00 > 814baf80 > [ 250.251782] 80003121 814b64ac 80002f8eb810 > 80002f8eb810 > [ 250.251782] 814f7790 800031290c00 814baf80 > 814baf80 > [ 250.251782] 800031225000 80003290ca10 > 814b66a4 > [ 250.251782] 800031225000 800031290c00 0001 > 814f7b80 > [ 250.251782] 800031225000 800031225788 800031225830 > 1002 > [ 250.251782] 80002f8ebb80 814ba81c 800fb7105c32 > 8116aab4 > [ 250.251782] ... > [ 250.251784] Call Trace: > [ 250.251791] [] __mutex_lock_slowpath+0x7c/0x190 > [ 250.251801] [] phy_probe+0x6c/0x120 > [ 250.251807] [] phy_attach_direct+0xdc/0x1a8 > [ 250.251814] [] phy_connect_direct+0x2c/0x98 > [ 250.251822] [] of_phy_connect+0x60/0xb8 > [ 250.251830] [] octeon_mgmt_open+0x36c/0xad0 Hi Aaro, Olof I've not been able to reproduce this. I've tried a Kirkwood Qnap, a Kirkwood DIR665, an Armada XP WRT1900AC and a Freescale Vybrid. And i've turned on mutex debugging Nothing, always boots to user space, no complaints. Andrew
Re: [BISECTED] v4.5-rc1 phylib regression
On Mon, Jan 25, 2016 at 05:45:21PM +0200, Aaro Koskinen wrote: > Hi, > > I get the below crash on OCTEON (with octeon_mgmt interface, genphy) > always during systemd boot. Hi Aaro Olof reported a similar issue with a Marvell Ethernet driver/MDIO driver. Olof thinking was the mutex was used before it was initialised. I will look into this tonight. Thanks Andrew > > Bisected to: > > commit a9049e0c513c4521dbfaa302af8ed08b3366b41f > Author: Andrew Lunn > Date: Wed Jan 6 20:11:26 2016 +0100 > > mdio: Add support for mdio drivers. > > [ 250.179887] CPU 2 Unable to handle kernel paging request at virtual > address , epc == 81637bac, ra == 81637b7c > [ 250.218161] Oops[#1]: > [ 250.224970] CPU: 2 PID: 850 Comm: systemd-network Not tainted > 4.5.0-rc1-octeon-distro.git-test #1 > [ 250.251569] task: 800031188000 ti: 80002f8e8000 task.ti: > 80002f8e8000 > [ 250.251586] $ 0 : 81639774 > > [ 250.251595] $ 4 : 8174 > 0001 > [ 250.251604] $ 8 : 0001 81106100 > 00010001 > [ 250.251613] $12 : 813eb81c 8150be18 > > [ 250.251622] $16 : 800031290fc0 800031290fc4 > 800031188000 > [ 250.251631] $20 : 0002 0001 800031290fc8 > 80002f8eba40 > [ 250.251640] $24 : 0038 81105fb0 > > [ 250.251649] $28 : 80002f8e8000 80002f8eb740 00fff7857f88 > 81637b7c > [ 250.251651] Hi: 431bde82d7b50717 > [ 250.251653] Lo: c8de2ac3222855ea > [ 250.251668] epc : 81637bac __mutex_lock_slowpath+0x7c/0x190 > [ 250.251675] ra: 81637b7c __mutex_lock_slowpath+0x4c/0x190 > [ 250.251684] Status: 10108ce3 KX SX UX KERNEL EXL IE > [ 250.251686] Cause : 008c (ExcCode 03) > [ 250.251688] BadVA : > [ 250.251690] PrId : 000d0409 (Cavium Octeon+) > [ 250.251699] Modules linked in: pata_octeon_cf libata autofs4 > [ 250.251704] Process systemd-network (pid: 850, > threadinfo=80002f8e8000, task=800031188000, tls=00fff75ba700) > [ 250.251782] Stack : 800031290fc8 0001 > 83f9bca0 > [ 250.251782] 800031290c00 81856558 800031290fc0 > 800031225000 > [ 250.251782] 0001 800031008800 > 814b6284 > [ 250.251782] 81639774 81175dc4 800031290c00 > 814baf80 > [ 250.251782] 80003121 814b64ac 80002f8eb810 > 80002f8eb810 > [ 250.251782] 814f7790 800031290c00 814baf80 > 814baf80 > [ 250.251782] 800031225000 80003290ca10 > 814b66a4 > [ 250.251782] 800031225000 800031290c00 0001 > 814f7b80 > [ 250.251782] 800031225000 800031225788 800031225830 > 1002 > [ 250.251782] 80002f8ebb80 814ba81c 800fb7105c32 > 8116aab4 > [ 250.251782] ... > [ 250.251784] Call Trace: > [ 250.251791] [] __mutex_lock_slowpath+0x7c/0x190 > [ 250.251801] [] phy_probe+0x6c/0x120 > [ 250.251807] [] phy_attach_direct+0xdc/0x1a8 > [ 250.251814] [] phy_connect_direct+0x2c/0x98 > [ 250.251822] [] of_phy_connect+0x60/0xb8 > [ 250.251830] [] octeon_mgmt_open+0x36c/0xad0 > [ 250.251838] [] __dev_open+0x11c/0x1b0 > [ 250.251844] [] __dev_change_flags+0xa0/0x188 > [ 250.251850] [] dev_change_flags+0x30/0x78 > [ 250.251856] [] do_setlink+0x374/0xa38 > [ 250.251862] [] rtnl_setlink+0xdc/0x120 > [ 250.251868] [] rtnetlink_rcv_msg+0xac/0x2a0 > [ 250.251875] [] netlink_rcv_skb+0xf0/0x120 > [ 250.251880] [] rtnetlink_rcv+0x38/0x48 > [ 250.251886] [] netlink_unicast+0x1c0/0x2d8 > [ 250.251891] [] netlink_sendmsg+0x424/0x480 > [ 250.251898] [] sock_sendmsg+0x24/0x40 > [ 250.251904] [] SyS_sendto+0xc4/0x108 > [ 250.251914] [] syscall_common+0x34/0x58 > [ 250.251918] > [ 250.251936] > [ 250.251936] Code: 24150001 ffa20008 24140002 0858def5 > ffb30010 fe74 0c58e612 0240202d > [ 250.251983] ---[ end trace 1be6b781dce6d4dc ]--- > > A.
