IMHO this board should get a new BIOS.

Try to boot with pci=noacpi or acpi=off boot option.
If this doesn't help, try buggy_semaphore=1 module option for snd-intel8x0 module.

I tried the noacpi option and it´s still the same.
How can I set the buggy_semaphore options (it´s not available in YaST)?

Did you try acpi=off, too?

You can edit the module option in /etc/modprobe.d/sound file via text editor. 
YaST doesn't support this option (the option was added after the yast feature
freeze).

I tried both acpi=off and setting the buggy_semaphore, but it has no effect

Your device is ALI5455, so buggy_semaphore has no influence.  Sorry for confusion.

But according to the mesasge above, the driver seems to be loaded properly.
Check /proc/asoudn/cards whether you find the driver entry.
If it's there, try "aplay -vv something.wav".  This will show VU meter, so you
see whether the DMA is running.

If the DMA looks running but you get no sound, it's probably the mixer setting
problem.  Start alsamixer, unmute and adjust Master, Headphone and PCM volumes.

If this doesn't help, check the kernel message during you change something on
alsamixer whether any errors/warnings appear.  Then, run "alsactl -f
asound.state store", and attach it.  Also, attach the contents of
/proc/asound/card0/codec97#0/* files, too.

BTW, the "codec timeout" messages may be harmless.  It tries to detect the
secondary codec (most likely a modem codec) and failed.

The entry in /proc/asound/cards is there
When I try to play something I get these messages in the log:

Oct  6 00:15:29 r098088 kernel: ALSA sound/pci/intel8x0.c:670: intel8x0: AC97
codec ready timeout.
Oct  6 00:15:29 r098088 kernel: ALSA sound/pci/ac97/ac97_codec.c:1959: AC'97 1
does not respond - RESET
Oct  6 00:15:29 r098088 kernel: ALSA sound/pci/intel8x0.c:670: intel8x0: AC97
codec ready timeout.
Oct  6 00:15:29 r098088 kernel: ALSA sound/pci/intel8x0.c:670: intel8x0: AC97
codec ready timeout.
Oct  6 00:15:29 r098088 kernel: ALSA sound/pci/ac97/ac97_codec.c:1968: AC'97 1
access is not valid [0xffffffff], removing mixer.
Oct  6 00:15:29 r098088 kernel: ALSA sound/pci/intel8x0.c:2100: Unable to
initialize codec #1

No, the messages above should be _before_ playback.

What about the other things I described above?

the aplay command displays this:
michael@r098088:~> aplay -vv applause.wav
Playing WAVE 'applause.wav' : Signed 16 bit Little Endian, Rate 11025 Hz, Mono
Plug PCM: Rate conversion PCM (48000, sformat=S16_LE)
Its setup is:
stream       : PLAYBACK
access       : RW_INTERLEAVED
format       : S16_LE
subformat    : STD
channels     : 1
rate         : 11025
exact rate   : 11025 (11025/1)
msbits       : 16
buffer_size  : 3763
period_size  : 235
period_time  : 21333
tick_time    : 0
tstamp_mode  : NONE
period_step  : 1
sleep_min    : 0
avail_min    : 235
xfer_align   : 235
start_threshold  : 3760
stop_threshold   : 3763
silence_threshold: 0
silence_size : 0
boundary     : 246611968
Slave: Route conversion PCM (sformat=S16_LE)
Transformation table:
0 <- 0
1 <- 0
Its setup is:
stream       : PLAYBACK
access       : MMAP_INTERLEAVED
format       : S16_LE
subformat    : STD
channels     : 1
rate         : 48000
exact rate   : 48000 (48000/1)
msbits       : 16
buffer_size  : 16384
period_size  : 1024
period_time  : 21333
tick_time    : 0
tstamp_mode  : NONE
period_step  : 1
sleep_min    : 0
avail_min    : 1024
xfer_align   : 1024
start_threshold  : 16384
stop_threshold   : 16384
silence_threshold: 0
silence_size : 0
boundary     : 1073741824
Slave: Direct Stream Mixing PCM

Its setup is:
stream       : PLAYBACK
access       : MMAP_INTERLEAVED
format       : S16_LE
subformat    : STD
channels     : 2
rate         : 48000
exact rate   : 48000 (48000/1)
msbits       : 16
buffer_size  : 16384
period_size  : 1024
period_time  : 21333
tick_time    : 0
tstamp_mode  : NONE
period_step  : 1
sleep_min    : 0
avail_min    : 1024
xfer_align   : 1024
start_threshold  : 16384
stop_threshold   : 16384
silence_threshold: 0
silence_size : 0
boundary     : 1073741824
Hardware PCM card 0 'ALi M5455' device 0 subdevice 0

Its setup is:
stream       : PLAYBACK
access       : MMAP_INTERLEAVED
format       : S16_LE
subformat    : STD
channels     : 2
rate         : 0
exact rate   : nan (0/0)
msbits       : 0
buffer_size  : 16384
period_size  : 0
period_time  : 0
tick_time    : 0
tstamp_mode  : NONE
period_step  : 0
sleep_min    : 0
avail_min    : 0
xfer_align   : 0
start_threshold  : 0
stop_threshold   : 0
silence_threshold: 0
silence_size : 0
boundary     : 1073741824
Max peak (235 samples): 01791 (0x06ff) ##                   5%
Max peak (235 samples): 21248 (0x5300) #############        64%
Max peak (235 samples): 16129 (0x3f01) ##########           49%
Max peak (235 samples): 24575 (0x5fff) ###############      74%
Max peak (235 samples): 16384 (0x4000) ###########          50%
Max peak (235 samples): 18433 (0x4801) ############         56%
Max peak (235 samples): 14080 (0x3700) #########            42%
Max peak (235 samples): 19968 (0x4e00) #############        60%
Max peak (235 samples): 16385 (0x4001) ###########          50%
Max peak (235 samples): 14080 (0x3700) #########            42%
Max peak (235 samples): 16129 (0x3f01) ##########           49%
Max peak (235 samples): 12286 (0x2ffe) ########             37%
Max peak (235 samples): 16128 (0x3f00) ##########           49%
Max peak (235 samples): 12288 (0x3000) ########             37%
Max peak (235 samples): 14592 (0x3900) #########            44%
Max peak (235 samples): 14336 (0x3800) #########            43%

Then it doesn´t do anything more, I´ve to press CTRL-c to kill it. There´s no
sound. Alsamixer seems to be fine. The messages about "removing mixer" are there
after starting up linux.

Created attachment 51609 [details]
ac97#0-0

Created attachment 51610 [details]
/home/michael/Desktop/ac97#0-0+regs

If the VU meter stops, it means the DMA doesn't run.  That is, a wrong IRQ
assignment.  Maybe ACPI.

Changed component to kernel.

Please attach dmesg and acpidmp output.

I attached the output because it would be too much as a comment.

Created attachment 51785 [details]
dmesg output

Created attachment 51786 [details]
acpidmp output

What shoulkd I do to help debugging further?

This is the problem:

ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [LNKC] -> GSI 15 (level, low) -> IRQ 15
irq 15: nobody cared (try booting with the "irqpoll" option)
 [<c013c18c>] __report_bad_irq+0x1c/0x70
 [<c013c27b>] note_interrupt+0x6b/0xd0
 [<c013bd1c>] __do_IRQ+0xbc/0xd0
 [<c01055e8>] do_IRQ+0x38/0x60
 [<c0103dea>] common_interrupt+0x1a/0x20
 [<c0120ba1>] __do_softirq+0x31/0xa0
 [<c0120c36>] do_softirq+0x26/0x30
 [<c01055ed>] do_IRQ+0x3d/0x60
 [<c0103dea>] common_interrupt+0x1a/0x20
 [<c0189b73>] do_task_stat+0x4d3/0x800
 [<c013bc33>] handle_IRQ_event+0x33/0x60
 [<c0142a57>] __pdflush+0x77/0x150
 [<c0186873>] proc_info_read+0x53/0x80
 [<c0186820>] proc_info_read+0x0/0x80
 [<c01590eb>] vfs_read+0x8b/0x170
 [<c015948c>] sys_read+0x3c/0x70
 [<c0102d1b>] sysenter_past_esp+0x54/0x79
handlers:
[<f98247e0>] (snd_intel8x0_interrupt+0x0/0x260 [snd_intel8x0])
Disabling IRQ #15
ALSA sound/pci/intel8x0.c:670: intel8x0: AC97 codec ready timeout.
ALSA sound/pci/intel8x0.c:670: intel8x0: AC97 codec ready timeout.

Not sure whether this is an ACPI or snd driver problem.
Takashi, could you help?

Could you try pci=noacpi, this one should work?

If this is an ACPI bug in setting the sound Interrupt I could only track this down with an ACPI_DEBUG=y kernel and even then it could get hard to find it...

Even worse: The 10.1 Alpha kernel has even not the ACPI_DEBUG_LITE patch of our 10.0 branch (I think, could you also attach "zcat /proc/config.gz", so we might not even see some ACPI errors/warnings.

You can try "buggy_irq=1" module option for snd-intel8x0 as a workaround.
This will always ack the interrupt, so the problem like above should disappear.

I already tried pci=noacpi but unfortunately it doesn´t help. Neither does the buggy_icq. The error messages are always the same.

No ideas anymore..., you could try acpi_irq_balance.
If pci=noacpi it shouldn't be an ACPI bug anyways.
Maybe lapic and apic=verbose shows something?
Takashi, what shall we do with this one?

I found that buggy_irq option is enabled after registering the irq handler, so if the irq is issued immediately, this option doesn't help.

But I have no idea what interrupt is generated at all.  Is the interrupt shared with other devices?

Where can I see the interrupt assignment?

You can see the irq number in /proc/interrupts.

If you're running kernel-default (not smp), I put one with some fixes on ftp.suse.com/pub/people/tiwai/10.0-fixes.  With this kernel, buggy_irq might work better in your case.
(Note that the sync to ftp host may take a bit time.  If no file is found there, please wait for a while.)

Thanks :)
I tried downloading the patch but the server seems to be down, at least for the last 6 hours.

I tried using your kernel and now I get this in the kernel log:

Nov  1 16:08:03 r098088 kernel: PCI: setting IRQ 15 as level-triggered
Nov  1 16:08:03 r098088 kernel: ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [LNKC] -> GSI 15 (level, low) -> IRQ 15
Nov  1 16:08:03 r098088 kernel: irq 15: nobody cared (try booting with the "irqpoll" option)
Nov  1 16:08:03 r098088 kernel:  [<c013c21c>] __report_bad_irq+0x1c/0x70
Nov  1 16:08:03 r098088 kernel:  [<c013c30b>] note_interrupt+0x6b/0xd0
Nov  1 16:08:03 r098088 kernel:  [<c013bdac>] __do_IRQ+0xbc/0xd0
Nov  1 16:08:03 r098088 kernel:  [<c01055e8>] do_IRQ+0x38/0x60
Nov  1 16:08:03 r098088 kernel:  [<c0103dea>] common_interrupt+0x1a/0x20
Nov  1 16:08:03 r098088 kernel:  [<c0120ba1>] __do_softirq+0x31/0xa0
Nov  1 16:08:03 r098088 kernel:  [<c0120c36>] do_softirq+0x26/0x30
Nov  1 16:08:03 r098088 kernel:  [<c01055ed>] do_IRQ+0x3d/0x60
Nov  1 16:08:03 r098088 kernel:  [<c0103dea>] common_interrupt+0x1a/0x20
Nov  1 16:08:03 r098088 kernel:  [<f97fe01a>] igetbyte+0x1a/0x20 [snd_intel8x0]
Nov  1 16:08:03 r098088 kernel:  [<f97fe46f>] snd_intel8x0_ali_codec_ready+0x1f/0x60 [snd_intel8x0]
Nov  1 16:08:03 r098088 kernel:  [<f981016d>] snd_ac97_write+0x3d/0x70 [snd_ac97_codec]
Nov  1 16:08:03 r098088 kernel:  [<f98112cd>] snd_ac97_try_bit+0x3d/0x70 [snd_ac97_codec]
Nov  1 16:08:03 r098088 kernel:  [<f98116be>] snd_ac97_cmix_new_stereo+0x3e/0xd0 [snd_ac97_codec]
Nov  1 16:08:03 r098088 kernel:  [<f97fe03c>] igetword+0x1c/0x30 [snd_intel8x0]
Nov  1 16:08:03 r098088 kernel:  [<f97fe5b7>] snd_intel8x0_ali_codec_read+0x87/0x90 [snd_intel8x0]
Nov  1 16:08:03 r098088 kernel:  [<f98101cc>] snd_ac97_read+0x2c/0x40 [snd_ac97_codec]
Nov  1 16:08:03 r098088 kernel:  [<f9811f17>] snd_ac97_mixer_build+0x7c7/0xaa0 [snd_ac97_codec]
Nov  1 16:08:03 r098088 kernel:  [<f98130b3>] snd_ac97_mixer+0x503/0xcf0 [snd_ac97_codec]
Nov  1 16:08:03 r098088 kernel:  [<f97fe826>] snd_intel8x0_interrupt+0x16/0x260 [snd_intel8x0]
Nov  1 16:08:03 r098088 kernel:  [<c01ee20a>] idr_get_new+0xa/0x30
Nov  1 16:08:03 r098088 kernel:  [<c013bcc3>] handle_IRQ_event+0x33/0x60
Nov  1 16:08:03 r098088 kernel:  [<c01055ed>] do_IRQ+0x3d/0x60
Nov  1 16:08:03 r098088 kernel:  [<c0103dea>] common_interrupt+0x1a/0x20
Nov  1 16:08:03 r098088 kernel:  [<f97ff7cf>] snd_intel8x0_mixer+0x1df/0x520 [snd_intel8x0]
Nov  1 16:08:03 r098088 kernel:  [<f97ff5d0>] snd_intel8x0_mixer_free_ac97+0x0/0x20 [snd_intel8x0]
Nov  1 16:08:03 r098088 kernel:  [<f9800e8e>] snd_intel8x0_probe+0x13e/0x240 [snd_intel8x0]
Nov  1 16:08:03 r098088 kernel:  [<c0255f70>] __driver_attach+0x0/0x40
Nov  1 16:08:03 r098088 kernel:  [<c01f9e80>] __pci_device_probe+0x30/0x40
Nov  1 16:08:03 r098088 kernel:  [<c01f9eae>] pci_device_probe+0x1e/0x40
Nov  1 16:08:03 r098088 kernel:  [<c0255eaf>] driver_probe_device+0x2f/0x90
Nov  1 16:08:03 r098088 kernel:  [<c0255fa9>] __driver_attach+0x39/0x40
Nov  1 16:08:03 r098088 kernel:  [<c0255718>] bus_for_each_dev+0x38/0x60
Nov  1 16:08:03 r098088 kernel:  [<c0255fc1>] driver_attach+0x11/0x20
Nov  1 16:08:03 r098088 kernel:  [<c0255f70>] __driver_attach+0x0/0x40
Nov  1 16:08:03 r098088 kernel:  [<c0255b1a>] bus_add_driver+0x5a/0xa0
Nov  1 16:08:03 r098088 kernel:  [<c01fa068>] pci_register_driver+0x58/0x80
Nov  1 16:08:03 r098088 kernel:  [<c0134201>] sys_init_module+0xa1/0x180
Nov  1 16:08:03 r098088 kernel:  [<c0102d1b>] sysenter_past_esp+0x54/0x79
Nov  1 16:08:03 r098088 kernel: handlers:
Nov  1 16:08:03 r098088 kernel: [<f97fe810>] (snd_intel8x0_interrupt+0x0/0x260 [snd_intel8x0])
Nov  1 16:08:03 r098088 kernel: Disabling IRQ #15
Nov  1 16:08:03 r098088 kernel: hdb: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33)
Nov  1 16:08:03 r098088 kernel: Uniform CD-ROM driver Revision: 3.20
Nov  1 16:08:03 r098088 kernel: ALSA sound/pci/ac97/ac97_codec.c:1959: AC'97 1 does not respond - RESET
Nov  1 16:08:03 r098088 kernel: ALSA sound/pci/ac97/ac97_codec.c:1968: AC'97 1 access is not valid [0xffffffff], removing mixer.
Nov  1 16:08:03 r098088 kernel: ALSA sound/pci/intel8x0.c:2109: Unable to initialize codec #1
Nov  1 16:08:03 r098088 kernel: intel8x0_measure_ac97_clock: measured 54974 usecs
Nov  1 16:08:03 r098088 kernel: intel8x0: clocking to 48000

This is a sound driver problem?
Still watching the bug, tell me if I can help...

Asrock has several 939 based boards, but I guess that this is about
939Dual-SATA2 since it is common, correct?

I have sound running in 10.0 using snd-intel8x0, doing a hwinfo
returns almost identical results (irq and driver order differs)
# hwinfo --sound
  IRQ: 5 (490025 events)
  Module Alias: "pci:v000010B9d00005455sv00001849sd00000850bc04sc01i00"
  Driver Info #0:
    Driver Status: snd_intel8x0 is active
    Driver Activation Cmd: "modprobe snd_intel8x0"
  Driver Info #1:
    Driver Status: ali5455 is not active
    Driver Activation Cmd: "modprobe ali5455"
  Config Status: cfg=yes, avail=yes, need=no, active=unknown

Yes, it is about this board. But I´ve changed to another Asus Board which has a higher level of quality :)

I see no progress on this bug for 8 weeks.
If we are waiting for more debug info please set to NEEDINFO.
If you accept this bug and will work on it please set to ASSIGNED.
It should not be in New state for so long.

We have no technical contact and no technical information about this board, so I cannot fix this problem.  Resolved to WONTFIX.