BAD_SG_DMA panic in aha1542

BAD_SG_DMA panic in aha1542

[Bob Tracy]

I previously reported an ISA DMA issue for the 2.6.12 kernel.  The issue
persists through at least 2.6.18.  SCSI controller is an Adaptec
AHA-1542B (ISA).

The action "mount -t iso9660 /dev/scd0 /mnt/cdrom -r"

produces

(cdrom detection messages as various modules autoload, then...)
sgpnt[0:1] page c1ee5af0/0x1ee5af0 length 32
Kernel panic - not syncing: Buffer at physical address > 16 Mb used for aha1542

As before, no problems using the sda hard disk (which is the boot drive):
everything works reliably until I touch the cdrom drive.

I'll be happy to assist with the debugging, but the system with the
aha1542 has no development facilities, i.e., I'll have to build test
kernels on a different system, and turnaround is going to be slow :-(.

Thanks in advance for helping me get this old machine working again.
No issues with 2.4 kernels.  I have no idea about 2.5 kernels and
2.6 kernels prior to 2.6.12.  As for why I didn't report this before
now, the aha1542b was in my parts bin until I cobbled a system together
approx. two weeks ago, mostly to see if a useful system could still be
had using legacy hardware and modern GNU/Linux software.  I'm happy to
report the answer is mostly "yes".

-- 
-----------------------------------------------------------------------
Bob Tracy                   WTO + WIPO = DMCA? http://www.anti-dmca.org
rct@frus.com
-----------------------------------------------------------------------

Re: BAD_SG_DMA panic in aha1542

[Alan Cox]

> As before, no problems using the sda hard disk (which is the boot drive):
> everything works reliably until I touch the cdrom drive.

A little quiet contemplation and gnome number 387 suggests trying the following
(and providing more detailed information such as the last message printed before
the DMA message). Stuff a BUG() before the panic in BAD_DMA (aha1542.c) if needed
to get a good trace.

Please report success/failure/change.

--- drivers/scsi/sr_ioctl.c~	2007-04-27 22:53:33.885035256 +0100
+++ drivers/scsi/sr_ioctl.c	2007-04-27 22:53:33.885035256 +0100
@@ -187,9 +187,10 @@
 	struct scsi_sense_hdr sshdr;
 	int result, err = 0, retries = 0;
 	struct request_sense *sense = cgc->sense;
-
+	void *zebedee = cgc->buffer;
+	
 	SDev = cd->device;
-
+	
 	if (!sense) {
 		sense = kmalloc(SCSI_SENSE_BUFFERSIZE, GFP_KERNEL);
 		if (!sense) {
@@ -197,7 +198,22 @@
 			goto out;
 		}
 	}
-
+	
+	if (cgc->buflen && cd->device->host->unchecked_isa_dma) {
+		switch(cgc->data_direction) {
+			case DMA_NONE:
+				break;
+			case DMA_FROM_DEVICE:
+			case DMA_TO_DEVICE: /* Boing!!!! said Zebedee */
+				zebedee = kmalloc(cgc->buflen, GFP_KERNEL|GFP_DMA);
+				if (zebedee ==NULL) {
+					err = -ENOMEM;
+					goto out;
+				}
+		}
+		if (cgc->data_direction == DMA_TO_DEVICE)
+			memcpy(zebedee, cgc->buffer, cgc->buflen);
+	}
       retry:
 	if (!scsi_block_when_processing_errors(SDev)) {
 		err = -ENODEV;
@@ -206,10 +222,13 @@
 
 	memset(sense, 0, sizeof(*sense));
 	result = scsi_execute(SDev, cgc->cmd, cgc->data_direction,
-			      cgc->buffer, cgc->buflen, (char *)sense,
+			      zebedee, cgc->buflen, (char *)sense,
 			      cgc->timeout, IOCTL_RETRIES, 0);
 
 	scsi_normalize_sense((char *)sense, sizeof(*sense), &sshdr);
+	
+	if (zebedeee != cgc->buffer && cgc->data_direction == DMA_FROM_DEVICE)
+		memcpy(cgc->buffer, zebedee, cgc->buflen);
 
 	/* Minimal error checking.  Ignore cases we know about, and report the rest. */
 	if (driver_byte(result) != 0) {

Re: BAD_SG_DMA panic in aha1542

[Bob Tracy]

Alan Cox wrote:
> > As before, no problems using the sda hard disk (which is the boot drive):
> > everything works reliably until I touch the cdrom drive.
> 
> A little quiet contemplation and gnome number 387 suggests trying the following
> (and providing more detailed information such as the last message printed before
> the DMA message). Stuff a BUG() before the panic in BAD_DMA (aha1542.c) if needed
> to get a good trace.
> 
> Please report success/failure/change.

Can do.  I don't have access to the machine on weekends, so it will be
at least Monday before I can give this a whirl.  Thanks!

-- 
-----------------------------------------------------------------------
Bob Tracy                   WTO + WIPO = DMCA? http://www.anti-dmca.org
rct@frus.com
-----------------------------------------------------------------------

Re: BAD_SG_DMA panic in aha1542

[James Bottomley]

On Fri, 2007-04-27 at 16:47 -0500, Bob Tracy wrote:
> I previously reported an ISA DMA issue for the 2.6.12 kernel.  The issue
> persists through at least 2.6.18.  SCSI controller is an Adaptec
> AHA-1542B (ISA).
> 
> The action "mount -t iso9660 /dev/scd0 /mnt/cdrom -r"
> 
> produces
> 
> (cdrom detection messages as various modules autoload, then...)

Knowing what these messages are is would be helpful; it tells me what
point in the initialisation it got to. 

> sgpnt[0:1] page c1ee5af0/0x1ee5af0 length 32
> Kernel panic - not syncing: Buffer at physical address > 16 Mb used for aha1542
> 
> As before, no problems using the sda hard disk (which is the boot drive):
> everything works reliably until I touch the cdrom drive.
> 
> I'll be happy to assist with the debugging, but the system with the
> aha1542 has no development facilities, i.e., I'll have to build test
> kernels on a different system, and turnaround is going to be slow :-(.

I'm interested.

This is clearly a use_sg==1 path that has failed to bounce the buffer
for some reason ... and I was contemplating eliminating the GFP_DMA from
our sr driver because I thought the block bouncing had it covered.

It might also be helpful to apply this patch.  It should give a stack
trace of the problem command and not immediately panic the box.

Thanks,

James

diff --git a/drivers/scsi/aha1542.c b/drivers/scsi/aha1542.c
index 1d239f6..4ee7d99 100644
--- a/drivers/scsi/aha1542.c
+++ b/drivers/scsi/aha1542.c
@@ -75,7 +75,7 @@ static void BAD_SG_DMA(Scsi_Cmnd * SCpnt,
 	/*
 	 * Not safe to continue.
 	 */
-	panic("Buffer at physical address > 16Mb used for aha1542");
+	WARN_ON(1);
 }
 
 #include<linux/stat.h>
@@ -725,8 +725,12 @@ static int aha1542_queuecommand(Scsi_Cmnd * SCpnt, void (*done) (Scsi_Cmnd *))
 				panic("Foooooooood fight!");
 			};
 			any2scsi(cptr[i].dataptr, SCSI_SG_PA(&sgpnt[i]));
-			if (SCSI_SG_PA(&sgpnt[i]) + sgpnt[i].length - 1 > ISA_DMA_THRESHOLD)
+			if (SCSI_SG_PA(&sgpnt[i]) + sgpnt[i].length - 1 > ISA_DMA_THRESHOLD) {
 				BAD_SG_DMA(SCpnt, sgpnt, SCpnt->use_sg, i);
+				SCpnt->result = DID_ERROR << 16;
+				done(SCpnt);
+				return 0;
+			}
 			any2scsi(cptr[i].datalen, sgpnt[i].length);
 		};
 		any2scsi(ccb[mbo].datalen, SCpnt->use_sg * sizeof(struct chain));

Re: BAD_SG_DMA panic in aha1542

[Bob Tracy]

James Bottomley wrote:
> On Fri, 2007-04-27 at 16:47 -0500, Bob Tracy wrote:
> > I previously reported an ISA DMA issue for the 2.6.12 kernel.  The issue
> > persists through at least 2.6.18.  SCSI controller is an Adaptec
> > AHA-1542B (ISA).
> > 
> > The action "mount -t iso9660 /dev/scd0 /mnt/cdrom -r"
> > 
> > produces
> > 
> > (cdrom detection messages as various modules autoload, then...)
> 
> Knowing what these messages are is would be helpful; it tells me what
> point in the initialisation it got to. 

Sorry about that...  I'm running the DSL-N distribution (based on
Knoppix), and having to transcribe the log messages by hand from the
console, i.e., there's no logfile to cut-and-paste from :-(.  I don't
have access to the machine except on weekdays, but I'll repeat the
crash first thing Monday morning and copy everything that's there...

> I'm interested.
> 
> This is clearly a use_sg==1 path that has failed to bounce the buffer
> for some reason ... and I was contemplating eliminating the GFP_DMA from
> our sr driver because I thought the block bouncing had it covered.
> 
> It might also be helpful to apply this patch.  It should give a stack
> trace of the problem command and not immediately panic the box.

I'll throw together a 2.6.21 kernel with this patch and give it a try.
Again, it will be at least Monday before you hear back from me on this.

Thanks!

-- 
-----------------------------------------------------------------------
Bob Tracy                   WTO + WIPO = DMCA? http://www.anti-dmca.org
rct@frus.com
-----------------------------------------------------------------------

Re: BAD_SG_DMA panic in aha1542

[Bob Tracy]

Apologies to all concerned for an unfortunate delay in resolving this.
I chose "unwisely" when I picked a popular experimental distro's
2.6.20 kernel source as a base for my troubleshooting efforts.  The
resulting kernel panics when it tries to load the initial ramdisk, and
I don't have the patience to track down which of the turned-on-by-default
experimental configuration parameters might be causing the problem.

I'll go retrieve a more conservatively-configured source tree (closer to
what DSL-N uses) and start over...

-- 
-----------------------------------------------------------------------
Bob Tracy                   WTO + WIPO = DMCA? http://www.anti-dmca.org
rct@frus.com
-----------------------------------------------------------------------

Re: BAD_SG_DMA panic in aha1542

[Jens Axboe]

On Fri, Apr 27 2007, James Bottomley wrote:
> > sgpnt[0:1] page c1ee5af0/0x1ee5af0 length 32
> > Kernel panic - not syncing: Buffer at physical address > 16 Mb used for aha1542
> > 
> > As before, no problems using the sda hard disk (which is the boot drive):
> > everything works reliably until I touch the cdrom drive.
> > 
> > I'll be happy to assist with the debugging, but the system with the
> > aha1542 has no development facilities, i.e., I'll have to build test
> > kernels on a different system, and turnaround is going to be slow :-(.
> 
> I'm interested.
> 
> This is clearly a use_sg==1 path that has failed to bounce the buffer
> for some reason ... and I was contemplating eliminating the GFP_DMA from
> our sr driver because I thought the block bouncing had it covered.
> 
> It might also be helpful to apply this patch.  It should give a stack
> trace of the problem command and not immediately panic the box.

It's due to the crappy ->generic_packet() ioctl stuff, it bypasses the
block layer. So that needs to be converted to use block pc requests and
the block layer interface, then things will just work.

Christoph had a sort-of ready patch for that some time ago. Christoph,
did that ever materialize into a full blown patch?

-- 
Jens Axboe

Re: BAD_SG_DMA panic in aha1542

[Christoph Hellwig]

On Mon, Apr 30, 2007 at 07:32:45PM +0200, Jens Axboe wrote:
> It's due to the crappy ->generic_packet() ioctl stuff, it bypasses the
> block layer. So that needs to be converted to use block pc requests and
> the block layer interface, then things will just work.
> 
> Christoph had a sort-of ready patch for that some time ago. Christoph,
> did that ever materialize into a full blown patch?

I had a fullblown patch somewhere.  The only drawback was that I didn't
convert pcd because I neither understand enough of the hardware nor do
I really understand what's going on there.

Re: BAD_SG_DMA panic in aha1542

[Jens Axboe]

On Mon, Apr 30 2007, Christoph Hellwig wrote:
> On Mon, Apr 30, 2007 at 07:32:45PM +0200, Jens Axboe wrote:
> > It's due to the crappy ->generic_packet() ioctl stuff, it bypasses the
> > block layer. So that needs to be converted to use block pc requests and
> > the block layer interface, then things will just work.
> > 
> > Christoph had a sort-of ready patch for that some time ago. Christoph,
> > did that ever materialize into a full blown patch?
> 
> I had a fullblown patch somewhere.  The only drawback was that I didn't
> convert pcd because I neither understand enough of the hardware nor do
> I really understand what's going on there.

Cool, pass the patch and I'll try to see if I can convert pcd.

-- 
Jens Axboe

Re: BAD_SG_DMA panic in aha1542

[Bob Tracy]

rct wrote:
> Apologies to all concerned for an unfortunate delay in resolving this.
> (...)
> I'll go retrieve a more conservatively-configured source tree (closer to
> what DSL-N uses) and start over...

Success with the Debian 2.6.18-4-486 build, which is known to work
almost as well on the test platform as the 2.6.12 kernel that DSL-N
comes with.  I used an older compiler than Debian used for their
production build, so I binary-patched the aha1542.ko and sr_mod.ko
files so insmod wouldn't complain about different vermagic strings.

That's as close as it gets without redoing everything from scratch.
I'll give Alan's and James' patches a go within the next 13 hours.

(Alan: what *else* would you name a variable associated with a bounce
buffer besides Zebedee?  Thanks for the occasion to smile...)

-- 
-----------------------------------------------------------------------
Bob Tracy                   WTO + WIPO = DMCA? http://www.anti-dmca.org
rct@frus.com
-----------------------------------------------------------------------

Re: BAD_SG_DMA panic in aha1542

[Jens Axboe]

On Mon, Apr 30 2007, Bob Tracy wrote:
> rct wrote:
> > Apologies to all concerned for an unfortunate delay in resolving this.
> > (...)
> > I'll go retrieve a more conservatively-configured source tree (closer to
> > what DSL-N uses) and start over...
> 
> Success with the Debian 2.6.18-4-486 build, which is known to work
> almost as well on the test platform as the 2.6.12 kernel that DSL-N
> comes with.  I used an older compiler than Debian used for their
> production build, so I binary-patched the aha1542.ko and sr_mod.ko
> files so insmod wouldn't complain about different vermagic strings.
> 
> That's as close as it gets without redoing everything from scratch.
> I'll give Alan's and James' patches a go within the next 13 hours.
> 
> (Alan: what *else* would you name a variable associated with a bounce
> buffer besides Zebedee?  Thanks for the occasion to smile...)

Try Alan's patch, it should fix it. As mentioned earlier in this thread,
the real fix is to get rid of the cgc stuff and inject into the block
layer from cdrom.c. But Alan's patch should work-around the issue for
now.

-- 
Jens Axboe

Re: BAD_SG_DMA panic in aha1542

[Bob Tracy]

Jens Axboe wrote:
> Try Alan's patch, it should fix it. As mentioned earlier in this thread,
> the real fix is to get rid of the cgc stuff and inject into the block
> layer from cdrom.c. But Alan's patch should work-around the issue for
> now.

Trying that patch is the next thing on my plate.  For now, here's the
dmesg output James requested (aha1542 debug patch).  Oddly enough, when
the smoke cleared, the mount succeeded and I could access the cd :-).

Initial state: SCSI cdrom drivers not loaded.
Command: "mount -t iso9660 /dev/scd0 /mnt/cdrom -r"

sr0: scsi3-mmc drive: 16x/16x writer cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 1:0:4:0: Attached scsi CD-ROM sr0
sgpnt[0:1] page c3489af0/0x3489af0 length 32
BUG: warning at drivers/scsi/aha1542.c:78/BAD_SG_DMA()
 [<c4819858>] aha1542_queuecommand+0x4a4/0x4ce [aha1542]
 [<c4833317>] scsi_done+0x0/0x16 [scsi_mod]
 [<c48339f2>] scsi_dispatch_cmd+0x1b0/0x223 [scsi_mod]
 [<c4837abc>] scsi_request_fn+0x22e/0x2ac [scsi_mod]
 [<c01a09d4>] __generic_unplug_device+0x1d/0x1f
 [<c01a0a3a>] blk_execute_rq_nowait+0x64/0x6a
 [<c01a0aae>] blk_execute_rq+0x6e/0x8f
 [<c01a02d0>] blk_end_sync_rq+0x0/0x1d
 [<c01354c9>] mempool_alloc+0x1c/0x97
 [<c014d2fc>] bio_phys_segments+0xe/0x14
 [<c019f456>] blk_rq_bio_prep+0x28/0x7c
 [<c483744f>] scsi_execute+0xc6/0xd9 [scsi_mod]
 [<c4942da2>] sr_do_ioctl+0x80/0x1bd [sr_mod]
 [<c483439d>] scsi_set_medium_removal+0x43/0x67 [scsi_mod]
 [<c494209b>] sr_packet+0x1a/0x1f [sr_mod]
 [<c49aad25>] cdrom_open+0x337/0x8ae [cdrom]
 [<c0275aaf>] wait_for_completion+0x5b/0x84
 [<c0111cba>] default_wake_function+0x0/0xc
 [<c0120312>] call_usermodehelper_keys+0xa6/0xb2
 [<c012031e>] __call_usermodehelper+0x0/0x43
 [<c012049b>] request_module+0xc2/0xd0
 [<c01a9b71>] kobject_get+0xf/0x13
 [<c4942324>] sr_block_open+0x74/0x81 [sr_mod]
 [<c014ec4f>] do_open+0x8a/0x313
 [<c4837b01>] scsi_request_fn+0x273/0x2ac [scsi_mod]
 [<c0275d9f>] io_schedule+0xe/0x16
 [<c0276065>] __wait_on_bit+0x50/0x58
 [<c014ad1a>] sync_buffer+0x0/0x2e
 [<c014ad1a>] sync_buffer+0x0/0x2e
 [<c02760cf>] out_of_line_wait_on_bit+0x62/0x6a
 [<c0122cf0>] wake_bit_function+0x0/0x3c
 [<c014ace5>] __wait_on_buffer+0x1c/0x1f
 [<c48852e1>] __ext3_get_inode_loc+0x263/0x2b1 [ext3]
 [<c015bbd6>] d_splice_alias+0xa9/0xc3
 [<c488b470>] ext3_lookup+0x98/0xb8 [ext3]
 [<c0153018>] do_lookup+0x4f/0x135
 [<c015b1cb>] dput+0x1a/0x10b
 [<c0154e0d>] __link_path_walk+0xa5d/0xba8
 [<c014ef2d>] blkdev_get+0x55/0x60
 [<c014f212>] open_bdev_excl+0x32/0x6e
 [<c014e1f8>] get_sb_bdev+0x14/0x115
 [<c49934c1>] isofs_get_sb+0x12/0x16 [isofs]
 [<c4993987>] isofs_fill_super+0x0/0x899 [isofs]
 [<c014df0a>] vfs_kern_mount+0x88/0xfd
 [<c014dfb2>] do_kern_mount+0x26/0x36
 [<c015eee2>] do_mount+0x589/0x5fb
 [<c015e21c>] mntput_no_expire+0x11/0x59
 [<c015e21c>] mntput_no_expire+0x11/0x59
 [<c0155007>] link_path_walk+0xaf/0xb9
 [<c013c4fc>] __handle_mm_fault+0x341/0x620
 [<c01552c4>] do_path_lookup+0x195/0x1b5
 [<c013c342>] __handle_mm_fault+0x187/0x620
 [<c0136236>] get_page_from_freelist+0x6e/0x2bb
 [<c0136ae6>] __get_free_pages+0x25/0x3e
 [<c015de80>] copy_mount_options+0x27/0x10a
 [<c015efbe>] sys_mount+0x6a/0xa2
 [<c0102a47>] syscall_call+0x7/0xb
sgpnt[0:1] page c3489af0/0x3489af0 length 32
BUG: warning at drivers/scsi/aha1542.c:78/BAD_SG_DMA()
 [<c4819858>] aha1542_queuecommand+0x4a4/0x4ce [aha1542]
 [<c4833317>] scsi_done+0x0/0x16 [scsi_mod]
 [<c48339f2>] scsi_dispatch_cmd+0x1b0/0x223 [scsi_mod]
 [<c4837abc>] scsi_request_fn+0x22e/0x2ac [scsi_mod]
 [<c01a1662>] blk_run_queue+0x2a/0x4b
 [<c483725a>] scsi_queue_insert+0x75/0x7d [scsi_mod]
 [<c01a1598>] blk_done_softirq+0x4a/0x55
 [<c0118563>] __do_softirq+0x35/0x75
 [<c01185c5>] do_softirq+0x22/0x26
 [<c0105074>] do_IRQ+0x48/0x50
 [<c0103a9a>] common_interrupt+0x1a/0x20
 [<c48339f6>] scsi_dispatch_cmd+0x1b4/0x223 [scsi_mod]
 [<c4837abc>] scsi_request_fn+0x22e/0x2ac [scsi_mod]
 [<c01a09d4>] __generic_unplug_device+0x1d/0x1f
 [<c01a0a3a>] blk_execute_rq_nowait+0x64/0x6a
 [<c01a0aae>] blk_execute_rq+0x6e/0x8f
 [<c01a02d0>] blk_end_sync_rq+0x0/0x1d
 [<c01354c9>] mempool_alloc+0x1c/0x97
 [<c014d2fc>] bio_phys_segments+0xe/0x14
 [<c019f456>] blk_rq_bio_prep+0x28/0x7c
 [<c483744f>] scsi_execute+0xc6/0xd9 [scsi_mod]
 [<c4942da2>] sr_do_ioctl+0x80/0x1bd [sr_mod]
 [<c483439d>] scsi_set_medium_removal+0x43/0x67 [scsi_mod]
 [<c494209b>] sr_packet+0x1a/0x1f [sr_mod]
 [<c49aad25>] cdrom_open+0x337/0x8ae [cdrom]
 [<c0275aaf>] wait_for_completion+0x5b/0x84
 [<c0111cba>] default_wake_function+0x0/0xc
 [<c0120312>] call_usermodehelper_keys+0xa6/0xb2
 [<c012031e>] __call_usermodehelper+0x0/0x43
 [<c012049b>] request_module+0xc2/0xd0
 [<c01a9b71>] kobject_get+0xf/0x13
 [<c4942324>] sr_block_open+0x74/0x81 [sr_mod]
 [<c014ec4f>] do_open+0x8a/0x313
 [<c4837b01>] scsi_request_fn+0x273/0x2ac [scsi_mod]
 [<c0275d9f>] io_schedule+0xe/0x16
 [<c0276065>] __wait_on_bit+0x50/0x58
 [<c014ad1a>] sync_buffer+0x0/0x2e
 [<c014ad1a>] sync_buffer+0x0/0x2e
 [<c02760cf>] out_of_line_wait_on_bit+0x62/0x6a
 [<c0122cf0>] wake_bit_function+0x0/0x3c
 [<c014ace5>] __wait_on_buffer+0x1c/0x1f
 [<c48852e1>] __ext3_get_inode_loc+0x263/0x2b1 [ext3]
 [<c015bbd6>] d_splice_alias+0xa9/0xc3
 [<c488b470>] ext3_lookup+0x98/0xb8 [ext3]
 [<c0153018>] do_lookup+0x4f/0x135
 [<c015b1cb>] dput+0x1a/0x10b
 [<c0154e0d>] __link_path_walk+0xa5d/0xba8
 [<c014ef2d>] blkdev_get+0x55/0x60
 [<c014f212>] open_bdev_excl+0x32/0x6e
 [<c014e1f8>] get_sb_bdev+0x14/0x115
 [<c49934c1>] isofs_get_sb+0x12/0x16 [isofs]
 [<c4993987>] isofs_fill_super+0x0/0x899 [isofs]
 [<c014df0a>] vfs_kern_mount+0x88/0xfd
 [<c014dfb2>] do_kern_mount+0x26/0x36
 [<c015eee2>] do_mount+0x589/0x5fb
 [<c015e21c>] mntput_no_expire+0x11/0x59
 [<c015e21c>] mntput_no_expire+0x11/0x59
 [<c0155007>] link_path_walk+0xaf/0xb9
 [<c013c4fc>] __handle_mm_fault+0x341/0x620
 [<c01552c4>] do_path_lookup+0x195/0x1b5
 [<c013c342>] __handle_mm_fault+0x187/0x620
 [<c0136236>] get_page_from_freelist+0x6e/0x2bb
 [<c0136ae6>] __get_free_pages+0x25/0x3e
 [<c015de80>] copy_mount_options+0x27/0x10a
 [<c015efbe>] sys_mount+0x6a/0xa2
 [<c0102a47>] syscall_call+0x7/0xb
sgpnt[0:1] page c3489af0/0x3489af0 length 32
BUG: warning at drivers/scsi/aha1542.c:78/BAD_SG_DMA()
 [<c4819858>] aha1542_queuecommand+0x4a4/0x4ce [aha1542]
 [<c4833317>] scsi_done+0x0/0x16 [scsi_mod]
 [<c48339f2>] scsi_dispatch_cmd+0x1b0/0x223 [scsi_mod]
 [<c4837abc>] scsi_request_fn+0x22e/0x2ac [scsi_mod]
 [<c01a1662>] blk_run_queue+0x2a/0x4b
 [<c483725a>] scsi_queue_insert+0x75/0x7d [scsi_mod]
 [<c01a1598>] blk_done_softirq+0x4a/0x55
 [<c0118563>] __do_softirq+0x35/0x75
 [<c01185c5>] do_softirq+0x22/0x26
 [<c0105074>] do_IRQ+0x48/0x50
 [<c0103a9a>] common_interrupt+0x1a/0x20
 [<c48339f6>] scsi_dispatch_cmd+0x1b4/0x223 [scsi_mod]
 [<c4837abc>] scsi_request_fn+0x22e/0x2ac [scsi_mod]
 [<c01a09d4>] __generic_unplug_device+0x1d/0x1f
 [<c01a0a3a>] blk_execute_rq_nowait+0x64/0x6a
 [<c01a0aae>] blk_execute_rq+0x6e/0x8f
 [<c01a02d0>] blk_end_sync_rq+0x0/0x1d
 [<c01354c9>] mempool_alloc+0x1c/0x97
 [<c014d2fc>] bio_phys_segments+0xe/0x14
 [<c019f456>] blk_rq_bio_prep+0x28/0x7c
 [<c483744f>] scsi_execute+0xc6/0xd9 [scsi_mod]
 [<c4942da2>] sr_do_ioctl+0x80/0x1bd [sr_mod]
 [<c483439d>] scsi_set_medium_removal+0x43/0x67 [scsi_mod]
 [<c494209b>] sr_packet+0x1a/0x1f [sr_mod]
 [<c49aad25>] cdrom_open+0x337/0x8ae [cdrom]
 [<c0275aaf>] wait_for_completion+0x5b/0x84
 [<c0111cba>] default_wake_function+0x0/0xc
 [<c0120312>] call_usermodehelper_keys+0xa6/0xb2
 [<c012031e>] __call_usermodehelper+0x0/0x43
 [<c012049b>] request_module+0xc2/0xd0
 [<c01a9b71>] kobject_get+0xf/0x13
 [<c4942324>] sr_block_open+0x74/0x81 [sr_mod]
 [<c014ec4f>] do_open+0x8a/0x313
 [<c4837b01>] scsi_request_fn+0x273/0x2ac [scsi_mod]
 [<c0275d9f>] io_schedule+0xe/0x16
 [<c0276065>] __wait_on_bit+0x50/0x58
 [<c014ad1a>] sync_buffer+0x0/0x2e
 [<c014ad1a>] sync_buffer+0x0/0x2e
 [<c02760cf>] out_of_line_wait_on_bit+0x62/0x6a
 [<c0122cf0>] wake_bit_function+0x0/0x3c
 [<c014ace5>] __wait_on_buffer+0x1c/0x1f
 [<c48852e1>] __ext3_get_inode_loc+0x263/0x2b1 [ext3]
 [<c015bbd6>] d_splice_alias+0xa9/0xc3
 [<c488b470>] ext3_lookup+0x98/0xb8 [ext3]
 [<c0153018>] do_lookup+0x4f/0x135
 [<c015b1cb>] dput+0x1a/0x10b
 [<c0154e0d>] __link_path_walk+0xa5d/0xba8
 [<c014ef2d>] blkdev_get+0x55/0x60
 [<c014f212>] open_bdev_excl+0x32/0x6e
 [<c014e1f8>] get_sb_bdev+0x14/0x115
 [<c49934c1>] isofs_get_sb+0x12/0x16 [isofs]
 [<c4993987>] isofs_fill_super+0x0/0x899 [isofs]
 [<c014df0a>] vfs_kern_mount+0x88/0xfd
 [<c014dfb2>] do_kern_mount+0x26/0x36
 [<c015eee2>] do_mount+0x589/0x5fb
 [<c015e21c>] mntput_no_expire+0x11/0x59
 [<c015e21c>] mntput_no_expire+0x11/0x59
 [<c0155007>] link_path_walk+0xaf/0xb9
 [<c013c4fc>] __handle_mm_fault+0x341/0x620
 [<c01552c4>] do_path_lookup+0x195/0x1b5
 [<c013c342>] __handle_mm_fault+0x187/0x620
 [<c0136236>] get_page_from_freelist+0x6e/0x2bb
 [<c0136ae6>] __get_free_pages+0x25/0x3e
 [<c015de80>] copy_mount_options+0x27/0x10a
 [<c015efbe>] sys_mount+0x6a/0xa2
 [<c0102a47>] syscall_call+0x7/0xb
sgpnt[0:1] page c3489af0/0x3489af0 length 32
BUG: warning at drivers/scsi/aha1542.c:78/BAD_SG_DMA()
 [<c4819858>] aha1542_queuecommand+0x4a4/0x4ce [aha1542]
 [<c4833317>] scsi_done+0x0/0x16 [scsi_mod]
 [<c48339f2>] scsi_dispatch_cmd+0x1b0/0x223 [scsi_mod]
 [<c4837abc>] scsi_request_fn+0x22e/0x2ac [scsi_mod]
 [<c01a1662>] blk_run_queue+0x2a/0x4b
 [<c483725a>] scsi_queue_insert+0x75/0x7d [scsi_mod]
 [<c01a1598>] blk_done_softirq+0x4a/0x55
 [<c0118563>] __do_softirq+0x35/0x75
 [<c01185c5>] do_softirq+0x22/0x26
 [<c0105074>] do_IRQ+0x48/0x50
 [<c0103a9a>] common_interrupt+0x1a/0x20
 [<c48339f6>] scsi_dispatch_cmd+0x1b4/0x223 [scsi_mod]
 [<c4837abc>] scsi_request_fn+0x22e/0x2ac [scsi_mod]
 [<c01a09d4>] __generic_unplug_device+0x1d/0x1f
 [<c01a0a3a>] blk_execute_rq_nowait+0x64/0x6a
 [<c01a0aae>] blk_execute_rq+0x6e/0x8f
 [<c01a02d0>] blk_end_sync_rq+0x0/0x1d
 [<c01354c9>] mempool_alloc+0x1c/0x97
 [<c014d2fc>] bio_phys_segments+0xe/0x14
 [<c019f456>] blk_rq_bio_prep+0x28/0x7c
 [<c483744f>] scsi_execute+0xc6/0xd9 [scsi_mod]
 [<c4942da2>] sr_do_ioctl+0x80/0x1bd [sr_mod]
 [<c483439d>] scsi_set_medium_removal+0x43/0x67 [scsi_mod]
 [<c494209b>] sr_packet+0x1a/0x1f [sr_mod]
 [<c49aad25>] cdrom_open+0x337/0x8ae [cdrom]
 [<c0275aaf>] wait_for_completion+0x5b/0x84
 [<c0111cba>] default_wake_function+0x0/0xc
 [<c0120312>] call_usermodehelper_keys+0xa6/0xb2
 [<c012031e>] __call_usermodehelper+0x0/0x43
 [<c012049b>] request_module+0xc2/0xd0
 [<c01a9b71>] kobject_get+0xf/0x13
 [<c4942324>] sr_block_open+0x74/0x81 [sr_mod]
 [<c014ec4f>] do_open+0x8a/0x313
 [<c4837b01>] scsi_request_fn+0x273/0x2ac [scsi_mod]
 [<c0275d9f>] io_schedule+0xe/0x16
 [<c0276065>] __wait_on_bit+0x50/0x58
 [<c014ad1a>] sync_buffer+0x0/0x2e
 [<c014ad1a>] sync_buffer+0x0/0x2e
 [<c02760cf>] out_of_line_wait_on_bit+0x62/0x6a
 [<c0122cf0>] wake_bit_function+0x0/0x3c
 [<c014ace5>] __wait_on_buffer+0x1c/0x1f
 [<c48852e1>] __ext3_get_inode_loc+0x263/0x2b1 [ext3]
 [<c015bbd6>] d_splice_alias+0xa9/0xc3
 [<c488b470>] ext3_lookup+0x98/0xb8 [ext3]
 [<c0153018>] do_lookup+0x4f/0x135
 [<c015b1cb>] dput+0x1a/0x10b
 [<c0154e0d>] __link_path_walk+0xa5d/0xba8
 [<c014ef2d>] blkdev_get+0x55/0x60
 [<c014f212>] open_bdev_excl+0x32/0x6e
 [<c014e1f8>] get_sb_bdev+0x14/0x115
 [<c49934c1>] isofs_get_sb+0x12/0x16 [isofs]
 [<c4993987>] isofs_fill_super+0x0/0x899 [isofs]
 [<c014df0a>] vfs_kern_mount+0x88/0xfd
 [<c014dfb2>] do_kern_mount+0x26/0x36
 [<c015eee2>] do_mount+0x589/0x5fb
 [<c015e21c>] mntput_no_expire+0x11/0x59
 [<c015e21c>] mntput_no_expire+0x11/0x59
 [<c0155007>] link_path_walk+0xaf/0xb9
 [<c013c4fc>] __handle_mm_fault+0x341/0x620
 [<c01552c4>] do_path_lookup+0x195/0x1b5
 [<c013c342>] __handle_mm_fault+0x187/0x620
 [<c0136236>] get_page_from_freelist+0x6e/0x2bb
 [<c0136ae6>] __get_free_pages+0x25/0x3e
 [<c015de80>] copy_mount_options+0x27/0x10a
 [<c015efbe>] sys_mount+0x6a/0xa2
 [<c0102a47>] syscall_call+0x7/0xb
ISO 9660 Extensions: Microsoft Joliet Level 1
ISOFS: changing to secondary root

-- 
-----------------------------------------------------------------------
Bob Tracy                   WTO + WIPO = DMCA? http://www.anti-dmca.org
rct@frus.com
-----------------------------------------------------------------------

Re: BAD_SG_DMA panic in aha1542

[Alan Cox]

> That's as close as it gets without redoing everything from scratch.
> I'll give Alan's and James' patches a go within the next 13 hours.
> 
> (Alan: what *else* would you name a variable associated with a bounce
> buffer besides Zebedee?  Thanks for the occasion to smile...)

The one I sent has a memory leak but it won't matter for basic testing.
Or you can change the final bit to


        scsi_normalize_sense((char *)sense, sizeof(*sense), &sshdr);
        
        if (zebedee != cgc->buffer) {
                if (cgc->data_direction == DMA_FROM_DEVICE)    
                        memcpy(cgc->buffer, zebedee, cgc->buflen);
                kfree(zebedee); /* Time for bed */        
        }

Alan
--

`I can hear you.` ,said Florence. `It s not true. Noddy and I are just
good friends.`

Re: BAD_SG_DMA panic in aha1542

[Bob Tracy]

Alan Cox wrote:
> The one I sent has a memory leak but it won't matter for basic testing.
> Or you can change the final bit to
> 
> 
>         scsi_normalize_sense((char *)sense, sizeof(*sense), &sshdr);
>         
>         if (zebedee != cgc->buffer) {
>                 if (cgc->data_direction == DMA_FROM_DEVICE)    
>                         memcpy(cgc->buffer, zebedee, cgc->buflen);
>                 kfree(zebedee); /* Time for bed */        
>         }

I changed it, because I'll be living with this for a while I'd bet...

Works fine.  No more BAD_SG_DMA() calls.  Thanks!

-- 
-----------------------------------------------------------------------
Bob Tracy                   WTO + WIPO = DMCA? http://www.anti-dmca.org
rct@frus.com
-----------------------------------------------------------------------