Hello,
I am a happy owner of Intel D815EEA2 mother board. This board
comes with integrated AC-97 audio. When I try to load i810_audio
driver for it, driver identifies the device as
"Intel 810 + AC97 Audio, version 0.02, 19:43:23 Apr 20 2001
i810: Intel ICH2 found at IO 0xef00 and 0xe800, IRQ 6
ac97_codec: AC97 Audio codec, id: 0x4144:0x5360 (Analog Devices
AD1885)"
and later brings the system into one of three possible conditions.
A) a bit later it says:
i810_audio: 11168 bytes in 50 milliseconds
i810_audio: setting clocking to 41260 to compensate
In this case everything is fine ( 16-bit sound is played correctly, I
don't need much more ... ).
B) It says:
i810_audio: 65528 bytes in 50 milliseconds
i810_audio: setting clocking to 7032 to compensate
In this case the sound does not work at all - sound card does not
produce anything but silence. With versions of kernel up to 2.4.3 I
also received a lot of "DMA buffer overrun on send" messages in dmesg
when playing anything.
C) Last condition is relatively rare. It says something similar to
case A, but number of bytes is multiple of 11168 and clocking is lower
( e.g. 13753 = 41260/3 ). Sound card works, but output quality is
quite low.
Which of cases A)..C) takes place, seems to be random ( I haven't
noticed any pattern ). However, attempts to do rmmod/insmod
do not have any effect. I have to at least reboot the system a few
times to bring the sound to working state.
I tried driver from kernels 2.4.1, 2.4.3 and 2.4.4-pre4. All of them
behave more or less in the same way.
In Windows 2000 this motherboard/audio device works without any problems.
I can provide any additional information if it helps to solve the bug.
Please cc: me, because I am not subscribed to the list.
--
Best regards,
Eugene
mailto:[email protected]
Eugene Kuznetsov wrote:
>
> Hello,
>
> I am a happy owner of Intel D815EEA2 mother board. This board
> comes with integrated AC-97 audio. When I try to load i810_audio
> driver for it, driver identifies the device as
> "Intel 810 + AC97 Audio, version 0.02, 19:43:23 Apr 20 2001
> i810: Intel ICH2 found at IO 0xef00 and 0xe800, IRQ 6
> ac97_codec: AC97 Audio codec, id: 0x4144:0x5360 (Analog Devices
> AD1885)"
> and later brings the system into one of three possible conditions.
> A) a bit later it says:
> i810_audio: 11168 bytes in 50 milliseconds
> i810_audio: setting clocking to 41260 to compensate
> In this case everything is fine ( 16-bit sound is played correctly, I
> don't need much more ... ).
Write that number down. You can add it to your /etc/modules.conf file if you
like. If the new driver sees that the clocking variable has been set to
anything other than 48000 it doesn't run the clocking autodetect routine.
> B) It says:
> i810_audio: 65528 bytes in 50 milliseconds
> i810_audio: setting clocking to 7032 to compensate
> In this case the sound does not work at all - sound card does not
> produce anything but silence. With versions of kernel up to 2.4.3 I
> also received a lot of "DMA buffer overrun on send" messages in dmesg
> when playing anything.
> C) Last condition is relatively rare. It says something similar to
> case A, but number of bytes is multiple of 11168 and clocking is lower
> ( e.g. 13753 = 41260/3 ). Sound card works, but output quality is
> quite low.
> Which of cases A)..C) takes place, seems to be random ( I haven't
> noticed any pattern ). However, attempts to do rmmod/insmod
> do not have any effect. I have to at least reboot the system a few
> times to bring the sound to working state.
Both B and C are cases of the whole chip acting flat busted. I would suspect
that possibly Win2k drivers set this thing up some way that we don't recover
from. Is there any pattern like maybe "I listen to X in Win2k then reboot to
linux and sound is screwed" or something like that? Also, when it does
happen, does shutting down and then actually powering the machine off
(possibly by going so far as to unplug the machine for 5 seconds or so to
overcome any low power state savings on modern motherboards) make it reliably
come back instead of having to reboot multiple times? Does this ever happen
if you just unload/reload the module without rebooting inbetween (aka, does
the linux driver module sometimes trigger the problem)? Finally, when B or C
does happen, can you get the module to work by loading the module with the
clocking= option set to the correct clocking value from A?
> I tried driver from kernels 2.4.1, 2.4.3 and 2.4.4-pre4. All of them
> behave more or less in the same way.
> In Windows 2000 this motherboard/audio device works without any problems.
> I can provide any additional information if it helps to solve the bug.
> Please cc: me, because I am not subscribed to the list.
>
> --
> Best regards,
> Eugene
> mailto:[email protected]
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Doug Ledford <[email protected]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
Hello Doug,
Monday, April 23, 2001, 9:54:35 PM, you wrote:
DL> Eugene Kuznetsov wrote:
>>
>> Hello,
>>
>> I am a happy owner of Intel D815EEA2 mother board. This board
>> comes with integrated AC-97 audio. When I try to load i810_audio
>> driver for it, driver identifies the device as
>> "Intel 810 + AC97 Audio, version 0.02, 19:43:23 Apr 20 2001
>> i810: Intel ICH2 found at IO 0xef00 and 0xe800, IRQ 6
>> ac97_codec: AC97 Audio codec, id: 0x4144:0x5360 (Analog Devices
>> AD1885)"
>> and later brings the system into one of three possible conditions.
>> A) a bit later it says:
>> i810_audio: 11168 bytes in 50 milliseconds
>> i810_audio: setting clocking to 41260 to compensate
>> In this case everything is fine ( 16-bit sound is played correctly, I
>> don't need much more ... ).
DL> Write that number down. You can add it to your /etc/modules.conf file if you
DL> like. If the new driver sees that the clocking variable has been set to
DL> anything other than 48000 it doesn't run the clocking autodetect routine.
>> B) It says:
>> i810_audio: 65528 bytes in 50 milliseconds
>> i810_audio: setting clocking to 7032 to compensate
>> In this case the sound does not work at all - sound card does not
>> produce anything but silence. With versions of kernel up to 2.4.3 I
>> also received a lot of "DMA buffer overrun on send" messages in dmesg
>> when playing anything.
>> C) Last condition is relatively rare. It says something similar to
>> case A, but number of bytes is multiple of 11168 and clocking is lower
>> ( e.g. 13753 = 41260/3 ). Sound card works, but output quality is
>> quite low.
>> Which of cases A)..C) takes place, seems to be random ( I haven't
>> noticed any pattern ). However, attempts to do rmmod/insmod
>> do not have any effect. I have to at least reboot the system a few
>> times to bring the sound to working state.
DL> Both B and C are cases of the whole chip acting flat busted. I would suspect
DL> that possibly Win2k drivers set this thing up some way that we don't recover
DL> from. Is there any pattern like maybe "I listen to X in Win2k then reboot to
DL> linux and sound is screwed" or something like that?
DL> Also, when it does
DL> happen, does shutting down and then actually powering the machine off
DL> (possibly by going so far as to unplug the machine for 5 seconds or so to
DL> overcome any low power state savings on modern motherboards) make it reliably
DL> come back instead of having to reboot multiple times?
DL> Does this ever happen
DL> if you just unload/reload the module without rebooting inbetween (aka, does
DL> the linux driver module sometimes trigger the problem)?
Maybe there is a pattern: I remember that case B occured more
frequently after soft reboot from Win2k. I had case C one time
immediately after turning the computer on and booting directly into
Linux. I will do some more testing about these three
questions and tell you the results later today.
DL> Finally, when B or C
DL> does happen, can you get the module to work by loading the module with the
DL> clocking= option set to the correct clocking value from A?
No.
I want to tell you that I received an advice from one of list subscribers
and tried installing ALSA drivers for the chip. They work without any
of described problems.
--
Best regards,
Eugene
mailto:[email protected] or [email protected]
[Team GADGET] [Team Two Divided By Zero] [Team Hackzone.ru]
Hello Doug,
Monday, April 23, 2001, 9:54:35 PM, you wrote:
DL> Both B and C are cases of the whole chip acting flat busted. I would suspect
DL> that possibly Win2k drivers set this thing up some way that we don't recover
DL> from. Is there any pattern like maybe "I listen to X in Win2k then reboot to
DL> linux and sound is screwed" or something like that? Also, when it does
DL> happen, does shutting down and then actually powering the machine off
DL> (possibly by going so far as to unplug the machine for 5 seconds or so to
DL> overcome any low power state savings on modern motherboards) make it reliably
DL> come back instead of having to reboot multiple times? Does this ever happen
DL> if you just unload/reload the module without rebooting inbetween (aka, does
DL> the linux driver module sometimes trigger the problem)?
Here are some more answers.
1. I tried powering the machine off, unplugging it for several seconds
and then booting into Linux. Two out of three times it came into state B and
one time into state A. Thus, I think that the problem is not caused by
Win2k drivers. Moreover, rebooting into Win2k, playing something with Winamp
( 44k/16/stereo ) and returning into Linux also brought it into state A.
2. Unloading/reloading driver module does _not_ trigger the problem.
It simply does not affect the condition. I can switch it from state
B to state A by removing i810_audio, inserting ALSA driver for the
chip, immediately removing it and inserting i810_audio back.
3. Multiple rebooting sometimes ( not always ) switches it from B to
A, but I'm not sure that it can switch it in other direction.
The whole thing sounds to my mind as having some kind of resource,
register, etc. which is supposed to be initialized during loading of
drivers, but it's not done by i810_audio driver.
--
Best regards,
Eugene
mailto:[email protected] or [email protected]
[Team GADGET] [Team Two Divided By Zero] [Team Hackzone.ru]
Eugene Kuznetsov wrote:
> The whole thing sounds to my mind as having some kind of resource,
> register, etc. which is supposed to be initialized during loading of
> drivers, but it's not done by i810_audio driver.
Sounds that way to me too. I didn't write that portion of the code, so it
will take me a little bit to figure out where it is screwing up at.
--
Doug Ledford <[email protected]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
On Mon, Apr 23, 2001 at 10:54:35PM -0400, Doug Ledford wrote:
[...]
>
> Both B and C are cases of the whole chip acting flat busted. I would suspect
> that possibly Win2k drivers set this thing up some way that we don't recover
> from.
Hmmmm...
quite possible. It's certainly true that a soft reboot from win2k leaves the
cs42xx stuff screwed on my Thinkpad T20 so it wouldn't be surprising to hear
of issues with other sound chips. I need to get around to dumping the
registers in the good and bad case to determine what on earth it futzed with
and undo it.
Tim
--
Tim Wright - [email protected] or [email protected] or [email protected]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI