Issue metadata
Sign in to add a comment
|
Crash on gl::GLContextEGL::MakeCurrent on Linux / Intel IGD |
||||||||||||||||||||||||
Issue descriptionSplitting this from Issue 738961 User is getting recurrent crashes like crash/409d861508000000 crash/79df71de40000000 And according to crash there is quite a number of those crashes in 61 (see go/wqbwe) which look like this: 0x00007ff3e5da0c24 (libEGL.so + 0x00005c24 ) 0x0000558c3fa531bf (chrome + 0x02c621bf ) 0x0000558c3fa552cd (chrome -gl_context_egl.cc:192 ) gl::GLContextEGL::MakeCurrent(gl::GLSurface*) 0x0000558c3dac515f (chrome -gpu_info_collector.cc:55 ) gpu::CollectGraphicsInfoGL(gpu::GPUInfo*) 0x0000558c3dac73ae (chrome -gpu_info_collector_linux.cc:20 ) gpu::CollectContextGraphicsInfo(gpu::GPUInfo*) 0x0000558c3fadda95 (chrome -gpu_init.cc:91 ) gpu::GpuInit::InitializeAndStartSandbox(base::CommandLine const&) 0x0000558c41e1c897 (chrome -gpu_main.cc:267 ) content::GpuMain(content::MainFunctionParams const&) 0x0000558c3ed24254 (chrome -content_main_runner.cc:740 ) content::ContentMainRunnerImpl::Run() 0x0000558c40010e2f (chrome -main.cc:179 ) service_manager::Main(service_manager::MainParams const&) 0x0000558c3ed23031 (chrome -content_main.cc:19 ) content::ContentMain(content::ContentMainParams const&) 0x0000558c3d956260 (chrome -chrome_main.cc:123 ) ChromeMain jbauman: one thing I noticed in the cmdline switches is: --use-gl=swiftshader-webgl. we seem to have had problems in the past with that on the bots ( Issue 720933 ), although this is affective a live user. merlin: could you please copy/paste here the output of your chrome://gpu ?
,
Jul 6 2017
To give more details, it's a thinkpad P70 with dual graphics, nvidia and intel. I'm aware that the intel graphics aren't the best, but they are low battery use and not closed source and kernel tainting like the nvidia ones, so I do not use nvidia. saruman:~$ xrandr --listproviders Providers: number : 2 Provider 0: id: 0x7a cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 1 associated providers: 0 name:modesetting Provider 1: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 4 outputs: 3 associated providers: 0 name:modesetting [ 73.575] (II) xfree86: Adding drm device (/dev/dri/card1) [ 73.576] (II) xfree86: Adding drm device (/dev/dri/card0) [ 73.588] (--) PCI:*(0:0:2:0) 8086:191b:17aa:222d rev 6, Mem @ 0xd2000000/16777216, 0x60000000/536870912, I/O @ 0x00006000/64, BIOS @ 0x????????/131072 [ 73.588] (--) PCI: (0:1:0:0) 10de:13b2:17aa:222d rev 162, Mem @ 0xd3000000/16777216, 0xc0000000/268435456, 0xd0000000/33554432, I/O @ 0x00005000/128, BIOS @ 0x????????/524288 [ 73.597] (II) LoadModule: "modesetting" [ 73.597] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so [ 73.598] (II) Module modesetting: vendor="X.Org Foundation" [ 73.598] compiled for 1.19.2, module version = 1.19.2 [ 73.598] Module class: X.Org Video Driver [ 73.598] ABI class: X.Org Video Driver, version 23.0 [ 73.598] (II) LoadModule: "fbdev" [ 73.598] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so [ 73.598] (II) Module fbdev: vendor="X.Org Foundation" [ 73.598] compiled for 1.19.0, module version = 0.4.4 [ 73.598] Module class: X.Org Video Driver [ 73.598] ABI class: X.Org Video Driver, version 23.0 [ 73.598] (II) LoadModule: "vesa" [ 73.598] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so [ 73.599] (II) Module vesa: vendor="X.Org Foundation" [ 73.599] compiled for 1.19.0, module version = 2.3.4 [ 73.599] Module class: X.Org Video Driver [ 73.599] ABI class: X.Org Video Driver, version 23.0 [ 73.599] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [ 73.599] (II) FBDEV: driver for framebuffer: fbdev [ 73.599] (II) VESA: driver for VESA chipsets: vesa [ 73.637] (II) modeset(0): using drv /dev/dri/card0 [ 73.637] (II) modeset(G0): using drv /dev/dri/card1 ii libdrm-intel1:amd64 2.4.74-1 ii xserver-xorg-core 2:1.19.2-1 ii xserver-xorg-video-intel 2:2.99.917+git20161206-1
,
Jul 6 2017
Now, I just noticed that I've been getting this in my Xorg.log: [ 5031.435] (WW) modeset(0): flip queue failed: Invalid argument [ 5031.435] (WW) modeset(0): Page flip failed: Invalid argument [ 5031.435] (EE) modeset(0): present flip failed [ 5031.519] (WW) modeset(0): flip queue failed: Invalid argument [ 5031.519] (WW) modeset(0): Page flip failed: Invalid argument [ 5031.519] (EE) modeset(0): present flip failed On the plus side, once chrome starts, it seems to work without crashing, although it's true that google maps with GL is slow as molasses. In case it helps: saruman:~# grep . /sys/module/i915/parameters/* /sys/module/i915/parameters/alpha_support:0 /sys/module/i915/parameters/disable_display:N /sys/module/i915/parameters/disable_power_well:1 /sys/module/i915/parameters/edp_vswing:0 /sys/module/i915/parameters/enable_cmd_parser:Y /sys/module/i915/parameters/enable_dc:-1 /sys/module/i915/parameters/enable_dpcd_backlight:N /sys/module/i915/parameters/enable_dp_mst:Y /sys/module/i915/parameters/enable_execlists:1 /sys/module/i915/parameters/enable_fbc:1 /sys/module/i915/parameters/enable_guc_loading:0 /sys/module/i915/parameters/enable_guc_submission:0 /sys/module/i915/parameters/enable_gvt:N /sys/module/i915/parameters/enable_hangcheck:Y /sys/module/i915/parameters/enable_ips:1 /sys/module/i915/parameters/enable_ppgtt:3 /sys/module/i915/parameters/enable_psr:0 /sys/module/i915/parameters/enable_rc6:1 /sys/module/i915/parameters/error_capture:Y /sys/module/i915/parameters/fastboot:N /sys/module/i915/parameters/force_reset_modeset_test:N /sys/module/i915/parameters/guc_log_level:-1 /sys/module/i915/parameters/inject_load_failure:0 /sys/module/i915/parameters/invert_brightness:0 /sys/module/i915/parameters/load_detect_test:N /sys/module/i915/parameters/lvds_channel_mode:0 /sys/module/i915/parameters/lvds_use_ssc:-1 /sys/module/i915/parameters/mmio_debug:0 /sys/module/i915/parameters/modeset:1 /sys/module/i915/parameters/nuclear_pageflip:N /sys/module/i915/parameters/panel_ignore_lid:1 /sys/module/i915/parameters/prefault_disable:N /sys/module/i915/parameters/reset:Y /sys/module/i915/parameters/semaphores:0 /sys/module/i915/parameters/use_mmio_flip:0 /sys/module/i915/parameters/vbt_sdvo_panel_type:-1 /sys/module/i915/parameters/verbose_state_checks:Y
,
Jul 6 2017
Hmm I am not an expert of the field, but shouldn't you be using the intel driver (xf86-video-intel ) instead of the generic fbdev/mesa? I have a i915 (IGD from a Skylake) at home, GL and maps works fine in chrome. WIll check once I get home how my Xorg config looks like.
,
Jul 6 2017
I didn't post the whole Xorg log, but it's actually using [ 73.597] (II) LoadModule: "modesetting" [ 73.597] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so the other 2 drivers autoload as fallback since I don't have an xorg.conf, but they aren't being used. Debian has apparently switched to the kernel mode setting/KMS drivers
,
Jul 6 2017
,
Jul 6 2017
Now, I want to be fair to you and I totally understand that Xorg drivers and 3D on linux is a never ending battle (I know, been using linux for more than 20 years). I'm happy to work with you to give you any info that can help, but I also understand if the intel drivers are broken enough or if the xorg KMS modesetting drivers are broken in ways that affect you. Basic 3D works on my laptop though. Also, I'm merlin@google in MTV-1842. If somehow you'd like to see my laptop for easier debugging, that can be arranged.
,
Jul 6 2017
crash/409d861508000000 and crash/79df71de40000000 are cases of Issue 720933 . It got fixed in Beta 59.0.3071.64, so we're going to see crashes from 59.0.3071.61 for as long as people/machines are using that version on a system with blacklisted/no GPU trying to run WebGL content. merlin@'s problem seems to be entirely different. Note that Google Maps will not use WebGL when running on SwiftShader (it will only show a 2D map), so I'm not sure why it's slow (nor is SwiftShader slow as molasses). However, we're aware of some blacklisting issues. We're now blacklisting all uses of the GPU when it's blacklisted for WebGL. Given the relatively low number of people affected, and the expectation that CPU compositing is still quite fast, this hasn't alarmed us. But it's quite possible that the generic drivers for these dual GPU systems have some very slow code paths for getting CPU rendered pixels out on the screen. We plan on making sure that SwiftShader rendered WebGL can be combined with GPU compositing, but it's going to take a while to be able to do that. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by mer...@gmail.com
, Jul 6 2017