[07:41]  * apw yawns
[07:43]  * smb waits
[07:46] <apw> smb, have you seen this KVM hang people are reporting in saucy (since -3 i _think_)
[07:47] <smb> apw, no, but mostly because I have not yet looked at kvm recently as I was busy with xen
[07:47] <apw> (and by hang i mean host locking solid)
[07:48] <smb> apw, do you have the bug number more ready than me?
[07:48] <apw> i saw it myself last night, and someone was reporting it on #ubuntu-kernel last night, but though i asked for a number i wasn't present if and when it was filed
[07:49] <smb> Hm... lets see what is see in scrollback...
[07:56] <apw> so there was no bug from jdstrand then ?
[07:56] <smb> not mentioned in this channel
[07:57]  * apw starts looking to see whne it was introduced
[07:57]  * apw gets out a piece of paper
[08:11] <apw> smb, jdstrand, KVM hang bug filed: bug #1204005
[08:11] <ubot2`> Launchpad bug 1204005 in linux (Ubuntu) "[saucy] kvm host hangs of guest boot with 3.10.0-5" [Critical,Triaged] https://launchpad.net/bugs/1204005
[09:01] <ppisati> apw: brb
[09:01] <ppisati> ops
[09:01] <ppisati> brb
[09:01] <apw> ppisati, heh
[09:43] <larsu> booting into 3.10.0-4 messes up my graphics. Uses vesa because it can't find /dev/dri/card0. Is that a known issue?
[09:43] <larsu> oh, this is an intel card btw
[09:54] <smb> larsu, If 3.10.0-3 was working still it might be the same module loading with arguments stopped working regression. I thought i915 was sometimes affected too. You might try the -5 kernel. apw, is that somewhere already
[09:55] <larsu> yep, -3 is definitely working (I booted into that now)
[09:55] <smb> https://launchpad.net/ubuntu/saucy/+source/linux/3.10.0-5.14
[09:56] <apw> smb, larsu, seems to be in -proposed at the moment, but there are some prerelease ones here: http://people.canonical.com/~apw/master-next-saucy/
[09:56] <smb> Currently still in proposed but that should not be enabled
[09:56] <smb> Or directly wget from launchpad
[09:58] <larsu> smb, apw: thanks, I will try that one
[09:58] <seb128> hey there
[09:58] <seb128> larsu, did you figure out your intel issue?
[10:00] <rickspencer3> apw pinging you because I thought you might be up
[10:00] <rickspencer3> wireless doesn't work for me with the new kernel :(
[10:00] <rickspencer3> and it sounds like larsu has some video issues?
[10:00] <larsu> rickspencer3: yep, apw just pointed me to -5, which might fix the issue
[10:01] <larsu> http://people.canonical.com/~apw/master-next-saucy/
[10:04] <larsu> smb, apw, rickspencer3: -5 fixes it indeed. Thanks!
[10:04] <apw> larsu, great ... it is stuck in migration cause of the alpha2 freeze, but they actually want it
[11:05] <jdstrand> apw: re bug #1204005, thanks!
[11:05] <ubot2`> Launchpad bug 1204005 in linux (Ubuntu) "[saucy] kvm host hangs of guest boot with 3.10.0-5" [Critical,Triaged] https://launchpad.net/bugs/1204005
[11:10] <smb> apw, Unfortunately I am as unsuccessful in getting the hang with a EFI booted desktop as I was before... :(
[11:11] <apw> smb, i am going to put that on the boggle list and not worry about it too much for now
[11:11] <apw> smb, it is clearly reproducible for many of us, so that is very odd indeed
[11:11] <apw> smb, so i get to find it :/
[11:12] <smb> apw, Yeah. Just sad that I cannot be of any help there
[11:15]  * ppisati -> reboot
[12:15] <nessita> diwic, hello! I'm ready for debugging whenever you can
[12:15] <diwic> nessita, hi, I just started looking at your logs
[12:15] <diwic> nessita, it looks like several "maybe" bugs in combination somehow
[12:16] <diwic> nessita, but first, don't get confused by Raymond - he's often out on the wrong track
[12:16] <nessita> diwic, I was going to mention, his comments really, really confused me
[12:20] <nessita> diwic, is there anything I can run/test from here to help?
[12:21] <diwic> nessita, maybe we should try the wakeup_rt tracer to see what's causing system latencies. Instructions coming shortly, I just have to refresh my memory a little on how to do that...
[12:22] <nessita> diwic, great, I'll wait for those
[12:28] <infinity> BenC: Were you going to do any regression testing (or a smoketest, at least) of the raring-proposed kernel on your hardware?
[12:29] <diwic> nessita, ok, now posted as comment in the bug
[12:29]  * nessita goes and check
[12:31] <diwic> nessita, when it says "run for a minute or two" that means run skype/mumble/hangout 
[12:31] <nessita> diwic, what should I run for the "Run for a minute or two" part?
[12:31] <diwic> nessita, just try to talk to someone on mumble e g
[12:31] <nessita> ah, ok
[12:37] <nessita> diwic, attached, shall I also attach the pulseaudio verbose log?
[12:38] <diwic> nessita, thanks, I'm analysing the wakeup_rt file now
[12:38] <diwic> It's the graphics, that's for sure
[12:39] <nessita> diwic, the graphics mess up with the sound?
[12:39] <diwic> nessita, do you use open-source or binary nvidia drivers?
[12:40] <nessita> diwic, checking
[12:40] <diwic> nessita, binary it seems like
[12:41] <nessita> NVIDIA Driver Version: 304.88
[12:42] <diwic> yeah, that's binary
[12:42] <nessita> yeah, wasn't fully sure because in the upgrade to raring I did not explicitely enabled any propietary drivers
[12:43] <diwic> so; either we can try pursuing this track, i e, trying different driver versions, open-source drivers if you don't need anything that the binary drivers provide etc
[12:44] <diwic> or I could try looking deeper on the PulseAudio side to see if I can understand why you start getting underruns every 200 ms 
[12:44] <diwic> or both...
[12:45] <nessita> diwic, happy to do whatever you think is best. I'm not sure about the open-source drivers, there was a time were those were underperforming, no idea now
[12:47] <diwic> nessita, okay, let's say you give the open-source nvidia drivers (nouveau) a try, and see if they work sufficiently well for you or if they cause other trouble.
[12:48] <apw> BenC, yo ... do i have access to your saucy repo, i was just trying to push the new linux-ppc-udebs thing that infinity was after
[12:48] <diwic> nessita, and if they cause trouble, come back to me and we'll try to look deeper on the PulseAudio side of things
[12:49] <nessita> diwic, so, before I do that, question: I reproduce the sounce bug in a raring booted in mem from a pendrive
[12:49] <nessita> diwic, doesn't that setup use the default stuff from the ubuntu repo?
[12:49] <nessita> I reproduced*
[12:50] <nessita> (ie, the default stuff would be the open source driver)
[12:50] <diwic> nessita, yes, if you boot Ubuntu from a pendrive, that should use the open-source drivers by default I believe
[12:50] <nessita> diwic, right, I reproduced the same audio playback issue there (was the second thing I tried -- first one was latest kernel)
[12:51] <diwic> nessita, so if that also causes the problem, it would be interesting to see what a pulseaudio verbose log looks like when booted from the pendrive
[12:52] <nessita> diwic, I can do that. Is there any way of enabling verbose pulseaudio output without rebooting
[12:52] <diwic> nessita, https://wiki.ubuntu.com/PulseAudio/Log doesn't include rebooting 
[12:53] <nessita> diwic, ah, yes, but that disables autospawn, and I've noticed different behavior of the sound stopping with or without autospawn
[12:53] <diwic> nessita, in what way is it different?
[12:53] <nessita> without autospawn is much "harder" to reproduce the bug
[12:54] <nessita> with autospawn I can reproduce almost instantly
[12:54] <diwic> nessita, autospawn is unrelated, possibly the debug level can cause that effect, but not autospawn in itself I believe
[12:54] <nessita> diwic, but if the information is the same for you in both cases, I can certainly try that
[12:55] <diwic> nessita, you can also just execute "pacmd set-log-level 4", without restarting PA, and it will start outputting the verbose log to /var/log/syslog
[12:55] <diwic> nessita, if you like that better
[12:55] <nessita> diwic, I do! will use that
[12:56] <nessita> ok, so, rebooting to raring from pendrive
[13:02]  * henrix -> lunch
[13:13] <nessita> diwic: hi there, I'm in the raring booted from pendrive. Definitely using nouveau: video                  19390  1 nouveau
[13:13] <diwic> yep
[13:13] <nessita> diwic:  ran the pacmd set-log-level 4 command but verbosity did not increased in syslog
[13:13] <nessita> diwic: shall I have restarted the pulseaudio service?
[13:14] <diwic> nessita, no, that's not necessary
[13:14] <diwic> nessita, did "pacmd set-log-level 4" say anything else than "hi and welcome to pulseaudio"?
[13:14] <nessita> diwic: yes, it did
[13:14] <nessita> will paste the whole output
[13:15] <nessita> diwic: I had audio playback at first, but opened chrome to do a hangout and audio stopped. Pasting output
[13:16] <nessita> diwic: http://paste.ubuntu.com/5904065/
[13:16] <nessita> PA output seems not verbose though
[13:17] <diwic> nessita, could you execute "pulseaudio -k", start the wakeup_rt tracer, go to a hangout, stop the wakeup_rt tracer and attach the output?
[13:17] <nessita> diwic: yes. Shall I start from a clean raring again?
[13:17] <diwic> nessita, from the pendrive
[13:18] <diwic> nessita, you don't need to reboot, just restart pulseaudio with "pulseaudio -k"
[13:18] <nessita> diwic: ack!
[13:19] <nessita> diwic: I have more log in syslog (opening it with less showed me that there was much more verbosity). Shall I pastebin that?
[13:19] <diwic> nessita, ok
[13:21] <nessita> diwic: http://paste.ubuntu.com/5904076/ doing the other test now (pulseaudio -k)
[13:22] <diwic> Scheduling delay of 105.41ms, that's a lot, really
[13:26] <nessita> diwic: does that give you any hint of what needs fixing?
[13:26] <diwic> nessita, the kernel needs fixing
[13:26] <nessita> heh
[13:27] <diwic> nessita, if we could capture one of those really high spikes with the wakeup_rt tracer it could tell what part of the kernel needed fixing, too
[13:27] <nessita> diwic: yeah, trying to do a hangout, but it keeps erroinh
[13:27] <nessita> erroing
[13:27]  * nessita is on it
[13:28] <diwic> nessita, you can also try just using the audio wizard in mumble
[13:28] <nessita> great, let me install mumble
[13:31] <nessita> gaaaah 2fa
[13:31]  * nessita hunts a 2fa code
[13:31] <diwic> nessita, no, just start the audio wizard
[13:31] <diwic> nessita, you don't need to connect to a server
[13:31] <nessita> diwic: yeah yeah, already did, the 2fa is for logging in to LP
[13:31] <nessita> and upload the trace
[13:31] <diwic> nessita, pastebin it here instead
[13:32] <nessita> diwic: as you wish, already found the code generator
[13:34] <nessita> diwic: http://paste.ubuntu.com/5904115/ (also uploaded to the bug)
[13:34] <apw> jdstrand, you are hitting this hang in kvm, could you tell me which display adpater you have configured
[13:36] <apw> jdstrand, if you have vmvga configured, could you switch it to cirrus and see if it will boot without eating your machine
[13:37] <diwic> Sarvatt, ping, what do you think of the trace nessita just posted?
[13:37] <diwic> Sarvatt, nouveau hanging the kernel for 90 ms? And nvidia did it for ~20 ms
[13:39] <diwic> Sarvatt, also I can't really understand that even if nouveau wants to do that, why don't we just schedule audio/Pulseaudio on another CPU core?
[13:43] <nessita> diwic: is there anything else I can do from this raring boot? happy to wait if that could help, but otherwise I may reboot to my "normal"  setup
[13:44] <diwic> nessita, feel free to reboot to your normal setup
[13:44] <nessita> thanks
[13:44]  * nessita brb
[13:51] <nessita> diwic, so, I will be resuming some tasks, let me know if you need something else from me
[13:51] <diwic> nessita, ok, thanks!
[13:52] <nessita> thank you :)
[13:54] <nessita> diwic, not sure if it's relevant, but in all cases mic keeps working (people keeps listening to me)
[13:55] <diwic> nessita, I'm not sure if it's relevant either.
[13:57] <nessita> ack
[14:00] <rtg> apw, just pushed a rebase to saucy unstable that might impact the boot issues on your laptop.
[14:01] <rtg> bjf, apw: did either of you have time to read the k-team email I sent yesterday entitled 'Patches dropped on the way to 3.11-rc2' ?
[14:02] <bjf> rtg, i glanced at it
[14:02]  * bjf goes back to find it
[14:03] <infinity> BenC: Are you around?  linux-ppc in saucy is very broken.
[14:24] <smb> apw, After running for a while I had a kvm guest crash my AMD machine (using vmvga). Though it took a while and also the stacktrace points to virtnet ...
[14:32] <apw> smb, hmmm perhaps it is not the same, there seems to be a lot of issues this week
[14:39] <jdstrand> apw: lucid and precise are cirrus, quantal and higher are vmvga
[14:40] <jdstrand> let me reboot to see if either makes a differnce
[14:41] <apw> jdstrand, it isn't reasonable for that to fix it at all, as clearly there should be nothing which allows a hang like this, but i would like to confirm you see the same as me
[14:43] <jdstrand> apw: yeah, and fwiw, cirrus is rubbish for quantal and higher 
[14:45] <apw> jdstrand, yep, i was much happier with the other one in R, but if it is that at least i have it cornered a little
[14:45] <jdstrand> there is a bug on that too
[14:46] <jdstrand> bug #1080674 was for display corruption
[14:46] <ubot2`> Launchpad bug 1080674 in cairo "[QEMU] Corrupted desktop screen for raring desktop installation in QEMU guest (Cirrus graphics). Affects KVM but not VBox." [Medium,Confirmed] https://launchpad.net/bugs/1080674
[14:47] <jdstrand> but on quntal, there were frequent guest crashes
[14:47] <jdstrand> I don't know if a bug was filed for that
[14:47] <smb> jdstrand, fwiw it also affects Xen and you cannot change the gfx there :-P
[14:48]  * smb wished they had fixed the driver and not just the default gfx card for KVM
[14:48]  * rtg starts bisect for mb raid0 mount failure in 3.11-rc2
[14:48] <rtg> md*
[14:53] <jsalisbury> **
[14:53] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[14:53] <jsalisbury> **
[14:54] <infinity> I assume someone's still looking at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1204005 ?
[14:54] <ubot2`> Ubuntu bug 1204005 in linux (Ubuntu) "[saucy] kvm host hangs of guest boot with 3.10.0-5" [Critical,Triaged]
[14:55] <rtg> infinity, I think apw is on it
[14:55] <apw> infinity, yeah that one i am working on right now
[14:56] <apw> infinity, if you switch the graphics for your VM to cirrus it'll likely stop it eating your machine
[14:56] <apw> while i struggle to find out wtf is going on
[14:56] <nessita> diwic, saw your comment in the bug, shall I try that ppa with my current raring installation (nvidia) or booting raring from the pendrive?
[14:56] <infinity> rtg: Oh, you mentioned that the foo-udebs package blows up for you on lts-raring?  I don't much care but, on the other hand, we tried to engineer it to work right for derivative kernels.  What breaks?
[14:57] <rtg> infinity, I fixed it, no big deal.
[14:57] <infinity> apw: I'm not hitting it personally, I'm just being annoying about following up on what looks like a nasty bug.
[14:57] <apw> rtg, what did you have to change
[14:57] <rtg> apw, added the flavours bit that is specific to saucy LTS
[14:57] <rtg> control info
[14:57] <apw> oh yeah, i see what you mean
[14:58] <apw> infinity, so he just had to configure it is all
[14:58] <infinity> Right, okay.  I was worried that fixing it meant breaking it. ;)
[14:58] <rtg> gimme _some_ credit :)
[14:59] <infinity> rtg: I dunno.  Do I have to?
[15:10] <jdstrand> apw: ok, booting into 3.10.0-5 I started amd and i386 vms for lucid and precise, all at once, all using cirrus
[15:11] <jdstrand> apw: I got to the login screen, logged in, started a browser, all fine
[15:11] <jdstrand> apw: I then shut those down, and started an amd64 saucy vm with vmvga, got to the login screen, logged in and bam
[15:12] <jdstrand> I don't think I always had to log in though
[15:12] <jdstrand> (maybe, not sure)
[15:12] <apw> jdstrand, that sounds like waht i saw thanks
[15:13] <apw> so somehow vmvga tickles this, now to try and work out how a userspace emulation is imploding the world
[15:21] <BenC> infinity: Broken how?
[15:21] <diwic> nessita, it does not matter.
[15:22] <infinity> -rw------- 1 adconrad adconrad 153262637 Jul 23 07:59 vmlinux-3.10.0-0-powerpc64-smp
[15:22] <infinity> -rw------- 1 adconrad adconrad   5148092 Jul 23 07:59 vmlinux-3.10.0-0-powerpc-e500
[15:22] <infinity> -rw------- 1 adconrad adconrad   5160618 Jul 23 07:59 vmlinux-3.10.0-0-powerpc-e500mc
[15:22] <infinity> -rw------- 1 adconrad adconrad 113357254 Jul 23 08:00 vmlinux-3.10.0-0-powerpc-smp
[15:22] <infinity> BenC: ^-- The lack of stripping on two out of four flavours...
[15:23] <BenC> That's…very odd
[15:23] <nessita> diwic, ack!
[15:28] <BenC> infinity: I'll check into it
[15:32] <infinity> BenC: Many thanks.
[15:44] <BenC> infinity: how do I reproduce the environment in the buildds that causes it to build debug debs?
[15:45] <BenC> infinity: And are the modules stripped ok?
[15:45] <apw> BenC, full_build=true to fdr binary-arch will ensure the ddebs are made, expect it to take a while though
[15:46] <apw> BenC, if you are using an sbuilder then you can find where we set that in the source and just force it on
[15:47] <BenC> apw: Thanks
[15:47] <infinity> BenC: Can you think of a module that would be large enough to tell for sure?
[15:47] <BenC> du -sh /lib/modules/*
[15:47] <BenC> And see if there's a large descrepancy
[15:47] <apw> file on them tells you if they are stirppedd or not
[15:47] <infinity> BenC: file(1) claims none of my modules are stripped, even for e500*
[15:48] <BenC> 131M	/lib/modules/3.10.0-0-powerpc-e500mc
[15:48] <BenC> 123M	/lib/modules/3.8.0-11-powerpc-e500mc
[15:48] <BenC> 123M	/lib/modules/3.8.0-12-powerpc-e500mc
[15:48] <BenC> I suspect the modules are ok for e500mc
[15:48] <infinity> http://paste.ubuntu.com/5904539/
[15:48] <BenC> At least they match up with raring
[15:48] <infinity> Random module pick.
[15:49] <infinity> So, I dunno.  file(1) could be wrong, or module stripping might just be weird.
[15:49] <BenC> I don't think they would be fully stripped
[15:49] <infinity> Yeah, it could just be file being wrong.
[15:49] <BenC> There'd at least a debug link to the /usr/lib/debug blob
[15:50] <infinity> BenC: Anyhow, as you point out, the module sizes appear to match 3.8.x, ish.
[15:50] <BenC> infinity: My guess is that the ppc64/ppc-smp kernels show this problem because it is just a copy of vmlinux where as e500 kernels are the uImage (stripped/compressed/wrapped)
[15:50] <infinity> BenC: So, whatever's going wrong here, I imagine it's just the kernel images.
[15:51] <BenC> Probably need to add some machinery to strip these sorts of cases
[15:51] <infinity> BenC: I'm a bit curious as to how that only became necessary between 0.3 and 0.5
[15:51] <BenC> apw: this will likely be something to pull back into master for debian/rules.d/ 
[15:51] <infinity> BenC: Did we not always have massive debug kernels that needed stripping?
[15:52] <BenC> infinity: That's what I'm wondering
[15:52] <infinity> BenC: The new CONFIG_ option may have tickled this.
[15:52] <BenC> What is the config option?
[15:52] <infinity> CONFIG_DYNAMIC_DEBUG=y
[15:52] <infinity> And CONFIG_DEBUG_INFO
[15:52] <infinity> So, two of them.
[15:53] <BenC> debian.ppc/config/config.common.ubuntu:# CONFIG_DYNAMIC_DEBUG is not set
[15:53] <BenC> CONFIG_DEBUG_INFO is on
[15:54] <BenC> That's likely it
[15:54] <rtg> BenC, is that a change from 0.3 ?
[15:55] <BenC> rtg: Did this problem not happen in previous saucy linux-ppc kernels?
[15:55] <infinity> +  [ Ubuntu: 3.10.0-2.11 ]
[15:55] <infinity> +
[15:55] <infinity> +  * [Config] enforce CONFIG_DEBUG_INFO
[15:55] <infinity> BenC, rtg: This only showed up in -0.5, -0.3 was fine.  And -0.5 includes the above rebase.
[15:56] <BenC> Ah, I remember having to enable that for the enforce
[15:56] <BenC> Had it disabled before
[15:56] <BenC> Problem identified
[15:56] <infinity> So, it's probably right to enforce that, *but*, only if we can sanely strip the kernel that lands in the pakcages. :P
[15:56] <infinity> Otherwise, dropping it for PPC for now seems a sane workaround.
[16:08] <apw> yeah striping is normal during install i am supprised yours is not
[16:10] <BenC> infinity: I can safely get it to strip
[16:11] <apw> BenC, i am somewhat supprised you have to get it stripped
[16:11] <apw> as the install i am sure asks for that for the binaries, and not for the ddebs
[16:11] <BenC> apw: All of the other kernels that end up in .deb's are bzImage and similar, which get stripped before they are compressed
[16:11] <BenC> apw: ppc/ppc64 use the raw vmlinux, which doesn't
[16:11] <infinity> Yeah, but this should have been a problem for years, not suddenly today.
[16:11] <infinity> That's what I'm unsure about.
[16:12] <BenC> infinity: CONFIG_DEBUG_INFO wasn't enabled on ppc before this
[16:12] <infinity> I mean, yeah, more CONFIG_DEBUG stuff got turned on, but the kernels should have still been big and debuggy before.
[16:12] <apw> BenC, good to know
[16:12] <infinity> BenC: Oh, that *was* enabled elsewhere before, but not enforced on PPC?
[16:12] <BenC> Right
[16:13] <BenC> Probably because nobody felt like dealing with it (maybe even me)
[16:13] <apw> enforcement is new, because we lost it in master and that is bad for the ddebs
[16:13] <infinity> Well, it would have never been on on PPC, even when it was in master, then.
[16:13] <infinity> That's the bit I'm confused about.
[16:14] <apw> hmm indeed, odd
[16:14] <infinity> apw: Is CONFIG_DEBUG_INFO actually arch-specific in precise?
[16:14] <BenC> The debian.master/config/enforce is what changed
[16:14] <infinity> BenC: Sure, but keep in mind powerpc wasn't always rebased source.  I'm trying to sort out the root of this.
[16:14] <BenC> infinity: Most likely
[16:14] <infinity> If it really was arch-specific (perhaps due to this), that's a bit lolz.
[16:15] <infinity> BenC: Anyhow, I assume there's some canonical kernel way to strip that isn't just "strip vmlinux"?
[16:16] <BenC> infinity: I'm checking if there's maybe a "make STRIP=1 vmlinux or something like that
[16:16] <apw> there must be a way
[16:16] <infinity> I nly see the MOD_STRIP business.
[16:17] <apw> stupid thing
[16:19] <infinity> $(obj)/vmlinux.strip: vmlinux
[16:19] <infinity>         $(STRIP) -s -R .comment $< -o $@
[16:24] <apw> yeah you might be able to switch
[16:24] <infinity> No idea if that's bootable, but that seems to be the object we'd want.
[16:24] <infinity> (I see no reason why it wouldn't be bootable, I just can't test right now)
[16:24] <infinity> BenC: ^
[16:25] <infinity> BenC: So we want vmlinux.strip, not vmlinux, and a bit of movey-twiddling when installing it.
[16:25] <BenC> infinity: Ah, that's really easy to do then
[16:25] <infinity> (Which is fine, you have to rename it anyway to add version/abi/etc)
[16:26] <BenC> Doesn't require syncing a fix back to master
[16:44] <rtg> apw, drat. my SNB mount failure appears to be Ubuntu specific. vanilla 3.11-rc2 works OK.
[16:56] <jsalisbury> ##
[16:56] <jsalisbury> ## Kernel team meeting in 5 minutes
[16:56] <jsalisbury> ##
[17:06]  * ppisati -> gym
[17:34]  * rtg -> lunch
[19:38] <xnox> does our mako kernel have USB on the go patches ?
[19:39] <ogra_> xnox, all android kernels use the android gadget to be able to run adb
[19:39] <ogra_> so USb is claimed by that atm
[19:39] <xnox> ogra_: ok, but that was not my question =)
[19:40] <ogra_> well, we dont really offer a way to re-enable adb again if you disable it 
[19:40] <xnox> stock mako kernel has on-the-go disabled and needs patches to be enabled, there are custom kernels available on $forums, but i'd like mine from a deb =)))))
[19:40] <ogra_> and you cant reboot without cmdline ... so it would be useless 
[19:41] <ogra_> we'd need a UI switch to toggle adb, then you could use OTG 
[19:42] <ogra_> i assume we will want these patches in 14.04 for convergence though 
[20:32]  * rtg -> EOD
[22:05] <F41l> Question... can I get 32bit ubuntu kernel booting with EFI?
[22:05] <F41l> I have an IA32, efi-only atom tablet that I'm having issue getting ubuntu installed on. I tried a method of installing to a usb-stick and using boot-repair to change it to EFI, but it's complaining about the kernel not being compatible.
[22:17] <BenC> infinity: Can yaboot use gzip compressed kernels?
[22:20] <BenC> infinity: Better yet, can I send you a deb to see if it works on your ppc64 and ppc32?
[22:46] <RAOF> F41l: As far as I'm aware, EFI-for-IA32 is blissfully unimplemented.
[22:57] <infinity> BenC: Not home in front of test hardware until August. :/
[22:57] <infinity> BenC: I think it would be safe to assume the stripped vmlinux would boot fine, gzipped kernels would need a lot more testing, and not all ppc32 machines are yaboot.
[22:58] <BenC> infinity: Unfortunately, you can't "make vmlinux.strip" directly, and calling "make zImage" creates vmlinux.strip.gz
[22:59] <BenC> infinity: The compressed zImage is actually an executable, that would unzip itself
[22:59] <BenC> I just need to make sure it works
[23:01] <infinity> BenC: Sure, I realize what a zImage is and I realize that, in theory, it should Just Work from pretty much any bootloader, but I make no guarantees.  One would think that if there were no problems with zImage on PPC, we'd have been using them all along, no?
[23:01] <infinity> BenC: And, at least on my 32-bit system, I fear for things like BootX and Quik sucking. :P
[23:04] <infinity> BenC: Right, so, load addresses are the issue.  Any modern yaboot should probably be fine, ancient bootloaders (like mine) might not be.
[23:04] <infinity> BenC: You could just make vmlinux and strip it with the same arguments that vmlinux.strip uses as you install it to the deb?
[23:05] <BenC> infinity: Yes, but that requires me to mess with things in debian/rules.d/ and I was hoping to avoid that :)
[23:07] <infinity> BenC: Well, I'm willing to bet I won't be able to coax my ppc32 machine into booting a zImage, but happy to play next month when I get home.
[23:07] <infinity> BenC: I realize that machine (an ancient G3) is hardly a large or common use-case, but I see no reason to gratuitously break it either.
[23:08] <BenC> infinity: Very true
[23:08] <infinity> BenC: From what I can tell, though, yaboot should have supported zImage since 2001, ish.
[23:09] <infinity> BenC: We can, again, confirm that when I get home, but I'd see no reason we can't switch ppc64 to zImage if that's true, since the only ppc64 bootloaders we use (yaboot or grub2) would both work.
[23:09] <BenC> infinity: I'd be willing to bet the executable zImage will work even on your machines, but I'd have to make sure
[23:09] <BenC> infinity: I might post these images to debian-powerpc and see if people can test it
[23:10] <infinity> BenC: Well, as pointed out in the yaboot-supporting-zImage thread I found, the fundamental issue is that the bootloader needs to detect if the image is a zImage or vmlinux, cause they need to be loaded to a different address before jumping into them.
[23:10] <infinity> BenC: http://lists.debian.org/debian-powerpc/2001/09/msg00710.html
[23:10] <infinity> BenC: So, I'm willing to bet no one ever bothered to retrofit quik and bootx to do that, cause who cares.
[23:12] <infinity> BenC: Worse, benh hasn't touched bootx since 2000 or so, so I imagine it's bitrotted to the point where my trying to fix it would make me want to shoot myself.  Or he may have even lost the source, I forget noew.
[23:14] <infinity> BenC: On the other hand, we don't support bootable media with anything but yaboot, so I could totally support zImage by default, and a bit of a hack to provide a linux-image-coff package that just has the vmlinux binary in it (and depends on the full linux-image) for schmucks like me. ;)
[23:15] <infinity> BenC: If we do some testing and discover that zImage works for everyone who isn't me, I may give you a patch to do that.
[23:15] <infinity> BenC: Cause smaller kernels for everyone who can use them sounds good.
[23:15] <BenC> infinity: How about this…I'll upload with zImage and we'll figure out the fallout from there :)
[23:16] <BenC> Worse case, we revert to stripped vmlinux
[23:16] <infinity> BenC: Sure.  I suspect the fallout won't be all that interesting.  The people in my position (stuck with ancient bootloaders) are probably few, far between, and all running Debian.
[23:17] <infinity> BenC: Oh, wait.
[23:17] <infinity> BenC: No, please don't.
[23:17] <infinity> BenC: We'll need a migration strategy too.
[23:17] <infinity> BenC: Cause that changes the names yaboot.conf needs to look for.
[23:17] <BenC> infinity: Well, if it "just works" what is there to migrate?
[23:18] <BenC> No, I left it as vmlinux (I don't really care about the name matching with x86 vmlinuz type things)
[23:18] <infinity> BenC: Oh, fair enough.  If the naming doesn't change, it should Just Work, unless it doesn't. ;)
[23:18] <infinity> BenC: I'd test remotely right now, but I need that machine to not explode while I'm away. :/
[23:19] <BenC> I'll expect a full report when you return home :)
[23:19] <BenC> Or at least silence if everything works with no harm done
[23:19] <infinity> BenC: Although, qemu-system-powerpc should emulate a yaboot-using type of machine.
[23:20] <BenC> I think qemu stuff boots linux directly
[23:20] <infinity> BenC: I'm pretty sure you'll hear from me about the ppc32 kernel.  But we'll see.  Maybe I'll get lucky.
[23:21] <BenC> Even on e500 qemu stuff it doesn't even emulate uBoot
[23:23] <infinity> Well, there's an openfirmware build specifically for qemu, which leads me to believe it *can* give you an early boot experience, if you so choose.
[23:24] <infinity> Admittedly, I've never used it, cause I have faster PPC hardware than I could possibly emulate on my x86 kit.
[23:24] <BenC> I'll toss it around in there and see what happens
[23:24] <infinity> BenC: openhackware - OpenFirmware emulator for PowerPC
[23:25] <infinity> BenC: Not installed as a dep of qemu by default, to keep the PPC cross-compiler and friends out of main, so you'll need to install it.
[23:26] <infinity> Oh, hrm.  The package description claims it doesn't know forth, so maybe it just fakes it.
[23:26] <infinity> And yaboot is a forth OF application, isn't it?
[23:26] <infinity> So, nevermind.
[23:26] <infinity> Not a valid test.
[23:26] <BenC> yaboot is 32-bit native
[23:26] <infinity> Oh, is it?
[23:26] <BenC> only the bootX stuff is forth
[23:26] <infinity> It was quik that was forth.
[23:27] <BenC> I know the boot logo is in forth :)
[23:27] <infinity> BootX is a MacOS application.
[23:27] <BenC> Ah, right
[23:27] <BenC> yaboot is the same base code as silo
[23:27] <BenC> Neither of which is forth
[23:27] <BenC> Althought both call into open firmware routines in order to work
[23:28] <BenC> So maybe openhackware implements just enough for that
[23:28] <F41l> RAOF: "blissfully unimplemented", as in, not coded, or... do I need a module, something?
[23:28] <infinity> It's probably high time I spend a Saturday just switching PPC to grub2 and ditching yaboot anyway.
[23:28] <infinity> Not that this helps my poor beige G3 with its BootX woes. :P
[23:29] <RAOF> F41l: Not coded, AFAIK
[23:29] <F41l> fek
[23:29] <BenC> infinity: I purchased an Apple //c last week from a thrift store…thinking of adding a 6502-a2c kernel some time soonish
[23:29] <F41l> how am I supposed to run 32bit 'buntu on an EFI-only system?
[23:29] <F41l> thought linux runs on friggin' everything!
[23:29] <infinity> BenC: Hah.  Masochist. :)
[23:29] <BenC> F41l: why not run 64-bit?
[23:29] <F41l> Impossible with this system.
[23:30] <infinity> BenC: I assume it's a 32-bit-only Atom.
[23:30] <F41l> It's IA32 Atom
[23:30] <infinity> Intel's special way of saying they hate you.
[23:30] <BenC> F41l: Oh, I suspect it's not an EFI problem as much as a correct kernel problem
[23:30] <BenC> You said you got it to boot a kernel but it claimed it wasn't the right type of system
[23:31] <F41l> Not necessarily. 
[23:31] <BenC> Atom requires special binary, right?
[23:31] <BenC> Like, it can't just run any old x86-32-bit kernel
[23:31] <F41l> I installed ubuntu on a USB drive (as the hard drive), and am trying to change that installation to use an EFI bootloader.
[23:31] <infinity> No, Atoms are just plain old i686
[23:32] <infinity> But you need an EFI-happy kernel (and bootloader) if you have EFI-only firmware.  We provide none of that on i386.
[23:32] <BenC> infinity: I thought the assembly was slightly different because of some ripped out functionality...
[23:32] <F41l> using the boot-repair-disk, I attempted to do this, but the software gave me an error akin to something that the kernel wasn't compatible.
[23:32] <BenC> Ah
[23:32] <BenC> F41l: As they say in my country…SoL
[23:33] <infinity> F41l: It's not wrong, our 32-bit kernels don't support EFI (and 32-bit EFI may be incomplete upstream too, haven't looked in a while), and we also don't provide a 32-bit grub-efi.
[23:33] <F41l> Seems kind of dumb to alienate an entire swath of systems from running ubuntu.
[23:33] <infinity> F41l: This isn't Ubuntu.  Upstreams don't support 32-bit EFI either, or didn't last we checked.
[23:33] <BenC> F41l: I doubt it's an ubuntu problem
[23:33] <F41l> I can get elilo to boot, but need a kernel too
[23:34] <infinity> F41l: And to be fair, that "whole swath" is, like, three and a half computers.  All 32-bit Atoms were legacy BIOS until very, very recently.
[23:34] <BenC> F41l: and to be fair the "swath" of Atom-EFI systems is more like a sliver 
[23:34]  * BenC ^5's infinity
[23:35] <F41l> *surprised horror* you rather I run windows 8
[23:35] <F41l> !
[23:35] <Sarvatt> they even made 64bit atoms that never got 64bit blob drivers (hello cedartrail with pvr graphics blobs) so needed the 32 bit efi crap to fix that fail.
[23:35] <infinity> F41l: Anyhow, this isn't something we're being intentionally obtuse about either.  If the upstream support is there, we'll look at enabling EFI on i686 in Ubuntu too.
[23:36] <F41l> blegh
[23:36] <F41l> fucking clovertrail
[23:36] <infinity> F41l: Trolling us with "threats" to run the OS that came on your hardware won't really help. ;)
[23:36] <F41l> It was a joke :P
[23:36] <infinity> It won't convince me to port Ubuntu Touch to iPhones either.
[23:36] <F41l> If i had the technical knowhow and programming knowledge I'd single handedly put the support in myself.
[23:36] <F41l> But I don't.
[23:36] <F41l> *cry*
[23:37] <F41l> I'd really like ubuntu touch to work on this device.
[23:37] <F41l> I was going to settle for using Kubuntu and KDE Active
[23:37] <infinity> Sarvatt: Mentioning cedartrail around me is a punishable offense.
[23:38] <Sarvatt> infinity: hey you just messed with it on the archive side, i had to put up with it for months working with intel :)
[23:39] <infinity> Sarvatt: You were paid to do it, I do 95% of my archive admin stuff off hours as a volunteer.
[23:39] <Sarvatt> infinity: ugh, I'm so sorry.
[23:39] <infinity> Sarvatt: So, basically, I was volunteering to gouge my eyes out with a fork and scream obscenities into the nether.