[opensuse-factory] Kernel Panic with snapshot 20180104
Hi, I'm getting an always reproducible kernel panic and the system is not bootable with kernel 4.14.11. Booting with 4.14.9 works. Was only able to take a photo.... https://photos.app.goo.gl/CplKIGQy6tnvM2c83 Anyone else experiencing this or any hint on what to look? Stratos. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 01/07/2018, 10:17 AM, Stratos Zolotas wrote:
Hi,
I'm getting an always reproducible kernel panic and the system is not bootable with kernel 4.14.11. Booting with 4.14.9 works.
Was only able to take a photo....
https://photos.app.goo.gl/CplKIGQy6tnvM2c83
Anyone else experiencing this or any hint on what to look?
Could you try to boot with "nopti" kernel option? Is 4.14.12 better? thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, Jan 7, 2018 at 11:59 AM, Jiri Slaby <jslaby@suse.cz> wrote:
Could you try to boot with "nopti" kernel option?
With "nopti" 4.14.11 boots ok.
Is 4.14.12 better?
From which repo should I try 4.14.12 in case it works without the extra kernel option?
Thanks. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 07.01.2018 um 11:12 schrieb Stratos Zolotas:
On Sun, Jan 7, 2018 at 11:59 AM, Jiri Slaby <jslaby@suse.cz> wrote:
Could you try to boot with "nopti" kernel option?
With "nopti" 4.14.11 boots ok.
Is 4.14.12 better?
From which repo should I try 4.14.12 in case it works without the extra kernel option?
Thanks.
https://download.opensuse.org/repositories/Kernel:/stable/standard/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Kernel 4.14.12 fails even with "nopti" option for me... On Sun, Jan 7, 2018 at 12:19 PM, Frank Krüger <fkrueger@mailbox.org> wrote:
Am 07.01.2018 um 11:12 schrieb Stratos Zolotas:
On Sun, Jan 7, 2018 at 11:59 AM, Jiri Slaby <jslaby@suse.cz> wrote:
Could you try to boot with "nopti" kernel option?
With "nopti" 4.14.11 boots ok.
Is 4.14.12 better?
From which repo should I try 4.14.12 in case it works without the extra kernel option?
Thanks.
https://download.opensuse.org/repositories/Kernel:/stable/standard/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 01/07/2018, 11:41 AM, Stratos Zolotas wrote:
Kernel 4.14.12 fails even with "nopti" option for me...
Which is bad as nopti is implicitly set for all AMD cpus since 4.14.12. Could you take a photo again? thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, Jan 7, 2018 at 2:54 PM, Jiri Slaby <jslaby@suse.cz> wrote:
Could you take a photo again?
With kernel 4.14.12 and teamviewrd service enabled. https://photos.app.goo.gl/Z6T7K54IzHfah40Z2 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 01/07/2018, 11:12 AM, Stratos Zolotas wrote:
On Sun, Jan 7, 2018 at 11:59 AM, Jiri Slaby <jslaby@suse.cz> wrote:
Could you try to boot with "nopti" kernel option?
With "nopti" 4.14.11 boots ok.
Can you provide us with your /proc/cpuinfo?
Is 4.14.12 better?
From which repo should I try 4.14.12 in case it works without the extra kernel option?
It is in Kernel:stable yet, pending for tumbleweed: https://build.opensuse.org/project/monitor?project=Kernel%3Astable -- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, Jan 7, 2018 at 12:46 PM, Jiri Slaby <jslaby@suse.cz> wrote:
Can you provide us with your /proc/cpuinfo?
AMD FX-8350 cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD FX(tm)-8350 Eight-Core Processor stepping : 0 microcode : 0x600084f cpu MHz : 2100.000 cache size : 2048 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 16 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb cpb hw_pstate vmmcall bmi1 arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bugs : fxsave_leak sysret_ss_attrs null_seg cpu_insecure bogomips : 8037.21 TLB size : 1536 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 01/07/2018 11:57 AM, Stratos Zolotas wrote:
On Sun, Jan 7, 2018 at 12:46 PM, Jiri Slaby <jslaby@suse.cz> wrote:
Can you provide us with your /proc/cpuinfo?
AMD FX-8350
You should be safe turning PTI off permanently on AMD CPUs, it is actually disabled by default on AMD CPUs in recent kernels [1]. Nevertheless, please file a bug report, preferably in the upstream kernel bug tracker reporting this issue. Adrian
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jiri Slaby writes:
Could you try to boot with "nopti" kernel option?
That saved me today when I tried to update my old Athlon64 based machine from 20180104 to 20180109. It would always panic after the installation of a 32bit package from Gtk.
Is 4.14.12 better?
Looks good so far, but I haven't run many things. Regards Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 07/01/18 20:17, Stratos Zolotas wrote:
Hi,
I'm getting an always reproducible kernel panic and the system is not bootable with kernel 4.14.11. Booting with 4.14.9 works.
Was only able to take a photo....
https://photos.app.goo.gl/CplKIGQy6tnvM2c83
Anyone else experiencing this or any hint on what to look?
Stratos.
Ooops...I just realised that this is Factory list so we are talking here Tumbleweed, right? Well, I *still* get this in LEAP 42.3 but not anymore in TW. In TW I am now running kernel 4.14.12.x *AND* the new BETA version of the nVidia driver -- 390.12 -- and the nvidia driver compiles and the TW boots without any problems. (But I haven't allowed TW to be updated to the latest 'snapshot' -- I might just forego this while the going is good.) In Leap 42.3 I am also using nvidia driver 390.12 and kernel 4.14.12.0 and I get the error msg you mention above. However, I can compile the nvidia driver and get 42.3 to boot by using adding to the command line which compiles the nvidia driver: '--no-unified-memory'. And this what has got me absolutely bamboozled: both Leap 42.3 and TW are installed on the same desktop and yet Leap stuffs-up while TW I managed to get working. BC -- Always be nice to people on your way up -- you'll see the same people on your way down. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
07.01.2018 12:17, Stratos Zolotas пишет:
Hi,
I'm getting an always reproducible kernel panic and the system is not bootable with kernel 4.14.11.
Your screenshot shows that kernel panics when starting specific process (teamviewerd); you should be able to disable this service. B> ooting with 4.14.9 works.
Was only able to take a photo....
https://photos.app.goo.gl/CplKIGQy6tnvM2c83
Anyone else experiencing this or any hint on what to look?
Stratos.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, Jan 7, 2018 at 12:58 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
Your screenshot shows that kernel panics when starting specific process (teamviewerd); you should be able to disable this service.
Oh yes, again a closed source issue. That did the trick. Kernel 4.14.11 boots now with "nopti" option after disabling the service start. Thanks! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 01/07/2018, 12:07 PM, Stratos Zolotas wrote:
On Sun, Jan 7, 2018 at 12:58 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
Your screenshot shows that kernel panics when starting specific process (teamviewerd); you should be able to disable this service.
Oh yes, again a closed source issue. That did the trick. Kernel 4.14.11 boots now with "nopti" option after disabling the service start.
No user space program (provided it does not write to /dev/mem or something) shall be able to crash the kernel. It is the PTI patchset suspect here -- there is a lot of issues with that crap arising. -- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op zondag 7 januari 2018 12:20:47 CET schreef Jiri Slaby:
On 01/07/2018, 12:07 PM, Stratos Zolotas wrote:
On Sun, Jan 7, 2018 at 12:58 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
Your screenshot shows that kernel panics when starting specific process (teamviewerd); you should be able to disable this service.
Oh yes, again a closed source issue. That did the trick. Kernel 4.14.11 boots now with "nopti" option after disabling the service start
No user space program (provided it does not write to /dev/mem or something) shall be able to crash the kernel. It is the PTI patchset suspect here -- there is a lot of issues with that crap arising.
Yup, a sudden increase of posts about freezes, kernel-panic, spontanious reboots in the forums as well. Both for Tumbleweed and Leap. Users can test the nopti nospec noefi boot options by hitting 'e' in GRUB, as a commandline parameter, after 'showopts' . All these options have been reported to work as well as not to work. Some report that even booting a previous kernel doesn't work. Of course booting into a btrfs snapshot does work for those who use btrfs. FWIW Reported by Debian users as well -- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Knurpht - Gertjan Lettink <knurpht@opensuse.org> [01-07-18 11:04]:
Op zondag 7 januari 2018 12:20:47 CET schreef Jiri Slaby:
On 01/07/2018, 12:07 PM, Stratos Zolotas wrote:
On Sun, Jan 7, 2018 at 12:58 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
Your screenshot shows that kernel panics when starting specific process (teamviewerd); you should be able to disable this service.
Oh yes, again a closed source issue. That did the trick. Kernel 4.14.11 boots now with "nopti" option after disabling the service start
No user space program (provided it does not write to /dev/mem or something) shall be able to crash the kernel. It is the PTI patchset suspect here -- there is a lot of issues with that crap arising.
Yup, a sudden increase of posts about freezes, kernel-panic, spontanious reboots in the forums as well. Both for Tumbleweed and Leap. Users can test the nopti nospec noefi boot options by hitting 'e' in GRUB, as a commandline parameter, after 'showopts' . All these options have been reported to work as well as not to work. Some report that even booting a previous kernel doesn't work. Of course booting into a btrfs snapshot does work for those who use btrfs. FWIW Reported by Debian users as well
no problem here:
inxi CPU~Hexa core Intel Core i7 970 (-HT-MCP-) speed/max~1596/3193 MHz Kernel~4.14.11-1-default x86_64 Up~2:04 Mem~11046.1/36189.5MB HDD~13638.2GB(10.0% used) Procs~457 Client~Shell inxi~2.3.40 nvidia gt450 and NVIDIA-Linux-x86_64-390.12.run
-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op zondag 7 januari 2018 18:18:48 CET schreef Patrick Shanahan:
* Knurpht - Gertjan Lettink <knurpht@opensuse.org> [01-07-18 11:04]:
Op zondag 7 januari 2018 12:20:47 CET schreef Jiri Slaby:
On 01/07/2018, 12:07 PM, Stratos Zolotas wrote:
On Sun, Jan 7, 2018 at 12:58 PM, Andrei Borzenkov <arvidjaar@gmail.com>
wrote:
Your screenshot shows that kernel panics when starting specific process (teamviewerd); you should be able to disable this service.
Oh yes, again a closed source issue. That did the trick. Kernel 4.14.11 boots now with "nopti" option after disabling the service start
No user space program (provided it does not write to /dev/mem or something) shall be able to crash the kernel. It is the PTI patchset suspect here -- there is a lot of issues with that crap arising.
Yup, a sudden increase of posts about freezes, kernel-panic, spontanious reboots in the forums as well. Both for Tumbleweed and Leap. Users can test the nopti nospec noefi boot options by hitting 'e' in GRUB, as a commandline parameter, after 'showopts' .
All these options have been reported to work as well as not to work. Some
report that even booting a previous kernel doesn't work. Of course booting into a btrfs snapshot does work for those who use btrfs. FWIW Reported by Debian users as well
no problem here:
Neither here. Just noticed.
inxi
CPU~Hexa core Intel Core i7 970 (-HT-MCP-) speed/max~1596/3193 MHz Kernel~4.14.11-1-default x86_64 Up~2:04 Mem~11046.1/36189.5MB HDD~13638.2GB(10.0% used) Procs~457 Client~Shell inxi~2.3.40 nvidia gt450 and NVIDIA-Linux-x86_64-390.12.run
-- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
07.01.2018 19:03, Knurpht - Gertjan Lettink пишет:
Op zondag 7 januari 2018 12:20:47 CET schreef Jiri Slaby:
On 01/07/2018, 12:07 PM, Stratos Zolotas wrote:
On Sun, Jan 7, 2018 at 12:58 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
Your screenshot shows that kernel panics when starting specific process (teamviewerd); you should be able to disable this service.
Oh yes, again a closed source issue. That did the trick. Kernel 4.14.11 boots now with "nopti" option after disabling the service start
No user space program (provided it does not write to /dev/mem or something) shall be able to crash the kernel. It is the PTI patchset suspect here -- there is a lot of issues with that crap arising.
Yup, a sudden increase of posts about freezes, kernel-panic, spontanious reboots in the forums as well. Both for Tumbleweed and Leap. Users can test the nopti nospec noefi boot options by hitting 'e' in GRUB, as a commandline parameter, after 'showopts' . All these options have been reported to work as well as not to work. Some report that even booting a previous kernel doesn't work. Of course booting into a btrfs snapshot does work for those who use btrfs. FWIW Reported by Debian users as well
There is also at least one report that latest Intel microcode results in unbootable system: https://bugzilla.opensuse.org/show_bug.cgi?id=1074919. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Stratos! On 01/07/2018 10:17 AM, Stratos Zolotas wrote:
Was only able to take a photo....
https://photos.app.goo.gl/CplKIGQy6tnvM2c83
Anyone else experiencing this or any hint on what to look?
On a sidenote: A very useful feature of the Linux kernel in these situations is the netconsole [1] which allows to use a second computer on the network as a text terminal for the early kernel boot and is very helpful to capture kernel backraces in case of a panic. Adrian
[1] https://wiki.archlinux.org/index.php/Netconsole -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
I'm seeing the same thing here today. After issuing zypper dup (20180110 -> 20180114) the system spontaneously rebooted while applying updates. I found out that I could not boot into the system with the new 4.14.12-1.8 kernel. Booting with the 4.14.11 kernel did work, so I tried to finish the update that got previously interrupted. I tried that at least three times, but every time when zypper was halfway uninstalling fetchmsttfonts the kernel panicked. After several tries I decided to go back to a safe snapshot, and that worked perfectly. I am now again booting with kernel 4.14.12-1.5 without problems, and I'm refraining from trying to update again until I see some news here. Here is my /proc/cpuinfo (I am only reporting the first of my 8 cores, as they are all identical I suppose): Cris -- Sent from: http://opensuse.14.x6.nabble.com/opensuse-factory-f3292933.html -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Cris70 wrote
(...) Here is my /proc/cpuinfo (I am only reporting the first of my 8 cores, as they are all identical I suppose): (...)
Somehow my /proc/cpuinfo didn't get through, however my cpu is an AMD FX-8350, just like Stratos'. Cris -- Sent from: http://opensuse.14.x6.nabble.com/opensuse-factory-f3292933.html -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
I had the same issue on an AMD kaveri apu. It would reproducably kernel panic and then reboot while zypper dup tried to install some gtk-32bit package. Just watch the process to see at which package it hangs. Then zypper rm the package and try zypper dup again. If you need it, you can re-install the gtk package afterwards again. That worked for me (TM)... cheers, tomme Am 17.01.2018 um 09:12 schrieb Cris70:
Cris70 wrote
(...) Here is my /proc/cpuinfo (I am only reporting the first of my 8 cores, as they are all identical I suppose): (...)
Somehow my /proc/cpuinfo didn't get through, however my cpu is an AMD FX-8350, just like Stratos'.
Cris
-- Sent from: http://opensuse.14.x6.nabble.com/opensuse-factory-f3292933.html
-- fest 040 32536326 mobil 01525 337 1476 Heidebrinker Weg 7 22147 Hamburg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Tomme! tomtomme wrote
I had the same issue on an AMD kaveri apu. It would reproducably kernel panic and then reboot while zypper dup tried to install some gtk-32bit package. Just watch the process to see at which package it hangs. Then zypper rm the package and try zypper dup again. If you need it, you can re-install the gtk package afterwards again. That worked for me (TM)... cheers, tomme
The problem is that in my case it would reproducibly panic when *removing* a package. I tried removing it alone (i.e. not in the process of a zypper dup), but it would nonetheless panic the kernel. So I had no other choice than to roll back to an earlier snapshot. Cris -- Sent from: http://opensuse.14.x6.nabble.com/opensuse-factory-f3292933.html -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, although I don't have any issue to boot with 4.14.12 after disabling the teamviewer service, I have experienced 2 kernel panics when zypper dup was running for next snapshots... It seems that something is broken seriously but I don't know where to look... Stratos On Wed, Jan 17, 2018 at 12:36 PM, Cris70 <criguada@gmail.com> wrote:
Hi Tomme!
tomtomme wrote
I had the same issue on an AMD kaveri apu. It would reproducably kernel panic and then reboot while zypper dup tried to install some gtk-32bit package. Just watch the process to see at which package it hangs. Then zypper rm the package and try zypper dup again. If you need it, you can re-install the gtk package afterwards again. That worked for me (TM)... cheers, tomme
The problem is that in my case it would reproducibly panic when *removing* a package. I tried removing it alone (i.e. not in the process of a zypper dup), but it would nonetheless panic the kernel. So I had no other choice than to roll back to an earlier snapshot.
Cris
-- Sent from: http://opensuse.14.x6.nabble.com/opensuse-factory-f3292933.html -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (11)
-
Achim Gratz -
Andrei Borzenkov -
Basil Chupin -
Cris70 -
Frank Krüger -
Jiri Slaby -
John Paul Adrian Glaubitz -
Knurpht - Gertjan Lettink -
Patrick Shanahan -
Stratos Zolotas -
tomtomme