[08:05] cooloney: ping? [08:13] jk-: hi [08:16] cooloney: could I get you to test my clk code on omap? [08:16] cooloney: sorry, s/clk/debug macro/ [08:19] cooloney: the 'debug' branch here: http://kernel.ubuntu.com/git?p=jk/dt/linux-2.6.git;a=shortlog;h=refs/heads/debug [08:21] jk-: no problem, just a moment [08:43] jk-: it's quite slow for me to git fetch, pls wait for a while [08:44] * cooloney will upgrade his network to 4MB [08:45] cooloney: no problem, thanks :) [08:46] cooloney: 4Mbps? Will that really change anything? I thought the problem was due to limited bandwidth between China and US... [08:47] amitk: yeah, that won't change the problem here. [08:47] amitk: but it's double my speed soon [08:47] and the upgrade is free [08:47] cooloney: heh :) free is good [08:50] cooloney: Morning [08:50] Hey jk- amitk [08:50] hey lag [08:51] cooloney: ... [08:53] cooloney: You're not getting away from me that easily [08:56] lag: how is it going? [08:56] amitk: Chugging along, and you? [08:59] lag: I see light at the end of the tunnel (and it is moving away from me) [09:00] amitk: Ouch! :) [09:00] amitk: My situation will improve when I catch hold of that slippery cooloney ;) [09:00] heh [09:02] lag: morning man [09:04] cooloney: There you are :) [09:04] cooloney: What's going on with L24.9? [09:04] cooloney: I haven't heard anything; no emails, messages or calls [09:09] lag: yeah, sebjan is back [09:09] lag: and he is working on that, [09:09] lag: i'm also waiting for that [09:11] cooloney: No worries - I'll continue to wait ... [09:13] lag: np, man [09:39] jk-: good news, it boots fine [09:40] cooloney_: woot! thank you for testing [09:41] jk-: oh, wait, CONFIG_DEBUG_LL=y is right? [09:41] jk-: i am using the omep3_defconfig [09:41] cooloney_: yeah, CONFIG_DEBUG_LL=y and CONFIG_EARLY_PRINTK=y [09:42] (and maybe with 'earlyprintk' on the cmdline) [09:42] (to give it a thorough test :) ) [09:44] ok, np, 1 sec [09:46] it *should* be the same as the !CONFIG_DEBUG_LL case, but I'd like to make sure [09:47] jk-: yeah, it works fine too [09:47] cooloney_: awesome, thanks [09:50] jk-: one question, [09:51] cooloney_: yup? [09:51] jk-: if i wanna debug in a arch/arm/kernel/head.S, just wanna print out some register value, [09:51] beside printhex helpers [09:52] any other choice [09:53] cooloney_: yeah, i'd suggest printhex and printascii - are these not suitable for your usage? [09:54] jk-: i'm afraid that will corrupt some registers [09:55] jk-: http://pastebin.ubuntu.com/482255/, booting message of your kernel [09:55] cooloney_: yeah, corrupts r0-r3. [09:56] cooloney_: looks good === amitk is now known as amitk-afk === yofel_ is now known as yofel [11:22] hi [11:23] Has anyone been working with Sony Fn buttons? I vaguely remember someone working on them recently [11:23] jk-: Was it you? [11:23] lag: not me :/ [11:24] I remember someone saying something like "I have them fixed, and I didn't even have the hardware" [11:24] jk-: Okay :( [11:24] http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html mentions (for example) an ubuntu kernel version 2.6.34-5.14 for lucid. how would i install that kernel for testing? [11:24] sounds like something Colin would say :) [11:25] moldy: Wait one, I'll get you the URL [11:27] moldy: You can either look them up here: https://edge.launchpad.net/ubuntu/+source/linux [11:27] moldy: If they're not there you can use your git tree to build your own *.deb [11:27] lag: thanks, i will have a look [11:28] moldy: Our git tree: http://kernel.ubuntu.com/git [11:29] moldy: The Lucid repo: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=summary [11:30] moldy: tag 2.6.34-5.14: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=tag;h=b2c6db6e3155efd7f3af1d871c7a279f4f116d37 [11:34] could i just install a kernel .deb from maverick on lucid? [11:35] Sure === amitk-afk is now known as amitk [11:35] lag: would that also install all the modules, or would i have to install them separately? [11:36] moldy: If you install the .deb, the modules will be installs with the kernel [11:36] installed* [11:36] ok, thanks [11:36] moldy: No problem [13:45] Hey JFo [13:46] hey lag [13:47] JFo: How do you search just for kernel bugs on Launchpad? [13:47] with much despair [13:47] :( [13:49] lag, It should be possible to limit them to package linux I guess/hope [13:49] smb: You mean like this - https://bugs.edge.launchpad.net/ubuntu/+source/linux [13:50] yeah that looks ok [13:51] But then you get really random ones like bug 43531 [13:51] Launchpad bug 43531 in linux (Ubuntu) "Kernel isn't very useful without a boot loader, but doesn't depend on one (affects: 1) (heat: 5)" [Medium,In progress] https://launchpad.net/bugs/43531 [13:51] How is that a kernel bug? [13:52] Would be a bug in the packaging [13:52] And one we probably should look at [13:53] lag, sorry, got distracted by something shiny [13:53] smb: It's 4 years old :) [13:53] * lag is not surprised :) [13:53] Heh, yeah. [13:53] Is Ben Collins still with us? [13:53] At least we then should check whether this is really valid [13:53] Nod [13:53] No [13:54] The last person to complain about it did so 3 years ago [13:54] Sounds like a real good candidate for getting rid of. [13:55] Though we probably need to check whether you could clean up away your boot loader [13:56] lag, You could do that in your copious spare time. :) [13:57] * ogra wouldnt blindly close it regarding the initial reporter :) [13:57] there should be plenty of duplicates of that one btw [13:58] we had a time where we had one for each arm flavour to at least recommend a bootloader iirc [13:59] I'll assign myself to it and try to put it to bed [13:59] smb: Hmm ... [14:00] lag, Actually there is a "Recommends: BOOTLOADER" in flavour.control.stub [14:00] So this rather looks fixed by now [14:00] smb: hey. I saw your email response re xen/hardy. have you gotten any upstream feedback? [14:00] smb: I have to confess, I don't know a great deal about packaging, but I guess there's always time to learn [14:00] smb, I've added to the needs-review list so we can verify before responding and closing [14:01] What's the best way to review this? [14:01] jdstrand, I updated the bug report. There is/was an upstream discussion about this. For Hardy and earlier the code is so different that we ended up doing what the upstream code intended but was wrong [14:01] Teach me sensai [14:01] smb, am I correct in my assumption that the gobi-loader package is not yet in Lucid? [14:02] pgraner, should be universe [14:02] pgraner, It won't ever be. In Lucid all is included in lbm [14:02] tgardner, pgraner Only Maverick has the universe package [14:02] smb, ok, then is the lbm package there yet? I'm assuming it will be -wwan? [14:02] smb: ack. don't let me keep you. ping me when you are ready and I can get it uploaded and building [14:02] Uploaded but I think not accepted yet [14:03] smb, ack [14:03] jdstrand, Test kernel compiling right now [14:04] pgraner, And yes, will be lbm-wwan [14:04] JFo: Should bug 525801 still be on the Top50? [14:04] Launchpad bug 525801 in linux (Ubuntu) (and 1 other project) "[i915] NULL pointer dereference in intel_tv_detect() (affects: 18) (dups: 9) (heat: 90)" [High,Invalid] https://launchpad.net/bugs/525801 [14:04] JFo: bug 527361 - same [14:04] Launchpad bug 527361 in linux (Ubuntu Lucid) (and 2 other projects) "hotplug interferes with ethernet card (affects: 1) (heat: 23)" [Medium,Incomplete] https://launchpad.net/bugs/527361 [14:05] * JFo looks [14:05] JFo: bug 553498 - same [14:05] Launchpad bug 553498 in linux (Ubuntu Maverick) (and 2 other projects) "Dell Studio 155x hang on resume from suspend (SCI_EN) (affects: 15) (heat: 85)" [High,Fix released] https://launchpad.net/bugs/553498 [14:05] I think the Top50 is out of date [14:05] first one you gave me is marked invalid [14:05] Exactly [14:05] smb, thx [14:06] Second is fixed released [14:07] oh, you are saying the list is out of date [14:07] of course it is [14:07] As is the third [14:07] I was in meetings all last week [14:07] Ohhhhhhh [14:07] np [14:07] and we had no meeting [14:07] Was getting confused [14:07] I see [14:07] I'm guessing the Top50 is static [14:07] there is a bug meeting today [14:07] it is [14:07] kk [14:08] jdstrand, To be clear here. This is not any upstream solution as anything upstream did might be really hard to get backported and it just went into 2.6.36-rc2. We might in the long term want to fix the other issues in there. But they are different. [14:08] You'd best get on your Python course ;) [14:08] tgardner, you been seeing issues with the latest maverick kernel? I'm getting real bad jitter on music playing doing normal day to day tasks, I mainly see it on window opens [14:09] jdstrand, I hope the explanation in the bug is understandable. But basically I would like to get the test kernels tested on xen (I can do normal bootup) to make sure this is really the fix. [14:09] pgraner, I haven't been using Maverick on a laptop whilst playing music. I've mostly been testing the Lucid ext4 stuff for stability [14:09] smb: ok [14:09] pgraner, I don't see it on my desktop [14:09] smb: I have started reading https://help.ubuntu.com/community/Xen myself [14:09] will fire up my Mav lappy to test [14:10] smb: I wonder if lamont has a spare builder he could try it out on [14:10] tgardner, I can get it to do it every time, its on this i5 box [14:10] * pgraner wonders [14:11] jdstrand, There is a link to kernel trap in the bug now for some of the discussion. It has been kicked off abit earlier by someone doing xen. Though it did not sound fatal at the beginning. [14:11] jdstrand, lamont maybe can. But it sounds a bit more complicated. Have been chatting with him [14:12] tgardner, this box is still having huge issues with memory, it has 2 gigs and it has a half gig in swap [14:13] pgraner, wouldn't swapping account for the jitter? I have to wonder _why_ its swapping. are you running some huge mem hog, or you still have a leak somewhere? [14:14] tgardner, I have Evolution, Xchat, Chromium and Rhythmbox open, nothing big other than Chromium [14:14] pgraner, ok, does it jitter right after a reboot, or does it take awhile? [14:15] tgardner, takes awhile a few hours [14:15] tgardner, I just killed chromium and it stopped and it freed a ton of memory [14:15] pgraner, then that sounds like a leak (no pun intended) [14:16] tgardner, swap went down to 229meg from 500 [14:16] pgraner, did it completely clear your swap? [14:16] tgardner, nope [14:16] pgraner, how about after 'sudo sync' [14:17] you really shouldn't have much in swap if all your progs are active. [14:17] tgardner, with 2 gigs your right, it only dropped it a hundred kb [14:18] pgraner, what does slabtop show? anything exceptional? [14:19] tgardner, 135936 135919 99% 0.03K 1062 128 4248K kmalloc-32 [14:19] thats the top entry [14:20] pgraner, just reading the man page to see how its sorted [14:20] pgraner, 'c' sorts by cache size [14:20] 31956 14366 44% 0.96K 1998 16 31968K ext4_inode_cache [14:20] top entry after "c" sort [14:21] pgraner, thats consistent with tangerine which is running a lucid kernel [14:21] did your music stop stuttering after killing chromium? [14:21] tgardner, yep [14:23] pgraner, the evidence kind of points there, though I _still_ don't think you should be swapping [14:24] tgardner, me either, it was doing this in Prague and the ureadahead fix made it better, but seems to not have fixed it [14:25] smb: yeah, I can test for you [14:25] pgraner, all ureadahead did was free some mem which just pushed back the time when swapping started [14:25] tgardner, my netbook has 2gig and it never swaps (cuz I didn't crate a swap partition on the SSD) [14:25] pgraner, same with mine, i.e., no swap [14:26] tgardner, understand, but its similiar symptoms, due to that the ureadahead I never noticed this [14:26] lemme wrap up a few things and I'll go play with my SSD based machine on Maverik [14:26] lamont, Currently uploading the 64bit versions to people.c.c which have been at least booting on the generic version. So 64bit should be available in a couple of minutes [14:28] cool. say when/where and I'll go grab it for testing [14:30] pgraner: do you have some power save mechanism enabled for the disk? e.g. sata link controller [14:33] amitk, nope [14:33] amitk, stock out of the box [14:37] lamont, 64bit test kernels ready at http://people.canonical.com/~smb/lp620994/ , the 32bit versions will follow later (and if I may add a little whining here: it would all be quicker if I would be able to scp from tangerine to people directly :-P) [14:39] smb: yes, I'm very familiar with that challenge [14:52] ogasawara_, lemme know when you're done on tangerine so I can bounce for the -security kernel [14:54] smb: so... good news, bad news... domU boots [14:54] Error: /usr/lib64/xen/bin/xc_restore 23 7 1 2 0 0 0 failed [14:55] Hm, any kernel errors? [14:55] fyi, since lp deleted the last kernel, I made the previous hardy kernel available in ubuntu-security-proposed, with appropriate warnings etc in the bug [14:56] [ 381.653530] audit(1282571471.116:7): dev=vif7.0 prom=256 old_prom=0 auid=4294967295 [14:56] and some entries about learning, propagating, forwarding, disabled, disabled state for vif7.0 [14:56] jdstrand, Yep, saw that. [14:56] that is all dmesg has [14:56] and daemon.log looks pretty benign [14:57] http://paste.ubuntu.com/482411/ [14:57] lamont, Darn, not very helpful. Not being familiar with xen, so what should xc_restore do? [14:58] I'll admit to using xen, not to understanding it [14:58] basically, the guest has a golden image that is being restored. I additionally rebuilt said image from scratch, to the same result === bjf[afk] is now known as bjf [15:03] lamont, Somehow the paste looks like the errors are in bringing down several interfaces. But then it claims success anyway... Confusing [15:03] lamont, Is the end result a usable DomU or one without any networking? [15:04] I'm sshed into domU [15:04] so that feels like "networking" :-D [15:04] lamont, Also, even if that maybe should be obvious, were those errors probably there before? :) Ok, I'd be counting this as network, too [15:05] dunno [15:06] http://paste.ubuntu.com/482413/ <-- smb: the previous reset of the (then up) guest [15:08] Looks shorter but also has the error about brctl failing [15:09] lamont, jdstrand I wonder whether jj knows the xen output better to tell whether this is bad or ok... [15:10] maybe. zul might as well [15:10] zul: would you mind taking a look at ^ [15:10] It is at least not crashing anymore. But I want to be a bit more confidence before calling this a fix [15:12] smb: what I would like to do when you are ready is to build the kernel in the ubuntu-security ppa, copy it to hardy-proposed and get feedback in the bug from the reporters/subscribers [15:12] smb: once we have positive feedback, I can publish to -security [15:13] smb: for you, just use 'hardy-security' as the distribution name and I'll take care of the rest [15:13] jdstrand, The test kernels I am uploading to the people page are exactly that. Based of the last release and the patch added [15:13] I just did not finalize it [15:13] So the version number is smaller that the actual security release [15:13] smb: sounds great. I too would like some more feedback from zul and jj [15:14] smb: I'd be -1 with the current state [15:14] smb: but when you feel they are ready for wider testing, let me know [15:15] jdstrand, Exactly. As soon as we are confident about the fix. I would finalize the source package and all. But at the moment as lamont says there might be issues and this might not be the final resolution [15:15] right [15:15] smb: I was just trying to communicate my plan. specifically, not going straight to -security [15:16] jdstrand, Ah, maybe missed that. Ok with that [15:18] lamont, Another question for my understanding: is the same kernel used for the host and the guest or are they different? [15:18] same [15:19] Ok, thanks [15:19] smb: oh, I missed your comment regarding test kernels in the bug [15:19] smb: sorry for the confusion [15:20] jdstrand, np. we might have been adding comments around the same time [15:20] yes I think so [15:20] smb: anyway, people testing your kernels is just fine by me [15:22] yeah does not matter exactly from where they come. And coming from a people page might stress more on the "this is maybe not final" thing === achiang` is now known as achiang [15:26] how can i troubleshoot a network module (igb) having difficulty with bonding when booting? need to manually load 'bonding' module === ogasawara_ is now known as ogasawara [15:55] tgardner: go ahead and bounce tangerine [15:55] ogasawara, ack [15:56] Sarvatt: wecome aboard [15:57] s/wecome/welcome/ [16:00] thanks bjf! :) [16:05] yeah Sarvatt great to have you! :) [16:20] pgraner: ping [16:20] vanhoof, yo [16:20] pgraner: yooo [16:20] pgraner: can you add ~canonical-hwe-team to c-k-t in lp? [16:20] * pgraner looks [16:21] pgraner: getting Sarvatt setup, so adding our team to yours should get him access indirectly [16:21] otherwise if you want, just add sarvatt [16:22] sorry for the trouble, and thanks :) [16:23] Sarvatt, whats your lp id? [16:23] sarvatt [16:23] vanhoof, I'm going to add him as that how all the hew guys are done [16:23] Sarvatt: that's very tricky of you :-) [16:24] :) [16:24] pgraner: cool [16:24] Sarvatt, vanhoof: done [16:24] pgraner: thanks a ton! [16:24] Sarvatt, np [16:25] tgardner, tangerine bounced ok and I can use it again? [16:25] smb, yep [16:25] ok. ta [16:41] bjf, do you have a minute to help me test out my desktop mumble settings in the Ad-hoc room?? [16:59] JFo, I won't be able to join the bug review call as I am still busy with the xen regression [17:00] smb, no sweat [17:00] thanks for the heads-up [17:00] It more a head down. And sort of late... [17:01] heh [17:23] manjo: there's a work item you have for the kernel-maverick-config-review - "investigate memory stick options and produce proposal" [17:24] manjo: I actually have no recollection of what the reasoning behind that was for or the proposal that was going to be produced. [17:24] manjo: just curious if you still have that on your radar? or is it something we should just postpone and readdress for Natty? [17:26] lamont: you mentioned a 'pristine' image for your xen instance. how do you guys do snapshots with xen. I have xen setup here on some real hardware and am looking for anohter test case... [17:30] smb: I just rebooted into the .75 kernel after setting up on i386. my trace is very similar but slightly different than what is in the report [17:32] jdstrand, Without using xen? [17:33] smb: I setup hardy/xen on some real hardware with the -xen kernel. Got it all working with .73. Rebooted into .75 and have a similar but slightly different trace [17:35] jdstrand, Ok, sort of gives a test system and shows the issue. Can you pastbin the trace? [17:35] smb: actually, I attached it to the bug [17:35] smb: http://launchpadlibrarian.net/54226707/620994.log [17:36] smb: this machine is dedicated to testing this bug atm, so just let me know what you want me to test [17:37] jdstrand, Ah ok. Seems splitup can also be a single page which then gets avoided and ends in a zero range [17:38] jjohansen: re me testing> ^ [17:38] jdstrand, Basically there are two approaches. #1 don't avoid touching the guard page in mlock. Which could be used to use mlock to grow the stack [17:38] #2 implement even better testing that in my version 1 of patches [17:38] Which I am currently trying to implement [17:39] I have only the highest level understanding of the issue, as I came into this CVE late in the game. I'm happy with what you decide and am able to test [17:40] I think #2 is probably the way to go === ivoks_away is now known as ivoks [17:40] though /me is still trying to catchup on this one [17:41] I guess yes. (which will need some fixing in more recent kernels too). Seems in the older version I actually can make use of the fact that mlock there actually passes around the previous vma pointer. [17:41] But I need to be carefull [17:41] it would seem #2 is the better of the two, since it seems closest to upstream intent [17:42] For Jaunty to Lucid/Maverick we might take the upstream version (after a bit of cooking there) [17:54] ogasawara, I think we can move it for N [17:54] manjo: ack, will get it moved. thanks. [17:54] ogasawara, I don't think I will have the bandwidth to do any investigation this cycle [17:54] ogasawara, thanks [18:00] JFo: I've moved your kernel triage summit work items to have a maverick-beta milestone since a 10.10.10 milestone will be too late. [18:02] ? [18:02] not sure what you mean ogasawara [18:03] JFo: you had some work items for organizing the triage summit (in the kernel-maverick-bug-handling bp). I thought you'd set the date to be sept 11 for that? [18:04] jdstrand: lvm snapshotting. I'm a bit fuzzy on it, but can point at the scriptages [18:04] JFo: assuming that date is still correct, the work items for organizing I suspect would need to be done by maverick-beta (sept 2). [18:04] smb: any new news? [18:06] lamont, Not finite ones. I think I got something better, but probably would let jjohansen look over the patch and then start building it [18:06] ogasawara, oh heh yeah, sorry. my brain is moving way slow [18:06] cool [18:07] lamont: nah, thanks. it sounds like you are probably doing it outside of the xen-tools commands [18:08] jdstrand: I'm pretty sure our use predates those commands [18:19] hey all. is there an expected/target date for the next lucid SRU kernel ? [18:20] smoser, it's looking like the end of next month right now [18:20] for entry into -proposed ? [18:21] smoser, honestly, there is a proposed in right now and then a security upload and then the following will be the next regular upload [18:21] smoser, ack [18:22] can i see the changelog for the "proposed in right now" ? [18:22] smoser: is there one you are looking for? [18:23] smoser, commit that is [18:23] Hi all. [18:24] Is there any way I can tell the kernel "don't allow this process to access swap; when I run out of physical memory, fire a signal"? [18:24] bjf, bug 574910 is what i am hoping for [18:24] smoser, if you are asking about the patch jj posted on friday, that's not in proposed [18:24] Launchpad bug 574910 in linux-meta (Ubuntu) (and 4 other projects) "High load averages on Lucid while idling (affects: 25) (dups: 3) (heat: 174)" [Undecided,New] https://launchpad.net/bugs/574910 [18:24] :-( [18:24] yeah, i was hoping [18:25] smoser: it's going to be at least 3 weeks before that gets into proposed, and probably not that soon === sconklin is now known as sconklin-lunch [18:26] bjf, thanks for your time. [18:43] dpkg-gencontrol: error: package linux-image-2.6.35-18-omap not in control info [18:43] What does that mean? [18:44] often that you forgot to run clean [18:44] I thought control was built by fdr clean [18:44] The scripts run clean [18:45] Then it depends whether there is the right info in debian/control.d to include that arch/flavour in the control file [18:46] Okay, I'll look into it [18:46] lag Is this a new flavour? [18:46] Thanks [18:46] No [18:46] OMAP3 [18:46] I've built it 100's of times before [18:46] ;aglucid? [18:47] lag, lucid? [18:47] tgardner: Maverick [18:49] The build before it said something about a stamp [18:50] lag, its in the debian/control that I just generated. [18:50] I've fdr cleaned manually and rebuilding [18:50] Okay [18:51] I'll let you know if it's still an issue [19:21] * tgardner lunches [19:43] jjohansen, smb: fyi-- I only have i386 available for testing the xen issue [19:43] jjohansen, smb: so whenever you are ready, please also compile i386 [19:43] jdstrand: hrmm, okay I can install an amd64 [19:44] jdstrand: actually smb kicked off the compiles [19:44] I am compiling both. Though i386 is slower [19:44] * jjohansen notes it would sure help if x86 virtualization could be nested [19:45] jdstrand, Do you have access to tangerine? [19:46] smb: I don't believe he does but I can copy kernels out for him [19:46] smb: I do not [19:47] jjohansen, Ok, amd64 is done already, but i386 is still doing xen, so that takes a bit more. [19:47] Also note that this is a totally untested version [19:47] smb: yep :) === sconklin-lunch is now known as sconklin [20:12] jdstrand: it also didn't fit my use model. I see the guest exist, but when we save it and then try to restore, it falls flat [20:13] that is, when I rebuilt it (which does a wipe-n-build, save, restore), the guest was pingable for many of the steps, and then failed to restore in the end [20:17] jjohansen, jdstrand its probably not really useful, but the i386 build on tangerine finished now as well [20:18] smb: thanks, I'll copy it over for jd [20:21] it is quite useful to me, it is all I can test :) [20:22] jjohansen, When looking at the patches, the mistake might be trying to avoid find_vma in the checking function... [20:22] jdstrand, Only unusful insofar as lamont is not happy with the 64bit version [20:23] right, I was thinking that may be an issue [20:23] I hoped that it would be possible to avoid it as do_mlock uses find_vma_prev and passes in the prev pointer. [20:24] ah, I missed that :) [20:25] smb: right [20:26] jdstrand, I hope with the current patch it will be relatively simple to make a version with find_vma. That could even skip the new variable and do the checking below. Just be aware not to change anything around the splitting. openvz patches break if touching that. the custom-binaries are so much fun... :-P [20:26] s/jdstrand/jjohanson/ [20:27] * smb feels like he needs to go away from the keyboard when already mixing up names [20:28] slangasek: are you on archive admin duty today? If so, could I get the 2.6.35-18.24 kernels in the new queue processed? [20:29] hehe, smb go eod already :) [20:29] * smb hears and obeys [20:29] jjohansen, lamont, smb: rebooting with pre3 on i386 doesn't trace back, but gives: [20:30] Error: /usr/lib/xen/bin/xc_restore 4 1 1 2 0 0 0 failed [20:30] let me try with .73 to be sure [20:34] jdstrand: different numbers here, but same answer: Error: /usr/lib64/xen/bin/xc_restore 23 5 1 2 0 0 0 failed [20:38] ogasawara: yes, will do [20:45] jjohansen, lamont, smb: k, I rebooted with .73 with a guest that was running (ie, it triggers xc_restore on boot) with no error [20:46] jdstrand: thanks [20:58] * ogasawara lunch [20:58] Hi gyus [21:00] Someone know, about a bug by compiling a kernel with a gcc4.4 under Ubuntu 10.04? [21:16] Akendo: what does 'gcc --version' return? [21:17] root@akendo:~/kernel/linux-2.6.35.2# gcc --version [21:17] gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3 [21:17] Copyright (C) 2009 Free Software Foundation, Inc. [21:17] This is free software; see the source for copying conditions. There is NO [21:17] warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [21:17] Akendo: ok, that looks like the stock gcc [21:17] stock gcc? [21:18] Akendo: lucid one [21:18] Akendo: what "bug" are you referring to? [21:18] Hm [21:18] My config to compile the kernel do not work anymore [21:19]