From: Takashi Iwai <tiwai@suse.de>
To: karsten wiese <annabellesgarden@yahoo.de>
Cc: Lee Revell <rlrevell@joe-job.com>,
Clemens Ladisch <clemens@ladisch.de>,
Devel Alsa <alsa-devel@lists.sourceforge.net>
Subject: Re: [PATCH]usx2y: prevent oops & dead keyboard on hot usb unplugging
Date: Fri, 15 Apr 2005 17:50:36 +0200 [thread overview]
Message-ID: <s5hmzs0ca43.wl@alsa2.suse.de> (raw)
In-Reply-To: <20050415154544.40500.qmail@web26508.mail.ukl.yahoo.com>
At Fri, 15 Apr 2005 17:45:44 +0200 (CEST),
karsten wiese wrote:
>
> --- Takashi Iwai <tiwai@suse.de> schrieb:
> > At Fri, 15 Apr 2005 17:14:40 +0200 (CEST),
> > karsten wiese wrote:
> > >
> > >
> > > --- Takashi Iwai <tiwai@suse.de> wrote:
> > > > At Fri, 15 Apr 2005 16:28:54 +0200 (CEST),
> > > > karsten wiese wrote:
> > > > >
> > > > >
> > > > > --- Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > At Fri, 15 Apr 2005 15:59:25 +0200 (CEST),
> > > > > > karsten wiese wrote:
> > > > > > >
> > > > > > >
> > > > > > > --- Lee Revell <rlrevell@joe-job.com> wrote:
> > > > > > > > On Thu, 2005-04-14 at 20:59 +0200, karsten
> > wiese
> > > > > > wrote:
> > > > > > > > > Hi Clemens & Takashi
> > > > > > > > >
> > > > > > > > > Please commit the patch.
> > > > > > > >
> > > > > > > > Is the ALSA in kernel 2.6.11 affected? If
> > so,
> > > > this
> > > > > > >
> > > > > > > Think so, yes. The keyboard dead effect +
> > described
> > > > > > oops
> > > > > > > has been around for quiet a long time.
> > > > > > > (There is a lkml mail from yesterday about an
> > > > > > usb-cellphone
> > > > > > > setup,
> > > > > > > where the same oops + dead keyboard happens
> > also:
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://marc.theaimsgroup.com/?i=<20050414230621.49663f75.vsu%20()%20altlinux%20!%20ru>
> > > > > > > )
> > > > > > > There is also an alsa-bug with snd-usb-audio in
> > the
> > > > > > > bugbase.
> > > > > > > Clemens seams not to be convinced about this
> > > > aproach
> > > > > > yet.
> > > > > > > maybe 'cause the comment of
> > snd_card_free_in_thread
> > > > > > > explicitly states that its the one to be called
> > for
> > > > > > > hotplug:
> > > > > > > /**
> > > > > > > * snd_card_free_in_thread - call
> > snd_card_free()
> > > > in
> > > > > > > thread
> > > > > > > * @card: soundcard structure
> > > > > > > *
> > > > > > > * This function schedules the call of
> > > > snd_card_free()
> > > > > > > function in a
> > > > > > > * work queue. When all devices are released
> > > > > > (non-busy),
> > > > > > > the work
> > > > > > > * is woken up and calls snd_card_free().
> > > > > > > *
> > > > > > > * When a card can be disconnected at any time
> > by
> > > > > > hotplug
> > > > > > > service,
> > > > > > > * this function should be used in disconnect
> > (or
> > > > > > detach)
> > > > > > > callback
> > > > > > > * instead of calling snd_card_free()
> > directly.
> > > > > > > *
> > > > > > > * Returns - zero otherwise a negative error
> > code
> > > > if
> > > > > > the
> > > > > > > start of thread failed.
> > > > > > > */
> > > > > > >
> > > > > > > Also I remember , that snd_card_free didn't
> > work ok
> > > > > > when i
> > > > > > > used it in the first implementations of
> > > > usx2y-module
> > > > > > some 2
> > > > > > > years ago.
> > > > > > > but that was on kernel 2.4.something.......
> > > > > > > maybe above comment is from kernel 2.4 also and
> > the
> > > > > > hotplug
> > > > > > > system has changed ? anybody?
> > > > > >
> > > > > > Might be. To be sure, check whether the release
> > fops
> > > > is
> > > > > > called
> > > > > > properly before you calling snd_card_free().
> > > > >
> > > > > You mean snd_card_disconnect()?
> > > > > That's called with the same argument and before
> > > > > snd_card_free().
> > > >
> > > > No, I mean snd_card_free(), which you changed from
> > > > snd_card_free_in_thread(). Someone has to release
> > the
> > > > files
> > > > (i.e. call release fops eventually) before clean up
> > > > everything via
> > > > snd_card_free().
> > > >
> > > Erm, you mean the close (for
> > > snd_pcm_ops_t,snd_rawmidi_ops_t) and release (for
> > > snd_hwdep_ops_t) callbacks then?
> >
> > I meant the "file operations". Anyway, the callback of
> > PCM or rawmidi
> > will be called from the release callback of fops,
> > though...
> >
> > > They should all be called
> > > before snd_card_free()?
> >
> > Yes.
> >
> > > in other words:
> > > <snip>
> > > int snd_card_free_in_thread(snd_card_t * card)
> > > {
> > > if (card->files == NULL) {
> > > snd_card_free(card);
> > > return 0;
> > > }
> > > </snip>
> > > the "(card->files == NULL)" MUST be true before
> > > snd_card_free() can be called safely?
> >
> > Yes, exactly.
> > Otherwise, snd_card_free() removes the device entry, and
> > the remainig
> > files will have no way to release themselves after that.
>
> Just found that snd_card_free() also waits for all files
> being released:
> <snip>
> int snd_card_free(snd_card_t * card)
> {
> struct snd_shutdown_f_ops *s_f_ops;
>
> if (card == NULL)
> return -EINVAL;
> write_lock(&snd_card_rwlock);
> snd_cards[card->number] = NULL;
> write_unlock(&snd_card_rwlock);
>
> #ifdef CONFIG_PM
> wake_up(&card->power_sleep);
> #ifdef CONFIG_SND_GENERIC_PM
> if (card->pm_dev) {
> snd_generic_device_unregister(card->pm_dev);
> card->pm_dev = NULL;
> }
> #endif
> #endif
>
> /* wait, until all devices are ready for the free
> operation */
> wait_event(card->shutdown_sleep, card->files == NULL);
> </snip>
>
> (-: You apply my patch now?
No, not enough :) This is exactly why snd_card_free_in_thread() was
introduced.
As I asked, please make sure that the files are all released before
snd_card_free(). Otherwise the disconnect callback hangs at this
point because of this check.
(IOW, the fact that calling snd_card_free doesn't hang implies that
the files are released. But it's better to check this explicitly.)
Takashi
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
next prev parent reply other threads:[~2005-04-15 15:50 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-15 15:14 [PATCH]usx2y: prevent oops & dead keyboard on hot usb unplugging karsten wiese
2005-04-15 15:22 ` Takashi Iwai
2005-04-15 15:45 ` karsten wiese
2005-04-15 15:50 ` Takashi Iwai [this message]
2005-04-15 16:25 ` Clemens Ladisch
2005-04-15 15:32 ` Clemens Ladisch
-- strict thread matches above, loose matches on Subject: below --
2005-04-19 22:14 karsten wiese
2005-04-19 21:22 karsten wiese
2005-04-20 9:17 ` Takashi Iwai
2005-04-16 0:31 karsten wiese
2005-04-19 9:23 ` Takashi Iwai
2005-04-19 14:27 ` Clemens Ladisch
2005-04-19 9:32 ` Takashi Iwai
2005-04-15 15:15 karsten wiese
2005-04-15 14:28 karsten wiese
2005-04-15 14:36 ` Takashi Iwai
2005-04-15 13:59 karsten wiese
2005-04-15 14:16 ` Takashi Iwai
2005-04-15 13:31 karsten wiese
2005-04-14 18:59 karsten wiese
2005-04-14 22:25 ` Lee Revell
2005-04-15 7:07 ` Clemens Ladisch
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=s5hmzs0ca43.wl@alsa2.suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@lists.sourceforge.net \
--cc=annabellesgarden@yahoo.de \
--cc=clemens@ladisch.de \
--cc=rlrevell@joe-job.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