http://bugzilla.opensuse.org/show_bug.cgi?id=954783 http://bugzilla.opensuse.org/show_bug.cgi?id=954783#c9 --- Comment #9 from Jozef Kovac --- I tried yesterday glmatrix even multiple(parallel) 4-6 for for couple of minutes but nothing happen(windowed and fullscreen) using ALT+TAB, workspace switching , also test Unigine Heaven, unigine valley also ok more than hour. I tried now glmatrix 5 parallel and system freezy after 2-3 minutes. Torchlight II game system freezy after 15-20 min of gameplay. DRI_PRIME=1 steam work fine, also in Big picture mode but i tested only once. i have compositor set to xrandrd, because openGL settings show only black screen. Also on Arch wiki Black screen with GL-based compositors https://wiki.archlinux.org/index.php/PRIME -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954783 http://bugzilla.opensuse.org/show_bug.cgi?id=954783#c11 --- Comment #11 from Jozef Kovac --- I also us TLP/TLP-rdw can by relevant for this bug? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954783 http://bugzilla.opensuse.org/show_bug.cgi?id=954783#c13 --- Comment #13 from Jozef Kovac --- TLP is from openSUSE-Leap-42.1-Oss repository, VLC+VLC-codecs and necessary dependencies is the only thing from another repository. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954783 http://bugzilla.opensuse.org/show_bug.cgi?id=954783#c15 --- Comment #15 from Jozef Kovac --- without TLP crash freezy 7 min. glmatrix 10x. but i have feeling crash is more often in screen resolution 1920x1200 than 1024x768. Maybe it's just a coincidence. can be helpful ? http://lists.x.org/archives/xorg-announce/2015-November/002657.html -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954783 http://bugzilla.opensuse.org/show_bug.cgi?id=954783#c17 --- Comment #17 from Jozef Kovac --- I set up kdump https://doc.opensuse.org/documentation/html/openSUSE_114/opensuse-tuning/cha... via YAST defaul settings but /var/crash folder after crash is empty. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954783 http://bugzilla.opensuse.org/show_bug.cgi?id=954783#c19 --- Comment #19 from Takashi Iwai --- You can trigger the crash dump via echo c > /proc/sysrq-trigger If this doesn't give the proper dump, try to increase the memory size for the crash kernel. YaST tends to set up in a tight size. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954783 http://bugzilla.opensuse.org/show_bug.cgi?id=954783#c21 --- Comment #21 from Takashi Iwai --- (In reply to Jozef Kovac from comment #20)

echo c > /proc/sysrq-trigger immediately reset computer but folder is still empty.

Didn't it switch to kdump kernel? Check "systemctl status kdump" -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954783 http://bugzilla.opensuse.org/show_bug.cgi?id=954783#c23 --- Comment #23 from Jozef Kovac --- systemctl status kdump kdump.service - Load kdump kernel on startup Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled) Active: active (exited) since Fri 2015-11-13 17:33:56 CET; 7min ago Process: 1020 ExecStart=/lib/kdump/load.sh (code=exited, status=0/SUCCESS) Main PID: 1020 (code=exited, status=0/SUCCESS) CGroup: /system.slice/kdump.service -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954783 http://bugzilla.opensuse.org/show_bug.cgi?id=954783#c25 --- Comment #25 from Jozef Kovac --- 144/98 reboot, GLmatrix system freezy but /var/crash still empty -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954783 http://bugzilla.opensuse.org/show_bug.cgi?id=954783#c27 --- Comment #27 from Jozef Kovac --- But when i use external monitor via DP ( DELL U2410) DRI_PRIME=1 glmatrix every time crash after couple minutes. (3-10 minutes, glmatrix parallel 10x) On internal LCD sometimes work fine for long time, sometimes also crash after few minutes. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954783 http://bugzilla.opensuse.org/show_bug.cgi?id=954783#c29 --- Comment #29 from Takashi Iwai --- (In reply to Jozef Kovac from comment #28)

with sysrq-trigger works fine.

OK, so it implies that the crash isn't a normal kernel logic error, but it's directly crashing to the system stall or reset. Too bad. Then the only way to watch is via serial console. Or with some luck, we might be able to catch the log via netconsole. Basically without a crash log, we can't assume even that it's the similar as the bug you pointed (https://bugs.freedesktop.org/show_bug.cgi?id=92258). So, for now, the most important thing is to get any kernel log showing the crash. Then another thing to check would be to test the newer kernel (e.g. FACTORY 4.3 kernel) and/or test the newer X packages (available in OBS X11:XOrg repo). -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954783 http://bugzilla.opensuse.org/show_bug.cgi?id=954783#c31 --- Comment #31 from Jozef Kovac --- I testet with kernel 4.3+firmware from http://download.opensuse.org/repositories/Kernel:/stable/standard/ more then 4 hours work perfectly stable, game/glmatrix, switching external/internal LCD nothing happen, multiple reboots stil without crash. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954783 http://bugzilla.opensuse.org/show_bug.cgi?id=954783#c33 --- Comment #33 from Jozef Kovac --- kernel-default-4.2.5-1.1.g0491388.x86_64 works without any problem. I also tried 4.1.12(default leap kernel) with firmware from Kernel:/stable/standard/ but crash after few minutes. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954783 http://bugzilla.opensuse.org/show_bug.cgi?id=954783#c35 --- Comment #35 from Jozef Kovac --- 3.16.7-29 from openSUSE 13.2 works completely stable after couple days of testing( almost week) Tested dedicated GPU(AMD) as primary/only GPU ( DP on docking station are conected directly to AMD GPU) also without any problem except slightly better performance and fan always running. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954783 http://bugzilla.opensuse.org/show_bug.cgi?id=954783#c37 --- Comment #37 from Takashi Iwai --- Hmm, there hasn't been so much intensive changes in radeon part that may lead to a crash. It'd be helpful if you can capture the panic screen or such if possible. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954783 http://bugzilla.opensuse.org/show_bug.cgi?id=954783#c39 --- Comment #39 from Takashi Iwai --- (In reply to Jozef Kovac from comment #38)

I found nothing relevant in log, actualy nothing at all in that time and never happen again, tested for couple days, probably another bug, not related to radeon or need special circumstances.

But i set up netconsole(with my old mini 2133 Debian) and try capture old DRI_PRIME=1 bug.

4.1.12-1 immediately after i use DRI_PRIME=1 show:

[ 187.561982] [drm:radeon_pm_late_init [radeon]] *ERROR* failed to create device file for dpm state [ 187.562556] [drm:radeon_pm_late_init [radeon]] *ERROR* failed to create device file for dpm state [ 187.563102] [drm:radeon_pm_late_init [radeon]] *ERROR* failed to create device file for power profile [ 187.563643] [drm:radeon_pm_late_init [radeon]] *ERROR* failed to create device file for power method

These are the bugs that have been fixed in 4.1.13.

[ 187.678751] snd_hda_intel 0000:03:00.1: CORB reset timeout#2, CORBRP = 65535

This is usually non-fatal issue. It's checked since recent kernels.

and nothing more until crash.

4.1.13-5 show every time when DRI_PRIME=1 is in use.

[ 378.149829] snd_hda_intel 0000:03:00.1: CORB reset timeout#2, CORBRP = 65535

This is same as above, thus no cause. So, we didn't catch the cause yet...

3.16.7-29

nothing show via netconsole when i use DRI_PRIME=1 and work absolutly stable.

The old kernel had no check in HD-audio driver.

With 4.1.12 crash everytime after couple minutes (max 7min), but 4.1.13-5 crash 32min/2min/11min when DRI_PRIME=1 when used.(tested three times)

Does it with a high CPU load, or it happens in idle state, too? I wonder whether it's a software failure, or it's triggered by hardware (by some change in kernel, etc). Also, if it's about graphics, you may boot with drm.debug=0x0e option. Then it'll show more verbose logs regarding graphics. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954783 http://bugzilla.opensuse.org/show_bug.cgi?id=954783#c41 --- Comment #41 from Jozef Kovac --- Nothing else show with drm.debug=0x0e vie netconsole only snd_hda_intel... In systemd journal is many more drm entries but i not know how copy here. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954783 http://bugzilla.opensuse.org/show_bug.cgi?id=954783#c43 --- Comment #43 from Jozef Kovac --- 4.1.13-5/DRI_PRIME=1/netconsole [ 147.171197] [drm:i915_gem_open] [ 156.538080] [drm] probing gen 2 caps for device 8086:9c18 = 5323c42/0 [ 156.538093] [drm] PCIE gen 2 link speeds already enabled [ 156.542218] [drm] PCIE GART of 1024M enabled (table at 0x0000000000277000). [ 156.542345] radeon 0000:03:00.0: WB enabled [ 156.542349] radeon 0000:03:00.0: fence driver on ring 0 use gpu addr 0x0000000040000c00 and cpu addr 0xffff880036d62c00 [ 156.542351] radeon 0000:03:00.0: fence driver on ring 1 use gpu addr 0x0000000040000c04 and cpu addr 0xffff880036d62c04 [ 156.542354] radeon 0000:03:00.0: fence driver on ring 2 use gpu addr 0x0000000040000c08 and cpu addr 0xffff880036d62c08 [ 156.542356] radeon 0000:03:00.0: fence driver on ring 3 use gpu addr 0x0000000040000c0c and cpu addr 0xffff880036d62c0c [ 156.542358] radeon 0000:03:00.0: fence driver on ring 4 use gpu addr 0x0000000040000c10 and cpu addr 0xffff880036d62c10 [ 156.543910] radeon 0000:03:00.0: fence driver on ring 5 use gpu addr 0x0000000000075a18 and cpu addr 0xffffc90001435a18 [ 156.544585] [drm:radeon_crtc_handle_flip] radeon_crtc->flip_status = 0 != RADEON_FLIP_SUBMITTED(2) [ 156.544592] [drm:radeon_crtc_handle_flip] radeon_crtc->flip_status = 0 != RADEON_FLIP_SUBMITTED(2) [ 156.781101] [drm] ring test on 0 succeeded in 1 usecs [ 156.781114] [drm] ring test on 1 succeeded in 1 usecs [ 156.781121] [drm] ring test on 2 succeeded in 1 usecs [ 156.781131] [drm] ring test on 3 succeeded in 5 usecs [ 156.781140] [drm] ring test on 4 succeeded in 4 usecs [ 156.956763] [drm] ring test on 5 succeeded in 2 usecs [ 156.956772] [drm] UVD initialized successfully. [ 156.956811] [drm] ib test on ring 0 succeeded in 0 usecs [ 156.956858] [drm] ib test on ring 1 succeeded in 0 usecs [ 156.956901] [drm] ib test on ring 2 succeeded in 0 usecs [ 156.956932] [drm] ib test on ring 3 succeeded in 0 usecs [ 156.956966] [drm] ib test on ring 4 succeeded in 0 usecs [ 157.605812] [drm] ib test on ring 5 succeeded [ 157.614315] snd_hda_intel 0000:03:00.1: Enabling via VGA-switcheroo [ 157.719256] snd_hda_intel 0000:03:00.1: CORB reset timeout#2, CORBRP = 65535 [ 157.765449] [drm:radeon_info_ioctl] macrotile mode array is cik+ only! [ 163.932378] [drm:radeon_info_ioctl] macrotile mode array is cik+ only! [ 167.286021] [drm:radeon_info_ioctl] macrotile mode array is cik+ only! [ 171.125632] [drm:radeon_info_ioctl] macrotile mode array is cik+ only! [ 174.384673] [drm:radeon_info_ioctl] macrotile mode array is cik+ only! [ 177.111597] [drm:radeon_info_ioctl] macrotile mode array is cik+ only! [ 180.648221] [drm:radeon_info_ioctl] macrotile mode array is cik+ only! [ 183.863776] [drm:radeon_info_ioctl] macrotile mode array is cik+ only! [ 187.519144] [drm:radeon_info_ioctl] macrotile mode array is cik+ only! [ 191.038127] [drm:radeon_info_ioctl] macrotile mode array is cik+ only! --- and crash... and this with 3.16.7 for comparison [ 75.808416] [drm:intel_crtc_cursor_set] cursor off [ 76.279634] [drm] probing gen 2 caps for device 8086:9c18 = 5323c42/0 [ 76.279644] [drm] PCIE gen 2 link speeds already enabled [ 76.283764] [drm] PCIE GART of 1024M enabled (table at 0x0000000000276000). [ 76.283904] radeon 0000:03:00.0: WB enabled [ 76.283908] radeon 0000:03:00.0: fence driver on ring 0 use gpu addr 0x0000000040000c00 and cpu addr 0xffff880238c1dc00 [ 76.283910] radeon 0000:03:00.0: fence driver on ring 1 use gpu addr 0x0000000040000c04 and cpu addr 0xffff880238c1dc04 [ 76.283912] radeon 0000:03:00.0: fence driver on ring 2 use gpu addr 0x0000000040000c08 and cpu addr 0xffff880238c1dc08 [ 76.283915] radeon 0000:03:00.0: fence driver on ring 3 use gpu addr 0x0000000040000c0c and cpu addr 0xffff880238c1dc0c [ 76.283917] radeon 0000:03:00.0: fence driver on ring 4 use gpu addr 0x0000000040000c10 and cpu addr 0xffff880238c1dc10 [ 76.285473] radeon 0000:03:00.0: fence driver on ring 5 use gpu addr 0x0000000000075a18 and cpu addr 0xffffc90011135a18 [ 76.286084] [drm:radeon_crtc_handle_flip] radeon_crtc->flip_status = 0 != RADEON_FLIP_SUBMITTED(2) [ 76.286089] [drm:radeon_crtc_handle_flip] radeon_crtc->flip_status = 0 != RADEON_FLIP_SUBMITTED(2) [ 76.481930] [drm] ring test on 0 succeeded in 1 usecs [ 76.481942] [drm] ring test on 1 succeeded in 1 usecs [ 76.481948] [drm] ring test on 2 succeeded in 1 usecs [ 76.481956] [drm] ring test on 3 succeeded in 4 usecs [ 76.481964] [drm] ring test on 4 succeeded in 4 usecs [ 76.667487] [drm] ring test on 5 succeeded in 2 usecs [ 76.667497] [drm] UVD initialized successfully. [ 76.667531] [drm] ib test on ring 0 succeeded in 0 usecs [ 76.667561] [drm] ib test on ring 1 succeeded in 0 usecs [ 76.667589] [drm] ib test on ring 2 succeeded in 0 usecs [ 76.667617] [drm] ib test on ring 3 succeeded in 0 usecs [ 76.667644] [drm] ib test on ring 4 succeeded in 0 usecs [ 76.818256] [drm] ib test on ring 5 succeeded [ 76.827403] snd_hda_intel 0000:03:00.1: Enabling via VGA-switcheroo [ 76.827546] snd_hda_intel 0000:03:00.1: irq 69 for MSI/MSI-X [ 76.861702] [drm:radeon_info_ioctl] Invalid request 37 [ 76.861713] [drm:radeon_info_ioctl] macrotile mode array is cik+ only! [ 79.192677] [drm:radeon_info_ioctl] Invalid request 37 [ 79.192690] [drm:radeon_info_ioctl] macrotile mode array is cik+ only! [ 83.737880] [drm:radeon_info_ioctl] Invalid request 37 [ 83.737892] [drm:radeon_info_ioctl] macrotile mode array is cik+ only! [ 89.062058] [drm:radeon_info_ioctl] Invalid request 37 [ 89.062070] [drm:radeon_info_ioctl] macrotile mode array is cik+ only! [ 93.254184] [drm:radeon_info_ioctl] Invalid request 37 [ 93.254197] [drm:radeon_info_ioctl] macrotile mode array is cik+ only! [ 96.922265] [drm:radeon_info_ioctl] Invalid request 37 [ 96.922280] [drm:radeon_info_ioctl] macrotile mode array is cik+ only! [ 101.272998] [drm:radeon_info_ioctl] Invalid request 37 [ 101.273015] [drm:radeon_info_ioctl] macrotile mode array is cik+ only! [ 104.574944] [drm:radeon_info_ioctl] Invalid request 37 [ 104.574969] [drm:radeon_info_ioctl] macrotile mode array is cik+ only! [ 108.408574] [drm:radeon_info_ioctl] Invalid request 37 [ 108.408597] [drm:radeon_info_ioctl] macrotile mode array is cik+ only! [ 111.561355] [drm:radeon_info_ioctl] Invalid request 37 [ 111.561369] [drm:radeon_info_ioctl] macrotile mode array is cik+ only! [ 117.931164] [drm:intel_crtc_cursor_set] cursor off [ 123.179592] [drm:intel_crtc_cursor_set] cursor off [ 130.923942] [drm:intel_crtc_cursor_set] cursor off -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954783 http://bugzilla.opensuse.org/show_bug.cgi?id=954783#c45 --- Comment #45 from Takashi Iwai --- (In reply to Jozef Kovac from comment #44)

I installed Arch for testing multiple old LTS kernels ( 3.14,3.18...) but DRI_PRIME=1 works stable even with 4.1.13, after day of testing nothing happen(gameplay, glmatrix... only slightly worse performance than openSUSE_Leap but still much better than IGP

Could you try kernel-vanilla from 4.1.13? It might be that some our backports broke something. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954783 http://bugzilla.opensuse.org/show_bug.cgi?id=954783#c47 --- Comment #47 from Takashi Iwai --- (In reply to Jozef Kovac from comment #46)

Arch Linux DRI_PRIME=1 kernel-4.1.15(drm.debug=0x0e,dmesg -n 8) looks like this for comparsion

Does Arch kernel work, or does it show the same crash, too? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954783 http://bugzilla.opensuse.org/show_bug.cgi?id=954783#c49 --- Comment #49 from Takashi Iwai --- Interesting. The latest 4.1.x kernel for openSUSE Leap is found in OBS Kernel:openSUSE-42.1 repo. Currently it's 4.1.15, too. http://download.opensuse.org/repositories/Kernel:/openSUSE-42.1/standard/ Please give it a try. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954783 http://bugzilla.opensuse.org/show_bug.cgi?id=954783#c51 --- Comment #51 from Takashi Iwai --- (In reply to Jozef Kovac from comment #50)

I tested Arch first with 4.1.13 works stable also 4.2.7 and currently running on 4.3.3 all stable. I have Leap on another drive, i try but Leap has issue with 4.2 and 4.3 too.

Then it makes me wonder whether it's rather a user-space side difference (e.g. X driver or configuration) -- especially if the same issue happened with 4.1.3 kernel-vanilla. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954783 http://bugzilla.opensuse.org/show_bug.cgi?id=954783#c53 --- Comment #53 from Jozef Kovac --- Framrate on Arch lokks like a stem-runtime issue not OS. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954783 http://bugzilla.opensuse.org/show_bug.cgi?id=954783#c55 --- Comment #55 from Jozef Kovac --- both /lib64/modules and /lib/modules/ ? (on Arch both have same size 147MB) Where is System.map located? [polo@polo /]$ dir bin etc lib64 opt root-image-pkgs.txt srv usr boot home lost+found proc run sys var dev lib mnt root sbin tmp xfce-image-pkgs.txt [polo@polo boot]$ dir grub intel-ucode.img syslinux initramfs-4.1-x86_64-fallback.img linux41-x86_64.kver vmlinuz-4.1-x86_64 initramfs-4.1-x86_64.img linux43-x86_64.kver vmlinuz-4.3-x86_64 initramfs-4.3-x86_64-fallback.img lost+found initramfs-4.3-x86_64.img memtest86+ -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954783 http://bugzilla.opensuse.org/show_bug.cgi?id=954783#c57 --- Comment #57 from Takashi Iwai --- (In reply to Jozef Kovac from comment #55)

both /lib64/modules and /lib/modules/ ? (on Arch both have same size 147MB)

On SUSE, it's /lib/modules/*

Where is System.map located?

Usually /boot. With the same suffix as vmlinuz and initrd. (In reply to Jozef Kovac from comment #56)

Same folder /boot/ on openSUSE much more files (new instalation on external HDD, only OS and all updates)

You don't need but vmlinuz and initrd only for booting. Other files are relevant for development or other purposes.

System.map is present but not on Arch, means what?

It might work without it, maybe dracut doesn't require it unlike the old mkinitrd script. Just give it a try. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954783 http://bugzilla.opensuse.org/show_bug.cgi?id=954783#c59 --- Comment #59 from Takashi Iwai --- initramfs should be named as initrd for SUSE. Maybe instead of regenerated initrd, you could rename initrd-4.1-x86.img as initrd-4.1-x86_64. And, instead of manual grub2-mkconfig, you can try update-bootloader script, e.g.: update-bootloader --add --image /boot/vmlinuz-xxx --initrd /boot/initrd-xxx update-bootloader --refresh The module files themselves have no relation of the path, so it shouldn't matter whether /lib/modules or /lib64/modules. It's at most the modprobe which matters. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954783 http://bugzilla.opensuse.org/show_bug.cgi?id=954783#c61 --- Comment #61 from Takashi Iwai --- (In reply to Jozef Kovac from comment #60)

But on Arch is only initramfs present, still reneame initramfs to initrd?

[polo@polo boot]$ dir grub intel-ucode.img syslinux initramfs-4.1-x86_64-fallback.img linux41-x86_64.kver vmlinuz-4.1-x86_64 initramfs-4.1-x86_64.img linux43-x86_64.kver vmlinuz-4.3-x86_64 initramfs-4.3-x86_64-fallback.img lost+found initramfs-4.3-x86_64.img memtest86+

The filename doesn't matter for the kernel itself. But it matters for GRUB who passes the init ramdisk to kernel. And openSUSE's grub configuration assumes the initrd being /boot/initrd-xxx. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954783 http://bugzilla.opensuse.org/show_bug.cgi?id=954783#c63 --- Comment #63 from Takashi Iwai --- OK, then it's like some boot option is missing for Arch kernel, e.g. root disk or such has to be passed in a different way. You can edit /boot/grub2/grub.conf directly, too, and correct the boot options. Try to strip down as much as possible, and use a simpler path like /dev/sda1 for root partition instead of UUID. Basically just passing root=xxx should suffice for booting up. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954783 http://bugzilla.opensuse.org/show_bug.cgi?id=954783#c65 --- Comment #65 from Takashi Iwai --- Yes, it's grub.cfg. This should be accessibly only for root. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954783 http://bugzilla.opensuse.org/show_bug.cgi?id=954783#c67 Vladislav Kamenev changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mazahakaforever@ya.ru --- Comment #67 from Vladislav Kamenev --- Sorry for disturbance but this also affects all versions of ubuntu in all kernels from 3.19 to 4.6-rc1 Intel HD3000 + AMD Radeon HD6650m -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954783 Vladislav Kamenev changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugzilla.kernel.org | |/show_bug.cgi?id=72701 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954783 http://bugzilla.opensuse.org/show_bug.cgi?id=954783#c70 --- Comment #70 from Jozef Kovac --- 3.18.30 on Leap works without problem. 3.19.0 and 3.19.8 crash ( after few minutes with DRI_PRIME=1 same test on IGP stable) -- You are receiving this mail because: You are on the CC list for the bug.