[08:38]  * apw waves
[08:38]  * smb waves back
[08:39] <apw> bah this UDS-lag sucks
[08:39] <smb> Like a week of travel. :)
[08:39] <apw> LOl
[08:39]  * apw pokes lag
[08:40] <smb> apw, lag?
[08:40] <smb> apw, Or you look for naga
[08:41] <smb> Which seems to be the same
[08:41] <smb> Doh!
[08:41]  * apw watches the cogs turn
[08:42] <lag> apw: I thought you called me =:-(
[08:42] <lag> apw: Oh, you did!
[08:42] <lag> Hello all
[08:42] <smb> lag, Indeed he did. Hello
[08:43] <lag> smb: Hello yourself :)
[08:43] <apw> called is a little overstated, i more jiggled the cage to see if you lived
[08:43] <lag> I assumed you were reminded of my existence by your UDS comment 
[08:44] <apw> heh, no, it was on my mind anyhow... after t
[08:44] <lag> Yes, I've been here since 7:30hrs (ish)
[08:44] <apw> the discussion at UDS of how hungover we all will be after UDS
[08:44] <apw> the week which follows is always low energy
[08:45] <lag> I had a similar week on my holiday 
[08:45] <lag> This week will be de-tox 
[08:50]  * apw needs a cuppa ... this is going to be hard day
[08:53] <amitk> welcome lag 
[08:54] <lag> amitk: Thank you - It's good to be here
[08:54] <lag> all: How did UDS go?
[08:57] <apw> lag, a log hard slog, but i for one thought i had a very productive week
[08:58] <smb> Hey amitk and cking 
[08:58] <apw> if you are interested in the sessions you can see the schedule: http://summit.ubuntu.com/uds-m/
[08:58] <cking> morning!
[08:59] <apw> cking, lag (lee), lag, cking (colin troll)
[08:59]  * apw does intros
[08:59] <apw> not so easy to grok without the hand to wave about
[08:59] <lag> I believe we've met
[08:59] <lag> (I called him eking =;-) )
[09:00] <apw> heh
[09:00] <lag> cking: Good morning 
[09:00] <cking> lag, good morning! and welcome!
[09:00] <apw> lag, you'll be interested in the stuff on the Kernel track and Ubuntu_on_ARM tracks i be reconing
[09:00] <amitk> hey smb, apw, cking
[09:01]  * apw smiles at amitk 
[09:01] <apw> (thats about the only bit of me which is working)
[09:01] <lag> apw: Looking at the schedule now
[09:01] <cking> lag, you got the necessary info to get up and running?
[09:02] <lag> cking: Not yet - waiting on IS
[09:02] <cking> lag, that sounds familiar
[09:02] <amitk> they're probably backed up because of UDS
[09:03] <apw> lag, the root of our team documentation is (currently) here https://wiki.ubuntu.com/KernelTeam/KnowledgeBase
[09:03] <apw> if you run out of things to do/read on your list you can start reading on there
[09:03] <apw> we try and get all new people to learn the basics so they know why we do things
[09:03]  * lag thanks apw
[09:04] <cking> ..and please ask us questions!
[09:04] <lag> "A very good place to start..."
[09:04] <lag> cking: Don't fear. I am not adverse to asking (stupid) questions 
[09:04] <apw> yep.  our docs are crap, you are expected to not find the information you need, and ask for help, and _required_ to update the docs to fix them
[09:05] <apw> it being a wiki and all
[09:05] <Daviey> apw: Talking of things to do.. :)  At UDS i spoke to you about Bug #576601, it's got 24 "me too's" and would like to try and get it moving - but not sure how to proceed.
[09:05] <ubot3> Malone bug 576601 in linux "mcp89 sata not detected" [Undecided,New] https://launchpad.net/bugs/576601
[09:05]  * lag shudders at the thought of documentation 
[09:05]  * apw curses apple under his breath
[09:06]  * Daviey curses louder.
[09:09] <apw> Daviey, does this machine work on Lucid ?
[09:10] <Daviey> apw: no
[09:10] <Daviey> apw: Boooting via non-SATA works.. ie USB.. 
[09:11]  * apw dropships you a fast usb stick :)
[09:11] <Daviey> The COMRESET in the BootDmesg seems the interesting part.
[09:11] <Daviey> apw: Yeah.. that sucks :)
[09:12] <apw> Daviey, yep, looks a lot like a broken sata chipset
[09:12] <apw> [   61.181006] applesmc:  - Model with 12 temperature sensors
[09:12] <apw> what a waste of h/w
[09:15] <Daviey> and a light on the lid isn't a waste of electricity either! :)
[09:15] <apw> and you bought this bundle of joy why?
[09:16] <Daviey> IBM/Lenovo annoyed with aftersales of my current laptop, Dell wouldn't deliever until June, and a friend told me it would be the BEST descision i had ever made..  Oh, and it's shiny!
[09:17] <Daviey> Doesn't mean i'm sold on the idea. :)
[09:17] <cking> Daviey, tried libata.force=1.5Gbps?
[09:18] <Daviey> cking: purely that option?
[09:18] <cking> it's just a guess
[09:19]  * apw suspects the friend needs a macbook sepository
[09:19] <apw> cking, didn't know you could do that, interesting
[09:20] <apw> smb, rember those ones which do something similar, where 'waiting for a bit' makes the issue go away
[09:20] <apw> Daviey, i think we saw that if you waited long enough you get to a busy box prompt
[09:20] <apw> we have found in some cases that simply asking the machine to boot from there sometimes works, and it would be good to try that test
[09:20] <Daviey> apw: i tried rootwait and rootsleep=260  , however it was
[09:20] <smb> apw, You mean the rootdelay stuff?
[09:21] <apw> smb, yeah
[09:21] <Daviey> oh yes, rootdelay, not rootsleep
[09:21] <smb> 260 "should" be long enough
[09:22] <cking> hrm, another heck to remember
[09:22] <cking> s/heck/hack
[09:22] <Daviey> ok, i'll try the speed force.
[09:26] <apw> cking, i suspect that is not going to work as we claim to be doing after a bit
[09:26] <apw> [ 56.122620] ata1: COMRESET failed (errno=-16)
[09:26] <apw> [ 56.122680] ata1: limiting SATA link speed to 1.5 Gbps
[09:27] <Daviey> cking: no dice on the speed limit.
[09:27] <cking> rats
[09:27] <Daviey> apw: I do get a busybox.. but no sata
[09:28] <apw> busy box just means no disks in this context
[09:28] <apw> how is the disk controller described in lspci (if busy box has it)
[09:29] <Daviey> bah.. i just crapped out of it.. /me reboots
[09:31] <apw> man this machine is a living nightmare h/w wise, how much closed unsupported components can you put in one box
[09:31] <apw> shiney or not
[09:32] <Daviey> apw: booting via usb, everything does seem to work except sata
[09:33] <Daviey> lspci isn't in busybox :(
[09:35] <lag> daviey: Is this any good to you? ftp://ftp.kernel.org/pub/software/utils/pciutils/
[09:36] <lag> Sorry "Daviey" - Is the nick alert case sensitive? 
[09:39] <Daviey> nah :)
[09:39] <lag> Daviey: It's not good to you, or nick alert isn't case sensitive? 
[09:40] <apw> Lag ...
[09:40] <lag> apw: Nothing
[09:40] <Daviey> nick alert not case sensative
[09:40] <lag> again
[09:41] <Daviey> apw: networking isn't up, is BusyBox gaining me anything that i wouldn't get in a live enviroment?
[09:41] <Daviey> apw: Sorry, i went afk
[09:41] <apw> Daviey, probabally not no
[09:42] <Daviey> apw: In that case, isn't lspci the same as the one on the bug report?
[09:50] <apw> Daviey, maybe maybe not, you didn't put it in right?  i don't trust your two apples to be one and the same
[09:51] <Daviey> apw: Hmm.. ok. I'll compare it with mine today, and upload it if it diff's
[09:51] <apw> i have learned not to trust any vendors to tell us when they skew a machine
[09:51]  * smb is slowly waking and congratulates cking for having no critical mass incidents on his way home
[09:51] <Daviey> apw: I do know someone else bought one on the same day, from the same supplier.. so we can certainly prove them identical.. Unless one of them includes special Jobs fairy dust. :)
[09:52] <cking> smb, we had a delay of 50 mins, but no asteroid strike or earthquake - so it was a good return trip
[09:53] <smb> cking, Good to hear.
[09:53] <smb> (actually knew since apw was home by the time I was)
[09:54] <apw> heh, i could have been home, though i was out at a pub as it was a friends hen-do
[09:54] <cking> smb, thanks again for driving us to the station
[09:54] <smb> apw, Isn't that "sort of" home :-P
[09:54] <apw> yeah much appreciated, specially the 1.40 beers
[09:54] <apw> *slap*
[09:55] <smb> cking, apw No worries. Was a good time, too. :)
[09:55] <smb> apw, I was hiding. Not sure who you hit. ;-)
[09:56] <amitk> apw: hen-do?
[09:56] <apw> amitk, womans stag-do
[09:57] <smb> amitk, Don't ask. It will certainly involve funny dressing and lots of beer
[09:57] <cking> that's infinitely clearer
[09:57] <amitk> lol
[09:59] <apw> celebration/commisseration of the upcoming lack of freedom engendered by marriage.  generally as indicated by playing games and getting very drunk and falling over
[10:01] <apw> yay the ask is back
[10:02] <jk-> morning
[10:02] <jk-> .. or something
[10:02] <cking> apw, the ask?
[10:02] <smb> jk-, Definitely .... something
[10:02] <cking> jk-, good [morning|aftenoon|evening]
[10:03] <amitk> more like, good whatever
[10:05] <jk-> or maybe good `warning: enumeration value not handled in switch`
[10:06] <apw> cking, ash
[10:06] <apw> jk-, erm, what you doing up at this time
[10:06] <apw> jk-, heh
[10:06] <jk-> apw: so UK hen's dos include men too?
[10:06] <apw> jk-, not commonly, but this one did include all her friends
[10:07] <smb> jk-, Or apw is honours woman (or whatever thats called)
[10:08] <apw> honary woman
[10:08] <smb> apw, Ah ok. :) At least there now should be enough wigs around, too. 
[10:09] <apw> smb, and boobies
[10:09] <smb> There is no limit on what one does for free beer. :-P
[10:24] <popey> Daviey / apw I do have my mbp with me here, so if there's anything I can do to test, lemme know :)
[10:24] <Daviey> popey: fancy seeing what freebsd are doing differently? :)
[10:25]  * popey looks for a live freebsd iso
[10:26] <popey> livecd-1.2.4.tar.gz (24.2KB) <- looks like a very heavily optimised kernel they have there.
[10:26] <Daviey> popey: try your left coat pocket.
[10:26]  * apw wonders whether these machines have bios modes for the sata controller, AHIC and something else?
[10:27] <Daviey> apw: it's EFI, which means that bios modes are a PITA to change.. /me is an EFI n00b, so i may be mistaken.
[10:27] <apw> this is a tricky one, the co
[10:27] <Daviey> from my reading, i wanted to change the SATA compatability mode.. but nfi if you can.
[10:28] <popey> Daviey: learn FORTH :)
[10:28] <apw> the controller appears to be an early one in the series, and supported for some time
[10:28] <apw> so its somewhat enexpected it doesn't work
[10:29] <apw> smb, is there a general way to disable MSI ?
[10:29] <Daviey> apw: yeah.. i understand some COMRESET issues were introduced after 2.6.24, so i tried hardy.. but i don't think hardy supported the chipset yet.. so rock and hard place.
[10:29] <smb> apw, nomsi I believe
[10:29] <apw> apple are the pits
[10:29] <apw> Daviey, may be worth booting nomsi to see if that changes thigns
[10:29]  * Daviey checks his notes
[10:30] <Daviey> hmm, that is one i haven't yet tried.
[10:30] <Daviey> popey: If you have a few moments, fancy doing that?  Booting with the kernel line, s/quiet splash/nomsi/ ?
[10:31] <popey> sure
[10:31] <Daviey> cool
[10:31] <popey> hold C to boot from CD, then press something at the accessibility prompt?
[10:33] <popey> still getting the COMRESET failed 
[10:36] <popey> and then it still can't find /dev/sda sadly
[10:37] <Daviey> popey: ah well... worth a try
[10:38] <popey> yup
[10:41] <apw> Daviey, popey what you running bits wise?  32/64?
[10:42] <popey> that was a 32-bit official shipit cd
[10:42] <apw> Daviey, you have a USB install i think yes?
[10:42] <popey> i do, but it wont boot on this machine
[10:42] <popey> due to it needing refit / efi stuff
[10:43] <Daviey> apw: yes.. can boot to a live enviroment via usb
[10:43] <popey> hmm, could I use the cd and usb together?
[10:43] <Daviey> popey: yes
[10:44]  * popey needs learning how to do that
[10:44] <popey> root=something initrd=something? 
[10:44] <Daviey> popey: insert usb pendrive, insert cd.. boot from CD and select Try Ubuntu without installing.
[10:46] <popey> that it? :)
[10:46] <Daviey> yeah, when the cd fails, it'll hand over to the USB... ugly but easy.
[10:46] <popey> seriously, no interaction required, just boot off cd with usb attached?
[10:46] <Daviey> popey: yes
[10:47] <popey> blimey
[10:48] <apw> normally in this kind of mess i install from the CD to the USB, so that whats on the USB is a bootable real root image, that then lets you replace the kernel and test
[10:48] <apw> as the next step is going to be test kernels me thinks and someone has to be able to test them for them to be of use
[10:50] <popey> if i can get it to boot off usb then i can certainly do that testing
[10:50] <apw> i've turned on ata debug and added some specfic debug for the EBUSY that is being reported, hope that can provide some clues to someone
[10:50] <popey> Daviey: I'm just getting a blinking cursor after choosing try ubuntu. no flashing on the usb stick.
[10:51] <popey> ah, spoke to soon, patience
[10:53] <Daviey> apw: yeah, in order to have a non-casper usb.. would need to sort of the UEFI stuff; which i haven't yet done
[10:55] <apw> Daviey, how much spondoolies does this heap cost ?
[10:55] <Daviey> apw: don't ask :)
[10:55] <apw> cking, do you have any uefi platforms for testing?
[10:55] <Daviey> apw: around £1k
[10:55] <apw> ouch
[10:55] <popey> indeed
[10:56] <cking> apw, I have an intel box with reference UEFI firmware
[10:56] <Daviey> "Best decision you'll ever make".. still pondering that statement.
[10:56] <popey> Daviey: jfo tweeted me saying he's building a usb stick of this type :)
[10:56] <apw> "beacuse you will be forced to run Mac OSX, and we will get you" perhaps
[10:57] <Daviey> apw: Lucid might LOOK like OSX.. but you shouldn't confuse the two :P
[10:57] <cking> apw, the Mac has non standard firmware that'sfor sure
[10:57] <apw> Daviey, if it boots from a USB install of the live CD, could you not make the USB real-root on another machine?
[10:57] <apw> cking, so no value in you having one then
[10:57] <apw> and damned expensive either way
[10:57] <cking> apw, indeed
[10:58] <Daviey> apw: yeah, but the hack i was using to get a live env', was the cd failing - and happening to find the casper on the usb stick by luck.
[10:58] <Daviey> so, i could be wrong; but i think booting real root USB requires EFI support.
[10:58] <popey> yup, i believe so too
[10:58] <Daviey> dunno why it supports legacy CD, but not legacy USB from boot.
[10:58]  * apw tries to understand ... there is no 'F12' to chose where to boot?
[10:58] <Daviey> correct
[10:59] <popey> you hold down C to boot from CD
[10:59]  * apw puts this machine in the 'not suitable for purpose' bucket
[10:59] <Daviey> apw: to set a "bios password", you need to use a graphical app in the OS!
[10:59] <popey> or learn FORTH :)
[10:59] <apw> in the 'other' OS i assume
[10:59] <apw> well forth is pretty easy
[10:59] <Daviey> yeah..
[10:59] <apw> its just reverse polish
[10:59] <Daviey> i am pretty new to this EFI voodoo tbh.
[10:59]  * popey decides not to teach his mum FORTH
[10:59] <apw> i had a reverse polish calculator once
[11:00] <Daviey> apw: That is on my xmas stocking list, for sure.
[11:00] <cking> doesn't everone do math in reverse polish?!
[11:00] <apw> intelligent people only of course
[11:02] <apw> Daviey, popey, so its not clear you are going to be able to test a kernel will your current 'access' to this h/w
[11:02] <popey> well, jfo said he was making an efi bootable usb image for kernel testing
[11:02] <popey> which would help
[11:02] <Daviey> apw: Given a kernel, i can either re-create a casper image, or learn EFI support... either i'm keen to do if it helps speed a resolution.
[11:03] <Daviey> or what popey said.
[11:03] <apw> we have next to no information other than the links are deemed not up, so i've turned on all the debug there is and added some for the errors you are reporting
[11:03] <apw> we'll have to see what that produces if anything
[11:04] <Daviey> apw: For the kernel autobuild?
[11:05] <apw> i am building a i386 kernel with those modifications now, and will hope you can test with it
[11:05] <Daviey> super
[11:06] <Daviey> popey: any news on jfo's build?
[11:06] <Daviey> i'd rather dd, than do it myself :)
[11:08] <popey> Daviey: http://twitter.com/jeremyfoshee/status/14135364460 is all i know
[13:18] <eipi-1> how long does it take until the new kernel 2.6.34 is in the kernel ppa?
[13:20] <amitk> eipi-1: probably by tomorrow if the automated scripts don't fail
[13:20] <eipi-1> amitk, thx
[13:20] <tgardner> eipi-1, it'll likely be Wednesday. ogasawara is out today.
[13:31] <cking> the post UDS TZ changes are killing me ;-)
[13:32] <tgardner> cking, my sympathy is limited. I made it all the way until 0430 today.
[13:33] <cking> owch
[13:42] <apw> eipi-1, are you talking about the mainline kernel builds ?
[13:43] <apw> if so they will be about another 8 hours as there are a heap of other ones building
[13:43] <eipi-1> apw, yes
[13:43]  * apw blames smb for all the 5 digit ones
[13:43] <eipi-1> apw, perfect thx
[13:44] <smb-afk> apw, Not that I have changed that much. Must be you automation. :-P
[13:46] <apw> hey lag whats your launchpad id ... we'll need that to get you on the right groups
[13:48]  * apw pokes lag
[13:49] <lag> Oh, hello
[13:49] <lag> 2 secs
[13:50] <lag> Is there any way to change it to one that's already taken? 'lag' is used by someone who signed up in 2006 and hasn't logged on since.
[13:51] <amitk> don't think so, unless they delete their accounts
[13:52] <lag> That sucks
[13:52] <lag> In which case, I'm ljones
[13:52] <lag> :(
[13:53] <smb> lag, In theory it is possible but requires to convince certain people and then might mess up some other things.
[13:54] <smb> lag, So probably now or never.
[13:55] <lag> Now would be good
[13:55] <lag> I don't have anything else to do 
[13:55] <lag> Still waiting on IS for other things
[13:55] <amitk> lag: you could try writing to them..
[13:56] <lag> Okay
[13:56] <lag> They have an IRC channel
[14:00] <JFo> so... btrfs in Lucid... we don't support it, yes?
[14:00]  * smb wonders whether that was a question or statement
[14:01] <smb> JFo, no
[14:01] <apw> it hink he wants it to be a stement
[14:01]  * apw orders some keys up for his keyboard
[14:01]  * JFo has a bug report on btrfs
[14:01] <JFo> I want it to be :)
[14:01] <smb> apw, I meant lag but was too slow
[14:01] <apw> whats the report
[14:01] <JFo> bug 578742
[14:01] <ubot3> Malone bug 578742 in linux "Btrfs device balancing does not work" [Undecided,New] https://launchpad.net/bugs/578742
[14:02] <apw> JFo, hrm, thats a kernel panic on a userspace command, not wonderful
[14:03] <pgraner> JFo: punt to cjwatson
[14:03] <smb> apw, I am not aware that btrfs is enabled at all
[14:03] <JFo> pgraner, will do
[14:04] <apw> debian.master/config/config.common.ubuntu:CONFIG_BTRFS_FS=m
[14:04] <apw> smb, from lucid
[14:04] <smb> apw, That much for having experimental stuff not turned on. :/
[14:05] <apw> i suspect we got asked to add that one, just so people could experiment with it, we should ahve a list of 'EXPERIMENTAL but on and NOT supported' features
[14:05] <JFo> and I had a nice "HA! but no." message all queued
[14:06] <pgraner> apw: sounds like a good topic for a wiki page
[14:06]  * pgraner ducks
[14:06]  * JFo giggles
[14:06] <smb> We finally have a volunteer. >.-)
[14:07] <JFo> :-P
[14:07] <apw> sounds like something the kernel release manager would produce as part of a new release
[14:08] <pgraner> apw: just kneecapped ogasawara
[14:08]  * apw hums innocently
[14:08] <pgraner> apw: thats cold bloooooded
[14:08] <JFo> UNITY!!!
[14:08] <apw> i have my moments :)
[14:09] <tgardner> JFo, btrfs in Lucid was a technology preview. we are not supporting it officially until Maverick
[14:09] <apw> unison ?
[14:09] <JFo> right
[14:09] <JFo> I just wanted to make sure before I spanked the OR
[14:09] <JFo> :)
[14:09] <apw> smb, i would think an appropriate response to that problem might be to disable the ioctl it uses in the kernel :)
[14:10] <smb> apw, Rather remove the whole module. Or mark it as taint crap
[14:11] <JFo> so cjwatson says thusly: "not too bothered yet, assuming that it can be forwarded upstream and fixed in maverick; at this point, given the lack of userspace support, I only care about problems that would make it difficult for us to implement that support"
[14:11] <amitk> tgardner: we're supporting btrfs in maverick? I thought it was optional at install time...
[14:11] <apw> if its not EXPERMIMENTAL its supported at the kernel level right?
[14:11] <smb> amitk, Have you listened to the wrap up talks at UDS? ;-)
[14:12] <tgardner> amitk, right, its not going to be the default FS, but it _will_ be an option.
[14:13] <tgardner> at least that is the plan, unless its so shite that its unsupportable (which is unlikely)
[14:13] <amitk> smb: yes, with the alertness of a sloth
[14:13]  * JFo throws up his hands
[14:13]  * apw wonders what jfo will use to catch them
[14:13] <amitk> :)
[14:14]  * JFo calls the whole thing off
[14:14] <JFo> :)
[14:15]  * amitk relocates to the balcony
[14:15]  * smb would freeze if he did that
[14:17]  * amitk relocates back to the office, damn screen is unreadable in the glare
[14:17] <eipi-1> can someone explain me why linux-headers-generic depends on linux-headers and how to resolve it? (I downloaded it from the mainstream kernel-ppa)
[14:17] <apw> eipi-1, ?
[14:17] <apw> there are two headers packages normally
[14:18] <apw> one flavour specific and one common one, you need both
[14:18] <smb> apw, He might refer to the meta packages
[14:18] <apw> we don;t 
[14:18] <apw> we don't have meta in the mainline builds tho.
[14:18] <eipi-1> apw, stupid, i missed that. sorry
[14:19] <smb> ah right, missed the kernel-ppa part
[14:46] <apw> pgraner, i noted that ogasawara seems to have some additional blueprint foo to set goals and the like on our blueprints, i wonder if thats something we can spread around the planners
[14:47] <apw> anyhow, we have one blueprint with no owner, seems someone should own: https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-arm-single-zimage
[14:47] <ogasawara> apw:  I thought that one was ericm's?
[14:48] <apw> it maybe, but isn't his at the mo
[14:48] <ogasawara> apw: and I actually thought I assigned him to be the owner
[14:48] <apw> so we'd better shove it to either him or to jk imo
[14:48] <apw> ogasawara, its not taken if you did
[14:49] <ogasawara> apw: I'll follow up with them to get an owner assigned
[14:50] <apw> yay leanns problem, i like those kind
[14:55] <apw> ogasawara, arn't you off today?
[14:56] <ogasawara> apw: I am, but I woke up early and no one else is awake yet
[14:56] <ogasawara> apw: so I figured I'd check email etc.
[14:56] <smb> ogasawara, keybaddict! :)
[14:56]  * apw slaps ogasawara 
[14:56]  * ogasawara slowly steps away from the keyboard
[14:57] <smb> apw, Next we get told "I can stop anytime... if I want to" :-P
[14:57] <ogasawara> heh
[14:59] <cking> gotta pick kids up from school, back in 35-40 mins
[15:42]  * psurbhi steps out for a while to run some errands
[15:53]  * apw pops out to get a new flus
[15:53] <apw> flush ... yes he does
[15:53] <JFo> interesting: bug 574462
[15:54] <ubot3> Malone bug 574462 in linux "udisks-probe-ata-smart causes HSM violations" [High,Confirmed] https://launchpad.net/bugs/574462
[15:54] <tgardner> JFo,  I've been sort of poking at that one. I think its drive or host controller related.
[15:54] <manjo> apw, what is a flush?
[15:55] <apw> the bit in your loo which makes the flush occur
[15:55] <JFo> tgardner, sounds interesting 
[15:55] <tgardner> JFo, I guess thats one way to put it.
[15:55] <JFo> heh
[15:55] <pmatulis> on the generic kernel in lucid, what is the limit on recognized memory?
[15:56] <tgardner> pmatulis, 32 bit?
[15:56] <pmatulis> no, this is a 64-bit system
[15:56] <tgardner> pmatulis, I'm not aware of any practical limit. apw?
[15:57] <pmatulis> system is supposedly seeing 16 GB but has a lot of random crashing.  was thinking it might be a limitation of generic
[15:57] <pmatulis> it's a desktop
[15:57] <tgardner> pmatulis, no, thats well within the norm for RAM quantity
[15:58] <pmatulis> oh well, thanks
[15:58] <tgardner> pmatulis, have you had them run the memory test? or this generic across multiple machines?
[15:58] <tgardner> is this*
[15:59] <pmatulis> tgardner: funny that, memtest *fails*, the test doesn't run
[15:59] <pmatulis> tgardner: i think it's a separate problem involving the BIOS
[16:00] <tgardner> that sounds a bit strange to me
[16:01] <pmatulis> tgardner: to me too.  userspace memtest binary works however
[16:01] <pmatulis> (memtester)
[16:02] <pmatulis> it's a HP Z600 Workstation
[16:33] <apw> tgardner, no limits i am aware of no
[16:34] <apw> if there was a limit i would expect you to miss memory not to have crashes
[16:34] <apw> pmatulis, ^^
[16:34] <apw> do you have a boot dmesg from it, you can tell how much ram and where it is from that
[16:37] <pmatulis> apw: https://pastebin.canonical.com/32340/
[16:40] <cking> cnd, does ftrace work reliably over S3 suspend/resume cycles?
[16:40] <cnd> cking: I would assume so, but I've not tried
[16:42] <cking> cnd, it seems to fail on a box I'm working on - can you sanity check that it generally works for you?
[16:42] <apw> pmatulis, well its showing around 16GB of ram
[16:43] <pmatulis> apw: alright, thanks
[16:43] <cnd> cking: how urgent do you need a response by?
[16:43] <cking> sometime today if poss
[16:44] <apw> cking, does virtualbox use any kernel support for virtualisation?
[16:45] <cnd> cking: ok, I'll get back to you in a bit
[16:45] <cnd> JFo: no regression review today right?
[16:46] <manjo> JFo, are you going to have the regression call ? 
[16:46] <JFo> nope
[16:46] <cnd> cool
[16:46] <JFo> giving you guys a break, plus we will be changing the meeting around a biot
[16:46] <JFo> errr bit
[16:46] <JFo> so I will need some time to communicate that
[16:46] <manjo> JFo, k thanks
[16:46] <JFo> my pleasure
[16:46] <vanhoof> JFo: been up since 3am working? ;)
[16:46] <JFo> heh
[16:46] <JFo> feels like it
[16:47] <vanhoof> JFo: looks like we made it out just in time
[16:47] <vanhoof> JFo: ash cloud is back in action
[16:47] <JFo> vanhoof, yeah, I am thankful
[16:47]  * vanhoof is not ;)
[16:47] <JFo> lol
[16:47] <JFo> well, you know what I mean :)
[16:51] <apw> JFo, smb, !ogasawara, apw (!), ... are we doing the regression call?
[16:51] <JFo> we are not
[16:51]  * smb wonders where apw has been the last few minutes
[16:52] <JFo> he was dreaming of trays bangign together
[16:52] <smb> lol
[16:52] <apw> i was buying a new flush
[16:52] <apw> so ner
[16:52] <cnd> ppetraki: on the psmouse reset fix, the easiest way to get it into releases of Ubuntu is to send it to stable@kernel.org
[16:53] <smb> cnd, When it has hit upstream
[16:53] <cnd> it will end up in one of the stable releases for 2.6.32, and the change will get merged into our kernel when it's released
[16:53] <cnd> smb, ppetraki just sent out an email saying it's been merged upstream
[16:53] <apw> didn't it just hit upstream according to ppetraki 
[16:53] <cnd> smb: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ef110b24e28f36620f63dab94708a17c7e267358
[16:54] <apw> so i recon send it to stable yes, but also send it out to kernel-team as it fixes something real for (pre-stable) treatment
[16:55] <smb> I guess, if it i urgent. Would even have been better if Dmitry would have added cc: stable...
[16:55] <smb> s/i/is/
[16:55] <apw> smb, i suspect its one of those OEM things that will run us down like a train
[16:57] <smb> apw, Likely. Maybe even one of those things were they _should_ tell us if it is already used in some way
[16:57] <apw> smb, heh yeah
[16:57] <apw> smb, btw when did you do the 13.3 and 13.4 tags for your tree
[16:58]  * apw is trying to work out why they are both pending together
[16:58] <smb> apw, During UDS. Maybe a bad idea
[16:58] <apw> explains it then ...
[16:58] <apw> i had cod-execute down for a bit for maintenance
[16:59]  * apw notes zinc has 7 more hours of builds to complete
[16:59] <smb> apw, Oh, you meant why they both are new. Not some badness as being on the same commit
[17:00] <apw> yeah, i was supprised you did both at the same time roughly
[17:01] <smb> apw, Mind that there is a commit on top of the tags as Greg had this crazyness too
[17:01] <smb> apw, Doing them together is rather normal in my workflow
[17:02] <apw> so you do like 12.3 -> 13.3, and 13.3 -> 13.4 as separate steps?
[17:02] <apw> hense two tags at 'once' there
[17:03] <smb> Right, I usually update the .32 part first but follow up with the .33 drm immediately after
[17:03] <apw> smb, ring ring
[17:03] <smb> (at least as long as upstream/Greg makes updates at the same time)
[17:09] <cnd> cking: I traced the psmouse module through a resume
[17:09] <cnd> it worked fine, though the timestamps sot screwed up (like the TSC warping) and then eventually settled back to 0
[17:10] <cnd> so the timestamps seem relative to the last resume
[17:24] <cking> cnd, thanks, something is screwy then with my tracing
[17:24] <cnd> cking: what are you trying to do?
[17:27] <cking> cnd, just measure func calls thru a S3
[17:27] <cking> s/measure/capture
[17:28] <cnd> cking: what happens?
[17:28] <cnd> do you just lose trace data after the suspend?
[17:33] <cking> cnd, yep, any idea why it evaporates?
[17:34] <cnd> hrm, unfortunately no...
[17:34] <cnd> cking: sounds like you should just throw the machine in the dumpster and get a new one :)
[17:34] <cnd> that's how I solve my sw problems
[17:34] <cking> cnd, any idea of how many func calls can be captured in one test
[17:34] <cnd> blame the hw
[17:34] <cnd> cking: what do you mean by that?
[17:35] <cking> cnd, that's why the H/W is on my desk :-(
[17:35] <cnd> how many func calls before some start to get deleted in favor of new ones?
[17:35] <cking> cnd, any idea of how many func calls can be captured before the internal buffer gets full
[17:36]  * cking notes that "no idea" is perfectly valid answer ;-)
[17:36] <cnd> so first, it operates in flight recorder mode meaning that new events overwrite old events (contrary to how perf drops events if the buffer gets full)
[17:36] <cnd> however, I don't really know how many events it can store
[17:36] <cnd> it probably depends on the size of the events
[17:36] <cnd> and function calls
[17:36] <cnd> it's all stored as binary data
[17:37] <cking> yeah, oh well, I will try one more time and then fall back traditional methods aka printk etc
[17:37] <manjo> cking, are you trying tracepoints in suspend/resume code ?
[17:37] <cking> manjo, just tracking using ftrace
[17:37] <cnd> cking: you can check whether it's been turned off somehow
[17:37] <cnd> by loocking at trace_enabled and trace_on
[17:38] <cnd> maybe dmesg will give a hint?
[17:38] <cnd> and check that current_tracer is what you set it to
[17:38] <cnd> if it's nop, then no functions will be traced
[17:38] <cking> it's set to "function"
[17:45] <manjo> vanhoof, ping 
[17:47] <vanhoof> manjo: pong
[17:51] <ppetraki> cking, apw, so what else do I need to do to close the loop on 551234?
[17:51] <apw> bg 5512334
[17:51] <apw> bug 551234
[17:51] <ubot3> Malone bug 551234 in oem-priority "touchpad doesn't reconnect after resume: Synaptics ps2" [High,In progress] https://launchpad.net/bugs/551234
[17:52] <apw> i say submit it to stable, and to kernel-team, the final form patch
[17:52] <smb> ppetraki, The mail has been sent. We will look at the patch and then possibly take it pre-stable
[17:52] <ppetraki> smb, cool
[17:55] <smb> ppetraki, When you ask for this patch to be considered upstream stable, can you cc kernel-team along with dmitry?
[17:56] <ppetraki> smb, sure, I can do that, anyone else to copy? I saw stable... mentioned earlier
[17:58] <smb> ppetraki, You will send it to stable@kernel.org (==Greg) and need to cc all on the signed-off-by list (in that case only dmitry). The mail should contain the reference to the upstream patch and saying that this is a bug fix you think should go into .32, .33 (.34?)
[17:59] <manjo> ppetraki, scripts/get_maintainer.pl should help ?
[18:00]  * abogani waves
[18:00] <smb> manjo, ppetraki That helps too in doubt but can be over the top for stable.
[18:00]  * apw waves back to abogani 
[18:00] <smb> Hi abogani 
[18:00] <abogani> apw, smb: Hi :)
[18:01] <ppetraki> manjo, I'll take a look at it for future reference. Thanks.
[18:01] <abogani> I would want bother you with one of my usual stupid questions :-D
[18:01] <abogani> I'm just wondering if in the Lucid life-cycle management you will ever update kernel with a more recent version (that is > 2.6.32).
[18:02] <abogani> If I don't recall wrong there are time ago a blueprint about it (about updating kernel into a LTS). Sorry i don't have the link.
[18:02] <abogani> *is
[18:02] <pgraner> abogani: we will have the Maverick kernel avail when its ready for server only
[18:02] <smb> abogani, There will be kernels bckported, but only supported for server
[18:03] <apw> abogani, the default kernel will not change, the backports will be an elective install only
[18:03] <smb> abogani, MAybe pgraner is also quicker in finding the link to the blueprint
[18:03] <abogani> smb: That kernel will be available in -backports?
[18:03] <cking> cnd, how does one clear the trace log?
[18:04] <apw> https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-new-kernel-on-lts
[18:04] <pgraner> smb: https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-new-kernel-on-lts
[18:04] <cnd> cking: I believe changing the current_tracer will do the trick
[18:04] <apw> the kernels will be in main as separate packages
[18:04] <cnd> cat'ing trace_pipe will too
[18:04] <pgraner> abogani: no main archive
[18:04] <smb> apw, wins over pgraner 
[18:04] <smb> abogani, But will start in a ppa before maverick is released
[18:08] <abogani> Last thing (I promise :) Why kernel packages not present "Supported: 3/5y" line in apt-cache output?
[18:09] <apw> abogani, is that something they _can_ report?
[18:09] <abogani> apw: I meant: If I don't recall wrong there are time ago a blueprint about it (about updating kernel into a LTS). Sorry i don't have the link.
[18:09] <abogani> Urgh
[18:09] <abogani> apw: apt-cache show linux-image-2.6.32-22-generic | grep -i supported
[18:10] <apw> abogani, right but that was definatly the predecessor blueprint to the one i pasted.  we always planned to do elective installs for those
[18:10] <manjo> cking, have you seen http://lwn.net/Articles/290277/ ? article on ftrace has detailed info 
[18:11] <apw> abogani, hrm, that supported thing is odd
[18:11]  * apw investigates
[18:11] <abogani> apw: I would want let you notice than:
[18:12] <abogani> apt-cache show linux-image-2.6.32-21-generic | grep -i supported
[18:12] <abogani> Supported: 5y
[18:12] <cking> manjo, cheers
[18:12] <abogani> apt-cache show linux-image-2.6.32-22-generic | grep -i supported
[18:12] <abogani> No Supported line at all
[18:12] <apw> nnnng
[18:12] <apw> will ask
[18:13] <smb> abogani, Just that for -generic it would be 3y
[18:13] <abogani> I wrong something?
[18:13] <smb> abogani, I think we don't know if that ever was possible
[18:13] <apw> smb, i think the information is coming from outside the packages too
[18:13] <apw> am asking where it comes from now
[18:14] <apw> as we've not changed our packaging between -21 to -22 yet one has it and the other not
[18:14] <apw> i bet its cause -21 was -release and the later packages do not have it...
[18:17] <smb> apw, Strangeness. But if you find out let me know. I'd really like to see that change to 3y and only to be 5y for -server, too
[18:17] <apw> seems mvo is the man to talk to, but that there is bugs handlng -updates stuff at the mo
[18:21] <Sarvatt> yuck, theres one intel pci id that is flickering in lucid because of FBC that is fixed in the maverick kernel, need to track down the commit that fixed it because it seems to be happening to all 8086:2a42 devices
[18:22] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/538648
[18:22] <ubot3> Malone bug 538648 in xserver-xorg-video-intel "[Intel GM45] Irregular sync flashes on 8086:2a42 (Needs i915.powersave quirk)" [Medium,Triaged] 
[18:23] <abogani> pgraner, smb, apw: Thanks!
[18:24] <apw> Sarvatt, we could just disable FBC for that ID right?
[18:24] <apw> we have support infrastructure for that ... rather than try and fix it i mean
[18:25] <apw> Sarvatt, can put that together for testing if that would help
[18:25] <Sarvatt> we don't though, theres more than one pci id in that generation so i'm not sure how to disable it
[18:26] <Sarvatt> can't just remove has_fbc from that generation's struct without affecting all of the others, thats why I'm trying to find where it was actually fixed in .34
[18:26] <apw> Sarvatt, yeah we could, we could clone that ones entry to a new structure and drop it there
[18:27] <apw>         INTEL_VGA_DEVICE(0x2a42, &intel_gm45_info),
[18:27] <apw> change that to:
[18:27] <apw>         INTEL_VGA_DEVICE(0x2a42, &intel_gm45_nofbc_info),
[18:27] <apw> and copy the structure and drop .fbc=1 ... no?
[18:28] <pgraner> JFo: damn! Your blowing up my mailbox dude...
[18:28] <apw> Sarvatt, and anyhow thats the only id using that specific structure
[18:28] <JFo> pgraner, sorry :-/
[18:28] <apw> JFo, you expiring bugs?
[18:28] <Sarvatt> it is?! awesome
[18:28] <pgraner> JFo: I can tell you're so tore up about it
[18:28] <JFo> :-D
[18:29] <JFo> apw, not yet
[18:29] <apw> Sarvatt, at a cursory look yes it is, even if not we could make that one id use a new one
[18:29] <JFo> need to check that the fixes are in so I can
[18:29] <apw> Sarvatt, so 2a42 is the one yes?
[18:29] <Sarvatt> yeah
[18:29] <Sarvatt> wish i had one so I could bisect it down
[18:29] <apw> so that seems to be the only one which uses that structure
[18:30] <apw> drivers/gpu/drm/i915/i915_drv.c:const static struct intel_device_info intel_gm45
[18:30] <apw> drivers/gpu/drm/i915/i915_drv.c:        INTEL_VGA_DEVICE(0x2a42, &intel_gm45_inf
[18:30] <apw> so i recon we can just rip it out for now
[18:30] <apw> you want me to spin a test kernel for the bug with it torn out?
[18:31] <Sarvatt> it's still setting up the fbc registers and stuff for all is_i965 (or whatever it is, dont have it open) though, not sure if thats a problem
[18:31] <Sarvatt> if you could that'd be great
[18:31] <Sarvatt> quite a lot of people are hit by that problem since thats one of the more common devices these days
[18:37] <JFo> need food, bbiab
[18:38] <apw> Sarvatt, no worries
[18:38] <apw> Sarvatt, building now, will update the bug when they are available
[18:41] <Sarvatt> thanks a bunch apw!
[18:41]  * cking enters a new level of S3 weirdness. /me thinks it's time to call it a day
[18:44] <apw> cking, its time to call it a day
[18:45] <cking> apw, yeah, made some progress, but it's just gonna have to wait 'til tomorrow now
[18:46] <cking> yawn
[18:59] <JFo> k, back
[19:42] <apw> Sarvatt, those kernels are uploading now, i've updated the bug asking for testing
[19:43] <Sarvatt> awesome, thanks apw!
[19:44] <Sarvatt> need to find out if the people saying it was fixed in 2.6.34 were still using powersave=0..
[19:53] <popey> Daviey: dont suppose you have a guide to respinning an iso with a modified kernel do you?
[19:54] <popey> or indeed if anyone has such a guide, for bug 576601
[19:54] <ubot3> Malone bug 576601 in linux "[MacBookPro 7,1]mcp89 sata link reset fails, no disks detected" [Medium,Triaged] https://launchpad.net/bugs/576601
[19:55] <manjo> popey, ping bjf for a script that does that
[19:55] <manjo> jfo, might know  if it is publicly available 
[19:55] <JFo> popey, I don't have any docos written, but I plan to wikify the script manjo is talking about
[19:55] <JFo> manjo, it isn't yet
[19:55] <JFo> there are some bugs in it
[19:55] <popey> ok
[19:55] <JFo> and I need to hash them out
[19:56] <JFo> sorry popey, but it is on my list much like the uEFI one
[19:56] <popey> :) no worries
[20:01] <Daviey> popey: it's on the wiki
[20:01] <popey> o rly? ou est la?
[20:02] <Daviey> popey: potted guide, https://help.ubuntu.com/community/LiveCDCustomization
[20:02] <Daviey> ie, the cheats way :)
[20:03] <popey> heh
[20:08] <JFo> mmmm
[20:08]  * JFo bookmarks for a review :)
[20:12]  * popey tries this magic
[20:42] <JFo> bug 581312
[20:42] <ubot3> Malone bug 581312 in linux "Unknown key fee[x] pressed" [Undecided,Incomplete] https://launchpad.net/bugs/581312
[21:07] <cnd> apw: thanks for the broadcom fix!
[21:19] <popey> apw: are you about? I've got the mac booted to your new kernel and could open an ssh port to it if you want to poke it with a stick?
[21:33] <popey> apw: ran an apport-collect for bug 576601 :)
[21:33] <ubot3> Malone bug 576601 in linux "[MacBookPro 7,1]mcp89 sata link reset fails, no disks detected" [Medium,Triaged] https://launchpad.net/bugs/576601
[22:06] <achiang> ugh, can't figure out how to remove tags from a LP entry
[22:07] <achiang> notably, i want to remove the needs-upstream-testing tag from bug 578138
[22:07] <ubot3> Malone bug 578138 in linux "Thinkpad T400 (model 2765-TDG) fails to resume after second suspend" [Undecided,Incomplete] https://launchpad.net/bugs/578138
[23:21] <kamal> achiang: I have a pencil icon at the end of the Tags: list I think I can remove it -- want me to?
[23:21] <kamal> s/list I think/list, therefore I think/
[23:23] <kamal> achiang: I suppose this is because I'm a member of ubuntu-bugcontrol