[07:08] TheMuso: you know that dmraid only needs the hd meta data? you can use hds with it even on systems which do NOT have got a raid bios at all. At least when you are not requried to boot from it. [07:08] TheMuso: so basically you could use a ppc to access hds from a pc raid too. [07:09] but that all would only work with a working dm [07:09] and that is broken [07:12] http://patchwork.kernel.org/patch/33534/ [07:13] without all with dm is useless [07:42] Kano: I know that. The module is only used for RAID 5 arrays, and teh likelyhood of users using powerpc to access such arrays is very low. Most macs for example would require at least 2 E-Sata cards to allow people to connect the minimum of 3 drives needed for a RAID5 array. [07:43] and the space requirement for that module is so big ;) [07:43] why did nobody test dm functionality at all? [07:44] Well, the code builds on other architectures, and the code looks ok, so no idea why gcc on powerpc complained about it. [07:44] Kano: I don't know, you will have to ask the kernel team. I am only helping out with powerpc, because its a ports architecture I care about. [07:58] TheMuso: can't you daisy chain sata? [08:00] lifeless: not afaik. [08:00] lifeless: You're probably thinking of firewire. [08:01] In which case, a user could set drives up with firewire, once they were in docks/caddies that supported firewire. [08:01] in any case, I think for most users to use ppc for dmraid stuff, it would be too much effort. There is also endianness issues that may yet need resolving. [08:01] actually, fibrechannel I think is what I was thinking of [08:01] That would be my believe as well. sata being 1-1 only [08:02] fibrechannel? isn't that a san topology? [08:02] * TheMuso learns something new. [08:02] I knew of fibre channel, but didn't know it could be chained. [08:03] I neither, but my knowledge could be patchy too [08:06] TheMuso, Ok, seems with arbitrated loop layout you seem to be able to daisy chain the devices [08:07] well you can use port mulitpliers for sata [08:09] I'm not sure how well those would work. [09:17] apw, the fan overheating bug - I will double check this on my other laptops now. [09:17] to see if is generic rather than related to specific models. [09:17] cking, thats great. if you confirm its hibernate which triggers the behaviour then we can ask whether that is a common thread on the bug [09:18] also have you tested suspend too? [09:18] not yet. I woke up at 3am this morning and it hit me that hibernate was the only thing I've done in both cases where I have done this over the past few months. [09:19] ..so I've only just tested hibernate [10:05] cking, you should be sleeping when the clock has those kind of times on it [10:05] eh? [10:06] oh, yeh. [10:06] You know how it is, you sleep on a problem then bingo at 3.00am you wake up with a solution [10:08] or you could just be an insomniac [10:08] like jjohansen [10:08] jjohansen: do you ever sleep? [10:08] weekends [10:08] heh [10:10] not sleeping wrecks the memory [10:11] cking: yep [10:14] actually I do usually sleep, I just have a tendency to work until 2 or 3 in the morning [11:00] jjohansen, stop confusing me [11:00] apw: ? [11:00] by being awake allt he time [11:02] apw: is that a not so subtle hint? [11:03] heh ... you are a little time challenged ... [11:08] cjwatson, we seem to have a further bug relating to the bnx2 firmware loading stuff; we are missing firmware.sh to do the actual load (see bug #394783). i've pushed up a bzr branch up a bzr branch on that bug which should fix it. perhaps you could have a look when you are not busy [sic] [11:08] Malone bug 394783 in udev "Broadcom BCM5708 "SIOCSIFADDR: No such device"" [Medium,In progress] https://launchpad.net/bugs/394783 [11:24] apw: you need to copy 50-firmware.rules as well [11:24] apw: I'd also remove the mention of udebs in the initramfs - that isn't really relevant here and it's confusin [11:25] g [11:25] apw: Keybuk should sign off on this really [11:28] we've generally tried to avoid having firmware in the initramfs *sigh* [11:29] cjwatson, ahh ok ... of course. doh [11:29] Keybuk, heh yeah, but we have firmware and no way to load it. [11:29] will update the branch and hastle Keybuk instead :) [11:30] howdy! [11:30] apw: err, hang on [11:30] back up a *LOT* [11:30] is there anything else I need to provide for bug #396286 ? [11:30] Malone bug 396286 in linux "kernel 2.6.31-generic oops after loading initramfs" [Undecided,New] https://launchpad.net/bugs/396286 [11:30] why are you talking about adding firmware to the initramfs for a *network* card ?! [11:30] a network card isn't critical to mounting the root filesystem [11:31] Keybuk, it is if its on a netowkr? [11:31] apw: so we should add wpa_supplicant to the initramfs as well, just in case they want to NFS mount over a WPA-secured wireless network?! :p [11:31] nfsroot i assume in this case, cjwatson was involved in the changes to bring the firmware to a udeb, and may know the use model [11:32] when we originally added the netroot support, we decided we'd only support sensible cards [11:32] wired network cards that didn't need firmware [11:32] also the bug doesn't sound like the user is trying to netboot from it [11:32] i am suspicious that we have brought in the bnx2 card to fix something, and that has broken general bnx2 support [11:32] it sounds like they have a problem that the module doesn't work even after the system is fully booted [11:33] which is more likely a module bug than a udev one [11:33] since udev will just supply the firmware later [11:34] apw: I was involved in adding firmware to the *udeb*, not to the initramfs, FWIW [11:34] for the installer, yes, i am conflating [11:34] I would guess that this is a module bug [11:34] it's probably setting some insanely stupid timeout for firmware [11:34] "if I don't get firmware within 500 ms I'm going to lobotomise myself" [11:35] looks like 60s per card in this case yes [11:35] 60s should be long enough to boot [11:35] but if they have scsi drives, it might not be [11:35] but the issue seems to be if it fails, then the driver is loaded, and does not get loaded [11:35] we could just take bnx2 out of the initramfs ... [11:35] wait, back up again! [11:35] cjwatson, that would work i suspect in this case [11:35] stop trying to ride the rollercoaster of assumptions [11:35] but but but we like that game its loads of fun [11:36] there is a wonderful system called "uevents" tied with this thing called the "/sys filesystem" [11:36] yep [11:36] when a module wants firmware, it creates a kobject in the firmware class [11:36] yep [11:36] so if a module is calling out for firmware, there will be an entry in /sys/class/firmware for it [11:36] (FWIW I'm not assuming anything about the problem here other than "why is bnx2 in the initramfs in the first place, since it needs firmware to work") [11:36] cjwatson: well, yes that I'd agree with - I was talking to apw ;) [11:36] apw: now, if the module calls out for firmware and just *waits* [11:37] my only assumption was that the bug was real and needed fixing :) [11:37] then when we run udevadm trigger while booting the full system [11:37] udev will see that there's the outstanding firmware request [11:37] and [11:37] ... [11:37] *supply the firmware* [11:37] so, all you should need to do to fix this is make the module more patient [11:37] arguably it's also a bug that after it fails to get firmware it stays loaded [11:37] it should fail to load [11:37] but at that point the kernell is waiting [11:37] no [11:37] the kernel isn't waiting [11:37] the module is waiting [11:38] indeed, but the boot process is waiting for the load [11:38] no it isn't [11:38] so we get a full 2 minute delay for giggle in this case [11:38] no we don't [11:38] dmesg dissagrees with you [11:38] right [11:38] that's exactly my point [11:38] this is a buggy module [11:38] it's doing firmware wrong [11:38] it's most likely sitting in a loop going "Dude, where's my firmware?" [11:39] well request_firmware interface is the standard way, and thats its semantic [11:39] get the firmware and wait for it to occur [11:39] so there are three ways forward [11:39] 1) fix loading firmware in initramfs [11:39] 2) stop loading bnx2 somehow [11:39] 3) fix bnx2 somehow [11:40] but why is request_firmware() a problem here? [11:40] because its a blocking interface [11:40] it should only block that one module's _init() [11:40] and will that not block modprobe [11:40] also request_firmware_nowait() [11:41] though not much uses that [11:41] it'll block modprobe [11:41] oh, duh [11:41] sorry, I was going on a "but we don't call udevadm settle in the initramfs" line [11:41] but we do now [11:41] to fix a different bug [11:41] ok, I concede your point ;) [11:42] the way we do the initramfs means you'll block waiting for that modprobe to complete - and it can't [11:42] heh ... at least i am not completley mad [11:42] yeah, so just don't ship that module in the initramfs ;) [11:42] ok ... what decides whats in there i wonder [11:43] auto_add_modules() in /usr/share/initramfs-tools/hook-functions iirc [11:43] ogra: correct, it's a hardcoded list there [11:43] yes, I have it fixed in my tree [11:44] I'll upload now if folks are ok with that [11:44] why is bnx2 in there now? [11:44] is that a manual list of modules without firmware? [11:44] we added lots of random network modules [11:45] keen though I normally am to find the reasons why things are as they are right now, I think you ascribe too much thought to that code [11:45] hehe ... :) probabally [11:45] ok so i'll shove this bug over to initramfs-tools then [11:46] aye [11:46] cjwatson: of course, we should probably address the whole needing firmware thing [11:46] that code isn't exactly fluffy [11:46] if you want to do netroot, we could apply much more common sense to it [11:47] is it so bad to just include the firmware loader for that (when and if we decide to so support)? [11:47] seems to be two files and the firmware [11:48] wihch mostly used to be in the kernel and is sliding out into files [11:56] apw: yes, because then we'll suddenly need all the firmware in the initramfs [11:56] 11M /lib/firmware [11:56] which is larger than the initramfs itself! [11:57] surely compresses good :P [11:57] ogra: why, it's binary blob? [11:57] i am never quite sure why we don't only put in the ones we need [11:57] into the initrd [11:57] Keybuk, thus the ":P" [11:57] given it is rebuilt for every machine [11:57] apw: because the kernel never bothered to add any header to a module to list the associated firmware files? :) [11:58] so we can't actually *tell* what firmware files we need [11:58] and instead would have to maintain a list by hand, to go with the by-hand list of modules [11:58] heh now thats a valid arguemnt if there ever was one [12:08] apw: we've also long had a general design goal to make disks portable across hardware - that is, if you replace some components in your computer, your Ubuntu installation shouldn't fail to boot, and you should even be able to boot the system on a totally different computer to some reasonable extent - think USB disks [12:08] apw: which is why we don't use the MODULES=dep initramfs building mode by default [12:09] i have wondered at times if it would make sense to use the current mode for the recovery boot, and a =dep mode for the initrd for the default entry [12:09] loading the initrd is pretty slow generally [12:34] apw: not really, the fallback case isn't pretty [12:34] ie. if we can't mount the filesystem, then we can't write the magic that tells grub to try recovery mode next time [12:34] indeed it would be manual i guess [12:46] more interesting would be if grub could somehow set that itself [12:51] ie. after any menu selection, it remembers that the *next* time it must always use the equivalent recovery mode [12:51] a successful boot overrides that [12:58] the problem is storing that needs [13:31] apw: are you dropping EXTRA_CFLAGS from Karmic ubuntu/compcache/Makefile ? [13:32] i hadn't looked at them, that does seem odd [13:33] want me to do that [13:33] apw: I forgot to look at the package from the buildd, but did compcache actually get compiled? [13:34] no cause i missed half the fix when committing somehow [13:34] its in there as of 1 minute ago and is build tested [13:34] apw: ok, as long as you're mucking around in it, why don't you also fix EXTRA_CFLAGS [13:34] yep will do, and i'll shove it into my PPA to build test === smb changed the topic of #ubuntu-kernel to: Karmic Kernel Plan: 2.6.31 -- Kernel Team Bug Day https://wiki.ubuntu.com/KernelTeam/BugDay/20090707 [13:35] apw: doh! CONFIG_TLSF. what a dunce I am. [13:36] how stupid do i feel having seen it, then not noticed it was missing from the commit [13:36] apw: I'll bet I spent an hour messing with that Kconfig [13:36] its in the one above ... which is confusing [13:41] the power of 20-20 hindsight [13:49] apw: it looks to me like *everything* exploded [13:49] I'm going through that "out of warranty" vs. "not fit for purpose" battle :) [13:49] Keybuk, heh ... been connecting mains to the wrong end again? [13:50] always loads of fun indeed [13:50] of course, I've already found and bid on a replacement unit on ebay [13:50] but I like arguing with companies [13:50] waht was it before it exploded, it looks very industrial [13:50] apw: Creative/Cambridge SoundWorks S750 [13:50] THX 7.1 amp [13:51] wow ... you must like your sound [13:51] this is the baby for the office [13:51] I have a real amp connected to the tv/blu-ray downstairs :) [13:51] my neighbours ... do not like my sound [13:55] heh uk houses are not well designed for anything over a pin drop often [13:55] Keybuk, you tested that devramfs thing and it worked iirc, is that coming downstream? [13:56] apw: it worked well enough that we found udev bugs as a result ;) [13:56] ie. devtmpfs is better than udev [13:56] it's in gregkh's tree at the moment [13:56] heheh [13:56] I may ask you to pull it early if it doesn't look like it'll hit .31 but definitely .32 [13:56] it's self-contained enough that it shouldn't be a problem [13:57] yeah its pretty self conftained, though i guess it'd be in .31 if it was going to be [13:57] its not exactly a bug fix :) [13:57] I'm never sure how the merge window works [13:57] in theory once the window closes (when -rc1 ships) no new functionality should be commited [13:58] right, which means it's already not in .31 right? [14:00] I never quite understand how things work wrt mm [14:00] if a patch is "added to the mm tree", how does that then end up in Linus' tree? [14:04] Keybuk: *maybe*, if it is baked for enough time and gets ACKs from some key developers. [14:05] yeah on the flip side it _was_ in linux-next [14:05] and that means it was meant tomake .31... so hard to tell [14:05] there have been instances of stuff being dropped from -mm after a while [14:05] can tell cause steven is bitching that its still there [14:05] and -next should in theory go to 0 [14:12] apw: steven ? [14:12] I assume that "its still there" => devtmpfs? [14:13] rothwell who runs linux-next, yep devtmpfs is still in the meant for the release pile [14:13] yet not merged [14:14] * Keybuk wonders how Jan and Val are getting on [14:15] last conversation i saw, there was a serious locking issue which needs a rearchitect to fix. so i am not expecting it to be ready any time soon frankly [14:15] we need to start thinking about a fallback position [14:16] i am guessing we still have aufs support out there in our tools [14:19] we have the unionfs fuse implementation [14:19] that seems to vaguely work [14:19] i thought performance was poor [14:22] sure [14:22] poor performance > nothing [14:22] especially if we know we have something better still down the line [14:27] one day I'll meet the guy who came up with /var/run/utmp and /var/log/wtmp [14:28] and if I'm lucky, I will have a chainsaw [14:33] you think he is a lumberjack and need some device to start a conversation ? [14:46] Keybuk, was it you who has the machine that had particularly sucky performance under very high IO load? [14:46] yes [14:47] if so you might want to test the 31-2.16 kernel, as i have it on my machine and it seems much better. there are some reclaim changes which are supposed to help keep binary pages in core [14:47] which is fingered for the huge 'delays' where apps grey out under compiz [14:52] apw: Kay seems very confident that devtmpfs will be in for .32 [14:52] oh, interesting [14:52] is that on the archive now? [14:53] yes, any of those on the archive has the fix (for karmic) [14:53] i am building in the background here and not spitting feathers [14:54] ok installing [15:08] Keybuk: is the gateway command in /etc/network/interfaces still valid in Jaunty? Mine seems to have stopped working, yet all of the other static address setup commands are correct. [15:09] rtg_: don't see why not [15:10] damn, its the last statement in the file. I've tried several times to get it to set a default route. wonder what gives? [15:43] > [15:43] > Ubuntu Kernel Team Meeting Announcement [15:43] > Today at 17:00 UTC in #ubuntu-meeting [15:43] > [16:33] Keybuk: grub/recovery mode> that should be feasible with grub2 [16:36] Keybuk: there are load_env, list_env, and save_env commands; you give them a preallocated file to scribble in [16:36] sure, but that only works once you've got a file to scribble in ;) [16:37] if you can't mount the root filesystem, how do you scribble? [16:37] right, this only works if grub itself can mount the root filesystem [16:37] but if you can't mount the root filesystem, recovery mode is no use anyway! [16:38] and there are certainly cases where grub can manage to load the kernel but the initramfs fails for some reason [17:26] right, if the file is in the /boot directory we know grub can handle that dir, else it cannot load either itself nor the kernek === bjf_afk is now known as bjf [17:59] > [17:59] > Ubuntu Kernel Team Meeting Announcement [17:59] > Starting now in #ubuntu-meeting [17:59] > [17:59] scary [17:59] :) === ogasawara_ is now known as ogasawara [18:22] cjwatson, the majority of the recommendations on that ssd blueprint was to use ext4 which you have already done, the other part was about partition alignment [18:23] yes, partition alignment is fairly non-trivial [18:23] I'm familiar with the issue from a previous mail thread [18:23] mostly it depends on a newer parted that's unlikely to be released in time for karmic [18:24] using fdisk is totally unacceptable [18:24] (in the installer at any rate) - it's very dependent on parted [18:24] I'd like to deal with the alignment thing, certainly, just not sure when we can === sconklin is now known as sconklin-brb [18:28] an ext4 no journal option would probably be a good thing to add to the installer for SSDs === sconklin-brb is now known as sconklin [18:36] Sarvatt: is that a mke2fs or mount option? [18:37] and is it supported with the kernel/e2fsprogs combination we have? [18:39] mkfs.ext4 -O ^has_journal [18:39] yeah its supported by karmics, not jaunty's though of course [18:41] hmm, there's nothing generic I can hook into, will take a bit of work [18:41] it was introduced just after e2fstools 1.41.4 [18:41] somebody should file a bug on partman-ext3 for it I think [18:41] http://git.kernel.org/?p=fs/ext2/e2fsprogs.git;a=commit;h=a90f5391dda78f7bc4a8196a78355584ace0adf5 [18:46] its nice that e4defrag works now on .31, just defragged 700k files on a drive i converted from ext3 [18:51] apw,cking: unionfs-fuse is I think barely acceptable, but I'd *much* rather have something in-kernel [18:51] it's very much a last resort in my book [18:51] cjwatson, ok ... thanks for the input === pace_t_zulu is now known as pace_t_zulu|afk [19:17] kernel bug day? [19:18] apw, unionfs-fuse isnt acceptable for ltsp (where we use union mounted squashfses as well) [19:20] apw, it puts thin client boots into a 4 - 5 min zone [19:20] ogra, thanks for that also === pace_t_zulu|afk is now known as pace_t_zulu [23:34] hi ogasawara sorry it took me so long to get here [23:34] :) [23:34] JFo: what's up, glad you made it [23:34] just busier than I thought I would be today [23:34] glad to be here [23:35] JFo: have you had a chance to browse through the bug day list - https://wiki.ubuntu.com/KernelTeam/BugDay/20090707 [23:36] so I see the bug list and I assume that the name above each group is the assigned engineer for those particular bugs? [23:36] I have :-D [23:36] JFo: correct, there is a community section towards the bottom for anyone else interested in helping [23:36] ok [23:37] JFo: we can also go through some simpler types of bugs first though if you like [23:37] that sounds good [23:37] I'd like to understand a bit more before I dive in [23:37] JFo: right, gimme a sec to get a list of good starter bugs [23:37] ok :) [23:41] interesting, I logged in to Launchpad, but it looks like I am not logged in when I view the kernel bug pages [23:41] I suspect that may be due to some permission I lack [23:41] or team that I am not yet a part of [23:41] hmmm [23:41] * JFo goes digging [23:41] JFo: no, it's because I stole the lp template for the bug page [23:42] ah hah :-) [23:42] everything becomes clear [23:42] this is a listing you have created just for this purpose I assume? [23:43] JFo: correct [23:43] that explains the missing icons [23:43] :) [23:46] JFo: ok, lets just start with bug 177026 [23:46] Malone bug 177026 in linux "palm z22 won't sync" [Undecided,New] https://launchpad.net/bugs/177026 [23:46] ok [23:47] JFo: what happened recently is we transitioned quite a bit of bugs from linux-meta to the linux package [23:47] I see [23:47] JFo: You'll see that the bug was reported quite some time ago (2007-12-17) [23:48] indeed [23:48] so we need the standard response to check this against Jaunty? [23:48] JFo: yes! [23:48] or am I skipping ahead? [23:48] cool [23:48] JFo: so, if you want, go ahead and post a comment asking them to test Jaunty [23:49] ok [23:49] JFo: I think the bug day page may have a stock reply you can use [23:49] JFo: of course you'll then set the status to Incomplete at the same time [23:49] right [23:49] the bug page does have a reply [23:49] first one I believe [23:50] JFo: that's the one, go ahead and just copy and paste it [23:50] got it. [23:50] where do I set as incomplete? [23:51] Update description/tags? [23:51] JFo: if you click on the current status on the Status column it should expand for you [23:51] ah [23:51] JFo: in there you can add your comment and update the status all at the same time [23:52] excellent [23:52] JFo: since you are not a member of ubuntu-bugcontrol yet there are some Status' you will not have the permissions to set [23:52] done [23:52] I see, what are those? [23:52] JFo: for ex Won't Fix and Triaged [23:52] ah, ok [23:52] that makes sense [23:53] ready for the next one :) [23:54] JFo: cool, lets just make the next logical progression and handle some Incomplete bugs [23:54] ok [23:54] JFo: take a look at bug 84898 [23:54] Malone bug 84898 in linux-source-2.6.20 "After resume, video playback is order of magnitude slower than normal" [Medium,Won't fix] https://launchpad.net/bugs/84898 [23:54] got it [23:54] JFo: I forgot one thing, if we can backtrack just a sec [23:55] sure [23:55] JFo: when a bug is set to Incomplete it obviously indicates it needs more info [23:55] right [23:55] JFo: when I set a bug to Incomplete I usually also subscribe to the bug [23:55] ah, good point [23:55] JFo: that way when they do provide the information, I'll be notified [23:56] and that bug can be moved forward [23:56] JFo: right. I usually just tick the checkbox "Email me about changes to this bug report" [23:56] I see that [23:56] ok [23:57] JFo: alternatively you can click on the "Subscribe" link on the right hand side of the bug [23:57] ok [23:57] JFo: ok, no onto the next bug [23:57] k [23:57] I see this one is a WontFix [23:57] for one package [23:57] and Incomplete for another [23:58] JFo: right, a while back the kernel package naming convention changed from "linux-source-2.6.xx" to just "linux" [23:58] so this one may still be WontFix? [23:59] JFo: actually it was Won't Fix against the 2.6.20 kernel (because it's past it's End of Life) [23:59] I should have seen that [23:59] JFo: it could very well still exist against the current kernel [23:59] ok, so for the new version of the Kernel we need it tested against the Jaunty release [23:59] I see [23:59] JFo: right [23:59] ok [23:59] so same as before?