fatal oops in current CVS confirmed

fatal oops in current CVS confirmed

[Paul Davis]

yesterday, i backed up to gcc 2.95.3, rebuilt kernel 2.4.20 and
current ALSA CVS. i continued to get the same oops/lockups i have seen when:

	* using the trident module with arecord
	* loading the wavefront module and/or

i infrequently get an oops, and when i do, it points at either:

   in the trident case
	* smp-related code 
   in the wavefront case
	* code within the module

i can't identify code within the module because its not possible to
finish loading the module and thus get the symbol addresses. i believe
it to be in the module because when i prevent the wavefront module
from loading (normally the first module to load), the addresses
correspond to things in the trident module (which becomes my first
loaded module instead).
	
so, i reverted to my "old" ALSA CVS tree, which is quite old at this
point. i recompiled it all (gcc 2.95.3), and of course, it works
fine. for me, this conclusively points to a problem in ALSA CVS that
is not related to kernel version or compiler version, but is just a
plain and simple bug. the problem is, what is it? the diffs between my
old tree and the current CVS tree are vast, and the few oops traces i
have are unrevealing in that they do not have any ALSA related calls
in them. the only way i can see for us to track this down (unless
jaroslav or takashi have a sudden inspiration) is for me to do a
binary search on CVS using a date specification until i find the first
date that causes the oops.

any other ideas?

i would strongly advise against releasing 0.9.0 final when its so
trivial to crash a system with it. and incidentally, its precisely
this kind of waste of 3 days that explains why i haven't updated from
ALSA CVS in a long time :)

--p



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: fatal oops in current CVS confirmed

[Jaroslav Kysela]

On Fri, 7 Mar 2003, Paul Davis wrote:

>    in the trident case
> 	* smp-related code 

Fixed. The problem was in Takashi's Scatter-Gather DMA update. The 
driver package 0.9.0rc8d should fix this problem.

>    in the wavefront case
> 	* code within the module

I cannot fix above problem, until I know the place of this bug. The best 
way is to determine this problem is commenting/uncommenting of the 
initialization code.

> i would strongly advise against releasing 0.9.0 final when its so
> trivial to crash a system with it. and incidentally, its precisely
> this kind of waste of 3 days that explains why i haven't updated from
> ALSA CVS in a long time :)

Because it appears that all your reported problems are "local" (driver 
specific), I don't think that it's a showstoper for the final release.

						Jaroslav

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



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: fatal oops in current CVS confirmed

[Takashi Iwai]

At Mon, 10 Mar 2003 01:06:59 +0100 (CET),
Jaroslav wrote:
> 
> On Fri, 7 Mar 2003, Paul Davis wrote:
> 
> >    in the trident case
> > 	* smp-related code 
> 
> Fixed. The problem was in Takashi's Scatter-Gather DMA update. The 
> driver package 0.9.0rc8d should fix this problem.
 
oops, sorry.  the bug had lived more than two months, so i wonder why 
this wasn't reported at all... 

> >    in the wavefront case
> > 	* code within the module
> 
> I cannot fix above problem, until I know the place of this bug. The best 
> way is to determine this problem is commenting/uncommenting of the 
> initialization code.
 
... or a traditional way; put many printk()'s in the init path and
check at which point stalls.

> > i would strongly advise against releasing 0.9.0 final when its so
> > trivial to crash a system with it. and incidentally, its precisely
> > this kind of waste of 3 days that explains why i haven't updated from
> > ALSA CVS in a long time :)
> 
> Because it appears that all your reported problems are "local" (driver 
> specific), I don't think that it's a showstoper for the final release.

yes, and please remember that 0.9.0-final is not the final for ALSA.
we'll be able to release the fixed version ASAP.

i guess you won't expect that, for example, the 2.6.0 kernel is
so perfect that all components work without any bugs :)


ciao,

Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: fatal oops in current CVS confirmed

[Paul Davis]

>oops, sorry.  the bug had lived more than two months, so i wonder why 
>this wasn't reported at all... 

  [ ... ]

>yes, and please remember that 0.9.0-final is not the final for ALSA.
>we'll be able to release the fixed version ASAP.
>
>i guess you won't expect that, for example, the 2.6.0 kernel is
>so perfect that all components work without any bugs :)

oh sure. i mean, i've known for more than 1 year that the PCM output
on the cs4231 driver doesn't work anymore (at least not for the
tropez+), but that's not going to get fixed any time soon, i
suspect. someone has to get 0.5 installed, add some code to print all
the registers, and then figure out why 0.9 doesn't do the right thing.

i wonder who that will be :)


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: fatal oops in current CVS confirmed

[Takashi Iwai]

At Mon, 10 Mar 2003 09:17:08 -0500,
Paul Davis wrote:
> 
> >oops, sorry.  the bug had lived more than two months, so i wonder why 
> >this wasn't reported at all... 
> 
>   [ ... ]
> 
> >yes, and please remember that 0.9.0-final is not the final for ALSA.
> >we'll be able to release the fixed version ASAP.
> >
> >i guess you won't expect that, for example, the 2.6.0 kernel is
> >so perfect that all components work without any bugs :)
> 
> oh sure. i mean, i've known for more than 1 year that the PCM output
> on the cs4231 driver doesn't work anymore (at least not for the
> tropez+), but that's not going to get fixed any time soon, i
> suspect. someone has to get 0.5 installed, add some code to print all
> the registers, and then figure out why 0.9 doesn't do the right thing.
> 
> i wonder who that will be :)

i wonder, too :)

but this can't be the reason to postpone the 0.9.0-final tarball.
not all people don't like cvs or rc/beta versions to try, and such a
situation is surely one of the reason to have made such a bug hidden
for long time more than one year.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf