[08:36]  * apw watches 100s MB of updated download
[08:52] <smb> Which was even there yesterday...
[08:53] <smb> including just a new gcc... nothing to worry about...
[08:56] <apw> smb, was that my '100s MB of updates' you are talking about ?
[08:56] <apw> are you seeing "waiting for network configuration" as a plymouth message during boot?
[08:56] <smb> apw, Only when my network is bust usually
[08:57] <smb> So by now its a bad sign to me if I see it
[08:57] <apw> smb, this is on everything and on multiple networks all of a suddent
[08:58] <smb> Hm, strange. But then you don't see the waiting 60s more message?
[08:58] <smb> And your network is up when you log in?
[08:59] <smb> apw, ^
[08:59] <apw> yep just a single message
[09:01] <smb> The question now is whether it is always there and just now long enough for you to notice or whether it gets printed when network setup is delayed for a certain time
[09:01] <smb> any way, something seems slower for you
[09:02] <apw> i don't normally see any messages on the boot screen other than whn its doing an fsck
[09:02] <apw> this message i have never seen before, and indeed i thought networks were done after you logged in
[09:03] <smb> apw, No that changed a while ago
[09:03] <smb> Even with nm, your network was running even you being on the lightdm or gdm screen
[09:04] <apw> ok, still never ever seen that message with network or without
[09:04] <apw> and its all of a sudden on both my main machines and with two different network setups
[09:05] <smb> ok, so something became slower. I assume just this mornings update (if one can say just to that)
[10:25] <smb> apw, Hm, finished updating a test laptop and I do not see that message in my environment
[10:25] <apw> smb, hrm, will do the same in a bit
[10:26] <smb> apw, ok
[10:26] <smb> cking, we are talking to you
[10:27] <apw> cking, we heard you, a bit at least
[10:27]  * cking gives mumble a kick
[11:09] <ppisati> brb
[12:34]  * apw loses mumble too
[12:34] <apw> wtf is with this stuff these days
[12:35] <ogra_> its all hangouts now anyway :(
[12:36] <apw> bah
[13:38] <awe> cking: ping
[13:59] <cking> awe, pong
[14:01] <awe> hi
[14:01] <awe> so my machines has shutdown on me a few times in the last week
[14:01] <awe> I tracked it down to excessive CPU temp
[14:01] <awe> I was going to enter a bug against the kernel this morning, but noticed a new kernel was released
[14:02] <awe> should I wait to hit the bug again before reporting?
[14:02] <awe> ( also can it really be considered a kernel bug? )
[14:03] <cking> awe I'd say file a bug so at least we can track this
[14:03] <cking> you are not the first to report this
[14:03] <awe> ok
[14:03] <awe> thanks
[14:03] <awe> is there already a bug?
[14:04] <cking> awe, file a new bug, as I expect your H/W is different
[14:04] <awe> right
[14:04] <awe> will do
[14:06] <cking> awe, I have a bunch of things for you to try, which will help me corner this issue
[14:06] <awe> ok
[14:06] <awe> I'm in crunch mode right now, but will file a bug today
[14:06] <cking> ack
[14:07] <awe> ttyl
[14:07] <pgraner> sforshee, ping
[14:08] <sforshee> pgraner, hi
[14:08] <pgraner> sforshee, hey, so I think the mystery of the dropping wifi is solved
[14:09] <sforshee> really! what's causing it?
[14:09] <pgraner> sforshee, I checked yesterday and running up2date precise kernel it happened twice yesterday on that netbook
[14:10] <pgraner> I found https://bugs.launchpad.net/ubuntu/+source/linux/+bug/937118  
[14:10] <ubot2`> Launchpad bug 937118 in linux "Wireless stops passing packets" [High,Confirmed]
[14:10] <pgraner> and  mainline 3.3.0-030300rc6-generic  has made it work
[14:11] <jsalisbury> pgraner, sforshee yeah, the  linux-backports-modules-cw-3.3-precise-generic package solved that bug because the bug was fixed upstream.
[14:11] <pgraner> looks like its a dd-wrt issue and I'm guessing whatever it is exists on the cisco fw we use at events
[14:11] <pgraner> sforshee, Its been running now for over 8 hours and no issue
[14:12] <pgraner> sforshee, I could trigger it here in a matter of 2-3 hours
[14:12] <sforshee> pgraner, interesting. I use dd-wrt on one of my routers, but it wasn't the one I was using to test that machine.
[14:12] <sforshee> we may want to bisect then to see what fixed it so we can backport it to precise
[14:13] <pgraner> jsalisbury, sounds like a job for you my friend :-D
[14:13] <jsalisbury> pgraner, sforshee will do.  I think it may be this that fixed it: eea79e0713d94b02952f6c591b615710fd40a562
[14:14] <jsalisbury> pgraner, sforshee But I didn't do an actual bisect yet.  I came up with that commit after reviewing the git log.
[14:14] <sforshee> jsalisbury, that's a merge commit, so it's not _the_ fix
[14:14] <sforshee> it's just when the fix got merged to linus's tree
[14:14] <jsalisbury> sforshee, ahh right.  So a bisect of the merge commit will need to be done.
[14:16] <cking> awe, can you boot with an oneiric kernel and see if the overheating re-occurs?
[14:16] <awe> cking, let me catch you in a few minutes...
[14:18] <awe> cking, I've only hit it twice in the last week...
[14:18] <awe> unfortunately it's not reproduce on demand.  ;(
[14:19] <cking> awe, well, I can write up a bunch of things to try once you've file a bug ;-)
[14:20] <awe> cking, ok cool
[14:40] <akgraner> apw, cking - still no crash today - and I've been stressing my machine pretty hard over the last couple of days - the fan thing seems to have fixed it
[14:41] <cking> akgraner, that wasn't a fix, it was step #1 in me seeing what the problem could be - I've updated the bug - can you try the next step as instructed
[14:43] <akgraner> cking, sure 
[14:43] <cking> thanks!
[14:43] <akgraner> sorry I didn't see it sooner - I thought I would get an email when someone comments on it...weird
[14:43] <cking> akgraner, LP email isn't instantaneous at times
[14:44] <akgraner> cking, I didn't need to update a filter :-)
[14:44] <akgraner> ugh
[14:45] <akgraner> I meant - I did  get it - just need to update my filters - English and typing fail today it seems
[14:49] <cking> ah, no worries
[14:50]  * ogasawara back in 20
[15:02] <ericm|ubuntu> sforshee, bug 952698
[15:02] <ubot2`> Launchpad bug 952698 in linux "Backlight no longer works on Macbook Pro5,5 with EFI boot" [Undecided,Incomplete] https://launchpad.net/bugs/952698
[15:02] <ericm|ubuntu> sforshee, backlight actually works with nouveau driver w/ EFI boot
[15:02] <ericm|ubuntu> sforshee, and backlight is controlled by the nouveau driver instead of apple_bl
[15:03] <ericm|ubuntu> sforshee, backlight used to work w/ BIOS compatible mode, I'll need to test again
[15:04] <sforshee> ericm|ubuntu, apple_bl doesn't work on all macbooks, nouveau might be the only way to change it
[15:04]  * cking -> back in 20min
[15:04] <ericm|ubuntu> sforshee, apple_bl works sometimes as I remember but not reliable
[15:05] <ericm|ubuntu> sforshee, there is a small issue w/ nvidia-current though, when de-activating it in jockey, it makes nouveau un-usable, I have to purge it to get nouveau back again
[15:06] <sforshee> ericm|ubuntu, it may be that it only works in bios-compatibility, or that it needs changes to work with efi boot. I'm not sure.
[15:06] <ericm|ubuntu> sforshee, I believe it's nvidia-current black-listed nouveau
[15:06] <sforshee> that's nasty, probably need to file a bug for that
[15:06] <ericm|ubuntu> sforshee, yeah I doubt the I/O ports are still valid w/ EFI boot - brightness control never seems to be reliable to me
[15:07] <sforshee> ericm|ubuntu, adjusting via the graphics card is probably your best bet then
[15:08] <ericm|ubuntu> sforshee, yes
[15:08] <sforshee> the backlight situation on macbooks is horrendous
[15:08] <ericm|ubuntu> sforshee, and we won't have it w/ nvidia-current I guess
[15:08] <sforshee> ericm|ubuntu, no, and there's nothing we can do about it
[15:09] <ericm|ubuntu> sforshee, there is a backlight driver in mactel ppa - but that's a bit hackish
[15:10] <ericm|ubuntu> sforshee, one other problem w/ nvidia-current + EFI boot, I cannot seem to find my framebuffer consoles
[15:11] <sforshee> ericm|ubuntu, hackish yes, and I don't know what happens if you have it installed and try to use the nouveau driver
[15:11] <sforshee> EFI boot still has lots of issues to iron out
[15:11] <sforshee> graphics is the biggest one
[15:12] <sforshee> most of the drm drivers rely on having access to the vbios, which doesn't seem to be possible in EFI boot
[15:12] <mjg59> Sure it is
[15:12] <ericm|ubuntu> sforshee, yeah that's one issue
[15:12] <mjg59> But Apple don't provide it on Radeon-based machines for reasons that are unclear
[15:13] <mjg59> You can work around this by grabbing it out of the firmware during boot services and handing it off to the kernel
[15:13] <mjg59> I've a patch for grub that does that, but haven't forward-ported it to grub2 yet
[15:13] <sforshee> mjg59, thanks for the explanation. I confess I haven't looked into it much yet.
[15:13] <mjg59> But yeah nvidia is going to work badly on EFI Macs
[15:13] <mjg59> nouveau is a much better choice there
[17:00] <awe> bjf, any idea who I talk to about problems with ubuntu-bug?  I tried to run 'ubuntu-bug -p linux' and it just returns on my system...
[17:00] <awe> I have a power-mgmt problem which I guess I'll report directly via LP, and then try to apport attach...
[17:16] <bjf> awe, i think pitti knows more about ubuntu-bug than anyone 
[17:20] <Sarvatt> awe: its ubuntu-bug linux
[17:21] <awe> Sarvatt, someone should fix: https://wiki.ubuntu.com/Kernel/Bugs
[17:21] <awe> cause that's where I got the command-line from
[17:21] <awe> '$ ubuntu-bug -p linux'
[17:22] <Sarvatt> sorry about that, fixed the wiki
[17:22] <Sarvatt> -p linux is for apport-collect
[17:23]  * ppisati -> brb
[17:27] <philipballew> If i install a mainline upstream kernel to fix a bug, does that mess up updating from the repos or will it detect my newer kernel?
[18:06] <apw> o
[18:07] <apw> ogasawara, the enforcer deliberatly uses the enforcer file on master ... so that the rules are consistant on all branches
[18:07] <ogasawara> apw: just saw your email
[18:07] <apw> ogasawara, and it has expressive power in theory at least to allow different rules to be expressed for different flavours
[18:08] <ogasawara> apw: will yank the patch from master-next
[18:28] <apw> ppisati, you gave the arm peeps a way to test with an initramfs-less kernel didn't you, using the overlapping partition tables with puid fields ... right ?
[18:33] <GrueMaster> apw: being one of those arm peeps directly involved with testing, I have heard nothing yet.
[18:53] <jsalisbury> cking, another overheat related bug reported, bug 953205  Looks like the same type of hardware as bug 751689 so it may be a duplicate.
[18:53] <ubot2`> Launchpad bug 953205 in linux "System shuts down due to CPU temp exceeding critical thresh-hold (100C)" [Medium,Confirmed] https://launchpad.net/bugs/953205
[18:53] <ubot2`> Launchpad bug 751689 in linux "ThinkPads overheat due to slow fans when on 'auto'" [Critical,In progress] https://launchpad.net/bugs/751689
[18:54] <cking> jsalisbury, cool, I was talking to tony about that early
[18:54] <cking> earlier
[18:54] <jsalisbury> cking, ahh, ok.
[18:54] <ohsix> are the fans on the thinkpad not managed by acpi or are the thermal zones just wrong?
[18:55] <cking> ohsix, they can be managed by the firmware or by the thinkpad_acpi driver (by prodding the EC memory if I recall correctly)
[18:55] <ohsix> interesting
[18:56] <ohsix> also strange that even if you can do it with thinkpad_acpi, TMM1/2 don't work; or the critical thermal zone in acpi doesn't overrule it
[18:56] <cking> it's all in the thinkpad_acpi driver if you want to see the gory details 
[18:56] <ohsix> okie dokie
[18:57] <cking> jsalisbury, I hacked up some code to monitor what's going on so I can get an idea of what's causing the grief
[18:58] <jsalisbury> cking, cool.  I can reproduce an overhead pretty quickly on my x201, so I can do some testing if needed.
[18:58] <cking> jsalisbury, so is this happening more with precise than oneiric? 
[18:59] <ohsix> burnmmx ftw
[18:59] <jsalisbury> cking, In my case, I would say it happens the same.  My laptop will overheat and hit 100C shortly after kicking off a kernel build.
[19:00] <jsalisbury> cking, That was also the case in Oneiric
[19:00] <cking> jsalisbury, ok - that's bad, but not looking like a glaring regression.
[21:05]  * cking --> EOD