=== JanC_ is now known as JanC [01:44] I just noticed that the builds from http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.31-rc5/ do not have CONFIG_MEDIA_SUPPORT set, which makes it harder to test anything webcam-related. [01:45] Should I report it somewhere? === mdz_ is now known as mdz [10:16] howdy! [10:17] I'm wondering what is the correct syntax for declaring the framebuffer size on grub cmdline, these days? vga=794 no longer works, it seems. [10:18] have we reverted to hex values again? [11:15] Keybuk, hey ... floppies ... do you think its reasonable to automatically scan those for partitions? or more specificially do you think its unreasonable to not scan them? [11:17] err, floppies can't have partitions [11:17] Q-FUNK, i've alway seen hex used, i have also seen vga=ask which lists them and lets you select [11:17] they really can [11:17] no they can't [11:17] they have an mbr, therefore they can have a partition table, as far as i know [11:17] but i am happy to hear scanning them is stupid in your opinion :) [11:18] actually that's not correct ;) [11:18] floppy disks have a volume boot sector [11:18] please educate me, it not being possible is very handy [11:18] not an mbr [11:18] apw: found the solution. it just seems that fbdev used to be compiled-in on ubuntu kernels. not anymore. plus, it's blacklisted in some modprobe.d config. [11:19] öö.. vesafb [11:19] apw: just to confirm [11:19] we're talking about the legacy floppy controller here [11:19] not IDE or SCSI "floppy" drives, right? [11:19] yes, the legacy isa one, not scsi etc [11:19] you don't mean ISA do you? [11:19] hard-wired one? [11:19] i mean the crappy old one most of us don't have :) [11:19] right [11:20] so i think thats the cause of the boot delays, devkit-disk is running on the floppy [11:20] really? [11:20] and trying to find the partition table, even when there is no media, and its takign 48 seconds [11:20] that's probably [11:20] i had someone time it, 48s to run devkit-disks on it [11:20] that devkit-disks rules is causing a *lot* of problems [11:21] (this is the case when you dont have a floppy drive) [11:21] cool. then i think i can simply justify skipping those checks on a floppy [11:21] yeah [11:21] talk to upstream though [11:21] don't patch the rules locally [11:22] upstream being debian i assume [11:22] no [11:22] upstream being devkit-disks upstream [11:22] we have a strong policy of not shipping modified udev rules for any of the plumbing layer [11:22] oh are the rules coming from there... hrm [11:22] ok ... [11:23] https://bugzilla.redhat.com/show_bug.cgi?id=489083 [11:23] bugzilla.redhat.com bug 489083 in DeviceKit-disks "devkit-disk tortures my good old floppy drive" [Medium,Closed: errata] [11:24] looks from that like davidz is quite happy with the "ignore legacy floppy" approach [11:24] and this is just an omission [11:25] interestingly [11:25] in 60-persistent-storage.rules: [11:25] KERNEL=="fd*|mtd*|nbd*|gnbd*|btibm*|dm-*|md*", GOTO="persistent_storage_end" [11:25] but in 95-devkit-disks.rules: [11:25] KERNEL=="mtd*|nbd*|gnbd*|btibm*", GOTO="probe_parttable_end" [11:25] so they don't quite match [11:25] I'll chat to David when he wakes up [11:26] Keybuk, thanks [11:26] yeah my proposal was to add fd* to the latter one [11:27] right [11:27] that would be the fix [11:27] let me get it fixed upstream though ;) [11:27] fair enough for me [11:27] less work :) [11:27] i should mark the bug for devkit-disks i guess ... will do that [11:28] yup [11:43] Keybuk, done [13:24] Two quick questions: 1. Why is the AHCI and ATA drivers compiled directly into the kernel in 9.04 Server, and 2. Is there a way to change the order in which these drivers are loaded? I could do this with modules in the past but I have yet to determine if it's possible when the drivers were compiled directly into the kernel. [13:33] who is our squashfs expert? [13:33] I've got a problem with the fsl live image: http://pastebin.ubuntu.com/252472/ [13:33] amitk, apw did the port [13:34] squashfs had to be ported? [13:34] well, integrated I guess [13:34] * apw looks up... huh? [13:35] that pastebin think looks like there is no filesystem? [13:36] apw: squashfs, bug, http://pastebin.ubuntu.com/252472/, clue? [13:36] SQUASHFS error: squashfs_read_data failed to read block 0x0 [13:36] it panicing after a read error might be reasonable [13:36] where is the squashfs stored? [13:36] vfat partition [13:37] on mmc [13:38] rtg squashfs went upstream didn't it? [13:38] it was compcache i ported [13:38] apw, uh, right. I was confusing it with AUFS [13:45] amitk, ogra that error is nearly useless it can mean one of at least 5 different failures [13:45] probabally a decompression failure [13:46] how do we build these squashfs things? [13:46] a simple mksquashfs [13:46] do we have a userspace tool to check its integrity like we do with initrds? [13:46] apt-get source livecd-rootfs ... see the bottom of the livefs.sh script [13:47] mksquashfs ${ROOT} livecd.${FSS}.squashfs -sort livecd.${FSS}.sort [13:47] chmod 644 livecd.${FSS}.squashfs [13:49] ogra, i guess the first test is to pull the MMC and see if you can successffuly run unsquashfs on it [13:49] * ogra does so [13:51] there is no real error before to say it failed to load anything [13:54] hmm, trying to unsuqsh on i386 doesnt work so far [13:55] http://paste.ubuntu.com/252484/ [13:55] * ogra copies the file over to an arm board [13:56] takes a moment ... [13:57] squashfs data shouldn't really be arch-specific, should it? [13:57] no [13:57] hi [13:58] amitk, but to be sure i'll try it anyway, the squashfs was built on armel [13:58] though it will take another 10min to copy [13:58] if I need to build a kernel from vanilla for some reason, how to initialise the source tree so I have all the build scripts in debian/ etc? [13:59] krgn: you could just use the pre-built vanilla kernels if you don't need extra patches [14:00] amitk: I do need extra patches though [14:00] amitk: is there a script that creates debian/ ? [14:01] krgn, start here: https://wiki.ubuntu.com/KernelTeam/KernelMaintenance [14:03] amitk: thanks for the link [14:07] krgn: you could also look at https://wiki.ubuntu.com/KernelTeam/MainlineBuilds?action=show&redirect=KernelMainlineBuilds and just download the source .deb of the last mainline build [14:09] amitk, though i shouldnt get an oops (i dont get one on i386) even with a corrupted fs [14:10] i can properly reproduce the oops with mount -o loop -t squashfs filesystem.squashfs /cdrom ... in the initramfs [14:11] ogra: that bug should go upstream through kerneloops/apport [14:11] complicated :P [14:12] we dont have kerneloops in initramfs [14:12] I can see the same issue trying to mount the squashfs on my laptop [14:12] and it triggers kerneloops ;) [14:15] it would be interesting to see how the armel liveimage squashfs differs from the i386 [14:16] ogra: ^ [14:16] OH ! [14:16] ogra@dove:~/temp$ file filesystem.squashfs [14:16] filesystem.squashfs: Squashfs filesystem, little endian, version 4.0, 179630923519 bytes, 113897 inodes, blocksize: 41 bytes, created: Sun Jan 15 06:02:56 1967 [14:16] thats pre-epoch [14:17] heh [14:17] i wonder if that has any influence [14:17] it definately shouldnt but you never know [14:17] I guess I should refuse to work on things that were created before I was born ;) [14:18] heh [14:21] ogra: BTW squashfs isn't oopsing. It is a warning. [14:21] cant they make their warnings look like warnings ? [14:22] its confusing to have a stacktrace in a warning [14:22] they do, WARNING: at /build/buildd/linux-fsl-imx51-2.6.31/fs/inode.c:699 unlock_new_inode+0x40/0x4c() [14:22] yeah, but attach a stacktrace below [14:32] apw, I'm having a brain fade. How do you get the SHA1 of HEAD for the branch you are on? [14:32] git show has it [14:32] to get just the raw one there is a command [14:33] git show-ref HEAD [14:34] hmm not sure that does what you might hope [14:34] apw, ah, thats it. [14:34] hmmm no thats not getting the right head [14:35] apw, 'tis for me [14:35] whats the second word tho. [14:35] on mine its a remote ref [14:35] 73aa74e5a55563ac54c161f307f8fc282a8f4e47 refs/remotes/origin/HEAD [14:36] you're right, but its OK in my case. [14:36] I guess you could always 'git log |head -n1 ...' [14:37] apw@penfold:~/git2/ubuntu-karmic$ git log --pretty=format:%H HEAD^..HEAD [14:37] 3844ea1e7161a8883a1a52b7b176d5f6c29be463 [14:37] looks to me one way [15:21] amitk, ogra, so is this really a squashfs kernel error or not? [15:21] cking, i start to suspect its userspace induced [15:22] i cant loop mount the squashfs anywhere nor can i unsquash [15:22] it's not some weird endianess issue? [15:22] we didnt have endianess issues in jaunty [15:23] it was the very same script we used to build images [15:23] just with squashfs-tools 3.0 [15:23] or 3.3 or whatever [15:23] while we use 4.0 now [15:24] ARM specific or a generic issue? [15:24] works on the ubuntu livecds and i guess also on UNR vfat images [15:32] ogra, hrm, so unsquashfs failed too? at least the kernel isn't going mad [15:32] right, mount fails as well as unsquashfs [15:33] i'm just rebuilding the image on the build servers to see if it was a temporary hiccup or something [15:33] i'll also rebuild one locally [15:33] ogra, sensible but a bit scarey [15:39] apw, I'm getting audio clicks after ~10 seconds of not using audio on karmic on my HP mini - you referred to this a while ago - do you know what the workaround is? [15:40] thats the amps going off, there is new code to do that, power them down to save power [15:42] bug #380892 is where it was turned on and lists how to supress it [15:42] Malone bug 380892 in alsa-driver "[9.10 regression] HDA power_save=10"" [Undecided,New] https://launchpad.net/bugs/380892 [15:42] cking, thats the patch I showed you while in Dublin [15:43] rtg, of course, that's the one - I'm kind of fuzzy headed at the moment - I'm pain killer'd out and had a tooth worked on earlier today ;-) [15:44] cking, dude - you should be napping :) [15:45] maybe in a couple of hours :-) [15:45] anyhow, the pain in the mouth has gone so that's a result! [15:48] cking, heh ... its funny how good one feels when a pain you had is gone [15:49] of course in your case the pop is thought to be a known issue with your specific lappy, so we don't want to fix it generally [15:50] I think there could be a work around by tweaking the EAPD pin and waiting 250ms.. hrmm.. [15:53] ogra, new crack in the Karmic Dove branch, rebased against -rc5 [15:54] cool [15:54] i'll update my local stuff soon then [16:11] cking, ? i thought we always did that (the turn offy wait thing) [16:15] apw, not sure for karmic. [16:15] * cking goes and has a peep [16:15] i think i've missunderstood, i though the EAPD thing was a std and supported ... clearly not [16:16] * cking does some vague handywavy statement : possibly, it depends. [16:16] * apw adds cking to ubuntu-audio, *whistles* [16:16] no - taint me not [16:17] toooooo late [16:17] humbug [16:20] apw, we probably should add the clicky audio pop power check to those manjo tests [16:21] yeah how would one test that i wonder [16:21] make a sound, wait 20 seconds, "do you hear a pop?" [16:22] heh yeah i guess so [16:22] * apw notes that firefox has become a crashy pos today, and i didn't even update it [16:23] Must be the flash-tastic sites you're looking at [16:23] freshly started no flash [16:24] Hrm. I'm now on 3.5.2 - it's been as solid as the previous 3.0.x version [16:25] 3.0.13, and its new behaviour today. and as far as i know i've not installed any fixes [16:26] if only one had "apt-unget yesterday" === JanC__ is now known as JanC [16:56] carefully applying all the audio patches that dtchen suggested did not fix sound on xps1300 [16:56] 1330 [16:57] probably be less careful ? [17:03] * manjo plugs ogra's babbage 2.5 board into the network and watches it die [17:04] :P [17:28] apw, what's the story behind the broadcom b43 driver on Karmic - where can I peek at the driver? [17:29] cking, hrm which one is that. there are so many broadcom ones [17:29] is that the one which drives BCM43xx devices? [17:29] the one on the mini for instance? [17:30] That's what I'm confused about. I've just installed karmic in a HP mini 1000 and it's grumbling at me. [17:30] and not working? [17:30] there seem to be three options [17:30] ..yep - no workies. [17:30] there is b43 and b43legacy in the kernel [17:30] 3 options(!) [17:31] plus there is bcmwl-kernel-source which is a dkms thingy which carries some binary blob [17:31] that is the one which works on my mini10 [17:31] 03:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g (rev 01) [17:32] how does one get the bcmwl-kernel-source installed? [17:33] i installed it by hand using apt-get i think [17:33] bit tricky w/o a network connecton [17:33] i think that was sufficient, reboot required i think [17:33] i used an ethernet cable to install it [17:33] that don't work either. This is a tad regression bound at the mo [17:33] a usb stick for someone at sprint [17:34] i just got the .deb from the pool and shoved it on [17:34] OK. That's a cunning plan [17:34] * apw looks up cunning ... hmmm [17:38] * cking wonders how the average punter is gonna handle this [17:42] has anyone seen this before? [17:42] /usr/bin/ld.real: kernel image bigger than KERNEL_IMAGE_SIZE [17:44] zul_, not seen that no [17:44] cking, they arn't [17:45] thats why oem ship their own installs [17:45] cking, so any idea what an ssb id is ? [17:45] what's the context? [17:46] the b43 driver is using ssb ids for matching not pci vendory things as normal [17:46] looks to be some kind of bridgey thing [17:47] yeah "b43: probe of ssb0:0 failed with error -95"... [17:47] is that from the default kernel modules? [17:47] yep. use the source luke [17:47] now i am lost as i don't have an lsssb -nnvv to get them [17:50] * apw is using the source and getting moany :) [17:50] cking, i wonder if lbm would help here, as it has wireless more up to date in it [17:51] maybe [17:51] that might be worth a go [17:51] urgh.. running out of time.. [17:51] * apw looks at the lbm to see what it has in it [19:19] hey all [19:20] I have the following scenario: I have a vanilla source tree but use the debian/ dir from karmic git [19:20] actually I get this error too with jaunty [19:21] but when I execute debian/rules binary-generic or binary-arch it just tells me that binary-generic isn't defined [19:21] make: *** No rule to make target `binary-generic', needed by `binary-debs'. Stop.