=== amitk is now known as amitk-afk === ericm_ is now known as ericm|ubuntu === doko_ is now known as doko === ericm|ubuntu is now known as ericm-afk [09:34] Hello, is there a tool to automatically generate a config file with the best value to its corresponding hardware? [09:35] It depends from what you mean for "best value". [09:36] * abogani waves all [09:42] sleblanc, i think there might be something to minimise it, but not sure i know what it is called [09:42] abogani, morning [09:42] I want to get a smallest kernel, but with the need to work properly. [09:45] It is to realize a network appliance with 2 GB of disk space. [09:45] apw: Good morning! [09:48] sleblanc: Perhaps "make localmodconfig" could help you. [09:50] Thanks, [10:01] moin === amitk is now known as amitk-afk === amitk-afk is now known as amitk [11:03] Hi all, I have a question hope you can help [11:04] I'm applying a kernel patch that adds 3 system calls on kernel 2.6.32 (Ubuntu 10.04) [11:05] Now I'm noticing that unistd.h and syscall_table_32.S doesn't match up [11:07] Also there doesn't seem to be a syscall_table_64.S file... [11:08] Does someone know why there is a discrapancy in the system call numbers from the header file and the syscall table? [11:41] Arnold, what version was the patch originally for [11:43] Arnold, as 64bit doesn't seem to do its syscall linkage in the same way at all === xfaf is now known as zul === ogra_ac_ is now known as ogra_ac === amitk is now known as amitk-afk [13:34] http://people.canonical.com/~apw/master-natty/ [13:37] http://people.canonical.com/~apw/ronx-revert-natty/ [13:52] http://people.canonical.com/~apw/master-natty/ === ogra_ac_ is now known as ogra_ac [14:41] tgardner, how did urbana tae the master-natty update [14:42] apw, yep, though the kernel you sent still had an -rc2 in the signature. I've rebuild from master and am just booting that. [14:43] apw, looks good now: Ubuntu 2.6.37-6.16-server 2.6.37-rc3 [14:43] tgardner, huh ? i have it booted here with -rc3 [14:43] apw, maybe I grabbed the wrong one. no matter. [14:44] tgardner, good enough i'll upload it [14:44] apw, wfm [15:19] apw: Sorry I was in a meeting [15:20] The patch was for 2.6.24, but I've completely rewritten it for 2.6.32 [15:21] ok well then the syscall infrastructure has changed a lot between the two [15:22] i've noticed ;) [15:23] Can you explain the numbering in include/asm-generic/unistd.h to me? [15:23] well the numberiing its using is in arch/x86/include/unistd_64.h [15:25] ok, I'm building a 32bit kernel, so I guess it's unistd_32.h [15:25] the asm-generic is not used.. k thnx, that explains :) [15:26] Arnold, well no i think 32bit is different again [15:26] i do have a arch/x86/include/asm/unistd_32.h [15:26] there _is_ a suscall_table_32.S [15:26] which i think has to be kept in sync [15:26] whereas 64 bit is fixed so they cannot be out of sync [15:26] ok [15:27] so 32 bit is harder as you have to do both, 64 just the one [15:28] in 2.6.24 they also needed to be in sync. I was unaware of how the 64bit version was now working and that the files ware renamed [15:28] thanks apw ! ++ [15:31] apw, Uploading linux-lts-backport-natty_2.6.37-6.16~lucid1 [15:31] tgardner, is there anything in there ? === bjf[afk] is now known as bjf [15:32] apw, do you mean is there anything currently in the kernel-ppa ? [15:33] tgardner, DOH i missread it, ignore me, and thanks [15:33] apw, pushed to the repo as well [16:38] jjohansen, are you working today ? [16:38] smoser: yep [16:38] so you and i have different results with https://bugs.launchpad.net/ubuntu/+source/linux/+bug/669496 [16:38] Launchpad bug 669496 in linux (Ubuntu) "natty fails ec2 boot on i386 or t1.micro (affects: 1) (heat: 10)" [Critical,Confirmed] [16:39] which is "interesting", "fun" or whatever you want to call it :) [16:40] smoser: yeah, though I am not sure it is that different [16:40] at very least, i think all of you, i and smb have booted the kernel successfully on m1.large, and my initial attached logs show filesystem or block device failing after user space starts. [16:40] I launched a lot of instances and most didn't produce console output [16:41] yeah, so thats the first thing to fight i guess. [16:41] without console output, you're black magic skills have to come in. [16:41] :( [16:42] black magic == iterate [16:42] but its not all bad we actually have a half decent starting point in maverick [16:45] yeah. [16:45] [plus some madman is changing natty under your feet all the time] [16:45] And unfortunately all the console output looks like pre kernel start [16:45] smb, well, yes, but jjohansen and i know better than to trust that. [16:45] unfortunately, you can't [16:45] jjohansen, I thought I might try to see what old versions we have in the natty repo (ie 2.6.36) and try how that goes... [16:46] smb, see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/588715 [16:46] Launchpad bug 588715 in linux-meta-ec2 (Ubuntu) (and 1 other project) "instance had only post-shutdown console output (affects: 1) (heat: 22)" [Undecided,New] [16:46] basically, i do not 100% trust the console collection in the hypervisor. [16:47] smb: sure, I was going to troll through the commits to block front and back [16:47] smoser, No worries I am not really trusting anything there. Just was trying to say, that no output from the natty kernel in any cases [16:48] smb, well, right... i'm just saying that I suspect that the kernel is getting loaded, properly writing plenty of things to hvc0 , crashing, and that crash causes hypervisor to not be able to display logs [16:48] The x sectors of 0 bytes initially were looking strange but that is the same in maverick i386 and that boots [16:48] possibly its just a buffer that was lost or something, but one way or another, sometimes console logs aren't there, when you know that the kernel wrote something. [16:49] jjohansen, smb i trust both of you, so i'll stop nagging :) [16:50] smb, for the pv-on-hvm in natty, we think that is just kernel config options (s/think/hope/) [16:50] right ? [16:50] I agree that it would be too nice to really look at the machine it happens and to see whether one might pull a memory dump or so. Sadly thats out of qquestion.:) [16:50] smb, right [16:50] And we hope they are already turned on (at least it looks like that to me) [16:51] I believe jjohansen wanted to play a bit with those on Fri [16:51] oh. i didn't realize they were turned on. [16:51] in -virtual ? [16:51] that would rock. i'm going to install a centos here and poke at getting hvm instances going [16:51] i suspected i would have to recompile kernel, but not having to do that is nice [16:52] there at least. [16:52] smoser: yeah its just a kernel config option [16:52] which makes it nice and easy [16:53] I was just playing with whether to turn on for server/generic or only -virtual [16:53] If it is XEN_PVHVM then its even turned on for all confis [16:53] I think just a module for all [16:53] jjohansen, i'd think it makes sense to turn it on as modules in server, right ? [16:54] or is there something negative from that. [16:55] smoser: i don't see anything negative [16:55] I just wanted to make sure [16:55] size of ramdisk ? [16:56] smoser: well turning it on is different than sticking it in the ramdisk [16:56] smoser: sticking it the ramdisk is another issue [16:57] well, yes, but i was under the impression that we touched the mkinitramdisk stuff very little [16:57] I think we will have to do that for -server [16:57] (ie, didn't change "MOST" and the like) [17:12] moin moin [17:16] hi [17:35] jjohansen, So ubuntu-2.6.36-2.8 fails to boot as well (which is less surprising when one finds out that this is based on 2.6.37-rc1) [17:36] smb: o_O [17:36] smb: yea I wasn't expecting it to boot but that version skew is worthy of a double take [17:37] jjohansen, I guess such things happen during development phase [17:37] yeah [17:38] I am moving back to a real .36 and check again [17:40] apw: whoa. I wonder when module ro/nx broke so badly for your system? It was fine for me. [17:40] s/when/why [17:40] a good question, but i did a single patch revert to confirm it was that support which borked everything [17:41] what cpu do you have? [17:41] it broke on both my atoms, 32bit and 64bit [17:42] it also broke all of tgardner's installs, including a big-iron intel [17:42] kees, plus 2 of my machines [17:42] ah, what apw said [17:42] kees, it looked like it was trying to link modules and failing [17:42] i also had an ftrace failure [17:43] (for sky2) [17:43] and you pulled all 4 patches? now I wonder what I did wrong in my testing. I even built with page table debugging to verify it worked [17:43] 4 patches ? [17:43] yeah, my pull request show 3 from mat and 1 from me (config) [17:44] 849fdf5 UBUNTU: [Config] update config for CONFIG_DEBUG_SET_MODULE_RONX [17:44] 18f3991 x86: Add RO/NX protection for loadable kernel modules [17:44] 5c0fd04 x86: Add NX protection for kernel data [17:44] 18e43c9 x86: Fix improper large page preservation [17:44] those yes ? [17:44] yup. bizarre [17:44] ok the only one i had to dunk was the last one [17:44] well the last two i guess [17:44] as they are one change [17:44] right [17:44] hunh [17:45] the kernel data NX survived ok [17:45] kees, what base did you test it on [17:45] i tested in 2 VMs (32 and 64) [17:45] i mean which base version of the kernel [17:46] and they had all kinds of modules [17:46] the natty based on -rc2 [17:46] plus the NFS fix [17:47] should still be on tangerine [17:49] hrm, cannot explain it at all [17:51] well, I didn't test on real hardware, but I know kvm handles NX correctly, so maybe it's something subtly wrong in kvm [17:51] kees, also just saw this in LKML, a resume regression: Bisect to commit 5bd5a45(x86: Add NX protection for kernel data). [17:51] like maybe it only handle nx in ring3 [17:51] *handles [17:52] * apw puts security patches on his shit list :) [17:52] heh [17:53] i'l follow up with the author and try to reproduce on bare metal. bleh. [17:53] apw, I think we should back the NX patches out for now until we can have a closer look. I just has an unexplained reset on my Urbana [17:54] which _could_ be something else... [17:54] tgardner, fair enough [18:01] tgardner, i can confirm that my amd64's do not resume with this kenel [18:01] oddly my i386s do [18:02] apw, Lin Ming just posted 'x86: Resume trampoline must be executable' which should fix it [18:03] tgardner, out it goes [18:03] apw, but, given this stuff will show up in .38 I think we should back it out for now until the dust settles. [18:03] yep, it'll be back but tested i hope [18:04] apw, I dropped a couple of patches in master-next. I think this is worthy of another upload. [18:05] this being the NX/RO revert [18:05] one of these days one of my uploads will finish building before it turns to shite [18:06] yep if its breaking suspend as well its going to generate much whining [18:06] it'll generate some whinging from me, for sure :) [18:16] jjohansen, Partial good news. What we are looking for happened somewhere between 2.6.36 and 2.6.37-rc1 (I know that is still quite broad) [18:17] smb: yep, also check your mail some interesting info there [18:18] Saw it. Just need to grok what that exactly said about the micro instances. [18:18] But at least a 2.6.36 final rebase from our git tree still boots [18:20] jjohansen, oops, maybe I should have checked the dmesg first... [18:21] jjohansen, Seems I am on a ro filesystem after io errors happened. But I was able to ssh into it === yofel_ is now known as yofel [19:08] smb, smoser: we should split bug #669496 as t1.micro failing is a separate issue from t1.small and t1.medium failing [19:08] Launchpad bug 669496 in linux (Ubuntu) "natty fails ec2 boot on i386 or t1.micro (affects: 1) (heat: 10)" [Critical,Confirmed] https://launchpad.net/bugs/669496 [19:08] * tgardner lunches [19:09] jjohansen, sure. [19:09] I was surprised by smb reporting boot success of 2.6.36 because the initial bug was filed against a 2.6.36 kernel, but of course it was t1.micro failing [19:09] jjohansen, Well there was a small addition to that [19:09] smb: oh what was the addition? [19:09] m1.small and c1.medium [19:10] Which meant it booted but failed with the "io error" [19:10] ah, I missed that [19:10] jjohansen, well, the original failure showed both on m1.large and t1.micro [19:10] but... who cares. [19:10] going forward i think there are possibly 3 issues: [19:10] * amd64 sometimes doesn't boot [19:10] hrmm, well t1.micro failing on x86_64 is definitely a different issue than i386 [19:10] * i386 never boots [19:11] * t1.micro never boots [19:11] right [19:11] t1.micro has the additional issue of memory constraints [19:11] so, i will defer to however you and smb want to handle the bugs there. [19:13] jjohansen, How did you read that? For micro one needs to configure it to use no huge memory layout? Cause it is assigned only around 500M [19:14] btw it was a t1.micro that booted into the ro-fs but was accessible through ssh [19:14] smb: hrmm, I'm not sure. I think we need to play with it a bit to clarify exactly what the constraints are [19:15] smb: oh you had to go add that little detail didn't you [19:15] :( [19:16] alright we won't split the bug yet [19:16] but I expect its 2 maybe 3 separate issues [19:17] Probably I wanted to retry a few more times before I add that info to the bug [19:17] err [19:17] Thats should be "probably I ..." [19:50] anyone have any idea on how receptive vendors are to reports for bios breakage; like do they ever fix things (in general, compaq/hp in particular) [19:53] ohsix: sometimes, it doesn't hurt to try [19:53] this is what fwts has to say about my laptop: http://paste.ubuntu.com/535329/ [19:54] does ubuntu have any swing with hp/compaq? or anyone i can directly send a report to that will really count, experience lends that mails sent to general support addresses are almost never acknowledged [19:55] ohsix: I am sure canonical as some relationship with hp/compaq but I don't know the details and I don't have anything I can give you [19:56] alright, cool [19:56] would it be appropriate to report it to launchpad if its not strictly related? is there a place for that? [19:57] part of fixing some problems i have with my video is lending me to looking at lots of things that are also telling me things are broken :O [20:00] hi, I was wondering if kafs allowed to set permissions on the afs mount (using kafs) [20:01] right now only root can read some mounts below it [21:02] argh; can't even find an email to report stuff to [21:06] this is like the only stuff that really pisses me off :] (my sn is out of warranty on their little form so i can't see _any_ support addresses) [21:14] you could obfuscate it enough that nobody is ever able to contact you, that saves money so people do it :[ === tgardner is now known as tgardner-afk === ogra_ac__ is now known as ogra_ac