ALSA 0.9.3a sequencer/rawmidi oops

ALSA 0.9.3a sequencer/rawmidi oops

[Jonathan Woithe]

Hi all

Over the weekend I thought I'd give ALSA 0.9.3a a go.  For the most part it
worked fine.  However, there seems to be a bug in the sequencer or rawmidi
components.

If any application connects to a sequencer port, a oops results and the
machine is locked solid.  An example decoded oops is given at the end of
this email.  Initially I was testing using jazz++ 4.1.3 and OSS emulation,
but the oops occurs if pmidi is used.  Because pmidi is a native ALSA app,
it tends to suggest the problem is within the sequencer and/or MPU401
rawmidi components.  The oops given occurred when pmidi was invoked as:
  pmidi -p 64:0
where "64:0" was the port corresponding to the ens1370's external midi
interface.

ALSA 0.9.2 gives no trouble at all.

The soundcard in use is an Ensoniq AudioPCI (ens1370).

Does anyone have any ideas here?

The oops:
> ksymoops 2.4.8 on i586 2.4.20.  Options used
>      -V (default)
>      -k /proc/ksyms (default)
>      -l /proc/modules (default)
>      -o /lib/modules/2.4.20 -o /home/audio/alsa/alsa-driver-0.9.3a/modules/ (specified)
>      -m /boot/System.map (specified)
> 
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> *pde = 00000000
> Oops: 0000
> CPU:    0
> EIP:    0010:[<c011373b>]    Not tainted
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010097
> eax: c13ede84   ebx: c13ede80   ecx: 00000000   edx: 00000003
> esi: 00000001   edi: 00000001   ebp: c7a6dda8   esp: c7a6dd90
> ds: 0018   es: 0018   ss: 0018
> Process pmidi (pid: 1291, stackpage=c7a6d000)
> Stack: c13ede60 00000001 c75e8960 c13ede84 00000082 00000003 00000086 ccafc7c8
>        80006800 00000002 c12c8a60 00000000 ccb10f42 c75e8960 00000001 00000001
>        ff000000 80000068 cc2c8a60 00006800 ccb11399 c12c8a60 c757a3c0 24000001
> Call trace:    [<ccafc7c8>] [<ccb10f42>] [<ccb11399>] [<c0109b4d>] [<c0109cbe>]
>   [<c010be78>] [<ccafc847>] [<ccafc986>] [<ccb1539b>] [<ccaf8491>] [<ccaf8066>]
>   [<ccaf811e>] [<ccaf82a7>] [<ccaf235b>] [<ccaf23e7>] [<ccaf25a2>] [<c0131814>]
>   [<c01308a5>] [<c01308f3>] [<c0108813>]
> Code: 8b 01 85 45 fc 74 4e 31 c0 9c 5e fa c7 01 00 00 00 00 00 83 79
> 
> 
> >>EIP; c011373b <__wake_up+2b/98>   <=====
> 
> >>eax; c13ede84 <_end+10d8400/c7bc5dc>
> >>ebx; c13ede80 <_end+10d83fc/c7bc5dc>
> >>ebp; c7a6dda8 <_end+7758324/c7bc5dc>
> >>esp; c7a6dd90 <_end+775830c/c7bc5dc>
> 
> Trace; ccafc7c8 <[snd-rawmidi]snd_rawmidi_transmit_ack+88/90>
> Trace; ccb10f42 <[snd-ens1370]snd_ensoniq_midi_interrupt+82/d0>
> Trace; ccb11399 <[snd-ens1370]snd_audiopci_interrupt+a9/b0>
> Trace; c0109b4d <handle_IRQ_event+31/5c>
> Trace; c0109cbe <do_IRQ+72/b4>
> Trace; c010be78 <call_do_IRQ+5/d>
> Trace; ccafc847 <[snd-rawmidi]snd_rawmidi_kernel_write1+37/160>
> Trace; ccafc986 <[snd-rawmidi]snd_rawmidi_kernel_write+16/20>
> Trace; ccb1539b <[snd-seq-midi]midisynth_unuse+1b/40>
> Trace; ccaf8491 <[snd-seq]unsubscribe_port+41/90>
> Trace; ccaf8066 <[snd-seq]clear_subscriber_list+e6/180>
> Trace; ccaf811e <[snd-seq]port_delete+1e/50>
> Trace; ccaf82a7 <[snd-seq]snd_seq_delete_all_ports+97/d0>
> Trace; ccaf235b <[snd-seq]seq_free_client1+b/70>
> Trace; ccaf23e7 <[snd-seq]seq_free_client+27/a0>
> Trace; ccaf25a2 <[snd-seq]snd_seq_release+12/40>
> Trace; c0131814 <fput+4c/e0>
> Trace; c01308a5 <filp_close+59/64>
> Trace; c01308f3 <sys_close+43/54>
> Trace; c0108813 <system_call+33/40>
> 
> Code;  c011373b <__wake_up+2b/98>
> 00000000 <_EIP>:
> Code;  c011373b <__wake_up+2b/98>   <=====
>    0:   8b 01                     mov    (%ecx),%eax   <=====
> Code;  c011373d <__wake_up+2d/98>
>    2:   85 45 fc                  test   %eax,0xfffffffc(%ebp)
> Code;  c0113740 <__wake_up+30/98>
>    5:   74 4e                     je     55 <_EIP+0x55>
> Code;  c0113742 <__wake_up+32/98>
>    7:   31 c0                     xor    %eax,%eax
> Code;  c0113744 <__wake_up+34/98>
>    9:   9c                        pushf  
> Code;  c0113745 <__wake_up+35/98>
>    a:   5e                        pop    %esi
> Code;  c0113746 <__wake_up+36/98>
>    b:   fa                        cli    
> Code;  c0113747 <__wake_up+37/98>
>    c:   c7 01 00 00 00 00         movl   $0x0,(%ecx)
> Code;  c011374d <__wake_up+3d/98>
>   12:   00 83 79 00 00 00         add    %al,0x79(%ebx)
> 
>  <0>Kernel panic: Aiee, killing interrupt handler!

Regards 
  jonathan
-- 
* Jonathan Woithe    jwoithe@physics.adelaide.edu.au                        *
*                    http://www.physics.adelaide.edu.au/~jwoithe            *
***-----------------------------------------------------------------------***
** "Time is an illusion; lunchtime doubly so"                              **
*  "...you wouldn't recognize a subtle plan if it painted itself purple and *
*   danced naked on a harpsichord singing 'subtle plans are here again'"    *


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: ALSA 0.9.3a sequencer/rawmidi oops

[Takashi Iwai]

At Mon, 12 May 2003 12:43:49 +0930 (CST),
Jonathan Woithe wrote:
> 
> Hi all
> 
> Over the weekend I thought I'd give ALSA 0.9.3a a go.  For the most part it
> worked fine.  However, there seems to be a bug in the sequencer or rawmidi
> components.
> 
> If any application connects to a sequencer port, a oops results and the
> machine is locked solid.  An example decoded oops is given at the end of
> this email.  Initially I was testing using jazz++ 4.1.3 and OSS emulation,
> but the oops occurs if pmidi is used.  Because pmidi is a native ALSA app,
> it tends to suggest the problem is within the sequencer and/or MPU401
> rawmidi components.  The oops given occurred when pmidi was invoked as:
>   pmidi -p 64:0
> where "64:0" was the port corresponding to the ens1370's external midi
> interface.
> 
> ALSA 0.9.2 gives no trouble at all.
> 
> The soundcard in use is an Ensoniq AudioPCI (ens1370).
> 
> Does anyone have any ideas here?

does this still happen on the cvs version?


Takashi


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: ALSA 0.9.3a sequencer/rawmidi oops

[Jonathan Woithe]

Hi Takashi

> > Over the weekend I thought I'd give ALSA 0.9.3a a go.  For the most part it
> > worked fine.  However, there seems to be a bug in the sequencer or rawmidi
> > components.
> > 
> > If any application connects to a sequencer port, a oops results and the
> > machine is locked solid.  An example decoded oops is given at the end of
> > this email.  Initially I was testing using jazz++ 4.1.3 and OSS emulation,
> > but the oops occurs if pmidi is used.  Because pmidi is a native ALSA app,
> > it tends to suggest the problem is within the sequencer and/or MPU401
> > rawmidi components.  The oops given occurred when pmidi was invoked as:
> >   pmidi -p 64:0
> > where "64:0" was the port corresponding to the ens1370's external midi
> > interface.
> > 
> > ALSA 0.9.2 gives no trouble at all.
> > 
> > The soundcard in use is an Ensoniq AudioPCI (ens1370).
> > 
> > Does anyone have any ideas here?
> 
> does this still happen on the cvs version?

The current CVS version is worse.  I grabbed a version at around 0900
UT+0930 today (Wed 14 May).  I have just compiled this and loaded it.  When 
  pmidi -l
or
  pmidi -p 64:0
is run, we now get an error about being unable to open the sequencer.  Then
when 
  ls /proc/asound
is executed the kernel oopses.  It's not a hard lock - the machine keeps
going - but it's an oops non-the-less which clearly shouldn't happen.  It
seems that there is something strange lurking in the sequencer.  The decoded
oops is reproduced below.

The oops occurs irrespective of whether pmidi has been run first.  After
loadin CVS alsa, the "ls /proc/asound" command will oops even if it's the
first thing done after loading.

ksymoops 2.4.8 on i586 2.4.20.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.20 -o /home/audio/alsa/alsa-20030514-cvs/alsa-driver/modules/ (specified)
     -m /boot/System.map (specified)

Unable to handle kernel NULL pointer dereference at virtual address 00000034
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<cc976d1d>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: 00000000   ebx: 00000000   ecx: c43c72a0   edx: c9761940
esi: c43c72a0   edi: c3f7bfa4   ebp: 00001001   esp: c3f7bf80
ds: 0018   es: 0018   ss: 0018
Process ls (pid: 2928, stackpage=c3f7b000)
Stack: c0136ed7 c9761940 bfffe780 00001001 c43c72a0 c3f7a000 bffff7c0 00000000
       bffff7a8 c9761940 c12164a0 c3f7a000 080572d8 080572c0 00000008 00000001
       c0108813 bffff7c0 bfffe780 00001001 bffff7c0 00000000 bffff7a8 00000055
Call Trace:    [<c0136ed7>] [<c0108813>]
Code: 8b 40 34 50 8b 4c 24 10 51 8b 44 24 10 50 52 e8 bf 4e 7c f3

>>EIP; cc976d1d <[snd]snd_info_card_readlink+d/30>   <=====

>>ecx; c43c72a0 <_end+40b181c/c65c5dc>
>>edx; c9761940 <_end+944bebc/c65c5dc>
>>esi; c43c72a0 <_end+40b181c/c65c5dc>
>>edi; c3f7bfa4 <_end+3c66520/c65c5dc>
>>esp; c3f7bf80 <_end+3c664fc/c65c5dc>

Trace; c0136ed7 <sys_readlink+87/a0>
Trace; c0108813 <system_call+33/40>

Code;  cc976d1d <[snd]snd_info_card_readlink+d/30>
00000000 <_EIP>:
Code;  cc976d1d <[snd]snd_info_card_readlink+d/30>   <=====
   0:   8b 40 34                  mov    0x34(%eax),%eax   <=====
Code;  cc976d20 <[snd]snd_info_card_readlink+10/30>
   3:   50                        push   %eax
Code;  cc976d21 <[snd]snd_info_card_readlink+11/30>
   4:   8b 4c 24 10               mov    0x10(%esp,1),%ecx
Code;  cc976d25 <[snd]snd_info_card_readlink+15/30>
   8:   51                        push   %ecx
Code;  cc976d26 <[snd]snd_info_card_readlink+16/30>
   9:   8b 44 24 10               mov    0x10(%esp,1),%eax
Code;  cc976d2a <[snd]snd_info_card_readlink+1a/30>
   d:   50                        push   %eax
Code;  cc976d2b <[snd]snd_info_card_readlink+1b/30>
   e:   52                        push   %edx
Code;  cc976d2c <[snd]snd_info_card_readlink+1c/30>
   f:   e8 bf 4e 7c f3            call   f37c4ed3 <_EIP+0xf37c4ed3>


Best regards
  jonathan
-- 
* Jonathan Woithe    jwoithe@physics.adelaide.edu.au                        *
*                    http://www.physics.adelaide.edu.au/~jwoithe            *
***-----------------------------------------------------------------------***
** "Time is an illusion; lunchtime doubly so"                              **
*  "...you wouldn't recognize a subtle plan if it painted itself purple and *
*   danced naked on a harpsichord singing 'subtle plans are here again'"    *


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: ALSA 0.9.3a sequencer/rawmidi oops

[Takashi Iwai]

At Wed, 14 May 2003 22:16:07 +0930 (CST),
Jonathan Woithe wrote:
> 
> Hi Takashi
> 
> > > Over the weekend I thought I'd give ALSA 0.9.3a a go.  For the most part it
> > > worked fine.  However, there seems to be a bug in the sequencer or rawmidi
> > > components.
> > > 
> > > If any application connects to a sequencer port, a oops results and the
> > > machine is locked solid.  An example decoded oops is given at the end of
> > > this email.  Initially I was testing using jazz++ 4.1.3 and OSS emulation,
> > > but the oops occurs if pmidi is used.  Because pmidi is a native ALSA app,
> > > it tends to suggest the problem is within the sequencer and/or MPU401
> > > rawmidi components.  The oops given occurred when pmidi was invoked as:
> > >   pmidi -p 64:0
> > > where "64:0" was the port corresponding to the ens1370's external midi
> > > interface.
> > > 
> > > ALSA 0.9.2 gives no trouble at all.
> > > 
> > > The soundcard in use is an Ensoniq AudioPCI (ens1370).
> > > 
> > > Does anyone have any ideas here?
> > 
> > does this still happen on the cvs version?
> 
> The current CVS version is worse.  I grabbed a version at around 0900
> UT+0930 today (Wed 14 May).  I have just compiled this and loaded it.  When 
>   pmidi -l
> or
>   pmidi -p 64:0
> is run, we now get an error about being unable to open the sequencer.  Then
> when 
>   ls /proc/asound
> is executed the kernel oopses.  It's not a hard lock - the machine keeps
> going - but it's an oops non-the-less which clearly shouldn't happen.  It
> seems that there is something strange lurking in the sequencer.  The decoded
> oops is reproduced below.

yep, there is a bug in the recent cvs version.
right now i fixed it and committed.  please update your tree again.


thanks,

Takashi


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: ALSA 0.9.3a sequencer/rawmidi oops

[Jonathan Woithe]

> > > > Over the weekend I thought I'd give ALSA 0.9.3a a go.  For the most part it
> > > > worked fine.  However, there seems to be a bug in the sequencer or rawmidi
> > > > components.
> > > > 
> > > > If any application connects to a sequencer port, a oops results and the
> > > > machine is locked solid.  An example decoded oops is given at the end of
> > > > this email.  Initially I was testing using jazz++ 4.1.3 and OSS emulation,
> > > > but the oops occurs if pmidi is used.  Because pmidi is a native ALSA app,
> > > > it tends to suggest the problem is within the sequencer and/or MPU401
> > > > rawmidi components.  The oops given occurred when pmidi was invoked as:
> > > >   pmidi -p 64:0
> > > > where "64:0" was the port corresponding to the ens1370's external midi
> > > > interface.
> > > > 
> > > > ALSA 0.9.2 gives no trouble at all.
> > > > 
> > > > The soundcard in use is an Ensoniq AudioPCI (ens1370).
> > > > 
> > > > Does anyone have any ideas here?
> > > 
> > > does this still happen on the cvs version?
> > 
> > The current CVS version is worse.  I grabbed a version at around 0900
> > UT+0930 today (Wed 14 May).  I have just compiled this and loaded it.  When 
> >   pmidi -l
> > or
> >   pmidi -p 64:0
> > is run, we now get an error about being unable to open the sequencer.  Then
> > when 
> >   ls /proc/asound
> > is executed the kernel oopses.  It's not a hard lock - the machine keeps
> > going - but it's an oops non-the-less which clearly shouldn't happen.  It
> > seems that there is something strange lurking in the sequencer.  The decoded
> > oops is reproduced below.
> 
> yep, there is a bug in the recent cvs version.
> right now i fixed it and committed.  please update your tree again.

I grabbed an update at 1700 UT+0930 on 15 Mat 2003.  The kernel oops when
accessing /proc/asound/ is gone now.  However, there are still major
problems with this release:
 1) trying to access any of the pseudo files under /proc/asound results
    in "no such device" errors.
 2) using
      pmidi -l
    or
      pmidi -p 64:0
    still results in the "cannot open sequencer" error message
 3) attempting to play a wav file using wavplay via the OSS emulation layer
    results in a kernel oops and a hard lockup.  I didn't have time to copy
    the oops down and decode it last night - sorry.

So I still can't test whether the original problem with the sequencer is
fixed.  Since audio playing is broken, my guess is that the sequencer
problem still exists, but until things start behaving again I can't test
that.

Regards
  jonathan
-- 
* Jonathan Woithe    jwoithe@physics.adelaide.edu.au                        *
*                    http://www.physics.adelaide.edu.au/~jwoithe            *
***-----------------------------------------------------------------------***
** "Time is an illusion; lunchtime doubly so"                              **
*  "...you wouldn't recognize a subtle plan if it painted itself purple and *
*   danced naked on a harpsichord singing 'subtle plans are here again'"    *


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: ALSA 0.9.3a sequencer/rawmidi oops

[Takashi Iwai]

At Fri, 16 May 2003 08:48:49 +0930 (CST),
Jonathan Woithe wrote:
> 
> > > > > Over the weekend I thought I'd give ALSA 0.9.3a a go.  For the most part it
> > > > > worked fine.  However, there seems to be a bug in the sequencer or rawmidi
> > > > > components.
> > > > > 
> > > > > If any application connects to a sequencer port, a oops results and the
> > > > > machine is locked solid.  An example decoded oops is given at the end of
> > > > > this email.  Initially I was testing using jazz++ 4.1.3 and OSS emulation,
> > > > > but the oops occurs if pmidi is used.  Because pmidi is a native ALSA app,
> > > > > it tends to suggest the problem is within the sequencer and/or MPU401
> > > > > rawmidi components.  The oops given occurred when pmidi was invoked as:
> > > > >   pmidi -p 64:0
> > > > > where "64:0" was the port corresponding to the ens1370's external midi
> > > > > interface.
> > > > > 
> > > > > ALSA 0.9.2 gives no trouble at all.
> > > > > 
> > > > > The soundcard in use is an Ensoniq AudioPCI (ens1370).
> > > > > 
> > > > > Does anyone have any ideas here?
> > > > 
> > > > does this still happen on the cvs version?
> > > 
> > > The current CVS version is worse.  I grabbed a version at around 0900
> > > UT+0930 today (Wed 14 May).  I have just compiled this and loaded it.  When 
> > >   pmidi -l
> > > or
> > >   pmidi -p 64:0
> > > is run, we now get an error about being unable to open the sequencer.  Then
> > > when 
> > >   ls /proc/asound
> > > is executed the kernel oopses.  It's not a hard lock - the machine keeps
> > > going - but it's an oops non-the-less which clearly shouldn't happen.  It
> > > seems that there is something strange lurking in the sequencer.  The decoded
> > > oops is reproduced below.
> > 
> > yep, there is a bug in the recent cvs version.
> > right now i fixed it and committed.  please update your tree again.
> 
> I grabbed an update at 1700 UT+0930 on 15 Mat 2003.  The kernel oops when
> accessing /proc/asound/ is gone now.  However, there are still major
> problems with this release:
>  1) trying to access any of the pseudo files under /proc/asound results
>     in "no such device" errors.

hmm, i saw this phenomenon once but after rebuilding the latest
drivers it doesn't appear any more.

/proc/asound/dev is no longer created with the latest cvs version.
if you used symlink /dev/snd -> /proc/asound/dev, you'll need to run
snddevices script once.


Takashi


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: ALSA 0.9.3a sequencer/rawmidi oops

[Jonathan Woithe]

Hi takashi

> > > > > > Over the weekend I thought I'd give ALSA 0.9.3a a go.  For the most part it
> > > > > > worked fine.  However, there seems to be a bug in the sequencer or rawmidi
> > > > > > components.
> > > > > > 
> > > > > > If any application connects to a sequencer port, a oops results and the
> > > > > > machine is locked solid. ... ALSA 0.9.2 gives no trouble at all.
> > > > > > 
> > > > > > The soundcard in use is an Ensoniq AudioPCI (ens1370).
> > > > > > 
> > > > > > Does anyone have any ideas here?
> > > > > 
> > > > > does this still happen on the cvs version?
> > > > 
> > > > The current CVS version is worse.  I grabbed a version at around 0900
> > > > UT+0930 today (Wed 14 May).  I have just compiled this and loaded it.  When 
> > > >   pmidi -l
> > > > or
> > > >   pmidi -p 64:0
> > > > is run, we now get an error about being unable to open the sequencer.  Then
> > > > when 
> > > >   ls /proc/asound
> > > > is executed the kernel oopses.  It's not a hard lock - the machine keeps
> > > > going - but it's an oops non-the-less which clearly shouldn't happen.  It
> > > > seems that there is something strange lurking in the sequencer.  The decoded
> > > > oops is reproduced below.
> > > 
> > > yep, there is a bug in the recent cvs version.
> > > right now i fixed it and committed.  please update your tree again.
> > 
> > I grabbed an update at 1700 UT+0930 on 15 Mat 2003.  The kernel oops when
> > accessing /proc/asound/ is gone now.  However, there are still major
> > problems with this release:
> >  1) trying to access any of the pseudo files under /proc/asound results
> >     in "no such device" errors.
> 
> hmm, i saw this phenomenon once but after rebuilding the latest
> drivers it doesn't appear any more.

Ok.  I have some more information which I'm hoping will help us track this
problem down.

Firstly, I have grabbed a CVS snapshot at around 1500 UT+0930 on 18 May
2003.  I have repeated all my tests with this snapshot.  The alsa-driver
was configured using
  ./configure --with-sequencer=yes --with-oss=yes \
     --with-kernel=/home/audio/src/linux-2.4.20 \
     --with-cards=mpu401,ens1370,dt019x

The tests were conducted with the ens1370 card - the dt019x components were
not loaded.  As can be seen, this is under kernel 2.4.20.

The machine loaded the alsa modules with no errors.

I have run the snddevices script to create the static alsa device nodes.

Doing an "ls" of /proc/asound does not produce the oops which plagued
earlier CVS versions.  In fact, that particular bug was also in 0.9.3a
release.  However, attempting to "cat" *any* file under the /proc/asound
hierarchy still produced "no such device".  The directory structure is
created fine and can be navigated with no trouble.  It's just that it's
impossible to view the contents of any of the pseudo-files displayed
therein.  In other words, simply compiling the latest version of the driver
has not cured this problem for me - there's obviously some other lingering
problem.

This latest snapshot has cured the kernel oops I reported earlier regarding
pmidi.  I have not yet checked to see if pmidi can actually output anything,
but not having "pmidi -l" oops is a good start.

However, there seems to be serious problems with the pcm components of the
current CVS version.  Using "wavplay" through the ALSA OSS emulation layer
produces an oops and locks the machine solid.  The oops is in __wake_up().
Using the native aplay is slightly better - it still oopses, but at least
the machine isn't locked solid.  The oops is still in __wake_up().  Both
decoded oopses are included at the end of this email.

Now, the interesting thing about the pcm oops is that it occurs in
__wake_up().  This is actually the same endpoint of the original oops I
reported with the sequencer.  This might have since been fixed (as mentioned
above), so it's likely that whatever fix was applied to the sequencer
component is also needed to the pcm interface.

So to summarise findings regarding the CVS ALSA version under kernel 2.4.20:
 1) no files under /proc/asound can be displayed: they all give "no such
    device errors".
 2) the oops which used to be triggered by "pmidi -l" may have been fixed.
 3) using wavplay (via ALSA OSS emulation) or aplay (native ALSA app) causes
    a kernel oops in __wake_up() (decoded oopses at end of email).  It's
    possible that the pcm component of ALSA needs the same fix which may
    have been applied to the sequencer component to fix the oops I reported
    at the start of this thread.

Regards
  jonathan

=============================
Oops from wavplay invocation:
ksymoops 2.4.8 on i586 2.4.20.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.20 -o /tmp/alsa-20030518-cvs/ (specified)
     -m /boot/System.map (specified)

Unable to handle kernel NULL pointer dereference at virtual address 00000000
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c011373b>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010097
eax: c12ddcac   ebx: c12ddca8   ecx: 00000000   edx: 00000003
esi: 00000004   edi: 00000001   ebp: c02cdecc   esp: c02cfeb4
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 0, stackpage=c02cf000)
Stack: 00000000 00000004 c12c8b60 cf2ddcac 00000082 00000003 cc98eaec cc9847d6
       c12c8b60 00000004 cc98eaec 00000000 c12ddc00 c12c8b60 cc98480d cc98eaec
       c12c8b60 00000004 ffffffe0 cc984a04 cc98eaec c12c8b60 00000004 cc98be7b
Call Trace:    [<cc98eaec>] [<cc9847d8>] [<cc98eaec>] [<cc98480d>] [<cc98eaec>]
  [<cc984a04>] [<cc98eaec>] [<cc98be7b>] [<ccb93679>] [<cc98ae9c>] [<cc9b138b>]
  [<c0109b4d>] [<c0109cbe>] [<c0106e10>] [<c010be78>] [<c0106e10>] [<c0106e33>]
  [<c0106e97>] [<c0105000>] [<c0105027>]
Code: 8b 01 85 45 fc 74 4e 31 c0 9c 5e fa c7 01 00 00 00 00 83 79


>>EIP; c011373b <__wake_up+2b/98>   <=====

>>eax; c12ddcac <_end+fc8228/c65c5dc>
>>ebx; c12ddca8 <_end+fc8224/c65c5dc>
>>ebp; c02cdecc <_edata+568/69c>
>>esp; c02cfeb4 <init_task_union+1eb4/2000>

Trace; cc98eaec <[snd-pcm]snd_pcm_action_stop+0/c>
Trace; cc9847d8 <[snd-pcm]snd_pcm_action_single+38/40>
Trace; cc98eaec <[snd-pcm]snd_pcm_action_stop+0/c>
Trace; cc98480d <[snd-pcm]snd_pcm_action+2d/30>
Trace; cc98eaec <[snd-pcm]snd_pcm_action_stop+0/c>
Trace; cc984a04 <[snd-pcm]snd_pcm_stop+14/20>
Trace; cc98eaec <[snd-pcm]snd_pcm_action_stop+0/c>
Trace; cc98be7b <[snd-pcm]snd_pcm_update_hw_ptr_interrupt+13b/1d0>
Trace; ccb93679 <[usb-uhci]rh_int_timer_do+3d/44>
Trace; cc98ae9c <[snd-pcm]snd_pcm_period_elapsed+6c/c0>
Trace; cc9b138b <[snd-ens1370]snd_audiopci_interrupt+9b/b0>
Trace; c0109b4d <handle_IRQ_event+31/5c>
Trace; c0109cbe <do_IRQ+72/b4>
Trace; c0106e10 <default_idle+0/28>
Trace; c010be78 <call_do_IRQ+5/d>
Trace; c0106e10 <default_idle+0/28>
Trace; c0106e33 <default_idle+23/28>
Trace; c0106e97 <cpu_idle+3f/54>
Trace; c0105000 <_stext+0/0>
Trace; c0105027 <rest_init+27/28>

Code;  c011373b <__wake_up+2b/98>
00000000 <_EIP>:
Code;  c011373b <__wake_up+2b/98>   <=====
   0:   8b 01                     mov    (%ecx),%eax   <=====
Code;  c011373d <__wake_up+2d/98>
   2:   85 45 fc                  test   %eax,0xfffffffc(%ebp)
Code;  c0113740 <__wake_up+30/98>
   5:   74 4e                     je     55 <_EIP+0x55>
Code;  c0113742 <__wake_up+32/98>
   7:   31 c0                     xor    %eax,%eax
Code;  c0113744 <__wake_up+34/98>
   9:   9c                        pushf
Code;  c0113745 <__wake_up+35/98>
   a:   5e                        pop    %esi
Code;  c0113746 <__wake_up+36/98>
   b:   fa                        cli
Code;  c0113747 <__wake_up+37/98>
   c:   c7 01 00 00 00 00         movl   $0x0,(%ecx)
Code;  c011374d <__wake_up+3d/98>
  12:   83 79 00 00               cmpl   $0x0,0x0(%ecx)

=============================
Oops occuring after aplay:
ksymoops 2.4.8 on i586 2.4.20.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.20 -o /tmp/alsa-20030518-cvs/ (specified)
     -m /boot/System.map (specified)

Unable to handle kernel NULL pointer dereference at virtual address 00000000
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c011373b>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010097
eax: c9c66388   ebx: c9c66384   ecx: 00000000   edx: 00000003
esi: c7ad6460   edi: 00000001   ebp: c7439f44   esp: c7439f2c
ds: 0018   es: 0018   ss: 0018
Process aplay (pid: 426, stackpage=c7439000)
Stack: c9b5c860 c7ad6460 c9c66200 c9c66388 00000286 00000003 c7adb4e0 cc97625d
       c7ad6460 00000019 cc9776e4 c9c66200 c7ad6460 c9c6635c c7ad6460 c9b05c20
       c12162e0 c8a2ec20 c0131814 c9b05c20 c7ad6460 c7ad6460 00000000 c799f080
Call Trace:    [<cc97625d>] [<cc9776e4>] [<c0131814>] [<c01308a5>] [<c01308f3>]
  [<c0108813>]
Code: 8b 01 85 45 fc 74 4e 31 c0 9c 5e fa c7 01 00 00 00 00 83 79


>>EIP; c011373b <__wake_up+2b/98>   <=====

>>eax; c9c66388 <_end+9950904/c65c5dc>
>>ebx; c9c66384 <_end+9950900/c65c5dc>
>>esi; c7ad6460 <_end+77c09dc/c65c5dc>
>>ebp; c7439f44 <_end+71244c0/c65c5dc>
>>esp; c7439f2c <_end+71244a8/c65c5dc>

Trace; cc97625d <[snd]snd_card_file_remove+6d/90>
Trace; cc9776e4 <[snd]snd_ctl_release+d4/f0>
Trace; c0131814 <fput+4c/e0>
Trace; c01308a5 <filp_close+59/64>
Trace; c01308f3 <sys_close+43/54>
Trace; c0108813 <system_call+33/40>

Code;  c011373b <__wake_up+2b/98>
00000000 <_EIP>:
Code;  c011373b <__wake_up+2b/98>   <=====
   0:   8b 01                     mov    (%ecx),%eax   <=====
Code;  c011373d <__wake_up+2d/98>
   2:   85 45 fc                  test   %eax,0xfffffffc(%ebp)
Code;  c0113740 <__wake_up+30/98>
   5:   74 4e                     je     55 <_EIP+0x55>
Code;  c0113742 <__wake_up+32/98>
   7:   31 c0                     xor    %eax,%eax
Code;  c0113744 <__wake_up+34/98>
   9:   9c                        pushf
Code;  c0113745 <__wake_up+35/98>
   a:   5e                        pop    %esi
Code;  c0113746 <__wake_up+36/98>
   b:   fa                        cli
Code;  c0113747 <__wake_up+37/98>
   c:   c7 01 00 00 00 00         movl   $0x0,(%ecx)
Code;  c011374d <__wake_up+3d/98>
  12:   83 79 00 00               cmpl   $0x0,0x0(%ecx)

-- 
* Jonathan Woithe    jwoithe@physics.adelaide.edu.au                        *
*                    http://www.physics.adelaide.edu.au/~jwoithe            *
***-----------------------------------------------------------------------***
** "Time is an illusion; lunchtime doubly so"                              **
*  "...you wouldn't recognize a subtle plan if it painted itself purple and *
*   danced naked on a harpsichord singing 'subtle plans are here again'"    *


-------------------------------------------------------
This SF.net email is sponsored by: If flattening out C++ or Java
code to make your application fit in a relational database is painful, 
don't do it! Check out ObjectStore. Now part of Progress Software.
http://www.objectstore.net/sourceforge

Re: ALSA 0.9.3a sequencer/rawmidi oops

[Jaroslav Kysela]

On Sun, 18 May 2003, Jonathan Woithe wrote:

> Hi takashi
> 
> > > > > > > Over the weekend I thought I'd give ALSA 0.9.3a a go.  For the most part it
> > > > > > > worked fine.  However, there seems to be a bug in the sequencer or rawmidi
> > > > > > > components.
> > > > > > > 
> > > > > > > If any application connects to a sequencer port, a oops results and the
> > > > > > > machine is locked solid. ... ALSA 0.9.2 gives no trouble at all.
> > > > > > > 
> > > > > > > The soundcard in use is an Ensoniq AudioPCI (ens1370).
> > > > > > > 
> > > > > > > Does anyone have any ideas here?
> > > > > > 
> > > > > > does this still happen on the cvs version?
> > > > > 
> > > > > The current CVS version is worse.  I grabbed a version at around 0900
> > > > > UT+0930 today (Wed 14 May).  I have just compiled this and loaded it.  When 
> > > > >   pmidi -l
> > > > > or
> > > > >   pmidi -p 64:0
> > > > > is run, we now get an error about being unable to open the sequencer.  Then
> > > > > when 
> > > > >   ls /proc/asound
> > > > > is executed the kernel oopses.  It's not a hard lock - the machine keeps
> > > > > going - but it's an oops non-the-less which clearly shouldn't happen.  It
> > > > > seems that there is something strange lurking in the sequencer.  The decoded
> > > > > oops is reproduced below.
> > > > 
> > > > yep, there is a bug in the recent cvs version.
> > > > right now i fixed it and committed.  please update your tree again.
> > > 
> > > I grabbed an update at 1700 UT+0930 on 15 Mat 2003.  The kernel oops when
> > > accessing /proc/asound/ is gone now.  However, there are still major
> > > problems with this release:
> > >  1) trying to access any of the pseudo files under /proc/asound results
> > >     in "no such device" errors.
> > 
> > hmm, i saw this phenomenon once but after rebuilding the latest
> > drivers it doesn't appear any more.
> 
> Ok.  I have some more information which I'm hoping will help us track this
> problem down.
> 
> Firstly, I have grabbed a CVS snapshot at around 1500 UT+0930 on 18 May
> 2003.  I have repeated all my tests with this snapshot.  The alsa-driver
> was configured using
>   ./configure --with-sequencer=yes --with-oss=yes \
>      --with-kernel=/home/audio/src/linux-2.4.20 \
>      --with-cards=mpu401,ens1370,dt019x
> 
> The tests were conducted with the ens1370 card - the dt019x components were
> not loaded.  As can be seen, this is under kernel 2.4.20.
> 
> The machine loaded the alsa modules with no errors.
> 
> I have run the snddevices script to create the static alsa device nodes.
> 
> Doing an "ls" of /proc/asound does not produce the oops which plagued
> earlier CVS versions.  In fact, that particular bug was also in 0.9.3a
> release.  However, attempting to "cat" *any* file under the /proc/asound
> hierarchy still produced "no such device".  The directory structure is
> created fine and can be navigated with no trouble.  It's just that it's
> impossible to view the contents of any of the pseudo-files displayed
> therein.  In other words, simply compiling the latest version of the driver
> has not cured this problem for me - there's obviously some other lingering
> problem.
> 
> This latest snapshot has cured the kernel oops I reported earlier regarding
> pmidi.  I have not yet checked to see if pmidi can actually output anything,
> but not having "pmidi -l" oops is a good start.
> 
> However, there seems to be serious problems with the pcm components of the
> current CVS version.  Using "wavplay" through the ALSA OSS emulation layer
> produces an oops and locks the machine solid.  The oops is in __wake_up().
> Using the native aplay is slightly better - it still oopses, but at least
> the machine isn't locked solid.  The oops is still in __wake_up().  Both
> decoded oopses are included at the end of this email.
> 
> Now, the interesting thing about the pcm oops is that it occurs in
> __wake_up().  This is actually the same endpoint of the original oops I
> reported with the sequencer.  This might have since been fixed (as mentioned
> above), so it's likely that whatever fix was applied to the sequencer
> component is also needed to the pcm interface.

Do you use same compiler for kernel sources and for ALSA driver? It seems 
like incompatible stack problems (GCC 2.9 and 3.x is incompatible).

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.net email is sponsored by: If flattening out C++ or Java
code to make your application fit in a relational database is painful, 
don't do it! Check out ObjectStore. Now part of Progress Software.
http://www.objectstore.net/sourceforge

Re: ALSA 0.9.3a sequencer/rawmidi oops

[Jonathan Woithe]

> > > > I grabbed an update at 1700 UT+0930 on 15 Mat 2003.  The kernel oops when
> > > > accessing /proc/asound/ is gone now.  However, there are still major
> > > > problems with this release:
> > > >  1) trying to access any of the pseudo files under /proc/asound results
> > > >     in "no such device" errors.
> > > 
> > > hmm, i saw this phenomenon once but after rebuilding the latest
> > > drivers it doesn't appear any more.
> > 
> > Ok.  I have some more information which I'm hoping will help us track this
> > problem down.
> > 
> > Firstly, I have grabbed a CVS snapshot at around 1500 UT+0930 on 18 May
> > 2003.  I have repeated all my tests with this snapshot.  The alsa-driver
> > was configured using
> >   ./configure --with-sequencer=yes --with-oss=yes \
> >      --with-kernel=/home/audio/src/linux-2.4.20 \
> >      --with-cards=mpu401,ens1370,dt019x
> > 
> > The tests were conducted with the ens1370 card - the dt019x components were
> > not loaded.  As can be seen, this is under kernel 2.4.20.
> > 
> > The machine loaded the alsa modules with no errors.
> > 
> > I have run the snddevices script to create the static alsa device nodes.
> > 
> > Doing an "ls" of /proc/asound does not produce the oops which plagued
> > earlier CVS versions.  In fact, that particular bug was also in 0.9.3a
> > release.  However, attempting to "cat" *any* file under the /proc/asound
> > hierarchy still produced "no such device".  The directory structure is
> > created fine and can be navigated with no trouble.  It's just that it's
> > impossible to view the contents of any of the pseudo-files displayed
> > therein.  In other words, simply compiling the latest version of the driver
> > has not cured this problem for me - there's obviously some other lingering
> > problem.
> > 
> > This latest snapshot has cured the kernel oops I reported earlier regarding
> > pmidi.  I have not yet checked to see if pmidi can actually output anything,
> > but not having "pmidi -l" oops is a good start.
> > 
> > However, there seems to be serious problems with the pcm components of the
> > current CVS version.  Using "wavplay" through the ALSA OSS emulation layer
> > produces an oops and locks the machine solid.  The oops is in __wake_up().
> > Using the native aplay is slightly better - it still oopses, but at least
> > the machine isn't locked solid.  The oops is still in __wake_up().  Both
> > decoded oopses are included at the end of this email.
> > 
> > Now, the interesting thing about the pcm oops is that it occurs in
> > __wake_up().  This is actually the same endpoint of the original oops I
> > reported with the sequencer.  This might have since been fixed (as mentioned
> > above), so it's likely that whatever fix was applied to the sequencer
> > component is also needed to the pcm interface.
> 
> Do you use same compiler for kernel sources and for ALSA driver? It seems 
> like incompatible stack problems (GCC 2.9 and 3.x is incompatible).

Ah.  Up until last night I thought I did.  However, when I double-checked I
discovered that the running kernel was indeed compiled with a pre-upgrade
gcc (2.95.x actually) whereas ALSA was compiled with the current gcc
(v3.2.2).  Obviously I never got around to recompiling even though I thought
I did.  After recompiling the kernel with gcc 3.2.2 the oopses disappeared
and things started working again.

Thanks for the gentle reminder. :)  Case closed.

Regards
  jonathan
-- 
* Jonathan Woithe    jwoithe@physics.adelaide.edu.au                        *
*                    http://www.physics.adelaide.edu.au/~jwoithe            *
***-----------------------------------------------------------------------***
** "Time is an illusion; lunchtime doubly so"                              **
*  "...you wouldn't recognize a subtle plan if it painted itself purple and *
*   danced naked on a harpsichord singing 'subtle plans are here again'"    *


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: ALSA 0.9.3a sequencer/rawmidi oops

[Jonathan Woithe]

Takasi

Another bit of information to add to my previous email.  With the latest CVS
snapshot, there *is* still an oops associated with the sequencer, so that
hasn't changed all that much.  In short,
  pmidi -l
now does work and correctly describes available MIDI ports.  However, doing
  pmidi -p 64:0
still oopses and locks the machine solid, as before.

Therefore, it seems that the oops which was reported at the start of this
thread (which was under 0.9.3a) has *not* been subsequently fixed.  The oops
endpoint is still in __wake_up() as per the original report.

The last ALSA version I have which does work is 0.9.2 release.  I'm
wondering whether these problems are associated with the integration of 2.5
things which I believe occurred between 0.9.2 and 0.9.3a.

Regards
  jonathan
-- 
* Jonathan Woithe    jwoithe@physics.adelaide.edu.au                        *
*                    http://www.physics.adelaide.edu.au/~jwoithe            *
***-----------------------------------------------------------------------***
** "Time is an illusion; lunchtime doubly so"                              **
*  "...you wouldn't recognize a subtle plan if it painted itself purple and *
*   danced naked on a harpsichord singing 'subtle plans are here again'"    *


-------------------------------------------------------
This SF.net email is sponsored by: If flattening out C++ or Java
code to make your application fit in a relational database is painful, 
don't do it! Check out ObjectStore. Now part of Progress Software.
http://www.objectstore.net/sourceforge