lkml.org 
[lkml]   [2014]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH regression] net: phy: fix initialization (config_init) for Marvel 88E1116R PHYs
    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


    \
     
     \ /
      Last update: 2014-04-03 18:29    [W:4.219 / U:0.140 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site