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.
>
>