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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/