[hardy] keyboard modifiers randomly forgotten

Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately we can't fix it, because your description didn't include enough information. You may find it helpful to read "How to report bugs effectively" [WWW] http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful if you would then provide a more complete description of the problem.

We have instructions on debugging some types of problems. [WWW] http://wiki.ubuntu.com/DebuggingProcedures

At a minimum, we need:
1. the specific steps or actions you took that caused you to encounter the problem,
2. the behavior you expected, and
3. the behavior you actually encountered (in as much detail as possible).
Thanks!

Umm, ok.

1. I used GNOME. Sometimes it triggers when I reboot and log back in. Sometimes, I'm not doing anything in particular. Sometimes it'll do it a bit after I unlock the screen. Trigger is unknown. It just "forgets" sometimes.

2. The behavior I expected is for it not to forget my keyboard settings?

3. The behavior I actually encountered is that the keyboard settings were forgotten, as described above. See "symptoms".

If you tell me what to point a debugger at, I'll see what I find.

Starting point for verification may be swapping caps lock and control, and/or setting menu as compose key via the gnome capplets.

I've told you as much as I know right now; if you ask specific questions I can see what I can do about it.

This sounds like what I'm seeing on my Dell Inspiron 510m running Hardy. Sometimes (seemingly at random) the modifier keys stop working. Logging out and back in usually fixes it. The problem seems to be that I cannot hold a key, since keyboard repeat fails at the same time.

The problem was frequent on the Alpha 4 live cd and the fresh install, but it seems to have been less frequent lately, though this might just be random.

I had just completed writing up this thing, and then my 'alt' key got stuck and rendered me unable to post, or even save, my writeup.... grr.

I've also been having severe keyboard breakage under Hardy. Initially I used evdev for my keyboard, but then I started having the issue where, almost every single time I used a compiz [-fusion] feature bound to my 'super' key, the modifier would become stuck and render my desktop literally useless; I'd have to alt-sysrq-k to kill Xorg.

Once I changed back to using the kbd driver, the behavior changed: now I no longer get 'super' stuck down as often, but I have had keys either become stuck or just stop working. In addition, keyboard repeat will break at the same time.

When the keyboard breaks, modifer key behavior becomes very odd -- for example, I'll press ctrl-c-c-c in console without releasing the ctrl key, and I'll get c-c-<break> (break is ctrl-c, of course). In addition, I can press ctrl-alt-backspace in xev, and the window will receive the terminate_server keycode that Xorg itself should be intercepting.

One easy way to trigger the bug seems to be through scrolling: go to a long page such as this one, and repeatedly use (hold) pgup and pgdn to scroll around on a page. This will often result in the key becoming 'stuck'. In addition, I can sometimes un-trigger the bug in a similar way: hold the key while also scrolling with the mouse.
http://connect.creativelabs.com/linux/Lists/Driver Issues/AllItems.aspx

The oddest behavior I have seen with keyboard occured one time when 'ctrl' became stuck, and then I used alt-sysrq-r to ubreak the keyboard, and xkbcomp to reload my keymap. This placed Xorg in an odd state: most keyboard actions, such as ctrl-w in Firefox, worked fine; however, any mouse actions acted as if the ctrl key was still held down.

I'd like to suggest marking this bug as 'high' probability, because if you happen to get shift-super stuck down in xorg, it will become difficult, if not literally impossible, to save work before killing Xorg. In fact, even just the 'alt' key can break saving contents of forms such as these, since there will be no way to open anything to paste the text into.

I confirm major breakup, with similar symptoms
I'm using last hardy (upgrade from gutsy), and i sometimes experience the alt key non functionning, with repeating keys non working. This is quite strange, because emacs reports correctly the input (ie M-x works as expected). Control and shift work as expected though.
I also found that the keyboard layout customization options such as make caps lock an additional control do not work when rebooting, unless you go back to the menu. Even if i go back to the menu, when the customization works, caps lock still makes the DEL switch on and off, while in gutsy it did not. Using xmodmap works ok though.
I can reproduce the bug by holding down the key to invoke Yakuake.

Marking confirmed from the other comments on here. Again, if you want more information, we'll be glad to provide it, but you have to come back here and tell us what you need.

this is happening to me right now. i thought maybe it had to do with vmware, but i guess not.
ctrl and shift seem to do nothing.

it's impossible to switch to another vt which make this tough to fix.

is there some way to reset things without having to close your session/ that's supposed to be a question mark...

I just discovered switching the keyboard layout in system->preferences->layouts
from 105 to 104 and back resolves the problem!

i hope something is being done about this crippling bug
this is making hardy virtually unusable

i've tried reconfiguring xorg. modifying layout with the new keyboard applet.

I confirm this as a problem in Kubuntu Hardy Alpha 5 (fresh install) on my Inspiron 1420. Xev still says that I am hitting Alt but it does not do anything:

KeyPress event, serial 31, synthetic NO, window 0x2600001,
    root 0x68, subw 0x0, time 14157100, (164,-5), root:(167,615),
    state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

I get this on a Dell Inspiron 8600 with Hardy updated to 19th March. It happens frequently but I can't determine a single event that causes it - the last time it happened was after resume.

When it happens, the ALT, SHIFT, CTRL, and CAPS LOCK keys fail to work, as does key repeat.

Last time it happened, I tried xev and it was behaving strangely: it was constantly receiving events even when I was not typing, instead of the normal 'keypress event' followed by 'key release event'. I could see the key events were being recognised as I typed them but the info scrolled quickly off the screen because of the constant flow of events.

Some minutes afterwards and with no discernible cause, the ENTIRE keyboard stopped working. At this point, menus no longer worked (eg in gnome-panel) and when I tried running update manager via the notification icon (one of the few things I could run from gnome-panel) and went to do a check, gksu reported that it could not grab the keyboard.

I'm having the same problem with a fresh install of Kubuntu Hardy Beta (released on march 20).

I made a fresh install on a Dell XPS m1210. One of the first things I tried (maybe is what spoiled things up as someone mentioned it) was trying to use desktop effect (compiz and installed compizconfig-setting-manager) and played with it for a while until I uninstalled and went back to the more reliable and customizable kwin.

The first problem I notice was that afterwards I could set a shortcut using Win (Super)... I pressed Win+X and it received only X. And afterwards all kind of keyboard problems: Not able to use other modifiers (for Alt+F2 for example).

And also noticed the problem with not being able to repeat keys, even though changing the repeat key settings.

I imagine that before the compiz try I didn't have this issues since they are so annoying, that I believe I would notice them before. The problem is that they persist even after removing (purging) every compiz package...

Best regards,
Mguel

I am experiencing this problem with a Hardy Heron Beta install as well. Esp. while playing a 3D MMORPG (regnum online) the keyboard locks up after a few minutes running this game (reproducibly on two systems, one a new install another a upgrade).

Symptom is always, that one key stays pressed. The system becomes unusable by this. The basic configuration of both system is:
- server variant kernel
- gnome
- compiz

All worked fine under Gutsy using an similar configuration...

New information, a bit:

- removing all SCIM packages eases the problem, keyboard hangs not after a few minutes, but after half an hour
- using openbox/fluxbox seems to remove the problem at all, even when using gdm and running gtk apps (firefox and gajim)

I upgraded Kubuntu from gutsy to hardy alpha 5 and later on I installed a fresh Kubuntu beta 6 and I had the same problem. So I dont think it is gnome related ...

normally, xev only logs key press events when you actually press a key. but when the modifiers stop working it sees a continuous stream of key press/key release events.

following is a sample key press/key release/key press sequence from xev when the modifier keys stop working.

KeyPress event, serial 32, synthetic NO, window 0x3a00001,
    root 0x5a, subw 0x0, time 28763460, (171,-12), root:(1529,853),
    state 0x0, keycode 101 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 32, synthetic NO, window 0x3a00001,
    root 0x5a, subw 0x0, time 28763494, (171,-12), root:(1529,853),
    state 0x100, keycode 101 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 32, synthetic NO, window 0x3a00001,
    root 0x5a, subw 0x0, time 28763494, (171,-12), root:(1529,853),
    state 0x100, keycode 101 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

you can see that the second keypress event shown has the same timestamp as the previous keyrelease event. this is the same for all the ones i looked at.

so perhaps this phantom key press/release could be preventing key modifiers from working properly, eg you press shift, but then this phantom keypress occurs before you get a chance to press the i key, so the shift is cancelled and the i comes out lowercase.

I reproduced this bug (once only) by doing the following:

1. I ran xev.

2. I did the key combination for 'brightness down'. The brightness dimmed but xev reported a continuous series of 101 key press / release events. This keycode 101 is listed at https://wiki.ubuntu.com/KubuntuLaptopKeycodes as being the brightness down key for some Dell laptops like mine.

3. I did the key combination for 'brightness up'. The brightness increased and xev reported a single key press / release combination for key code 212. The stream of 101 keycodes stopped.

After step 3, the key modifiers all work.

However, I haven't been able to make it happen again. Brightness down normally generates no key events as far as xev is concerned (although the brightness does dim) and brightness up generates a single press / release sequence for keycode 212.

So might the bug be related to the brightness controls? Note bug 188775, where X changes the screen brightness at random intervals for some users. I haven't noticed that bug on my system for a while now, but X now also rarely forgets key modifiers - it seems to happen after resume or in the 'brightness down' sequence in step 2 above.

I too have seen this bug. I recently upgraded (GUI) from gutsy to hardy.

I thought that losing the modifier keys had something to do with vmware but I might be wrong. It seems to trigger when I leave a VM and go back into the host os. (but this might be random, as other commenters have thought)

I have found two workarounds. The first one is to save all of my work and log out, then log back in. This fixes the problem for me temporarily. The other workaround is to go to the keyboard settings and change the keyboard layout, this will fix the issue (not sure if it is temporary yet)

Also, when this bug is triggered, I find it hard to open applications (terminal is a good example), which will hang and then crash.

Another odd behaviour is that the control keys work inside the vmware guests, so the keyboard events are still happening properly, its just that hardy gets broken.

For those of you having trouble saving your work, do not forget the mouse methods for cut/paste and that selecting text usually puts it in the copy/paste buffer.

By coincidence I had a VMWare VM open today when it happened again and I can confirm what Matt said, ie:

- The keyboard worked perfectly in the VM, including the modifiers like shift, etc

- Newly-opened applications were crashing, eg I opened gedit to store the output of xev, and gedit crashed; then apport detected that gedit crashed, but then apport crashed while trying to report that gedit crashed.

This and the previous time this bug occurred occurred, I wasn't getting a series of 'brightness down' events reported in xev - it only registered keyboard events when I actually pressed/released a key.

Since the VM isn't affected by the bug, perhaps this isn't a keyboard driver bug at all? Perhaps Gnome is not passing the events on correctly?

I'd say this bug is critical because:

- it's a bug in a fundamental function of the OS (ie I/O)

- it can cause data loss

- the computer becomes unusable (you have to log out to fix the problem)

- if it's happening regularly in the beta for some people, it's likely to affect many users in the released version, which would be terrible publicity for Ubuntu;

Does anybody have suggestions for what to do to try and debug this next time it happens?

xev shows an incorrect state variable when this bug occurs - it is set to zero.

From what I can see, it seems that the state normally should be set to 0x2000 and OR'd with 1,2,4,8 for each of the modifiers, ie:

0x2000 - no modifiers
0x2001 - shift key
0x2002 - caps lock key
0x2004 - control key
0x2008 - alt key

Devon's post shows the same state=0x0 problem as mine.

The last time I recreated this was when I alt-tabbed between Firefox and gnome-terminal and back. I then tried xev again and saw that the event being generated for the key sequence shift-V is a lower-case v instead of the expected upper-case V:

KeyPress event, serial 28, synthetic NO, window 0x4400001,
    root 0x5a, subw 0x0, time 17124192, (1294,2), root:(1301,867),
    state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 31, synthetic NO, window 0x4400001,
    root 0x5a, subw 0x0, time 17125412, (1294,2), root:(1301,867),
    state 0x0, keycode 55 (keysym 0x76, v), same_screen YES,
    XLookupString gives 1 bytes: (76) "v"
    XmbLookupString gives 1 bytes: (76) "v"
    XFilterEvent returns: False

KeyRelease event, serial 31, synthetic NO, window 0x4400001,
    root 0x5a, subw 0x0, time 17125640, (1294,2), root:(1301,867),
    state 0x0, keycode 55 (keysym 0x76, v), same_screen YES,
    XLookupString gives 1 bytes: (76) "v"
    XFilterEvent returns: False

KeyRelease event, serial 31, synthetic NO, window 0x4400001,
    root 0x5a, subw 0x0, time 17126506, (1294,2), root:(1301,867),
    state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

This is the expected sequence where an upper-case V is generated:

KeyPress event, serial 28, synthetic NO, window 0x1200001,
    root 0x5a, subw 0x0, time 17686510, (1197,-43), root:(1204,822),
    state 0x2000, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 31, synthetic NO, window 0x1200001,
    root 0x5a, subw 0x0, time 17687106, (1197,-43), root:(1204,822),
    state 0x2001, keycode 55 (keysym 0x56, V), same_screen YES,
    XLookupString gives 1 bytes: (56) "V"
    XmbLookupString gives 1 bytes: (56) "V"
    XFilterEvent returns: False

KeyRelease event, serial 31, synthetic NO, window 0x1200001,
    root 0x5a, subw 0x0, time 17687220, (1197,-43), root:(1204,822),
    state 0x2001, keycode 55 (keysym 0x56, V), same_screen YES,
    XLookupString gives 1 bytes: (56) "V"
    XFilterEvent returns: False

KeyRelease event, serial 31, synthetic NO, window 0x1200001,
    root 0x5a, subw 0x0, time 17688138, (1197,-43), root:(1204,822),
    state 0x2001, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

Is anyone seeing this bug who is *not* using VMWare?

The original bug report that everyone is following up to is about random breakage of the modifiers, even on a logout and login, that's fixable by removing .gconf/desktop/gnome/peripherals/keyboard. This is completely unrelated to the VMWare problem. Could someone please open a new bug report for the VMWare, cross-desktop issue?

So after I reset the keyboard configuration in the keyboard preferences I have not seen this bug in several days.

I am guessing that the vmware users (of which I am one) are also suffering the same bug as everyone else, we just happen to mention it because of the odd differences between the behaviour inside and outside of the vm.

(Also, there might be a correlation between people who use vmware, and people who upgraded to the hardy beta, who knows?)

On Thu, Apr 10, 2008 at 08:04:53PM -0000, Matt Fedderly wrote:

> I am guessing that the vmware users (of which I am one) are also
> suffering the same bug as everyone else, we just happen to mention it
> because of the odd differences between the behaviour inside and outside
> of the vm.

No, there is a long-standing bug that involves VMWare directly eating the
modifier keys; and then there is the bug originally reported, which has
something to do with gconf settings and I'm sure is unrelated to the VMWare
problem.

> (Also, there might be a correlation between people who use vmware, and
> people who upgraded to the hardy beta, who knows?)

I've been running hardy since well before beta, and I don't see this problem
on my systems that don't run VMWare. :)

On Thu, 2008-04-10 at 19:37 +0000, Steve Langasek wrote:
> The original bug report that everyone is following up to is about random
> breakage of the modifiers, even on a logout and login, that's fixable by
> removing .gconf/desktop/gnome/peripherals/keyboard. This is completely
> unrelated to the VMWare problem. Could someone please open a new bug
> report for the VMWare, cross-desktop issue?

It's not clear to me whether vmware is part of the problem...

I've seen in with and without vmware running.

I can't say whether it's two bugs or one.

brad

I just posted this on the Ubuntu forums....

"I don't think that its Compiz, I get it in Firefox as well. This is an issue that I have seen reported a few times. I have tried many workarounds but still the issue continues. I think at this point the only option would be wait and see what happens with the bugs that have been reported. I do know that some people suggested that this was a VMware issue, but that is not the case I get it both on my install and my VMware.

If you would like to see the Firefox issue, at lest how I get the bug, just take a long blank HTML page and scroll down with the mouse wheel. At times the mouse will seem to not respond then "kick" back in. In WoW I get it when I move my toon with both "W" and "D" pressed, once I let go the toon gets locked into a endless circle until I press "W" and "D" again.

And Speaking of Compiz, if I set rain to toggle on "shift" + F9 it may or may not activate (Most of the time not)."

Can anybody confirm the bug on Kubuntu?

I am not using Kubuntu, but I will add this. I did another install of gutsy and then upgraded to hardy (How I have done it before, you seem to find more bugs that way.) and didn't see this issue again.

I can confirm this bug. I too thought it was linked to vmware, since it happens only while using a virtual machine.

I can also confirm this... Using VMware as well.

When it happens, going to System -> Preferences -> Keyboard -> Layouts tab and changing the keyboard model seems to fix it partially, however Alt+Tab is still broken.

I also can confirm this bug, it happens only using vmware...
Also when i want to type in any other applicattion outside vmware the program who receives the keyboard event crashes by a segfault..
dmesg show me this:
[ 9705.276747] metacity[12965]: segfault at 00000017 eip b7b3c275 esp bfc6f230 error 4
[ 9706.186578] metacity[13578]: segfault at 00000017 eip b7bdc275 esp bfe3a1d0 error 4
[ 9706.535459] VFS: busy inodes on changed media.
[ 9706.752551] metacity[13579]: segfault at 00000017 eip b7c16275 esp bfd1b8b0 error 4
[ 9706.811222] VFS: busy inodes on changed media.
[ 9707.311504] metacity[13580]: segfault at 00000017 eip b7b94275 esp bfc89020 error 4
[ 9707.449526] nautilus[13384]: segfault at 00000017 eip b77be275 esp bfe35a10 error 4
[ 9716.783931] VFS: busy inodes on changed media.
[ 9718.521534] VFS: busy inodes on changed media.
[ 9718.743659] nautilus[13582]: segfault at 00000040 eip b783f275 esp bf8a7480 error 4
[ 9718.796341] VFS: busy inodes on changed media.
[ 9719.043490] metacity[13581]: segfault at 00000017 eip b7b3e275 esp bfac7e60 error 4
[ 9720.508087] VFS: busy inodes on changed media.
[ 9720.783115] VFS: busy inodes on changed media.
[ 9730.236897] gnome-terminal[13602]: segfault at 00000026 eip b78fa275 esp bfb5c8e0 error 4
[ 9730.505680] VFS: busy inodes on changed media.
[ 9736.813553] VFS: busy inodes on changed media.
[ 9737.531916] gnome-panel[12967]: segfault at 00000024 eip b7910275 esp bfb984e0 error 4

I think this is a duplicate of bug 124406, but if not, I'm confirming it on a fresh install of kubuntu hardy. Both problems occur here - sometimes sticky keys shut themselves off and sometimes, repeat keys occur at a burst of speed.

I can confirm you this is happening in my Ubuntu Hardy fresh install and it is gone when selecting layout Keyboard Model Generic 104-Key PC instead of 105.

I get the same exact problem, losing my modifiers. I am using Ubuntu and this bug happens randomly when I am using VMWare. I found a fast way to recover from this bug by creating a keymap that I can load with xmodmap from a menu.

I too have this problem. Bertrand, would you mind giving detailed
instructions on your quick fix? I've been using the keyboard layout
gui and it's annoying to have to do it so often. I'm not familiar
with xmodmap, so any help would be appreciated.

-Jay

On Tue, May 6, 2008 at 7:03 AM, Bertrand Janin <email address hidden> wrote:
> I get the same exact problem, losing my modifiers. I am using Ubuntu and
> this bug happens randomly when I am using VMWare. I found a fast way to
> recover from this bug by creating a keymap that I can load with xmodmap
> from a menu.
>
>
>
> --
> [hardy] keyboard modifiers randomly forgotten
> https://bugs.launchpad.net/bugs/190934
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I too confirm this problem on Hardy 8.04 with all updates as of today.

I am using vmware server 1 (running Windows XP in it). Within vmware, everything is fine.

My guess is that this bug is somehow vmware related, but it also has to do with Ubuntu 8.04 or its components (X, Gnome, Compiz?). I used vmware ratherly intensive in all previous Ubuntu versions and never had similar problems. Even though vmware certainly is no supported part of Ubuntu, I consider this bug -- whereever it is -- serious.

PS: The fastest way I found to get temporarily rid of this annoyance is the switch user function. Switch to another random user, switch back. This seems to reset the X/Gnome/whatever keyboard settings.

:( Happening also with Keyboard Model Generic 104-Key PC. Only changing keyboard and then changing it back from System - Preferences - Keyboard works

PPS: switch user does not help always :-(
changing the keyboard layout seems the only reliable way to get out of this

I wrote a short perl script to automate switching the keyboard layout and posted it here: http://rymerheason.blogspot.com/2008/05/vmware-keyboard-annoyances-on-ubuntu.html

Adding a keyboard layout seems to fix it as well as changing the layout. (ie just add and remove a random keyboard layout to fix it).

I find that often when the modifiers are lost, some applications (gedit, gnome-keyboard-properties are two examples) will segfault when you try to type a key.

I can confirm it. Despite my keyboard settings are set in the xorg.conf, sometimes after a login they all are screwed. An unsetting/setting the checkbox in the modifier switcher options helps for a whole session, but gets lost after the next login.

See also bug 195982

I solve this problem partly.

Edit -> Preferences -> Input -> Keyboard and Mouse

uncheck -> Grab keyboard ... on mouse click
check -> Grab keyboard ... on key press

If you don't in focus VM, you can press ctrl-alt-enter for full screen without problem.

Kubuntu 8.04, linux-rt, nvidia-glx, vmware-server 1.05.

Same thing, except any and all key presses on any X window causes the window to segfault.

Ubuntu 8.0.4 and vmware-server 1.0.6 on a thinkpad T41.

Adding a new keyboard layout and deleting the old one fixes the issue temporarily.

Well, it looks like there are two bugs here. The original was not related to VMWare, but it looks like VMWare people have kind of taken this one over.

FWIW I see issues with the compose key setting similar to what was originally described here, but also similar to what is in bug #222653. I have to re-set my compose key regularly because it stops acting like a compose key.

I have this bug - WITHOUT vmware. It shows up randomly. In fact, while trying to reproduce it, I logged out; logged in again - to my surprise, the compose_key is working. I call a colleague to show it and... it just stopped working!

Will try to figure out the xev results shortly. If only this bug will show up, that is ;-)

Giuseppe Verde, could you please confirm this issue exists with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ . If the issue remains, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.11-rc5

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

If you are unable to test the mainline kernel, please comment as to why specifically you were unable to test it and add the following tags:
kernel-unable-to-test-upstream
kernel-unable-to-test-upstream-VERSION-NUMBER

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

Closing this bug with Won't fix as Hardy is no longer supported.
Please feel free to open a new bug report if you're still experiencing this on a newer release (Bionic 18.04.3 / Disco 19.04)
Thanks!