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: 63+ 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 20:43 ` 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:04 ` Alan Stern
2011-07-01 21:13 ` James Bottomley
2011-07-02 2:03 ` Alan Stern
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 17:09 ` James Bottomley
2011-07-02 18:15 ` Andi Kleen
2011-07-02 18:15 ` Andi Kleen
2011-07-02 20:05 ` Alan Stern
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
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 15:29 ` Alan Stern
2011-07-03 16:06 ` Alan Stern
2011-07-03 16:06 ` Alan Stern
2011-07-02 17:37 ` 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-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
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 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
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
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 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 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.