Tervehdys!

Yritin tilata sivustonne uutisosion verkkosyötteen, mutta molemmat uutissivulla tarjolla olevat osoitteet (RSS [1] ja Atom [2]) ovat rikki: palvelin ilmoittaa 403 Forbidden. En myöskään löytänyt yhteystietosivuiltanne web-vastaavan nimeä, ja joudun siksi pommittamaan tällä asialla info-osoitetta. Olisi kiva jos webmaster korjaisi tuon syötejutun meille Facebookia karttaville.

*[1] http://www.finnwatch.org/uutiset?format=feed&type=rss
*[2] http://www.finnwatch.org/uutiset?format=feed&type=atom

No problems with 3.5 either, marking as invalid.

Olen kateellinen. Miehen haju on aikuisuuden vastenmielisimpiä puolia, ja jaan keinotekoisten hajujen inhosi, joskin kuitenkin sen verran lievempänä että pystyn Doven vienoimmin maustettuja tököttejä käyttämään, ja käytettävä on, kun olen kaikkea muuta kuin hajuton. Käytin Hicodermiä pitkään, mutta sen saatavuus apteekkituotteena on hankalaa ja kallista, joten lopulta vaihdoin.

Rainbow muuten nyt varmaan haiseekin kemiantehtaalta todennäköisemmin kuin esim. Axe, halpikset useimmiten haisevat. Kalliitkin usein, mutta niissä on sentään joitain vähemmän synteettisen hajuisia.

Don’t read Jon Ronson, read Robert Hare’s Commentary on Ronson.

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?