lkml.org 
[lkml]   [2020]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [EXT] [PATCH 09/15] qed: use new module_firmware_crashed()
    From
    Date

    >> So I think its not a good place to insert this call.
    >> Its hard to find exact good place to insert it in qed.
    >
    > Is there a way to check if what happened was indeed a fw crash?

    Our driver has two firmwares (slowpath and fastpath).
    For slowpath firmware the way to understand it crashed is to observe command
    response timeout. This is in qed_mcp.c, around "The MFW failed to respond to
    command" traceout.

    For fastpath this is tricky, think you may leave the above place as the only
    place to invoke module_firmware_crashed()

    >
    >> One more thing is that AFAIU taint flag gets permanent on kernel, but
    > for
    >> example our device can recover itself from some FW crashes, thus it'd be
    >> transparent for user.
    >
    > Similar things are *supposed* to recoverable with other device, however
    > this can also sometimes lead to a situation where devices are not usable
    > anymore, and require a full driver unload / load.
    >
    >> Whats the logical purpose of module_firmware_crashed? Does it mean fatal
    >> unrecoverable error on device?
    >
    > Its just to annotate on the module and kernel that this has happened.
    >
    > I take it you may agree that, firmware crashing *often* is not good
    > design,
    > and these issues should be reported to / fixed by vendors. In cases
    > where driver bugs are reported it is good to see if a firmware crash has
    > happened before, so that during analysis this is ruled out.

    Probably, but still I see some misalignment here, in sense that taint is about
    the kernel state, not about a hardware state indication.

    devlink health could really be a much better candidate for such things.

    Regards
    Igor

    \
     
     \ /
      Last update: 2020-05-12 18:25    [W:3.699 / U:0.192 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site