At least on my computer, it seems to me that this
bug turned out to be caused by flaky hardware.
In the interest of possibly helping someone else
who happens to encounter it, here's how I recall
that I worked around, diagnosed and ultimately
fixed my bug.
I worked around it by typing this as root whenever
audio stopped working:
$ for control in Master PCM CD ; do amixer set $control mute ; amixer set
$control unmute ; done
I diagnosed it as a hardware problem by
a.) adding "printk()" statements to anywhere in
via82xx.c and ac97_codec.c that looked like they
might reset audio,
b.) recompiling by running the following command
as root:
$ m-a -f -v -O a-i alsa
and then monitoring the printk()'s with something like
$ cat /proc/kmsg | while read a_line ; do echo $(date +%x:%T) "$a_line" ;
done
and
c.) checking for diagnostic printk() messages when
audio spontaneously stopped working. None
appeared, which makes me suspect that the sound
hardware, AC97 on the motherboard, was
spontaneously resetting, unrelated to any alsa
bug. (Coincidentally, my computer's audio started
spontaneously resetting at about the same time
that I replaced a Buslogic scsi host adapter with
a used one from Adaptec. I had encountered an old
bug in the unsupported Buslogic driver that broke
my computer's scanner.)
I ultimately fixed the audio bug by installing a
sound card.
As an aside, the new sound card seemed to cause
the kernel to crash with
<3>irq 11: nobody cared (try booting with the "irqpoll" option)
<4> [<c01408e7>] __report_bad_irq+0x2b/0x69
<4> [<c0140adb>] note_interrupt+0x1b6/0x1ef
<4> [<c01400eb>] handle_IRQ_event+0x23/0x49
<4> [<c01401c3>] __do_IRQ+0xb2/0xe6
<4> [<c01050e5>] do_IRQ+0x43/0x52
<4> [<c0103692>] common_interrupt+0x1a/0x20
<4> [<c012197f>] __do_softirq+0x51/0xbb
<4> [<c0121a1f>] do_softirq+0x36/0x3a
<4> [<c01050ea>] do_IRQ+0x48/0x52
<4> [<c0103692>] common_interrupt+0x1a/0x20
<4> [<c0284973>] _spin_unlock_irqrestore+0x5/0x6
<4> [<c020c527>] uart_change_speed+0x54/0x57
<4> [<c020e678>] uart_set_termios+0x4e/0x16a
<4> [<c0117862>] default_wake_function+0x0/0xc
<4> [<c0201965>] n_tty_ioctl+0x0/0x3fd
<4> [<c0201922>] set_termios+0x2ad/0x2f0
<4> [<c0201965>] n_tty_ioctl+0x0/0x3fd
<4> [<c01ff20d>] tty_ioctl+0xb35/0xb94
<4> [<c0145e1c>] __alloc_pages+0x4e/0x275
<4> [<c0141c91>] find_get_page+0x18/0x38
<4> [<c014426b>] filemap_nopage+0x192/0x30b
<4> [<c014c8d7>] __handle_mm_fault+0x3d8/0x705
<4> [<c0169933>] do_ioctl+0x47/0x5d
<4> [<c0169b9b>] vfs_ioctl+0x252/0x264
<4> [<c0169bf5>] sys_ioctl+0x48/0x5f
<4> [<c0102c57>] syscall_call+0x7/0xb
<3>handlers:
<3>[<f8858501>] (usb_hcd_irq+0x0/0x50 [usbcore])
<3>[<f8858501>] (usb_hcd_irq+0x0/0x50 [usbcore])
<3>[<f88bc3ac>] (ahc_linux_isr+0x0/0x1cb [aic7xxx])
<3>[<f8945544>] (irq_redirect+0x0/0x1a [snd])
<3>[<f8945544>] (irq_redirect+0x0/0x1a [snd])
<3>[<f8847684>] (tulip_interrupt+0x0/0x6b3 [tulip])
<3>[<f88f38fd>] (rtl8139_interrupt+0x0/0x37a [8139too])
<0>Disabling IRQ #11
Interrupt #11 was shared by uhci_hcd:usb1,
uhci_hcd:usb2, aic7xxx, Ensoniq AudioPCI,
VIA8233A, eth0 and eth1.
I stabilized the kernel by booting it with the
"irqpoll" option.
Thanks,
Kingsley
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
