[03:00] <ohsix> any idea why bug 711429 is nonpublic?
[03:00] <ubot2> ohsix: Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/711429)
[03:01] <ohsix> marking a public bug a duplicate of a private one suxxx
[03:08] <bjf> ohsix, i've added a somment asking why it's private
[03:08] <ohsix> ok, thanks
[03:08] <bjf> ohsix, not sure why you are asking in the kernel channel though, you might get more satisfaction in #ubuntu-devel
[03:09] <ohsix> well, eyes; most things i have to ask about are fleeting in interest :]
[03:09] <ohsix> it being private is almost good for me; then i don't have to follow up on the public one i posted
[03:12] <bjf> ohsix, it was marked a duplicate by a bot
[03:12] <ohsix> right
[03:13] <bjf> ohsix, i'm trying to find out who "ownes" the bot, it shouldn't automatically mark public bugs duplicates of private bugs
[03:14] <ohsix> keen, i've had it happen two or three times; wondered why it took that path
[03:14] <bjf> ohsix, there's probably a way to file a bug against the bot
[03:18] <bjf> ohsix, email sent, i'm guessing this will get fixed up fairly quickly
[03:18] <ohsix> much appreciated
[11:19] <apw> herton, http://reports.qa.ubuntu.com/reports/jfo/kernel-buglist-by-team.html
[11:21] <apw> https://wiki.ubuntu.com/Kernel/Dev/KernelGitGuide
[11:21] <apw> https://www.launchpad.net/ubuntu/+source/linux
[11:43]  * apw pops to run some errands
[12:19] <lag> Why would debian/tests/check-aliases fail?
[12:56] <apw> lag, aliases are module aliases i beleive
[12:56] <apw> does it produce any output when it fails ?
[12:56] <apw> lag, it should have done
[12:56] <lag> apw: No it didn't
[12:56] <apw> it is saying that there are two entries for the same alias
[12:57] <lag> apw: The 'die' died, but didn't produce output 
[12:57] <lag> apw: I know what's wrong
[12:57] <apw> lag, can i see the log up to that point pls
[12:57] <SamuraiAlba> any fix for the "cannot reserve MMIO region" issue?
[12:57] <lag> apw: The debian packaging system does not use $(make kernelversion)
[12:58] <apw> it does make vmlinuz or similar right?
[12:58] <lag> Instead it looking for ./debian/linux-image-2.6.35.7-1000-u8500/lib/modules/2.6.35-7-1000-u8500/modules.alias
[12:58] <lag> Sorry, other way round
[12:59] <apw> it does a make O=debian/build/build-flavour vmlinuz or whatever to be more accurate
[12:59] <apw> which should work
[12:59] <lag> Well $(make kernelversion) produces 2.6.35.7
[12:59] <SamuraiAlba> The "cannot reserve MMIO region" is cutting into my boot time on Ubuntu 10.10 :)
[12:59] <lag> And the debian packaging system is using 2.6.35
[13:00] <apw> SamuraiAlba, i don't think i know that issue, got a bug # ?
[13:00] <lag> So it's not looking in the correct directory for modules.alias
[13:01] <apw> the default is to install them insto 2.6.NN-ABI-flavour
[13:01] <apw> that is where they are on my system
[13:01] <SamuraiAlba> Bug #577842 in linux (Ubuntu): “shpchp cannot reserve mmio region”
[13:01] <ubot2> Launchpad bug 577842 in linux "shpchp cannot reserve mmio region" [Low,Triaged] https://launchpad.net/bugs/577842
[13:01] <SamuraiAlba> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/577842
[13:01] <ubot2> Launchpad bug 577842 in linux "shpchp cannot reserve mmio region" [Low,Triaged]
[13:01] <SamuraiAlba> ahhh
[13:01] <apw> lag, mumble ?
[13:01] <apw> feels like we are spinning round each other
[13:02] <lag> apw: Sure
[13:03] <lag> apw: https://wiki.linaro.org/PackageYourOwnKernel
[13:05] <apw> apw@dm$ make EXTRAVERSION='' kernelversion
[13:05] <apw> 2.6.38
[13:05] <apw> lag, ^^
[13:07] <lag> apw: linux-u8500 (2.6.35.7-1000.0) UNRELEASED; urgency=low
[13:12] <apw> apw@dm$ fdr printenv | grep 2.6.35
[13:12] <apw> lag, could you paste the output of that
[13:14] <lag> apw: https://pastebin.linaro.org/19/
[13:16] <lag> apw: http://paste.ubuntu.com/561921/
[14:02] <soren> Are kernel uploads to natty on a specific schedule (like e.g. every Thursday) or what triggers an upload?
[14:03] <tgardner> soren, its fairly adhoc. we're waiting for the A2 release cycle to finish, then we'll upload when -rc3 is out.
[14:05] <soren> tgardner: I see, ok.
[14:05] <soren> tgardner: Cool, thanks.
[14:35] <apw> smb, fyi i see you assigned self to CVE-2010-0435 in the cve tracker, but was not reflected in the Awsome sheet, corrected
[14:35] <ubot2> apw: The Hypervisor (aka rhev-hypervisor) in Red Hat Enterprise Virtualization (RHEV) 2.2, and KVM 83, when the Intel VT-x extension is enabled, allows guest OS users to cause a denial of service (NULL pointer dereference and host OS crash) via vectors related to instruction emulation. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0435)
[14:36] <smb> apw, did I? That sounds like some old cruft somehow...
[14:36] <smb> IOW before awesome sheet existed
[14:36] <apw> smb, could well be, but as you are assigned noone else will touch it
[14:36] <apw> and its xen :)
[14:37] <smb> apw, No kvm
[14:37]  * tgardner thinks smb likes xen
[14:37] <smb> apw, But anyway IIRC that was the one I thought had been moved to completed
[14:37] <apw> oh yeah, doh, can't read for looking
[14:37] <smb> tgardner, As much as I like tax declarations :-P
[14:37] <apw> smb, could be ... prob best you sanity check it
[14:38] <smb> apw, yup, will do. Thanks for the heads up
[14:40] <tgardner> sconklin, I pushed a bunch of CVE updates on the maverick ti-omap branch. since I cherry-picked them from maverick master-next, do you think we need to go through the mailing list ACK process? I'm thinking not.
[14:43] <sconklin> tgardner: no, especially if they cherry picked cleanly
[14:44] <tgardner> sconklin, yep, that was sorta my criteria as well
[14:47] <apw> tgardner, if the patch had an ack as a patch and applies clean its just noise otherwise
[14:47] <apw> tgardner, is that a .33 branch?
[14:47] <tgardner> .35
[14:47] <tgardner> I went through all of maverick master-next and cherry-picked the CVE patches
[14:50] <apw> tgardner, i think we should take an ack on maverick to mean an ack for all 2.6.35 based branches; if they arn't a rebase then i'd expect them to get it via cherry without additional comment
[14:51] <tgardner> apw, yep, I think I'll codify that as policy in the wiki.
[14:52] <apw> ack
[14:52] <apw> right i am off-ski  .. speak latetr
[14:53] <tgardner> apw, later dude...
[15:04] <lag> kamal: Hi :)
[15:04] <kamal> lag: hey man, howdy
[15:04] <lag> kamal: I'm playing around with GPG keys (only because I have to :))
[15:05] <lag> What's the difference between full and ultimate?
[15:06] <lag> And how do I change my new uids from unknown to full/ultimate?
[15:06] <kamal> lag: http://www.queen.clara.net/pgp/art4.html
[15:06] <lag> Oh, they're already ultimate. They were unknown before?
[15:07] <kamal> lag: you can mark other people's keys as "full" trust, meaning that you have a high level of trust in their signatures when they appear on other keys ...
[15:07] <kamal> lag: you should mark (only) your own key as "ultimate", so that gpg will realize that it should absolutely positively trust any key that you yourself have signed.
[15:07] <lag> kamal: Did you 'make' me do that for you when you signed my keys?
[15:08] <kamal> lag: when you create your own key, gpg automatically assigns it "ultimate"
[15:08] <lag> kamal: Make them 'full' I mean
[15:08] <kamal> I didn't adivse you to fiddle with the trust levels at all
[15:08] <lag> kamal: Is 'full' the default then?
[15:09] <lag> kamal: For other people's keys I man
[15:09] <lag> mean*
[15:09] <kamal> lag: no, i think the default should be "no trust" for other peoples keys
[15:12]  * kamal afk for a bit
[15:12] <lag> kamal-afk: No problem - thanks for your help
[15:37] <kamal> lag: got it sorted out?
[15:38] <lag> kamal: I do - thanks dude :)
[15:38] <kamal> lag: excellent :-)
[15:54] <amitk> anybody's seen (or done) any changes related to the number of open files in the natty kernel? I've just installed natty for the first time and mutt is constantly complaining about "too many files open".
[15:54] <amitk> wonder if anything changed in the kernel before I go search for mutt bugs
[15:55] <tgardner> amitk, nothing that we've done on purpose.
[15:55] <tgardner> amitk, apw uses mutt. 
[15:56] <tgardner> as does pgraner IIRC
[15:56] <amitk> tgardner: yes, I know. I was hoping he'd hit the problem first ;)
[15:56] <tgardner> amitk, you're just lucky I guess
[16:22] <bjf> herton, look at https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel  these are the simplest instructions we have, you can build upon them
[16:23] <herton> ok, thanks
[16:30] <tgardner> JFo, what tags should a CVE bug have in order to avoid getting spammed?
[16:30] <tgardner> JFo, bug #711341 for example
[16:30] <ubot2> Launchpad bug 711341 in linux "CVE-2010-3880" [Undecided,Incomplete] https://launchpad.net/bugs/711341
[16:31] <bjf> tgardner, i am putting "kernel-cve-tracker" on all my cve bugs
[16:31]  * JFo adds that to the ignore list
[16:32] <tgardner> bjf, so much shit to remember, so little ability
[16:32] <bjf> JFo, i think i mentioned it the other day but can't remember now
[16:32]  * JFo checks
[16:32] <bjf> tgardner, i think i put it on the wiki page, will verify
[16:33] <bjf> tgardner, yup, it's there, 3rd bullet under #2
[16:33] <JFo> bjf, I don't see it, but I am adding it now
[16:33] <bjf> JFo, ack
[16:34] <bjf> tgardner, also part of 3. Create an LP bug
[16:34] <tgardner> are we both looking at https://wiki.ubuntu.com/Kernel/Dev/FixingCVEs ?
[16:35] <bjf> tgardner, yup
[16:35] <JFo> k, fixed and pushed. Let me know of any other tags you want ignored as you remember them :)
[16:36] <bjf> there is a section above where you added your ARM branch text "3. Create an LP bug"
[16:36] <bjf> tgardner, ^
[16:37] <tgardner> bjf, sconklin: I'm rev'ing the ARM kernels beginning with Lucid. where is the wiki page that shows all of the flavours and notes for maintenance?
[16:37] <sconklin> stand by while I find it
[16:37]  * tgardner did a lazy search with no results
[16:40] <JFo> doing another script run now, let me know if you see any other glaring fails
[17:01] <bjf> JFo, can you approve my nominations for bug #712609 ?
[17:01] <ubot2> Launchpad bug 712609 in linux "CVE-2010-4248" [Undecided,New] https://launchpad.net/bugs/712609
[17:01] <JFo> yessir
[17:02] <JFo> bjf, done
[17:03] <bjf> JFo, thanks
[17:03] <JFo> my pleasure
[17:11] <apw> amitk, yep i use mutt, have used it relativly recently on .38 i thought
[17:11]  * apw wonders at the wonders of 3G
[17:14] <amitk> apw: I'm running 'watch -n20 "lsof | grep mutt | wc -l"' to track the number of open files, 884 currently (in ~1hr)
[17:24] <JFo> smb, is bug 445456 still a CVE issue or is it marked incorrectly?
[17:24] <ubot2> Launchpad bug 445456 in linux "kvm hangs booting windows XP Pro SP2 or later, since at least 2.6.28-15" [High,New] https://launchpad.net/bugs/445456
[17:26] <smb> JFo, I don't think that ever was one. But let me quick check the reference
[17:28] <JFo> ok
[17:28] <JFo> has a CVE ref in the description it looks like
[17:28] <smb> JFo, Hmm, its long ago but the refence is not completely unrelated. Leave it as is for the moment
[17:28] <smb> I will need to have a closer look
[17:28] <JFo> ok
[17:28] <JFo> thanks for looking smb :)
[17:29]  * smb decides to not only hate xen
[17:36] <JFo> jjohansen, are you still working on bug 326849?
[17:36] <ubot2> Launchpad bug 326849 in linux "KVM Kernel bugs in intrepid guests under jaunty host" [Low,New] https://launchpad.net/bugs/326849
[17:36] <JFo> it looks stale/old
[17:37] <smb> At least both would be unsupported by now...
[17:37] <JFo> my thoughts too :)
[17:37] <jjohansen> JFo: I think I let that one fall off when it went unsupported
[17:38] <JFo> k, I'll close as out of support
[17:38] <JFo> thanks for looking jjohansen :)
[17:39] <jjohansen> hrmm no, no I let that one go when we couldn't get the extra info and kirland moved to invalid
[17:39] <jjohansen> so even before it was out of support
[17:39] <JFo> yeah, closed WONTFIX
[17:39] <JFo> :)
[17:55] <amitk> apw: can you tell me the output of 'ls -1 /proc/<pid>/fd | wc -l' where <pid> is the pid for mutt on natty
[17:58] <JFo> amitk, I am running your command (for the last while since you posted it) and I only see 33 max
[17:58] <JFo> but that is on Maverick
[17:58] <JFo> are you looking from Natty?
[17:58] <JFo> perhaps I missed that
[17:59] <amitk> JFo: Natty, yes. I've got 1024 open
[17:59] <JFo> hmm
[18:00]  * JFo kicks his natty box on
[18:00] <JFo> give me a bit to test some
[18:00] <amitk> JFo: thanks!
[18:00] <JFo> and I'll let you know what I see
[18:00] <JFo> amitk, my pleasure
[18:00] <jjohansen> amitk: 3
[18:01] <jjohansen> amitk: of course mutt is also spitting back an error message so that may be of no help
[18:01] <amitk> jjohansen: what error message?
[18:02] <jjohansen> no such file or directory
[18:02] <jjohansen> amitk: are you using maildir
[18:03] <amitk> jjohansen: I am
[18:03] <jjohansen> hrmmm so a bug in mutts maildir handling for you
[18:03] <jjohansen> is 1024 your max fd for a process?
[18:04] <amitk> jjohansen: strace'ing mutt is showing several messages like : "open("/home/amit/Mail/Canonical/ubuntu.kernel-team/new", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 EMFILE (Too many open files)"
[18:04] <amitk> jjohansen: I didn't change anythning explicitly, haven't checked the default yet
[18:04] <jjohansen> amitk: yep, its hit the per process limit
[18:04] <amitk> so much for switching to natty toda
[18:04] <amitk> y
[18:05] <JFo> :-/
[18:06] <jjohansen> amitk: you can always up the limit with ulimit but there is definitely a bug if its got 1024 open
[18:09] <jjohansen> amitk: I check what my default limits are for maverick and natty and they are the same
[18:10] <jjohansen> cat /proc/<pid>/limits
[18:14] <cking> amitk, looks like the mutt developer does not subscribe to as many mailing lists as you do.
[18:17] <jjohansen> my bet is he doesn't subscribe to lkml
[18:17] <jjohansen> and neither do the thunderbird or evo developers
[18:17] <amitk> cking: :) I don't download my lkml email. I use gmail to search thru lkml
[18:18] <JFo> same here
[18:19] <JFo> painful even then
[18:22] <amitk> jjohansen: seems like a mutt bug for sure, or something funky in my setup. http://paste.ubuntu.com/562128/
[18:22] <jjohansen> yeah I would say a mutt bug too
[18:42] <JFo> <- lunch
[19:03]  * tgardner --> lunch
[19:42] <tgardner> JFo, why are some of these old bugs getting stroked? bug #185025 has its importance changed, but its been fix released for over 3 years.
[19:42] <ubot2> Launchpad bug 185025 in linux-source-2.6.15 "Coolermaster Xcraft 360 USB drive fails" [Low,Fix released] https://launchpad.net/bugs/185025
[19:46] <JFo> tgardner, that isn't me
[19:47] <JFo> nor any of the scripts
[19:47] <JFo> I use
[19:47] <tgardner> JFo, k
[19:47]  * JFo inquires elsewhere
[19:48] <tgardner> sconklin-afk, bjf - how do you guys initiate a pocket copy from the c-k-t PPA? Subscribe the SRU team, or just annoy pitti on IRC?
[19:50] <bjf> annoy pitti
[19:50] <bjf> tgardner, ^
[19:58] <JFo> tgardner, per the LP guys, apparently there was a change to how they calculate that from upstreams
[19:58] <JFo> so that was expected
[19:59] <tgardner> JFo, hmm, seems like useless churning.
[20:00] <JFo> I agree, but apparently it is an attempt to do the right thing(tm)
[20:01] <JFo> :)
[20:16]  * JFo steps away to wrangle with his Natty machine
[20:16] <JFo> brb
[20:16] <tgardner> kees, are USN noticed automatically generated? In looking at the Dapper USN I noticed that not all of the CVEs in the changelog were reflected in the USN.
[20:16] <tgardner> notices*
[20:18] <kees> tgardner: they are manually generated because the changelogs are misleading. :)
[20:18] <kees> tgardner: the 3 CVE mentioned in dapper were already fixed in a prior release.
[20:18] <kees> tgardner: but those fixes were reverted in favor of the identical upstream fixes.
[20:19] <kees> i.e.:
[20:19] <kees>   * Revert "SAUCE: AF_ECONET prevent kernel stack overflow"
[20:19] <kees> vs
[20:19] <tgardner> kees, ok, looks like you're right.
[20:19] <kees>   * econet: fix CVE-2010-3848
[20:19] <kees>     - CVE-2010-3848
[20:19] <ubot2> kees: Stack-based buffer overflow in the econet_sendmsg function in net/econet/af_econet.c in the Linux kernel before 2.6.36.2, when an econet address is configured, allows local users to gain privileges by providing a large number of iovec structures. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3848)
[20:19] <ubot2> kees: Stack-based buffer overflow in the econet_sendmsg function in net/econet/af_econet.c in the Linux kernel before 2.6.36.2, when an econet address is configured, allows local users to gain privileges by providing a large number of iovec structures. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3848)
[20:20]  * kees nods
[20:20] <kees> argh ubot2
[20:21] <tgardner> kees, how do you want to handle linux-mvl-dove which I just uploaded to the c-k-t PPA. Do you need a USN for them since they contain some CVE patches ?
[20:24] <kees> tgardner: yup, if it goes into -security in main, it needs a USN. we can treat linux-mvl-dove just like all the others.
[20:25] <kees> i.e. once the archive admin copies it to -security, we'll generate and send the USN for it.
[20:25] <kees> tgardner: do you want me to add mvl-dove to the CVE tracker?
[20:25] <kees> or is this an uncommon situation?
[20:25] <tgardner> kees, ok, I'll try to remember to annoy you when it gets pocket copied. Is there an automatic way for you to get notified?
[20:26] <kees> tgardner: not yet, but after talking with pitti, he'll ping us when it happens.
[20:26] <tgardner> kees, yeah, you should add mvl-dovve to the mix as we're on the hook for security, etc.
[20:28] <kees> karmic, lucid, maverick?
[20:29] <tgardner> kees, I'll forward davidm's email regarding which ARM branches for which release.
[20:29] <kees> https://wiki.ubuntu.com/Kernel/Dev/ABIPackages <- they're here
[20:29] <kees> I just need to know which to remove the "**" from. :)
[20:31] <tgardner> kees, well, remove '**' from Maverick mvl-dove. I'm still figuring out where we are on fsl-imx51.
[20:32] <kees> okay, but leave it for karmic and lucid mvl-dove?
[20:33] <tgardner> kees, I'm not sure I'm gonna bother with Karmic. Its so close to EOL. Leave Lucid mvl-dove as abandoned for now.
[20:35] <kees> tgardner: works for me; thanks.
[20:36] <tgardner> kees, I'll let you know if I make any more changes. I'll likely hold off on uploading ti-omap until we've exhausted the CVE tracker list.
[20:36] <kees> cool
[20:48] <JFo> grrrrrr
[20:49]  * JFo goes to slap around his natty machine
[20:49] <JFo> this is really beginning to piss me off
[20:49] <JFo> amitk, I know you and jjohansen already pretty much figured the problem out
[20:49] <JFo> just wanted to add
[20:50] <JFo> Natty is making me want to get the hammer ahold of this laptop
[20:50] <JFo> in a purely Hulk Smash sort of way
[20:50] <jjohansen> JFo: download the maverick mutt .deb and manually install it
[20:50] <JFo> k
[20:51] <JFo> doing updates just now (which is likely a bad idea)
[20:52]  * jjohansen -> lunch
[20:56] <amitk> JFo: same problems with mutt on natty?
[20:57] <amitk> or just hate it in general? ;)
[20:57] <JFo> both, but in general just now :)
[20:57] <JFo> there used to be a really nice "choose desktop environment" selector, that is gone
[20:58] <JFo> and for some reason ,the wireless (that worked so well during install) won't stay connected
[20:58] <JFo> I very nearly threw this thing across the room a few minutes ago
[20:58] <JFo> :)
[20:58] <JFo> very trying
[20:59] <amitk> JFo: you can choose the Desktop in gdm _after_ you click on your userid
[21:00] <bjf> JFo, bug #712723, bug #712737, bug #712744, bug #712749  (accept nominations please :-))
[21:00] <ubot2> Launchpad bug 712723 in linux "CVE-2010-4080" [Undecided,New] https://launchpad.net/bugs/712723
[21:00] <ubot2> Launchpad bug 712737 in linux "CVE-2010-4081" [Undecided,New] https://launchpad.net/bugs/712737
[21:00] <ubot2> Launchpad bug 712744 in linux "CVE-2010-4082" [Undecided,New] https://launchpad.net/bugs/712744
[21:00] <ubot2> Launchpad bug 712749 in linux "CVE-2010-4083" [Undecided,New] https://launchpad.net/bugs/712749
[21:01] <JFo> bjf, on it :)
[21:02] <JFo> amitk, it used to be simplet than that ;)
[21:02] <JFo> simpler*
[21:15] <JFo> looks like I have them all bjf
[21:15] <bjf> JFo, thanks!
[21:15] <JFo> let me know if I missed any, or if there are more :)
[21:15] <JFo> my pleasure
[21:53] <bhanu> not find the linux kernel debug images for makerich
[21:53] <bhanu> not find the linux kernel debug images for makerick
[21:53] <bhanu> I cannot find it in any repositories
[21:53] <bhanu> Am I missing something
[22:01] <JFo> bjf, we have a bug in the new script somewhere (likely something I introduced)
[22:01] <JFo> It only tries to process 2 bugs
[22:02] <bjf> JFo, point me at it
[22:02] <JFo> it is the new-process-new script
[22:02] <bjf> JFo, ack
[22:03] <JFo> looks like it has been there for a while as I have been going through the list of bugs that it has been skipping and the overall number of bugs processed gradually dropped until there are only the 2 left
[22:03] <JFo> :-)
[22:13] <bjf> JFo, ok, so, here's "the plan", I'm currently finishing up 4 CVEs, as soon as I get them done I will work on the script and nothing else (within reason) until we get it fixed
[22:14] <bjf> JFo, I may be able to start on it this evening but by tomorrow a.m. at the latest
[22:16] <JFo> dude, no sweat
[22:17] <JFo> I am in no rush. I am just glad that we can identify now where the possible problem is
[22:17] <JFo> I'm going to keep looking at it, but some is still greek to me :)
[22:19] <bjf> JFo, are you running it on cranberry ?
[22:20] <bhanu> how do I install debug kernel on ubuntu
[22:20] <JFo> bjf, not right now. I am running it on my local machine
[22:21] <JFo> been trying to nail down some oddities while I am trying to document the run steps.
[22:21] <JFo> this was the main one
[22:21] <bjf> JFo, try it on cranberry, i have an account there now so it would give us a common environment to work in
[22:21] <JFo> ok
[22:22] <JFo> will do
[22:26] <JFo> hmmm, can't get a bzr branch there
[22:26]  * JFo tries something
[22:28] <bjf> bhanu, i've not tried before, and i'm looking for wiki documentation but not finding any
[22:30] <bjf> bhanu, maybe if you said what the problem is that you are having someone would be able to point you at a different solution than a debug kernel