HCL -- Thinkpad x230 Centrino Advanced-N 6205 AGN

[mgflax]

The iwlwifi driver was throwing a horrible stack trace whenever resuming from suspend mode.  Managed to work around it with:

1. In dom0:/usr/lib/systemd/system-sleep, create a "netvm.sh" with the following contents
    #!/bin/bash
    [ "$1" = "post" ] && qvm-run -u root netvm /usr/local/bin/postSuspend.sh
    [ "$1" = "pre" ]  && qvm-run -u root netvm /usr/local/bin/preSuspend.sh
    exit 0

2. In netvm:/usr/local/bin, create "preSuspend.sh"
    #!/bin/bash
    modprobe -r iwldvm
    modprobe -r iwlwifi

3. In netvm:/usr/local/bin, create "postSuspend.sh"
    #!/bin/bash
    modprobe iwlwifi
    modprobe iwldvm

Does this make sense?  Is there an alternative that's more idiomatic?

Many thanks!

Marshall

[Marek Marczykowski-Górecki]

There is already /usr/lib/qubes/prepare-suspend for such things, but currently
it doesn't call any user-defined hooks.
I'll just add those modules to the above file.

--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[mgflax]

The weird thing is that I had tried that first and it didn't seem like prepare_suspend was even being called at all in netVM.  But perhaps I was doing something wrong.

[Marek Marczykowski-Górecki]

On 19.07.2013 03:42, mgflax wrote:
> The weird thing is that I had tried that first and it didn't seem like
> prepare_suspend was even being called at all in netVM. But perhaps I was
> doing something wrong.

How do you suspend the system? Those scripts depends on pm-suspend called,
which actually isn't used by systemd (but most desktop environments calls it).
Check /var/log/pm-suspend.log (especially its timestamp) to see if it is used.

[mgflax]

No /var/log/pm-suspend.log on either dom0 or netVM at all.

I suspend my laptop the old-fashioned way: I just close the lid.

Marshall

[Marek Marczykowski-Górecki]

On 19.07.2013 03:49, mgflax wrote:
> No /var/log/pm-suspend.log on either dom0 or netVM at all.
>
> I suspend my laptop the old-fashioned way: I just close the lid.

You're using KDE, right? It should disable default systemd handler of lid
switch and use its own settings. Check it with:
systemd-inhibit --list
There should be "handle-lid-switch" listed somewhere. If not - check if KDE
has enabled action for lid switch.

PS Do not toppost.

[mgflax]

Sorry about the topposting ... is this better?  I'm using stock KDE and I see an inhibitor for power-key, suspend-key, hibernate-key, and lid-switch.

If I have time this weekend I'll reinstall from scratch and see if I can prove that I didn't mess anything up while trying to get the 802.11 to work.

Thanks again.

Marshall

[Marek Marczykowski-Górecki]

On 19.07.2013 04:07, mgflax wrote:
> On Thursday, July 18, 2013 9:53:37 PM UTC-4, Marek Marczykowski-Górecki
> wrote:
>>
>> On 19.07.2013 03:49, mgflax wrote:
>>> No /var/log/pm-suspend.log on either dom0 or netVM at all.
>>>
>>> I suspend my laptop the old-fashioned way: I just close the lid.
>>
>> You're using KDE, right? It should disable default systemd handler of lid
>> switch and use its own settings. Check it with:
>> systemd-inhibit --list
>> There should be "handle-lid-switch" listed somewhere. If not - check if
>> KDE
>> has enabled action for lid switch.
>

> Sorry about the topposting ... is this better?

Yes :)

> I'm using stock KDE and I
> see an inhibitor for power-key, suspend-key, hibernate-key, and lid-switch.
>
> If I have time this weekend I'll reinstall from scratch and see if I can
> prove that I didn't mess anything up while trying to get the 802.11 to work.

You can also check if using "sudo pm-suspend" from dom0 causes the iwlwifi
problem. I've similar wifi card and it works without any workaround.

--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[Laszlo Zrubecz]

On 19 July 2013 03:14, mgflax <marsha...@gmail.com> wrote:
> The iwlwifi driver was throwing a horrible stack trace whenever resuming
> from suspend mode. Managed to work around it with:

This sounds that R2B2 is actually working on that hardware...

Can you just provide more information for the HCL please?
http://qubes-os.org/trac/wiki/HCL

Thanks.

[mgflax]

Here's an initial stab at HCL info:

Installation onto 256Gig mSATA from USB key. LVM on 256 mSATA

• dom0:/etc/fstab ⇒ add discard to /

• dom0:/etc/crypttab ⇒ add “allow-discard” after “none”

• template:/etc/fstab ⇒ add “discard” to / and /rw

TXT (but not “secure boot”) enabled in BIOS.

Before upgrading, 51qubes-suspend-netvm called on pm-suspend but not when lid is closed.  At least one hang when resuming from suspend (don’t remember if it was from pm-suspend or from lid closing).  In any case, I’m more interested in how the machine works after an upgrade, so I did: (TemplateVM: sudo yum upgrade) and (dom0: sudo qubes-dom0-update) -- both to 3.7.6-2.pvops.qubes.x86_64.

After upgrade: dom0:sudo pm-suspend *does* call /usr/lib64/pm-utils/sleep.d/51qubes-suspend-netvm but, but when resume desktop comes up *without* screenlock (or requiring a password).  On the other hand, closing the lid *doesn’t* call 51qubes-suspend-netvm but password is required upon suspend.  dom0:systemd-inhibit --list does list handle-{power-key,suspend-key,hibernate-key,lid-switch} as blocked.

Working

- - LAN networking (NOTE: survives pm-suspend but not lid-switch unless I do the dom0:/usr/lib/systemd/system-sleep hack above).

- - fn+ display brightness

- - fn + sleep

- - sound via speaker

- - volume buttons/mute

- - x220 docking station: cdrom, usb 2.0

- - usb 2.0

- - hardware wireless switch

Not working

- - fn + lock

- - fn + wireless on/off

- - sd card reader

Not yet tested

- - minidisplayport

- - wlan networking

- - audio input/output combo jack

- - fingerprint reader

- - fn+ media buttons play/pause/forward/backward

- - fn mircophone/webcam

- - microphone

- - usb 3.0

- - express card

- - vga

- - webcam

1. In dom0:/usr/lib/systemd/system-sleep, create a "netvm.sh" with the following contents to handle lid-switch

    #!/bin/bash

    qvm-run -u root netvm /usr/local/bin/$1.suspend.sh

    exit 0

2. In netvm:/usr/local/bin, create "pre.suspend.sh"

    #!/bin/bash

    modprobe -r iwldvm

    modprobe -r iwlwifi

3. In netvm:/usr/local/bin, create "post.suspend.sh"

[somelegald...@gmail.com]

Thankyou for your detailed feedback.
have you already tested remaining features?

> Not yet tested
> - - minidisplayport
> - - wlan networking
> - - audio input/output combo jack
> - - fingerprint reader
> - - fn+ media buttons play/pause/forward/backward

> - - fn mircophone/webcam- - microphone

> - - usb 3.0
> - - express card
> - - vga
> - - webcam
>

also, have you tested other(latest) releases?