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