[03:54] <power885> can anybody help in kernel programming am just newbie to linux
[03:55] <power885> hello anybody der??
[03:55] <power885> hello anybody der??
[03:57] <power885> is der anybody to help me in kernel programming
[08:52] <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:53] <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:54] <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:55] <soren> Err... I'm quite sure, it's "sound"
[08:56] <soren> Perhaps it's not implemented yet?
[08:56] <amitk> soren: that was a proposal at UDS
[08:57] <soren> Ah, ok. Sorry :)
[08:57] <amitk> functionality-based bug filing or some such thing
[08:58] <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 :)
[09:00] <amitk> right
[09:01] <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
[10:01] <apw> *ANNOUCE* today is a 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] <apw> TheMuso, you still in the wake land?
[10:09] <TheMuso> apw: indeed
[10:09] <TheMuso> apw: its 7:10PM here.
[10:10] <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:11] <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:12] <apw> TheMuso, the bug i have i don't think anything is going on :)  but i can sync with dtchen happily
[10:13] <TheMuso> ok
[10:46] <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:48] <smb> Hm, I do not think there will be much attention to that now. Lets restrict that to the Jaunty kernel. 
[10:50] <apw> smb, fair, ack
[11:40] <apw> smb, any idea if the bug list is live in any sense?  seems to never update for me
[11:43] <apw> makes working with it very laborious
[11:44] <apw> i wonder if we could get tags added to them, and remove them as we go
[11:45] <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:46] <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:47] <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:48] <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:55] <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:57] <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:59] <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?
[12:01] <Keybuk> apw: around?
[12:02] <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:03] <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:04]  * 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:06] <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:07] <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:08] <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:09] <soren> What's the maximum limit of the size of the initramfs?
[12:12] <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:13] <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:14] <apw> amitk, those are for review, if they are open without response they go Won't Fix, is on the intro page
[12:15] <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:16] <amitk> apw: I missed the Incomplete-> Won't Fix 
[12:22] <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:28] <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:29] <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:36] <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:37] <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:38] <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:39] <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:40] <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:41] <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:42] <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:43] <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:44] <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:45] <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: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] <apw> its deffo a tmpfs as you reused it didn't you?
[12:49] <Keybuk> it shows up as "rootfs" ;)
[12:50] <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:51] <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:52] <soren> Keybuk: What's the idea?
[12:53] <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:54] <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:55] <Keybuk> but also saves a massive amount of time on boot (bind mounts are a single syscall to set up each)
[13:50] <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:57] <cjwatson> neat
[15:30] <Kano> hi apw , how about adding 2 commits with very simple changes from wireless-git
[15:31] <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:32] <Kano> you only need to remove the additional "ath/", then it applies
[15:33] <Kano> needs a new firmware too
[15:35] <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:36] <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:37] <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:38] <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:39] <cjwatson> it's a pain to continue maintaining it. It will not be necessary once we have mount --union.
[15:40] <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:41] <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:42] <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:43] <mjg59> There's no benefit in adding functionality to a kernel that's never going to be part of a release
[15:44] <Kano> ok, waiting for a live image with mount --union then
[16:23] <Keybuk> damnit
[16:24] <Keybuk> foiled again!
[16:24] <vissky> who do jobs as embeded linux?
[16:35] <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:36] <Kano> cjwatson: do you use kvm?
[16:43] <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:44] <vissky> I love arm!
[16:47] <amitk> vissky: you might find more people on #ubuntu-arm or #ubuntu-mobile
[16:48] <vissky> maybe!
[19:00] <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:01] <maxb> and then it breaks and drops to an initramfs shell
[19:50] <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:51] <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:52] <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:53] <Keybuk> heh
[19:53] <Keybuk> there's few enough that grep should be ok
[21:29] <maco> mjg59, have there been any acpi/pmutils/etc-related changes in the last few days?
[21:38] <mjg59> maco: I'm not active in Ubuntu any more
[21:42] <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:44] <mjg59> Pitti, at a guess
[22:39]  * cwillu pokes apw
[22:42] <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