power885 | can anybody help in kernel programming am just newbie to linux | 03:54 |
---|---|---|
power885 | hello anybody der?? | 03:55 |
power885 | hello anybody der?? | 03:55 |
power885 | is der anybody to help me in kernel programming | 03:57 |
dholbach | hiya - can somebody tell me if I should report http://paste.ubuntu.com/191481 - or is that a known bug and being worked on already? | 08:52 |
dholbach | I just get a very quiet rustling sound instead of music on karmic | 08:53 |
amitk | dholbach: best to report the bug | 08:53 |
dholbach | (same using 'aplay' too) | 08:53 |
dholbach | ubuntu-bug audio? or ubuntu-bug alsa? | 08:53 |
dholbach | what was it again? | 08:53 |
amitk | alsa | 08:53 |
dholbach | gracias | 08:54 |
dholbach | erm no | 08:54 |
dholbach | there's "no package alsa" | 08:54 |
amitk | alsa-base | 08:54 |
amitk | sorry | 08:54 |
dholbach | ah yes, looking much better | 08:54 |
soren | Err... I'm quite sure, it's "sound" | 08:55 |
soren | Perhaps it's not implemented yet? | 08:56 |
amitk | soren: that was a proposal at UDS | 08:56 |
soren | Ah, ok. Sorry :) | 08:57 |
amitk | functionality-based bug filing or some such thing | 08:57 |
soren | https://wiki.ubuntu.com/DesktopTeam/Specs/Karmic/SymptomBasedBugReporting | 08:58 |
soren | I just saw it mentioned so many times I thought it was here already :) | 08:58 |
amitk | right | 09:00 |
dholbach | thanks amitk - reported, bug 385094 | 09:01 |
ubot3 | Malone bug 385094 in alsa-driver "[karmic] very quiet rustling sound instead of music" [Undecided,New] https://launchpad.net/bugs/385094 | 09:01 |
=== NCommander is now known as ApportRetracerPo | ||
=== ApportRetracerPo is now known as NCommander | ||
apw | *ANNOUCE* today is a kernel team bug day ... https://wiki.ubuntu.com/KernelTeam/BugDay/20090609 | 10:01 |
=== alex_jon1 is now known as alex_joni | ||
=== smb changed the topic of #ubuntu-kernel to: Karmic Kernel Plan: 2.6.31 -- Kernel Team Bug Day https://wiki.ubuntu.com/KernelTeam/BugDay/20090609 | ||
* apw wonders when dtchen choses to have his wake time | 10:07 | |
apw | TheMuso, you still in the wake land? | 10:08 |
TheMuso | apw: indeed | 10:09 |
TheMuso | apw: its 7:10PM here. | 10:09 |
apw | just wading through some old bugs, for the bug day and stubled across | 10:10 |
apw | the bug regarding muting PCM leading to crackles when sound is played | 10:10 |
apw | which is believed to be pulse audio related | 10:10 |
apw | and wondered if you had any background on it, and/or advice as to how to | 10:10 |
apw | go about moving it forward | 10:11 |
TheMuso | I think dtchen may know more than me with that, I am not sure whats going on at this time, without checking the bug again. | 10:11 |
apw | TheMuso, the bug i have i don't think anything is going on :) but i can sync with dtchen happily | 10:12 |
TheMuso | ok | 10:13 |
apw | smb, i have found a bug which was fixed by a stable update, this is in intrepid we interested in updating the changlog that far back? | 10:46 |
smb | Hm, I do not think there will be much attention to that now. Lets restrict that to the Jaunty kernel. | 10:48 |
apw | smb, fair, ack | 10:50 |
apw | smb, any idea if the bug list is live in any sense? seems to never update for me | 11:40 |
apw | makes working with it very laborious | 11:43 |
apw | i wonder if we could get tags added to them, and remove them as we go | 11:44 |
amitk | apw: leanne's list? It's live more me, updates take a few minutes to be seen though. | 11:45 |
apw | yeah leans list | 11:45 |
apw | amitk, none of them have changed opn your list for me | 11:45 |
amitk | apw: coz I haven't worked on any yet :) | 11:45 |
apw | ie your bit looks unchanged here | 11:46 |
apw | so you have no idea then! | 11:46 |
apw | if it was broke this time i mean | 11:46 |
amitk | apw: it did work on previous bug days | 11:46 |
amitk | aah, point. | 11:46 |
apw | yeah it did indeed. not so well today | 11:46 |
apw | poop, its obviously worked at least a bit as its got stuff some people did yesterday updated in it | 11:47 |
apw | ahh its part updated. hrm | 11:47 |
apw | and that happened in the last 20 mins i recon | 11:48 |
apw | strnage. i do note edge is SLOOOO today so perhaps its slowing the updates too | 11:48 |
cjwatson | there's some firmware in the main kernel packages in karmic that needs to be delivered to d-i. There's already a separate linux-firmware source package, though, that squats the obvious package names for this (nic-firmware, scsi-firmware). What would you guys like to do about this? | 11:55 |
cjwatson | (this is bug 384861, regarding bnx2) | 11:57 |
ubot3 | Malone bug 384861 in debian-installer "Broadcom NetXtreme II (BCM5708) not detected by installer [karmic]" [Undecided,New] https://launchpad.net/bugs/384861 | 11:57 |
cjwatson | or maybe it ought to just deliver the firmware in the nic-modules package along with the bnx2 module itself; I suppose there's no real reason to keep it separate | 11:57 |
Keybuk | II: Checking ABI for generic... | 11:59 |
Keybuk | EE: Previous or current ABI file missing! | 11:59 |
Keybuk | /build/buildd/linux-2.6.30/debian/abi/2.6.30-8.10~boot2/amd64/generic | 11:59 |
Keybuk | make: *** [abi-check-generic] Error 1 | 11:59 |
* Keybuk explodes | 11:59 | |
Keybuk | how the hell do I avoid this? | 11:59 |
Keybuk | apw: around? | 12:01 |
cjwatson | mkdir -p debian/abi/2.6.30-8.10~boot2 && touch debian/abi/2.6.30-8.10~boot2/ignore # ? | 12:02 |
Keybuk | cjwatson: I don't want to ignore it, I want to know how to get what should be in that directory | 12:02 |
apw | Keybuk, yep here | 12:02 |
apw | run getabi's | 12:03 |
Keybuk | apw: how do I make the debian/abi/2.6.30-8.9 for your upload? | 12:03 |
Keybuk | apw: where is that? | 12:03 |
apw | debian/scripts/misc/getabis 2.6.30 8.9 | 12:03 |
apw | though if you have changed it in any way which changes the ABI you will still need to either ignore it | 12:03 |
apw | or up the ABI number too | 12:03 |
* Keybuk only mucked around with static functions | 12:04 | |
apw | though i thought the current tree _has_ the ABIs in it already | 12:04 |
Keybuk | I went from the source p ackage | 12:04 |
apw | then you won't have them, as you can't know them before the upload | 12:06 |
apw | so they get committed with the startnewrelease commit in the git tree | 12:06 |
apw | basically your 'error' is making a new changelog stanza | 12:07 |
apw | if you update the top one and add your ~boot2 you won't hit the issue i beleive | 12:07 |
apw | not ideal, but ok for debugging | 12:07 |
apw | Keybuk, am i making sense? | 12:08 |
Keybuk | yup | 12:08 |
Keybuk | that makes sense | 12:08 |
Keybuk | thanks :) | 12:08 |
apw | phew, np | 12:08 |
soren | What's the maximum limit of the size of the initramfs? | 12:09 |
Keybuk | there isn't one | 12:12 |
Keybuk | though there's a multiplicative speed penalty for putting anything inside it | 12:12 |
Keybuk | so the smaller the better | 12:12 |
amitk | ogasawara: why do we have already 'incomplete' bugs on the list today? I can't set it to "really incomplete"... | 12:13 |
apw | yeah my understanding of initramfs was it being better than initrd | 12:13 |
apw | as it could grow to ram size | 12:13 |
apw | amitk, those are for review, if they are open without response they go Won't Fix, is on the intro page | 12:14 |
apw | woh, if i reload three times on web page it is the same twice and different once... out of sync web me thinks | 12:15 |
apw | amitk, or did i miss understand | 12:15 |
amitk | apw: I missed the Incomplete-> Won't Fix | 12:16 |
cjwatson | soren: there are some architecture-dependent limits on the size of the objects that bootloaders can load | 12:22 |
cjwatson | frex yaboot has difficulty netbooting anything over 6MB | 12:22 |
cjwatson | (IIRC) | 12:22 |
soren | Hmm... I just seem to remember reading about the "protocol" the boot loaders employ putting some limits on the sizes of the kernel and ramdisk. | 12:28 |
* soren goes to find that again | 12:28 | |
apw | i have cirtainly had trouble with yaboot i the past with 60MB initrds and similar | 12:29 |
soren | AFAIUI the bootloader puts the kernel and ramdisk at specific adresses, and then starts running the kernel. Otherwise, how will the kernel know where to look for the initrd? | 12:29 |
Keybuk | soren: you're confusing initrd and initramfs | 12:36 |
Keybuk | soren: the initramfs is simply concatenated onto the end of the kernel image | 12:36 |
soren | Ah. There's a specific address where you put a pointer to the ramdisk along with the size of it. | 12:36 |
Keybuk | soren: again, you're confusing initrd and initramfs | 12:36 |
soren | Keybuk: Oh. | 12:36 |
soren | Keybuk: I thought the difference was just the format. | 12:37 |
Keybuk | no | 12:37 |
apw | Keybuk, do you mean in /boot or by the boot laoder | 12:37 |
Keybuk | the format is one difference | 12:37 |
Keybuk | another difference is the way they are loaded | 12:37 |
Keybuk | and yet another difference is when in the kernel the code inside is actualyl used | 12:37 |
apw | it is possible to embed initramfs in the kernel, but also to have it in the initrd bucket | 12:37 |
Keybuk | apw: you can do both | 12:37 |
Keybuk | apw: the bootloader puts it after the kernel image in memory | 12:37 |
Keybuk | so it appears identically to the kernel whether it was directly added in /boot or put after it by the bootloader | 12:38 |
soren | Keybuk: ..but how does the bootloader know whether it's an initrd or an initramfs? | 12:38 |
apw | though it uses the normal initrd style mechanism to tell the kernel about it | 12:38 |
apw | if its a separate image | 12:38 |
apw | and we have to use the magics in the initrd to tell if its initrd or initramfs format | 12:38 |
Keybuk | oh, that might be a bootloader thing ;) | 12:38 |
Keybuk | I could certainly be wrong | 12:38 |
Keybuk | though, that being said | 12:39 |
Keybuk | "how big can I make the initramfs" is the kind of question that makes me nervous | 12:39 |
soren | Ok, so even though we're using an initramfs, we do still use the ramdisk_image and ramdisk_size fields as described in Documentation/x86/i386/boot.txt? | 12:39 |
soren | Keybuk: Heh :) | 12:39 |
Keybuk | soren: I don't think so, no | 12:39 |
soren | Oh. | 12:39 |
Keybuk | soren: initramfs is unpacked into a tmpfs | 12:39 |
Keybuk | not a ramfs | 12:39 |
soren | Sure, sure. | 12:39 |
soren | That I understand. | 12:40 |
Keybuk | (how many ways can the name be wrong? :p) | 12:40 |
Keybuk | err, I think it's a tmpfs anyway, I should check that | 12:40 |
apw | i beive we do use the same pointers for a non-builtin initrd image | 12:40 |
soren | I'm just unsure how the bootloader tells the kernel where to find the initrd.img thing. | 12:40 |
apw | the bootloader just has the instruction to load and tell me where you loaded this blob for either format | 12:40 |
soren | apw: And that's those two fields? | 12:40 |
* soren crosses fingers | 12:40 | |
apw | i believe it is yes | 12:41 |
soren | Oh, good. | 12:41 |
soren | :) | 12:41 |
soren | I was about to lose it :) | 12:41 |
apw | heh ... if you look at the source for INITRD you can see the bit where it looks at those two bits | 12:41 |
apw | and uses them to map some space into the kernel to reference it, then it checks for initrd and initramfs format contents and unpacks it as appropriate | 12:41 |
soren | Keybuk: I'm trying to overcome some annoying limitations on EC2 by stuffing some extra modules in the initramfs and exporting them to "real" system by way of a tmpfs. | 12:42 |
soren | Keybuk: I'm not going to slow down booting on your Mini 9 :) | 12:42 |
apw | the problem is we rm -rf the initramfs before we switch to normal root | 12:42 |
soren | apw: Not a problem. | 12:43 |
apw | though Keybuk did i see you do something funky sharing the initramfs onto /dev/ and the like to save space? | 12:43 |
Keybuk | apw: yes | 12:43 |
apw | ^5 cool idea | 12:43 |
soren | I'm doing pretty much the same thing here. | 12:43 |
Keybuk | which is why I'm suddenly curious as to whether it's a tmpfs or a ramfs ;) | 12:44 |
soren | What's the difference? | 12:44 |
Keybuk | ramfs is backed by ram | 12:44 |
Keybuk | tmpfs is backed by virtual memory | 12:44 |
soren | So is tmpfs, surely? | 12:44 |
soren | Oh. | 12:44 |
soren | Gotcha. | 12:44 |
apw | ramfs is a block device into which you can put any filesystem, and tmpfs is a real filesystem type whihc uses ram to back itself | 12:45 |
apw | (i think) | 12:45 |
Keybuk | apw: no, you're confusing ramdisk and ramfs there ;) | 12:45 |
Keybuk | ramfs is a real filesystem that uses ram | 12:45 |
apw | heh ... easy to do | 12:45 |
Keybuk | it's basically non-swappable tmpfs | 12:45 |
apw | makes sense | 12:45 |
* apw goes back to his _fun_ bug day list | 12:46 | |
* Keybuk is just proving to himself that initramfs is really not a ramfs but a tmpfs | 12:46 | |
apw | its deffo a tmpfs as you reused it didn't you? | 12:49 |
Keybuk | it shows up as "rootfs" ;) | 12:49 |
Keybuk | I just assumed it was a tmpfs because that's what all the documentation and comments say | 12:50 |
Keybuk | just proving to myself from the code that it's not ramfs | 12:50 |
Keybuk | cause that would make my idea not-so-great | 12:50 |
apw | if you are reusing it for the /dev/ mount too that is reported as tmpfs | 12:50 |
Keybuk | current karmic doesn't reuse them | 12:51 |
Keybuk | they're separate mounts | 12:51 |
Keybuk | What is rootfs? | 12:51 |
Keybuk | --------------- | 12:51 |
Keybuk | Rootfs is a special instance of ramfs (or tmpfs, if that's enabled), which is | 12:51 |
Keybuk | always present in 2.6 systems. You can't unmount rootfs for approximately the | 12:51 |
Keybuk | same reason you can't kill the init process; rather than having special code | 12:51 |
Keybuk | to check for and handle an empty list, it's smaller and simpler for the kernel | 12:51 |
Keybuk | to just make sure certain lists can't become empty. | 12:51 |
Keybuk | Most systems just mount another filesystem over rootfs and ignore it. The | 12:51 |
Keybuk | amount of space an empty instance of ramfs takes up is tiny. | 12:51 |
soren | Keybuk: What's the idea? | 12:52 |
Keybuk | soren: we have several virtual filesystems | 12:53 |
Keybuk | /dev, /dev/shm, /var/run, /var/lock | 12:53 |
Keybuk | and probably /tmp | 12:53 |
Keybuk | they're all instances of tmpfs, just with different mount options | 12:53 |
Keybuk | so each one uses up resource to exist | 12:53 |
Keybuk | and we also have the initramfs/rootfs hanging around forever because it was built-in to the kernel | 12:53 |
Keybuk | we save memory, time and money by just re-using it | 12:54 |
Keybuk | so instead of mounting a new tmpfs at each of them | 12:54 |
Keybuk | we just bind-mount sub-directories of the rootfs onto the real filesystem | 12:54 |
Keybuk | so (initramfs)/dev is exactly equal to (root)/dev | 12:54 |
soren | Ah. | 12:54 |
Keybuk | (initramfs)/var/run is exactly equal to (root)/var/run | 12:54 |
Keybuk | etc. | 12:54 |
soren | Yeah, that would be neat. | 12:54 |
Keybuk | each of the bind mounts can still have different options of course | 12:54 |
Keybuk | it means we don't need things like /dev/.initramfs for a start | 12:54 |
Keybuk | but also saves a massive amount of time on boot (bind mounts are a single syscall to set up each) | 12:55 |
cjwatson | Keybuk: that would mean they'd share a maximum size rather than having independent maximum sizes, wouldn't it? (I don't think that's important for /dev /dev/shm /var/run /var/lock but it might be relevant for /tmp) | 13:50 |
Keybuk | no, that's a mount option | 13:50 |
cjwatson | neat | 13:57 |
Kano | hi apw , how about adding 2 commits with very simple changes from wireless-git | 15:30 |
Kano | http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=3d563f6e2fdac4544f0de25af6ff299f4e29f10a | 15:31 |
Kano | http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=b82882e12934ec192a6b21264da087f00ade0b39 | 15:31 |
Kano | you only need to remove the additional "ath/", then it applies | 15:32 |
Kano | needs a new firmware too | 15:33 |
apw | i would imaging we'll get that when the merge window opens | 15:35 |
apw | we'll need a bug i recon to handle the firmware so we can track the licence | 15:35 |
Kano | http://article.gmane.org/gmane.linux.kernel.wireless.general/33605 | 15:36 |
Kano | i think it will be in 2.6.31 too, so maybe add the firmware already | 15:36 |
cjwatson | Kano: (#ubuntu-devel) the purpose of unionfs-fuse is not speed; it's purely a stopgap measure until we get proper VFS-level union mounts, so I'm not interested in any properties of its speed other than "is it minimally usable" right now | 15:37 |
cjwatson | Kano: the kernel team is fed up having to twiddle aufs* into applying against the current kernel and I don't really blame them considering that a real upstream solution is in sight | 15:38 |
Kano | cjwatson: i prepared the patch, it works, what big thing do you need to do? | 15:38 |
cjwatson | it's a pain to continue maintaining it. It will not be necessary once we have mount --union. | 15:39 |
amitk | Kano: it will break again when 2.6.31 starts | 15:40 |
Kano | it is not that hard as you say. it was a bit tricky to fix the aufs patch for module mode as u had already some additional exports | 15:40 |
Kano | but the driver itself you can cp 1:1 from a git tree | 15:41 |
cjwatson | mount --union is much cooler anyway | 15:41 |
Kano | is it fast? | 15:41 |
amitk | not hard != automatic | 15:41 |
Kano | amitk: you could automate it | 15:42 |
mjg59 | Kano: --union is done entirely in the VFS, so yes, it's fast | 15:42 |
Kano | the only tricky part are the additional expoerts | 15:42 |
Kano | the rest can be of course automated | 15:42 |
Kano | the exports will not change usually | 15:42 |
mjg59 | There's no benefit in adding functionality to a kernel that's never going to be part of a release | 15:43 |
Kano | ok, waiting for a live image with mount --union then | 15:44 |
=== pace_t_zulu_ is now known as pace_t_zulu | ||
=== pgraner_ is now known as pgraner-afk | ||
Keybuk | damnit | 16:23 |
Keybuk | foiled again! | 16:24 |
vissky | who do jobs as embeded linux? | 16:24 |
manjo | apw, I have a draft version of the design/implementation its in no way complete but you can look at it and let me know if I am going in the right direction ... https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-karmic-suspend-resume | 16:35 |
Kano | cjwatson: do you use kvm? | 16:36 |
CarlFK1 | vissky: I got hired to do embedded linux, but personally I don't think running on x86 2g ram 60g hd qualifies as embedded | 16:43 |
vissky | I love arm! | 16:44 |
amitk | vissky: you might find more people on #ubuntu-arm or #ubuntu-mobile | 16:47 |
vissky | maybe! | 16:48 |
maxb | Karmic ABI 8 kernel seems to break my software raid | 19:00 |
maxb | Instead of bind<sda2> and bind<sdb2>, I get bind<dm-3> | 19:00 |
maxb | and then it breaks and drops to an initramfs shell | 19:01 |
Keybuk | apw: my attempts to make populate_rootfs() async have been so far thwarted by something re-synchronising the world just after calling it | 19:50 |
apw | thats a royal pain | 19:50 |
apw | i can see its prolly needed pretty soon | 19:51 |
apw | s/see/imagine/ | 19:51 |
apw | do you know if its syncing on it, or on something else entirly | 19:51 |
Keybuk | just everything | 19:51 |
Keybuk | need to track it down, but I think something is just calling async_synchronise_full() | 19:52 |
apw | unhelpful for sure, you should instrument that with a WARN_ON(1); | 19:52 |
Keybuk | heh | 19:53 |
Keybuk | there's few enough that grep should be ok | 19:53 |
maco | mjg59, have there been any acpi/pmutils/etc-related changes in the last few days? | 21:29 |
mjg59 | maco: I'm not active in Ubuntu any more | 21:38 |
maco | mjg59, ok. i just remember that you know all about acpi, so i thought maybe you'd be someone that would notice such changes | 21:42 |
maco | any idea who the current ubuntu acpi know-it-all is? | 21:42 |
mjg59 | Pitti, at a guess | 21:44 |
* cwillu pokes apw | 22:39 | |
cwillu | EXT4-fs warning (device sda1): dx_probe: dx entry: limit != root limit | 22:42 |
cwillu | EXT4-fs warning (device sda1): dx_probe: Corrupt dir inode 8962051, running e2fsck is recommended | 22:42 |
cwillu | the latest post-suspend bugs :) | 22:42 |
cwillu | re: bug #380807 | 22:42 |
ubot3 | Malone bug 380807 in linux "[karmic, intel] Laptop locks up moments after resuming from suspend" [Medium,In progress] https://launchpad.net/bugs/380807 | 22:42 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!