From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933751AbXCKPVm (ORCPT ); Sun, 11 Mar 2007 11:21:42 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S933755AbXCKPVl (ORCPT ); Sun, 11 Mar 2007 11:21:41 -0400 Received: from hancock.steeleye.com ([71.30.118.248]:53375 "EHLO hancock.sc.steeleye.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933749AbXCKPVk (ORCPT ); Sun, 11 Mar 2007 11:21:40 -0400 Subject: Re: [PATCH] [scsi]: Add offline state checking while dispatch a scsi cmd From: James Bottomley To: Joe Jin Cc: akpm@osdl.org, dgilbert@interlog.com, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, haobo.zhou@oracle.com In-Reply-To: <20070309014040.GA6632@joejin-pc.cn.oracle.com> References: <20070308092207.GA17141@joejin-pc.cn.oracle.com> <1173369759.3683.1.camel@mulgrave.il.steeleye.com> <20070309014040.GA6632@joejin-pc.cn.oracle.com> Content-Type: text/plain Date: Sun, 11 Mar 2007 10:21:23 -0500 Message-Id: <1173626483.3420.3.camel@mulgrave.il.steeleye.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-1.fc6) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2007-03-09 at 09:40 +0800, Joe Jin wrote: > > What's the error you're trying to fix? scsi_dispatch_cmd() is only > > called from scsi_request_fn() which already has an equivalent of this > > check in it just prior to calling dispatch. > > Yeah, I have saw the cheking at scsi_request_fn(), recently we got a crash > info as following at rhel4 2.6.9-42.0.2.ELsmp, This kernel is way to old to debug ... However: > scsi0 (0:0): rejecting I/O to offline device > ... > EXT3-fs error (device sda8) in start_transaction: Journal has aborted > > Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP: > {:megaraid_mbox:megaraid_queue_command+2634} This is a bug actually in the megaraid. > PML4 21a25d067 PGD 2170ac067 PMD 0 > Oops: 0002 [1] SMP > CPU 0 > Modules linked in: hangcheck_timer mptctl mptbase ipmi_devintf ipmi_si ipmi_msghandler dell_rbu netconsole netdump autofs4 i2c_dev i2c_core ocfs2(U) debugfs(U) nfs lockd nfs_acl ocfs2_dlmfs(U) ocfs2_dlm(U) ocfs2_nodemanager(U) configfs(U) sunrpc ds yenta_socket pcmcia_core ide_dump scsi_dump diskdump zlib_deflate dm_mirror dm_multipath dm_mod emcphr(U) emcpmpap(U) emcpmpaa(U) emcpmpc(U) emcpmp(U) emcp(U) emcplib(U) button battery ac joydev uhci_hcd ehci_hcd hw_random tg3 e1000 bond0(U) floppy sg ext3 jbd lpfc scsi_transport_fc megaraid_mbox megaraid_mm sd_mod scsi_mod > Pid: 13238, comm: emagent Tainted: P 2.6.9-42.0.2.ELsmp > RIP: 0010:[] {:megaraid_mbox:megaraid_queue_command+2634} > RSP: 0018:000001019b5a9b48 EFLAGS: 00010002 > RAX: 0000000220b8e000 RBX: 00000102ffd1b048 RCX: 0000000000000000 > RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000010431124bf0 > RBP: 0000000000000001 R08: 0000000000000000 R09: 0000010133ce5b80 > R10: 00000102ffd3e5a0 R11: 0000000000000060 R12: 0000010133ce5b80 > R13: 00000102ffd3e480 R14: 00000100bfb4c8b8 R15: 00000101ffcf4000 > FS: 0000000000000000(0000) GS:ffffffff804e5180(005b) knlGS:00000000f47ffbb0 > CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b > CR2: 0000000000000000 CR3: 0000000000101000 CR4: 00000000000006e0 > Process emagent (pid: 13238, threadinfo 000001019b5a8000, task 000001003e5a8030) > Stack: 0000000000000000 0000000000000046 0000000000000046 00000102ffd3e480 > 00000101fff73980 ffffffff8015cb38 00000100bfb4d4aa 00000100bfb4d4a2 > 00000100bfb4c8b8 0000010100000080 > Call Trace:{mempool_alloc+129} {:scsi_mod:scsi_done+0} > {__mod_timer+113} {:scsi_mod:scsi_dispatch_cmd+595} > {:scsi_mod:scsi_request_fn+990} {generic_unplug_device+24} > {__wait_on_buffer+120} {bh_wake_function+0} > {bh_wake_function+0} {:ext3:ext3_bread+96} > {:ext3:htree_dirblock_to_tree+50} > {:ext3:ext3_htree_fill_tree+295} > {filldir64+122} {filldir64+0} > {:ext3:ext3_readdir+371} {dput+56} > {filldir64+0} {path_release+12} > {compat_sys_statfs+105} {filldir64+0} > {vfs_readdir+155} {sys_getdents64+118} > {sysenter_do_call+27} And this is a direct command submission path: it already passed both online check gates in this path *after* the device was offlined, so adding a third won't fix this. Firstly, I'm assuming you have only a single disk, so the I/O was definitely bound for sda? Secondly, can you reproduce with a modern (2.6.20) kernel. Your trace strongly suggests that the device came back online for some reason and then the megaraid driver died. James