[lkml]   [2008]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [REGRESSION] 2.6.24/25: random lockups when accessing external USB harddrive
    On Mon, 23 Jun 2008, Stefan Becker wrote:

    > >>> I get random machine lockups when accessing my USB harddrive with
    > >>> kernels 2.6.24/25. They don't occur with kernel 2.6.23. During testing I
    > >>> figured out that it has something to do with the USB Bluetooth adaptor.
    > >>> If I remove it before the testing I don't get any lockups.
    > >
    > > Does the same problem still occur in 2.6.26-rc7?
    > Yes.
    > > Does it occur if you rmmod ehci-hcd?
    > Yes, i.e. it also happens when the external hardrive runs as USB 1.1
    > device with 12mpbs.
    > > Machine lockups are awfully hard to debug. Can you get any information
    > > at all (like Alt-SysRq-T) when this happens?
    > SysRq does not work when the machine locks up. I forgot to mention that
    > the test machine is a single CPU machine and that the CPU fan starts to
    > run full speed when the lockup occurs.
    > Guessing from the commit returned by git bisect there is a locking
    > error, i.e. the CPU runs into a spinlock that is already locked and
    > therefore busy loops.

    That is certainly possible. But an error like that should affect lots
    of different people and computers, not just your one machine.

    > > Can you add debugging
    > > printk statements to the USB bluetooth driver to try and localize where
    > > the hang occurs?
    > Any suggestions where to start?

    Around every place where the driver calls into the core. You might
    also want to debug the places where uhci-hcd acquires and releases

    > >>> git bisect resulted in the following bad commit:
    > >>>
    > >>> e9df41c5c5899259541dc928872cad4d07b82076 is first bad commit
    > >>> commit e9df41c5c5899259541dc928872cad4d07b82076
    > >>> Author: Alan Stern <>
    > >>> Date: Wed Aug 8 11:48:02 2007 -0400
    > >>>
    > >>> USB: make HCDs responsible for managing endpoint queues
    > >
    > > Knowing this doesn't help much without more information.
    > Too bad. Each bisect cycle took 2-3 hours and the whole process took me
    > 3 days :-( :-(

    I didn't mean that your efforts were wasted. They just don't help much
    at this point; maybe later on they will be more useful.

    > That commit has spinlock changes so I hoped that it would be a good
    > starting point. Is there a way to track the locks?

    Only what I suggested: Print something in the log whenever a lock is
    acquired or released.

    > > Do you have any idea why nobody else has reported this sort of problem?
    > > Is it reproducible on other machines?
    > I attached both USB devices to another, newer dual core laptop. I
    > couldn't reproduce the problem there, even when I simulated a single CPU
    > machine with maxcpus=1.

    Alan Stern

     \ /
      Last update: 2008-06-23 20:13    [W:0.023 / U:14.304 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site