[opensuse] crash problem with 13.2
Hello, I have a serious problem with my 13.2 install. In short it crashes approx twice a day. Hardcrash. Suddenly no more keyboard nor mouse. sometime, after a long wait (very long, it happenned twice and I was no more in front of the computer, it reboots or unconnect, anyway I find the computer sitting on the login prompt. I don't see anything in the system logs I have this from the beginning (a week or more), never had it with 13.1. What's new apart the 13.2 is the use of a new 256Gb Kingston ssd devoted at the 13.2 install and sitted on an external esata dock (I have the dock since more than two years with no problem). What can I do to track the problem? it do not come at any special time, but randomly. thanks jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd wrote:
Hello,
I have a serious problem with my 13.2 install.
In short it crashes approx twice a day. Hardcrash. Suddenly no more keyboard nor mouse. sometime, after a long wait (very long, it happenned twice and I was no more in front of the computer, it reboots or unconnect, anyway I find the computer sitting on the login prompt.
I don't see anything in the system logs
I have this from the beginning (a week or more), never had it with 13.1.
What's new apart the 13.2 is the use of a new 256Gb Kingston ssd devoted at the 13.2 install and sitted on an external esata dock (I have the dock since more than two years with no problem).
What can I do to track the problem? it do not come at any special time, but randomly.
Can you try loading an alternate kernel? Ideally -- for testing, if you can substitute in a "vanilla" kernel with as few "patch addons" as necessary for things to work, that could help. Do you run with any sort of HANGCHECK timer
zgrep HANG /proc/config.gz CONFIG_HANGCHECK_TIMER=m <- (m or y)
or a Watchdog timer that can yell if a process hangs?...
zgrep WATCH /proc/config.gz CONFIG_AUDIT_WATCH=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_IPMI_WATCHDOG=m CONFIG_WATCHDOG=y CONFIG_WATCHDOG_CORE=y
Nov 12 04:41:46 Ishtar kernel: [ 5766.362637] INFO: task sendmail:38508 blocked for more than 120 seconds. Nov 12 04:41:46 Ishtar kernel: [ 5766.369362] Not tainted 3.17.2-Isht-Van #1 Nov 12 04:41:46 Ishtar kernel: [ 5766.373984] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Nov 12 04:41:46 Ishtar kernel: [ 5766.381842] ffff880f221d7700 0000000000000046 ffff880a8f16a510 ffff880f221d7fd8 Nov 12 04:41:46 Ishtar kernel: [ 5766.381844] 00000000001d3b40 00000000001d3b40 ffff8817fbca4a20 ffff880a8f16a510 Nov 12 04:41:46 Ishtar kernel: [ 5766.381847] 7fffffffffffffff ffff880bf796d370 0000000000000002 0000000000000000 Nov 12 04:41:46 Ishtar kernel: [ 5766.381848] Call Trace: Nov 12 04:41:46 Ishtar kernel: [ 5766.381856] [<ffffffff8160cea4>] schedule+0x24/0x70 [.....] Nov 12 04:41:46 Ishtar kernel: [ 5766.382027] [<ffffffff81613352>] system_call_fastpath+0x16/0x1b Nov 12 04:41:46 Ishtar kernel: [ 5766.382029] 4 locks held by sendmail/38508: Nov 12 04:41:46 Ishtar kernel: [ 5766.382029] #0: (sb_writers#3){......}, at: [<ffffffff811c62bf>] mnt_want_write+0x1f/0x50 ... --------------- Had a few of those in my log w/the 3.17.2 kernel due to a regression, moving back to 3.16.x & waiting for 3.17.3 got around the problem. In my case, the hangs were xfs related, so I posted a Q on the xfs list and found out about the regression (that only appeared during "xfsdump"s (backups)), but having a good amount of system logs around so you can know what is "normal" and what is not, helps when "abnormal" pops up. FWIW, I also *try* to keep my system-boot messages:
unzip -l boot.msg.zip Archive: boot.msg.zip Length Date Time Name 190342 2011-12-24 00:56 boot-111224.0057 ... 120345 2014-11-17 09:29 boot-141117.0933
17410349 120 files ---- Doesn't always help, but keeping logs can let you look for anomalies that can point to problems. Other than that, there are too many causes of the symptoms you describe -- maybe googling for your problem? "how to track suse 13.2 hang" brings up a bunch of places to look... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 07/12/2014 11:37, jdd a écrit :
Hello,
I have a serious problem with my 13.2 install.
before I try an other kernel (forgive me, but as this bug appen approx twice a day, I have to wait between every test :-) it crashed à 15h45 and this time I have in the logs (see below). I also give my zypper lr. I have yast:Head, but only for rear and I don't use it I don't know what cpu 4 is doing :-) may I change kernel or any kernel config? thanks jdd déc. 08 15:45:32 linux-uegt kernel: BUG: soft lockup - CPU#1 stuck for 22s! [kwin:1542] déc. 08 15:45:32 linux-uegt kernel: BUG: soft lockup - CPU#2 stuck for 22s! [Xorg:1054] déc. 08 15:45:32 linux-uegt kernel: BUG: soft lockup - CPU#3 stuck for 23s! [systemd-journal:470] the last log line (fror this session: déc. 08 15:44:30 linux-uegt kernel: nouveau E[ VM][0000:01:00.0] vm flush timeout: engine 13 déc. 08 15:44:34 linux-uegt kernel: nouveau E[ PGRAPH][0000:01:00.0] PGRAPH TLB flush idle timeout fail déc. 08 15:44:34 linux-uegt kernel: nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_STATUS : 0x00be0001 BUSY ENG2D RMASK TPC_RAST TPC_PROP TPC_TEX TPC_MP déc. 08 15:44:34 linux-uegt kernel: nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_VSTATUS0: 0x00000000 déc. 08 15:44:34 linux-uegt kernel: nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_VSTATUS1: 0x0000106d TPC_TEX TPC_MP déc. 08 15:44:34 linux-uegt kernel: nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_VSTATUS2: 0x00148000 ENG2D déc. 08 15:44:34 linux-uegt kernel: nouveau E[ PGRAPH][0000:01:00.0] vm flush timeout déc. 08 15:44:36 linux-uegt kernel: nouveau E[ VM][0000:01:00.0] vm flush timeout: engine 13 déc. 08 15:45:31 linux-uegt kernel: nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00200000, ch 6 déc. 08 15:45:32 linux-uegt kernel: [sched_delayed] sched: RT throttling activated déc. 08 15:45:32 linux-uegt kernel: nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00200000, ch 6 déc. 08 15:45:32 linux-uegt kernel: nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00200000, ch 6 déc. 08 15:45:32 linux-uegt kernel: hrtimer: interrupt took 288699270 ns déc. 08 15:45:32 linux-uegt kernel: nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00200000, ch 6 déc. 08 15:45:32 linux-uegt kernel: nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00200000, ch 6 déc. 08 15:45:32 linux-uegt kernel: nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00a00000, ch 6 déc. 08 15:45:32 linux-uegt kernel: nouveau E[ PFIFO][0000:01:00.0] CACHE_ERROR - ch 127 [unknown] subc 7 mthd 0x1ffc data 0xffffffff déc. 08 15:45:32 linux-uegt kernel: nouveau E[ PFIFO][0000:01:00.0] DMA_PUSHER - ch 127 [unknown] get 0x0020006a7c put 0x0020006a7c ib_get 0x00000390 ib_put 0x00000391 state 0x00000024 (err: NONE) push 0x00504011 déc. 08 15:45:32 linux-uegt kernel: nouveau W[ PFIFO][0000:01:00.0] unknown intr 0xbfefefee, ch 127 déc. 08 15:45:32 linux-uegt kernel: BUG: soft lockup - CPU#1 stuck for 22s! [kwin:1542] déc. 08 15:45:32 linux-uegt kernel: Modules linked in: bnep bluetooth 6lowpan_iphc fuse af_packet xt_pkttype xt_LOG xt_limit ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT iptable_raw xt_CT iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tables usblp xfs libcrc32c iTCO_wdt gpio_ich iTCO_vendor_support snd_hda_codec_hdmi intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd serio_raw pcspkr i2c_i801 joydev arc4 rt2800pci rt2800mmio rt2800lib rt2x00pci snd_hda_codec_realtek rt2x00mmio snd_hda_codec_generic rt2x00lib eeprom_93cx6 mac80211 cfg80211 snd_hda_intel crc_ccitt déc. 08 15:45:32 linux-uegt kernel: rfkill snd_hda_controller r8169 snd_hda_codec mii snd_hwdep snd_pcm snd_timer snd soundcore lpc_ich mfd_core mei_me mei shpchp acpi_cpufreq processor dm_mod btrfs xor raid6_pq crc32c_intel sr_mod cdrom firewire_ohci xhci_hcd firewire_core déc. 08 15:45:32 linux-uegt kernel: BUG: soft lockup - CPU#2 stuck for 22s! [Xorg:1054] déc. 08 15:45:32 linux-uegt kernel: crc_itu_t déc. 08 15:45:32 linux-uegt kernel: nouveau video déc. 08 15:45:32 linux-uegt kernel: Modules linked in: déc. 08 15:45:32 linux-uegt kernel: bnep bluetooth déc. 08 15:45:32 linux-uegt kernel: mxm_wmi déc. 08 15:45:32 linux-uegt kernel: 6lowpan_iphc déc. 08 15:45:32 linux-uegt kernel: BUG: soft lockup - CPU#3 stuck for 23s! [systemd-journal:470] LANG=us ; zypper lr # | Alias | Name | Enabled | Refresh ---+---------------------------+------------------------------------+---------+-------- 1 | YaST:Head | YaST:Head | No | No 2 | ftp.gwdg.de-suse | Packman Repository | Yes | Yes 3 | openSUSE-13.2-0 | openSUSE-13.2-0 | Yes | No 4 | opensuse-guide.org-repo | libdvdcss repository | Yes | Yes 5 | repo-debug | openSUSE-13.2-Debug | No | Yes 6 | repo-debug-update | openSUSE-13.2-Update-Debug | No | Yes 7 | repo-debug-update-non-oss | openSUSE-13.2-Update-Debug-Non-Oss | No | Yes 8 | repo-non-oss | openSUSE-13.2-Non-Oss | Yes | Yes 9 | repo-oss | openSUSE-13.2-Oss | Yes | Yes 10 | repo-source | openSUSE-13.2-Source | No | Yes 11 | repo-update | openSUSE-13.2-Update | Yes | Yes 12 | repo-update-non-oss | openSUSE-13.2-Update-Non-Oss | Yes | Yes -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd wrote:
I don't know what cpu 4 is doing :-)
may I change kernel or any kernel config?
déc. 08 15:45:32 linux-uegt kernel: BUG: soft lockup - CPU#1 stuck for 22s! [kwin:1542] déc. 08 15:45:32 linux-uegt kernel: BUG: soft lockup - CPU#2 stuck for 22s! [Xorg:1054] déc. 08 15:45:32 linux-uegt kernel: BUG: soft lockup - CPU#3 stuck for 23s! [systemd-journal:470] ==== In *****my mind*****, 22-23 seconds is awfully low -- from the below, most things seem to be waiting on flush I/O timeout which indicates you are running way too many disk I/O intensive processes for your disk to keep up -- if any process (highest priority process will get 1st dibs, and systemd puts itself at the top of the food chain). From PAST discussion,
What do you mean? The best thing to do is too copy a working "config" into your source tree, then run make 'oldconfig' to make the new config compatible w/the old, then run "make xconfig". Gives you a nice gui you can use to go through about 200-400 options. most you won't need as they apply to Hw you won't have or other platforms. the designers of systemd-journal designed it for a high speed SSD, and using it on a normal spinning disk can bring many systems to a crawl. On top of that ... well... I have a relatively beefy I/O system (RAID 10 for all data disks) with about 11 separate RAID groups -- which means the system can do UP TO around 10-11 separate R/W at the same time -- AND I have my timeout set to 180seconds (yeah, I try to go for over-engineered solutions and often find out I was lucky cuz worst cases happen). At the same time you are running your regular system load.. try running 'latencytop -c >& ~/latency.log. That may be able to tell you which commands are causing the most latency problems that are causing a **cascade** of timeouts an could be causing your issue. Also, cpu'4' is likely a red-herring (next time it might be 3 or 0... whatever). You **could** use schedtool to set affinities to groups of processes (all background daemons on 1 core, all real-time ones on cores 2+3, all user procs on 4...etc)... manipulating what cores they can run on might help gather data... but hopefully the logging of latency issues will be sufficient to point the way... Unless systemd-journal has been improved alot, it had a rep for being poorly designed for normal disks, so you might try to see if that is fixed, and/or use another syslog daemon for the actual output. Another thing -- if you are logging to a tmpfs system, could it be filling? and slowing down while it is fragmenting more and looking for space? BTW -- I hate bugs like these -- so hard to know what direction to go. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 08/12/2014 22:15, Linda Walsh a écrit :
jdd wrote:
déc. 08 15:45:32 linux-uegt kernel: BUG: soft lockup - CPU#3 stuck for 23s! [systemd-journal:470] ==== In *****my mind*****, 22-23 seconds is awfully low --
for sure :-) from the
below, most things seem to be waiting on flush I/O timeout which indicates you are running way too many disk I/O intensive processes for your disk to keep up
In fact it's a brand new Kingston 256Gb very fast ssd
the designers of systemd-journal designed it for a high speed SSD, and using it on a normal spinning disk can bring many systems to a crawl.
but i *use* a fast ssd :-(
At the same time you are running your regular system load...
yes, only computer user (and not that much now, apart some copy to the web)
try running 'latencytop -c >& ~/latency.log.
I do, and also iostat, hope not to fill the disk before the crash :-)
Also, cpu'4' is likely a red-herring (next time it might be 3 or 0... whatever).
yes, I just wondered why one cpu is not enough when there are no intensive work :-)
Another thing -- if you are logging to a tmpfs system, could it be filling? and slowing down while it is fragmenting more and looking for space?
don't know The install is pretty fresh and mostly standard (apart the debugging tools I install now :-)
BTW -- I hate bugs like these -- so hard to know what direction to go.
sure, but the logs I sent seemed to quote nouveau déc. 08 15:45:32 linux-uegt kernel: nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00200000, ch 6 may be nouveau infinite loop? If I get this again, I will test the nvidia prpprietary driver (about nouveau, what a dumb idea to choose this name, it makes it mostly impossible to google for it!) thanks jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
crash just happening loga are below. I have complete iostat, latencytop and journald logs if necessary. journald seems to speak about nouveau. When the session crashed, I was just clicking on a file link in a firefox/ftp page. The computer crashed, but not completely, I could see some mouse movement after, but ctl alt backspace did not kill the session, I had to do a hard reboot. ideas welcome :-( thanks jdd last latencytop. By the way I had no usb storage active at the moment :-(: =============== Tue Dec 9 22:37:54 2014 Globals: Cause Maximum Percentage Userspace lock contention 1.3 msec 79.4 % Waiting for event (poll) 0.9 msec 13.2 % [ep_poll] 0.2 msec 7.3 % Process details: Process ksoftirqd/0 (3) Total: 5.1 msec [smpboot_thread_fn] 3.1 msec 100.0 % smpboot_thread_fn kthread ret_from_fork Process rcu_preempt (9) Total: 1540.0 msec [rcu_gp_kthread] 3.0 msec 100.0 % rcu_gp_kthread kthread ret_from_fork Process rcuop/0 (10) Total: 11.6 msec [rcu_nocb_kthread] 2.9 msec 100.0 % rcu_nocb_kthread kthread ret_from_fork Process rcuop/1 (11) Total: 21.4 msec [rcu_nocb_kthread] 3.9 msec 100.0 % rcu_nocb_kthread kthread ret_from_fork Process ksoftirqd/1 (41) Total: 5.4 msec [smpboot_thread_fn] 3.5 msec 100.0 % smpboot_thread_fn kthread ret_from_fork Process usb-storage (228) Total: 1.9 msec [usb_sg_wait] 1.8 msec 93.6 % usb_sg_wait usb_stor_bulk_transfer_sglist.part.4 [usb_storage] usb_stor_bulk_srb [usb_storage] usb_stor_Bulk_transport [usb_storage] usb_stor_invoke_transport [usb_storage] usb_stor_control_thread [usb_storage] kthread ret_from_fork Process usb-storage (247) Total: 0.2 msec [usb_stor_msg_common] 0.1 msec 100.0 % usb_stor_msg_common [usb_storage] usb_stor_bulk_transfer_buf [usb_storage] usb_stor_Bulk_transport [usb_storage] usb_stor_invoke_transport [usb_storage] usb_stor_control_thread [usb_storage] kthread ret_from_fork Process usb-storage (259) Total: 0.2 msec [usb_stor_msg_common] 0.1 msec 100.0 % usb_stor_msg_common [usb_storage] usb_stor_bulk_transfer_buf [usb_sto last iotop - I don't really know what to looka at here: il sdc 0,00 0,00 2,00 0,00 150,00 0,00 150,00 0,01 4,50 4,50 0,00 1,25 0 ,25 avg-cpu: %user %nice %system %iowait %steal %idle 19,80 0,00 29,77 0,00 0,00 50,43 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %u til sdc 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0 ,00 ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@ (full of bin garbage) ^@^@^@^@^@^@^@^@^@^@^@m/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sdc 0,00 0,00 6,50 0,00 80,00 0,00 24,62 13,00 3997,00 3997,00 0,00 153,85 100,00 journalctl of crashed session, tail: déc. 09 22:35:50 linux-uegt kernel: nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_VSTATUS2: 0x00000000 déc. 09 22:35:52 linux-uegt kernel: nouveau E[ PGRAPH][0000:01:00.0] vm flush timeout déc. 09 22:35:52 linux-uegt kernel: nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00c00000, ch 3 déc. 09 22:35:54 linux-uegt kernel: nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00400000, ch 3 déc. 09 22:35:58 linux-uegt kernel: nouveau E[ VM][0000:01:00.0] vm flush timeout: engine 13 déc. 09 22:36:04 linux-uegt kernel: nouveau E[ PGRAPH][0000:01:00.0] PGRAPH TLB flush idle timeout fail déc. 09 22:36:04 linux-uegt kernel: nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_STATUS : 0xffffffff BUSY DISPATCH UNK2 UNK3 UNK4 UNK5 M2MF UNK7 CTXPROG VFETCH CCACHE_PREGEOM STRMOUT_VATTR_POSTGEOM VCLIP RATTR_APLANE TRAST CLIPID ZCULL ENG2D RMASK TPC_RAST TPC_PROP TPC_TEX TPC_GEOM TPC_MP ROP (unknown bits 0xfe000000) déc. 09 22:36:04 linux-uegt kernel: nouveau W[ BARCTL][0000:01:00.0] flush timeout déc. 09 22:36:04 linux-uegt kernel: nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_VSTATUS0: 0x00000009 VFETCH CCACHE déc. 09 22:36:04 linux-uegt kernel: nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_VSTATUS1: 0x00000000 déc. 09 22:36:04 linux-uegt kernel: nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_VSTATUS2: 0x00000000 déc. 09 22:36:04 linux-uegt kernel: nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00c00000, ch 3 déc. 09 22:36:04 linux-uegt kernel: nouveau E[ PGRAPH][0000:01:00.0] vm flush timeout déc. 09 22:36:04 linux-uegt kernel: nouveau W[ BARCTL][0000:01:00.0] flush timeout déc. 09 22:36:04 linux-uegt kernel: nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x04c00000, ch 3 déc. 09 22:36:04 linux-uegt kernel: nouveau W[ BARCTL][0000:01:00.0] flush timeout déc. 09 22:36:04 linux-uegt kernel: nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x04c00000, ch 3 déc. 09 22:36:04 linux-uegt rtkit-daemon[1716]: The canary thread is apparently starving. Taking action. déc. 09 22:36:04 linux-uegt rtkit-daemon[1716]: Demoting known real-time threads. déc. 09 22:36:04 linux-uegt rtkit-daemon[1716]: Successfully demoted thread 1835 of process 1715 (/usr/bin/pulseaudio). déc. 09 22:36:04 linux-uegt rtkit-daemon[1716]: Successfully demoted thread 1834 of process 1715 (/usr/bin/pulseaudio). déc. 09 22:36:04 linux-uegt rtkit-daemon[1716]: Successfully demoted thread 1833 of process 1715 (/usr/bin/pulseaudio). déc. 09 22:36:04 linux-uegt rtkit-daemon[1716]: Successfully demoted thread 1715 of process 1715 (/usr/bin/pulseaudio). déc. 09 22:36:04 linux-uegt rtkit-daemon[1716]: Demoted 4 threads. déc. 09 22:36:05 linux-uegt kernel: nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x04400000, ch 3 déc. 09 22:36:08 linux-uegt kernel: nouveau E[ VM][0000:01:00.0] vm flush timeout: engine 13 déc. 09 22:36:08 linux-uegt kernel: nouveau E[ PGRAPH][0000:01:00.0] PGRAPH TLB flush idle timeout fail déc. 09 22:36:08 linux-uegt kernel: nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_STATUS : 0x00000703 déc. 09 22:36:08 linux-uegt kernel: nouveau W[ BARCTL][0000:01:00.0] flush timeout déc. 09 22:36:08 linux-uegt kernel: BUSY DISPATCH CTXPROG VFETCH CCACHE_PREGEOM déc. 09 22:36:08 linux-uegt kernel: nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_VSTATUS0: 0x00000009 VFETCH CCACHE déc. 09 22:36:08 linux-uegt kernel: nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_VSTATUS1: 0x00000000 déc. 09 22:36:08 linux-uegt kernel: nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_VSTATUS2: 0x00000000 déc. 09 22:36:10 linux-uegt kernel: nouveau E[ PGRAPH][0000:01:00.0] vm flush timeout déc. 09 22:36:10 linux-uegt kernel: nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x04c00000, ch 3 déc. 09 22:36:12 linux-uegt kernel: nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00400000, ch 3 déc. 09 22:36:30 linux-uegt org.a11y.Bus[1439]: g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd wrote:
journalctl of crashed session, tail:... déc. 09 22:36:04 linux-uegt kernel: nouveau W[ BARCTL][0000:01:00.0] flush timeou
Not sure about the rest of your logs, but this stood out as easy to search for: linux kernel: nouveau W[ BARCTL] flush timeout I see a couple of kernel bugs that come up in this search, including at least one w/a hung cpu. .. also some bugs in RedHat w/the GeForce 310M/630M -- another Nvidia card... Check out some of the symptoms and see if they look familiar... Trying a different graphics driver might not hurt as an easy 'test', either... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 10/12/2014 07:07, Linda Walsh a écrit :
Not sure about the rest of your logs, but this stood out as easy to search for: linux kernel: nouveau W[ BARCTL] flush timeout
I should have done this. obviously too tired last night :-) thanks
Check out some of the symptoms and see if they look familiar... Trying a different graphics driver might not hurt as an easy 'test', either...
tabooed nouveau, looks like my system use nv now, will see... thanks jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 10/12/2014 10:13, jdd a écrit :
tabooed nouveau, looks like my system use nv now, will see...
using yasy to uninstall nouveau and taboo it is not enough to get rid of nouveau :-( I had also to echo "blacklist nouveau" >> /etc/modprobe.d/50-blacklist.conf and to add "nomodeset" to the kernel line :-( then no more nouveau in journalctl :-) will see is this changes anything to the crash. appointment in two days if alls works right :-) thanks jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 10/12/2014 11:52, jdd a écrit :
and to add "nomodeset" to the kernel line :-(
in fact, I for start did this on grub command line. When changing this parameter in yast, I got an error "grub install did not work, do you want to do it again?", and I aborted. but then, trying to make it by hand, I noticed the change was already done by yast, an so I don't understand the error :-( - works also after a reboot jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 10/12/2014 10:13, jdd a écrit : I keep the initial messsage below, because it looks like it's the solution. since it (two days), no more crash. If this stay like this some days more, I will report through bugzilla jdd
tabooed nouveau, looks like my system use nv now, will see...
using yasy to uninstall nouveau and taboo it is not enough to get rid of nouveau :-( I had also to echo "blacklist nouveau" >> /etc/modprobe.d/50-blacklist.conf and to add "nomodeset" to the kernel line :-( then no more nouveau in journalctl :-) will see is this changes anything to the crash. appointment in two days if alls works right :-) thanks jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (2)
-
jdd
-
Linda Walsh