lkml.org 
[lkml]   [2007]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [OOPS] 2.6.21-rc6-git5 in cfq_dispatch_insert
    On Tue, Apr 24 2007, Roland Kuhn wrote:
    > Hi Jens!
    >
    > On 24 Apr 2007, at 14:32, Jens Axboe wrote:
    >
    > >On Tue, Apr 24 2007, Roland Kuhn wrote:
    > >>Hi Jens!
    > >>
    > >>[I made a typo in the Cc: list so that lkml is only included as of
    > >>now. Actually I copied the typo from you ;-) ]
    > >
    > >Well no, you started the typo, I merely propagated it and forgot to
    > >fix
    > >it up :-)
    > >
    > Actually, I copied it from your printk() ;-) (thinking helps...)

    Ahhh! Yeah that one indeed has a typo, tsk tsk.

    > >>>>>Sure. You might want to include NFS file access into your tests,
    > >>>>>since we've not triggered this with locally accessing the disks.
    > >>>>>BTW:
    > >>>>
    > >>>>How are you exporting the directory (what exports options) - how
    > >>>>is it
    > >>>>mounted by the client(s)? What chunksize is your raid6 using?
    > >>>
    > >>>And what are the nature of the files on the raid (huge, small, ?)
    > >>>and
    > >>>what are the client(s) doing? Just approximately, I know these
    > >>>things
    > >>>can be hard/difficult/impossible to specify.
    > >>>
    > >>The files are 100-400MB in size and the client is merging them into a
    > >>new file in the same directory using the ROOT library, which does in
    > >>essence alternating sequences of
    > >>
    > >>_llseek(somewhere)
    > >>read(n bytes)
    > >>_llseek(somewhere+n)
    > >>read(m bytes)
    > >>...
    > >>
    > >>and then
    > >>
    > >>_llseek(somewhere)
    > >>rt_sigaction(ignore INT)
    > >>write(n bytes)
    > >>rt_sigaction(INT->DFL)
    > >>time()
    > >>_llseek(somewhere+n)
    > >>...
    > >>
    > >>where n is of the the order of 30kB. The input files are treated
    > >>sequentially, not randomly.
    > >
    > >Ok, I'll see if I can reproduce it. No luck so far, I'm afraid.
    > >
    > Too bad.
    >
    > >>BTW: the machine just stopped dead, no sign whatsoever on console or
    > >>netconsole, so I rebooted with elevator=deadline
    > >>(need to get some work done besides ;-) )
    > >
    > >Unfortunately expected, if we can race and lose an update to -
    > >>next_rq,
    > >we can race and corrupt some of the internal data structures as
    > >well. If
    > >you have the time and inclination, it would be interesting to see
    > >if you
    > >can reproduce with some debugging options enabled:
    > >
    > >- Enable all preempt, spinlock and lockdep debugging measures
    > >- Possibly slab poisoning, although that may slow you down somewhat
    > >
    > Kernel compilation under way, will report back.

    Thanks!

    > >Are you using 4kb stacks?
    > >
    > No idea, 'grep -i stack .config' gives no indication, but ISTR that
    > 4k was made the default some time back?

    You are on x86-64, my mistake.

    --
    Jens Axboe

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

    \
     
     \ /
      Last update: 2007-04-24 15:13    [W:3.308 / U:0.648 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site