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