| zeroprog | 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 | 02:31 |
|---|---|---|
| === cjwatson_ is now known as cjwatson | ||
| samir_ | hello there, i just wanna downgrade my kernel to 2.6.26* | 06:26 |
| samir_ | so i just have to install linux-image-2.6.26* ?? | 06:26 |
| anubhav | samir_: that should work | 06:31 |
| samir_ | anubhav : plus, that will install 2.6.26 modules for me? that's what i'm interested in | 06:37 |
| anubhav | samir_: yes | 06:40 |
| anubhav | samir_: but i am not sure if .26 is present in the ubuntu repository | 06:41 |
| samir_ | anubhav maybe in packages.ubuntu.com | 06:43 |
| apw | NCommander, am looking at the ports issue | 11:03 |
| apw | bah all the configs are in the toilet | 11:13 |
| apw | TheMuso, you about? | 11:13 |
| StevenK | apw: Given the time, TheMuso is probably dinner-ing | 11:39 |
| apw | yeah, i have a handle on the mess now thankfully | 11:40 |
| StevenK | apw: This will be another .30? | 11:42 |
| StevenK | apw: You should also be aware that i386 failed to upload (there's a new state for you) due to version number fun | 11:42 |
| apw | is that the linux-doc breakage? | 11:43 |
| StevenK | Yup | 11:43 |
| apw | yeah can't fix that until rtg gets in as he has the tree, but we are aware | 11:54 |
| apw | 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:13 |
| rtg | apw: I have a test system. where have you stashed test kernels? your PPA? | 14:14 |
| apw | yeah in a ppa .... https://edge.launchpad.net/~apw/+archive/red | 14:15 |
| apw | (gah edge is slow today) | 14:15 |
| apw | 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 | 14:48 |
| rtg | 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:19 |
| mdz | 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:21 |
| rtg | mdz: why would it need manual intervention? | 15:23 |
| mdz | 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:23 |
| mdz | "didn't get built" has different semantics from "was explicitly removed" | 15:24 |
| mdz | rtg: this is because it's hard for LP to tell the difference | 15:24 |
| mdz | "maybe this source package doesn't built that binary package anymore, or maybe it just hasn't built yet" | 15:24 |
| mdz | s/built/build/ | 15:24 |
| rtg | mdz: what is the grace period? a couple days? | 15:25 |
| mdz | 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 |
| soren | Really? They get automatically deleted eventually? | 15:25 |
| soren | I thought they always had to be explicitly removed by an archive admin. | 15:26 |
| rtg | 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:30 |
| mdz | rtg: fine with me | 15:31 |
| mdz | rtg: I just followed up to the list with a suggestion for the upload order | 15:32 |
| rtg | mdz: cool, I'd really like to get the new i386 pae flavour propagated. | 15:32 |
| * Keybuk is having strange behaviour today | 15:41 | |
| Keybuk | nc -q0 ip port | dd of=/dev/sda bs=1M | 15:41 |
| Keybuk | just hangs eventually | 15:42 |
| mdz | Keybuk: on the network side or the sda side? | 15:42 |
| Keybuk | sda side | 15:42 |
| Keybuk | seems to be hung deep inside the io scheduler | 15:51 |
| rtg | apw: care to review ubuntu-karmic-meta.git for me before I upload it? | 15:54 |
| * apw looks | 15:55 | |
| apw | rtg, i see 9.9 at the tip? | 15:56 |
| rtg | apw: yes | 15:56 |
| Keybuk | wow | 15:57 |
| Keybuk | it really looks like it screwed the scheduler | 15:57 |
| apw | so this is just the meta change for mdz's change | 15:58 |
| rtg | apw: correct. next week you'll have to bumop the ABI when you do 2.6.31 | 15:59 |
| rtg | 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 |
| apw | so the plan is to drop it from meta, but not add it to the kernel yet | 16:02 |
| rtg | correct | 16:02 |
| apw | then when its cleared the archive, add it back into the kernel? with the next abi update | 16:02 |
| rtg | correct | 16:02 |
| apw | sounds reasonable, and appears ok to me | 16:03 |
| apw | as for the ports comment i was more referring to the fact it ends up being updated | 16:03 |
| apw | config wise with the other x86 flavours | 16:03 |
| rtg | oh | 16:03 |
| apw | as the ports split we end up with is basically by architecture | 16:04 |
| apw | we'd need to do a bit more work to make the different | 16:04 |
| apw | thought perhaps thats not a negative thing overall | 16:04 |
| apw | as there is probabally some benefit to us at least updating the configs for distro and ports at the saem time | 16:05 |
| apw | always taking defaults for ports, and reporting them to the ports maintainers | 16:05 |
| apw | else they will always fail to build | 16:05 |
| apw | with a dirty config, if we don't | 16:05 |
| rtg | after looking at your 'family' [atch, its not clear that 386 would build at all. there is no '386' flavour. | 16:06 |
| apw | hmmm ... so have i lost it or did the ports fixes lose it? | 16:07 |
| rtg | apw: methinks the ports fixes lost it, [PATCH 1/2] UBUNTU: split out the ports configs into their own family | 16:08 |
| apw | hmm but the family changes are just at the top level | 16:10 |
| apw | by which i mean the arch level | 16:10 |
| apw | there is no config.flavour.386 at all in this origina commit: | 16:12 |
| apw | UBUNTU: [Config] ports - Add configuration files for ports architectures | 16:12 |
| apw | so i think we never brought it over | 16:12 |
| rtg | apw: that is the conclusion I was just coming to as well. | 16:13 |
| apw | want me to sort that out? | 16:13 |
| apw | i suspect it just got forgotten | 16:14 |
| apw | inserting a new complete config into the split configs is an interesting game, which i just did for the ports ones | 16:14 |
| rtg | apw: yeah, go ahead and sort it out. I've just pushed one more commit (reverting the linux-doc patch) | 16:15 |
| rtg | apw: can you make 386 it's own arch? | 16:18 |
| apw | it does appear the kernel arches are not the same as build arches right? | 16:18 |
| rtg | apw: hmm, I think 386 gets built on an i386 chroot | 16:19 |
| apw | will have a play | 16:19 |
| apw | rtg what we care about is keeping 386 merging with ports configs | 16:26 |
| apw | otherwise its fine? | 16:26 |
| rtg | apw: I dunno if its fine, but yeah, 386 should be part of the ports family of configs. | 16:28 |
| mvo | 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:30 |
| rtg | mvo: I believe so. It keeps the mirrors from picking it up. | 16:31 |
| mvo | ok, thanks | 16:32 |
| rtg | apw: the original patch set from Luke simply didn't contain a 386 config | 16:32 |
| apw | yeah or indeed anything about 386 at all | 16:32 |
| rtg | apw: ok, I'd say just drop him a note about it and lets move on with other work | 16:33 |
| apw | 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:34 |
| apw | i t | 16:36 |
| apw | 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 |
| rtg | apw: it could, but I'm gonna let Luke figure it out | 16:37 |
| apw | ok | 16:37 |
| apw | rtg ok, i've emailed him and copied u-k-t | 16:43 |
| rtg | 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 |
| apw | rtg yeah thats the one that should exhibit it | 16:49 |
| apw | i've personally tested some of the other combinations, which still work at least but would never have been affected | 16:50 |
| rtg | apw: I take it these are upstream cherry-picks? | 16:51 |
| apw | 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 |
| apw | i think dave got sick of them and just merged them | 16:56 |
| rtg | apw: well, can we easily cherry-pick from Linus tree, or should we just ignore the PAE problem until 2.6.31 ? | 16:57 |
| apw | the only urgency is if we are pushing people to -pae at all during upgrades, if not then there is none | 16:58 |
| apw | 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 |
| rtg | apw: fresh installs will have the problem if > 4GB RAM. Otherwise, upgrades ought to be OK. | 16:59 |
| apw | so i think ... they can sensibly fall into the 'will wait for upstream to have them' bucket to my eye | 16:59 |
| rtg | apw: works for me. I'm gonna package and upload then. | 17:00 |
| apw | ok | 17:00 |
| apw | that should get us at least an upload with the new flavours me thinks | 17:03 |
| rtg | thats my goal | 17:03 |
| Keybuk | rtg: can I ask a question? | 17:08 |
| rtg | Keybuk: always | 17:09 |
| rtg | whether I can answer... | 17:09 |
| Keybuk | rtg: I have an image file | 17:09 |
| Keybuk | and I'm trying to write it to the disk | 17:09 |
| Keybuk | but every time, the kernel hangs inside the I/O scheduler | 17:09 |
| Keybuk | is there a simple way to change that so I can use a different I/O scheduler | 17:09 |
| Keybuk | (and worry about filing the bug later :p) | 17:09 |
| rtg | Keybuk: yeah, there is a way to change the I/O scheduler dynamically. just need to remember how. | 17:10 |
| Keybuk | rtg: what's a good "just do it" I/O scheduler? | 17:10 |
| rtg | deadline? | 17:10 |
| rtg | Keybuk: find /sys|grep sched | 17:13 |
| rtg | cat /sys/devices/pci0000:00/0000:00:1f.1/host0/target0:0:0/0:0:0:0/block/sda/queue/scheduler | 17:13 |
| rtg | This is a server install, so the default is deadline. | 17:13 |
| Keybuk | ok | 17:13 |
| Keybuk | great | 17:13 |
| * Keybuk tries that | 17:13 | |
| rtg | Keybuk: try noop also, which is the simplest | 17:14 |
| rtg | IIRC | 17:14 |
| noptys | 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:19 |
| rtg | noptys: perhaps you should email Jesse Brandenburg about that | 17:22 |
| noptys | can do | 17:22 |
| Keybuk | rtg: the deadline scheduler worked | 17:29 |
| rtg | Keybuk: is Ingo the I/O scheduler dude? | 17:29 |
| rtg | Keybuk: maybe Jens Axboe <axboe@kernel.dk> (block/cfq-iosched.c) | 17:32 |
| apw | ingo is cpu scheduler to my mind | 17:32 |
| rtg | apw: Jens did the CFQ scheduler | 17:33 |
| apw | rtg he is also the maintainer of BLOCK in general, so a good starting point | 17:34 |
| wjblack | Hello! | 20:27 |
| wjblack | 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:29 |
| wjblack | Am I going about this the wrong way entirely? | 20:30 |
| rtg | wjblack: is it a DKMS based package? | 20:31 |
| wjblack | Nope. Modified vanilla kernel.org. | 20:31 |
| wjblack | Literally, it's a patch to the 2.6.30 r8169.c that allows it to compile/run on 2.6.28 | 20:32 |
| wjblack | (the 2.6.30 version has a slightly different api but a fix for a rather nasty MSI bug) | 20:32 |
| rtg | wjblack: the best way to package it so that you don't have to deal with ABI dependencies is to use DKMS | 20:33 |
| wjblack | Hmm. Okie-dokie. Is there an Ubuntuish way to do that, or do I do generic dkms stuff? | 20:34 |
| wjblack | (never used DKMS before, obviously ;-) ) | 20:34 |
| rtg | 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 |
| rtg | s/here/there/ | 20:35 |
| wjblack | Aah, so the bcmwl package that's available via apt-get somewhere uses dkms? Excellent. | 20:35 |
| * wjblack learns best by example ;-) | 20:35 | |
| rtg | wjblack: yes, the maintainer is Alberto Milone (tseliot) | 20:36 |
| rtg | wjblack: in Karmic its called bcmwl-kernel-source | 20:36 |
| wjblack | 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 |
| wjblack | Right on. I'll give it a looksee. Thanks! | 20:37 |
| rtg | wjblack: 2.6.30 is in the Karmic archive right now, 2.6.31-rc1 soonish | 20:37 |
| wjblack | 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. ;-) | 20:39 |
| bullgard4 | Update Manager differentiates 'distriution updates' and 'security updates'. What is the difference? Does every single DE program package have a flag for that? | 21:29 |
| bullgard4 | s/DE/DEB/ | 21:30 |
| _ruben | not every bugfix relates to security issues | 21:30 |
| bullgard4 | _ruben: Yes. -- So it depends solely on the maintainer's judgement? | 21:32 |
| zeroprog | 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:39 |
| johanbr | a module can do pretty much anything | 21:43 |
| johanbr | think of it as a plugin for the kernel | 21:43 |
| zeroprog | 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 |
| zeroprog | 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:50 |
| johanbr | look at the kernel source for sth simple | 21:51 |
| zeroprog | ok | 21:51 |
| zeroprog | do you know where thats located? | 21:53 |
| dtchen | zeroprog: www.kernel.org, git.kernel.org, kernelnewbies.org, kernel.ubuntu.com/git | 23:29 |
| dtchen | zeroprog: see also #kernelnewbies on irc.oftc.net | 23:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!