[00:43] <stgraber> sforshee, mjg59, slangasek: so you know my bricked x230, I got a replacement one last week, well... I just bricked the replacement doing the exact same thing (by accident...)
[00:43] <stgraber> so I think this rules out bad system board, or I'm terribly unlicky getting two units that decide to go brick just after I do the exact same thing
[00:44] <stgraber> the "reproducer" appears to be: run current raring (3.8) on UEFI, connect to the internet using a phone over bluetooth, after a while, disconnect.
[00:45] <stgraber> at that point, I seem to get a oops which makes me jump out of vt7, when trying to type anything, it's followed by a panic, listing some intel stuff (I remember seeing drm_ lines in there)
[00:45] <stgraber> any attempt to reboot the machine after that fails to POST
[00:47] <mjg59> stgraber: Ok. The patch I sent yesterday should fix it.
[00:48] <stgraber> mjg59: ok. did you manage to reproduce this at all or did you just spot something wrong and fixed it?
[00:49] <mjg59> stgraber: No, I just did something based on what Samsung told us was the problem
[00:49] <mjg59> Haven't had an opportunity to reproduce yet
[00:50] <stgraber> ok, hopefully Lenovo won't be too annoying when I ask them to replace a second unit with the exact same deffect as the one they just replaced ;)
[00:50] <stgraber> by the time I get a fixed unit, the fix should be in our kernel so hopefully that'll be the last time this happens
[00:50] <stgraber> sforshee: I'd very strongly recommend cherry-picking mjg59's fix immediately! (I'm by far not the only x230 raring user, ...)
[01:40] <JanC> stgraber: assuming Samsung's problem is the same as Lenovo's?   :-/
[01:42] <mjg59> Assuming that
[01:44] <JanC> to be honest, I was going to try to get linux to boot on my Toshiba laptop using UEFI (currently it only boots when I enable legacy BIOS mode), but I'd rather not brick it...
[03:06] <infinity> stgraber: You're making me very confident in my decision to run my ThinkPad in Legacy mode.
[03:14] <stgraber> infinity: :)
[10:56] <lantizia> apw, updated the bug as you asked
[13:35] <apw> has everyone tested the g+ hangouts recently
[13:36] <smb> Obviously I did... :-P
[13:36]  * henrix has never used g+ hangouts
[13:38] <apw> smb, obviously you did indeed, to test myself
[13:38] <apw> and very kind of you it was too
[13:39] <apw> henrix, i guess if you are only watching you may not care
[13:39] <apw> else get on it !
[13:39] <smb> apw, or vice versa. Haven't used them for long before that
[13:41] <rtg> apw, seems to work for me the few times I've used 'em. gotta close mumble first though
[13:43] <smb> rtg, seemed to work even with mumble running yesterday... of course it gets a bit confusing when pressing ptt
[13:44] <apw> rtg, yeah i was using both together, but pretty ppt with smb online was a bad loop
[13:44] <rtg> smb, my problem is that mumble/pulse in combination with G+ consume so much CPU that the fan starts howling.
[13:44] <sforshee> mjg59, I assume the patch you're referring to is "efi: be more paranoid about available space when creating variables" ?
[13:45] <smb> rtg, Ah yeah... probably thats when the pictures went bad too...
[13:47] <aissen> rtg: I was wondering the other day why you removed tigon and bnx2x firmware from linux-firmware, and not from linux-image instead ?
[13:47] <rtg> aissen, IIRC they were kernel version specific
[13:50] <aissen> rtg: but so is linux-firmware, for which you have a branch per ubuntu release.
[13:52] <aissen> rtg: also, it seems that linux-firmware has the most recent version, and the kernel only has an outdated version of the firmware.
[13:53] <rtg> aissen, file a bug with specifics and I'll fix it.
[13:54] <aissen> rtg: I don't use this driver or hardware so I don't want to cause a regression
[13:54] <aissen> it just seemed weird
[13:55] <aissen> when I was comparing the list of in-kernel firmware and in linux-firmware.
[13:55] <rtg> aissen, so you don't know of any specific failures ?
[13:56] <aissen> not at all, otherwise I would have filled a bug :-)
[13:57] <aissen> rtg: I was just trying to understand the rationale of the removal in linux-firmware 1.88.
[13:57] <rtg> aissen, primarily it was to decrease the size of the package and also accomodate kernel version dependencies
[16:16] <bguthro> gordon, John tried to use the XCE DL, but it doesn't have any members...so now he's waiting for everyone to show up to a meeting that nobody got an invitation for.
[16:18] <bguthro> oops wrong window. Apologies
[18:01] <bryce> apw, btw remember that drm race bug from back when?  (bug #982889) I finally got to patching the xserver to check for EAGAIN, but actually it appears the kernel is giving us EACCES, and while sleeping for a bit does eventually get us working drm, we never get anything except EACCES from the kernel.
[18:01] <ubot2`> Launchpad bug 982889 in xorg-server (Ubuntu) "X trying to start before plymouth has finished using the drm driver" [Critical,In progress] https://launchpad.net/bugs/982889
[18:02] <bryce> apw, I'm going to ship my xserver patch as a "fix" but I think I'm just papering over breakage somewhere lower down.
[18:03] <apw> bryce, that sucks bad things
[18:03] <apw> bryce, but it also sounds sensible, sadly
[18:04] <bryce> apw, so you might put that bug somewhere on your todo list to look at if you have time.  Seems the bug is cropping up more frequently now that SSDs are getting more pervasive.
[18:19]  * rtg -> lunch
[20:45] <sbeattie> bjf: FYI, I get an instant oops when schrooting with an overlayfs with the 3.5.0-26.40 kernel in quantal-proposed (bug 1147678)
[20:45] <ubot2`> Launchpad bug 1147678 in linux (Ubuntu) "kernel 3.5.0-26.40-generic oops immediately when doing schroot w/overlayfs" [Undecided,New] https://launchpad.net/bugs/1147678
[20:48] <bjf> sbeattie, ugh
[20:49] <rtg> bjf, apw has a test suite for that IIRC
[20:49] <bjf> rtg, ack
[20:50]  * bjf wonders why he's not running it as part of the kernel tests
[20:50]  * rtg wonders the same thing
[20:50] <rtg> I'm pretty sure you can do a reasonable loopback test
[21:03] <bjf> jsalisbury, ^ hotlist please
[21:06]  * rtg -> EOD
[21:53] <jsalisbury> bjf ack