Re: [ibm-acpi-devel] [PATCH AUTOSEL 6.1 12/24] platform/x86: thinkpad_acpi: fix for incorrect fan reporting on some ThinkPad systems

Hi! > [ Upstream commit 66e92e23a72761f5b53f970aeb1badc5fd92fc74 ] > > Some ThinkPad systems ECFW use non-standard addresses for fan control > and reporting. This patch adds support for such ECFW so that it can report > the correct fan values. > Tested on Thinkpads L13 Yoga Gen 2 and X13 Yoga

Re: [ibm-acpi-devel] [PATCH v2] Input: document inhibiting

Hi! > +Inhibiting input devices > + > + > +Inhibiting a device means ignoring input events from it. As such it is about > maintaining > +relationships with input handlers - either already existing relationships, > or relationships > +to be established while the device is

Re: [ibm-acpi-devel] [PATCH v3 0/7] Support inhibiting input devices

On Fri 2020-06-05 19:33:28, Andrzej Pietrasiewicz wrote: > Userspace might want to implement a policy to temporarily disregard input > from certain devices. Wow, you certainly cc a lot of lists. > An example use case is a convertible laptop, whose keyboard can be folded > under the screen to

Re: [ibm-acpi-devel] [PATCH] leds: avoid races with workqueue

Hi! > >Yes, that looks right. If you can add fixes: and cc: stable tags, the > >rest should happen automagically. > > Cc: sta...@kernel.org is exactly for what it claims - sending a copy > to that list. > > "Fixes:" seems to be always enough for the bots to pick a patch. > > Tag added. Well,

Re: [ibm-acpi-devel] [PATCH] leds: avoid races with workqueue

On Thu 2019-05-02 21:28:06, Jacek Anaszewski wrote: > On 5/2/19 9:13 PM, Pavel Machek wrote: > >Hi! > > > >>>>>+++ b/drivers/leds/led-class.c > >>>>>@@ -57,6 +57,7 @@ static ssize_t brightness_store(struc

Re: [ibm-acpi-devel] [PATCH] leds: avoid races with workqueue

Hi! > >>>+++ b/drivers/leds/led-class.c > >>>@@ -57,6 +57,7 @@ static ssize_t brightness_store(struct device *dev, > >>> if (state == LED_OFF) > >>> led_trigger_remove(led_cdev); > >>> led_set_brightness(led_cdev, state); > >>>+ flush_work(_cdev->set_brightness_work); > >> > >>Is

Re: [ibm-acpi-devel] [PATCH] leds: avoid races with workqueue

1 > brightness... but that does not work, either, > >if done too quickly. > >Synchronization of the workqueue fixes both. > >Signed-off-by: Pavel Machek > > > >diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c > >index 68aa923..dcb59c

[ibm-acpi-devel] [PATCH] leds: avoid races with workqueue

. Synchronization of the workqueue fixes both. Signed-off-by: Pavel Machek diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c index 68aa923..dcb59c8 100644 --- a/drivers/leds/led-class.c +++ b/drivers/leds/led-class.c @@ -57,6 +57,7 @@ static ssize_t brightness_st

[ibm-acpi-devel] [PATCH] leds: tpacpi: cleanup for Thinkpad ACPI led

Make error returns more consistent... no behaviour change intended. Signed-off-by: Pavel Machek diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c index 726341f..7008a7f 100644 --- a/drivers/platform/x86/thinkpad_acpi.c +++ b/drivers/platform/x86

Re: [ibm-acpi-devel] Thinkpad ACPI led -- it keeps blinking

Hi! > >This fixes one problem: > >Signed-off-by: Pavel Machek > > > >diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c > >index e3da7c0..d795d8f 100644 > >--- a/drivers/leds/led-core.c > >+++ b/drivers/leds/led-core.c > >@@ -164

Re: [ibm-acpi-devel] Thinkpad ACPI led -- it keeps blinking

Hi! It seems quite clear: static int timer_trig_activate(struct led_classdev *led_cdev) { printk("timer_trig_activate\n"); if (led_cdev->flags & LED_INIT_DEFAULT_TRIGGER) { led_blink_set(led_cdev, _cdev->blink_delay_on, _cdev->blink_delay_off);

Re: [ibm-acpi-devel] Thinkpad ACPI led -- it keeps blinking

On Sat 2019-04-27 22:35:35, Jacek Anaszewski wrote: > On 4/27/19 9:34 PM, Pavel Machek wrote: > >On Sat 2019-04-27 18:55:37, Jacek Anaszewski wrote: > >>On 4/26/19 11:42 PM, Pavel Machek wrote: > >>>Hi! > >>> > >>>>Kernel 5.1.0-rc1 +

Re: [ibm-acpi-devel] Thinkpad ACPI led -- it keeps blinking

Hi! > Kernel 5.1.0-rc1 + some unrelated bits. I tried adding https://marc.info/?l=linux-kernel=151622365715313=raw as Jacek suggested, and it is still broken. Test code is this: ledtest actually works as expected on first try, but keeps blinking on second run. Strange.

[ibm-acpi-devel] Thinkpad ACPI led -- it keeps blinking

Hi! Something is wrong with blinking on thinkpad pavel@amd:~/bt/blee$ cat /sys/class/leds/tpacpi\:\:power/trigger [none] bluetooth-power rfkill-any rfkill-none kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock

[ibm-acpi-devel] Well-known LED names was Re: [PATCH 0/6] Introduce audio-mute LED trigger (and conversions to it)

nting good and bad LEDs, so that patch authors know what is there, and can try to be consistent, and so that userland knows what names to probe for. What about following? Any other LEDs worth mentioning? commit c56708addf9c312cefd760bca218a0545258b217 Author: Pavel Date: Sat Dec 1 15:32:13 2018 +0

Re: [ibm-acpi-devel] [PATCH 0/6] Introduce audio-mute LED trigger (and conversions to it)

Hi! > > If external USB keyboard is identified as "input7" device, then > > "input7::mute" is a good name for mute key. But "sys::mute" does not say > > anything to which device or hardware it belongs nor does not solve > > problem that which device/driver/subsystem should have privilege to take

Re: [ibm-acpi-devel] [PATCH 0/6] Introduce audio-mute LED trigger (and conversions to it)

Hi! > > > >> A nice godfather is required here... > > > > > > > > Just use sys:: :-). > > > > > > > > laptop:: would work for me, too. (It is always laptop in the cases we > > > > are handling now, right?) > > > > > > > > When we get a keyboard with mute led, we'll have to decide if it > > > >

Re: [ibm-acpi-devel] [PATCH 0/6] Introduce audio-mute LED trigger (and conversions to it)

Hi! > Looks good... except one detail: you have "tpacpi::micmute" and > "dell::micmute". I know it follows "tradition", but we are trying to > fix that at the moment. Laptop micmute button is a laptop micmute > button, and userspace should not need to know what prefix to use >

Re: [ibm-acpi-devel] [PATCH 0/6] Introduce audio-mute LED trigger (and conversions to it)

On Wed 2018-11-28 12:38:19, Takashi Iwai wrote: > On Wed, 28 Nov 2018 12:18:06 +0100, > Pali Rohár wrote: > > > > On Tuesday 27 November 2018 09:44:18 Pavel Machek wrote: > > > Looks good... except one detail: you have "tpacpi::micmute" and > > >

Re: [ibm-acpi-devel] [PATCH 0/6] Introduce audio-mute LED trigger (and conversions to it)

that at the moment. Laptop micmute button is a laptop micmute button, and userspace should not need to know what prefix to use depending on vendor. I'd suggest using "sys::micmute". With that: Acked-by: Pavel Machek

Re: [ibm-acpi-devel] ThinkPad T480s & LED_MUTE, LED_MICMUTE

Hi! > > Question is if we want flexibility or security. > > For thinkpad-acpi, it is security by default. Flexibility is allowed as > *compile*-time (Kconfig) option, and only as long as it defaults to > secure *and* the help text is very explicit at instructing distros to > NOT enable this

Re: [ibm-acpi-devel] ThinkPad T480s & LED_MUTE, LED_MICMUTE

Hi! On Fri 2018-06-15 20:36:28, Henrique de Moraes Holschuh wrote: > On Fri, 15 Jun 2018, Pali Rohár wrote: > > This means that kernel should not export any led class device. Or when > > exported, then "set" operation should always fail. > > "not export" is right. > > > > 2. Otherwise implement

Re: [ibm-acpi-devel] ThinkPad T480s & LED_MUTE, LED_MICMUTE

Hi! > Hi! With up-to-date thinkpad_acpi.ko driver on ThinkPad T480s I'm seeing > a strange behavior of LEDs which are integrated into mic mute (Fn+F4) > and mute (Fn+F1) keys. > > When thinkpad_acpi.ko is not loaded, then mute key is working fine. When > pressed, it correctly generates KEY_MUTE

Re: [ibm-acpi-devel] [PATCH 2/3 v5] battery: Add the ThinkPad "Not Charging" quirk

On Sun 2017-12-10 19:05:29, Ognjen Galic wrote: > The EC/ACPI firmware on Lenovo ThinkPads used to report a status > of "Unknown" when the battery is between the charge start and > charge stop thresholds. On Windows, it reports "Not Charging" > so the quirk has been added to also report correctly.

Re: [ibm-acpi-devel] [PATCH v2] thinkpad_acpi: Support the battery wear control

On Sat 2017-12-09 11:29:51, Ognjen Galić wrote: > On 09/12/2017, Pavel Machek <pa...@ucw.cz> wrote: > > In newer series (I can't find it at the moment, sorry) > > The new series is a 3-patch patchset that obsoletes this > patch. It is in the testing stage and will be pushe

Re: [ibm-acpi-devel] [PATCH v2] thinkpad_acpi: Support the battery wear control

Hi! In newer series (I can't find it at the moment, sorry) you return "NOT_CHARGING" status when not charging because of wear control. Maybe we should have separate status "not charging due to wear control"? Thanks, Pavel

Re: [ibm-acpi-devel] [PATCH 1/1] thinkpad_acpi: Add support for status (external cover) LED

On Sun 2017-05-07 20:49:03, Henrique de Moraes Holschuh wrote: > On Sun, 07 May 2017, Pavel Machek wrote: > > On Thu 2017-01-19 12:21:32, Adam Goode wrote: > > > This allows the control of the red status LED, which is the dot of the "i" > > > in the word &qu

Re: [ibm-acpi-devel] [PATCH 1/1] thinkpad_acpi: Add support for status (external cover) LED

On Thu 2017-01-19 12:21:32, Adam Goode wrote: > This allows the control of the red status LED, which is the dot of the "i" > in the word "ThinkPad" on the outside cover of newer models. > > In the manual, both this LED and the power LED are referred to as > the "system-status indicators" without

Re: [ibm-acpi-devel] [PATCH v5 2/6] leds: triggers: Add a keyboard backlight trigger

Hi! > >> There might exist users that adjust LED brightness while having > >> active trigger. The best example is default-on trigger - it sets > >> brightness only on init, but remains active all the time. Whereas > >> this could be fixed, there is another case: think of changing blinking > >>

Re: [ibm-acpi-devel] s2disk broken at a ThinkPad since 4.6.5

On Sat 2016-11-26 15:00:17, Toralf Förster wrote: > On 11/26/2016 02:16 PM, Pavel Machek wrote: > > Any chance to try 4.9? > > Pavel > sure - 4.9-rc6 is fine, both undocked and docked system allows hiber

Re: [ibm-acpi-devel] s2disk broken at a ThinkPad since 4.6.5

On Sat 2016-10-29 11:33:06, Toralf Förster wrote: > This is a hardened stable Gentoo Linux ThinkPad T440s. > After wakeup from s2disk the console stays at line "clocksource: tsc: mask:" > forever. > > FWIW (and maby completely unrelated) I do wonder why since that version I do > have a dmesg

Re: [ibm-acpi-devel] [PATCH v5 2/6] leds: triggers: Add a keyboard backlight trigger

Hi! > >>Triggers are not limited to periodic blinking or reporting cpu > >>activity. There is also oneshot trigger that can be used e.g. when > >>user touches the screen, as Pali mentioned. > > > >Using oneshot trigger for this would be pretty strange. > > It was only an example to mention other

Re: [ibm-acpi-devel] [PATCH v5 2/6] leds: triggers: Add a keyboard backlight trigger

Hi! > >Lets keep it simple. Yes, monitoring backlight state while hardware > >updates it is useful. But doing the monitor when some kind of blinking > >from the kernel is active is just a unneccessary complexity... > > Triggers are not limited to periodic blinking or reporting cpu > activity.

Re: [ibm-acpi-devel] [PATCH v5 2/6] leds: triggers: Add a keyboard backlight trigger

Hi! > > As for the modeling how the hotkey controls the LED as a trigger, > > although I do like this from one pov, I can see Jacek's point that > > this is confusing as there really is nothing to configure here, > > where as normally a user could do "echo none > trigger" to break > > the link.

Re: [ibm-acpi-devel] [PATCH v5 2/6] leds: triggers: Add a keyboard backlight trigger

Hi! > >>In view of the above we could report hw brightness changes with POLLPRI > >>on brightness file, but unfortunately we can't because it is impossible > >>to guarantee that readout of brightness file will return the brightness > >>the POLLPRI was meant to notify about. > > > >Agreed here. >

Re: [ibm-acpi-devel] [PATCH v5 2/6] leds: triggers: Add a keyboard backlight trigger

s it seems senseless to implement a one off > >>>>trigger for just the dell / thinkpad case. > >>>> > >>>>>It seems however to be > >>>>>the other way round - if kbd-backlight means that this is > >>>>>a trig

Re: [ibm-acpi-devel] [PATCH v5 2/6] leds: triggers: Add a keyboard backlight trigger

Hi! > In view of the above we could report hw brightness changes with POLLPRI > on brightness file, but unfortunately we can't because it is impossible > to guarantee that readout of brightness file will return the brightness > the POLLPRI was meant to notify about. Agreed here. > That's why a

Re: [ibm-acpi-devel] [PATCH v5 2/6] leds: triggers: Add a keyboard backlight trigger

On Thu 2016-11-24 16:36:51, Pali Rohár wrote: > On Thursday 24 November 2016 16:32:06 Jacek Anaszewski wrote: > > Since it has been reported that POLLPRI notifications on brightness > > file can lead to increased power consumption, and having my above > > statement I don't think that it is a good

Re: [ibm-acpi-devel] [PATCH v5 2/6] leds: triggers: Add a keyboard backlight trigger

On Thu 2016-11-24 10:15:25, Pali Rohár wrote: > On Wednesday 23 November 2016 12:01:02 Jacek Anaszewski wrote: > > I would also appreciate your opinion on the other solution to the > > problem of notifying brightness changes originating from hardware, > > i.e. hw_brightness_change{_ro} file, that

Re: [ibm-acpi-devel] [PATCH v5 2/6] leds: triggers: Add a keyboard backlight trigger

Hi! > As pointed in other email, we do not know if HW really controls keyboard > backlight, > so adding "fake" trigger on machines without HW control is not a good > idea. > >>> > >>>Well, if we know that hardware will not change the brightness on its > >>>own, yes, I'd avoid

Re: [ibm-acpi-devel] [PATCH v5 1/6] leds: triggers: Add current_brightness trigger parameter

On Mon 2016-11-21 00:07:35, Pali Rohár wrote: > On Thursday 17 November 2016 23:24:36 Hans de Goede wrote: > > In some cases it may be desirable for userspace to be notified when > > a trigger event happens. This commit adds support for a poll-able > > current_brightness trigger specific sysfs

Re: [ibm-acpi-devel] [PATCH v5 1/6] leds: triggers: Add current_brightness trigger parameter

Hi! > > > If I understood correctly we need to handle two things: > > > > > > 1) Provide poll() for userspace when LED level is changed (either > > > by HW > > > > > >or other user call) > > > > > > 2) Deal with fact that on _some_ hardware, special key is hardwired > > > to > > > > > >

Re: [ibm-acpi-devel] [PATCH v5 2/6] leds: triggers: Add a keyboard backlight trigger

Hi! > > Thanks for the patch. > > > > I think we need less generic trigger name. > > With present name we pretend that all kbd-backlight controllers > > can change LED brightness autonomously. > > > > How about kbd-backlight-pollable ? > > >>> > > >>> This is

[ibm-acpi-devel] 6ea8c546f3655 breaks thermal management on thinkpad x60 and t40p

Hi! Bisection was not fun, but I've got the result: # first bad commit: [6ea8c546f3655a81f82672f24b66dad6095bdd07] ACPICA: FADT support cleanup I've reverted the patch on top of 4.9-rc4, and thermal management now works. More details are in https://bugzilla.kernel.org/show_bug.cgi?id=187311

[ibm-acpi-devel] thinkpad x60, T40p: overheat with v4.9-rc4 (was Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build)

Hi! Thanks to Srinivas, bug tracking moved to bugzilla at https://bugzilla.kernel.org/show_bug.cgi?id=187311 , it is regression from v4.8-final. Easiest way to observe it is that cpufreq/bios_limit does not change in v4.9, where it goes lower with high temperature on v4.8. Best regards,

Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

Hi! BTW.. This machine has nasty habit of hanging during kernel boot when it is "hot".. which makes reboots unplesant here. Ideas would be welcome how to debug that. Best regards, Pavel -- (english)

Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

On Sat 2016-11-05 16:04:58, Henrique de Moraes Holschuh wrote: > On Sat, 05 Nov 2016, Pavel Machek wrote: > > [ 825.759661] thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something > > is extremely hot! > > [ 825.761935] thinkpad_acpi: temperatures (Celsius): 101 49 N/

Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

On Sat 2016-11-05 15:46:12, Henrique de Moraes Holschuh wrote: > On Sat, 05 Nov 2016, Pavel Machek wrote: > > Hmm, thanks for the pointer. But it seems like I'll have to build my > > own, as /proc/acpi/ibm does not follow the usual infrastructure... > > /proc/acpi/ib

Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

Hi! > > > Yes, this seems to work. scaling_max goes to 1.5, then 1.1. Also > > > under > > > load, scaling_max_freq changes. But at that point, we are already > > > around 98C... and bios_limit stays the same all the time in v4.9. > > > > ...while in v4.8-rc1, bios limit goes to 1.0 GHz at 90C,

Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

Hi! > > > > So we seem to have thermal or ACPI regression in v4.9-rc3. > > > > > > > It is possible. Can you add either add printk > > > in acpi_processor_ppc_has_changed() or use ftrace and see do you > > > get to > > > these functions > > > > > > acpi_processor_ppc_init() > > >

Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

On Sat 2016-11-05 14:53:13, Pavel Machek wrote: > Hi! > > > > Ok, can do, let me recompile and reboot. > > > > > > > > > > > When temperature limit is reached acpi_processor_ppc_notifier() > > > > should > > > > be

Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

Hi! > > Ok, can do, let me recompile and reboot. > > > > > > > > When temperature limit is reached acpi_processor_ppc_notifier() > > > should > > > be called. > > > > No, that's not correct for ACPI passive trip points, is it? If I > > recall correctly, those should be monitored even when

Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

On Fri 2016-11-04 23:20:53, Pandruvada, Srinivas wrote: > On Fri, 2016-11-04 at 23:16 +0100, Pavel Machek wrote: > > Hi! > > > > [...] > > > So we seem to have thermal or ACPI regression in v4.9-rc3. > > > It is possible. Can you add either add pri

Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

Hi! > > So we seem to have thermal or ACPI regression in v4.9-rc3. > > > To me, there are two problems, > the first one is a 4.9-rc regression that BIOS limit stops working, > results in overheating because of high cpu frequency. I agree with > Srinivas to check acpi_cpufreq driver code for this

Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

Hi! > Under v4.8-rc, behaviour is different: bios_limit goes to 1GHz there > when temperature is around 84C at the thermal zone. That keeps > ibm/thermal temperatures under 90C, and no "thermal emergency" > messages in syslog. Argh. So v4.9 thermal management does not work. v4.8 passive thermal

Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

Hi! > > 4.9-rc2 has bios_limit: > > > > pavel@duo:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/bios_limit > > 1833000 > > > > and it has thermal zones: > > > > /sys/devices/virtual/thermal/thermal_zone0/trip_point_0_temp 127000 > > /sys/devices/virtual/thermal/thermal_zone0/trip_point_0_type

Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

Hi! > I'd prefer mails over bugzilla for now... > > 4.9-rc2 has bios_limit: > > pavel@duo:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/bios_limit > 1833000 > > and it has thermal zones: > > /sys/devices/virtual/thermal/thermal_zone0/trip_point_0_temp 127000 >

Re: [ibm-acpi-devel] [PATCH] thinkpad_acpi: Add support for keyboard backlight

On Wed 2016-01-13 09:54:55, Pali Rohár wrote: > On Tuesday 12 January 2016 22:58:04 Pavel Machek wrote: > > Hi! > > > > On Mon 2016-01-11 21:03:01, Pali Rohár wrote: > > > On Monday 11 January 2016 20:28:00 Henrique de Moraes Holschuh wrote > > &

Re: [ibm-acpi-devel] [PATCH] thinkpad_acpi: Add support for keyboard backlight

On Wed 2016-01-13 20:07:36, Pavel Machek wrote: > On Wed 2016-01-13 09:54:55, Pali Rohár wrote: > > On Tuesday 12 January 2016 22:58:04 Pavel Machek wrote: > > > Hi! > > > > > > Next question is.. apparently there are some keyboards that have > > > p

Re: [ibm-acpi-devel] [PATCH] thinkpad_acpi: Add support for keyboard backlight

Hi! On Mon 2016-01-11 21:03:01, Pali Rohár wrote: > On Monday 11 January 2016 20:28:00 Henrique de Moraes Holschuh wrote > > The two features are not the same (and are handled differently by the > > firmware, for whatever reason), although they do serve the same > > purpose. I don't think a

Re: [ibm-acpi-devel] [PATCH] thinkpad_acpi: Add support for keyboard backlight

Hi1 > This patch adds support for controlling keyboard backlight via standard > linux led class interface (::kbd_backlight). It uses ACPI HKEY device with > MLCG and MLCS methods. > > Signed-off-by: Pali Rohár > Tested-by: Fabio D'Urso On my

Re: [ibm-acpi-devel] [PATCH V4 RESEND] Support Thinkpad X1 Carbon 2nd gen's adaptive keyboard

Hi! Resend patch V4. Support Thinkpad X1 Carbon 2nd generation's adaptive keyboard. Hi Henrique, could you please have a chance to review it? As far as I can tell... thinkpad just has small display above its function keys (right?). Would it be possible to support it as a display?

Re: [ibm-acpi-devel] thinkpad x60: critical thermal shutdown does not work (and ethernet overheats)

On Mon 2013-09-23 09:02:56, Henrique de Moraes Holschuh wrote: On Mon, 23 Sep 2013, Pavel Machek wrote: I have rather old thinkpad x60 here. Long time ago, I noticed that on high continuous ethernet load, it shuts itself down in regular way. I traced it down to overheat, followed by ACPI

[ibm-acpi-devel] ethernet-related thermal emergency on Thinkpad x60

Hi! When using nework interface (eth0), machine starts to behave weird. Like... complete freeze, then poweroff, then it hangs on boot (initializing ACPI) until I let it to cool down... and I'm not even using gigabit speed. Did anyone see it? Any ideas? Should I attempt to open it and clean the

Re: [ibm-acpi-devel] [RFC] Controlling the ThinkPad battery charger

On Mon 2011-05-09 12:29:41, Henrique de Moraes Holschuh wrote: On Mon, 09 May 2011, Andrew Lutomirski wrote: The SBS interface exposes more data about the battery, including per-cell-group voltage and pack microcontroller aging counters, alarms, and the needs to get through the

Re: [ibm-acpi-devel] [RFC] Controlling the ThinkPad battery charger

Hi! Hmm, I jave a battery pack with reasonably good cells, but firmware killed it. IOW available for testing. That is likely a problem with the battery pack uC, we cannot override that using any know firmware path in the ThinkPad. Does the thinkpad recognizes the presence of the

Re: [ibm-acpi-devel] 2.6.33-rc2: regression: gkrellm no longer shows all the temperatures on thinkpad x60

Hi! Please apply the latest stack of patches (sent them to acpi-test yesterday). It is failing to register the ALSA mixer for some reason, and due to a bug, it is not loading the module at all. I will look at the reason it is failing to register the ALSA mixer soon. Meanwhile, the

Re: [ibm-acpi-devel] 2.6.33-rc2: regression: gkrellm no longer shows all the temperatures on thinkpad x60

On Sun 2009-12-27 23:24:15, Didier Spaier wrote: Pavel Machek wrote: ...I'll have to find out where gkrell got that info. It worked in 2.6.32. Pavel Only to make sure... What is the output of cat /proc/acpi/ibm/thermal

Re: [ibm-acpi-devel] [PATCH 08/10] thinkpad-acpi: log temperatures on termal alarm (v2)

On Tue 2009-12-08 23:36:28, Henrique de Moraes Holschuh wrote: Log temperatures on any of the EC thermal alarms. It could be useful to help tracking down what is happening... Signed-off-by: Henrique de Moraes Holschuh h...@hmh.eng.br Cc: Pavel Machek pa...@ucw.cz ACK. -- (english) http

Re: [ibm-acpi-devel] [PATCH 8/8] thinkpad-acpi: log temperatures on termal alarm

Hi! + for (i = 0; i n; i++) + t.temp[i] = t.temp[i] / 1000; + + /* Fill missing sensors with N/A marker */ + for (i = n; i TPACPI_MAX_THERMAL_SENSORS; i++) + t.temp[i] = -128; -273 would be better N/A marker :-). No can do. The firmware uses -128 (it

Re: [ibm-acpi-devel] [PATCH 8/8] thinkpad-acpi: log temperatures on termal alarm

Hi! Log temperatures on any of the EC thermal alarms. It could be useful to help tracking down what is happening... Thanks, I applied it locally. static bool hotkey_notify_thermal(const u32 hkey, bool *send_acpi_ev, bool

[ibm-acpi-devel] -rc6: annoying thermal messages

My dmesg log is rather full of. Thinkpad x60. Pavel wlan0: RX AssocResp from 00:11:95:05:30:d7 (capab=0x421 status=0 aid=2) wlan0: associated wlan0: deauthenticated from 00:11:95:05:30:d7 (Reason: 3) thinkpad_acpi: THERMAL

Re: [ibm-acpi-devel] refcounting problems with ibm_acpi but acpi=off

Hi! --- a/drivers/acpi/ibm_acpi.c +++ b/drivers/acpi/ibm_acpi.c @@ -2695,6 +2695,9 @@ static void acpi_ibm_exit(void) { int i; + if (acpi_disabled) + return; + for (i = ARRAY_SIZE(ibms) - 1; i = 0; i--) ibm_exit(ibms[i]); Indeed