| jMCg | I'd argue one of the basic operations of an OS is to boot. If it can't do that, then something's going wrong. | 01:01 |
|---|---|---|
| jMCg | Wonderful, after installing the kernel from oneiric-proposed, it still doesn't boot. | 01:33 |
| ppisati | moin | 07:55 |
| === smb` is now known as smb | ||
| smb | morning | 08:20 |
| * apw waves to smb | 08:24 | |
| * smb waves back | 08:25 | |
| ppisati | *reboot after dist-upgrade | 08:40 |
| jMCg | https://bugs.launchpad.net/ubuntu-release-notes/+bug/818177/ (#128) | 09:05 |
| ubot2` | Launchpad bug 818177 in udev "boot failures as /dev is not transferred to /root (because 'udevadm exit' times out waiting for a deadlocked worker)" [High,Fix released] | 09:06 |
| jMCg | So, after six hours it's still dead-locked, yes. | 09:07 |
| smb | A lockup that long does not sound like the initial problem | 09:48 |
| apw | henrix, morning | 10:18 |
| apw | jMCg, what are you seeing exactly, and are you using lvm | 10:19 |
| henrix | apw: hey, morning | 10:25 |
| cking | smb, http://awaseconfigurations.wordpress.com/2011/11/21/automated-ubuntu-release-upgrade/ | 10:29 |
| smb | cking, Ah thank, guess I have to fold that into doing it through do-release-update. At least that has a frontend option as well iirc. It just did not explain much. And the dpkg env variable theoreticall should pass it as well... | 10:36 |
| * smb will reset the vm and try | 10:36 | |
| * cking wishes smb luck | 10:37 | |
| * smb needs to re-adjust coffee levels first, though | 10:37 | |
| jMCg | apw: the kvm's installed on an LVM partition. It doesn't use lvm by itself (I even uninstalled the lvm2 and mdadm packages from the VM images) | 10:46 |
| jMCg | What I pasted is what I see in the end, of course I can paste the entire boot process. | 10:46 |
| smb | jMCg, And the problem is the kvm guest that does not boot? | 10:47 |
| jMCg | smb: it doesn't finish booting. It starts, which is great progress! | 10:48 |
| smb | At least that could make it less likely related to the initial problem. Is that guest running with the graphical splash screen or a server install coming up in text mode? | 10:53 |
| smb | Not sure whether one can send kvm magic sysrq-keys... That might be one way to find out what is blocking... | 10:54 |
| jMCg | smb: I'm on the serial console thingy, I don't think it's got any splash stuff installed. (It's based on my ISP's minimal image, I don't think that has any splash stuff) | 10:55 |
| smb | jMCg, Hm, ok so a blind stab would be to try press 's' when it hangs. | 10:56 |
| smb | There had been cases in the past when mountall was waiting for something but did not print a message when there was no plymouth | 10:56 |
| jMCg | Oh... plymouth is installed, wonder why | 10:56 |
| jMCg | mountall depends on plymouth. that explains it, I guess. | 10:57 |
| jMCg | ii plymouth-theme-ubuntu-text 0.8.2-2ubuntu28 graphical boot animation and logger - ubuntu-logo theme | 10:58 |
| jMCg | Okay, waiting for the 61 timeout to finish. | 10:59 |
| jMCg | smb: pressing s does nothing. | 11:02 |
| jMCg | Just as a reminder: I'm booting the kvm, I'm connected to it via serial console | 11:03 |
| smb | jMCg, Ok, but I guess you have something like console= in the kernel arguments, otherwise you would not see anything in that serial console... | 11:05 |
| jMCg | smb: yeah. | 11:06 |
| jMCg | http://sprunge.us/VFch | 11:06 |
| jMCg | nomodeset, cute. | 11:06 |
| jMCg | Well, it was late and I was desperate. | 11:07 |
| apw | jMCg, ok the fixes that went in on the bug you mention fixed the issue triggering that bug, therefore you must have a different if similar issue, so it'd be good to have your own bug, as noone is going to look at that closed one | 11:07 |
| jMCg | I didn't realize it was closed. | 11:08 |
| apw | yeah i had a system i could actually reproduce that specific issue and we found root cause and fixed that one | 11:08 |
| apw | i believe at least | 11:09 |
| jMCg | apw: okay. So, what do I call this bug, and how do I provide more info? | 11:09 |
| * apw is thinking | 11:10 | |
| apw | i would title it something like 'boot hanging at "<whatever the last line of console output>" to start with | 11:10 |
| apw | and i would like to see the whole log at least on that bug | 11:10 |
| smb | Question would be to find out where it is hanging/waiting. So like apw said and having the dmesg from the serial console | 11:11 |
| jMCg | virsh start ; virsh console > log should be easy to give you that. | 11:11 |
| smb | probably add a debug to the kernel arguments | 11:11 |
| smb | I mean "debug" as an option | 11:12 |
| jMCg | s/nomodeset/debug/ | 11:12 |
| smb | and what was that other one for startup | 11:12 |
| smb | keep the nomodeset | 11:12 |
| apw | yep | 11:12 |
| apw | and add --debug as well | 11:13 |
| smb | at least prevents the kernel from trying fancy graphics where you don't really need | 11:13 |
| apw | which gets to upstart in case we are getting that far | 11:13 |
| jMCg | I don't have a graphics card configured :) | 11:13 |
| smb | Ah, ok. Probably won't make a difference but neither does hurt then | 11:14 |
| apw | jMCg, yeah i _think_ we are making it into the main root | 11:14 |
| smb | apw, initcall_debug? | 11:14 |
| apw | will make his buffer be very big, so initially i think i'd leave that one off | 11:14 |
| jMCg | Well, there's some ugly formatting. | 11:15 |
| apw | so i think its getting to real root, as we have run and completed 'init-bottom' which kills udev off | 11:16 |
| apw | and then we have udevd starting some time later, over 1s, which i believe should be only occuring in real root | 11:16 |
| apw | so you definatly have a different error, as the error on that bug, we get stuck in init-bottom | 11:16 |
| jMCg | Heisenbug! | 11:17 |
| jMCg | Sweet. When I add debug --debug, it doesn't get post-start. | 11:17 |
| apw | 'post-start' ? | 11:17 |
| jMCg | http://sprunge.us/igSh | 11:17 |
| apw | bah i hate serial ports which lose charactes | 11:18 |
| apw | [ 3.8 console-setup main process (347) 3.893235] init: console-state changed from spawnost-start | 11:18 |
| jMCg | The best part is that this is an emulated serial port ;) | 11:18 |
| apw | ok so that mess has enough in it to tell us we got as far as upstart | 11:18 |
| jMCg | I'm gonna send it a shutdown command and see what that does. | 11:21 |
| jMCg | http://sprunge.us/SIQC not much. | 11:22 |
| apw | so it responded, and shutdown as far as i can see | 11:23 |
| apw | it ran rc scripting at least to try and kill stuff | 11:23 |
| jMCg | So from what I gather, we're past mounting / in the right place. | 11:26 |
| apw | long past that yes | 11:26 |
| apw | as soon as all the init: stuff comes out in the --debug mode, we are running that in the real root | 11:27 |
| apw | [ 1.7 linear personality registered for level [ 1.74271path personality registered for leve[ 1.827 (vda): mounted filesystem with ordea mode. Opts: (null) | 11:27 |
| apw | Loading onfiguration from /etc/init.conf | 11:27 |
| apw | that is the disk coming online and us flipping over | 11:27 |
| jMCg | So, what's the next point to get stuck? | 11:28 |
| apw | jMCg, heh there are no sensible points to get stuck | 11:29 |
| jMCg | I'd argue that getting stuck at all in a boot isn't very sensible, but then I've passed the point of sensibility a long time ago. | 11:29 |
| smb | jMCg, Just to be sure this is not something there. If you can extract the /etc/fstab from the lv you use as root | 11:30 |
| apw | jMCg, well what i am saying is there are no know points to get stuck | 11:30 |
| jMCg | The job of an OS is to manage resources. If I spend 4 days trying to get it to boot, that's a terrible waste of my resources :-/ | 11:30 |
| apw | jMCg, yep and we're trying to help | 11:31 |
| apw | you asked where is the place i expect a hang, i told nowhere | 11:31 |
| jMCg | apw: thanks | 11:31 |
| jMCg | So, /etc/fstab from the kvm? | 11:31 |
| apw | jMCg, ok so advice is to boot with --verbose instead of --debug and add --no-log in case | 11:31 |
| apw | that might get us less output so we can read it | 11:31 |
| jMCg | http://sprunge.us/fNUY | 11:32 |
| jMCg | New command line for the kernel: | 11:33 |
| jMCg | <cmdline>root=/dev/vda ro serial=tty0 console=ttyS0,38400 nomodeset debug --verbose --no-log</cmdline> | 11:33 |
| jMCg | sweet! That looks readable! | 11:34 |
| apw | yeah that looks fine | 11:34 |
| apw | thats something at least | 11:34 |
| jMCg | http://sprunge.us/BiSi | 11:34 |
| smb | Hm | 11:37 |
| smb | jMCg, Have you sshd running | 11:37 |
| smb | Or other thing, is there a /etc/init/ttyS0.conf to actually bring up a login session on the serial console? | 11:37 |
| jMCg | smb: last time I checjked, there was one. But I'll check again. | 11:40 |
| * ppisati -> out for lunch | 11:41 | |
| smb | jMCg, No, I guess then it is still there | 11:41 |
| smb | Just going through my memory of things that had been failing and looking similar | 11:42 |
| jMCg | gah. | 11:42 |
| smb | The virtual fs stage seems to be waiting | 11:42 |
| apw | jMCg, ok ... can you try creating /etc/init/procps.override in the image containing the word 'manual' | 11:43 |
| apw | and try booting it again | 11:43 |
| jMCg | apw: first, I'll re-dd ttyS0.conf | 11:43 |
| jMCg | Which magickally got lost since last week. | 11:43 |
| jMCg | So, right now, I feel like punching myself in the face. | 12:01 |
| jMCg | apw: thank you. | 12:01 |
| apw | so was that a missing ttyS0 config ? | 12:02 |
| apw | jMCg, ^ | 12:02 |
| jMCg | So, between the real issue, which hung up the domains, and my ghost issue, I (accidentally) axed ttyS0.conf and have been wondering why it doesn't boot ever since. | 12:02 |
| apw | smb, you win a cookie | 12:02 |
| * smb munches | 12:02 | |
| jMCg | The real issue was fixed with the udev/and or kernel upgrade (in the Host), this here should be fixed by head-desking ;) | 12:03 |
| jMCg | freaky. This thing actually works. O_o | 12:03 |
| jMCg | I appear to have done a pretty decent job creating my vm image. Except for that ttyS0.conf thing :D | 12:04 |
| apw | heh we hope most of the time | 12:04 |
| smb | Unfortunately no login tty and hanging rather look similar from a console. ;) | 12:04 |
| jMCg | RFE: put a ttyS0.conf in by default | 12:05 |
| apw | thats kinda image specific, as i don't have a S0 most of the time | 12:05 |
| jMCg | Neither do I, except with KVMs and servers. | 12:06 |
| apw | sadly even in virtual ones it differes depending if its kvm or xen | 12:06 |
| jMCg | :-/ | 12:06 |
| smb | Yeah, at least differently named | 12:06 |
| jMCg | There needs to be a unified way of managing servers (real or virtual ones) if there's no ethernet connection, or the OS is otherwise not up and running. | 12:07 |
| jMCg | Oh, and it should be cheap and secure. | 12:07 |
| apw | a nice utopia indeed | 12:08 |
| jMCg | Yeah. | 12:09 |
| smb | At least that way makes people earn their money by knowing where to hit with the hammer... ;) | 12:09 |
| * henrix will be back in ~20m | 12:35 | |
| herton | ppisati, do you know someone who can verify bug 927526 against latest ti-omap4 proposed? | 13:01 |
| ubot2` | Launchpad bug 927526 in linux-ti-omap4 "missing support for some LIRC devices" [Undecided,Fix committed] https://launchpad.net/bugs/927526 | 13:01 |
| ppisati | herton: community only i guess | 13:37 |
| ppisati | herton: personally i don't have any IR receiver/transmitter (maybe my tv remote?!?!?! :) ) | 13:37 |
| herton | ppisati, ok, will try pinging reporter on that bug | 13:38 |
| === bladernr_afk is now known as bladernr_ | ||
| ppisati | the sticking edge on the other screen is just annoying | 14:17 |
| === yofel_ is now known as yofel | ||
| apw | ppisati, on the other screen ? | 14:46 |
| * ogasawara back in 20 | 14:48 | |
| ppisati | apw: yes, in a dual screen setup, on the left i've email + terminal (stacked) and on the right i've chrome | 14:54 |
| ppisati | apw: and when i move to the right one, i find it to be a *royal* pain to go back to the left one | 14:55 |
| ppisati | apw: since i've to rush the mouse pointer else it gets stuck over there | 14:55 |
| ppisati | it's just innatural | 14:55 |
| apw | ppisati, yep i hate it too, the gluey ness is configurable, in ccsm | 14:57 |
| smb | ppisati, Maybe you need to think of it as like you have to break through the monitors edges to get to the other screen... :) | 14:57 |
| ppisati | apw: i just tried U3d, i'll probably go back to 2d: less resources, and it doesn't have this feature :) | 14:57 |
| ppisati | smb: or probably i should stop going over there altogether | 14:58 |
| apw | heh, well its good someone tests 2d, as it is supported | 14:58 |
| manjo | herton, https://bugs.launchpad.net/linux/+bug/925552 verification done | 15:23 |
| ubot2` | Launchpad bug 925552 in linux "[12.04] Broadcom Bluetooth device (Vendor=0a5c ProdID=21f3) not supported" [High,In progress] | 15:23 |
| herton | manjo, yep, everything is ok now. I released oneiric for testing this morning | 15:24 |
| manjo | oh cool thanks a ton | 15:24 |
| * cking grabs a coffee | 15:56 | |
| * henrix follows cking | 15:57 | |
| pgraner | cking, ping | 16:01 |
| cking | pgraner, pong | 16:01 |
| pgraner | cking, hey on your sandybridge laptop are you seeing high fan useage recently? | 16:02 |
| cking | pgraner, nope, it's running relatively quietly | 16:02 |
| pgraner | cking, powertop is estimating its using 9.4w to run it | 16:02 |
| pgraner | cking, that seems like a lot of juice | 16:03 |
| cking | I am running with UEFI as the default | 16:03 |
| cking | pgraner, ah, well, powertop results may be a bit iffy if you run them for too short a period. use my powerstat tool instead and see what it reports | 16:03 |
| pgraner | cking, ok, powertop has been running for over an hour (box is on battery) | 16:04 |
| cking | let me look up my latest power usage stats | 16:04 |
| cking | I was getting ~8.8W on a default clean install with the latest Precise kernel on Saturday | 16:05 |
| cking | w/o RC6 it was consuming ~17W | 16:06 |
| cking | pgraner, you could try: https://wiki.ubuntu.com/Kernel/PowerManagement/IdentifyingIssues | 16:07 |
| cking | (best to try power-usage-report, about 1/2 down the wiki page) | 16:08 |
| cking | the X220i that I've got is an i3-2350M with BT disabled too | 16:10 |
| amitk | cking: some scary (as in wrecking the scheduler -scary) bed-time reading for you in case you haven't seen this yet: http://lwn.net/Articles/482344/ , https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/HMPscheduling | 16:11 |
| cking | amitk, eek, more data ;-) | 16:12 |
| amitk | cking: lots more data :) , but if you have an input, I'd love to hear it | 16:13 |
| cking | amitk, no "fix the broken apps" items on the action points then? | 16:13 |
| amitk | cking: -EMAKEPROGRESS | 16:14 |
| cking | amitk, how about "why do so many apps do such low poll() timeouts and causes dozens of unnecessary wakeups? ;-)" | 16:14 |
| pgraner | cking, ok powerstat show avg power use at 10.3w | 16:15 |
| pgraner | cking, powertop lies, lies, lies | 16:15 |
| cking | pgraner, well, powerstat applies some sneaky sliding window averages, so we are comparing apples vs pears so to speak | 16:16 |
| amitk | cking: that was solved by powertop, but I've been thinking about a new cgroup type to catch these sorts of apps in automated testing - multi-stage cgroup that only delivers a certain percentage of wakeups to the apps at each level. At L1 you get 100% of your wakeups, if you wake up too many times, you get demoted to L2 where you only get 75% of your wakeups, so on and so forth... | 16:17 |
| * amitk waves to pgraner | 16:18 | |
| cking | amitk I was thinking more like the OOM style killer for badly behaving apps that do poll() with a zero timeout ;-) | 16:18 |
| * pgraner waves back at amitk | 16:19 | |
| cking | amitk, sometimes wakeups are legitimate, eg. perhaps audio/video requires it on AV sync. however, sometimes it is just badly written apps | 16:20 |
| amitk | cking: which is why OOM would be a big hammer. I'd like to run then entire application stack in this new cgroup type and see how many end up in L2, L3, go correlate with what the ongoing activity was, and if necessary go fix them. | 16:22 |
| amitk | s/run then/run the/ | 16:22 |
| cking | amitk, yep, I was being joking about OOM ;-) | 16:22 |
| amitk | cking: heh :) | 16:22 |
| Amoz | hi cking :) about the RC6 testing, intel_reg_dumper doesn't return any rc6 register, is this normal? | 16:24 |
| Amoz | looks like it's the same for all of us.. | 16:24 |
| cking | Amoz, yep, it is consistently "none" | 16:25 |
| Amoz | and that's why you check it, I suppose... | 16:25 |
| Amoz | cking, have you checked the results recently? if so, do you think rc6 will be enabled for precise? | 16:26 |
| cking | Amoz, it is our intention to | 16:27 |
| cking | ogasawara, I see you added to the RC6 power testing the request for intel_reg_dumper data - everyone is getting "None" for that | 16:28 |
| Amoz | cking, could other i915 kernelparams interfere with the results? | 16:30 |
| Amoz | I ran my test with fbc=1, lvds_downclock=1 | 16:30 |
| cking | Amoz, potentially, so best to test w/o the other i915 options so we can compare like for like in this table. | 16:30 |
| Amoz | cking, I'll rerun my test then | 16:31 |
| Amoz | without other params | 16:31 |
| cking | but it is also valid to test with fbc=1 etc as these may save a little bit more power, but we are not going to use these by default for precise because of the associated risk that they may cause other bugs | 16:31 |
| * tgardner reboots to test AA patches | 16:35 | |
| cking | Amoz, thanks for testing! | 16:37 |
| ogasawara | cking: hrm, lemme double check. I'd gotten that from eugeni. | 16:38 |
| Amoz | cking, no thank you for making my computer perform better! | 16:38 |
| * cking likes to point out this one wasn't his work at all ;-) | 16:41 | |
| cking | amitk, that's a lot of info to digest, I may get back to you later on those links | 16:42 |
| ogasawara | cking: RC6 state output via intel_reg_dumper is only available in intel-gpu-tools v1.2, and it looks like we've only got v1.1 in Precise. I think I'll just remove it from the wiki for now and let eugeni know. | 16:58 |
| cking | ogasawara, ah, that explains it, I couldn't see what I was doing wrong on Saturday when I ran this and got no output. | 16:58 |
| amitk | cking: sure thing, it was meant for you bed time light reading anyway ;) | 17:00 |
| cking | amitk, the synthetic simulation of smart phone apps is going to be hard to do - that requires a lot of data gathering and some deep analysis to understand different use-cases correctly. | 17:05 |
| amitk | cking: we want to start with simple models first which I suspec will be similar to a desktop usecase model (except for the input sources) e.g. web browsing, mp3 playback, video playback, etc. | 17:07 |
| cking | amitk, yep, chose some misbehaving apps to ;-) | 17:08 |
| Amoz | cking, updated, almost the same results | 17:27 |
| cking | Amoz, thanks, that was to be expected, we just wanted to see if it fixed any existing issues or threw up any new ones - thanks for testing - it is good to see that your data does not vary much at all between test - that's a good sign! | 17:29 |
| Amoz | cking, yeah I know. especially the low std deviation is good I assume :) | 17:32 |
| cking | yes, that makes me very confident ;-) | 17:33 |
| Amoz | cking, is there anything else one can do to exercise the rc6 code? | 17:36 |
| Amoz | and while I'm at it, how can one start contributing to the kernel team? | 17:38 |
| cking | Amoz, do you normal work on the desktop, watch videos, etc and see if you can spot any issues. | 17:38 |
| cking | (for rc6) | 17:38 |
| cking | Amoz, there is always a load of bug triaging and stuff - perhaps talk to jsalisbury about this | 17:40 |
| jsalisbury | Amoz, We can *always* use help triaging :-) | 17:41 |
| Amoz | I guess everyone need to start out with the triaging stuff before doing development :) | 17:41 |
| Amoz | jsalisbury, I figured | 17:41 |
| jsalisbury | Amoz, there are some good documents available at: | 17:42 |
| jsalisbury | Amoz, https://wiki.ubuntu.com/Kernel/BugTriage | 17:42 |
| Amoz | I've read some | 17:42 |
| Amoz | still doesn't make me a good triager | 17:42 |
| Amoz | :( | 17:43 |
| Amoz | but I suppose one need to know everything there | 17:43 |
| jsalisbury | Amoz, Not everything. Basically just start of with one bug at a time | 17:43 |
| jsalisbury | Amoz, Testing is also another area that is of great help. Especially if you can reproduce a bug easily. | 17:44 |
| Amoz | jsalisbury, I guess stacktrace dumps are very helpful for crashes etc? | 17:46 |
| jsalisbury | Amoz, sure, when we can get them. | 17:46 |
| Amoz | jsalisbury, so what bugs should be triaged? undecided - new, unknowns - new ? | 17:49 |
| Amoz | jsalisbury, if something's in the wiki, just direct me there | 17:49 |
| jsalisbury | Amoz, we have a bug bot that checks for all required information and then changes to "Confirmed". Those are the bugs that need to be triaged. | 17:51 |
| jsalisbury | Amoz, this is a good link for the various bug states: | 17:52 |
| jsalisbury | Amoz, https://wiki.ubuntu.com/Kernel/BugTriage/BugStates | 17:52 |
| jsalisbury | Amoz, the #ubuntu-bugs channel on Freenode is a good place to go to. There is also some good info at: | 17:54 |
| jsalisbury | https://wiki.ubuntu.com/BugSquad/KnowledgeBase | 17:54 |
| jsalisbury | Amoz, The previous wiki link I mentioned has lots of info, but is focused on all Ubuntu packages, not just linux package. | 17:56 |
| Amoz | jsalisbury, thanks, already aware of them | 17:56 |
| jsalisbury | Amoz, cool | 17:56 |
| ogasawara | jsalisbury: was just reading your status... bug 914161, have you had them test a more recent Precise kernel? We disabled CONFIG_INTEL_IOMMU_DEFAULT_ON a while ago due to issues it was causing. | 17:57 |
| ubot2` | Launchpad bug 914161 in linux "Linux 3.2 freezes system on FUJITSU ESPRIMO P7935" [Medium,Confirmed] https://launchpad.net/bugs/914161 | 17:57 |
| jsalisbury | ogasawara, I will confirm he is running 3.2.0-17.27 | 17:59 |
| ogasawara | jsalisbury: ah nm. just saw their recent comment. | 17:59 |
| ogasawara | jsalisbury: based on their comment, you can close it Fix Released. | 17:59 |
| jsalisbury | ogasawara, I'll still confirm what he means by "Latest" kernel | 17:59 |
| ogasawara | jsalisbury: he gave uname -a output in comment #68, shows 3.2.0-17 | 17:59 |
| jsalisbury | ogasawara, ahh, cool. | 18:00 |
| ogasawara | jsalisbury: we intend to keep iommu disabled by default | 18:00 |
| jsalisbury | ogasawara, great, I'll mark as fix released and update the bug. | 18:00 |
| Amoz | are there any sources for the bot scripts you're using? | 18:02 |
| jsalisbury | ogasawara, thanks | 18:02 |
| jsalisbury | Amoz, The following wiki describes them: | 18:04 |
| jsalisbury | https://wiki.ubuntu.com/Kernel/kteam-tools | 18:04 |
| bryceh | Amoz, https://code.launchpad.net/bugbot | 18:04 |
| Amoz | jsalisbury, bryceh, thanks | 18:05 |
| === kentb-out is now known as kentb | ||
| === jjohansen is now known as creckets | ||
| === creckets is now known as crickets | ||
| === crickets is now known as jjohansen | ||
| htorque | jsalisbury: hi! bug 808384 - i'm not seeing it with the current mainline kernel - do you think it's worth it testing again with a vanilla kernel 3.2 with ubuntu's config? | 18:46 |
| ubot2` | Launchpad bug 808384 in linux "[drm:drm_mode_getfb] *ERROR* invalid framebuffer id (FujitsuSiemens Amilo Pi 2530 Hotkeys)" [Medium,Triaged] https://launchpad.net/bugs/808384 | 18:46 |
| === tgardner is now known as tgardner-lunch | ||
| jsalisbury | htorque, Or possibly the latest precise kernel. I'll post a link in the bug. | 18:58 |
| jsalisbury | htorque, ahh, wait, you already tested 3.2.0-17-generic, correct? | 18:58 |
| htorque | yes | 18:58 |
| htorque | jsalisbury: i'm building the 3.2.7 vanilla with 3.2.0-17-generic's config now | 18:59 |
| jsalisbury | htorque, ok, can you post your results to the bug. | 19:00 |
| htorque | sure, will do | 19:00 |
| apw | htorque, the mainline kernels are built ubuntu's configs ? | 19:18 |
| htorque | apw: oops, i bookmarked http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/ - never knew there are older kernels available too !:-) | 19:22 |
| htorque | thanks, that should save some time ;-) | 19:22 |
| * cking -> EOD | 19:23 | |
| * apw gets something to work as intended instead of exploding ... sounds like time to quit to me | 19:25 | |
| jjohansen | apw: nice, run don't walk don't walk, if you look back it might break | 19:32 |
| htorque | jsalisbury: also got the warning/error message with the 3.2.7 mainline kernel, so it sounds like this has been fixed upstream, right? | 19:54 |
| jsalisbury | htorque, sounds like it. Are you able to test the latest v3.3-rc5 kernel? It is available from: | 20:02 |
| jsalisbury | http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.3-rc5-precise/ | 20:02 |
| htorque | jsalisbury: can test it, though it's older than the daily one i tested | 20:04 |
| jsalisbury | htorque, if the bug exists there, we will want to open a bug upstream. | 20:05 |
| htorque | ok, on it | 20:06 |
| === tgardner-lunch is now known as tgardner | ||
| jsalisbury | htorque, great, thanks. | 20:06 |
| htorque | jsalisbury: doesn't seem to be in 3.3-rc5 either :-) | 20:11 |
| jsalisbury | htorque, but it does happen in 3.2.7 mainline? That would indicate a bug in 3.2 stable. | 20:12 |
| jsalisbury | htorque, that was fixed in 3.3 | 20:12 |
| htorque | right, it's there in 3.2.7, it's gone in 3.3-rc5 | 20:13 |
| jsalisbury | htorque, thanks for testing. I'll do some upstream searches and see if the fix in 3.3 has been queued up for 3.2 stable. | 20:16 |
| htorque | jsalisbury: np! verified the results on a second system and also the new 3.2.8 seems affected. | 20:28 |
| jsalisbury | htorque, great, thanks. | 20:29 |
| jsalisbury | htorque, I posted some additional comments to the bug report. | 21:19 |
| htorque | jsalisbury: the ftrace commit is also in 3.2.8 | 21:20 |
| htorque | so that's not it | 21:20 |
| htorque | it seems fixed with 3.3-rc1 but that's a lot of commits... | 21:21 |
| jsalisbury | htorque, do you see any additional messages in syslog when you reproduce the error? | 21:21 |
| htorque | no, it's just "[drm:drm_mode_getfb] *ERROR* invalid framebuffer id" | 21:21 |
| jsalisbury | htorque, ok, I'll do some more investigation | 21:22 |
| jsalisbury | htorque, is anything written to your /var/log/Xorg.0.log log file? | 21:39 |
| htorque | jsalisbury: yes! http://paste.ubuntu.com/859764/ | 21:41 |
| jsalisbury | htorque, thanks, that give some more to search on. | 21:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!