lkml.org 
[lkml]   [2004]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ide-cd problem
On Sat, Nov 20 2004, Alan Chandler wrote:
> I have been trying to track down why all attempts to burn a cd on my
> ide cdrw fails (see bug #3741 on bugzilla ), with a subprocess of
> cdrecord ending up hanging in uninterruptable sleep state.
>
> I think I understand what is happening, I just don't know what to do
> about it.
>
> Inside drivers/ide/ide-cd.c
>
> the ide_do_rw_cdrom routine has been called via a request with the
> request flags having the REQ_BLOCK_PC flag set. The request->data_len
> of this request is set to 0.
>
> This request is sent to the device and it generates interrupts to
> eventually land it up inside the routine cdrom_newpc_intr.
>
> At this point the status register on the hardware is set to 0x58 -
> implying, I think that the DRQ_STAT bit is set and that something
> should be sent to the device.
>
> Normally, because the requested data_len is not zero, the data is
> sent. In this case however, because the original request had nothing
> to send, the while/if clauses to initiate a new transfer are skipped
> and the routine ends up setting a new interrupt handler address and
> returning to await an interrupt that will never come.

The big question is - what does the original command look like? Just
dumping rq->cmd[0] would be a big help, but really just put code in
sg_io() in block/scsi_ioctl.c to dump the completed sg_io_hdr_t and send
that.

> Question: should something validate that the request length is not
> zero earlier, or should there be a check in ide-cd.c, or is it my
> hardware (its a generic cd read/rewriter which announces itself as
> 'CW078D CD-R/RW')

It's hard to know, you would have to parse every command type to verify
if the dxfer_len made sense or not. It's perfectly possible to generate
a command that would hang the drive as you describe above, only to be
aborted after it times out.

--
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.062 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site