HCL -- Thinkpad x230 Centrino Advanced-N 6205 AGN

943 views
Skip to first unread message

mgflax

unread,
Jul 18, 2013, 9:14:09 PM7/18/13
to qubes...@googlegroups.com
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

unread,
Jul 18, 2013, 9:35:32 PM7/18/13
to mgflax, qubes...@googlegroups.com
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

signature.asc

mgflax

unread,
Jul 18, 2013, 9:42:34 PM7/18/13
to qubes...@googlegroups.com, 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

unread,
Jul 18, 2013, 9:45:52 PM7/18/13
to mgflax, qubes...@googlegroups.com
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.
signature.asc

mgflax

unread,
Jul 18, 2013, 9:49:34 PM7/18/13
to qubes...@googlegroups.com, 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

unread,
Jul 18, 2013, 9:53:37 PM7/18/13
to mgflax, qubes...@googlegroups.com
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.
signature.asc

mgflax

unread,
Jul 18, 2013, 10:07:11 PM7/18/13
to qubes...@googlegroups.com, 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

unread,
Jul 18, 2013, 10:13:42 PM7/18/13
to mgflax, qubes...@googlegroups.com
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?

signature.asc

Laszlo Zrubecz

unread,
Jul 19, 2013, 3:11:15 PM7/19/13
to mgflax, qubes...@googlegroups.com
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

unread,
Jul 20, 2013, 10:02:43 PM7/20/13
to qubes...@googlegroups.com, 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"

Qubes-HCL-LENOVO-2320HPU-20130720.cpio.gz
Qubes-HCL-LENOVO-2320HPU-20130720.txt

somelegald...@gmail.com

unread,
Aug 9, 2015, 6:31:17 PM8/9/15
to qubes-users, marsha...@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?

Reply all
Reply to author
Forward
0 new messages