I asked Nicolas to try running "cdrdao scanbus" and "cdrecord -scanbus" and here's what he got:

I don't think it a cdrecord/cdrdao problem because, I can burn cdrom
directly from these tools on command line. The problem appears when I
launch k3b and the splash screen shows "Scanning for devices".

But, here is the log you have asked :

* as regular user

cdrecord -scanbus
Cdrecord-Clone 2.01.01a03 (i686-pc-linux-gnu) Copyright (C) 1995-2005
Joerg Schilling
NOTE: this version of cdrecord is an inofficial (modified) release of
cdrecord
      and thus may have bugs that are not present in the original
version.
      Please send bug reports and support requests to
<cdrtools@packages.debian.org>.
      The original author should not be bothered with problems of this
version.

cdrecord: Warning: Running on Linux-2.6.14-debian
cdrecord: There are unsettled issues with Linux-2.5 and newer.
cdrecord: If you have unexpected problems, please try Linux-2.4 or
Solaris.
Linux sg driver version: 3.5.33
Using libscg version 'ubuntu-0.8ubuntu1'.
cdrecord: Warning: using inofficial version of libscg (ubuntu-0.8ubuntu1
'@(#)scsitransp.c      1.91 04/06/17 Copyright 1988,1995,2000-2004 J.
Schilling').
scsibus0:
        0,0,0     0) 'SEAGATE ' 'ST373307LSUN72G ' '0507' Disk
        0,1,0     1) *
        0,2,0     2) *
        0,3,0     3) *
        0,4,0     4) 'PLEXTOR ' 'CD-ROM PX-40TS  ' '1.05' Removable
CD-ROM
        0,5,0     5) *
        0,6,0     6) 'YAMAHA  ' 'CRW2100S        ' '1.0N' Removable
CD-ROM
        0,7,0     7) *

cdrdao scanbus
Cdrdao version 1.1.9 - (C) Andreas Mueller <andreas@daneb.de>
  SCSI interface library - (C) Joerg Schilling
  Paranoia DAE library - (C) Monty

Check http://cdrdao.sourceforge.net/drives.html#dt for current driver
tables.

Using libscg version 'schily-0.8'

ATA:1,0,0            PIONEER , DVD-RW  DVR-108 , 1.20

* as root

cdrecord -scanbus
Cdrecord-Clone 2.01.01a03 (i686-pc-linux-gnu) Copyright (C) 1995-2005
Joerg Schilling
NOTE: this version of cdrecord is an inofficial (modified) release of
cdrecord
      and thus may have bugs that are not present in the original
version.
      Please send bug reports and support requests to
<cdrtools@packages.debian.org>.
      The original author should not be bothered with problems of this
version.

cdrecord: Warning: Running on Linux-2.6.14-debian
cdrecord: There are unsettled issues with Linux-2.5 and newer.
cdrecord: If you have unexpected problems, please try Linux-2.4 or
Solaris.
Linux sg driver version: 3.5.33
Using libscg version 'ubuntu-0.8ubuntu1'.
cdrecord: Warning: using inofficial version of libscg (ubuntu-0.8ubuntu1
'@(#)scsitransp.c      1.91 04/06/17 Copyright 1988,1995,2000-2004 J.
Schilling').
scsibus0:
        0,0,0     0) 'SEAGATE ' 'ST373307LSUN72G ' '0507' Disk
        0,1,0     1) *
        0,2,0     2) *
        0,3,0     3) *
        0,4,0     4) 'PLEXTOR ' 'CD-ROM PX-40TS  ' '1.05' Removable
CD-ROM
        0,5,0     5) *
        0,6,0     6) 'YAMAHA  ' 'CRW2100S        ' '1.0N' Removable
CD-ROM
        0,7,0     7) *

cdrdao scanbus
Cdrdao version 1.1.9 - (C) Andreas Mueller <andreas@daneb.de>
  SCSI interface library - (C) Joerg Schilling
  Paranoia DAE library - (C) Monty

Check http://cdrdao.sourceforge.net/drives.html#dt for current driver
tables.

Using libscg version 'schily-0.8'

0,4,0 : PLEXTOR , CD-ROM PX-40TS  , 1.05
0,6,0 : YAMAHA  , CRW2100S        , 1.0N
ATA:1,0,0            PIONEER , DVD-RW  DVR-108 , 1.20


None of these commands trigger the errors.

I have experienced similar system-wide crash with k3b and scsi burner as those
described in the Debian mailing list URLs above in the original bug reporter.

I have submitted a bug report to bugzilla.kernel.org which also describes
which kernel versions have this problem.

http://bugzilla.kernel.org/show_bug.cgi?id=5776

I get a total system lock which I can't even use SysRq to do an emergency reboot. I have used cdrecord without problems on 2.6.14 kernels.

I get no information in the system logs, even when telling syslog to sync
the logs to disk for each write. If I unload the scsi driver, I can use
k3b on affected kernels without problems.

[root@tigerclaw /home/srdjant]# cdrdao scanbus
Cdrdao version 1.1.9 - (C) Andreas Mueller <andreas@daneb.de>
  SCSI interface library - (C) Joerg Schilling
  Paranoia DAE library - (C) Monty

Check http://cdrdao.sourceforge.net/drives.html#dt for current driver tables.

Using libscg version 'schily-0.8'

1,4,0 : GENERIC , CRD-BP4         , 4.28
ATA:1,1,0            HL-DT-ST, DVDRAM GSA-4163B, A104

Brent Busby <brent@keycorner.org> has added the following to the Debian bug tracker:

I have this problem also.  I'm running a self-compiled Linus kernel
2.6.15, with an Adaptec 29160N controller, two Ultra-160 hard drives, a
Plextor 12/10/32S CD-RW, and a Seagate Scorpion-40 DAT tape drive on the
SCSI bus.  There is also an LG DVD-RAM/DVD-RW combo drive on the ATAPI
side, which I formerly used on kernel 2.4.31 via the ide-scsi emulation
module.

Ironically, k3b can see my ATAPI drive on 2.6.15 with no need for
ide-scsi emulation, but it cannot see my true SCSI Plextor drive, even
if I tell it the exact dev node to scan for, plus I am getting the exact
same errors in syslog as the other users who have posted bug reports,
during K3b's device scan.  From the shell, 'cdrecord -scanbus' finds
devices, but only when it is setuid root.  (It doesn't help k3b find it
even then though.)  My burners' device nodes are mode 660, root:cdrom,
and I am in the cdrom group.

Everything worked on 2.4.31.  I've read recommendations in many forums
that people experiencing this should burn as root, but not only is that
probably not very safe for stability (some people have reported lockups
trying to get around this that way), it is also unlikely to happen on
multiuser systems where not everyone who has an account is going to be
given root access.  It seems that making cdrecord setuid is not enough
either -- the newer kernels seem to require these SCSI commands to be
coming from a truly root-owned process.

the problem is that I do not own any true scsi devices to test k3b's scsi 
support.

Brent Busby <brent@keycorner.org> added the following comment on the Debian bug tracker:

I've seen a lot of people on the LKML who saw breakage around 2.6.9 or
so.  Linus said there use to be a practice in many userland applications
of opening a block device for read, and then writing to it.  When the
kernel stopped honoring that for security reasons, lots of apps broke.
K3b did that when its splash screen started, during the scan for CD
devices, and that's why people were getting writers either not detected
or misidentified as readers, even in cases where cdrecord from the shell
worked.  I'm now running Debian's 2.6.8 kernel package and everything
works, but probably people who want to run newer upstream kernels who
have this problem may have to wait for etch.  More and more, the
userland apps are getting fixed upstream to work with the new kernels,
but the older versions in sarge just get their SCSI commands blocked.

k3b 0.12.10 does open the device for writing when necessary. so that should 
not be the problem....

does 0.12.15 work?

k3b 0.12.15 does not work for me on kernel 2.6.17, so I guess not.

I'm not sure if I have a different bug than the one Francois Marier originaly posted.

Last time I ran tests, cdrecord was finding the SCSI burner fine, while k3b
was locking up the machine. I don't have much free time for this, at the moment,
but it would be a good idea I suppose to try using cdrecord code in k3b, and
seeing if that makes k3b work.

This is still affecting my SCSI burner. The IDE burner is working totally
fine.

It would be great to know the last command k3b issued before the system locked up (k3b console output) or at least the system log.

The system locks up so hard, that I don't get anything to my system log.
The last thing k3b prints is in my kernel bugzilla report (see comment #2 above).

From my bugzilla report:

   K3B manages to output only:
   [srdjant@tigerclaw ~]$ k3b: (K3bPluginManager) lib libk3bffmpegdecoder not found
   k3b: (K3bPluginManager) lib libk3bflacdecoder not found
   k3b: (K3bPluginManager) lib libk3bmpcdecoder not found

   before crashing. When running K3B on non-crashing kernels, the next message
   printed, after the above, is:

   k3b: (K3bExternalBinManager) Cdrecord 2.1 features: gracetime, overburn,
         cdtext, clone, tao, cuefile, xamix, plain-atapi, hacked-atapi

I can put in a load of printf's, and try to capture the output, if that will help.

it would, yes. if possible, please flush all of them so we do not get buffered 
output.

Created attachment 16758 [details]
Printline patch for k3b-0.12.15

I tried to isolate all ioctl() calls, and put printline statements before and
after each.

Created attachment 16759 [details]
Printline output, copied by hand.

is /dev/sr0 your writer?
Seems the problematic command is the simple INQUIRY which should be supported by every scsi device.

Created attachment 16760 [details]
Scsi target info from cdrecord under linux 2.6.17 (k3b would crash if used)

Yes, /dev/sr0 is my writer.

k3b 0.12.15 works very nicely with kernels <= 2.6.13.4
As soon as I hit 2.6.14, the system hangs.
Cdrecord isn't affected by this problem, which is why it would be interesting
to
"borrow" cdrecord code and stick it in k3b.

I did a diff between linux 2.6.13.4 and 2.6.14 some months ago, and there have
been various API changes in the scsi code. But cdrecord works in any case.

using code from cdrecord is not that simple. cdrecord uses libschily which is 
IMHO way to big for k3b and not necessary. There is no point in trying it 
because it won't tell us much if it worked.
I just found one problem in the SCSI code in k3b which is fixed in 0.12.16. 
maybe it also solves this issue.... if you are interested in trying it please 
ask me for the download link in private as it has not been released yet.

does it work with 0.12.17?

Sebastian,

I was trying to find exactly which patch in the kernel caused the hangs
that I had.

k3b-0.12.17 hung the kernel.
k3b-1.0pre2 did not.

See:  http://marc.theaimsgroup.com/?l=linux-scsi&m=116381916417215&w=2

Actual git commit is here together with the patches: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=186d330e682210100c671355580a8592e4a21692

Francois,

Any chance you can try k3b-1.0pre2 and see if that works?

I no longer have a SCSI burner myself so I can no longer test this, but I have asked the original reporters to comment on this if they are still having problems.

Marking as NEW because it has been diagnosed and nailed down to a specific commit in the kernel.

looks like this is fixed. Right?

Sebastian,

I just burnt a CD-RW with k3b-1.0pre2, under Linux 2.6.18-git21.
There was no crash. CD was burnt ok. Verified data using md5sum.

With the previous k3b versions, this would've locked up my system,
however it seems that you fixed this.

Christoph,

I only diagnosed which commit it was that caused my problem. I don't
know if this is also the same problem that the original post reports.
It could be that those problems are caused by a different commit.

I marked it as NEW, not as RESOLVED. By specifying the commit in the kernel, it seemed clear, that it is not just a simple user error, since you found a condition which allowed you to enable or disable the crash. In my opinion this merits marking the bug as confirmed.

Why? This one seems fixed if it works in 1.0?

Slight misunderstanding here. I marked it NEW in comment 20 before Srdjan posted comment 22 in which he stated that it worked. Since he addressed me directly, I gave some explanation in comment 23. I also think that this can be closed but have not done so myself, since it is worth waiting to hear from the original downstream reporter to see if the original bug is also fixed (see comment 19).

Ok, than let's wait for the original poster of the bug.

I've pinged the original reporters of the bug (on the Debian bug tracker) about a week ago, so you can probably close this bug on monday if you haven't heard anything by then.

There has been no information in a long time. I cannot reproduce the bug so I 
will close it.