Dear Voyjtech, dear Dmitry, dear Linux folks, On 02/08/17 14:12, 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
`helmuth-N24-25BU_mem.html`), and other processes(?) like *ec* are *not*
run in parallel but after (cf. attached `helmuth-N24-25BU_mem.html`).
The callgraph is captured with the command below.
```
$ sudo ./analyze_suspend.py -config config/suspend-callgraph.cfg -filter
i8042`
```
Looking through it, the delay `delay_tsc()` happens in the code below.
```
/*
* 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(¶m, I8042_CMD_AUX_LOOP) || param != val)
return -1;
param = val = multiplex ? 0x56 : 0xf6;
if (i8042_command(¶m, I8042_CMD_AUX_LOOP) || param != val)
return -1;
param = val = multiplex ? 0xa4 : 0xa5;
if (i8042_command(¶m, 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?
Is there anything, that can be done about this, to get into S3 state
faster?
If you want me to create a ticket in the Linux kernel bug tracker [3]
for this issue, I am happy to do that.
Please find the HTML files in the attached archive, so that the message gets delivered as no HTML parts are allowed.
Kind regards, Paul
[1] https://www.tuxedocomputers.com/Linux-Hardware/Linux-Notebooks/10-14-Zoll/TUXEDO-Book-BU1406-14-matt-Full-HD-IPS-bis-Intel-Core-i7-Energiespar-CPU-zwei-HDD/SSD-bis-32GB-RAM-bis-12h-Akku-Slim-Book-LTE-opt..geek [2] https://01.org/suspendresume/ [3] https://bugzilla.kernel.org/
Attachment:
analyze_suspend-HTML_output.7z
Description: application/7z-compressed
