[00:38] jjohansen, arjan: I will now get out of this communication loop. ;) [00:39] hehe thanks [00:39] arjan: I have kicked off a debug kernel build for you, I'll ping you when its done [00:39] all I need is the drivers/acpi/processor-idle.o file === omani2 is now known as omani [00:40] http://www.kerneloops.org/oneweek31.php [00:40] that is currently mostly ubuntu reports (until Fedora 12 ships I suspect.. then it'll be amix) [00:40] looking at the nr 2 issue [00:41] and failing to make sense out of it without knowing exactly which instruction we're executing [00:41] -> hence the request for vmlinux or drivers/acpi/processor-idle.o [00:45] arjan: okay, I just build that then, it will be quicker [00:57] arjan: http://kernel.ubuntu.com/~jj/processor_idle.o [00:58] * arjan grabs [00:58] thanks a lot! [00:59] ooh fun [00:59] this is in a paravirt hook [01:00] anyway that's good food-for-thought [01:00] thanks again [01:00] * arjan will ponder more after dinner ;) [01:19] Is there an irc channel where I can ask a question about the ubuntu/debian kernel build environment? [01:42] eswenson, this is the right channel, but most folks are about gone. can you post an email to the canonical-kernel-team@lists.canonical.com list? [01:44] rtg: I could, but I'm not on the kernel team. I'm just a developer who has a need to update/add modules to a local copy of the kernel. Can I still send email to canonical-kernel-team list? [01:44] eswenson, yep, I'll moderate it later tonight. [01:45] rtg: And my question regards the jaunty kernel, not the karmic kernel. Ok, I'll post the question to the list. THanks. === bjf is now known as bjf-afk [06:42] hello [09:19] On launchpad bugs , should the team be the ones selecting confirmed and priotrity? [09:19] or the team? [09:19] or the user* i mean [10:57] Appiah: confirmed is if other people can reproduce the same bug, so it can be another user [10:57] priority is for the developers (or team managers or such) [10:58] never confirm your own bugs though ;) [11:07] Appiah, yeah what JanC said ... the priority is covered by our 'policy' so data loss is critical, crashes are high or medium etc [11:07] the status implies things about the bug, co [11:08] confirmed for more than one user, trigaged for 'having all the data we need' etc [11:09] does anyone know if there's a difference between the sreadahead and the ureadahead kernel patches? [11:10] and how come the said patches aren't entering mainline? [11:20] hyperair, yes the patches differ. and as it says in the leader to those patches, we are expecting a more sane common and standard way to trace all syscalls via ftrace which would superceed most of the patch [11:21] @_@ [11:21] i see [11:22] you really meant header and not leader, right? [11:22] those words mean the same thing to me for patches ... :) ... the description of the patch [11:23] are you sure "leader" can be used in this context? [11:23] "leader" applies to a person who leads, right? [11:23] It's not upstream because it will need to be rebased onto the syscall [11:23] trace events whenever that gets merged, and is a stop-gap. [11:23] a leader is something or someone who leadsd [11:23] the header arrives in your eyes first, so i can be called a leader [11:23] english is stupid [11:24] you get a similar confusion with rider, a rider can be someone who rides or it can be something which is carried with and is a bout something, like a limitation [11:25] @_@ [11:25] alright, point taken [11:25] hyperair, apparently we have 12 meanings for leader [11:25] * hyperair groans [11:25] 1. a person or thing that leads. [11:25] is the one i was using it in [11:25] ah [11:26] you don't need to remind me that english is massivly ambigious even to native speakers and a nightmare for the rest of the world :/ [11:26] so anyway, what does ureadahead require that the sreadahead patch doesn't provide? [11:26] * hyperair considers himself to be a native speaker of english [11:26] it needs to know which binaries you are running [11:27] ah i see [11:28] well then off i go to hack the ureadahead patch to apply ontop of sreadahead's [11:29] hyperair, why so? [11:29] apw: i compile and run the zen kernels. they have the sreadahead patch applied. [11:29] but not the ureadahead one [11:30] maybe i'll go suggest to them [11:30] well we are expecting to switch out sreadahead for ureadahead at the same time that the kernel updates [11:30] and i assume xen is a patch on top of our main branch [11:30] so they should switch when they rebase [11:31] zen, not xen. [11:31] ... oh yeah ... no idea :) [11:31] heh [11:31] and no, zen isn't a patch.. [11:31] what the heck is zen [11:31] it's a tree [11:31] http://www.zen-kernel.org/ [11:31] it's the mainline with all kinds of unapproved extras applied [11:32] stuff like phc, bfs, tuxonice [11:32] and they frequently pull from mainline [11:32] gotcha [11:33] so you'd want them to have 'both' so you can use that kerenl with ubuntu userspace i assume [11:33] but of course [11:33] sounds like fun for them :) [11:33] heh [11:33] well the ureadahead patch isn't much on top of the sreadahead patch, is it? [11:33] i only had one conflict [11:34] and that conflict was from stuff already added by sreadahead [11:34] i think it produces more data for the existing sreadahead hook iirc [11:34] yeah it does [11:34] dunno how sreadahead would take that change [11:34] isn't it a different ftrace? [11:34] to be honest sreadahead has major issues, like its not aware of hdd ... so it makes things worse there [11:35] agreed [11:35] my boot up time is 2m 30s [11:35] this is ridiculous [11:35] readahead-list was way better [11:35] why did we get rid of that? [11:35] yeah ... it was ... and ureadahead is fixing that and doing better [11:36] was where the majority were going, and probabally was wrong [11:36] yeah, at least we don't need readahead-list wasting time setting up inotify hooks on every single file on the filesystem >_> [11:36] there was quite some noise made re readahead-list's removal, but somebody said that sreadahead's packfile was equivalent if not better <_< [11:37] and conveniently stifled out all the noise by invalidating said bug [11:37] very elegant. [11:40] heh ... sometimes you need to try things, find its wrong, and fix it [11:40] i think thats what happened here [11:42] heh i suppose =\ [11:44] aw damnit it won't compile [12:14] JanC and apw thanks for the explaination [12:18] * hyperair reverted every sreadahead commit on the list and then applied the ureadahead patch [14:31] Hi! [14:31] s'up [14:32] Question: How do I install an older pre-built kernel on Karmic. (Like the kernel used in Jaunty) ??? [14:32] I am trying to troubleshoot a failing wireless adapter [14:32] older kernels are available in the launchpad librarian, i blieve all of them are there [14:33] Do I get to that from synaptic? Or can you give me a URL? [14:33] you can get to the current ones at least here: https://edge.launchpad.net/ubuntu/+source/linux [14:34] Thanks! [14:34] this link looks to show you _all_ kernels ever: https://edge.launchpad.net/ubuntu/+source/linux/+publishinghistory [14:36] I have a Linksys USB wireless adapter that won't connect now that I installed Karmic. It worked fine with Jaunty. I'm going to try the Jaunty kernel with my karmic installation. Does that sound like a good approach to diagnosing this? [14:36] michLinuxGuy, yep ... what device is it inside? [14:37] ID 13b1:000d Linksys WUSB54G Wireless Adapter [14:38] I tried the adapter on another machine with karmic and it did work, but dropped and reconnected once. [14:38] odd [14:39] Yeah. This was with a clean install. I could try reinstalling, but I think I will try the older kernel first. [14:40] The problem machine is an older HP laptop: ze4210 [14:44] apw: Are the links you showed me source only? Is it possible to get a prebuilt .deb file with the kernel and modules? [14:46] michLinuxGuy, binary packages appear to be there if you click trhough the build links for an architecture [14:53] I guess I am not as smart as I thought I was. I can't quite find what I need to install an older kernel from binary. :( [14:57] To install a binary kernel, do I just need an image .deb and a .deb containing the kernel modules? === thunderstruck is now known as gnomefreak [15:06] michLinuxGuy, the linux-image contains the whole kernel, if you have any binary drievers you also nead the linux-headers, and the generic headers the _all package which is only built on i386 [15:10] apw: Thanks for all your help. === bjf-afk is now known as bjf [15:19] apw: I installed kernel linux-image-2.6.28-16-generic_2.6.28-16.55_i386.deb and my linksys USB wireless adapter started working again. Do you have advice on what I should do with this information? [15:21] file a bug using ubuntu-bug when you are booted on the karmic broken kernel. include a dmesg from the working kernel [15:21] and clearly mark that dmesg, and clearly indicate the version you found it does work [15:22] apw: Thanks, I'll do that. One note: the symptom is it finds the access pt, but never connects and times out. I didn't see anything informative in the dmesg output about it. [15:24] but having both tells us if the same driver picked up the device and the like [15:24] apw: Okay - will do. Thanks! [16:51] apw: I submitted a bug for the problem [Bug 472953]. Thanks again for your help with this. [16:51] Malone bug 472953 in ubuntu "Linksys WUSB54G won't connect to wireless network with karmic kernel" [Undecided,New] https://launchpad.net/bugs/472953 [18:59] is the Mainline Kernel PPA source web-browseable somewhere like with cgit? === TheMuso` is now known as TheMuso [21:59] tormod, it's just the vanilla kernel, so kernel.org [22:03] cwillu, thanks, right, I guess that's the whole point of the PPA :) but there is some Ubuntu building stuff like a debian dir? [22:05] can't speak to that, sorry :p [22:05] btw there is 2.6.32-rc6 now [22:07] is the daily ppa build exactly like the upstream "snapshot" or is it a pull from linus tree at some time of day? [22:08] I would guess that it's a package for each tagged upstream release [22:09] yes, but plus the daily builds [22:09] sorry, missed that [22:09] * cwillu clams up [22:09] thanks for answering === Hellow_ is now known as Hellow === makx_ is now known as _maks [23:45] <_maks> hey [23:45] <_maks> the gitweb installation on kernel.u.c seems quite old [23:45] <_maks> what's the refspec to clone http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=summary [23:47] <_maks> git clone git://kernel.ubuntu.com/ubuntu/ubuntu-lucid.git # works [23:47] <_maks> would be cool to have that on gitweb ;)