=== Appiah_ is now known as Appiah [11:48] hi, how to disable acpi-thermal when it is builtin? [12:15] Kano, it has a module param 'off' so you should be able to do that from the kernel command line [12:15] acpi-thermal=off? [12:16] more likely acpi-thermal.off=1 by the look of it, the prefix is a bit of a guessing game [12:16] hmm maybe even without [12:26] hi all, i'm building a custom flavour of hardy kernel, but i get an error on abi-check. abi-check-* target is looking for an old build: http://launchpadlibrarian.net/36256913/buildlog_ubuntu-hardy-amd64.linux_2.6.24-25.63~ebox1_FAILEDTOBUILD.txt.gz [12:26] any clue on how to fix this ? [12:26] disable all checks [12:26] custom-binary.d/README doesn't say anything about this [12:27] skipabi=true skipmodule=true [12:27] add that [12:28] Kano: where ? rules.d/ARCH.mk ? [12:28] apw: btw. since .32 the virtual build is broken when i compile generic-pae. i do not need it anyway but i dont get why [12:30] Kano: i think binary-custom.d/myfalvour/rules is the right place to do so, isn't it ? [12:31] bencer: i usually compile it manually [12:31] Kano: i need to build it on my ppa ... local builds are easier to workarround, yes :) [12:32] i think it is another file, apw should know it [12:34] for a PPA build putting it in the .mk will work just fine [12:34] bencer, The "normal" way to get around this is to download the abi files from the last build "./debian/scripts/misc/getabis 2.6.24 " [12:34] often those files are also available in the git report, if there is a startnewrelease commit [12:34] smb: i see, but to get this build on launchpad ? [12:35] of course you would also need to have not made any abi sensitive changes to prevent the checks still triggering [12:35] bencer, The last one in your case would be the latest that was build and released. [12:36] If you are using the latest repo, this would be 25.63 [12:36] (for which no startnewrelease has been done, yet" [12:37] i'm patching this kernel with l7filter ... [12:37] Its a bit of download as it pulls the binary packages of all kernels and arch [12:38] Can't say I know from my head how much this changes [12:38] thats likely to be an abi bumper anyhow, so you'd want to just turn it off [12:38] There could be a bumper as apw says [12:38] hi peoples [12:38] ok, going to switch off all these abi checks [12:38] i have a question about my nerdy webcam bug [12:38] does the upstart do at anytime again an slow boot to ctch things changed ? [12:38] catch [12:39] this would explain why my cam works one day and a few days later it doesnt [12:39] whenever you install new packages, you will find it does a ureadahead rescan which is slower [12:39] btw, i want the same config than the -server one, so i generated my binary-custom.d/myflavour/ARCH.config from config/ARCH/config + config/ARCH/config.server, is that right ? [12:39] ok that would explain why it worked yesterday again [12:39] iirc we did suggest this was possible [12:40] and i thought you were going to watch updates to confirm the pattern [12:40] apw: yeah but iam still confused [12:40] :D [12:40] apw: i cant exact tell you when it happpens [12:40] thats my problem iam watching it but cant get into the problem [12:40] ghostcube, but it is you that applies the updates, so you know if you did or not between each reboot [12:40] is it needed to install complete new files or is an update enough ? [12:40] bencer, For the ppa build it would recreate those again and actually build a server flavour too [12:41] by tracking that you can work out if its related to the update [12:41] so this would be the same if i update an package already installed ? [12:41] bencer, If you really want to force it to use server for both, you'd copy config.server to config.generic in the arch dir [12:41] or only a complete new one [12:41] any package install which includes updates to packages [12:41] ok i will check this today [12:41] and this week long [12:42] after the week i tell you again [12:42] havent got the time to last week [12:42] i have daily updates from an ppa so it should work [12:42] :) [12:42] bencer, Oh, actually sorry I missed that. Yeah, you would use the two to get that config for a custom flaour [12:42] ok :) [12:43] thanks dude, trying to build now with checks off on binary-custom.d/flavour/rules [12:44] * smb wonders... abi checks were done on custom flavours... [12:45] one presumes its failing on the main flavours cause the source is changed and those are not disabled? [12:45] bencer, are you disabling the main flavour builds? [12:45] apw: nope [12:45] ah ok [12:45] but i should, because i don't need them [12:45] yeah, then thats the reason [12:46] so if you are building the main ones and the custom the mains will fail if you don't disable abi there too [12:46] or drop tehm [12:46] usually the way custom binaries were done is to add a patch to modify the main code in there [12:47] then he may be ok [12:47] yep, but still compile time sucks with having all the other stuff in [12:47] and space as well [12:47] yes, ~3h [12:48] closer to 4 these days [12:48] and i don't need lpia builds neither ... i'll try to disable all these stuff once it builds [13:14] Nov 30 05:56:59 mmjgroup kernel: [218942.819621] IPv6: sending pkt_too_big to self <-- something to do with karmic on the same v6 network, or a recent hardy kernel update... why does hardy hate on the v6 so much? [13:15] lamont, not something i've heard of, smb? [13:17] first occurred Nov 1 23:43:57 local (-0800) [13:17] er, -0700 [13:17] not that I could give a good answer to that. beside ipv6 being sort of the bastard child of protocols and hardy sort of old [13:17] meh. lying. [13:17] smb: hardy has just short of 4 years of support. [13:18] and v6 is like 12 years old. [13:18] and yeah, definitely the bastard child [13:18] though everywhere not .us is caring about it more these days [13:18] so rather to do with karmic on same network, I would be guessing, that they might have increased some packet sizes. I know, not that we forsee all the interactions [13:18] * soren still doesn't care, fwiw :) [13:18] i am constantly amazed we've not been forced over to v6 [13:19] (nov 1 is as far back as syslog goes atm, even though there are older names - those are from june... go me) [13:20] Hm, that would speak against Karmic [13:20] apw: .us doesn't care about v6 for the same reasons that the rest of the world cares - 80% or so of the routable v4 IP space belongs to .us (wag statistics for the win) [13:20] heh a good chunk to ibm and mit [13:21] and from the efforts they put into making internet more "controllable" it does not seem they really spend much time on ipv6 [13:21] mine is a small chunk. tiny, even. [13:25] hrm... not quite lying - backups tell me that the messages began sometime between 01:14 and 23:43 on nov 1 [13:27] smb: the funny part is the 'to self' in that message... [13:28] lamont, yeah, sounds like something passing on to an internal if... ok, lets look what prints that [13:28] apw: I know of one company that owns an effective /7 [13:28] /7 wow [13:30] apw: well.. historical class A, then they merged with another class-A owner, and well... [13:30] but the blocks don't aggregate [13:30] still an allocation of epic proportions in this day and age [13:31] ibm has 9.x and uses one class C out of it for external addresses [13:31] hp has expanded beyond the /16 they used to use from their class A [13:32] hrm... given what I was doing then.... um, NFC what changed on nov 1. highly unlikely that I would have done a remote kernel upgrade [13:33] are they spamming the logs or sparse these new messages? [13:33] lamont, Hm, so the likely way to get there is trying to xmit a packet bigger than the mtu and the text seems to want to tell you that it also sends a pkt_too_big message to itself... [13:33] 4-6 per day [13:35] actually the message level is debug... [13:36] this AM: x6 @05:56:59, *4 at 05:57:00 [13:36] yesterday, *10 @04:44:25-26 [13:36] and 27Nov: *10 at 20:28:44-45 [13:37] it seems to like that 10-tap [13:38] Nov 30 05:56:59 mmjgroup kernel: [218942.819600] printk: 8 messages suppressed. [13:38] or maybe "more than 10-tap" [13:38] It might also happen for packets that are not allowed to be fragmented... [13:38] yeah 10 at a time is interestng, the text of the message implies we are telling ourselves off as we send [13:38] The whole good case is "if ((skb->len <= mtu) || ipfragok || skb_is_gso(skb))" (no idea what gso is) [13:39] apw, yep, so whatever is trying this should notice and back of in theory [13:40] so... consistent bit (across my sampled size of ... 2): postfix with a slew of v6 outbound traffic on the box in question [13:41] maybe pmtu discovery? [13:41] though "to self" kinda speaks against that [13:41] might be a logical explanation [13:41] there is a tunnel involved, so MTU is shortened [13:41] well, trying something huge, gets told off [13:41] then trying smaller, told off again [13:41] ... [13:41] until fits [13:42] heh. how much smaller,I wonder? [13:42] mtu on the tunnel (which does not exist on the machine that's bitching) is 1480 [13:43] it could also be once-each for the smtp daemons, too [13:43] the message definatly implies local tried to send a packet that won't fit in the mtu if the channel and is not fragmentable, a real response is sent to itself ... so an error should be generated [13:43] there is also a stat generated so we should be able to see the real counts [13:43] It compares against mtu... That would need something bigger than that and then it makes no sense again to try bigger on the same machine... [13:43] IP6_INC_STATS(net, ip6_dst_idev(skb_dst(skb)), IPSTATS_MIB_FRAGFAILS); [13:45] where does that show up in /proc? [13:46] possibly in /sys/class/net/ [13:48] maybe /proc as well if one would find the tree in the forest [13:49] {t,r}x_{packets,bytes} are the only non-zero things in /sys/class/net/*/statistics/* [13:50] /proc/sys/net/ipv6/ip6frag_secret_interval:600 [13:50] ^^ sure doesn't look all that secret... [13:50] lamont, :) heh no [13:51] lets hope the interval is not the secret [13:51] heh [13:51] not anymore [13:51] every box I look at, == 600 [13:51] so it must be the interval for regenerating the secret [13:51] heres hoping .. else kees will be hopping up and down [13:53] 14%, 12%, 13%... maybe cloning hardy, karmic, _and_ lucid kernels at the same time was not-so-smart [13:54] lamont, do you have a master linus tree? if you get one of those and git clone --reference linus ubuntu-foo [13:54] you will download _much_ less [13:54] oh! [13:54] they can share the objects in common that way ... but do not delete the linus tree :) [13:55] right [13:55] * lamont freshens his linus tree [13:56] would referencing ubuntu-jaunty speed up ubuntu-karmic? [13:56] (curious only - I plan to nuke -jaunty, so not gonna actually do it) [13:57] better never reference anything other than Linus [13:57] smb: point. [13:57] thats the only tree only going forward [13:57] afk for a few while the kernel fetches [13:57] (or better is never rebased) [13:59] smb: hey, thanks for the kernel building help [13:59] I was able to bisect the problem [13:59] and this is the result: http://bugzilla.kernel.org/show_bug.cgi?id=14700 [13:59] bugzilla.kernel.org bug 14700 in Power-Processor "Broken system because of a bad ACPI commit" [Normal,New] [14:01] akheron, Ah, you're welcome. And upstream already knows of that too. Perfect. :) [14:01] akheron, so which patch did i you add to confirm the fix, just the last one? [14:02] apw: originally I just reverted the commit mentioned in the bug report [14:02] hm, that looks strikingly like something I've seen before [14:02] I'll try the patch in bugzilla later today [14:02] have you ever tried a ubuntu 2.6.31-16 kernel? [14:02] no [14:02] let me quickly check [14:02] smb in our stable updates perhaps? [14:03] I got the impression this might be in there... [14:03] the bisecting took so long that I think it was -14 with which I found out that my machine doesn't boot [14:03] yep, seems like its there [14:04] akheron, https://launchpad.net/~stefan-bader-canonical/+archive/karmic [14:04] try that kernel [14:05] akheron, Do you have a lp bug open as well? [14:05] yes [14:05] https://bugs.launchpad.net/linux/+bug/481765 [14:05] Malone bug 481765 in linux "ACPI: After an upgrade to Karmic, the system hangs on boot" [Unknown,Confirmed] [14:05] smb, excellent we can tie the tat to the stable update [14:05] yup [14:06] smb: I'll try -16 [14:06] apw, but let akheron confirm that kernel does help him [14:06] akheron, thanks [14:06] but I don't have the machine in my hands right now [14:06] smb, indeed so [14:07] which commit in ubuntu-karmic fixes this? [14:07] or you think fixes it [14:07] ACPI: fix Compaq Evo N800c (Pentium 4m) boot hang regression [14:07] cannot find that one, has it been pushed out? [14:07] Its in the git repo on the master branch [14:08] i'm using git://kernel.ubuntu.com/ubuntu/ubuntu-karmic.git [14:08] still cannot find it [14:09] Hm, its in mine and it claims to be in sync with the remote one [14:09] apw, You find it? [14:10] commit 24b73c5eac1aa8cdee7271dcba9d2fb7fea488be [14:10] yep [14:10] don't search with the (...) bit of the title though [14:10] akheron, are you still on a checkout of your bisect? [14:10] else less doesn't find it [14:10] git log origin/mater [14:10] master [14:11] ah right [14:12] ok I found it [14:12] it's already there in -14.46 [14:12] my cpu family : 6 [14:12] so that fix shouldn't help with my problem [14:13] akheron, what model? [14:13] apw@dm$ git describe --contains 24b73c5eac1aa8cdee7271dcba9d2fb7fea488be [14:13] Ubuntu-2.6.31-14.46~18 [14:13] cpu family : 6 [14:13] model : 14 [14:14] the whole cpuinfo is attached in http://bugzilla.kernel.org/show_bug.cgi?id=14700 [14:14] bugzilla.kernel.org bug 14700 in Power-Processor "Broken system because of a bad ACPI commit" [Normal,New] [14:14] the patch seems to change behaviour for family = 6 and lowers the limit from 14 to 0f [14:14] for model [14:15] hm... [14:15] yes [14:15] and I guess it should change from 6/15 and upwards [14:15] err [14:16] ok, it would be the same in your case. probably even if you 14 is dec and those numbers are hex [14:16] it changes the behavior for 16/* and 6/14 and upwards [14:16] urgh, now I'll have to fly [14:16] smb, ok the patch you point to is _not_ the one in the upstream bug [14:16] its yet a further refinement [14:16] heh. my linus tree was ancient... now at 27% [14:16] are we talking about a different patch? [14:17] :) [14:17] I'll test -16 and the proposed fix in kernel bug 14700 later [14:17] Malone bug 14700 in vnc "xvncviewer -listen X Error" [Medium,Fix released] https://launchpad.net/bugs/14700 [14:17] see ya [14:17] smb http://bugzilla.kernel.org/attachment.cgi?id=23973 [14:18] apw, I looked at http://bugzilla.kernel.org/show_bug.cgi?id=14700 [14:18] bugzilla.kernel.org bug 14700 in Power-Processor "Broken system because of a bad ACPI commit" [Normal,New] [14:19] yep, but the last patch therre he tested is not in our tree even in origin/master [14:19] + (c->x86 > 0xf || (c->x86 == 6 && c->x86_model >= 0x0f))) [14:19] the patch you pointed out changes the first 0xf [14:19] the last one in the bug, the attachment i pointed out [14:19] changes the second 0xf [14:19] right i see [14:20] but actually then, the patch we have could have more impact [14:20] hm no [14:20] different impact [14:21] well actually in both cases it seems to be the same [14:21] the second looks like a refinement on the first [14:21] * apw doesn't see that [14:21] the patch we have: [14:21] - (c->x86 > 0x6 || (c->x86 == 6 && c->x86_model >= 14))) [14:21] + (c->x86 > 0xf || (c->x86 == 6 && c->x86_model >= 14))) [14:21] the tested patch: [14:22] - (c->x86 > 0xf || (c->x86 == 6 && c->x86_model >= 14))) [14:22] + (c->x86 > 0xf || (c->x86 == 6 && c->x86_model >= 0x0f))) [14:22] with the version as it was before the one we have, it would go into the if as model >= 14 and x86 = 6 [14:22] he is testing with the first patch, and with both [14:22] its always the second part of the || that applies, isn't it [14:23] and there we move from >=14 which he has to >=16 which he does not [14:23] model : 14 [14:23] oh, heck [14:23] moving from dec to hex in that patch [14:23] so yes [14:24] somehow my brain made both into hex [14:24] heh === Appiah_ is now known as Appiah === bjf-afk is now known as bjf [18:26] apw, jjohansen or anyone ... according to man kernel-img.conf do_initrd only disables a warning that the ramdisk is being created. [18:26] is there a way to say "do not create ramdisk" in /etc/kernel-img.conf ? [18:27] smoser, i don't think i am aware of it [18:27] as in i don't think i know [18:28] reading the postinst, it doesn't look like it. seems like the kernel package itself defines that: [18:28] y $initrd = "YES"; # initrd kernel [18:28] thanks though. [18:28] i'd not be supprised if we don't have support for no initramfs, as its needed for so much of our boot stuff === NCommander is now known as Guest64268 [23:31] sconklin, we're discussing -nouveau/kms on #ubuntu-x if you're interested [23:32] bryce: thanks, joining [23:51] bjf: I've been CCing you on these conversations; let me know if you'd like me to stop