usbmidi reconnect -> kernel oops

usbmidi reconnect -> kernel oops

[Dmitry Baikov]

[-- Attachment #1: Type: text/plain, Size: 4902 bytes --]

Hi!
I am working on a alsa-midi driver for jackd and stepped on the following bug:
Sometimes, if a program is reading from usb midi port (rawmidi) and I
disconnect and then reconnect device, kernel dumps an oops. Below is
the trace, got by Lars Lutman with kernel 2.6.17 and alsa-lib-1.0.12,
but I had the same oops with kernel-2.6.19 (in-kernel alsa) and
alsa-lib-1.0.13, though I have only tainted trace (with nvidia driver,
I seen it with nv driver
+ simple test program as well, but lost the trace after reboot, and
then could not reproduce it).

The jackmidi driver does the following:
one thread (scan) periodically (every 2 seconds) walks all
cards/devs/subdevs and opens new ports if any. Two other threads poll
opened ports and read/write them (passing ports with errors back to
scan thread for closing).

If this trace is insufficient, I may try to reproduce the bug using a
simple test program (I have one already, but as I said, do not have
untainted trace).

Regards,
Dmitry.
---------------------

\aMessage from syslogd@localhost at Tue Jan  9 16:38:05 2007 ...
localhost kernel: Oops: 0000 [#1]

\aMessage from syslogd@localhost at Tue Jan  9 16:38:05 2007 ...
localhost kernel: PREEMPT

\aMessage from syslogd@localhost at Tue Jan  9 16:38:05 2007 ...
localhost kernel: CPU:    0

\aMessage from syslogd@localhost at Tue Jan  9 16:38:05 2007 ...
localhost kernel: EIP is at usb_buffer_free+0x16/0x40 [usbcore]

\aMessage from syslogd@localhost at Tue Jan  9 16:38:05 2007 ...
localhost kernel: eax: c8ccb800   ebx: 00000002   ecx: df51b180   edx:
00000040

\aMessage from syslogd@localhost at Tue Jan  9 16:38:05 2007 ...
localhost kernel: esi: d74abe00   edi: d31f6920   ebp: d0129e00   esp:
d2177ef0

\aMessage from syslogd@localhost at Tue Jan  9 16:38:05 2007 ...
localhost kernel: ds: 007b   es: 007b   ss: 0068

\aMessage from syslogd@localhost at Tue Jan  9 16:38:05 2007 ...
localhost kernel: Process jackd (pid: 11753, threadinfo=d2176000
task=d072aa90)

\aMessage from syslogd@localhost at Tue Jan  9 16:38:05 2007 ...
localhost kernel: Stack: 018cba80 1f51b180 d74abe00 e0e0cc4c 1f51b180
d31f6950 00000000 e0e0cce1

\aMessage from syslogd@localhost at Tue Jan  9 16:38:05 2007 ...
localhost kernel:        d8837b4c d8837aa0 00001fff e0d25538 d75c6c80
d0129f40 e0ceb16a 00000000

\aMessage from syslogd@localhost at Tue Jan  9 16:38:05 2007 ...
localhost kernel:        00001000 e0ceb20b d0129e00 00000000 cf0d46e0
d0129e00 e0ce66f0 cf0d46e0

\aMessage from syslogd@localhost at Tue Jan  9 16:38:05 2007 ...
localhost kernel: Call Trace:

\aMessage from syslogd@localhost at Tue Jan  9 16:38:05 2007 ...
localhost kernel:  <e0e0cc4c> snd_usbmidi_out_endpoint_delete+0x2c/0x50
[snd_usb_lib]  <e0e0cce1> snd_usbmidi_free+0x21/0x50 [snd_usb_lib]

\aMessage from syslogd@localhost at Tue Jan  9 16:38:05 2007 ...
localhost kernel:  <e0d25538> snd_rawmidi_free+0x68/0x80 [snd_rawmidi]
<e0ceb16a> snd_device_free+0x4a/0xa0 [snd]

\aMessage from syslogd@localhost at Tue Jan  9 16:38:05 2007 ...
localhost kernel:  <e0ceb20b> snd_device_free_all+0x4b/0x60 [snd]
<e0ce66f0> snd_card_do_free+0x30/0x100 [snd]

\aMessage from syslogd@localhost at Tue Jan  9 16:38:05 2007 ...
localhost kernel:  <e0ce7061> snd_card_file_remove+0xa1/0xd0 [snd]
<e0d2697f> snd_rawmidi_release+0x4f/0x70 [snd_rawmidi]

\aMessage from syslogd@localhost at Tue Jan  9 16:38:05 2007 ...
localhost kernel:  <c016755b> __fput+0x8b/0x1a0  <c01646f7> filp_close
+0x47/0x80

\aMessage from syslogd@localhost at Tue Jan  9 16:38:05 2007 ...
localhost kernel:  <c0102f77> sysenter_past_esp+0x54/0x75

\aMessage from syslogd@localhost at Tue Jan  9 16:38:05 2007 ...
localhost kernel: Code: 24 89 d8 ff d6 eb cf 8d b4 26 00 00 00 00 8d bc
27 00 00 00 00 83 ec 0c 85 c0 89 5c 24 04 89 74 24 08 74 20 8b 58 30 85
db 74 19 <8b> 43 24 85 c0 74 12 8b 70 10 85 f6 74 0b 8b 44 24 10 89 04
24

\aMessage from syslogd@localhost at Tue Jan  9 16:38:05 2007 ...
localhost kernel: EIP: [pg0+543150422/1069028352] usb_buffer_free
+0x16/0x40 [usbcore] SS:ESP 0068:d2177ef0

\aMessage from syslogd@localhost at Tue Jan  9 16:38:05 2007 ...
localhost kernel: EIP: [<e0a7a156>] usb_buffer_free+0x16/0x40 [usbcore]
SS:ESP 0068:d2177ef0


--
Lars Luthman - please encrypt any email sent to me if possible
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E
Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________
Jackit-devel mailing list
Jackit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-devel

[-- Attachment #2: signature.asc --]
[-- Type: text/plain, Size: 190 bytes --]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQBFo7doQ3FGUATHfi4RAmdBAJ45YpTzP3yNQaDeMuTALejjJXMGDwCfTd1a
1jY79FKmgIDwOwHmvPA+XS0=
=DkdM
-----END PGP SIGNATURE-----


[-- Attachment #3: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #4: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: usbmidi reconnect -> kernel oops

[Dmitry Baikov]

Sorry, I forgot to note: please CC me in your replies, as I am not subscribed.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Ideas for the softvol plugin

[Ingo Müller]

Hi!

I have some ideas about features that could be added to the softvol
plugin, that I want to discuss with you.

1) A mute/unmute function. I think this is the most easy job.

2) Ability to replace an existing control. I have no idea whether it is
possible to realize this, but this would be very usefull (see below).

3) Multi channel capabilities. This is just a vague idea. The aim is to
be able to control e.g. front, rear and center/lfe channels seperately
from each other. Maybe like this:

pcm.softvol {
    type softvol
    slave {
        pcm "hw:0,1"
    }
    controls [
        {
            name "SoftFront"
            affects [ 0 1 ]
        }
        {
            name "SoftRear"
            affects [ 2 3 ]
        }
        {
            name "SoftCenterLfe"
            affects [ 4 5 ]
        }
    ]
}

All the three suggestions aim to solve one frequent problem (it occured
with EVERY sound card I ever had (~5) and forums are full of them): The
volume control elements don't control the volume like they are supposed
to. E.g. I've seen so many people whose Master control only affects the
volume of the front channels. With the above changes, one could just
rebuild a software based volume control system without having to worry
whether the hardware controls are supported or not.

Right now, one can create a softvol device, create a control named
"Softmaster" and make every application use this device. AFAIK, there's
is no mute function. I don't need to explain why this would be usefull.
What can't be done is name this control "Master" (unless this control
doesn't exist yet). Many media applications have a function to control
the volume, but most of them just control the master volume, so ones
"Softmaster" would not be touched by them.

Well the multichannel capabilities are not that important. It's just an
idea, like I said. With some cards, I was able to realize the same
functionality with softvol in combination with the multi plugin, on
other I wasn't. I just think that this would be the cleanest way to do it.

Finally, I wanted to mention, that I am not a developper of any sort,
but as I user, I am always trying to improve things (see my work on the
alsa wiki). I hope some of you think about my suggestions anyway!

Greets, Ingo

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Ideas for the softvol plugin

[Daniel Jacobowitz]

On Thu, Jan 11, 2007 at 03:54:55PM +0100, Ingo Müller wrote:
> Hi!
> 
> I have some ideas about features that could be added to the softvol
> plugin, that I want to discuss with you.
> 
> 1) A mute/unmute function. I think this is the most easy job.

I've got code for this lying around somewhere, though I'm not sure
where.  But...

> All the three suggestions aim to solve one frequent problem (it occured
> with EVERY sound card I ever had (~5) and forums are full of them): The
> volume control elements don't control the volume like they are supposed
> to. E.g. I've seen so many people whose Master control only affects the
> volume of the front channels. With the above changes, one could just
> rebuild a software based volume control system without having to worry
> whether the hardware controls are supported or not.

Take a look at the "ganged volume" patch I posted to this list, at the
beginning of the month.  In general, when the kernel master volume
only controls the front channels, that's because it's how the card's
control registers work; ganged volume lets you add a kernel control
that moves things up and down in sync.  It's a bit better than using
softvol, because you don't have to do any processing of the samples
as they pass through.

It's to solve exactly what you're describing.

You have to adjust the kernel drivers to set it up properly, but
after messing around with softvol for a while, I think that's best.
It's not hard to do.

-- 
Daniel Jacobowitz
CodeSourcery

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Ideas for the softvol plugin

[Ingo Müller]

Daniel Jacobowitz schrieb:
> On Thu, Jan 11, 2007 at 03:54:55PM +0100, Ingo Müller wrote:
>> 1) A mute/unmute function. I think this is the most easy job.
> 
> I've got code for this lying around somewhere, though I'm not sure
> where.  But...

Sounds great! That'd be awesome if this would find its way into the
official alsa code!

> Take a look at the "ganged volume" patch I posted to this list, at the
> beginning of the month.  In general, when the kernel master volume
> only controls the front channels, that's because it's how the card's
> control registers work; ganged volume lets you add a kernel control
> that moves things up and down in sync.  It's a bit better than using
> softvol, because you don't have to do any processing of the samples
> as they pass through.
> 
> It's to solve exactly what you're describing.

That sounds good, too! Unfortunately, I don't understand C code very
well, and nothing of kernel programming at all. I doubt whether I would
be able to apply the patch, even if I used the same module as you do
(which I don't).

On Sat, Oct 14, 2006 at 04:37:37PM -0400, Daniel Jacobowitz wrote:
> Here's an implementation of a ganged volume control. I suspect it
> could be improved with advice from a maintainer; I'm happy to revise
> it. It works in every way I've been able to test it. I suspect plenty
> of other devices could benefit from this; probably even some not AC97
> based, so maybe it ought to move elsewhere, but at least it's a start.

I do also think that this piece of code (as far as I understan it)
should be used more often or more centrally! On many sound cards, the
master volume doesn't seem to control the volume of all channels (which
it should definitely).

Greetings, Ingo


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Ideas for the softvol plugin

[Tom Horsley]

On Thu, 11 Jan 2007 15:54:55 +0100
Ingo Müller <alsa@ingomueller.net> wrote:

> I have some ideas about features that could be added to the softvol
> plugin, that I want to discuss with you.

The feature I'd love to see might possibly be called something like
"dynamic volume normalizer". I want a central place to arrange for
the volume to automagically go down when it starts getting loud
and up when it starts getting soft. No two programs ever seem to
treat volume settings the same so when one is working fine, the next
one I start will blow my head off or be totally inaudible.

Would this softvol plugin be the place to figure out how to do that?
Or is the architecture such that something entirely different would be
required?

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Ideas for the softvol plugin

[Ingo Müller]

Hi!

It's just a blind guess, but *maybe* it could work with ladspa. There is
a ladspa plugin for alsa and a normalization plugin for ladspa. I didn't
work with either of them but it *could* work. If you really try it and
get it to work, then please add an howto in the ALSA wiki at
http://alsa.opensrc.org. I'd sure appriciate it!

Greets, Ingo


Tom Horsley schrieb:
> On Thu, 11 Jan 2007 15:54:55 +0100
> Ingo Müller <alsa@ingomueller.net> wrote:
> 
>> I have some ideas about features that could be added to the softvol
>> plugin, that I want to discuss with you.
> 
> The feature I'd love to see might possibly be called something like
> "dynamic volume normalizer". I want a central place to arrange for
> the volume to automagically go down when it starts getting loud
> and up when it starts getting soft. No two programs ever seem to
> treat volume settings the same so when one is working fine, the next
> one I start will blow my head off or be totally inaudible.
> 
> Would this softvol plugin be the place to figure out how to do that?
> Or is the architecture such that something entirely different would be
> required?


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Ideas for the softvol plugin

[Takashi Iwai]

At Thu, 11 Jan 2007 15:54:55 +0100,
Ingo Müller wrote:
> 
> Hi!
> 
> I have some ideas about features that could be added to the softvol
> plugin, that I want to discuss with you.
> 
> 1) A mute/unmute function. I think this is the most easy job.

Likely.

> 2) Ability to replace an existing control. I have no idea whether it is
> possible to realize this, but this would be very usefull (see below).

Well, my idea is to overwrap the existing mixer elements with the new
user-space elements instead of replacing the kernel space entries.
This would be a plugin for ctl interface.

> 3) Multi channel capabilities. This is just a vague idea. The aim is to
> be able to control e.g. front, rear and center/lfe channels seperately
> from each other. Maybe like this:
> 
> pcm.softvol {
>     type softvol
>     slave {
>         pcm "hw:0,1"
>     }
>     controls [
>         {
>             name "SoftFront"
>             affects [ 0 1 ]
>         }
>         {
>             name "SoftRear"
>             affects [ 2 3 ]
>         }
>         {
>             name "SoftCenterLfe"
>             affects [ 4 5 ]
>         }
>     ]
> }

Hm, this wouldn't be too hard, too...


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Ideas for the softvol plugin

[Ingo Müller]

Hi!

Thanks for the answer!

Takashi Iwai schrieb:
> At Thu, 11 Jan 2007 15:54:55 +0100,
> Ingo Müller wrote:
>> Hi!
>>
>> I have some ideas about features that could be added to the softvol
>> plugin, that I want to discuss with you.
>>
>> 1) A mute/unmute function. I think this is the most easy job.
> 
> Likely.
> 
>> 2) Ability to replace an existing control. I have no idea whether it is
>> possible to realize this, but this would be very usefull (see below).
> 
> Well, my idea is to overwrap the existing mixer elements with the new
> user-space elements instead of replacing the kernel space entries.
> This would be a plugin for ctl interface.

I'm not sure whether I understand it right. But that doesn't matter.
Anything that lets the master volume control control the master volume
is fine :-)

> 
>> 3) Multi channel capabilities. This is just a vague idea. The aim is to
>> be able to control e.g. front, rear and center/lfe channels seperately
>> from each other. Maybe like this:
>>
[...]
> 
> Hm, this wouldn't be too hard, too...

I'd really love if some of those ideas would be implemented.
Unfortunately, I really can't do it myself. What I can do and sure will
is testing. So if anyone needs a tester for one of those things, here I
am :-)

Greets, Ingo

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV