linux-4.7-1 breaks X on i915-based Samsung laptop

akobel · 2016-08-12 21:13:04

Hi all,

todays upgrade to linux-4.7-1 left me with a non-working X. As far as I can see, the boot process is entirely normal until X shall start; but then the following error pops up and the machine becomes irresponsive:

[    7.736821] [drm:ironlake_crtc_compute_clock [i915]] *ERROR* Couldn't find PLL settings for mode!

If I remove X from the startup sequence, I can boot to console normally, but on a startx the same happens. I can switch to another terminal, though, and investigate. However, nothing fruitful in the logs - dmesg shows perfectly fine output except for

[    7.330929] thermal LNXTHERM:00: registered as thermal_zone0
[    7.330931] ACPI: Thermal Zone [TZ00] (51 C)
[    7.331321] thermal LNXTHERM:01: registered as thermal_zone1
[    7.331322] ACPI: Thermal Zone [TZ01] (30 C)
[    7.334590] ACPI Warning: SystemIO range 0x0000000000000428-0x000000000000042F conflicts with OpRegion 0x0000000000000400-0x000000000000047F (\PMIO) (20160422/utaddress-255)
[    7.334592] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[    7.334598] ACPI Warning: SystemIO range 0x0000000000000540-0x000000000000054F conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (\GPIO) (20160422/utaddress-255)
[    7.334599] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[    7.334603] ACPI Warning: SystemIO range 0x0000000000000530-0x000000000000053F conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (\GPIO) (20160422/utaddress-255)
[    7.334603] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[    7.334607] ACPI Warning: SystemIO range 0x0000000000000500-0x000000000000052F conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (\GPIO) (20160422/utaddress-255)
[    7.334607] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver

which seems unrelated. Googling for ironlake_crtc_compute_clock revealed few hits that are above my level of competence. After reverting the kernel update, everything is back to normal.

The machine in question is a Samsung NP900X4C, with the very common Intel HD Graphics 4000, which served me perfectly reliably since years. A (software-wise) similar setup on a different machine (Surface Pro3) works like a charm, at least as far the graphical interface is concerned.

Any pointers?

Edit: The timestamps claim that the error is thrown even before startx is called; it's just that the terminal stays available if I remove the automatic loading of the login manager (LightDM, starting X) from the boot sequence. But still, startx throws the same error again, and breaks the terminal.
Full dmesg output: http://pastebin.com/t5E9iMZf (btrfs journal complaints are due to the fact that I had to shut down the system hard on the last boot, due to this very issue)

Thanks in advance,
Alexander

Last edited by akobel (2016-08-12 21:30:40)

jasonwryan · 2016-08-12 21:33:51

I have the same laptop. I uninstalled the intel driver some kernels ago and just use the native modesetting; works great.

akobel · 2016-08-12 22:53:34

Thanks for the suggestion. How do I go about that? My first guess is that you mean pacman -R xf86-video-intel; pacman -Syu # for linux-4.7-1; but after that and a reboot, I still see the same error message concerning i915. (Also, lsmod still shows i915 loaded; but I think that's how it should be, and you only proposed to get rid of the X driver, right?)

Furthermore, startx still doesn't work, and besides the repeated message about [drm:ironlake_crtc_compute_clock [i915]] I get Xorg.log entries

[    51.655] (II) LoadModule: "glx"
[    51.656] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[    51.668] (II) Module glx: vendor="X.Org Foundation"
[    51.668] 	compiled for 1.18.4, module version = 1.0.0
[    51.668] 	ABI class: X.Org Server Extension, version 9.0
[    51.669] (==) AIGLX enabled
[    51.669] (==) Matched intel as autoconfigured driver 0
[    51.669] (==) Matched intel as autoconfigured driver 1
[    51.669] (==) Matched modesetting as autoconfigured driver 2
[    51.669] (==) Matched fbdev as autoconfigured driver 3
[    51.669] (==) Matched vesa as autoconfigured driver 4
[    51.669] (==) Assigned the driver to the xf86ConfigLayout
[    51.669] (II) LoadModule: "intel"
[    51.670] (WW) Warning, couldn't open module intel
[    51.670] (II) UnloadModule: "intel"
[    51.670] (II) Unloading intel
[    51.670] (EE) Failed to load module "intel" (module does not exist, 0)
[    51.670] (II) LoadModule: "modesetting"
[    51.670] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[    51.671] (II) Module modesetting: vendor="X.Org Foundation"
[    51.671] 	compiled for 1.18.4, module version = 1.18.4
[    51.671] 	Module class: X.Org Video Driver
[    51.671] 	ABI class: X.Org Video Driver, version 20.0
[    51.671] (II) LoadModule: "fbdev"
[    51.671] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[    51.672] (II) Module fbdev: vendor="X.Org Foundation"
[    51.672] 	compiled for 1.18.0, module version = 0.4.4
[    51.672] 	Module class: X.Org Video Driver
[    51.672] 	ABI class: X.Org Video Driver, version 20.0
[    51.672] (II) LoadModule: "vesa"
[    51.672] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
[    51.672] (II) Module vesa: vendor="X.Org Foundation"
[    51.672] 	compiled for 1.18.0, module version = 2.3.4
[    51.672] 	Module class: X.Org Video Driver
[    51.672] 	ABI class: X.Org Video Driver, version 20.0
[    51.672] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[    51.672] (II) FBDEV: driver for framebuffer: fbdev
[    51.672] (II) VESA: driver for VESA chipsets: vesa
[    51.672] (WW) xf86OpenConsole: VT_ACTIVATE failed: Operation not permitted
[    51.672] (EE) 
Fatal server error:
[    51.672] (EE) xf86OpenConsole: Switching VT failed

This doesn't look like I can go without the intel module? Or am I getting something completely wrong here? FWIW, here is the list of X-related packages I have, if this helps something:

akobel@s9 ~ % pacman -Q | grep xf86
lib32-libxxf86vm 1.1.4-1
libxxf86dga 1.1.4-1
libxxf86vm 1.1.4-1
xf86-input-libinput 0.19.0-1
xf86-input-synaptics 1.8.99.1-1
xf86-video-dummy 0.3.7-5
xf86-video-fbdev 0.4.4-5
xf86-video-intel 1:2.99.917+691+ga77397a-1
xf86-video-vesa 2.3.4-2
xf86dgaproto 2.1-3
xf86vidmodeproto 2.3.1-3

akobel@s9 ~ % pacman -Q | grep xorg 
xorg-appres 1.0.4-1
xorg-bdftopcf 1.0.5-1
xorg-font-util 1.3.1-1
xorg-font-utils 7.6-4
xorg-fonts-alias 1.0.3-1
xorg-fonts-encodings 1.0.4-4
xorg-fonts-misc 1.0.3-4
xorg-luit 1.1.1-2
xorg-mkfontdir 1.0.7-2
xorg-mkfontscale 1.1.2-1
xorg-server 1.18.4-1
xorg-server-common 1.18.4-1
xorg-server-xephyr 1.18.4-1
xorg-server-xwayland 1.18.4-1
xorg-setxkbmap 1.3.1-1
xorg-utils 7.6-9
xorg-xauth 1.0.9-1
xorg-xbacklight 1.2.1-1
xorg-xclipboard 1.1.3-1
xorg-xdpyinfo 1.3.2-1
xorg-xdriinfo 1.0.5-1
xorg-xev 1.2.2-1
xorg-xhost 1.0.7-1
xorg-xinit 1.3.4-4
xorg-xinput 1.6.2-1
xorg-xkbcomp 1.3.1-1
xorg-xlsatoms 1.1.2-1
xorg-xlsclients 1.1.3-1
xorg-xlsfonts 1.0.5-1
xorg-xmodmap 1.0.9-1
xorg-xprop 1.2.2-1
xorg-xrandr 1.5.0-1
xorg-xrdb 1.1.0-2
xorg-xset 1.2.3-1
xorg-xvinfo 1.1.3-1
xorg-xwininfo 1.1.3-1

Cheers,
Alexander

akobel · 2016-08-12 23:03:00

Sorry, I just found the remark about that at the very top of the Intel graphics wiki page. The second edit of the second link seems to apply for me.
I'll have to try this tomorrow and will report again. Do xf86-video-{dummy,fbdev,vesa} do any harm? I have no idea anymore why they ended up on my machine...

Cheers,
Alexander

atomicbeef · 2016-08-13 01:57:11

This article on the wiki explains how Xorg searches for graphics drivers to use. Since you have xf86-video-fbdev and xf86-video-vesa installed, you'll have to specify something like

Section "Device"
    Identifier "Intel"
    Driver "modesetting"
EndSection

in an Xorg configuration file in order to use the modesetting driver.

Head_on_a_Stick · 2016-08-13 10:06:14

This works for me to force the modesetting driver:

Section "Device"
	Identifier "Device0"
	Driver "modesetting"
EndSection

FWIW, my HD4600 is fine with the Intel DDX driver and the Zen-patched 4.7 kernel.

akobel · 2016-08-13 12:20:35

Thanks for your feedback. I got the modesetting driver running now, and everything seems to be fine on kernel 4.6. But the initial problem still persists: With linux-4.7, I get

[drm:ironlake_crtc_compute_clock [i915]] *ERROR* Couldn't find PLL settings for mode!
(EE) Xorg: xf86Helper.c:1942: xf86ScrnToScreen: Assertion `pScrn->scrnIndex < screenInfo.numScreens' failed.

and no graphical interface. Here's the new Xorg.0.log.

Edit: W.r.t. permissions: starting X as a normal user gives the above log; trying to start as root locks up the machine entirely, and I have to raise elephants.
My Xorg.conf{,.d} is empty except for setting few touchpad parameters. No section that is concerned with graphics. I also tried to include i915 in the mkinitcpio.conf MODULES section, but to no avail.

@jasonwryan: Do you use linux-4.7-1 already on your NP900X4C? Any specific settings on boot, or just the defaults?

BTW: Phoronix reports about changes regarding PLL computation in kernel 4.7; but I have no idea what PLL even is, so I can't get any useful information from that news entry or the linked development logs...

Thanks,
Alexander

Last edited by akobel (2016-08-13 12:48:40)

Head_on_a_Stick · 2016-08-13 17:13:32

Xorg.0.log wrote:

[    20.008] (EE) AddScreen/ScreenInit failed for driver 0

Try using this kernel parameter:

iomem=relaxed

https://bbs.archlinux.org/viewtopic.php?id=211331

jasonwryan · 2016-08-13 19:07:32

Yes, both vanilla and my own kernel work fine with only one parameter: i8042.nopnp=1

akobel · 2016-08-13 19:21:15

iomem=relaxed helped in the sense that this specific message doesn't occur anymore, but does not change anything in the overall problem...

oceans11 · 2016-08-13 19:58:14

Have the same laptop as OP and since kernel 4.7 my screen goes blank as soon as kms.
I 've tried uninstalling xf86-video-intel (I just learn about the split driver thing) but same behaviour.
If a downgrade the kernel the video works (with and without the intel driver)
I'm not using any kernel parameter video related.

Any hints?

akobel · 2016-08-13 22:24:28

Thanks @jasonwryan for the reply I didn't want to hear (it's always nice to not be alone with the trouble ;-)), and thanks @oceans11 for sharing my misery... Another victim reports on reddit, where I don't have an account to spend solace.
I guess I simply have to wait for a while until I give 4.7 a shot again. Too clueless to have anything constructive...

W.r.t. uninstalling xf86-video-intel, I just found out that videos in chromium go haywire without it (random blackouts for the video), so I'm back to 4.6.4 and the intel driver. If there are any new ideas, I'm following this issue and will be happy to report my findings.

Thanks everybody!

R00KIE · 2016-08-14 13:12:31

I don't have much to add except check if there is a bios/uefi update for your laptop as it can contain also updates for the gpu and it might helps things work more smoothly.

mcloaked · 2016-08-14 21:09:38

Any chance that this is related to my problem reported at https://bbs.archlinux.org/viewtopic.php?id=215809 ?

WFV · 2016-08-15 05:45:58

@ akobel

Do xf86-video-{dummy,fbdev,vesa} do any harm? I have no idea anymore why they ended up on my machine...

these do no harm and are helpful when your exclusive video driver doesn't load, they run before handing off to the intel driver - at some point in journalctl log perhaps you see vesa switching to intel? Without them you might have no video at all during boot after bios hands off. fbdev is about frame buffering. My initial Arch install I think loaded all the xf86-video-packages, I removed all except those and the ati one used for the radeon driver. From journalctl -b

% journalctl -b | grep frame                                                                                                                                  :(
Aug 13 22:46:21 arch-bill kernel: vesafb: framebuffer at 0xd0000000, mapped to 0xffffc90003800000, using 8128k, total 8128k
Aug 13 22:46:21 arch-bill kernel: Console: switching to colour frame buffer device 240x67
Aug 13 22:46:21 arch-bill kernel: fb0: VESA VGA frame buffer device
Aug 13 22:46:21 arch-bill kernel: Console: switching to colour frame buffer device 240x67
Aug 13 22:46:21 arch-bill kernel: radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device
% journalctl -b | grep dummy
Aug 13 22:46:21 arch-bill kernel: Console: colour dummy device 80x25
Aug 13 22:46:21 arch-bill kernel: Console: switching to colour dummy device 80x25
Aug 13 22:46:21 arch-bill kernel: ehci-pci 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
Aug 13 22:46:21 arch-bill kernel: ehci-pci 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
Aug 13 22:46:21 arch-bill kernel: ehci-pci 0000:00:16.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
journalctl -b | grep radeon
Aug 13 22:46:21 arch-bill kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-linux-ck root=UUID=abcde0123 rw quiet radeon.dpm=1 elevator=bfq
Aug 13 22:46:21 arch-bill kernel: Kernel command line: BOOT_IMAGE=/boot/vmlinuz-linux-ck root=UUID=abcde0123 rw quiet radeon.dpm=1 elevator=bfq
Aug 13 22:46:21 arch-bill kernel: [drm] radeon kernel modesetting enabled.
Aug 13 22:46:21 arch-bill kernel: fb: switching to radeondrmfb from VESA VGA
etc, etc,,,

these are not in the actual order of operation except the last switch to radeondrmfb, and I'm not sure if the 'dummy' refs are related to xf86-video-dummy.

akobel · 2016-08-15 07:07:38

Thanks everybody for your comments.

@R00KIE: Good catch, in particular since jasonwryan's very similar machine doesn't show the problem. Unfortunately, no BIOS update available AFAICS.

@mcloaked: Unlikely (but then I don't exactly know what's the reason here, too). In your case, you get a graphical interface, no freezing of the machine, and "just" some part of the interface doesn't work. AFAIK, SDDM is based on a full X server unlike, e.g., qingy; so the fact that SDDM starts already hints to a different problem.
On the other hand, this PLL clock computation stuff is not in your logs at all, and it received a major rewrite for kernel 4.7; so I suspect that's (a part of) the culprit.

@WFV: Sorry, I forgot to mention that: Trying to uninstall it, pacman reminded me that it's a dependency for xpra (the server componentm, I guess). It's not mentioned in the logs at all, so I think it's not even tried to load. Doesn't seem to interfere with the problem at all.

akobel · 2016-08-15 23:28:09

Sorry for poking this up, but to save other victims the hassle: same issue on linux-zen after its update to 4.7. zen-4.6.5 was fine; note that linux-4.6.4 was the latest stable/core version of the vanilla kernel. So FWIW, I can tell that the issue emerged between 4.6.5 and 4.7.0...

Edit: Here Here's a report in the kernel freedesktop bug tracker.

Last edited by akobel (2016-08-16 12:02:03)

nomorewindows · 2016-08-15 23:47:02

akobel wrote:

Thanks for your feedback. I got the modesetting driver running now, and everything seems to be fine on kernel 4.6. But the initial problem still persists: With linux-4.7, I get
[drm:ironlake_crtc_compute_clock [i915]] *ERROR* Couldn't find PLL settings for mode!
(EE) Xorg: xf86Helper.c:1942: xf86ScrnToScreen: Assertion `pScrn->scrnIndex < screenInfo.numScreens' failed.
and no graphical interface. Here's the new Xorg.0.log.
Edit: W.r.t. permissions: starting X as a normal user gives the above log; trying to start as root locks up the machine entirely, and I have to raise elephants.
My Xorg.conf{,.d} is empty except for setting few touchpad parameters. No section that is concerned with graphics. I also tried to include i915 in the mkinitcpio.conf MODULES section, but to no avail.
@jasonwryan: Do you use linux-4.7-1 already on your NP900X4C? Any specific settings on boot, or just the defaults?
BTW: Phoronix reports about changes regarding PLL computation in kernel 4.7; but I have no idea what PLL even is, so I can't get any useful information from that news entry or the linked development logs...

Thanks,
Alexander

PLL is a radio term, it locks on a frequency.....Most modern cars have a PLL tuner to keep it from receiving trespass from other stations. Older non-PLL radios could bleed over.

R00KIE · 2016-08-16 13:43:48

I believe in this case the PLL(1) is connected with clock generation, and not radio reception. Something in the new math is wrong and when programming the PLL things don't work.

(1) PLL means Phase Locked Loop in case you want to look it up in $search_engine

balazs4 · 2016-08-19 20:22:03

Exactly the same happened to me:

After linux 4.7 upgrade I was not able to start the X and the PPL error message appeared in the terminal.
My setup is also a Samsung Series 9 NP900X4C.

The only workaround is currently downgrading the kernel to 4.6.x.

I hope it will be fixed soon....:/

humhumhum · 2016-08-23 07:29:11

oceans11 wrote:

Have the same laptop as OP and since kernel 4.7 my screen goes blank as soon as kms.
I 've tried uninstalling xf86-video-intel (I just learn about the split driver thing) but same behaviour.
If a downgrade the kernel the video works (with and without the intel driver)
I'm not using any kernel parameter video related.

Same here, my NP900X4C have a the blank screen as soosn as kms start. As I have a autologin but no autostartX, I can blindly write commands (and reboot for example). So it's "just" a problem of display.

NB: If I modify the screen brightness with

(( bmax = $(cat /sys/class/backlight/intel_backlight/max_brightness) ))
echo $bmax | sudo dd of=/sys/class/backlight/intel_backlight/brightness

I can see that my screen is lighter but still blank.
If I select the linux-lts or if I downgrading the kernel to 4.6.x it works fine.

jasonwryan wrote:

I have the same laptop. I uninstalled the intel driver some kernels ago and just use the native modesetting; works great.

my other samsung laptop NP900X3C (more or less the same spec of my NP900X4C but with a i5 and a 13" screen) is working fine with the new kernel.

oceans11 · 2016-08-23 08:17:47

The problem remains with linux 4.7.1-1 and 4.7.2 (in testing). And still no updates from freedesktop.

humhumhum wrote:

my other samsung laptop NP900X3C (more or less the same spec of my NP900X4C but with a i5 and a 13" screen) is working fine with the new kernel.

I cannot understand why jasonwryan's working fine. So is your np900x3c which iirc has the same graphics (intel hd4000).

Blindly running X results in pretty much the same as OP, modeset cannot "sense" higher resolutions (laptop capable of 1600x900@60Hz) and so X cannot init the screen.

Last edited by oceans11 (2016-08-23 08:18:53)

bmbaker · 2016-08-29 15:03:22

I also have this problem with my np900x3d! the Lts kernel works fine but the 4.7 and 4.8 kernels both have the PLL settings error!

loqs · 2016-08-29 17:08:26

akobel wrote:

So FWIW, I can tell that the issue emerged between 4.6.5 and 4.7.0...

The stable series is branches from mainline so last known good should be 4.6 and first bad 4.7 Bisecting between those two should allow you to find the cause.
From the freedesktop bugreport the error seems likely to be caused by a change in drivers/gpu/drm/i915/intel_bios.c looking at commits between 4.6 and 4.7 to that file this seems the most likely cause to me so you could just try reverting that single commit but a bisect although longer would remove guess work.
Edit:
https://bugs.freedesktop.org/show_bug.cgi?id=97363#c11 also https://bugs.freedesktop.org/show_bug.cgi?id=97060#c13

Ville Syrjala 2016-09-06 12:10:06 UTC
Can you try
git://github.com/vsyrjala/linux.git opregion_panel_type_stuff
I'm not expecting it would really fix the problem, but it will at least show us the full response from the BIOS.

Easy way to build that kernel is to use linux-git from AUR and change first source entry to

source=('git+https://github.com/vsyrjala/linux.git#branch=opregion_panel_type_stuff'

Now contains possible fix see https://github.com/vsyrjala/linux/commi … b91e2f5f9f
Edit2:
https://bugs.freedesktop.org/show_bug.cgi?id=97363#c16 also https://bugs.freedesktop.org/show_bug.cgi?id=97060#c16

I had to resort to a quirk to fix this for all machines. Please test this branch:
git://github.com/vsyrjala/linux.git opregion_panel_type_quirk

source=('git+https://github.com/vsyrjala/linux.git#branch=opregion_panel_type_quirk'

Original version of the fix has been replaced by the following https://github.com/vsyrjala/linux/commi … d2532b0c96

Last edited by loqs (2016-09-08 13:51:53)

humhumhum · 2016-09-07 13:31:41

humhumhum wrote:

Same here, my NP900X4C have a the blank screen as soosn as kms start. As I have a autologin but no autostartX, I can blindly write commands (and reboot for example). So it's "just" a problem of display.

add vga=895 into kernel option solve the blank screen in my console. But as soon as I run startx, it crashes with the "couldn't find PLL settings for mode!" error.

Arch Linux

#1 2016-08-12 21:13:04

linux-4.7-1 breaks X on i915-based Samsung laptop

#2 2016-08-12 21:33:51

Re: linux-4.7-1 breaks X on i915-based Samsung laptop

#3 2016-08-12 22:53:34

Re: linux-4.7-1 breaks X on i915-based Samsung laptop

#4 2016-08-12 23:03:00

Re: linux-4.7-1 breaks X on i915-based Samsung laptop

#5 2016-08-13 01:57:11

Re: linux-4.7-1 breaks X on i915-based Samsung laptop

#6 2016-08-13 10:06:14

Re: linux-4.7-1 breaks X on i915-based Samsung laptop

#7 2016-08-13 12:20:35

Re: linux-4.7-1 breaks X on i915-based Samsung laptop

#8 2016-08-13 17:13:32

Re: linux-4.7-1 breaks X on i915-based Samsung laptop

#9 2016-08-13 19:07:32

Re: linux-4.7-1 breaks X on i915-based Samsung laptop

#10 2016-08-13 19:21:15

Re: linux-4.7-1 breaks X on i915-based Samsung laptop

#11 2016-08-13 19:58:14

Re: linux-4.7-1 breaks X on i915-based Samsung laptop

#12 2016-08-13 22:24:28

Re: linux-4.7-1 breaks X on i915-based Samsung laptop

#13 2016-08-14 13:12:31

Re: linux-4.7-1 breaks X on i915-based Samsung laptop

#14 2016-08-14 21:09:38

Re: linux-4.7-1 breaks X on i915-based Samsung laptop

#15 2016-08-15 05:45:58

Re: linux-4.7-1 breaks X on i915-based Samsung laptop

#16 2016-08-15 07:07:38

Re: linux-4.7-1 breaks X on i915-based Samsung laptop

#17 2016-08-15 23:28:09

Re: linux-4.7-1 breaks X on i915-based Samsung laptop

#18 2016-08-15 23:47:02

Re: linux-4.7-1 breaks X on i915-based Samsung laptop

#19 2016-08-16 13:43:48

Re: linux-4.7-1 breaks X on i915-based Samsung laptop

#20 2016-08-19 20:22:03

Re: linux-4.7-1 breaks X on i915-based Samsung laptop

#21 2016-08-23 07:29:11

Re: linux-4.7-1 breaks X on i915-based Samsung laptop

#22 2016-08-23 08:17:47

Re: linux-4.7-1 breaks X on i915-based Samsung laptop

#23 2016-08-29 15:03:22

Re: linux-4.7-1 breaks X on i915-based Samsung laptop

#24 2016-08-29 17:08:26

Re: linux-4.7-1 breaks X on i915-based Samsung laptop

#25 2016-09-07 13:31:41

Re: linux-4.7-1 breaks X on i915-based Samsung laptop

Board footer