bug#24087: recovery from suspend is broken with recent libreboot + linux-libre 4.7

bug#24087: recovery from suspend is broken with recent libreboot + linux-libre 4.7

[ng0]

Following this[0] thread you can see the problems I have with libreboot
latest (latest at the time of flashing) experimental release.

Leah later said - an email or log I can not find at the moment on
libreboot or libreboot-dev - that this behavior was fixed with
a T400 system running parabola with linux-libre 4.6.4.

I know more people than just me are using libreboot here, do you have
any problems with suspend and recovery?
Can you test (if your system is already libreboot testing, if not wait
for either the next release candidate which should happen soon or be
ready to unbrick it) and provide logs so that we can fix it in our
system?


[0]: https://lists.gnu.org/archive/html/libreboot/2016-07/msg00020.html
-- 
♥Ⓐ  ng0
Current Keys: https://we.make.ritual.n0.is/ng0.txt
For non-prism friendly talk find me on http://www.psyced.org

bug#24087: recovery from suspend is broken with recent libreboot + linux-libre 4.7

[Danny Milosavljevic]

Hi,

> I know more people than just me are using libreboot here, do you have
> any problems with suspend and recovery?

I have a X200 and some time after waking up from suspend on the first larger disk access it hangs, losing all the dirty sector payload in the process. This is Guix-specific, the same machine works just fine on Ubuntu.

> Following this[0] thread you can see the problems I have with libreboot
> latest (latest at the time of flashing) experimental release.

> Can you test (if your system is already libreboot testing, if not wait
> for either the next release candidate which should happen soon or be
> ready to unbrick it) and provide logs so that we can fix it in our
> system?

I don't update the BIOS (I disabled the ability to do so in the chip settings).

Given the ability for an update to brick, I only flashed it once before there was any data on the machine - and I don't plan on doing it again on this machine.

I do actual work on this machine and were it not booting it would be much worse than wakeup not working.

I sometimes non-thinkingly close the laptop lid so it crashes from time to time. So if logs help I can provide those.

Also, dmidecode stopped working some time ago so I can't check which libreboot version I have.

$ sudo dmidecode 
Password: 
# dmidecode 2.12
SMBIOS 2.7 present.
8 structures occupying 382 bytes.
Table at 0xBDAB4020.

/dev/mem: Operation not permitted
Table is unreachable, sorry.

$ uname -a
Linux dayas 4.6.4-gnu #1 SMP 1 x86_64 GNU/Linux

bug#24087: recovery from suspend is broken with recent libreboot + linux-libre 4.7

[ng0]

Hi,

Danny Milosavljevic <dannym@scratchpost.org> writes:

> Hi,
>
>> I know more people than just me are using libreboot here, do you have
>> any problems with suspend and recovery?
>
> I have a X200 and some time after waking up from suspend on the first larger disk access it hangs, losing all the dirty sector payload in the process. This is Guix-specific, the same machine works just fine on Ubuntu.
>
>> Following this[0] thread you can see the problems I have with libreboot
>> latest (latest at the time of flashing) experimental release.
>
>> Can you test (if your system is already libreboot testing, if not wait
>> for either the next release candidate which should happen soon or be
>> ready to unbrick it) and provide logs so that we can fix it in our
>> system?
>
> I don't update the BIOS (I disabled the ability to do so in the chip settings).
>
> Given the ability for an update to brick, I only flashed it once before there was any data on the machine - and I don't plan on doing it again on this machine.
>
> I do actual work on this machine and were it not booting it would be much worse than wakeup not working.
>
> I sometimes non-thinkingly close the laptop lid so it crashes from time to time. So if logs help I can provide those.
>
> Also, dmidecode stopped working some time ago so I can't check which libreboot version I have.
>
> $ sudo dmidecode 
> Password: 
> # dmidecode 2.12
> SMBIOS 2.7 present.
> 8 structures occupying 382 bytes.
> Table at 0xBDAB4020.
>
> /dev/mem: Operation not permitted
> Table is unreachable, sorry.

This seems to be normal for GuixSD.  I don't have much knowledge about
how the kernel and drivers here are packaged and configured, maybe some
/dev/ devices are left out or we have more restriction than 'standard'
systems. With libreboot and Gentoo, or at least with coreboot and Gentoo
dmidecode worked… I think. I know that it works when I flash from ubuntu
livedisk.

Output for me (if not already written in my logs) is this:
# dmidecode 2.12
SMBIOS 2.7 present.
8 structures occupying 386 bytes.
Table at 0x7DAA0020.

/dev/mem: Operation not permitted
Table is unreachable, sorry.


> $ uname -a
> Linux dayas 4.6.4-gnu #1 SMP 1 x86_64 GNU/Linux

-- 
♥Ⓐ  ng0
Current Keys: https://we.make.ritual.n0.is/ng0.txt
For non-prism friendly talk find me on http://www.psyced.org

bug#24087: recovery from suspend is broken with recent libreboot + linux-libre 4.7

[ng0]

This is the boot up messages of one of the affected (running GuixSD)
devices. As I was assured this is a GuixSD specific problem, parabola,
trisquel and others do behave as expected (recover from
suspend/hibernate works).


Jul 28 15:32:29 localhost vmunix: [    0.000000] KERNEL supported cpus:
Jul 28 15:32:29 localhost vmunix: [    0.000000]   Intel GenuineIntel
Jul 28 15:32:29 localhost vmunix: [    0.000000]   AMD AuthenticAMD
Jul 28 15:32:29 localhost vmunix: [    0.000000]   Centaur CentaurHauls

I am used to individual configured kernels, so this might be just my
impression. Should this not be more specific, include core2 etc, or is
this just a listing of vendors there and not the cpu selection I
remember from the makemenuconfig dialog?

Then further on there's a call trace, this will be pasted here and leave
out some lines because I don't like to be that transparent in clear
public communication about my hardware.  Then again I don't know how
much this will tell, so if anyone says it's easier to debug with the
full information provided, I could do so.  This trace happens every time
I boot:

Jul 28 15:32:36 localhost vmunix: [    0.000000] ------------[ cut here ]------------
Jul 28 15:32:36 localhost vmunix: [    0.000000] WARNING: CPU: 0 PID: 0 at drivers/iommu/dmar.c:830 warn_invalid_dmar.part.7+0x78/0x90
Jul 28 15:32:36 localhost vmunix: [    0.000000] Your BIOS is broken; DMAR reported at address fed92000 returns all ones!
-- snip for bios vendor etc etc --
Jul 28 15:32:37 localhost vmunix: [    0.000000] Modules linked in:
Jul 28 15:32:37 localhost vmunix: [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.7.0-gnu #1
-- snip for hardware name etc --
Jul 28 15:32:37 localhost vmunix: [    0.000000] Call Trace:
Jul 28 15:32:37 localhost vmunix: [    0.000000]  [<ffffffff813dce53>] dump_stack+0x63/0x90
Jul 28 15:32:37 localhost vmunix: [    0.000000]  [<ffffffff81080ef1>] __warn+0xd1/0xf0
Jul 28 15:32:38 localhost vmunix: [    0.000000]  [<ffffffff81080fe7>] warn_slowpath_fmt_taint+0x57/0x70
Jul 28 15:32:38 localhost vmunix: [    0.000000]  [<ffffffff81fa81fc>] ? __early_ioremap+0x14b/0x1d2
Jul 28 15:32:38 localhost vmunix: [    0.000000]  [<ffffffff815271b8>] warn_invalid_dmar.part.7+0x78/0x90
Jul 28 15:32:38 localhost vmunix: [    0.000000]  [<ffffffff8181e524>] dmar_validate_one_drhd+0x84/0xe0
Jul 28 15:32:38 localhost vmunix: [    0.000000]  [<ffffffff81526b53>] dmar_walk_remapping_entries+0x83/0x1a0
Jul 28 15:32:38 localhost vmunix: [    0.000000]  [<ffffffff81fc612c>] detect_intel_iommu+0x5f/0xf2
Jul 28 15:32:38 localhost vmunix: [    0.000000]  [<ffffffff8181e4a0>] ? xen_swiotlb_init+0x4b0/0x4b0
Jul 28 15:32:39 localhost vmunix: [    0.000000]  [<ffffffff81f8124e>] pci_iommu_alloc+0x4a/0x6c
Jul 28 15:32:39 localhost vmunix: [    0.000000]  [<ffffffff81f907a3>] mem_init+0x11/0xa3
Jul 28 15:32:39 localhost vmunix: [    0.000000]  [<ffffffff81f71dc9>] start_kernel+0x230/0x489
Jul 28 15:32:39 localhost vmunix: [    0.000000]  [<ffffffff81f71120>] ? early_idt_handler_array+0x120/0x120
Jul 28 15:32:39 localhost vmunix: [    0.000000]  [<ffffffff81f71481>] x86_64_start_reservations+0x2f/0x31
Jul 28 15:32:39 localhost vmunix: [    0.000000]  [<ffffffff81f715cd>] x86_64_start_kernel+0x14a/0x16d
Jul 28 15:32:39 localhost vmunix: [    0.000000] ---[ end trace e301e3fe181525a1 ]---


Moving on:

Jul 28 15:32:43 localhost vmunix: [    0.040144] DMAR: Host address width 36
Jul 28 15:32:44 localhost vmunix: [    0.040150] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
Jul 28 15:32:44 localhost vmunix: [    0.040166] DMAR: dmar0: reg_base_addr fed90000 ver 1:0 cap c9008020e30260 ecap 1000
Jul 28 15:32:44 localhost vmunix: [    0.040175] DMAR: DRHD base: 0x000000fed91000 flags: 0x0
Jul 28 15:32:44 localhost vmunix: [    0.040184] DMAR: dmar1: reg_base_addr fed91000 ver 1:0 cap c0000020630260 ecap 1000
Jul 28 15:32:44 localhost vmunix: [    0.040193] DMAR: DRHD base: 0x000000fed92000 flags: 0x0
Jul 28 15:32:44 localhost vmunix: [    0.040207] DMAR: Failed to map dmar2
Jul 28 15:32:44 localhost vmunix: [    0.040212] DMAR: Parse DMAR table failure.

Then there are some lines about some devices and  "System wakeup disabled by ACPI"

...

Jul 28 15:33:01 localhost vmunix: [    0.482055] ACPI Exception: AE_NOT_FOUND, Error reading AC Adapter state (20160422/ac-128)
Jul 28 15:33:01 localhost vmunix: [    0.482218] input: Sleep Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:2a/PNP0C09:00/PNP0C0E:00/input/input0
Jul 28 15:33:01 localhost vmunix: [    0.482290] ACPI: Sleep Button [SLPB]
Jul 28 15:33:01 localhost vmunix: [    0.482388] input: Lid Switch as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:2a/PNP0C09:00/PNP0C0D:00/input/input1
Jul 28 15:33:01 localhost vmunix: [    0.482578] ACPI: Lid Switch [LID] Jul 28 15:33:01 localhost vmunix: [    0.482680] input: Power Button as
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input2
Jul 28 15:33:02 localhost vmunix: [    0.482732] ACPI: Power Button [PWRF]
Jul 28 15:33:02 localhost vmunix: [    0.484295] tsc: Marking TSC unstable due to TSC halts in idle
Jul 28 15:33:02 localhost vmunix: [    0.486639] thermal LNXTHERM:00: registered as thermal_zone0
Jul 28 15:33:02 localhost vmunix: [    0.486685] ACPI: Thermal Zone [THM0] (32 C)
Jul 28 15:33:02 localhost vmunix: [    0.488684] thermal LNXTHERM:01: registered as thermal_zone1
Jul 28 15:33:02 localhost vmunix: [    0.489901] ACPI: Thermal Zone [THM1] (29 C)
Jul 28 15:33:02 localhost vmunix: [    0.491148] GHES: HEST is not enabled!

...


Jul 28 15:33:16 localhost vmunix: [    7.389127] acpi device:04: registered as cooling_device2
Jul 28 15:33:16 localhost vmunix: [    7.389897] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input5
Jul 28 15:33:16 localhost vmunix: [    7.546204] ACPI Warning: SystemIO range 0x0000000000000528-0x000000000000052F conflicts with OpRegion 0x0000000000000500-0x000000000000057F (\PMIO) (20160422/utaddress-255)
Jul 28 15:33:17 localhost vmunix: [    7.547836] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
Jul 28 15:33:17 localhost vmunix: [    7.548752] ACPI Warning: SystemIO range 0x00000000000005B0-0x00000000000005BF conflicts with OpRegion 0x0000000000000580-0x00000000000005BE (\GPCM) (20160422/utaddress-255)
Jul 28 15:33:17 localhost vmunix: [    7.550626] ACPI Warning: SystemIO range 0x00000000000005B0-0x00000000000005BF conflicts with OpRegion 0x0000000000000580-0x00000000000005BB (\GPIO) (20160422/utaddress-255)
Jul 28 15:33:17 localhost vmunix: [    7.552731] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
Jul 28 15:33:17 localhost vmunix: [    7.553853] ACPI Warning: SystemIO range 0x0000000000000580-0x00000000000005AF conflicts with OpRegion 0x0000000000000580-0x00000000000005BE (\GPCM) (20160422/utaddress-255)
Jul 28 15:33:17 localhost vmunix: [    7.556230] ACPI Warning: SystemIO range 0x0000000000000580-0x00000000000005AF conflicts with OpRegion 0x0000000000000580-0x00000000000005BB (\GPIO) (20160422/utaddress-255)
Jul 28 15:33:17 localhost vmunix: [    7.558815] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
Jul 28 15:33:17 localhost vmunix: [    7.560144] lpc_ich: Resource conflict(s) found affecting gpio_ich
Jul 28 15:33:18 localhost vmunix: [    7.670414] Non-volatile memory driver v1.3

...

Jul 28 15:33:23 localhost vmunix: [    9.259071] i915 0000:00:02.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0x0000
Jul 28 15:33:23 localhost vmunix: [    9.259077] [drm] failed to find VBIOS tables
Jul 28 15:33:23 localhost vmunix: [    9.259614] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem

...

Jul 28 15:33:24 localhost vmunix: [    9.398653] [drm] RC6 disabled, disabling runtime PM support
Jul 28 15:33:24 localhost vmunix: [    9.398720] [drm] Initialized i915 1.6.0 20160425 for 0000:00:02.0 on minor 0
Jul 28 15:33:24 localhost vmunix: [   10.153770] intel_powerclamp: No package C-state available
Jul 28 15:33:25 localhost vmunix: [   10.276405] intel_powerclamp: No package C-state available


-- 
♥Ⓐ  ng0
Current Keys: https://we.make.ritual.n0.is/ng0.txt
For non-prism friendly talk find me on http://www.psyced.org

bug#24087: recovery from suspend is broken with recent libreboot + linux-libre 4.7

[Mark H Weaver]

Danny Milosavljevic <dannym@scratchpost.org> writes:

> Hi,
>
>> I know more people than just me are using libreboot here, do you have
>> any problems with suspend and recovery?
>
> I have a X200 and some time after waking up from suspend on the first
> larger disk access it hangs, losing all the dirty sector payload in
> the process. This is Guix-specific, the same machine works just fine
> on Ubuntu.

It's unlikely to be Guix-specific.  More likely, it's related to the
kernel version.  On several occasions in the past, new kernels have been
found to have problems on Libreboot systems.

We include older kernel versions: linux-libre-4.4 and linux-libre-4.1,
which you can select via the 'kernel' field of the OS configuration,
e.g.: (kernel linux-libre-4.4)

Can you try these and see if the problem persists?

For what it's worth, linux-libre-4.7 works well for me on my Libreboot
X60.

       Mark

bug#24087: recovery from suspend is broken with recent libreboot + linux-libre 4.7

[Clément Lassieur]

Hi,

> We include older kernel versions: linux-libre-4.4 and linux-libre-4.1,
> which you can select via the 'kernel' field of the OS configuration,
> e.g.: (kernel linux-libre-4.4)
>
> Can you try these and see if the problem persists?

I tried these kernels and still have the problem (with GuixSD +
libreboot x200).

Clément

bug#24087: recovery from suspend is broken with recent libreboot + linux-libre 4.7

[ng0]

Clément Lassieur <clement@lassieur.org> writes:

> Hi,
>
>> We include older kernel versions: linux-libre-4.4 and linux-libre-4.1,
>> which you can select via the 'kernel' field of the OS configuration,
>> e.g.: (kernel linux-libre-4.4)
>>
>> Can you try these and see if the problem persists?
>
> I tried these kernels and still have the problem (with GuixSD +
> libreboot x200).
>
> Clément
>
>
>

I had my original problems (see subject) on 4.6 and 4.7. It is likely
that they appear on earlier kernels too.

I will try to test 4.1 and 4.4 when I have the time, but I doubt it
changes anything.

Mark, Clèment: Do you run the release or the testing version of
libreboot?
-- 
♥Ⓐ  ng0
Current Keys: https://we.make.ritual.n0.is/ng0.txt
For non-prism friendly talk find me on http://www.psyced.org

bug#24087: recovery from suspend is broken with recent libreboot + linux-libre 4.7

[Clément Lassieur]

> Mark, Clèment: Do you run the release or the testing version of
> libreboot?

I reproduced with both stable (20150518) and beta
(experimental-86-g07ed7f9).

For each one of them, I tried linux-libre 4.1, 4.4 and 4.7 without
success.

Note that my system is encrypted (except /boot).

bug#24087: recovery from suspend is broken with recent libreboot + linux-libre 4.7

[Danny Milosavljevic]

My machine just crashed with a Linux oops (with blinking caps lock and everything) - the second time it did that, ever.

I have crashkernel enabled - but unfortunately the kernel that Guix installed didn't have all the flags enabled that I need to be able to generate the crashdump.

See http://dedoimedo.com/computers/kdump.html#mozTocId967714

Also, I have 2 CPUs and kdump only supports 1 CPU :(

What's the standard way to recover just the oops text? I didn't see any text.

bug#24087: recovery from suspend is broken with recent libreboot + linux-libre 4.7

[Mark H Weaver]

ng0 <ng0@we.make.ritual.n0.is> writes:

> Clément Lassieur <clement@lassieur.org> writes:
>
>> Hi,
>>
>>> We include older kernel versions: linux-libre-4.4 and linux-libre-4.1,
>>> which you can select via the 'kernel' field of the OS configuration,
>>> e.g.: (kernel linux-libre-4.4)
>>>
>>> Can you try these and see if the problem persists?
>>
>> I tried these kernels and still have the problem (with GuixSD +
>> libreboot x200).
>>
>> Clément
>>
>>
>>
>
> I had my original problems (see subject) on 4.6 and 4.7. It is likely
> that they appear on earlier kernels too.
>
> I will try to test 4.1 and 4.4 when I have the time, but I doubt it
> changes anything.
>
> Mark, Clèment: Do you run the release or the testing version of
> libreboot?

I'm running an older Libreboot release on my X60: 20150126

      Mark

bug#24087: recovery from suspend is broken with recent libreboot + linux-libre 4.7

[Vincent Legoll]

> What's the standard way to recover just the oops text? I didn't see any text

Can you setup a serial console or a netconsole ? That should help you
get the logs.

-- 
Vincent Legoll

bug#24087: recovery from suspend is broken with recent libreboot + linux-libre 4.7

[Ricardo Wurmus]

Clément Lassieur <clement@lassieur.org> writes:

> Hi,
>
>> We include older kernel versions: linux-libre-4.4 and linux-libre-4.1,
>> which you can select via the 'kernel' field of the OS configuration,
>> e.g.: (kernel linux-libre-4.4)
>>
>> Can you try these and see if the problem persists?
>
> I tried these kernels and still have the problem (with GuixSD +
> libreboot x200).

I have an X200s with the 2015 release of libreboot.  I’m using the 4.1
kernel and have no problems.

AFAIR suspend problems on X200 and similar are a known regression in the
current version of libreboot.

~~ Ricardo

bug#24087: recovery from suspend is broken with recent libreboot + linux-libre 4.7

[ng0]

Mark H Weaver <mhw@netris.org> writes:

> Danny Milosavljevic <dannym@scratchpost.org> writes:
>
>> Hi,
>>
>>> I know more people than just me are using libreboot here, do you have
>>> any problems with suspend and recovery?
>>
>> I have a X200 and some time after waking up from suspend on the first
>> larger disk access it hangs, losing all the dirty sector payload in
>> the process. This is Guix-specific, the same machine works just fine
>> on Ubuntu.
>
> It's unlikely to be Guix-specific.  More likely, it's related to the
> kernel version.  On several occasions in the past, new kernels have been
> found to have problems on Libreboot systems.
>
> We include older kernel versions: linux-libre-4.4 and linux-libre-4.1,
> which you can select via the 'kernel' field of the OS configuration,
> e.g.: (kernel linux-libre-4.4)
>
> Can you try these and see if the problem persists?
>
> For what it's worth, linux-libre-4.7 works well for me on my Libreboot
> X60.
>
>        Mark
I think this is more or less coreboot and libreboot related.
Libreboot is working on it[0], and I'd rather sit on this bug until it
is solved upstream. Testing t400 image now could mean to repeat the
disassemble,reassemble procedure if I get a brick[1] ;)


[0]: https://libreboot.org/download/#tasks
[1]: http://vignette4.wikia.nocookie.net/fatherted/images/1/17/Brick.PNG/revision/latest?cb=20110426185303
-- 
♥Ⓐ  ng0
Current Keys: https://we.make.ritual.n0.is/ng0.txt
For non-prism friendly talk find me on http://www.psyced.org

bug#24087: recovery from suspend is broken with recent libreboot + linux-libre 4.7

[Danny Milosavljevic]

Thanks to Kei I could now check the libreboot version:

--------------------------------------------------------------------------
Getting SMBIOS data from sysfs.
SMBIOS 2.7 present.
8 structures occupying 382 bytes.
Table at 0xBDAB4020.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
        Vendor: coreboot
        Version: CBET4000 4.0
        Release Date: 05/18/2015
        ROM Size: 8192 kB
        Characteristics:
                PCI is supported
                PC Card (PCMCIA) is supported
                BIOS is upgradeable
                Selectable boot is supported
                ACPI is supported
                Targeted content distribution is supported
        BIOS Revision: 4.0
        Firmware Revision: 0.0

Handle 0x0001, DMI type 1, 27 bytes
System Information
        Manufacturer: LENOVO
        Product Name: 74553XG
        Version: ThinkPad X200
        Serial Number: <snip>
        UUID: <snip>
        Wake-up Type: Reserved
        SKU Number: Not Specified
        Family: Not Specified

Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
        Manufacturer: LENOVO
        Product Name: 74553XG
        Version: ThinkPad X200
        Serial Number: <snip>

Handle 0x0003, DMI type 3, 21 bytes
Chassis Information
        Manufacturer: LENOVO
        Type: Laptop
        Lock: Not Present
        Version: Not Specified
        Serial Number: Not Specified
        Asset Tag: Not Specified
        Boot-up State: Safe
        Power Supply State: Safe
        Thermal State: Safe
        Security Status: None
        OEM Information: 0x00000000
        Height: Unspecified
        Number Of Power Cords: Unspecified
        Contained Elements: 0

Handle 0x0004, DMI type 4, 42 bytes
Processor Information
        Socket Designation: Not Specified
        Type: Central Processor
        Family: Pentium Pro
        Manufacturer: GenuineIntel
        ID: <snip>
        Signature: Type 0, Family 6, Model 23, Stepping 10
        Flags:
                FPU (Floating-point unit on-chip)
                VME (Virtual mode extension)
                DE (Debugging extension)
                PSE (Page size extension)
                TSC (Time stamp counter)
                MSR (Model specific registers)
                PAE (Physical address extension)
                MCE (Machine check exception)
                CX8 (CMPXCHG8 instruction supported)
                APIC (On-chip APIC hardware supported)
                SEP (Fast system call)
                MTRR (Memory type range registers)
                PGE (Page global enable)
                MCA (Machine check architecture)
                CMOV (Conditional move instruction supported)
                PAT (Page attribute table)
                PSE-36 (36-bit page size extension)
                CLFSH (CLFLUSH instruction supported)
                DS (Debug store)
                ACPI (ACPI supported)
                MMX (MMX technology supported)
                FXSR (FXSAVE and FXSTOR instructions supported)
                SSE (Streaming SIMD extensions)
                SSE2 (Streaming SIMD extensions 2)
                SS (Self-snoop)
                HTT (Multi-threading)
                TM (Thermal monitor supported)
                PBE (Pending break enabled)
        Version: Intel(R) Core(TM)2 CPU         P8600  @ 2.40GHz
        Voltage: Unknown
        External Clock: Unknown
        Max Speed: Unknown
        Current Speed: Unknown
        Status: Unpopulated
        Upgrade: Other
        L1 Cache Handle: Not Provided
        L2 Cache Handle: Not Provided
        L3 Cache Handle: Not Provided
        Serial Number: Not Specified
        Asset Tag: Not Specified
        Part Number: Not Specified
        Core Count: 2
        Characteristics: None

Handle 0x0005, DMI type 11, 5 bytes
OEM Strings
        String 1: IBM ThinkPad Embedded Controller -[7XHT22WW-3.6     ]-

Handle 0x0006, DMI type 32, 11 bytes
System Boot Information
        Status: No errors detected

Handle 0x0007, DMI type 127, 4 bytes
End Of Table
--------------------------------------------------------------------------

bug#24087: recovery from suspend is broken with recent libreboot + linux-libre 4.7

[ng0]

Hi,

ng0 <ng0@we.make.ritual.n0.is> writes:

> Following this[0] thread you can see the problems I have with libreboot
> latest (latest at the time of flashing) experimental release.
>
> Leah later said - an email or log I can not find at the moment on
> libreboot or libreboot-dev - that this behavior was fixed with
> a T400 system running parabola with linux-libre 4.6.4.
>
> I know more people than just me are using libreboot here, do you have
> any problems with suspend and recovery?
> Can you test (if your system is already libreboot testing, if not wait
> for either the next release candidate which should happen soon or be
> ready to unbrick it) and provide logs so that we can fix it in our
> system?
>
>
> [0]: https://lists.gnu.org/archive/html/libreboot/2016-07/msg00020.html

I just flashed the latest stable of libreboot and for t400 it is fixed,
I can recover from suspend. Thanks to the amazing work of Leah and all
other libreboot contributors :)
-- 
ng0
For non-prism friendly talk find me on http://www.psyced.org

bug#24087: Acknowledgement (recovery from suspend is broken with recent libreboot + linux-libre 4.7)

[ng0]

GNU bug Tracking System <help-debbugs@gnu.org> writes:

> Thank you for filing a new bug report with debbugs.gnu.org.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  bug-guix@gnu.org
>
> If you wish to submit further information on this problem, please
> send it to 24087@debbugs.gnu.org.
>
> Please do not send mail to help-debbugs@gnu.org unless you wish
> to report a problem with the Bug-tracking system.
>
> -- 
> 24087: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=24087
> GNU Bug Tracking System
> Contact help-debbugs@gnu.org with problems

Additionally: We have to include in our documentation either a link to
how to deal with debbugs (specifically: how to close bugs) or if it's
not already existing, create it in Guix contrib documentation and
upstream it.
I have no clue how to close this bug, and upstream website is not good
in providing info.
-- 
ng0
For non-prism friendly talk find me on http://www.psyced.org

bug#24087:

[ng0]

bug#24087: recovery from suspend is broken with recent libreboot + linux-libre 4.7

[Clément Lassieur]

> I just flashed the latest stable of libreboot and for t400 it is fixed,
> I can recover from suspend. Thanks to the amazing work of Leah and all
> other libreboot contributors :)

I still reproduce the bug with latest stable and x200.

bug#24087: recovery from suspend is broken with recent libreboot + linux-libre 4.7

[Clément Lassieur]

Clément Lassieur <clement@lassieur.org> writes:

>> I just flashed the latest stable of libreboot and for t400 it is fixed,
>> I can recover from suspend. Thanks to the amazing work of Leah and all
>> other libreboot contributors :)
>
> I still reproduce the bug with latest stable and x200.

This is probably a libreboot bug, because it is reproducible with
Debian.  Closing it.

bug#24087: recovery from suspend is broken with recent libreboot + linux-libre 4.7

[Christopher Allan Webber]

Clément Lassieur writes:

> Clément Lassieur <clement@lassieur.org> writes:
>
>>> I just flashed the latest stable of libreboot and for t400 it is fixed,
>>> I can recover from suspend. Thanks to the amazing work of Leah and all
>>> other libreboot contributors :)
>>
>> I still reproduce the bug with latest stable and x200.
>
> This is probably a libreboot bug, because it is reproducible with
> Debian.  Closing it.

Libreboot is probably involved, but it's a combination of libreboot +
linux-libre upgrades fwiw.

I'm running an X200 with an older version of Libreboot.  I just verified
that Linux 4.10.X still suspends fine, but 4.11 fails to suspend.

Anyway, not saying it shouldn't be closed, but maybe useful information
for people to have.

bug#24087: recovery from suspend is broken with recent libreboot + linux-libre 4.7

[Clément Lassieur]

Christopher Allan Webber <cwebber@dustycloud.org> writes:

> Clément Lassieur writes:
>
>> Clément Lassieur <clement@lassieur.org> writes:
>>
>>>> I just flashed the latest stable of libreboot and for t400 it is fixed,
>>>> I can recover from suspend. Thanks to the amazing work of Leah and all
>>>> other libreboot contributors :)
>>>
>>> I still reproduce the bug with latest stable and x200.
>>
>> This is probably a libreboot bug, because it is reproducible with
>> Debian.  Closing it.
>
> Libreboot is probably involved, but it's a combination of libreboot +
> linux-libre upgrades fwiw.
>
> I'm running an X200 with an older version of Libreboot.  I just verified
> that Linux 4.10.X still suspends fine, but 4.11 fails to suspend.

I've reproduced the bug with Debian testing (linux-nonfree 4.9 +
libreboot stable).

> Anyway, not saying it shouldn't be closed, but maybe useful information
> for people to have.

Thank you, it is interesting indeed!

While chatting on #libreboot the other day, and I've been told that this
might have been fixed upstream (coreboot), but that the fix introduces
random "forced suspends" every week or so.  I'm going to try, as I
prefer my computer to shut down every week than not being able to
suspend to ram.