[alsa-devel] ALI5451: "stimer is not ready"
Dear All,
since our hardware supplier changed the processor type from Transmeta T5700 (667MHz) to T5800 (997MHz), we experience massive problems with the sound card access.
With the new T5800 processor we first noticed problems with IDE access. But it can be solved by switching "acpi=off" and choosing another processor type in kernel config, e.g. 'Pentium MMX' instead 'Transmeta Crusoe'.
Moreover we experienced random appearance of "ali_stimer_read: stimer is not ready" messages from ALSA when accessing the sound card on T5800. I tried also 2.4.37 and 2.6.22 kernels. An update to ALSA 1.0.19 does not help too. The strange thing is that i can boot the same system over and over again... in some cases i get above error message, sometimes i get no ALSA error message at all but the sound card can not be accessed, and sometimes the system works and is recording sound - at least for a few hours. Loading the kernel module trident instead of ALSA makes the system freeze immediately on a T5800. On a T5700 it works. System yields regulary " i8253 count too high ! resetting " but does not seem to have any effect on system with T5700. On T5800 this messages is much more often. On 2.6.22 kernel i saw "TSC unstable" at boot time.
I do not have knowledge about these timing things, so i would like to know a) what does above message mean exactly? b) what timing source is alsa using and how can i influence it? c) what timing source is the kernel using and how can i influence it? d) can this be caused by defect hardware or buggy BIOS? e) do you have any other ideas (e.g. kernel options)?
Some info about the original system which worked well on T5700:
- Linux is self-compiled with 'Linux from Scratch' - System boots from Compact Flashdisk, HDD is used for log files only - Kernel 2.4.22, optimized for Transmeta crusoe - Glibc version 2.3.2, compiled with GNU CC 3.3.3 for i686 on Kernel 2.4.25 - ALSA 1.0.5a, loaded modules are snd, snd-ali5451, soundcore, snd-pcm snd-timer, snd-page-alloc, snd-ac97-codec
The same compact flashcard containing this configuration on a T5800 system will yield IDE errors "DRQ after issuing write" and will show the stated ALSA stimer error.
Thank you very much in advance. Kind regards, Christoph
At Tue, 17 Feb 2009 18:28:49 +0100, hagedorn@kimae.de wrote:
Dear All,
since our hardware supplier changed the processor type from Transmeta T5700 (667MHz) to T5800 (997MHz), we experience massive problems with the sound card access.
With the new T5800 processor we first noticed problems with IDE access. But it can be solved by switching "acpi=off" and choosing another processor type in kernel config, e.g. 'Pentium MMX' instead 'Transmeta Crusoe'.
Moreover we experienced random appearance of "ali_stimer_read: stimer is not ready" messages from ALSA when accessing the sound card on T5800. I tried also 2.4.37 and 2.6.22 kernels. An update to ALSA 1.0.19 does not help too. The strange thing is that i can boot the same system over and over again... in some cases i get above error message, sometimes i get no ALSA error message at all but the sound card can not be accessed, and sometimes the system works and is recording sound - at least for a few hours. Loading the kernel module trident instead of ALSA makes the system freeze immediately on a T5800. On a T5700 it works. System yields regulary " i8253 count too high ! resetting " but does not seem to have any effect on system with T5700. On T5800 this messages is much more often. On 2.6.22 kernel i saw "TSC unstable" at boot time.
I do not have knowledge about these timing things, so i would like to know a) what does above message mean exactly?
The driver checks stimer ("sample timer" I suppose) register. The purpose of the function is to wait until one sample is proceeded. By some reason on your machine, stimer register doesn't change.
b) what timing source is alsa using and how can i influence it? c) what timing source is the kernel using and how can i influence it?
"stimer" is the sound device thing, and nothing to do with the kernel timer. The timeout could be a kernel issue, though, because the timeout is checked by the kernel timekeeping.
d) can this be caused by defect hardware or buggy BIOS?
Always possible :)
e) do you have any other ideas (e.g. kernel options)?
Try the patch below, which simply disables the stimer check. Looking at the code, stimer check is anyway non-fatal procedure, and I feel it's just an overkill.
thanks,
Takashi
--- diff --git a/sound/pci/ali5451/ali5451.c b/sound/pci/ali5451/ali5451.c index b36c551..9bc9ded 100644 --- a/sound/pci/ali5451/ali5451.c +++ b/sound/pci/ali5451/ali5451.c @@ -321,6 +321,7 @@ static int snd_ali_codec_ready(struct snd_ali *codec, return -EIO; }
+#if 0 /* seems like an overkill */ static int snd_ali_stimer_ready(struct snd_ali *codec) { unsigned long end_time; @@ -339,6 +340,9 @@ static int snd_ali_stimer_ready(struct snd_ali *codec) snd_printk(KERN_ERR "ali_stimer_read: stimer is not ready.\n"); return -EIO; } +#else +#define snd_ali_stimer_ready(codec) 0 +#endif
static void snd_ali_codec_poke(struct snd_ali *codec,int secondary, unsigned short reg,
participants (2)
-
hagedorn＠kimae.de -
Takashi Iwai