[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

ALSA and Sounds on the Alphas



Okay.  I did some experimentation on my box this am.  What follows is what 
happens and my interpretation of it.  First some general stuff:

patch -- referring to the one I put together that enables the alternative 
interupt detection code -- it, and various recompiled stock Debian kernels 
with it applied are available at "whitehead.apmaths.uwo.ca/~tyson".

"ctrl+c" -- as first discovered up by Bob or Michael, under some 
configurations, interupting "aplay" results in the kernel barfing a bunch of 
messages such as:
----------------------------------------------------------------
bad page state in process 'aplay'
page:fffffc00002a02b8 flags:0x0000000000000414 mapping:0000000000000000 
mapcount:0 count:0
Trying to fix it up, but a reboot is needed
Backtrace:
fffffc0004977c98 0000000000000000 0000000000000000 0000000000000000
       fffffc0001056e34 0000000000000400 fffffc00002a02b8 fffffc00002a02b8
       fffffc00014bfed8 0000020000026000 fffffc0001057250 0000000000000000
       fffffc00002a02b8 000000000000001e fffffc000105a3f0 fffffc00014bfed8
       fffffc00002a02b8 0000000000000000 fffffc0005d24088 0000020000026000
       fffffc0001068dbc fffffc00002a02b8 0000000000063309 0000020000022000
Trace:
[<fffffc0001056e34>] free_pages_check+0x64/0x9c
[<fffffc0001057250>] free_hot_cold_page+0x54/0xf0
[<fffffc000105a3f0>] __page_cache_release+0x80/0xa0
[<fffffc0001068dbc>] free_page_and_swap_cache+0x28/0x40
[<fffffc0001060fa0>] unmap_vmas+0x3d4/0x548
[<fffffc00010642a8>] unmap_region+0xb0/0x124
[<fffffc000106461c>] do_munmap+0x1b8/0x260
[<fffffc00010649a4>] sys_munmap+0x5c/0x88
[<fffffc0001011354>] entSys+0xa4/0xc0
----------------------------------------------------------------


With that out of the way, here are the results:

Kernel 2.6.14:
  "snd-es18xx isa-pnp=0"
    stock -- loads, but interupts aren't recognized and playback loops
    patched -- loads, and works fine
  "snd-sb8 port=0x220 irq=5 dma8=1"
    stock -- loads, and works fine

Kernel 2.6.16
  "snd-es18xx isa-pnp=0"
    stock -- loads, but interupts aren't recognized and playback loops
    patched -- haven't recompiled yet (but others report "ctrl+c" problems)
  "snd-sb8 port=0x220 irq=5 dma8=1"
    stock -- loads, and works, but has "ctrl+c" problems


There are three things that stand out here to me on this:

1 --  Something broke between kernels 2.6.14 and 2.6.16, and it is resulting 
in pages being left in an inconsistent state if alsa playback is not properly 
deinitialized (probably something to do with driver mmaping)

2 -- The stock snd-es18xx is not able to properly detect interupts

3 -- The snd-sb8 driver works fine

This is good news.  I didn't even know the snd-sb8 driver existed until a 
couple of days ago when I went looking.  Now as soon as some kernel hackers 
figure out what broke between 2.6.14 and 2.6.16 and is causing one, I won't 
have to custom compile any more kernels!  : )

The one downside to the more generic snd-sb8 driver appears to be that it 
cannot reconfigure which irq it runs on (unlike the snd-es18xx driver which 
seems to be able to reconfigure various aspects of the card in software).

Later!  -T

PS#1:  By udev not working on earlier kernels, I wasn't referring to unaligned 
traps, I meant that it really does not work (due to the switch for execing 
the user land interace to talking over net sockets).

PS#2:  I resolved the dependency requires/conflict problem in the 2.6.14 
kernel package on my box.  Unfortunately, the latest version of udev now 
appears to require 2.5.15 or higher (which is why my box didn't come back up 
from my last remote reboot) -- I'll compile up some 2.6.16 packages.

-- 
 Tyson Whitehead  (-twhitehe at uwo.ca -- WSC-)
 Computer Engineer                          Dept. of Applied Mathematics,
 Graduate Student- Applied Mathematics      University of Western Ontario,
 GnuPG Key ID# 0xF7666BFF                   London, Ontario, Canada

Attachment: pgpghNFzFaMaQ.pgp
Description: PGP signature


Reply to: