[00:34] <rostam> apw, I do not think I have serial port on this system
[01:20] <apw> rostam, then it could just be a new job which will fail and be disabled when you don't have them ... ie could be an upstart config issue
[02:40] <rostam> apw, thank you for shading some info on this. any more info on how to debug this please? thx
[04:17] <larsduesing> short informational question: what do the tags "kernel-da-key" & "kernel-key" mean? Is there somewhere a list?
[04:18] <larsduesing> (only curiousity...)
[05:28] <apw> larsduesing, they are literally tags in launchpad we use to group bugs we are keeping a particular eye on
[05:28] <apw> larsduesing, we mostly use them to list bugs by tag in launchpad
[06:57] <cheater_3> hi
[06:57] <cheater_3> do the kernels in the kernel ppa have pae?
[11:03] <brendand> can someone help me understand this strace? http://paste.ubuntu.com/6294278/
[11:04] <cheater_3> do the kernel builds on kernel-ppa have pae support?
[11:04] <brendand> i think 'ioctl(3, RTC_WIE_ON or RTC_WKALM_SET, {enabled=1, pending=0, {tm_sec=4, tm_min=0, tm_hour=11, tm_mday=24, tm_mon=9, tm_year=113, ...}}) = 0' is where it's setting the wakealarm
[11:06] <brendand> it's using ioctl on the rtc device, right?
[11:10] <brendand> the documentation for ioctl says it needs an open file descriptor, but i can't see where it was opened
[11:11] <brendand> oh i see it's on file descriptor 3, which is /dev/rtc0
[11:12] <brendand> cking, meaning - i need to talk to you about this ^
[11:13] <brendand> cking, fwts aborts the wakealarm test on ARM, because it doesn't have /sys/class/rtc/rtc0/wakealarm
[11:13] <brendand> cking, but rtcwake appears to operate via ioctls on /dev/rtc0
[11:13] <brendand> cking, and on the ARM hardware i'm testing, rtcwake does work
[11:14] <cking> brendand, file a bug and I will make it operate akin to what rtc wake is doing
[11:15] <cking> recall that this was originally just hacked up for x86, so never been tested, so bugs like this will occur
[11:16] <brendand> cking, cool - cheers
[11:16] <cking> brendand, the trace showed: open("/sys/class/rtc/rtc0/device/power/wakeup", O_RDONLY) = 3
[11:17] <cking> oops, forget that
[11:18] <cking> brendand, I meant open("/dev/rtc0", O_RDONLY|O_CLOEXEC)   = 3  (see line 52)
[11:18] <brendand> cking, one thing though is that we are using the wakealarm interface in our test code
[11:19] <brendand> cking, so either that *should* be there, and fwts should be updated to fail if it's not
[11:19] <brendand> cking, or we need to update our test code to use ioctl's or whatever else
[11:20] <cking> brendand, or something like that, file a bug and I will look at it, sorry but I'm fixing a more pressing bug at the mo
[11:20] <cking> brendand, when do you need a fix for this?
[11:20] <brendand> cking, it's not urgent
[11:21] <brendand> manjo, just the person i needed :)
[11:21] <cking> brendand, OK, I will pop it on my list of things for friday or monday :-)
[11:25] <brendand> cking, here: https://bugs.launchpad.net/bugs/1244184. like i said, not urgent for now - so feel free to schedule it whenever. if it becomes urgent i'll surely update the bug
[11:25] <ubot2> Launchpad bug 1244184 in Firmware Test Suite "wakealarm test needs to be updated to pass when rtcwake would work" [Undecided,New]
[11:26] <cking> brendand, ok, thanks for finding and reporting this
[11:27] <brendand> cking, note there's an open question about whether the wakealarm interface should actually be there anyway. i'm trying to find out
[11:27] <brendand> cking, will update the bug if i get more info
[11:27] <cking> brendand, no worries about that, I'll sort it out
[13:11] <erle-> last month amd had fglrx 13.9 on their website, now they are back to 13.4
[13:11] <erle-> how come?
[13:12] <erle-> sorry, if you don't want to deal with those proprietary questions
[14:02]  * apw yawns
[14:03] <cking> morning apw
[14:04]  * cking wonders how we ever got stuff done w/o virtual machines
[14:05] <henrix> cking: with serial cables? :)
[14:07] <cking> apw, got a fix to the ecryptfs bug, just exercising it like mad right now
[14:08] <apw> cking, hey that was quick, have you talked to tyler he was also sounding like he was looking
[14:08] <apw> cking, ie does he know you have it fixed :) so he can stop
[14:08] <cking> he's not online yet, but I will prod him asap as he comes on line
[14:08] <apw> tyhicks, ^^
[14:08] <cking> tyhicks, hey, I got a fix :-)
[14:08] <apw> :)
[14:30]  * cking has a late lunch break
[14:57] <cking> brendand, can you reply back to bug 1244184 as I need a little more data
[14:57] <ubot2> Launchpad bug 1244184 in Firmware Test Suite "wakealarm test needs to be updated to pass when rtcwake would work" [Medium,In progress] https://launchpad.net/bugs/1244184
[14:58] <brendand> cking, sure
[15:01] <cheater_3> hi
[15:01] <cheater_3> do the kernel builds in kernel-ppa have pae support?
[15:17] <brendand> cking, which options will get me the most info out of fwts?
[15:22] <cking> brendand, just run it the way you tripped the issue and send me the bit of text that reports the error you saw
[15:23] <brendand> cking, ok - the body of the results.log should do i think
[15:23] <cking> cool
[15:48] <tyhicks> cking: hey - I had come up with a potential fix last night and let some tests run while I was sleeping
[15:49]  * tyhicks looks to see if we came up with the same thing
[15:49] <cking> heh, could be a dup of effort
[15:49] <cking> i was on a plane last night so I only saw the email this morning
[15:50] <tyhicks> Same fix :)
[15:50] <tyhicks> I hadn't updated the bug yet
[15:51] <tyhicks> I noticed that corruption would start at (4G - 8192 + 1) upper file size, would would be (4G + 1) lower file size
[15:51] <tyhicks> and then noticed the recent change that I had made to the lower offset calculation
[15:52] <cking> tyhicks, i looked at a bunch of other file systems and saw they needed to do the same cast before the shift too
[15:53] <tyhicks> ah, yep
[15:53] <cking> well, shall I leave it in your hands?
[15:57] <cking> tyhicks, I'll drop doing any more on this then, are you going to SRU it for Saucy?
[15:57] <tyhicks> cking: I'm going to use your patch since you've already got the commit message done
[15:58] <tyhicks> cking: I'll get it to Linus today and I will also do the SRU
[15:58] <cking> ok, thanks, whatever really :-)
[15:59] <tyhicks> cking: thanks for the help! :)
[16:11] <brendand> cking, updated
[16:11] <cking> brendand, ta, I'm working on a fix now
[16:12] <brendand> cking, did you make a decision about whether the wakealarm file should be there?
[16:12] <cking> brendand, see my comment in the bug, I'll update it when I am certain
[16:20] <erle-> jsalisbury, i reopened the bug now
[16:20] <erle-> problem still exists will all 3.11 versions and with fglrx purged
[16:21] <jsalisbury> erle-, ack.  can you post the bug number?
[16:22] <erle-> #1241582
[16:22] <erle-> i am just adding reports
[16:24] <jsalisbury> erle-, thanks, I'll take a look and update the bug.
[16:25] <erle-> I just added a list of kernel versions I tested
[16:25] <erle-> all from ppa or from official repo
[16:26] <jsalisbury> erle-, Is the bug fixed with 3.11.0-13.20 ?
[16:26] <erle-> wait, i will try it out
[16:26] <jsalisbury> erle-, great, thanks
[16:26] <erle-> costs me a lot of time btw, its my main machine :)
[16:27] <jsalisbury> erle-,  I believe it should be resolved in that kernel.  It might also be good to test the latest Trusty kernel, if you have a chance.
[16:29] <erle-> jsalisbury, 3.11.0-13.20 came up this time
[16:33] <erle-> jsalisbury, worked another time
[16:34] <erle-> ok, maybe 3.11.0-13.20 is fine
[16:35] <jsalisbury> erle-, cool.  that means the bug should be fixed in the next Saucy update.
[16:35] <erle-> i will put status to "fix commited" again
[16:36] <erle-> i will report if anything bad happens
[16:36] <erle-> i will go without fglrx for a while now
[16:36] <jsalisbury> erle-, thanks for all the help testing
[16:37] <erle-> i should have written down some notes about what version crashed when
[17:02] <rostam> HI all,  I am porting a driver for a capture card. The driver was originally developed with Linux 2.6.32 (RHEL 6.4) now I am porting it to linux 3.8 (Ubuntu 12.04). There was only one change that I had to do, ".ioctl"  to ".unlocked_ioctl"  in  'struct file_operations'.  The driver loads fine but it fails on any ioctl with "Unknown ioctl cmd ..." any help greatly appreciated.  Thx 
[19:20] <cking> brendand, i'll have a fix for you to test first thing tomorrow
[19:20] <brendand> \o/
[21:02] <coredump> Soooo
[21:02] <coredump> tools/hv refuses to compile
[21:02] <coredump> hv_kvp_daemon.c:1450: error: 'CN_KVP_IDX' undeclared (first use in this function)
[21:03] <coredump> any hint?
[21:44] <apw> coredump, the debian/rules in the package manage to build it, the incantation there should help