Re: Laptop keyboard unusable when ACPI is active
Many responsible CCs added. On 2007-10-20 18:33:09 Pavel Machek responded to Daniele C.: > > > Try disabling acpi embedded controller. > > > > > How can I accomplish this? Are you referring to the i8042? > > rmmod acpi_ec or how is it called. But I'm not sure how easy this is. Designed to be 'hard' because it in effect breaks several functions. See "config ACPI_EC" in drivers/acpi/Kconfig which one must edit manually, as well as arch/*/configs/*_defconfig Either way, the result is exactly as not loading modularized battery and ac (thermal module still worked on my system). But this whole issue is getting ridiculous. INPUT subsystem is addled more and more by ACPI (in real laptop life) while the maintainers, from a user view, seem stumped. The bad interaction between ACPI controlled EC (embedded controller) and the i8042 interrupt handler is theorized about in detail at OLPCs http://dev.laptop.org/ticket/2401 - almost at the end of that page. Thanks to Daniele C for the link. And the bug scenario has been present for many _years_ now. From my own experience it is only getting worse. Here's the current relations in 2.6.24-rc3-git1 _EC-reading ACPI modules unloaded_ Notebook keyboard and Synaptics touchpad operations all perfectly OK. Nothing related show up in the logs. _EC-reading ACPI modules loaded_ Keyboard keys get stuck when EC is accessed for battery, temperature etc. Touchpad (mouse pointer) gets stuck for up to ca 5 seconds if I eg move a window while EC data is read. The logs are spammed when EC screws over i8042: psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio4/input0 - driver resynched. psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: issuing reconnect request [etc] Messages about an unknown key show up (possibly in relation to a stuck key). I don't have this on disk, so I'll copy the message from the bug http://bugzilla.kernel.org/show_bug.cgi?id=9147 atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 ' to make it known. _EC-reading ACPI modules loaded. Command line option i8042.nomux used_ Keyboard keys _can_ get stuck when EC is accessed for battery, temperature etc. Much less frequent than without i8042.nomux though. Synaptics touchpad operations OK. Nothing related show up in the logs. I know that some kind of US holiday is in effect presently, but please make an effort to take a coordinated look at this afterwards. The issues are so old and widespread that even the angels cry (I'm told). PS. No, Dmitry. Lowering the report rate, eg psmouse.rate=40 does not fix anything, as I tried on your suggestion already in August 2006. - 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: Laptop keyboard unusable when ACPI is active
Many responsible CCs added. On 2007-10-20 18:33:09 Pavel Machek responded to Daniele C.: Try disabling acpi embedded controller. How can I accomplish this? Are you referring to the i8042? rmmod acpi_ec or how is it called. But I'm not sure how easy this is. Designed to be 'hard' because it in effect breaks several functions. See config ACPI_EC in drivers/acpi/Kconfig which one must edit manually, as well as arch/*/configs/*_defconfig Either way, the result is exactly as not loading modularized battery and ac (thermal module still worked on my system). But this whole issue is getting ridiculous. INPUT subsystem is addled more and more by ACPI (in real laptop life) while the maintainers, from a user view, seem stumped. The bad interaction between ACPI controlled EC (embedded controller) and the i8042 interrupt handler is theorized about in detail at OLPCs http://dev.laptop.org/ticket/2401 - almost at the end of that page. Thanks to Daniele C for the link. And the bug scenario has been present for many _years_ now. From my own experience it is only getting worse. Here's the current relations in 2.6.24-rc3-git1 _EC-reading ACPI modules unloaded_ Notebook keyboard and Synaptics touchpad operations all perfectly OK. Nothing related show up in the logs. _EC-reading ACPI modules loaded_ Keyboard keys get stuck when EC is accessed for battery, temperature etc. Touchpad (mouse pointer) gets stuck for up to ca 5 seconds if I eg move a window while EC data is read. The logs are spammed when EC screws over i8042: psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio4/input0 - driver resynched. psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: issuing reconnect request [etc] Messages about an unknown key show up (possibly in relation to a stuck key). I don't have this on disk, so I'll copy the message from the bug http://bugzilla.kernel.org/show_bug.cgi?id=9147 atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 keycode' to make it known. _EC-reading ACPI modules loaded. Command line option i8042.nomux used_ Keyboard keys _can_ get stuck when EC is accessed for battery, temperature etc. Much less frequent than without i8042.nomux though. Synaptics touchpad operations OK. Nothing related show up in the logs. I know that some kind of US holiday is in effect presently, but please make an effort to take a coordinated look at this afterwards. The issues are so old and widespread that even the angels cry (I'm told). PS. No, Dmitry. Lowering the report rate, eg psmouse.rate=40 does not fix anything, as I tried on your suggestion already in August 2006. - 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: 2.6.23-rc4-mm1
c8e] 00:0b.1 CardBus bridge [0607]: Texas Instruments PCI7420 CardBus Controller [104c:ac8e] 00:0b.2 FireWire (IEEE 1394) [0c00]: Texas Instruments PCI7x20 1394a-2000 OHCI Two-Port PHY/Link-Layer Controller [104c:802e] 00:0c.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet [10ec:8169] (rev 10) 00:10.0 USB Controller [0c03]: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] (rev 80) 00:10.1 USB Controller [0c03]: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] (rev 80) 00:10.2 USB Controller [0c03]: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] (rev 80) 00:10.3 USB Controller [0c03]: VIA Technologies, Inc. USB 2.0 [1106:3104] (rev 82) 00:11.0 ISA bridge [0601]: VIA Technologies, Inc. VT8235 ISA Bridge [1106:3177] 00:11.1 IDE interface [0101]: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE [1106:0571] (rev 06) 00:11.5 Multimedia audio controller [0401]: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller [1106:3059] (rev 50) 00:11.6 Communication controller [0780]: VIA Technologies, Inc. AC'97 Modem Controller [1106:3068] (rev 80) 00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100] 00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101] 00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102] 00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103] 01:00.0 VGA compatible controller [0300]: nVidia Corporation NV36 [GeForce FX Go5700] [10de:0347] (rev a1) Mvh Mats Johannesson - 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: 2.6.23-rc4-mm1
CardBus bridge [0607]: Texas Instruments PCI7420 CardBus Controller [104c:ac8e] 00:0b.2 FireWire (IEEE 1394) [0c00]: Texas Instruments PCI7x20 1394a-2000 OHCI Two-Port PHY/Link-Layer Controller [104c:802e] 00:0c.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet [10ec:8169] (rev 10) 00:10.0 USB Controller [0c03]: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] (rev 80) 00:10.1 USB Controller [0c03]: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] (rev 80) 00:10.2 USB Controller [0c03]: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] (rev 80) 00:10.3 USB Controller [0c03]: VIA Technologies, Inc. USB 2.0 [1106:3104] (rev 82) 00:11.0 ISA bridge [0601]: VIA Technologies, Inc. VT8235 ISA Bridge [1106:3177] 00:11.1 IDE interface [0101]: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE [1106:0571] (rev 06) 00:11.5 Multimedia audio controller [0401]: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller [1106:3059] (rev 50) 00:11.6 Communication controller [0780]: VIA Technologies, Inc. AC'97 Modem Controller [1106:3068] (rev 80) 00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100] 00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101] 00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102] 00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103] 01:00.0 VGA compatible controller [0300]: nVidia Corporation NV36 [GeForce FX Go5700] [10de:0347] (rev a1) Mvh Mats Johannesson - 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: [PATCH] x86-64 highres/dyntick support
On Sun May 06 2007 - Europe Evening Time Thomas Gleixner wrote: > I'm pleased to announce the first cut of the final x86_64 > highres/dyntick support, which I did based on Chris Wright's patch > set, which is again based on Arjan van de Ven's initial work: [...] > Comments, bugreports, patches are welcome as ususal Are questions welcome? Then I'd ask: "What are the _minimal_ CPU requirements to gain anything (eg less power consumption) with dyntick?" I ask because of a trial round with Chris Wright's patch set on a fresh battery, idle system outside X with wifi card shut off and HZ set to 100 (from my normal 1000): [EMAIL PROTECTED]:~# ls -l battest-the-new-battery/* battest-the-new-battery/dyn-100hz-2.6.21: total 4 -rw-r--r-- 1 root root 0 2007-04-27 00:50 start -rw-r--r-- 1 root root 0 2007-04-27 03:54 stop -rwxr-xr-x 1 root root 72 2007-04-26 22:16 test-batt.bash battest-the-new-battery/plain-2.6.21: total 4 -rw-r--r-- 1 root root 0 2007-04-27 13:16 start -rw-r--r-- 1 root root 0 2007-04-27 16:22 stop -rwxr-xr-x 1 root root 72 2007-04-26 22:16 test-batt.bash [EMAIL PROTECTED]:~# The script just touched the "stop" file with a 2 minutes interval until the machine died. As seen by the plus/minus 2 minutes results there is absolutely no difference. This AMD 64 Mobile processor only has a C1 level which isn't used: [EMAIL PROTECTED]:~# cat /proc/acpi/processor/CPU0/power active state:C1 max_cstate: C8 bus master activity: maximum allowed latency: 2000 usec states: *C1: type[C1] promotion[--] demotion[--] latency[000] usage[] duration[] But shouldn't the the kernel 'hlt' routine, or whatever it's called, work in conjunction with dyntick to achieve... something...? CPU markings are: Mobile AMD Athlon 64 AMA3400BEX5AR 1169004L40404 CAAZC 0451APMW 2001 AMD Assembled in Malaysia [EMAIL PROTECTED]:~# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 4 model name : AMD Athlon(tm) 64 Processor 3400+ stepping: 10 cpu MHz : 800.000 cache size : 1024 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow bogomips: 1601.73 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp Mvh, Mats - 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: [PATCH] x86-64 highres/dyntick support
On Sun May 06 2007 - Europe Evening Time Thomas Gleixner wrote: I'm pleased to announce the first cut of the final x86_64 highres/dyntick support, which I did based on Chris Wright's patch set, which is again based on Arjan van de Ven's initial work: [...] Comments, bugreports, patches are welcome as ususal Are questions welcome? Then I'd ask: What are the _minimal_ CPU requirements to gain anything (eg less power consumption) with dyntick? I ask because of a trial round with Chris Wright's patch set on a fresh battery, idle system outside X with wifi card shut off and HZ set to 100 (from my normal 1000): [EMAIL PROTECTED]:~# ls -l battest-the-new-battery/* battest-the-new-battery/dyn-100hz-2.6.21: total 4 -rw-r--r-- 1 root root 0 2007-04-27 00:50 start -rw-r--r-- 1 root root 0 2007-04-27 03:54 stop -rwxr-xr-x 1 root root 72 2007-04-26 22:16 test-batt.bash battest-the-new-battery/plain-2.6.21: total 4 -rw-r--r-- 1 root root 0 2007-04-27 13:16 start -rw-r--r-- 1 root root 0 2007-04-27 16:22 stop -rwxr-xr-x 1 root root 72 2007-04-26 22:16 test-batt.bash [EMAIL PROTECTED]:~# The script just touched the stop file with a 2 minutes interval until the machine died. As seen by the plus/minus 2 minutes results there is absolutely no difference. This AMD 64 Mobile processor only has a C1 level which isn't used: [EMAIL PROTECTED]:~# cat /proc/acpi/processor/CPU0/power active state:C1 max_cstate: C8 bus master activity: maximum allowed latency: 2000 usec states: *C1: type[C1] promotion[--] demotion[--] latency[000] usage[] duration[] But shouldn't the the kernel 'hlt' routine, or whatever it's called, work in conjunction with dyntick to achieve... something...? CPU markings are: Mobile AMD Athlon 64 AMA3400BEX5AR 1169004L40404 CAAZC 0451APMW 2001 AMD Assembled in Malaysia [EMAIL PROTECTED]:~# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 4 model name : AMD Athlon(tm) 64 Processor 3400+ stepping: 10 cpu MHz : 800.000 cache size : 1024 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow bogomips: 1601.73 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp Mvh, Mats - 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/
