#include <hallo.h> * Manuel Cepedello Boiso [Wed, Mar 14 2007, 12:02:24AM]: > > > Same problem here using libata's PATA support (2.6.21-rc3 linux kernel). > Ufortunately, the patch doesn't improve the situation for me. Hope the > logs will provide something useful. > > BTW, cdrdao works pretty nicely instead.
This just does not add up. The only difference is IMO the driver used by /dev/sgX vs. /dev/sr0 (sg vs. sg_io). sg_io works pretty well, while sg does weird things: after few data writes it starts returning false sense codes indicating that the drive is busy (04/08, long drive in progress). So wodim keeps retrying, which is the correct way to do in order to not come to late. And after few dozens of retry it returns weird stuff and the process breaks. The issue is still confusing. Why does the problem not appear with the sg_io driver? There is no single occurence of a long-write-in-progress busy report. I would assume that the drive itself may be confused, maybe misconfigured by the driver which is corrupting the control messages (wild guess), or the driver returns bogus broken replies. But why does the problem not appear with cdrdao then, since it is usually using the sg driver. OTOH it uses an old copy of libscg which may not trigger that particular problem. You both are using LG drives. May be a coincidence since they are quite popular, or maybe not. I personaly think there is a driver bug. There is another report on the mailing list with long-write-in-progress where it should not happen, in the fixation phase after the drive should have reported OK after cache flushing. It just does not make sense, and the user has also an LG driver and is using the fake-SCSI access method. I don't have much time to do debug work this week, unfortunately. Eduard. -- <weasel> die alphascorpii ist naemlich mein grosses vorbild <weasel> wenn ich mal gross bin, werd ich so wie alphascorpii <alphascorpii> dann werd als erstes mal nicht groß ;)
