Displaying 5 results from an estimated 5 matches for "misprogrammed".
2019 Dec 20
0
[PATCH AUTOSEL 5.4 38/52] drm/nouveau/kms/nv50-: fix panel scaling
From: Ben Skeggs <bskeggs at redhat.com>
[ Upstream commit 3d1890ef8023e61934e070021b06cc9f417260c0 ]
Under certain circumstances, encoder atomic_check() can be entered
without adjusted_mode having been reset to the same as mode, which
confuses the scaling logic and can lead to a misprogrammed display.
Fix this by checking against the user-provided mode directly.
Link: https://bugs.freedesktop.org/show_bug.cgi?id=108615
Link: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/464
Signed-off-by: Ben Skeggs <bskeggs at redhat.com>
Signed-off-by: Sasha Levin <sa...
2009 Jul 12
13
pv_ops kernel and nvidia binary driver
Just wondering what it will take to get the nvidia binary driver
working on a pv_ops kernel.
It makes it difficult to debug without the source to the nvidia
driver, but I think it should be possible to get it to work without
changing the binary driver. If the dom0 kernel had access to all the
resources that a bare metal kernel did, then it should work right?
I''m using Jeremy''s
2009 Jul 12
13
pv_ops kernel and nvidia binary driver
Just wondering what it will take to get the nvidia binary driver
working on a pv_ops kernel.
It makes it difficult to debug without the source to the nvidia
driver, but I think it should be possible to get it to work without
changing the binary driver. If the dom0 kernel had access to all the
resources that a bare metal kernel did, then it should work right?
I''m using Jeremy''s
2008 May 13
1
Hard(?) lock when reassociating ath with wpa_supplicant on RELENG_7
I seem to be able to lock my machine by going into wpa_cli and asking it
to 'reassoc'. The reason for question mark after "hard" is that debug
information (caused by wlandebug and athdebug) is being printed on the
console. The only way to get machine's attention is to hold power button
for 8 seconds.
Note: manual reassociation is just the handy way to reproduce the
problem
2013 May 31
7
[PATCH v2] AMD/intremap: Prevent use of per-device vector maps until irq logic is fixed
XSA-36 changed the default vector map mode from global to per-device. This is
because a global vector map does not prevent one PCI device from impersonating
another and launching a DoS on the system.
However, the per-device vector map logic is broken for devices with multiple
MSI-X vectors, which can either result in a failed ASSERT() or misprogramming
of a guests interrupt remapping tables.