From: "Bjørn Mork" <bjorn@mork.no>
To: Daniel Mack <zonque@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
Sarbojit Ganguly <unixman.linuxboy@gmail.com>,
gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org, Takashi Iwai <tiwai@suse.de>
Subject: Re: Kernel Oops while disconnecting USB peripheral (always)
Date: Sat, 28 Jul 2012 14:27:02 +0200 [thread overview]
Message-ID: <87r4rwvzop.fsf@nemi.mork.no> (raw)
In-Reply-To: <500D659E.5090207@gmail.com> (Daniel Mack's message of "Mon, 23 Jul 2012 16:54:22 +0200")
Daniel Mack <zonque@gmail.com> writes:
> On 23.07.2012 16:47, Alan Stern wrote:
>> On Mon, 23 Jul 2012, Sarbojit Ganguly wrote:
>>> That is why I provided two stacks,
>>>
>>> 1st one is when I tried to remove the USB hub (which connects a webcam
>>> + microphone)
>>> 2nd one is when I tried to remove an USB powered external HDD.
>>>
>>> Just to make sure whether the problem is with USB sound or the USB subsystem.
>>
>> Do you stop all the programs that are using the USB devices before
>> unplugging the hub? Do you unmount the USB HDD first?
>>
>> The first crash shows a problem in the snd-usb-audio driver.
>>
>> The second crash shows a problem in the VFS layer or in ext3, not in
>> the USB stack.
>
> I dare to doubt there are two severe bugs of that kind that are 100%
> reproducible. I haven't had a hotplug crash in any of the two drivers
> for a long time, and I use both of them extensively.
Actually, based on the recent usb_wwan experience, I'd say that two such
bugs isn't as unlikely as it may seem at first. Even three if we add
the now fixed usb_wwan (or six, if we count the three drivers affected
by the usb_wwan bug). There are probably even more.
The reason is this change:
0998d0631 device-core: Ensure drvdata = NULL when no driver is bound
It will make bugs like this suddenly 100% reproducible. But the bugs
*are* in the drivers, and may have been there for a long time. The
drivers have been accessing drvdata after unbinding. They just didn't
crash prior to that commit.
But the commit is correct, and a very much needed improvement if my
assumptions are correct. The drivers need fixing and this just makes it
evident.
> I rather assume there's something else failing, probably some host
> controller issue that corrupts mempory? Can anyone else reproduce this
> maybe?
You could of course do like me and bisect, but if you end up with commit
0998d0631 then you haven't really learned more than confirming my guess.
Bjørn
next prev parent reply other threads:[~2012-07-28 12:27 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-23 3:42 Kernel Oops while disconnecting USB peripheral (always) Sarbojit Ganguly
2012-07-23 5:50 ` Daniel Mack
2012-07-23 6:03 ` Sarbojit Ganguly
2012-07-23 14:47 ` Alan Stern
2012-07-23 14:54 ` Daniel Mack
2012-07-23 15:05 ` Sarbojit Ganguly
2012-07-28 12:27 ` Bjørn Mork [this message]
2012-07-28 12:52 ` Daniel Mack
2012-07-28 13:25 ` Bjørn Mork
2012-07-28 13:30 ` Daniel Mack
2012-07-28 16:19 ` Alan Stern
2012-08-08 3:22 ` Sarbojit Ganguly
2012-07-23 15:04 ` Sarbojit Ganguly
2012-07-23 15:07 ` Daniel Mack
2012-07-28 11:13 ` Daniel Mack
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=87r4rwvzop.fsf@nemi.mork.no \
--to=bjorn@mork.no \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=tiwai@suse.de \
--cc=unixman.linuxboy@gmail.com \
--cc=zonque@gmail.com \
/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