At Tue, 17 Feb 2009 18:28:49 +0100,
hagedorn@xxxxxxxx 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,
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
