search for: libphys

On 21.03.19 18:12, Jerome Glisse wrote: > On Thu, Mar 21, 2019 at 04:59:14PM +0100, Tobias Klausmann wrote: >> Hi, >> >> just for your information and maybe for some help: with 5.1rc1 and SVM >> enabled i see the following backtrace [1] when the nouveau card (reverse >> prime) goes to sleep, for now i have papered over with [2] which leaves me >> with

https://bugs.freedesktop.org/show_bug.cgi?id=108658 Bug ID: 108658 Summary: gt215 scheduling while atomic warning Product: xorg Version: git Hardware: Other OS: All Status: NEW Severity: major Priority: medium Component: Driver/nouveau Assignee: nouveau at

https://bugzilla.netfilter.org/show_bug.cgi?id=991 Bug ID: 991 Summary: Exactly after 24h of uptime system hungs Product: netfilter/iptables Version: unspecified Hardware: sparc64 OS: Debian GNU/Linux Status: NEW Severity: blocker Priority: P5 Component: ip_tables (kernel)

https://bugs.freedesktop.org/show_bug.cgi?id=99966 Bug ID: 99966 Summary: Crash of nouveau - cache related? Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

Hi, while doing work, my luks encrypted btrfs home got a nice stacktrace i run a Debian testing and a kernel 3.4 vanilla % uname -a Linux Klappe2 3.4.0 #2 SMP Thu Jun 14 03:02:37 CEST 2012 x86_64 GNU/Linux the box is a dell xps m 1330 with about 4gb ram % btrfs fi show Label: ''home'' uuid: 9c1a77c9-3767-43aa-908d-0bae1ef4e534 Total devices 1 FS bytes used 198.25GB devid

Hi, trying to pass through a intel x520 VF on a Dell R620, I''m getting in domU: [ 58.162639] pci 0000:00:00.6: address space collision: [mem 0xd500c000-0xd500ffff 64bit pref] conflicts with System RAM [mem 0x00100000-0x176ffffff] [ 58.162654] pcifront pci-0: Could not claim resource 0000:00:00.6/0! Device offline. Try using e820_host=1 in the guest config. and in dom0 (XEN)

Hi, we have regular crashed of a kvm host with the error "unable to handle paging request". Can this be due to memory over-commitment even if some memory is still used by the kernel for caches and buffers? (collectd graph shows no free memory, with 15G used, very little buffers, and 1G cache). There are 32GB of swap, of which only 150MB are used. I suspect might be the direction to

> -----Original Message----- > From: Matt [mailto:jackdachef@gmail.com] > Sent: Tuesday, February 15, 2011 5:12 PM > To: Minchan Kim > Cc: Dan Magenheimer; gregkh@suse.de; Chris Mason; linux- > kernel@vger.kernel.org; linux-mm@kvack.org; ngupta@vflare.org; linux- > btrfs@vger.kernel.org; Josef Bacik; Dan Rosenberg; Yan Zheng; > miaox@cn.fujitsu.com; Li Zefan > Subject:

Hi, just for your information and maybe for some help: with 5.1rc1 and SVM enabled i see the following backtrace [1] when the nouveau card (reverse prime) goes to sleep, for now i have papered over with [2] which leaves me with userspace hangs. Any pointers where to look for the actual culprit? PS: Card is: nouveau 0000:01:00.0: NVIDIA GP106 (136000a1) Greetings, Tobias [1]: BUG: unable

On (06/14/19 11:50), Sergey Senozhatsky wrote: > dmesg > > nouveau 0000:01:00.0: DRM: GPU lockup - switching to software fbcon > nouveau 0000:01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT] > nouveau 0000:01:00.0: fifo: runlist 0: scheduled for recovery > nouveau 0000:01:00.0: fifo: channel 5: killed > nouveau 0000:01:00.0: fifo: engine 6: scheduled for recovery >

Hi All, I''m having a similar issue as Ian Tobin some weeks ago here: http://lists.xensource.com/archives/html/xen-users/2010-02/msg00645.html I''m using Debian Squeeze amd64, downloaded the experimental debian xen-amd64 kernel with pv_ops support. linux-headers-2.6.32-5-common-xen_2.6.32-13_amd64.deb linux-headers-2.6.32-5-xen-amd64_2.6.32-13_amd64.deb

[15561.391527] ------------[ cut here ]------------ [15561.391560] WARNING: CPU: 0 PID: 20957 at drivers/gpu/drm/nouveau/nvif/vmm.c:71 nvif_vmm_put+0x4a/0x50 [nouveau] [15561.391562] Modules linked in: nls_utf8(E) isofs(E) fuse(E) msr(E) xt_comment(E) br_netfilter(E) xt_physdev(E) nfnetlink_cthelper(E) nfnetlink(E) ebtable_filter(E) ebtables(E) af_packet(E) bridge(E) stp(E) llc(E) iscsi_ibft(E)

Hi there, I just found a segfaulting tapdisk2 process which led into a kernel oops. [1527071.169682] tapdisk2[26548]: segfault at 7fffd324cfe8 ip 000000000040837f sp 00007fffd324cff0 error 6 in tapdisk2[400000+38000] [1527071.220104] BUG: unable to handle kernel NULL pointer dereference at 0000000000000048 [1527071.220170] IP: [<ffffffff810ce73c>] apply_to_page_range+0x47/0x2f3

[11558.527680] ------------[ cut here ]------------ [11558.527708] kernel BUG at fs/btrfs/transaction.c:1337! [11558.527730] invalid opcode: 0000 [#1] PREEMPT SMP [11558.527764] CPU 1 [11558.527776] Modules linked in: loop nls_cp437 vfat fat dm_mod xfs exportfs jfs usb_storage uas fuse ext4 jbd2 mbcache snd_hda_codec_hdmi snd_hda_codec_realtek arc4 iwlwifi snd_hda_intel snd_hda_codec uvcvideo

I get these kernel error messages too on 4.15-rc2 (and rc1) with my MSI GeForce 210. The messages appear to be benign as X Window and the X nouveau driver seem to work fine. [ 8.069341] fb: switching to nouveaufb from VESA VGA [ 8.089848] Console: switching to colour dummy device 80x25 [ 8.089983] nouveau 0000:0f:00.0: NVIDIA GT218 (0a8280b1) [ 8.104713] snd_hda_codec_realtek

5.2.0-rc4-next-20190613 dmesg nouveau 0000:01:00.0: DRM: GPU lockup - switching to software fbcon nouveau 0000:01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT] nouveau 0000:01:00.0: fifo: runlist 0: scheduled for recovery nouveau 0000:01:00.0: fifo: channel 5: killed nouveau 0000:01:00.0: fifo: engine 6: scheduled for recovery nouveau 0000:01:00.0: fifo: engine 0: scheduled for recovery

Hi there, Could someone please comment on the following hard-lock (*). Staring at the code, I see `nvkm_rd32` calls are enclosed in a timeout detection, except one. drivers/gpu/drm/nouveau/nvkm/engine/gr/g84.c#L171 ... nvkm_msec(device, 2000, if (!(nvkm_rd32(device, 0x100c80) & 0x00000001)) break; ); ... Would it make sense to also enclose this in the do/while loop ? Full ref: *

Hello we see the same with debian Wheezy. Apr 16 16:02:25 hypervisor3 kernel: [2441115.664216] vif vif-17-0: vif17.0: Frag is bigger than frame. Apr 16 16:02:25 hypervisor3 kernel: [2441115.664267] vif vif-17-0: vif17.0: fatal error; disabling device Apr 16 16:02:25 hypervisor3 kernel: [2441115.675667] BUG: unable to handle kernel NULL pointer dereference at 00000000000008b8 Apr 16 16:02:25

https://bugs.freedesktop.org/show_bug.cgi?id=109529 Bug ID: 109529 Summary: [NV46] unable to handle kernel paging request Product: Mesa Version: 18.2 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau Assignee: nouveau at

Dear all, Maybe I'm the only one - so before filing it as a bug: it appears that the latest set of kernel patches in 3.10.0-693.11.6.el7 makes issue 0013763 "CentOS 7.4 kernel (3.10.0-693*) fails to boot as Xen PV guest" re-surface *also* with the CentOS PLUS kernel. But maybe in a different way ... Thanks to the (great!) quick work on making the plus kernel available (in #14330,