[00:59] Is there a chance to include virtualbox-ose-modules in linux-ubuntu-modules or something similar, so it gets rebuild for new kernels more automatically? [01:07] blueyed: unlikely, tomorrow is feature freeze for hardy. But there are exceptions for legitimate cases... So write email to kernel-team@lists.ubuntu.com explaining what needs to be done and why. Providing a patch that already works with Ubuntu gets bonus points. [01:29] amitk: what should the patch target? linux-ubuntu-modules? Please note, that virtualbox-ose-modules is already around, but needs to be uploaded for new kernels always separately. === asac_ is now known as asac [06:29] anyone have any idea what's causing this error? http://paste.ubuntu-nl.org/55947/ [06:30] (I was referred from the #ubuntu channel to ask on here) [06:31] only modifications I've made were some recent updates from synaptic... which included kernel updates [07:36] rtg: do you have any changes to lrm other than the ones by me and tseliot? [07:58] rtg: ok, I'll prepare the lrm but won't upload until ack'ed [08:25] moin [09:19] hi rtg , do you want to add dmraid45? [09:21] #97655 [09:24] Bug #97655 [09:24] Launchpad bug 97655 in linux-source-2.6.20 "dmraid45 target please" [Wishlist,Won't fix] https://launchpad.net/bugs/97655 [10:16] this vmsplice issue is fixed in the vanilla kerne 2.6.24-2, not in -1, correct? [10:21] right === rikai_ is now known as rikai [11:14] tjaalton: thanks [13:51] tjaalton: I don't have anything for lrm, though I might take a stab at producing a -server version later on. (next week) [13:57] rtg: I'm trying to do that now, if it's ok [13:57] tjaalton: that works for me :) [13:57] its not like I lack for things to do. [14:05] rtg: hehe, ok. it should be easy [14:57] whee, lrm-server built [14:59] fritz and ltmodem have been disabled for some time now, but ltmodem seems to build fine [15:00] tjaalton: I'll be uploading a -8 kernel this morning that fixes the compile issues with sparc/hppa/ia64. [15:01] rtg: you'd have the lrm ready by then? [15:01] +like [15:02] tjaalton: I assumed you were doing a -8 release for lrm, right? [15:02] hi [15:03] rtg: sure, but how much do I have time left?-) [15:03] i have this weird issue with ram.. i have an old pc with me, its a pentium550mhz intel i810 mothermotherboard and it had 128 mb sdram. so recently i thought of upgrading it to 512mb ram. so i bought this 256mb X 2 sticks as my motherboard have only two slots and support upto 512 mb. its all 133 mhz. ie same speed.now the problem is ..when i put this 512 mb ram.. my booting time takes almost 20 minutes.. so i checked it with only 256 mb in the slot.. th [15:03] en it took almost 7-8 mins.. but with my old 128mb ram it usedto take only less than 2 mins...i.e as i increase the ram the system is getting slower [15:03] tjaalton: even if you upload now it ought to DEPWAIT on the arches that have yet to build. [15:04] tjaalton: I guess my point is, I don't think we need to coordinate on when you upload since there is already a -8 kernel in the archive. [15:04] can anyone help me [15:04] rtg: ok, cool. I hope to be ready soon [15:05] natvie: have you run the memtest ? [15:06] * ogra has a really funny bug here ... [15:06] yes.. idi run the mem test.. evrything is fine [15:06] ogra: how amused will I be? [15:06] one more thing.. i have got dual boot.. and 512 is working perfectly with my windows XP [15:07] since the beginning of hardy i noticed that my music playback didnt keep a constant speed (sounding like you play with the reel on a tape) [15:07] i use ubuntu 6.06. as i'm new in linux.. [15:07] i was looking for bugs in mp3 playback and even in rhythmbox .... [15:07] ogra: I think listening to that would make me ill :) [15:07] today i had to stopwatch something ... [15:08] intrestingly that showed me that not my playback but my system constantly seems to change speed [15:08] rtg:i tried 512mb and 128mb seprately on suse9.1, gnu/linux, ubuntu 5.10 etc.. in all the above i did fresh installations.. but in all the above ..i'm having trounle with this ram upgrade [15:08] rtg: btw, now that we have open-vm-tools, aren't the ones in lrm redundant? [15:08] they are not even built [15:09] tjaalton: likely, contact soren. He just updated the lum version. [15:09] (i never noticed that before, but the "wait" cursor rotates according to teh music speed as well) [15:09] ogra: could it be a problem with the codec device and/or driver? [15:10] rtg: wat could possibly be the problem [15:10] rtg, unlikely and i wonder how that should influence my cursor [15:11] its also not constantly there [15:11] tjaalton: No. [15:11] ogra: well, if interrupts were not getting serviced. something like that. arethere any complaints in syslog? [15:11] ogra: is that the same machine that has this oopses and sometimes some clock issues [15:11] only happens at times, very unpredictable but lasts for a while then [15:11] soren: ok, thanks [15:11] smb, nope, other one [15:11] tjaalton: The ones in lrm are the ones you need on the host side. The ones in lum are the ones you can benefit from in the guest. [15:12] ogra: ah. ok. just came to my mind :) [15:13] soren: ok, they haven't been built since feisty though :) [15:13] wat can i do abt he ram [15:13] tjaalton: *shrug* [15:13] rtg, hmm, nothing in syslog it seems [15:14] soren: not to mention that they are old, but maybe I'll just leave them be for the time being :) [15:14] ogra: what kind of platform? [15:15] tjaalton: I forget why they were added to begin with.. I wasn't involved in that stuff back then. [15:15] ogra@ceron:~$ cat /proc/cpuinfo |grep model [15:15] model : 4 [15:15] model name : Intel(R) Pentium(R) 4 CPU 3.00GHz [15:15] model : 4 [15:15] model name : Intel(R) Pentium(R) 4 CPU 3.00GHz [15:15] dual core pentium [15:15] ogra: looks identical to mine. [15:15] Actual dual core or hyperthreading? [15:16] play some internet radio during the next days while working ;) [15:16] soren: hyperthreaded. [15:16] soren: seems that the kernel modules are now in partner repo [15:16] ogra: I play local tunes quite often. The only time I notice drop out is under heavy disk activity. [15:17] hmm, i rarely play local tunes ... [15:17] i'll switch to local for the day tomorrow, so i can see if it shows up there as well [15:19] its really significant sometimes ... like you hold back the tape, lest loose and it rushes past the head quickly it really behaves very analogue :) [15:19] s/lest/let/ [15:20] ogra: see if you can correlate that behavior with other activity, such as wireless or wired network activity, background disk indexing, etc. [15:21] maybe screen updates? [15:23] well, its an ltsp server so it doesnt have or drive any screen [15:24] ogra: so, lots of network activity, then? [15:24] well, not really, i usually only run a single terminal on it ... [15:25] but your audio is coming over the network, right? [15:25] right [15:25] through pulse [15:25] any change that the stream is being affected somewhere else? [15:25] emulating an alsa device in the user session ... [15:25] s/change/chance/ [15:26] well, the line between server and client is a direct connection ... my payload goes over the other networks here in the house [15:27] all ist does is serving one terminal over 100Mbit ... if i do tests i usually run up to ten terminals on that network piece without any saturation issues [15:28] additionally i would expect audio to get choppy rather than changing speed if the net is involved [15:28] ogra: I agree. [15:29] ogra: I also know that if this bugs the shit out of you, you're capable of figuring it out :) [15:29] right [15:29] I don't havbe a quick anser. [15:29] its not overly important and i wasnt after pushing anyone to fix it :) [15:30] as i stated initially ... funny bug :) [15:41] ogra: could you check if frequency scaling is involved? === amitk_ is now known as amitk [15:42] amitk, i did alreaady seems not :/ [15:42] (that was actually the first thing i checked after searching in the audio stack) [15:42] ogra: install latencytop and keep it running it through these apparent slow downs [15:43] but i suspect there is a clocking issue *somewhere* [15:43] cool, thanksi didnt know about that tool [15:43] recently released [15:44] ah, thats why apt doesnt find it :) [15:44] where do i get it ? [15:44] latencytop.org i believe [15:45] uuuh [15:45] does our kernel have the required patch ? [15:45] tjaalton: see http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=983c3899ef3f44ec0e65f23cf6fd8571a8bc4d5b . You'll need to do this for lrm. [15:46] unfortunately, no. But I'm thinking if we should... [15:47] yeah [15:47] t least during development we should [15:47] seems like a helpful monitoring tool [15:48] amitk: its gotta happen today. [15:48] rtg: needed for lrm too? [15:48] rtg: ogra: there is an overhead with tracking anything. [15:49] amitk, i dont mind having some overhead during the development cycle ... you can remove it for the release [15:49] tjaalton: the new dpkg-buildpackage passes options to all build. kernel stuff just won't work unless you unexport LDFLAGS (in particular) [15:50] rtg: would enabling it now and disabling it in some Beta be acceptable? [15:50] amitk: how about ifdef'ing it? ogra can build his own kernels. [15:51] rtg: it is #ifdef'ed. You need to enable CONFIG_LATENCYTOP [15:51] (that doesnt mean he wants to :P ) [15:51] even better, a sysfs entry to enable it dynamically? [15:51] yeah [15:51] that sounds handy [15:52] rtg: gotcha [15:52] amitk: it would be easy enough to peridically produce a CONFIG_LATENCYTOP enabled kernel in a PPA. [15:53] rtg: yup, let me see how current the patch is. I'll get back to you [15:53] amitk: np. we can add it later since its not an active feature (by default) [15:56] How far are we from a new linux-meta? [15:57] soren: as soon as I verify the kernel FTBS are fixed. probaly later this afternoon. [15:58] rtg: When is "afternoon"? I forget your $TZ. [15:59] its 0900 here. so, another 3-4 hours? [15:59] Awesome. === fabbione is now known as thegodfather [16:28] rtg: you already wrapping up -8.14? [16:28] amitk: test building as we speak. [16:28] making damn sure I didn't break ABI [16:29] rtg: so I can commit to git? [16:29] yep, but don't start a new release just yet. [16:29] just in case. [16:29] rtg: this is the latencytop patch [16:29] ok [17:17] rtg: hmm, the new lrm will end up in NEW because of adding -server [17:18] tjaalton: thats OK. almost every kernel does as well. [17:18] ah, ok [17:19] tjaalton: besides, I know the archive admins. [17:19] :) [17:36] rtg: phew, lrm is now uploading [17:37] bombs away... kernel in a bit. I want to make _really_ sure I've solved the dpkg-buildpackage FTBS carnage. [18:02] rtg: do you know this driver: http://www.ralinktech.com.tw/data/drivers/2007_1220_RT2870_Linux_STA_v1.2.1.0.tar.bz2 [18:02] it fails to build with 2.6.24 [18:03] Kano: why am I responsible for that? [18:03] well it is a wlan driver [18:03] and you could add it if you get it compiled [18:03] i am sure there will be more users for that driver === smb is now known as smb_away [18:11] Kano: its likely it'll have to go into the lbm package (if anywhere) [18:11] whats lbm? [18:11] linux-backports-modules [18:12] replacement for lum? [18:12] its in addition to lum [18:12] ah [18:12] whats teh difference [18:12] in the past its how I upgraded ALSA with impacting users who choose _not_ to install lbm [18:12] s/with/without/ [18:13] lbm modules take precedence over lum and kernel. [18:13] e.g., they are first in the depmod search order. [18:13] but is completely empty now? [18:14] it is empty for Hardy. Look at Gutsy for an example. [18:50] Hm. -7 boots *very* slowly on one of my test boxes, until / gets mounted [18:50] Then it seems to speed up [18:50] Caps lock takes ages to respond, so it seems to be somewhere in the kernel [18:54] mjg59: I've noticed that on at least one as well. I'm hoping -8 (without the generic IDE driver) will help. [18:54] mjg59: -8.14 that is. [18:56] Hm. Yeah, generic has ended up binding. [18:56] Wait, no. [18:56] rtg: how about using pata_nv for nvidia? [18:56] amitk, Jay toled me that you guys were having issues with the driver....? [18:56] mjg59: I backed all the IDE changes out: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=351cc10d3c1c2ab09773b24994389d7533c832dd [18:57] inuka_desk: it was an ABI and versioning confusion in the mobile PPA [18:57] should be solved soon [18:57] rtg: Right, if the legacy drivers are enabled they need to be blacklisted by default [18:57] amitk, oh ok just checking... [19:00] Kano: CONFIG_SATA_NV=m in all configs except virtual. === smb_away is now known as smb [19:03] rtg: but i have got hda [19:03] i mean PATA_NV [19:03] the other nv driver disables dma for my dvd drive [19:03] mjg59: rtg: Wouldn't it be nicer to have a way to explicitly enforce an order in which modules are tried: ata_piix -> ide_generic [19:04] pata_amd.c: Nvidia SATA devices are claimed by sata-nv.c [19:04] amitk: There's only really one order that makes sense [19:04] i will compile the kernel without old ide drives but it is really annoying when you try the generic one [19:04] amitk: some thing in itiramfs ? [19:04] s/itiramfs/initramfs/ [19:05] amitk: There's only really one order that makes sense (native,acpi,pci-generic,generic) [19:06] The problem is that there's two different native drivers provided [19:06] Either will work, but libata is basically always preferred [19:06] rtg: yeah... apparently fedora does something like this in the mkinitrd script [19:06] s/the/their [19:06] The sensible thing is just not to include the legacy ones in the initramfs when a libata driver is shipped [19:07] mjg59: but sometimes (admittedly very rarely now) the libata driver doesn't work [19:08] amitk: Right, so in that case we should ship the legacy one and blacklist the libata one :) [19:08] You'll never want both in the initramfs [19:08] Unless one trips bugs on some hardware and the other trips bugs on different hardware, in which case we should probably just trim the PCI IDs [19:09] no good idea when you want to use em with a different config [19:09] Kano: ? [19:10] well when you want to do a kernel without legacy ide drivers [19:10] I still don't understand what you're saying [19:10] which ids do you want to remove? [19:11] Any overlapping IDs when we need to provide both in the initramfs [19:16] then remove the legacy ids [19:19] Well, obviously [19:20] also pata_amd i would prefer (it is not pata_nv) [19:24] amitk: It would probably be helpful to write something to scan through the modules and flag any cases where we have multiple modules supporting the same IDs [19:34] mjg59: sure [19:35] mjg59: thats easy [19:36] just usw awk on modules.pcimap [19:46] amitk: Then we can add appropriate blacklist entries or remove IDs as necessary [19:58] rtg: crap, lrm failed to build on i386, nv-new for -server [19:58] tjaalton: do you want a patch [19:59] or do you want to seek for it alone ;) [19:59] i fixed that weeks ago *g* [19:59] Kano: you have one? [19:59] i reused the fedora one [19:59] accept dcc [20:00] whats up [20:00] url please [20:00] or pastebin [20:00] extracted from source.rpm [20:00] which package? [20:00] http://rpmfind.net/linux/RPM/mandriva/devel/cooker/x86_64/media/non-free/release/dkms-nvidia-current-169.09-1mdv2008.1.x86_64.html [20:01] nvidia-2.6.24-xen.patch [20:01] is what you need [20:01] already included in http://kanotix.com/files/install-nvidia-debian.sh [20:04] tjaalton: i think it was before from fedora, but just seek for the name, very easy to find [20:05] Kano: ok thanks [20:06] that script installs nvidia with a patched standard installer and has that patch also integrated in case of xen found [20:07] Kano: doesn't this line work any more? [20:07] export IGNORE_XEN_PRESENCE=1 [20:07] it works but for 2.6.24 you need an extra patch [20:08] i told you the name, gave you link to rpm with that, even a script with it... [20:08] ok, thanks [20:09] I asked since DKMS + export IGNORE_XEN_PRESENCE=1 works well on Hardy [20:10] it can not be for xen [20:11] that deb has [20:11] err rpm [20:11] PATCH[0]="nvidia-2.6.24-xen.patch" [20:11] PATCH_MATCH[0]="^2.6.2[4-9]" [20:11] do you see that [20:11] in the dkms.conf [20:13] * tseliot nods [20:13] you're right [20:14] It looks like I'll have to modify Envy [20:14] you write envy? [20:14] Yes, I did [20:14] well i wanted to adopt that for my script too [20:15] maybe i add dkms support,seems to be easy [20:15] yes, it's quite easy to do [20:15] only that dkms file [20:16] I did it [20:16] i never use envy ;) [20:16] well, I haven't released EnvyNG yet [20:16] ;) [20:17] my scripts have been out years before envy and work still [20:17] EnvyNG (Next Generation) will use DKMS [20:17] yes, I know :-) [20:17] will change the fglrx script to dkms , thats easy, for nvidia it is a bit tricky [20:17] not that tricky ;) [20:18] well maybe i put it in a package like fglrx [20:18] maybe you can have a look at EnvyNG when it's finished [20:19] that is to say very soon [20:19] maybe, but i prefer "own" solutions *g* [20:19] there's only one solution as regards dkms.conf :-P [20:20] you can reuse the mandrake one too [20:20] I tried but DKMS refused to install the module [20:21] so upload yours [20:22] sure, I would like to include the patch you gave me first [20:22] i can think of the 2 lines [20:22] thats not the problem [20:22] nvidia, 169.09, 2.6.24-7-generic, i686: built [20:22] that worked btw... [20:23] with Mandriva's dkms? [20:23] with Mandriva's dkms.conf ? [20:23] i only changed ver to 169.09 [20:24] really? Then it means that I had tried some older version of the package [20:25] i used the one i gave you [20:25] I remember that the package built but when I tried to install it, DKMS failed [20:25] have you tried to install the packages? [20:27] maybe it needs the makefile for other kernels too [20:28] have you tried the packages yourself? [20:28] the package now [20:28] no [20:28] i only extracted a few things [20:28] ah, ok [20:29] but in theory i could try that too... [20:30] it shouldn't break anything [20:30] if it's only the part with DKMS [20:32] hmm when i copy it completely i get bad exit status 2 [20:32] musst diff it [20:33] -mcmodel=kernel -mno-red-zone [20:34] and removed xenchat [20:38] does this depend on your specific system configuration? [20:40] well i fetched the x86_64 rpm ;) [20:41] you need a 64 bit system [20:41] aah [20:45] well basically only 2 files are different to 32 bit [20:45] Module.symvers + nv-kernel.o [20:47] then it works [20:47] I see [20:54] i just dont understand why [20:54] DEST_MODULE_LOCATION[0]="/kernel/drivers/char/drm" [20:54] this is used [20:54] usually it is in [20:54] kernel/drivers/video/ [20:55] do you get this? [20:57] let me check [20:58] which is stupid [20:58] it should be [20:58] /kernel/drivers/video/nvidia [20:58] as when you uninstall the module an older module will be copied to the new location [20:59] it works well with that [20:59] sure, maybe mandrake specific [21:00] I don't use Mandriva [21:01] therefore, yes it might be mandriva specific [21:03] interestingly fglrx uses the drm location for dkms.conf [21:06] but misc when you use m-a... [21:06] (edgy target) [21:07] dont know what the installer uses [21:08] true, but I don't know why fglrx requires that line... [21:08] i dont think that you require it, maybe you just use it for both [21:11] currently I use a customised dkms.conf for NVIDIA while I leave the ATI installer the burden to build the packages for me [21:15] why is it impossible to use remove before using build? [21:16] dkms remove $(dkms status|awk '/^nvidia/{print "-m "$1" -v "$2}'|sed 's/,//g'|uniq) --all [21:16] that only works after build but not directly after add... [21:17] stupid or not... [21:24] rm -rf /var/lib/dkms/nvidia/ [21:24] maybe thats faster... [21:34] as final cleanup [21:38] dkms remove $(dkms status 2>/dev/null|awk '/^nvidia/{print "-m "$1" -v "$2}'|sed 's/,//g;s/:$//'|uniq) --all 2>/dev/null [21:38] this works... forgot that : [21:44] tseliot: what do you think about creating the dir, adding it, mkdeb --source-only and then just install the deb? [21:45] I don't understand your question [21:46] how do you package it [21:46] I use the packaging scripts of the lrm [21:46] Hi. I am tryiing to compile a Xen kernel using the linux-source package in 7.10. However, simply copying the config file from the linux-xen image and running make oldconfig doesn't seem to work. Any suggestions / instructions on how to build it? [21:46] so that I get 3 packages [21:46] ok [21:46] well to integrate into my script i will first use another way [21:47] sorry but I have no experience whatsoever with Xen kernels (yet) [21:47] Back to what I was saying, I generate 3 packages: [21:48] nvidia-glx{new,legacy}, nvidia-glx{new,legacy}-dev, nvidia-kernel-source [21:48] where nvidia-kernel-source contains the dkms part [21:49] well my script works a bit differnt [21:49] it has a -v option to specify the driver or it chooses automatically the best driver for th card [21:49] so it is more generic [21:50] Envy can do that for me [21:50] so that I can build whatever the user wants [21:50] or whatever autodetection decides [21:51] nv autodetect is really simple... fglrx you need to update everytime [21:51] I keep id lists for both drivers [21:52] i use whitelist for fglrx and blacklist for nv [21:55] I keep the ids in python dictionaries. Each driver flavour has its own dict [21:57] there are always different ways [21:58] yep [21:59] i do not understand python, i use bash [21:59] or better: dash [21:59] as the script is pure posix [22:02] I use Python because it's just too easy to use [22:02] and I can use both GTK and QT4 with it [22:03] and of course I know Python better than bash [22:04] it's a matter of taste [22:08] btw, envy was originally written in bash === smb is now known as smb_away [23:19] re: #183928, is the intention only to carry the Centrino branded and certified version of iwlwifi at the expense of the various improvements in the later versions? [23:20] (particularly talking about Hardy here) [23:20] bug #183928 [23:20] Launchpad bug 183928 in linux-ubuntu-modules-2.6.24 "update iwlwifi to latest version" [Medium,Won't fix] https://launchpad.net/bugs/183928 [23:20] Caesar: for now. its possible that if there are compelling reasons I might do an lbm version. [23:20] rtg: how would you like to be compelled? :-) [23:21] There would have to be a number of failure cases. At any rate, I'm not going to get to it for a few weeks. [23:21] serge: you have failure cases, right? [23:21] Versions like 1.2.23 is being used by Fedora 8 so could be considered well tested === rei_0000 is now known as greeneg_ [23:22] on WPA enterprise roaming from one access point to another we get packet loss, I have bug reports from people saying that their connection drops [23:23] drops out from time to time [23:23] also my logs are full of TKIP decrypt failed for RX [23:23] etc [23:24] I don't think the users look at their logs so have not had any reports [23:24] rtg: can we make this easier for you? Provide a patch? [23:25] sure, but do it for linux-backports-modules [23:25] Fro Hardy ? [23:25] yep. [23:28] rtg: why backports? [23:28] because its an elective install. lum and the kernel are required. [23:53] rtg: I hope the latest lrm builds on i386, since I need to get some sleep :) [23:53] lpia is the only one that has finished building [23:54]