You did write:
>> Executing 'read buffer' command on Bus 1 Target 0, Lun 0 timeout 40s
>> CDB: 3C 00 00 00 00 00 00 FC 00 00
>>
>> So the kernel doesn't timeout/return for some reason.
>> You can find the full log here:
>> http://muenchen-surf.de/lohmaier/cdrecord_atip_log
>>
>> If that information is not enough to handle the process, please tell me what
>> else you need. Thank you.
>>
>We seem to have an awful lot of these "CD burner doesn't work but it did in
>2.4" reports.
>Does anyone have the vaguest inklink of how we broke it?
There are various reasons....
One important problem of course is the fact that various distributors (e.g.
RedHat, Suse, Debian, Ubuntu) are ungrading cdrecord slower than the Linux
kernel changes it's interfaces. Related to is problem: the Linux Kernel folks
do not inform me before breaking Linux kernel interfaces, so I am informed too
late in order to add a workaround to cdrecord in time.
The most recent interface changes have been:
- Instead of fixing the bug that allowed anyone to send arbitrary SCSI
commands to CD/DVD-recorders (caused by not requiring write permission
on the node), the behavior of SCSI generic was changed (in 2.6.8.1).
Old behavior: open device as root and send commands as user.
New behavior: open device as user and send commands as root.
- Some time between January 2006 and 2004, a new rlimit "RLIMIT_NOFILE"
was added and implemented in a way that is not compatible to previous
kernel behavior.
Old behavior: mlockall(MCL_CURRENT|MCL_FUTURE) done as root was honored
for the same process if later continued as user.
New behavior: mlockall(MCL_CURRENT|MCL_FUTURE) done as root is no longer
honored for the same process if later continued as user.
Another problem is caused by the fact that various distributors (e.g. RedHat,
Suse, Debian, Ubuntu) are applying patches to cdrecord that break cdrecord.
The problem mentioned in this thread seems to be caused by the fact that
Linux sometimes ignores timeouts. I have no idea how to help in this (timeout)
case.
Jörg
--
EMail:[email protected] (home) Jörg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
