[00:37] <ohsix> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/793796 i filed a bug about it, if anyone has appropriate tags to add; or people to subscribe
[00:37] <ubot2> Ubuntu bug 793796 in linux "2.6.38-10 panic after ejecting drive" [Undecided,New]
[00:53] <ohsix> woo confirmed, i wonder if someone was waiting for a report :D
[08:07] <apw> ohsix, the confirmed update was likely a bot
[08:07] <apw> ohsix, can you get the picture attached to the bug please
[08:07] <ohsix> i attached one, did it not make it?
[08:09] <apw> ohsix, bah you did, stupid interface hiding it from me
[08:10] <ohsix> there were only 2 scsi/block/vm patches in the changelog that might have something to do with it but none that i can see how
[08:12] <ohsix> you can probably reproduce it easily enough; it's on x86_64 but i don't know if that matters
[08:12] <apw> ohsix, yep i am sure they will, i've seen similar on .39, but neither of those boxes boot at the moment
[08:12] <apw> i've tagged it up for the stable peep to sort out
[08:13] <ohsix> i was trying .39 from the xorg-edgers ppa for other reasons & hit it a week or two ago; didn't report a bug but i did tell one of the guys on top of that stuff
[08:21] <jussi> Morning all
[08:23] <jussi> Ive managed to reproduce https://launchpad.net/bugs/792291 and the machine is still on, is there anyone about that can help me get anything out of the machine to help debug? 
[08:23] <ubot2> Ubuntu bug 792291 in linux "Machine hung, display frozen" [Undecided,Confirmed]
[08:27] <apw> jussi, do you know what you did to reproduce it?  if so record that
[08:27] <apw> i seem to remember we didn't know if the machine is still alive on the network or not, you could try and determine that
[08:28] <jussi> apw: unfortunately not, its happened several times, at random intervals.
[08:28] <jussi> apw: let me try
[08:29] <jussi> Hrm, Ive no idea of that machines ip (we have a dhcp system here), but the network lights near the cable are still blinking
[08:29] <apw> jussi, if you know the machine name, name.local often works as a hostname on the local lan
[08:30] <jussi> yeah, it doesnt appear to be reponsive
[08:31] <apw> jussi, and you have tried the sysrq options out?
[08:32] <jussi> ahh, reisub rebooted it. 
[08:33] <apw> jussi, so in theory you may have some output in your logs sync'd to disk maybe, cirtainly worth looking now
[08:33] <apw> jussi, and record that reisub did something too
[08:33] <jussi> apw: ok. which logs in particular are wothe looking at ?
[08:34] <apw> syslog contains the output of dmesg if we are lucky
[08:34] <apw> looknig for sysrq may help
[08:34] <smb> morning
[08:34] <apw> smb, moin
[08:35] <apw> jussi, was this the one with a moving mouse cursor ?
[08:35] <jussi> apw: no, total freeze, different machine
[08:36] <jussi> is it safe to pastebin the syslog? 
[08:36] <apw> jussi, has this problem aways existed on natty?
[08:36] <apw> (trying to work out where it might have been introduced)
[08:36] <jussi> apw: we only bought/installed the machine a few weeks ago, and it has happened several times since
[08:36] <apw> jussi, i think pastbin is ok, you could grep for your password and name before
[08:37] <apw> jussi, ok so we have no idea if its a regression
[08:37] <apw> jussi, was there anything interesting in syslog ?
[08:38] <jussi> apw: Im looking, but let me share it with you also, because Im not certain what to look for.
[08:41] <ohsix> jussi: are you running 2.6.38-10 on that?
[08:42] <jussi> ohsix: no, 2.6.38-8 (x86_64)
[08:45] <apw> Jun  7 10:32:05 monster kernel: [81028.414275] SysRq : Keyboard mode set to system default
[08:45] <apw> Jun  7 10:32:07 monster kernel: [81029.756536] SysRq : Terminate All Tasks
[08:45] <apw> ok so the machine was alive per-se
[08:45] <apw> as the logging deamons saw the sysrq keys and reported them
[08:46] <apw> so that is useful information and should be recorded in the bug
[08:47] <jussi> apw: Ill attach that syslog if you think its useful (and doesnt contain too personal stuff)
[08:47] <apw> jussi, also the fact there isn't any panic before the Sysrq
[08:47] <jussi> right, so its likely not in the kernel then.
[08:47] <apw> jussi, include like 5 lines before the SysRQ and the first couple of sysrq things
[08:47] <apw> jussi, its as likely X i'd guess
[08:48] <apw> so next time jussi could you do the sysrq-R then try to switch VTs
[08:48] <apw> and also then try Sysrq-w, to see if anything is hung
[08:48] <apw> then perhaps Sysrq-t
[08:48] <jussi> apw: ok, sure.  Thank you for taking the time to help. 
[08:49] <apw> now the latter will take a while likely, you should be able to see it producing disk activity i suspect as the logs are being pulled out
[08:49] <apw> (maybe leave it for 1min after then continue with the reisub)
[08:49] <apw> then look for those in your syslog and see hwats there
[08:50] <jussi> apw: excellent. Ill note that down for next time something happens. 
[08:55] <apw> jussi, good luck
[08:56] <jussi> apw: Thanks - I think Ill need it. :D
[08:57] <apw> jussi, i've recorded that in the bug for posterity
[08:59] <jussi> apw: excellent! :D
[09:01] <Kano> hi, where are the daily builds? also 3.0-rc2 is missing
[09:05] <apw> Kano, they are missing because some fool changes the version number radically and breaks every damn tool we have
[09:06] <Kano> well that was done with rc1, no time to fix em yet?
[09:07] <apw> yes we fixed it in part last time, but not comopletely it seems
[09:10] <ohsix> haha
[09:12] <Tommeh> There was some discussion on the release announcement about the tarball being screwed, at least originally.
[09:12] <Tommeh> Presumably the kernels are built straight from git though?
[09:12] <apw> Tommeh, luckily we don't use the tarballs
[09:13] <Tommeh> ah
[09:13] <apw> but we are getting hammered by the tags not being v2.6.*
[09:20] <cking> what fun
[09:21] <apw> i know ... and right now i can't build them with the right version as module-init-tools specifically depmod won't work
[09:21] <apw> ARRRRG
[10:17]  * apw bounces to verify a unity bug which someone has FIXED !?!
[10:23] <amitk> lol
[10:28] <apw> seems to work too ... amazing, shame i have found another new bug now
[10:28] <jk-> hey apw
[10:28] <apw> jk-, hiya
[14:26] <tgardner> apw, ogasawara, AceLan: tangerine needs a reboot for kernel update. lemme know when is a good time.
[14:26] <apw> tgardner, don't believe i am using it currently
[14:27] <ogasawara> tgardner: am in the middle of a quick build, will ping you when it's done
[14:27] <ogasawara> apw: I'm hopefully zeroing in on the bad commit for the hp mini
[14:28] <apw> ogasawara, awsome, bisecting ?
[14:28] <ogasawara> apw: yep.  your mainline-build-one script comes in handy
[14:28] <apw> :) thats something
[14:30] <ogasawara> I went ahead and pushed the -rc2 rebase to master-next, if anyone wants it
[14:38] <apw> ogasawara, i assume its no more working than before
[14:38] <ogasawara> apw: nope, still the same
[14:40] <ppisati> tgardner: rsu added
[14:40] <ppisati> *SRU
[14:40] <tgardner> ppisati, ack
[14:43] <ogasawara> tgardner: your good to reboot tangerine from my end
[14:44] <tgardner> bouncing
[14:44] <apw> you're
[14:46] <ogasawara> damn, you know it's bad when apw corrects your misspelling :)
[14:46] <apw> ogasawara, an embaressment indeed
[14:46] <ogasawara> hehe
[14:47] <tgardner> ogI just figured apw had blurted a sentence fragment
[14:47] <tgardner> ogasawara, ^^
[15:02] <ppisati> thunderbid formatting of emails is really annoying
[15:02] <ppisati> i can't make a message without stupid formatting...
[15:03] <sforshee> tgardner, ogasawara: can one of you accept my natty nomination on bug 770232 ?
[15:03] <ubot2> Launchpad bug 770232 in linux-firmware "148f:3072 Ralink RT3072 WLAN not working with rt2800usb - firmware missing" [Undecided,Incomplete] https://launchpad.net/bugs/770232
[15:04] <tgardner> sforshee, done
[15:04] <sforshee> tgardner, thanks!
[15:37] <bjf> ##
[15:37] <bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:37] <bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
[15:37] <bjf> ##
[15:47]  * ogasawara back in 20
[16:02] <apw> ppisati, remind me, mvl-dove is identicle in lucid and maverick isn't it, and we update lucid
[16:05] <ppisati> apw: yep
[16:05] <ppisati> apw: i think tomorrow i'll do the rebase
[16:05] <apw> ppisati, whenever, just interested for a cve i am finishing up
[16:23] <apw> tgardner, about ?  i see we don't have armel cross compilers in our lucid chroots on tangerine, is this something we can get easily from somewhere?
[16:24] <tgardner> apw, I'm not sure they exist for Lucid unless we pull the deb from Maverick
[16:24] <apw> oh hrm, bugger
[16:25] <tgardner> herton, please have a look at bug #794096. It loooks like it could be a stable update regression.
[16:25] <ubot2> Launchpad bug 794096 in linux "SMTP and posting to a web-form time out (probably due to netfilter changes)" [Undecided,In progress] https://launchpad.net/bugs/794096
[16:25] <herton> tgardner: ack
[17:08]  * herton --> lunch
[17:16] <apw> smb, about?  got a sec to review a debdiff for m-i-t for me ?
[17:16] <smb> apw, currently taken up in server meeting 
[17:16] <smb> a min
[17:16] <apw> smb np
[17:18] <smb> apw, k, they moved on. what where?
[17:18] <apw> chinstrap:~apw/DEBDIFF
[17:33] <apw> HRM somethign bad happened when i right clicked on a link
[17:33] <apw> X exited
[17:44] <bjf> ##
[17:44] <bjf> ## Kernel team meeting in 15 minutes
[17:44] <bjf> ##
[17:45] <cking> already? where did the day go?
[17:45] <ppisati> yep
[17:53] <ogasawara> bah, it helps if I actually install the test kernel I downloaded before I reboot
[17:54] <bjf> ##
[17:54] <bjf> ## Kernel team meeting in 5 minutes
[17:54] <bjf> ##
[18:00] <smb> Gah! its time
[18:05] <Sarvatt> smb: a minute later and you would have missed the meeting :)
[18:06] <smb> Sarvatt, Too true. :)
[18:43] <ogasawara> apw: cool, I've isolated the regression
[18:43] <ogasawara> commit 6067aaeadb5b3df26f27ac827256b1ef01e674f5
[18:43] <ogasawara> Author: Jesse Barnes <jbarnes@virtuousgeek.org>
[18:43] <ogasawara> Date:   Thu Apr 28 15:04:31 2011 -0700
[18:43] <ogasawara>     drm/i915: split clock gating init into per-chipset functions
[18:43] <ogasawara>     
[18:43] <ogasawara>     This helps contain the mess to init_display() instead.
[18:43] <ogasawara> apw: and it appears there's already a fix coming down the pipe
[18:43] <ogasawara> apw: https://lkml.org/lkml/2011/6/5/12
[18:43] <ogasawara> apw: gonna build us a test kernel to verify
[18:48] <bjf> ogasawara, i just modified the moin paragraph levels that kt-meeting-stats generates, be sure to use the latest version
[18:48] <ogasawara> bjf: ack
[19:03]  * tgardner --> lunch
[19:16] <apw> ogasawara, awsome, let me have some test kernels when you've tested :)
[19:27]  * apw waits with baited breath for ogasawara's testing results
[19:58] <ogasawara> apw: \o/, it works.  debs are on tangerine in my oneiric-i386 dir
[19:59] <tgardner> ogasawara, this is for an HP mini?
[19:59] <ogasawara> tgardner: yep
[19:59] <ogasawara> tgardner: am gonna push the fix to master-next
[19:59] <tgardner> ogasawara, cool, I'll give it a try as well.
[20:01] <ogasawara> apw: if you can, would you also test on the other atom kit you said was having issues with -rc1.  just curious if it's still there with an -rc2 kernel.
[20:07] <apw> ogasawara, i've got both 32 and 64 bit suffering, got and 64bit debs ?
[20:07] <ogasawara> apw: I'll kick off a build right now
[20:21] <apw> ogasawara, good on my 32 bit machine (not the mini)
[20:21] <apw> yell when we have amd64s
[20:21] <ogasawara> apw: should almost be finished up
[20:21] <ogasawara> apw: it'll appear on tangerine:oneiric-amd64
[20:23]  * jjohansen -> lunch
[20:23] <apw> ogasawara, i'll watch for it
[20:26] <ogasawara> apw: generic flavour should be there now
[20:33] <tgardner> ogasawara, how come you aren't using 3.0.0-0.1 in the oneiric changelog ? There are still 3 version digits in the Makefile
[20:34] <apw> tgardner, cause it isn't going to be called 3.0.0 but 3.0 when it releases
[20:34] <apw> tgardner, and if we use 3.0.0 we can't go back down to 3.0 which is <
[20:35] <apw> he only put the extra .0 in the makefile cause you couldn't build it without it at the time
[20:35] <tgardner> apw, but this is a packaging version thats only loosely related to the kernel version.
[20:36] <apw> tgardner, that is true, but we were trying to continue the current system which is to use the version before stable 
[20:37] <tgardner> apw, and I suspect the first stable version will be 3.0.1, right?
[20:37] <apw> tgardner, yep, but we don't expose the stable version in our package version
[20:37] <apw> 2.6.38.8 is still 2.6.38 in the archive
[20:38] <tgardner> apw, right, as will 3.0.0-ABI-N
[20:39] <tgardner> it will simplify a lot of our scripting problems if we use 3 digits.
[20:39] <apw> tgardner, we can do that, its just a change in meaning
[20:39] <apw> tgardner, though all the scirpting issues we have look to be cause we have Ubuntu-2.6 as searches and the like
[20:39] <apw> not so much because of the length of the prefix right ?
[20:40] <tgardner> apw, well, I was thinking about the regexes that extract ABI and the like
[20:40] <apw> they should be using the 'before' and 'after' really
[20:41] <apw> they should be using the 'before' and 'after' the - really
[20:41] <tgardner> apw, perhaps, but fixing them in all places will be a PITA
[20:42] <apw> tgardner, i think that most of it is working now, that isn't using 2.6 as far as i can tell
[20:42] <tgardner> I'm thinking about the LTS backports as we go forward.
[20:43] <tgardner> All of our Lucid stuff wants 3 digits. (I just don't know where yet)
[20:43] <apw> the lts backports carries the whole changelog and debian machinary with it no?
[20:43] <apw> the only thing which needs a little love is depmod and that is easy to fix
[20:43] <tgardner> likely, but its easy to avoid the 'noid by just carrying the 3rd digit. I hate inconsistencies and special  cases
[20:44] <apw> well it feels like an inconsistancy to represent 3.0 with an extra digit and not 2.6.x
[20:45] <apw> but i am happy to be persuaded
[20:46] <tgardner> well, lets see how it goes. we've got a little time before things get cast in concrete
[20:46] <apw> tgardner, as long as we start with 3.0 we can move 'up' to 3.0.0, the inverse is not possible
[20:48] <apw> ogasawara, ok this looks good for me, i'll get these two uploaded together and tested, then we can upload to the archive in the morning
[20:48] <ogasawara> apw: ack, sounds good
[21:15] <Guest24499> hi - just installed natty.  would like to try out xen - any pointers?  I last tried xen about a year ago, but heard that the 4.1 is much better
[21:16] <Guest24499> google points me to pages that require manual kernel config/make
[21:16] <Guest24499> is this the right place to ask?
[21:19] <apw> Guest24499, i am not sure that the .38 kernel has all the pieces you need to for a dom0 kernel which makes it hard to do
[21:19] <Guest24499> previous versions of ubuntu has xen-dom0 kernels - natty doesn't have it?
[21:21] <jjohansen> Guest24499: hardy was the only kernel that had all the pieces for xen-dom0
[21:21] <Guest24499> ahh
[21:21] <jjohansen> they have all had the domU pieces
[21:21] <Guest24499> I guess I was lucky when I last tried xen I hit hardy :)
[21:22] <jjohansen> the oneiric kernel (11.10) will have the pieces for dom0 and domU
[21:22] <Guest24499> should I try 11.10 then?  is it even in beta yet or in a position to be used?
[21:22] <jjohansen> Guest24499: its because since hardy we have tried to follow upstream, where in hardy we had a special xen kernel
[21:23] <jjohansen> Guest24499: its not in beta yet, and the upstream 3.0 kernel that has all the domo pieces is at rc2
[21:23] <jjohansen> and uhm isn't the most stable thing at the moment
[21:23] <Guest24499> so, would it be a good idea to follow https://help.ubuntu.com/community/Xen and compile my own kernel?
[21:23] <jjohansen> at least from my experience
[21:23] <Guest24499> heh.
[21:24] <jjohansen> Guest24499: you could, or you could try the oneric kernel
[21:24] <Guest24499> man, linux has changed so much from my slackware days...
[21:24] <jjohansen> Guest24499: just don't expect all the bugs to be ironed out yet
[21:25] <Guest24499> so the oneric kernel should be ok for dom0?
[21:27] <jjohansen> Guest24499: yes it should
[21:28] <Guest24499> any pointers or URLs for a quick howto to pin a oneric kernel to natty?
[21:28] <jjohansen> I would just download and install the package
[21:28] <jjohansen> dpkg -i <package-name>.deb
[21:29] <jjohansen> Guest24499: packages can be found on packages.ubuntu.com
[21:30] <Guest24499> ok, thanks
[21:30] <jjohansen> just search in oneiric for linux
[21:34] <Guest24499> umm, I'm in http://packages.ubuntu.com/oneiric/kernel - don't see any kernels?
[21:36] <jjohansen> http://packages.ubuntu.com/oneiric/linux
[21:36] <jjohansen> Guest24499: ^
[21:37] <Guest24499> ahh, in admin
[21:37] <Guest24499> not in kernel
[21:37] <tgardner> ogasawara, so, how are you building this oneiric pile ? I'm getting some really weird errors. 'WARNING: Couldn't open directory /home/rtg/oneiric/ubuntu-oneiric/debian/linux-image-3.0-0-generic//lib/modules/2.6.38-10-server: No such file or directory'
[21:38] <ogasawara> tgardner: using the kteam-tools buildscripts.  but a usual fakeroot debian/rules binary-generic should work too
[21:39] <tgardner> ogasawara, thats what I'm doing. hmm
[21:41] <tgardner> ogasawara, are you keeping a log of your builds? I'm thinking this might be some fallout due to the 2 digit version number. to whit: 'Missing argument in printf at debian/scripts/abi-check line 174.'
[21:42] <ogasawara> tgardner: yep, look on tangerine:oneiric-amd64/build.log
[21:42] <ogasawara> tgardner: you have apw's patches to fix up the version?
[21:43] <tgardner> ogasawara, no, I just pulled from the repo.
[21:43] <apw> tgardner, that is the bug with depmod, you need an up to date m-i-t in the chroot
[21:44] <tgardner> apw, ah, thats it
[21:44] <apw> tgardner, tangerine in my home are some fixed ones
[21:45] <tgardner> apw, which one ?
[21:45] <apw> once they are built in my PPA i'll be uploading them to the archive
[21:45] <tgardner> 3.13-1ubuntu1~test4 ?
[21:45] <apw> those sound right yes
[21:46] <apw> module-init-tools_3.13-1ubuntu1~test4_amd64.deb
[21:46] <apw> module-init-tools_3.13-1ubuntu1~test4_i386.deb
[21:46] <apw> those are the right ones
[21:53] <apw> ogasawara, this kernel is looking nice, am pretty sure my fans are on less
[21:54] <ogasawara> apw: definitely in much better shape than we were a few days ago
[21:56] <apw> ogasawara, yeah ... 
[22:13] <tgardner> ogasawara, LKML: Re: 3.0.0-rc2 fails to boot on Atom appliance (bisected, drm/i915)
[22:15] <ogasawara> tgardner: thanks will take a look
[22:16] <tgardner> ogasawara, looks like you bisected to the same patch
[23:35] <kees> apw, ogasawara: bug 771445 in hardy (commit 5caf3ae4c4bed98bd6148021e6e934d94b5dea1d) mentions "backport of commit 272b62c1f0f6f742046e45b50b6fec98860208a0" but it is actually a backport of commit b00916b189d13a615ff05c9242201135992fcda3. the resulting hardy kernel is fine, but we have now a tracking glitch. how should we handle this?
[23:35] <ubot2> Launchpad bug 771445 in linux-ti-omap4 "CVE-2010-4655" [Undecided,In progress] https://launchpad.net/bugs/771445
[23:37] <apw> kees, hrm, thats a bit of a problem, i suspect we need an exceptions table for my match up tool
[23:38] <apw> kees, to handle that ... let me think about it
[23:38] <kees> apw: okay, cool.
[23:38] <apw> i think only my tool needs to handle any errors
[23:39] <kees> well, it's a bit odd since I'll only discover this when comparing u-c-t against the changelog. in this case I found an extra CVE in the changelog and went looking for it, at which point we can add exception maps, etc
[23:41] <apw> kees, yeah, but i suspect there will be more than one error in there over time
[23:41] <apw> and i've already wanted to mark an old commit as being a cherry-pick when it wasn't which would use the same
[23:41] <apw> mapping table.
[23:41] <apw> anyhow will let the shower brain think about it
[23:42] <apw> i fear my tooling will keep unding any corrections otherwise