Re: 2.6.2-rc2-bk1 oopses on boot (ACPI patch)

[Dominik Brodowski]

On Wed, Jan 28, 2004 at 04:40:32AM +0100, Alessandro Suardi wrote:
> printk("CPUFREQ DEBUG: [%lu] [%u] [%u]\n", l_p_j_ref, l_p_j_ref_freq, 
> ci->new);
> 
>  as both first and last instruction in adjust_jiffies() turns
>  up the same values, which are 1773568, 1, 0.

The ACPI tables report totally bogus CPU frequencies -- 1 and 0 MHz. I'm
surprised this differs between 2.6.0 and 2.6.x-mm... Len, any idea?


On Tue, Jan 27, 2004 at 07:06:41PM -0800, Linus Torvalds wrote:
> 
> 
> On Wed, 28 Jan 2004, Alessandro Suardi wrote:
> >
> > Already reported, but I'll do so once again, since it looks like
> >   in a short while I won't be able to boot official kernels in my
> >   current config...
> >
> >	http://www.ussg.iu.edu/hypermail/linux/kernel/0312.3/0442.html
> 
> Can you make adjust_jiffies() print out its arguments (it's in 
> drivers/cpufreq/cpufreq.c).
> 
> It looks like cpufreq_scale() gets a divide-by-zero or an overflow on one 
> of
> 
> 	l_p_j_ref, l_p_j_ref_freq, ci->new
> 
> and just printing out those values would be interesting.
> 
> That said, the code is crap anyway.

> It does various divides without 
> actually testing for any sanity at all,

CPUfreq and the CPUfreq timing code _need_ to rely on the CPU frequencies
being reported by the drivers. If they're wrong all timing will be wrong[1]...
Nonetheless, a fix for the acpi driver which aborts on such "zero" MHz
reports has already been sent to Len for reviewal [2].

> and tries to "avoid overflow" by 
> totally bogus methods, instead of just using the 64-bit do_div64().

Agreed, will fix it.

	Dominik

[1] Especially as the pmtmr also uses tsc for the delay() routines...
[2] http://marc.theaimsgroup.com/?l=acpi4linux&m=107421039607335&w=2

Attachment: pgp00000.pgp
Description: PGP signature