Joerg Schilling wrote:
I am very surprised to hear this from you! You have complained many time over the years that people were finding problems in modified versions of cdrecord and blaming errors on your source. When I suggested getting the official source instead of some patched version, I would have expected you to agree completely that it is always better to use the real thing.Bill Davidsen <email@example.com> wrote:OK, I guess my first step is to wait until linux-source-2.6.20 arrives in testing so that I can try that. The system I am working on is my main workhorse, so I am reluctant to mess about with it much.Kernel source 22.214.171.124 is on ftp.kernel.org, if you want to see if there's a bug in the mainline kernel.Note that the Linux kernel folks do not like that these sources are used and claim that they are not useful for running a stable system. They rather point you to a distribution...... Replacing the custom kernel from Suse with one from kernel.org did never work for me without a big effort since Linux supports loadable modules.
I think you should stop having one policy for Linux kernel problems and another for cdrecord (and mkisofs, and cdda2wav). I stand by my recommendation, 2.6.21 is running on several of my machines and should be stable for a test. 2.6.22 is going to be very exciting for this group, the new scheduler code patches improve burning without realtime priorities, ripping, and multimedia playback under load.
-- bill davidsen <firstname.lastname@example.org> CTO TMR Associates, Inc Doing interesting things with small computers since 1979