| infinity | zequence: Merry Christmas: https://bugs.launchpad.net/ubuntu/+source/linux-lowlatency/+bug/1403242 | 07:19 |
|---|---|---|
| ubot5 | Launchpad bug 1403242 in Kernel SRU Workflow "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress] | 07:19 |
| 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. | 07:20 |
| === zyga-afk is now known as zyga | ||
| === lifeless_ is now known as lifeless | ||
| === jdstrand_ is now known as jdstrand | ||
| 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:14 |
| hallyn | just wondering what cat is actually looking at | 17:20 |
| hallyn | bc it seems to be treating procfiles differently | 17:20 |
| infinity | hallyn: That may actually be a question about fuse. | 17:41 |
| 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:42 |
| 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:43 |
| apw | hallyn, have you strace'd cat in both cases to see what cat actually does ? | 17:44 |
| 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:52 |
| apw | hallyn, and for your fuse it does what, open; fstat; seek; ftell; fails ? | 17:53 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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 | 17:59 |
| 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:00 |
| 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:01 |
| apw | hallyn, and yes, we did a real read, in the hope there was data, and fuse said 0 bytes | 18:03 |
| 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:08 |
| infinity | hallyn: It certainly still seems to be reading it, so it's fuse returning the empty file. | 18:29 |
| hallyn | infinity: yeah, it's still possible that libfuse intercepts, but that would seem even sillier than the kernel fuse module doing so | 18:30 |
| 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:31 |
| infinity | hallyn: Oh, I have no opinion if it's userspace or the kernel module, but it's clearly the filesystem returning nothing. | 18:32 |
| hallyn | infinity: i'm asserting that *my* read isn't being called | 18:35 |
| infinity | hallyn: Curious. cat's sure is. | 18:36 |
| hallyn | cat's? | 18:37 |
| hallyn | yeah the *system* call is being called. | 18:37 |
| 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:38 |
| 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:39 |
| hallyn | agreed | 18:40 |
| retabell | a Prob with 3.18.0-7 (own build) | 19:01 |
| retabell | http://paste.debian.net/137128/ | 19:01 |
| vmesons | ubu-14.10 - unwanted suspend: http://pastebin.com/7Gr11Q3F -- I might get around to reporting a bug.. :) | 19:42 |
| apw | retabell, i do not get that with the builds of teh same tip i am running | 19:54 |
| retabell | ok thx | 20:04 |
| === ara is now known as Guest47294 | ||
| === mwhudson_ is now known as mwhudson | ||
| ChrisP1948 | After googling for this which I 'think' has been causing lockups [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... render ring idle | 22:01 |
| 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:02 |
| ubot5 | Launchpad bug 1402331 in linux (Ubuntu) "System will periodically lockup with [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... render ring idle" [Low,Incomplete] | 22:02 |
| 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:04 |
| ubot5 | Freedesktop bug 75394 in DRM/Intel "System hangs randomly with error message: [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... render ring idle" [Critical,Needinfo] | 22:04 |
| 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:05 |
| 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:06 |
| ChrisP1948 | I could not find the above error in my syslog. I'm imputing all this looking for some guidance | 22:07 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!