After compiling my own kernels from 2.6.11 to 2.6.14, I found that
only the Ubuntu official kernel didn't lock up hard after 2 hours or
so. Why? Because it didn't provide the frequency scaling driver
longhaul.ko for my VIA C3 CPU. WIthout longhaul frequency scaling, my
laptop is rock stable.
According to http://tinyurl.com/k7wlw , this has been going on since kernel 2.4!
In http://tinyurl.com/oxetd Dave Jones says,
Version 2 of longhaul is the same as v1, but adds voltage scaling.
12 * Present in Samuel 2 (steppings 1-7 only) (C5B), and Ezra (C5C)
Output of cat /proc/cpuinfo included.
Output of dmesg also included.
As you can see, dmesg says the kernel detected a Ezra C5C version of
VIA C3. However, it also goes on to say, only longhaul v1 supported.
What's with that? Does that have anything to do with the laptop
locking?
When the laptop locks, nothing on the screen moves. I can adjust
screen brightness even in the bios, but once it locks, I cannot do
that. Numlock,Capslock,Scrolllock do not change when I press their
buttons either, and pinging my lockedup laptop does not solicit a
reply.
So, it is unfortunate, but I don't think any kernel dumps or panic
messages were output. I should know. I've been experiencing this for a
year or so.
Please, somebody fix this frequency scaling issue!
Randomshinichi
--
....pi......pi......kaaaaaaa....
AMD Throughbred-A 1533MHz, 768MB PC2100 RAM, Maxtor 6EL040,
NV25 Ti4200 128MB
On Sat, Mar 04, 2006 at 10:46:11PM +0800, Shinichi Kudo wrote:
> After compiling my own kernels from 2.6.11 to 2.6.14, I found that
> only the Ubuntu official kernel didn't lock up hard after 2 hours or
> so. Why? Because it didn't provide the frequency scaling driver
> longhaul.ko for my VIA C3 CPU. WIthout longhaul frequency scaling, my
> laptop is rock stable.
>
> According to http://tinyurl.com/k7wlw , this has been going on since kernel 2.4!
2.4 never officially had cpufreq.
> In http://tinyurl.com/oxetd Dave Jones says,
> Version 2 of longhaul is the same as v1, but adds voltage scaling.
> 12 * Present in Samuel 2 (steppings 1-7 only) (C5B), and Ezra (C5C)
>
> Output of cat /proc/cpuinfo included.
> Output of dmesg also included.
>
> As you can see, dmesg says the kernel detected a Ezra C5C version of
> VIA C3. However, it also goes on to say, only longhaul v1 supported.
> What's with that?
v2 is v1+voltage scaling. As the driver doesn't do voltage scaling,
there's no difference.
> Does that have anything to do with the laptop
> locking?
No. It's to do with the way frequency scaling is implemented on those CPUs.
It's very tempremental. If there's any (for eg) IDE DMA that occurs
during a frequency transition, everything goes bang a short time later.
There's an ugly patch below that was submitted, which fixes it for
some people, but as it's a) ide specific, and b) completely the
wrong place to do this and c) racy, I never merged it to mainline.
I'm hopeful that future generations of their CPUs will behave
in the same manner of other implementations that other x86 vendors
have invented, where we don't need such hacks.
> Please, somebody fix this frequency scaling issue!
I'm actually contemplating marking it CONFIG_BROKEN in mainline,
as there's not a great deal we can do to make it work without
significant infrastructure to quiesce DMA.
Dave
>From patch by: Ken Staton <[email protected]>
--- linux-2.6.11/arch/i386/kernel/cpu/cpufreq/longhaul.c~ 2005-05-24 01:51:51.000000000 -0400
+++ linux-2.6.11/arch/i386/kernel/cpu/cpufreq/longhaul.c 2005-05-24 01:52:07.000000000 -0400
@@ -30,6 +30,8 @@
#include <linux/slab.h>
#include <linux/string.h>
#include <linux/pci.h>
+#include <linux/ide.h>
+#include <linux/delay.h>
#include <asm/msr.h>
#include <asm/timex.h>
@@ -91,6 +91,25 @@ static char *print_speed(int speed)
}
#endif
+static void ide_idle(void)
+ {
+ int i;
+ ide_hwif_t *hwif = ide_hwifs;
+ ide_drive_t *drive;
+
+ i = 0;
+ do {
+ drive = &hwif->drives[i];
+ i++;
+ if (strncmp(drive->name,"hd",2) == 0) {
+ while (drive->waiting_for_dma)
+ udelay(10);
+ } else {
+ i = 0;
+ }
+ } while (i != 0);
+}
+
static unsigned int calc_speed(int mult)
{
@@ -146,6 +165,7 @@ static void do_powersaver(union msr_long
longhaul->bits.RevisionKey = 0;
preempt_disable();
+ ide_idle(); /* avoid ide timeouts when bus master off */
local_irq_save(flags);
/*
--
http://www.codemonkey.org.uk
On Sad, 2006-03-04 at 23:38 -0500, Dave Jones wrote:
> There's an ugly patch below that was submitted, which fixes it for
> some people, but as it's a) ide specific, and b) completely the
> wrong place to do this and c) racy, I never merged it to mainline.
If I understand the documentation correctly you simply need to disable
the master bit on the root bridge during the transition and the PCI
transactions will be stalled, providing you don't take too long about
it.
On Mon, Mar 06, 2006 at 07:44:10PM +0000, Alan Cox wrote:
> On Sad, 2006-03-04 at 23:38 -0500, Dave Jones wrote:
> > There's an ugly patch below that was submitted, which fixes it for
> > some people, but as it's a) ide specific, and b) completely the
> > wrong place to do this and c) racy, I never merged it to mainline.
>
> If I understand the documentation correctly you simply need to disable
> the master bit on the root bridge during the transition and the PCI
> transactions will be stalled, providing you don't take too long about
> it.
tried it, didn't change anything.
The current code goes one step further, and disables it for all devices.
Still no joy. See the do_powersaver() function in arch/i386/kernel/cpu/cpufreq/longhaul.c
Dave
--
http://www.codemonkey.org.uk
On 05/03/06 04:38, Dave Jones wrote:
> On Sat, Mar 04, 2006 at 10:46:11PM +0800, Shinichi Kudo wrote:
> > Please, somebody fix this frequency scaling issue!
>
> I'm actually contemplating marking it CONFIG_BROKEN in mainline,
> as there's not a great deal we can do to make it work without
> significant infrastructure to quiesce DMA.
Good idea! Too many people fall foul of this (well, I did...).
--
-=( Ian Abbott @ MEV Ltd. E-mail: <[email protected]> )=-
-=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-