From: Aboo Valappil <aboo@aboo.org>
To: dougg@torque.net
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>, linux-scsi@vger.kernel.org
Subject: Re: Linux Virtual SCSI HBAs and Virtual disks
Date: Sun, 21 Jan 2007 20:48:03 +1100 [thread overview]
Message-ID: <45B336D3.5010106@aboo.org> (raw)
In-Reply-To: <45AEA118.5030608@torque.net>
Hi Doug Gilbert,
sorry for the late reply. I am in the process of implementing sense code
and I will make it available.
I tried the sdparms and it failed not due to lack of sense code and
status. What happened was that the user space SCSI target died due to a
unsupported SCSI command (bug in user space target). When it crashed,
the SCSI disk served by that user space target was opened by sdparms.
The driver removed the scsi_host which was attached to user space
target, thinking that the last registered user space part died. I think
those stack traces are due to the EH thread trying perform some sort of
recovery on SCSI command, but the scsi host has been removed!
To prevent this, I implemented some checks. When the last user space
application attached to the scsi_host, the driver will check to make
sure that there is no open SCSI devices on that scsi_host. If there is
some devices open, it will not remove the scsi_host. This kind of
approach should be ok because my design supports re-attaching a new user
space target with an existing scsi_host. The design also allows to start
multiple user space target to serve one scsi_host in the kernel and
there is no issue at all even if one dies. Whoever gets the SCSI command
will serve it and sleep if nothing available.
Thanks
Aboo
Douglas Gilbert wrote:
> Aboo Valappil wrote:
>
>> Hi All,
>>
>> Thanks everyone to have a look at this.
>>
>> I think i modified to have the latest kernel support. Unfortunately I
>> could not test it with 2.6.20 kernel due to some issues in my laptop and
>> 2.6.20 kernel. But it should work with 2.6.20 with this modification.
>>
>> The modified version is available through
>> http://vscsihba.aboo.org/vscsihbav202.tgz.
>>
>> 1. I fixed the kmem_cache issue for sure.
>> 2. I think i got around with INIT_WORK ... Made the following
>> modifications ...
>>
>
> Perhaps you could get some of my scsi tools (e.g.
> sdparm and sg3_utils) and make sure that vscsihba
> can handle everything they can throw at it.
> If the user space doesn't support a SCSI command then
> your driver should fail gracefully (i.e. CHECK CONDITION,
> etc).
>
> Here is a worrying example: sdparm sends an INQUIRY
> and a couple of MODE SENSE(10) commands to a device.
> /dev/sda was created by your script:
> $ ./start_target.sh id=3 -files zz_lun0
>
> $ sdparm /dev/sda
> /dev/sda: VirtualH VHD 0
> <long wait>
> $
>
>
> However dmesg showed this:
>
> vscsihba:3: In Reset Device
> vscsihba:3: In Reset Device
> vscsihba:3: In Reset Device
> vscsihba:3: In Reset Device
> vscsihba:3: In Reset Device
> vscsihba:3: In Reset Device
> sd 0:0:0:0: SCSI error: return code = 0x00000002
> end_request: I/O error, dev sda, sector 10240
> Buffer I/O error on device sda, logical block 10240
> vscsihba:3: In Reset Device
> vscsihba:3: In Reset Device
> vscsihba:3: In Reset Device
> vscsihba:3: In Reset Device
> vscsihba:3: In Reset Device
> vscsihba:3: In Reset Device
> sd 0:0:0:0: SCSI error: return code = 0x00000002
> end_request: I/O error, dev sda, sector 10240
> Buffer I/O error on device sda, logical block 10240
> vscsihba:3: In Reset Device
> vscsihba:3: In Reset Device
> vscsihba:3: In Reset Device
> vscsihba:3: In Reset Device
> vscsihba:3: In Reset Device
> vscsihba:3: In Reset Device
> sd 0:0:0:0: SCSI error: return code = 0x00000002
> end_request: I/O error, dev sda, sector 10240
> Buffer I/O error on device sda, logical block 10240
> vscsihba:3: In Reset Device
> vscsihba:3: In Reset Device
> vscsihba:3: In Reset Device
> vscsihba:3: In Reset Device
> vscsihba:3: In Reset Device
> vscsihba:3: In Reset Device
> sd 0:0:0:0: SCSI error: return code = 0x00000002
> end_request: I/O error, dev sda, sector 10240
> Buffer I/O error on device sda, logical block 10240
> vscsihba:3: In Reset Device
> vscsihba:3: In Reset Device
> vscsihba:3: In Reset Device
> vscsihba:3: In Reset Device
> vscsihba:3: In Reset Device
> vscsihba:3: In Reset Device
> sd 0:0:0:0: SCSI error: return code = 0x00000002
> end_request: I/O error, dev sda, sector 10240
> Buffer I/O error on device sda, logical block 10240
> vscsihba:3: In Reset Device
> vscsihba:3: In Reset Device
> vscsihba:3: In Reset Device
> vscsihba:3: In Reset Device
> vscsihba:3: In Reset Device
> vscsihba:3: In Reset Device
> sd 0:0:0:0: SCSI error: return code = 0x00000002
> end_request: I/O error, dev sda, sector 10240
> Buffer I/O error on device sda, logical block 10240
> BUG: at kernel/sched.c:3388 sub_preempt_count()
> [<e1bf029c>] scsitap_eh_abort+0x1c/0x90 [vscsihba]
> [<c024fe22>] scsi_error_handler+0x3e2/0xbe0
> [<c02d74f1>] __sched_text_start+0x2f1/0x660
> [<c024fa40>] scsi_error_handler+0x0/0xbe0
> [<c0131679>] kthread+0xa9/0xe0
> [<c01315d0>] kthread+0x0/0xe0
> [<c0103d0f>] kernel_thread_helper+0x7/0x18
> =======================
> vscsihba:3: Abortng command serial number : 94
> BUG: scheduling while atomic: scsi_eh_0/0x00000001/4749
> [<c02d7684>] __sched_text_start+0x484/0x660
> [<c013183b>] autoremove_wake_function+0x1b/0x50
> [<c01264a8>] lock_timer_base+0x28/0x70
> [<c01265f2>] __mod_timer+0x92/0xd0
> [<c02d826b>] schedule_timeout+0x4b/0xd0
> [<c01269c0>] process_timeout+0x0/0x10
> [<c02d7bbc>] wait_for_completion_timeout+0x9c/0x130
> [<c0119ee0>] default_wake_function+0x0/0x10
> [<c024f3c9>] scsi_send_eh_cmnd+0x1b9/0x390
> [<c011df3e>] vprintk+0x1fe/0x3a0
> [<c024f805>] scsi_delete_timer+0x15/0x60
> [<c024f624>] scsi_eh_tur+0x34/0xa0
> [<c024fe69>] scsi_error_handler+0x429/0xbe0
> [<c02d74f1>] __sched_text_start+0x2f1/0x660
> [<c024fa40>] scsi_error_handler+0x0/0xbe0
> [<c0131679>] kthread+0xa9/0xe0
> [<c01315d0>] kthread+0x0/0xe0
> [<c0103d0f>] kernel_thread_helper+0x7/0x18
> =======================
> vscsihba:3: Abortng command serial number : 95
> vscsihba:3: In Reset Device
> BUG: scheduling while atomic: scsi_eh_0/0x00000001/4749
> [<c02d7684>] __sched_text_start+0x484/0x660
> [<c011df3e>] vprintk+0x1fe/0x3a0
> [<c01264a8>] lock_timer_base+0x28/0x70
> [<c01265f2>] __mod_timer+0x92/0xd0
> [<c02d826b>] schedule_timeout+0x4b/0xd0
> [<c01269c0>] process_timeout+0x0/0x10
> [<c02d7bbc>] wait_for_completion_timeout+0x9c/0x130
> [<c0119ee0>] default_wake_function+0x0/0x10
> [<c024f3c9>] scsi_send_eh_cmnd+0x1b9/0x390
> [<c024f805>] scsi_delete_timer+0x15/0x60
> [<c024f624>] scsi_eh_tur+0x34/0xa0
> [<e1bf00cd>] scsitap_eh_device_reset+0x1d/0x30 [vscsihba]
> [<c02503a8>] scsi_error_handler+0x968/0xbe0
> [<c02d74f1>] __sched_text_start+0x2f1/0x660
> [<c024fa40>] scsi_error_handler+0x0/0xbe0
> [<c0131679>] kthread+0xa9/0xe0
> [<c01315d0>] kthread+0x0/0xe0
> [<c0103d0f>] kernel_thread_helper+0x7/0x18
> =======================
> vscsihba:3: Abortng command serial number : 96
> vscsihba:3: In Reset Host
> BUG: scheduling while atomic: scsi_eh_0/0x00000001/4749
> [<c02d7684>] __sched_text_start+0x484/0x660
> [<c01264a8>] lock_timer_base+0x28/0x70
> [<c01265f2>] __mod_timer+0x92/0xd0
> [<c02d826b>] schedule_timeout+0x4b/0xd0
> [<c01269c0>] process_timeout+0x0/0x10
> [<c01273d5>] msleep+0x25/0x30
> [<c024efb1>] scsi_try_host_reset+0xa1/0xd0
> [<c0250150>] scsi_error_handler+0x710/0xbe0
> [<c02d74f1>] __sched_text_start+0x2f1/0x660
> [<c024fa40>] scsi_error_handler+0x0/0xbe0
> [<c0131679>] kthread+0xa9/0xe0
> [<c01315d0>] kthread+0x0/0xe0
> [<c0103d0f>] kernel_thread_helper+0x7/0x18
> =======================
> BUG: scheduling while atomic: scsi_eh_0/0x00000001/4749
> [<c02d7684>] __sched_text_start+0x484/0x660
> [<c01264a8>] lock_timer_base+0x28/0x70
> [<c01265f2>] __mod_timer+0x92/0xd0
> [<c02d826b>] schedule_timeout+0x4b/0xd0
> [<c01269c0>] process_timeout+0x0/0x10
> [<c02d7bbc>] wait_for_completion_timeout+0x9c/0x130
> [<c0119ee0>] default_wake_function+0x0/0x10
> [<c024f3c9>] scsi_send_eh_cmnd+0x1b9/0x390
> [<c02d74f1>] __sched_text_start+0x2f1/0x660
> [<c01265f2>] __mod_timer+0x92/0xd0
> [<c02d8272>] schedule_timeout+0x52/0xd0
> [<c024f624>] scsi_eh_tur+0x34/0xa0
> [<c02501a0>] scsi_error_handler+0x760/0xbe0
> [<c02d74f1>] __sched_text_start+0x2f1/0x660
> [<c024fa40>] scsi_error_handler+0x0/0xbe0
> [<c0131679>] kthread+0xa9/0xe0
> [<c01315d0>] kthread+0x0/0xe0
> [<c0103d0f>] kernel_thread_helper+0x7/0x18
> =======================
> vscsihba:3: Abortng command serial number : 97
> sd 0:0:0:0: scsi: Device offlined - not ready after error recovery
> BUG: scheduling while atomic: scsi_eh_0/0x00000001/4749
> [<c02d7684>] __sched_text_start+0x484/0x660
> [<c013aa11>] module_put+0x31/0x60
> [<c024bd6e>] scsi_device_put+0x3e/0x40
> [<c024be5f>] __scsi_iterate_devices+0x6f/0x90
> [<c024fa86>] scsi_error_handler+0x46/0xbe0
> [<c024fa40>] scsi_error_handler+0x0/0xbe0
> [<c0131679>] kthread+0xa9/0xe0
> [<c01315d0>] kthread+0x0/0xe0
> [<c0103d0f>] kernel_thread_helper+0x7/0x18
> =======================
>
>
> Doug Gilbert
>
next prev parent reply other threads:[~2007-01-21 9:48 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-16 10:22 Linux Virtual SCSI HBAs and Virtual disks Aboo Valappil
2007-01-16 21:52 ` Erik Mouw
2007-01-16 23:01 ` aboo
2007-01-17 1:50 ` Douglas Gilbert
2007-01-17 8:36 ` Stefan Richter
2007-01-17 10:24 ` Aboo Valappil
2007-01-17 22:20 ` Douglas Gilbert
2007-01-17 21:59 ` aboo
2007-01-18 0:38 ` Stefan Richter
2007-01-21 9:48 ` Aboo Valappil [this message]
2007-01-21 9:53 ` Aboo Valappil
2007-01-21 11:24 ` Stefan Richter
2007-01-22 0:43 ` aboo
2007-01-22 2:23 ` aboo
2007-01-22 16:47 ` Stefan Richter
2007-01-22 16:58 ` Stefan Richter
2007-01-22 18:07 ` James Bottomley
2007-01-23 13:11 ` Aboo Valappil
2007-01-23 16:36 ` Randy Dunlap
2007-01-23 17:22 ` Stefan Richter
2007-01-24 9:47 ` Aboo Valappil
2007-01-25 22:02 ` Aboo Valappil
2007-01-23 17:16 ` Stefan Richter
2007-01-23 22:12 ` Aboo Valappil
2007-01-24 0:09 ` Stefan Richter
2007-01-24 3:24 ` Douglas Gilbert
2007-01-24 9:40 ` Aboo Valappil
2007-01-25 21:41 ` Aboo Valappil
2007-01-25 22:01 ` Stefan Richter
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=45B336D3.5010106@aboo.org \
--to=aboo@aboo.org \
--cc=dougg@torque.net \
--cc=linux-scsi@vger.kernel.org \
--cc=stefanr@s5r6.in-berlin.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox