Re: high system cpu load during intense disk i/o

So I would assume that delay_tsc() probably only makes the situation worse for the libata tests, but the real problem is at __switch_to() and schedule(). Do you agree with these assumptions? Yes. I agree that percentage of CPU time is unreasonably high for these functions. But not only for

Re: high system cpu load during intense disk i/o

So I would assume that delay_tsc() probably only makes the situation worse for the libata tests, but the real problem is at __switch_to() and schedule(). Do you agree with these assumptions? Yes. I agree that percentage of CPU time is unreasonably high for these functions. But not only for

Re: high system cpu load during intense disk i/o

Hello again, Hi, I 'm now using libata on the same system described before (see attached dmesg.txt). When writing to both disks I think the problem is now worse (pata_oprof_bad.txt, pata_vmstat_bad.txt), even the oprofile script needed half an hour to complete! For completion I also attach

Re: high system cpu load during intense disk i/o

Hello again, Hi, I 'm now using libata on the same system described before (see attached dmesg.txt). When writing to both disks I think the problem is now worse (pata_oprof_bad.txt, pata_vmstat_bad.txt), even the oprofile script needed half an hour to complete! For completion I also attach

Re: HPET force-enable investigations on Via VT8235

Hi, BTW, is there any obvious chipset ecosystem difference in your system? Are any other important PCI IDs/revs different from mine? I don't see any differences. 00:00.0 Host bridge [0600]: VIA Technologies, Inc. VT8623 [Apollo CLE266] [1106:3123] 00:01.0 PCI bridge [0604]: VIA Technologies,

Re: high system cpu load during intense disk i/o

Just tested (plain curiosity). via82cxxx average result @533MHz: /dev/hda: Timing cached reads: 232 MB in 2.00 seconds = 115.93 MB/sec Timing buffered disk reads: 64 MB in 3.12 seconds = 20.54 MB/sec pata_via average result @533MHz: /dev/sda: Timing cached reads: 234 MB in 2.01 seconds

Re: HPET force-enable investigations on Via VT8235

RB> VT8235 does *NOT* have a HPET(*). Only part which has HPET is VT8237. It RB> is device 00:17.0 too, but only 1106:3227 has HPET enable and memory RB> base registers. VT8235 one and only feature which doesn't have driver RB> yet seems to be hardware watchdog. RB> (*) Datasheet revision 2.03

Re: HPET force-enable investigations on Via VT8235

RB VT8235 does *NOT* have a HPET(*). Only part which has HPET is VT8237. It RB is device 00:17.0 too, but only 1106:3227 has HPET enable and memory RB base registers. VT8235 one and only feature which doesn't have driver RB yet seems to be hardware watchdog. RB (*) Datasheet revision 2.03 March

Re: high system cpu load during intense disk i/o

Just tested (plain curiosity). via82cxxx average result @533MHz: /dev/hda: Timing cached reads: 232 MB in 2.00 seconds = 115.93 MB/sec Timing buffered disk reads: 64 MB in 3.12 seconds = 20.54 MB/sec pata_via average result @533MHz: /dev/sda: Timing cached reads: 234 MB in 2.01 seconds

Re: HPET force-enable investigations on Via VT8235

Hi, BTW, is there any obvious chipset ecosystem difference in your system? Are any other important PCI IDs/revs different from mine? I don't see any differences. 00:00.0 Host bridge [0600]: VIA Technologies, Inc. VT8623 [Apollo CLE266] [1106:3123] 00:01.0 PCI bridge [0604]: VIA Technologies,

Re: high system cpu load during intense disk i/o

Hello Rafal, Hello, However I find it quite possible to have reached the throughput limit because of software (driver) problems. I have done various testing (mostly "hdparm -tT" with exactly the same PC and disks since about kernel 2.6.8 (maybe even earlier). I remember with certainty that

Re: HPET force-enable investigations on Via VT8235

Hi, Hi, So, *please* (I'd *love* to get this working somehow): whoever has a VT8235 and is listening here, - give a "lspci -nn" (two 'n'!), to figure out details of chipset revision etc. - give a "lspci -d 1106:3177 -xxx", to try to figure out whether there happen to be additional magical

Re: high system cpu load during intense disk i/o

Hello and thanks for your reply. Hello again, The cron job that is running every 10 min on my system is mpop (a fetchmail-like program) and another running every 5 min is mrtg. Both normally finish within 1-2 seconds. The fact that these simple cron jobs don't finish ever is certainly

Re: high system cpu load during intense disk i/o

Hello and thanks for your reply. Hello again, The cron job that is running every 10 min on my system is mpop (a fetchmail-like program) and another running every 5 min is mrtg. Both normally finish within 1-2 seconds. The fact that these simple cron jobs don't finish ever is certainly

Re: HPET force-enable investigations on Via VT8235

Hi, Hi, So, *please* (I'd *love* to get this working somehow): whoever has a VT8235 and is listening here, - give a lspci -nn (two 'n'!), to figure out details of chipset revision etc. - give a lspci -d 1106:3177 -xxx, to try to figure out whether there happen to be additional magical enable

Re: high system cpu load during intense disk i/o

Hello Rafal, Hello, However I find it quite possible to have reached the throughput limit because of software (driver) problems. I have done various testing (mostly hdparm -tT with exactly the same PC and disks since about kernel 2.6.8 (maybe even earlier). I remember with certainty that read

Re: high system cpu load during intense disk i/o

Hello and thanks for your reply. Hi, The cron job that is running every 10 min on my system is mpop (a fetchmail-like program) and another running every 5 min is mrtg. Both normally finish within 1-2 seconds. The fact that these simple cron jobs don't finish ever is certainly because of the

Re: high system cpu load during intense disk i/o

Hello again, Hi! was my report so complicated? Perhaps I shouldn't have included so many oprofile outputs. Anyway, if anyone wants to have a look, the most important is two_discs_bad.txt oprofile output, attached on my original message. The problem is 100% reproducible for me so I would

Re: high system cpu load during intense disk i/o

Hello again, Hi! was my report so complicated? Perhaps I shouldn't have included so many oprofile outputs. Anyway, if anyone wants to have a look, the most important is two_discs_bad.txt oprofile output, attached on my original message. The problem is 100% reproducible for me so I would

Re: high system cpu load during intense disk i/o

Hello and thanks for your reply. Hi, The cron job that is running every 10 min on my system is mpop (a fetchmail-like program) and another running every 5 min is mrtg. Both normally finish within 1-2 seconds. The fact that these simple cron jobs don't finish ever is certainly because of the

[PATCH] Remove bdput from do_open() in fs/block_dev.c

0x0/0x1e0 === Removing bdput from do_open() in fs/block_dev.c seems to be a cure for irq timeout. Signed-off-by: Rafał Bilski <[EMAIL PROTECTED]> --- diff --git a/fs/block_dev.c b/fs/block_dev.c --- a/fs/block_dev.c +++ b/fs/block_dev.c @@ -1120,7 +1120,6 @@ static in

[PATCH] Remove bdput from do_open() in fs/block_dev.c

[c0281a46] acpi_processor_idle+0x162/0x380 [c0100d0e] cpu_idle+0x4e/0x70 [c0524ac5] start_kernel+0x1f5/0x240 [c05243a0] unknown_bootoption+0x0/0x1e0 === Removing bdput from do_open() in fs/block_dev.c seems to be a cure for irq timeout. Signed-off-by: Rafał Bilski [EMAIL PROTECTED

Re: [PATCH] mtd: Makefile fix (was Re: [PATCH] mtdsuper: licensce = GPL)

[PATCH] mtd: Makefile fix We want drivers/mtd/{mtdcore, mtdsuper, mtdpart}.c to be built and linked into the same mtd.ko module. Fix the Makefile to ensure this, and remove duplicate MODULE_ declarations in mtdpart.c, as mtdcore.c already has them. Signed-off-by: Satyam Sharma <[EMAIL

Re: [PATCH] mtd: Makefile fix (was Re: [PATCH] mtdsuper: licensce = GPL)

[PATCH] mtd: Makefile fix We want drivers/mtd/{mtdcore, mtdsuper, mtdpart}.c to be built and linked into the same mtd.ko module. Fix the Makefile to ensure this, and remove duplicate MODULE_ declarations in mtdpart.c, as mtdcore.c already has them. Signed-off-by: Satyam Sharma [EMAIL PROTECTED]

JFFS2 BUG

Hi, I can't find JFFS2 maintainer so I'm sending it to MTD maintainer. I don't have luck in this week :-( Linux: 2.6.23-rc1-git3 (2.6.22.1 patched - that's why version is wrong) Command which caused BUG(): chmod o+r * ezri user.warn kernel: argh. node added in wrong place ezri user.alert

Re: CS5530 Alsa driver fails

The 5530 in native mode only generates SMI. I've always felt however that if you make the buffers big enough you ought to be able to drive it off the 1KHz timer tick by polling. Interesting project. Looks like somebody did it already. I will try it as soon as I can. You btw won't have removed

Re: [PATCH] mtdsuper: licensce = GPL

You should apply -rcN or -gitX patches on the previous Linus' kernel (2.6.x) and not the 2.6.x.y "-stable" ones -- those are a "parallel" tree. Done. Hmm, you've got mtdpart build separately as well. Could you redo as per what I suggested above (take 2.6.22, apply -rc1, then -rc1-git3) and then

Re: [PATCH] mtdsuper: licensce = GPL

block2mtd: version $Revision: 1.30 $ block2mtd: mtd0: [d: /dev/sdc2] erase_size = 64KiB [65536] mtdsuper: module license 'unspecified' taints kernel. mtdsuper: Unknown symbol get_mtd_device mtdsuper: Unknown symbol put_mtd_device jffs2: Unknown symbol get_sb_mtd jffs2: Unknown symbol

Re: [PATCH] mtdsuper: licensce = GPL

block2mtd: version $Revision: 1.30 $ block2mtd: mtd0: [d: /dev/sdc2] erase_size = 64KiB [65536] mtdsuper: module license 'unspecified' taints kernel. mtdsuper: Unknown symbol get_mtd_device mtdsuper: Unknown symbol put_mtd_device jffs2: Unknown symbol get_sb_mtd jffs2: Unknown symbol

Re: [PATCH] mtdsuper: licensce = GPL

You should apply -rcN or -gitX patches on the previous Linus' kernel (2.6.x) and not the 2.6.x.y -stable ones -- those are a parallel tree. Done. Hmm, you've got mtdpart build separately as well. Could you redo as per what I suggested above (take 2.6.22, apply -rc1, then -rc1-git3) and then

Re: CS5530 Alsa driver fails

The 5530 in native mode only generates SMI. I've always felt however that if you make the buffers big enough you ought to be able to drive it off the 1KHz timer tick by polling. Interesting project. Looks like somebody did it already. I will try it as soon as I can. You btw won't have removed

JFFS2 BUG

Hi, I can't find JFFS2 maintainer so I'm sending it to MTD maintainer. I don't have luck in this week :-( Linux: 2.6.23-rc1-git3 (2.6.22.1 patched - that's why version is wrong) Command which caused BUG(): chmod o+r * ezri user.warn kernel: argh. node added in wrong place ezri user.alert

Problem with udev and block2mtd

Hi! I have changed static /dev to udev on my machine. It has a lot of RAM (94MB) so I was expecting that udev will not make things worse. Unfortunately udev isn't noticing that new mtd device was born. I was suspecting that this is my fault, but udev's /dev is populated and:

Re: CS5530 Alsa driver fails

Hi Rafał, It seems that you're already using irq 9 for another device, and as Alan says the cs5530 audio device doesn't seem to do irq sharing. It seems to me that you need to go into your BIOS settings at startup and tell the device to use an irq line that's not already in use by some other

[PATCH] mtdsuper: licensce = GPL

kill_mtd_super Signed-off-by: Rafał Bilski <[EMAIL PROTECTED]> --- drivers/mtd/mtdsuper.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/mtd/mtdsuper.c b/drivers/mtd/mtdsuper.c index aca3319..3510ed0 100644 --- a/drivers/mtd/mtdsuper.c +++ b/drivers/mtd/mtdsuper.c @@

Re: CS5530 Alsa driver fails

Might be worth setting the IRQ to sharable. I've never seen a 5530 with the sound IRQ shared so I don't know if that works and is a valid configuration for the VSA firmware The relevant patch is below. Please give it a try. Takashi - if (request_irq(irq, irq_handler, hardware ==

Re: CS5530 Alsa driver fails

Might be worth setting the IRQ to sharable. I've never seen a 5530 with the sound IRQ shared so I don't know if that works and is a valid configuration for the VSA firmware The relevant patch is below. Please give it a try. Takashi - if (request_irq(irq, irq_handler, hardware ==

[PATCH] mtdsuper: licensce = GPL

kill_mtd_super Signed-off-by: Rafał Bilski [EMAIL PROTECTED] --- drivers/mtd/mtdsuper.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/mtd/mtdsuper.c b/drivers/mtd/mtdsuper.c index aca3319..3510ed0 100644 --- a/drivers/mtd/mtdsuper.c +++ b/drivers/mtd/mtdsuper.c @@ -230,3

Re: CS5530 Alsa driver fails

Hi Rafał, It seems that you're already using irq 9 for another device, and as Alan says the cs5530 audio device doesn't seem to do irq sharing. It seems to me that you need to go into your BIOS settings at startup and tell the device to use an irq line that's not already in use by some other

Problem with udev and block2mtd

Hi! I have changed static /dev to udev on my machine. It has a lot of RAM (94MB) so I was expecting that udev will not make things worse. Unfortunately udev isn't noticing that new mtd device was born. I was suspecting that this is my fault, but udev's /dev is populated and:

CS5530 Alsa driver fails

Hello, Linux: 2.6.23-rc1-git3 Hardware: CX5530 After "modprobe snd-cs5530" I have: CS5530: XpressAudio at 0x220 CS5530: MPU at 0x330 CS5530: IRQ: 9 DMA8: 0 DMA16: 5 sb: can't grab irq 9 CS5530: Could not create SoundBlaster CS5530_Audio: probe of :00:12.3 failed with error -16 Thank You

CS5530 Alsa driver fails

Hello, Linux: 2.6.23-rc1-git3 Hardware: CX5530 After modprobe snd-cs5530 I have: CS5530: XpressAudio at 0x220 CS5530: MPU at 0x330 CS5530: IRQ: 9 DMA8: 0 DMA16: 5 sb: can't grab irq 9 CS5530: Could not create SoundBlaster CS5530_Audio: probe of :00:12.3 failed with error -16 Thank You

[PATCH] Hardware MPEG audio fix for SAA7134 based "KNC One TV-Station DVR" card

With previous patch card is generating MPEG audio stream too. Unfortunatly I2S audio output is muted. Unmute it. Signed-off-by: Rafal Bilski <[EMAIL PROTECTED]> --- drivers/media/video/saa7134/saa7134-empress.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git

[PATCH] Alsa fix for SAA7134 based "KNC One TV-Station DVR" card

Sound recording doesn't work for this card because ACNI and ACPF are not set before snd_card_saa7134_capture_prepare(). As a result timeout occurs. These registers aren't poked because thread never gets wake up signal. ACNI initialization is done in the thread. Sound is muted when capture stops.

[PATCH] Alsa fix for SAA7134 based KNC One TV-Station DVR card

Sound recording doesn't work for this card because ACNI and ACPF are not set before snd_card_saa7134_capture_prepare(). As a result timeout occurs. These registers aren't poked because thread never gets wake up signal. ACNI initialization is done in the thread. Sound is muted when capture stops.

[PATCH] Hardware MPEG audio fix for SAA7134 based KNC One TV-Station DVR card

With previous patch card is generating MPEG audio stream too. Unfortunatly I2S audio output is muted. Unmute it. Signed-off-by: Rafal Bilski [EMAIL PROTECTED] --- drivers/media/video/saa7134/saa7134-empress.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git

Problem with SAA7134 driver

Hi! I have bought recently 00:14.0 Multimedia controller: Philips Semiconductors SAA7134/SAA7135HL Video Broadcast Decoder (rev 01) Subsystem: KNC One KNC One TV-Station DVR Flags: bus master, medium devsel, latency 32, IRQ 11 Memory at d6003000 (32-bit, non-prefetchable)

Problem with SAA7134 driver

Hi! I have bought recently 00:14.0 Multimedia controller: Philips Semiconductors SAA7134/SAA7135HL Video Broadcast Decoder (rev 01) Subsystem: KNC One KNC One TV-Station DVR Flags: bus master, medium devsel, latency 32, IRQ 11 Memory at d6003000 (32-bit, non-prefetchable)

Re: NOHZ: local_softirq_pending 08

>> Hi! >> >> A lot of "NOHZ: local_softirq_pending 08" messages (about 100) and >> then suddenly stoped to show. I have 2.6.21.1. I checked .2 and .3 >> changelogs but I don't see anything about this message. >> What does it mean? >> >> Is "08" IRQ number? >> 8: 2XT-PIC-XT

Re: NOHZ: local_softirq_pending 08

Hi! A lot of NOHZ: local_softirq_pending 08 messages (about 100) and then suddenly stoped to show. I have 2.6.21.1. I checked .2 and .3 changelogs but I don't see anything about this message. What does it mean? Is 08 IRQ number? 8: 2XT-PIC-XTrtc Please CC me.

NOHZ: local_softirq_pending 08

Hi! A lot of "NOHZ: local_softirq_pending 08" messages (about 100) and then suddenly stoped to show. I have 2.6.21.1. I checked .2 and .3 changelogs but I don't see anything about this message. What does it mean? Is "08" IRQ number? 8: 2XT-PIC-XTrtc Please CC me. Thank

NOHZ: local_softirq_pending 08

Hi! A lot of NOHZ: local_softirq_pending 08 messages (about 100) and then suddenly stoped to show. I have 2.6.21.1. I checked .2 and .3 changelogs but I don't see anything about this message. What does it mean? Is 08 IRQ number? 8: 2XT-PIC-XTrtc Please CC me. Thank You

Problem with 82365SL driver in 2.6.21.1

Hello, I have problem with PC card slot in Wyse 3360SE terminal. Card insertion or removal is detected, but nothing more. I tried two different cards. Same behaviour. Hardware is: > Intel ISA PCIC probe: > Intel i82365sl A step ISA-to-PCMCIA at port 0x3e0 ofs 0x00, 1 socket > host opts

Problem with 82365SL driver in 2.6.21.1

Hello, I have problem with PC card slot in Wyse 3360SE terminal. Card insertion or removal is detected, but nothing more. I tried two different cards. Same behaviour. Hardware is: Intel ISA PCIC probe: Intel i82365sl A step ISA-to-PCMCIA at port 0x3e0 ofs 0x00, 1 socket host opts [0]:

[PATCH] Longhaul - Broken again

Not so long ago Longhaul was marked broken, because to protect system from lockup it was clearing BMDMA master bit on each device. Later I came with patches which make use of hardware support present in VIA north and south bridges. Unfortunately after some time this support seems to be broken

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.

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

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

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.

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ł

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.

[PATCH] Longhaul - Broken again

Not so long ago Longhaul was marked broken, because to protect system from lockup it was clearing BMDMA master bit on each device. Later I came with patches which make use of hardware support present in VIA north and south bridges. Unfortunately after some time this support seems to be broken

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

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

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

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

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

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 >>

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]>. >

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

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

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

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

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

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

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

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

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

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

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

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. >>

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

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

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

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

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

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

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

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

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

Re: [PATCH 0/2] natsemi: Improve DspCfg workaround

> The natsemi driver contains a workaround for broken hardware which can > on some boards cause more problems than it solves. The following patch > series improves this by making the diagnostic more obvious and allowing > users to disable the workaround if it causes them problems. Works great.

Re: Natsemi DP83815 driver spaming

>> What about module option? > > That would work, though you crossed in the post with me writing a patch > adding a sysfs file; I merged the two for overkill (below). I also have > a patch which changes the log message for the workaround so that it is > displayed by default in order to make this

Re: Natsemi DP83815 driver spaming

What about module option? That would work, though you crossed in the post with me writing a patch adding a sysfs file; I merged the two for overkill (below). I also have a patch which changes the log message for the workaround so that it is displayed by default in order to make this easier

Re: [PATCH 0/2] natsemi: Improve DspCfg workaround

The natsemi driver contains a workaround for broken hardware which can on some boards cause more problems than it solves. The following patch series improves this by making the diagnostic more obvious and allowing users to disable the workaround if it causes them problems. Works great. Thank

Re: Natsemi DP83815 driver spaming

>> > I'm not sure what the right answer is. The code was designed to do >> > the right thing, and yet in your case it's broken. Does it need to be >> > a build option to work around broken hardware? Yuck. >> >> Without a system that really needs the original problem that was being >> worked

Re: Natsemi DP83815 driver spaming

[...] > >> With code commented out I have 1 error / 3 transmitted packets from >> DP83815C. I have 1 error / 10 transmitted packets to DP83815C. Maybe >> it works at all because I have short cable, only 10m long. >> I don't remember any errors with plain 2.6.21.1. Sorry. I mean

Re: Natsemi DP83815 driver spaming

[...] With code commented out I have 1 error / 3 transmitted packets from DP83815C. I have 1 error / 10 transmitted packets to DP83815C. Maybe it works at all because I have short cable, only 10m long. I don't remember any errors with plain 2.6.21.1. Sorry. I mean transmition errors,

Re: Natsemi DP83815 driver spaming

I'm not sure what the right answer is. The code was designed to do the right thing, and yet in your case it's broken. Does it need to be a build option to work around broken hardware? Yuck. Without a system that really needs the original problem that was being worked around it's going

Re: Natsemi DP83815 driver spaming

>> > > * 2) check for sudden death of the NIC: >> > > *It seems that a reference set for this chip went out with >> incorrect info, >> > > *and there exist boards that aren't quite right. An >> unexpected voltage >> > > *drop can cause the PHY to get itself in a weird state >>

Re: Natsemi DP83815 driver spaming

>> eth0: Media selection timer tick. >> eth0: possible phy reset: re-initializing > > This is why the reset is being triggered - it's a workaround for a hardware > bug which checks to make sure the hardware is in the state that the > kernel thinks it is is going off. The code has this

  1   2   >