Re: [bug] ata subsystem related crash with latest -git

[Jens Axboe <jens.axboe@oracle.com>]

On Wed, Oct 17 2007, Jens Axboe wrote:
> On Wed, Oct 17 2007, Ingo Molnar wrote:
> > 
> > ok, here's a different but similar crash that triggers on the testbox:
> > 
> > [  233.438890] BUG: unable to handle kernel paging request at virtual address 7d93e000
> > [  233.446390] printing eip: 784e9480 *pde = 01000067 *pte = 0593e000 
> > [  233.452630] Oops: 0000 [#1] DEBUG_PAGEALLOC
> > [  233.456790] 
> > [  233.458264] Pid: 0, comm: swapper Not tainted (2.6.23 #5)
> > [  233.463637] EIP: 0060:[<784e9480>] EFLAGS: 00010087 CPU: 0
> > [  233.469101] EIP is at ata_qc_issue+0x90/0x380
> > [  233.473429] EAX: 7d93dff0 EBX: 0000001f ECX: 7d93dff0 EDX: 798daf80
> > [  233.479668] ESI: 00000020 EDI: 7d93de00 EBP: 7b54007c ESP: 78a13e14
> > [  233.485908]  DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
> > [  233.491282] Process swapper (pid: 0, ti=78a12000 task=789753e0 task.ti=78a12000)
> > [  233.498473] Stack: 7d93de00 7b540000 7b540000 00000000 7d93dfe0 7b54007c 7d93db00 7b5417a4 
> > [  233.506793]        784c2490 784ef69e 784f21f3 7b52de98 7d93db00 7b540000 7b5417a4 7d93db00 
> > [  233.515112]        7b540000 7b524004 784f22e0 784ef380 784c2490 7d93db00 00000202 7b524004 
> > [  233.523432] Call Trace:
> > [  233.526033]  [<784c2490>] scsi_done+0x0/0x20
> > [  233.530279]  [<784ef69e>] ata_scsi_translate+0xbe/0x140
> > [  233.535478]  [<784f21f3>] ata_scsi_queuecmd+0x33/0x200
> > [  233.540591]  [<784f22e0>] ata_scsi_queuecmd+0x120/0x200
> > [  233.545791]  [<784ef380>] ata_scsi_rw_xlat+0x0/0x220
> > [  233.550730]  [<784c2490>] scsi_done+0x0/0x20
> > [  233.554976]  [<784c2d12>] scsi_dispatch_cmd+0x152/0x290
> > [  233.560177]  [<78135c67>] trace_hardirqs_on+0x67/0xb0
> > [  233.565202]  [<784c8c7e>] scsi_request_fn+0x1be/0x370
> > [  233.570229]  [<78408086>] blk_run_queue+0x36/0x80
> > [  233.574909]  [<784c7520>] scsi_next_command+0x30/0x50
> > [  233.579935]  [<784c76ab>] scsi_end_request+0xab/0xe0
> > [  233.584875]  [<784c83f9>] scsi_io_completion+0xa9/0x3d0
> > [  233.590075]  [<78135c67>] trace_hardirqs_on+0x67/0xb0
> > [  233.595100]  [<78405125>] blk_done_softirq+0x45/0x80
> > [  233.600040]  [<78405153>] blk_done_softirq+0x73/0x80
> > [  233.604981]  [<7811d4c3>] __do_softirq+0x53/0xb0
> > [  233.609573]  [<7811d588>] do_softirq+0x68/0x70
> > [  233.613993]  [<78105351>] do_IRQ+0x51/0x90
> > [  233.618066]  [<78135c9c>] trace_hardirqs_on+0x9c/0xb0
> > [  233.623092]  [<7810f2d0>] pgd_dtor+0x0/0x50
> > [  233.627252]  [<7810388e>] common_interrupt+0x2e/0x40
> > [  233.632192]  [<7810f2d0>] pgd_dtor+0x0/0x50
> > [  233.636352]  [<7815f3be>] quicklist_trim+0x5e/0x90
> > [  233.641118]  [<7810f2cb>] check_pgt_cache+0x1b/0x20
> > [  233.645971]  [<78100c52>] cpu_idle+0x32/0x60
> > [  233.650217]  [<78a14b35>] start_kernel+0x265/0x300
> > [  233.654983]  [<78a14380>] unknown_bootoption+0x0/0x1e0
> > [  233.660097]  =======================
> > [  233.663649] Code: 00 00 00 8b 45 34 a8 02 0f 84 ed 00 00 00 8b bd 88 00 00 00 31 db 89 3c 24 8b 75 3c 89 f8 c7 44 24 10 00 00 00 00 eb 1b 8d 76 00 <8b> 50 10 8d 48 10 f6 c2 01 0f 85 be 02 00 00 89 44 24 10 83 c3 
> > [  233.682455] EIP: [<784e9480>] ata_qc_issue+0x90/0x380 SS:ESP 0068:78a13e14
> > [  233.689302] Kernel panic - not syncing: Fatal exception in interrupt
> > 
> > (gdb) list *0x784e9480
> > 0x784e9480 is in ata_qc_issue (include/linux/scatterlist.h:48).
> > 43       */
> > 44      static inline struct scatterlist *sg_next(struct scatterlist *sg)
> > 45      {
> > 46              sg++;
> > 47
> > 48              if (unlikely(sg_is_chain(sg)))
> > 49                      sg = sg_chain_ptr(sg);
> > 50
> > 51              return sg;
> > 52      }
> > (gdb)
> > 
> > so there's sg_next() involvement too. Below is the disassembly.
> 
> You must have a magic test box :-)
> 
> Will investigate... libata doesn't actually enable chaining, but since
> i386 supports it, it ends up using the chain helpers anyway.
> 
> There seems to be some automatic inlining involved here, it must be
> dying inside ata_sg_setup().

OK, something to try out - libata doesn't enable sg chaining, since the
support isn't complete yet. Here's a dumb check just to verify that
scsi_alloc_sgtable() will NEVER return a chain entry for a host that
doesn't have it enabled. If this triggers for you, then that could
explain your problem.

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index aac8a02..cc89c86 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -777,8 +777,12 @@ struct scatterlist *scsi_alloc_sgtable(struct scsi_cmnd *cmd, gfp_t gfp_mask)
 		 * sglist must be the biggest one, or we would not have
 		 * ended up doing another loop.
 		 */
-		if (prev)
+		if (prev) {
+			struct Scsi_Host *shost = cmd->device->host;
+
+			BUG_ON(!shost->use_sg_chaining);
 			sg_chain(prev, SCSI_MAX_SG_SEGMENTS, sgl);
+		}
 
 		/*
 		 * don't allow subsequent mempool allocs to sleep, it would

-- 
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/