[07:19] <infinity> zequence: Merry Christmas: https://bugs.launchpad.net/ubuntu/+source/linux-lowlatency/+bug/1403242
[07:20] <infinity> zequence: Note that Andy and I did the previous one, so make sure you're picking up our changes and not working in dirty local trees.
[17:14] <hallyn> i've got a potentially stupid question about 'cat' and stat(2).  When I cat a fuse file, it returns empty unless the getattr() function returns a non-zeor size.  But stat(2) on /proc/cpuinfo returns 0 size, while cat /proc/cpuinfo certainly works.
[17:20] <hallyn> just wondering what cat is actually looking at
[17:20] <hallyn> bc it seems to be treating procfiles differently
[17:41] <infinity> hallyn: That may actually be a question about fuse.
[17:42] <hallyn> true
[17:42] <hallyn> yeah actually i think i get it,
[17:42] <hallyn> if you do open(file); fseek(f, 0, SEEK_END); ftell(f); then fuse returns what it got fro mgetattr, i bet
[17:43] <hallyn> though no, you get 0 in a procfile, 
[17:43] <hallyn> but yeah i'm sur eit's something fuse is doing
[17:43] <hallyn> so i'll just return the max possible size and screw it :)
[17:44] <apw> hallyn, have you strace'd cat in both cases to see what cat actually does ?
[17:52] <hallyn> apw: oddly, in both caess it does open; fstat;  and with /proc/cpuinfo you can see fstat returns st-size=0.  but it goes on to read the write # chars.  no seek/ftell.  magic
[17:53] <apw> hallyn, and for your fuse it does what, open; fstat; seek; ftell; fails ?
[17:55] <cking> the code that does the stat with st_size=0 may of course be ignoring that field, it may be stat'ing the file for other reasons
[17:55] <hallyn> apw: no, it doesn't seek/ftell.  does the exact same things as with /proc
[17:55] <hallyn> cking: right, but the point is that when my fusefs returns st_size = 0, then 'cat somefile' always returns nothing,
[17:55] <hallyn> even though my read() is defined
[17:55] <apw> right it is fstating the file, not for its size, but to check that in and out arn't the same
[17:56] <hallyn> when i use a non-zero, then it does
[17:56] <hallyn> in and out?
[17:56] <apw> is it chekcing the major minors and the like
[17:56] <apw> it is making sure you arn't doing like cat <foo >foo
[17:56] <apw> cat foo >foo etc
[17:56] <hallyn> oh
[17:57] <apw> hallyn, and it is then oging to "read"
[17:57] <apw> what does the failed read case look like
[17:57] <apw> in the strace
[17:59] <cking> of course, reading from /proc/.. one can never really tell what the size will be until it is read, so fstat won't work on getting the size
[17:59] <apw> right, and that shouldn't matter, cause it does "read" regardless
[17:59] <hallyn> cking and the same is true of my fusefs, ideally, since it sits on top of proc and cgroups
[17:59] <apw> hallyn, what does it return for inode numbers and the like
[18:00] <apw> those being "always the same" etc might throw it
[18:00] <hallyn> apw: http://paste.ubuntu.com/9552719/ , so actually i bet fuse is the one saying "nothing to see here s oi wont' call read()"
[18:01] <apw> and its behaviour changes depending if the stat returns that it is not REG
[18:01] <hallyn> (which makes sense as i'm pretty sure i verified this with manual read(2) before)
[18:01] <hallyn> but the files are REG
[18:01] <hallyn> so must be fuse, in kernel or libfuse
[18:01] <hallyn> it's a pain :)  but not a blocker at this point
[18:01] <apw> hallyn, so this is a fuse remount of a /proc ?
[18:03] <apw> hallyn, and yes, we did a real read, in the hope there was data, and fuse said 0 bytes
[18:08] <hallyn> apw: yeah it's an overlay for cpuinfo, meminfo, etc.  (file-by-file, not the whoel fs)
[18:08] <hallyn> apw: still wonder whether it's libfuse optimizing rather than the kernel... probably 
[18:08] <apw> it might well make sense for it to use the underlying stat info to tell us the attmept to read is pointless, but ... odd
[18:29] <infinity> hallyn: It certainly still seems to be reading it, so it's fuse returning the empty file.
[18:30] <hallyn> infinity: yeah, it's still possible that libfuse intercepts, but that would seem even sillier than the kernel fuse module doing so
[18:31] <infinity> hallyn: Line 37 is clearly a 0-length read, so your assertion that the read doesn't happen if the stat is 0 is false.
[18:31] <infinity> hallyn: It stats, it reads, it gets nothing from fuse, you get nothing on stdout.
[18:32] <infinity> hallyn: Oh, I have no opinion if it's userspace or the kernel module, but it's clearly the filesystem returning nothing.
[18:35] <hallyn> infinity: i'm asserting that *my* read isn't being called
[18:36] <infinity> hallyn: Curious.  cat's sure is.
[18:37] <hallyn> cat's?
[18:37] <hallyn> yeah the *system* call is being called.  
[18:38] <hallyn> so i guess i need to see whether i can 'trick' fuse into calling read regardless
[18:38] <hallyn> *calling my read handler
[18:38] <hallyn> (we have some naming problems here :)
[18:38] <apw> hallyn, it optimising it out, given it could work seems wrong
[18:39] <infinity> hallyn: Well, the system call is being called, but returning no content.
[18:39] <infinity> hallyn: So this still seems to be an issue with the filesystem.
[18:40] <hallyn> agreed
[19:01] <retabell> a Prob with 3.18.0-7 (own build)
[19:01] <retabell> http://paste.debian.net/137128/
[19:42] <vmesons> ubu-14.10 - unwanted suspend: http://pastebin.com/7Gr11Q3F -- I might get around to reporting a bug.. :)
[19:54] <apw> retabell, i do not get that with the builds of teh same tip i am running
[20:04] <retabell> ok thx
[22:01] <ChrisP1948> After googling for this which I 'think' has been causing lockups [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... render ring idle
[22:02] <ChrisP1948> I filed a bug with Ubuntu - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1402331 and it was suggested in a comment that I update my bios
[22:04] <ChrisP1948> I also, after  more googling found that others not using Ubuntu have experienced this issue so I added to a bug report here https://bugs.freedesktop.org/show_bug.cgi?id=75394 
[22:05] <ChrisP1948> Today I received a comment on this bug wanting me to install and test the latest 3.18 kernel which so far I haven't done as I don't want to mess up my system.
[22:06] <ChrisP1948> Earlier today I came home to a black screen with a mouse cursor only and had to reboot using the power button. Though the system kept working in the background
[22:07] <ChrisP1948> I could not find the above error in my syslog. I'm imputing all this looking for some guidance