| === Appiah_ is now known as Appiah | ||
| Kano | hi, how to disable acpi-thermal when it is builtin? | 11:48 |
|---|---|---|
| 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:15 |
| 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:16 |
| 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:26 |
| Kano | skipabi=true skipmodule=true | 12:27 |
| Kano | add that | 12:27 |
| 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:28 |
| bencer | Kano: i think binary-custom.d/myfalvour/rules is the right place to do so, isn't it ? | 12:30 |
| 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:31 |
| Kano | i think it is another file, apw should know it | 12:32 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| bencer | thanks dude, trying to build now with checks off on binary-custom.d/flavour/rules | 12:43 |
| * smb wonders... abi checks were done on custom flavours... | 12:44 | |
| 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:45 |
| 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:46 |
| 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:47 |
| 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 | 12:48 |
| 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:14 |
| apw | lamont, not something i've heard of, smb? | 13:15 |
| 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:17 |
| 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:18 |
| lamont | (nov 1 is as far back as syslog goes atm, even though there are older names - those are from june... go me) | 13:19 |
| 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:20 |
| 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:21 |
| lamont | hrm... not quite lying - backups tell me that the messages began sometime between 01:14 and 23:43 on nov 1 | 13:25 |
| lamont | smb: the funny part is the 'to self' in that message... | 13:27 |
| 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:28 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| smb | actually the message level is debug... | 13:35 |
| 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:36 |
| lamont | it seems to like that 10-tap | 13:37 |
| 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:38 |
| smb | apw, yep, so whatever is trying this should notice and back of in theory | 13:39 |
| lamont | so... consistent bit (across my sampled size of ... 2): postfix with a slew of v6 outbound traffic on the box in question | 13:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| lamont | where does that show up in /proc? | 13:45 |
| apw | possibly in /sys/class/net/<device> | 13:46 |
| smb | maybe /proc as well if one would find the tree in the forest | 13:48 |
| lamont | {t,r}x_{packets,bytes} are the only non-zero things in /sys/class/net/*/statistics/* | 13:49 |
| 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:50 |
| 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:51 |
| lamont | 14%, 12%, 13%... maybe cloning hardy, karmic, _and_ lucid kernels at the same time was not-so-smart | 13:53 |
| 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:54 |
| lamont | right | 13:55 |
| * lamont freshens his linus tree | 13:55 | |
| 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:56 |
| 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:57 |
| 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] | 13:59 |
| 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:01 |
| 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:02 |
| 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:03 |
| smb | akheron, https://launchpad.net/~stefan-bader-canonical/+archive/karmic | 14:04 |
| smb | try that kernel | 14:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| akheron | i'm using git://kernel.ubuntu.com/ubuntu/ubuntu-karmic.git | 14:08 |
| akheron | still cannot find it | 14:08 |
| smb | Hm, its in mine and it claims to be in sync with the remote one | 14:09 |
| smb | apw, You find it? | 14:09 |
| 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:10 |
| smb | ah right | 14:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| smb | but actually then, the patch we have could have more impact | 14:20 |
| smb | hm no | 14:20 |
| apw | different impact | 14:20 |
| 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:21 |
| 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:22 |
| apw | and there we move from >=14 which he has to >=16 which he does not | 14:23 |
| apw | <akheron> model : 14 | 14:23 |
| smb | oh, heck | 14:23 |
| smb | moving from dec to hex in that patch | 14:23 |
| smb | so yes | 14:23 |
| smb | somehow my brain made both into hex | 14:24 |
| apw | heh | 14:24 |
| === Appiah_ is now known as Appiah | ||
| === bjf-afk is now known as bjf | ||
| 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:26 |
| apw | smoser, i don't think i am aware of it | 18:27 |
| apw | as in i don't think i know | 18:27 |
| 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 | 18:28 |
| === NCommander is now known as Guest64268 | ||
| bryce | sconklin, we're discussing -nouveau/kms on #ubuntu-x if you're interested | 23:31 |
| sconklin | bryce: thanks, joining | 23:32 |
| dtchen | bjf: I've been CCing you on these conversations; let me know if you'd like me to stop | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!