Re: [ibm-acpi-devel] 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 ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] 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. Using that utility in list mode, it reports states which match those from sysfs. In event mode, some of the output may be more useful. Note that I think phy0 lags behind tpacpi, which confuses the output a little. In the output below, master_switch_mode=1 and idx 0 is phy0, 1 is tpacpi_bluetooth_sw, 2 is tpacpi_wwan_sw. The testing was started with bluetooth soft blocked and everything else unblocked, at the end of the test everything is unblocked. # Initial state RFKILL event: idx 0 type 1 op 0 soft 0 hard 0 RFKILL event: idx 1 type 2 op 0 soft 1 hard 0 RFKILL event: idx 2 type 5 op 0 soft 0 hard 0 # Switch toggled to off RFKILL event: idx 1 type 2 op 2 soft 1 hard 1 RFKILL event: idx 2 type 5 op 2 soft 0 hard 1 RFKILL event: idx 0 type 1 op 2 soft 1 hard 0 RFKILL event: idx 1 type 2 op 2 soft 1 hard 1 RFKILL event: idx 2 type 5 op 2 soft 1 hard 1 RFKILL event: idx 0 type 1 op 2 soft 1 hard 1 # Switch toggled to on RFKILL event: idx 1 type 2 op 2 soft 1 hard 0 RFKILL event: idx 2 type 5 op 2 soft 1 hard 0 RFKILL event: idx 0 type 1 op 2 soft 0 hard 1 RFKILL event: idx 1 type 2 op 2 soft 0 hard 0 RFKILL event: idx 2 type 5 op 2 soft 0 hard 0 RFKILL event: idx 0 type 1 op 2 soft 0 hard 0 RFKILL event: idx 4 type 2 op 0 soft 0 hard 0 RFKILL event: idx 4 type 2 op 2 soft 0 hard 0 > But it appears, from your description, that we are disturbing the kernel at > module load. One of the things that thinkpad-acpi will do at module load, > is to issue a EV_SW SW_RFKILL_ALL event with the current state of the rfkill > switch. If that is not working right, it might be the reason for the > problem. That would make sense with how the master switch behaves when toggled. If this same effect is simulated with the EV_SW, that would explain what is happening. > On Tue, 01 Dec 2009, Kevin Locke wrote: >> If this is expected behavior, could it be documented somewhere (or am >> I overlooking somewhere that it is documented already)? > > No, there is something wrong, and I'd really like to know what :P I really appreciate you looking into it. If there is anything else I can do to help/test, please let me know. Kevin -- 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 ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] 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 ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] 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 ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] 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 ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
