[11:54] <apw> awreece, perf for sure, sometimes we do do ftrace type gathering as wel, depends on the problem
[13:32] <henrix> apw: question about commit c097877319ab ("ARM: 8307/1: psci: move psci firmware calls out of line") since i see your 'Reported-by:' :)
[13:32] <henrix> apw: would you say that commit is applicable for the 3.16 stable kernel?
[13:33] <henrix> apw: it has been applied in 4.0 and 3.18, and it seems to apply cleanly in 3.16 as well
[14:44] <tomp> Something is wrong and I do not know where to start :-(((
[14:46] <tomp> I have specific symptoms but not like those at the "Kernel/Debugging/Symptom"-site
[14:46] <tomp> What could be my most simple debugging strategy ?
[14:48] <tomp> I'm well nigh sure I have a kernel problem :-/ 
[14:52] <tomp> What it's not:
[14:52] <tomp> backlight brightness control 
[14:53] <tomp> thermal
[14:53] <tomp> hotkeys
[14:54] <tomp> suspend/resume problem
[14:54] <tomp> What it could be:
[14:56] <tomp> sometimes it seems as if the module for wireless via USB can't be loaade (see the machine modprobing ad infinitum)
[15:03] <tomp> First appearance after updating/upgrading from Ubuntu-3.2.0-80.116 to Ubuntu-3.2.0-83.120 and still subsisting in Ubuntu-3.2.0-84.121
[15:04] <tomp> BTW: What is "scheduling while atomic" ? I've seen some CPU hard lockups while investigating my problem
[15:06] <tomp> How can I investigate it's not a BIOS issue ?
[15:06] <tomp> Once a sound problem occured :-/ 
[15:07] <tomp> Could it be an interrupt related issue ? In a log I saw that IRQ18 was disabled (by what???)
[15:08] <tomp> BTW: It's nit EFI
[15:11] <tomp> On https://wiki.ubuntu.com/Kernel/Debugging there's a lot of Debugging Tools/Information - regrettably it's too many, I don't see where to start from and what to start with :-(
[15:15] <tomp> But headache N°1: The whole thing isn't reproducible - at the moment, the machine is up 8,5 hours without any issue ...
[15:16] <tomp> Where should I start when the issues appear  ?
[15:24] <apw> henrix, ok the issue there is only triggered by the compiler combinations, but yes if it applies i would think it is safe and prolly snesible to have
[15:24] <henrix> apw: ack, thanks.  just wanted to confirm, as it was not tagged for stable
[15:25] <apw> tomp, well you have a believed good kernel, and one you know is bad so i would try the ones in between
[15:25] <apw> tomp, if it isn't very easy to reproduce this will take some time to confirm/deny each of the interviening ones is good/bad
[15:26] <apw> but once we have two consequtive kernels good/bad then we can look at the differences there
[15:28] <tomp> apw: What I can say so far: I first noticed it with 3.2.0-83.120. But next day I saw a kernel update and was in "good hope" that someone had found the issues and fixed them. So I'm on 3.2.0-84.121 now - but sadly the issues reappear from time to time :-(
[15:29] <apw> so whatever 119 is would be a good one to try
[15:30] <tomp> So, the question is: No more experiments and go back to 3.2.0-80.116 or go forward to some other available 3.5 kernel ?
[15:31] <apw> well if you are on the LTS you can try the linux-lts-trusty kernels
[15:32] <tomp> OK, but I'd like to have some informative basis about the problem before trying (and not knowing what I'm looking for) ...
[15:33] <apw> tomp, yep, you need to know how to say the problem exhibited itself for sure, what the primaty symptom is
[15:34] <tomp> Curiously 81.117 and 82.118 weren't installed by update manager. Maybe it was on 14 day frequency then an the kernel versions came in that time slot.
[15:35] <tomp> If it's reappearing the next days, can I get some help here ?
[15:35] <apw> tomp, there were a lot of small uploads for security and the like, may have been those
[15:35] <apw> tomp, yep
[15:36] <tomp> What's the best time to disturb you with new problems ;-) ?
[15:39] <apw> there are lots of people in and around at all sorts of time, just ask and you are likely to find someone
[15:41] <tomp> apw: Our daylight time seems to be the same. I'm CEST=UTC+2
[15:45] <tomp> Have a nice day
[16:31] <attente> apw: hi, how does one propose changes to the ubuntu kernel?
[16:35] <apw> attente, if you have specific fixes in mind then you can email kernel-team@lists.ubuntu.com and starts a thread there
[16:35] <apw> you can also start talking about it here
[16:37] <attente> apw: sure, it's just a small patch that will permit the addition of a new apparmor rule type for dconf settings confinement
[16:39] <jjohansen> attente: uh, sending to kt is premature
[16:40] <attente> jjohansen: oh ok. sorry, i didn't know the process
[16:40] <jjohansen> attente: I would say send it to the apparmor list for review
[16:40] <attente> jjohansen: sure. thanks
[16:41] <jjohansen> attente: apparmor@lists.ubuntu.com
[16:44] <apw> attente, yeah if its apparmor, then i would refer you to jjohansen who has already answered all my followup questions
[16:46] <attente> apw: great, thanks
[17:39] <cheburan> Hey, another try: PATCH 3.16.y-ckt 033/129 d2dc317 ext4 data corruptions - is it going to make to 3.13 LTS?
[17:41] <apw> kamal, henrix, ^
[17:43] <henrix> i'm not sure 3.13 is affected by that, let me have alook
[17:45] <kamal> cheburan, henrix, it looks relevant to me.  test-building it now.  :-)
[17:45] <henrix> yeah, it looks like it's applicable.  and since it's tagged for stable, it should hit 3.13 soon
[17:47] <kamal> cheburan, henrix: assuming that it builds okay, I'll queue it up for 3.13-stable immediately
[17:47] <cheburan> kamal, thanks. from the post on lwn (https://lwn.net/Articles/645723/), it seems that the bug was in the kernel for long time
[17:48] <henrix> cheburan: yep, true
[17:48] <kamal> cheburan, yes thanks for the heads-up ... I certainly prefer to get this into 3.13 sooner rather than later :-)