> From: David Brownell <[EMAIL PROTECTED]> > Date: Wed, 02 Apr 2003 07:52:05 -0800
> I got a report of a problem with a high speed CD-ROM that > could be reproduced by a simple loop: > > dd if=/dev/scd0 of=cdrom.iso > cmp /dev/scd0 cdrom.iso > > The failure was reported on 2.4, so I wanted to know if it > showed up on 2.5 too. (Since usb-storage on 2.5 seems to > be more robust.) So I tried it, and it ran fine ... for > about an hour, then the script wedged completely. I thought Arjan and I plugged all such occurences, and I saw Greg's BK changeset with it. > Looking at the system state, there were no requests queued > to the EHCI driver; it wasn't even doing async schedule > processing any more. And the next level up was usb-storage, > which seemed to be waiting for requests too ... meanwhile, > the "dd" was blocked. Hmm... we never touched ehci-hcd. Make sure you aren't taking any semaphores without dropping right locks, and that you do not have any of this crap: p = kmalloc(N, in_interrupt()? GFP_ATOMIC: GFP_NOIO); -- it's a sure way to deadlock Better yet, visit the bkbits and glance for ohci changesets. There will be one with loads and loads of PCI posting changes, but among those it had locking corrections. > Alt-SysRq-T showed the "dd" blocking in the read; the relevant > bits are appended. Disassembly shows that blk_run_queues+0x146 > is a CLI instruction right after q->unplug_fn(q). Yeah, that's what I fixed (with ohci). -- Pete ------------------------------------------------------- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
