prolog-in wrote:So the problem is in eudev? because I have all the modules compiled and available? what is happening:
No sorry, my mistake, codecs are load/use by alsa, udev is there to load the module for the card.
your dmesg show eudev is doing the work, it try to load the module for your card, however, the module is failing, either because it need a specific option for your card model (you said, i have a dell, and many dell have options for intel-hd-audio, look at /usr/src/linux/Documentation/sound/alsa)
i think those specials models may alter probing mask.
you could see that from Audio-HD.txt
Codec-Probing Problem
~~~~~~~~~~~~~~~~~~~~~
A less often but a more severe problem is the codec probing. When
BIOS reports the available codec slots wrongly, the driver gets
confused and tries to access the non-existing codec slot. This often
results in the total screw-up, and destructs the further communication
with the codec chips. The symptom appears usually as error messages
like:
------------------------------------------------------------------------
hda_intel: azx_get_response timeout, switching to polling mode:
last cmd=0x12345678
hda_intel: azx_get_response timeout, switching to single_cmd mode:
last cmd=0x12345678
------------------------------------------------------------------------
The first line is a warning, and this is usually relatively harmless.
It means that the codec response isn't notified via an IRQ. The
driver uses explicit polling method to read the response. It gives
very slight CPU overhead, but you'd unlikely notice it.
The second line is, however, a fatal error. If this happens, usually
it means that something is really wrong. Most likely you are
accessing a non-existing codec slot.
Thus, if the second error message appears, try to narrow the probed
codec slots via `probe_mask` option. It's a bitmask, and each bit
corresponds to the codec slot. For example, to probe only the first
slot, pass `probe_mask=1`. For the first and the third slots, pass
`probe_mask=5` (where 5 = 1 | 4), and so on.
Since 2.6.29 kernel, the driver has a more robust probing method, so
this error might happen rarely, though.
On a machine with a broken BIOS, sometimes you need to force the
driver to probe the codec slots the hardware doesn't report for use.
In such a case, turn the bit 8 (0x100) of `probe_mask` option on.
Then the rest 8 bits are passed as the codec slots to probe
unconditionally. For example, `probe_mask=0x103` will force to probe
the codec slots 0 and 1 no matter what the hardware reports.
You don't need for now to tweak that, but what you need to do is checking what codec your card use, and reading in HD-Audio-Models.txt if your dell card is support and then you need to feed alsa with the proper switch, so that when loading the intel-hda the proper option is given (which may already fix the probing trouble)
don't worry about howto do that if you are lost, you will have someone that will tells you later, for now, seek the info
