[lkml]   [2005]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH/RFC] I/O-check interface for driver's error handling
    On Tuesday, March 1, 2005 8:59 am, Matthew Wilcox wrote:
    > The MCA handler has to go and figure out what the hell just happened
    > (was it a DIMM error, PCI bus error, etc). OK, fine, it finds that it
    > was an error on PCI bus 73. At this point, I think the architecture
    > error handler needs to call into the PCI subsystem and say "Hey, there
    > was an error, you deal with it".
    > If we're lucky, we get all the information that allows us to figure
    > out which device it was (eg a destination address that matches a BAR),
    > then we could have a ->error method in the pci_driver that handles it.
    > If there's no ->error method, at leat call ->remove so one device only
    > takes itself down.
    > Does this make sense?

    This was my thought too last time we had this discussion. A completely
    asynchronous call is probably needed in addition to Hidetoshi's proposed API,
    since as you point out, the driver may not be running when an error occurs
    (e.g. in the case of a DMA error or more general bus problem). The async
    ->error callback could do a total reset of the card, or something along those
    lines as Jeff suggests, while the inline ioerr_clear/ioerr_check API could
    potentially deal with errors as they happen (probably in the case of PIO
    related errors), when the additional context may allow us to be smarter about

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:10    [W:0.023 / U:0.156 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site