>> 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.
--
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
> 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ł
On May 6 2007 11:23, Rafał Bilski wrote:
>
>> <6>No local APIC present or hardware disabled
>> <7>mapped APIC to d000 (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>No local APIC present or hardware disabled
> <7>mapped APIC to d000 (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
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 wrot
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
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL P
>> :-/ 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
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/cpuf
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/
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 alrea
>> 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
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
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.
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
> 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: 0x1107=0x9e3f1ad6 : 1000 0011 00011010 1
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 s
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 i
>> 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.
>> 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 <[EMAIL PROTECTED]>.
>
> 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 gove
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
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
>> thro
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 Longh
>>> 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=po
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
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 archiv
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
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
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 ti
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
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: longhau
>> 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.
>>
> 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 lo
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 ano
> [...]
>
> 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
a
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
> 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
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
39 matches
Mail list logo
