[Debburn-devel] Re: Bug#413960: wodim: fails to burn with dev='0, 0, 0' but burns with dev='/dev/sr0'

[scdbackup at gmx.net]

Hi,

> > Vladimir Nadvornik wrote:
> > https://bugzilla.novell.com/show_bug.cgi?id=226019
> Eduard Bloch wrote:
> OMG. This is naturally a kernel issue.

Yes. But we know what happens if burner people and
kernel people quarrel over how SCSI should work
in Linux. ;)

After all, the SCSI locking issue is not the only
problem with a device groping automat.
I got a kernel 2.6 system here, where wodim and cdrskin
work fine with sg + hald and have trouble with sr + hald.

Looks like one has to choose: hald or reliable burning.

The decision to switch to /dev/srN on kernel 2.6 seems
reasonable, nevertheless. sr gives hope to have lock
coordination with growisofs. My vote: killall hald.


Have a nice day :)

Thomas

-------------------------------------------------------
Details:

I am testing now in cdrskin wether to use /dev/sr
on kernel 2.6.
On a SuSE 9.3, kernel "2.6.11.4-20a-default" i already
had lots of collisions with (i strongly believe):
  /usr/sbin/hald --daemon=yes
The drive is an USB attached 'PHILIPS SPD3300L'
at sg1 resp. sr1 resp. 1,0,0.

If i press the drive's load button, then my
program is not allowed to access the drive
because it is open O_EXCL for about 10 seconds.

Worse: If i let cdrskin or wodim load the tray,
then i catch the drive with replying random nonsense
to information requests like GET CONFIGURATION or
MODE SENSE.
The record holding alleged feature list length was
1.6 GB. Mode page 2Ah has wrong length and/or bad
content. 

To reproduce the problems, i need this start situation:
- hald running,
- the tray open, containing a DVD+RW
- usage of /dev/sr1 rather than /dev/sg1:
    wodim dev=/dev/sr1 -atip -eject
  or
    cdrskin dev=/dev/sr1 -atip -eject drive_scsi_dev_family=sr

If i stop hald, then /dev/sr1 with open tray is ok.
If the tray is closed and hald had its look, it is ok.
If there is no media in the tray, it is ok.
If i open /dev/sg1 rather than /dev/sr1, it is ok.
("ok" means 20 of 20 consecutive tries did work properly.
"not ok" means at most 7 successful tries in a row
before a failure occured.)


This all happens in varying frequency. In average about
one of five tries fails with some recognizable false reply.
(How much nonsense gets away undetected ?)

wodim-1.1.2 reports:

Device seems to be: Generic mmc2 DVD-R/DVD-RW.
wodim: Warning: controller returns zero sized CD capabilities page.
wodim: Warning: controller returns wrong size for CD capabilities page.
wodim: Warning: controller returns wrong page 0 for CD capabilities page (2A).
wodim: Warning: controller returns zero sized CD capabilities page.
wodim: Warning: controller returns wrong size for CD capabilities page.
wodim: Warning: controller returns wrong page 0 for CD capabilities page (2A).
wodim: Cannot attach driver for CD/DVD-Recorder.

cdrskin-0.3.5 in a similar situation reports:

LIBBURN: sbc_load()
LIBBURN: sbc_load():spc_test_unit_ready()= 0 0 0 0 1
LIBBURN: spc_test_unit_ready= 1
LIBBURN: MMC_GET_CONFIGURATION len=89294595
LIBBURN: spc_test_unit_ready= 1
LIBBURN: MMC_GET_CONFIGURATION len=0
cdrskin: status 6 BURN_DISC_UNSUITABLE "Media is not suitable"

(The "len" reply normally is 352 with that drive.)

I have not much of an idea wether the drive or
the kernel are to blame for such replies. One of them
(or even both) gets confused by the combination of
what hald is doing and what wodim or libburn are doing.

(Without TEST UNIT READY waiting after the START STOP UNIT
 command in sbc_load() the effect is quite reliable. At least
 half of the DVD+RW attempts fail. CD-RW begins to fail too.)

-------------------------------------------------------