[00:02] rtg, Ng: done, and pushed [00:03] :) [00:05] Good time to go home ;-) [00:05] * smb_tp leaves === thegodfather is now known as fabbione === dhaval_away is now known as dhaval === asac_ is now known as asac === dhaval is now known as dhaval_away === dhaval_away is now known as dhaval [08:19] cking: Good morning Colin. [08:19] cking: Do you have a minute for me? [08:19] Hi there... [08:19] About Bug #177895... [08:19] Launchpad bug 177895 in linux "Kernel 2.6.24-2 causing ~1000 wakeups by "Rescheduling Interrupts"" [Medium,In progress] https://launchpad.net/bugs/177895 [08:20] First of all: Please discard all my previous patch. [08:20] ..yep.. the on going scheduler issue :-) [08:20] Tonight after a long git-bisect session i think to have found a fix for it. [08:20] * abogani already have drank two coffe... :-) [08:20] It isn't a very fix because it isn't remove the problem completely. Anyway it reduce the wrong behaviour a lot. To achieve the same behaviour of .25-rc8 are necessary 8 commits at least. These commits change heavily scheduler (a lot of LOC are touched). IMHO It isn't a viable way. [08:21] ... OK .. there definitely is a fix upstream but it's very entangled in a series of patches ... [08:21] For this reason this night i have tested every commits to found the most adeguate commit (with a reduced number of changes). I'm sure that you are happy to know that the best one is an one-line patch! :-) [08:21] .. a one liner? ! [08:21] This mitigate a lot the problem on my laptop. Unfortunately i have only one pc (my laptop) so i can't do exhaustive tests! Could you check if that fix works on you pc also? [08:21] I would love to test this one.. [08:22] .. in 64 bit and 32 bit x86 tests too! [08:22] I'm sure that BenC don't accept it for Hardy release! ;) [08:23] cking: How many pc have you? [08:23] ...we will have to see... no promises on how it gets into the hardy release.. [08:23] I have 2 pc's, but I can run amd64 and 32 bit - with a duo core. [08:24] The good news is that I can exercise the core in such a way to manifest this bug [08:24] ..with a combination of amarok and other "interesting" apps :-) [08:25] :-) [08:25] cking: Ok! The commit is 33b0c4217dcd67b788318c3192a2912b530e4eef (Ingo Molnar)! Good test! Please let me know i hope that this night was good spent and thanks a lot! :-) [08:26] abogani: I tested the same bug against linus' kernel tree yesterday and the bug did not occur so intensely. I will test this one out.. [08:27] Good work in tracking this down to one commit. I owe you a beer! [08:29] BenC promised me a Big Mac! Together a beer i have a good meal! :-) [08:32] abogani: I am sure we can do better than a Big Mac.. :) [08:32] :-) [08:33] I will get this built in a couple of hours and try to thrash it over the next day or so to see how it performs. [08:33] Ok. Thank you very much. [08:34] I think I'm the one who owes you the "thank you" [08:36] Hey guys! Is there any way I can see the changelist for a kernel package (the ubuntu-xen kernel variant)? [08:36] * changelog [08:41] ph8: First open changelog file with less /usr/share/doc/linux-image-2.6.22-14-xen/changelog.Debian.gz (it isn't Xen specific) thus search for xen with /xen [ENTER] [08:43] cheers¬! [08:44] I don't suppose anyone here works on Xen and fancies talking about the error when the whole system freezes when it starts swapping? [08:44] i think it's related to/the actual cause of 'System Crashes on high I/O' [08:44] which is all over the place [08:46] ph8: Sorry i'm don't work with Xen at all so i don't know how works proceed. === doko_ is now known as doko === cjwatson_ is now known as cjwatson [11:57] Hi! Are there any precompiled vmware tools kernel modules for Ubuntu 8.04Beta? Compiling vmware tools modules with the installer always fails. How do I install the tools? === Traxer is now known as Traxer|off === Traxer|off is now known as Traxer === chuck_ is now known as zul [14:03] tjaalton: do you have time to roll the ABI for LRM and apply a patch from doko at http://people.ubuntu.com/~rtg/lrm.diff ? The ABI is -15. [14:03] rtg: 404 [14:03] rtg: sure [14:04] tjaalton: lemme get that path correct [14:04] got it [14:05] tjaalton: the patch? [14:05] rtg: yep [14:05] tjaalton: ok, thanks. I gotta leave for an hour or so. back in a bit. [14:07] cking: I suppose that i have lost a beer! ;) [14:33] abogani: not at all - it was probably the best looking fix that I've seen so far for this problem. [14:34] it's just that when it came to the fine analysis it proved less useful in practice - but it's hard to tell until it's been thrashed out. [14:35] Probably it required the other relative commits. [14:36] rtg: Do you know if the acx driver is actually working for anyone? [14:37] doko: lrm.debdiff> there already is libnvidia-tls.so in /usr/lib, but you want to use the one in /usr/lib/tls in favour of that one? [14:38] tjaalton: yes, please read the debian report in the glibc task [14:44] doko: got it [15:14] rtg: Do you have a minute or are you rather busy? [15:15] smb: what up? [15:16] rtg: I need some help to decide how to proceed with the rt wireless driver [15:17] smb: as in "should I bother?" [15:17] rtg: Not quite. From test and some feedback from upstream (IvD) the driver in the kernel (even in linus) will not fix the problems [15:18] smb: if its not fixed upstream, then what do you expect that we can do? [15:18] rtg: So the way to go would be lbm and the latest version from serial monkey (which is a linux-tree with "enhancements") [15:18] smb: that is my opinion. [15:19] rtg: I had already started with something but this will somehow take longer since the driver requires its own mac80211 (much more advanced than kernel) [15:20] smb: If you're pulling drivers that need new mac80211, it might be an idea to look at the mac80211 port of acx [15:20] smb: yeah, its similar in effort to what I did for iwlwifi in Gutsy (and ported to Hardy) [15:20] rtg: And that mac80211 in turn uses stuff from other wireless base modules that are more ahead than the current kernel as well [15:21] smb: I'm not sure if it would help, but trying to use my acx111 with either the code in lum or the latest non-mac80211 driver from upstream just oopses on me [15:21] mjg59: are you having problems with acx? [15:21] rtg: Yeah, it's not working at all [15:21] mjg59: is that modern hw that I can purchase? [15:21] rtg: I'm testing on x86_64, though [15:22] rtg: Not to the best of my knowledge [15:22] mjg59: I take it the driver is running, but just not working. if I remeber correctly, that is using the kernel mac80211 stack. [15:23] rtg: To me it seems as something, that has to be very carefully ported, since there might be structs that are now different but go unnoticed when using newer headers with some older ones [15:24] rtg: No, it's not using mac80211 [15:24] smb: you have to fully isolate any mac80211'isms from the mainline kernel. the rest of the network stack should be OK. [15:24] rtg: On attempt to connect, the kernel oopses [15:25] rtg: Not only. I already found some stuff needing newer net/wireless [15:25] mjg59: well, at least that is easier to find then a mac80211 state transition problem. [15:26] Hrngh. Oops scrolls off the screen. Let me try that again. [15:27] rtg: There is a wireless-compat project but what they do is to put the whole bunch of wireless infrastructure modules into a moddir that overrides kernel [15:27] smb: given the state of wireless in general, its possible that we will just have lousy support for rt. until I dig ito it myself, I can't really offer an informed opinion. I spent 3 days on the Gutsy iwlwifi stuff. [15:27] rtg: So that is not usable, too [15:28] smb: I'm OK with overriding kernel components (if it works) [15:31] rtg: As long as this woulnd't affect other lbm wireless drivers. The iwlwifi uses unly its own mac80211. What it seems to come to is that maybe it can be put somehow into lbm but I don't see a chance for Hardy (as a milestone). Maybe later [15:32] smb: yeah, it'll likely be later. What I meant by fully isolating the rt mac80211'isms is that you'll have to change the source code so that the public symbols do not clash with existing kernel/lum components. [15:34] rtg: Sure, I already spent some time on that and got to the point rt2x00 and mac20811 compiled but still had unresolved symbols from yet another module [15:34] smb: a lot of unresolved symbols? You may be fairly close already. [15:37] rtg: some from the wireless core, so maybe making a private version of that as well. Well. maybe I am not that far away. It just after spending 3 days on it and a bit on the prospect of being close to release that makes me feel worried [15:38] smb: LBM isn't important for release. we can update it pretty much anytime. [15:40] is LBM meant to be a staging area for proposed updates to LUM? [15:40] tjaalton: not really. Its for backports and elective installs. [15:41] tjaalton: some of the stuff that goes into it can be pretty ugly. [15:41] tjaalton: its also less restrictive in terms of SRU policy. [15:41] tjaalton: by the way, thanks for uploading LRM. [15:41] the metapackage naming is different from the rest (no "l-b-m-generic" for instance) [15:42] rtg: ok.. [15:42] and np [15:42] rtg: Right. Well it might be just too much worries. Its first release for me and i don't want to spend too much time on something that i probably shouldn't.. :-/ [15:43] smb: there are lots of folks using rt based adapters, so if you can get it working, then its worthwhile. [15:44] smb: really, wireless support is probably one of Linux weakest areas. [15:44] smb: its rapidly improving, but still needs work. [15:44] rtg: Including bluetooth [15:46] rtg: I agree and from the number of responses to the test kernel there are quite a few users to rt2x00 [15:46] rtg: So I just try to get that working [15:46] smb: its worth another day or two. [15:47] rtg: Ok. And thanks. [15:55] tjaalton: I'm curious about your comment regarding linux-meta and lbm. Is it because there is a linux-backports-modules-hardy meta package? I did that in order to break the distribution upgrade path. LBM should not be automatically upgraded. [15:57] rtg: yeah, I figured there was a reason for it ;) [16:12] will the gutsy kernel continue to receive updates for the 2.6.24.y -stable kernel series, or should I send patches to kernel-team ? === smb_ is now known as smb [16:15] mkrufky: only updates that satisfy SRU policy, e.g., oops fixes, CVEs, etc. [16:15] this patch fixes an old bugzilla, we pushed it into 2.6.25 but didn't realize that 2.6.24.y needed it until now [16:16] i am waiting on one last sign-off before I send it to -stable [16:16] it's a showstopper dvb-s diseqc bug [16:16] mkrufky: sending it to the kernel-team mailing list is good. I'm close to doing a Gutsy update. [16:16] ok, then .... i will send it within the next few days (most likely today) [16:16] i will cc kernel-team when i send it to -stable [16:16] thanks :-) [16:17] mkrufky: thats fine, I'll be at LFS until late next week, so won't get much done. [16:17] no problem.... it's waited this long, another week will kill anybody :-) [16:17] oops, i meant WONT kill anybody [16:18] mkrufky: :) [16:18] mkrufky: I have some NFS and CIFS changes queued as well. [16:18] btw, after last night's hardy updates, HAL is broken on my machine, now .... i know that this is the wrong place to report the issue, and im hoping somebody else will fix it by the time i get home :-) [16:19] but if not, i'll file a bug [16:20] mkrufky: the major change was enabling CGROUPS in all of the non x86 flavours. everything else was quite minor. [16:20] mkrufky: oh wait, you probably don't have that one yet. [16:21] mkrufky: I have not upload -meta (waiting on LRM to finish) [16:23] no idea... all i know is i get an error about HAL crashing, and my nic didnt work... maybe other things broke, too, but i just booted into 2.6.24-12 (rather than -14) and it was all fine again [16:23] and i know not to expect perfection until it's actually released, so im not complaining :-) [16:24] mkrufky: well, this is the right place to discuss those kinds of issues. After release is a bit late :) [16:25] haha [16:25] ok, in that case, I will come back here when im actually in front of that machine so that i can furnish any logs and / or debug info [16:25] should be approx 7 hours from now [16:25] ...or maybe tomorrow [16:26] mkrufky: s'fine [16:27] rtg: is there a way to prevent aptitude from removing old linux-headers-foo packages? i am happy testing all new updates, but i want to retain the ability to boot into older kernels -and- be able to rebuild my kernel modules against it [16:28] mkrufky: each package is NEW with every ABI bump. I wonder why it wants to remove them? [16:29] each kernel package, that is. [16:29] it doesnt remove the kernel packages [16:29] it removes the header packages [16:29] I have linux-headers installed for the last 10 or so ABI bumps. [16:29] id like my system to keep every release of the headers packages, since it DOES keep the kernel images [16:30] hmm perhaps i am missing a setting somewhere [16:30] mkrufky: perhaps autoremove or something like that? I don't use aptitude. [16:31] ah, ok... its definately autoremove. and i am happy for autoremove to do its thing, except for the kernel headers [16:31] ok, then -- i will try some things and hopefully will solve that myself :-) === mkrufky is now known as mkrufky-away === mkrufky-away is now known as mkrufky === mkrufky is now known as mkrufky-away === mkrufky-away is now known as mkrufky [18:59] gar [18:59] this AACRAID bug is still present in hardy :-( [18:59] it's a regression from feisty IIRC [19:00] elmo: did we fix this once? [19:00] I don't believe so [19:01] this is https://bugs.launchpad.net/bugs/149071 [19:01] Launchpad bug 149071 in linux-source-2.6.22 "-server kernel variant fails to boot on PowerEdge 2650 with AACRAID timeouts" [Undecided,Confirmed] [19:01] elmo: ok, lemme read it. [19:01] oh [19:01] I just read it myself [19:01] it says 'upgrade the BIOS, kthx' [19:02] which seems irritating considering the server works (and has worked for years with << gutsy) [19:02] elmo: its worth a try. [19:05] haha [19:06] there's another work around [19:06] ignore it for 30 mins, and it'll fix itself enough to recognise the drive, then exit the initramfs and the boot works [19:06] elmo: seems kind of painful :) [19:07] rtg: considering this was a dapper -> hardy upgrade and the only other kernel I have available is dapper... less painful than the alternative [19:07] since I'm betting dapper kernel i read regarding bug#110585 (dl360/cpqarray&sym53c8xx) to force sym53c8xx to not load was [22:14] sym53c8xx.blacklist=true [22:14] however this gives error and loads anyways [22:14] how is it proper to force unloading? [22:15] t.i.a [22:43] Hey gang, just thought I'd pop in and say hi, also letting you guys know that I got hit with the bug #208247 on a fresh daily of Ubuntu Studio, with nvidia-glx-new for video driver. [22:43] Launchpad bug 208247 in linux-restricted-modules-2.6.24 "nvidia-glx-new crashes when using rt kernel" [Undecided,Incomplete] https://launchpad.net/bugs/208247 [22:44] Commented on that bug report also, so this is just a safety thumbs-up. :) === thegodfather is now known as fabbione