I have a HP/Compaq SDM4700P PS/2 keyboard, quite a prevalent model (I even have two myself). The keyboard has a set of 8 ”internet” keys on the top, one of which has a ”home” icon (so it’s supposed to be XF86HomePage I believe).

After installing linux-generic-lts-trusty (3.13.0-27.23 from -proposed), pressing the ”home” key triggers the computer going to sleep (powering down, power led starts blinking).

This did not happen with kernels prior to 3.13.

I installed and booted 3.13.0-24.47 (also available in the repositories now) and the issue was still reproducible.

To be sure, I also tried 3.11.0-22.38 and 3.8.0-41.60 again, and it was *not* reproducible.

(I wouldn’t have much use for the ”home” key as such, but as the keyboard lacks audio controls, I’ve remapped the ”home” key to be my XFAudioMute with ~/.Xmodmap. This was working fine until 3.13; now it still does mute the audio just before putting the computer to sleep. As I don’t use sleep mode otherwise, I’ve worked around this by adding an `exit` at the top of /etc/acpi/sleep.sh.)

No niin, hyvä. En ole hiirtä kummempia lisälaitteita aikoihin itse hommannut, ja siksi en ole näistä enää perillä. Webkameroiden suhteen oli samantyyppinen standardointi aluillaan silloin kun niiden kanssa viimeksi värkkäsin.

Onko näissä USB-mikki/kuulokesysteemeissä jokin standardi nykyisin, että toimivat Linuxissa sen puolesta, vai selvittelitkö etukäteen tämän nimenomaisen setin toimivuuden Linuxissa?

The Professor did great covering the early days, but I’m sure other people besides me are going to point out that Richard Stallman deserves as much if not more of a credit as Linus Torvalds does for what we call ”Linux” today, which is the Linux kernel combined with a ton of GNU software.

Since you appreciate typo spotting, a couple of more it’ses to itses: ConsoleKit and its successor, to retain its position.

This was very interesting to read, thank you. I wish more people could see these issues as resulting from conflicting design philosophies and would put their effort on improving implementations of their choice, rather than arguing that the other choice is inferior (let alone those ad hominem attacks against the other camp). I for one believe both designs have their uses, and that we shouldn’t be advocating either as the be-all end-all.

No problems with 3.5 either, marking as invalid.

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.

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.