| Message ID | 1429759476-13186-1-git-send-email-alex.hung@canonical.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Thu, Apr 23, 2015 at 11:24:35AM +0800, Alex Hung wrote: > Dell Inspiron 7437's ACPI events does not work well with Win8 OSI. > Disabling Win8 OSI can fix wireless hotkey and ACPI battery. Does this machine work if you actually install Windows 8 on it?
I don't have any Win8 media to test it but I will try to look for one. I recalled that kernel 4.1rc has a patch "ACPICA: Permanently set _REV to the value '2'" that may also change firmware's behaviours, but it does not fix Inspiron 7437's ACPI event just for references. On Fri, Apr 24, 2015 at 4:21 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote: > On Thu, Apr 23, 2015 at 11:24:35AM +0800, Alex Hung wrote: >> Dell Inspiron 7437's ACPI events does not work well with Win8 OSI. >> Disabling Win8 OSI can fix wireless hotkey and ACPI battery. > > Does this machine work if you actually install Windows 8 on it? > -- > Matthew Garrett | mjg59@srcf.ucam.org
On Mon, Apr 27, 2015 at 04:30:11PM +0800, Alex Hung wrote: > I don't have any Win8 media to test it but I will try to look for one. > > I recalled that kernel 4.1rc has a patch "ACPICA: Permanently set _REV > to the value '2'" that may also change firmware's behaviours, but it > does not fix Inspiron 7437's ACPI event just for references. The _REV behaviour didn't change between Windows 7 and 8, so it shouldn't be relevant here.
I tried Windows 8.1 Pro, and it seems that wireless hotkey works fine (with AirplaneMode driver installed) and ACPI battery works fine too. I didn't observe similar ACPI interrupt problems that occur on Linux. On Tue, Apr 28, 2015 at 1:46 AM, Matthew Garrett <mjg59@srcf.ucam.org> wrote: > On Mon, Apr 27, 2015 at 04:30:11PM +0800, Alex Hung wrote: >> I don't have any Win8 media to test it but I will try to look for one. >> >> I recalled that kernel 4.1rc has a patch "ACPICA: Permanently set _REV >> to the value '2'" that may also change firmware's behaviours, but it >> does not fix Inspiron 7437's ACPI event just for references. > > The _REV behaviour didn't change between Windows 7 and 8, so it > shouldn't be relevant here. > > -- > Matthew Garrett | mjg59@srcf.ucam.org
On Tue, Apr 28, 2015 at 12:53:10PM +0800, Alex Hung wrote: > I tried Windows 8.1 Pro, and it seems that wireless hotkey works fine > (with AirplaneMode driver installed) and ACPI battery works fine too. > I didn't observe similar ACPI interrupt problems that occur on Linux. Ok, sounds like we've got another problem somewhere. Do you have the acpidump?
Matthew, Its acpidump is available @ http://people.canonical.com/~alexhung/LP1435731/ On Tue, Apr 28, 2015 at 1:24 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote: > On Tue, Apr 28, 2015 at 12:53:10PM +0800, Alex Hung wrote: >> I tried Windows 8.1 Pro, and it seems that wireless hotkey works fine >> (with AirplaneMode driver installed) and ACPI battery works fine too. >> I didn't observe similar ACPI interrupt problems that occur on Linux. > > Ok, sounds like we've got another problem somewhere. Do you have the > acpidump? > > -- > Matthew Garrett | mjg59@srcf.ucam.org
With Windows 8 enabled you're going down this path:
If (_OSI (WIN8))
{
Local0 = 0x81
}
With it blacklisted, you're going down this path:
If (_OSI (WIN7))
{
Local0 = 0x80
Local1 = _REV /* \_REV */
If ((Local1 == 0x05))
{
Local0 = 0x40
}
}
So your guess about _REV was actually correct - if the OS claims to be
Windows 7 and returns 5 to _REV, it'll let Local0 to 0x40. This results
in:
If ((Local0 == 0x40))
{
MIS0 = SMI (0x98, Zero)
MIS0 &= 0x13
}
MIS0 appears to be involved in various event delivery paths, so my
suspicion is that the firmware is deliberately working around a quirk of
Linux behaviour in order to deliver events appropriately. If so, your
patch won't help in 4.1 because _REV now returns 2, and so we need to
root cause the actual problem and fix that instead.
Matthew, Your conclusion is correct. Disabling OSI(Windows 2012/2013) in kernel 4.1rc will not work. I will take a closer look into this machine. Thanks. On Wed, Apr 29, 2015 at 1:11 AM, Matthew Garrett <mjg59@srcf.ucam.org> wrote: > With Windows 8 enabled you're going down this path: > > If (_OSI (WIN8)) > { > Local0 = 0x81 > } > > With it blacklisted, you're going down this path: > > If (_OSI (WIN7)) > { > Local0 = 0x80 > Local1 = _REV /* \_REV */ > If ((Local1 == 0x05)) > { > Local0 = 0x40 > } > } > > So your guess about _REV was actually correct - if the OS claims to be > Windows 7 and returns 5 to _REV, it'll let Local0 to 0x40. This results > in: > > If ((Local0 == 0x40)) > { > MIS0 = SMI (0x98, Zero) > MIS0 &= 0x13 > } > > MIS0 appears to be involved in various event delivery paths, so my > suspicion is that the firmware is deliberately working around a quirk of > Linux behaviour in order to deliver events appropriately. If so, your > patch won't help in 4.1 because _REV now returns 2, and so we need to > root cause the actual problem and fix that instead. > > -- > Matthew Garrett | mjg59@srcf.ucam.org
On 04/29/2015 05:09 AM, Alex Hung wrote: > Matthew, > > Your conclusion is correct. Disabling OSI(Windows 2012/2013) in kernel > 4.1rc will not work. I will take a closer look into this machine. > > Thanks. > > On Wed, Apr 29, 2015 at 1:11 AM, Matthew Garrett <mjg59@srcf.ucam.org> wrote: >> With Windows 8 enabled you're going down this path: >> >> If (_OSI (WIN8)) >> { >> Local0 = 0x81 >> } >> >> With it blacklisted, you're going down this path: >> >> If (_OSI (WIN7)) >> { >> Local0 = 0x80 >> Local1 = _REV /* \_REV */ >> If ((Local1 == 0x05)) >> { >> Local0 = 0x40 >> } >> } >> >> So your guess about _REV was actually correct - if the OS claims to be >> Windows 7 and returns 5 to _REV, it'll let Local0 to 0x40. This results >> in: >> >> If ((Local0 == 0x40)) >> { >> MIS0 = SMI (0x98, Zero) >> MIS0 &= 0x13 >> } >> >> MIS0 appears to be involved in various event delivery paths, so my >> suspicion is that the firmware is deliberately working around a quirk of >> Linux behaviour in order to deliver events appropriately. If so, your >> patch won't help in 4.1 because _REV now returns 2, and so we need to >> root cause the actual problem and fix that instead. >> >> -- >> Matthew Garrett | mjg59@srcf.ucam.org Matthew, Thank you for bringing this to my attention on that other thread. I've checked with the team more on this. I'm also looking into any other platforms that are quirking behavior on _REV. If you are aware of any other specifics I can inquire on those too. The 7437 platform (and it's two sister platforms 7537 and 7737) include the following differences when acpi_osi=Windows 2009 and _REV is 5. These platforms were enabled in the era before Windows 2013 was default _OSI in the Linux kernel. * Backlight control is set to 16 levels in Win7 and Linux. It's set to 10 levels in Win 8/Win8.1. * Battery information was not displayed in the OS. The BIOS team found that the Linux wasn't asking for battery information in the OS in the same way that Windows does. The delta path creates a SMI event to get battery information. Alex, Does dell-rbtn/dell-airplane work properly with this platform when set to Windows 2013? I'd expect that should fix the wireless hotkey issue. As you know airplane mode is only effective on systems with _OSI of Windows 2013. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 14, 2015 at 02:02:02PM -0500, Mario Limonciello wrote: > * Battery information was not displayed in the OS. The BIOS team > found that the Linux wasn't asking for battery information in the OS > in the same way that Windows does. The delta path creates a SMI > event to get battery information. Huh. Is there any chance we can find out what the difference is so we can make them equivalent?
On 05/14/2015 02:13 PM, Matthew Garrett wrote: > On Thu, May 14, 2015 at 02:02:02PM -0500, Mario Limonciello wrote: > >> * Battery information was not displayed in the OS. The BIOS team >> found that the Linux wasn't asking for battery information in the OS >> in the same way that Windows does. The delta path creates a SMI >> event to get battery information. > Huh. Is there any chance we can find out what the difference is so we > can make them equivalent? > That was my reaction too. I'm asking for some technical details on this. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/14/2015 02:17 PM, Mario Limonciello wrote: > > On 05/14/2015 02:13 PM, Matthew Garrett wrote: >> On Thu, May 14, 2015 at 02:02:02PM -0500, Mario Limonciello wrote: >> >>> * Battery information was not displayed in the OS. The BIOS team >>> found that the Linux wasn't asking for battery information in the OS >>> in the same way that Windows does. The delta path creates a SMI >>> event to get battery information. >> Huh. Is there any chance we can find out what the difference is so we >> can make them equivalent? >> > That was my reaction too. I'm asking for some technical details on this. Hi Matthew, I've gotten some more information on this. Windows: Asks for battery information update multiple times. Linux: Only asks once for battery information update. The net result is that on Linux ACPI battery is missing. In the _REV test BIOS workaround, a SMI event was added to ask for battery information update. Thanks, -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, May 20, 2015 at 12:42:14PM -0500, Mario Limonciello wrote: > I've gotten some more information on this. > Windows: Asks for battery information update multiple times. > Linux: Only asks once for battery information update. > > The net result is that on Linux ACPI battery is missing. In the > _REV test BIOS workaround, a SMI event was added to ask for battery > information update. Hm. Why does only asking once not result in us seeing the battery?
On 05/20/2015 01:42 PM, Matthew Garrett wrote: > On Wed, May 20, 2015 at 12:42:14PM -0500, Mario Limonciello wrote: > >> I've gotten some more information on this. >> Windows: Asks for battery information update multiple times. >> Linux: Only asks once for battery information update. >> >> The net result is that on Linux ACPI battery is missing. In the >> _REV test BIOS workaround, a SMI event was added to ask for battery >> information update. > Hm. Why does only asking once not result in us seeing the battery? > I'm not sure, this is all I was told about the difference in behavior with Windows that prompted this bios workaround. Looking through the kernel log, i'm wondering if maybe 75646e758a0ecbed5024454507d5be5b9ea9dcbf will actually have fixed this. Alex, What was the last kernel validated on the 7*37 family? Can you see if a kernel that includes 75646e758a0ecbed5024454507d5be5b9ea9dcbf does resolve it? -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
I ran at least kernel 3.19 (Ubuntu Vivid), 4.0 and 4.1rc on 7437, and they have the same symptom - ACPI events are not generated with wireless hotkey presses and battery info is not updated. The commit 75646e758a0ecbed5024454507d5be5b9ea9dcbf is included. If I ran "cat /proc/interrupts", interrupt 9 (acpi) is not incrementing. If AC is plugged/unplugged, battery will be updated once. This implies AC event is generated correctly. On Thu, May 21, 2015 at 4:16 AM, Mario Limonciello <mario_limonciello@dell.com> wrote: > > > On 05/20/2015 01:42 PM, Matthew Garrett wrote: >> >> On Wed, May 20, 2015 at 12:42:14PM -0500, Mario Limonciello wrote: >> >>> I've gotten some more information on this. >>> Windows: Asks for battery information update multiple times. >>> Linux: Only asks once for battery information update. >>> >>> The net result is that on Linux ACPI battery is missing. In the >>> _REV test BIOS workaround, a SMI event was added to ask for battery >>> information update. >> >> Hm. Why does only asking once not result in us seeing the battery? >> > I'm not sure, this is all I was told about the difference in behavior with > Windows that prompted this bios workaround. Looking through the kernel log, > i'm wondering if maybe 75646e758a0ecbed5024454507d5be5b9ea9dcbf will > actually have fixed this. > > Alex, > > What was the last kernel validated on the 7*37 family? Can you see if a > kernel that includes 75646e758a0ecbed5024454507d5be5b9ea9dcbf does resolve > it? > >
diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c index 37925a3..e2db565 100644 --- a/drivers/acpi/blacklist.c +++ b/drivers/acpi/blacklist.c @@ -306,6 +306,14 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = { DMI_MATCH(DMI_PRODUCT_NAME, "Vostro 3546"), }, }, + { + .callback = dmi_disable_osi_win8, + .ident = "Dell Inspiron 7437", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), + DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 7437"), + }, + }, /* * The brightness hotkeys do not work on those machines when
Dell Inspiron 7437's ACPI events does not work well with Win8 OSI. Disabling Win8 OSI can fix wireless hotkey and ACPI battery. Signed-off-by: Alex Hung <alex.hung@canonical.com> --- drivers/acpi/blacklist.c | 8 ++++++++ 1 file changed, 8 insertions(+)