snd_hda works on i386, fails on amd64 (RELENG_7)

[Alexander Motin]

Hi.

Rick C. Petty wrote:
> In a recent switch from i386 to amd64, I having a problem with the
> onboard audio, an Asus M3N78-VM board with VT1708B HDA 8-channel codec.
> 
> It works perfectly in i386 but fails on the same kernel source in amd64:

> hdac0: <NVidia MCP78 High Definition Audio Controller> mem 0xfe978000-0xfe97bfff irq 22 at device 7.0 on pci0
> hdac0: HDA Driver Revision: 20090329_0131
> hdac0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xfe978000
> hdac0: [MPSAFE]
> hdac0: [ITHREAD]

> hdac0: Probing codec #0...
> hdac0: hdac_command_send_internal: TIMEOUT numcmd=1, sent=1, received=0
> hdac0: hdac_command_send_internal: TIMEOUT numcmd=1, sent=1, received=0
> hdac0: Codec #0 is not responding! Probing aborted.
> hdac0: Probing codec #3...
> hdac0: hdac_command_send_internal: TIMEOUT numcmd=1, sent=1, received=0
> hdac0: hdac_command_send_internal: TIMEOUT numcmd=1, sent=1, received=0
> hdac0: Codec #3 is not responding! Probing aborted.

I have already seen such reports few times, but nobody yet reported 
about platform specifics of this. I think it is not codec, but a HDA 
controller related issue. In your case problem only appears with 
on-board NVidia controller, but not with external ATI one.

Could you boot with `hw.snd.verbose=4` to get maximum driver debugging. 
I am especially interested in first hdac0 related messages. There is 
some sort of CPU cache coherency/DMA management magic used, which looks 
suspicious to me. Also some people report about such problems with 
NVidia HDA controllers when MSI interrupts enabled, but it is probably 
not your case, as snd_hda does not uses MSI by default on RELENG_7.

-- 
Alexander Motin