From: Willem Riede <wrlk@riede.org>
To: linux-scsi@vger.kernel.org
Subject: Badness in scsi_single_lun_run at /root/scsi/scsi_lib.c:344
Date: Mon, 26 Jan 2004 19:32:44 -0500 [thread overview]
Message-ID: <20040127003244.GM23308@serve.riede.org> (raw)
For additional fun shaking bugs out of ide-scsi, I dusted of my old
PD/CD drive (retired years ago in favor of a CD Writer).
Besides having to set host->max_lun = 2; in idescsi_attach() to
have both luns of this device detected:
Jan 26 17:13:23 fallguy kernel: scsi6 : SCSI host adapter emulation for IDE ATAPI devices
Jan 26 17:13:23 fallguy kernel: Vendor: NEC Model: PD-1 ODX654P Rev: A111
Jan 26 17:13:23 fallguy kernel: Type: CD-ROM ANSI SCSI revision: 02
Jan 26 17:13:23 fallguy kernel: sr1: scsi3-mmc drive: 6x/6x xa/form2 cdda tray
Jan 26 17:13:23 fallguy kernel: Vendor: NEC Model: PD-1 ODX654P Rev: A111
Jan 26 17:13:23 fallguy kernel: Type: Optical Device ANSI SCSI revision: 02
Jan 26 17:13:23 fallguy kernel: SCSI device sdc: 1298496 512-byte hdwr sectors (665 MB)
Jan 26 17:13:23 fallguy kernel: sdc: Write Protect is off
Jan 26 17:13:23 fallguy kernel: SCSI device sdc: drive cache: write back
I get a bunch of the following warning:
Jan 26 17:13:23 fallguy kernel: Badness in scsi_single_lun_run at /root/scsi/scsi_lib.c:344
Jan 26 17:13:23 fallguy kernel: Call Trace:
Jan 26 17:13:23 fallguy kernel: [<e0850192>] scsi_single_lun_run+0x202/0x230 [scsi_mod]
Jan 26 17:13:23 fallguy kernel: [<e084a33d>] scsi_put_command+0xbd/0x160 [scsi_mod]
Jan 26 17:13:23 fallguy kernel: [<e0850347>] scsi_run_queue+0x187/0x190 [scsi_mod]
Jan 26 17:13:23 fallguy kernel: [<e0850524>] scsi_end_request+0xf4/0x150 [scsi_mod]
Jan 26 17:13:23 fallguy kernel: [<e08508f7>] scsi_io_completion+0x1c7/0x4b0 [scsi_mod]
Jan 26 17:13:23 fallguy kernel: [<e0829a32>] sd_rw_intr+0x82/0x260 [sd_mod]
Jan 26 17:13:24 fallguy kernel: [<e084aed1>] scsi_finish_command+0x81/0xe0 [scsi_mod]
Jan 26 17:13:24 fallguy kernel: [<e084ade8>] scsi_softirq+0xc8/0xf0 [scsi_mod]
Jan 26 17:13:24 fallguy kernel: [<c012d6a7>] do_softirq+0xc7/0xd0
Jan 26 17:13:24 fallguy kernel: [<c010e395>] do_IRQ+0x165/0x220
Jan 26 17:13:24 fallguy kernel: [<c011c04d>] smp_apic_timer_interrupt+0xdd/0x150
Jan 26 17:13:24 fallguy kernel: [<c010c21c>] common_interrupt+0x18/0x20
Jan 26 17:13:24 fallguy kernel: [<c01089f0>] default_idle+0x0/0x40
Jan 26 17:13:24 fallguy kernel: [<c0108a19>] default_idle+0x29/0x40
Jan 26 17:13:24 fallguy kernel: [<c0108aab>] cpu_idle+0x3b/0x50
Jan 26 17:13:24 fallguy kernel: [<c0128f80>] printk+0x180/0x260
Jan 26 17:13:24 fallguy kernel:
Most are similar from do_IRQ up, io_completion called from sd_rw_intr or (sr) rw_intr,
which make its way to scsi_single_lun_run. (I don't understand why scsi_put_command
shows up, I believe it should be scsi_end_request -> scsi_next_request -> scsi_run_queue
-> scsi_single_lun_run.
One is different, don't know if that's a fluke (kernel log buffer overrun?) or evidence
of a rogue path...
Jan 26 17:14:12 fallguy kernel: Badness in scsi_single_lun_run at /root/scsi/scsi_lib.c:344
Jan 26 17:14:12 fallguy kernel: Call Trace:
Jan 26 17:14:12 fallguy kernel: [<e0850192>] scsi_single_lun_run+0x202/0x230 [scsi_mod]
Jan 26 17:14:12 fallguy kernel: [<e084a33d>] scsi_put_command+0xbd/0x160 [scsi_mod]
Jan 26 17:14:12 fallguy kernel: [<e0850347>] scsi_run_queue+0x187/0x190 [scsi_mod]
Jan 26 17:14:12 fallguy kernel: [<e084fd01>] scsi_wait_req+0xa1/0xb0 [scsi_mod]
Jan 26 17:14:12 fallguy kernel: [<e084fb90>] scsi_wait_done+0x0/0xd0 [scsi_mod]
Jan 26 17:14:12 fallguy kernel: [<e084a02e>] scsi_allocate_request+0x2e/0x70 [scsi_mod]
Jan 26 17:14:12 fallguy kernel: [<e084bf7d>] ioctl_internal_command+0x6d/0x200 [scsi_mod]
Jan 26 17:14:12 fallguy kernel: [<e084c17f>] scsi_set_medium_removal+0x6f/0xa0 [scsi_mod]
Jan 26 17:14:12 fallguy kernel: [<e0829602>] sd_release+0x72/0x90 [sd_mod]
Jan 26 17:14:12 fallguy kernel: [<c0176b54>] blkdev_put+0x214/0x260
Jan 26 17:14:12 fallguy kernel: [<c016d60a>] __fput+0x10a/0x120
Jan 26 17:14:12 fallguy kernel: [<c016b7a9>] filp_close+0x59/0x90
Jan 26 17:14:13 fallguy kernel: [<c016b85f>] sys_close+0x7f/0x100
Jan 26 17:14:13 fallguy kernel: [<c010b8af>] syscall_call+0x7/0xb
Jan 26 17:14:13 fallguy kernel:
Somehow it appears that io completion sometimes happens twice without
current_sdev->sdev_target->starget_sdev_user being set to a new owner so
that the WARN_ON(!current_sdev->sdev_target->starget_sdev_user) triggers...
(I have proven to my satisfaction that no path exists that can set
current_sdev->sdev_target->starget_sdev_user to NULL to cause this).
Setting starget_sdev_user happens in scsi_request_fn(). Do any paths exist
that start io that don't use it?
Probably to simple minded to suspect the request sense following a command that
reports "Check Condition"?
Ideas of where to look next appreciated.
Thanks, Willem Riede.
next reply other threads:[~2004-01-27 0:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-27 0:32 Willem Riede [this message]
2004-01-28 3:30 ` Badness in scsi_single_lun_run at /root/scsi/scsi_lib.c:344 Willem Riede
2004-01-28 16:41 ` Patrick Mansfield
2004-01-28 17:36 ` Willem Riede
2004-01-28 17:53 ` Patrick Mansfield
2004-01-28 18:33 ` Willem Riede
2004-01-28 18:37 ` Matthew Wilcox
2004-01-30 20:14 ` [PATCH] fix badness in scsi_single_lun_run Patrick Mansfield
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040127003244.GM23308@serve.riede.org \
--to=wrlk@riede.org \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.