[00:07] <smb_tp> 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] <CarlFK> smb_tp: this kernel doesn't pause: 
[00:16] <CarlFK> [    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] <CarlFK> I booted the beta clonezilla 
[00:17] <CarlFK> http://dev.personnelware.com/carl/a/dmesg24ck.txt
[00:18] <CarlFK> hmm
[00:18] <CarlFK> wrong file...
[00:19] <CarlFK> http://dev.personnelware.com/carl/a/dmesg25ck.txt
[00:22] <smb_tp> CarlFK, Could you post this to the bug, please. I have to leave but then I can look at that tomorrow
[00:40] <CarlFK> will do
[01:23] <DBO> 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] <DBO> 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] <CarlFK> mjg59: nosmp = no pause 
[01:36] <mjg59> CarlFK: Hrm.
[01:37] <CarlFK> ill post dmesg - anything else I should post?
[01:41] <CarlFK> would nosmp explain the lack of [    2.438997] clockevents_set_mode(lapic, 3) [    2.439059] CPU#1: enter broadcast 
[01:42] <CarlFK> its from debugging that smb added  http://launchpadlibrarian.net/17938610/dmesg24ck.txt
[01:57] <CarlFK> :q
[03:37] <DBO> I have more information on resume from suspend freezing on T500's
[03:37] <DBO> it seems to be that the drm module is causing X to freeze
[03:38] <DBO> well the whole system to freeze
[03:38] <DBO> running X without the drm module loaded fixes susped
[03:41] <CarlFK> DBO: have you opened a bug report?
[03:41] <DBO> CarlFK, a couple, but they never get confirmed
[03:41] <DBO> well one for this issue
[03:41] <CarlFK> be sure to add these comments to it
[03:41] <CarlFK> i hear ya on the lack of confirm - bugs me too
[03:42] <DBO> well if I can get a little help I can add a lot more info
[03:42] <DBO> like a possible fix
[03:42] <DBO> i need to be able to rebuild i915.ko
[03:42] <DBO> i have built and installed the latest libdrm
[03:42] <DBO> and drm.ko to match
[03:42] <CarlFK> have you tried #ubuntu+1?
[03:42] <CarlFK> im not going to be much help 
[03:42] <DBO> they directed me to #ubuntu-x
[03:42] <DBO> who directed me to #ubuntu-kernel
[03:42] <CarlFK> lol
[03:43] <wgrant> Here is the right place.
[03:44] <DBO> with latest drm.ko i get errors when trying to modprobe i915
[03:44] <DBO> i915: disagrees about version of symbol drm_open and a bunch of similar
[03:44] <DBO> i am not sure if this is something that a rebuild can fix
[03:44] <DBO> or if I need a more recent version of i915
[03:45] <DBO> to build a new version of i915.ko i need to get GEM support in xorg
[05:48] <fabbione> 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] <fabbione> BenC: ^^^
[08:08] <jwest--> is it advisable to have two kernels
[08:08] <jwest--> a new and an old just in case one doesn't work..
[08:15] <abogani> No more with Intrepid
[08:16] <jwest--> it's not specific with ubuntu, i mean in general
[08:16] <jwest--> is it advisable?
[12:58] <laga> amitk: how's aufs coming along? i'd love to have that in beta.
[12:59] <amitk> laga: It looks good. I am thinking about a few changes to the Makefile. I'll try to push it out today
[12:59] <laga> most appreciated :)
[13:00] <laga> 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] <amitk> laga: you want to run inotify on / ? :)
[13:03] <laga> amitk: aufs can use inotify to detect direct changes to a branch, and wgrant wants that for some reason or another
[13:05] <amitk> ok
[13:23] <Zhenech> IntuitiveNipple, did you find out why hdaps_ec is missing?
[13:26] <smb_tp> Zhenech, Hi mind a counter question? You are the debian maintainer of tp_smapi, right?
[13:27] <Zhenech> smb_tp, yes
[13:29] <smb_tp> 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] <Zhenech> 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] <Zhenech> smb_tp, but if we are lucky, we will see the hdaps_protect stuff in 2.6.28
[13:35] <smb_tp> 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] <Zhenech> smb_tp, that applies to thinkpad_ec too
[13:43] <Zhenech> smb_tp, and yes they cannot run together
[13:44] <Zhenech> smb_tp, thats why I override the in-kernel hdaps completely when tp-smapi is installed
[13:46] <smb_tp> 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] <Zhenech> which makes patching in tp-smapi almost useless
[13:57] <IntuitiveNipple> Having just read the LKML thread where it was refused, it reads as if the refusal was more dogmatic in the end
[13:58] <Zhenech> didnt follow it closely to be honest
[14:00] <IntuitiveNipple> It's pretty short and sweet
[14:06] <DBO> how does one get the source for the linux-rt kernel?  It seems to have been removed from apt
[14:24] <rtg_> lamont: I just emailed you a patch for util-linux/hwclock. Is there a mailling list that it should also go on?
[15:46] <lamont> rtg: hwclock the binary, or hwclock.sh ?
[15:46] <lamont> the first has a mailing list, where I can certainly forward the patch, the second is purely debian et al stuff
[15:46] <rtg> lamont: hwclock the binary
[15:47] <rtg> lamont: I've uploaded that fix for Hardy and Intrepid.
[15:48] <lamont> grr
[15:48] <rtg> lamont: ?
[15:48]  * lamont points at the git repo referenced in debian/control...
[15:48] <lamont> I assume your patch is a git-patch?
[15:48] <rtg> yep
[15:49] <lamont> ah, well then,  skip the 'grr' :-)
[15:49] <lamont> usually, "I've uploaded" == "go grab the deb, break up the diff, and commit it to git for them
[15:49] <rtg> lamont: have you had your coffee yet this morning ?
[15:49] <lamont> heh
[15:50] <rtg> so, I accidentally did both for you :)
[15:50] <lamont> thanks
[15:51]  * lamont kinda bets that it's one diff with debian/changelog and hwclock/* mixed in to one commit though
[15:52] <lamont> oh.  rock on rtg!!!
[15:52] <rtg> lamont: nope, no changelog diff, only the patch to hwclock.
[15:52] <lamont> yeah - finally found the mail in my morning spamfest
[15:54] <lamont> that #if is ugly though... what about x86_64?  other arch?
[15:54] <rtg> I just followed existing ifdefs
[15:54] <rtg> it works for amd64
[15:54] <lamont> ok
[15:55] <rtg> I don't know of any other arches that have that RTC part.
[15:57] <lamont> is there an LP bug#?
[15:57] <rtg> lamont: I created an SRU for Hardy. one sec...
[15:58] <rtg> lamont: bug #274402
[15:59] <lamont> Addresses-Ubuntu-Bug: 274402
[15:59] <lamont> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
[15:59] <lamont> just for future reference :)
[15:59] <rtg> I didn't know what policy was on your debian git repo, so I left it out of the commit.
[16:00] <lamont> no worries - my changelog-generator looks for Addresses-{Debian,Ubuntu}-Bug: NNN[, NNN, NNN]
[16:01] <lamont> I'll grab the source and get the tags to look right sometime today
[16:44] <soren> BenC: Do you remember our talking about the virtio modules' udeb in the context of netboot?
[16:45] <soren> BenC: I talked to cjwatson. The verdict: 15:40:35 < cjwatson> I'd suggest http://paste.ubuntu.com/50526/
[16:58] <BenC> soren: ok
[18:02] <rtg> BenC: how come we're using the sourceforge e1000e driver ?