Re: Half second spend in i8042 during suspend on TUXEDO BU1406

4 messages, 2 authors, 2017-02-09 · open the first message on its own page

Re: Half second spend in i8042 during suspend on TUXEDO BU1406

From: Vojtech Pavlik <hidden>
Date: 2017-02-09 03:20:08

On Wed, Feb 08, 2017 at 02:12:44PM +0100, Paul Menzel wrote:
On the TUXEDO BU1406 [1] the Linux kernel (tested with 4.10-rc{6,7})
takes over a second to get into suspend [2]. For whatever reason
around 550 ms are spent in `i8042_set_mux_mode()` (cf. attached
/*
 * Internal loopback test - send three bytes, they should come back
from the
 * mouse interface, the last should be version.
 */

        param = val = 0xf0;
        if (i8042_command(&param, I8042_CMD_AUX_LOOP) || param != val)
                return -1;
        param = val = multiplex ? 0x56 : 0xf6;
        if (i8042_command(&param, I8042_CMD_AUX_LOOP) || param != val)
                return -1;
        param = val = multiplex ? 0xa4 : 0xa5;
        if (i8042_command(&param, I8042_CMD_AUX_LOOP) || param == val)
                return -1;
Is that a hardware limitation, or even an error as such long delays
are not allowed according to some standard?
It looks like an EC firmware bug not handling the CMD_AUX_LOOP command
correctly.
Is there anything, that can be done about this, to get into S3 state faster?
Does it still happen if you specify i8042.nomux=1 on the kernel command
line?

If that helps, it can be added to a blacklist based on DMI.

Vojtech

Re: Half second spend in i8042 during suspend on TUXEDO BU1406

From: Paul Menzel <hidden>
Date: 2017-02-09 09:18:05

Dear Vojtech,


On 02/09/17 00:58, Vojtech Pavlik wrote:
On Wed, Feb 08, 2017 at 02:12:44PM +0100, Paul Menzel wrote:
quoted
On the TUXEDO BU1406 [1] the Linux kernel (tested with 4.10-rc{6,7})
takes over a second to get into suspend [2]. For whatever reason
around 550 ms are spent in `i8042_set_mux_mode()` (cf. attached
/*
 * Internal loopback test - send three bytes, they should come back
from the
 * mouse interface, the last should be version.
 */

        param = val = 0xf0;
        if (i8042_command(&param, I8042_CMD_AUX_LOOP) || param != val)
                return -1;
        param = val = multiplex ? 0x56 : 0xf6;
        if (i8042_command(&param, I8042_CMD_AUX_LOOP) || param != val)
                return -1;
        param = val = multiplex ? 0xa4 : 0xa5;
        if (i8042_command(&param, I8042_CMD_AUX_LOOP) || param == val)
                return -1;
Is that a hardware limitation, or even an error as such long delays
are not allowed according to some standard?
It looks like an EC firmware bug not handling the CMD_AUX_LOOP command
correctly.
quoted
Is there anything, that can be done about this, to get into S3 state faster?
Does it still happen if you specify i8042.nomux=1 on the kernel command
line?
Starting Linux with that, the delay is gone.

Before:

 > i8042 @ i8042 {i8042} sync_device (Total Suspend: 546.038 ms Total 
Resume: 3.850 ms)

After:

 > i8042 @ i8042 {i8042} sync_device (Total Suspend: 0.973 ms Total 
Resume: 1.369 ms)

What downsides are there of using that `i8042.nomux=1`? Is any 
functionality lost?
If that helps, it can be added to a blacklist based on DMI.
Sounds good.
$ journalctl -k | grep 'DMI:'
Feb 09 10:15:04 helmuth-N24-25BU kernel: DMI: Notebook 
       N24_25BU/N24_25BU, BIOS 5.12 10/11/2016

Kind regards,

Paul

Re: Half second spend in i8042 during suspend on TUXEDO BU1406

From: Vojtech Pavlik <hidden>
Date: 2017-02-09 11:24:13

On Thu, Feb 09, 2017 at 10:17:56AM +0100, Paul Menzel wrote:
Starting Linux with that, the delay is gone.

Before:
quoted
i8042 @ i8042 {i8042} sync_device (Total Suspend: 546.038 ms Total Resume: 3.850 ms)
After:
quoted
i8042 @ i8042 {i8042} sync_device (Total Suspend: 0.973 ms Total Resume: 1.369 ms)
What downsides are there of using that `i8042.nomux=1`? Is any
functionality lost?
If the notebook doesn't implement the Active AUX Multiplexing
specification, then there is no functionality lost. 

If it does, and apparently yours doesn't, then you lose the ability to
distinguish between the internal touchpad/touchpoint and an external
connected PS/2 mouse and lose the ability to use any advanced protocol
beyond standard PS/2 mouse.

Apparently the TUXEDO Book BU1406 doesn't have any external AUX port for
mouse, only USB and internally it only seems to have one touchpad, so
there is no need for Active AUX Multiplexing.
quoted
If that helps, it can be added to a blacklist based on DMI.
Sounds good.

$ journalctl -k | grep 'DMI:'
Feb 09 10:15:04 helmuth-N24-25BU kernel: DMI: Notebook
N24_25BU/N24_25BU, BIOS 5.12 10/11/2016
A full output of 'dmidecode' would be more useful.

-- 
Vojtech Pavlik
Director SUSE Labs

Re: Half second spend in i8042 during suspend on TUXEDO BU1406

From: Paul Menzel <hidden>
Date: 2017-02-09 16:17:54

Dear Vojtech,


On 02/09/17 12:24, Vojtech Pavlik wrote:
On Thu, Feb 09, 2017 at 10:17:56AM +0100, Paul Menzel wrote:
quoted
Starting Linux with that, the delay is gone.

Before:
quoted
i8042 @ i8042 {i8042} sync_device (Total Suspend: 546.038 ms Total Resume: 3.850 ms)
After:
quoted
i8042 @ i8042 {i8042} sync_device (Total Suspend: 0.973 ms Total Resume: 1.369 ms)
What downsides are there of using that `i8042.nomux=1`? Is any
functionality lost?
If the notebook doesn't implement the Active AUX Multiplexing
specification, then there is no functionality lost.

If it does, and apparently yours doesn't, then you lose the ability to
distinguish between the internal touchpad/touchpoint and an external
connected PS/2 mouse and lose the ability to use any advanced protocol
beyond standard PS/2 mouse.

Apparently the TUXEDO Book BU1406 doesn't have any external AUX port for
mouse, only USB and internally it only seems to have one touchpad, so
there is no need for Active AUX Multiplexing.
quoted
quoted
If that helps, it can be added to a blacklist based on DMI.
Sounds good.

$ journalctl -k | grep 'DMI:'
Feb 09 10:15:04 helmuth-N24-25BU kernel: DMI: Notebook
N24_25BU/N24_25BU, BIOS 5.12 10/11/2016
A full output of 'dmidecode' would be more useful.
$ sudo dmidecode -t BIOS
# dmidecode 3.0
Getting SMBIOS data from sysfs.
SMBIOS 3.0.0 present.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
	Vendor: American Megatrends Inc.
	Version: 5.12
	Release Date: 10/11/2016
	Address: 0xF0000
	Runtime Size: 64 kB
	ROM Size: 16384 kB
	Characteristics:
		PCI is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		Boot from CD is supported
		Selectable boot is supported
		BIOS ROM is socketed
		EDD is supported
		Print screen service is supported (int 5h)
		8042 keyboard services are supported (int 9h)
		Printer services are supported (int 17h)
		ACPI is supported
		USB legacy is supported
		BIOS boot specification is supported
		Targeted content distribution is supported
		UEFI is supported
	BIOS Revision: 5.12

Handle 0x0026, DMI type 13, 22 bytes
BIOS Language Information
	Language Description Format: Long
	Installable Languages: 1
		en|US|iso8859-1
	Currently Installed Language: en|US|iso8859-1
Please find the whole output of `dmidecode` attached.


Kind regards,

Paul
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help