[07:16]  * apw yawns
[07:20] <RAOF> apw: Good morning!
[07:20] <apw> RAOF, evening !
[07:24] <RAOF> apw: I've been prodded with a gfxpayload bug - bug #971204 - I thought this stuff had been pretty thouroughly bedded down by now?
[07:24] <ubot2> Launchpad bug 971204 in linux "graphics fails with setgfxpayload=keep, AMD Radeon" [Medium,Incomplete] https://launchpad.net/bugs/971204
[07:24] <apw> RAOF, yeah we did too, but they probabally only test initialisating from 'text mode', so some level of regressions are only going to be detected by us
[07:26] <apw> RAOF, i have only ever debugged one of these with Intel, and the approach there was to get an intel register dump from the two initialisations ... so disable X, and then boot both ways and get a dump remotly via ssh.  that then showed a difference in setup that the upstream guys could see how to unpick correctly
[07:28] <apw> RAOF, so actually it was 4 dumps, disabling DRM drivers as well, so both modes, dumps before and after drm initialises
[07:28] <RAOF> Whee!
[07:28] <apw> RAOF, can we do something similar for radeon registers ?
[07:28] <RAOF> I think that'd be possible for radeon, yeah.
[07:29] <apw> in intel cases it has always been an unpicking error, so we turn things off in such an order that we put the thing in a state which would be illegal during init and it locks up or goes mad or similar
[07:29] <RAOF> I think radeon has a bunch more registers, but radeontool can dump them all.
[07:30] <apw> yeah it cirtainly wasn't about comparing them by hand.  i was using diff -u on them, i was finding the broken case the pipes were going into error and never coming out
[07:31] <apw> with that infor they said, doh if A is connected to Y and we try and switch the pipe order without first switching off Q ... and they fixed it
[07:31] <apw> but it needed someone who knew the specs in their head
[07:31] <apw> RAOF, also is it a 'new' card ?
[07:32] <RAOF> Newish.
[07:32] <apw> [ATI Radeon HD 6800 Series]
=== anubhav__ is now known as anubhav
[07:33]  * apw is a little supprised it has regrssed between the two, i've not seen that before (between O -> P)
[07:33] <RAOF> Yah.
[07:34] <apw> https://launchpadlibrarian.net/99888732/Screenshot%20from%202012-04-03%2022%3A38%3A09.png
[07:35] <apw> RAOF, i assume htat is nothing todo with the original but there, but i have seen that recently-ish as well, the old there when you scroll, gone when you scroll some more
[07:35] <RAOF> Urgh.
[07:35] <RAOF> What driver?  radeon?
[07:36] <apw> RAOF, na, all intel.  i've seen it only once, and i have upgraded X and kernel since i suspect, i'll worry if it becomes common :)
[07:36] <RAOF> :)
[07:36] <apw> RAOF, its one of those that happened when using SHIFT+PGUP in terminals
[07:37] <diwic> apw, btw, are  you and the rest of the team  still having pulseaudio + mumble problems?
[07:37]  * apw remembers the says when the fence locking was bad and it was every time :)
[07:37] <RAOF> Aaah, fun times.
[07:37] <apw> diwic, yeah some, tim nearly wrecked his monitor trying to get it working yestrday.  personally i have had a few good days recently
[07:37] <apw> diwic, she is a tempremental beast
[07:38] <diwic> apw, yeah, because I haven't even seen a launchpad bug for it, nowhere to ask you questions, get logs etc. Honestly, you don't look very eager to get it fixed...?
[07:38] <apw> diwic, you don't expect us to behave like proper sensible citizens do you?  to do the things we'd ask you to do?
[07:39] <apw> diwic, :)  i'll file a bug next time it happens to me and try and get a core or something off it before i kill it in the face
[07:39] <diwic> apw, and we're closing in on Final Freeze, so if you want it fixed...
[07:39] <apw> diwic, ubuntu-bug alsa ?
[07:39] <diwic> apw, go for ubuntu-bug pulseaudio and then ping me to point me at it.
[07:39] <apw> diwic, yeah i know, though as its broken we can still fix it, and frankly i'll be on whatever Q is called soon :/
[07:40] <apw> diwic, ok will get the message out to people
[07:40] <diwic> apw, bug fixes are in general carried on to the next release. :-)
[07:40] <apw> smb`, yo ... mumble ?
[07:41] <apw> diwic, heh fingers crossed ... we gonna get some spectacular new fun in pulse in Q
[07:41]  * apw considers he probabally expects to know what Q is called by now
[07:42] <apw> diwic, ahh crap i have pulse pending for update ... so i can't file a bug even if i want to
[07:43] <apw> RAOF, do i want to know why i have a new x-server :)
[07:43] <RAOF> apw: Only if you've got a touchscreen :)
[07:43] <apw> wacom ?
[07:44] <RAOF> Are you having problems single-clicking on stuff?
[07:44] <RAOF> Because the new server should fix it.
[07:45] <apw> RAOF, heh no i think that works ok :)
[07:45] <apw> oh goody the keyboard bindings they changed last week ... are changing again
[07:45] <apw> how could that possibly be confusing for m
[07:45] <apw> me
=== smb` is now known as smb
[07:54] <ppisati> moin
[07:57] <smb> ciao
[07:59] <ppisati> ciao Stefan! :)
[08:02] <smb> ppisati, :)
[08:03]  * smb needs coffee...
[08:33]  * ppisati -> reboot
[08:51] <janimo> are the kernel meta-packages also kept in git and source packages built from there?
[09:03] <smb> yes
[09:22]  * cking bailing out, feeling really unwell today
[09:45]  * smb reboot
[09:47] <apw> tseliot, manage to test that vthandoff combo ?
[11:30] <apw> smb, bah after all that the bad link is indeed bad, but completely ireelivant, it should be simply removed
[11:32] <smb> apw, saw the email
[11:33] <smb> apw, btw, you may be pleased to hear I also have a system that can reproduce the nouveau need to press esc twice bug
[11:37] <apw> smb, ahh that is excellent
[11:37] <apw> then ... i will forward you and email with the testing bits
[11:37] <smb> apw, sure. was sort of the plan. :)
[11:38] <apw> smb in flight
[11:38] <smb> apw, landed
[11:39] <apw> smb, cool thanks
[11:40] <apw> smb, so to expalin, this would still need a third fix for not selecting text when we know we cannot ever do it, but the key is if =text is selected then we should never enable handoff kernel side
[11:41] <apw> smb, in the case of encrypted root there is no point and it should be forcing no-graphics always
[11:41] <apw> currently it is assumed the selection will fail (no graphics mode selected as an error) and then be ok, but handoff is wacking some bad drivers i think
[11:42] <smb> apw, I was wondering about (and also about to ask) what the $foo stands for (whithout having looked at the diff yet as its doewnloaded)
[11:43] <apw> smb, that bit referes to editing your grub line at boot time, you know how it has set gfxpayload=$linux_gfx_payload or very similar, you change that to =text to disable handoff but let grub handle fiddling with the options to the kernel
[11:43] <apw> smb, instead of the more normal needing to do =text _and_ remove vt.handoff 
[11:43] <apw> smb, nice side effect of these patches is that we only need to change =text any time we want to disable handoff, so the instructions are simpler
[11:44] <apw> smb, making any sense??
[11:44] <smb> Ah ok... probably what would be there if grub defaults had console...
[11:44] <apw> right, if we had correctly told it graphics don't work it would be already =text, so that line would do the right thing for us
[11:44] <apw> but its stupidly trying to load the graphics drivers, when it can't open the disk to find them
[11:45] <smb> Confusingly there once was a "text" as kernel/upstart argument...
[11:45] <apw> smb, still is, as i found when i was testing :)
[11:45] <apw> when X all broke and i was really confused, cause i was using $gfxpayload on the command line :)
[11:45] <smb> Yes, there also is a message shortly visible about not being able to set graphics
[11:45] <smb> heh
[11:46] <apw> right and that'd go away if we'd corectly told it not to try that
[11:46] <apw> so fix 3 will be to insert something something to stop it for encrypted disks
[11:46]  * apw get tea
[11:46]  * smb resists to obey
[11:55] <smb> apw, OK, so with gfxpayload=text, I see the booting commandlist (in a smaller than normal 80x25 font), then the slpash which asks for the passphrase. connot set videomode is gone as expected
[12:00] <apw> smb, so it does the right thing basically ?
[12:00] <apw> and can you paste me the /proc/cmdline output
[12:02] <smb> OOT_IMAGE=/vmlinuz-3.2.0-22-generic root=/dev/mapper/eddie-root ro quiet splash vt.handoff=7 vt.handoff_enable=text
[12:08]  * henrix will be off for ~30mins
[12:17] <smb> apw, Anything else I should try or look up?
[12:18] <tseliot> apw: no, sorry, not yet, but I'll let you know
[12:18] <apw> smb, i want to just confirm i've done it all right and if so we're good else i may have a second round
[12:18] <apw> smb, so if it can stay in that shape for the min that'd be handy
[12:19] <smb> apw, It can be left that stage. Just wanted to be sure you don't need anything else off it or done right now
[12:19] <apw> no that confirmation is great
[12:20] <tgardner> henrix, did you pin down that regression in Oneiric for sure? I'm thinking we likely need the same patch in Precise.
[12:23] <tgardner> herton, did you pin down that regression in Oneiric for sure? I'm thinking we likely need the same patch in Precise.
[12:25] <herton> tgardner, in one of the other bugs the reporter said the fix didn't work for him, so I'm not sure now if that patch fixes things. Is a good fix to have anyway
[12:25] <tgardner> herton, do you trust the reporter  ?
[12:27] <herton> tgardner, heh not sure, bug 972285 the guy just said it didn't work for him. I just installed a i386 oneiric here, will see if I reproduce
[12:27] <ubot2> Launchpad bug 972285 in linux "segmentation fault when start on linux 3.0.0-18-generic" [Medium,Confirmed] https://launchpad.net/bugs/972285
=== ogra is now known as Guest67850
[12:42] <herton> tgardner, ok, I'm able to reproduce here, just installing -18 kernel. it's not the epoll issue, I'll have to investigate more (bisect etc.)
=== ogra_ is now known as ogry
[12:42] <tgardner> herton, do you suppose there is more then one regression ?
=== ogry is now known as ogra_
[12:43] <herton> tgardner, may be, since in one of the bug reports someone said the epoll fix was ok (fixed his problem)
[12:44] <tgardner> herton, or he just rebooted and the problem went away. I think on these kinds of issues the reporter needs to go back and forth a couple of times on the different kernels.
[12:45] <herton> yeah, and the epoll thing shouldn't be causing this crashes, it makes more sense now
[12:45] <herton> *these
[13:06] <janimo> apw, do you keep kernel meta packages under git too?
[13:06] <apw> janimo, yes
[13:06] <henrix> herton: i built a kernel without the epoll patch, instead of adding the fix
[13:06] <janimo> thanks
[13:06] <henrix> herton: would you want to try that?
[13:07] <apw> janimo, i think we are holding linux-meta right now in view of a possible regression, ogasawara is looking at it
[13:07] <henrix> herton: there are more reporters on bug #972821 stating the previous kernel didn't fix the issue
[13:07] <ubot2> Launchpad bug 972821 in linux "[oneiric-proposed] linux-image-3.0.0-18-generic makes apport-gtk and chromium-browser segfault on startup" [High,Confirmed] https://launchpad.net/bugs/972821
[13:07]  * ogasawara just got in and is catching up on things
[13:09] <janimo> apw, I was just wondering how useful having meta in VCS is given it is mostly changelog diffs among versions (at least with the simple kernel source I worked with)
[13:09] <herton> henrix, sure, I can check, but I don't think it'll change anything, should be another issue, I'm investigating now that I reproduce here
[13:09] <apw> janimo, it about it being the same, else one has to use bzr for meta and git for the kernel source and one tends to destroy things 
[13:10] <henrix> herton: have you checked strace output?
[13:15] <henrix> herton: take a look at https://lists.ubuntu.com/archives/ubuntu-users/2012-April/258939.html
[13:15] <henrix> herton: one of the logs seems to point to epoll_wait()
[13:19] <herton> henrix, strace stops on poll here as well like he says
[13:20] <henrix> herton: interesting
[13:20] <herton> but I'm not sure this is related to the problem
[13:35]  * apw runs an errand
[13:39] <dileks> http://nopaste.snit.ch/128636
[13:39] <dileks> are those meta-generic packages not JIT? /me installed -22
[13:40] <janimo> apw, and for meta packages the revision number needs to match the image package revision number it is supposed to depend on right?
[13:40] <janimo> so not an upload count for the meta as the upload counts for the two packages can get out of sync
[13:41] <apw> janimo, right the first bits have to match the version of the depa
[13:41] <apw> depndant binaries, the uploads cycle as they wish
[13:41] <dileks> I personally dont understand why you ubuntu kernel guys bump two versions at one time: for example for -22 its .35
[13:41] <dileks> for -21 it was .34
[13:42] <apw> dileks, ?
[13:42] <janimo> dileks, I recently learned it is the upload count during a release cycle
[13:42] <janimo> regardless of version, so version and upload count increase independently
[13:42] <dileks> my first kernel was with precise-beta1: 3.2.0-17.27
[13:43] <tgardner> janimo, we use the upload count as a minor version within an ABI series
[13:43] <apw> and every upload has to have a different version number thats the debian law
[13:43] <janimo> tgardner, right. Until a few days ago I though (and did so for ac100) the minor version is set to 1 on each ABI bump
[13:43] <janimo> whereas I learned it is monotonically increasing across bumps
[13:44] <tgardner> janactually, that works as well since its the ABI number that takes lexicographical precedence
[13:44] <dileks> I manually installed... 3.2.0-20.33 and 3.2.0-21.34
[13:44] <janimo> so I thought kernels use 3.2.0-1000.1 then 1000.2 then with the ABI bump 1001.1 again
[13:44] <tgardner> janimo, there is nothing wrong with that
[13:45] <janimo> tgardner, was told the policy is to have the last number reflect the absolute number of uploads, which is fine too, was just news to me :)
[13:45] <tgardner> janimo, its not policy per se, its just the way we've been doing it.
[13:45] <janimo> tgardner, so there is no ubuntu/canonical/oem wide policy? There should be imo to avoid confusion
[13:45] <janimo> the two approaches seem both good enough
[13:45] <apw> all kernels shold follow our lead as far as i know
[13:46] <tgardner> janimo, the only policy is the debian version numbering rules
[13:46] <janimo> ok
[13:46]  * apw really makes it out the door
[13:46]  * tgardner has to reboot for updates
[13:46] <joumetal> hi. i bisected boot regression in mainline kernel 4a3d2d9bfb3b594b6e1f2b7eabfaf4e820a18c0e
[13:47] <dileks> for me it seems to be +1 for both: 3.2.0-$prev1+1.$prev2+1. so why do you bump both versions? 3.2.0-20.1 would be enough. even -20 would be enough. I only want to understand for what both versions stand for.
[13:47] <dileks> hmm, abi change
[13:48]  * dileks sshs into his i386/sid system
[13:49] <dileks> ii  linux-image-3.2.0-2-rt-686-pae       3.2.13-1                        Linux 3.2 for modern PCs, PREEMPT_RT
[13:51] <dileks> hmm, upload count #. anyway :-)
[13:53] <joumetal> is it better to report this upstream bug to launchpad an forward it or report it to kernel.org bugzilla?
[13:53] <janimo> apw, do you use git-buildpackage or something else to build sources for the metapackages?
[13:56]  * ppisati -> restart pulse, stuttering audio
[13:58] <ogasawara> joumetal: if you've bisected the regression to an upstream commit, I'd report it upstream first.  you can then open a secondary report in launchpad track the upstream status.
[14:02] <tgardner> janimo, are you looking at ubuntu-precise-meta.git ? Use 'make binary' or 'make source'
[14:08] <joumetal> ogasawara: I report it. it's perf tools: Adjust make rules. What component, Other?
[14:08] <ogasawara> joumetal: sure
[14:10] <ogasawara> joumetal: the commit you referenced looks like it was included as of v3.4-rc1, you may just want to report it to LKML
[14:11] <joumetal> ogasawara: should I cc someone based on this commit?
[14:11] <ogasawara> joumetal: I suspect the patch author would be good
[14:12] <joumetal> ogasawara: thanks
[14:17] <tgardner> ogasawara, did you notice gcc was uploaded ?
[14:17] <ogasawara> tgardner: I did
[14:17] <tgardner> ogasawara, I don't think it'll impact us
[14:18] <ogasawara> tgardner: hopefully not
[14:18] <ogasawara> tgardner: might be cutting it close though, but I'm sure the release team will give approval
[14:19] <ogasawara> tgardner: but I guess this gives us an opportunity to squeeze in any last minute fixes without having to jump through the SRU hoops
[14:19] <tgardner> ogasawara, well, I think we've gotta wait until henrix and herton figure out this regression on oneiric as it may well impact precise
[14:19] <ogasawara> tgardner: indeed
[14:22] <ogasawara> skaet: just a heads up, gcc was just uploaded.  I'm hoping/assuming it should finish building in time for us to rebuild the kernel in time for freeze tomorrow.
[14:23] <skaet> ogasawara,  thanks for the head's up.
[14:23] <ogasawara> skaet: did we have a specific time of day kernel freeze would take affect?
[14:24] <skaet> ogasawara, 2100 UTC 
[14:24] <ogasawara> skaet: ack, thanks
[14:24] <skaet> n/p
[14:35] <bjf> ogasawara: not sure you saw the comment in the backtrace but someone was saying that bug 570542 has not been fully fixed though it is "Fix Released"
[14:35] <ubot2> Launchpad bug 570542 in linux "linux-image-virtual does not include ahci module, prevents virtualbox from booting an Ubuntu guest" [Medium,Fix released] https://launchpad.net/bugs/570542
[14:35] <ogasawara> bjf: was just looking at that.  it's fixed in precise since the module is built in.  I'll do the SRU for previous releases to include libahci
[14:37] <bjf> ogasawara: mostly cared about Precise :-)
[14:41]  * ogasawara back in 20
=== emma is now known as em
[15:40] <ashif> hi
[15:41] <ashif> im new here
[15:41] <jsalisbury> bjf, henrix, herton A couple more regressions in 3.0.0-18: bug 973111 bug 973444
[15:41] <ubot2> Launchpad bug 973111 in linux "System fails to boot after installing linux-image-3.0.0-18-generic" [High,Confirmed] https://launchpad.net/bugs/973111
[15:41] <ubot2> Launchpad bug 973444 in linux "can't boot into kernel 3.0.0-18" [High,Confirmed] https://launchpad.net/bugs/973444
[15:41] <bjf> jsalisbury: yup, we spotted those
[15:41] <jsalisbury> bjf, cool, thanks.
[15:42] <bjf> jsalisbury: np, keep em coming
[15:42] <ashif> kernel programming ?
[15:49] <apw> people say the darndest things
[15:51] <herton> ok, the bisect to these general protection faults with chromium etc. points to commit "i387: do not preload FPU state at task switch time" on 3.0.0 stable
[15:51] <herton> I tested precise i386 kernel, and precise doesn't show the issue I reproduce here with oneiric i386 from proposed
[15:52] <herton> bjf, henrix ^
[15:53] <tgardner> herton, that kind of makes sense.
[15:53] <ohsix> do you know what they mean by preload in that message? from what i know of the fpu it's not familiar to me
[15:53] <ohsix> also i don't think they mean restore, or they'd have said that
[15:53] <herton> yeah, especially as we are seeing this only on i386
[15:53] <bjf> herton, is there a subsiquent patch that 3.0 didn't get that 3.2 did ?
[15:54] <herton> bjf, good question, may be we miss something on 3.0 indeed
[15:55] <henrix> bjf: not that i could find it
[15:55] <henrix> bjf: but still looking
[15:57] <tgardner> herton, henrix: the i386 FPU patches were supposed to have address a bug that has existed for awhile, but were only recently uncovered. it could be that the backport isn't correct.
[15:57] <tgardner> or is not needed
[16:02] <herton> yes, the bisect point to the middle of the i387 series, mostly likely is a backport problem
[16:02] <herton> *most
[16:03] <tgardner> herton, how are you reproducing ? 'strace chromium-browser' ?
[16:04] <herton> tgardner, just running chromium, I get segmentation faults after some browsing or in random places, sometimes even lightdm/gnome-session crash on login, before doing anything else
[16:06] <herton> strace/gdb didn't help much
[16:07]  * herton -> lunch
[16:07] <tgardner> herton, I think my reproducer isn't reliable. my bisect ended on 'xhci: Fix oops caused by more USB2 ports than USB3 ports.'
[16:08] <herton> tgardner, I think is a problem in backport of i387 changes, but as my bisect ended in the middle of i387 changes, it may not be a problem specific on that commit
[16:09] <ogasawara> tgardner, herton: so I'm not going to wait on any patches to upload precise to rebuild against the new gcc upload.  I'm thinking we'll have another upload next week anyways (just under our SRU policy)
[16:09] <tgardner> herton, I'll rewind to 'i387: re-introduce FPU state preloading at context switch time' and try that
=== lool- is now known as lool
[16:14] <bjf> herton, lets get some test kernels built and spam those bugs for testing
[16:18] <apw> tgardner, i wonder if you need CPUs which support like aesni or similar before you trigger the need
[16:19] <tgardner> apw, possibly, though I was able to get it lock in poll() several times. perhaps a new bug ?
[16:19] <apw> gawd
[16:19] <apw> its all going to hell
[16:20] <ogasawara> tgardner: you were testing on precise?  or oneiric?
[16:20] <tgardner> ogasawara, oneiric
[16:20] <henrix> fwiw, i wasn't able to reproduced on kvm, running oneiric i386
[16:21] <tgardner> apw: model name	: Intel(R) Core(TM)2 Duo CPU     E6850  @ 3.00GHz
[16:21] <apw> tgardner, that sounds like a proper cpu, so likely has most things
=== infinity1 is now known as infinity
[16:25] <tgardner> herton, immediate seg fault with the FPU patches. I'll try next without
[16:35] <herton> back
[16:36] <herton> tgardner, ok
[16:38] <herton> bjf, yeah I'll put a kernel somewhere without the patch/patches, lets see
[16:39] <tgardner> herton, much more stable without the FPU patches
[16:44] <henrix> there are a few commits upstream related with fpu, but it would take same time to actually understand if they would solve the prob
[16:44] <henrix> the commits are 7e16838, 80ab6f1 and cea20ca
[16:44] <tgardner> I'm not convinced we ever had an FPU state problem in 3.0
[16:45] <henrix> oh, and there is also a SAUCE on oneiric (but not on precise) that may mess things up: 775e6e802597c3f6c334cdaaf8df807dd28c6dd6
[16:47] <tgardner> henrix, IIRC the NX emulation code doesn't change CPU FPU regsiters
[16:47] <henrix> tgardner: maybe not, but it looks like it touches the same source code
[16:49] <herton> tgardner, ok so here is a strange thing. Our commit 1d43fea348a44815c01c5fbd7cf3d29b7b13078d on ubuntu-oneiric, removes one hunk from ubuntu nx-emu changes
[16:49] <herton> +       if (next_p->mm)
[16:49] <herton> +               load_user_cs_desc(cpu, next_p->mm);
[16:50] <henrix> herton: yep, i was looking at that one
[16:51] <tgardner> so lets try a kernel without 775e6e802597c3f6c334cdaaf8df807dd28c6dd6 but with the FPU patches ?
[16:52] <henrix> or with both, but with the FPU refactored to *not* remove the NX-emul code pointed out by herton...
[16:52] <tgardner> henrix, right, we'll have to revert 775e6e802597c3f6c334cdaaf8df807dd28c6dd6, then reapply the FPU patches
[16:53] <herton> yes, I think it's worth to look at, 3.0 stable doesn't remove that hunk as well, as they don't have it. That also may explain why upstream isn't having these issues, at least didn't found reports about it
[16:54] <henrix> herton: do you want me to build the test kernel, or you're already on it?
[16:55] <herton> I'm going to build here a stock -18 first just with the missing hunk added back again, if that fails then remove the patches
[16:55] <henrix> herton: ack
[16:57] <tgardner> herton, while thats building, have a look at precise to make sure we don't have the same problem.
[16:57] <herton> tgardner, ack
[16:57] <henrix> tgardner: precise does not seem to have the NX emul patch
[16:58] <henrix> tgardner: ignore my last comment...
[17:00] <henrix> tgardner: it does have it, and it keeps that code
[17:00] <tgardner> henrix, I have vague memories of doing the precise backport.
[17:02] <herton> yes, precise is ok, it still kept that nx-emu change
[17:05] <tgardner> ogasawara, ^^
[17:05] <ogasawara> tgardner: ack, thanks.  I'm just gonna prep a no-change upload.   gcc is still going to take the majority of the day to build.  so apw will upload in the morning if needed.
[17:06] <tgardner> ogasawara, yeah, looks like the poll() thing might have been a red herring
[17:06] <apw> ogasawara, sounds good
[17:07] <ogasawara> apw: infinity scored up the gcc builds for me, so I'm hoping I might be able to upload before I go to bed tonight.
[17:07] <ogasawara> apw: I'll email you if I do
[17:07] <apw> ogasawara, i will simply check and see if there has been an upload, if not, i'll do it
[17:19] <herton> tgardner, http://people.canonical.com/~herton/fpu_bug/ , if you want to test too, also put there the patch on top of -18 that I applied
[17:19] <tgardner> herton, ack
[17:27] <tgardner> herton, seems pretty good.
[17:31] <herton> yeah, so far is going ok here as well
[17:32] <tgardner> herton, damn, who'd of thunk setting the CS register was that important :)
=== tgardner is now known as tgardner-lunch
=== tgardner-lunch is now known as tgardner
[18:36] <manjo> ogasawara, was seeing a bug where I have 4x4GB DIMs on a UEFI system and I was not able boot past grub, 3X4GB works, DIM in Channel A DIM1 causes boot to hang... bryceh told me there is some known fix for it ... you have any idea when we will get that fix ?
[18:37] <ogasawara> manjo: hrm, no clue.  do you have any additional info, like a sha1 or commit message for the "fix"?
=== bladernr_ is now known as bladernr_afk
[18:37] <manjo> ogasawara, no have not looked ... but bryceh was suggesting that there might be a known fix... thought I will ask before I dig
[18:38] <ogasawara> manjo: you'll probably have dig as it's not ringing a bell here
[18:39] <manjo> ok
[18:39] <bryceh> manjo, sorry, bug 961482 was the one I ran into; it's already fixed
[18:39] <ubot2> Launchpad bug 961482 in linux "3.2.0-19 kernel fails to boot (-18 OK)" [Critical,Fix committed] https://launchpad.net/bugs/961482
[18:42] <manjo> bryceh, np ... I am starting to dig into it now ... 
[18:42] <manjo> bryceh, was worth a shot ... could have saved me some cycles
[18:42] <manjo> :) 
[19:57]  * tgardner -> EOD
[20:24] <martinphone> hi
[20:24] <martinphone> can you explain why the sudden change from current 3.0.0.18 to 3.2?
[20:25] <martinphone> when 12.04 is released I mean
[20:25] <martinphone> Where is 3.1?
[20:26] <JanC> martinphone: Ubuntu releases happen every 6 months, while kernel releases happen about every 3 months
[20:27] <martinphone> JanC, then why does my machine update to 3.0.0.18 and not to a 3.1 something?
[20:27] <JanC> so the kernel got 2 new releases between 11.10 & 12.04
[20:27] <martinphone> by today's date it should be a 3.1, shouldnt it?
[20:29] <JanC> once released you don't get new kernel versions (although I'm pretty sure your 3.0 kernel has some bugfixes backported from 3.1)
[20:30] <martinphone> janc, certainly not for the sake of stability: 3.0.0.18 6 segfaults in a row forced me to go back to 3.0.0.17, the one in use now
[20:30] <martinphone> incidentally
[20:30] <JanC> martinphone: I hope you filed a regression bug report about that then
[20:31] <martinphone> If I nuke my machine and do a fresh 12.04 install, how many kernels will be installed? just 3.2? some previous ones I can use in case the last ones are unstable?
[20:32] <martinphone> JanC, im pretty sure another user I coincided with, who had the same problem, did that
[20:33] <JanC> if you do a 12.04 install, it will have the 3.2 kernel that is on the install media
[20:34] <bjf> martinphone: have you filed a bug on the -18 segfaults, we have several reports of similar issues
[20:34] <martinphone> bjf, no, should I?
[20:34] <martinphone> if you already have several....
[20:34] <bjf> martinphone: yes because your's may in fact be different
[20:35] <martinphone> link please, I have never done this before
[20:35] <bjf> martinphone: is yours an i386 install ?
[20:35] <martinphone> yes
[20:35] <JanC> and finding the reason is easier if you see what all those affected have in common
[20:35] <bjf> martinphone: i have a kernel for you to try, one sec.
[20:35] <martinphone> bjf, no need, really, Im waiting for the stable relsease of 3.2
[20:35] <martinphone> then ill nuke
[20:36] <martinphone> bjf, and 3.0.0.17 is stable
[20:36] <bjf> martinphone: it would help if you could try: http://people.canonical.com/~herton/fpu_bug/
[20:36] <JanC> martinphone: but by testing you can help fixing things for other people
[20:36] <martinphone> me? testing?
[20:36] <martinphone> my craptop is not the best option
[20:37] <JanC> "crap" is the best to test on  ;)
[20:37] <martinphone> lol
[20:37] <martinphone> with my level of computing i wouldnt be an asset
[20:38] <bjf> martinphone: it's the reason regressions happen though, lack of testing on a wide variety of HW
[20:38] <JanC> martinphone: just test if bjf's kernel fixes your segfaults
[20:38] <martinphone> ok, downloading 35.2mb
[20:38] <JanC> if it does work for you and several others, they can release that as a fix
[20:39] <martinphone> i suddenly feel important
[20:39] <JanC> if it doesn't fix things, they can throw it away instead  ;)
[20:39] <JanC> martinphone: testers *are* important  ☺
[20:40] <JanC> and "crowdsourcing" is how open source gets testers!
[20:40] <martinphone> yeah, Im the man :)
[20:40] <JanC> also, think about it as contributing back (or "paying" for Ubuntu/linux)
[20:40] <bjf> martinphone: look at http://pad.lv/973637 and see if that's similar to what you are seeing
[20:42] <martinphone> bjf, very similar: I can actually start chromium, but it , eventually, will segfault
[20:42] <bjf> martinphone: if so, you can click on the "affects me" link
[20:42] <bjf> martinphone: after testing, add a comment at the bottom if it helped or not
[20:45] <martinphone> im only accepting cause in 3 weeks ill nuke this thing
[20:45] <martinphone> brb
[20:55] <martinphone> segfault
[20:56] <martinphone> back int 3.0.0.17
[20:59] <bjf> martinphone: thanks for testing
[21:00] <martinphone> meh
[21:00] <JanC> martinphone: don't "meh", even failed tests are important
[21:01] <martinphone> if you say so...
[21:01] <JanC> martinphone: they are sometimes more important than successful ones  ☺
[21:01] <martinphone> what do you use to insert those plain emoticons JanC ¿
[21:01] <martinphone> ?
[21:03] <JanC> xchat has a feature that allows replacing text, so I let it replace ":)" with ☺
[21:03] <JanC> but that's off-topic here
[21:10] <martinphone> offtopic, you mean you will kick me out if I keep asking about it?
[21:13] <JanC> martinphone: I can't kick you out, but I just meant that we shouldn't keep discussing xchat/unicode features here (it's not kernel-related)
[21:15] <JanC> so feel free to PM me or something (although it's 23h15 here, so I'll be off to bed probably ;) )
[21:15] <martinphone> JanC, are you in windows?
[21:18] <JanC> martinphone: if you mean MS Windows, no (I have no computers with that OS)
[21:18] <JanC> anyway, off to bed...
[21:19] <martinphone> JanC, in xchat they told me that the function you are using is only for windows
[21:19] <martinphone> nite nite
=== yofel_ is now known as yofel
[22:35] <slangasek> ogasawara: bug #919281 is a packaging bug that it's rather important to have fixed for 12.04.0; can that be squeezed into the next upload?
[22:35] <ubot2> Launchpad bug 919281 in linux "devmapper kernel modules missing from precise server cd" [Critical,Triaged] https://launchpad.net/bugs/919281
[22:36] <atpa8a> hello
[22:36] <atpa8a> filed the bug 972960...
[22:36] <ubot2> Launchpad bug 972960 in linux "md fails during install [kernel BUG at /build/buildd/linux-3.2.0/drivers/md/md.c:6920!]" [High,Confirmed] https://launchpad.net/bugs/972960
[22:37] <atpa8a> seems like it's what (as i understand it) is external metadata with one of my dmraid arrays
=== bladernr_afk is now known as bladernr_