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