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