lkml.org 
[lkml]   [2011]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: sata_mv port lockup on hotplug (kernel 2.6.38.2)
    Sorry about delay.  -EWASTRAVELING

    On Tue, Apr 12, 2011 at 10:55:55AM -0400, Mark Lord wrote:
    > >> One thing I noticed was that there is no spinlock around the
    > >> mv_save_cached_regs/mv_edma_cfg in mv_hardreset (unlike mv_port_start and
    > >> mv_port_stop); why is this?
    > >
    > > The mv_hardreset path is run from a libata-eh thread,
    > > and it assumes it has exclusive access to the hardware.
    >
    > Mmm.. another suspect is sata_mv's ".sff_irq_clear" function.
    > I don't see any locking in libata-sff.c before calling that one.
    >
    > Tejun -- should libata-sff grab ap->lock before calling .sff_irq_clear,
    > or is that up to the LLD to do?

    It depends. The basic assumption is that inside a single port, most
    of exclusions are achieved implicit either by command protocol or
    freeze/thaw mechanism - ie. either the port is in known state and
    accesses are interlocked or the port is frozen and irq handler won't
    do anything interfering with EH until EH brings the port back to sane
    state. If something goes wrong in the process, the port will get
    frozen and reset, so we should be able to survive most conditions.

    Ports on the same host are a bit more complicated. Only a single EH
    can proceed on a host. ie. EHs for two separate ports won't proceed
    at the same time (ap->eh_owner); however, this doesn't prevent from
    normal issue path of another path racing with EH of another port. In
    this case, the EH routine should grab the host lock explicitly. The
    latter case wasn't common so the compromise for simplicity.

    Thanks.

    --
    tejun


    \
     
     \ /
      Last update: 2011-04-23 02:59    [W:0.021 / U:87.404 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site