HP Mini 1000 fails to resume from suspend

[Erich Eickmeyer]

Booting various kernels including the mainline 3.12 kernel, HP Mini 1000 does not resume from suspend. Problem seems to have begun following update to 13.10, including kernels 3.9, 3.10, 3.11.

Ran steps on DebuggingKernelSuspend wiki page at https://wiki.ubuntu.com/DebugginKernelSuspend#A.22resume-trace.22_debugging_procedure_for_finding_buggy_drivers.

Attached: dmesg.txt
---
ApportVersion: 2.12.5-0ubuntu2.1
Architecture: i386
DistroRelease: Ubuntu 13.10
EcryptfsInUse: Yes
InstallationDate: Installed on 2013-11-12 (1 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release i386 (20131016.1)
MarkForUpload: True
NonfreeKernelModules: wl
Package: linux (not installed)
Tags: saucy
Uname: Linux 3.12.0-031200-generic i686
UnreportableReason: The running kernel is not an Ubuntu kernel
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1251065

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Alan Pope 🍺🐧🐱 🦄 (popey)]

Looks like perhaps a video driver issue?

[ 2.130646] Magic number: 0:559:321
[ 2.130654] hash matches /home/apw/COD/linux/drivers/base/power/main.c:581
[ 2.130720] tty tty46: hash matches
[ 2.130745] pci 0000:00:02.0: hash matches

[ 2.689886] i915 0000:00:02.0: setting latency timer to 64

[Erich Eickmeyer (eeickmeyer)]

apport information

[Colin Ian King (colin-king)]

I can reproduce this, I will bisect the kernel and figure out what's broken. May take a while to do.

[Colin Ian King (colin-king)]

This is proving to be a bit tricky, commit fa55583797d12b10928a1813f3dcf066637caf5e causes a regression on the i915 driver on resume causing screen corruption, making it hard to see resume failures on the console. I've now figured out between which two points the resume hangs, but I need to now revert the above commit on each bisect so I can see what's happening when it hangs. But I am slowly making some progress.

[Colin Ian King (colin-king)]

There is a S3 resume issue that affects HP Mini Atom N270 with Intel
Mobile 945GSE on Linux 3.9.0 upwards.

Device:
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile
945GSE Express Integrated Graphics Controller [8086:27ae] (rev 03)
(prog-if 00 [VGA controller])
        Subsystem: Hewlett-Packard Company Device [103c:361a]
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at fe980000 (32-bit, non-prefetchable) [size=512K]
        Region 1: I/O ports at dc80 [size=8]
        Region 2: Memory at d0000000 (32-bit, prefetchable) [size=256M]
        Region 3: Memory at fe940000 (32-bit, non-prefetchable) [size=256K]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: <access denied>
        Kernel driver in use: i915

Issue: On S3 resume screen is blank. I've tracked this down to 2 patches:

1. 24576d23976746cb52e7700c4cadbf4bc1bc3472

drm/i915: enable VT switchless resume v3

This commit stops the screen from turning back on. Without the patch the
screen resumes back to on, however it is filled with random vertical lines.

2. fa55583797d12b10928a1813f3dcf066637caf5e

drm/i915: fixup the plane->pipe fixup code

I have to manually revert this. If I don't I get the random vertical
lines on resume.

[Chris Wilson (ickle)]

Start off with a drm.debug=6 dmesg just so we can get a feel for the hardware and what is going on. If you revert the switchless resume patch, then grab intel_reg_dumper output before and after resume, that will highlight what the bios touched. In fact, if you grab intel_reg_dumper after resume with each patch reverted (none, only switchless patch reverted, both patches reverted) that is likely to have sufficient information to figure out both bugs.

[Colin Ian King (colin-king)]

I've tracked this down to 2 patches that trigger this issue:

1. 24576d23976746cb52e7700c4cadbf4bc1bc3472

drm/i915: enable VT switchless resume v3

This commit stops the screen from turning back on. Without the patch the
screen resumes back to on, however it is filled with random vertical lines.

2. fa55583797d12b10928a1813f3dcf066637caf5e

drm/i915: fixup the plane->pipe fixup code

I have to manually revert this. If I don't I get the random vertical
lines on resume.

[Colin Ian King (colin-king)]

Created attachment 90873
dmesg log

[Colin Ian King (colin-king)]

I ran intel_reg_dumper, but I am seeing:

Gen2/3 Ranges are not supported. Please use unsafe access.

[Chris Wilson (ickle)]

(In reply to comment #3)
> I ran intel_reg_dumper, but I am seeing:
>
> Gen2/3 Ranges are not supported. Please use unsafe access.

BEN! You will need to build intel-gpu-tools from git (or a recent stable release).

[Colin Ian King (colin-king)]

Created attachment 90886
3.9.0, no reverts, before S3

[Colin Ian King (colin-king)]

Created attachment 90887
3.9.0, no reverts, after S3

[Colin Ian King (colin-king)]

Created attachment 90888
3.9.0, reverted commit fa55583, before s3

[Colin Ian King (colin-king)]

Created attachment 90889
3.9.0, reverted commit fa55583, built at head b5644d0, before s3

[Colin Ian King (colin-king)]

Created attachment 90890
3.9.0, reverted commit fa55583, built at head b5644d0, after s3

[Colin Ian King (colin-king)]

Attached are the requested register dumps. Could not resume on the revert of fa55583, so no "after S3" results for that. Apoligies it took so long, had issues getting build of the latest intel-gpu-tools sorted (other dependancy issues).

[Chris Wilson (ickle)]

Hmm, the BIOS sets DSPCLK_GATE_D DPLUNIT which we don't restore, that may result in some instability on your machine, and it may be generally applicable to gen3 devices.

[Colin Ian King (colin-king)]

OK, that's interesting to know. I know for sure that HP aren't doing any BIOS updates on that unit (as I worked on enabling it several years ago).

[Chris Wilson (ickle)]

Out of curiosity more than anything else, can you try

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 27300d6b583b..eb2fa4b89219 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5548,6 +5548,8 @@ static void gen3_init_clock_gating(struct drm_device *dev)
        if (IS_PINEVIEW(dev))
                I915_WRITE(ECOSKPD, _MASKED_BIT_ENABLE(ECO_GATING_CX_ONLY));

+ I915_WRITE(DSPCLK_GATE_D, I915_READ(DSPCLK_GATE_D) | DPLUNIT_CLOCK_GATE_DISABLE);
+
        /* IIR "flip pending" means done if this bit is set */
        I915_WRITE(ECOSKPD, _MASKED_BIT_DISABLE(ECO_FLIP_DONE));
 }

and see if that cures the random lines?

[Colin Ian King (colin-king)]

Chris, unfortunately that patch does not fix the random vertical lines.

[Colin Ian King (colin-king)]

..although I discovered today that the machine later blanks the screen after several of idle and then unblanks it in a fully working state. Not sure if that is a helpful data point to consider.

[Chris Wilson (ickle)]

Colin, just to clarify, do you mean that after an xrandr (or dpms) off/on, everything is back to normal? No random vertical lines? That's more or less what we expected due to "enable VT switchless resume" and userspace missing its hotplug notifications, but I was still expecting the garbage.

If you try 3.12/3.13 do we get any more warnings about inconsistent hw state?

[Colin Ian King (colin-king)]

so I believe xrandr is sorting this out, running it manually:

king@hpmini:~$ xrandr --output LVDS1 --off
king@hpmini:~$ xrandr --output LVDS1 --auto

seems to get rid of the vertical lines.

"If you try 3.12/3.13 do we get any more warnings about inconsistent hw state?"
.. I can test with 3.13 later today, but how do I check for inconsistent hw state?

[Chris Wilson (ickle)]

(In reply to comment #17)
> so I believe xrandr is sorting this out, running it manually:
>
> king@hpmini:~$ xrandr --output LVDS1 --off
> king@hpmini:~$ xrandr --output LVDS1 --auto
>
> seems to get rid of the vertical lines.

Ok, that just confirms that the hotplug uevent that we send upon resume is just vanishing. I think.

> "If you try 3.12/3.13 do we get any more warnings about inconsistent hw
> state?"
> .. I can test with 3.13 later today, but how do I check for inconsistent hw
> state?

The kernel has more checks and will print an OOPS report if it finds the hardware in an inconsistent state.

[Chris Wilson (ickle)]

Colin, will it possible to try with drm-intel-nightly (or latest mainline) to see if the state checker catches anything?

Also it would be interesting to read an --enable-debug=full Xorg.0.log to see what happened to that uevent.

[Colin Ian King (colin-king)]

Today's mainline kernel (top commit 85ce70fdf48aa290b4845311c2dd815d7f8d1fa5)

[ 241.352344] INFO: task systemd-udevd:381 blocked for more than 120 seconds.
[ 241.352420] Tainted: PF O 3.13.0-3-generic #18-Ubuntu
[ 241.352474] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 241.352532] systemd-udevd D f4fd7a24 0 381 270 0x00000004
[ 241.352552] f4fd7a4c 00000086 c12f0573 f4fd7a24 c18294f8 c1a7c780 00000001 00000001
[ 241.352582] c1a7c780 f5858000 f68a0d00 0003d1d6 00000000 f4fd7a1c f86e97df 1b762573
[ 241.352608] f86e97e1 f86e97e1 f86ee998 f4fd7a60 c12f29dc 00000001 00000000 0000ff02
[ 241.352635] Call Trace:
[ 241.352663] [<c12f0573>] ? format_decode+0x323/0x390
[ 241.352708] [<c12f29dc>] ? vsnprintf+0x2cc/0x3d0
[ 241.352728] [<c12f0001>] ? put_dec_trunc8+0x61/0xa0
[ 241.352750] [<c16415a3>] schedule_preempt_disabled+0x23/0x60
[ 241.352766] [<c1642eed>] __mutex_lock_slowpath+0x10d/0x171
[ 241.352782] [<c164241c>] mutex_lock+0x1c/0x28
[ 241.352910] [<f8d93aa2>] intel_get_load_detect_pipe+0x152/0x3a0 [i915]
[ 241.353059] [<f8dc3142>] ? gen4_read32+0x32/0xb0 [i915]
[ 241.353075] [<c12f2b6a>] ? snprintf+0x1a/0x20
[ 241.353195] [<f8d9516d>] intel_modeset_setup_hw_state+0xa7d/0xae0 [i915]
[ 241.353273] [<f86cffd8>] ? drm_mode_config_reset+0x98/0xb0 [drm]
[ 241.353392] [<f8d951fe>] intel_modeset_gem_init+0x2e/0x40 [i915]
[ 241.353490] [<f8d5abfb>] i915_driver_load+0xb3b/0xdc0 [i915]
[ 241.353586] [<f8d57e10>] ? i915_switcheroo_set_state+0xa0/0xa0 [i915]
[ 241.353706] [<f86cbcab>] drm_dev_register+0x8b/0x1a0 [drm]
[ 241.353768] [<f86cd78e>] drm_get_pci_dev+0x7e/0x120 [drm]
[ 241.353797] [<c11d8e37>] ? sysfs_do_create_link_sd.isra.2+0xa7/0x1c0
[ 241.353897] [<f8d575ea>] i915_pci_probe+0x3a/0x80 [i915]
[ 241.353918] [<c132870f>] pci_device_probe+0x6f/0xc0
[ 241.353934] [<c11d8f75>] ? sysfs_create_link+0x25/0x40
[ 241.353956] [<c13faf65>] driver_probe_device+0x105/0x380
[ 241.353972] [<c1328662>] ? pci_match_device+0xb2/0xc0
[ 241.353992] [<c13fb291>] __driver_attach+0x71/0x80
[ 241.354008] [<c13fb220>] ? __device_attach+0x40/0x40
[ 241.354026] [<c13f93c7>] bus_for_each_dev+0x47/0x80
[ 241.354043] [<c13fa9ce>] driver_attach+0x1e/0x20
[ 241.354057] [<c13fb220>] ? __device_attach+0x40/0x40
[ 241.354072] [<c13fa627>] bus_add_driver+0x157/0x230
[ 241.354093] [<c13fb859>] driver_register+0x59/0xe0
[ 241.354111] [<c10487a0>] ? __set_pmd_pte+0xa0/0xa0
[ 241.354130] [<c1327142>] __pci_register_driver+0x32/0x40
[ 241.354191] [<f86cd925>] drm_pci_init+0xf5/0x100 [drm]
[ 241.354223] [<f8655000>] ? 0xf8654fff
[ 241.354316] [<f865505e>] i915_init+0x5e/0x60 [i915]
[ 241.354333] [<c1002122>] do_one_initcall+0xd2/0x190
[ 241.354352] [<c10e94f8>] ? tracepoint_module_notify+0x118/0x180
[ 241.354372] [<f8655000>] ? 0xf8654fff
[ 241.354389] [<c1049daf>] ? set_memory_nx+0x5f/0x70
[ 241.354411] [<c16393ee>] ? set_section_ro_nx+0x54/0x59
[ 241.354432] [<c10c210a>] load_module+0x111a/0x18e0
[ 241.354464] [<c10c2a35>] SyS_finit_module+0x75/0xc0
[ 241.354481] [<c11374cb>] ? vm_mmap_pgoff+0x7b/0xa0
[ 241.354513] [<c164b90d>] sysen...

[Chris Wilson (ickle)]

(In reply to comment #20)
> Today's mainline kernel (top commit 85ce70fdf48aa290b4845311c2dd815d7f8d1fa5)
>
> [ 241.352344] INFO: task systemd-udevd:381 blocked for more than 120
> seconds.
> [ 241.352420] Tainted: PF O 3.13.0-3-generic #18-Ubuntu
> [ 241.352474] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
> this message.
> [ 241.352532] systemd-udevd D f4fd7a24 0 381 270 0x00000004
> [ 241.352552] f4fd7a4c 00000086 c12f0573 f4fd7a24 c18294f8 c1a7c780
> 00000001 00000001
> [ 241.352582] c1a7c780 f5858000 f68a0d00 0003d1d6 00000000 f4fd7a1c
> f86e97df 1b762573
> [ 241.352608] f86e97e1 f86e97e1 f86ee998 f4fd7a60 c12f29dc 00000001
> 00000000 0000ff02
> [ 241.352635] Call Trace:
> [ 241.352663] [<c12f0573>] ? format_decode+0x323/0x390
> [ 241.352708] [<c12f29dc>] ? vsnprintf+0x2cc/0x3d0
> [ 241.352728] [<c12f0001>] ? put_dec_trunc8+0x61/0xa0
> [ 241.352750] [<c16415a3>] schedule_preempt_disabled+0x23/0x60
> [ 241.352766] [<c1642eed>] __mutex_lock_slowpath+0x10d/0x171
> [ 241.352782] [<c164241c>] mutex_lock+0x1c/0x28
> [ 241.352910] [<f8d93aa2>] intel_get_load_detect_pipe+0x152/0x3a0 [i915]
> [ 241.353059] [<f8dc3142>] ? gen4_read32+0x32/0xb0 [i915]
> [ 241.353075] [<c12f2b6a>] ? snprintf+0x1a/0x20
> [ 241.353195] [<f8d9516d>] intel_modeset_setup_hw_state+0xa7d/0xae0 [i915]
> [ 241.353273] [<f86cffd8>] ? drm_mode_config_reset+0x98/0xb0 [drm]
> [ 241.353392] [<f8d951fe>] intel_modeset_gem_init+0x2e/0x40 [i915]
> [ 241.353490] [<f8d5abfb>] i915_driver_load+0xb3b/0xdc0 [i915]
> [ 241.353586] [<f8d57e10>] ? i915_switcheroo_set_state+0xa0/0xa0 [i915]
> [ 241.353706] [<f86cbcab>] drm_dev_register+0x8b/0x1a0 [drm]
> [ 241.353768] [<f86cd78e>] drm_get_pci_dev+0x7e/0x120 [drm]
> [ 241.353797] [<c11d8e37>] ? sysfs_do_create_link_sd.isra.2+0xa7/0x1c0
> [ 241.353897] [<f8d575ea>] i915_pci_probe+0x3a/0x80 [i915]
> [ 241.353918] [<c132870f>] pci_device_probe+0x6f/0xc0
> [ 241.353934] [<c11d8f75>] ? sysfs_create_link+0x25/0x40
> [ 241.353956] [<c13faf65>] driver_probe_device+0x105/0x380
> [ 241.353972] [<c1328662>] ? pci_match_device+0xb2/0xc0
> [ 241.353992] [<c13fb291>] __driver_attach+0x71/0x80
> [ 241.354008] [<c13fb220>] ? __device_attach+0x40/0x40
> [ 241.354026] [<c13f93c7>] bus_for_each_dev+0x47/0x80
> [ 241.354043] [<c13fa9ce>] driver_attach+0x1e/0x20
> [ 241.354057] [<c13fb220>] ? __device_attach+0x40/0x40
> [ 241.354072] [<c13fa627>] bus_add_driver+0x157/0x230
> [ 241.354093] [<c13fb859>] driver_register+0x59/0xe0
> [ 241.354111] [<c10487a0>] ? __set_pmd_pte+0xa0/0xa0
> [ 241.354130] [<c1327142>] __pci_register_driver+0x32/0x40
> [ 241.354191] [<f86cd925>] drm_pci_init+0xf5/0x100 [drm]
> [ 241.354223] [<f8655000>] ? 0xf8654fff
> [ 241.354316] [<f865505e>] i915_init+0x5e/0x60 [i915]
> [ 241.354333] [<c1002122>] do_one_initcall+0xd2/0x190
> [ 241.354352] [<c10e94f8>] ? tracepoint_module_notify+0x118/0x180
> [ 241.354372] [<f8655000>] ? 0xf8654fff
> [ 241.354389] [<c1049daf>] ? set_memory_nx+0x5f/0x70
> [ 241.354411] [<c16393ee>] ? set_section_ro_nx+0x54/0x59
> [ 241.354432] [<c10c210a>] load_module+0x111a/0x18e0
> [ 241....

[Colin Ian King (colin-king)]

I tried today's drm-intel-nightly and all I get is a black screen, spinning CPU and I can't ssh in to see what's happening.

[Daniel-ffwll (daniel-ffwll)]

(In reply to comment #22)
> I tried today's drm-intel-nightly and all I get is a black screen,
> spinning CPU and I can't ssh in to see what's happening.

Ville went right away and created another regression in the load detect code ;-) Patch should get merged soon.

[Chris Wilson (ickle)]

(In reply to comment #19)
> Colin, will it possible to try with drm-intel-nightly (or latest mainline)
> to see if the state checker catches anything?
>
> Also it would be interesting to read an --enable-debug=full Xorg.0.log to
> see what happened to that uevent.

Time to retry. Hopefully.

[Chris Wilson (ickle)]

Colin can you please also attach your Xorg.0.log? I just want to check that it is setup to receive hotplug events - but having it available should help any future queries.

[Colin Ian King (colin-king)]

Created attachment 93360
tarball of dmesg output and Xorg.0.log

Attached is dmesg.log and Xorg.0.log tarball using today's drm-intel-nightly. S3 resume still results in a blank screen.

[Chris Wilson (ickle)]

For the record, X has hotplug (uevents) enabled.

[Jani-nikula (jani-nikula)]

Timeout, please re-test on current drm-intel-nightly.

[Daniel-ffwll (daniel-ffwll)]

Bug reporter seems to have disappeared, so closing. If this is still an issue please reopen.

[Peter Rimshnick (peter-rimshnick)]

I also recently experienced this bug, so not sure that it makes sense to close

[Peter Rimshnick (peter-rimshnick)]

I'm still experiencing this issue.

[Peteypabpro (peteypabpro)]

I'm still experiencing this issue. I'll be happy to do whatever is needed and provide any information that will help resolve it.

[Ander Conselvan de Oliveira (conselvan2)]

Can you confirm it still happens with the latest drm-intel-nightly?

Please provide dmesg with the kernel running with drm.debug=6 in its command line, and also you Xorg.0.log.

[Peteypabpro (peteypabpro)]

Created attachment 110965
New Xorg.0 and dmesg logs

Based on intel-drm-nightly, 12/16/14

[Peteypabpro (peteypabpro)]

Comment on attachment 93360
tarball of dmesg output and Xorg.0.log

With new intel-drm-nightly, blank screen / cpu spinning happens at boot. If I run in recovery mode I can get to the desktop, and then the same behavior occurs on suspend/resume. These logs reflect the first case.

[Ander Conselvan de Oliveira (conselvan2)]

(In reply to Peter Rimshnick from comment #33)
> Comment on attachment 93360 [details]
> tarball of dmesg output and Xorg.0.log

Did you set drm.debug=6 in the kernel command line? The dmesg output is missing debugging information.

[Peteypabpro (peteypabpro)]

(In reply to Ander Conselvan de Oliveira from comment #34)
> (In reply to Peter Rimshnick from comment #33)
> > Comment on attachment 93360 [details]
> > tarball of dmesg output and Xorg.0.log
>
> Did you set drm.debug=6 in the kernel command line? The dmesg output is
> missing debugging information.

I think I accidentally commented on the wrong attachment. My logs are attachment 110965. If you grep dmesg for "drm" you can see my command line. Please let me know if it is incorrect. Thanks!

[Ander Conselvan de Oliveira (conselvan2)]

Created attachment 111040
Fix warn on pipe disabled assertion

(In reply to Peter Rimshnick from comment #35)
> (In reply to Ander Conselvan de Oliveira from comment #34)
> > Did you set drm.debug=6 in the kernel command line? The dmesg output is
> > missing debugging information.
>
> I think I accidentally commented on the wrong attachment. My logs are
> attachment 110965 [details]. If you grep dmesg for "drm" you can see my
> command line. Please let me know if it is incorrect. Thanks!

Ah, I was looking at the wrong thing. Can you apply this patch and run it again. It probably won't fix the problem, but it moves the first reported error out of the way, so it might help with debugging the real issue.

[Peteypabpro (peteypabpro)]

Created attachment 111183
Dmesg and Xorg logs with new patch

I've attached output with new logs. Same result (black screen) as last time, but the dmesg does look slightly different.

[Peteypabpro (peteypabpro)]

Are the latest logs I posted helpful? Let me know if you think I messed up somehow or need any other info. Thanks.

[Jesse Barnes (jbarnes-virtuousgeek)]

Looks like a crash (on resume?), I'll take a look.

[Daniel-ffwll (daniel-ffwll)]

(In reply to Jesse Barnes from comment #39)
> Looks like a crash (on resume?), I'll take a look.

Yes this is the drm_mm fumble I think. It's fixed in latest kernels, so unfortunately you need to retest. Relevant patch

commit 046d669c62f37323ef0329c41d83a03c06b2087d
Author: Krzysztof Kolasa <email address hidden>
Date: Sun Mar 15 20:22:36 2015 +0100

    [PATCH] drm/mm: Fix support 4 GiB and larger ranges

[Peteypabpro (peteypabpro)]

Created attachment 114972
Logs using generic-4.0.0-994_4.0.0-994.201504072205

Using mainline kernel drm-intel-nightly--2015-04-09

[Peteypabpro (peteypabpro)]

(In reply to Peter Rimshnick from comment #41)
> Created attachment 114972 [details]
> Logs using generic-4.0.0-994_4.0.0-994.201504072205
>
> Using mainline kernel drm-intel-nightly--2015-04-09

Unfortunately, same as before - does not even boot into desktop, let alone resume from suspend. Let me know if I'm not using the right kernel. Thanks!

[Jani-nikula (jani-nikula)]

I don't think Jesse will be working on this anymore...

Have you tried more recent kernels?

[Peteypabpro (peteypabpro)]

Haven't tried more recent kernels.. Will try to get around to that soon.

[Colin Ian King (colin-king)]

tested HP Mini on Ubuntu Xenial and this works. Will not back port fixes as these are too intrusive for earlier releases.

[Jari-tahvanainen (jari-tahvanainen)]

Peter - could we close this bug or is this still valid?

[Peteypabpro (peteypabpro)]

(In reply to Jari Tahvanainen from comment #45)
> Peter - could we close this bug or is this still valid?

Hi Jari,

You can close. I can't confirm whether it's still valid since I no longer have that machine.

Best,
Peter