[02:31] hey guys....im having a problem...i read the first 4 chapters of allesandro rubini driver book and still have no clue how to use what ive learned or how to apply it to my device...is there a simple source in the kernel that i may be able to decipher === cjwatson_ is now known as cjwatson [06:26] hello there, i just wanna downgrade my kernel to 2.6.26* [06:26] so i just have to install linux-image-2.6.26* ?? [06:31] samir_: that should work [06:37] anubhav : plus, that will install 2.6.26 modules for me? that's what i'm interested in [06:40] samir_: yes [06:41] samir_: but i am not sure if .26 is present in the ubuntu repository [06:43] anubhav maybe in packages.ubuntu.com [11:03] NCommander, am looking at the ports issue [11:13] bah all the configs are in the toilet [11:13] TheMuso, you about? [11:39] apw: Given the time, TheMuso is probably dinner-ing [11:40] yeah, i have a handle on the mess now thankfully [11:42] apw: This will be another .30? [11:42] apw: You should also be aware that i386 failed to upload (there's a new state for you) due to version number fun [11:43] is that the linux-doc breakage? [11:43] Yup [11:54] yeah can't fix that until rtg gets in as he has the tree, but we are aware [14:13] rtg the GEM/PAE changes we were testing seem good, and indeed airlied has merged them already. in theory that makes 2.6.31-rc1 capable of KMS on PAE too [14:14] apw: I have a test system. where have you stashed test kernels? your PPA? [14:15] yeah in a ppa .... https://edge.launchpad.net/~apw/+archive/red [14:15] (gah edge is slow today) [14:48] rtg i note that the effect of pulling all the ports kernels back into our kernel has slipped the 386 kernel over to non-ports status [15:19] mdz: if I respun linux-meta and uploaded linux-meta_2.6.30.9.9 (with your linux-doc patch), then the existing linux-doc package would eventually get reaped, right? That should clear up any conflicts in case there is another 2.6.30 kernel upload (which I think we should do) [15:21] rtg: did you see my message to kernel-team@ from yesterday? that's #2 out of the 3 options I suggested for how to fix it. the trouble is that the old linux-doc package wouldn't get reaped right away, and might require manual Launchpad hackery, so Colin was (understandably) not thrilled with that idea [15:23] mdz: why would it need manual intervention? [15:23] rtg: when a source package stops building a binary package, Launchpad doesn't just delete the old one. it hangs around for a grace period [15:24] "didn't get built" has different semantics from "was explicitly removed" [15:24] rtg: this is because it's hard for LP to tell the difference [15:24] "maybe this source package doesn't built that binary package anymore, or maybe it just hasn't built yet" [15:24] s/built/build/ [15:25] mdz: what is the grace period? a couple days? [15:25] rtg: I think it's on the order of days, but I can't say for sure. cprov or bigjools or somebody could tell for sure [15:25] Really? They get automatically deleted eventually? [15:26] I thought they always had to be explicitly removed by an archive admin. [15:30] mdz: how about if I just restore the kernel package naming convention for linux-doc for now, then deal with the new linux-doc package name when we update to 2.6.31 next week? In the meantime, I'll respin linux-meta and let the reaper do its thing. [15:31] rtg: fine with me [15:32] rtg: I just followed up to the list with a suggestion for the upload order [15:32] mdz: cool, I'd really like to get the new i386 pae flavour propagated. [15:41] * Keybuk is having strange behaviour today [15:41] nc -q0 ip port | dd of=/dev/sda bs=1M [15:42] just hangs eventually [15:42] Keybuk: on the network side or the sda side? [15:42] sda side [15:51] seems to be hung deep inside the io scheduler [15:54] apw: care to review ubuntu-karmic-meta.git for me before I upload it? [15:55] * apw looks [15:56] rtg, i see 9.9 at the tip? [15:56] apw: yes [15:57] wow [15:57] it really looks like it screwed the scheduler [15:58] so this is just the meta change for mdz's change [15:59] apw: correct. next week you'll have to bumop the ABI when you do 2.6.31 [16:02] apw: now, back to your comment about 386 becoming a non-ports package. Isn't that a function of the archive admin overrides? [16:02] so the plan is to drop it from meta, but not add it to the kernel yet [16:02] correct [16:02] then when its cleared the archive, add it back into the kernel? with the next abi update [16:02] correct [16:03] sounds reasonable, and appears ok to me [16:03] as for the ports comment i was more referring to the fact it ends up being updated [16:03] config wise with the other x86 flavours [16:03] oh [16:04] as the ports split we end up with is basically by architecture [16:04] we'd need to do a bit more work to make the different [16:04] thought perhaps thats not a negative thing overall [16:05] as there is probabally some benefit to us at least updating the configs for distro and ports at the saem time [16:05] always taking defaults for ports, and reporting them to the ports maintainers [16:05] else they will always fail to build [16:05] with a dirty config, if we don't [16:06] after looking at your 'family' [atch, its not clear that 386 would build at all. there is no '386' flavour. [16:07] hmmm ... so have i lost it or did the ports fixes lose it? [16:08] apw: methinks the ports fixes lost it, [PATCH 1/2] UBUNTU: split out the ports configs into their own family [16:10] hmm but the family changes are just at the top level [16:10] by which i mean the arch level [16:12] there is no config.flavour.386 at all in this origina commit: [16:12] UBUNTU: [Config] ports - Add configuration files for ports architectures [16:12] so i think we never brought it over [16:13] apw: that is the conclusion I was just coming to as well. [16:13] want me to sort that out? [16:14] i suspect it just got forgotten [16:14] inserting a new complete config into the split configs is an interesting game, which i just did for the ports ones [16:15] apw: yeah, go ahead and sort it out. I've just pushed one more commit (reverting the linux-doc patch) [16:18] apw: can you make 386 it's own arch? [16:18] it does appear the kernel arches are not the same as build arches right? [16:19] apw: hmm, I think 386 gets built on an i386 chroot [16:19] will have a play [16:26] rtg what we care about is keeping 386 merging with ports configs [16:26] otherwise its fine? [16:28] apw: I dunno if its fine, but yeah, 386 should be part of the ports family of configs. [16:30] hello! I noticed that there is a linux-image-debug-`uname -r` package on ddebs.ubuntu.com - but it appears to be not part of the Packages.gz file - is that intentional (the deb is pretty big) [16:31] mvo: I believe so. It keeps the mirrors from picking it up. [16:32] ok, thanks [16:32] apw: the original patch set from Luke simply didn't contain a 386 config [16:32] yeah or indeed anything about 386 at all [16:33] apw: ok, I'd say just drop him a note about it and lets move on with other work [16:34] can do that, i feel the 386 ports port is the one that is worth a tiny bit of our attention just cause its an x86. but you are likely sensible there [16:36] i t [16:37] rtg ok one question, if its a flavour of x86 and it gets built on i386, i suspect that will make it part of the common i386 build and therefore that one can have greater dammage to our build process than the other builds [16:37] apw: it could, but I'm gonna let Luke figure it out [16:37] ok [16:43] rtg ok, i've emailed him and copied u-k-t [16:49] apw: so, to test the KMS/PAE combination with your test kernels, I want https://edge.launchpad.net/~apw/+archive/red/+files/linux-image-2.6.30-9-server_2.6.30-9.10kms9_i386.deb, right? [16:49] rtg yeah thats the one that should exhibit it [16:50] i've personally tested some of the other combinations, which still work at least but would never have been affected [16:51] apw: I take it these are upstream cherry-picks? [16:56] rtg, the patches on that kernel, one was direct from lkml from airlied and the other was mine. since the equivalent of both has merged into what will be .31-rc1 [16:56] i think dave got sick of them and just merged them [16:57] apw: well, can we easily cherry-pick from Linus tree, or should we just ignore the PAE problem until 2.6.31 ? [16:58] the only urgency is if we are pushing people to -pae at all during upgrades, if not then there is none [16:59] i saw the whole testing of gem and pae and these two patches as a response to the 'blocker' if we were pushing people to -pae by default. i cannot recall the outcome, or indeed if there was an outcome without this infrmation [16:59] apw: fresh installs will have the problem if > 4GB RAM. Otherwise, upgrades ought to be OK. [16:59] so i think ... they can sensibly fall into the 'will wait for upstream to have them' bucket to my eye [17:00] apw: works for me. I'm gonna package and upload then. [17:00] ok [17:03] that should get us at least an upload with the new flavours me thinks [17:03] thats my goal [17:08] rtg: can I ask a question? [17:09] Keybuk: always [17:09] whether I can answer... [17:09] rtg: I have an image file [17:09] and I'm trying to write it to the disk [17:09] but every time, the kernel hangs inside the I/O scheduler [17:09] is there a simple way to change that so I can use a different I/O scheduler [17:09] (and worry about filing the bug later :p) [17:10] Keybuk: yeah, there is a way to change the I/O scheduler dynamically. just need to remember how. [17:10] rtg: what's a good "just do it" I/O scheduler? [17:10] deadline? [17:13] Keybuk: find /sys|grep sched [17:13] cat /sys/devices/pci0000:00/0000:00:1f.1/host0/target0:0:0/0:0:0:0/block/sda/queue/scheduler [17:13] This is a server install, so the default is deadline. [17:13] ok [17:13] great [17:13] * Keybuk tries that [17:14] Keybuk: try noop also, which is the simplest [17:14] IIRC [17:19] anyone familiar with recent changes to the e1000 driver? It seems that in gutsy (2.6.22-14-generic), the 82573 wouldn't support jumbo frames, but with jaunty (2.6.28-11-generic), it lets you enable jumbo frames, but gets swapper allocation failures under network load [17:22] noptys: perhaps you should email Jesse Brandenburg about that [17:22] can do [17:29] rtg: the deadline scheduler worked [17:29] Keybuk: is Ingo the I/O scheduler dude? [17:32] Keybuk: maybe Jens Axboe (block/cfq-iosched.c) [17:32] ingo is cpu scheduler to my mind [17:33] apw: Jens did the CFQ scheduler [17:34] rtg he is also the maintainer of BLOCK in general, so a good starting point [20:27] Hello! [20:29] So I recently backported the 2.6.30 version of the r8169 driver to 2.6.28 and am wondering how to go about packaging it for e.g. a PPA. The actual "how to put it in a package" details aside, I want to make sure I don't step on anyone's toes. Should I just call it "r8169-backport-driver-2.6.28....*" or similar? [20:30] Am I going about this the wrong way entirely? [20:31] wjblack: is it a DKMS based package? [20:31] Nope. Modified vanilla kernel.org. [20:32] Literally, it's a patch to the 2.6.30 r8169.c that allows it to compile/run on 2.6.28 [20:32] (the 2.6.30 version has a slightly different api but a fix for a rather nasty MSI bug) [20:33] wjblack: the best way to package it so that you don't have to deal with ABI dependencies is to use DKMS [20:34] Hmm. Okie-dokie. Is there an Ubuntuish way to do that, or do I do generic dkms stuff? [20:34] (never used DKMS before, obviously ;-) ) [20:35] wjblack: there is a bit of a learning curve, but its not too bad once you grok things. here are some good example driver packages, e.g., bcmwl. [20:35] s/here/there/ [20:35] Aah, so the bcmwl package that's available via apt-get somewhere uses dkms? Excellent. [20:35] * wjblack learns best by example ;-) [20:36] wjblack: yes, the maintainer is Alberto Milone (tseliot) [20:36] wjblack: in Karmic its called bcmwl-kernel-source [20:37] I'm thinking this particular backport will have an effective lifespan of, er, rather short since >=2.6.30 should be in the main distro at some point... [20:37] Right on. I'll give it a looksee. Thanks! [20:37] wjblack: 2.6.30 is in the Karmic archive right now, 2.6.31-rc1 soonish [20:39] Hmm. Still might be nice to have a PPA for Jaunty. I'll check out this rabbit hole and see if I can handle its depth. ;-) [21:29] Update Manager differentiates 'distriution updates' and 'security updates'. What is the difference? Does every single DE program package have a flag for that? [21:30] s/DE/DEB/ [21:30] <_ruben> not every bugfix relates to security issues [21:32] _ruben: Yes. -- So it depends solely on the maintainer's judgement? [21:39] hey guys im a little confused as to what a module can do other than a device driver(which i cant figure out either)...could somebody explain to me some of the more useful modules [21:43] a module can do pretty much anything [21:43] think of it as a plugin for the kernel [21:50] johanbr: i get that but....i dunno im having trouble understanding what modules do what....like i want to look at specific device drivers(webcam, audio, anything i can find) but i dont know which source does what [21:50] in the module programming guide they said we can write a module that says "Hey that tickles" everytime i delete something....but how would i do that you know what i mean? [21:51] look at the kernel source for sth simple [21:51] ok [21:53] do you know where thats located? [23:29] zeroprog: www.kernel.org, git.kernel.org, kernelnewbies.org, kernel.ubuntu.com/git [23:29] zeroprog: see also #kernelnewbies on irc.oftc.net