Re: [PATCH regression] net: phy: fix initialization (config_init) for Marvel 88E1116R PHYs

[Alexander Holler]

Am 03.04.2014 00:27, schrieb Sebastian Hesselbarth:
> On 04/03/2014 12:12 AM, Alexander Holler wrote:

> > > I am curious, how you determined above commit to be the cause of the
> > > regression you are seeing. Can you bisect, if you didn't already?
> >
> > There was no bisecting necessary. I've just looked at what changed in
> > mv643xx_eth since 3.13 and the first commit I've reverted was already a
> > hit. Reading a bit source revealed the differences between the old reset
> > and the newly used one and ended up with my patch (first try) and was a
> > hit too.
>
> Honestly, your own fix changes a different driver than mv643xx_eth.

It changes stuff which now (through the mentioned commit) gets used 
through the change in mv643xx_eth.

> There is a lot of changes from v3.13 to v3.14 and bisecting really
> helps to pin-point the one offending patch. As you can see from my
> tests with Dockstar, poking in the PHY driver may not be the right
> place to fix it.
>
> > Actually I assumed the reset needs longer than the 500ms, but as the
> > printks revealed, the reset is much faster.
> > So the problem seems to be the much increased time (1s) the newly used
> > reset function idles in mdelay.
>
> You assume that the PHY issue comes from waiting for too long _after_
> the reset? And again, the very same PHY on Dockstar is not affected.

Guess with which hardware I'm experiencing this problem? Hint: 
http://ahsoftware.de/dockstar/ ;)

> > But I think I have found the real reason. and the change of the reset
> > just increased the chance the problem is hit (here with 100% success or
> > fail rate however you want to name it).
> >
> > Just give me a day or two to find the time to verify my assumption (I
> > don't want to speculate) and maybe find a real fix for the problem. Of
> > course, I still like my patch because it greatly decreases the time
> > necessary for a reset (and the chance to hit the problem).
>
> Well, you can share your idea anytime. You already speculated that PHY
> reset on 88e1116r is broken but it seems that is not true. The more
> you share of your issue and the tries to fix it, the more likely is it
> we can follow your patch immediately.

Sorry, but wild speculating doesn't help always. Otherwise I could 
mention several dozen possible reasons, starting from broken memory or 
other hw up to some memory corruption elsewhere in the kernel.

But I already have given a hint before, try what happens if you enable 
netconsole (compiled in) through the kernel commandline 
(netconsole=...). Maybe the ethernet on your dockstar will get stuck too.

> Again, if you really want to find the real patch breaking Sheevaplug,
> use git bisect.

That's silly if I already know a/the change which brings the problem to 
light. If I revert the mentioned commit the problem disapears. So why 
should I go through the pain to bisect stuff? I already have found the 
knob to kill the ethernet on that machine.

Regards,

Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/