r852 & r592 IRQ: DMA errors cause log files to grow *HUGE*

[Laurent Martin-Borret]

Hi,
I have many crash messages related to r852 & r592 modules in my syslog files.
I had already submitted a bug report for that ( https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1500156 ) but since that time, I upgraded to 15.10. The issue is still there, but displayed a bit differently (stack trace now).
This issue slows down the machine and can also lead to a disk full in /var/log I guess. My current syslog is about 4GB large and is 1 day old.

Typical messages I get :
[104370.032867] r592: IRQ: card added
[104370.032873] r592: IRQ: DMA error

I've read some posts/other bug reports related to the same issue :

http://lists.opensuse.org/opensuse-bugs/2014-08/msg01076.html

https://bugzilla.redhat.com/show_bug.cgi?id=1119361

https://forum.ubuntu-fr.org/viewtopic.php?id=1907131&p=1

https://bugzilla.novell.com/show_bug.cgi?id=892249

I would be glad if some solution is proposed to stop filling these logs !

Cheers,

Laurent

ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: linux-image-4.2.0-22-generic 4.2.0-22.27
ProcVersionSignature: Ubuntu 4.2.0-22.27-generic 4.2.6
Uname: Linux 4.2.0-22-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.19.1-0ubuntu5
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: lmartinb 1743 F.... pulseaudio
CurrentDesktop: Unity
Date: Wed Dec 30 18:42:04 2015
HibernationDevice: RESUME=UUID=6512e903-d5d3-4c2e-90b4-45ed0610fcd5
InstallationDate: Installed on 2014-07-29 (519 days ago)
InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2)
MachineType: ASUSTeK Computer Inc. M50Vc
ProcFB:

ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.2.0-22-generic root=UUID=c05406a2-6b6b-4c79-aa26-51af9aa16cb1 ro quiet splash
RelatedPackageVersions:
 linux-restricted-modules-4.2.0-22-generic N/A
 linux-backports-modules-4.2.0-22-generic N/A
 linux-firmware 1.149.3
SourcePackage: linux
UpgradeStatus: Upgraded to wily on 2015-12-21 (8 days ago)
dmi.bios.date: 10/14/2009
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 212
dmi.board.asset.tag: ATN12345678901234567
dmi.board.name: M50Vc
dmi.board.vendor: ASUSTeK Computer Inc.
dmi.board.version: 1.0
dmi.chassis.asset.tag: ATN12345678901234567
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK Computer Inc.
dmi.chassis.version: 1.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr212:bd10/14/2009:svnASUSTeKComputerInc.:pnM50Vc:pvr1.0:rvnASUSTeKComputerInc.:rnM50Vc:rvr1.0:cvnASUSTeKComputerInc.:ct10:cvr1.0:
dmi.product.name: M50Vc
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK Computer Inc.

[gldickens3 (gordon-dickens)]

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0

I am seeing this problem on OpenSUSE with kernel-desktop versions 3.15.6 (stable repo) and 3.16.0 (HEAD repo).

The log files on my laptop, /var/log/messages and /var/log/warn, will grow HUGE with the following repeated over and over along with some extraneous related log entries:

2014-08-15T12:18:41.396981-04:00 localhost kernel: [17310.691176] r592: IRQ: card added
2014-08-15T12:18:41.396983-04:00 localhost kernel: [17310.691178] r592: IRQ: DMA error
.
<snip>
.
2014-08-15T12:18:41.397001-04:00 localhost kernel: [17311.223846] r592: IRQ: card added
2014-08-15T12:18:41.397004-04:00 localhost kernel: [17311.223847] r592: IRQ: DMA error

On any given day, there will be tens of thousands of these entries such that /var/log/messages and /var/log/warn will both exceed 3GB within a day (over 6GB total).

I believe that this bug is generated due to the presence of a Ricoh R5C592 Memory Stick Adapter on my laptop and which has never been properly recognized by the stock linux kernels. Apparently, the kernel developers keep trying to make it work but have now introduced a "bigger" problem so to speak since it is now causing all these extraneous error messages to be generated in the logs.

I am seeing this bug on OpenSUSE with kernel-desktop versions 3.15.6 and 3.16.0. This bug does not appear to be present in the OpenSUSE stock 3.11.6 and 3.11.10 kernels. I have since reverted back to the earlier kernels that don't have this problem.

This bug has also been reported at Red Hat's bugzilla at:

https://bugzilla.redhat.com/show_bug.cgi?id=1119361

IMHO, this bug needs to be fixed prior to the release of OpenSUSE 13.2.

FYI,

Gordon

Reproducible: Always

Steps to Reproduce:
1. Boot
2. Wait a while. It sometimes takes an hour or two for the log errors to begin at top volume.
Actual Results:
Logs grow *HUGE* with r592IRQ: DMA errors and related entries.

Expected Results:
Logger should not produce error messages of this magnitude and size.

[Tiwai-r (tiwai-r)]

Since it's endless irq wakeups, here is a blind shot: could you check whether the patch below works?

[Tiwai-r (tiwai-r)]

Created attachment 603338
Test patch

[gldickens3 (gordon-dickens)]

I am not a kernel developer and so I'm not sure how to build r592.c with the patch, however, I would be happy to test it if somebody else would build it for me. Alternatively, if its simple to do, then please provide some instructions and I will attempt to build it.

Also, the following is from a post at:

https://forums.opensuse.org/showthread.php/494706-openSUSE-13-1-KDE-inconsistant-resume-from-Suspend-to-RAM?p=2661131#post2661131

Quoting Romanator: "The most recent openSUSE kernel (3.11.10-21-desktop) Makefile for the r592.c from Maxim Levitsky is from 2010. His final patch wasn't submitted until Jan. 8, 2011. <snip> Ask the openSUSE kernel devs to look at and backport patch #5b945a6 from this link: https://gitorious.org/ricoh-kernel/ricoh-kernel.git ".

So, it doesn't look like the OpenSUSE kernel has the most recent r592 driver...

Also, there is a good bit of recent activity by the r592 developer, Maxim Levitsky, on this exact same bug at Red Hat's Bugzilla site here:

https://bugzilla.redhat.com/show_bug.cgi?id=1119361

The bottom line is that someone needs to make sure that OpenSUSE is using the most recent version of r592.c.

FYI,

Gordon

[gldickens3 (gordon-dickens)]

The ricoh-kernel project is maintained here:

https://gitorious.org/ricoh-kernel/ricoh-kernel/source/33138f5085346e1000bcab7ef83e2c88a200b6ec:

Also, there is a more recent (March 31, 2011) r592.c patch here:

https://gitorious.org/ricoh-kernel/ricoh-kernel/commit/33138f5085346e1000bcab7ef83e2c88a200b6ec

FYI,

Gordon

[Tiwai-r (tiwai-r)]

(In reply to comment #3)
> I am not a kernel developer and so I'm not sure how to build r592.c with the
> patch, however, I would be happy to test it if somebody else would build it for
> me. Alternatively, if its simple to do, then please provide some instructions
> and I will attempt to build it.

Yes, you should learn how to build a kernel and a patched module. There are a few good ways. I'll give some brief instructions later.

> Also, the following is from a post at:
>
> https://forums.opensuse.org/showthread.php/494706-openSUSE-13-1-KDE-inconsistant-resume-from-Suspend-to-RAM?p=2661131#post2661131
>
> Quoting Romanator: "The most recent openSUSE kernel (3.11.10-21-desktop)
> Makefile for the r592.c from Maxim Levitsky is from 2010. His final patch
> wasn't submitted until Jan. 8, 2011. <snip> Ask the openSUSE kernel devs to
> look at and backport patch #5b945a6 from this link:
> https://gitorious.org/ricoh-kernel/ricoh-kernel.git ".
>
> So, it doesn't look like the OpenSUSE kernel has the most recent r592 driver...

You're testing 3.15 and 3.16, so the above statement doesn't fit at all.

> Also, there is a good bit of recent activity by the r592 developer, Maxim
> Levitsky, on this exact same bug at Red Hat's Bugzilla site here:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1119361
>
> The bottom line is that someone needs to make sure that OpenSUSE is using the
> most recent version of r592.c.

No, r592 developer has to submit the fix to the upstream at first. This is the golden rule. In general, we take *only* the upstream fix (or the patch that is promised to upstream) to openSUSE kernels.

If there is a problem of upstreaming, put me in Cc in chain, so that I can assist for it.

[Tiwai-r (tiwai-r)]

(In reply to comment #5)
> (In reply to comment #3)
> > I am not a kernel developer and so I'm not sure how to build r592.c with the
> > patch, however, I would be happy to test it if somebody else would build it for
> > me. Alternatively, if its simple to do, then please provide some instructions
> > and I will attempt to build it.
>
> Yes, you should learn how to build a kernel and a patched module. There are a
> few good ways. I'll give some brief instructions later.

A quick way to rebuild a module is like below:

1. Install kernel-source and kernel-desktop-devel packages.

2. Copy the relevant driver code to the local directory. Suppose you'll work on a directory /somewhere/test to compile the module:
   % mkdir /somewhere/test
   % cp -a /usr/src/linux/drivers/memstick/host /somewhere/test

3. Patch the code. In this case, pass -p4 to strip the paths:
   % cd /somewhere/test
   % patch -p4 < /yetsomewhere/r592.patch

4. Build the module. This is the tricky part. Pass -C option to make.
   % make -C /usr/src/linux-obj/x86_64/desktop M=$(pwd) modules

5. If successful built, install it to the updates directory. Do this as root.
   % su
   ....
   # mkdir -p /lib/modules/$(uname -r)/updates
   # cp *.ko /lib/modules/$(uname -r)/updates
   # depmod -a

6. Confirm that the module will be loaded from the new path. The command below should give the path with "updates" path:
   % /usr/sbin/modinfo r592 | grep filename
   filename: /lib/modules/..../updates/r592.ko

7. Retest. If anything goes wrong, just remove the updated modules from /lib/modules/*/updates/* directory.

Since this rebuilds only a few modules, it won't take time at all, at most 5 minutes or so.

[gldickens3 (gordon-dickens)]

I have found a resolution to this problem as is described in the Red Hat bug report here:

https://bugzilla.redhat.com/show_bug.cgi?id=1119361

That is, set the following parameter in the kernel config file /boot/<kernel version>:

CONFIG_MMC_RICOH_MMC=n

On my recently upgraded OpenSUSE 13.2 machine, the kernel was 3.16.6-2-desktop so the file that I modified was /boot/config-3.16.6-2-desktop.

The log messages will then subside completely. Otherwise, if you have the ricoh r592 card reader then your logs will grow exponentially. For example, after I upgraded to OpenSUSE 13.2 two days ago, /var/log/journal had grown to over 5GB in less than 48 hours.

The problem is the default setting should be CONFIG_MMC_RICOH_MMC=n instead of CONFIG_MMC_RICOH_MMC=y. So, the kernel developers need to change this parameter for all OpenSUSE versions.

FYI,

Gordon

[Tiwai-r (tiwai-r)]

Thanks, that's a good information.

Though, CONFIG_MMC_RICOH_MMC was also y in the old working kernel, so disabling this is no real solution unless confirmed to *all* Ricoh MMC chips.

If the Kconfig matters, the bug must be in drivers/pci/quirks.c, and indeed there were a few changes regarding Ricoh MMC device there between 3.15 and 3.16 kernels.

Could you give hwinfo output of your machine? I particularly need the PCI IDs, but it's better to have all hwinfo in anyway.

[Tiwai-r (tiwai-r)]

Also, could you check whether the problem still exists with the recent kernels, 3.17.x and 3.18-rc? They are available in OBS Kernel:stable and Kernel:HEAD repos. We need to know this before reporting to the upstream.

[gldickens3 (gordon-dickens)]

I set CONFIG_MMC_RICOH_MMC=n since that was recommended by the maintainer of the device driver, Maxim Levitsky in the RedHat bug report that I previously referenced. Nevertheless, I apparently spoke to soon. Sorry! My PC was stable with minimal log entries for an hour or two last night. Then, today it started generating huge logs again even with CONFIG_MMC_RICOH_MMC=n. So, as a test, I blacklisted r592 in /etc/modprobe.d/50-blacklist.conf. Its been 5 hours since then without any excessive logging. Interestingly, the SD card reader works properly too even after I black listed r592. So, blacklisting r592 (with CONFIG_MMC_RICOH_MMC=n) has stopped the excessive logging and the SD card still works. I have attached the results of the lspci and hwinfo commands. As you can see, there are actually four RICOH devices listed. I hope that this helps.

Also, I am running nVidia proprietary drivers which I would have to recompile in order to try out the other more recent kernels so installing these kernels (and reverting back to stock) will be a bit more time consuming than otherwise. Nevertheless, if you still want me to test these newer kernels, I will do so within the next week or so.

Thanks very much for your assistance!

Gordon

[gldickens3 (gordon-dickens)]

Created attachment 614989
Results of hwinfo command

[gldickens3 (gordon-dickens)]

Created attachment 614990
Results of lspci command.

[Tiwai-r (tiwai-r)]

You may try a kernel package in OBS home:tiwai:bnc892249 repo. This should be compatible with openSUSE 13.2 (so Nvidia kmp should work as is) and yet includes a possible fix patch.

[gldickens3 (gordon-dickens)]

The massive logging started up again after about 7 hours.... Ugh...

Thanks for your repo for me to try! Its installed:

gordon@rhino:~> uname -a
Linux rhino 3.16.7-1.g632515b-desktop #1 SMP PREEMPT Tue Nov 25 07:11:35 UTC 2014 (632515b) x86_64 x86_64 x86_64 GNU/Linux

Lets see how it goes for a day or so.

Thanks again for your efforts!

Gordon

[gldickens3 (gordon-dickens)]

Created attachment 615124
12 second shapshot of the kernel log output.

[gldickens3 (gordon-dickens)]

Well, your kernel-desktop version 3.16.7-1.g632515b-desktop did not help. Like before, after installing your new kernel, everything was fine through a few hours or operation and 3 to 4 suspends/resumes. Then, following the most recent resume from suspend, the massive logging started back up again. I have attached a 12 second snippet of the log output that I hope helps you figure this out.

To review what is happening, everything is fine for a few hours of operation. Then the kernel logger goes crazy with huge massive logging. I believe that the massive logging has always begun following a resume from suspend, however, I cannot say that with 100% certainty. Then, following a reboot, everything is fine again for a little while.

Please review the attached log and reply with your advice. This is an unmanageable situation. If it cannot be fixed soon then I need to revert back to an earlier kernel version and, if necessary, an earlier OS version such as OpenSUSE 13.1.

As another test, I am going to blacklist r852 since it has been showing up in these logs too.

Thanks again for your help.

Gordon

[Tiwai-r (tiwai-r)]

OK, then maybe it isn't a regression that was introduced in 3.16 but did exist in the former versions, too.

Just to confirm: does the card reader work even without r592 module at all? I saw you blacklisted, but it isn't loaded at all when using the card reader?

[gldickens3 (gordon-dickens)]

I have recently run kernels 3.11, 3.15, 3.16. The problem did not exist with kernel 3.11 and I first saw issues in kernels 3.15 and 3.16. I did not test kernels 3.12, 3.13 or 3.14. So the problem started between kernel 3.12 and 3.15.

Yes, the card reader works without the r592 module. I have now blacklisted both r592 and r852 and there are no mention of either in the kernel logs at startup or when I plug the card in. Also, the hwinfo command indicates that both modules are not active even when the card is inserted during which I am able to browse the card.

I am adding another hwinfo output file with r592 and r852 blacklisted. This file was generated with the SD card inserted and working. The hwinfo output says that both R592 and r852 are not active. However, there are two other Ricoh devices:

Device 32: PCI 301.0: 0c00 FireWire (IEEE 1394) (OHCI)
Model: Model: "Ricoh R5C832 IEEE 1394 Controller"
Driver: "firewire_ohci"

Device 33: PCI 301.1: 0805 SD Host controller
Model: "Ricoh R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter"
Driver: "sdhci-pci"

So, should I also blacklist both firewire_ohci and sdhci-pci?

Thanks,

Gordon

PS: As an FYI, I am now running OpenSUSE 13.2. Previous to three days ago, I was runing OpenSUSE 13.1. I don't know if it matters but I thought that I should mention this.

[gldickens3 (gordon-dickens)]

Created attachment 615145
Results of hwinfo command with both r592 and r852 blacklisted and the SD card inserted.

[Tiwai-r (tiwai-r)]

Ah, I have looked somehow at the wrong places.

Yes, you can keep using the SD-card, etc, without r592 and r852 modules. r592 module is only for the legacy memory stick device, and r852 is for xD. Unless you need these rare media, you can safely blacklist them.

Did you have to blacklist both modules, not only one of them? I wonder now whether disabling DMA in r592 and r852 modules make things calm down. Put the following in /etc/modprobe.d/*.conf:

  options r592 enable_dma=0
  options r852 r852_enable_dma=0

[gldickens3 (gordon-dickens)]

Yes, yesterday, I blacklisted both the r592 and r852 modules and its now been almost 24 hours without encountering the excessive logging problem. I am going to watch and wait before I disable DMA for the two modules. I want to see if blacklisting both RICOH devices solves the problem by itself. However, if/when the excessive logging next occurs then I will immediately disable DMA to see if that helps.

Thanks again for your support. Let me know if you have any other recommendations. I will report back with my findings.

Gordon

[gldickens3 (gordon-dickens)]

Hi Takashi,

I believe that we have achieved success! Blacklisting both the r592 and r852 modules appears to have fixed the problem. I have now been running your 3.16.7-1.g632515b-desktop kernel for 3 days with these two modules blacklisted and I have not seen any unusual or excessive logging at all. With this configuration, everything seems to be back to normal. As an FYI, I have not disabled DMA for the r592 and r852 modules; only blacklisted them.

I noticed that you posted an updated kernel on November 27 which I did install. Did that update contain anything special or significant regarding this problem?

Also, do you recommend that I stay on your kernel/repo or should I revert back to the stock kernel at some point?

Please advise.

Thank you very much for your help and assistance.

Gordon

[Jslaby-h (jslaby-h)]

I hope this is fixed in later kernels, so we can close it now. If not, please reopen.

[Brad Figg (brad-figg)]

This change was made by a bot.

[penalvch (penalvch)]

Laurent Martin-Borret, at your earliest convenience, could you please test the latest upstream kernel available from the very top line at the top of the page from http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D (the release names are irrelevant for testing, and please do not test the daily folder)? Install instructions are available at https://wiki.ubuntu.com/Kernel/MainlineBuilds . This will allow additional upstream developers to examine the issue.

If testing on your main install would be inconvenient, one may:
1) Install Ubuntu to a different partition and then test this there.
2) Backup, or clone the primary install.

If the latest kernel did not allow you to test to the issue (ex. you couldn't boot into the OS) please make a comment in your report about this, and continue to test the next most recent kernel version until you can test to the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this issue is fixed in the mainline kernel, please add the following tags by clicking on the yellow circle with a black pencil icon, next to the word Tags, located at the bottom of the report description:
kernel-fixed-upstream
kernel-fixed-upstream-X.Y-rcZ

Where X, and Y are the first two numbers of the kernel version, and Z is the release candidate number if it exists.

If the mainline kernel does not fix the issue, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-X.Y-rcZ

Please note, an error to install the kernel does not fit the criteria of kernel-bug-exists-upstream.

Once testing of the latest upstream kernel is complete, please mark this report's Status as Confirmed. Please let us know your results.

Thank you for your understanding.

[Laurent Martin-Borret (laurent-martin-borret)]

I tested on latest available kernel as suggested by Christopher.
Issue is still present on kernel v4.4-rc7-wily
I got more or less the same stack trace when inserting an SD card. However, I got the stack trace once, not repeatedly. Or maybe I did not wait enough time. Gordon Dickens mentionned he had to wait some time (~7h) before the issue to occur. He also mentionned that it could be related to doing suspend/resume, but I am not able to test that with this kernel (my machine starts to suspend but then it seems stuck at some point, and it never shuts).
I hope it will help to fix it.
For my personal usage, I only use the SD card reader (no XD and no MemoryStick), so I guess I could blacklist both r592 and r852 modules but I guess it would be nice to have a better fix for others (or for me once I will have discovered an old XD/MS to read !)

[penalvch (penalvch)]

Laurent Martin-Borret, the next step is to fully commit bisect from kernel 3.19 to 4.2 in order to identify the last good kernel commit, followed immediately by the first bad one. This will allow for a more expedited analysis of the root cause of your issue. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection ?

Please note, finding adjacent kernel versions is not fully commit bisecting.

After the offending commit (not kernel version) has been identified, then please mark this report Status Confirmed.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[Laurent Martin-Borret (laurent-martin-borret)]

Christopher, I am not sure regarding your proposed strategy...
Let me explained :
- when I first discovered & reported this issue, I was using Ubuntu 15.04 / kernel 3.19.0-28-generic #30-Ubuntu on x86_64
- then I thought it was resolved when upgrading to kernel 3.19.0-39-generic (now I more think that I had some luck it did not appear as I am actually not able to reproduce it easily)
- I upgraded to Ubuntu 15.10 / kernel 4.2.0-22-generic and the issue is still there
- I tested latest mainline kernel 4.4-rc7, issue is present

To me, applying bisect on the 3.19-4.2 range will probably not lead to any good result as I expect all kernels to show up the issue.

I would rather look for issues on the 3.16-3.19 range...

Let me know if I missed something.

[penalvch (penalvch)]

Laurent Martin-Borret, to clarify, what is needed is the most recent kernel which didn't demonstrate the issue. If that's the 3.16 series, then that would be the start of the bisect, versus 3.19.

[Pontus Gråskæg (graaskaeg)]

I get the same issue on a newly installed Lubuntu 16.04.3 with 'apt upgrade' freshly applied.

/var/log/syslog and /var/log/kern.log grow to 100s of MiB in less than a day.

Typical syslog entry is attached (hostname redacted). I am not making hardware changes at the times these entries are made.

Note that the kernel reports itself as tainted. This is due to a previous kernel warning issued during the boot-up, which I believe to be unrelated - kern.log extract (hostname redacted) of warning and taint also attached.

The laptop reports itself as having the problematic Ricoh devices. relevant hwinfo attached. grepped extract follows

  Model: "Ricoh R5C832 IEEE 1394 Controller"
  Vendor: pci 0x1180 "Ricoh Co Ltd"
  Model: "Ricoh xD-Picture Card Controller"
  Vendor: pci 0x1180 "Ricoh Co Ltd"
  Model: "Ricoh R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter"
  Vendor: pci 0x1180 "Ricoh Co Ltd"
  Model: "Ricoh R5C592 Memory Stick Bus Host Adapter"
  Vendor: pci 0x1180 "Ricoh Co Ltd"

Workaround is blacklisting devices by adding the following lines at the end of /etc/modprobe.d/blacklist.conf

# Stop errors filling up log - see
# https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1530187
# Blacklist Ricoh card reader
blacklist r592
blacklist r852

This stops messages from appearing in /var/log/kern.log and /var/log/syslog. Cardreader still reads SD cards.

graaskaeg

[penalvch (penalvch)]

Pontus Gråskæg, it will help immensely if you use the computer the problem is reproducible with, and file a new report with Ubuntu by using the default repository kernel (not mainline/upstream/3rd party) via a terminal:
ubuntu-bug linux

Please feel free to subscribe me to it.

[Pontus Gråskæg (graaskaeg)]

For anyone tracking this, the new bug is here:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1715861