cpufreq longhaul locks up

cpufreq longhaul locks up

[Jan Engelhardt]

Hi,


I found that setting the cpufreq governor to ondemand making the box 
lock up solid in 2.6.20.2 and 2.6.21 after a few seconds. Sysrq 
does not work anymore, and the last messages are:

May  3 19:16:58 cn kernel: longhaul: VIA C3 'Nehemiah C' [C5P] CPU 
detected.  Powersaver supported.
May  3 19:16:58 cn kernel: longhaul: Using northbridge support.
May  3 19:17:22 cn kernel: Time: acpi_pm clocksource has been installed.
May  3 19:17:22 cn kernel: Clocksource tsc unstable (delta = -136422685 
ns)

I have also tried 2.6.20.2 in single-user mode (so that I can have 
the disk readonly), and it take a little longer (magnitude: minutes) 
to lock up; not sure if it's 20.2 or the single-user mode but I suspect 
the latter since nothing is running then that could potentially 
contribute to quickly changing workloads/frequencies.

If you need more info, please let me know.


Thanks,
Jan
-- 

Re: cpufreq longhaul locks up

[Wander Winkelhorst]

On 5/4/07, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
>
> Hi,
>
>
> I found that setting the cpufreq governor to ondemand making the box
> lock up solid in 2.6.20.2 and 2.6.21 after a few seconds. Sysrq
> does not work anymore, and the last messages are:
>
> May  3 19:16:58 cn kernel: longhaul: VIA C3 'Nehemiah C' [C5P] CPU
> detected.  Powersaver supported.
> May  3 19:16:58 cn kernel: longhaul: Using northbridge support.
> May  3 19:17:22 cn kernel: Time: acpi_pm clocksource has been installed.
> May  3 19:17:22 cn kernel: Clocksource tsc unstable (delta = -136422685
> ns)
>
> I have also tried 2.6.20.2 in single-user mode (so that I can have
> the disk readonly), and it take a little longer (magnitude: minutes)
> to lock up; not sure if it's 20.2 or the single-user mode but I suspect
> the latter since nothing is running then that could potentially
> contribute to quickly changing workloads/frequencies.
>
> If you need more info, please let me know.


Hi,

I also have the same problem. Except in my case the box is stable for a
couple of hours before it locks up hard.
I did some digging around, and from what I found on the internet, it seems
that having busmaster DMA devices causes this problem.

And indeed, if I stop the ondemand governor and use the performance governor
if I record anything with my Hauppauge PVR150 (which is a busmaster DMA
device) and afterwards use the ondemand governor again, the box is more
stable (stable for a couple of days)

I have a VIA SP1300 motherboard, which has a VIA C3 Nehemiah processor @
1333 Mhz
This box has never been stable with any kernel in combination with the
ondemand governor (I've had this box since 2.6.12 or so)
If I use the performance governor, the box is stable (for weeks, months...)

I hope this helps, I'd love to use the ondemand governor and if anyone wants
me to test related patches, please send them.

Wander.
(I'm not subscribed to LKML BTW)

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 4 2007 13:36, Wander Winkelhorst wrote:
>
> Hi,
>
> I also have the same problem. Except in my case the box is stable
> for a couple of hours before it locks up hard. I did some digging
> around, and from what I found on the internet, it seems that having
> busmaster DMA devices causes this problem.
>
Does it happen for you when you use the 'powersave' governor
(always keeping the lowest frequency)?


Jan
-- 

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 4 2007 13:36, Wander Winkelhorst wrote:
>
> Hi,
>
> I also have the same problem. Except in my case the box is stable
> for a couple of hours before it locks up hard. I did some digging
> around, and from what I found on the internet, it seems that having
> busmaster DMA devices causes this problem.
>
Does it happen for you when you use the 'powersave' governor
(always keeping the lowest frequency)?


Jan
-- 

Re: cpufreq longhaul locks up

> Hi,
Hello all
> 
> I found that setting the cpufreq governor to ondemand making the box 
> lock up solid in 2.6.20.2 and 2.6.21 after a few seconds.
> [...]

I can't explain this. Some motherboards are running fine, some don't.
I'm running longhaul too. It is working fine. No lockups at all. 
So far I heard only about one Epia which had problems with longhaul. 
It was almost like my Epia but older.
What is possible:
- some chipsets revisions are broken and aren't blocking DMA,
- special setup is required, some versions of BIOS are doing 
necessary things, some don't,
- some chipsets revisions are broken and drivers are not aware. At 
the beginning Unichrome driver was causing lockups on my machine, but 
Openchrome was fine. Longhaul may trigger, somehow, other hardware bug. 

Anyway I don't belive in Longhaul anymore. It is working for me. It is 
working for others. And it isn't working for others. VIA isn't supporting 
this driver. Support came only from Centaur and Dave Jones. If special 
setup is required for north/southbridge then it is necessary to have 
documentation. I will not receive it from VIA.

I'm asking about advice. Make it BROKEN again? Add "big fat warning" and 
"enable" option? I know that this is Dave Jones decision, but I would like 
to heard what people are thinking, becuse I've been messing a lot with 
this driver.

Btw. I've been writting many times: if You want to use ondemand with 
Longhaul You don't need cpufreq at all. It is just one another cool 
gadget for You. Longhaul wasn't designed to change frequency often. 
It has big latency and requires so much preparation that it isn't worth 
if You don't need to save power or cool down CPU. 

Sorry for bad English
Rafał


----------------------------------------------------------------------
NIE KUPUJ!!!
...zanim nie porownasz cen >> http://link.interia.pl/f1a5e

Re: cpufreq longhaul locks up

[Rafał Bilski]

> Hi,
Hello all
> 
> I found that setting the cpufreq governor to ondemand making the box 
> lock up solid in 2.6.20.2 and 2.6.21 after a few seconds.
> [...]

I can't explain this. Some motherboards are running fine, some don't.
I'm running longhaul too. It is working fine. No lockups at all. 
So far I heard only about one Epia which had problems with longhaul. 
It was almost like my Epia but older.
What is possible:
- some chipsets revisions are broken and aren't blocking DMA,
- special setup is required, some versions of BIOS are doing 
necessary things, some don't,
- some chipsets revisions are broken and drivers are not aware. At 
the beginning Unichrome driver was causing lockups on my machine, but 
Openchrome was fine. Longhaul may trigger, somehow, other hardware bug. 

Anyway I don't belive in Longhaul anymore. It is working for me. It is 
working for others. And it isn't working for others. VIA isn't supporting 
this driver. Support came only from Centaur and Dave Jones. If special 
setup is required for north/southbridge then it is necessary to have 
documentation. I will not receive it from VIA.

I'm asking about advice. Make it BROKEN again? Add "big fat warning" and 
"enable" option? I know that this is Dave Jones decision, but I would like 
to heard what people are thinking, becuse I've been messing a lot with 
this driver.

Btw. I've been writting many times: if You want to use ondemand with 
Longhaul You don't need cpufreq at all. It is just one another cool 
gadget for You. Longhaul wasn't designed to change frequency often. 
It has big latency and requires so much preparation that it isn't worth 
if You don't need to save power or cool down CPU. 

Sorry for bad English
Rafał


----------------------------------------------------------------------
NIE KUPUJ!!!
...zanim nie porownasz cen >> http://link.interia.pl/f1a5e

Re: cpufreq longhaul locks up

[Chuck Ebbert]

Rafał Bilski wrote:
>> Hi,
> Hello all
>> I found that setting the cpufreq governor to ondemand making the box 
>> lock up solid in 2.6.20.2 and 2.6.21 after a few seconds.
>> [...]
> 
> I can't explain this. Some motherboards are running fine, some don't.
> I'm running longhaul too. It is working fine. No lockups at all. 
> So far I heard only about one Epia which had problems with longhaul. 
> It was almost like my Epia but older.
> What is possible:
> - some chipsets revisions are broken and aren't blocking DMA,
> - special setup is required, some versions of BIOS are doing 
> necessary things, some don't,
> - some chipsets revisions are broken and drivers are not aware. At 
> the beginning Unichrome driver was causing lockups on my machine, but 
> Openchrome was fine. Longhaul may trigger, somehow, other hardware bug. 
> 

The below is in the cpufreq git tree.

(Maybe also ondemand needs to be disabled for Longhaul?)

From: Rafal Bilski <rafalbilski@interia.pl>
Date: Sun, 22 Apr 2007 10:26:04 +0000 (+0200)
Subject: [CPUFREQ] Longhaul - Revert Longhaul ver. 2
X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fdavej%2Fcpufreq.git;a=commitdiff_plain;h=07844252ffd81ec192a62014bada1016c9703765

[CPUFREQ] Longhaul - Revert Longhaul ver. 2

There is something wrong with this code. It needs more
testing. It is better to disable it for now because support
for some machines will be broken.

Signed-off-by: Rafal Bilski <rafalbilski@interia.pl>
Signed-off-by: Dave Jones <davej@redhat.com>
---

diff --git a/arch/i386/kernel/cpu/cpufreq/longhaul.c b/arch/i386/kernel/cpu/cpufreq/longhaul.c
index e5fee72..a3df9c0 100644
--- a/arch/i386/kernel/cpu/cpufreq/longhaul.c
+++ b/arch/i386/kernel/cpu/cpufreq/longhaul.c
@@ -683,7 +683,7 @@ static int __init longhaul_cpu_init(struct cpufreq_policy *policy)
 				sizeof(samuel2_eblcr));
 			break;
 		case 1 ... 15:
-			longhaul_version = TYPE_LONGHAUL_V2;
+			longhaul_version = TYPE_LONGHAUL_V1;
 			if (c->x86_mask < 8) {
 				cpu_model = CPU_SAMUEL2;
 				cpuname = "C3 'Samuel 2' [C5B]";

Re: cpufreq longhaul locks up

[Chuck Ebbert]

Rafał Bilski wrote:
>> Hi,
> Hello all
>> I found that setting the cpufreq governor to ondemand making the box 
>> lock up solid in 2.6.20.2 and 2.6.21 after a few seconds.
>> [...]
> 
> I can't explain this. Some motherboards are running fine, some don't.
> I'm running longhaul too. It is working fine. No lockups at all. 
> So far I heard only about one Epia which had problems with longhaul. 
> It was almost like my Epia but older.
> What is possible:
> - some chipsets revisions are broken and aren't blocking DMA,
> - special setup is required, some versions of BIOS are doing 
> necessary things, some don't,
> - some chipsets revisions are broken and drivers are not aware. At 
> the beginning Unichrome driver was causing lockups on my machine, but 
> Openchrome was fine. Longhaul may trigger, somehow, other hardware bug. 
> 

The below is in the cpufreq git tree.

(Maybe also ondemand needs to be disabled for Longhaul?)

From: Rafal Bilski <rafalbilski@interia.pl>
Date: Sun, 22 Apr 2007 10:26:04 +0000 (+0200)
Subject: [CPUFREQ] Longhaul - Revert Longhaul ver. 2
X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fdavej%2Fcpufreq.git;a=commitdiff_plain;h=07844252ffd81ec192a62014bada1016c9703765

[CPUFREQ] Longhaul - Revert Longhaul ver. 2

There is something wrong with this code. It needs more
testing. It is better to disable it for now because support
for some machines will be broken.

Signed-off-by: Rafal Bilski <rafalbilski@interia.pl>
Signed-off-by: Dave Jones <davej@redhat.com>
---

diff --git a/arch/i386/kernel/cpu/cpufreq/longhaul.c b/arch/i386/kernel/cpu/cpufreq/longhaul.c
index e5fee72..a3df9c0 100644
--- a/arch/i386/kernel/cpu/cpufreq/longhaul.c
+++ b/arch/i386/kernel/cpu/cpufreq/longhaul.c
@@ -683,7 +683,7 @@ static int __init longhaul_cpu_init(struct cpufreq_policy *policy)
 				sizeof(samuel2_eblcr));
 			break;
 		case 1 ... 15:
-			longhaul_version = TYPE_LONGHAUL_V2;
+			longhaul_version = TYPE_LONGHAUL_V1;
 			if (c->x86_mask < 8) {
 				cpu_model = CPU_SAMUEL2;
 				cpuname = "C3 'Samuel 2' [C5B]";

Re: cpufreq longhaul locks up

[Rafał Bilski]

> [...]
> 
> The below is in the cpufreq git tree.
> 
> (Maybe also ondemand needs to be disabled for Longhaul?)
Would be great. Is this possible? Just kidding. I don't like 
ondemand. It isn't doing anything good for C3. There is no 
significant difference between halt/ACPI C2/ACPI C3 on 533Mhz 
and 999MHz. Difference is when processor is *running*. With 
ondemand it is running very short on 533MHz. When I was 
testing ondemand my CPU was running max f most the time. With 
conservative it is running min f most the time. CPU is much 
cooler and it is running fanless for most the time. Best part 
is that conservative is doing more transitions when system is 
busy because it needs to do all the steps (66MHz step for me) 
from min (533) to max (999). Ondemand is doing only one 
transition - from min to max.
> From: Rafal Bilski <rafalbilski@interia.pl>
> Date: Sun, 22 Apr 2007 10:26:04 +0000 (+0200)
> Subject: [CPUFREQ] Longhaul - Revert Longhaul ver. 2
> X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fdavej%2Fcpufreq.git;a=commitdiff_plain;h=07844252ffd81ec192a62014bada1016c9703765
> 
> [CPUFREQ] Longhaul - Revert Longhaul ver. 2
> 
No. It is new thing in 2.6.21 which will stop Longhaul 
from changing frequencies. As usual tested by email. Works 
for one, not works for others. Without this patch older 
C3 will not change frequency. Longhaul will be disabled for 
good. But both processors which we are talking about are 
"Powersaver". New.



----------------------------------------------------------------------
Wicie, rozumicie....
Zobacz >>> http://link.interia.pl/f1a74

Re: cpufreq longhaul locks up

[Wander Winkelhorst]

[-- Attachment #1: Type: text/plain, Size: 4383 bytes --]

On 5/4/07, Rafał Bilski <rafalbilski@interia.pl> wrote:
> > Hi,
> Hello all

Hi Rafał,

> >
> > I found that setting the cpufreq governor to ondemand making the box
> > lock up solid in 2.6.20.2 and 2.6.21 after a few seconds.
> > [...]
>
> I can't explain this. Some motherboards are running fine, some don't.
> I'm running longhaul too. It is working fine. No lockups at all.
> So far I heard only about one Epia which had problems with longhaul.
> It was almost like my Epia but older.
> What is possible:
> - some chipsets revisions are broken and aren't blocking DMA,
> - special setup is required, some versions of BIOS are doing
> necessary things, some don't,

Which BIOS are you using?

> Anyway I don't belive in Longhaul anymore. It is working for me. It is
> working for others. And it isn't working for others. VIA isn't supporting
> this driver. Support came only from Centaur and Dave Jones. If special
> setup is required for north/southbridge then it is necessary to have
> documentation. I will not receive it from VIA.

That is to bad, I was all excited that someone was doing work on the
longhaul code again.

>
> Btw. I've been writting many times: if You want to use ondemand with
> Longhaul You don't need cpufreq at all. It is just one another cool
> gadget for You. Longhaul wasn't designed to change frequency often.
> It has big latency and requires so much preparation that it isn't worth
> if You don't need to save power or cool down CPU.

What should I use instead of ondemand? I do want to save power and
have my machine run cooler (I have a htpc that is on 24/7, it's
running kind of hot and allready has blown a PSU)

Does the userspace governor have the same problems? (I'd guess so)

>
> Sorry for bad English
> Rafał
>

I'd like to take this opportunity to thank you for the work you have
already done on cpufreq!
So: thanks Rafał! I appreciate it!

 In case someone wants some more info about my box, here it is:

It's a Via SP1300 MiniATX.

/proc/cpuinfo:

processor       : 0
vendor_id       : CentaurHauls
cpu family      : 6
model           : 9
model name      : VIA Nehemiah
stepping        : 8
cpu MHz         : 1330.000
cache size      : 64 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr cx8 sep mtrr pge cmov pat mmx
fxsr sse rng rng_en ace ace_en
bogomips        : 2668.66
clflush size    : 32

lspci:
0000:00:00.0 Host bridge: VIA Technologies, Inc. CN400/PM880 Host Bridge
0000:00:00.1 Host bridge: VIA Technologies, Inc. CN400/PM880 Host Bridge
0000:00:00.2 Host bridge: VIA Technologies, Inc. CN400/PM880 Host Bridge
0000:00:00.3 Host bridge: VIA Technologies, Inc. CN400/PM880 Host Bridge
0000:00:00.4 Host bridge: VIA Technologies, Inc. CN400/PM880 Host Bridge
0000:00:00.7 Host bridge: VIA Technologies, Inc. CN400/PM880 Host Bridge
0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
0000:00:0d.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394
Host Controller (rev 80)
0000:00:0f.0 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
0000:00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB
1.1 Controller (rev 81)
0000:00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB
1.1 Controller (rev 81)
0000:00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB
1.1 Controller (rev 81)
0000:00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB
1.1 Controller (rev 81)
0000:00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
0000:00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge
[KT600/K8T800/K8T890 South]
0000:00:11.5 Multimedia audio controller: VIA Technologies, Inc.
VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
0000:00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102
[Rhine-II] (rev 78)
0000:00:14.0 Multimedia video controller: Internext Compression Inc
iTVC16 (CX23416) MPEG-2 Encoder (rev 01)
0000:01:00.0 VGA compatible controller: VIA Technologies, Inc. S3
Unichrome Pro VGA Adapter (rev 02)

uname -a:

Linux doodspoor 2.6.20.6 #1 PREEMPT Sun Apr 8 15:06:34 CEST 2007 i686 GNU/Linux

I am using the onboard mpeg2 hardware decoder with the Openchrome drivers

I hope this helps someone
Wander.

[-- Attachment #2: Type: text/plain, Size: 147 bytes --]

_______________________________________________
Cpufreq mailing list
Cpufreq@lists.linux.org.uk
http://lists.linux.org.uk/mailman/listinfo/cpufreq

Re: cpufreq longhaul locks up

[Rafał Bilski]

> Hi Rafał,
Hi 
>> >
>> > I found that setting the cpufreq governor to ondemand making the box
>> > lock up solid in 2.6.20.2 and 2.6.21 after a few seconds.
>> > [...]
>>
>> I can't explain this. Some motherboards are running fine, some don't.
>> I'm running longhaul too. It is working fine. No lockups at all.
>> So far I heard only about one Epia which had problems with longhaul.
>> It was almost like my Epia but older.
>> What is possible:
>> - some chipsets revisions are broken and aren't blocking DMA,
>> - special setup is required, some versions of BIOS are doing
>> necessary things, some don't,
> 
> Which BIOS are you using?
Latest beta BIOS which was supposed to fix Linux "DMA timeout" bug. 
I don't remember exact version, It wasn't fixing this bug.
> [...]
>> Btw. I've been writting many times: if You want to use ondemand with
>> Longhaul You don't need cpufreq at all. It is just one another cool
>> gadget for You. Longhaul wasn't designed to change frequency often.
>> It has big latency and requires so much preparation that it isn't worth
>> if You don't need to save power or cool down CPU.
> 
> What should I use instead of ondemand? I do want to save power and
> have my machine run cooler (I have a htpc that is on 24/7, it's
> running kind of hot and allready has blown a PSU)
I'm using conservative. It is allowing me to turn off fan with 
bigger cooler borowed from AMD CPU.
> Does the userspace governor have the same problems? (I'd guess so)
For testing I was using userspace governor. 1s interval, Min to max. 
1s interval. Max to min.
I don't like userspace programs. Most of them is doing exactly the 
same thing which ondemand does.
> I'd like to take this opportunity to thank you for the work you have
> already done on cpufreq!
> So: thanks Rafał! I appreciate it!
Thanks, but it isn't working. It isn't good job. It isn't nothing more 
then luck.
> [...] 
> I am using the onboard mpeg2 hardware decoder with the Openchrome drivers
Me too. Works great. As usual not thanks to VIA, but good developers 
diging in binary drivers.
> I hope this helps someone
> Wander.
Regards
Rafał


----------------------------------------------------------------------- Linda jako gospodyni domowa - zobacz!!!
>>> http://link.interia.pl/f1a79

Re: cpufreq longhaul locks up

[Rafał Bilski]

> Hi Rafał,
Hi 
>> >
>> > I found that setting the cpufreq governor to ondemand making the box
>> > lock up solid in 2.6.20.2 and 2.6.21 after a few seconds.
>> > [...]
>>
>> I can't explain this. Some motherboards are running fine, some don't.
>> I'm running longhaul too. It is working fine. No lockups at all.
>> So far I heard only about one Epia which had problems with longhaul.
>> It was almost like my Epia but older.
>> What is possible:
>> - some chipsets revisions are broken and aren't blocking DMA,
>> - special setup is required, some versions of BIOS are doing
>> necessary things, some don't,
> 
> Which BIOS are you using?
Latest beta BIOS which was supposed to fix Linux "DMA timeout" bug. 
I don't remember exact version, It wasn't fixing this bug.
> [...]
>> Btw. I've been writting many times: if You want to use ondemand with
>> Longhaul You don't need cpufreq at all. It is just one another cool
>> gadget for You. Longhaul wasn't designed to change frequency often.
>> It has big latency and requires so much preparation that it isn't worth
>> if You don't need to save power or cool down CPU.
> 
> What should I use instead of ondemand? I do want to save power and
> have my machine run cooler (I have a htpc that is on 24/7, it's
> running kind of hot and allready has blown a PSU)
I'm using conservative. It is allowing me to turn off fan with 
bigger cooler borowed from AMD CPU.
> Does the userspace governor have the same problems? (I'd guess so)
For testing I was using userspace governor. 1s interval, Min to max. 
1s interval. Max to min.
I don't like userspace programs. Most of them is doing exactly the 
same thing which ondemand does.
> I'd like to take this opportunity to thank you for the work you have
> already done on cpufreq!
> So: thanks Rafał! I appreciate it!
Thanks, but it isn't working. It isn't good job. It isn't nothing more 
then luck.
> [...] 
> I am using the onboard mpeg2 hardware decoder with the Openchrome drivers
Me too. Works great. As usual not thanks to VIA, but good developers 
diging in binary drivers.
> I hope this helps someone
> Wander.
Regards
Rafał


----------------------------------------------------------------------- Linda jako gospodyni domowa - zobacz!!!
>>> http://link.interia.pl/f1a79

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 4 2007 19:08, Rafał Bilski wrote:
>
>Btw. I've been writting many times: if You want to use ondemand with 
>Longhaul You don't need cpufreq at all.

Does VIA Nehemiah do hardware-driven autoregulation like Transmeta
Crusoe too? (I suspect no, have not seen that happen.)

>It is just one another cool gadget for You.
>Longhaul wasn't designed to change frequency often. 

Is there a way I can start with a specific governor (powersave) right
from the start so that all devices that Linux will initialize assume
the CPU runs at <choose something> MHz?

>It has big latency and requires so much preparation that it isn't worth 
>if You don't need to save power or cool down CPU. 

I found frequency switching on my VIA to be fast enough.


Jan
-- 

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 4 2007 19:08, Rafał Bilski wrote:
>
>Btw. I've been writting many times: if You want to use ondemand with 
>Longhaul You don't need cpufreq at all.

Does VIA Nehemiah do hardware-driven autoregulation like Transmeta
Crusoe too? (I suspect no, have not seen that happen.)

>It is just one another cool gadget for You.
>Longhaul wasn't designed to change frequency often. 

Is there a way I can start with a specific governor (powersave) right
from the start so that all devices that Linux will initialize assume
the CPU runs at <choose something> MHz?

>It has big latency and requires so much preparation that it isn't worth 
>if You don't need to save power or cool down CPU. 

I found frequency switching on my VIA to be fast enough.


Jan
-- 

Re: cpufreq longhaul locks up

[Rafał Bilski]

>> Btw. I've been writting many times: if You want to use ondemand with 
>> Longhaul You don't need cpufreq at all.
> 
> Does VIA Nehemiah do hardware-driven autoregulation like Transmeta
> Crusoe too? (I suspect no, have not seen that happen.)
No.
>> It is just one another cool gadget for You.
>> Longhaul wasn't designed to change frequency often. 
> 
> Is there a way I can start with a specific governor (powersave) right
> from the start so that all devices that Linux will initialize assume
> the CPU runs at <choose something> MHz?
You have to search cpufreq mail list archives. I think that I saw 
patch recently.
>> It has big latency and requires so much preparation that it isn't worth 
>> if You don't need to save power or cool down CPU. 
> 
> I found frequency switching on my VIA to be fast enough.
Timer frequency equal to 1000Hz? 
> Jan
Rafa³



----------------------------------------------------------------------
Wicie, rozumicie....
Zobacz >>> http://link.interia.pl/f1a74

Re: cpufreq longhaul locks up

[Rafał Bilski]

>> Btw. I've been writting many times: if You want to use ondemand with 
>> Longhaul You don't need cpufreq at all.
> 
> Does VIA Nehemiah do hardware-driven autoregulation like Transmeta
> Crusoe too? (I suspect no, have not seen that happen.)
No.
>> It is just one another cool gadget for You.
>> Longhaul wasn't designed to change frequency often. 
> 
> Is there a way I can start with a specific governor (powersave) right
> from the start so that all devices that Linux will initialize assume
> the CPU runs at <choose something> MHz?
You have to search cpufreq mail list archives. I think that I saw 
patch recently.
>> It has big latency and requires so much preparation that it isn't worth 
>> if You don't need to save power or cool down CPU. 
> 
> I found frequency switching on my VIA to be fast enough.
Timer frequency equal to 1000Hz? 
> Jan
Rafał



----------------------------------------------------------------------
Wicie, rozumicie....
Zobacz >>> http://link.interia.pl/f1a74

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 4 2007 22:11, Rafał Bilski wrote:
>> 
>>> It has big latency and requires so much preparation that it isn't worth 
>>> if You don't need to save power or cool down CPU. 
>> 
>> I found frequency switching on my VIA to be fast enough.
>
>Timer frequency equal to 1000Hz? 

The regular irq0 timer ticks at 250. What I meant is that I do not have
to wait more than 0.5 seconds for cpufreq-set to finish.


Jan
-- 

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 4 2007 22:11, Rafał Bilski wrote:
>> 
>>> It has big latency and requires so much preparation that it isn't worth 
>>> if You don't need to save power or cool down CPU. 
>> 
>> I found frequency switching on my VIA to be fast enough.
>
>Timer frequency equal to 1000Hz? 

The regular irq0 timer ticks at 250. What I meant is that I do not have
to wait more than 0.5 seconds for cpufreq-set to finish.


Jan
-- 

Re: cpufreq longhaul locks up

[john stultz]

On Fri, 2007-05-04 at 12:16 +0200, Jan Engelhardt wrote:
> Hi,
> 
> 
> I found that setting the cpufreq governor to ondemand making the box 
> lock up solid in 2.6.20.2 and 2.6.21 after a few seconds. Sysrq 
> does not work anymore, and the last messages are:
> 
> May  3 19:16:58 cn kernel: longhaul: VIA C3 'Nehemiah C' [C5P] CPU 
> detected.  Powersaver supported.
> May  3 19:16:58 cn kernel: longhaul: Using northbridge support.
> May  3 19:17:22 cn kernel: Time: acpi_pm clocksource has been installed.
> May  3 19:17:22 cn kernel: Clocksource tsc unstable (delta = -136422685 
> ns)

What happens if you boot wihtout the ondemand governor but w/ clocksource=acpi_pm ? 


thanks
-john

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 4 2007 13:37, john stultz wrote:
>> 
>> I found that setting the cpufreq governor to ondemand making the box 
>> lock up solid in 2.6.20.2 and 2.6.21 after a few seconds. Sysrq 
>> does not work anymore, and the last messages are:
>> 
>> May  3 19:16:58 cn kernel: longhaul: VIA C3 'Nehemiah C' [C5P] CPU 
>> detected.  Powersaver supported.
>> May  3 19:16:58 cn kernel: longhaul: Using northbridge support.
>> May  3 19:17:22 cn kernel: Time: acpi_pm clocksource has been installed.
>> May  3 19:17:22 cn kernel: Clocksource tsc unstable (delta = -136422685 
>> ns)
>
>What happens if you boot wihtout the ondemand governor but w/
>clocksource=acpi_pm ?

I always let it boot with the default gov (performance), then
use cpufreq-set to change it.

acpi_pm+performance behaves like tsc+performance, which works

When switching from tsc+performance to (tsc+)ondemand, acpi_pm gets
used because of the unstable tsc (of course, since we changed
frequency and the cpu does NOT have constant_tsc), so it's
becoming acpi_pm+ondemand naturally.

Switching from acpi_pm+performance to acpi_pm+ondemand also
locks up after a few minutes.


Jan
-- 

Re: cpufreq longhaul locks up

[john stultz]

On Fri, 2007-05-04 at 23:02 +0200, Jan Engelhardt wrote:
> On May 4 2007 13:37, john stultz wrote:
> >> 
> >> I found that setting the cpufreq governor to ondemand making the box 
> >> lock up solid in 2.6.20.2 and 2.6.21 after a few seconds. Sysrq 
> >> does not work anymore, and the last messages are:
> >> 
> >> May  3 19:16:58 cn kernel: longhaul: VIA C3 'Nehemiah C' [C5P] CPU 
> >> detected.  Powersaver supported.
> >> May  3 19:16:58 cn kernel: longhaul: Using northbridge support.
> >> May  3 19:17:22 cn kernel: Time: acpi_pm clocksource has been installed.
> >> May  3 19:17:22 cn kernel: Clocksource tsc unstable (delta = -136422685 
> >> ns)
> >
> >What happens if you boot wihtout the ondemand governor but w/
> >clocksource=acpi_pm ?
> 
> I always let it boot with the default gov (performance), then
> use cpufreq-set to change it.
> 
> acpi_pm+performance behaves like tsc+performance, which works
> 
> When switching from tsc+performance to (tsc+)ondemand, acpi_pm gets
> used because of the unstable tsc (of course, since we changed
> frequency and the cpu does NOT have constant_tsc), so it's
> becoming acpi_pm+ondemand naturally.

Ok. I just wanted to make sure it wasn't the ACPI PM that was broken and
when the system switched to it it was causing the hang.

> Switching from acpi_pm+performance to acpi_pm+ondemand also
> locks up after a few minutes.

Yep. Sounds like an ondemand issue. Thanks for verifying this for me.

-john

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 4 2007 15:49, john stultz wrote:
>
>> Switching from acpi_pm+performance to acpi_pm+ondemand also
>> locks up after a few minutes.
>
>Yep. Sounds like an ondemand issue. Thanks for verifying this for me.

Nah, it also happens with cpufreq_powersave. I just need to check 
through some archives and try booting with governor=powersave so that it 
always stays low. Though, lowering the frequency does not really buy any 
temperature improvement in 60 seconds, so I don't think I will need 
cpufreq anyway (other processors have a noticable jump in core 
temperature between 100%idle and a busy loop).


Jan
-- 

Re: cpufreq longhaul locks up

[Rafał Bilski]

>>> Switching from acpi_pm+performance to acpi_pm+ondemand also
>>> locks up after a few minutes.
>> Yep. Sounds like an ondemand issue. Thanks for verifying this for me.
> 
> Nah, it also happens with cpufreq_powersave. I just need to check 
> through some archives and try booting with governor=powersave so that it 
> always stays low. 
You have a lockup when switching from other governor to powersave? Or if  
You are using it for some time?


----------------------------------------------------------------------
Wicie, rozumicie....
Zobacz >>> http://link.interia.pl/f1a74

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 5 2007 06:03, Rafał Bilski wrote:
>
>>>> Switching from acpi_pm+performance to acpi_pm+ondemand also
>>>> locks up after a few minutes.
>>> Yep. Sounds like an ondemand issue. Thanks for verifying this for me.
>> 
>> Nah, it also happens with cpufreq_powersave. I just need to check 
>> through some archives and try booting with governor=powersave so that it 
>> always stays low. 
>
>You have a lockup when switching from other governor to powersave? Or if  
>You are using it for some time?

After some time.



Jan
-- 

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 5 2007 06:03, Rafał Bilski wrote:
>
>>>> Switching from acpi_pm+performance to acpi_pm+ondemand also
>>>> locks up after a few minutes.
>>> Yep. Sounds like an ondemand issue. Thanks for verifying this for me.
>> 
>> Nah, it also happens with cpufreq_powersave. I just need to check 
>> through some archives and try booting with governor=powersave so that it 
>> always stays low. 
>
>You have a lockup when switching from other governor to powersave? Or if  
>You are using it for some time?

After some time.



Jan
-- 

Re: cpufreq longhaul locks up

[Rafał Bilski]

>>>>> Switching from acpi_pm+performance to acpi_pm+ondemand also
>>>>> locks up after a few minutes.
>>>> Yep. Sounds like an ondemand issue. Thanks for verifying this for me.
>>> Nah, it also happens with cpufreq_powersave. I just need to check 
>>> through some archives and try booting with governor=powersave so that it 
>>> always stays low. 
>> You have a lockup when switching from other governor to powersave? Or if  
>> You are using it for some time?
> 
> After some time.
Don't understand me wrong, but this is very weird. I think that powersave is  
changing frequency only one time, when it is loaded. I will look into its code 
to be sure. Probably Longhaul is making something what isn't allowed or there 
is hardware bug somewhere.
> Jan
Rafa³



----------------------------------------------------------------------
Po meczu.....kurde...:)
>>> http://link.interia.pl/f1a72

Re: cpufreq longhaul locks up

[Rafał Bilski]

>>>>> Switching from acpi_pm+performance to acpi_pm+ondemand also
>>>>> locks up after a few minutes.
>>>> Yep. Sounds like an ondemand issue. Thanks for verifying this for me.
>>> Nah, it also happens with cpufreq_powersave. I just need to check 
>>> through some archives and try booting with governor=powersave so that it 
>>> always stays low. 
>> You have a lockup when switching from other governor to powersave? Or if  
>> You are using it for some time?
> 
> After some time.
Don't understand me wrong, but this is very weird. I think that powersave is  
changing frequency only one time, when it is loaded. I will look into its code 
to be sure. Probably Longhaul is making something what isn't allowed or there 
is hardware bug somewhere.
> Jan
Rafał



----------------------------------------------------------------------
Po meczu.....kurde...:)
>>> http://link.interia.pl/f1a72

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 5 2007 15:58, Rafał Bilski wrote:
>>>>>> Switching from acpi_pm+performance to acpi_pm+ondemand also
>>>>>> locks up after a few minutes.
>>>>> Yep. Sounds like an ondemand issue. Thanks for verifying this for me.
>>>> Nah, it also happens with cpufreq_powersave. I just need to check 
>>>> through some archives and try booting with governor=powersave so that it 
>>>> always stays low. 
>>> You have a lockup when switching from other governor to powersave? Or if  
>>> You are using it for some time?
>> 
>> After some time.

>Don't understand me wrong, but this is very weird. I think that
>powersave is changing frequency only one time, when it is loaded. I
>will look into its code to be sure. Probably Longhaul is making
>something what isn't allowed or there is hardware bug somewhere.

I patched Kconfig and the kernel source so that powersave
is the only governor available at boot
(CONFIG_CPU_FREQ_GOV_POWERSAVE=y, CPU_FREQ_DEFAULT_GOV_POWERSAVE=y,
CONFIG_X86_LONGHAUL=y) -- also locks up.

I'll keep you posted.


Jan
-- 

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 5 2007 15:58, Rafał Bilski wrote:
>>>>>> Switching from acpi_pm+performance to acpi_pm+ondemand also
>>>>>> locks up after a few minutes.
>>>>> Yep. Sounds like an ondemand issue. Thanks for verifying this for me.
>>>> Nah, it also happens with cpufreq_powersave. I just need to check 
>>>> through some archives and try booting with governor=powersave so that it 
>>>> always stays low. 
>>> You have a lockup when switching from other governor to powersave? Or if  
>>> You are using it for some time?
>> 
>> After some time.

>Don't understand me wrong, but this is very weird. I think that
>powersave is changing frequency only one time, when it is loaded. I
>will look into its code to be sure. Probably Longhaul is making
>something what isn't allowed or there is hardware bug somewhere.

I patched Kconfig and the kernel source so that powersave
is the only governor available at boot
(CONFIG_CPU_FREQ_GOV_POWERSAVE=y, CPU_FREQ_DEFAULT_GOV_POWERSAVE=y,
CONFIG_X86_LONGHAUL=y) -- also locks up.

I'll keep you posted.


Jan
-- 

Re: cpufreq longhaul locks up

[David Johnson]

On Friday 04 May 2007 11:16, you wrote:
>
> I found that setting the cpufreq governor to ondemand making the box
> lock up solid in 2.6.20.2 and 2.6.21 after a few seconds. Sysrq
> does not work anymore, and the last messages are:
>

I've been seeing a similar issue, but with a few differences.
I'm running 2.6.21.1 on the same CPU as yourself:

longhaul: VIA C3 'Nehemiah C' [C5P] CPU detected.  Powersaver supported.
longhaul: Using ACPI support.

It seems that longhaul on my system is 'using ACPI support' whereas on yours 
it is 'using northbridge support'. I'm getting lockups after approx. 2-3 
hours using the ondemand governor. It has no problem changing the clock 
speed, and runs at the minimum speed most of the time.

I seem to recall that I get an oops when my system locks-up (the system runs 
headless normally, so it isn't easy to check). I'll investigate.

Regards,
David.

-- 
David Johnson
www.david-web.co.uk

Re: cpufreq longhaul locks up

[David Johnson]

On Friday 04 May 2007 11:16, you wrote:
>
> I found that setting the cpufreq governor to ondemand making the box
> lock up solid in 2.6.20.2 and 2.6.21 after a few seconds. Sysrq
> does not work anymore, and the last messages are:
>

I've been seeing a similar issue, but with a few differences.
I'm running 2.6.21.1 on the same CPU as yourself:

longhaul: VIA C3 'Nehemiah C' [C5P] CPU detected.  Powersaver supported.
longhaul: Using ACPI support.

It seems that longhaul on my system is 'using ACPI support' whereas on yours 
it is 'using northbridge support'. I'm getting lockups after approx. 2-3 
hours using the ondemand governor. It has no problem changing the clock 
speed, and runs at the minimum speed most of the time.

I seem to recall that I get an oops when my system locks-up (the system runs 
headless normally, so it isn't easy to check). I'll investigate.

Regards,
David.

-- 
David Johnson
www.david-web.co.uk

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 4 2007 23:20, David Johnson wrote:
>
>longhaul: VIA C3 'Nehemiah C' [C5P] CPU detected.  Powersaver supported.
>longhaul: Using ACPI support.
>
>It seems that longhaul on my system is 'using ACPI support' whereas on yours 
>it is 'using northbridge support'. I'm getting lockups after approx. 2-3 
>hours using the ondemand governor. It has no problem changing the clock 
>speed, and runs at the minimum speed most of the time.

I had tried this:

-  if (enable_arbiter_disable()) {
+  if (0 && enable_arbiter_disable()) {

to skip enabling the northbridge. Unfortunately, I do not seem to have
southbridge or ACPI support.

>I seem to recall that I get an oops when my system locks-up (the system runs 
>headless normally, so it isn't easy to check). I'll investigate.

I think I did not see any oops, though I (1) did not redirect the
kernel output back to tty0 [the distro moves it away to tty11]
so I might have missed something, but (2) netconsole did not send
anything. IIRC, the kernel still catches sysrq if it paniced, i.e.
as a result of not finding a proper root device during startup;
but no sysrq, so it seems a harder lockup. Maybe I should try
without all the modules loaded and/or disable some hw in the bios.


Jan
-- 

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 4 2007 23:20, David Johnson wrote:
>
>longhaul: VIA C3 'Nehemiah C' [C5P] CPU detected.  Powersaver supported.
>longhaul: Using ACPI support.
>
>It seems that longhaul on my system is 'using ACPI support' whereas on yours 
>it is 'using northbridge support'. I'm getting lockups after approx. 2-3 
>hours using the ondemand governor. It has no problem changing the clock 
>speed, and runs at the minimum speed most of the time.

I had tried this:

-  if (enable_arbiter_disable()) {
+  if (0 && enable_arbiter_disable()) {

to skip enabling the northbridge. Unfortunately, I do not seem to have
southbridge or ACPI support.

>I seem to recall that I get an oops when my system locks-up (the system runs 
>headless normally, so it isn't easy to check). I'll investigate.

I think I did not see any oops, though I (1) did not redirect the
kernel output back to tty0 [the distro moves it away to tty11]
so I might have missed something, but (2) netconsole did not send
anything. IIRC, the kernel still catches sysrq if it paniced, i.e.
as a result of not finding a proper root device during startup;
but no sysrq, so it seems a harder lockup. Maybe I should try
without all the modules loaded and/or disable some hw in the bios.


Jan
-- 

Re: cpufreq longhaul locks up

[Rafał Bilski]

Jan,

Can You send output of x86info program and output of 
lspci command? Longhaul wasn't working for You since 2.6.18 right?
I'm going to work now, but I will be available after 14:00 UTC.

If You have problem with longhaul+powersave there may be one thing 
related. When I started to change Longhaul it was causing lockups 
on Epia 800. I added transition protection. Helped, but not for 
long. After one or two hours machine locked up anyway. I found 
datasheet in Google and changed "disable BMDMA bit on PCI device" to 
northbridge support. Problem fixed. Somehow CLE133 chipset didn't 
like touching "BMDMA master" bits.
Second: I didn't get answer from VIA why they are blocking ACPI C3 on CPU's 
faster then 1GHz. I don't know if it is standard practice and if
Intel and AMD are doing it too.

Things worth checking: disable PREEMPT, change it to "Voluntary preemption". 
Check if using conservative governor makes any difference. I know that 
this may sound strange, but transition latency is directly proportional to 
difference between current and destination frequency. Maybe for faster 
processors it isn't allowed to change frequency directly from min to max?

Rafa³



----------------------------------------------------------------------
NIE KUPUJ!!!
...zanim nie porownasz cen >> http://link.interia.pl/f1a5e

Re: cpufreq longhaul locks up

[Rafał Bilski]

Jan,

Can You send output of x86info program and output of 
lspci command? Longhaul wasn't working for You since 2.6.18 right?
I'm going to work now, but I will be available after 14:00 UTC.

If You have problem with longhaul+powersave there may be one thing 
related. When I started to change Longhaul it was causing lockups 
on Epia 800. I added transition protection. Helped, but not for 
long. After one or two hours machine locked up anyway. I found 
datasheet in Google and changed "disable BMDMA bit on PCI device" to 
northbridge support. Problem fixed. Somehow CLE133 chipset didn't 
like touching "BMDMA master" bits.
Second: I didn't get answer from VIA why they are blocking ACPI C3 on CPU's 
faster then 1GHz. I don't know if it is standard practice and if
Intel and AMD are doing it too.

Things worth checking: disable PREEMPT, change it to "Voluntary preemption". 
Check if using conservative governor makes any difference. I know that 
this may sound strange, but transition latency is directly proportional to 
difference between current and destination frequency. Maybe for faster 
processors it isn't allowed to change frequency directly from min to max?

Rafał



----------------------------------------------------------------------
NIE KUPUJ!!!
...zanim nie porownasz cen >> http://link.interia.pl/f1a5e

Re: cpufreq longhaul locks up

[Wander Winkelhorst]

[-- Attachment #1: Type: text/plain, Size: 1222 bytes --]

On 5/5/07, Rafał Bilski <rafalbilski@interia.pl> wrote:
> Jan,
>
> Can You send output of x86info program and output of
> lspci command? Longhaul wasn't working for You since 2.6.18 right?
> I'm going to work now, but I will be available after 14:00 UTC.
>

Output from x86info (I know you didn't ask me, but hey, information
wants to be free)

x86info v1.20.  Dave Jones 2001-2006
Feedback to <davej@redhat.com>.

Found 1 CPU
--------------------------------------------------------------------------
Family: 6 Model: 9 Stepping: 8
CPU Model : VIA C3 (Nehemiah) [C5XL]
Feature flags:
 fpu vme de pse tsc msr cx8 sep mtrr pge cmov pat mmx fxsr sse
Extended feature flags:


> Things worth checking: disable PREEMPT, change it to "Voluntary preemption".
> Check if using conservative governor makes any difference. I know that
> this may sound strange, but transition latency is directly proportional to
> difference between current and destination frequency. Maybe for faster
> processors it isn't allowed to change frequency directly from min to max?
>
> Rafał

My girlfriend is going to hate you for getting me to tinker with the
HTPC again :)

Will check if these suggestions help. Probably on sunday though..

Wander.

[-- Attachment #2: Type: text/plain, Size: 147 bytes --]

_______________________________________________
Cpufreq mailing list
Cpufreq@lists.linux.org.uk
http://lists.linux.org.uk/mailman/listinfo/cpufreq

Re: cpufreq longhaul locks up

[Rafał Bilski]

>> Can You send output of x86info program and output of
>> lspci command? Longhaul wasn't working for You since 2.6.18 right?
> 
> Output from x86info (I know you didn't ask me, but hey, information
> wants to be free)
> 
> x86info v1.20.  Dave Jones 2001-2006
> Feedback to <davej@redhat.com>.
> 
> Found 1 CPU
> --------------------------------------------------------------------------
> Family: 6 Model: 9 Stepping: 8
> CPU Model : VIA C3 (Nehemiah) [C5XL]
> Feature flags:
> fpu vme de pse tsc msr cx8 sep mtrr pge cmov pat mmx fxsr sse
> Extended feature flags:
Sorry. I'm asking You now. Can You send entire output?


----------------------------------------------------------------------
NIE KUPUJ!!!
...zanim nie porownasz cen >> http://link.interia.pl/f1a5e

Re: cpufreq longhaul locks up

[Rafał Bilski]

>> Can You send output of x86info program and output of
>> lspci command? Longhaul wasn't working for You since 2.6.18 right?
> 
> Output from x86info (I know you didn't ask me, but hey, information
> wants to be free)
> 
> x86info v1.20.  Dave Jones 2001-2006
> Feedback to <davej@redhat.com>.
> 
> Found 1 CPU
> --------------------------------------------------------------------------
> Family: 6 Model: 9 Stepping: 8
> CPU Model : VIA C3 (Nehemiah) [C5XL]
> Feature flags:
> fpu vme de pse tsc msr cx8 sep mtrr pge cmov pat mmx fxsr sse
> Extended feature flags:
Sorry. I'm asking You now. Can You send entire output?


----------------------------------------------------------------------
NIE KUPUJ!!!
...zanim nie porownasz cen >> http://link.interia.pl/f1a5e

Re: cpufreq longhaul locks up

[Rafał Bilski]

I found one line which wasn't were it should be. Probably this will not 
fix Your problem with powersave governor, but it is a bit related. 
Looks like Longhaul isn't skipping frequency transtition when it is asked 
to set f which is already set. Now after first transition it will not 
try to set same frequency again. Second part contains some magic 
because I don't have CN400 datasheet. It is NDA protected :-( Should 
print You one byte in hex and will try to set one register. I don't 
know if anything will change but it is worth testing.

Fingers crossed
Rafa³

---
 arch/i386/kernel/cpu/cpufreq/longhaul.c |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/i386/kernel/cpu/cpufreq/longhaul.c b/arch/i386/kernel/cpu/cpufreq/longhaul.c
index 2b030d6..5548e5b 100644
--- a/arch/i386/kernel/cpu/cpufreq/longhaul.c
+++ b/arch/i386/kernel/cpu/cpufreq/longhaul.c
@@ -88,6 +88,7 @@ static int clock_ratio[32];
 static int eblcr_table[32];
 static int longhaul_version;
 static struct cpufreq_frequency_table *longhaul_table;
+static unsigned int old_ratio = -1;
 
 #ifdef CONFIG_CPU_FREQ_DEBUG
 static char speedbuffer[8];
@@ -252,7 +253,6 @@ static void longhaul_setstate(unsigned int clock_ratio_index)
 {
 	int speed, mult;
 	struct cpufreq_freqs freqs;
-	static unsigned int old_ratio=-1;
 	unsigned long flags;
 	unsigned int pic1_mask, pic2_mask;
 
@@ -603,7 +603,12 @@ static int enable_arbiter_disable(void)
 		/* Find CN400 V-Link host bridge */
 		if (dev == NULL)
 			dev = pci_find_device(PCI_VENDOR_ID_VIA, 0x7259, NULL);
-
+		if (dev != NULL) {
+			pci_read_config_byte(dev, 0x47, &pci_cmd);
+			printk(KERN_INFO PFX "%#02x\n", pci_cmd);
+			pci_cmd |= 0xf;
+			pci_write_config_byte(dev, 0x47, pci_cmd);
+		}
 	}
 	if (dev != NULL) {
 		/* Enable access to port 0x22 */
-- 



----------------------------------------------------------------------
Po meczu.....kurde...:)
>>> http://link.interia.pl/f1a72

Re: cpufreq longhaul locks up

[Rafał Bilski]

I found one line which wasn't were it should be. Probably this will not 
fix Your problem with powersave governor, but it is a bit related. 
Looks like Longhaul isn't skipping frequency transtition when it is asked 
to set f which is already set. Now after first transition it will not 
try to set same frequency again. Second part contains some magic 
because I don't have CN400 datasheet. It is NDA protected :-( Should 
print You one byte in hex and will try to set one register. I don't 
know if anything will change but it is worth testing.

Fingers crossed
Rafał

---
 arch/i386/kernel/cpu/cpufreq/longhaul.c |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/i386/kernel/cpu/cpufreq/longhaul.c b/arch/i386/kernel/cpu/cpufreq/longhaul.c
index 2b030d6..5548e5b 100644
--- a/arch/i386/kernel/cpu/cpufreq/longhaul.c
+++ b/arch/i386/kernel/cpu/cpufreq/longhaul.c
@@ -88,6 +88,7 @@ static int clock_ratio[32];
 static int eblcr_table[32];
 static int longhaul_version;
 static struct cpufreq_frequency_table *longhaul_table;
+static unsigned int old_ratio = -1;
 
 #ifdef CONFIG_CPU_FREQ_DEBUG
 static char speedbuffer[8];
@@ -252,7 +253,6 @@ static void longhaul_setstate(unsigned int clock_ratio_index)
 {
 	int speed, mult;
 	struct cpufreq_freqs freqs;
-	static unsigned int old_ratio=-1;
 	unsigned long flags;
 	unsigned int pic1_mask, pic2_mask;
 
@@ -603,7 +603,12 @@ static int enable_arbiter_disable(void)
 		/* Find CN400 V-Link host bridge */
 		if (dev == NULL)
 			dev = pci_find_device(PCI_VENDOR_ID_VIA, 0x7259, NULL);
-
+		if (dev != NULL) {
+			pci_read_config_byte(dev, 0x47, &pci_cmd);
+			printk(KERN_INFO PFX "%#02x\n", pci_cmd);
+			pci_cmd |= 0xf;
+			pci_write_config_byte(dev, 0x47, pci_cmd);
+		}
 	}
 	if (dev != NULL) {
 		/* Enable access to port 0x22 */
-- 



----------------------------------------------------------------------
Po meczu.....kurde...:)
>>> http://link.interia.pl/f1a72

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 5 2007 19:48, Rafał Bilski wrote:
>
>I found one line which wasn't were it should be. Probably this will not 
>fix Your problem with powersave governor, but it is a bit related. 
>Looks like Longhaul isn't skipping frequency transtition when it is asked 
>to set f which is already set. Now after first transition it will not 
>try to set same frequency again. Second part contains some magic 
>because I don't have CN400 datasheet. It is NDA protected :-( Should 
>print You one byte in hex and will try to set one register. I don't 
>know if anything will change but it is worth testing.

Did not help unfortunately. The output the printk line generated was
  longhaul: 0x0

(Strangely enough, %#02x with glibc outputs "00", not "0x0".
And I would have expected "0x00". Subtleties of the kernel 
printk/glibc?)



Jan
-- 

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 5 2007 19:48, Rafał Bilski wrote:
>
>I found one line which wasn't were it should be. Probably this will not 
>fix Your problem with powersave governor, but it is a bit related. 
>Looks like Longhaul isn't skipping frequency transtition when it is asked 
>to set f which is already set. Now after first transition it will not 
>try to set same frequency again. Second part contains some magic 
>because I don't have CN400 datasheet. It is NDA protected :-( Should 
>print You one byte in hex and will try to set one register. I don't 
>know if anything will change but it is worth testing.

Did not help unfortunately. The output the printk line generated was
  longhaul: 0x0

(Strangely enough, %#02x with glibc outputs "00", not "0x0".
And I would have expected "0x00". Subtleties of the kernel 
printk/glibc?)



Jan
-- 

Re: cpufreq longhaul locks up

[Rafał Bilski]

>> I found one line which wasn't were it should be. Probably this will not 
>> fix Your problem with powersave governor, but it is a bit related. 
>> Looks like Longhaul isn't skipping frequency transtition when it is asked 
>> to set f which is already set. Now after first transition it will not 
>> try to set same frequency again. Second part contains some magic 
>> because I don't have CN400 datasheet. It is NDA protected :-( Should 
>> print You one byte in hex and will try to set one register. I don't 
>> know if anything will change but it is worth testing.
> 
> Did not help unfortunately. The output the printk line generated was
>   longhaul: 0x0
> 
> (Strangely enough, %#02x with glibc outputs "00", not "0x0".
> And I would have expected "0x00". Subtleties of the kernel 
> printk/glibc?)
:-/ Weird. Nothing new in datasheet. Longhaul MSR seems to be OK too. 
Would be good to check if PLL really can go downto x4,0. Can You 
limit minimal CPU multiplier to 5,0 and check if is stable? If it 
is check 4,5.
Please send me below part of Your dmesg too:
CPU: After generic identify, caps: 0381b83f 00000000 00000000 00000000 00000000 00000000 00000000
CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line)
CPU: L2 Cache: 64K (32 bytes/line)
CPU: After all inits, caps: 0381b93f 00000000 00000000 00000000 00000000 000000dd 00000000

"dd" is very important here.
> Jan
Rafa³



----------------------------------------------------------------------
Kasia Cichopek eksponuje biust  
>>> http://link.interia.pl/f1a6f

Re: cpufreq longhaul locks up

[Rafał Bilski]

>> I found one line which wasn't were it should be. Probably this will not 
>> fix Your problem with powersave governor, but it is a bit related. 
>> Looks like Longhaul isn't skipping frequency transtition when it is asked 
>> to set f which is already set. Now after first transition it will not 
>> try to set same frequency again. Second part contains some magic 
>> because I don't have CN400 datasheet. It is NDA protected :-( Should 
>> print You one byte in hex and will try to set one register. I don't 
>> know if anything will change but it is worth testing.
> 
> Did not help unfortunately. The output the printk line generated was
>   longhaul: 0x0
> 
> (Strangely enough, %#02x with glibc outputs "00", not "0x0".
> And I would have expected "0x00". Subtleties of the kernel 
> printk/glibc?)
:-/ Weird. Nothing new in datasheet. Longhaul MSR seems to be OK too. 
Would be good to check if PLL really can go downto x4,0. Can You 
limit minimal CPU multiplier to 5,0 and check if is stable? If it 
is check 4,5.
Please send me below part of Your dmesg too:
CPU: After generic identify, caps: 0381b83f 00000000 00000000 00000000 00000000 00000000 00000000
CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line)
CPU: L2 Cache: 64K (32 bytes/line)
CPU: After all inits, caps: 0381b93f 00000000 00000000 00000000 00000000 000000dd 00000000

"dd" is very important here.
> Jan
Rafał



----------------------------------------------------------------------
Kasia Cichopek eksponuje biust  
>>> http://link.interia.pl/f1a6f

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 5 2007 21:58, Rafał Bilski wrote:
>
>>> I found one line which wasn't were it should be. Probably this will not 
>>> fix Your problem with powersave governor, but it is a bit related. 
>>> Looks like Longhaul isn't skipping frequency transtition when it is asked 
>>> to set f which is already set. Now after first transition it will not 
>>> try to set same frequency again. Second part contains some magic 
>>> because I don't have CN400 datasheet. It is NDA protected :-( Should 
>>> print You one byte in hex and will try to set one register. I don't 
>>> know if anything will change but it is worth testing.
>> 
>> Did not help unfortunately. The output the printk line generated was
>>   longhaul: 0x0
>> 
>> (Strangely enough, %#02x with glibc outputs "00", not "0x0".
>> And I would have expected "0x00". Subtleties of the kernel 
>> printk/glibc?)
>
>:-/ Weird. Nothing new in datasheet. Longhaul MSR seems to be OK too. 
>Would be good to check if PLL really can go downto x4,0. Can You 
>limit minimal CPU multiplier to 5,0 and check if is stable? If it 
>is check 4,5.

How do I do that? I tried `cpufreq-set -d 665 -u 665` (x5.0), but that
changed the frequency to 532 (x4.0).

I can set the CPU frequency in the BIOS, from x3.0 to x16.0, in x0.5
steps (base frequency is 133, DIMM freq is 266).

[ Actually, the values are a bit off,

cn:~ # cpufreq-info 
cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to http://bugs.opensuse.org, please.
analyzing CPU 0:
  driver: longhaul
  CPUs which need to switch frequency at the same time: 0
  hardware limits: 532 MHz - 731 MHz
  available frequency steps: 532 MHz, 598 MHz, 731 MHz, 665 MHz
  available cpufreq governors: performance
  current policy: frequency should be within 532 MHz and 731 MHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 731 MHz (asserted by call to hardware).

]

The BIOS default is x5.5, producing 733 MHz. With longhaul/cpufreq,
I can then choose from between 533 MHz (x4.0) and the value that was
set in the BIOS.



>Please send me below part of Your dmesg too:
>CPU: After generic identify, caps: 0381b83f 00000000 00000000 00000000 00000000 00000000 00000000
>CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line)
>CPU: L2 Cache: 64K (32 bytes/line)
>CPU: After all inits, caps: 0381b93f 00000000 00000000 00000000 00000000 000000dd 00000000

CPU: After generic identify, caps:
0381b03f 00000000 00000000 00000000 00000000 00000000 00000000
CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line)
CPU: L2 Cache: 64K (32 bytes/line)
CPU: After all inits, caps: 0381b13f 00000000 00000000 00000000 00000000
000000dd 00000000



Jan
-- 

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 5 2007 21:58, Rafał Bilski wrote:
>
>>> I found one line which wasn't were it should be. Probably this will not 
>>> fix Your problem with powersave governor, but it is a bit related. 
>>> Looks like Longhaul isn't skipping frequency transtition when it is asked 
>>> to set f which is already set. Now after first transition it will not 
>>> try to set same frequency again. Second part contains some magic 
>>> because I don't have CN400 datasheet. It is NDA protected :-( Should 
>>> print You one byte in hex and will try to set one register. I don't 
>>> know if anything will change but it is worth testing.
>> 
>> Did not help unfortunately. The output the printk line generated was
>>   longhaul: 0x0
>> 
>> (Strangely enough, %#02x with glibc outputs "00", not "0x0".
>> And I would have expected "0x00". Subtleties of the kernel 
>> printk/glibc?)
>
>:-/ Weird. Nothing new in datasheet. Longhaul MSR seems to be OK too. 
>Would be good to check if PLL really can go downto x4,0. Can You 
>limit minimal CPU multiplier to 5,0 and check if is stable? If it 
>is check 4,5.

How do I do that? I tried `cpufreq-set -d 665 -u 665` (x5.0), but that
changed the frequency to 532 (x4.0).

I can set the CPU frequency in the BIOS, from x3.0 to x16.0, in x0.5
steps (base frequency is 133, DIMM freq is 266).

[ Actually, the values are a bit off,

cn:~ # cpufreq-info 
cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to http://bugs.opensuse.org, please.
analyzing CPU 0:
  driver: longhaul
  CPUs which need to switch frequency at the same time: 0
  hardware limits: 532 MHz - 731 MHz
  available frequency steps: 532 MHz, 598 MHz, 731 MHz, 665 MHz
  available cpufreq governors: performance
  current policy: frequency should be within 532 MHz and 731 MHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 731 MHz (asserted by call to hardware).

]

The BIOS default is x5.5, producing 733 MHz. With longhaul/cpufreq,
I can then choose from between 533 MHz (x4.0) and the value that was
set in the BIOS.



>Please send me below part of Your dmesg too:
>CPU: After generic identify, caps: 0381b83f 00000000 00000000 00000000 00000000 00000000 00000000
>CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line)
>CPU: L2 Cache: 64K (32 bytes/line)
>CPU: After all inits, caps: 0381b93f 00000000 00000000 00000000 00000000 000000dd 00000000

CPU: After generic identify, caps:
0381b03f 00000000 00000000 00000000 00000000 00000000 00000000
CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line)
CPU: L2 Cache: 64K (32 bytes/line)
CPU: After all inits, caps: 0381b13f 00000000 00000000 00000000 00000000
000000dd 00000000



Jan
-- 

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 5 2007 21:58, Rafał Bilski wrote:

>:-/ Weird. Nothing new in datasheet. Longhaul MSR seems to be OK too. 
>Would be good to check if PLL really can go downto x4,0. Can You 
>limit minimal CPU multiplier to 5,0 and check if is stable? If it 
>is check 4,5.

I directly wrote to /sys/devices/system/cpu/cpu0/cpufreq, which
worked better than `cpufreq -u xxx -d xxx`.

Lockup after 9 minutes. (Perhaps the longest time so far.)


Jan
-- 

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 5 2007 21:58, Rafał Bilski wrote:

>:-/ Weird. Nothing new in datasheet. Longhaul MSR seems to be OK too. 
>Would be good to check if PLL really can go downto x4,0. Can You 
>limit minimal CPU multiplier to 5,0 and check if is stable? If it 
>is check 4,5.

I directly wrote to /sys/devices/system/cpu/cpu0/cpufreq, which
worked better than `cpufreq -u xxx -d xxx`.

Lockup after 9 minutes. (Perhaps the longest time so far.)


Jan
-- 

Re: cpufreq longhaul locks up

[Rafał Bilski]

Is patch attached below making things better?
You should see in log that You are using VT8235 support now.

---
 arch/i386/kernel/cpu/cpufreq/longhaul.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/i386/kernel/cpu/cpufreq/longhaul.c b/arch/i386/kernel/cpu/cpufreq/longhaul.c
index 5548e5b..c3c9096 100644
--- a/arch/i386/kernel/cpu/cpufreq/longhaul.c
+++ b/arch/i386/kernel/cpu/cpufreq/longhaul.c
@@ -635,6 +635,8 @@ static int longhaul_setup_vt8235(void)
 
 	/* Find VT8235 southbridge */
 	dev = pci_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8235, NULL);
+	if (dev == NULL)
+		dev = pci_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8237, NULL);
 	if (dev != NULL) {
 		/* Set transition time to max */
 		pci_read_config_byte(dev, 0xec, &pci_cmd);
@@ -771,11 +773,11 @@ static int __init longhaul_cpu_init(struct cpufreq_policy *policy)
 		}
 	}
 	/* Check if northbridge is friendly */
-	if (enable_arbiter_disable()) {
+/*	if (enable_arbiter_disable()) {
 		longhaul_flags |= USE_NORTHBRIDGE;
 		goto print_support_type;
 	}
-	/* Use VT8235 southbridge if present */
+*/	/* Use VT8235 southbridge if present */
 	if (longhaul_version == TYPE_POWERSAVER && vt8235_present) {
 		longhaul_flags |= USE_VT8235;
 		goto print_support_type;
-- 



----------------------------------------------------------------------
Wicie, rozumicie....
Zobacz >>> http://link.interia.pl/f1a74

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 5 2007 23:32, Rafał Bilski wrote:
>
>Is patch attached below making things better?
>You should see in log that You are using VT8235 support now.

Yeah, but locks up too.



Jan
-- 

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 5 2007 23:32, Rafał Bilski wrote:
>
>Is patch attached below making things better?
>You should see in log that You are using VT8235 support now.

Yeah, but locks up too.



Jan
-- 

Re: cpufreq longhaul locks up

[Rafał Bilski]

>> :-/ Weird. Nothing new in datasheet. Longhaul MSR seems to be OK too. 
>> Would be good to check if PLL really can go downto x4,0. Can You 
>> limit minimal CPU multiplier to 5,0 and check if is stable? If it 
>> is check 4,5.
> 
> I directly wrote to /sys/devices/system/cpu/cpu0/cpufreq, which
> worked better than `cpufreq -u xxx -d xxx`.
> 
> Lockup after 9 minutes. (Perhaps the longest time so far.)
Can You send me Your entire boot log with performance governor set? 
> Jan
Rafa³


----------------------------------------------------------------------
Po meczu.....kurde...:)
>>> http://link.interia.pl/f1a72

Re: cpufreq longhaul locks up

[Rafał Bilski]

>> :-/ Weird. Nothing new in datasheet. Longhaul MSR seems to be OK too. 
>> Would be good to check if PLL really can go downto x4,0. Can You 
>> limit minimal CPU multiplier to 5,0 and check if is stable? If it 
>> is check 4,5.
> 
> I directly wrote to /sys/devices/system/cpu/cpu0/cpufreq, which
> worked better than `cpufreq -u xxx -d xxx`.
> 
> Lockup after 9 minutes. (Perhaps the longest time so far.)
Can You send me Your entire boot log with performance governor set? 
> Jan
Rafał


----------------------------------------------------------------------
Po meczu.....kurde...:)
>>> http://link.interia.pl/f1a72

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 6 2007 07:12, Rafał Bilski wrote:

>>> :-/ Weird. Nothing new in datasheet. Longhaul MSR seems to be OK too. 
>>> Would be good to check if PLL really can go downto x4,0. Can You 
>>> limit minimal CPU multiplier to 5,0 and check if is stable? If it 
>>> is check 4,5.
>> 
>> I directly wrote to /sys/devices/system/cpu/cpu0/cpufreq, which
>> worked better than `cpufreq -u xxx -d xxx`.
>> 
>> Lockup after 9 minutes. (Perhaps the longest time so far.)
   [ this was with powersave compiled in and default]

>Can You send me Your entire boot log with performance governor set? 

This is the default kernel with performance gov:

Inspecting /boot/System.map-2.6.21-3-default
Loaded 24898 symbols from /boot/System.map-2.6.21-3-default.
Symbols match kernel version 2.6.21.
No module symbols loaded - kernel modules not enabled.

klogd 1.4.1, log source = ksyslog started.
<5>Linux version 2.6.21-3-default (geeko@buildhost) (gcc version 4.1.3 20070413 (prerelease) (SUSE Linux)) #1 SMP Thu Apr 26 11:49:27 UTC 2007
<6>BIOS-provided physical RAM map:
<4>sanitize start
<4>sanitize end
<4>copy_e820_map() start: 0000000000000000 size: 000000000009f800 end: 000000000009f800 type: 1
<4>copy_e820_map() type is E820_RAM
<4>copy_e820_map() start: 000000000009f800 size: 0000000000000800 end: 00000000000a0000 type: 2
<4>copy_e820_map() start: 00000000000f0000 size: 0000000000010000 end: 0000000000100000 type: 2
<4>copy_e820_map() start: 0000000000100000 size: 000000000eef0000 end: 000000000eff0000 type: 1
<4>copy_e820_map() type is E820_RAM
<4>copy_e820_map() start: 000000000eff0000 size: 0000000000003000 end: 000000000eff3000 type: 4
<4>copy_e820_map() start: 000000000eff3000 size: 000000000000d000 end: 000000000f000000 type: 3
<4>copy_e820_map() start: 00000000fec00000 size: 0000000001400000 end: 0000000100000000 type: 2
<4> BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
<4> BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
<4> BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
<4> BIOS-e820: 0000000000100000 - 000000000eff0000 (usable)
<4> BIOS-e820: 000000000eff0000 - 000000000eff3000 (ACPI NVS)
<4> BIOS-e820: 000000000eff3000 - 000000000f000000 (ACPI data)
<4> BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
<5>0MB HIGHMEM available.
<5>239MB LOWMEM available.
<7>Entering add_active_range(0, 0, 61424) 0 entries of 256 used
<4>Zone PFN ranges:
<4>  DMA             0 ->     4096
<4>  Normal       4096 ->    61424
<4>  HighMem     61424 ->    61424
<4>early_node_map[1] active PFN ranges
<4>    0:        0 ->    61424
<7>On node 0 totalpages: 61424
<7>  DMA zone: 32 pages used for memmap
<7>  DMA zone: 0 pages reserved
<7>  DMA zone: 4064 pages, LIFO batch:0
<7>  Normal zone: 447 pages used for memmap
<7>  Normal zone: 56881 pages, LIFO batch:15
<7>  HighMem zone: 0 pages used for memmap
<6>DMI 2.3 present.
<6>Using APIC driver default
<4>ACPI: RSDP 000F7630, 0014 (r0 CM400 )
<4>ACPI: RSDT 0EFF3040, 0028 (r1 CM400  AWRDACPI 42302E31 AWRD        0)
<4>ACPI: FACP 0EFF30C0, 0074 (r1 CM400  AWRDACPI 42302E31 AWRD        0)
<4>ACPI: DSDT 0EFF3180, 5433 (r1 CM400  AWRDACPI     1000 MSFT  100000E)
<4>ACPI: FACS 0EFF0000, 0040
<6>ACPI: PM-Timer IO Port: 0x408
<4>Allocating PCI resources starting at 10000000 (gap: 0f000000:efc00000)
<4>Built 1 zonelists.  Total pages: 60945
<5>Kernel command line: root=/dev/disk/by-id/scsi-SATA_iCreate_CF_Card000000001-part1 rootflags=usrquota,grpquota
<6>No local APIC present or hardware disabled
<7>mapped APIC to ffffd000 (011ea000)
<6>Enabling fast FPU save and restore... done.
<6>Enabling unmasked SIMD FPU exception support... done.
<6>Initializing CPU#0
<4>PID hash table entries: 1024 (order: 10, 4096 bytes)
<4>Detected 733.024 MHz processor.
<4>Console: colour VGA+ 80x25
<4>Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
<4>Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
<6>Memory: 237444k/245696k available (1735k kernel code, 7628k reserved, 721k data, 188k init, 0k highmem)
<4>virtual kernel memory layout:
<4>    fixmap  : 0xffdf5000 - 0xfffff000   (2088 kB)
<4>    pkmap   : 0xff800000 - 0xffc00000   (4096 kB)
<4>    vmalloc : 0xcf800000 - 0xff7fe000   ( 767 MB)
<4>    lowmem  : 0xc0000000 - 0xceff0000   ( 239 MB)
<4>      .init : 0xc036e000 - 0xc039d000   ( 188 kB)
<4>      .data : 0xc02b1c67 - 0xc0366374   ( 721 kB)
<4>      .text : 0xc0100000 - 0xc02b1c67   (1735 kB)
<4>Checking if this processor honours the WP bit even in supervisor mode... Ok.
<4>Calibrating delay using timer specific routine.. 1468.17 BogoMIPS (lpj=2936355)
<6>Security Framework v1.0.0 initialized
<4>Mount-cache hash table entries: 512
<7>CPU: After generic identify, caps: 0381b03f 00000000 00000000 00000000 00000000 00000000 00000000
<6>CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line)
<6>CPU: L2 Cache: 64K (32 bytes/line)
<7>CPU: After all inits, caps: 0381b13f 00000000 00000000 00000000 00000000 000000dd 00000000
<4>Compat vDSO mapped to ffffe000.
<6>Checking 'hlt' instruction... OK.
<6>SMP alternatives: switching to UP code
<6>Freeing SMP alternatives: 12k freed
<6>ACPI: Core revision 20070126
<4>ACPI: setting ELCR to 0200 (from 12a0)
<4>CPU0: Centaur VIA Nehemiah stepping 08
<5>SMP motherboard not detected.
<5>Local APIC not detected. Using dummy APIC emulation.
<6>Brought up 1 CPUs
<6>NET: Registered protocol family 16
<6>ACPI: bus type pci registered
<6>PCI: PCI BIOS revision 2.10 entry at 0xf9f40, last bus=1
<6>PCI: Using configuration type 1
<4>Setting up standard PCI resources
<6>ACPI: Interpreter enabled
<6>ACPI: (supports S0 S1 S4 S5)
<6>ACPI: Using PIC for interrupt routing
<6>ACPI: PCI Root Bridge [PCI0] (0000:00)
<7>PCI: Probing PCI hardware (bus 00)
<6>PCI: MSI-K8T-Neo2Fir, attempting to turn soundcard ON
<6>PCI: MSI-K8T-Neo2Fir, soundcard on
<7>Boot video device is 0000:01:00.0
<7>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
<4>ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 *5 6 7 10 11 12)
<4>ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 10 11 *12)
<4>ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 *7 10 11 12)
<4>ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 10 11 12) *0, disabled.
<4>ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12) *0, disabled.
<4>ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 12) *0, disabled.
<4>ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 5 6 7 10 11 12) *0, disabled.
<4>ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 5 6 7 10 11 12) *0, disabled.
<4>ACPI: PCI Interrupt Link [ALKA] (IRQs *20), disabled.
<4>ACPI: PCI Interrupt Link [ALKB] (IRQs *21)
<4>ACPI: PCI Interrupt Link [ALKC] (IRQs *22)
<4>ACPI: PCI Interrupt Link [ALKD] (IRQs *23), disabled.
<6>Linux Plug and Play Support v0.97 (c) Adam Belay
<6>pnp: PnP ACPI init
<6>pnp: PnP ACPI: found 13 devices
<6>PnPBIOS: Disabled by ACPI PNP
<6>PCI: Using ACPI for IRQ routing
<6>PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
<6>pnp: 00:00: iomem range 0xd0000-0xd3fff has been reserved
<6>pnp: 00:00: iomem range 0xf0000-0xf7fff could not be reserved
<6>pnp: 00:00: iomem range 0xf8000-0xfbfff could not be reserved
<6>Time: tsc clocksource has been installed.
<6>pnp: 00:00: iomem range 0xfc000-0xfffff could not be reserved
<6>pnp: 00:02: ioport range 0x400-0x47f has been reserved
<6>pnp: 00:02: ioport range 0x500-0x50f has been reserved
<6>PCI: Bridge: 0000:00:01.0
<6>  IO window: disabled.
<6>  MEM window: f4000000-f5ffffff
<6>  PREFETCH window: f0000000-f3ffffff
<7>PCI: Setting latency timer of device 0000:00:01.0 to 64
<6>NET: Registered protocol family 2
<4>IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
<4>TCP established hash table entries: 8192 (order: 4, 98304 bytes)
<4>TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
<6>TCP: Hash tables configured (established 8192 bind 8192)
<6>TCP reno registered
<6>Unpacking initramfs... done
<6>Freeing initrd memory: 2325k freed
<6>audit: initializing netlink socket (disabled)
<5>audit(1178443810.948:1): initialized
<4>Total HugeTLB memory allocated, 0
<5>VFS: Disk quotas dquot_6.5.1
<4>Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
<6>io scheduler noop registered
<6>io scheduler anticipatory registered
<6>io scheduler deadline registered
<6>io scheduler cfq registered (default)
<6>PCI: Bypassing VIA 8237 APIC De-Assert Message
<6>isapnp: Scanning for PnP cards...
<6>isapnp: No Plug & Play device found
<6>Real Time Clock Driver v1.12ac
<6>Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
<6>serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
<6>serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
<6>serial8250: ttyS2 at I/O 0x3e8 (irq = 4) is a 16550A
<6>serial8250: ttyS3 at I/O 0x2e8 (irq = 3) is a 16550A
<6>00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
<6>00:09: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
<6>00:0a: ttyS2 at I/O 0x3e8 (irq = 10) is a 16550A
<6>00:0b: ttyS3 at I/O 0x2e8 (irq = 11) is a 16550A
<4>floppy0: no floppy controllers found
<6>input: Macintosh mouse button emulation as /class/input/input0
<6>PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
<4>PNP: PS/2 controller doesn't have AUX irq; using default 12
<6>serio: i8042 KBD port at 0x60,0x64 irq 1
<6>mice: PS/2 mouse device common for all mice
<6>input: PC Speaker as /class/input/input1
<6>NET: Registered protocol family 1
<4>Using IPI No-Shortcut mode
<6>Freeing unused kernel memory: 188k freed
<6>input: AT Translated Set 2 keyboard as /class/input/input2

initramfs begins here.

Creating device nodes with udev
Loading scsi_mod
Loading sd_mod
Loading libata
Loading pata_via
Loading xfs

<5>SCSI subsystem initialized
<7>libata version 2.20 loaded.
<7>pata_via 0000:00:0f.0: version 0.2.1
<4>ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 5
<7>PCI: setting IRQ 5 as level-triggered
<6>ACPI: PCI Interrupt 0000:00:0f.0[A] -> Link [LNKA] -> GSI 5 (level, low) -> IRQ 5
<6>PCI: VIA VLink IRQ fixup for 0000:00:0f.0, from 255 to 5
<6>ata1: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001e000 irq 14
<6>ata2: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001e008 irq 15
<6>scsi0 : pata_via
<6>ata1.00: CFA: iCreate CF Card, g1.01a, max PIO6
<6>ata1.00: 1024128 sectors, multi 0: LBA 
<6>ata1.00: configured for PIO4
<6>scsi1 : pata_via
<4>ATA: abnormal status 0x8 on port 0x00010177
<5>scsi 0:0:0:0: Direct-Access     ATA      iCreate CF Card  g1.0 PQ: 0 ANSI: 5
<5>SCSI device sda: 1024128 512-byte hdwr sectors (524 MB)
<5>sda: Write Protect is off
<7>sda: Mode Sense: 00 3a 00 00
<5>SCSI device sda: write cache: disabled, read cache: enabled, doesn't support DPO or FUA
<5>SCSI device sda: 1024128 512-byte hdwr sectors (524 MB)
<5>sda: Write Protect is off
<7>sda: Mode Sense: 00 3a 00 00
<5>SCSI device sda: write cache: disabled, read cache: enabled, doesn't support DPO or FUA
<6> sda: sda1 sda2
<5>sd 0:0:0:0: Attached scsi removable disk sda
<5>sd 0:0:0:0: Attached scsi generic sg0 type 0
<6>SGI XFS with ACLs, security attributes, realtime, large block numbers, no debug enabled
<6>SGI XFS Quota Management subsystem

Waiting for device /dev/disk/by-id/scsi-SATA_iCreate_CF_Card000000001-part1 to appear:  ok
fsck 1.40-WIP (14-Nov-2006)
[/bin/fsck.xfs (1) -- /] fsck.xfs -a /dev/disk/by-id/scsi-SATA_iCreate_CF_Card000000001-part1 
/bin/fsck.xfs: XFS file system.
fsck succeeded. Mounting root device read-write.
Mounting root /dev/disk/by-id/scsi-SATA_iCreate_CF_Card000000001-part1

<5>XFS mounting filesystem sda1
<7>Ending clean XFS mount for filesystem: sda1

/sbin/init begins here.
Starting udevd

<6>Linux agpgart interface v0.102 (c) Dave Jones
<6>agpgart: Detected VIA PM800/PN800/PM880/PN880 chipset
<6>agpgart: AGP aperture is 128M @ 0xe8000000
<6>8139too Fast Ethernet driver 0.9.28
<6>ACPI: PCI Interrupt 0000:00:0d.0[A] -> Link [LNKA] -> GSI 5 (level, low) -> IRQ 5
<6>eth0: RealTek RTL8139 at 0xcf820000, 00:14:0b:20:06:9d, IRQ 5
<7>eth0:  Identified 8139 chip type 'RTL-8100B/8139D'
<4>ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 12
<7>PCI: setting IRQ 12 as level-triggered
<6>ACPI: PCI Interrupt 0000:00:0e.0[A] -> Link [LNKB] -> GSI 12 (level, low) -> IRQ 12
<6>eth1: RealTek RTL8139 at 0xcf838000, 00:14:0b:20:06:9c, IRQ 12
<7>eth1:  Identified 8139 chip type 'RTL-8100B/8139D'
<6>usbcore: registered new interface driver usbfs
<6>usbcore: registered new interface driver hub
<6>usbcore: registered new device driver usb
<6>USB Universal Host Controller Interface driver v3.0
<6>ACPI: PCI Interrupt 0000:00:10.0[A] -> Link [LNKA] -> GSI 5 (level, low) -> IRQ 5
<6>uhci_hcd 0000:00:10.0: UHCI Host Controller
<6>uhci_hcd 0000:00:10.0: new USB bus registered, assigned bus number 1
<6>uhci_hcd 0000:00:10.0: irq 5, io base 0x0000dc00
<6>usb usb1: new device found, idVendor=0000, idProduct=0000
<6>usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1
<6>usb usb1: Product: UHCI Host Controller
<6>usb usb1: Manufacturer: Linux 2.6.21-3-default uhci_hcd
<6>usb usb1: SerialNumber: 0000:00:10.0
<6>usb usb1: configuration #1 chosen from 1 choice
<6>hub 1-0:1.0: USB hub found
<6>hub 1-0:1.0: 2 ports detected
<6>ACPI: PCI Interrupt 0000:00:10.1[A] -> Link [LNKA] -> GSI 5 (level, low) -> IRQ 5
<6>uhci_hcd 0000:00:10.1: UHCI Host Controller
<6>uhci_hcd 0000:00:10.1: new USB bus registered, assigned bus number 2
<6>uhci_hcd 0000:00:10.1: irq 5, io base 0x0000dd00
<6>usb usb2: new device found, idVendor=0000, idProduct=0000
<6>usb usb2: new device strings: Mfr=3, Product=2, SerialNumber=1
<6>usb usb2: Product: UHCI Host Controller
<6>usb usb2: Manufacturer: Linux 2.6.21-3-default uhci_hcd
<6>usb usb2: SerialNumber: 0000:00:10.1
<6>usb usb2: configuration #1 chosen from 1 choice
<6>hub 2-0:1.0: USB hub found
<6>hub 2-0:1.0: 2 ports detected
<6>ACPI: PCI Interrupt 0000:00:10.2[B] -> Link [LNKB] -> GSI 12 (level, low) -> IRQ 12
<6>uhci_hcd 0000:00:10.2: UHCI Host Controller
<6>uhci_hcd 0000:00:10.2: new USB bus registered, assigned bus number 3
<6>uhci_hcd 0000:00:10.2: irq 12, io base 0x0000de00
<6>usb usb3: new device found, idVendor=0000, idProduct=0000
<6>usb usb3: new device strings: Mfr=3, Product=2, SerialNumber=1
<6>usb usb3: Product: UHCI Host Controller
<6>usb usb3: Manufacturer: Linux 2.6.21-3-default uhci_hcd
<6>usb usb3: SerialNumber: 0000:00:10.2
<6>usb usb3: configuration #1 chosen from 1 choice
<6>hub 3-0:1.0: USB hub found
<6>hub 3-0:1.0: 2 ports detected
<6>ACPI: PCI Interrupt 0000:00:10.3[B] -> Link [LNKB] -> GSI 12 (level, low) -> IRQ 12
<6>uhci_hcd 0000:00:10.3: UHCI Host Controller
<6>uhci_hcd 0000:00:10.3: new USB bus registered, assigned bus number 4
<6>uhci_hcd 0000:00:10.3: irq 12, io base 0x0000df00
<6>usb usb4: new device found, idVendor=0000, idProduct=0000
<6>usb usb4: new device strings: Mfr=3, Product=2, SerialNumber=1
<6>usb usb4: Product: UHCI Host Controller
<6>usb usb4: Manufacturer: Linux 2.6.21-3-default uhci_hcd
<6>usb usb4: SerialNumber: 0000:00:10.3
<6>usb usb4: configuration #1 chosen from 1 choice
<6>hub 4-0:1.0: USB hub found
<6>hub 4-0:1.0: 2 ports detected
<4>ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 7
<7>PCI: setting IRQ 7 as level-triggered
<6>ACPI: PCI Interrupt 0000:00:10.4[C] -> Link [LNKC] -> GSI 7 (level, low) -> IRQ 7
<6>ehci_hcd 0000:00:10.4: EHCI Host Controller
<6>ehci_hcd 0000:00:10.4: new USB bus registered, assigned bus number 5
<6>ehci_hcd 0000:00:10.4: irq 7, io mem 0xf6002000
<6>ehci_hcd 0000:00:10.4: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
<6>usb usb5: new device found, idVendor=0000, idProduct=0000
<6>usb usb5: new device strings: Mfr=3, Product=2, SerialNumber=1
<6>usb usb5: Product: EHCI Host Controller
<6>usb usb5: Manufacturer: Linux 2.6.21-3-default ehci_hcd
<6>usb usb5: SerialNumber: 0000:00:10.4
<6>usb usb5: configuration #1 chosen from 1 choice
<6>hub 5-0:1.0: USB hub found
<6>hub 5-0:1.0: 8 ports detected
<6>rtc_cmos 00:05: rtc core: registered rtc_cmos as rtc0
<4>rtc_cmos: probe of 00:05 failed with error -16
<6>Adding 1016k swap on /dev/disk/by-id/scsi-SATA_iCreate_CF_Card000000001-part2.  Priority:-1 extents:1 across:1016k
<6>loop: loaded (max 8 devices)
etc.

longhaul is not loaded by default. Loading it gives

longhaul: VIA C3 'Nehemiah C' [C5P] CPU detected.  Powersaver supported.
longhaul: Using northbridge support.

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 6 2007 07:12, Rafał Bilski wrote:

>>> :-/ Weird. Nothing new in datasheet. Longhaul MSR seems to be OK too. 
>>> Would be good to check if PLL really can go downto x4,0. Can You 
>>> limit minimal CPU multiplier to 5,0 and check if is stable? If it 
>>> is check 4,5.
>> 
>> I directly wrote to /sys/devices/system/cpu/cpu0/cpufreq, which
>> worked better than `cpufreq -u xxx -d xxx`.
>> 
>> Lockup after 9 minutes. (Perhaps the longest time so far.)
   [ this was with powersave compiled in and default]

>Can You send me Your entire boot log with performance governor set? 

This is the default kernel with performance gov:

Inspecting /boot/System.map-2.6.21-3-default
Loaded 24898 symbols from /boot/System.map-2.6.21-3-default.
Symbols match kernel version 2.6.21.
No module symbols loaded - kernel modules not enabled.

klogd 1.4.1, log source = ksyslog started.
<5>Linux version 2.6.21-3-default (geeko@buildhost) (gcc version 4.1.3 20070413 (prerelease) (SUSE Linux)) #1 SMP Thu Apr 26 11:49:27 UTC 2007
<6>BIOS-provided physical RAM map:
<4>sanitize start
<4>sanitize end
<4>copy_e820_map() start: 0000000000000000 size: 000000000009f800 end: 000000000009f800 type: 1
<4>copy_e820_map() type is E820_RAM
<4>copy_e820_map() start: 000000000009f800 size: 0000000000000800 end: 00000000000a0000 type: 2
<4>copy_e820_map() start: 00000000000f0000 size: 0000000000010000 end: 0000000000100000 type: 2
<4>copy_e820_map() start: 0000000000100000 size: 000000000eef0000 end: 000000000eff0000 type: 1
<4>copy_e820_map() type is E820_RAM
<4>copy_e820_map() start: 000000000eff0000 size: 0000000000003000 end: 000000000eff3000 type: 4
<4>copy_e820_map() start: 000000000eff3000 size: 000000000000d000 end: 000000000f000000 type: 3
<4>copy_e820_map() start: 00000000fec00000 size: 0000000001400000 end: 0000000100000000 type: 2
<4> BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
<4> BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
<4> BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
<4> BIOS-e820: 0000000000100000 - 000000000eff0000 (usable)
<4> BIOS-e820: 000000000eff0000 - 000000000eff3000 (ACPI NVS)
<4> BIOS-e820: 000000000eff3000 - 000000000f000000 (ACPI data)
<4> BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
<5>0MB HIGHMEM available.
<5>239MB LOWMEM available.
<7>Entering add_active_range(0, 0, 61424) 0 entries of 256 used
<4>Zone PFN ranges:
<4>  DMA             0 ->     4096
<4>  Normal       4096 ->    61424
<4>  HighMem     61424 ->    61424
<4>early_node_map[1] active PFN ranges
<4>    0:        0 ->    61424
<7>On node 0 totalpages: 61424
<7>  DMA zone: 32 pages used for memmap
<7>  DMA zone: 0 pages reserved
<7>  DMA zone: 4064 pages, LIFO batch:0
<7>  Normal zone: 447 pages used for memmap
<7>  Normal zone: 56881 pages, LIFO batch:15
<7>  HighMem zone: 0 pages used for memmap
<6>DMI 2.3 present.
<6>Using APIC driver default
<4>ACPI: RSDP 000F7630, 0014 (r0 CM400 )
<4>ACPI: RSDT 0EFF3040, 0028 (r1 CM400  AWRDACPI 42302E31 AWRD        0)
<4>ACPI: FACP 0EFF30C0, 0074 (r1 CM400  AWRDACPI 42302E31 AWRD        0)
<4>ACPI: DSDT 0EFF3180, 5433 (r1 CM400  AWRDACPI     1000 MSFT  100000E)
<4>ACPI: FACS 0EFF0000, 0040
<6>ACPI: PM-Timer IO Port: 0x408
<4>Allocating PCI resources starting at 10000000 (gap: 0f000000:efc00000)
<4>Built 1 zonelists.  Total pages: 60945
<5>Kernel command line: root=/dev/disk/by-id/scsi-SATA_iCreate_CF_Card000000001-part1 rootflags=usrquota,grpquota
<6>No local APIC present or hardware disabled
<7>mapped APIC to ffffd000 (011ea000)
<6>Enabling fast FPU save and restore... done.
<6>Enabling unmasked SIMD FPU exception support... done.
<6>Initializing CPU#0
<4>PID hash table entries: 1024 (order: 10, 4096 bytes)
<4>Detected 733.024 MHz processor.
<4>Console: colour VGA+ 80x25
<4>Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
<4>Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
<6>Memory: 237444k/245696k available (1735k kernel code, 7628k reserved, 721k data, 188k init, 0k highmem)
<4>virtual kernel memory layout:
<4>    fixmap  : 0xffdf5000 - 0xfffff000   (2088 kB)
<4>    pkmap   : 0xff800000 - 0xffc00000   (4096 kB)
<4>    vmalloc : 0xcf800000 - 0xff7fe000   ( 767 MB)
<4>    lowmem  : 0xc0000000 - 0xceff0000   ( 239 MB)
<4>      .init : 0xc036e000 - 0xc039d000   ( 188 kB)
<4>      .data : 0xc02b1c67 - 0xc0366374   ( 721 kB)
<4>      .text : 0xc0100000 - 0xc02b1c67   (1735 kB)
<4>Checking if this processor honours the WP bit even in supervisor mode... Ok.
<4>Calibrating delay using timer specific routine.. 1468.17 BogoMIPS (lpj=2936355)
<6>Security Framework v1.0.0 initialized
<4>Mount-cache hash table entries: 512
<7>CPU: After generic identify, caps: 0381b03f 00000000 00000000 00000000 00000000 00000000 00000000
<6>CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line)
<6>CPU: L2 Cache: 64K (32 bytes/line)
<7>CPU: After all inits, caps: 0381b13f 00000000 00000000 00000000 00000000 000000dd 00000000
<4>Compat vDSO mapped to ffffe000.
<6>Checking 'hlt' instruction... OK.
<6>SMP alternatives: switching to UP code
<6>Freeing SMP alternatives: 12k freed
<6>ACPI: Core revision 20070126
<4>ACPI: setting ELCR to 0200 (from 12a0)
<4>CPU0: Centaur VIA Nehemiah stepping 08
<5>SMP motherboard not detected.
<5>Local APIC not detected. Using dummy APIC emulation.
<6>Brought up 1 CPUs
<6>NET: Registered protocol family 16
<6>ACPI: bus type pci registered
<6>PCI: PCI BIOS revision 2.10 entry at 0xf9f40, last bus=1
<6>PCI: Using configuration type 1
<4>Setting up standard PCI resources
<6>ACPI: Interpreter enabled
<6>ACPI: (supports S0 S1 S4 S5)
<6>ACPI: Using PIC for interrupt routing
<6>ACPI: PCI Root Bridge [PCI0] (0000:00)
<7>PCI: Probing PCI hardware (bus 00)
<6>PCI: MSI-K8T-Neo2Fir, attempting to turn soundcard ON
<6>PCI: MSI-K8T-Neo2Fir, soundcard on
<7>Boot video device is 0000:01:00.0
<7>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
<4>ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 *5 6 7 10 11 12)
<4>ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 10 11 *12)
<4>ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 *7 10 11 12)
<4>ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 10 11 12) *0, disabled.
<4>ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12) *0, disabled.
<4>ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 12) *0, disabled.
<4>ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 5 6 7 10 11 12) *0, disabled.
<4>ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 5 6 7 10 11 12) *0, disabled.
<4>ACPI: PCI Interrupt Link [ALKA] (IRQs *20), disabled.
<4>ACPI: PCI Interrupt Link [ALKB] (IRQs *21)
<4>ACPI: PCI Interrupt Link [ALKC] (IRQs *22)
<4>ACPI: PCI Interrupt Link [ALKD] (IRQs *23), disabled.
<6>Linux Plug and Play Support v0.97 (c) Adam Belay
<6>pnp: PnP ACPI init
<6>pnp: PnP ACPI: found 13 devices
<6>PnPBIOS: Disabled by ACPI PNP
<6>PCI: Using ACPI for IRQ routing
<6>PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
<6>pnp: 00:00: iomem range 0xd0000-0xd3fff has been reserved
<6>pnp: 00:00: iomem range 0xf0000-0xf7fff could not be reserved
<6>pnp: 00:00: iomem range 0xf8000-0xfbfff could not be reserved
<6>Time: tsc clocksource has been installed.
<6>pnp: 00:00: iomem range 0xfc000-0xfffff could not be reserved
<6>pnp: 00:02: ioport range 0x400-0x47f has been reserved
<6>pnp: 00:02: ioport range 0x500-0x50f has been reserved
<6>PCI: Bridge: 0000:00:01.0
<6>  IO window: disabled.
<6>  MEM window: f4000000-f5ffffff
<6>  PREFETCH window: f0000000-f3ffffff
<7>PCI: Setting latency timer of device 0000:00:01.0 to 64
<6>NET: Registered protocol family 2
<4>IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
<4>TCP established hash table entries: 8192 (order: 4, 98304 bytes)
<4>TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
<6>TCP: Hash tables configured (established 8192 bind 8192)
<6>TCP reno registered
<6>Unpacking initramfs... done
<6>Freeing initrd memory: 2325k freed
<6>audit: initializing netlink socket (disabled)
<5>audit(1178443810.948:1): initialized
<4>Total HugeTLB memory allocated, 0
<5>VFS: Disk quotas dquot_6.5.1
<4>Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
<6>io scheduler noop registered
<6>io scheduler anticipatory registered
<6>io scheduler deadline registered
<6>io scheduler cfq registered (default)
<6>PCI: Bypassing VIA 8237 APIC De-Assert Message
<6>isapnp: Scanning for PnP cards...
<6>isapnp: No Plug & Play device found
<6>Real Time Clock Driver v1.12ac
<6>Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
<6>serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
<6>serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
<6>serial8250: ttyS2 at I/O 0x3e8 (irq = 4) is a 16550A
<6>serial8250: ttyS3 at I/O 0x2e8 (irq = 3) is a 16550A
<6>00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
<6>00:09: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
<6>00:0a: ttyS2 at I/O 0x3e8 (irq = 10) is a 16550A
<6>00:0b: ttyS3 at I/O 0x2e8 (irq = 11) is a 16550A
<4>floppy0: no floppy controllers found
<6>input: Macintosh mouse button emulation as /class/input/input0
<6>PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
<4>PNP: PS/2 controller doesn't have AUX irq; using default 12
<6>serio: i8042 KBD port at 0x60,0x64 irq 1
<6>mice: PS/2 mouse device common for all mice
<6>input: PC Speaker as /class/input/input1
<6>NET: Registered protocol family 1
<4>Using IPI No-Shortcut mode
<6>Freeing unused kernel memory: 188k freed
<6>input: AT Translated Set 2 keyboard as /class/input/input2

initramfs begins here.

Creating device nodes with udev
Loading scsi_mod
Loading sd_mod
Loading libata
Loading pata_via
Loading xfs

<5>SCSI subsystem initialized
<7>libata version 2.20 loaded.
<7>pata_via 0000:00:0f.0: version 0.2.1
<4>ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 5
<7>PCI: setting IRQ 5 as level-triggered
<6>ACPI: PCI Interrupt 0000:00:0f.0[A] -> Link [LNKA] -> GSI 5 (level, low) -> IRQ 5
<6>PCI: VIA VLink IRQ fixup for 0000:00:0f.0, from 255 to 5
<6>ata1: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001e000 irq 14
<6>ata2: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001e008 irq 15
<6>scsi0 : pata_via
<6>ata1.00: CFA: iCreate CF Card, g1.01a, max PIO6
<6>ata1.00: 1024128 sectors, multi 0: LBA 
<6>ata1.00: configured for PIO4
<6>scsi1 : pata_via
<4>ATA: abnormal status 0x8 on port 0x00010177
<5>scsi 0:0:0:0: Direct-Access     ATA      iCreate CF Card  g1.0 PQ: 0 ANSI: 5
<5>SCSI device sda: 1024128 512-byte hdwr sectors (524 MB)
<5>sda: Write Protect is off
<7>sda: Mode Sense: 00 3a 00 00
<5>SCSI device sda: write cache: disabled, read cache: enabled, doesn't support DPO or FUA
<5>SCSI device sda: 1024128 512-byte hdwr sectors (524 MB)
<5>sda: Write Protect is off
<7>sda: Mode Sense: 00 3a 00 00
<5>SCSI device sda: write cache: disabled, read cache: enabled, doesn't support DPO or FUA
<6> sda: sda1 sda2
<5>sd 0:0:0:0: Attached scsi removable disk sda
<5>sd 0:0:0:0: Attached scsi generic sg0 type 0
<6>SGI XFS with ACLs, security attributes, realtime, large block numbers, no debug enabled
<6>SGI XFS Quota Management subsystem

Waiting for device /dev/disk/by-id/scsi-SATA_iCreate_CF_Card000000001-part1 to appear:  ok
fsck 1.40-WIP (14-Nov-2006)
[/bin/fsck.xfs (1) -- /] fsck.xfs -a /dev/disk/by-id/scsi-SATA_iCreate_CF_Card000000001-part1 
/bin/fsck.xfs: XFS file system.
fsck succeeded. Mounting root device read-write.
Mounting root /dev/disk/by-id/scsi-SATA_iCreate_CF_Card000000001-part1

<5>XFS mounting filesystem sda1
<7>Ending clean XFS mount for filesystem: sda1

/sbin/init begins here.
Starting udevd

<6>Linux agpgart interface v0.102 (c) Dave Jones
<6>agpgart: Detected VIA PM800/PN800/PM880/PN880 chipset
<6>agpgart: AGP aperture is 128M @ 0xe8000000
<6>8139too Fast Ethernet driver 0.9.28
<6>ACPI: PCI Interrupt 0000:00:0d.0[A] -> Link [LNKA] -> GSI 5 (level, low) -> IRQ 5
<6>eth0: RealTek RTL8139 at 0xcf820000, 00:14:0b:20:06:9d, IRQ 5
<7>eth0:  Identified 8139 chip type 'RTL-8100B/8139D'
<4>ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 12
<7>PCI: setting IRQ 12 as level-triggered
<6>ACPI: PCI Interrupt 0000:00:0e.0[A] -> Link [LNKB] -> GSI 12 (level, low) -> IRQ 12
<6>eth1: RealTek RTL8139 at 0xcf838000, 00:14:0b:20:06:9c, IRQ 12
<7>eth1:  Identified 8139 chip type 'RTL-8100B/8139D'
<6>usbcore: registered new interface driver usbfs
<6>usbcore: registered new interface driver hub
<6>usbcore: registered new device driver usb
<6>USB Universal Host Controller Interface driver v3.0
<6>ACPI: PCI Interrupt 0000:00:10.0[A] -> Link [LNKA] -> GSI 5 (level, low) -> IRQ 5
<6>uhci_hcd 0000:00:10.0: UHCI Host Controller
<6>uhci_hcd 0000:00:10.0: new USB bus registered, assigned bus number 1
<6>uhci_hcd 0000:00:10.0: irq 5, io base 0x0000dc00
<6>usb usb1: new device found, idVendor=0000, idProduct=0000
<6>usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1
<6>usb usb1: Product: UHCI Host Controller
<6>usb usb1: Manufacturer: Linux 2.6.21-3-default uhci_hcd
<6>usb usb1: SerialNumber: 0000:00:10.0
<6>usb usb1: configuration #1 chosen from 1 choice
<6>hub 1-0:1.0: USB hub found
<6>hub 1-0:1.0: 2 ports detected
<6>ACPI: PCI Interrupt 0000:00:10.1[A] -> Link [LNKA] -> GSI 5 (level, low) -> IRQ 5
<6>uhci_hcd 0000:00:10.1: UHCI Host Controller
<6>uhci_hcd 0000:00:10.1: new USB bus registered, assigned bus number 2
<6>uhci_hcd 0000:00:10.1: irq 5, io base 0x0000dd00
<6>usb usb2: new device found, idVendor=0000, idProduct=0000
<6>usb usb2: new device strings: Mfr=3, Product=2, SerialNumber=1
<6>usb usb2: Product: UHCI Host Controller
<6>usb usb2: Manufacturer: Linux 2.6.21-3-default uhci_hcd
<6>usb usb2: SerialNumber: 0000:00:10.1
<6>usb usb2: configuration #1 chosen from 1 choice
<6>hub 2-0:1.0: USB hub found
<6>hub 2-0:1.0: 2 ports detected
<6>ACPI: PCI Interrupt 0000:00:10.2[B] -> Link [LNKB] -> GSI 12 (level, low) -> IRQ 12
<6>uhci_hcd 0000:00:10.2: UHCI Host Controller
<6>uhci_hcd 0000:00:10.2: new USB bus registered, assigned bus number 3
<6>uhci_hcd 0000:00:10.2: irq 12, io base 0x0000de00
<6>usb usb3: new device found, idVendor=0000, idProduct=0000
<6>usb usb3: new device strings: Mfr=3, Product=2, SerialNumber=1
<6>usb usb3: Product: UHCI Host Controller
<6>usb usb3: Manufacturer: Linux 2.6.21-3-default uhci_hcd
<6>usb usb3: SerialNumber: 0000:00:10.2
<6>usb usb3: configuration #1 chosen from 1 choice
<6>hub 3-0:1.0: USB hub found
<6>hub 3-0:1.0: 2 ports detected
<6>ACPI: PCI Interrupt 0000:00:10.3[B] -> Link [LNKB] -> GSI 12 (level, low) -> IRQ 12
<6>uhci_hcd 0000:00:10.3: UHCI Host Controller
<6>uhci_hcd 0000:00:10.3: new USB bus registered, assigned bus number 4
<6>uhci_hcd 0000:00:10.3: irq 12, io base 0x0000df00
<6>usb usb4: new device found, idVendor=0000, idProduct=0000
<6>usb usb4: new device strings: Mfr=3, Product=2, SerialNumber=1
<6>usb usb4: Product: UHCI Host Controller
<6>usb usb4: Manufacturer: Linux 2.6.21-3-default uhci_hcd
<6>usb usb4: SerialNumber: 0000:00:10.3
<6>usb usb4: configuration #1 chosen from 1 choice
<6>hub 4-0:1.0: USB hub found
<6>hub 4-0:1.0: 2 ports detected
<4>ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 7
<7>PCI: setting IRQ 7 as level-triggered
<6>ACPI: PCI Interrupt 0000:00:10.4[C] -> Link [LNKC] -> GSI 7 (level, low) -> IRQ 7
<6>ehci_hcd 0000:00:10.4: EHCI Host Controller
<6>ehci_hcd 0000:00:10.4: new USB bus registered, assigned bus number 5
<6>ehci_hcd 0000:00:10.4: irq 7, io mem 0xf6002000
<6>ehci_hcd 0000:00:10.4: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
<6>usb usb5: new device found, idVendor=0000, idProduct=0000
<6>usb usb5: new device strings: Mfr=3, Product=2, SerialNumber=1
<6>usb usb5: Product: EHCI Host Controller
<6>usb usb5: Manufacturer: Linux 2.6.21-3-default ehci_hcd
<6>usb usb5: SerialNumber: 0000:00:10.4
<6>usb usb5: configuration #1 chosen from 1 choice
<6>hub 5-0:1.0: USB hub found
<6>hub 5-0:1.0: 8 ports detected
<6>rtc_cmos 00:05: rtc core: registered rtc_cmos as rtc0
<4>rtc_cmos: probe of 00:05 failed with error -16
<6>Adding 1016k swap on /dev/disk/by-id/scsi-SATA_iCreate_CF_Card000000001-part2.  Priority:-1 extents:1 across:1016k
<6>loop: loaded (max 8 devices)
etc.

longhaul is not loaded by default. Loading it gives

longhaul: VIA C3 'Nehemiah C' [C5P] CPU detected.  Powersaver supported.
longhaul: Using northbridge support.

Re: cpufreq longhaul locks up

[Rafał Bilski]

> <6>No local APIC present or hardware disabled
> <7>mapped APIC to ffffd000 (011ea000)
> <5>Local APIC not detected. Using dummy APIC emulation.
I/O APIC is very bad thing with Longhaul, but You don't have 
local APIC, so it shouldn't be used.
> <6>ACPI: Using PIC for interrupt routing
Looks like it isn't.
> <4>ACPI: PCI Interrupt Link [ALKA] (IRQs *20), disabled.
> <4>ACPI: PCI Interrupt Link [ALKB] (IRQs *21)
> <4>ACPI: PCI Interrupt Link [ALKC] (IRQs *22)
> <4>ACPI: PCI Interrupt Link [ALKD] (IRQs *23), disabled.
This is pointing to I/O APIC, but I don't see later that 
such high interrupts are used. And if I/O APIC would be in 
use You would have lockup in the moment of transition.

I was suspecting:
> One of the 2.6.21 regressions was Guilherme's problem seeing his box
> lock up when the system detected an unstable TSC and dropped back to
> using the HPET.
> 
> In digging deeper, we found the HPET is not actually incrementing on
> this system. And in fact, the reason why this issue just cropped up was
> because of Thomas's clocksource watchdog code was comparing the TSC to
> the HPET (which wasn't moving) and thought the TSC was broken.
because I know that VT8237 has HPET built in. But I don't see any lines 
starting with "hpet: enabled" or something similar. But I don't know 
what to search for. I didn't have contact with HPET earlier.
It is very similar and Your problem with ondemand is starting right 
after
> May  3 19:17:22 cn kernel: Clocksource tsc unstable (delta = -136422685 
> ns)
I don't see such message as long as "performance" governor is used. 

Anyway adding "hpet=disable" at boot should confirm for sure that it 
isn't it. And I think that John already ruled this out by 
clocksource=acpi_pm.

Sorry 
Rafa³

----------------------------------------------------------------------- Linda jako gospodyni domowa - zobacz!!!
>>> http://link.interia.pl/f1a79

Re: cpufreq longhaul locks up

[Rafał Bilski]

> <6>No local APIC present or hardware disabled
> <7>mapped APIC to ffffd000 (011ea000)
> <5>Local APIC not detected. Using dummy APIC emulation.
I/O APIC is very bad thing with Longhaul, but You don't have 
local APIC, so it shouldn't be used.
> <6>ACPI: Using PIC for interrupt routing
Looks like it isn't.
> <4>ACPI: PCI Interrupt Link [ALKA] (IRQs *20), disabled.
> <4>ACPI: PCI Interrupt Link [ALKB] (IRQs *21)
> <4>ACPI: PCI Interrupt Link [ALKC] (IRQs *22)
> <4>ACPI: PCI Interrupt Link [ALKD] (IRQs *23), disabled.
This is pointing to I/O APIC, but I don't see later that 
such high interrupts are used. And if I/O APIC would be in 
use You would have lockup in the moment of transition.

I was suspecting:
> One of the 2.6.21 regressions was Guilherme's problem seeing his box
> lock up when the system detected an unstable TSC and dropped back to
> using the HPET.
> 
> In digging deeper, we found the HPET is not actually incrementing on
> this system. And in fact, the reason why this issue just cropped up was
> because of Thomas's clocksource watchdog code was comparing the TSC to
> the HPET (which wasn't moving) and thought the TSC was broken.
because I know that VT8237 has HPET built in. But I don't see any lines 
starting with "hpet: enabled" or something similar. But I don't know 
what to search for. I didn't have contact with HPET earlier.
It is very similar and Your problem with ondemand is starting right 
after
> May  3 19:17:22 cn kernel: Clocksource tsc unstable (delta = -136422685 
> ns)
I don't see such message as long as "performance" governor is used. 

Anyway adding "hpet=disable" at boot should confirm for sure that it 
isn't it. And I think that John already ruled this out by 
clocksource=acpi_pm.

Sorry 
Rafał

----------------------------------------------------------------------- Linda jako gospodyni domowa - zobacz!!!
>>> http://link.interia.pl/f1a79

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 6 2007 11:23, Rafał Bilski wrote:
>
>> <6>No local APIC present or hardware disabled
>> <7>mapped APIC to ffffd000 (011ea000)
>> <5>Local APIC not detected. Using dummy APIC emulation.
>
>I/O APIC is very bad thing with Longhaul, but You don't have 
>local APIC, so it shouldn't be used.
>
>> <6>ACPI: Using PIC for interrupt routing
>
>Looks like it isn't.
>
>> <4>ACPI: PCI Interrupt Link [ALKA] (IRQs *20), disabled.
>> <4>ACPI: PCI Interrupt Link [ALKB] (IRQs *21)
>> <4>ACPI: PCI Interrupt Link [ALKC] (IRQs *22)
>> <4>ACPI: PCI Interrupt Link [ALKD] (IRQs *23), disabled.
>
>This is pointing to I/O APIC, but I don't see later that 
>such high interrupts are used. And if I/O APIC would be in 
>use You would have lockup in the moment of transition.

cn:~ # cat /proc/interrupts 
           CPU0       
  0:    1745595    XT-PIC-XT        timer
  1:         29    XT-PIC-XT        i8042
  2:          0    XT-PIC-XT        cascade
  5:       1194    XT-PIC-XT        uhci_hcd:usb1, uhci_hcd:usb2, eth0
  7:          1    XT-PIC-XT        ehci_hcd:usb5
  8:          2    XT-PIC-XT        rtc
  9:          0    XT-PIC-XT        acpi
 12:          0    XT-PIC-XT        uhci_hcd:usb3, uhci_hcd:usb4, eth1
 14:      59882    XT-PIC-XT        libata
 15:          0    XT-PIC-XT        libata
NMI:          0 
LOC:          0 
ERR:          0
MIS:          0

So, just the regular 16.

>I was suspecting:
>> One of the 2.6.21 regressions was Guilherme's problem seeing his box
>> lock up when the system detected an unstable TSC and dropped back to
>> using the HPET.
>> 
>> In digging deeper, we found the HPET is not actually incrementing on
>> this system. And in fact, the reason why this issue just cropped up was
>> because of Thomas's clocksource watchdog code was comparing the TSC to
>> the HPET (which wasn't moving) and thought the TSC was broken.
>
>because I know that VT8237 has HPET built in. But I don't see any lines 
>starting with "hpet: enabled" or something similar. But I don't know 
>what to search for. I didn't have contact with HPET earlier.
>It is very similar and Your problem with ondemand is starting right 
>after
>
>> May  3 19:17:22 cn kernel: Clocksource tsc unstable (delta = -136422685 
>> ns)
>
>I don't see such message as long as "performance" governor is used. 

Well this message pops up whenever the frequency changes, because
the CPU does not have constant_tsc. E.g.

<performance is default and active>
echo 598000 >/sys/devices/cpu/cpu0/cpufreq

spews out the clocksource message. I do not think the clocksource
is a culprit. The kernel just noticed the TSC jumped and hence
uses a new clocksource.

>Anyway adding "hpet=disable" at boot should confirm for sure that it 
>isn't it. And I think that John already ruled this out by 
>clocksource=acpi_pm.
>
>Sorry 
>Rafał

Nevermind, it does not look like it gets any cooler at lower frequencies,
so it's a nobrainer to run it at the default 733.


Jan
-- 

Re: cpufreq longhaul locks up

[Rafał Bilski]

> Nevermind, it does not look like it gets any cooler at lower frequencies,
> so it's a nobrainer to run it at the default 733.
Well. You have very good CPU - 4,4W typical and 6,0W is a factory maximum.
My is eating 6,78W while *sleeping* at 1GHz or about 5W while *sleeping* at 
533MHz.
> Jan
Rafa³



----------------------------------------------------------------------
Wicie, rozumicie....
Zobacz >>> http://link.interia.pl/f1a74

Re: cpufreq longhaul locks up

[Rafał Bilski]

> Nevermind, it does not look like it gets any cooler at lower frequencies,
> so it's a nobrainer to run it at the default 733.
Well. You have very good CPU - 4,4W typical and 6,0W is a factory maximum.
My is eating 6,78W while *sleeping* at 1GHz or about 5W while *sleeping* at 
533MHz.
> Jan
Rafał



----------------------------------------------------------------------
Wicie, rozumicie....
Zobacz >>> http://link.interia.pl/f1a74

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 6 2007 12:25, Rafał Bilski wrote:

>> Nevermind, it does not look like it gets any cooler at lower frequencies,
>> so it's a nobrainer to run it at the default 733.
>
>Well. You have very good CPU - 4,4W typical and 6,0W is a factory maximum.

Says who? TM5800 draws around 2.0W (or even less) when idle [333 MHz]. :)
Though it has a different hardware engine than most x86.

>My is eating 6,78W while *sleeping* at 1GHz or about 5W while *sleeping* at 
>533MHz.
>> Jan
>Rafał
>
>
>
>----------------------------------------------------------------------
>Wicie, rozumicie....
>Zobacz >>> http://link.interia.pl/f1a74
>

Jan
-- 

Re: cpufreq longhaul locks up

[Rafał Bilski]

>> Well. You have very good CPU - 4,4W typical and 6,0W is a factory maximum.
> 
> Says who? TM5800 draws around 2.0W (or even less) when idle [333 MHz]. :)
> Though it has a different hardware engine than most x86.
Datasheet. It says that Your CPU needs 4,4W (typical) when 100% busy.



----------------------------------------------------------------------
NIE KUPUJ!!!
...zanim nie porownasz cen >> http://link.interia.pl/f1a5e

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 5 2007 07:40, Rafał Bilski wrote:
>Jan,
>
>Can You send output of x86info program and output of 

Where do I find this?

>lspci command? Longhaul wasn't working for You since 2.6.18 right?

# lspci
00:00.0 Host bridge: VIA Technologies, Inc. CN400/PM880 Host Bridge
00:00.1 Host bridge: VIA Technologies, Inc. CN400/PM880 Host Bridge
00:00.2 Host bridge: VIA Technologies, Inc. CN400/PM880 Host Bridge
00:00.3 Host bridge: VIA Technologies, Inc. CN400/PM880 Host Bridge
00:00.4 Host bridge: VIA Technologies, Inc. CN400/PM880 Host Bridge
00:00.7 Host bridge: VIA Technologies, Inc. CN400/PM880 Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
00:0e.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
00:0f.0 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South]
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
01:00.0 VGA compatible controller: VIA Technologies, Inc. S3 Unichrome Pro VGA Adapter (rev 02)

# dmidecode
Handle 0x0000, DMI type 0, 20 bytes
BIOS Information
        Vendor: Phoenix Technologies, LTD
        Version: 6.00 PG
        Release Date: 11/30/2005
        Address: 0xE0000
        Runtime Size: 128 kB
        ROM Size: 512 kB
        Characteristics:


>I'm going to work now, but I will be available after 14:00 UTC.

2.6.20.2 (2.6.20.2-ccj45-default, slightly different config
than openSUSE 10.2), no preemption, lockup.

2.6.21 (openSUSE 10.3 Alpha 3 2.6.21-3-default), voluntary
preemption, lockup.

If I shall try more combinations, let me know.

>If You have problem with longhaul+powersave there may be one thing 
>related. When I started to change Longhaul it was causing lockups 
>on Epia 800. I added transition protection. Helped, but not for 
>long. After one or two hours machine locked up anyway. I found 
>datasheet in Google and changed "disable BMDMA bit on PCI device" to 
>northbridge support. Problem fixed. Somehow CLE133 chipset didn't 
>like touching "BMDMA master" bits.
>Second: I didn't get answer from VIA why they are blocking ACPI C3 on CPU's 
>faster then 1GHz. I don't know if it is standard practice and if
>Intel and AMD are doing it too.
>
>Things worth checking: disable PREEMPT, change it to "Voluntary preemption". 
>Check if using conservative governor makes any difference. I know that 
>this may sound strange, but transition latency is directly proportional to 
>difference between current and destination frequency. Maybe for faster 
>processors it isn't allowed to change frequency directly from min to max?

I'll try that .. too.


Thanks,
Jan
-- 

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 5 2007 07:40, Rafał Bilski wrote:
>Jan,
>
>Can You send output of x86info program and output of 

Where do I find this?

>lspci command? Longhaul wasn't working for You since 2.6.18 right?

# lspci
00:00.0 Host bridge: VIA Technologies, Inc. CN400/PM880 Host Bridge
00:00.1 Host bridge: VIA Technologies, Inc. CN400/PM880 Host Bridge
00:00.2 Host bridge: VIA Technologies, Inc. CN400/PM880 Host Bridge
00:00.3 Host bridge: VIA Technologies, Inc. CN400/PM880 Host Bridge
00:00.4 Host bridge: VIA Technologies, Inc. CN400/PM880 Host Bridge
00:00.7 Host bridge: VIA Technologies, Inc. CN400/PM880 Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
00:0e.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
00:0f.0 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South]
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
01:00.0 VGA compatible controller: VIA Technologies, Inc. S3 Unichrome Pro VGA Adapter (rev 02)

# dmidecode
Handle 0x0000, DMI type 0, 20 bytes
BIOS Information
        Vendor: Phoenix Technologies, LTD
        Version: 6.00 PG
        Release Date: 11/30/2005
        Address: 0xE0000
        Runtime Size: 128 kB
        ROM Size: 512 kB
        Characteristics:


>I'm going to work now, but I will be available after 14:00 UTC.

2.6.20.2 (2.6.20.2-ccj45-default, slightly different config
than openSUSE 10.2), no preemption, lockup.

2.6.21 (openSUSE 10.3 Alpha 3 2.6.21-3-default), voluntary
preemption, lockup.

If I shall try more combinations, let me know.

>If You have problem with longhaul+powersave there may be one thing 
>related. When I started to change Longhaul it was causing lockups 
>on Epia 800. I added transition protection. Helped, but not for 
>long. After one or two hours machine locked up anyway. I found 
>datasheet in Google and changed "disable BMDMA bit on PCI device" to 
>northbridge support. Problem fixed. Somehow CLE133 chipset didn't 
>like touching "BMDMA master" bits.
>Second: I didn't get answer from VIA why they are blocking ACPI C3 on CPU's 
>faster then 1GHz. I don't know if it is standard practice and if
>Intel and AMD are doing it too.
>
>Things worth checking: disable PREEMPT, change it to "Voluntary preemption". 
>Check if using conservative governor makes any difference. I know that 
>this may sound strange, but transition latency is directly proportional to 
>difference between current and destination frequency. Maybe for faster 
>processors it isn't allowed to change frequency directly from min to max?

I'll try that .. too.


Thanks,
Jan
-- 

Re: cpufreq longhaul locks up

[Rafał Bilski]

>> Can You send output of x86info program and output of 
> 
> Where do I find this?

http://www.codemonkey.org.uk/projects/x86info/
It needs msr device support in kernel.


----------------------------------------------------------------------
NIE KUPUJ!!!
...zanim nie porownasz cen >> http://link.interia.pl/f1a5e

Re: cpufreq longhaul locks up

[Rafał Bilski]

>> Can You send output of x86info program and output of 
> 
> Where do I find this?

http://www.codemonkey.org.uk/projects/x86info/
It needs msr device support in kernel.


----------------------------------------------------------------------
NIE KUPUJ!!!
...zanim nie porownasz cen >> http://link.interia.pl/f1a5e

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 5 2007 16:10, Rafał Bilski wrote:
>
>>> Can You send output of x86info program and output of 
>> 
>> Where do I find this?
>
>http://www.codemonkey.org.uk/projects/x86info/
>It needs msr device support in kernel.

I just wonder why x86info says I have a C5XL while `modprobe longhaul`
says it is a C5P.


cn:/dev/shm # ./x86info -v -v
x86info v1.20.  Dave Jones 2001-2006
Feedback to <davej@redhat.com>.

Found 1 CPU
--------------------------------------------------------------------------
Family: 6 Model: 9 Stepping: 8
CPU Model : VIA C3 (Nehemiah) [C5XL]
Feature flags:
        Onboard FPU
        Virtual Mode Extensions
        Debugging Extensions
        Page Size Extensions
        Time Stamp Counter
        Model-Specific Registers
        CMPXCHG8 instruction
        Memory Type Range Registers
        Page Global Enable
        CMOV instruction
        Page Attribute Table
        MMX support
        FXSAVE and FXRESTORE instructions
        SSE support

Extended feature flags:
 [0] RNGp RNGe [4] ACEp ACEe
Cache info
 L1 Instruction cache: 64KB, 4-way associative, 1 lines per tag, line size=32
bytes.
 L1 Data cache: 64KB 4-way associative, 1 lines per tag, line size=32 bytes.
 L2 (on CPU) cache: 64KB 8-way associative, 1 lines per tag, line size=32
bytes.
TLB info
 Instruction TLB: 8-way associative. 128 entries.
 Data TLB: 8-way associative. 128 entries.

(Without -v it's:)
Feature flags:
 fpu vme de pse tsc msr cx8 mtrr pge cmov pat mmx fxsr sse


cn:/dev/shm # cat /proc/cpuinfo 
processor       : 0
vendor_id       : CentaurHauls
cpu family      : 6
model           : 9
model name      : VIA Nehemiah
stepping        : 8
cpu MHz         : 731.000
cache size      : 64 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr cx8 mtrr pge cmov pat mmx fxsr sse up
rng rng_en ace ace_en
bogomips        : 1468.17
clflush size    : 32


And the BIOS announces it as a "Via Eden ESP 6000" (as does the manufacturer).



Jan
-- 

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 5 2007 16:10, Rafał Bilski wrote:
>
>>> Can You send output of x86info program and output of 
>> 
>> Where do I find this?
>
>http://www.codemonkey.org.uk/projects/x86info/
>It needs msr device support in kernel.

I just wonder why x86info says I have a C5XL while `modprobe longhaul`
says it is a C5P.


cn:/dev/shm # ./x86info -v -v
x86info v1.20.  Dave Jones 2001-2006
Feedback to <davej@redhat.com>.

Found 1 CPU
--------------------------------------------------------------------------
Family: 6 Model: 9 Stepping: 8
CPU Model : VIA C3 (Nehemiah) [C5XL]
Feature flags:
        Onboard FPU
        Virtual Mode Extensions
        Debugging Extensions
        Page Size Extensions
        Time Stamp Counter
        Model-Specific Registers
        CMPXCHG8 instruction
        Memory Type Range Registers
        Page Global Enable
        CMOV instruction
        Page Attribute Table
        MMX support
        FXSAVE and FXRESTORE instructions
        SSE support

Extended feature flags:
 [0] RNGp RNGe [4] ACEp ACEe
Cache info
 L1 Instruction cache: 64KB, 4-way associative, 1 lines per tag, line size=32
bytes.
 L1 Data cache: 64KB 4-way associative, 1 lines per tag, line size=32 bytes.
 L2 (on CPU) cache: 64KB 8-way associative, 1 lines per tag, line size=32
bytes.
TLB info
 Instruction TLB: 8-way associative. 128 entries.
 Data TLB: 8-way associative. 128 entries.

(Without -v it's:)
Feature flags:
 fpu vme de pse tsc msr cx8 mtrr pge cmov pat mmx fxsr sse


cn:/dev/shm # cat /proc/cpuinfo 
processor       : 0
vendor_id       : CentaurHauls
cpu family      : 6
model           : 9
model name      : VIA Nehemiah
stepping        : 8
cpu MHz         : 731.000
cache size      : 64 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr cx8 mtrr pge cmov pat mmx fxsr sse up
rng rng_en ace ace_en
bogomips        : 1468.17
clflush size    : 32


And the BIOS announces it as a "Via Eden ESP 6000" (as does the manufacturer).



Jan
-- 

Re: cpufreq longhaul locks up

[Rafał Bilski]

> I just wonder why x86info says I have a C5XL while `modprobe longhaul`
> says it is a C5P.
I have changed names to names which VIA is using. 
> 
> cn:/dev/shm # ./x86info -v -v
You need to be root and use -a option. I'm interested in:
FCR: MSR: 0x00001107=0x9e3f1ad6 : 10011110 00111111 00011010 11010110
Power management: Powersaver
MSR: 0x0000110a=0x07ff000d000280f0 : 00000111 11111111 00000000 00001101
           00000000 00000010 10000000 11110000

 RevisionID: 0 : Initial revision (Software clock multiplier only, no SoftVID)
 Software clock multiplier is disabled
Please send me below part of Your dmesg too:
CPU: After generic identify, caps: 0381b83f 00000000 00000000 00000000 00000000 00000000 00000000
CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line)
CPU: L2 Cache: 64K (32 bytes/line)
CPU: After all inits, caps: 0381b93f 00000000 00000000 00000000 00000000 000000dd 00000000
> 
> And the BIOS announces it as a "Via Eden ESP 6000" (as does the manufacturer).
Great. I think that I saw datasheet somewhere.
> Jan
Rafa³



----------------------------------------------------------------------
Wicie, rozumicie....
Zobacz >>> http://link.interia.pl/f1a74

Re: cpufreq longhaul locks up

[Rafał Bilski]

> I just wonder why x86info says I have a C5XL while `modprobe longhaul`
> says it is a C5P.
I have changed names to names which VIA is using. 
> 
> cn:/dev/shm # ./x86info -v -v
You need to be root and use -a option. I'm interested in:
FCR: MSR: 0x00001107=0x9e3f1ad6 : 10011110 00111111 00011010 11010110
Power management: Powersaver
MSR: 0x0000110a=0x07ff000d000280f0 : 00000111 11111111 00000000 00001101
           00000000 00000010 10000000 11110000

 RevisionID: 0 : Initial revision (Software clock multiplier only, no SoftVID)
 Software clock multiplier is disabled
Please send me below part of Your dmesg too:
CPU: After generic identify, caps: 0381b83f 00000000 00000000 00000000 00000000 00000000 00000000
CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line)
CPU: L2 Cache: 64K (32 bytes/line)
CPU: After all inits, caps: 0381b93f 00000000 00000000 00000000 00000000 000000dd 00000000
> 
> And the BIOS announces it as a "Via Eden ESP 6000" (as does the manufacturer).
Great. I think that I saw datasheet somewhere.
> Jan
Rafał



----------------------------------------------------------------------
Wicie, rozumicie....
Zobacz >>> http://link.interia.pl/f1a74

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 5 2007 20:04, Rafał Bilski wrote:
>
>> I just wonder why x86info says I have a C5XL while `modprobe longhaul`
>> says it is a C5P.
>I have changed names to names which VIA is using. 
>> 
>> cn:/dev/shm # ./x86info -v -v
>You need to be root and use -a option. I'm interested in:

x86info v1.20.  Dave Jones 2001-2006
Feedback to <davej@redhat.com>.

Found 1 CPU
MP Table:
#	APIC ID	Version	State		Family	Model	Step	Flags

--------------------------------------------------------------------------
eax in: 0x00000000, eax = 00000001 ebx = 746e6543 ecx = 736c7561 edx = 48727561
eax in: 0x00000001, eax = 00000698 ebx = 00000000 ecx = 00000000 edx = 0381b13f

eax in: 0x80000000, eax = 80000006 ebx = 00000000 ecx = 00000000 edx = 00000000
eax in: 0x80000001, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000
eax in: 0x80000002, eax = 20414956 ebx = 6568654e ecx = 6861696d edx = 00000000
eax in: 0x80000003, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000
eax in: 0x80000004, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000
eax in: 0x80000005, eax = 00000000 ebx = 08800880 ecx = 40040120 edx = 40040120
eax in: 0x80000006, eax = 00000000 ebx = 00000000 ecx = 00408120 edx = 00000000

eax in: 0xc0000000, eax = c0000001 ebx = 00000000 ecx = 00000000 edx = 00000000
eax in: 0xc0000001, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 000000dd

Family: 6 Model: 9 Stepping: 8
CPU Model : VIA C3 (Nehemiah) [C5XL]
Feature flags:
 fpu vme de pse tsc msr cx8 mtrr pge cmov pat mmx fxsr sse
Extended feature flags:
 [0] RNGp RNGe [4] ACEp ACEe
Cache info
 L1 Instruction cache: 64KB, 4-way associative, 1 lines per tag, line size=32 bytes.
 L1 Data cache: 64KB 4-way associative, 1 lines per tag, line size=32 bytes.
 L2 (on CPU) cache: 64KB 8-way associative, 1 lines per tag, line size=32 bytes.
TLB info
 Instruction TLB: 8-way associative. 128 entries.
 Data TLB: 8-way associative. 128 entries.
FCR: MSR: 0x00001107=0x9e3f1ad2 : 10011110 00111111 00011010 11010010
Power management: Powersaver
MSR: 0x0000110a=0x07ff0004000080f0 : 00000111 11111111 00000000 00000100
           00000000 00000000 10000000 11110000

 RevisionID: 0 : Initial revision (Software clock multiplier only, no SoftVID)
 Software clock multiplier is disabled

750MHz processor (estimate).



>> And the BIOS announces it as a "Via Eden ESP 6000" (as does the manufacturer).
>
>Great. I think that I saw datasheet somewhere.

Oops, that should read *ESP 7000*. And s/manufacturer/vendor/.
The box is an Atiosys BA-4000 (www.atiosys.com) pretty much your
standard x86-in-a-tiny-box.


Jan
-- 

Re: cpufreq longhaul locks up

[Jan Engelhardt]

On May 5 2007 20:04, Rafał Bilski wrote:
>
>> I just wonder why x86info says I have a C5XL while `modprobe longhaul`
>> says it is a C5P.
>I have changed names to names which VIA is using. 
>> 
>> cn:/dev/shm # ./x86info -v -v
>You need to be root and use -a option. I'm interested in:

x86info v1.20.  Dave Jones 2001-2006
Feedback to <davej@redhat.com>.

Found 1 CPU
MP Table:
#	APIC ID	Version	State		Family	Model	Step	Flags

--------------------------------------------------------------------------
eax in: 0x00000000, eax = 00000001 ebx = 746e6543 ecx = 736c7561 edx = 48727561
eax in: 0x00000001, eax = 00000698 ebx = 00000000 ecx = 00000000 edx = 0381b13f

eax in: 0x80000000, eax = 80000006 ebx = 00000000 ecx = 00000000 edx = 00000000
eax in: 0x80000001, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000
eax in: 0x80000002, eax = 20414956 ebx = 6568654e ecx = 6861696d edx = 00000000
eax in: 0x80000003, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000
eax in: 0x80000004, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000
eax in: 0x80000005, eax = 00000000 ebx = 08800880 ecx = 40040120 edx = 40040120
eax in: 0x80000006, eax = 00000000 ebx = 00000000 ecx = 00408120 edx = 00000000

eax in: 0xc0000000, eax = c0000001 ebx = 00000000 ecx = 00000000 edx = 00000000
eax in: 0xc0000001, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 000000dd

Family: 6 Model: 9 Stepping: 8
CPU Model : VIA C3 (Nehemiah) [C5XL]
Feature flags:
 fpu vme de pse tsc msr cx8 mtrr pge cmov pat mmx fxsr sse
Extended feature flags:
 [0] RNGp RNGe [4] ACEp ACEe
Cache info
 L1 Instruction cache: 64KB, 4-way associative, 1 lines per tag, line size=32 bytes.
 L1 Data cache: 64KB 4-way associative, 1 lines per tag, line size=32 bytes.
 L2 (on CPU) cache: 64KB 8-way associative, 1 lines per tag, line size=32 bytes.
TLB info
 Instruction TLB: 8-way associative. 128 entries.
 Data TLB: 8-way associative. 128 entries.
FCR: MSR: 0x00001107=0x9e3f1ad2 : 10011110 00111111 00011010 11010010
Power management: Powersaver
MSR: 0x0000110a=0x07ff0004000080f0 : 00000111 11111111 00000000 00000100
           00000000 00000000 10000000 11110000

 RevisionID: 0 : Initial revision (Software clock multiplier only, no SoftVID)
 Software clock multiplier is disabled

750MHz processor (estimate).



>> And the BIOS announces it as a "Via Eden ESP 6000" (as does the manufacturer).
>
>Great. I think that I saw datasheet somewhere.

Oops, that should read *ESP 7000*. And s/manufacturer/vendor/.
The box is an Atiosys BA-4000 (www.atiosys.com) pretty much your
standard x86-in-a-tiny-box.


Jan
--