| === panda|x201 is now known as panda|w530 | ||
| * ppisati didn't get the egg thing, but it's ok... | 10:12 | |
| cking | ppisati, http://en.wikipedia.org/wiki/Teaching_grandmother_to_suck_eggs | 10:45 |
|---|---|---|
| cking | http://regimentalrogue.com/papers/egg.htm | 10:46 |
| apw | cking, heh thanks :) | 10:47 |
| apw | ppisati, i am inviting you to a hangout for testing | 10:47 |
| apw | which you may, or may not, be able to accept | 10:47 |
| ppisati | apw: about egg sucking? :) | 10:48 |
| apw | well you might have gotten the description | 10:48 |
| ppisati | :) | 10:48 |
| * apw goes for lunch ... and yes GOES | 12:56 | |
| === psivaa is now known as psivaa-lunch | ||
| === chrisccoulson is now known as notchrisccoulson | ||
| arges | smb: hello | 13:43 |
| smb | arges, Hi there | 13:44 |
| arges | smb: would you have time today to review a crash merge? | 13:44 |
| smb | arges, You may have email ;) | 13:44 |
| smb | Oh wait | 13:45 |
| smb | crash merge | 13:45 |
| smb | dammit | 13:45 |
| arges | smb: yea, other issue. sorry | 13:45 |
| smb | maybe | 13:45 |
| smb | if you point me to the merge | 13:45 |
| arges | smb: sure which files would be useful? or shoudl i just upload the directory | 13:45 |
| smb | arges, Hm, you got the merged source package files somewhere. I can pull the Debian part | 13:46 |
| arges | smb: ok i'll upload to p.c.c | 13:46 |
| smb | So without the orig tar is good enough | 13:46 |
| smb | arges, That or chinstrap is fine | 13:47 |
| arges | smb: uploading. I build for amd64/i386/armhf | 13:47 |
| smb | arges, Ok, iirc we did not have many differences left | 13:48 |
| arges | smb: yea caribou has been helping make sure our changes have been merged, and he helped out with this one as well | 13:49 |
| arges | which reminds me, i'll need to update the changelog to include credit for Louis as well | 13:50 |
| smb | Guess I had done a bit of that too, but meh | 13:52 |
| smb | ah apparently there was another ftbs in the new version | 13:55 |
| arges | smb: http://people.canonical.com/~arges/merges/crash/ | 13:59 |
| arges | smb: i didn't hit any FTBFS just using the debian rules/ | 13:59 |
| smb | arges, Oh I was referring the the one that caribou fixed | 13:59 |
| smb | I remember having had been looking at one a while back (having to do with pic register usage in inline assembly). Not sure it was the same and I failed to report upstream | 14:00 |
| smb | Though the last trusty rebuild must have succeeded I guess (7.0.2) | 14:01 |
| smb | arges, Hm, did you merge from 6.1.6? | 14:03 |
| === psivaa-lunch is now known as psivaa | ||
| arges | smb: 6.16 to 7.0.3 | 14:06 |
| arges | although i see 7.0.2 is in the trusty archive | 14:06 |
| jcz | im having problems with booting 3.8.0-34-generic kernel from ubuntu armhf repo on a laguna GW2388-4 arm board. After trying to boot the kernel with initrd nothing shows up on serial. Bootargs are: console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait rw. Do you guys have any idea what could be wrong? The bootloader is uboot and its working fine (booting openwrt from flash) | 14:06 |
| smb | arges, Yeah it was failing for i386 (for exactly the reason I failed to send a change upstream but caribou did, doh!) | 14:07 |
| arges | smb: so should we re-merge 7.0.3 then? | 14:08 |
| smb | arges, I guess it should not matter for except including those parts of the changelog... | 14:08 |
| caribou | isn't 7.0.2 there just because of the automatic sync ? | 14:09 |
| smb | caribou, It was a manual one | 14:09 |
| arges | caribou: looks like doko did it | 14:09 |
| caribou | 7.0.2 did build on amd64 but it FTBS on i386 | 14:09 |
| caribou | hmm, 2nd time I waste time on merging pkg that some other people did | 14:09 |
| smb | Somehow I remember having a quick look at that merge but apparently did not test compile on i386 | 14:10 |
| smb | caribou, At least it was done not that well | 14:10 |
| smb | And I must beat myself for not subitting that bugfix myself | 14:10 |
| caribou | smb: hehe :-) | 14:10 |
| caribou | smb: well at least now, the delta b/w ubuntu & debian is minimal | 14:10 |
| smb | I can remember having done a fix for it, too but then... gone | 14:11 |
| smb | caribou, Yeah that is cool | 14:11 |
| smb | arges, So _i_ would insert the missing changlog into your merge only... Not sure this is the _right_ thing, though | 14:11 |
| arges | smb: well i need to start with the 7.0.2 package and merge 7.0.3 I think | 14:12 |
| smb | apw, ^what would another cdev think? :) | 14:12 |
| smb | arges, I just think there was not much diff except arm64 and armhf in control and autopkgtest | 14:13 |
| smb | arges, which just get dropped... | 14:13 |
| smb | but ok for fully compliantness | 14:13 |
| arges | there are additional fixes in 7.0.3 + louis's i386 ftbfs + my autopkgtest merg | 14:14 |
| smb | arges, Yes, though for the merge you basically replace the orig.tgz and whether you do that from 6.1.6 or 7.0.2 should in the end be the same. Just the diff of 7.0.2 to the ubuntu version would have the autopkg test added which you either not add or drop... | 14:17 |
| smb | arges, But I guess better fallow the simple standard approch is better than trying to be smart | 14:17 |
| arges | smb: yea just re-doing the merge (its fairly simple) | 14:17 |
| arges | grab-merges didn't pick it up because it never got beyond proposed | 14:18 |
| smb | arges, true. so when you are done, let me know and I pull it down and have a quick review | 14:18 |
| arges | smb: ack thanks | 14:19 |
| arges | smb: which arches should we include | 14:22 |
| arges | i386 ia64 alpha powerpc amd64 armel armhf arm64 s390x | 14:22 |
| arges | do I leave all? or drop some? | 14:22 |
| apw | arges, we will only build on the intersection of the ones on the debian list, or that we actually have in the archive for the release you are uploading for | 14:29 |
| apw | which is fine if its the ones you want | 14:29 |
| arges | apw: ok then i'll keep what debian upstream has plus armhf/arm64 | 14:29 |
| apw | that list has armhf | 14:30 |
| arges | apw: yea ubuntu adds armhf/amd64, debian doesn't have those arches in its control file | 14:32 |
| arges | that's the remaining changes | 14:32 |
| arges | apw: btw is it ok to merge after a pacakge has already been merged? | 14:32 |
| arges | in a development cycle | 14:33 |
| apw | to roll our changes forward to a second or third debian update | 14:33 |
| apw | sure ... | 14:33 |
| arges | cool, plus alleviate our delta a bit more | 14:33 |
| arges | and more fixes etc | 14:33 |
| arges | smb: http://people.canonical.com/~arges/merges/crash/crash.v2/ | 14:33 |
| arges | smb: that's the smaller merge then | 14:33 |
| smb | ok. otp right now. will look in a sec | 14:34 |
| arges | smb: np | 14:34 |
| smb | arges, seems you don't want me to look at some files (permission) | 14:52 |
| smb | ;) | 14:52 |
| arges | smb: hmm... | 14:52 |
| arges | permissions are fine on my end | 14:53 |
| smb | /home/arges/public_html/merges/crash/crash.v2$ ls -la | 14:53 |
| smb | -rw------- 1 arges warthogs 67898 Nov 18 14:30 crash_7.0.3-3ubuntu1.diff.gz | 14:54 |
| arges | smb: ok try now | 14:55 |
| smb | arges, great now I cannot even ls the dir. :) | 14:56 |
| arges | smb: try now | 14:56 |
| arges | my brain is still warming up | 14:56 |
| smb | arges, better | 14:57 |
| smb | Reminds me of mine this morning | 14:57 |
| smb | arges, Where you a better contributor than me and have let Troy know about the messed up shebang thing? | 15:00 |
| arges | smb: no, i need to submit that | 15:00 |
| arges | so he moved the EOF, and removed stderr from the autodpkgtest permissions | 15:01 |
| arges | but I think stderr is needed if -x is on, which if the shebang doesn't execute it doesn't matter | 15:01 |
| arges | so I need to fix it, and resubmit | 15:01 |
| smb | arges, Oh, hm. I only saw the change of adding ! to #!/bin/sh | 15:02 |
| arges | yea i'm tweaking it more now | 15:02 |
| smb | Ah ok, though that unlikely makes a difference on the overall merge... on a quick glance that one does look good to me (iow nothing (much) to see, moving on) | 15:05 |
| smb | hm, time to create local trusty chroots... | 15:07 |
| === vishnu_ is now known as vijaya | ||
| vijaya | how could we read the VMA content from vm_area_struct? | 15:07 |
| vijaya | my attempt to do so returns only zeros. some sites says it is due to no Read premission. How to change the premission? Plz help me. | 15:11 |
| jcz | is there any way to determine the load address and entry point using only the kernel image? | 15:12 |
| apw | vijaya, i don't think there is enough info in your question to know what you are asking | 15:14 |
| apw | jcz, of the kernel on what arch, on most it is relocatable so up to the bootloader | 15:15 |
| jcz | armhf, generic kernel from repo | 15:16 |
| jcz | im trying to boot it with uboot but no idea where to find those addresses needed | 15:16 |
| jcz | i guess i can get it when compiling the kernel | 15:17 |
| jcz | or maybe even generate uImage directly, but i wanted to use the repo one | 15:17 |
| apw | ppisati, ^^ any idea | 15:18 |
| ppisati | jcz: actually when you generate the uImage you'll have to specify at which address you are going to load it | 15:20 |
| ppisati | jcz: so, zImage has no embedded info, while uImage has it | 15:20 |
| ppisati | jcz: and those info are boot loader/loading script dependent | 15:20 |
| vijaya | apw, actually i have used kernel module to read task_struct, mm_struct and vm_area_struct. using mmap list i can know the virtual address of start and end of the all VMA's . i tried to used copy_from_user but it return zero bits for most the VMA. | 15:20 |
| apw | vijaya, i would suggest looking at the core dump code as that does that | 15:22 |
| jcz | ppisati: by those info you are referring to load address and entry point? I thought that this is kernel specific | 15:22 |
| ppisati | jcz: kernel is relocatable, as i said | 15:22 |
| apw | ppisati, that implies the zimage payload is relocatable | 15:22 |
| ppisati | right | 15:23 |
| apw | which is as they say normal on generic kernels, cool | 15:23 |
| apw | ppisati, i assume it made sense to copy those saucy config changes forward to T | 15:24 |
| jcz | jcz: so i guess that load address and entry point have to be in a specific relation so that we hit some spot in the kernel loaded @ load address? am i correct? | 15:24 |
| ppisati | apw: yes | 15:24 |
| apw | ppisati, ta | 15:28 |
| stgraber | would I be right to assume that bug 1251946 would become a whole lot more important if I can reproduce it with the current trusty kernel? | 16:01 |
| ubot2 | Launchpad bug 1251946 in linux (Ubuntu) "Network related kernel panic on Atom 64bit system using saucy backport stack on precise" [Undecided,Confirmed] https://launchpad.net/bugs/1251946 | 16:01 |
| apw | stgraber, in theory trusty matters less to us than a stable release | 16:02 |
| stgraber | ok | 16:02 |
| apw | stgraber, it being reproducible is interesting whereever it is so reproducible | 16:02 |
| stgraber | I'll test anyway, since I don't like the idea of my firewalls randomly panicking when I upgrade them to the new LTS :) | 16:03 |
| apw | we are interested in anything like that, if it can be repro'd so we can try and smack it down | 16:03 |
| stgraber | I'll give the current saucy-proposed a try first as the changelog contains a lot of network related fixes, maybe that'll magically fix it, if not, I'll try our current 3.12 and if that still doesn't fix it, then I'll see if I can figure out a way to reproduce it in a VM | 16:05 |
| stgraber | though it seems to only affect the one box where I have bond+bridge+vlan+dual-stack firewall. Those without the bond don't show the issue, so it'll be a fun reproducing environment... | 16:05 |
| stgraber | and I also have systems with bond+vlan+bridge that don't show the problem... | 16:07 |
| arges | smb: ok now lets see if that i386 ftbfs go away for crash... | 16:09 |
| smb | arges, It did compile for me | 16:10 |
| arges | yea me too | 16:10 |
| arges | so, pretty confident it will work | 16:10 |
| smb | yup, so only any changes to the autotest script I have not seen but I would trust you there | 16:11 |
| stgraber | apw: seems like the current -proposed kernel is a significant improvement, I'm no longer getting the Oops at boot time and it's been over 4 minutes without a panic so far (all time record when using a 3.11 kernel on that box). I'll wait a couple more hours before considering the -proposed kernel as fixing the issue though :) | 16:14 |
| apw | stgraber, sounds good though, there is a heap of stable on that kernel | 16:15 |
| stgraber | yep, I was going through the list and found a dozen that seem to apply to my specific setup ;) | 16:16 |
| apw | stgraber, and this is one reason that for the normals out there (you arn't one) we don't recommend the lts saucy backport till we get to the point release | 16:17 |
| stgraber | apw: spoke too soon... http://paste.ubuntu.com/6438234/ | 16:36 |
| apw | stgraber, heh you have ipv6, you are so out there on your (nearly own) sigh | 16:38 |
| apw | or indeed is that your v6 tunnel that is exploding the world | 16:39 |
| stgraber | it's not a tunnel | 16:39 |
| stgraber | I have native IPv6 here | 16:39 |
| stgraber | and all my other firewalls do too and haven't blown up yet since the switch to 3.11 | 16:39 |
| stgraber | anyway, installing a 3.12 kernel before the next panic, let's see if that's somehow more reliable | 16:40 |
| stgraber | it's annoying that it now takes more than 5 minutes for the panic to show up though, ... | 16:40 |
| apw | stgraber, yeah well though that does give you enough time to install a new kernel | 16:41 |
| stgraber | 5min was way enough to switch kernels ;) | 16:43 |
| apw | stgraber, there are some changes in the functions that implode after 3.11 so you may seem some difference there | 16:50 |
| stgraber | apw: didn't even last a minute on 3.12 | 16:51 |
| apw | stgraber, the mix of 6 and 4 functions in that stack seem as if we are tunnelling, but you arn't using that right? | 16:51 |
| stgraber | I tunnel some IPv4 traffic over IPv6 in an IPSEC tunnel | 16:52 |
| stgraber | http://paste.ubuntu.com/6438301/ is the 3.12 one | 16:52 |
| apw | [ 54.052018] Kernel BUG at ffffffff81607e40 [verbose debug info unavailable] | 16:53 |
| apw | when did we stop having the right lines listted | 16:54 |
| apw | there are two 'bugon's in that function | 16:54 |
| xnox | rtg: apw: small config change request for goldfish https://bugs.launchpad.net/ubuntu/+source/linux-goldfish/+bug/1252339 | 16:55 |
| ubot2 | Launchpad bug 1252339 in linux-goldfish (Ubuntu) "Please enable EFI partitions on goldfish/armhf targets" [Medium,Confirmed] | 16:55 |
| rtg | xnox, ack | 16:56 |
| apw | xnox, in trusty ? | 16:56 |
| xnox | yeap, for trusty. | 16:57 |
| rtg | apw, I think trusty is the only release where the emulator works | 16:57 |
| stgraber | apw: once I'm done with a mumble meeting, I'll our 3.8 and 3.5 backport kernels on that box. So far I know 3.2 works fine (been running that for well over a year without panics) and I know current is broken, so I'll see if I can track down approximately when things broke. | 16:58 |
| xnox | rtg: well, things that "work" is increasing. e.g. unity is still waiting for patches to be uploaded in various packages. | 16:58 |
| rtg | xnox, right, but that is still just in trusty. | 16:59 |
| apw | stgraber, sounds good, and i'll pop a version of the saucy kernel so we know which of those two go BUG's it is | 16:59 |
| xnox | rtg: yeap. | 16:59 |
| === notchrisccoulson is now known as chrisccoulson | ||
| apw | stgraber, http://people.canonical.com/~apw/lp1251946-saucy/ <-- is a kernel (saucy level) which has some debug turned back on | 17:44 |
| stgraber | apw: ok, I'll try that one next. | 17:49 |
| stgraber | apw: 3.8 is affected too, I'm testing 3.5 now | 17:49 |
| apw | stgraber, good info indeed, i expect that one to implode the same but at lest say which bug on is tripped | 17:50 |
| apw | (that one == the one i pasted above) | 17:50 |
| apw | 3.5 if it is affected might also give us the same clue, so be interested in the dmesg from that one | 17:50 |
| stgraber | apw: 3.5 seems stable so far, I'll let it run until I'm done with lunch, if it doesn't panic by then I'll consider it good and reboot on your 3.11 | 17:56 |
| apw | stgraber, heh, poor firewall, some day i'd love to know how that thing is setup and why it is so very comple | 18:00 |
| apw | complex | 18:00 |
| stgraber | well, I actually simplified my firewalls a bit recently by dropping BGP ;) but for the rest, all of the firewalls I managed are dual-stack, they all talk to each other over IPSEC using the IPv6 link and sending the internal IPv4 traffic over that same tunnel, and then on the internal end, they are connected to managable switches over two links, so do bonding, vlans and bridges. All traffic between vlans goes through a dual-stack iptables f | 18:02 |
| === kernel is now known as Guest16327 | ||
| Guest16327 | Hi my name is Vaithi. I am new to open source community. I wish to contribute to ubuntu kernel. Anybody can guide me on how to start with some bugs and then walk my way up slowly? | 18:17 |
| Guest16327 | Thanks | 18:17 |
| Guest16327 | Anybody please? | 18:19 |
| apw | Guest16327, i think i may have just replied to your email | 18:19 |
| Guest16327 | Oh Hi Andy. Sorry for the question again. I thought I had to contact in the IRC too. Thanks. | 18:20 |
| stgraber | apw: got an hour of uptime on 3.5 and no panic, rebooting on your 3.11 now | 18:41 |
| stgraber | apw: and just got it to panic, dump in bug 1251946 | 18:55 |
| ubot2 | Launchpad bug 1251946 in linux (Ubuntu) "Network related kernel panic on Atom 64bit system using saucy backport stack on precise" [High,Confirmed] https://launchpad.net/bugs/1251946 | 18:55 |
| stgraber | testing the mainline 3.6 now | 18:55 |
| rtg | xnox, goldfish awaits in trusty https://launchpad.net/~canonical-kernel-team/+archive/ppa. I forgot to noe in the changelog that I also relaxed the armhf compiler version restriction. it now uses 4.8 (so please try it out) | 18:58 |
| rtg | apw, ogasawara: do you have anything pending for trusty ? master-next has accumulated enough cruft that its likely time to upload. | 19:28 |
| ogasawara | rtg: nothing for me | 19:28 |
| rtg | apw, I picked up CONFIG_DEBUG_BUGVERBOSE=y from bug #1252353 | 19:29 |
| ubot2 | Launchpad bug 1252353 in linux (Ubuntu Trusty) "CONFIG_BUGVERBOSE should be enabled (=y) to ensure BUGs produce the line information needed" [Medium,In progress] https://launchpad.net/bugs/1252353 | 19:29 |
| stgraber | jsalisbury, apw: so looks like the issue was introduced with 3.8 | 20:49 |
| jsalisbury | stgraber, ack. We will want to test some of the 3.8 release candidate kernels to find which exact one introduced the bug. I can post links in the bug report. | 20:51 |
| stgraber | jsalisbury: ok | 20:51 |
| jsalisbury | stgraber, thanks for testing | 20:51 |
| stgraber | jsalisbury: rc4 and rc2 are both bad, testing rc1 now | 21:27 |
| jsalisbury | stgraber, thanks | 21:32 |
| stgraber | jsalisbury: got anything else for me to test? :) | 21:33 |
| jsalisbury | stgraber, I can start a bisect and build a test kernle once we know if rc1 is bad or not | 21:34 |
| jsalisbury | stgraber, Just to confrm, 3.7 was good? | 21:34 |
| stgraber | yeah, I ran 3.7 for over 40min without a panic | 21:35 |
| stgraber | doesn't mean it wouldn't have paniced a minute later but seems unlikely as 3.8 usually paniced within 2-3min of boot | 21:36 |
| jsalisbury | stgraber, ok | 21:36 |
| Guest16327 | jsalisbury: This is Vaithi, you got anything for me to start looking at? Thought of asking, since you were talking about some test. Thanks. | 21:37 |
| jsalisbury | Guest16327, nothing specific as of yet. What might help is to see if any bugs exist for hardware that your currently have. Then see if you can reproduce the bug on your hardware. | 21:39 |
| Guest16327 | jsalisbury, I have a 64 bit system running a 32 bit kernel. I usually use virtual box for multiple copies. I have a Dell chipset. Do you want me to just search for such hardware or is there any other way? | 21:42 |
| jsalisbury | Guest16327, sure, searching for similar hardware is one way to go. You can use lspci, dmidecode and/or dmesg to get more details about your hardware and use that info to search for bugs. | 21:46 |
| Guest16327 | Jsalisbury, Great. I will do that and ask any questions if I have. Thanks | 21:47 |
| jsalisbury | Guest16327, great. | 21:48 |
| shnatsel | Hello everyone | 21:49 |
| Guest16327 | Jsalisbury, Out of curiosity, will everyone working on the bugs have most possible hardware in order to service all the bug requests? | 21:49 |
| shnatsel | I come from #checkbox to check what the support status for zram (bundled kernel module) is in 12.04 LTS | 21:49 |
| shnatsel | It's regressed in the past, causing freezes and kernel panics | 21:50 |
| shnatsel | I'm about to write a regression test | 21:50 |
| shnatsel | The thing is, it has evolved a lot upstream since 3.2 | 21:51 |
| jsalisbury | Guest16327, not always. It makes it easier to fix a bug when you do have the hardware, but that's not always the case. Most times we have to build a test kernel and ask the bug reporter to test. | 21:51 |
| shnatsel | Any pointers on where to check the support status of zram in Ubuntu? | 21:51 |
| Guest16327 | Jsaisbury, I was wondering you would do that, creating a mimic kernel and solve the error. Any pointers on how to build a test kernel? Sorry, I know basic kernel building, but most advanced aspects are in my learning curve. | 21:52 |
| jsalisbury | Guest16327, There is a wiki page linked from here that talks about building kernels: https://wiki.ubuntu.com/Kernel/Dev | 21:53 |
| Guest16327 | Jsalisbury, Thanks. I will first read all points in the wiki. | 21:54 |
| jsalisbury | Guest16327, This is a good page too: https://help.ubuntu.com/community/Kernel/Compile | 21:54 |
| Guest16327 | Jsalisbury, Thanks again. Last question, is it recommended to have a stand-alone OS running or can I also use virtual box? Using virtual box helps me to work with different images at the same time right. I usually do that. | 21:56 |
| jsalisbury | Guest16327, It all depends on the bug. If its hw specific a vm may not be the best to test. However, if its a more general kernel bug or say a filesystem bug, a vm would be good. | 21:57 |
| Guest16327 | Jsalisbury, Got it! I will leave you undisturbed, while I take some time to get used to the environment. Thanks. | 21:57 |
| shnatsel | Guest16327: when using virtualbox, do not install their guest additions. Upstream considers them very buggy, up to memory corruption in random places. | 22:11 |
| Guest16327 | shnatsel, Thanks. I will not have them installed for my vm's that I use for prototypes. I am a beginner in open source, just trying to use my evolving experience to contribute something. | 22:13 |
| * rtg -> EOD | 22:39 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!