lkml.org 
[lkml]   [2007]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: [bug] ata subsystem related crash with latest -git
    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/

    \
     
     \ /
      Last update: 2007-10-17 20:39    [W:0.025 / U:30.672 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site