similar to: stable? kms: take mode_config mutex in connector hotplug path

Displaying 20 results from an estimated 4000 matches similar to: "stable? kms: take mode_config mutex in connector hotplug path"

2014 Sep 09
2
mutex
Hi Amit, Rusty RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1127062 steps: - Read random data by 'dd if=/dev/hwrng of=/dev/null' in guest - check sysfs files in the same time, 'cat /sys/class/misc/hw_random/rng_*' Result: cat process will get stuck, it will return if we kill dd process. We have some static variables (eg, current_rng, data_avail, etc) in hw_random/core.c,
2014 Sep 09
2
mutex
Hi Amit, Rusty RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1127062 steps: - Read random data by 'dd if=/dev/hwrng of=/dev/null' in guest - check sysfs files in the same time, 'cat /sys/class/misc/hw_random/rng_*' Result: cat process will get stuck, it will return if we kill dd process. We have some static variables (eg, current_rng, data_avail, etc) in hw_random/core.c,
2014 Sep 15
1
[PATCH v2 1/3] virtio-rng cleanup: move some code out of mutex protection
On Tue, 16 Sep 2014 00:02:27 +0800 Amos Kong <akong at redhat.com> wrote: > It doesn't save too much cpu time as expected, just a cleanup. > > Signed-off-by: Amos Kong <akong at redhat.com> > --- > drivers/char/hw_random/core.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/char/hw_random/core.c
2014 Sep 15
1
[PATCH v2 1/3] virtio-rng cleanup: move some code out of mutex protection
On Tue, 16 Sep 2014 00:02:27 +0800 Amos Kong <akong at redhat.com> wrote: > It doesn't save too much cpu time as expected, just a cleanup. > > Signed-off-by: Amos Kong <akong at redhat.com> > --- > drivers/char/hw_random/core.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/char/hw_random/core.c
2014 Sep 10
0
[PATCH 1/2] virtio-rng cleanup: move some code out of mutex protection
It doesn't save too much cpu time as expected, just a cleanup. Signed-off-by: Amos Kong <akong at redhat.com> --- drivers/char/hw_random/core.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c index aa30a25..c591d7e 100644 --- a/drivers/char/hw_random/core.c +++ b/drivers/char/hw_random/core.c @@
2014 Sep 15
0
[PATCH v2 1/3] virtio-rng cleanup: move some code out of mutex protection
It doesn't save too much cpu time as expected, just a cleanup. Signed-off-by: Amos Kong <akong at redhat.com> --- drivers/char/hw_random/core.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c index aa30a25..c591d7e 100644 --- a/drivers/char/hw_random/core.c +++ b/drivers/char/hw_random/core.c @@
2015 Nov 07
12
[Bug 92851] New: NV34: err: MEM_FAULT
https://bugs.freedesktop.org/show_bug.cgi?id=92851 Bug ID: 92851 Summary: NV34: err: MEM_FAULT Product: xorg Version: unspecified Hardware: x86 (IA32) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Driver/nouveau Assignee: nouveau at
2018 Sep 05
0
[PATCH v2 1/6] drm: replace DRIVER_PREFER_XBGR_30BPP driver flag with mode_config quirk
Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- include/drm/drm_drv.h | 1 - include/drm/drm_mode_config.h | 1 + drivers/gpu/drm/drm_framebuffer.c | 4 ++-- drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h index 46a8009784..23b9678137 100644
2019 Jul 05
0
[PATCH v2 3/6] drm/fb-helper: Instanciate shadow FB if configured in device's mode_config
Generic framebuffer emulation uses a shadow buffer for framebuffers with dirty() function. If drivers want to use the shadow FB without such a function, they can now set prefer_shadow or prefer_shadow_fbdev in their mode_config structures. The former flag is exported to userspace, the latter flag is fbdev-only. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> ---
2016 Jun 01
0
segfault / crash when asking for large memory via strrep()
That would be because the product nc * ni overflows in cbuf = buf = CallocCharBuf(nc * ni); Since we disallow strings with more than 2^31-1 bytes we could test and reject this. It might be more future-proof to change the declaration of int j, ni, nc; to R_xlen_t j, ni, nc; and let the character allocation code reject, but that would create a memory leak since the Free call
2016 Jun 01
2
segfault / crash when asking for large memory via strrep()
We've had this more general topic on R-help, and also in R-devel recently. There's one case here where I get the feeling R never gets into swapping but more directly aborts possibly from a bug we can more easily fix. Today I've been working (successfully! - not yet committed) at fixing str() for very large strings. In this process, I've found that pc <- function(.)
2015 Nov 04
0
Re: P2V conversion failed with "/run/lvm/lvmetad.socket: connect failed: No such file or directory"
On Wed, Nov 04, 2015 at 06:08:16AM -0800, Tejas Gadaria wrote: > After starting conversation, at the time of decompressing kernel, after > loading modules by iso we are getting below error, > > *file -zb > /sysroot/lib/modules/3.17.4-301.fc21.x86_64/kernel/arch/x86/crypto/blowfish-x86_64.ko.xz* > *libguestfs: trace: file = "XZ compressed data"* > *libguestfs: trace:
2019 Jul 07
0
[PATCH v2 3/6] drm/fb-helper: Instanciate shadow FB if configured in device's mode_config
Hi Am 07.07.19 um 16:37 schrieb Noralf Tr?nnes: > > > Den 05.07.2019 11.26, skrev Thomas Zimmermann: >> Generic framebuffer emulation uses a shadow buffer for framebuffers with >> dirty() function. If drivers want to use the shadow FB without such a >> function, they can now set prefer_shadow or prefer_shadow_fbdev in their >> mode_config structures. The former
2018 May 18
0
[PATCH] drm/nouveau/kms/nv50-: fix drm-get-put.cocci warnings
From: kbuild test robot <fengguang.wu at intel.com> Use drm_*_get() and drm_*_put() helpers instead of drm_*_reference() and drm_*_unreference() helpers. Generated by: scripts/coccinelle/api/drm-get-put.cocci Fixes: 30ed49b55b6e ("drm/nouveau/kms/nv50-: move code underneath dispnv50/") Signed-off-by: kbuild test robot <fengguang.wu at intel.com> Signed-off-by: Julia
2014 Oct 21
0
VGA resume & thaw (wake up from S3 & S4) broken - reloaded & Fedora kernels 3.18 boot from soft-off(S5) broken
On 21.10.2014 02:23, poma wrote: > On 20.10.2014 21:30, poma wrote: >> On 20.10.2014 08:13, poma wrote: >>> >>> 02:00.0 VGA compatible controller: >>> NVIDIA Corporation G98 [GeForce 8400 GS Rev. 2] (rev a1) >>> Chipset: G98 (NV98) >>> Family : NV50 >>> >>> The same for all four kernel: >>> -
2014 Oct 20
2
INFO: task echo:622 blocked for more than 120 seconds. - 3.18.0-0.rc0.git
02:00.0 VGA compatible controller: NVIDIA Corporation G98 [GeForce 8400 GS Rev. 2] (rev a1) Chipset: G98 (NV98) Family : NV50 The same for all four kernel: - 3.18.0-0.rc0.git8.1.fc22.x86_64 - 3.18.0-0.rc0.git9.1.fc22.x86_64 - 3.18.0-0.rc0.git9.3.fc22.x86_64 - 3.18.0-0.rc0.git9.4.fc22.x86_64 after "fb: switching to nouveaufb from VESA VGA" display is powered off. The magic SysRq key
2015 Oct 06
2
Chipset & Family
4.1.8-200.fc22.x86_64 dmesg: [ 11.809467] nouveau [ DEVICE][0000:02:00.0] BOOT0 : 0x098200a2 [ 11.809493] nouveau [ DEVICE][0000:02:00.0] Chipset: G98 (NV98) [ 11.809508] nouveau [ DEVICE][0000:02:00.0] Family : NV50 4.3.0-0.rc4.git0.1.fc24.x86_64 dmesg: [ 2.483843] nouveau 0000:02:00.0: NVIDIA G98 (098200a2) Where vanished these Chipset & Family super cool lines?
2011 May 30
1
Fwd: Re: Fwd: cgroup OOM killer loop causes system to lockup (possible fix included) - now pinpointed to openssh-server
Just did some testing.. root at vicky:~# cat /var/log/auth.log | grep "Set" May 30 21:41:05 vicky sshd[1568]: Set /proc/self/oom_adj from -17 to -17 May 30 21:41:07 vicky sshd[1574]: Set /proc/self/oom_adj to -17 root at vicky:~# ps faux | grep 1574 root 1574 0.0 0.0 70488 3404 ? Ss 21:41 0:00 \_ sshd: root at pts/1 root at vicky:~# ps faux | grep
2014 Oct 21
2
VGA resume & thaw (wake up from S3 & S4) broken - reloaded & Fedora kernels 3.18 boot from soft-off(S5) broken
On 20.10.2014 21:30, poma wrote: > On 20.10.2014 08:13, poma wrote: >> >> 02:00.0 VGA compatible controller: >> NVIDIA Corporation G98 [GeForce 8400 GS Rev. 2] (rev a1) >> Chipset: G98 (NV98) >> Family : NV50 >> >> The same for all four kernel: >> - 3.18.0-0.rc0.git8.1.fc22.x86_64 >> - 3.18.0-0.rc0.git9.1.fc22.x86_64 >> -
2019 Jul 07
2
[PATCH v2 3/6] drm/fb-helper: Instanciate shadow FB if configured in device's mode_config
Den 05.07.2019 11.26, skrev Thomas Zimmermann: > Generic framebuffer emulation uses a shadow buffer for framebuffers with > dirty() function. If drivers want to use the shadow FB without such a > function, they can now set prefer_shadow or prefer_shadow_fbdev in their > mode_config structures. The former flag is exported to userspace, the latter > flag is fbdev-only. > >