Hi, me: > > Non-technical hint: > > It will be psycho-dynamically helpful if you > > can point to growisofs or cdrskin as failing
Joerg Schilling: > If other programs do not fail, > this does not verify a problem in cdrecord. This is well understood. Vice versa the failure of other programs would be a valuable information, if confirmed by Joe. If on the one hand cdrecord succeeds on XP and on the other hand cdrecord and growisofs fail on that Linux system, then it is obvious that the common hub is in the combination of kernel and controller. The SCSI command's form is out of suspicion, the controller-drive combination is ok. So the central suspect is the transport, beginning at ioctl(SGIO) and ending at the VIA VT6240 SATA controller. It will ease the communications with any Linux kernel people if it is made clear that they will not have to debug underneath cdrecord. They love you as much as you love them. Therefore my hint to Joe. To Joe MacDonald: I would appreciate if you exposed yourself to the rough social winds near the kernel. We only have a chance to get a remedy if there is a machine for hunting down the bug. Yours is the only candidate, currently. I am asking around where else one could get advise for Ubuntu 7.04 and a particular SATA controller. (I myself use a kernel 2.4 with ide-scsi emulation resp. usb-scsi.) I have been pointed to Ubuntu kernel-team https://lists.ubuntu.com/mailman/listinfo/kernel-team which despite its official purpose "coordinate and plan kernel uploads for Ubuntu" has some requests and bug reports in its archives. Maybe Bill has a proposal ? Bill Davidsen: > Would it be reasonable to put debug in the kernel for > this reproducible case, such that it's easier to track what the kernel > is telling the controller? If you would team up with Joe and make his kernel tell what it is thinking then i could provide the program which sends the commands. It would be interesting to see how many mode page bytes are actually transmitted to the drive, and/or whether the error message is possibly fabricated by the driver. > I'm guessing it's not in the driver itself but in the > command filter, simply because this behavior has been seen in various > hardware. I am in doubt with the command filter theory. My favorite suspect is that VIA VT6240 in conjunction with its driver. Whatever, it's mere guessing in front of a blackbox yet. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
