[alsa-devel] ALI5451: "stimer is not ready"

[Takashi Iwai]

At Tue, 17 Feb 2009 18:28:49 +0100,
hagedorn at 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,