=== dannf` is now known as dannf | ||
=== smb` is now known as smb | ||
* apw yawns | 07:41 | |
* smb waits | 07:43 | |
apw | smb, have you seen this KVM hang people are reporting in saucy (since -3 i _think_) | 07:46 |
---|---|---|
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:47 |
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:48 |
smb | Hm... lets see what is see in scrollback... | 07:49 |
apw | so there was no bug from jdstrand then ? | 07:56 |
smb | not mentioned in this channel | 07:56 |
* apw starts looking to see whne it was introduced | 07:57 | |
* apw gets out a piece of paper | 07:57 | |
=== fmasi_afk is now known as fmasi | ||
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 | 08:11 |
=== ara is now known as Guest55554 | ||
ppisati | apw: brb | 09:01 |
ppisati | ops | 09:01 |
ppisati | brb | 09:01 |
apw | ppisati, heh | 09:01 |
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:43 |
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:54 |
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:55 |
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:56 |
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? | 09:58 |
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:00 |
larsu | http://people.canonical.com/~apw/master-next-saucy/ | 10:01 |
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 | 10:04 |
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:05 |
smb | apw, Unfortunately I am as unsuccessful in getting the hang with a EFI booted desktop as I was before... :( | 11:10 |
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:11 |
smb | apw, Yeah. Just sad that I cannot be of any help there | 11:12 |
* ppisati -> reboot | 11:15 | |
=== fmasi is now known as fmasi_afk | ||
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:15 |
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:16 |
nessita | diwic, is there anything I can run/test from here to help? | 12:20 |
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:21 |
nessita | diwic, great, I'll wait for those | 12:22 |
infinity | BenC: Were you going to do any regression testing (or a smoketest, at least) of the raring-proposed kernel on your hardware? | 12:28 |
diwic | nessita, ok, now posted as comment in the bug | 12:29 |
* nessita goes and check | 12:29 | |
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:31 |
nessita | diwic, attached, shall I also attach the pulseaudio verbose log? | 12:37 |
diwic | nessita, thanks, I'm analysing the wakeup_rt file now | 12:38 |
diwic | It's the graphics, that's for sure | 12:38 |
nessita | diwic, the graphics mess up with the sound? | 12:39 |
diwic | nessita, do you use open-source or binary nvidia drivers? | 12:39 |
nessita | diwic, checking | 12:40 |
diwic | nessita, binary it seems like | 12:40 |
nessita | NVIDIA Driver Version: 304.88 | 12:41 |
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:42 |
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:43 |
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:44 |
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:45 |
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:47 |
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:48 |
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:49 |
=== fmasi_afk is now known as fmasi | ||
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:50 |
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:51 |
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:52 |
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:53 |
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:54 |
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:55 |
nessita | ok, so, rebooting to raring from pendrive | 12:56 |
* henrix -> lunch | 13:02 | |
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:13 |
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:14 |
nessita | diwic: I had audio playback at first, but opened chrome to do a hangout and audio stopped. Pasting output | 13:15 |
nessita | diwic: http://paste.ubuntu.com/5904065/ | 13:16 |
nessita | PA output seems not verbose though | 13:16 |
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:17 |
diwic | nessita, you don't need to reboot, just restart pulseaudio with "pulseaudio -k" | 13:18 |
nessita | diwic: ack! | 13:18 |
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:19 |
nessita | diwic: http://paste.ubuntu.com/5904076/ doing the other test now (pulseaudio -k) | 13:21 |
diwic | Scheduling delay of 105.41ms, that's a lot, really | 13:22 |
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:26 |
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:27 | |
diwic | nessita, you can also try just using the audio wizard in mumble | 13:28 |
nessita | great, let me install mumble | 13:28 |
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:31 |
nessita | diwic: as you wish, already found the code generator | 13:32 |
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:34 |
apw | jdstrand, if you have vmvga configured, could you switch it to cirrus and see if it will boot without eating your machine | 13:36 |
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:37 |
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:39 |
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:43 |
diwic | nessita, feel free to reboot to your normal setup | 13:44 |
nessita | thanks | 13:44 |
* nessita brb | 13:44 | |
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:51 |
nessita | thank you :) | 13:52 |
nessita | diwic, not sure if it's relevant, but in all cases mic keeps working (people keeps listening to me) | 13:54 |
diwic | nessita, I'm not sure if it's relevant either. | 13:55 |
nessita | ack | 13:57 |
rtg | apw, just pushed a rebase to saucy unstable that might impact the boot issues on your laptop. | 14:00 |
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:01 |
bjf | rtg, i glanced at it | 14:02 |
* bjf goes back to find it | 14:02 | |
infinity | BenC: Are you around? linux-ppc in saucy is very broken. | 14:03 |
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:24 |
=== josepht_ is now known as josepht | ||
apw | smb, hmmm perhaps it is not the same, there seems to be a lot of issues this week | 14:32 |
jdstrand | apw: lucid and precise are cirrus, quantal and higher are vmvga | 14:39 |
jdstrand | let me reboot to see if either makes a differnce | 14:40 |
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:41 |
jdstrand | apw: yeah, and fwiw, cirrus is rubbish for quantal and higher | 14:43 |
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:45 |
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:46 |
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:47 |
* 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:48 |
jsalisbury | ** | 14:53 |
jsalisbury | ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting | 14:53 |
jsalisbury | ** | 14:53 |
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:54 |
rtg | infinity, I think apw is on it | 14:55 |
apw | infinity, yeah that one i am working on right now | 14:55 |
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:56 |
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:57 |
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:58 |
infinity | rtg: I dunno. Do I have to? | 14:59 |
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:10 |
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:11 |
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:12 |
apw | so somehow vmvga tickles this, now to try and work out how a userspace emulation is imploding the world | 15:13 |
BenC | infinity: Broken how? | 15:21 |
diwic | nessita, it does not matter. | 15:21 |
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:22 |
BenC | That's…very odd | 15:23 |
nessita | diwic, ack! | 15:23 |
BenC | infinity: I'll check into it | 15:28 |
infinity | BenC: Many thanks. | 15:32 |
BenC | infinity: how do I reproduce the environment in the buildds that causes it to build debug debs? | 15:44 |
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:45 |
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:46 |
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:47 |
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:48 |
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:49 |
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:50 |
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:51 |
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:52 |
BenC | debian.ppc/config/config.common.ubuntu:# CONFIG_DYNAMIC_DEBUG is not set | 15:53 |
BenC | CONFIG_DEBUG_INFO is on | 15:53 |
BenC | That's likely it | 15:54 |
rtg | BenC, is that a change from 0.3 ? | 15:54 |
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:55 |
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. | 15:56 |
apw | yeah striping is normal during install i am supprised yours is not | 16:08 |
BenC | infinity: I can safely get it to strip | 16:10 |
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:11 |
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:12 |
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:13 |
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:14 |
infinity | BenC: Anyhow, I assume there's some canonical kernel way to strip that isn't just "strip vmlinux"? | 16:15 |
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:16 |
apw | stupid thing | 16:17 |
infinity | $(obj)/vmlinux.strip: vmlinux | 16:19 |
infinity | $(STRIP) -s -R .comment $< -o $@ | 16:19 |
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:24 |
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:25 |
BenC | Doesn't require syncing a fix back to master | 16:26 |
rtg | apw, drat. my SNB mount failure appears to be Ubuntu specific. vanilla 3.11-rc2 works OK. | 16:44 |
jsalisbury | ## | 16:56 |
jsalisbury | ## Kernel team meeting in 5 minutes | 16:56 |
jsalisbury | ## | 16:56 |
* ppisati -> gym | 17:06 | |
=== jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues August 13th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! | ||
* rtg -> lunch | 17:34 | |
=== fmasi is now known as fmasi_afk | ||
xnox | does our mako kernel have USB on the go patches ? | 19:38 |
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:39 |
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:40 |
ogra_ | we'd need a UI switch to toggle adb, then you could use OTG | 19:41 |
ogra_ | i assume we will want these patches in 14.04 for convergence though | 19:42 |
* rtg -> EOD | 20:32 | |
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:05 |
BenC | infinity: Can yaboot use gzip compressed kernels? | 22:17 |
BenC | infinity: Better yet, can I send you a deb to see if it works on your ppc64 and ppc32? | 22:20 |
=== kentb is now known as kentb-out | ||
RAOF | F41l: As far as I'm aware, EFI-for-IA32 is blissfully unimplemented. | 22:46 |
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:57 |
BenC | infinity: Unfortunately, you can't "make vmlinux.strip" directly, and calling "make zImage" creates vmlinux.strip.gz | 22:58 |
BenC | infinity: The compressed zImage is actually an executable, that would unzip itself | 22:59 |
BenC | I just need to make sure it works | 22:59 |
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:01 |
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:04 |
BenC | infinity: Yes, but that requires me to mess with things in debian/rules.d/ and I was hoping to avoid that :) | 23:05 |
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:07 |
BenC | infinity: Very true | 23:08 |
infinity | BenC: From what I can tell, though, yaboot should have supported zImage since 2001, ish. | 23:08 |
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:09 |
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:10 |
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:12 |
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:14 |
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:15 |
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:16 |
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:17 |
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:18 |
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:19 |
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:20 |
BenC | Even on e500 qemu stuff it doesn't even emulate uBoot | 23:21 |
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:23 |
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:24 |
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:25 |
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:26 |
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:27 |
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:28 |
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:29 |
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:30 |
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:31 |
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:32 |
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:33 |
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:34 | |
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:35 |
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:36 |
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:37 |
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:38 |
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. | 23:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!