=== panda|x201 is now known as panda|w530
* ppisati didn't get the egg thing, but it's ok...10:12
ckingppisati, http://en.wikipedia.org/wiki/Teaching_grandmother_to_suck_eggs10:45
apwcking, heh thanks :)10:47
apwppisati, i am inviting you to a hangout for testing10:47
apwwhich you may, or may not, be able to accept10:47
ppisatiapw: about egg sucking? :)10:48
apwwell you might have gotten the description10:48
* apw goes for lunch ... and yes GOES12:56
=== psivaa is now known as psivaa-lunch
=== chrisccoulson is now known as notchrisccoulson
argessmb: hello13:43
smbarges, Hi there13:44
argessmb: would you have time today to review a crash merge?13:44
smbarges, You may have email ;)13:44
smbOh wait13:45
smbcrash merge13:45
argessmb: yea, other issue. sorry 13:45
smbif you point me to the merge13:45
argessmb: sure which files would be useful? or shoudl i just upload the directory13:45
smbarges, Hm, you got the merged source package files somewhere. I can pull the Debian part13:46
argessmb: ok i'll upload to p.c.c13:46
smbSo without the orig tar is good enough13:46
smbarges, That or chinstrap is fine13:47
argessmb: uploading. I build for amd64/i386/armhf13:47
smbarges, Ok, iirc we did not have many differences left13:48
argessmb: yea caribou has been helping make sure our changes have been merged, and he helped out with this one as well13:49
argeswhich reminds me, i'll need to update the changelog to include credit for Louis as well13:50
smbGuess I had done a bit of that too, but meh13:52
smbah apparently there was another ftbs in the new version13:55
argessmb: http://people.canonical.com/~arges/merges/crash/13:59
argessmb: i didn't hit any FTBFS just using the debian rules/13:59
smbarges, Oh I was referring the the one that caribou fixed13:59
smbI 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 upstream14:00
smbThough the last trusty rebuild must have succeeded I guess (7.0.2)14:01
smbarges, Hm, did you merge from 6.1.6?14:03
=== psivaa-lunch is now known as psivaa
argessmb: 6.16 to 7.0.314:06
argesalthough i see 7.0.2 is in the trusty archive14:06
jczim 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
smbarges, Yeah it was failing for i386 (for exactly the reason I failed to send a change upstream but caribou did, doh!)14:07
argessmb: so should we re-merge 7.0.3 then?14:08
smbarges, I guess it should not matter for except including those parts of the changelog... 14:08
caribouisn't 7.0.2 there just because of the automatic sync ?14:09
smbcaribou, It was a manual one14:09
argescaribou: looks like doko did it14:09
caribou7.0.2 did build on amd64 but it FTBS on i38614:09
caribouhmm, 2nd time I waste time on merging pkg that some other people did14:09
smbSomehow I remember having a quick look at that merge but apparently did not test compile on i38614:10
smbcaribou, At least it was done not that well14:10
smbAnd I must beat myself for not subitting that bugfix myself14:10
caribousmb: hehe :-)14:10
caribousmb: well at least now, the delta b/w ubuntu & debian is minimal14:10
smbI can remember having done a fix for it, too but then... gone14:11
smbcaribou, Yeah that is cool14:11
smbarges, So _i_ would insert the missing changlog into your merge only... Not sure this is the _right_ thing, though14:11
argessmb: well i need to start with the 7.0.2 package and merge 7.0.3 I think14:12
smbapw, ^what would another cdev think? :)14:12
smbarges, I just think there was not much diff except arm64 and armhf in control and autopkgtest14:13
smbarges, which just get dropped...14:13
smbbut ok for fully compliantness14:13
argesthere are additional fixes in 7.0.3 + louis's i386 ftbfs + my autopkgtest merg14:14
smbarges, 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
smbarges, But I guess better fallow the simple standard approch is better than trying to be smart14:17
argessmb: yea just re-doing the merge (its fairly simple)14:17
argesgrab-merges didn't pick it up because it never got beyond proposed14:18
smbarges, true. so when you are done, let me know and I pull it down and have a quick review14:18
argessmb: ack thanks14:19
argessmb: which arches should we include14:22
argesi386 ia64 alpha powerpc amd64 armel armhf arm64 s390x14:22
argesdo I leave all? or drop some?14:22
apwarges, 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 for14:29
apwwhich is fine if its the ones you want14:29
argesapw: ok then i'll keep what debian upstream has plus armhf/arm6414:29
apwthat list has armhf14:30
argesapw: yea ubuntu adds armhf/amd64, debian doesn't have those arches in its control file14:32
argesthat's the remaining changes14:32
argesapw: btw is it ok to merge after a pacakge has already been merged?14:32
argesin a development cycle14:33
apwto roll our changes forward to a second or third debian update14:33
apwsure ...14:33
argescool, plus alleviate our delta a bit more14:33
argesand more fixes etc14:33
argessmb: http://people.canonical.com/~arges/merges/crash/crash.v2/14:33
argessmb: that's the smaller merge then14:33
smbok. otp right now. will look in a sec14:34
argessmb: np14:34
smbarges, seems you don't want me to look at some files (permission)14:52
argessmb: hmm...14:52
argespermissions are fine on my end14:53
smb/home/arges/public_html/merges/crash/crash.v2$ ls -la14:53
smb-rw------- 1 arges warthogs    67898 Nov 18 14:30 crash_7.0.3-3ubuntu1.diff.gz14:54
argessmb: ok try now14:55
smbarges, great now I cannot even ls the dir. :)14:56
argessmb: try now14:56
argesmy brain is still warming up 14:56
smbarges, better14:57
smbReminds me of mine this morning14:57
smbarges, Where you a better contributor than me and have let Troy know about the messed up shebang thing?15:00
argessmb: no, i need to submit that15:00
argesso he moved the EOF, and removed stderr from the autodpkgtest permissions15:01
argesbut I think stderr is needed if -x is on, which if the shebang doesn't execute it doesn't matter15:01
argesso I need to fix it, and resubmit15:01
smbarges, Oh, hm. I only saw the change of adding ! to #!/bin/sh15:02
argesyea i'm tweaking it more now15:02
smbAh 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
smbhm, time to create local trusty chroots...15:07
=== vishnu_ is now known as vijaya
vijayahow could we read the VMA content from vm_area_struct?15:07
vijayamy 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
jczis there any way to determine the load address and entry point using only the kernel image?15:12
apwvijaya, i don't think there is enough info in your question to know what you are asking15:14
apwjcz, of the kernel on what arch, on most it is relocatable so up to the bootloader15:15
jczarmhf, generic kernel from repo15:16
jczim trying to boot it with uboot but no idea where to find those addresses needed15:16
jczi guess i can get it when compiling the kernel15:17
jczor maybe even generate uImage directly, but i wanted to use the repo one15:17
apwppisati, ^^ any idea15:18
ppisatijcz: actually when you generate the uImage you'll have to specify at which address you are going to load it15:20
ppisatijcz: so, zImage has no embedded info, while uImage has it15:20
ppisatijcz: and those info are boot loader/loading script dependent15:20
vijayaapw, 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
apwvijaya, i would suggest looking at the core dump code as that does that15:22
jczppisati: by those info you are referring to load address and entry point? I thought that this is kernel specific15:22
ppisatijcz: kernel is relocatable, as i said15:22
apwppisati, that implies the zimage payload is relocatable15:22
apwwhich is as they say normal on generic kernels, cool15:23
apwppisati, i assume it made sense to copy those saucy config changes forward to T15:24
jczjcz: 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
ppisatiapw: yes15:24
apwppisati, ta 15:28
stgraberwould 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
ubot2Launchpad 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/125194616:01
apwstgraber, in theory trusty matters less to us than a stable release16:02
apwstgraber, it being reproducible is interesting whereever it is so reproducible16:02
stgraberI'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
apwwe are interested in anything like that, if it can be repro'd so we can try and smack it down16:03
stgraberI'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 VM16:05
stgraberthough 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
stgraberand I also have systems with bond+vlan+bridge that don't show the problem...16:07
argessmb: ok now lets see if that i386 ftbfs go away for crash...16:09
smbarges, It did compile for me16:10
argesyea me too16:10
argesso, pretty confident it will work16:10
smbyup, so only any changes to the autotest script I have not seen but I would trust you there16:11
stgraberapw: 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
apwstgraber, sounds good though, there is a  heap of stable on that kernel16:15
stgraberyep, I was going through the list and found a dozen that seem to apply to my specific setup ;)16:16
apwstgraber, 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 release16:17
stgraberapw: spoke too soon... http://paste.ubuntu.com/6438234/16:36
apwstgraber, heh you have ipv6, you are so out there on your (nearly own) sigh16:38
apwor indeed is that your v6 tunnel that is exploding the world16:39
stgraberit's not a tunnel16:39
stgraberI have native IPv6 here16:39
stgraberand all my other firewalls do too and haven't blown up yet since the switch to 3.1116:39
stgraberanyway, installing a 3.12 kernel before the next panic, let's see if that's somehow more reliable16:40
stgraberit's annoying that it now takes more than 5 minutes for the panic to show up though, ...16:40
apwstgraber, yeah well though that does give you enough time to install a new kernel16:41
stgraber5min was way enough to switch kernels ;)16:43
apwstgraber, there are some changes in the functions that implode after 3.11 so you may seem some difference there16:50
stgraberapw: didn't even last a minute on 3.1216:51
apwstgraber, 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
stgraberI tunnel some IPv4 traffic over IPv6 in an IPSEC tunnel16:52
stgraberhttp://paste.ubuntu.com/6438301/ is the 3.12 one16:52
apw[ 54.052018] Kernel BUG at ffffffff81607e40 [verbose debug info unavailable]16:53
apwwhen did we stop having the right lines listted16:54
apwthere are two 'bugon's in that function16:54
xnoxrtg: apw: small config change request for goldfish https://bugs.launchpad.net/ubuntu/+source/linux-goldfish/+bug/125233916:55
ubot2Launchpad bug 1252339 in linux-goldfish (Ubuntu) "Please enable EFI partitions on goldfish/armhf targets" [Medium,Confirmed]16:55
rtgxnox, ack16:56
apwxnox, in trusty ?16:56
xnoxyeap, for trusty.16:57
rtgapw, I think trusty is the only release where the emulator works16:57
stgraberapw: 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
xnoxrtg: well, things that "work" is increasing. e.g. unity is still waiting for patches to be uploaded in various packages.16:58
rtgxnox, right, but that is still just in trusty.16:59
apwstgraber, sounds good, and i'll pop a version of the saucy kernel so we know which of those two go BUG's it is16:59
xnoxrtg: yeap.16:59
=== notchrisccoulson is now known as chrisccoulson
apwstgraber, http://people.canonical.com/~apw/lp1251946-saucy/ <-- is a kernel (saucy level) which has some debug turned back on17:44
stgraberapw: ok, I'll try that one next.17:49
stgraberapw: 3.8 is affected too, I'm testing 3.5 now17:49
apwstgraber, good info indeed, i expect that one to implode the same but at lest say which bug on is tripped17:50
apw(that one == the one i pasted above)17:50
apw3.5 if it is affected might also give us the same clue, so be interested in the dmesg from that one17:50
stgraberapw: 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.1117:56
apwstgraber, heh, poor firewall, some day i'd love to know how that thing is setup and why it is so very comple18:00
stgraberwell, 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 f18:02
=== kernel is now known as Guest16327
Guest16327Hi 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
Guest16327Anybody please?18:19
apwGuest16327, i think i may have just replied to your email18:19
Guest16327Oh Hi Andy. Sorry for the question again. I thought I had to contact in the IRC too. Thanks.18:20
stgraberapw: got an hour of uptime on 3.5 and no panic, rebooting on your 3.11 now18:41
stgraberapw: and just got it to panic, dump in bug 125194618:55
ubot2Launchpad 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/125194618:55
stgrabertesting the mainline 3.6 now18:55
rtgxnox, 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
rtgapw, ogasawara: do you have anything pending for trusty ? master-next has accumulated enough cruft that its likely time to upload.19:28
ogasawarartg: nothing for me19:28
rtgapw, I picked up CONFIG_DEBUG_BUGVERBOSE=y from bug #125235319:29
ubot2Launchpad 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/125235319:29
stgraberjsalisbury, apw: so looks like the issue was introduced with 3.820:49
jsalisburystgraber, 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
stgraberjsalisbury: ok20:51
jsalisburystgraber, thanks for testing20:51
stgraberjsalisbury: rc4 and rc2 are both bad, testing rc1 now21:27
jsalisburystgraber, thanks21:32
stgraberjsalisbury: got anything else for me to test? :)21:33
jsalisburystgraber, I can start a bisect and build a test kernle once we know if rc1 is bad or not21:34
jsalisburystgraber, Just to confrm, 3.7 was good?21:34
stgraberyeah, I ran 3.7 for over 40min without a panic21:35
stgraberdoesn't mean it wouldn't have paniced a minute later but seems unlikely as 3.8 usually paniced within 2-3min of boot21:36
jsalisburystgraber, ok21:36
Guest16327jsalisbury: 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
jsalisburyGuest16327, 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
Guest16327jsalisbury, 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
jsalisburyGuest16327, 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
Guest16327Jsalisbury, Great. I will do that and ask any questions if I have. Thanks21:47
jsalisburyGuest16327, great. 21:48
shnatselHello everyone21:49
Guest16327Jsalisbury, Out of curiosity, will everyone working on the bugs have most possible hardware in order to service all the bug requests? 21:49
shnatselI come from #checkbox to check what the support status for zram (bundled kernel module) is in 12.04 LTS21:49
shnatselIt's regressed in the past, causing freezes and kernel panics21:50
shnatselI'm about to write a regression test21:50
shnatselThe thing is, it has evolved a lot upstream since 3.221:51
jsalisburyGuest16327, 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
shnatselAny pointers on where to check the support status of zram in Ubuntu?21:51
Guest16327Jsaisbury, 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
jsalisburyGuest16327, There is a wiki page linked from here that talks about building kernels: https://wiki.ubuntu.com/Kernel/Dev21:53
Guest16327Jsalisbury, Thanks. I will first read all points in the wiki. 21:54
jsalisburyGuest16327, This is a good page too: https://help.ubuntu.com/community/Kernel/Compile21:54
Guest16327Jsalisbury, 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
jsalisburyGuest16327, 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
Guest16327Jsalisbury, Got it! I will leave you undisturbed, while I take some time to get used to the environment. Thanks.21:57
shnatselGuest16327: when using virtualbox, do not install their guest additions. Upstream considers them very buggy, up to memory corruption in random places.22:11
Guest16327shnatsel, 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 -> EOD22:39

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!