Re: MSI K7D-L sound problems

Johan Mson Lindman wrote:
> On Monday 26 September 2005 04:07, you wrote:
> Well auich(4) doesn't seem to work very well with GENERIC.MP, there's a PR 
> about this (although the PR is for amd64), 
> http://cvs.openbsd.org/cgi-bin/query-pr-wrapper?full=yes&numbers=4453.
> Anyway I happen to have a similar problem but on amd64 and my solution was to 
> disable auich in kernel config, reboot and then the emu(4) will work just 
> fine for me (see dmesg below).
> Please note, only stock GENERIC or GENERIC.MP kernels are supported.
> 
> 
> Regards
> Johan M:son
Neither auich or emu work on this board, with both enabled or
one disabled (i.e. emu not present auich wont work or auich disabled
in bios and emu still wont work) and every other hardware incantation I could
think of moving pci slots etc (doesn't matter the bios configuration remains
unchanged). This has been with both GENERIC and GENERIC.MP for 3.6, 3.7, and
kernels built everyday this week, stock or built here they still dont work
(incidentally that pr you mentioned was issued with a dmesg not from a stock kernel)
I have *almost* abandoned hope of sound ever working on this system period
and vowed to never ever ever buy another piece of MSI garbage again.

I have compiled with AUDIO_DEBUG and AUICH_DEBUG which fortunately I can compare
to another nForce board with auich (single processor only) and its a strange one,
cat foobar.au > /dev/audio starts the same on both machines, auich_trigger_output()
gets called and does its thing, the interrupt acknowledging the first block is
received auich_intr gets called, calls audio_pint which doesn't wake up the process
that called write because the used count is still greater than the low water mark
which is fine, this little process should repeat untill that condition occurs,
however no further interrupts are received by auich_intr signifying further blocks
processed.

Anyway thats what I have figured out so far and I don't see any solution since
the code is behaving the way it should compared to the working sound on the other
box it might be the chip doing something funny I honestly wonder if sound has
*ever* worked with open or net BSD and the AMD-768 (I came across someone describing
similar problems as my own on Net but cant find the link right now) If someone on the
list has one of these boxes with the on-board sound would care to share the state
of sound on their board I would be glad to hear.

In any case I am now rambling thank you very much for the suggestions,
GWK
(incidentally if anyone is using a Tyan Thunder K8WE board whats the experience
been like?)