Bug 22289 - cd writing failed with autorun running
Summary: cd writing failed with autorun running
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: autorun   
(Show other bugs)
Version: 6.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact: Aaron Brown
Depends On:
TreeView+ depends on / blocked
Reported: 2000-12-14 09:51 UTC by Need Real Name
Modified: 2007-04-18 16:30 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-12-14 09:51:28 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Need Real Name 2000-12-14 09:51:25 UTC
Dear developers of RedHat Linux!

I'm using RedHat Linux 6.1 on a P400 with IDE Harddisks and an NCR
53c810A SCSI controller, where I've attached my ZIP-drive and for a few
days a HP9210i CD writer. The first time I started up with the cd-writer
attached for testing, as the box 'new hardware found' I checked 'keep
konfiguration', so nothing has been changed in the system and the
cd-writer worked fine with xcdroast and cdrecord.

After final install of the cd-writer I checked 'configure device' at the
time the cd-writer gets recogniced at startup. From this time on, I was
able to read from the cd, but writing cd's failed with scsi bus command
errors 'device not ready' (see error-output from cdrecord below) if I
did a real write. Everything runs ok in dummy-writes. I tried a lot of
things including disconnecting the zip-drive, changing cabling ...
without success. I tested the cd-writer in another machine using WinOnCd
and it worked well, so I thought my controller is defective. Testing
another SCSI controller (Adaptec 2904CD), the cd-writer worked well, but
the zip didn't because this controller is fixed to 10MB/s sync.
transfers. Testing again with a new ncr53c810A repeated the errors.

Finally I found out, that the 'autorun' program seems to
interrupt/destroy the scsi command queue. Disabling it, the cd writer
worked well even with my old controller. Why is has been working with
the adaptec controller is not clear for me.

* So please don't start programs like 'autorun' in the script
'startkde', where the user has no chance to disable it with standard
configuration tools.
* Furthermore 'autorun' is not killed and restarted if one user logs off
and another logs in. Thus it doesn't work anymore, as it tries to start
a program on a display which is owned by another user in between.
* Best of all would be configureing autorun to ignore CD writers.
* Another way may be to lock the scsi device to the cd-writing process,
so autorun is not able to check the device while writing a cd. Maybe
this is already done, but as the setup in RH Linux uses symlinks from
cdrom to the actual device, device locking via /var/lock may fail.

I hope this message could improve program developement and help
non-experienced users avoid similar pain. For me it costs 5 evenings and
10 cd's.

Roland Exler

PS: The problem is definitly not caused by scsi termination problems or
performance issues. Writing with speed 2 doesn't change anything. 'On
the fly' dummy-writes with speed 8 give a minimum buffer fill of 75%,
standard-writes result in 95% minimum buffer fill on my machine. If
requested, I could give you an detailed hardware list of all components
installed in my computer.

screenshot of cdrecord
[root@Sensor242 /root]# cdrecord dev=4,0 -speed=8 -v
Cdrecord release 1.8a29 Copyright (C) 1995-1999Jvrg Schilling
TOC Type: 1 = CD-ROM
scsidev: '4,0'
scsibus: 0 target: 4 lun: 0
Using libscg version 'schily-0.1'
atapi: 0
Device type    : Removable CD-ROM
Version        : 4
Response Format: 2
Capabilities   : SYNC
Vendor_info    : 'HP      '
Identifikation : 'CD-Writer+ 9200 '
Revision       : '1.0e'
Device seems to be: Generic mmc CD-RW.
Using generic SCSI-3/mmc CD-R driver (mmc_cdr).
Driver flags   : SWABAUDIO
Drive buf size : 4183808 = 4085 KB
FIFO size      : 4194304 = 4096 KB
Track 01: data  270 MB
Total size:     310 MB (30:43.52) = 138264 sectors
Lout start:     310 MB (30:45/39) = 138264 sectors
Current Secsize: 2048
ATIP info from disk:
  Indicated writing power: 4
  Is not unrestricted
  Is not erasable
  Disk sub type: 4
  ATIP start of lead in:  -11624 (97:27/01)
  ATIP start of lead out: 337349 (74:59/74)
Disk type: Long strategy type (Cyanine, AZO or similar)
Manuf. index: 34
Blocks total: 337349 Blocks current: 337349 Blocks remaining: 199085
Starting to write CD/DVD at speed 8 in write mode for single session.
Last chance to quit, starting real write in 1 seconds.
Waiting for reader process to fill input-buffer ... input-buffer ready.
Starting new track at sector: 0
Track 01: 270 of 270 MB written (fifo 100%).
Track 01: Total bytes read/written: 283160576/283160576 (138262
Writing  time:  235.787s
cdrecord: Eingabe-/Ausgabefehler. close track/session: scsi sendcmd:
retryable error
CDB:  5B 00 02 00 00 00 00 00 00 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 02 00 00 00 00 12 00 00 00 00 04 01 00 00
Sense Key: 0x2 Not Ready, Segment 0
Sense Code: 0x04 Qual 0x01 (logical unit is in process of becoming
ready) Fru 0x0
Sense flags: Blk 0 (not valid)
cmd finished after 13.509s timeout 480s
cdrecord: Eingabe-/Ausgabefehler. test unit ready: scsi sendcmd:
retryable error
CDB:  00 00 00 00 00 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 02 00 00 00 00 12 00 00 00 00 30 00 00 00
Sense Key: 0x2 Not Ready, Segment 0
Sense Code: 0x30 Qual 0x00 (incompatible medium installed) Fru 0x0
Sense flags: Blk 0 (not valid)
Fixating time:  128.972s
cdrecord: fifo had 8642 puts and 8642 gets.
cdrecord: fifo was 0 times empty and 7474 times full, min fill was 95%.
[root@Sensor242 /root]#

Roland Exler                           mailto:R.Exler@jk.uni-linz.ac.at
Institute of Measurement Technology    http://Sensor200.emt.uni-linz.ac.at
Altenbergerstr. 69                     Tel. (+43) 732 / 2468 - 9774
A - 4040 Linz, Austria                 Fax. (+43) 732 / 2468 - 9233

Note You need to log in before you can comment on or make changes to this bug.