I like the completely random intercuts of unrelated people. Just look at that awkward slow-mo lady at 1:50.

The kernel parameterizing of allow-discards could be an Archism: apparently in Arch, you notify GRUB of an encrypted root with (e.g.) ”cryptdevice=/dev/mapper/root:root:allow-discards”. This being picked up by Ubuntu users might be due to Arch’s wiki being referred to as ”Best reference” by Ubuntu wiki’s EncryptedFilesystems.

This answer is starting to look good. I also found allow_discards in dm-crypt’s current documentation; everything seems to imply it’s not a kernel parameter but an option for the dm-crypt device-mapper target. I’m still trying to find out if those can be passed on the linux command line. That would explain the instructions parroted all over, otherwise it is probably just misinformation.

Sorry, I had forgot about this one after it vanished and was only reminded by a private email from someone suffering something similar.

I went through my collection of panic photos and (as my recollection also was) there seem to have been none of this ’warn_slowpath_common’ kind since I last commented.

Except for one just a week ago, on completely new hardware: this one with 3.8.0 rc2 when I was testing it wrt Bug #1096802, which turned out to be caused by bad card reader firmware. It was tied to usb-storage as most if not all of the panics caused by the firmware problem, so it was most likely another symptom of that, but I’m posting that one here too just in case it still contains a hint of the conditions under which ’warn_slowpath_common’ can occur.

Meanwhile, I’m marking this as fixed as per Joseph’s request above. For the record, as far as I’m concerned, a installing 3.3 or newer series kernel was a definite fix for this issue.

As I said, net’s full of instructions without explanations. I’m after the explanations, not the procedure.

So, neither of the options is needed if the filesystem isn’t encypted? Why two options if all they do is enable one command to work?

A lot of SSD-related instructions online currently say you should add allow-discards and root_trim=yes to your GRUB_CMDLINE_LINUX. I have yet to find one that says why you should do that, i.e. what exactly (if anything!) do those parameters do. Where is the documentation on this and what does it say about those two parameters’ purpose?

According to Cryptsetup 1.4.0 Release Notes,

Since kernel 3.1, dm-crypt devices optionally (not by default) support block discards (TRIM) commands. If you want to enable this operation, you have to enable it manually on every activation using –allow-discards

cryptsetup luksOpen --allow-discards /dev/sdb test_disk 

but is it the same when passed to the kernel (via GRUB_CMDLINE_LINUX)?

Edit: Kernel.org’s list of kernel parameters doesn’t (currently, Jan 2013, at least) have either of these options.

Ehkä ne polliisissa ottais ilmotuksen tuosta vastaan, vaikkeivät sulle mahd. löytämisiään kertoiskaan. Tiedä vaikka tämä tyyppi muutoin makaisi kotonaan muumioituneena vielä vuosienkin päästä, niin kuin tässä maassa ruukataan.

I’m happy to report that this seems to have been a firmware issue: with a temporary install of MS Windows, which the card reader manufacturer’s firmware upgrading software required [1], I managed to upgrade the card reader’s bought-with firmware version 551 to manufacturer’s current latest version 563 (released just last month). After this there were no more ”disabled ep” messages in any boot, the reader works just fine and there have been no kernel panics of any kind.

This was with the mainline 3.8 kernel so I’m not marking this bug invalid just yet. I’ve now switched back to the Quantal kernel I initially reported this with and will report here next week on how it goes.

*[1] http://www.akasa.com.tw/update.php?tpl=product/cpu.product.tpl&no=181&type=Card%20Reader/Hub&type_sub=Card%20Reader&model=AK-ICR-17

The lsusb listing attached by apport above seems to not list the card reader at all. This did happen on some sessions, IIRC there were no panics or ”disabled ep” messages then either but naturally, the reader also wouldn’t read any cards, it was as if disconnected.

I’m attaching output of `sudo lsusb -v` here, with the card reader (004:002) detected and showing.