Adding relevant mailing lists. Really, doing bug fixing in private isn't cool. And if it needs to be then please go through intel channels and don't cc the community maintainer addresses. -Daniel On Fri, Nov 15, 2013 at 9:29 PM, Bryan Christ <bryan.christ@xxxxxxxxxxxxx> wrote: > Xiang, > > Have you any luck reproducing the bug using the script that Bruce > provided? > > On Fri, 2013-11-15 at 11:03 +0800, Xiang, Haihao wrote: >> On Thu, 2013-11-14 at 19:33 -0600, Bryan Christ wrote: >> > Xiang, >> > >> > First, thanks for the speedy reply. Secondly, to confirm, there are no >> > other programs running that would use OpenGL. We literally let the >> > system boot to GDM and sit there. Our programs run on a standard >> > console or daemonized. >> > >> > I do believe we have seen the problem with heavy use of h264encode. I'm >> > pretty sure it happened when we attempted to run several instances of >> > the program simultaneously. >> >> We will try to reproduce the issue, how many instances are run in your >> testing ? >> >> > >> > How can we retrieve the data from /sys/kernel/debug/dri/0 with the >> > system hard locked? >> >> Can you remote login into your system ? If not, I have no idea too . >> >> > >> > Bryan >> > >> > On Fri, 2013-11-15 at 08:42 +0800, Xiang, Haihao wrote: >> > > Hi, >> > > >> > > Besides video encoding, do you run any other application which may use >> > > GPU, such as a OpenGL program ? Is this issue can be reproduced by the >> > > original h264encode ? If not, it would be better to provide a simple >> > > test case. Could you attach the relevant i915_error_state ? You can >> > > find this file in /sys/kernel/debug/dri/0. >> > > >> > > Thanks >> > > Haihao >> > > >> > > >> > > > Xiang, >> > > > >> > > > I want to again thank you for all your help so far. After quite a bit >> > > > of testing and performance benchmarking, we purchased a double digit >> > > > quantity order of Haswell systems. We have subsequently developed an >> > > > ffmpeg codec based on the 'h264encode' test program which seems to work >> > > > very well. The systems we have deployed are somewhat "headless". In >> > > > other words, we initialize the X stack but all of our tools run on the >> > > > standard console. Unfortunately, we are occasionally seeing our sandbox >> > > > server freeze with no kernel output to the console. It seems to >> > > > coincide with GPU usage at the time of the freeze. We really need help >> > > > debugging this and possibly getting a fix. Our current stack is: >> > > > >> > > > Fedora 19 >> > > > 3.11.7 kernel >> > > > intel driver 2.99.906 >> > > > libva 1.2.1 >> > > > Xorg 1.14.3 >> > > > libdrm 2.4.46 >> > > > vaapi intel driver 1.2.1 >> > > > intel gpu tools 1.3 >> > > > >> > > > Again, any help you or anyone on this email list can provide would be >> > > > greatly appreciated. >> > > > >> > > > Regards, >> > > > Bryan Christ, >> > > > >> > > > MediaFire.com >> > > > Director of Software Engineering >> > > > >> > > > >> > > > >> > > >> > > >> > >> > >> >> > > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
