New Kernel, K3B Problems

anorman · 08-31-2004, 09:26 AM

After configuring and installing a 2.6 kernel (upgraded from 2.4), my K3B will not recognize my burner. It just gives a message saying that no device can be located and it will use the image recorder. I am wondering if there is a kernel option that I need to reconfigure/compile, or a permission error, or something else. Any suggestions would be helpful. The drive is recongnized by Linux, just not by K3B.

Thanks,
Norman

mykrob · 08-31-2004, 10:02 AM

what is your specific kernel verision? K3B is reported to be broken by 2.6.8:

Quote:

Do not use Kernel 2.6.8

A patch that was introduced into the kernel shortly before the 2.6.8 release makes K3b and also the dvd+rw-tools unusable on Linux (unless run as root but that is not recommended). The very important GET CONFIGURATION MMC command is rejected by the kernel for reasons I cannot see and writing commands like MODE SELECT also fail (K3b cannot detect CD writers without it) even when the device is opened O_RDWR. Until this issue has been solved I strongly recommend to stick to kernel version 2.6.7.

Update: The kernel guys are currently fixing the problem so the next kernel release should work again.

Update 2: The problem is NOT fixed in 2.6.8.1

Update 3: Be aware that kernel 2.6.8 also contains the memory leak which makes it impossible to write audio cds, even as root.

-myk

amosf · 08-31-2004, 10:39 AM

After many hours of playing with this it seems that k3b and growisofs are not sending commands correctly to the kernel and so are being prevented by the new verify command structure... this exists in 2.6.8.1 (not sure if its completely correct in that version) and it will exist in 2.6.9 due shortly - k3b and growisofs still won't work until they fix them.

To run current k3b on 2.6.8.1 the easy way is just to remove the call to verify_command in drivers/block/scsi_ioctl.c (comment out lines 196 and 197) which reverts to the old dangerous behaviour which can kill drives

in the 2.6.9 snapshots I've been just removing the line if (file->f_mode & FMODE_WRITE) as it seems that k3b is not opening the device for writing while issuing commands or something, so this works and is maybe a little safer since the commands are still filtered... This idea might also work with 2.6.8.1, tho I never tried it...

Anyway, looks like there will be a few problems while everybody catches up. The choices are to use 2.6.7 or patch the 2.6.8.1/2.6.9 kernel yourself to revert to earlier behaviour...

anorman · 08-31-2004, 11:38 AM

That would be it I guess. I'm using 2.6.8. So I guess i'll either revert back or wait until a kernel release fixed the problem. Thanks guys.

amosf · 08-31-2004, 11:47 AM

You could go to 2.6.7 for the moment if you don't want to muck with the kernel source...

There won't be a kernel fix for the problem tho. The changes are permanent and any change will have to be in k3b and growisofs by the looks. To quote Linus on linux-kernel regarding k3b and growisofs:

"Yes. I suspect that these projects have at least looked at each other, so
it's probably a problem that has its basis in cdrecord or some "original"
program.

"And yes, opening for reading used to work. After all, you didn't need a
"write()" system call, and the ioctl functions didn't use to check. It's a
potential security problem, and one that 2.6.8 fixed, and I don't think
we're willing to go back to the old setup.

"And trust me - I absolutely _hate_ breaking user-level programs. I'd love
to unbreak it from the kernel, but in this case I don't see any
alternatives, really."