From: Jonathan McDowell <noodles@earth.li>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>,
axboe@kernel.dk,
James Bottomley <James.Bottomley@HansenPartnership.com>,
Andi Kleen <andi@firstfloor.org>, Dave Jones <davej@redhat.com>,
SCSI development list <linux-scsi@vger.kernel.org>,
Kernel development list <linux-kernel@vger.kernel.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
USB list <linux-usb@vger.kernel.org>
Subject: Re: Linux 3.0 oopses when pulling a USB CDROM
Date: Tue, 12 Jul 2011 19:49:43 +0100 [thread overview]
Message-ID: <20110712184943.GE6432@earth.li> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1107041202170.12242-100000@netrider.rowland.org>
On Mon, Jul 04, 2011 at 12:04:54PM -0400, Alan Stern wrote:
> On Mon, 4 Jul 2011, Heiko Carstens wrote:
>
> > On Sat, Jul 02, 2011 at 01:37:59PM -0400, Alan Stern wrote:
> > > The second bug, which hit me but apparently not any of you, is that the
> > > request_queue's elevator gets deallocated while it is still in use.
> > > That's because __scsi_remove_device() calls scsi_free_queue(), which
> > > does blk_cleanup_queue(), which calls elevator_exit(), even though the
> > > device file is still open and more requests will be submitted when the
> > > file is closed.
> > >
> > > I'm not sure of the right fix for this. One possibility is to move the
> > > scsi_free_queue() call to scsi_device_dev_release_usercontext(). Or
> > > maybe the elevator_exit() call should be moved to blk_release_queue().
> > >
> > > Also, I have no idea why this shows up with USB drives but not other
> > > SCSI transports. A fluke of timing?
> >
> > FWIW, I reported a bug where the request_queue's elevator got deallocated
> > while it was still in use (fc transport with device hotplug):
> >
> > http://www.spinics.net/lists/linux-scsi/msg52879.html
>
> That does sound like the second bug I encountered. Can you reproduce
> it? Does the patch here:
>
> http://marc.info/?l=linux-kernel&m=130963676907731&w=2
>
> fix the problem?
FWIW I'm seeing crashes when FC devices go away while in use as well,
under 2.6.39 and 3.0.0-rc6. I will try the patch linked to above, but
the most recent Oops was:
[71286.103409] end_request: I/O error, dev sdaw, sector 0
[71286.113710] BUG: unable to handle kernel NULL pointer dereference at 0000000000000048
[71286.117681] IP: [<ffffffff81197828>] elv_completed_request+0x38/0x47
[71286.117681] PGD 2571c8067 PUD 253b81067 PMD 0
[71286.117681] Oops: 0000 [#1] SMP
[71286.117681] CPU 0
[71286.117681] Modules linked in: ip6table_filter ip6_tables iptable_filter ip_tables ebtable_nat ebtables x_tables autofs4 ipv6 kvm_intel kvm nfsd nfs lockd auth_rpcgss nfs_acl sunrpc dm_round_robin dm_multipath scsi_dh ipmi_devintf ipmi_si ipmi_msghandler sg evdev processor button thermal_sys serio_raw i5k_amb i2c_i801 ioatdma i2c_core dca rng_core tpm_tis tpm tpm_bios ext3 jbd dm_mod ses enclosure ata_generic ata_piix lpfc scsi_transport_fc scsi_tgt [last unloaded: scsi_wait_scan]
[71286.117681]
[71286.117681] Pid: 0, comm: swapper Not tainted 3.0.0-rc6 #15 Intel S5000PAL./S5000PAL0
[71286.117681] RIP: 0010:[<ffffffff81197828>] [<ffffffff81197828>] elv_completed_request+0x38/0x47
[71286.117681] RSP: 0018:ffff88025fc03e10 EFLAGS: 00010002
[71286.117681] RAX: 0000000000000000 RBX: ffff880253cdc1c0 RCX: 00000000000003fe
[71286.117681] RDX: ffff880253155840 RSI: ffff880255e37c70 RDI: ffff880253cdc1c0
[71286.117681] RBP: ffff880255e37c70 R08: 00000001010ec65f R09: 0000000000000000
[71286.117681] R10: ffff880255e37c70 R11: ffffffff817e3e98 R12: 00000000fffffffb
[71286.117681] R13: 0000000000000246 R14: 0000000000000000 R15: 0000000000000000
[71286.117681] FS: 0000000000000000(0000) GS:ffff88025fc00000(0000) knlGS:0000000000000000
[71286.117681] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[71286.117681] CR2: 0000000000000048 CR3: 0000000257144000 CR4: 00000000000006f0
[71286.117681] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[71286.117681] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[71286.117681] Process swapper (pid: 0, threadinfo ffffffff81600000, task ffffffff8165b020)
[71286.117681] Stack:
[71286.117681] ffff880255e37c70 ffffffff8119c27e ffff880255e37c70 ffff880253cdc1c0
[71286.117681] 00000000fffffffb ffffffff8119d0c1 0000000000000000 ffff880255d733c0
[71286.117681] ffff880255e37c70 0000000000000000 00000000fffffffb ffffffff8122dfbb
[71286.117681] Call Trace:
[71286.117681] <IRQ>
[71286.117681] [<ffffffff8119c27e>] ? __blk_put_request+0x2e/0xb0
[71286.117681] [<ffffffff8119d0c1>] ? blk_end_bidi_request+0x3b/0x55
[71286.117681] [<ffffffff8122dfbb>] ? scsi_io_completion+0x431/0x48e
[71286.117681] [<ffffffff811a110f>] ? blk_done_softirq+0x5f/0x6c
[71286.117681] [<ffffffff8103bc7d>] ? __do_softirq+0xbe/0x194
[71286.117681] [<ffffffff810569c6>] ? timekeeping_get_ns+0xd/0x2a
[71286.117681] [<ffffffff8130dc0c>] ? call_softirq+0x1c/0x30
[71286.117681] [<ffffffff81003fc5>] ? do_softirq+0x31/0x63
[71286.117681] [<ffffffff8103ba69>] ? irq_exit+0x3f/0x9f
[71286.117681] [<ffffffff8130d873>] ? call_function_single_interrupt+0x13/0x20
[71286.117681] <EOI>
[71286.117681] [<ffffffffa012d0ca>] ? acpi_idle_enter_simple+0xb4/0xe2 [processor]
[71286.117681] [<ffffffffa012d0c5>] ? acpi_idle_enter_simple+0xaf/0xe2 [processor]
[71286.117681] [<ffffffff81277aba>] ? cpuidle_idle_call+0xe4/0x162
[71286.117681] [<ffffffff81001da4>] ? cpu_idle+0xa5/0xdb
[71286.117681] [<ffffffff816c1ba8>] ? start_kernel+0x38e/0x399
[71286.117681] [<ffffffff816c138f>] ? x86_64_start_kernel+0xee/0xf2
[71286.117681] Code: 40 74 35 83 7e 44 01 74 04 a8 40 74 2b 83 e0 11 ff c8 0f 95 c0 83 e0 01 48 05 fc 00 00 00 ff 4c 87 04 f6 46 41 04 74 10 48 8b 02
[71286.117681] 8b 40 48 48 85 c0 74 04 41 58 ff e0 59 c3 48 83 ec 08 48 8d
[71286.117681] RIP [<ffffffff81197828>] elv_completed_request+0x38/0x47
[71286.117681] RSP <ffff88025fc03e10>
[71286.117681] CR2: 0000000000000048
[71286.117681] ---[ end trace 242b012d98a46112 ]---
[71286.117681] Kernel panic - not syncing: Fatal exception in interrupt
J.
--
Listen to the words, they tell you what to do...
next prev parent reply other threads:[~2011-07-12 18:49 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-01 17:05 Linux 3.0 oopses when pulling a USB CDROM Andi Kleen
2011-07-01 18:14 ` Dave Jones
2011-07-01 18:32 ` Andi Kleen
2011-07-01 18:40 ` Dave Jones
2011-07-02 15:13 ` Christoph Fritz
2011-07-01 20:29 ` James Bottomley
2011-07-01 20:43 ` [PATCH] USB: fix regression occurring during device removal Alan Stern
2011-07-01 21:04 ` Andi Kleen
2011-07-01 21:04 ` Linux 3.0 oopses when pulling a USB CDROM Alan Stern
2011-07-01 21:13 ` James Bottomley
2011-07-02 2:03 ` Alan Stern
2011-07-02 6:08 ` Andi Kleen
2011-07-02 12:24 ` James Bottomley
2011-07-02 17:05 ` Andi Kleen
[not found] ` <20110702170554.GJ23059-qrUzlfsMFqo/4alezvVtWx2eb7JE58TQ@public.gmane.org>
2011-07-02 17:09 ` James Bottomley
2011-07-02 18:15 ` Andi Kleen
2011-07-02 20:05 ` Alan Stern
[not found] ` <Pine.LNX.4.44L0.1107021559250.16190-100000-pYrvlCTfrz9XsRXLowluHWD2FQJk+8+b@public.gmane.org>
2011-07-03 1:16 ` Andi Kleen
[not found] ` <20110703011630.GA15637-qrUzlfsMFqo/4alezvVtWx2eb7JE58TQ@public.gmane.org>
2011-07-03 15:29 ` Alan Stern
2011-07-03 16:06 ` Alan Stern
2011-07-02 17:37 ` Alan Stern
2011-07-02 18:11 ` Andi Kleen
2011-07-02 19:59 ` Alan Stern
2011-07-03 1:17 ` Andi Kleen
2011-07-07 20:47 ` solved was " Andi Kleen
2011-07-18 16:59 ` Dan Williams
2011-07-18 18:00 ` Andi Kleen
2011-07-20 9:58 ` Jack Wang
2011-10-18 21:16 ` Ankit Jain
2011-10-18 21:30 ` James Bottomley
2011-10-21 13:26 ` Hannes Reinecke
2011-07-03 9:14 ` Dan Williams
2011-07-03 18:16 ` Andi Kleen
2011-07-03 20:37 ` Stefan Richter
2011-07-08 13:37 ` Stefan Richter
2011-07-08 13:41 ` Stefan Richter
[not found] ` <Pine.LNX.4.44L0.1107021320180.14703-100000-pYrvlCTfrz9XsRXLowluHWD2FQJk+8+b@public.gmane.org>
2011-07-04 11:27 ` Heiko Carstens
2011-07-04 16:04 ` Alan Stern
2011-07-06 6:50 ` Heiko Carstens
2011-07-12 18:49 ` Jonathan McDowell [this message]
2011-07-02 12:38 ` Alan Stern
[not found] ` <Pine.LNX.4.44L0.1107020837220.11097-100000-pYrvlCTfrz9XsRXLowluHWD2FQJk+8+b@public.gmane.org>
2011-07-02 18:10 ` Andi Kleen
[not found] ` <20110702060846.GH23059-qrUzlfsMFqo/4alezvVtWx2eb7JE58TQ@public.gmane.org>
2011-07-02 12:48 ` Rafael J. Wysocki
2011-07-02 17:06 ` Andi Kleen
2011-07-01 19:20 ` James Bottomley
2011-07-01 19:33 ` James Bottomley
2011-07-01 19:45 ` James Bottomley
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=20110712184943.GE6432@earth.li \
--to=noodles@earth.li \
--cc=James.Bottomley@HansenPartnership.com \
--cc=andi@firstfloor.org \
--cc=axboe@kernel.dk \
--cc=davej@redhat.com \
--cc=heiko.carstens@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=rjw@sisk.pl \
--cc=stern@rowland.harvard.edu \
/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