From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 Description of problem: Sometimes when using dvdrecord (dvdrtools v0.1.3 /RH3), dvdrecord stalls. I am using an USB DVD writer. After this problem occurs, the process dvdrecord cannot be killed ( the same as super user), the DVD writer is no longer available Once the dvd burner has been restarted, user can kill the dvdrecord process and the machine works regularly afterward. Version-Release number of selected component (if applicable): How reproducible: Sometimes Steps to Reproduce: 1.burn a dvd 2.sometimes it fail Actual Results: sometimes it fail , accessing the dvd drive is not possible anymore untill the dvd drive has been stopped and started. Expected Results: less burning failed and a possibility to cope with the dvd burner afterward without having to restart it physically. Additional info: using "options ehci-hcd log2_irq_thresh=5 " decrease the problem's apparition frequency: 1 burning fails every 40 (average) burn without the option. with the option, user was able to burns dvd correctly 250 times before encoutering the problem
Created attachment 106273 [details] sysreport plus log file of what happen with debug kernel
Created attachment 106274 [details] sysreport plus log file of what happen with debug kernel kernel is a recompiled 2.4.21-20.EL . Options that have been changed are:CONFIG_USB_DEBUG=y and CONFIG_USB_STORAGE_DEBUG=y
Translation of the README for attachement 106274 : 1.gravure.* file match what happen when burning proceed correctly. plouf.* file match what happen when there is a problem in the burning process: faio_wait_on_buffer for writer timed out in dvdrecord. There has been no attempt to kill dvdrecord
Created attachment 106275 [details] logs with http://people.redhat.com/~lwoodman/RHEL3/
actually the setting of "options ehci-hcd log2_irq_thresh=5 " does not reduce the probability of having the problem occuring.
We know that EHCI locks up under load in kernel 2.4. There was a number of scenarios. Some were related to specific hardware. David Brownell supplied me with some fixes, but integrating them into 2.4 was risky, so I only applied about half to Marcelo's tree. I suppose we could try to pull at least those into RHEL 3 and pray that Pierre's specific failure is covered. But I don't see it happening. The realistic option is to plan a migration to RHEL 4.
*** Bug 156613 has been marked as a duplicate of this bug. ***
Thanks. I'm closing this as "Next release" as the problem isn't that severe (mighty annoying probably, but not severe).