[00:20] <PatrikOlsson> I'm going to bed now, I would really appreciate if someone would spend two seconds looking at the question!
[00:20] <PatrikOlsson> I just want to contribute
[01:00] <stgraber> sforshee: so, it looks like my laptop is a brick... I tried pulling the battery, memory, hdd, ... nothing helped
[01:00] <PatrikOlsson> nvm, good night
[01:00] <stgraber> sforshee: but it reminded me of the Samsung UEFI issue, I believe it's the first time I get a real panic on that machine
[01:00] <stgraber> sforshee: and my understanding is that we dump the panic to nvram now with new kernels
[01:00] <stgraber> sforshee: could it be that doing this somehow breaks Lenovo laptops?
[01:01] <stgraber> mjg59: ^ (thinkpad x230, 3.8 kernel on UEFI, kernel panic, won't show me anything since)
[07:24] <ppisati> moin
[08:02] <smb> ppisati, again ... bah! ;-P
[08:02] <ppisati> smb: what? :)
[08:03] <smb> ppisati, morning
[09:12]  * apw yawns
[09:53] <xnox> I see some references that "[PATCH] block: replace __getblk_slow misfix by grow_dev_page fix" made it all the way back to oneiric. Can somebody check if that patch is in precise generic kernels and up as well?
[09:53]  * xnox is struggling to find commit id
[10:02] <apw> ommit 7e9433b5394fd935dd6ea01dff601f23300aff83
[10:02] <apw> Author: Hugh Dickins <hughd@google.com>
[10:02] <apw> Date:   Thu Aug 23 12:17:36 2012 +0200
[10:02] <apw>     block: replace __getblk_slow misfix by grow_dev_page fix
[10:02] <apw>     
[10:02] <apw>     BugLink: http://bugs.launchpad.net/bugs/1049899
[10:02] <apw>     
[10:02] <ubot2> Ubuntu bug 1049899 in linux (Ubuntu Precise) "Precise update to 3.2.29 stable release" [Medium,Fix released]
[10:02] <apw>     commit 676ce6d5ca3098339c028d44fe0427d1566a4d2d upstream.
[10:02] <apw> xnox, that is from precises
[10:06] <xnox> apw: awesome, thanks.
[10:09] <apw> xnox, and that was in Ubuntu-3.2.0-32.51
[10:35] <cking> apw, http://www.x.org/wiki/IntelGraphicsDriver
[10:54] <henrix> apw: unless you're already on it, i'll apply herton's i915 patch into master-next so that i can start the respin
[10:55] <apw> henrix, you go ahead
[10:55] <henrix> apw: ack
[10:55] <apw> henrix, so we are respinning for it ?
[10:55] <henrix> apw: well, that's a nasty regression and its affecting lots of people it seems
[10:56] <apw> henrix, i cannot deny your logic
[10:56] <henrix> heh
[10:56] <apw> i was leaning that way myself
[10:56] <apw> henrix, as this is the P kerenl it isn't on the P point release CDs in fact is it
[10:57] <henrix> apw: no, this kernel won't be the one on the .2
[10:57] <apw> henrix, great, no panic then
[10:58] <henrix> apw: anyway, i'm going to prep everything, do all the testing etc, and leave it to brad to take the final decision ;)
[11:01] <apw> henrix, an even better plan :)
[12:14] <ogra_> apw, rtg, there is a new android release for nexus7 ... (not sure if it has a new kernel or wheer the source is though)
[12:14] <rtg> ogra_, I can look.
[12:14] <ogra_> it seems to add some stability acccording to the tests ... though i'm not sure if there is anything kernel related 
[12:15] <rtg> ogra_, when was the update released ? I don't remember having to update my unit recently .
[12:15] <ogra_> beginning of the week, but not released in all countries yet
[12:16] <ogra_> (i would have assumed the US being the first one though)
[12:16] <rtg> yeah
[12:26] <rtg> ogra_, there don't appear to be any kernel updates in the google repo
[12:28] <ogra_> well, it is supposed to have some BT fixes 
[12:28] <ogra_> not sure if thats in userspace or kernel though
[12:28] <rtg> maybe they don't push them right away
[12:29] <ogra_> if google would only allow me to search in english ...
[12:29] <ogra_> sigh
[12:30] <apw> ogra_, add something like ?hl=en to the end of the google URL
[12:30] <ogra_> (there used to be a "only english results" button for non natives ... )
[12:30] <ogra_> oh, thanks !
[12:30] <apw> it is something like that
[12:31] <jpds> apw: That only changes the interface language.
[12:33] <apw> jpds, hmmm i guess ogra_ can let us know :)
[12:33] <ogra_> hmm ?
[12:33] <ogra_> oh, i get english results now mixed with some few german ones
[12:33] <ogra_> (didnt attach it to the end but edited it in the url)
[12:34] <jpds> ogra_: Genau.
[12:39] <ogra_> hmm, https://developers.google.com/android/nexus/images doesnt have a 4.2.2 image yet
[12:39] <ogra_> so i guess you are right, they will roll out the ota ones first 
[14:15] <herton> apw, there is someone reporting a mismerge on an overlayfs patch on quantal, bug 1122094
[14:15] <ubot2> Launchpad bug 1122094 in linux (Ubuntu) "[patch] fix improper merge with overlayfs." [Medium,Confirmed] https://launchpad.net/bugs/1122094
[14:24] <apw> herton, ok thanks
[14:36] <apw> herton, it does look wrongo, quite how we ever get away with it, i am unsure
[14:41] <herton> apw, yes, henrix and I also took a quick look and seems wrong, perhaps we got away as it most affects the error path in nameidata_to_filp, error returned probably is uncommon
[14:49] <apw> yep
[14:49] <shadeslayer> hi, after installing fglrx I get : http://paste.kde.org/670244/
[14:50] <shadeslayer> any advice?
[14:51] <apw> shadeslayer, never seen that before, it looks on the face of it to be a bug in modprobe
[14:51] <shadeslayer> apw: I see bug reports on LP about this 
[14:51] <shadeslayer> bug 1073062
[14:51] <ubot2> Launchpad bug 1073062 in kmod (Ubuntu) "modprobe: Assertion `kmod_module_get_initstate(m) == KMOD_MODULE_BUILTIN' failed" [Undecided,Confirmed] https://launchpad.net/bugs/1073062
[14:52] <shadeslayer> http://paste.kde.org/670292/
[14:52] <shadeslayer> full log ^
[14:53] <apw> i would regenerate the initramsfs again and see if it works
[14:54] <apw> update-initramfs -u
[14:55] <shadeslayer> apw: nope, same issue
[14:56] <apw> tseliot, ^^ seen anything like this in your testing?
[14:59] <tseliot> apw: yes but only when the module can't build against the kernel
[15:00] <apw> tseliot, thanks
[15:00] <shadeslayer> tseliot: well ... as I can see, the module does build
[15:00] <shadeslayer> or maybe I'm reading it wrong?
[15:00] <apw> shadeslayer, what does 'grep off /etc/modprobe.d/*' say
[15:00] <shadeslayer> http://paste.ubuntu.com/1644200/
[15:01] <apw> /etc/modprobe.d/fglrx.conf:alias radeon off
[15:01] <apw> /etc/modprobe.d/fglrx.conf:alias lbm-radeon off
[15:01] <tseliot> shadeslayer: also the output of "dkms status" might help
[15:01] <shadeslayer> http://paste.ubuntu.com/1644202/
[15:01] <apw> ok according to the debian bug it is those (added by fgrlx) which kill kmod
[15:02] <tseliot> apw: how?
[15:02] <apw> tseliot, it is broken
[15:02] <apw> tseliot, it does not understand off
[15:03] <apw> (seemingly)
[15:03] <tseliot> apw: that would be a major issue
[15:03] <apw> and one i would have thought someone would a
[15:03] <apw> have noticed before now, given we have been using kmod for all of raring i think
[15:04] <tseliot> right
[15:05] <tseliot> maybe I should update my testing box again...
[15:13] <apw> shadeslayer, ok for now i would try converting those two 'off's to be blacklist <foo> and see if you can build an initrd ok
[15:13] <apw> shadeslayer, i will look into this in a bit
[15:14] <shadeslayer> apw: ack
[15:14] <shadeslayer> works :)
[15:15] <apw> shadeslayer, i am unsure if that is enough to prevent it loading on reboot, it _should_ be
[15:38]  * ogasawara back in 20
[15:43] <BenC>  /srv/ubuntu/linux-ppc-3.8.0/ubuntu/alx/alx_main.c:239:2: error: implicit declaration of function ‘vzalloc’ [-Werror=implicit-function-declaration]
[15:44] <BenC> rtg: This compiled for you guys everywhere else?
[15:44] <rtg> BenC, nope. in fact we disabled it for PPC, as should you
[15:45] <rtg> BenC, PPC in Quantal I mean
[15:46] <BenC> Ah, ok, I'll disable it
[15:49] <BenC> rtg: Seems like an easy fix though (add some #include's)
[15:50] <rtg> BenC, upstream is git://github.com/erikarn/alx.git. perhaps you could send 'em a patch.
[15:51] <rtg> so far this device only exists on x86'en platforms
[15:51] <BenC> I might…pretty low on my priority
[16:10] <kamal> BenC, rtg: I'll take care of that (fixing and submitting patch to alx upstream) if you like.    now to find a PPC build machine . . .
[16:11] <BenC> kamal: send me the patch, and I'll test it
[16:11] <BenC> kamal: I can send you the full error log if you want
[16:12] <kamal> BenC: sure: kamal@canonical.com
[16:12] <BenC> kamal: Ok, give me a bit to get back to that point after this upload
[16:12] <kamal> BenC: no rush, I've got plenty of stuff to break in the meantime
[16:13] <kamal> on that note ...
[16:14] <kamal> rtg: do you remember that day when I broke everybody's backlight?
[16:14] <rtg> quite thirstily :)
[16:14] <kamal> oh.   dang.
[16:14] <kamal> well anyway ...    that was a fun day, right?   wanna do that again?
[16:15] <rtg> only if I know there is free beer in it for me.
[16:15] <kamal> there's a small i915 patch (really, very small -- couldn't hurt a fly its so cute) that is pending in drm-intel-fixes-nightly ...   I'm not sure whether it'll make it in before 3.9.
[16:15] <kamal> so . . .   can I have it in raring pretty please?
[16:16] <apw> kamal, if you want a patch you know where to send it ... :)
[16:16] <rtg> submitted on the k-team list yet ?
[16:16] <kamal> apw: hush, I'm just trying to warm rtg up first
[16:17] <kamal> I'll be submitting it to k-team shortly.   yes, I agree in advance to whatever beer ransom you deem appropriate.
[17:19] <apw> herton, on that overlayfs thing, i have posted test kernels for him, as he can tickle the issue
[17:22] <rtg> ogra_, is the N7 image from today broken ? I can see Plymouth doing its thing, then the display goes dark. Plugging into the serial console works but I can't login since I have yet to setup a user.
[17:23] <ogra_> rtg, hmm, there are issues, but nothing that should prevent you from installing
[17:23] <rtg> ogra_, I've done it twice. would battery charge have any impact ? Mine might have been pretty low
[17:24] <herton> apw, ack thanks
[17:24] <ogra_> battery has surely some impact , i have seen the writing of images fail before due to it 
[17:25] <ogra_> but you got beyond that step, it sounds more like ubiquity being evil to you or so
[17:25] <rtg> well, I'll let it charge for an hour then try again
[17:54] <rtg> apw, ogasawara: any patches pending for raring ? I'm thinking I'll upload in order to get kamal's backlight fix out there.
[17:55] <apw> rtg, nothing i can think of
[17:55] <ogasawara> rtg: nothing here
[17:55] <rtg> ok then
[18:25]  * rtg -> lunch
[19:05] <plars> bjf, rtg: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1124415
[19:05] <ubot2> Ubuntu bug 1124415 in linux (Ubuntu) "Network installation fails with ahci" [Undecided,New]
[19:06] <rtg> plars, ack
[19:18]  * bjf[afk] -> lunch
[20:00] <sforshee> stgraber, I just noticed the messages from you in my backscroll, yikes
[20:01] <marvin24> dumb question: how to disable certain arch from kernel builds?
[20:02] <stgraber> sforshee: yeah... waiting for Lenovo to come replace the system board...
[20:02] <stgraber> sforshee: so that kernel test will have to wait a few days ;)
[20:03] <sforshee> my first suspicion would be that trying to store the panic messages triggered some firmware bug
[20:04] <stgraber> yeah. I don't think it's the first panic I had on that machine since I moved to the 3.8 kernel, but it can certainly depend on the size of the dump or maybe what's already in nvram
[20:04] <sforshee> do you happen to remember any details about where the panic happened?
[20:05] <sforshee> unfortunately there seem to be a lot of uefi bugs that are triggered by writing to nvram
[20:06] <stgraber> sforshee: sadly my memory isn't that good and the laptop was overheating so I didn't wait long before removing the battery to get it to cool. The only thing I remember was that it wasn't bluetooth related (I had a couple of those lately so that's I remember quickly going through the stack looking for bluetooth stuff and not seeing any)
[20:07] <stgraber> sforshee: do we have some kind of boot flag to turn off that feature (writing to nvram on panic)? because I don't want to end up bricking my replacement laptop ;)
[20:07] <sforshee> stgraber, okay. Just wondering whether it was related to my changes or not.
[20:07] <sforshee> not sure...
[20:07] <sforshee> and that's assuming that writing the panic to nvram was the cause
[20:08] <sforshee> I have a hard time believing that anything I changed could brick a machine though
[20:08] <stgraber> sadly as I want it fixed ASAP, I doubt this machine will end in the hands of anyone who actually knows what they are doing, so it's very unlikely we'll ever get to see a dump of the nvram or any kind of firmware debug data...
[20:10] <jsalisbury> rtg, bug 1124373 sounds like there may be an issue with the linux-firmware package in the preicse repository
[20:10] <ubot2> Launchpad bug 1124373 in linux-firmware (Ubuntu) "linux-firmware unexpected EOF in archive" [Undecided,New] https://launchpad.net/bugs/1124373
[20:13] <sforshee> stgraber, we can certainly disable writing the dump to nvram by disabling CONFIG_PSTORE, still not sure if there's some command-line option we can use
[20:14] <jsalisbury> rtg, I'll try to confirm the issue, but just wanted to give you a heads up.
[20:15] <stgraber> sforshee: it'd be unfortunate that we'd have to do that because the feature is kind of cool and useful... it sucks that we can't really check to be sure that it's indeed the problem...
[20:15] <stgraber> sforshee: well, I guess we could get similar certification machines and trigger panics in a loop (with panic=1 so the machine reboots), wait a day or so and see if we get any bricked ones... :)
[20:17] <sforshee> stgraber, that's an option
[20:18] <rtg> jsalisbury, I just pulled from the archive and unpacked OK.
[20:18] <rtg> wget http://archive.ubuntu.com/ubuntu/pool/main/l/linux-firmware/linux-firmware_1.79.1_all.deb
[20:18] <sforshee> stgraber, I'm pretty sure I heard some talk of tests involving filling up nvram, maybe that was wrt fwts
[20:19] <jsalisbury> rtg, Thanks for confirming it's ok.  I'll follow up on the bug.  His apt db is probably corrupt.
[20:19] <stgraber> sforshee: I know mjg59 wrote some tool on Windows that fills a bunch of nvram variables to trigger the samsung brick issue. I guess we could have something like that in fwts and maybe something that simulates what the kernel does on panic (if simply filling the nvram doesn't essentially do the same thing)
[20:20] <rtg> jsalisbury, just added https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1124373/comments/5
[20:20] <ubot2> Ubuntu bug 1124373 in linux-firmware (Ubuntu) "linux-firmware unexpected EOF in archive" [High,Triaged]
[20:20] <jsalisbury> rtg, great, thanks
[20:21] <ohsix> wasn't it tracked down to samsung using fake menu labels to do internal things? and when a proper user came by, it fell apart
[20:21] <mjg59> No, that's unrelated
[20:21] <ohsix> ok :>
[20:21] <mjg59> I'd look into that, except this Samsung is dead
[20:22] <ohsix> what were the nvram-y things related to?
[20:22] <mjg59> The nvram-y things
[20:22] <stgraber> mjg59: you don't have some Lenovo around by any chance to see if you can reproduce what happened on my laptop yesterday? ;)
[20:22] <ohsix> so nothing in particular
[20:22] <mjg59> stgraber: I've been running UEFI on Lenovos for about two years
[20:22] <mjg59> stgraber: They're what I wrote the EFI pstore code on
[20:23] <mjg59> stgraber: So I'm not immediately convinced that this is the problem
[20:23] <stgraber> mjg59: ok, so hopefully it was an unrelated issue that bricked my laptop yesterday after a kernel panic (x230)
[20:23] <mjg59> I'd hope so
[20:23] <mjg59> I mean, it could have been a kernel panic caused by bad hardware
[20:23] <mjg59> But yeah it's a concern
[20:23] <mjg59> I guess I can try filling the storage on this and see if it still boots
[20:24] <mjg59> I think I've got on-site...
[20:24] <stgraber> I'd been using it for UEFI/SB testing since September or so (got it right after Plumbers), I had a few panics but the fatal one was yesterday after testing a brightness fix from sforshee (3.8)
[20:26] <stgraber> so if it's the panic that triggered it, it must be a pretty specific bug (depending on the size of the dump or similar) and so will be a real pain to reproduce (especially as I don't have some magic way of getting the content of the nvram from the bricked unit)
[20:26] <stgraber> anyway, I'm glad I paid extra for quick warranty service on this one (and that I have a Lenovo service center a block away from here)
[20:31]  * rtg -> EOD
[20:49]  * ogasawara lunch