[01:06] Hi everybody, I need some help. I have installed several kernels (because of updates and so) and whenever I try to load Ubuntu with those kernels, I always get te screen as if I had pressed Ctrl+Alt+F1, so I can see all the outputs of the instructions being executed until I see some kind of error saying: nohup: ignoring input and appending output to `nohup.out'. After that, my laptop just seems like if it was in standby [01:08] and I can never use the recent kernels. I always got to enter with the 2.6.25 kernel [01:09] that sounds like the X server isn't starting, could be drivers or user configuration or just plain broken stuff [01:09] if you're using an X driver that's had UMS removed and you're disabling KMS on the kernel commandline that can happen too [01:12] ohsix, as I don't think it can be something about my configuration, because I can use this other 2.6.25 kernel, don't you think? [01:13] about this UMS thing removed and disabling KMS, I don't really know what you are tlaking about =/ [01:13] video driver features change between kernel versions [01:19] Look, here's the thing. Since I wanted to install Ubuntu by first time. My display gone black. I tried several times to install Ubuntu, until I found that the DVD was working, but my display wasn't. I used an external display, installed Ubuntu, and installed the nVidia private drivers. That way I could enter Ubuntu in my own display. I could never use the nouveau drivers, and yesterday I was told about how to make nouveau work on my laptop. Th [01:19] ere is a guide I'm following, and I need this 2.6.38rc8 kernel. I have already installed it. But I couldnt enter with thtat kernel. BUT because I was having some problems with my nVidia drivers, I decided to open a virtual TTY (Ctrl+Alt+F2) and reinstalled my nVidia drivers. I just reboot and I could finally enter with this new kernel! What I want to really know, is what is this happening? [01:20] why is this happening* [01:22] nouveau should be blacklisted if it doesn't work on your device, then plain vesa would be used and you still get a display; if you install the nvidia drivers manually it's all up in the air, you should use the packaged version or (assuming it actually boots without the nvidia stuff around on a clean install) jockey, which will offer to do it for you on first boot [01:23] Actually nouveau WAS blacklisted [01:23] then vesa should have at least given you something :\ [01:24] do you have an /etc/X11/xorg.conf? [01:24] yeah, but I assume it will have information about nVidia [01:25] if so, paste its contents to paste.ubuntu.org, or try and summarize its contents [01:25] by the way, what did you mean with jockey? [01:25] right, afaik; most of the automatic magic (including picking vesa as the lowest common denominator) depends on certain sections not being defined in xorg.conf [01:26] http://paste.pocoo.org/show/357486/ [01:26] the "Additional Drivers" applet in system -> administration, it's name is jockey, and if there are drivers available from a 3rd party for a device, it will show up in your notification area telling you about it on first boot with something like "Additional drivers for your hardware are available" [01:27] oh, I get it.. yes, I was told there was a privative driver from nVidia, I also tried that one, but didn't work [01:27] ok, that config would constrain that busid to only that driver, so nv, nouveau or vesa wouldn't work automatically with it present [01:28] ok, let me see if Im getting this... [01:29] when I install a new Kernel, it expects to use vesa, nouveau or nv, and since I have my xorg.conf with nvidia, it fails? [01:30] the kernel doesn't expect anything, but since yuo're not using the distro packages for the nvidia drivers it isn't rebuilt automatically for new kernels, so when you switch the kernel side of the nvidia driver isn't present [01:30] you could uninstall the nvidia blob, rm the xorg.conf, install the distro package and it should work for kernel version changes [01:32] sorry, english is not my native language, what you mean with "install the distro package" ? Which package? [01:33] Actually that's what I wanted. Install the nouveau driver and make it work. That's why I need this kernel. I just wanted to know why this happened [01:33] one moment [01:33] you alaready told me the answer, hehe [01:33] you shouldn't have to install nouveau; if it can work it will work with no xorg.conf present iirc [01:35] What will work with no xorg.conf? The kernels? [01:35] picking the appropriate driver automatically, so X starts with at least one of them [01:36] ohh [01:37] but I assume it won't use the nvidia one..right? [01:37] and nouveau is blacklisted, so it will use vesa [01:38] it could, i don't know; i don't have an nvidia card in anything with ubuntu on it, if you currently have a working display, just start the "Additional Drivers" applet and tell it to install the nvidia drivers [01:38] even when I have installed manually the drivers from nvidia.com? [01:39] sure, it will just overwrite them [01:39] ok [01:39] I'm gonna try that [01:39] with basically the same driver, but one that is known by the package manager, and will rebuild kernel parts when a new kernel is installed; thus be expected to work [01:40] I will also remove nouveau from the blacklist [01:40] oh.. so this will work when I install new kernel versions? [01:40] not now? [01:40] if the blacklist isn't something you added you should probably leave it alone; the things that come with the distro know what devices it's safe to run them on [01:41] it should rebuild it for all your kernels when you install it; i just meant in the future, when another kernel is installed [01:41] the thing is that nouveua got blacklisted when I installed the nVidia drivers mannually [01:42] i see, then it should probably be removed; but if you use jockey it will be using the nvidia drivers, if you want to try nouveau; you'll need to uninstall the manually installed drivers, the xorg.conf and whatever blacklists it added [01:42] ok [01:43] if I want to try the additional drivers, you told me they will remove the nvidia drvers I installed, but.. should I remove the xorg.conf? [01:43] yes, remove xorg.conf [01:43] ok [01:43] I really appreciate you help [01:44] uhm,.. I got another question [01:45] Why is this nohup message appearing? I realized that when I'm inside Ubuntu, and pressing Ctrl+Alt+F1, it takes mee to the black screen with the messages at the beginning and the last line is the same one [01:46] nohup : ignoring input and appending output to `nohup.out' [01:46] those are messages from the boot scripts, i don't know of any package in particular that uses nohup, so i can't point directly to what it is [01:47] I got confused because that means this error is always in there, even when I could enter in the X server [01:47] nohup just detaches the ran program from the terminal so it isn't killed when the terminal is closed, if you could find the nohup.out file, it'll contain program output messages and you might be able to infer what is doing it [01:47] yeha, I already know that [01:48] the file contains like 1 million (It never finishes loading) [01:48] with the instruction cat /sys/class/backlight/acpi/sony/brigthness [01:49] and saying the file couldn't been founded [01:50] I DO know that has relation with the fact the brightness doesn't work [01:50] ah, i can't say much about that [01:51] ok, thank you anyway, I learned something else today [01:51] thank you very much ohsix [01:51] I'm gonna try few things with the drivers and the kernel [01:51] Hi, folks, I want to install Fjalar(which is under Valgrind) into my Unbuntu 10.10(with glibc version 2.12.x), but the tools only support glibc(2.0~2.10), then I donot know how to solve this? anyone who can provide an help? [01:51] see you === lonewolf is now known as serious__sam === _LibertyZero is now known as LibertyZero [06:10] hey guys when will kernel 2.6.37 with scheduler patch will be available on ubuntu? === lonewolf is now known as serious__sam [07:44] Hi, morning. Can't we do 2 kernel compilation in parallel? It seems to me just one compilation progress and the other freezes until the other one finishes. [07:48] fairuz: sure you can compile 2 kernels in parallel [07:48] jjohansen: it's my PC then [07:49] fairuz: the ubuntu kernel build scripts do take advantage of machine parallelism by default [07:49] ie. fakeroot debian/rules binary-generic will launch make -j N_CPUs [07:50] jjohansen: I'm using a remote cross compilator, maybe it slows things a bit [07:50] so what you are seeing is probably the build scripts already taking advantage of your system resources [07:50] yes [07:52] jjohansen: all kernel sources are in /usr/src? [07:54] fairuz: if you install the kernel-source and linux-headers packages that is where they are placed [07:54] if you get the sources via git then, its where ever you put your git tree [07:58] jjohansen: understood. But yesterday I tried to use a function defined in one of the kernel files (cache-l2x0.c) to be exact, but during compilation it says the function is undefined. What should I do to be able to use the functions? [08:00] I use this command make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -C ../kernel-seb M=$(PWD) modules .... where ../kernel-seb is a clone of a git tree [08:00] Anything special to make it work? [08:00] fairuz: so your building a module, is the function exported? [08:01] jjohansen: Sorry, how should I know if it's exported? [08:03] jjohansen: in the header file, there is no prototype of the functions. So I just do extern thefunction() in my module. [08:03] fairuz: for a symbol to be usable by modules that aren't built into the kernel they must be exported using the EXPORT_SYMBOL or EXPORT_SYMBOL_GPL macros [08:03] extern is not enough [08:05] jjohansen: ok. So in the cache-l2x0.c file, I should see something like EXPORT_SYMBOL thefunction() if the function is exported? [08:05] right, eg. EXPORT_SYMBOL(posix_unblock_lock); [08:06] jjohansen: If that's not the case, is there any way to use the function? Do I need to build the module into the kernel? [08:07] fairuz: you either need to build it into the kernel, patch the kernel to export the function, or find an indirect way to invoke what you want [08:07] Or can I just hack the file and export the function myself, then rebuild the kernel? [08:07] yep [08:07] jjohansen: ok, as I thought. [08:10] jjohansen: hmm.. old kernel source can't be downloaded on launchpad? https://launchpad.net/~tiomap-dev/+archive/trunk/+buildjob/2114099 [08:10] not from ppas [08:10] too much churn, too much disk [08:11] fairuz: if you want the old source use the git tree [08:11] you can checkout arbitrary points after a kernel release [08:12] before the kernel release, rebasing against upstream is used so you may not be able to replicate alpha and beta release kernels [08:12] jjohansen: ok, i have to find the omap4 git tree first :D [08:15] fairuz: https://wiki.ubuntu.com/Kernel/Dev/KernelGitGuide?action=show&redirect=KernelTeam%2FKernelGitGuide [08:15] .35 is maverick? [08:16] fairuz: in the natty tree its the ti-omap4 branch [08:16] jjohansen: ok thanks! [08:16] fairuz: looks to be the same in the maverick tree [08:18] jjohansen: differences between natty and maverick? kernel version? [08:19] fairuz: maverick is 2.6.35 based kernel for a release distro, natty 2.6.38 based kernel for release that is about to go into beta [08:19] jjohansen: ok [08:19] fairuz: with that said the omap4 topic branch may differ more than the rest of the kernel [08:20] it actually may even be based on another kernel version, /me is not sure of its current state [08:21] I know at least one of our arm branches was based on a different kernel version than the rest of the distro [08:22] jjohansen: Right now, I'm using .35 on my board and it works well. I will try to compile and see if it boots well too or not [08:23] fairuz: yeah omap seems to be fairly well supported, TI has been fairly good about pushing patches upstream [08:23] jjohansen: I tried .38, but it's kinda weird. Sometime it boots sometime it not. [08:24] fairuz: well .38 just got released so if you tried before that then you were using an RC which tend to be buggy, /me expects we will get a .38.1 or .38.2 before natty is released, with even more bug fixes [08:25] but if .35 is working for you there is no reason to move to .38 unless there is a specific feature you need that .35 lacks [08:26] jjohansen: in fact there is. Things like Perf tool on ARM is not fully supported in .35 [08:26] jjohansen: since I tried .38 and it's not very stable. I just thought to patch .35 [08:26] at least I know .35 works [08:26] fairuz: ah, then I would try .35 make sure your build is working etc, and then try on .38 [08:28] basically I think you want to stick with a known working kernel but it doesn't hurt to try .38, from time to time to see if its stablized for you [08:28] jjohansen: yes [08:29] jjohansen: I cloned about four .38 tree before coming to that conclusion too :D [08:30] linaro tree, official tree, TI internal tree etc [08:30] fairuz: ah, which board? Panda? /me thought that was supposed to be fairly stable [08:32] jjohansen: yes panda. It's fairly stable but sometimes it does give me some problems (doesn't boot, sometimes giving kernel messages in the serial port etc) [08:33] jjohansen: Maybe it's me who don't do things right. [08:34] fairuz: hrmmm, well maybe but I doubt it, there has been a lot of churn in the kernel [09:50] jjohansen: i cloned maverick tree but I dont found any omap4-ti branch [09:51] jjohansen: I can just build it on master branch? [09:57] fairuz: you need to clone the branch locally too [09:58] jjohansen: oh git clone does not take all the branches> [09:58] ? [09:58] git checkout --track -b ti-omap4 origin/ti-omap4 [09:58] use that in your git tree [09:59] it will create a local ti-omap4 branch that tracks the remote origin ti-omap4 branch [09:59] jjohansen: ok [09:59] if you use git remote show origin, it will list off which branches are remote, or tracked [10:00] oh and when you are building make sure you are in the correct branch [10:00] git branch [10:01] will tell you if you are on the ti-omap4 branch [10:01] jjohansen: ok cool. ty [10:01] and git checkout will let you switch branches [10:01] jjohansen: i'll try to compile now [10:04] jjohansen: for each branch, they can have different tag if I do git tag, or it's the same [10:05] fairuz: err sort of, tags are just names for sha-1 hashes [10:05] jjohansen: do I have to pull tags for ti-omap4 branch? [10:06] fairuz: no [10:06] jjohansen: ok === ogra is now known as Guest67326 === Guest67326 is now known as ogra_ [10:35] Can I specify the kernel name before compilation so I will not get something like 2.6.35.3-00029-gc0381cb? [10:35] Since I already have the headers for 2.6.35-980-omap4, I would like my newly compiled kernel to have the same name [12:08] Can I specify the kernel name before compilation so I will not get something like 2.6.35.3-00029-gc0381cb? Since I already have the headers for 2.6.35-980-omap4, I would like my newly compiled kernel to have the same name === ogra_ is now known as ogra [12:54] hello people, quick q regarding make-kpkg [12:54] after a couple runs it started appending some kind of serial at the end of the kernel and debs names [12:55] its not the --append-to-version string i added, (it adds it too before the serial) [12:55] i end up with some rather cumbersome naming for the kernel and packages, how can i disable it or find some info about it? === ericm_ is now known as ericm [13:15] guampa: Are you searching to rename the Kernel name? me too =( [13:16] asking now in #debian, wish me luck! [13:16] guampa: if you have some answers, care to share it here :D === chuck_ is now known as zul [13:22] no luck :( [13:22] my uname -r and debs are all 2.6.38-customstring-06603-g10effcb [13:23] i cleaned, cleaned with debian/rules, even re-branched [13:24] guampa: same here :( [13:24] guampa: Btw, I'm recompiling my kernel [13:24] yeah i'm about to fire it again [13:25] had working my ati with kms and all and now it started to stuck at initialization, so i'm in the quest too on what was that i touched [13:44] guampa: I'm trying to hard coded the KERNELRELEASE to the Makefile. We will see what happens :D [13:46] lol, i'm trying something that if works, i'll smashing my head repeatedly with a frying pan [13:46] i wasnt running "make-kpḱg clean" after each new "make xconfig" (!) === Theravadan is now known as Theravadan|afk [14:22] * ogasawara back in 20min === smb` is now known as smb === jjohansen is now known as jj-afk [14:33] back on later [14:34] * smb takes over [14:35] smb: glad to see you made it, make that later + 1 hour :) [14:36] smb, any idea if we plan to add this for natty? http://www.phoronix.com/scan.php?page=news_item&px=OTA5MA [14:36] tgardner is off today or I would pester him :-) [14:36] JFo, Let me see what the heck it is. :) [14:36] k :) [14:36] ralink open wifi driver [14:38] JFo, I usually forget about schedule, but given that we are about a month away from release I would suspect we are either over or shortly before feature freeze. I'd suspect rather over [14:39] I thought that [14:39] So I would not hold my breath to have it in the release and kernel package. Depedning how it goes it could be something that is in the lbm [14:39] smb, JFo: FF is thursday [14:39] * jj-afk really goes now [14:39] ah, thanks jj-afk [14:40] smb, no, I suspect not if it isn't on our radar [14:40] err, no its not thursday, beta freeze is, FF is way passed, that was like 3 weeks ago [14:40] jj-afk, really has not gone then [14:40] apparently not :-P [14:40] but thanks anyway [14:41] * jj-afk smacked head walking away [14:41] That would be what I expeckt [14:41] same here [14:41] I thought we were past it, but my brain is foggy [14:41] JFo, same here [14:41] thanks smb and jj-afk [14:41] So I don't think this is specifically on our rader [14:41] I believe there have been rumors of them maybe doing something [14:42] ok [14:42] If there is anything in upstream for 2.6.39, then we just will get it as compat-wireless in lbm [14:43] that makes sense [14:45] * smb is amazed how much mail one can get in between yesterday evening and today... [14:45] oh yeah, my mail from the weekend and yesterday was crazy [14:47] pgraner: are you a moderator for the kernel-team mailing list? [14:47] Luckily its a lot of duplicates here. [14:48] pgraner: there's some patches Henrik Rydberg sent, but apparently they're being held up since he's not a subscriber to the mailing list [14:48] pgraner: I'd normally hassle tgardner but he's away [14:49] ogasawara, Same with apw but I believe pgraner should be admin too... [14:49] smb: yah, I didn't want to bug apw either :) [14:49] ogasawara, Likely quite hard. He is busily preparing "other things" :) [14:51] ogasawara, yep one sec [14:54] ## [14:54] ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting [14:54] ## agenda: https://wiki.ubuntu.com/KernelTeam/Meeting [14:54] ## === herton is now known as herton_lunch === JanC_ is now known as JanC === chuck_ is now known as zul [15:22] ogasawara, Knowing your speed, do you want (or are already) to apply the patches I just acked, or should I do it? :) [15:22] smb: I can do it. prolly easier since I've already got em in my trees. [15:24] ogasawara, True enough. Though taking the email an am it is not too badly. But I wanted to avoid being the rabbit discovering the hedgehog is already there. :) Go for it. [15:24] hi all... i am currently trying to isolate an ugly suspend/resume kernel bug and am using git bisect to figure out the problematic commit. unfortunately, git bisect picked a revision for me, which does not compile at all. any advice? [15:26] ah, just found git bisect skip... [15:26] that should hopefully do the trick [15:30] Hi, I just change from .35 kernel to .38 kernel. I tried to compile a personal module that works in .35, but in .38 when I try to insmod the module, it gives Invalid module format error. [15:31] fairuz, Did you re-compile the module against .38? [15:31] yes [15:32] You would need the right (abi) headers as well. Usually dmesg shows a bit more [15:32] like "disagrees about version or so" [15:33] smb: you are correct. Wait i take the output from dmseg [15:34] smb: http://pastebin.com/AiAhUr4a [15:36] smb: I already installed the headers for 2.6.38-1204-omap4 [15:39] fairuz, Hm..I triy to get the difference it complains about... [15:42] fairuz, I am not sure, but one seems to have modversions and one has not... [15:42] smb: it's weird since both is pratically similar [15:43] Could it be you compiled one as part of a complete kernel build [15:43] smb: anyway to check this modversion? [15:45] fairuz, modinfo with the full path to your module (if it is not in /lib/modules) [15:45] fairuz, Is the module you are building a seperate standalone module or did you make it part of the kernel tree [15:45] ? [15:45] smb: standalone [15:48] smb: this is modinfo http://pastebin.com/vXXcc14X [15:48] fairuz, So usually if you install the kernel headers package, you should get a Module.symvers in /usr/src/linux-headers-.... Maybe that is not there for some reason [15:48] smb: wait i check on that [15:49] fairuz, likely when you look at modinfo of any other module it would have modversion in the string... [15:51] smb: I do have Module.symvers in /usr/src/linux-headers-2.6.38-1204-omap4 [15:54] fairuz, Hm, though it sounds to me like for some reason, when you compiled your module, it did not find the other module versions. The compile should issue a warning about that but then goes on without. Just that normal modprobe will refuse to load then. [15:58] fairuz, I would propose to do the compile again and check the output for something like this (or maybe it magically works this time) [16:30] ## [16:30] ## Kernel team meeting in 30 minutes [16:30] ## === herton_lunch is now known as herton === jj-afk is now known as jjohansen === cking__ is now known as cking [17:08] <-food === sforshee is now known as sforshee-lunch === bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Natty Kernel Version: 2.6.38 || Ubuntu Kernel Team Meeting - March-29 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! === sforshee-lunch is now known as sforshee [18:50] gentlemen [18:51] or, gentlepersons... I have licked my wounds and is about to try once more [19:04] jjohansen, kamal hi [19:06] kristian-aalborg: hi [19:06] back for another beating I see :) [19:06] * kristian-aalborg is using the google [19:10] yeah, back for more [19:11] I'm thinking I'm not the first luser to need a few tries [19:23] kristian-aalborg: as I remember it, you did actually get to the point of a successful build and install right? good first step for sure. and yes, I certainly needed a "few" tries before getting the procedure right (or was it a few *hundred*? ;-) [19:24] * bjf -> lunch === bjf is now known as bjf[afk] [19:26] kamal: tbh, I've dabbled with it before... but newer made a working non-vanilla kernel [19:27] I accidently borked an installation once, though... then I could copy files over when they were needed [19:27] it was really, really fast [19:52] sudo update-initramfs -ck module-name-for-new-kernel [19:52] this is worth a try, I think [19:53] kristian-aalborg: yeah, there was a case or two where that wasn't working right [19:53] at least out of the build scripts [19:54] * jjohansen does that all the time with incremental manual builds where I am skipping the whole packaging system [19:55] it's a fairly simple thing to do [19:55] * kristian-aalborg crosses fingers [19:56] no... sends the computer straight to reboot still [19:57] jjohansen: btw, the "sanity check" worked fine [20:01] kristian-aalborg: well I expected it would but its nice to confirm that it did [20:02] yup [20:08] nah, enough for today [20:08] what I did was I did the "make" stuff until it exited, then I did it again with the no modules flags [20:09] I think I'll try turning that flag on before I do anything the next time, but it won't be today [20:09] ;) === bjf[afk] is now known as bjf [20:57] * ogasawara back on in a bit [21:12] hello bug 739774 system clock is halted but process time go on, can it be a linux issue? [21:12] Launchpad bug 739774 in casper "live session from usb key take very long to start (40 min.)" [Undecided,New] https://launchpad.net/bugs/739774 [21:33] that's probably a beginner's question, but where can i exclude a module from being built when building a kernel using make-kpkg? .config seems to be re-generated during each build... [21:33] hello [21:34] I have been having problems with my Ubuntu 10,04 LTS running extreamly slow since my last two updates [21:34] My previous 2 updates were 2.6.32-30-generic and 2.6.32-29-generic both exhibited the same strange slow behaviour, but I have regressed to 2.6.32-28-generic and have had no reduction in performance. [21:34] Specialist, you must change the config files at debian.master/config directory [21:34] I have tried top itop and ps aux to try and isolate the issue, but nothing stands out as eating up[ my cpu or memeory [21:35] Can anyone point me in the right direction to troubleshoot this issue? [21:35] Specialist, in case you're using an ubuntu tree [21:35] herton: I don't have such a directory as I am building a vanilla kernel to isolate the root cause of a bug (using git bisect) [21:36] unfortunately, the vanilla git tree does not build for each commit, so i'd like to exclude the (unrelated) module, which breaks the build [21:38] Specialist, in this case I believe editing .config and running make oldconfig should do it then [21:42] herton: that sounds like it would do the trick (using make-kpkg --config oldconfig), thanks! [21:46] hm, unfortunately, it does not. the config is overwritten again on build (putting back the default) [21:49] Specialist, I haven't used make-kpkg, but from my reading of the man page that doesn't sound like how it should behave [21:49] perhaps another module is selecting the module you're trying to disable ? [21:50] ack, but even make oldconfig selects it... [21:50] sforshee: is there an easy way to find out? [21:51] if another module is selecting it then make oldconfig is going to re-enable it [21:51] what's the module you're trying to disable ? [21:51] it's CONFIG_TI_ST, which is broken in some early 2.6.36 versions (and does not link correctly) [21:52] ERROR: "st_get_plat_device" [drivers/staging/ti-st/st_drv.ko] undefined! [21:53] for CONFIG_TI_ST, probably you have to disable CONFIG_ST_BT also, doing a quick check here [21:53] ST_BT selects TI_ST [21:53] yes, that's what I see as well [21:54] Specialist, in this case you'd want to grep through all files named Kconfig* for a line matching 'select TI_ST' [21:55] herton: thanks, disabling ST_BT did the trick [21:56] I have been having problems with my Ubuntu 10,04 LTS running extreamly slow since my last two kernel updates [21:56] My previous 2 updates were 2.6.32-30-generic and 2.6.32-29-generic both exhibited the same strange slow behaviour, but I have regressed to 2.6.32-28-generic and have had no reduction in performance. [21:56] I have tried top itop and ps aux to try and isolate the issue, but nothing stands out as eating up[ my cpu or memeory [21:56] Can anyone point me in the right direction to troubleshoot this issue? [22:01] DrDetroit: you could try to identify the git commit, which causes the slowdown (not sure how many commits happened from -28 to -29) [22:02] I am not a programmer or anything like that so I am not sure how to do that [22:02] I am just an ordinary user [22:02] I am just stuck [22:02] since it works fine on 28 generic but not on 29 or 30 its hard to think its a hardware issue [22:03] i hate to be stuck on 28 forever [22:03] but i will make sure my grub always keeps the 28 kernel [22:04] i have tried to find the problem in the forums but have had little luck [22:06] How would i identify the git commit? [22:09] DrDetroit, usually you'd do a git bisect, but that could be a little much for a non-developer [22:09] if you feel up to it, there are instructions at https://wiki.ubuntu.com/Kernel/KernelBisection [22:10] otherwise you probably just ought to open a bug in launchpad [22:10] i hate to open a bug [22:10] hehe [22:15] that KernelBisection looks intimidating [22:15] maybe i will go loolk at launchpad [22:15] i have never used it either [22:15] DrDetroit, if you file a bug against the kernel it's best to do it by running 'ubuntu-bug linux' [22:16] that will add a lot of information about your hardware to the bug report automatically [22:16] do i run that locally or when i get to launhpad [22:16] locally, just run it from a terminal on the affected machine [22:16] ah [22:16] I figured that if it were a bug, then i would not be the first to have the problem [22:17] you can search launchpad first to see if anyone else has reported the same thing [22:17] ah [22:18] ubuntu-bug Linux comes back package Linux does not exist [22:18] try lower-case l [22:19] hehe i did [22:19] thank you [22:19] np [22:19] i actually dont know if it is a kernel issue [22:19] DrDetroit: so this is a problem that you can easily tell if it were fixed, right? [22:22] absolutey [22:23] iI have regressed to 2.6.32-28-generic and have had no reduction in performance. [22:23] I hate to run the later kernels to file the report since it runs so slow [22:23] hopefully i can explain the issue in the report [22:24] if the problem exists it will manifest itself usually within 10 min or so [22:24] DrDetroit: ok, file a bug and we can do the bisection for you and give you kernels to test. Please be sure to make a comment in the bug listing the latest known kernel that does not have the problem, and the earliest known one that does. [22:24] will do [22:25] iI have regressed to 2.6.32-28-generic and have had no reduction in performance, both the 29 and 30 kernels exhibit really poor performance [22:25] This is my favorite type of bug - we have a reproducer and a willing tester! [22:25] hehe [22:25] the testiong phase looks prettyintimidating [22:26] guess i have to create a launcpad account first [22:27] nah, we'll just point you to new kernels to test and you answer yes/no whether they have the problem. It might take 5-8 tests, depending on the number of changes between the known good and bad [22:29] DrDetroit: you didn't run perm iotest did you? [22:30] no [22:30] i did run iotop [22:30] i mean itop [22:31] i just thought something was hogging my cpu or memory [22:31] that is usually the issue when machines slow down [22:31] i just cant figure out what it is [22:32] hrmm, I'll look into that, I had report of a performance regression on the weekend when perf io test where run, that I started looking at, the symptom of absolutely painful performance sounds the same [22:32] DrDetroit: in the case on the weekend, the machine was idle but io through put completely died [22:33] not saying it is the same, and I couldn't reproduce but it does sound similar [22:34] sconklin: the report I had came from the upstream kernel, it was in #apparmor user thought it was AA related but we managed to get that turned off and the regression remained [22:35] jjohansen: No proven connection yet, but lucid recently had a pile of scheduler changes go in from upstream stable. I'm looking now to see which version they dropped in [22:36] sconklin: yeah, I'm not sure there was a connection just similar symptoms [22:36] ok does this help? [22:36] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/740549 [22:36] Launchpad bug 740549 in linux "Ubuntu 10.04LTS runs slow after kernel updates" [Undecided,New] [22:37] i hate to have to continue to run an old kernel [22:37] and forgo updates [22:37] DrDetroit: that's great, thanks [22:37] i hope its clear the 28 kernel works but 29 and 30 dont work for me [22:38] yes, got that [22:38] ok cool [22:38] i will hang out here for a day or two just in case you want me to do something [22:38] i am usually available if i know someone wants me [22:39] otherwise i end up going outside to enjoy the sun [22:39] hehe [22:39] its been wacky weird weather here lately, way to nice for march [22:39] you should get email if we update the bug [22:39] oh ok cool [22:39] it's beautiful where I am in North AL [22:39] i have never filed one before [22:39] so i dont know what to expect [22:41] DrDetroit: nothing left for you to do on this today. Thanks for the report! [22:42] ok thank you very much for the help [22:42] is it ok to hang out anyways? [22:42] i might learn something [22:42] also i can load up the 29 or 30 kernels and do the same reports if you need me to [22:43] DrDetroit: yeah, we don't mind people hanging out, feel free to drop in any time [22:43] thanks [22:45] yeah, what he said ;-) [22:48] gah, efika messed up their kernel versions [22:49] jjohansen, DrDetroit - the big scheduler changes went in back at 2.6.32-25, so that's probably not related [22:49] sconklin: hrmm, no [22:50] we'll just have to bisect it, we have a willing victim^W tester [22:50] and DrDetroit, there's no need to submit bug reports for each of the failing kernels. You've already noted the version numbers, which is enough [22:51] sorry, it was my first bug report [22:51] its the only bug i have reported [22:51] only the one report [22:51] DrDetroit: no reporting all the information you can is good [22:52] the only thing i can think of to add is to fire up the other kernels and put the info into the original bug report if possible [22:52]