lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180523191222.GP23723@intel.com>
Date:   Wed, 23 May 2018 22:12:22 +0300
From:   Ville Syrjälä <ville.syrjala@...ux.intel.com>
To:     Vito Caputo <vcaputo@...garu.com>
Cc:     linux-kernel <linux-kernel@...r.kernel.org>, daniel.vetter@...ll.ch
Subject: Re: [REGRESSION] v4.17-rc4: xgalaga fails to start in fullscreen
 (default) mode

On Wed, May 23, 2018 at 11:39:00AM -0700, Vito Caputo wrote:
> On Wed, May 23, 2018 at 09:20:37PM +0300, Ville Syrjälä wrote:
> > On Wed, May 23, 2018 at 11:06:00AM -0700, Vito Caputo wrote:
> > > On Wed, May 23, 2018 at 04:18:05PM +0300, Ville Syrjälä wrote:
> > > > On Wed, May 23, 2018 at 02:49:19AM -0700, Vito Caputo wrote:
> > > > > On Mon, May 21, 2018 at 02:57:18PM -0700, Vito Caputo wrote:
> > > > > > On Mon, May 21, 2018 at 12:53:20PM -0700, Vito Caputo wrote:
> > > > > > > Hello all,
> > > > > > > 
> > > > > > > 4.17-rc4 (my latest kernel ATM) consistently fails to start xgalaga
> > > > > > > without -window.  I will try find time to build the latest rc this
> > > > > > > evening.
> > > > > > > 
> > > > > > > > ~$ xgalaga
> > > > > > > > X Error of failed request:  BadValue (integer parameter out of range for operation)
> > > > > > > >   Major opcode of failed request:  152 (XFree86-VidModeExtension)
> > > > > > > >   Minor opcode of failed request:  10 (XF86VidModeSwitchToMode)
> > > > > > > >   Value in failed request:  0x120004e
> > > > > > > >   Serial number of failed request:  199
> > > > > > > >   Current serial number in output stream:  203
> > > > > > > 
> > > > > > > Haven't dug into this much yet, only did a perfunctory check by booting into a
> > > > > > > few older kernels (4.11, 4.12, 4.16) and the problem is absent on all of them.
> > > > > > > It appears to be a 4.17-specific regression right now.
> > > > > > > 
> > > > > > > Also observed, though this is surely a different regression, the game
> > > > > > > ran like molasses with -window, showing some prominent kworkers in top:
> > > > > > > 
> > > > > > >   692 vc        20   0  312852  45884  20556 R  32.0  1.2   0:08.69 Xorg           
> > > > > > >   102 root      20   0       0      0      0 R  11.2  0.0   0:01.43 kworker/1:3    
> > > > > > >    94 root      20   0       0      0      0 I   8.9  0.0   0:00.83 kworker/0:2    
> > > > > > >   696 vc        20   0   39948   4124   2912 S   1.0  0.1   0:05.57 vwm            
> > > > > > >   902 vc        30  10   46372   4144   3500 S   0.7  0.1   0:00.08 xgalaga        
> > > > > > >   891 vc        30  10   44924   3868   3156 R   0.3  0.1   0:00.09 top            
> > > > > > >   903 vc        30  10    4180   1184   1100 S   0.3  0.0   0:00.01 xgal.sndsrv.oss
> > > > > > > 
> > > > > > > The windowed performance issue was observed on the older kernels tested
> > > > > > > as well, though 4.11 felt better and didn't have the busy kworkers.
> > > > > > > 
> > > > > > > I have not attempted to play xgalaga for ages, but it used to be perfectly
> > > > > > > playable on this machine in windowed mode when I last did.
> > > > > > > 
> > > > > > > Machine is the venerable Thinkpad X61s, 1.8Ghz, Debian 9, config attached.
> > > > > > > 
> > > > > > 
> > > > > > Just built and booted v4.17-rc6, still broken.
> > > > > 
> > > > > Bisected to:
> > > > > 
> > > > > e995ca0b8139c5f6807095464e969931b443f55a is the first bad commit
> > > > > commit e995ca0b8139c5f6807095464e969931b443f55a
> > > > > Author: Ville Syrjälä <ville.syrjala@...ux.intel.com>
> > > > > Date:   Tue Nov 14 20:32:58 2017 +0200
> > > > > 
> > > > >     drm/i915: Provide a device level .mode_valid() hook
> > > > >     
> > > > >     We never support certain mode flags etc. Reject those early on in the
> > > > >     mode_config.mode_valid() hook. That allows us to remove some duplicated
> > > > >     checks from the connector .mode_valid() hooks, and it guarantees that
> > > > >     we never see those flags even from user mode as the
> > > > >     mode_config.mode_valid() hooks gets executed for those as well.
> > > > >     
> > > > >     Signed-off-by: Ville Syrjälä <ville.syrjala@...ux.intel.com>
> > > > >     Link: https://patchwork.freedesktop.org/patch/msgid/20171114183258.16976-11-ville.syrjala@linux.intel.com
> > > > >     Reviewed-by: Daniel Vetter <daniel.vetter@...ll.ch>
> > > > 
> > > > Hmm. I guess xgalaga passes some garbage in via xf86vidmode which
> > > > the ddx doesn't validate before passing it on to the kernel. So far
> > > > I can't reproduce the problem here unfortnately.
> > > > 
> > > > Can you try the following patch and reproduce the problem with
> > > > drm.debug=0xe passed to the kernel so that we can seewhat the bad
> > > > modeline looks like?
> > > > 
> > > 
> > > dmesg after xgalaga fails:
> > > 
> > > ```
> > > [   75.617448] [drm:drm_mode_convert_umode] Bad user mode:
> > > [   75.617455] [drm:drm_mode_debug_printmodeline] Modeline 57:"800x600" 0 81000 800 832 928 1080 600 600 602 625 0x0 0x25
> > 
> > 0x20 == dblscan
> > 
> > > [   75.617458] [drm:drm_mode_setcrtc] Invalid mode
> > > ```
> > > 
> > > xrandr --verbose:
> > > 
> > > ```
> > > Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192
> > > LVDS-1 connected primary 1024x768+0+0 (0x44) normal (normal left inverted right x axis y axis) 246mm x 184mm
> > > 	Identifier: 0x41
> > > 	Timestamp:  23375
> > > 	Subpixel:   horizontal rgb
> > > 	Gamma:      1.0:1.0:1.0
> > > 	Brightness: 1.0
> > > 	Clones:    
> > > 	CRTC:       0
> > > 	CRTCs:      0 1
> > > 	Transform:  1.000000 0.000000 0.000000
> > > 	            0.000000 1.000000 0.000000
> > > 	            0.000000 0.000000 1.000000
> > > 	           filter: 
> > > 	EDID: 
> > > 		00ffffffffffff0030ae004000000000
> > > 		3010010380191278eafe609555518726
> > > 		22505421080001010101010101010101
> > > 		01010101010128150040410026301888
> > > 		3600f6b800000018ed10004041002630
> > > 		18883600f6b9000000180000000f0061
> > > 		43326143280f01000daf0714000000fe
> > > 		004e31323158352d4c303620202000ed
> > > 	scaling mode: Full aspect 
> > > 		supported: Full, Center, Full aspect
> > > 	non-desktop: 0 
> > > 		range: (0, 1)
> > > 	link-status: Good 
> > > 		supported: Good, Bad
> > >   1024x768 (0x44) 54.160MHz -HSync -VSync *current +preferred
> > >         h: width  1024 start 1048 end 1184 total 1344 skew    0 clock  40.30KHz
> > >         v: height  768 start  771 end  777 total  806           clock  50.00Hz
> > >   1024x768 (0x45) 65.000MHz -HSync -VSync
> > >         h: width  1024 start 1048 end 1184 total 1344 skew    0 clock  48.36KHz
> > >         v: height  768 start  771 end  777 total  806           clock  60.00Hz
> > >   1024x768 (0x46) 43.330MHz -HSync -VSync
> > >         h: width  1024 start 1048 end 1184 total 1344 skew    0 clock  32.24KHz
> > >         v: height  768 start  771 end  777 total  806           clock  40.00Hz
> > >   960x720 (0x47) 117.000MHz -HSync +VSync DoubleScan
> > >         h: width   960 start 1024 end 1128 total 1300 skew    0 clock  90.00KHz
> > >         v: height  720 start  720 end  722 total  750           clock  60.00Hz
> > >   928x696 (0x48) 109.150MHz -HSync +VSync DoubleScan
> > >         h: width   928 start  976 end 1088 total 1264 skew    0 clock  86.35KHz
> > >         v: height  696 start  696 end  698 total  719           clock  60.05Hz
> > 
> > Where are all these dblscan modes coming from?
> > 
> > Did you add them manually or are they being automatically
> > generated by something?
> > 
> 
> This is pure automagic xserver-xorg-video-intel on i915 drm/kms.
> 
> After booting back into a working 4.16 kernel I see the same xrandr --verbose
> list with all the DoubleScan modes, with which xgalaga is functional.
> 
> There's this in the Xorg.log:
> 
> ```
> [    12.856] (II) intel(0): Output LVDS1 using monitor section Monitor0
> [    12.857] (--) intel(0): found backlight control interface /sys/class/backlight/acpi_video0
> [    12.882] (II) intel(0): Output VGA1 has no monitor section
> [    12.883] (II) intel(0): EDID for output LVDS1
> [    12.883] (II) intel(0): Manufacturer: LEN  Model: 4000  Serial#: 0
> [    12.883] (II) intel(0): Year: 2006  Week: 48
> [    12.883] (II) intel(0): EDID Version: 1.3
> [    12.883] (II) intel(0): Digital Display Input
> [    12.883] (II) intel(0): Max Image Size [cm]: horiz.: 25  vert.: 18
> [    12.883] (II) intel(0): Gamma: 2.20
> [    12.883] (II) intel(0): DPMS capabilities: StandBy Suspend Off
> [    12.883] (II) intel(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4 
> [    12.883] (II) intel(0): First detailed timing is preferred mode
> [    12.883] (II) intel(0): redX: 0.585 redY: 0.335   greenX: 0.319 greenY: 0.529
> [    12.883] (II) intel(0): blueX: 0.149 blueY: 0.135   whiteX: 0.312 whiteY: 0.328
> [    12.883] (II) intel(0): Supported established timings:
> [    12.883] (II) intel(0): 640x480@...z
> [    12.883] (II) intel(0): 800x600@...z
> [    12.883] (II) intel(0): 1024x768@...z
> [    12.883] (II) intel(0): Manufacturer's mask: 0
> [    12.883] (II) intel(0): Supported detailed timing:
> [    12.883] (II) intel(0): clock: 54.2 MHz   Image Size:  246 x 184 mm
> [    12.883] (II) intel(0): h_active: 1024  h_sync: 1048  h_sync_end 1184 h_blank_end 1344 h_border: 0
> [    12.883] (II) intel(0): v_active: 768  v_sync: 771  v_sync_end 777 v_blanking: 806 v_border: 0
> [    12.883] (II) intel(0): Supported detailed timing:
> [    12.883] (II) intel(0): clock: 43.3 MHz   Image Size:  246 x 185 mm
> [    12.883] (II) intel(0): h_active: 1024  h_sync: 1048  h_sync_end 1184 h_blank_end 1344 h_border: 0
> [    12.883] (II) intel(0): v_active: 768  v_sync: 771  v_sync_end 777 v_blanking: 806 v_border: 0
> [    12.883] (II) intel(0): Unknown vendor-specific block f
> [    12.883] (II) intel(0):  N121X5-L06
> [    12.883] (II) intel(0): EDID (in hex):
> [    12.883] (II) intel(0):     00ffffffffffff0030ae004000000000
> [    12.883] (II) intel(0):     3010010380191278eafe609555518726
> [    12.883] (II) intel(0):     22505421080001010101010101010101
> [    12.883] (II) intel(0):     01010101010128150040410026301888
> [    12.883] (II) intel(0):     3600f6b800000018ed10004041002630
> [    12.883] (II) intel(0):     18883600f6b9000000180000000f0061
> [    12.883] (II) intel(0):     43326143280f01000daf0714000000fe
> [    12.883] (II) intel(0):     004e31323158352d4c303620202000ed
> [    12.883] (II) intel(0): Not using default mode "320x240" (doublescan mode not supported)
> [    12.883] (II) intel(0): Not using default mode "400x300" (doublescan mode not supported)
> [    12.883] (II) intel(0): Not using default mode "400x300" (doublescan mode not supported)
> [    12.883] (II) intel(0): Not using default mode "512x384" (doublescan mode not supported)
> [    12.883] (II) intel(0): Not using default mode "640x480" (doublescan mode not supported)
> [    12.883] (II) intel(0): Not using default mode "640x512" (doublescan mode not supported)
> [    12.883] (II) intel(0): Not using default mode "800x600" (doublescan mode not supported)
> [    12.883] (II) intel(0): Not using default mode "896x672" (doublescan mode not supported)
> [    12.883] (II) intel(0): Not using default mode "928x696" (doublescan mode not supported)
> [    12.883] (II) intel(0): Not using default mode "960x720" (doublescan mode not supported)
> [    12.883] (II) intel(0): Not using default mode "576x432" (doublescan mode not supported)
> [    12.883] (II) intel(0): Not using default mode "680x384" (doublescan mode not supported)
> [    12.883] (II) intel(0): Not using default mode "680x384" (doublescan mode not supported)
> [    12.883] (II) intel(0): Not using default mode "700x525" (doublescan mode not supported)
> [    12.883] (II) intel(0): Not using default mode "720x450" (doublescan mode not supported)
> [    12.883] (II) intel(0): Not using default mode "800x512" (doublescan mode not supported)
> [    12.883] (II) intel(0): Not using default mode "840x525" (doublescan mode not supported)
> [    12.883] (II) intel(0): Not using default mode "840x525" (doublescan mode not supported)
> [    12.884] (II) intel(0): Not using default mode "960x540" (doublescan mode not supported)
> [    12.884] (II) intel(0): Not using default mode "960x600" (doublescan mode not supported)

So first it rejected them all, but somehow later they get added back?
Very odd.

Hmm. Must be coming from that default modes thing...

Looks pretty much like ddx bug to me. Does the following ddx patch get
rid of the bogus dblscan modes?

>From 40672b8527313d8bc01aa5cdcda8602687ec0f23 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@...ux.intel.com>
Date: Wed, 23 May 2018 22:10:07 +0300
Subject: [PATCH xf86-video-intel] Don't accept dblscan from xf86DefaultModes[]

---
 src/sna/sna_display.c   | 3 +++
 src/uxa/intel_display.c | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index 6f6bea2e9cad..b38a915ca4ec 100644
--- a/src/sna/sna_display.c
+++ b/src/sna/sna_display.c
@@ -4204,6 +4204,8 @@ sna_output_add_default_modes(xf86OutputPtr output, DisplayModePtr modes)
 	DisplayModePtr i, m, preferred = NULL;
 	int max_x = 0, max_y = 0, max_clock = 0;
 	float max_vrefresh = 0.0;
+	int flags = (output->interlaceAllowed ? V_INTERLACE : 0) |
+		(output->doubleScanAllowed ? V_DBLSCAN : 0);
 
 	if (mon && GTF_SUPPORTED(mon->features.msc))
 		return modes;
@@ -4220,6 +4222,7 @@ sna_output_add_default_modes(xf86OutputPtr output, DisplayModePtr modes)
 
 	m = default_modes(preferred);
 	xf86ValidateModesSize(output->scrn, m, max_x, max_y, 0);
+	xf86ValidateModesFlags(output->scrn, m, flags);
 
 	for (i = m; i; i = i->next) {
 		if (i->Clock > max_clock)
diff --git a/src/uxa/intel_display.c b/src/uxa/intel_display.c
index 809cda1dd56b..431727fc4ac2 100644
--- a/src/uxa/intel_display.c
+++ b/src/uxa/intel_display.c
@@ -919,6 +919,8 @@ intel_output_panel_edid(xf86OutputPtr output, DisplayModePtr modes)
 		DisplayModePtr i, m, p = NULL;
 		int max_x = 0, max_y = 0;
 		float max_vrefresh = 0.0;
+		int flags = (output->interlaceAllowed ? V_INTERLACE : 0) |
+			(output->doubleScanAllowed ? V_DBLSCAN : 0);
 
 		for (m = modes; m; m = m->next) {
 			if (m->type & M_T_PREFERRED)
@@ -938,6 +940,7 @@ intel_output_panel_edid(xf86OutputPtr output, DisplayModePtr modes)
 #endif
 
 		xf86ValidateModesSize(output->scrn, m, max_x, max_y, 0);
+		xf86ValidateModesFlags(output->scrn, m, flags);
 
 		for (i = m; i; i = i->next) {
 			if (xf86ModeVRefresh(i) > max_vrefresh)
-- 
2.16.1

-- 
Ville Syrjälä
Intel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ