[00:25] <ogasawara> bjf: am here now, lemme know if you needed something
[01:40] <bjf> ogasawara: nah, thanks, vanhoof and hugh took care of it
[02:05] <cooloney> ogasawara: still around, for the bug 1084000
[02:06] <cooloney> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1084000
[02:06] <ubot2> cooloney: Error: <Bugtracker.plugin.Launchpad instance at 0xa91202c> bug 1084000 not found
[02:07] <cooloney> i believe we can point out to ubuntu server image builder and add a small post-install script to add 'elevator=deadline' to default grub kernel command line
[02:14] <cooloney> xnox: hey, are you still around?
[02:40] <BenC> ogasawara: When do you think the quantal tree with by tracking 3.5?
[02:40] <BenC> *will be tracking
[03:03] <ogasawara> BenC: I wanted to get it rebased today but got sidetracked, so hopefully tomorrow.
[03:03] <BenC> ogasawara: sweet, my work pre-depends on that, so if you could just ping me when it's done, I'd greatly appreciate it
[03:03] <ogasawara> BenC: will do
[03:04] <BenC> ogasawara: I have my tree on github ready and cloned from ubuntu-quantal
[03:05] <ogasawara> BenC: you're quick, I haven't heard back about the zinc access yet.
[03:07] <BenC> ogasawara: It's kind of moot at this point, but I guess for future reference it will give you a litmus test of how likely someone else is to get access :)
[03:07] <ogasawara> BenC: it's definitely not the first time it's come up, so will indeed be good to know what the actual policy is
[03:32] <ogasawara> cooloney: while I agree that having that bug reporter use elevator=deadline is a valid workaround in that bug scenario, I don't think it's a convincing enough argument to default *all* server image installs to it.  the fact that the CFQ scheduler is resulting in disk errors and hangs seems like a legitimate issue that needs to be addressed.  Additionally it won't be obvious for anyone examining our kernel config that in so
[03:32] <ogasawara> me cases the schedule will be set to elevator=deadline.   do you know if we've been able to reproduce?  The bug report doesn't have any logs files of the actual errors to confirm the issue.
[03:34] <cooloney> ogasawara: i can't reproduce it on my side, I just confirm CFQ is our default IO scheduler for server image now.
[03:34] <cooloney> ogasawara: and i don't think we need any change in our kernel side,since we have good reason to keep it as the same as desktop kernel 
[03:35] <cooloney> so might need talk with server folks about this issue, or add elevator=deadline in server image after fully installation
[03:37] <ogasawara> cooloney: yah, probably best to raise with the server team for feedback.  maybe try and get some benchmarks ran.  I thought we'd done some in the past but can't seem to find the results.
[03:38] <cooloney> ogasawara: no problem, i will handle that and might discuss this with smb firstly. 
[03:38] <ogasawara> cooloney: sounds good
[07:16] <xnox> cooloney: well I am now.
[07:16] <cooloney> xnox: cool, i saw your update about that usb 3.0 bug
[07:16] <cooloney> looks like some works some not
[07:16] <cooloney> quite weird
[07:17] <xnox> cooloney: well all that tested got a 'P' - pass. Others were not tested. So no fails.
[07:17] <xnox> it did take between 47-83s to spin up the drive and make it appear
[07:18] <xnox> the external drive has it's own power, so I'm not sure why it was taking so long.
[07:38] <taruti> Is it a known problem that installing the 3.5rc quantal kernel on precise makes an usb keyboard nonworking? and are there any workarounds?
[07:40] <cooloney> xnox: i will take a look at the kernel change based on your testing result
[07:43] <xnox> cooloney: they are inconclusive. I have tested 4 kernels and all 4 of them passed
[07:44] <xnox> both the reported kernel by the user, kernels before & after it. As well as the current 3.4 kernel. And all works.
[07:44] <xnox> APART from that it takes ages for the device to appear (upto a full minute sometimes)
[07:45] <cooloney> xnox: did you met this issue on some old ubuntu release before? like 11.10
[07:46] <cooloney> i mean the issue about long enumeration of USB 3.0 devices
[07:49] <xnox> cooloney: I got this laptop with USB 3.0 port this christmas and it has been running precise until precise release, and quantal since then. My first USB 3.0 device arrived yesterday.
[07:50] <xnox> Previously I thought that my 3.0 usb port was 'backwards-incompatible' as I would get frustrated and plut the stuff into 2.0 port, as that one 'was not working', well it actually was just enumerating slower.
[07:50]  * xnox it's not very scientific, and I'm not sure how to numerically test this.
[07:53] <cooloney> based on you testing, "P 3.2.0-23.363.2.14" means your devices can be enumerated and works fine, right? only it will take about 1 min to see the device appear
[07:54] <cooloney> xnox: if so, i'm going to check the change between 3.2.0-23.36 to 3.2.0-24.37
[07:57] <xnox> cooloney: well, all of them were slow. But I was not using, e.g. a stopwatch, nor multiple tests to see if there is a consistent trend/correlation. E.g. there was still a lot of cpu activity while desktop was loading and I would plug my device in.
[07:59] <xnox> cooloney: i am dogpiling on the bug report now. I think it is best to wait for the original reporter to come back and find out if it's "working slowly" or "not working at all"
[07:59] <xnox> hence the status incomplete.
[08:01] <cooloney> xnox: thanks a lot. i got you
[08:01] <cooloney> cking: morning, how's the celebration for Queen
[08:02] <cking> cooloney, morning;  the celebrations were a load of fun
[09:18] <dileks_> "For the fist time in my memory, today's linux-next build required no manual intervention i.e. there are no new conflicts or build problems."
[09:18] <dileks_> linux-next: Tree for Jun 7
[10:55] <gema> ppisati: I have A1 desktop image not booting on panda
[10:55] <gema> ppisati: it's stuck on the Uboot , keeps rebooting
[10:55] <gema> ppisati: how do I enable the debug info?
[10:56] <gema> ppisati: I'd like to give some more info than just "it doesn't boot" on the bug report
[11:01] <ppisati> gema: which board rev?
[11:01] <ppisati> ogra_: didn't you try A1 installation on panda?
[11:01] <gema> ppisati: A4
[11:02] <ppisati> gema: i've a panda a4
[11:02] <ppisati> gema: where di you get the img?
[11:03] <gema> ppisati: from the tracker
[11:03] <gema> ppisati: http://iso.qa.ubuntu.com/qatracker/milestones/221/builds/16974/downloads
[11:04] <ppisati> gema: ok, i'm downloading it
[11:04] <ppisati> gema: i'll let you know
[11:04] <gema> ppisati: thanks
[11:04] <gema> ppisati: can I enable serial console on the early boot ?
[11:04] <gema> ppisati: so that I can see something else
[11:05] <ppisati> gema: on the installation image? uhm
[11:05] <gema> yep
[11:05] <ppisati> gema: yes, but you'll have to tinker with uboot
[11:05] <ppisati> gema: or reroll boot.scr
[11:05] <gema> I'd like to see the crash
[11:06] <gema> ppisati: ack, will try
[11:06] <ppisati> gema: what's the content of boot.scr on the first partition of the sd card?
[11:09] <gema> ppisati:  Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,2)
[11:10] <ppisati> gema: so you installed the img somewhere
[11:10] <ppisati> gema: and it's unablt to mount what root= says
[11:10] <gema> I dd'ed the image to an mmc and then tried to boot the load
[11:11] <ppisati> gema: did you have any video output?
[11:11] <gema> ppisati: no
[11:12] <ppisati> gema: did you modify boot.scr? or did you manually override u-boot vars?
[11:12] <ppisati> gema: anyway, just finished downloading the img, let me try by myself
[11:12] <gema> ppisati: I unset the bootscr var
[11:13] <gema> ppisati: I will raise a bug, now I have something to put on it :D
[11:14] <ppisati> gema: can you past the boot messages somewhere? (http://paste.ubuntu.com/)?
[11:15] <gema> yep
[11:16] <gema> ppisati: http://paste.ubuntu.com/1028413/
[11:20] <gema> ppisati: the /dev/mmcblk0p2 in the card is not ext3
[11:20] <gema> ppisati: that is probably why the board cannot load it
[11:20] <gema> ppisati: so maybe the image is wrong or .. ?
[11:20] <ppisati> i'm dding it now
[11:20] <ppisati> wait
[11:20] <gema> ok
[11:21] <ppisati> ogra_ tested the installation img yesterday (or two days ago) and he said it was ok
[11:21] <ppisati> is this img different in any way?
[11:22] <gema> ppisati: this image is from yesterday
[11:22] <gema> ppisati: and it is an A1, so I am retesting
[11:22] <gema> no result for it on the iso tracker
[11:23] <gema> ppisati: breaking for lunch now, back in a bit
[11:23] <ppisati> still dd-ing..
[11:39] <gema> ppisati: back
[11:41] <ppisati> gema: ok so
[11:41] <ppisati> gema: i just tried your img on my panda rev a.4 here
[11:41] <ppisati> gema: and it's booting
[11:42] <ppisati> gema: how did you dd the img? 
[11:42] <gema> ppisati: the image itself is broken
[11:43] <ppisati> gema: but did you rech the installation? you installed and then it paniced or what?
[11:43] <gema> ppisati: let me verify I downloaded it correctly
[11:43] <gema> ppisati: it never booted the installer
[11:43] <ppisati> gema: works here
[11:43] <ppisati> choosing the timezone now
[11:44] <gema> ppisati: ack , I will have to figure out what's wrong with my setup 
[11:44] <gema> ppisati: thanks :D
[11:44] <ppisati> gema: zcat $imgfile | sudo dd of=/dev/sdX bs=64k
[11:44] <ppisati> gema: try this
[11:45] <ppisati> gema: sd cards are picky if you don't specify dd bs=
[11:45] <gema> ppisati: I used bs=1M
[11:46] <ppisati> finished netering my user details, it's installing now
[11:46] <ppisati> *entering
[11:46] <gema> ppisati: the second partition, in my image, is ext4 yet the bootargs in uboot tell the kernel it's ext3
[11:47] <gema> ppisati: any idea how could I do that to an image?
[11:48] <gema> ppisati: also, what is the correct type for mmcrootfstype? ext3 or ext4?
[11:53] <ppisati> gema: did you modify boot.scr?
[11:53] <ppisati> gema: because i don't have that info in mine
[11:53] <ppisati> gema: setenv bootargs vram=40M mem=456M@0x80000000 mem=512M@0xA0000000   root=/dev/mmcblk0p2 fixrtc quiet splash
[11:53] <ppisati> gema: that's what you img says
[11:57] <gema> ppisati: http://paste.ubuntu.com/1028461/
[11:57] <gema> ppisati: I never get to the installer, those are the env vars for uboot
[11:58] <ppisati> gema: wait
[12:04] <ppisati> gema: i've that too, but it shouldn't use that info
[12:05] <gema> ppisati: then why is it failing there for me?
[12:05] <ppisati> gema: did you dd it again with bs=64k?
[12:05] <gema> ppisati: not yet
[12:05] <ppisati> gema: try it
[12:06] <ppisati> and the loader prompt, execute 'printenv' and paste it somewhere so i can compare it
[12:06] <ppisati> *at
[12:09] <gema> ppisati: changing the mmcrootfstype to ext4 makes it boot (I tried before rewriting the card)
[12:10] <ppisati> gema: so you've a different boot environment
[12:10] <ppisati> where does your board come from?
[12:11] <gema> ppisati: http://paste.ubuntu.com/1028479/ <- the only thing removed is bootscr
[12:11] <gema> my board came from pgraner, on the same batch as yours, I believe
[12:12] <gema> ppisati: are we happy for me to try with bs=64K ?
[12:12] <ppisati> no
[12:12] <gema> Iok
[12:12] <gema> ok
[12:12] <ppisati> don't do that
[12:12] <gema> ok
[12:13] <gema> I only have a working SD
[12:13] <ppisati> why you removed bootscr?
[12:13] <ppisati> that's the bootscript present on the sd
[12:13] <gema> ppisati: to be able to see dmesg
[12:13] <gema> serial output
[12:13] <ppisati> ok, but then you are using the env of you board that is wrong
[12:13] <ppisati> if you want serial output
[12:13] <ppisati> you need to change the file boot.scr on the first partition of the sd
[12:14] <ppisati> taking out 'quiet splash'
[12:14] <ppisati> and adding console=ttyO2,115200
[12:14] <ppisati> boot.scr is created with mknewimage
[12:14] <ppisati> wait
[12:14] <gema> ppisati: ok
[12:14] <gema> ppisati: I am going to document that in our wiki
[12:15] <ppisati> gema: mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "Ubuntu 10.10" -d ./boot.cmd ./boot.scr
[12:16] <ppisati> gema: and boot.cmd is plain text file containing onle the text part of the boot.scr you find on the sd card/first partition
[12:16] <ppisati> gema: so, open a text editor, cut&paste from boot.scr ONLY the text part
[12:16] <ppisati> gema: delete 'quiet splash'
[12:17] <ppisati> gema: add "console=yyO2,115200"
[12:17] <ppisati> gema: write the file, close the editor
[12:17] <ppisati> gema: execute
[12:17] <ppisati> gema: mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "my Ubuntu boot.scr" -d ./$TEXTFILE ./boot.scr 
[12:18] <ppisati> gema: copy the resuling boot.scr to the sd card/first partition
[12:18] <ppisati> gema: of course, do a backup oif the boot.scr found there
[12:18] <ppisati> gema: just in case
[12:19] <gema> ppisati: ack
[12:20] <ppisati> gema: try by yourself, so we can double check it
[12:20]  * ppisati is hungry
[12:21] <gema> ppisati: ack, go for lunch, it is going to take me a while... where do I do the mkimage?
[12:27] <gema> ppisati: ok, on it, follow your instructions helps x)
[13:09] <ogasawara> ppisati: care to send a quick pull request for your omap4 config sync?
[13:12] <gema> ppisati, all is good, trying to write the boot.scr to my card it started to behave weirdly
[13:12] <gema> ppisati: camera to the rescue, all it good I can boot the image and install it
[13:13] <gema> ppisati: thanks !
[13:16] <ppisati> ogasawara: i'll do
[13:23] <ppisati> ogasawara: i did some more config sync, let me test that and then i'll pull req
[13:23] <ogasawara> ppisati: ack
[14:04] <diwic> hi, kentb would need ALSA 1.0.25 linux-backports-modules on top of oneiric, any chance we can provide that to him?
[14:12] <ogra_> ppisati, fyi, omap3 fails with an USB oops and i dont get any display output once the kernel started (i get the yellow u-boot screen though)
[14:12] <ogra_> (note also that i'm on vacation, just doing some quick image tests)
[14:14] <ogra_> bug 1010024
[14:14] <ubot2> Launchpad bug 1010024 in linux "omap fails to boot with oops in qantal alpha1 " [High,New] https://launchpad.net/bugs/1010024
[14:16] <ppisati> ogra_: i know video is broken on omap3
[14:17] <ppisati> ogra_: let me try the daily img for it
[14:17] <ogra_> well, apparently USB too :) 
[14:17] <ogra_> at least that oops comes up right after USB is initialized it seems
[14:19] <ppisati> uhm
[14:19] <ppisati> let's see
[14:32]  * cking gives his network a poke
[15:14]  * ogasawara back in 20
[15:17] <davmor2> network bites cking for poking it
[15:17] <cking> yep, it's a yappy little fella
[15:20] <ppisati> ogra_: actually boots here, it reaches the installer
[15:20] <ppisati> ogra_: but since video is broken, can't go ahead
[15:21] <ppisati> ogra_: server images shoudl be fine (if we ever build it for omap3)
[15:21] <ppisati> actually the installer dies cause X can't open a screem
[15:21] <ppisati> and then drop you in # shell
[15:46] <jsalisbury> ppisati, did you happen to see this one: bug 1010024
[15:46] <ubot2> Launchpad bug 1010024 in linux "omap fails to boot with oops in qantal alpha1 " [High,Incomplete] https://launchpad.net/bugs/1010024
[16:18] <ppisati> jsalisbury: kind of saw it, it actually boots here (i was talking about it with ogra above)
[16:18] <jsalisbury> ppisati, cool thanks.  Just wanted to give you a heads up.
[16:18] <ppisati> jsalisbury: but yes, video is broken on omap3, so omap3 desktop image for A1 are dead
[16:18] <ogra_> ppisati, i'll do a bit research tomorrow when i'm not in vacation mode 
[16:19] <ppisati> ogra_: don't worry, A1 is done
[16:19] <ppisati> ogra_: A1 is the target now
[16:19] <ogra_> not worrying about A1 but about the images in general :)
[16:19] <ogra_> A1 is done indeed, we'll only release omap4
[16:20] <ogra_> omap3 in the past didnt init the graphics when you didnt have the right boot options, thats what i planned to play with ... and i didnt do more than one test, might be that the oops doesnt show on every boot 
[16:21] <ppisati> ack
[16:22] <ppisati> go have a Weizenbier for me
[16:30]  * ogra_ will do :) 
[16:47] <henrix> jsalisbury: ping
[17:09] <jsalisbury> henrix, pong
[17:10] <henrix> jsalisbury: hi! i was trying to add the series (precise and quantal) to bug #1010022
[17:10] <ubot2> Launchpad bug 1010022 in linux "Ext3 filesystems converted to ext4 can get erroneously reported as containing errors" [Medium,Triaged] https://launchpad.net/bugs/1010022
[17:10] <henrix> jsalisbury: any idea how to do that?
[17:10] <ogasawara> infinity, apw: bah, so as I'm checking the linux-firmware 1.81 build that I've just uploaded to quantal-proposed I see I managed to typo the bug # in the debian/changelog (the git tree is correct).  what's the preferred way to resolve?  upload a new 1.82 version which only corrects the changelog and then make sure we just copy the 1.82 version to the release pocket?
[17:10] <henrix> jsalisbury: i guess i've done that before, but can't remember how :-/
[17:11] <jsalisbury> henrix, I see your nominations.  I can approve them.  I think I can approve them because I'm in the release team, which you may be able to subscribe to
[17:11] <infinity> ogasawara: Nah, just fix it in git retroactively, and it'll be right on the next upload.
[17:11] <infinity> ogasawara: And go close the bug by hand.
[17:11] <ogasawara> infinity: ok cool
[17:11] <jsalisbury> henrix, I clicked approve, can you check on your end to see if it worked?
[17:12] <henrix> jsalisbury: oh, so i need approval for that! that means i've never done that before :)
[17:12] <henrix> jsalisbury: will check
[17:12] <apw> ogasawara, yeah what infinity said.  once that version is in -proposed its used up anyhow
[17:12] <infinity> ogasawara: (If it were a stable release, I'd punt it from proposed and make you try harder, but this isn't really the devel workflow)
[17:12] <henrix> jsalisbury: yeah, thats it. thanks :)
[17:12] <jsalisbury> henrix, np
[17:47] <infinity> Oh cute, my ~ was never removed from zinc, I just lots access when I was gone.
[17:47] <infinity> Not that there was anything in it other than dotfiles...
[18:01] <Daviey> ogasawara: Am i right in saying a new snapsnot of linux-firmware will resolve.. [   21.388655] microcode: failed to load file amd-ucode/microcode_amd.bin
[18:02] <Daviey> ie, should i not bother raising a bug or investigating 
[18:39] <BenC> ogasawara: how goes the rebase?
[19:43] <htorque> RAOF: hi! do you know if there's any progress on making DP output work under nouveau with NVD9 based GPUs (e.g., the 4200M in the T*20 thinkpads)?
[22:40] <RAOF> htorque: As far as I'm aware, that should be fixed somewhere in the nouveau git pipeline. My T420s died before I could test out darktama's patch, though. I'd guess it should work in 3.5, if it doesn't already work in 3.4.
[22:42] <htorque> RAOF: thanks for the info, i'll give 3.4 a go then.