OOPS: 2.5.1-pre8 - cdrecord + ide_scsi

OOPS: 2.5.1-pre8 - cdrecord + ide_scsi

[Carl Ritson]

Got this at the very start of burning a cd, nothing special, using
ide-scsi build into kernel. "cdrecord -v dev=0,0,0 speed=4 img.iso".
Box is Dual-PIII 866, 1GB Ram, all IDE system.

Carl Ritson
critson@perlfu.co.uk
--------------------
ksymoops 2.4.0 on i686 2.5.1-pre8.  Options used
     -v /usr/src/linux/vmlinux (specified)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.5.1-pre8/ (default)
     -m /usr/src/linux/System.map (specified)

Unable to handle kernel NULL pointer dereference at virtual address
00000090
c01cd0e0
*pde = 00000000
Oops: 0000
CPU:    1
EIP:    0010:[<c01cd0e0>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00210292
eax: 00000000   ebx: f7e80000   ecx: 00000001   edx: c03b5024
esi: ffffffff   edi: ffffffff   ebp: c03b5024   esp: f5cabb28
ds: 0018   es: 0018   ss: 0018
Process cdrecord (pid: 1592, stackpage=f5cab000)
Stack: f7e80000 f69c94a0 c03b5068 c03b5024 c0324000 00000000 00000000
c1e41f80
       fffffc18 00000000 c0324000 00200246 00000000 f7e9b5a0 c1e41f80
c01e0465
       00000000 f69c94a0 f7e80000 f7e83000 00000001 c03b5068 c03b5024
c01e0550
Call Trace: [<c01e0465>] [<c01e0550>] [<c01e0ab0>] [<c01e2b5c>]
[<c01f9def>]
   [<c01f9f2d>] [<c01dca69>] [<c01dce2e>] [<c01dd504>] [<c01fa91a>]
[<c01eaaeb>]
   [<c01eafb8>] [<c01f0373>] [<c01ef7b1>] [<c01ef7fe>] [<c01eace2>]
[<f8ab0e8b>]
   [<f8ab1ab8>] [<f8ab0c9a>] [<f8ab10d8>] [<c012f0a2>] [<f8ab38a6>]
[<f8ab3975>]
   [<c01b9f7c>] [<c012f24f>] [<c01b6813>] [<c01b612e>] [<c01b66a0>]
[<c01b889e>]
   [<c01b8922>] [<c01b434b>] [<c0142db7>] [<c0106e5b>]
Code: 8b 90 90 00 00 00 83 e2 04 89 54 24 28 83 7c 24 34 00 0f 84

>>EIP; c01cd0e0 <blk_rq_map_sg+28/1d0>   <=====
Trace; c01e0465 <ide_build_sglist+1d/d4>
Trace; c01e0550 <ide_build_dmatable+34/174>
Trace; c01e0ab0 <ide_dmaproc+100/228>
Trace; c01e2b5c <via82cxxx_dmaproc+b8/cc>
Trace; c01f9def <idescsi_issue_pc+6b/190>
Trace; c01f9f2d <idescsi_do_request+19/44>
Trace; c01dca69 <start_request+129/19c>
Trace; c01dce2e <ide_do_request+2de/338>
Trace; c01dd504 <ide_do_drive_cmd+108/140>
Trace; c01fa91a <idescsi_queue+57e/5d8>
Trace; c01eaaeb <scsi_dispatch_cmd+107/198>
Trace; c01eafb8 <scsi_done+0/9c>
Trace; c01f0373 <scsi_request_fn+3a7/3cc>
Trace; c01ef7b1 <__scsi_insert_special+71/80>
Trace; c01ef7fe <scsi_insert_special_req+1a/20>
Trace; c01eace2 <scsi_do_req+b2/b8>
Trace; f8ab0e8b <[sg]sg_common_write+1cb/1dc>
Trace; f8ab1ab8 <[sg]sg_cmd_done_bh+0/2c8>
Trace; f8ab0c9a <[sg]sg_new_write+1a2/1c8>
Trace; f8ab10d8 <[sg]sg_ioctl+23c/b0c>
Trace; c012f0a2 <_alloc_pages+16/18>
Trace; f8ab38a6 <[sg]sg_low_malloc+132/198>
Trace; f8ab3975 <[sg]sg_malloc+69/120>
Trace; c01b9f7c <pty_write+138/148>
Trace; c012f24f <__alloc_pages+33/164>
Trace; c01b6813 <opost_block+167/174>
Trace; c01b612e <initialize_tty_struct+16a/188>
Trace; c01b66a0 <opost+1a4/1b0>
Trace; c01b889e <write_chan+18a/228>
Trace; c01b8922 <write_chan+20e/228>
Trace; c01b434b <tty_write+1ff/26c>
Trace; c0142db7 <sys_ioctl+1bb/1f4>
Trace; c0106e5b <system_call+33/38>
Code;  c01cd0e0 <blk_rq_map_sg+28/1d0>
00000000 <_EIP>:
Code;  c01cd0e0 <blk_rq_map_sg+28/1d0>   <=====
   0:   8b 90 90 00 00 00         mov    0x90(%eax),%edx   <=====
Code;  c01cd0e6 <blk_rq_map_sg+2e/1d0>
   6:   83 e2 04                  and    $0x4,%edx
Code;  c01cd0e9 <blk_rq_map_sg+31/1d0>
   9:   89 54 24 28               mov    %edx,0x28(%esp,1)
Code;  c01cd0ed <blk_rq_map_sg+35/1d0>
   d:   83 7c 24 34 00            cmpl   $0x0,0x34(%esp,1)
Code;  c01cd0f2 <blk_rq_map_sg+3a/1d0>
  12:   0f 84 00 00 00 00         je     18 <_EIP+0x18> c01cd0f8
<blk_rq_map_sg+40/1d0>

Re: OOPS: 2.5.1-pre8 - cdrecord + ide_scsi

[Jens Axboe]

[-- Attachment #1: Type: text/plain, Size: 585 bytes --]

On Sun, Dec 09 2001, Carl Ritson wrote:
> Got this at the very start of burning a cd, nothing special, using
> ide-scsi build into kernel. "cdrecord -v dev=0,0,0 speed=4 img.iso".
> Box is Dual-PIII 866, 1GB Ram, all IDE system.

Agrh, because of a bug in ide-scsi conversion this (other) bug went
unnoticed for a while. Basically we cannot look up the request queue
reliably from a request, since it may not have originated from the block
layer. ide-scsi builds it's own, for example. For those, we don't want
to trust the sg count either.

Does attached patch work?

-- 
Jens Axboe


[-- Attachment #2: ide-dma-queue-1 --]
[-- Type: text/plain, Size: 641 bytes --]

--- /opt/kernel/linux-2.5.1-pre8/drivers/ide/ide-dma.c	Sun Dec  9 03:54:19 2001
+++ drivers/ide/ide-dma.c	Sun Dec  9 05:03:15 2001
@@ -226,12 +226,13 @@
 
 static int ide_build_sglist (ide_hwif_t *hwif, struct request *rq)
 {
+	request_queue_t *q = &hwif->drives[DEVICE_NR(rq->rq_dev) & 1].queue;
 	struct scatterlist *sg = hwif->sg_table;
 	int nents;
 
-	nents = blk_rq_map_sg(rq->q, rq, hwif->sg_table);
+	nents = blk_rq_map_sg(q, rq, hwif->sg_table);
 
-	if (nents > rq->nr_segments)
+	if (rq->q && nents > rq->nr_segments)
 		printk("ide-dma: received %d segments, build %d\n", rq->nr_segments, nents);
 
 	if (rq_data_dir(rq) == READ)

Re: OOPS: 2.5.1-pre8 - cdrecord + ide_scsi

[Jens Axboe]

On Sun, Dec 09 2001, Jens Axboe wrote:
> On Sun, Dec 09 2001, Carl Ritson wrote:
> > Got this at the very start of burning a cd, nothing special, using
> > ide-scsi build into kernel. "cdrecord -v dev=0,0,0 speed=4 img.iso".
> > Box is Dual-PIII 866, 1GB Ram, all IDE system.
> 
> Agrh, because of a bug in ide-scsi conversion this (other) bug went
> unnoticed for a while. Basically we cannot look up the request queue
> reliably from a request, since it may not have originated from the block
> layer. ide-scsi builds it's own, for example. For those, we don't want
> to trust the sg count either.
> 
> Does attached patch work?

Irk, there's a ide-scsi bug in there too. In
drivers/scsi/ide-scsi.c:idescsi_free_bio() change the kfree(bhp) to
bio_put(bhp)


-- 
Jens Axboe

Re: OOPS: 2.5.1-pre8 - cdrecord + ide_scsi

[Carl Ritson]

> On Sun, Dec 09 2001, Jens Axboe wrote:
> > On Sun, Dec 09 2001, Carl Ritson wrote:
> > > Got this at the very start of burning a cd, nothing special, using
> > > ide-scsi build into kernel. "cdrecord -v dev=0,0,0 speed=4 img.iso".
> > > Box is Dual-PIII 866, 1GB Ram, all IDE system.
> >
> > Agrh, because of a bug in ide-scsi conversion this (other) bug went
> > unnoticed for a while. Basically we cannot look up the request queue
> > reliably from a request, since it may not have originated from the block
> > layer. ide-scsi builds it's own, for example. For those, we don't want
> > to trust the sg count either.
> >
> > Does attached patch work?
>
> Irk, there's a ide-scsi bug in there too. In
> drivers/scsi/ide-scsi.c:idescsi_free_bio() change the kfree(bhp) to
> bio_put(bhp)
>

With both these fixes applied cdrecord hangs for 30 seconds, then spits
out "cdrecord: No such device or address. Cannot send SCSI cmd via ioctl",
a couple of hundred times.

In the from dmesg from the same time I get.
------
hdc: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdc: drive not ready for command
scsi: device set offline - command error recover failed: host 0 channel 0
id 0 lun 0
------

So no joy yet. :/

Carl Ritson
critson@perlfu.co.uk

Re: OOPS: 2.5.1-pre8 - cdrecord + ide_scsi

[Jens Axboe]

On Sun, Dec 09 2001, Carl Ritson wrote:
> 
> > On Sun, Dec 09 2001, Jens Axboe wrote:
> > > On Sun, Dec 09 2001, Carl Ritson wrote:
> > > > Got this at the very start of burning a cd, nothing special, using
> > > > ide-scsi build into kernel. "cdrecord -v dev=0,0,0 speed=4 img.iso".
> > > > Box is Dual-PIII 866, 1GB Ram, all IDE system.
> > >
> > > Agrh, because of a bug in ide-scsi conversion this (other) bug went
> > > unnoticed for a while. Basically we cannot look up the request queue
> > > reliably from a request, since it may not have originated from the block
> > > layer. ide-scsi builds it's own, for example. For those, we don't want
> > > to trust the sg count either.
> > >
> > > Does attached patch work?
> >
> > Irk, there's a ide-scsi bug in there too. In
> > drivers/scsi/ide-scsi.c:idescsi_free_bio() change the kfree(bhp) to
> > bio_put(bhp)
> >
> 
> With both these fixes applied cdrecord hangs for 30 seconds, then spits
> out "cdrecord: No such device or address. Cannot send SCSI cmd via ioctl",
> a couple of hundred times.
> 
> In the from dmesg from the same time I get.
> ------
> hdc: timeout waiting for DMA
> ide_dmaproc: chipset supported ide_dma_timeout func only: 14
> hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest }
> hdc: drive not ready for command
> scsi: device set offline - command error recover failed: host 0 channel 0
> id 0 lun 0
> ------

Please try a run with DMA disabled.

-- 
Jens Axboe

Re: OOPS: 2.5.1-pre8 - cdrecord + ide_scsi

[Carl Ritson]

On Sun, 9 Dec 2001, Jens Axboe wrote:
> > > > Agrh, because of a bug in ide-scsi conversion this (other) bug went
> > > > unnoticed for a while. Basically we cannot look up the request queue
> > > > reliably from a request, since it may not have originated from the block
> > > > layer. ide-scsi builds it's own, for example. For those, we don't want
> > > > to trust the sg count either.
> > > >
> > > > Does attached patch work?
> > >
> > > Irk, there's a ide-scsi bug in there too. In
> > > drivers/scsi/ide-scsi.c:idescsi_free_bio() change the kfree(bhp) to
> > > bio_put(bhp)
> > >
> >
> > With both these fixes applied cdrecord hangs for 30 seconds, then spits
> > out "cdrecord: No such device or address. Cannot send SCSI cmd via ioctl",
> > a couple of hundred times.
> >
> > In the from dmesg from the same time I get.
> > ------
> > hdc: timeout waiting for DMA
> > ide_dmaproc: chipset supported ide_dma_timeout func only: 14
> > hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest }
> > hdc: drive not ready for command
> > scsi: device set offline - command error recover failed: host 0 channel 0
> > id 0 lun 0
> > ------
>
> Please try a run with DMA disabled.
>

Ok works with DMA off, so I expect that this new error is due to my resent
memory upgrade (36 Hours ago) and the switch to using HIGHMEM(4GB)..
So am I to believe that DMA is a problem with HIGHMEM(4GB) enabled ?

Carl Ritson
critson@perlfu.co.uk

Re: OOPS: 2.5.1-pre8 - cdrecord + ide_scsi

[Jens Axboe]

On Sun, Dec 09 2001, Carl Ritson wrote:
> On Sun, 9 Dec 2001, Jens Axboe wrote:
> > > > > Agrh, because of a bug in ide-scsi conversion this (other) bug went
> > > > > unnoticed for a while. Basically we cannot look up the request queue
> > > > > reliably from a request, since it may not have originated from the block
> > > > > layer. ide-scsi builds it's own, for example. For those, we don't want
> > > > > to trust the sg count either.
> > > > >
> > > > > Does attached patch work?
> > > >
> > > > Irk, there's a ide-scsi bug in there too. In
> > > > drivers/scsi/ide-scsi.c:idescsi_free_bio() change the kfree(bhp) to
> > > > bio_put(bhp)
> > > >
> > >
> > > With both these fixes applied cdrecord hangs for 30 seconds, then spits
> > > out "cdrecord: No such device or address. Cannot send SCSI cmd via ioctl",
> > > a couple of hundred times.
> > >
> > > In the from dmesg from the same time I get.
> > > ------
> > > hdc: timeout waiting for DMA
> > > ide_dmaproc: chipset supported ide_dma_timeout func only: 14
> > > hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest }
> > > hdc: drive not ready for command
> > > scsi: device set offline - command error recover failed: host 0 channel 0
> > > id 0 lun 0
> > > ------
> >
> > Please try a run with DMA disabled.
> >
> 
> Ok works with DMA off, so I expect that this new error is due to my resent
> memory upgrade (36 Hours ago) and the switch to using HIGHMEM(4GB)..
> So am I to believe that DMA is a problem with HIGHMEM(4GB) enabled ?

No it's probably still an ide-scsi bug, I'm not suspecting your
hardware. The reason I ask is because until -pre8 (since bio merge in
-pre2), ide-scsi never used DMA even though it was set for the drive.

-- 
Jens Axboe

Re: OOPS: 2.5.1-pre8 - cdrecord + ide_scsi

[Jens Axboe]

[-- Attachment #1: Type: text/plain, Size: 695 bytes --]

On Sun, Dec 09 2001, Jens Axboe wrote:
> > Ok works with DMA off, so I expect that this new error is due to my resent
> > memory upgrade (36 Hours ago) and the switch to using HIGHMEM(4GB)..
> > So am I to believe that DMA is a problem with HIGHMEM(4GB) enabled ?
> 
> No it's probably still an ide-scsi bug, I'm not suspecting your
> hardware. The reason I ask is because until -pre8 (since bio merge in
> -pre2), ide-scsi never used DMA even though it was set for the drive.

Ok finally had a chance to look some more at this -- it was a bit more
hairy than I had hoped. Please try this ide-scsi one liner, it should
cure it. (the bug fix is the bio->bi_vcnt = 1 change only)

-- 
Jens Axboe


[-- Attachment #2: ide-scsi-dma-1 --]
[-- Type: text/plain, Size: 1226 bytes --]

--- /opt/kernel/linux-2.5.1-pre9/drivers/scsi/ide-scsi.c	Tue Dec 11 05:01:51 2001
+++ linux/drivers/scsi/ide-scsi.c	Tue Dec 11 09:24:14 2001
@@ -261,7 +261,7 @@
 	ide_drive_t *drive = hwgroup->drive;
 	idescsi_scsi_t *scsi = drive->driver_data;
 	struct request *rq = hwgroup->rq;
-	idescsi_pc_t *pc = (idescsi_pc_t *) rq->buffer;
+	idescsi_pc_t *pc = (idescsi_pc_t *) rq->special;
 	int log = test_bit(IDESCSI_LOG_CMD, &scsi->log);
 	struct Scsi_Host *host;
 	u8 *scsi_buf;
@@ -464,7 +464,7 @@
 #endif /* IDESCSI_DEBUG_LOG */
 
 	if (rq->flags & REQ_SPECIAL) {
-		return idescsi_issue_pc (drive, (idescsi_pc_t *) rq->buffer);
+		return idescsi_issue_pc (drive, (idescsi_pc_t *) rq->special);
 	}
 	blk_dump_rq_flags(rq, "ide-scsi: unsup command");
 	idescsi_end_request (0,HWGROUP (drive));
@@ -662,6 +662,7 @@
 	if ((first_bh = bhp = bh = bio_alloc(GFP_ATOMIC, 1)) == NULL)
 		goto abort;
 	bio_init(bh);
+	bh->bi_vcnt = 1;
 	while (--count) {
 		if ((bh = bio_alloc(GFP_ATOMIC, 1)) == NULL)
 			goto abort;
@@ -802,7 +803,7 @@
 	}
 
 	ide_init_drive_cmd (rq);
-	rq->buffer = (char *) pc;
+	rq->special = (char *) pc;
 	rq->bio = idescsi_dma_bio (drive, pc);
 	rq->flags = REQ_SPECIAL;
 	spin_unlock(&cmd->host->host_lock);

Re: OOPS: 2.5.1-pre8 - cdrecord + ide_scsi

[Carl Ritson]

On Tue, 11 Dec 2001, Jens Axboe wrote:

> On Sun, Dec 09 2001, Jens Axboe wrote:
> > > Ok works with DMA off, so I expect that this new error is due to my resent
> > > memory upgrade (36 Hours ago) and the switch to using HIGHMEM(4GB)..
> > > So am I to believe that DMA is a problem with HIGHMEM(4GB) enabled ?
> >
> > No it's probably still an ide-scsi bug, I'm not suspecting your
> > hardware. The reason I ask is because until -pre8 (since bio merge in
> > -pre2), ide-scsi never used DMA even though it was set for the drive.
>
> Ok finally had a chance to look some more at this -- it was a bit more
> hairy than I had hoped. Please try this ide-scsi one liner, it should
> cure it. (the bug fix is the bio->bi_vcnt = 1 change only)
>
>
This Patch appears to work fine.  Tested with DMA on and DMA off, no
Errors.. :)

Carl Ritson

Re: OOPS: 2.5.1-pre8 - cdrecord + ide_scsi

[Jens Axboe]

On Wed, Dec 12 2001, Carl Ritson wrote:
> On Tue, 11 Dec 2001, Jens Axboe wrote:
> 
> > On Sun, Dec 09 2001, Jens Axboe wrote:
> > > > Ok works with DMA off, so I expect that this new error is due to my resent
> > > > memory upgrade (36 Hours ago) and the switch to using HIGHMEM(4GB)..
> > > > So am I to believe that DMA is a problem with HIGHMEM(4GB) enabled ?
> > >
> > > No it's probably still an ide-scsi bug, I'm not suspecting your
> > > hardware. The reason I ask is because until -pre8 (since bio merge in
> > > -pre2), ide-scsi never used DMA even though it was set for the drive.
> >
> > Ok finally had a chance to look some more at this -- it was a bit more
> > hairy than I had hoped. Please try this ide-scsi one liner, it should
> > cure it. (the bug fix is the bio->bi_vcnt = 1 change only)
> >
> >
> This Patch appears to work fine.  Tested with DMA on and DMA off, no
> Errors.. :)

Super, thanks for testing.

-- 
Jens Axboe

Re: OOPS: 2.5.1-pre8 - cdrecord + ide_scsi

[Andre Hedrick]

Sorry Jens, you are mis-informed.
SCSI is only the packbuilder, but it is excuted by the ATA PacketCommand.

Regards,

Andre Hedrick
CEO/President, LAD Storage Consulting Group
Linux ATA Development
Linux Disk Certification Project

On Sun, 9 Dec 2001, Jens Axboe wrote:

> On Sun, Dec 09 2001, Carl Ritson wrote:
> > On Sun, 9 Dec 2001, Jens Axboe wrote:
> > > > > > Agrh, because of a bug in ide-scsi conversion this (other) bug went
> > > > > > unnoticed for a while. Basically we cannot look up the request queue
> > > > > > reliably from a request, since it may not have originated from the block
> > > > > > layer. ide-scsi builds it's own, for example. For those, we don't want
> > > > > > to trust the sg count either.
> > > > > >
> > > > > > Does attached patch work?
> > > > >
> > > > > Irk, there's a ide-scsi bug in there too. In
> > > > > drivers/scsi/ide-scsi.c:idescsi_free_bio() change the kfree(bhp) to
> > > > > bio_put(bhp)
> > > > >
> > > >
> > > > With both these fixes applied cdrecord hangs for 30 seconds, then spits
> > > > out "cdrecord: No such device or address. Cannot send SCSI cmd via ioctl",
> > > > a couple of hundred times.
> > > >
> > > > In the from dmesg from the same time I get.
> > > > ------
> > > > hdc: timeout waiting for DMA
> > > > ide_dmaproc: chipset supported ide_dma_timeout func only: 14
> > > > hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest }
> > > > hdc: drive not ready for command
> > > > scsi: device set offline - command error recover failed: host 0 channel 0
> > > > id 0 lun 0
> > > > ------
> > >
> > > Please try a run with DMA disabled.
> > >
> > 
> > Ok works with DMA off, so I expect that this new error is due to my resent
> > memory upgrade (36 Hours ago) and the switch to using HIGHMEM(4GB)..
> > So am I to believe that DMA is a problem with HIGHMEM(4GB) enabled ?
> 
> No it's probably still an ide-scsi bug, I'm not suspecting your
> hardware. The reason I ask is because until -pre8 (since bio merge in
> -pre2), ide-scsi never used DMA even though it was set for the drive.
> 
> -- 
> Jens Axboe

Re: OOPS: 2.5.1-pre8 - cdrecord + ide_scsi

[Jens Axboe]

On Fri, Dec 14 2001, Andre Hedrick wrote:
> 
> Sorry Jens, you are mis-informed.
> SCSI is only the packbuilder, but it is excuted by the ATA PacketCommand.

What on earth are you talking about, this is completely unrelated to
what this message is about. ide-scsi didn't set the right vec count for
the submitted bio, so dma transfers barfed on irq timeout.

-- 
Jens Axboe

Re: OOPS: 2.5.1-pre8 - cdrecord + ide_scsi

[Thomas Hood]

> What on earth are you talking about, this is completely
> unrelated to what this message is about. ide-scsi didn't
> set the right vec count for the submitted bio, so dma
> transfers barfed on irq timeout.

I like the sound of that!    Hmm ...

The vec count is not set by
ide-scsi for submitted bi
o.

So,
on the timing out ir
q the dma transfar
doth barf.