[07:38] <ppisati> moin
[09:23]  * apw yawns
[09:37] <RAOF> Bees! A steaming hot cup of bees!
[09:39] <apw> RAOF, how do you like your women ?
[09:39] <RAOF> Very much.
[09:39] <apw> "covered in bees"
[09:39] <RAOF> No, silly. The women are covered in honey!
[09:39] <apw> and things which are covered in honey, are convered in what ?
[09:40] <RAOF> honeybees!
[09:41]  * apw hands RAOF a little medal
[09:41] <apw> RAOF, hows it going?
[09:41] <RAOF> Pretty well.
[09:42] <RAOF> I'm in Perth, staying at the in-law's, so there's a bit of extra babysitting available. :)
[09:43] <apw> oh very nice :)
[09:44] <RAOF> How about you?
[09:45] <apw> yeah good i think, if i could wake up it might stop being, but in my current state ok thanks
[11:15] <ashwini> can we use setjmp and longjmp in kernel mode ?? or any equivalent method ? kernel version 3.6*
[11:16] <ohsix> for what? there are a bunch of mechanisms for jobs and threads
[11:23] <ohsix> if you can be specific abotu what you're trying to do i might be able to point out an alternative
[11:28] <ogra> The following NEW packages will be installed:
[11:28] <ogra>   linux-headers-3.5.0-218 linux-headers-3.5.0-218-omap4
[11:29] <ogra> apw, ^^^  what'S that ? (dist-upgrading my nexus7)
[11:30] <apw> ogra, hmmm just doing it now ?
[11:30] <ogra> well, i do my daily upgrade, so yes
[11:30]  * apw tries
[11:31] <apw> ogra, while i think about it suspend/resume is bringing usb0 back up on the nexus, and upsetting NM on my desktop
[11:32] <ogra> apw, yep, NM will get fixed to ignore usb0
[11:32] <ogra> at least for certain usb id's
[11:32] <ogra> so you can still set up usbnet manually by selecting the device from the indicator, but it wont attemopt autoconnection
[11:32] <apw> hmmm, i thought you were fixing that n7 side
[11:33] <apw> by not running the interface there unless you were using it
[11:33] <ogra> well, i was abouot to, but was told NM would be fixed
[11:33] <apw> that seems backwards, but i guess its not my problem
[11:33] <ogra> it does that for other usb connections too so it makes sense to have some filtering apparently
[11:33] <apw>   libdatrie1 liblightdm-gobject-1-0 libthai-data libthai0 lightdm
[11:33] <apw>   linux-headers-3.1.10-9 linux-headers-3.1.10-9-nexus7
[11:33] <apw>   linux-image-3.1.10-9-nexus7 linux-libc-dev python-imaging
[11:33] <apw>   ubuntu-defaults-nexus7 ubuntu-settings unity-greeter
[11:33] <apw> ok didn't do that for me
[11:34] <ashwini> ohsix: what are the alternatives ?
[11:34] <apw> ogra, you didn't install the omap binary on there did you ?
[11:34] <ogra> i dont see ubuntu-drivers-common
[11:34] <ogra> i assume thats at fault
[11:34] <ohsix> ashwini: i don't know what you're trying to do
[11:35] <ogra> apw, nothing special installed that could pull it in, check if you didnt already have it installed, i'm probably not in sync with your upgrading
[11:35]  * apw notes that pretty much all use of setgjmp longjmp is wrong, in principle
[11:35] <ohsix> and even the marginal uses won't hold in the kernel :p
[11:36] <apw> ogra, i got a nice shiney new kernel and no omap stuff, odd
[11:36] <ogra> weird
[11:36] <ogra> i'll dig on then
[11:37] <ogra> hmm, so purging linux-headers-3.5.0-218-omap4 leaves me with ....
[11:37] <ogra> The following package was automatically installed and is no longer required:
[11:37] <ogra>   linux-headers-3.5.0-218
[11:38]  * ogra scratches head
[11:38] <apw> that makes sense i at least, that would be a dep of the other
[11:38] <apw> ogasawara, i have pushed a rebase to v3.8-rc6, booted and running here on 32 and 64 bit x86
[11:39] <ogra> well, but it indicates that there was no dep that pulled in linux-headers-3.5.0-218
[11:39] <ogra> thats the strange part here
[11:39] <apw> linux-headers-3.5.0-218-omap4 was the dep, you purged it
[11:39] <ogra> linux-headers-3.5.0-218-omap4 was not depended on by anything but its own meta though
[11:40] <apw> oh indeed,
[11:50] <ppisati> apw: did you check out the versatile support?
[11:59] <apw> ppisati, sorry i have lost some history, did you send me something to test?
[12:00] <apw> ppisati, otherwise, i tried hard to boot your kernel using qemu and options which seemed to be vexpress (not versatile)
[12:00] <apw> ppisati, and note it is vexpress
[12:05] <apw> ppisati, and i have failed to get it to do anything visible
[12:05] <apw> (your kernel == the one in the archive)
[12:06] <ppisati> apw: i sent a pull req yesterday about vexpress suport
[12:06] <ppisati> apw: vexpress = "ARM Ltd. Versatile Express family"
[12:07] <ppisati> apw: "enable ARM Versatile Express support"
[12:07] <ppisati> apw: To<EMAIL_ADDRESS>[12:08] <ppisati> apw: here is a precompiled version of kernel, initrd and rootfs with vexpress support: http://people.canonical.com/~ppisati/vexpress/
[12:08] <apw> ppisati, thanks ... i completely phased on that
[12:08] <ppisati> apw: in the email there's the qemu command to boot it
[12:08] <apw> ppisati, will get into it and get it applied thanks
[12:08] <ppisati> apw: ack
[12:20] <apw> ppisati, in all cases you are just enabling the specified option on the subject line for the omap flavour... yes ?
[12:20] <ppisati> apw: yep
[12:21] <apw> ppisati, great, i have rebased and the configs are different enough to break them, but they are easy to recreate
[12:21] <ppisati> apw: ah yes
[12:21] <ppisati> apw: i forgot, master-next requires an updateconfig before applying my patches
[12:21] <apw> ahh ok
[12:22] <apw> ppisati, oh excellent, now they work :)
[12:22] <apw> ppisati, i was pushing the updateconfigs anyhow :)
[12:24] <ppisati> apw: you can test it with my rootfs, but beware that the NIC drievr is a module
[12:24] <ppisati> apw: so you need to install the kernel .deb in the rootfs to get networking
[12:25] <ppisati> apw: ah, and my rootfs is linaro :P
[12:25] <ashwini> any pointer for setjmp_pre_handler ?? How to use or any type of documentation ??
[12:29]  * henrix -> lunch
[12:36] <apw> ogasawara, i have applied ppisati's versatile stuff and am testing it now
[13:04]  * ppisati -> goes to find some food
[13:45] <ogasawara> apw: ack, thanks.  I think I'll prep another upload for today then.
[13:49] <apw> ogasawara, i'll let you know when its 'good'
[13:51] <apw> ogasawara, the rc6 testing went well on x86
[13:53] <ogasawara> apw: good, I'm gonna test it all on my kit here as well
[13:54] <arges> ogasawara: fyi. wireless patch c3e5d718 on my raring laptop has fix issues so far. is this included in rc6?
[13:54] <ogasawara> arges: it should be, but let me double check
[13:55] <apw> v3.8-rc6~20^2~10^2^2~7^2
[13:55] <apw> arges, looks to be yes
[13:55] <arges> thanks, i should be less lazy : )
[13:55] <apw> yes, you should :)
[13:55] <apw> ppisati, ack
[13:56] <apw> if i can get a console i will be amazed
[13:56] <ppisati> apw: you should have a console
[14:02] <apw> ppisati, my panda(?) is hanging left right and centre with these kernels
[14:04] <ppisati> apw: scheduling while atomic?
[14:05] <apw> ppisati, no way to tell, it just hangs
[14:05] <apw> though the scheduling whilst atomics in there may well be indicative
[14:05] <ppisati> apw: i tested my patches on panda and it was ok
[14:06] <apw> ppisati, and my board is hanging ... a lot ... but i use ipv6, a lot
[14:06] <ppisati> apw: lemme try master-next tip
[14:06] <apw> so perhaps there is a connection
[14:06] <apw> or perhaps my board is dying, how the hell to tell
[14:06] <apw> ppisati, i have no serial console output from my kernel
[14:07] <ppisati> apw: that's weird
[14:07] <apw> and maybe that would be telling me something, whats the runes to get that working
[14:07] <apw> ppisati, no i think its config rather than anything else
[14:07] <apw> i get uboot on there
[14:07] <ppisati> ok so
[14:07] <ppisati> flag@flag-desktop:/media$ cat preEnv.txt
[14:07] <ppisati> bootargs=ro console=tty0 console=ttyO2,115200n8 debug earlyprintk=ttyO2,115200n8 root=UUID=be44da86-b040-478b-9ce9-4e99e29c2872
[14:07] <ppisati> and media is my /dev/mmcblk0p1
[14:08] <ppisati> you probably just need to add: "console=tty0 console=ttyO2,115200n8 debug earlyprintk=ttyO2,115200n8" and delete "quiet splash"
[14:09] <apw> ppisati, ack
[14:09] <apw> will have a look
[14:09] <apw> so your versatile works a lot better than it did before
[14:10] <apw> though on my image it implodes
[14:10] <apw> [    5.086795] WARNING: at /home/apw/build/ubuntu-raring/ubuntu-raring/drivers/tty/serial/serial_core.c:400 uart_get_baud_rate+0xec/0x144()
[14:10] <apw> [    5.098399] Division by zero in kernel.
[14:10] <apw> but hey... its much better than it was
[14:10] <ppisati> LOL :)
[14:11] <apw> and that is with an image i got from debian so anything is possible
[14:11] <apw> i'll get yours
[14:11] <ppisati> but the img should mke any different
[14:11] <ppisati> wait
[14:11] <ppisati> QEMU emulator version 1.2.0 (Debian 1.2.0-2012.09-0ubuntu1)
[14:11] <ppisati> your?
[14:11] <ppisati> qemu-system-arm -version
[14:12] <ppisati> *shouldn't
[14:18] <apw> QEMU emulator version 1.3.0 (Debian 1.3.0+dfsg-1~exp3ubuntu6), Copyright (c) 2003-2008 Fabrice Bellard
[14:18] <apw> ppisati, ^^
[14:19] <ppisati> apw: that would explain it
[14:19] <apw> it would?
[14:19] <ppisati> apw: well, could be a bug on qemu
[14:19] <apw> ppisati, i think its much more likely my fault to be hones
[14:20] <apw> i'll confirm with your rootfs
[14:20] <apw> if yours blows too then its qemu if not, i don't care ;)
[14:20] <apw> well it is qemu or my -4 kernel build
[14:25] <ppisati> flag@flag-desktop:~$ uname -a
[14:25] <ppisati> Linux flag-desktop 3.8.0-4-omap #8~vexpressrc6 SMP Fri Feb 1 14:12:38 UTC 2013 armv7l armv7l armv7l GNU/Linux
[14:25] <ppisati> apw: that's my pandaes booting current master-next tip
[14:27] <apw> ppisati, mine boots too, but ... it doesn't stay working for more than 10s of minutes
[14:37] <apw> ppisati, ok your image boots fine with my -4 kernel ..
[14:37] <apw> so ogasawara that looks good in my testing
[14:38] <ogasawara> apw: awesome.  I just want to finish up some quick testing on my kit here and then I'll push the upload
[14:41] <apw> ogasawara, sounds great
[14:43] <apw> QEMU emulator version 1.3.0 (Debian 1.3.0+dfsg-1~exp3ubuntu6), Copyright (c) 2003-2008 Fabrice Bellard
[14:43] <apw> bah
[14:43] <ppisati> apw: can you upload your img somewhere? i should try to roll my own ubuntu BTW
[14:47] <apw> ppisati, its just the debian one
[14:48] <apw> ppisati, i assume in theory if i dd off my panda with this -omap installed
[14:48] <apw> ppisati, that would make a valid image
[14:48] <ppisati> apw: yep, should be
[14:48] <apw> ppisati, this debian image isn't worth worrying about, its an old armel one even
[14:48] <apw> so ... we are better off making a new one off one of these pandas or someething
[14:50] <apw> ppisati, the serial job isn't working on this board even though echo >/dev/ttyO2 works
[14:50] <apw> ppisati, ever seen that?
[14:51] <apw> ppisati, as in the getty is not throwing onto it
[14:52] <ppisati> apw: do you have an /etc/init/ttyO2.conf?
[14:52] <apw> ppisati, no i have a serial.conf which is meant to do the right thing
[14:53] <apw> but i think it is broke ... debugging it now
[14:53]  * ppisati still uses /etc/init/ttyO2.conf
[14:53] <apw> ahh it doesn't work if you have console=tty0 console=SERIAL
[14:54] <apw> stupid thing
[14:54] <apw> fixed
[14:56] <apw> ppisati, http://paste.ubuntu.com/1597104/ feels like the last thing it said before locking up
[14:57] <apw> ppisati, and 100104 is like LIST_POISON or something isn't it?
[14:58] <ppisati> yes
[14:58] <apw> i'll let it do it again and see if it behaves the same
[15:03] <apw> ppisati, even with these stability problems this is a good step
[15:05] <ppisati> apw: i think it's ipv6 related because
[15:05] <ppisati> apw: time DEB_BUILD_OPTIONS=parallel=4 fakeroot debian/rules binary-omap4
[15:05] <ppisati> apw: and it's still compiling
[15:05] <ppisati> (~1hr so far)
[15:06] <apw> ppisati, could well be, i'll confirm it exists in this kerenl a couple more
[15:06] <apw> and then move it to my ipv4 only lan
[15:06] <ppisati> apw: truth be told, i got a "BUG: scheduling while atomic: cc1/19926/0x40000100"
[15:07] <apw> elloco login: [  386.207427] BUG: scheduling while atomic: swapper/0/0/0x40000100
[15:07] <apw> [  386.214782] BUG: scheduling while atomic: swapper/0/0/0x40000100
[15:07] <apw> i have two, but they haven't eaten my lunch yet
[15:07] <ppisati> my is still alive too
[15:07] <ppisati> *mine
[15:07] <ppisati> http://paste.ubuntu.com/1597185/
[15:13] <apw> it seems a lot happier now it has a console ... hmm
[15:13] <apw> we shall see
[15:15] <apw> ogasawara, have you wrapped the kernel yet?  we might want seth's thing
[15:16] <ogasawara> apw: heh, I was literally about to ping sforshee about that
[15:16] <ogasawara> apw: I'd prepped the upload but failed to see his patch till after
[15:16] <ogasawara> apw: I was going to redo it to include it
[15:16] <apw> that is annoying when it happens
[15:17] <ogasawara> apw: so I'm kicking off new builds
[15:17] <sforshee> ogasawara, it's not critical, but it would be helpful for helping me debug a wireless issue that bjf has been seeing
[15:17] <apw> if it it pushed, i can do the same and boot test them
[15:17] <ogasawara> apw: I'm applying it right now and will push, gimme 2min
[15:17] <sforshee> if it's too much of a hassle it can wait until next time
[15:18] <ogasawara> sforshee: nah not much trouble, I'll squeeze it in
[15:18] <apw> the more we have the less bad i feel about it being 36 hours after the last one
[15:18] <ogasawara> indeed
[15:19] <apw> ogasawara, i don't know if you followed along, but this -omap now supports omap3,4, some imx6 thing, and vexpress (for qemu) all out of the same bits
[15:19] <apw> pretty good start me thinks
[15:19] <ogasawara> apw: yep, I saw the chatter, it's sweet!
[15:20]  * apw is going to make a qemu'able image from his omap board when this test is done
[15:21] <ogasawara> apw: ok, pushed to master-next what I'm intending for the upload
[15:22] <ogasawara> apw: I've not yet tagged or reset master
[15:22] <ogasawara> apw: will do so after my builds and testing are good
[15:23] <apw> yep
[15:38]  * ogasawara back in 20
[17:10] <ppisati>  /me -> EOW
[17:10] <ppisati> meh
[17:12] <ocdtech> What do these errors mean?  http://dpaste.com/903980/
[17:19] <sforshee> ocdtech, it means there are some coding errors in the kernel you're trying to build
[17:24] <ocdtech> sforshee: are the error in the code or the .config ?
[17:25] <sforshee> ocdtech, the code
[17:26] <ocdtech> my source is the 3.2.37 stable from kernel.org how would errors get introduced?  If run make -i will it complete?  I know the kernel may not run if it does.
[17:27] <sforshee> ocdtech, you haven't modified the code at all? Applied any extra patches?
[17:27] <sforshee> it's possible the errors only show up under certain configs, but it definitely looks like code errors to me
[17:29] <ocdtech> sforshee: I applied only one patch from a known good tarball.  It was used on another machine in my office a few weeks ago.
[17:30] <sforshee> ocdtech, to the same kernel version? If it was a different kernel version then it may contain changes incompatible with 3.2.37.
[17:31] <ocdtech> sforshee: he was using 3.2.23 and the patch worked fine, but I can't find source for 3.2.23
[17:32] <ocdtech> sforshee: think that's the problem?
[17:32] <apw> ocdtech, well the simple test is to unapply the patch and see if it compiles without, if so then its the patch
[17:33] <ocdtech> apw: I didn't know I could do that.  Off to google I go!
[17:33] <apw> ocdtech, patch -R undoes patch
[17:34] <ocdtech> apw: Trying it now
[17:46] <ocdtech> apw: I get the same errors after patch is removed.  Would an environment variable cause these errors?
[17:48] <apw> not likely
[17:49] <apw> ocdtech, though i can also say that 3.2.37 built just fine in our mainline automated builds
[17:51] <ocdtech> I've only been using linux for about 6-7 months.  This is my first kernel build so I was half expecting problems.
[17:53] <sforshee> ocdtech, the errors are exactly the same?
[17:53] <ocdtech> sforshee: yes
[17:53] <sforshee> arch/x86/kernel/init_task.c:31:8: error: unknown field ‘deadline’ specified in initializer
[17:54] <sforshee> ocdtech, I'm looking at 3.2.37 and there shouldn't be any attempts to initialize a field named deadline
[17:55] <ocdtech> sforshee: is it refering to the I/O scheduler?
[17:58] <sforshee> sforshee, this is initialization of the task_struct
[17:58] <sforshee> gotta head out for a while, back in an hour or so
[17:58]  * sforshee -> lunch
[17:59] <ocdtech> sforshee: enjoy.
[18:06] <ocdtech> what is the command for pulling the build .config out of the currently running kernel?
[18:14]  * henrix -> EOD
[18:17] <bjf> ocdtech, if you are running ubuntu you can find the config at /boot/config-$(uname -r)
[18:37] <ocdtech> bjf: thanks
[20:37]  * ogasawara lunch
[20:47]  * llstarks dinner