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
[email protected]
--------------------
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>
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
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
> 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
[email protected]
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
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
[email protected]
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
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
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
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
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
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
> 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.