From: Ben Collins <bcollins@debian.org>
To: Torrey Hoffman <thoffman@arnor.net>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
linux firewire devel <linux1394-devel@lists.sourceforge.net>
Subject: Re: [OOPS] 2.5.70-bk15: sbp2: oops on unplug, replug
Date: Thu, 12 Jun 2003 15:50:18 -0400 [thread overview]
Message-ID: <20030612195018.GU4695@phunnypharm.org> (raw)
I'm not absolutely sure who is reponsible for what when a drive is left
mounted and you disconnect it. As far as I know, the sbp2 layer tells
the scsi layer to remove the device, so I'm of the opinion that sbp2 did
what it is supposed to, and the scsi layer needs to handle this better
down to the VFS.
I'd need to understand a bit better about why it oopses when plugged
back in. So far I have not had any problems with connecting and
disconnecting drives. I'll have to do some testing.
> Unable to handle kernel NULL pointer dereference at virtual address 0000004c
> printing eip:
> e88caaae
> *pde = 00000000
> Oops: 0000 [#1]
> CPU: 0
> EIP: 0060:[<e88caaae>] Not tainted
> EFLAGS: 00010286
> EIP is at scsi_device_get+0xe/0x40 [scsi_mod]
> eax: 00000000 ebx: c1740900 ecx: 00000001 edx: e68f2b60
> esi: e68f2b60 edi: e6dd54e0 ebp: e68a5a20 esp: e68a5a20
> ds: 007b es: 007b ss: 0068
> Process knodemgrd_0 (pid: 350, threadinfo=e68a4000 task=e75f00c0)
> Stack: e68a5a3c e88b3319 e68f2b60 c02117a2 c1740900 e88b32f0 e88b5c60 e68a5a7c
> c0151fba e51f9ba0 e68a5b30 e66cdf18 c0118bcc e68a5a7c 00000046 e7fedc30
> 00000001 c1740918 c0118d9a 00000000 c1740900 00000001 e68a5b30 e68a5bb8
> Call Trace:
Maybe I'm just not used to reading these new dumps, but where does the
oops actually occur in the list below? I'm used to seeing ksymoops's
"<---" marker.
> [<e88b3319>] sd_open+0x29/0xf0 [sd_mod]
> [<c02117a2>] get_gendisk+0x22/0x40
> [<e88b32f0>] sd_open+0x0/0xf0 [sd_mod]
> [<e88b5c60>] +0x0/0x100 [sd_mod]
> [<c0151fba>] do_open+0x2ea/0x320
> [<c0118bcc>] schedule+0x19c/0x340
> [<c0118d9a>] default_wake_function+0x2a/0x30
> [<c0152055>] blkdev_get+0x65/0x70
> [<c0175004>] register_disk+0xb4/0x150
> [<c0211731>] add_disk+0x51/0x60
> [<c02116b0>] exact_match+0x0/0x10
> [<c02116c0>] exact_lock+0x0/0x20
> [<e88b47c3>] sd_probe+0x1a3/0x260 [sd_mod]
> [<e88b5bc4>] +0x4/0x70 [sd_mod]
> [<c020baf3>] bus_match+0x43/0x80
> [<e88b5bc4>] +0x4/0x70 [sd_mod]
> [<e88b5bf4>] +0x34/0x70 [sd_mod]
> [<e88d8d1c>] scsi_bus_type+0x5c/0xe8 [scsi_mod]
> [<c020bb7f>] device_attach+0x4f/0x90
> [<e88b5bc4>] +0x4/0x70 [sd_mod]
> [<e88d8cc0>] scsi_bus_type+0x0/0xe8 [scsi_mod]
> [<c020bd33>] bus_add_device+0x63/0xb0
> [<c020ae1f>] device_add+0xcf/0x100
> [<e88d0720>] scsi_device_release+0x0/0x20 [scsi_mod]
> [<e88d8cc0>] scsi_bus_type+0x0/0xe8 [scsi_mod]
> [<e88d0824>] scsi_device_register+0xe4/0x180 [scsi_mod]
> [<e88d2758>] +0x4b8/0xc00 [scsi_mod]
> [<e88cfbae>] scsi_add_lun+0x1be/0x3a0 [scsi_mod]
> [<e88cfe36>] scsi_probe_and_add_lun+0xa6/0x120 [scsi_mod]
> [<e88cffb5>] scsi_add_device+0x35/0x50 [scsi_mod]
> [<e88a39f9>] sbp2_start_device+0x219/0x3d0 [sbp2]
> [<e88a37a3>] sbp2_start_ud+0xa3/0xe0 [sbp2]
> [<e88a3472>] sbp2_probe+0x32/0x40 [sbp2]
> [<e88a876c>] sbp2_driver+0xc/0x70 [sbp2]
> [<c020baf3>] bus_match+0x43/0x80
> [<e88a876c>] sbp2_driver+0xc/0x70 [sbp2]
> [<e88a879c>] sbp2_driver+0x3c/0x70 [sbp2]
> [<e88c885c>] ieee1394_bus_type+0x5c/0x100 [ieee1394]
> [<c020bb7f>] device_attach+0x4f/0x90
> [<e88a876c>] sbp2_driver+0xc/0x70 [sbp2]
> [<e88c8800>] ieee1394_bus_type+0x0/0x100 [ieee1394]
> [<c020bd33>] bus_add_device+0x63/0xb0
> [<c020ae1f>] device_add+0xcf/0x100
> [<e88c867c>] nodemgr_dev_template_ud+0xbc/0xc0 [ieee1394]
> [<e88be768>] nodemgr_process_unit_directory+0x188/0x490 [ieee1394]
> [<e88c1199>] +0x289/0x330 [ieee1394]
> [<e88bec52>] nodemgr_process_root_directory+0x1e2/0x1f0 [ieee1394]
> [<e88bef3e>] nodemgr_process_config_rom+0x8e/0xc0 [ieee1394]
> [<e88c873c>] nodemgr_dev_template_ne+0xbc/0xc0 [ieee1394]
> [<e88be203>] nodemgr_create_node+0x153/0x1e0 [ieee1394]
> [<e88bf376>] nodemgr_node_probe_one+0xe6/0xf0 [ieee1394]
> [<e88bf4c4>] nodemgr_node_probe+0x104/0x110 [ieee1394]
> [<e88bf7b8>] nodemgr_host_thread+0x118/0x180 [ieee1394]
> [<e88bf6a0>] nodemgr_host_thread+0x0/0x180 [ieee1394]
> [<c010912d>] kernel_thread_helper+0x5/0x18
>
> Code: 8b 40 4c 8b 00 85 c0 74 0b 83 38 02 74 19 ff 80 a0 00 00 00
>
>
> --
> Torrey Hoffman <thoffman@arnor.net>
>
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
next reply other threads:[~2003-06-12 20:36 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-12 19:50 Ben Collins [this message]
2003-06-12 20:02 Torrey Hoffman
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=20030612195018.GU4695@phunnypharm.org \
--to=bcollins@debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux1394-devel@lists.sourceforge.net \
--cc=thoffman@arnor.net \
/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
all inboxes | Powered by JetHome®