[00:07] <LLStarks> ohsix, is there any way to force compat-wireless to just build in the iwlwifi folder? the flags suck and still force everything else to be built.
[00:39] <LLStarks> ohsix, you can't bisect a folder? can you?
[00:40] <ohsix> yea, you can restrict the bisect to files in a directory, or to a single file
[00:53] <LLStarks> ohsix, can't because of unmarked tree files
[00:53] <LLStarks> *untracked working tree files
[02:36] <psusi> ok, so I have a reproducible bug where the kernel gets stuck in the uninterruptable state.  the output of sysrq-w isn't detailed enough to be very helpful.  any suggestions on where to proceed from here?
[02:41] <psusi> maybe a way to get the full call stack with parameters?
[02:41] <jk-> psusi: sysrq-t ?
[02:41] <jk-> won't have parameters though...
[02:42] <jk-> that should have the same output as W, but include all tasks
[02:42] <psusi> it's in the D state so w identifies and dumps it... t shows the same info just for all processes doesn't it?
[02:42] <psusi> yea
[02:42] <psusi> I don't need the other tasks... just trying to get more details on what the blocked one is doing
[02:43] <jk-> the backtrace should give a decent amount of info, could you pastebin it?
[02:43] <psusi> sure
[02:44] <psusi> http://pastebin.com/6Yc5Ke1D
[02:45] <psusi> all I can figure from that is that dmraid is issuing some kind of ioctl and device-mapper is waiting for something
[02:48] <jk-> psusi: could you file a bug and include this info?
[02:48] <psusi> I'm actually investigating an existing bug #666577
[02:48] <ubot2> Launchpad bug 666577 in dmraid (Ubuntu) "dmraid fails on start with ICH9R under RAID 5 (affects: 2) (heat: 12)" [Undecided,New] https://launchpad.net/bugs/666577
[02:48] <jk-> looks like dmraid is waiting for another thread to finish with the device, or something is refcounting wrongly
[02:48] <psusi> should I file a new one or just add linux to this one?
[02:50] <psusi> I got the original user to attach the raid metadata and I compiled dmraid with the testing option enabled, and set up loop and dm devices to simulate his disks and then tried to activate like he did... got the same results, only I could see that the task was stuck and hit sysrq-w
[02:50] <jk-> try sysrq-t too; that may show a task that holds a refcount to the device
[02:51] <psusi> ok.. let me reproduce it again
[03:00] <psusi> jk-, weird, starts off looking like: http://pastebin.com/wvifq9g9
[03:02] <jk-> psusi: I think you're missing some of the earlier lines of that dmesg output, could you copy from a little earlier in the log?
[03:03] <psusi> jk-, updated with the whole shebang
[03:04] <jk-> same URL?
[03:04] <psusi> yep
[03:04] <psusi> err... wait, no... http://pastebin.com/xYR4bwhx
[03:04] <jk-> looks better :)
[03:05] <jk-> so you're getting errors beforehand?
[03:07] <psusi> nope... dm-9 seems to be the new device it is trying to create
[03:10] <psusi> and it seems to still exist... it's an error target
[03:11] <psusi> hrm... I wonder if udev is doing something to the newly created device that is triggering a race condition
[05:54] <LLStarks> ohsix, i've done.
[05:54] <LLStarks> *done it
[05:54] <LLStarks> i found the commits
[05:54] <ohsix> nice, what was it?
[05:54] <LLStarks> 1402364162afbaac1b8a74ee21aeb013e817ac7d or a6866ac93e6cb68091326e80b4fa4619a5957644
[05:55] <LLStarks> i'm going to do a compat-wireless splice and test them
[05:56] <ohsix> the commit messages look interesting
[05:58] <LLStarks> i'd place my bets on 1402364162afbaac1b8a74ee21aeb013e817ac7d
[06:59] <LLStarks> now for the waiting game. by now, every single dev on lk wireless general has seen my message.
[11:44] <xclaesse> FYI, pcie_ports=compat option at boot fixes the kworker issue I have in natty
[11:44] <xclaesse> I had same issue with maverick but process was kslowd
[11:44] <xclaesse> https://bugs.launchpad.net/bugs/662946
[11:44] <ubot2> Launchpad bug 662946 in linux (Ubuntu Maverick) (and 2 other projects) "linux kernel 2.6.35 slows down the whole system because of kslowdxxx processes (affects: 39) (dups: 2) (heat: 212)" [Medium,Incomplete]
[11:45] <xclaesse> someone should set that bug as affecting natty too
[11:45] <xclaesse> latest working kernel is lucid :(
=== yofel_ is now known as yofel
[15:45] <po4> hi room
[17:39] <apw> tgardner, thats better, now by the fire :)
[17:39] <tgardner> apw, wow, that didn't take long
[17:46] <apw> tgardner, no indeed, the traffic is awsome
[17:48] <apw> quite how i don't know though, it was supposed to be the worse of the year
[17:49] <tgardner> apw, timing is everything
[18:14] <tgardner> apw, pushed 'UBUNTU: [Config] Added autofs4.ko to -virtual flavour' to natty master-next
[18:24] <apw> tgardner, cool thanks
[18:27]  * apw eyes a gin and tonic
[18:28]  * tgardner thinks apw should be _fondling_ a gin and tonic
[18:28] <LLStarks> why is git.kernel.org so slow?
[18:29] <apw> LLStarks, generally or instantaeously ?  there is no obvious load on the machine which serves it
[18:29] <LLStarks> slow for cloning and gitweb
[18:29] <LLStarks> and i have a 30mbit conn
[18:29] <mjg59> LLStarks: Likely because the Android source release was last week and it's hosted on the same servers
[18:30] <LLStarks> GINGERBREAD!!!!!!!!! CURSE YOU!!!!!!!!!!!!1
[18:30] <apw> heheh
[18:30] <LLStarks> "503 - The load average on the server is too high "
[18:30] <apw> LLStarks, heh i miss read the machine name ...
[18:31] <mjg59> apw: master.kernel.org isn't used for general serving, so the load there is probably much lower
[18:31] <apw> mjg59, indeed, should have thoguht of that :)
[18:31] <LLStarks> btw apw, i'm closing in on a fix for the iwl3945 speed issues that were introduced in the maverick cycle between 2.6.35-rc2 and rc3.
[18:32] <LLStarks> well, not a fix, but a specific commit that can be reverted.
[18:32] <apw> LLStarks, nice, what you found?
[18:32] <apw> tgardner, ^^#
[18:32] <LLStarks> down to 4 candidate commits.
[18:32] <apw> nice
[18:32] <apw> i assume you are bisecting
[18:32] <LLStarks> a6866ac93e6cb68091326e80b4fa4619a5957644
[18:32] <LLStarks> yes
[18:32] <LLStarks> 1402364162afbaac1b8a74ee21aeb013e817ac7d
[18:32] <LLStarks> 7d47618a2ade0cb6d8a0b2597029c383c1662fa0
[18:32] <LLStarks> 6db6340c42d027b6364d49fa99d69019aca24de4
[18:33] <LLStarks> i  can only assume a6866 is the culprit since its the largest
[18:33] <LLStarks> or 7d4
[18:34] <LLStarks> rather
[18:35] <LLStarks> i'm trying to narrow further, but i hate kernel compilation. is there an easy way to compile iwlwifi on its own without splicing patches into a compat-wireless tree?
[18:35] <tgardner> apw, saw that earlier this AM on the wireless mailing list
[18:36] <apw> LLStarks, not that i know of, i generally just do full rebuilds every time
[18:37] <LLStarks> can i offload the build to a farm or something?
[18:37] <apw> LLStarks, i have a build machine i use at home for them
[18:41] <LLStarks> hopefully, it be sufficient to pull a 2.6.34 release commit for compat-wireless and then patch upwards towards the bug.
[18:42] <LLStarks> but even then, compat-wireless pisses me off since intel/iwlwifi driver selection builds everything but that directory.
[18:45] <LLStarks> god. android needs its own vcs repo server.
[18:45] <LLStarks> i never see vanilla kernel releases bog down the server this bad.
[19:14] <apw> tgardner, right have gin and tonic in hand ... so am going to call it a day
[19:16] <kees> apw: that's the way to start the holiday :)
[19:43] <Keybuk> apw, kees: that's the way to start the working day too
[19:46] <kees> Keybuk: heheh
[21:32]  * jjohansen lunch
[23:39] <Keybuk> yofel: thanks
=== doko_ is now known as doko