Re: cpufreq longhaul locks up
>> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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>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:1745595XT-PIC-XTtimer 1: 29XT-PIC-XTi8042 2: 0XT-PIC-XTcascade 5: 1194XT-PIC-XTuhci_hcd:usb1, uhci_hcd:usb2, eth0 7: 1XT-PIC-XTehci_hcd:usb5 8: 2XT-PIC-XTrtc 9: 0XT-PIC-XTacpi 12: 0XT-PIC-XTuhci_hcd:usb3, uhci_hcd:usb4, eth1 14: 59882XT-PIC-XTlibata 15: 0XT-PIC-XTlibata 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. 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 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
> <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 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 ([EMAIL PROTECTED]) (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: size: 0009f800 end: 0009f800 type: 1 <4>copy_e820_map() type is E820_RAM <4>copy_e820_map() start: 0009f800 size: 0800 end: 000a type: 2 <4>copy_e820_map() start: 000f size: 0001 end: 0010 type: 2 <4>copy_e820_map() start: 0010 size: 0eef end: 0eff type: 1 <4>copy_e820_map() type is E820_RAM <4>copy_e820_map() start: 0eff size: 3000 end: 0eff3000 type: 4 <4>copy_e820_map() start: 0eff3000 size: d000 end: 0f00 type: 3 <4>copy_e820_map() start: fec0 size: 0140 end: 0001 type: 2 <4> BIOS-e820: - 0009f800 (usable) <4> BIOS-e820: 0009f800 - 000a (reserved) <4> BIOS-e820: 000f - 0010 (reserved) <4> BIOS-e820: 0010 - 0eff (usable) <4> BIOS-e820: 0eff - 0eff3000 (ACPI NVS) <4> BIOS-e820: 0eff3000 - 0f00 (ACPI data) <4> BIOS-e820: fec0 - 0001 (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 AWRD0) <4>ACPI: FACP 0EFF30C0, 0074 (r1 CM400 AWRDACPI 42302E31 AWRD0) <4>ACPI: DSDT 0EFF3180, 5433 (r1 CM400 AWRDACPI 1000 MSFT 10E) <4>ACPI: FACS 0EFF, 0040 <6>ACPI: PM-Timer IO Port: 0x408 <4>Allocating PCI resources starting at 1000 (gap: 0f00:efc0) <4>Built 1 zonelists. Total pages: 60945 <5>Kernel command line: root=/dev/disk/by-id/scsi-SATA_iCreate_CF_Card1-part1 rootflags=usrquota,grpquota <6>No local APIC present or hardware disabled <7>mapped APIC to d000 (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 - 0xf000 (2088 kB) <4>pkmap : 0xff80 - 0xffc0 (4096 kB) <4>vmalloc : 0xcf80 - 0xff7fe000 ( 767 MB) <4>lowmem : 0xc000 - 0xceff ( 239 MB) <4> .init : 0xc036e000 - 0xc039d000 ( 188 kB) <4> .data : 0xc02b1c67 - 0xc0366374 ( 721 kB) <4> .text : 0xc010 - 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 <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 00dd <4>Compat
Re: cpufreq longhaul locks up
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 PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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. 5Linux version 2.6.21-3-default ([EMAIL PROTECTED]) (gcc version 4.1.3 20070413 (prerelease) (SUSE Linux)) #1 SMP Thu Apr 26 11:49:27 UTC 2007 6BIOS-provided physical RAM map: 4sanitize start 4sanitize end 4copy_e820_map() start: size: 0009f800 end: 0009f800 type: 1 4copy_e820_map() type is E820_RAM 4copy_e820_map() start: 0009f800 size: 0800 end: 000a type: 2 4copy_e820_map() start: 000f size: 0001 end: 0010 type: 2 4copy_e820_map() start: 0010 size: 0eef end: 0eff type: 1 4copy_e820_map() type is E820_RAM 4copy_e820_map() start: 0eff size: 3000 end: 0eff3000 type: 4 4copy_e820_map() start: 0eff3000 size: d000 end: 0f00 type: 3 4copy_e820_map() start: fec0 size: 0140 end: 0001 type: 2 4 BIOS-e820: - 0009f800 (usable) 4 BIOS-e820: 0009f800 - 000a (reserved) 4 BIOS-e820: 000f - 0010 (reserved) 4 BIOS-e820: 0010 - 0eff (usable) 4 BIOS-e820: 0eff - 0eff3000 (ACPI NVS) 4 BIOS-e820: 0eff3000 - 0f00 (ACPI data) 4 BIOS-e820: fec0 - 0001 (reserved) 50MB HIGHMEM available. 5239MB LOWMEM available. 7Entering add_active_range(0, 0, 61424) 0 entries of 256 used 4Zone PFN ranges: 4 DMA 0 - 4096 4 Normal 4096 -61424 4 HighMem 61424 -61424 4early_node_map[1] active PFN ranges 40:0 -61424 7On 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 6DMI 2.3 present. 6Using APIC driver default 4ACPI: RSDP 000F7630, 0014 (r0 CM400 ) 4ACPI: RSDT 0EFF3040, 0028 (r1 CM400 AWRDACPI 42302E31 AWRD0) 4ACPI: FACP 0EFF30C0, 0074 (r1 CM400 AWRDACPI 42302E31 AWRD0) 4ACPI: DSDT 0EFF3180, 5433 (r1 CM400 AWRDACPI 1000 MSFT 10E) 4ACPI: FACS 0EFF, 0040 6ACPI: PM-Timer IO Port: 0x408 4Allocating PCI resources starting at 1000 (gap: 0f00:efc0) 4Built 1 zonelists. Total pages: 60945 5Kernel command line: root=/dev/disk/by-id/scsi-SATA_iCreate_CF_Card1-part1 rootflags=usrquota,grpquota 6No local APIC present or hardware disabled 7mapped APIC to d000 (011ea000) 6Enabling fast FPU save and restore... done. 6Enabling unmasked SIMD FPU exception support... done. 6Initializing CPU#0 4PID hash table entries: 1024 (order: 10, 4096 bytes) 4Detected 733.024 MHz processor. 4Console: colour VGA+ 80x25 4Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) 4Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) 6Memory: 237444k/245696k available (1735k kernel code, 7628k reserved, 721k data, 188k init, 0k highmem) 4virtual kernel memory layout: 4fixmap : 0xffdf5000 - 0xf000 (2088 kB) 4pkmap : 0xff80 - 0xffc0 (4096 kB) 4vmalloc : 0xcf80 - 0xff7fe000 ( 767 MB) 4lowmem : 0xc000 - 0xceff ( 239 MB) 4 .init : 0xc036e000 - 0xc039d000 ( 188 kB) 4 .data : 0xc02b1c67 - 0xc0366374 ( 721 kB) 4 .text : 0xc010 - 0xc02b1c67 (1735 kB) 4Checking if this processor honours the WP bit even in supervisor mode... Ok. 4Calibrating delay using timer specific routine.. 1468.17 BogoMIPS (lpj=2936355) 6Security Framework v1.0.0 initialized 4Mount-cache hash table entries: 512 7CPU: After generic identify, caps: 0381b03f 6CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line) 6CPU: L2 Cache: 64K (32 bytes/line) 7CPU: After all inits, caps: 0381b13f 00dd 4Compat vDSO mapped to e000. 6Checking 'hlt' instruction... OK. 6SMP alternatives: switching to UP code 6Freeing SMP alternatives: 12k freed 6ACPI: Core revision 20070126 4ACPI:
Re: cpufreq longhaul locks up
6No local APIC present or hardware disabled 7mapped APIC to d000 (011ea000) 5Local 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. 6ACPI: Using PIC for interrupt routing Looks like it isn't. 4ACPI: PCI Interrupt Link [ALKA] (IRQs *20), disabled. 4ACPI: PCI Interrupt Link [ALKB] (IRQs *21) 4ACPI: PCI Interrupt Link [ALKC] (IRQs *22) 4ACPI: 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
On May 6 2007 11:23, Rafał Bilski wrote: 6No local APIC present or hardware disabled 7mapped APIC to d000 (011ea000) 5Local 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. 6ACPI: Using PIC for interrupt routing Looks like it isn't. 4ACPI: PCI Interrupt Link [ALKA] (IRQs *20), disabled. 4ACPI: PCI Interrupt Link [ALKB] (IRQs *21) 4ACPI: PCI Interrupt Link [ALKC] (IRQs *22) 4ACPI: 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:1745595XT-PIC-XTtimer 1: 29XT-PIC-XTi8042 2: 0XT-PIC-XTcascade 5: 1194XT-PIC-XTuhci_hcd:usb1, uhci_hcd:usb2, eth0 7: 1XT-PIC-XTehci_hcd:usb5 8: 2XT-PIC-XTrtc 9: 0XT-PIC-XTacpi 12: 0XT-PIC-XTuhci_hcd:usb3, uhci_hcd:usb4, eth1 14: 59882XT-PIC-XTlibata 15: 0XT-PIC-XTlibata 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 -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
>> :-/ 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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, _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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 > >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 >00dd CPU: After generic identify, caps: 0381b03f 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 00dd Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
>> 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 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 00dd "dd" is very important here. > Jan Rafał -- Kasia Cichopek eksponuje biust >>> http://link.interia.pl/f1a6f - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 <[EMAIL PROTECTED]>.
Found 1 CPU
MP Table:
# APIC ID Version State Family Model StepFlags
--
eax in: 0x, eax = 0001 ebx = 746e6543 ecx = 736c7561 edx = 48727561
eax in: 0x0001, eax = 0698 ebx = ecx = edx = 0381b13f
eax in: 0x8000, eax = 8006 ebx = ecx = edx =
eax in: 0x8001, eax = ebx = ecx = edx =
eax in: 0x8002, eax = 20414956 ebx = 6568654e ecx = 6861696d edx =
eax in: 0x8003, eax = ebx = ecx = edx =
eax in: 0x8004, eax = ebx = ecx = edx =
eax in: 0x8005, eax = ebx = 08800880 ecx = 40040120 edx = 40040120
eax in: 0x8006, eax = ebx = ecx = 00408120 edx =
eax in: 0xc000, eax = c001 ebx = ecx = edx =
eax in: 0xc001, eax = ebx = ecx = edx = 00dd
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: 0x1107=0x9e3f1ad2 : 1000 0011 00011010 11010010
Power management: Powersaver
MSR: 0x110a=0x07ff000480f0 : 0111 0100
1000
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
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
> 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 11010110
Power management: Powersaver
MSR: 0x110a=0x07ff000d000280f0 : 0111 1101
0010 1000
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
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
00dd
>
> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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, _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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 <[EMAIL PROTECTED]>. 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 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
>> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
>> 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]>. > > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.3 USB Controller: VIA Technologies, Inc. VT82x 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 0x, DMI type 0, 20 bytes BIOS Information Vendor: Phoenix Technologies, LTD Version: 6.00 PG Release Date: 11/30/2005 Address: 0xE 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 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.3 USB Controller: VIA Technologies, Inc. VT82x 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 0x, DMI type 0, 20 bytes BIOS Information Vendor: Phoenix Technologies, LTD Version: 6.00 PG Release Date: 11/30/2005 Address: 0xE 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 -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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]. 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 [EMAIL PROTECTED]. 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 -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 11010110
Power management: Powersaver
MSR: 0x110a=0x07ff000d000280f0 : 0111 1101
0010 1000
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
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
00dd
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 [EMAIL PROTECTED].
Found 1 CPU
MP Table:
# APIC ID Version State Family Model StepFlags
--
eax in: 0x, eax = 0001 ebx = 746e6543 ecx = 736c7561 edx = 48727561
eax in: 0x0001, eax = 0698 ebx = ecx = edx = 0381b13f
eax in: 0x8000, eax = 8006 ebx = ecx = edx =
eax in: 0x8001, eax = ebx = ecx = edx =
eax in: 0x8002, eax = 20414956 ebx = 6568654e ecx = 6861696d edx =
eax in: 0x8003, eax = ebx = ecx = edx =
eax in: 0x8004, eax = ebx = ecx = edx =
eax in: 0x8005, eax = ebx = 08800880 ecx = 40040120 edx = 40040120
eax in: 0x8006, eax = ebx = ecx = 00408120 edx =
eax in: 0xc000, eax = c001 ebx = ecx = edx =
eax in: 0xc001, eax = ebx = ecx = edx = 00dd
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: 0x1107=0x9e3f1ad2 : 1000 0011 00011010 11010010
Power management: Powersaver
MSR: 0x110a=0x07ff000480f0 : 0111 0100
1000
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
--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 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 00dd dd is very important here. Jan Rafał -- Kasia Cichopek eksponuje biust http://link.interia.pl/f1a6f - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 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 00dd CPU: After generic identify, caps: 0381b03f 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 00dd Jan -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
:-/ 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
>>> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
>> 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 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 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 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
> [...] > > 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 <[EMAIL PROTECTED]> > Date: Sun, 22 Apr 2007 10:26:04 + (+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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 <[EMAIL PROTECTED]>
Date: Sun, 22 Apr 2007 10:26:04 + (+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 <[EMAIL PROTECTED]>
Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
---
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]";
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 [EMAIL PROTECTED]
Date: Sun, 22 Apr 2007 10:26:04 + (+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 [EMAIL PROTECTED]
Signed-off-by: Dave Jones [EMAIL PROTECTED]
---
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];
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
[...] 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 [EMAIL PROTECTED] Date: Sun, 22 Apr 2007 10:26:04 + (+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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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
--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
