[03:05] <jwi> jsalisbury: for the i915 edp regression in oneiric/precise, you might want to look into https://lkml.org/lkml/2012/1/25/203
[07:41] <eQuiNoX__> hey guys
[07:44] <larsk103> I have a weird problem with harddrives under the mpt2sas driver. When i do anything but 4k writes, the kernel reads from the drives before writing. These are 512 bytes sector drives, and the kernel seems to know this. Where can I report this?
[10:41] <apw> ppisati, i see you found the MMC issue, nice
[10:41] <ppisati> apw: yep
[10:41] <apw> ppisati, did it take all night ?
[10:42] <ppisati> apw: nope, i fnished yesterday around 21
[10:42] <apw> ppisati, phew, i was worried you'd have to bisect and it'd take ages
[10:42] <ppisati> apw: i prefer to do it manually
[10:43] <ppisati> apw: there were modules that were more suspects than others
[10:43] <ppisati> and i keep forgetting mumble in the morning...
[10:43] <apw> t'is easy to do, i sometimes think i am using it when i am not
[10:54] <ppisati> (EE) module ABI major version (10) doesn't match the server's version (11)
[10:55] <ppisati> uhm
[10:55] <RAOF> ppisati: What driver?
[10:55] <RAOF> I thought I'd caught them all, but sufficiently badly-packaged drivers might have escaped me :)
[10:56] <ppisati> RAOF: panda board
[10:56] <ppisati> RAOF: let me upload the X log
[10:56] <RAOF> That should use omapfb, right?  I thought that got a rebuild?
[10:56] <RAOF> Thanks for the log.
[11:04] <ppisati> RAOF: it's a dkms, the hw accelerated driver
[11:05] <RAOF> That's the kernel driver; your error comes from the X server trying to load the DDX, which is different.
[11:05] <ppisati> ah ok
[11:05]  * ppisati is X ignorant...
[11:06] <RAOF> Are your logs anywhere?
[11:06]  * RAOF will go soon; it's 10pm
[11:06] <ppisati> http://people.canonical.com/~ppisati/Xorg.0.log
[11:07] <RAOF> Where does that come from?
[11:07] <ppisati> RAOF: from my panda, dist-upgraded this morning
[11:08] <ppisati> RAOF: http://paste.ubuntu.com/818693/
[11:09] <RAOF> Where does that driver come from?  It doesn't appear to be in the archives.
[11:09] <ppisati> RAOF: http://paste.ubuntu.com/818694/
[11:10] <apw> RAOF, could it be a partner job ?
[11:10] <RAOF> That's broken from the Xserver 1.11 transition.  It won't work until you rebuild it against the newer server.  Or, if it's closed-source, it won't work until PowerVR rebuild it against the new server.
[11:11] <ppisati> well, it says: "pool/main/p/pvr-omap4/pvr-omap4_1.7.10.0.1.7-1_armel.deb"
[11:11] <ppisati> do we have closed/outside world stuff in main?
[11:12] <apw> ppisati, does this machine have any odd ppas on it
[11:12] <ppisati> apw: let me check
[11:12] <RAOF> “main” is the default component for PPAs.
[11:13] <apw> its unlikely powervr is something we have source for, me thinks
[11:13] <RAOF> This does indeed seem likely.
[11:13] <apw> PowerVR SGX540 kernel driver for OMAP4 in DKMS
[11:13] <RAOF> Also, is it really so hard to package X drivers?
[11:13] <ppisati> yes, it comes from TI ppa
[11:13] <apw> and the kernel driver isn't ... in the kernel
[11:13] <apw> ppisati, ok so you need to get the arm folks to poke them to rebuild it
[11:13] <ppisati> deb http://ppa.launchpad.net/tiomap-dev/release/ubuntu oneiric main #Added by so
[11:13] <RAOF> We've got all this fancy dpkg-helper stuff!
[11:13] <ppisati> ftware-center
[11:14] <RAOF> ppisati: Yeah.  That driver's not going to work until it gets rebuilt against the new Xserver ABI.
[11:14] <ppisati> got it
[11:14] <ppisati> i'll poke them then
[11:14] <ppisati> ogra_: ^^^
[11:14] <RAOF> Consider it a tax on out-of-archive drivers ;)
[11:14] <ppisati> rsalveti: ^^^
[11:14]  * apw notes A2 is ... SOON
[11:15] <apw> RAOF, i take it you have never been told there is a ti* wibble X driver to worry about
[11:15] <ogra_> TI hasnt done an upload yet, not much we can do about this but pinging them (which happened)
[11:15] <RAOF> apw: Indeed not.
[11:15] <RAOF> Well, maybe I have, but I'd forgotten entirely.
[11:15] <apw> ogra_, heres hoping you arn't gated on them for your A2 images
[11:15] <ogra_> they are also working on an armhf version of the driver... 
[11:16] <ogra_> apw, its a PPA driver ...
[11:16] <apw> so presumably ppisati can remove it and get something working
[11:16] <ppisati> cool, so i don't have to worry about it
[11:16] <ogra_> indeed we arent depending on PPA stuff for oour images :)
[11:16] <RAOF> Yeah.  I *did* check all the drivers in the archive.
[11:16] <apw> i presume just his performance will suck
[11:16] <RAOF> Although I would have missed a driver packaged as badly as that one - it doesn't even have a dependency on the X server!
[11:17] <ppisati> apw: i personally prefer the server images
[11:17] <ogra_> Ti doesnt manage to stick to our release schedule (their ubuntu team is to small) for that reason their stuff lives in the PPA
[11:17] <ppisati> all the X/light/unity/$fancyferretgraphicstuff just slow down my board
[11:17] <ogra_> as long as the xfbdev drver is working all is fine 
[11:18] <ppisati> ogra_: that's working
[11:18] <ogra_> (thats what we ship by default)
[11:19] <ogra_> plan is actually to remove the PPA icon from the desktop as well and eventually get the pvr driver into the archive, but that hasnt happened yet and will need agreement from the TI side to stick to the release schedule (which is being discussed)
[11:19] <RAOF> ogra_: Once it wanders archiveward, please give me a ping so I can fix up its packaging a little.
[11:20] <ogra_> RAOF, i will ! thanks for the offer ... it will be multiverse anyway though (package has an EULA) 
[11:21] <RAOF> That's fine.  I'd like to make sure it actually turns up on my sweep for drivers I'll break when changing Xserver ABI though :)
[11:22] <ogra_> ah, indeed :)
[11:27] <diwic> apw, still "Pending publication"...hmm...
[11:27] <diwic> for 3.2.0-11.19
[11:27] <apw> diwic, we were waiting on powerpc last night, i asked for it to be rescored
[11:27] <apw> diwic, yay they are all there, will hastle someone
[11:28] <apw> diwic, hopefully it'll be in shortly
[11:28] <RAOF> Heh.  Poor powerpc
[11:28] <apw> she is lagging and no mistake, even arm is getting done before her now
[11:28] <diwic> apw, thanks a lot
[11:29] <apw> diwic, ok ... they are accepted now, i'll go check meta
[11:29] <ppisati> ppc hw is quite cheap nowadays, can't we throw more hw at it?
[11:29] <ppisati> and, btw, why do we support ppc? :)
[11:29] <apw> ppisati, i hear we have a box in house, waiting to be installed, but ... is is on the case
[11:34] <apw> ogasawara, 3.2.0-11 now accepted, i've uploaded (your) meta
[11:34] <_jmp_> ppisati: maybe one day Ubuntu will run on Playstation (ppc for now) as Game-OS :)
[11:36] <apw> diwic, ok meta is now in the queue
[11:36] <apw> diwic, so it should all be in the archive in about an hour
[11:37] <diwic> apw, excellent
[11:38] <ppisati> _jmp_: with only 256mb of ram? neeehhh... :)
[11:39] <_jmp_> ppisati: PS4 maybe :D anyway... hi * :)
[11:52] <ppisati> ogra_: on the beagle ml, people are reporting issue with beaglebone + armhf: kernel doens't boot, while O/armel was working fine
[11:53] <ppisati> ogra_: http://groups.google.com/group/beagleboard/browse_thread/thread/370de0a4734bdd24/6a98b1623bf7a39d
[11:54] <ogra_> ppisati, thats talking about images from elinux !
[11:54] <ogra_> he rolls his very own kernel
[11:55] <ogra_> talk to robert nelson ;)
[11:55] <ogra_> (rcn_ee is his irc nick)
[11:55] <ogra_> see the last mail in that thread
[11:55] <ppisati> ogra_: acutally he says "BeagleBoardUbuntu#Precise_12.04_armhf_testing"
[11:56] <ogra_> yes, that means he uses our userspace for his u-boot and kernel hackery
[11:56] <ppisati> ogra_: he said he tried even upstream
[11:57] <ogra_> i havent heard about issues from tobin with armhf on beagle yet, does he have different HW from yours ?
[11:58] <ppisati> ogra_: don't think so
[11:59] <ogra_> also note it doesnt talk about the beagle*board* at all
[11:59] <ogra_> that thread is abotu the beagle*bone* (successor)
[11:59] <ppisati> ogra_: yep i know
[12:00] <ogra_> i dont think any of us has that HW
[12:00] <ogra_> unless someone sends us some boes we wont be able to support it 
[12:01] <ogra_> dont worry about it until we got some HW i'd say, we cant QA or test it at all without HW
[12:02] <ppisati> k
[12:35]  * herton -> errand+early lunch, back in +- 2h
[12:54] <aquarius> cking, heya; any chance you have a bit of time to think about my u300s not suspending? (No problem if not, of course. :))
[12:56] <davmor2> aquarius: it just hates you ;)
[12:56] <aquarius> is a possibility, I admit it.
[12:56] <cking> aquarius, quite frankly, i'm stumped by it - and our bios engineer is off on chinese new year at the mo
[12:57] <aquarius> cking, there's a certain satisfaction that it's actually a real genuine problem and not just me, I suppose!
[12:57] <aquarius> hibernate works (although I can't set the machine to hibernate from the gui, for reasons I do not understand)
[12:58] <apw> (i am sure i asked this before, but i like to make sure) you don't have powernap installed do you
[12:58] <aquarius> I doubt it, since I don't know what it is
[12:58]  * aquarius checks
[12:58] <aquarius> apw, I do not have it installed :)
[12:59] <apw> and you don't take CPUs offline
[12:59] <cking> apw, it's one of those mystery "hang" issues which exists outside of the kernel context
[13:04] <smb> apw,  ogasawara, tgardner head up on bug 921816
[13:04] <ubot2`> Launchpad bug 921816 in linux "BUG: unable to handle kernel NULL pointer dereference at 00000030" [Medium,Confirmed] https://launchpad.net/bugs/921816
[13:04] <smb> Looks like seccomp patches are at fault
[13:04] <eQuiNoX__> hey guys
[13:04] <apw> smb, ok so not something thats critical, as nothing uses them ?
[13:05] <smb> apw, No clue what is using them, but at least one thing from the seccomp qa regression tests does
[13:10] <apw> smb, as far as i know the only thing that every _might_ use it is chromium-browser, but in the thread from the submitter there was an indication that it was not in use
[13:11] <smb> apw, Yeah, seem we never heard anything before and it seems right now it may beonly triggered by the qa regression suite and maybe only on vms
[13:11] <smb> Will test bare metal now
[13:12] <apw> smb, sounds good, thanks
[13:12] <tgardner> smb, will drewery had a new patch set proposed on the list awhile ago, but the upstream discussion was so lengthy that I chose to wait a bit.
[13:13] <smb> tgardner, right, I have gone forward and made a kernel with all old seccomp patches reverted and his new version applied. That one seems not to cause a crash but some subtests to fail
[13:13] <smb> (which could be because its not implemented or different or. ...)
[13:14] <apw> definatly should ask kees and will about that, as we want to be on whatever he is upstreaming
[13:14] <tgardner> apw, right. they ought to be online in a couple of hours
[13:16] <smb> tgardner, apw I'd reply to will's mail to us. Just want to have the info about the old patcheset and the tests verified before I do
[13:16] <apw> sounds ike a plan to me
[13:18] <rsalveti> ogra_: ppisati: that abi incompatibility was expected 
[13:18] <rsalveti> TI was just waiting the upload to happen to release a newer driver
[13:18] <rsalveti> let me send an email to xavier so he can push it to the PPA
[13:18] <ogra_> do you think they will do it before A2 ?
[13:18] <rsalveti> and also request the armhf one
[13:18] <ogra_> (would be helpful indeed)
[13:19] <ogra_> i pinged nicolas about it but have no answer yet
[13:19] <rsalveti> ogra_: generally xavier is quite fast on uploading a newer version
[13:19] <ogra_> ah, great
[13:19] <rsalveti> we'll see
[13:19] <ogra_> yep
[13:20] <rsalveti> let me send the email :-)
[13:20] <ogra_> thanks !
[13:20] <ogra_> :)
[13:34] <eQuiNoX__> hey guys, it would be great if you could spend a minute to help me out here => http://askubuntu.com/questions/98995/system-programming-in-ubuntu. thanks for your time!
[14:02] <ogasawara> smb: thanks for the note.  I believe that jjohansen was looking into the seccomp qa regression test failure.
[14:03] <smb> ogasawara, Ah ok. Right now it seems to be reproducible on 64bit vm and bare metal and causing an oops. Just gathering more date about i386 and comparing to oneiric
[14:05] <smb> ogasawara, Right, so oneiric seems to be ok. There is one failure of the tests for libcap but that is likely rather the test incorrect (/me hopes)
[14:05] <jjohansen> smb: yeah hggdh opened Bug #921816 for it
[14:05] <ubot2`> Launchpad bug 921816 in linux "BUG: unable to handle kernel NULL pointer dereference at 00000030" [Medium,Confirmed] https://launchpad.net/bugs/921816
[14:05] <jjohansen> I haven't looked at oneiric yet
[14:05] <smb> jjohansen, right. jsalisbury pinged me about that
[14:05] <smb> jjohansen, Just did a run
[14:06] <jjohansen> I had been holding off on the new version of seccomp waiting on the discussion
[14:06]  * jjohansen doesn't actually expect we will carry the older version
[14:06] <smb> jjohansen, Right now it looks like someting in precise together with the seccom patch is bad
[14:06] <smb> jjohansen, Yep, I build a test kernel with the new version
[14:06] <jjohansen> yeah
[14:06] <smb> jjohansen, looks better but fails some subtests
[14:07]  * smb is about to fire of a mail thread
[14:07] <jjohansen> yeah, thanks for doing that I keep meaning to but ..
[14:11] <smb> jjohansen, no worries. mail is out. btw, running test-kernel-security.py on oneiric I got one fail in the last test that tries to check for libcap (oneiric would have libcap2) and fails. It is less of a worry but probably should be looked after
[14:11] <jjohansen> right
[14:12]  * smb sent mail without waiting for slooooow i386 to finish update all other stuff...
[14:14] <jjohansen> hehe, understandable
[14:31] <ogasawara> tgardner: are you updating chroots on gomeisa by chance?
[14:31] <tgardner> ogasawara, rebuilding them since they seem to have gotten borked. lemme go check on 'em
[14:32] <ogasawara> tgardner: ok cool.  got some random error when trying to chroot into precise-amd64, so I'll just wait.
[14:33] <tgardner> ogasawara, you might want to use tangerine. gomeisa seems to have a file system issue.
[14:33] <ogasawara> tgardner: ack
[14:34] <apw> tgardner, oh that sounds bad
[14:35] <tgardner> apw, 20copyfiles: cp: not writing through dangling symlink `/var/lib/schroot/mount/precise-armhf-5b681eba-8a44-4335-a08e-f089dc799848/etc/resolv.conf
[14:35] <apw> tgardner, isn't that a security thing, one of kees
[14:35] <apw> tgardner, as in something valid, not broken FS
[14:36] <tgardner> apw, a change in behavior then? this is a 3.0 kernel
[14:36] <tgardner> and what is a dangling symlink ?
[14:37]  * apw looks for the thing he is thinking of
[14:40] <apw> tgardner, ok, i think i am thinking of hardlink things
[14:41] <apw> tgardner, but a dangling symlink is just a symlink that points to a non-existant place
[14:41] <tgardner> apw, yeah, I don't see anything in yama
[14:41] <apw> and that directory there no longer exists cause its an schroot place
[14:42] <tgardner> apw, the failure was on armel, so perhaps I should check that the x86'en chroots recreated OK.
[14:42] <apw> i suspect that that may be being triggered by the resolvconf transition.  that changes your resolv.conf into a link i think
[14:43] <tgardner> apw, ah, 'cause i386 has the same issue.
[14:43] <apw> see if the resolv.conf is a symlink inside the chroot
[14:44] <tgardner> apw, you mean precise is now a symlink? hmm
[14:45] <tgardner> apw, well, its a link on my desktop. resolv.conf -> /run/resolvconf/resolv.conf
[15:09] <tgardner> apw, I think this is actually a schroot problem with /etc/schroot/sbuild/copyfiles
[15:15] <apw> tgardner, hmmm, well that just lists the files to copy
[15:15] <tgardner> apw, right. its actually /etc/schroot/default/copyfiles
[15:16] <apw> even that is just a list of files
[15:16] <tgardner> which is used by /etc/schroot/setup.d/20copyfiles
[15:17]  * ppisati -> the dove kernel is backing on tangerine, back in a bit
[15:17] <tgardner> I think I'll ask on #ubuntu-devel. surely they have encountered this issue already.
[15:17] <apw> etc/resolv.conf -> /run/resolvconf/resolv.conf
[15:17] <apw> no i think this is the bug
[15:17] <apw> that should not be an absolute link
[15:17] <apw> it should be etc/resolv.conf -> ../run/resolv.conf
[15:18] <apw> it should be etc/resolv.conf -> ../run/resolvconf/resolv.conf
[15:18] <apw> the second one ...
[15:18] <apw> so that it works in chroots from outside ... as the copy (20copyfiles) has to work from outside to see both files
[15:18] <tgardner> apw, well, only if /run is mounted within the choot
[15:19] <apw> run should be unique to the chroot right?  even if its not adding one, the directory should work
[15:19] <tgardner> apw, so you think the ultimate bug is in the resolvconf package ?
[15:20] <apw> i think its odd to use an absolute link like that ever, so i'd query if thats legal for this exact reason
[15:20] <tgardner> apw, ack
[15:20] <apw> if it is, then 20copyfiles needs to read all the links it finds and map / to the chroot
[15:21] <apw> or use something more like 'cat source | chroot FOO cat - >destination
[15:21] <apw> to do the copy
[15:35]  * ogasawara back in 20
[16:03] <tgardner> ogasawara, you're making tangerine squeal.
[16:03] <ogasawara> :)
[16:08] <apw> ogasawara, 420 ... ouch
[16:09] <apw> "420:1 and falling" "344:1 and falling"
[16:10] <ogasawara> bjf: there's complaints that rls-p-tracking-bugs.html is broken...
[16:11] <smb> apw, Guess when its one anything else is our own problem
[16:11] <apw> smb, :) indeed
[16:13] <bjf> ogasawara: naturally
[16:13] <apw> bjf, let me guess this is the first you have heard of it
[16:13] <bjf> apw, yup
[16:14] <ogasawara> I think this if the first people were aware (ie have looked at the page)
[16:14] <bjf> ogasawara: let whomever know i'm looking into it
[16:14] <ogasawara> bjf: will do
[16:14] <ogasawara> bjf: it was pointed out in the release meeting
[16:15] <bjf> ogasawara: figured as much
[16:15] <ppisati> herton: what's the status of the lucid/master? is it ok? can i go ahead and rebase?
[16:16] <herton> ppisati, yep, you can go ahead
[16:31] <bjf> ogasawara: the report is back
[16:31] <ogasawara> bjf: thanks
[16:51] <brendand> tgardner - hi
[16:52] <tgardner> brendand, hmm?
[16:53] <apw> ogasawara, i just pushed an ipv6 config change onto your tree
[16:53] <brendand> tgardner - do you think it would be important to test different wireless frequencies as well as different bands (e.g. 2.4Ghz and 5Ghz)?
[16:54] <tgardner> brendand, not particularly, no.
[16:54] <brendand> tgardner - cool
[16:55] <tgardner> ogasawara, gomeisa should be back to normal in 10 mins or so
[16:57] <ogasawara> apw: ack, thanks
[16:57] <ogasawara> tgardner: k, I'll hammer on it next
[16:58] <apw> ogasawara, it doesn't need to go in for A2 if you have already tested, it can happily wait for upload#1 after
[16:58] <ogasawara> apw: cool, I think I'll let it wait then since I've just finished my test builds.
[16:59] <apw> in fact not putting it in given all the other instability we have ...
[17:21] <tgardner> ogasawara, gomeisa is ready to bend to your will.
[17:21] <ogasawara> tgardner: thanks!
[18:40]  * ogasawara debates ripping out all the seccomp patches for the Alpha-2 upload
[18:41] <tgardner> ogasawara, it can't be any worse then the current situation.
[18:42] <tgardner> ogasawara, and having just read the email list, kees agrees.
[18:43] <arges> hey. i'm getting this odd error on my t420 where when I resume from suspend, it then re-suspends. is there a wiki on how to get verbose suspend info? or should I just file a bug and go from there. 
[18:43] <arges> its somewhat rare for me. but annoying when it happens.
[18:44] <tgardner> arges, you just missed cking, but I remember that the double suspend used to be a problem.
[18:44] <tgardner> I can't remember what was causing it.
[18:44]  * apw calls it a day ...
[18:44] <ogasawara> tgardner: was that the same issue cking and him were debugging in budapest?
[18:45] <tgardner> ogasawara, I don't recall if that was it.
[18:45] <tgardner> seems like the double suspend issue was in Oneiric
[18:46]  * tgardner -> lunch
[18:46] <cking> gah, my AP is a pile of unreliable do do
[18:47] <smb> cking, nah that is the new "this is the weekend" feature. :)
[18:47] <arges> cking, hey! having some wierd double-suspend issues with my t420. are there some bugs I should look at? or verbose info I can get to see what the problem is?
[18:48] <cking> arges, double -suspend? what's that
[18:49] <arges> cking, sorry, so when I wake my laptop up. it resumes suspend. I see the login, but then it immediately goes back into suspend 
[18:49] <arges> its not every time, so i occasionally hit this
[18:49] <arges> but I want to get better info on it, so I can file a good bug / start looking into it
[18:51] <cking> arges,  file a bug - then when it happens attach the dmesg output and the /var/log/pm-suspend.log so it can be eye-balled
[18:51] <arges> cking, ok. will do
[18:53] <ogasawara> arges: this is a wiki I found, but not the one I was thinking of...https://wiki.ubuntu.com/DebuggingKernelSuspendHibernateResume#Debugging_Suspend
[18:53] <arges> ogasawara, ok cool i'll read though this one too! thanks
[18:55] <herton> arges, I remembered/found another one too, this may be useful, an excellent instrumentation cking did using systemtap, for debugging suspend: https://wiki.ubuntu.com/Kernel/Reference/S3SystemTapDebug
[18:55] <ogasawara> tgardner: I'm ripping out the seccomp patches.  I've still got enough time to build, test, and upload.
[18:56] <herton> but it would be more intended for the case of a hang
[18:56] <cking> herton, this is kinda useful for hangs, but I'm unsure how useful my S3 scripts will be for a bounce
[18:56] <herton> indeed
[18:57] <arges> herton, ok that might be good for some deep debugging. i'll try to get a bug filed with dmesg / log info when I hit it again. thanks
[18:57] <cking> arges, does google show anything useful, you can't be other other user running ubuntu on this machine?
[18:58] <arges> cking, not sure what you mean by that.  i'm the only user on this machine 
[18:59] <cking> arges, i meant, there must be loads of other people with this machine on the planet running ubuntu, so if it's a common issue you may find it with google ;-)
[18:59] <arges> cking, yea i'll do that first
[19:00] <cking> search is your friend ;-)
[19:20] <cking> somebody make bzr run faster please!
[19:20] <tgardner> ogasawara, ack
[22:18] <jcastro> Hi, I'm looking for the generic backported compat-wireless package for oneiric, I think it's this one but it looks too specific to be the generic metapackage: http://packages.ubuntu.com/oneiric-updates/linux-backports-modules-cw-3.1-3.0.0-15-generic
[22:35] <bjf> jcastro: i think you are looking for linux-backports-modules-3.0.0
[22:56] <chrxn> Hail, Sages!
[22:58] <chrxn> I am trying to compile with 1000hz timing in EC2 for use with VOIP. I'm using some instructions that I found for doing this, but I have hit a wall, and I don't know how to continue exactly.
[23:01] <chrxn> This is the error ( http://pastebin.ca/2106891 ) I've encountered after following these instructions ( http://tinyurl.com/875emvt )
[23:01] <ohsix> if the ec2 vm's can do hrtimers HZ is going to be somewhat moot unless you end up depending on a driver (loool virtual machine) that still relies on jiffies
[23:03] <chrxn> So, even if this could be acheived,  and it could most likely by a more experienced person than I, it would be of little consequence?
[23:04] <ohsix> yep
[23:04] <chrxn> Thank you, oh sage.
[23:05] <ohsix> you can see what sort of timers are being used by userspace software and kernel threads in /proc/timer_list
[23:08] <chrxn> This is way over my head. It only took a jiffy of talking to you to know that my efforts are futile in doing this thing.
[23:08] <chrxn> I will keep the kernel as-is.
[23:08] <chrxn> Thanks for your guidance ohsix 
[23:11] <ohsix> no problem