[03:54] is there any easy way to throttle back how many scsi requests the kernel queues at any given time? [03:57] lamont: I thought there was a queue depth argument, but my very faded memory says it was driver-specific [03:57] 3w-xxxx [03:58] hmpf, modinfo doesn't show anything [03:58] color me silly, but swraid6 over 4 drives, currently has 2 of 4 live, recovers one to get to 3, starts down recovery for #4, and one of the 3 fails during that with request timeout type errors [03:59] ew ew [03:59] yeah - it's getting kinda boringly cool [04:00] 3844114304 blocks level 6, 64k chunk, algorithm 2 [4/2] [UU__] [04:00] [>....................] recovery = 0.1% (3679104/1922057152) finish=996.2min speed=32092K/sec [04:02] * lamont adjusts the raid speed limit max downwards [05:17] Dec 16 16:57:32 corn kernel: [40415.519987] 3w-xxxx: scsi3: Command failed: status = 0xc7, flags = 0x1b, unit #4. [05:17] so what's that mean === JanC_ is now known as JanC === diwic is now known as diwic_afk === diwic_afk is now known as diwic [14:01] Sarvatt, you around? [14:04] tseliot, are you aware of bug #566437 [14:04] Launchpad bug 566437 in fglrx-installer (Ubuntu Natty) (and 1 other project) "package fglrx 2:8.723.1-0ubuntu2 failed to REMOVE: error exit status 2 - dpkg-divert: mismatch on package - while removing the package (affects: 112) (dups: 27) (heat: 431)" [High,Triaged] https://launchpad.net/bugs/566437 [14:05] tseliot, seems to have appeared on the release team radar for natty all of a sudden [14:06] apw: err.. I haven't used diversions in my packages since hardy (if I remember correctly) [14:07] tseliot, oh hrm ... [14:07] tseliot, so it is unlikely its valid any more? [14:07] apw: wait I guess that was lucid, not hardy [14:07] apw: so that's something left by his Karmic installation [14:07] so it would be a lucid issue reproducible in maverick only then [14:08] oh a karmic issue in theory not reproducible later than lucid then [14:08] tseliot, though in comment #18 somone is claiming to be on maverick [14:08] apw: I guess we still try to remove that diversion though (so as not to break dist-upgrades, in theory...) [14:11] tseliot, so i'll phrase it that way then [14:11] apw: I'll have a look at it. Thanks for bringing it to my attention [15:02] apw, tgardner: any quick advice on http://launchpadlibrarian.net/60798677/buildlog_ubuntu-natty-i386.netcfg_1.57ubuntu3_FAILEDTOBUILD.txt.gz ? [15:03] doko, is that new ? [15:04] doko, and is that building in the archive or a PPA ? [15:04] apw: today's sync from unstable [15:04] doko, these headers seem familiar, like we fixed something for them [15:05] i wonder if a work around is still in place in that package which is no longer appropriate [15:05] doko, specifally is there an ubuntu fix changing the net/if.h include to something else or similar ? [15:06] doko, if you can point me at the build record itself with the package source and diff i may be able to answer my own questions [15:06] apw: https://launchpad.net/ubuntu/+source/netcfg/1.57ubuntu3 [15:07] doko, well that upload does contain a revert for a workaround ... [15:10] apw: ahh, wait, cjwatson did upload, not a sync. so I'll wait a bit ;) [15:10] doko, yeah [15:20] I reverted a patch which was supposed not to be needed any more [15:20] and it built fine locally [15:21] it does look like another double-inclusion bug, but why can't I reproduce it here I wonder? [15:23] cjwatson, i can't see why it would occur either [15:23] as i cannot find anything which triggers the linux/if.h include [15:25] cjwatson, and the headers do seem to be updated correctly in the build [15:28] cjwatson, on my system with the headers installed the 'fix' for the original issue is in place correctly [15:28] right, I did actually compile-test it before uploading :) [15:33] cjwatson, i am confused by the error as the bug we fixed (which looks the same) was triggered by an include of linux/rtnetlink.h [15:34] cjwatson, indeed i am at a loss as to how linux/if.h has been included, but it must have occured before [15:37] is there a way I can interrupt boot or modify grub args to boot into a busybox shell? I want to poke around the initrd world. [15:38] bfallik, yeah there is, there is a way to stop in the initramfs in a number of places [15:38] ubiquity fails in the same way, of course [15:38] bfallik: https://wiki.ubuntu.com/DebuggingKernelBoot [15:39] cjwatson, gurgle [15:39] apw: it incorporates a copy of netcfg so it's not surprising [15:40] thanks [15:45] cjwatson, ok i can reproduce this here ... trying to debug [15:47] In file included from /usr/include/iwlib.h:56:0, [15:47] from netcfg-common.c:26: [15:47] /usr/include/linux/if.h:1:2: error: #error wibble [15:47] cjwatson, ^^ seems that iwlib.h is to blame [15:48] #include /* for "struct sockaddr" et al */ [15:48] #include /* for IFNAMSIZ and co... */ [15:48] /* Glibc systems headers are supposedly less problematic than kernel ones */ [15:48] how come it doesn't break locally though? [15:48] those two are commented as above ... [15:48] (going to have to write up stuff for release meeting now) [15:49] cjwatson, it breaks locally for me in a natty-amd64 chroot [15:49] I'll have a look later then [15:54] cjwatson, if i change the linux/if.h to net/if.h in iwlib.h then things compile ... no idea if that is a reasonable change though [16:00] apw: I don't know - feel free to upload if you think it's likely to improve matters [16:07] cjwatson, still looking at it, but the meeting gets in the way [16:10] yeah === Sarvatt_ is now known as Sarvatt [17:27] cjwatson, ok back at this thing ... [17:27] cjwatson, i think that this sounds like the issue getting introduced [17:28] wireless-tools (30~pre9-3ubuntu5) natty; urgency=low [17:28] * header-with-2.6.36.patch: Replace the if.h header used in iwlib.h by [17:28] the one provided by the kernel instead of using the one from libc. The [17:28] kernel headers now provide the same structures and linux/if.h would [17:28] otherwise conflict, since it gets pulled in from wireless.h. (LP: #672584) [17:28] -- Mathieu Trudel-Lapierre Tue, 09 Nov 2010 15:29:06 +0000 [17:28] wireless-tools (30~pre9-3ubuntu5) natty; urgency=low [17:28] * header-with-2.6.36.patch: Replace the if.h header used in iwlib.h by [17:28] the one provided by the kernel instead of using the one from libc. The [17:28] kernel headers now provide the same structures and linux/if.h would [17:28] otherwise conflict, since it gets pulled in from wireless.h. (LP: #672584) [17:28] -- Mathieu Trudel-Lapierre Tue, 09 Nov 2010 15:29:06 +0000 [17:31] cjwatson, what i cannot tell from the description is whether its no longer necessary now the other bug if fixed or not [17:42] cjwatson, ok looks like that package is a bit of a mess, am working on getting it to compile since the compiler changes [17:42] hm, right, maybe that should be reverted [17:42] cjwatson, pointeless for us both to work on it [17:42] not too sure [17:42] yeah, indeed [17:42] thanks [17:42] cjwatson, well it claims its to maek the package build [17:42] but that was before your linux-libc-dev fix [17:42] so am trying to confirm that, and now its not anyhow :) [17:42] right so i think it can be reverted but to confirm i need to fix the link issues the new compiler has introduced in it [17:42] sigh [17:43] cjwatson, and its good experience for me to work on non-kernel [17:45] * cjwatson wonders if there's a better way for plymouth to spot nouveau substituting itself for vesafb than just listening for all uevents and looking for fb0 being removed/added [17:46] there's a custom fb notification chain thing in the kernel, but it seems to be internal AFAICS [17:46] cjwatson, that is a difficult question [17:46] fb0 removed => plymouth hide-splash; fb0 added => plymouth show-splash doesn't seem *entirely* unreasonable as logic [17:46] I was just wondering whether it was the most efficient way to get that information [17:49] (and it probably means having /lib/plymouth/renderers/frame-buffer.so link against libudev, but hey-ho) [17:49] cjwatson, no as we may not keep up either [17:50] hmm? [17:50] no to which bit? [17:57] cjwatson, oh i mean we may be running against ureadahead so very slow to react [17:57] cjwatson, so we may not clear down immediatly not redraw then either, which may make the interaction a problem [17:57] cjwatson: so I have 2 machines screwed up before the grub kernel selection screens even come up, do you have any tips on how to debug it further? one reboots and the other hangs at GRUB loading after a warm boot 100% of the time [17:59] cjwatson, so if a package has no VCS: line do i assume what is in 'apt-get source' is the way to get the source to modifiy it [18:13] apw: I can't see how we can react faster than udev, really ... [18:13] Sarvatt: does holding shift at boot change anything? [18:13] Sarvatt: also 'grub-install --debug-image=all ' may make it (lots!) more verbose [18:14] apw: yes [18:14] cjwatson, ok ... would you be able to review a package for me? [18:14] apw: sure [18:14] cjwatson: just makes the GRUB loading message display, otherwise it just silently reboots/hangs. thanks a ton, wasn't having any luck finding that magic [18:15] cjwatson, so it seems that backing out that patch in wireless-tools seems to still allow it to build and fixes our dependant build [18:15] cjwatson, i have also had to fix a compile issue with it related to our new compiler [18:16] cjwatson, see chinstrap:~apw/sign/wireless-tools_30~pre9-3ubuntu6* [18:17] looks mostly fine though two things [18:18] (1) actually remove the header-with-2.6.36.patch file as well as removing it from series [18:18] (2) I think better link order would be: [18:18] $(CC) -shared -o $@ -Wl,-soname,$@ $(STRIPFLAGS) $^ $(LIBS) -lc [18:18] i.e. keep -lc after $(LIBS) [18:18] cjwatson, will test that now [18:25] cjwatson, ok moving -lc works, though i suspect its not needed given it worked with it in the wrong place too [18:26] i've dropped the patch, quite why quilt remove FOO doesn't remove the patch is a mystery to me [18:26] and pushed the updated packages to the same place [18:32] cjwatson, ^ [18:33] yep, that's fine, want me to upload? [18:35] cjwatson, sure, it needs a sponsor [18:35] done [18:35] cjwatson, i assume we'll have to re-upload the netcfg etc as well, but i guess you have that in hand [18:36] cjwatson, and thanks for your help [18:38] nah, can just mash retry on those [18:38] once wireless-tools builds [18:39] ahh of course they didn't publish [18:51] cjwatson, all built, be in the archive in an hour [18:56] cool