[00:07] CarlFK, This leaves me somewhat puzzled to the source of the problem. Ok, that the neither cpu has called broadcast enter at that stage is not a 100% proof that they are not in an idle state... But I might have to search somewhere around. [00:16] smb_tp: this kernel doesn't pause: [00:16] [ 0.000000] Linux version 2.6.27-3-generic (buildd@vernadsky) (gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu6) ) #1 SMP Wed Sep 10 16:02:00 UTC 2008 (Ubuntu 2.6.27-3.4-generic) [00:16] I booted the beta clonezilla [00:17] http://dev.personnelware.com/carl/a/dmesg24ck.txt [00:18] hmm [00:18] wrong file... [00:19] http://dev.personnelware.com/carl/a/dmesg25ck.txt [00:22] CarlFK, Could you post this to the bug, please. I have to leave but then I can look at that tomorrow [00:40] will do === emma_ is now known as emma [01:23] hello everyone, can anyone help me figure out what the primary difference between the 2.6.26 rt kernel in intrepid is and its normal kernel [01:23] the 2.6.26-rt kernel is the only one that will suspend for me, but it also randomly will hardlock while I am using it, which is kind of sucky [01:36] mjg59: nosmp = no pause [01:36] CarlFK: Hrm. [01:37] ill post dmesg - anything else I should post? [01:41] would nosmp explain the lack of [ 2.438997] clockevents_set_mode(lapic, 3) [ 2.439059] CPU#1: enter broadcast [01:42] its from debugging that smb added http://launchpadlibrarian.net/17938610/dmesg24ck.txt [01:57] :q === emma_ is now known as emma [03:37] I have more information on resume from suspend freezing on T500's [03:37] it seems to be that the drm module is causing X to freeze [03:38] well the whole system to freeze [03:38] running X without the drm module loaded fixes susped [03:41] DBO: have you opened a bug report? [03:41] CarlFK, a couple, but they never get confirmed [03:41] well one for this issue [03:41] be sure to add these comments to it [03:41] i hear ya on the lack of confirm - bugs me too [03:42] well if I can get a little help I can add a lot more info [03:42] like a possible fix [03:42] i need to be able to rebuild i915.ko [03:42] i have built and installed the latest libdrm [03:42] and drm.ko to match [03:42] have you tried #ubuntu+1? [03:42] im not going to be much help [03:42] they directed me to #ubuntu-x [03:42] who directed me to #ubuntu-kernel [03:42] lol [03:43] Here is the right place. [03:44] with latest drm.ko i get errors when trying to modprobe i915 [03:44] i915: disagrees about version of symbol drm_open and a bunch of similar [03:44] i am not sure if this is something that a rebuild can fix [03:44] or if I need a more recent version of i915 [03:45] to build a new version of i915.ko i need to get GEM support in xorg [05:48] guys, if you are not going to pull from the gfs* trees I made for you, your gfs stuff will be utterly broken [05:48] BenC: ^^^ [08:08] is it advisable to have two kernels [08:08] a new and an old just in case one doesn't work.. [08:15] No more with Intrepid [08:16] it's not specific with ubuntu, i mean in general [08:16] is it advisable? === mdz_ is now known as mdz === amitk_ is now known as amitk === TheMuso_ is now known as TheMuso [12:58] amitk: how's aufs coming along? i'd love to have that in beta. [12:59] laga: It looks good. I am thinking about a few changes to the Makefile. I'll try to push it out today [12:59] most appreciated :) [13:00] then after beta, i'll ask the aufs guy if the inotify option has a huge impact on performance by default so we can make wgrant happy [13:01] laga: you want to run inotify on / ? :) [13:03] amitk: aufs can use inotify to detect direct changes to a branch, and wgrant wants that for some reason or another [13:05] ok [13:23] IntuitiveNipple, did you find out why hdaps_ec is missing? [13:26] Zhenech, Hi mind a counter question? You are the debian maintainer of tp_smapi, right? [13:27] smb_tp, yes [13:29] Zhenech, Do you know how far or in which state generally the upstream integration of hdaps / tp_smapi is? When I looked at hdaps for hardy the driver from the package seemed further developed but there didn't seem much change in the kernel [13:32] smb_tp, kernel guys refuse to include tp-smapi into the kernel, because tp-smapi upstream uses a pseudonym and the kernel guys are unsure about the source of his wisdom about the thinkpad controler [13:32] smb_tp, but if we are lucky, we will see the hdaps_protect stuff in 2.6.28 [13:35] Zhenech, That would be great. :) Ok, then it was tp_smapi which I had lurking in my mind about this "unclear sources". Hmm, I thought someone else said those reservations were somehow settled. Would you think this applies to thinkpad_ec as well or would there be chances to get this accepted. If I understand correctly the kernel hdaps and the tp_smapi driver cannot run concurrently because they both exclusively access the ec. [13:43] smb_tp, that applies to thinkpad_ec too [13:43] smb_tp, and yes they cannot run together [13:44] smb_tp, thats why I override the in-kernel hdaps completely when tp-smapi is installed [13:46] Zhenech, A pitty. Yes, and I tried with a different name for hardy to leave a choice. Which in turn triggered questions about why... And maybe it was that reason the driver got dropped when moving from hardy to intrepid. [13:49] which makes patching in tp-smapi almost useless [13:57] Having just read the LKML thread where it was refused, it reads as if the refusal was more dogmatic in the end [13:58] didnt follow it closely to be honest [14:00] It's pretty short and sweet [14:06] how does one get the source for the linux-rt kernel? It seems to have been removed from apt [14:24] lamont: I just emailed you a patch for util-linux/hwclock. Is there a mailling list that it should also go on? [15:46] rtg: hwclock the binary, or hwclock.sh ? [15:46] the first has a mailing list, where I can certainly forward the patch, the second is purely debian et al stuff [15:46] lamont: hwclock the binary [15:47] lamont: I've uploaded that fix for Hardy and Intrepid. [15:48] grr [15:48] lamont: ? [15:48] * lamont points at the git repo referenced in debian/control... [15:48] I assume your patch is a git-patch? [15:48] yep [15:49] ah, well then, skip the 'grr' :-) [15:49] usually, "I've uploaded" == "go grab the deb, break up the diff, and commit it to git for them [15:49] lamont: have you had your coffee yet this morning ? [15:49] heh [15:50] so, I accidentally did both for you :) [15:50] thanks [15:51] * lamont kinda bets that it's one diff with debian/changelog and hwclock/* mixed in to one commit though [15:52] oh. rock on rtg!!! [15:52] lamont: nope, no changelog diff, only the patch to hwclock. [15:52] yeah - finally found the mail in my morning spamfest [15:54] that #if is ugly though... what about x86_64? other arch? [15:54] I just followed existing ifdefs [15:54] it works for amd64 [15:54] ok [15:55] I don't know of any other arches that have that RTC part. [15:57] is there an LP bug#? [15:57] lamont: I created an SRU for Hardy. one sec... [15:58] lamont: bug #274402 [15:59] Addresses-Ubuntu-Bug: 274402 [15:59] Signed-off-by: Tim Gardner [15:59] just for future reference :) [15:59] I didn't know what policy was on your debian git repo, so I left it out of the commit. [16:00] no worries - my changelog-generator looks for Addresses-{Debian,Ubuntu}-Bug: NNN[, NNN, NNN] [16:01] I'll grab the source and get the tags to look right sometime today === mdz_ is now known as mdz [16:44] BenC: Do you remember our talking about the virtio modules' udeb in the context of netboot? [16:45] BenC: I talked to cjwatson. The verdict: 15:40:35 < cjwatson> I'd suggest http://paste.ubuntu.com/50526/ [16:58] soren: ok === mkrufky is now known as mkrufky-lunch [18:02] BenC: how come we're using the sourceforge e1000e driver ? === chuck_ is now known as zul === mkrufky-lunch is now known as mkrufky