| === 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 | ||
| sleblanc | Hello, is there a tool to automatically generate a config file with the best value to its corresponding hardware? | 09:34 |
|---|---|---|
| abogani | It depends from what you mean for "best value". | 09:35 |
| * abogani waves all | 09:36 | |
| 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:42 |
| sleblanc | It is to realize a network appliance with 2 GB of disk space. | 09:45 |
| abogani | apw: Good morning! | 09:45 |
| abogani | sleblanc: Perhaps "make localmodconfig" could help you. | 09:48 |
| sleblanc | Thanks, | 09:50 |
| kraut | moin | 10:01 |
| === amitk is now known as amitk-afk | ||
| === amitk-afk is now known as amitk | ||
| Arnold | Hi all, I have a question hope you can help | 11:03 |
| Arnold | I'm applying a kernel patch that adds 3 system calls on kernel 2.6.32 (Ubuntu 10.04) | 11:04 |
| Arnold | Now I'm noticing that unistd.h and syscall_table_32.S doesn't match up | 11:05 |
| Arnold | Also there doesn't seem to be a syscall_table_64.S file... | 11:07 |
| Arnold | Does someone know why there is a discrapancy in the system call numbers from the header file and the syscall table? | 11:08 |
| apw | Arnold, what version was the patch originally for | 11:41 |
| apw | Arnold, as 64bit doesn't seem to do its syscall linkage in the same way at all | 11:43 |
| === xfaf is now known as zul | ||
| === ogra_ac_ is now known as ogra_ac | ||
| === amitk is now known as amitk-afk | ||
| apw | http://people.canonical.com/~apw/master-natty/ | 13:34 |
| apw | http://people.canonical.com/~apw/ronx-revert-natty/ | 13:37 |
| apw | http://people.canonical.com/~apw/master-natty/ | 13:52 |
| === ogra_ac_ is now known as ogra_ac | ||
| apw | tgardner, how did urbana tae the master-natty update | 14:41 |
| 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:42 |
| 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:43 |
| apw | tgardner, good enough i'll upload it | 14:44 |
| tgardner | apw, wfm | 14:44 |
| Arnold | apw: Sorry I was in a meeting | 15:19 |
| Arnold | The patch was for 2.6.24, but I've completely rewritten it for 2.6.32 | 15:20 |
| apw | ok well then the syscall infrastructure has changed a lot between the two | 15:21 |
| Arnold | i've noticed ;) | 15:22 |
| 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:23 |
| 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:25 |
| 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:26 |
| apw | so 32 bit is harder as you have to do both, 64 just the one | 15:27 |
| 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:28 |
| tgardner | apw, Uploading linux-lts-backport-natty_2.6.37-6.16~lucid1 | 15:31 |
| apw | tgardner, is there anything in there ? | 15:31 |
| === bjf[afk] is now known as bjf | ||
| tgardner | apw, do you mean is there anything currently in the kernel-ppa ? | 15:32 |
| apw | tgardner, DOH i missread it, ignore me, and thanks | 15:33 |
| tgardner | apw, pushed to the repo as well | 15:33 |
| 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:38 |
| smoser | which is "interesting", "fun" or whatever you want to call it :) | 16:39 |
| 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:40 |
| 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:41 |
| jjohansen | black magic == iterate | 16:42 |
| jjohansen | but its not all bad we actually have a half decent starting point in maverick | 16:42 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| smoser | jjohansen, smb i trust both of you, so i'll stop nagging :) | 16:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| smoser | or is there something negative from that. | 16:54 |
| jjohansen | smoser: i don't see anything negative | 16:55 |
| jjohansen | I just wanted to make sure | 16:55 |
| smoser | size of ramdisk ? | 16:55 |
| 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:56 |
| 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) | 16:57 |
| oldkid | moin moin | 17:12 |
| apw | hi | 17:16 |
| 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:35 |
| 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:36 |
| smb | jjohansen, I guess such things happen during development phase | 17:37 |
| jjohansen | yeah | 17:37 |
| smb | I am moving back to a real .36 and check again | 17:38 |
| 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:40 |
| kees | what cpu do you have? | 17:41 |
| apw | it broke on both my atoms, 32bit and 64bit | 17:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| kees | and they had all kinds of modules | 17:46 |
| kees | the natty based on -rc2 | 17:46 |
| kees | plus the NFS fix | 17:46 |
| kees | should still be on tangerine | 17:47 |
| apw | hrm, cannot explain it at all | 17:49 |
| 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:51 |
| * apw puts security patches on his shit list :) | 17:52 | |
| kees | heh | 17:52 |
| 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:53 |
| tgardner | which _could_ be something else... | 17:54 |
| apw | tgardner, fair enough | 17:54 |
| apw | tgardner, i can confirm that my amd64's do not resume with this kenel | 18:01 |
| apw | oddly my i386s do | 18:01 |
| tgardner | apw, Lin Ming just posted 'x86: Resume trampoline must be executable' which should fix it | 18:02 |
| 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:03 |
| tgardner | apw, I dropped a couple of patches in master-next. I think this is worthy of another upload. | 18:04 |
| 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:05 |
| 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:06 |
| 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:16 |
| jjohansen | smb: yep, also check your mail some interesting info there | 18:17 |
| 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:18 |
| smb | jjohansen, oops, maybe I should have checked the dmesg first... | 18:20 |
| smb | jjohansen, Seems I am on a ro filesystem after io errors happened. But I was able to ssh into it | 18:21 |
| === yofel_ is now known as yofel | ||
| 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:08 | |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:13 |
| 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:14 |
| jjohansen | smb: oh you had to go add that little detail didn't you | 19:15 |
| jjohansen | :( | 19:15 |
| jjohansen | alright we won't split the bug yet | 19:16 |
| jjohansen | but I expect its 2 maybe 3 separate issues | 19:16 |
| 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:17 |
| 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:50 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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 | 19:57 |
| h0nk | hi, I was wondering if kafs allowed to set permissions on the afs mount (using kafs) | 20:00 |
| h0nk | right now only root can read some mounts below it | 20:01 |
| ohsix | argh; can't even find an email to report stuff to | 21:02 |
| 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:06 |
| ohsix | you could obfuscate it enough that nobody is ever able to contact you, that saves money so people do it :[ | 21:14 |
| === tgardner is now known as tgardner-afk | ||
| === ogra_ac__ is now known as ogra_ac | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!