ibm-acpi Linux driver development

Kevin Locke | 1 Dec 2009 05:21

Re: bluetooth off state not remembered accross reboots?

Sorry for digging up such an old thread, but I am afflicted by the
same problem and just recently found time to investigate.

On Sat, 2009-10-10 at 13:49 -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 10 Oct 2009, Yves-Alexis Perez wrote:
>> since some time (I guess 2.6.29 or 2.6.30 kernel), it seems that the
>> bluetooth ???off??? state isn't remembered on my T61.
> 
> The driver can remember state, yes. It *might* not work though. And it can
> be overriden by userspace.

The symptoms that I am observing on a T60p:
* Boot into single-user mode and kill everything (including udev)
* echo 0 > /sys/devices/platform/thinkpad_acpi/bluetooth_enable
  (bluetooth light is now off and it disappears from the USB bus)
* modprobe -r thinkpad_acpi
* modprobe thinkpad_acpi
  (bluetooth light back on and device reappears on USB bus)

Additionally, note that I have "options rfkill default_state=0" set in
modprobe.conf.d, if that is relevant.

With some more investigation and judicious use of dump_stack(), I have
put together the following call sequences that occur during modprobe
of thinkpad_acpi:
First, bluetooth is initialized and blocked:
thinkpad_acpi: bluetooth_init: bluetooth is supported, status 0x01
thinkpad_acpi: tpacpi_rfk_hook_set_block: request to change radio state to blocked
Pid: 1444, comm: modprobe Not tainted 2.6.31.6 #24
Call Trace:

(Continue reading)

Henrique de Moraes Holschuh | 1 Dec 2009 17:55

Picon

Re: bluetooth off state not remembered accross reboots?

On Mon, 30 Nov 2009, Kevin Locke wrote:
> Then, the radio is unblocked by rfkill_switch_all which is queued by
> rfkill_schedule_evsw_rfkillall as part of input_register_device:

That means rfkill thinks the radio should be enabled, and tells
thinkpad-acpi to do it, which it does.  If you're in single user mode, it is
happening because of thinkpad-acpi and rfkill interactions.

If you disable bluetooth through rfkill (and not through bluetooth_enable)
before you rmmod thinkpad-acpi ; modprobe thinkpad-acpi, what happens?

Also, are you sure you don't have a "bluetooth=enable" parameter in an
options line for thinkpad-acpi somewhere in the modprobe config (in
/etc/modprobe.d/*) ?

Note: 2.6.31 has an all-new rfkill core and thinkpad-acpi glue, so it is
worth testing it on 2.6.31 too.  One known bug: will resume with radios
disabled.  A fix is ready for that problem already, but it has not made it
to the kernel, yet.

--

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.

(Continue reading)

Kevin Locke | 1 Dec 2009 20:09

Re: bluetooth off state not remembered accross reboots?

On Tue, 2009-12-01 at 14:55 -0200, Henrique de Moraes Holschuh wrote:
> On Mon, 30 Nov 2009, Kevin Locke wrote:
>> Then, the radio is unblocked by rfkill_switch_all which is queued by
>> rfkill_schedule_evsw_rfkillall as part of input_register_device:
> 
> If you disable bluetooth through rfkill (and not through bluetooth_enable)
> before you rmmod thinkpad-acpi ; modprobe thinkpad-acpi, what happens?

If I change step 2 to 
# echo 0 > /sys/devices/platform/thinkpad_acpi/rfkill/rfkill0/state
the behavior is unchanged (light off, then after modprobe, back on)

> Also, are you sure you don't have a "bluetooth=enable" parameter in an
> options line for thinkpad-acpi somewhere in the modprobe config (in
> /etc/modprobe.d/*) ?

I'm sure.

> Note: 2.6.31 has an all-new rfkill core and thinkpad-acpi glue, so it is
> worth testing it on 2.6.31 too.  One known bug: will resume with radios
> disabled.  A fix is ready for that problem already, but it has not made it
> to the kernel, yet.

I should have mentioned originally, the testing is being done on
2.6.31.6 with thinkpad-acpi-0.23-20091010_v2.6.31.3.patch applied (but
I could pull from git if you would prefer).

Actually, with a little more testing I just figured it out.  It was
staring me in the face this whole time.  The trick was to add the
following somewhere in /etc/modprobe.d

(Continue reading)

Henrique de Moraes Holschuh | 1 Dec 2009 21:29

Picon

Re: bluetooth off state not remembered accross reboots?

On Tue, 01 Dec 2009, Kevin Locke wrote:
> I should have mentioned originally, the testing is being done on
> 2.6.31.6 with thinkpad-acpi-0.23-20091010_v2.6.31.3.patch applied (but
> I could pull from git if you would prefer).

Well, if you pull from here:
git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git  release/2.6.31

You will get the latest 2.6.31 with the latest thinkpad-acpi stable code.

Note: that branch is rewinded all the time, since it is a stgit branch tip.
Be prepared to have to rebase if you use it.  Maybe the easiest is to just
squash-merge it.

> Actually, with a little more testing I just figured it out.  It was
> staring me in the face this whole time.  The trick was to add the
> following somewhere in /etc/modprobe.d
> 
> options rfkill default_state=0 master_switch_mode=0

Ok, so it is the rfkill-input stuff (that is now part of the rfkill core)
that is showing the problem (the bug might be elsewhere).  We need to track
the state of the rfkill input device to know what's broken, then.

Please check and report what thinkpad-acpi reports for the content of
/sys/bus/platform/devices/thinkpad-acpi/hotkey_radio_sw

It has to be zero if the rfkill *physical* switch is on the "radios disabled"
position, and 1 if it is in the "radios enabled" position.

(Continue reading)

Henrique de Moraes Holschuh | 2 Dec 2009 15:32

Picon

Re: Lenovo T400s unhandled events

On Sat, 14 Nov 2009, Henrique de Moraes Holschuh wrote:
> On Mon, 09 Nov 2009, Radek ??enfeld wrote:
> > I just wanted to report two unhandled events on Lenovo T400s. Both of
> > them happen when dealing with dock - in this case it is Mini Dock III.
> > 
> > When I dock the machine: thinkpad_acpi: unhandled HKEY event 0x4010
> > When I undock then machine: thinkpad_acpi: unhandled HKEY event 0x4011
> 
> Can you please send me by private email the output of dmidecode (please mask
> out any serial numbers and UUIDs) and the full output of acpidump, for your
> T400s ?

Will have to ask Lenovo about them.

--

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Henrique de Moraes Holschuh | 2 Dec 2009 15:33

Picon

Re: Chaning so that WWAN is enabled after resume ?

On Mon, 09 Nov 2009, Henrique de Moraes Holschuh wrote:
> It could be a thinkpad-acpi bug, of course.  Or a firmware bug.

And it turned out to be a thinkpad-acpi bug, will send the fix upstream
soon.  I will add you to reported-by.

--

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Jerone Young | 2 Dec 2009 16:27

Re: Chaning so that WWAN is enabled after resume ?

Thanks Henrique! I havn't had time to get back to debugging this issue
since initially trying to go after it. 

Very curious on the fix. I rember diggin though the code and I can image
it's not an obvious bug just looking at the code.

				Jerone

On Wed, 2009-12-02 at 12:33 -0200, Henrique de Moraes Holschuh wrote:
> On Mon, 09 Nov 2009, Henrique de Moraes Holschuh wrote:
> > It could be a thinkpad-acpi bug, of course.  Or a firmware bug.
> 
> And it turned out to be a thinkpad-acpi bug, will send the fix upstream
> soon.  I will add you to reported-by.
> 

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

Kevin Locke | 2 Dec 2009 17:25

Re: bluetooth off state not remembered accross reboots?

On Tue, 2009-12-01 at 18:29 -0200, Henrique de Moraes Holschuh wrote:
> Well, if you pull from here:
> git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git  release/2.6.31

All testing now being done from this branch.

> Please check and report what thinkpad-acpi reports for the content of
> /sys/bus/platform/devices/thinkpad-acpi/hotkey_radio_sw
> 
> It has to be zero if the rfkill *physical* switch is on the "radios disabled"
> position, and 1 if it is in the "radios enabled" position.

I can confirm that it is.

> When the switch is in the "radios disabled" position, *every* rfkill device
> based on thinkpad-acpi *must* report that the state is "2"
> (hardware-blocked).
> 
> When the switch is in the "radios enabled" position, the rfkill devices must
> report either state "0" (software blocked) or "1" (unblocked).

I can confirm this is true as well.  Note that with
master_switch_mode=1 or master_switch_mode=2 all devices will report 1
after switching off and back on, regardless of previous state.  With
master_switch_mode=0 all devices report 0 after switching off and back
on, regardless of previous state.

> The rfkill core keeps "global" state for each type of rfkill switch, and
> something weird might be happening related to that.  It could be interesting
> to check it, but you will need something to interface to /dev/rfkill.

(Continue reading)

Henrique de Moraes Holschuh | 2 Dec 2009 18:01

Picon

Re: Chaning so that WWAN is enabled after resume ?

On Wed, 02 Dec 2009, Jerone Young wrote:
> Thanks Henrique! I havn't had time to get back to debugging this issue
> since initially trying to go after it. 
> 
> Very curious on the fix. I rember diggin though the code and I can image
> it's not an obvious bug just looking at the code.

Basically, the new rfkill core (for good reasons, to the benefit of the
EeePC driver) will not do a class resume on persistent devices.

So, thinkpad-acpi has to do it itself.  I took the easy way out: asked the
firmware to do it for us.  So far, the only oddity reported is that if the
user switches the hardware rfkill switch off then on, the firmware will
resume with all radios unblocked.

I *can* work around that, by ignoring the firmware entirely on a
suspend/resume cycle.  I am not convinced this is would be a better choice.

--

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

(Continue reading)

Kevin Locke | 5 Dec 2009 19:24

Re: bluetooth off state not remembered accross reboots?

On Tue, 2009-12-01 at 18:29 -0200, Henrique de Moraes Holschuh wrote:
> Ok, so it is the rfkill-input stuff (that is now part of the rfkill core)
> that is showing the problem (the bug might be elsewhere).  We need to track
> the state of the rfkill input device to know what's broken, then.

OK.  I think I have a pretty good understanding of what is going on
now.

Rfkill pretends that the master switch was set in its current position
at startup by using an EV_SW event on devices that support them.  So
when master_switch_mode=0 everything gets set to blocked, when
master_switch_mode=2 everything gets set to unblocked.  This is by
design (and 2 is the default).  The problem is that
master_switch_mode=1 does not behave well at all and default_state is
ignored.

The reason that master_switch_mode=1 is broken is that when a new
input device is registered, the rfkill_handler specifies rfkill_start
to be called for the new handle, which schedules an
rfkill_restore_states to be called before rfkill_eop is ever called.
So the 0-initialized (unblocked) save state is loaded for all devices.

default_state can be fixed by initializing the saved state to the
default state in rfkill_init (currently only the current state is
initialized).  However, this doesn't provide a way for thinkpad_acpi
to inform rfkill what the default state of each type should really be.
So, unless I am overlooking something, I think rfkill needs a new API
call to set the default state for each type of radio that tpacpi could
use before this bug can be fixed.

(Continue reading)

Group

gmane.linux.acpi.ibm-acpi.devel.

Project Web Page

ibm-acpi Linux driver development

Search Archive

Page

1 | 2 | 3 | 4 | 5

Articles in period: 47

December 2009

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane

Recent entries

regulate backlight on X230 and T430 works incorrectly (29 Apr 2013)
Suspend failure on Thinkpad X1 Carbon (18 Mar 2013)
thinkpad_acpi: unhandled HKEY event 0x6040 (31 Mar 2013)
unhandled HKEY event (28 Mar 2013)
unhandled HKEY event (24 Mar 2013)
W520 LCD Screen (27 Mar 2013)
thinkpad_acpi: unknown possible thermal alarm or keyboard event receiv (30 Mar 2013)
thinkpad_acpi: unhandled HKEY event 0x6050 on Thinkpad E420s (14 Mar 2013)
Update Submission (7 Mar 2013)
thinkpad_acpi: unknown possible thermal alarm or keyboard event receiv (18 Mar 2013)
reporting conditions (23 Mar 2013)
[PATCH] Remove nested functions from the Thinkpad ACPI (14 Feb 2013)
unknown acpi event on lenovo edge e130g (6 Feb 2013)
T420 chanegd ACPI event code for power (19 Feb 2013)
thinkpad_acpi doesn't load after alsa update, thinkfan (21 Feb 2013)
ThinkPad X230 fail on Linux (22 Feb 2013)
thinkpad_acpi unhandled HKEY events (15 Feb 2013)
thinkpad_acpi: unknown possible thermal alarm or keyboard event receiv (8 Feb 2013)
thinkpad_acpi: unhandled HKEY event 0x6040 (13 Feb 2013)
Bug report (3 Jan 2013)
unknown event (5 Jan 2013)

Archives

3	April 2013
15	March 2013
12	February 2013
10	January 2013
20	December 2012
5	November 2012
5	October 2012
2	September 2012
11	August 2012
22	July 2012
21	June 2012
8	May 2012
3	April 2012
15	March 2012
10	February 2012
11	January 2012
9	December 2011
23	November 2011
13	October 2011
7	September 2011
18	August 2011
5	July 2011
29	June 2011
23	May 2011
9	April 2011
18	March 2011
14	February 2011
38	January 2011
8	December 2010
8	November 2010
9	October 2010
16	September 2010
7	August 2010
10	July 2010
13	June 2010
24	May 2010
27	April 2010
28	March 2010
30	February 2010
39	January 2010
47	December 2009
48	November 2009
20	October 2009
49	September 2009
25	August 2009
15	July 2009
41	June 2009
21	May 2009
42	April 2009
15	March 2009
12	February 2009
45	January 2009
14	December 2008
54	November 2008
65	October 2008
20	September 2008
27	August 2008
48	July 2008
19	June 2008
25	May 2008
56	April 2008
21	March 2008
84	February 2008
100	January 2008
38	December 2007
48	November 2007
136	October 2007
77	September 2007
70	August 2007
245	July 2007
39	June 2007
118	May 2007
71	April 2007
123	March 2007
78	February 2007
15	January 2007
25	December 2006
71	November 2006

Design

Zawodny | Right Menu | Left Menu

Your Own Design

Paste the URL of your CSS below. Download CSS template