At Mon, 23 Jul 2007 22:42:07 -0400, Lee Revell wrote: > > On 7/23/07, Marek Zelem <marek@xxxxxxxxxxx> wrote: > > ACPI: PCI Interrupt 0000:00:14.2[A] -> GSI 16 (level, low) -> IRQ 16 > > ALSA > > /usr/src/modules/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:558: > > hda_intel: azx_get_response timeout, switching to polling mode... > > ALSA > > /usr/src/modules/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:564: > > hda_intel: azx_get_response timeout, switching to single_cmd mode... > > hda_codec: No auto-config is available, default to model=ref > > ALSA > > /usr/src/modules/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:1020: > > hda-intel: no codecs initialized > > Takashi-san, > > Maybe you should add another printk() to HDA intel driver that > instructs the user to post relevant debug info > (/proc/asound/card0/codecblah...) to alsa-devel in these cases where > we encounter some problem that is likely to result in no sound? Other > subsystems do it in similar cases (essentially, too many hardware > variants for the maintainers to have any chance of testing them all) > and it seems to produce good results. It would make a lot of users > happy to not have to google for what to do next... Well, in this case, the codec probe itself fails, so we cannot get the mostly userful information such as codec#* proc files. Thus it won't be helpful to give such instructions. I suspect this particular case is rather an ACPI problem like others. Some ACPI-related boot options are worth to try... Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
