Bug 3741

forgot to say - motherboard is Elite K7S5A with SIS5513 IDE chipset. 

ide-cd is sick.   In 2.6, please use /dev/hdc directly:

    cdrecord -dev /dev/hdc ...

This doesn't appear to make very much difference. 
 
I tried two things (as you will see from log timings, in the opposite order as 
presented) 
 
Leaving my setup as is - ide-cd is loaded in /etc/modules 
 
Then cdrecord -dev /dev/hdc blank=fast hangs with the following appearing on 
the console and in sylog every minute or so 
 
Nov 13 11:17:52 kanger kernel: hdc: lost interrupt 
Nov 13 11:18:32 kanger kernel: hdc: lost interrupt 
Nov 13 11:19:12 kanger kernel: hdc: lost interrupt 
Nov 13 11:19:52 kanger kernel: hdc: lost interrupt 
Nov 13 11:20:32 kanger kernel: hdc: lost interrupt 
Nov 13 11:21:52 kanger last message repeated 2 times 
Nov 13 11:22:32 kanger kernel: hdc: lost interrupt 
Nov 13 11:23:52 kanger last message repeated 2 times 
Nov 13 11:24:32 kanger kernel: hdc: lost interrupt 
 
And added the following to the kernel boot line hdc=ide-scsi hdd=ide=scsi 
 
loaded ide-scsi via /etc modules and then used 
 
cdrecord -dev=/dev/sr0 blank=fast 
 
(no /dev/hdc was created via udev) 
 
this gave the normal pre-amble of cdrecord and then  
 
Device type    : Removable CD-ROM 
Version        : 0 
Response Format: 1 
Vendor_info    : 'CD-R/RW ' 
Identifikation : 'CW078D CD-R/RW  ' 
Revision       : '14SD' 
Device seems to be: Generic mmc CD-RW. 
Using generic SCSI-3/mmc   CD-R/CD-RW driver (mmc_cdr). 
Driver flags   : MMC-2 SWABAUDIO BURNFREE 
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R 
resid: 4 
resid: 2 
resid: 4 
resid: 2 
cdrecord: Warning: controller returns zero sized CD write parameter page. 
cdrecord: Warning: controller returns wrong size for CD write parameter page. 
cdrecord: Warning: controller returns wrong page 0 for CD write parameter page 
(5). 
cdrecord: Warning: controller returns zero sized CD write parameter page. 
cdrecord: Warning: controller returns wrong size for CD write parameter page. 
cdrecord: Warning: controller returns wrong page 0 for CD write parameter page 
(5). 
cdrecord: Cannot init drive. 
 
 
and the following appeared in syslog 
 
Nov 13 11:08:42 kanger kernel: hdc: lost interrupt 
Nov 13 11:08:42 kanger kernel: hdc: DMA disabled 
Nov 13 11:08:42 kanger kernel: hdc: ATAPI reset complete 
Nov 13 11:09:02 kanger kernel: scsi: Device offlined - not ready after error 
recovery: host 0 channel 0 id 8 lun 0 
Nov 13 11:09:02 kanger kernel: scsi0 (8:0): rejecting I/O to offline device 
Nov 13 11:09:02 kanger last message repeated 42 times 
Nov 13 11:09:02 kanger kernel: SCSI error: host 0 id 8 lun 0 return code = 
4000000 
Nov 13 11:09:02 kanger kernel: ^ISense class 0, sense error 0, extended sense 0 
 
 
 
 

I'm suffering exactly the same bug but in Fedora Core 3 (kernel 2.6.9):

Cdrecord-Clone 2.01-dvd (i686-pc-linux-gnu) Copyright (C) 1995-2004 J

Things seem to be getting worse with later versions of the kernel 
 
with 2.6.10-rc2, I can't get past initialising the drives during startup. 
 
I had put a lot of printk's in ide-cd.c in order to find out what was 
happening, and its the sending of a command packet and never getting the 
complete interrupt, it keeps timing out until it gets to the point where 
something else reports an error - such as these type of error messages 
 
hdc: status timeout: status=0xd0 { Busy }  
hdc: status timeout: error=0xd0LastFailedSense  
 
and never recovers at that point. 
 
 
I thought maybe the printk's were the problem so took them all out, but this 
had minimal effect (initialisation seem to get fractionally further). 
 
Thinking it might be the .config I used I reverted to 2.6.9 with the same 
config - and this boots fine. 
 
(What is below is whats in the dmesg output from a boot of 2.6.9 - this is the 
place where 2.6.10-rc2 is having problems) 
 
hdc: ATAPI 48X CD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33) 
Uniform CD-ROM driver Revision: 3.20 
hdd: ATAPI 40X DVD-ROM drive, 512kB Cache, UDMA(33) 
 

I have done a detailed analysis of the problem with this drive, and although 
the initial symptoms show one thing, it turns out that the drive is delivering 
additional interrupts well after (actually less than a millisecond, but long 
enough that the next request was being processed) the io that is is performing 
has completed.  This seems to occur on the first "READ BUFFER" command. 
 
I have to conclude that its a faulty drive. There is no indication in the 
content of the control registers at the time the command should have completed 
that it did not do so succesfully and therefore will interrupt again, and when 
it does interrupt again it is necessary to properly read all the data again to 
pursuade the drive to stop setting its busy and drq flags.  Failure to do so 
leaves the drive locked in the busy state until a reset is performed. As a 
result, the doesn't seem any reasonable software solution to make it 
operational. 

But in my situation the same CDRW Unit work without problems with KNOPPIX
(kernel 2.4 series), but with the 2.6.10 does not. What tests can I run to try
to solve or report more data to this bug?

This bug is also discussed in:
http://bugs.debian.org/265747

Alan Chandler has stopped working on this bug as he bought a new one (with a
better firmware).

Sadly his explanation is somewhat limited (it would have helped to know which
code functions he tested). Newest kernel ide-cd seems more prone to get into an
uninterruptible loop :(

There are some patches in -mm that may be valuable to try (i will do it asap).

Also strangely cdrom.h doc tell to use O_NONBOCK and ide-cd/cdrecord use SG_IO
ioctl (which does not support O_NONBLOCK) ...


Also i don't think cdrecord dev=ATA:0,0,0 and cdrecord /dev/hd# is different ,
those are just frontend syntax for the libscg library which translate them all
to /dev/hd# if using the ATA interface (ide-cd).

However thanks for the new improvments in ide and libata. There have been a lot
of experimental ATAPI code for years, but few reached the stable kernel.

My drive is a MITSUMI , underlying board VIA (way more info in the debian bts):

some logs before the driver loop:
hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown
hda: drive not ready for command
hda: status timeout: status=0xd0 { Busy }
ide: failed opcode was: unknown
hda: DMA disabled
hda: drive not ready for command
hda: ATAPI reset complete
hda: request sense failure: status=0x51 { DriveReady SeekComplete Error }
hda: request sense failure: error=0x50 { LastFailedSense=0x05 }

just in case those are known messages. I ll try to provide more soon.

Is a problem still present in 2.6.15? 

I'd suggest you revert a couple og version back, I'm running
cdrecord_2.0+a30.pre1-1_i386, which is working fine.

Please reopen this bug if it's still present in kernel 2.6.17.

  The bug still exists in FC5 with all current updates and a Cyberdrive CW038D.
 Please reopen.  (I'm also available for testing, though I lack the
kernel-related background and would have to be walked through tests.  The CW038D
is currently being sold for $17.99 with free shipping at pcdirect.com, so if
someone in the US with a more suitable background is willing to run tests, I'd
be willing to order one and have it shipped.)
  The bug is also being discussed at
<http://bugzilla.kernel.org/show_bug.cgi?id=6745>.  I've seen references to the
problem affecting the CW038D, CW058D, CW078D, and CW088D, so basically
everything from Cyberdrive.
  Someone claimed that cdrdao works with these drives, and I find that it allows
writing to a blanked CD-RW, but not blanking one.  It doesn't seem to generate
system errors like cdrecord.

  Disregard what I said about cdrdao and blanking - it seems to work properly
for both writing and blanking.  The only problem is that recent versions only
work as root, not as an ordinary user.  This should be relatively easy to fix.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191684

Andre would you mind if we close the bug then?
Thanks.

I'm closing this one, please reopen if the problem is still there.