Bug#686153: [PATCH] int10: fix pci_device_read_rom usage
On Thu, Aug 30, 2012 at 4:03 AM, Julien Cristau jcris...@debian.org wrote:
From: Stephan Schreiber i...@fs-driver.org
I noticed that the build-in int10 driver always reports
Unable to retrieve all of segment 0x0C.
even though the entire BIOS data is retrieved with success.
The associated code is in hw/xfree86/int10/generic.c, in the function
xf86ExtendedInitInt10():
if (pci_device_read_rom(pInt-dev, vbiosMem) V_BIOS_SIZE) {
xf86DrvMsg(screen, X_WARNING,
Unable to retrieve all of segment 0x0C.\n);
}
The function pci_device_read_rom() is from libpciaccess; its return
value is not a size but an error status code: 0 means success.
If pci_device_read_rom() returns 0 for success, the warning is generated.
The proposed patch corrects the evaluation of the return value of
pci_device_read_rom() and of the supplied BIOS size.
Debian bug#686153
Signed-off-by: Julien Cristau jcris...@debian.org
Reviewed-by: Dave Airlie airl...@redhat.com
---
hw/xfree86/int10/generic.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/xfree86/int10/generic.c b/hw/xfree86/int10/generic.c
index 4633120..d7594de 100644
--- a/hw/xfree86/int10/generic.c
+++ b/hw/xfree86/int10/generic.c
@@ -178,7 +178,8 @@ xf86ExtendedInitInt10(int entityIndex, int Flags)
*/
vbiosMem = (char *) base + V_BIOS;
memset(vbiosMem, 0, 2 * V_BIOS_SIZE);
-if (pci_device_read_rom(pInt-dev, vbiosMem) V_BIOS_SIZE) {
+if (pci_device_read_rom(pInt-dev, vbiosMem) != 0
+|| pInt-dev-rom_size V_BIOS_SIZE) {
xf86DrvMsg(pScrn-scrnIndex, X_WARNING,
Unable to retrieve all of segment 0x0C.\n);
}
--
1.7.10.4
___
xorg-de...@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614221: iMac-G3 fails to boot with 2.6.37-1-powerpc (Bug#614221)
I've been using radeon KMS on my PowerBook ever since I got it working initially about 1.5 years ago and fixing issues as time permits. The major outstanding issues I'm aware of are: * The uninorth AGP driver doesn't allow AGP transfer rates beyond 1x to work reliably with KMS. Benjamin Herrenschmidt (CC'd) was working on a fix for this, any progress Ben? * Come to think of it, the OFfb handover probably only works for me thanks to a patch drm/radeon: Add early unregister of firmware fb's by BenH. Ben/Dave, what's the status of that? That was merged in 2.6.37. * LVDS backlight control was only added for 2.6.38, and some concerns were raised about the prerequisite backlight infrastructure changes, so I'm not sure if it's staying in for 2.6.38 final. I've no idea where the backlight stuff ended up I think its sitting in akpm's tree due to requiring the other changes. * No suspend to RAM support yet. Suspend to disk seems to work though without AGP, I have some hackish fixes for it to work with AGP as well that I need to clean up and submit. * Various endianness issues in the Mesa drivers. Dave. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616301: xserver-xorg-video-radeon:screen goes black, system hangs after 2sec:[youtube(FF/Opera)-reset req.]
On Mon, Mar 7, 2011 at 4:36 AM, Ben Hutchings b...@decadent.org.uk wrote: On Sun, 2011-03-06 at 13:08 -0500, Alex Deucher wrote: On Fri, Mar 4, 2011 at 8:50 PM, Ben Hutchings b...@decadent.org.uk wrote: On Fri, 2011-03-04 at 21:01 +0200, Faidon Liambotis wrote: severity 616301 critical thanks No, not unless it will affect a large proportion of users. My system locks up whenever I click on a YouTube video link since yesterday. I can probably live without YouTube :), but in any case this shouldn't happen. This isn't a singled out case nor in exotic, possibly faulty, hardware. It's on a standard 1½-year old Dell OptiPlex 780 desktop with a Radeon HD card (one of the standard configurations) and this is on a stock squeeze system. The findings so far seem to suggest this is a Mesa issue; I'd probably file it under Linux kernel bugs (or even DoS bugs) but I'm not sure where to properly file such bugs in the post-KMS stack world. If there is a kernel driver involved then it should be assigned to the kernel. Even without KMS, a Mesa driver should be considered untrusted and should not be able to trigger a crash or hang. With KMS, this applies to the X driver too. With or without KMS, the userspace acceleration drivers can certainly cause GPU hangs if the 3D engine is programmed with some combination of commands it doesn't like. You can't solve the halting problem but you can implement a watchdog, can't you? We do, we reset the GPU 10s after it hangs, but this depends on a lot of things going our way. Occasionally we do reset the GPU when we shouldn't as well. However if there is an issue in the kernel, ddx or mesa driver, constants resets will pretty much DoS the GPU. Dave. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591061: Leak still present.
Proposed patch to remove leak attached.
Dave.
On Tue, Sep 28, 2010 at 6:42 PM, Eduardo I. persegui...@gmail.com wrote:
Hi Cyril, thanks for the heads up.
Unfortunately I still seem to be able to leak memory in the exact same
way. I'm reporting this back at RH's bugzilla.
I'm attaching ttm/drm related entries in vmallocinfo just in case.
--
Eduardo.
___
xorg-driver-ati mailing list
xorg-driver-...@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
From 086970d5b8371bc38d25bfc9b3a59328bce7a6f9 Mon Sep 17 00:00:00 2001
From: Dave Airlie airl...@redhat.com
Date: Wed, 29 Sep 2010 13:31:07 +1000
Subject: [PATCH] drm/ttm: remove race and optimise evicting destroyed buffers.
A race condition was identifed that led to a leak of the BOs, when
a bo was on the delayed delete list and was selected for eviction,
the code would enter
thread 1 (evict) -- thread2 (dd)
bo added to delayed destroy list
take lru lock
ttm_mem_evict_first called
- reserve locked
- remove from lru
- drop lru lock
take lru lock
try del from lru - get put_count == 0
try to reserve locked
- drop lru lock to wait unreserved
call bo_evict
unreserve buffer
- take lru lock
- add back to lru
- unreserver
- drop lru lock
take lru lock due to unreserved
unbind ttm
drop put_count references (which is 0)
despite being on the lru/swap lru lists.
leak due to never losing reference
The obvious quick fix is to try the bo from the ddestroy list if we
are going to evict it, however if we are going to evict a buffer that
is going to be destroyed we should just destroy it instead, its more
likely to be a lighter-weight operation than evict + delayed destroy.
This patch check is a bo that we are about to evict is actually on the
destroy list and if it is, it unreserves it (without adding to lru),
and cleans up its references. It should then get destroyed via
normal ref counting means.
proposed fix for:
https://bugzilla.redhat.com/show_bug.cgi?id=615505
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591061
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/ttm/ttm_bo.c | 18 +++---
1 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index cb4cf7e..60689b1 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -689,7 +689,7 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
struct ttm_mem_type_manager *man = bdev-man[mem_type];
struct ttm_buffer_object *bo;
int ret, put_count = 0;
-
+ bool destroy = false;
retry:
spin_lock(glob-lru_lock);
if (list_empty(man-lru)) {
@@ -719,6 +719,13 @@ retry:
}
put_count = ttm_bo_del_from_lru(bo);
+
+ /* is the buffer currently on the delayed destroy list? */
+ if (!list_empty(bo-ddestroy)) {
+ list_del_init(bo-ddestroy);
+ destroy = true;
+ put_count++;
+ }
spin_unlock(glob-lru_lock);
BUG_ON(ret != 0);
@@ -726,8 +733,13 @@ retry:
while (put_count--)
kref_put(bo-list_kref, ttm_bo_ref_bug);
- ret = ttm_bo_evict(bo, interruptible, no_wait_reserve, no_wait_gpu);
- ttm_bo_unreserve(bo);
+ if (destroy) {
+ atomic_set(bo-reserved, 0);
+ ret = ttm_bo_cleanup_refs(bo, !no_wait_gpu);
+ } else {
+ ret = ttm_bo_evict(bo, interruptible, no_wait_reserve, no_wait_gpu);
+ ttm_bo_unreserve(bo);
+ }
kref_put(bo-list_kref, ttm_bo_release_list);
return ret;
--
1.7.2.3
Bug#444223: xserver-xorg-video-ati: RS480 (radeon express X200G series): display goes to sleep after upgrade to latest unstable/sid
On 9/28/07, Junichi Uekawa [EMAIL PROTECTED] wrote: Hi, I've tried unstable and experimental versions, but the display goes to sleep after starting up X, and I see nothing. I can enter username / password in what is probably a gdm login screen, and I can hear disk activity, so I assume it starts and it thinks it's running. Is this a laptop? What outputs does it actually have and which are in use? It looks like it has a bogus connector table, or some sort of weird connector. As such the driver is probably lighting up the wrong output. This is a desktop PC, hp dx5150MT. It has DVI-out and D-sub analogue output; which DVI is connected to the display. It's most likely an external DVI chip, so maybe Alex can quirk it if you figure out the correct connector table. Dave. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439322: xserver-xorg-video-ati: xrandr does not detect VGA monitor
On 8/27/07, Marcus Better [EMAIL PROTECTED] wrote: Hi, there are no differences as far as I can see in version 6.7.192-1. The xrandr commands give me: ~$ xrandr --addmode VGA-0 1024x768 ~$ xrandr Screen 0: minimum 320 x 200, current 1024 x 768, maximum 2048 x 768 VGA-0 disconnected (normal left inverted right x axis y axis) 1024x768 60.0 LVDS connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1024x768 60.0*+ 800x60060.3 640x48059.9 S-video connected 800x600+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 800x60059.9*+ 60.3 ~$ xrandr --output VGA-0 --mode 1024x768 xrandr: cannot find crtc for output VGA-0 ~$ xrandr -v Server reports RandR version 1.2 But perhaps my xrandr version is too old. WIll 1.2.2 it be available in the archive anytime soon? it might worth trying to add an xrandr --output S-video --off Dave. Marcus ___ xorg-driver-ati mailing list [EMAIL PROTECTED] http://lists.x.org/mailman/listinfo/xorg-driver-ati -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392915: xserver-xorg-video-ati: xserver freezes system when starting
I'm not sure how this could happen though; can you also post the full kernel output, or at least everything related to AGP and the DRI? Sure. Attached are the entries from /var/log/messages that I believe matches the two Xorg log files. Below are the results of grep:ing for agp and drm. can you attach lspci -vv for both cases? Dave. 32 MB Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected VIA Apollo Pro 133 chipset agpgart: AGP aperture is 32M @ 0xfc00 [drm] Initialized drm 1.0.1 20051102 [drm] Initialized radeon 1.25.0 20060524 on minor 0 agpgart: Found an AGP 2.0 compliant device at :00:00.0. agpgart: Putting AGP V2 device at :00:00.0 into 1x mode agpgart: Putting AGP V2 device at :01:00.0 into 1x mode [drm] Setting GART location based on new memory map [drm] Loading R200 Microcode [drm] writeback test failed 128 MB Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected VIA Apollo Pro 133 chipset agpgart: AGP aperture is 128M @ 0xf000 [drm] Initialized drm 1.0.1 20051102 [drm] Initialized radeon 1.25.0 20060524 on minor 0 agpgart: Found an AGP 2.0 compliant device at :00:00.0. agpgart: Putting AGP V2 device at :00:00.0 into 1x mode agpgart: Putting AGP V2 device at :01:00.0 into 1x mode [drm] Setting GART location based on new memory map [drm] Loading R200 Microcode [drm] writeback test succeeded in 1 usecs -- Andreas Johansson[EMAIL PROTECTED] http://www.berget.nu/~andjo/ ___ Xorg-driver-ati mailing list [EMAIL PROTECTED] http://lists.x.org/mailman/listinfo/xorg-driver-ati -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#378594: Gatos patch for radeon TV out
I'm attaching an updated version of the Gatos patch [1] enabling radeon TV output for xserver-xorg-video-ati 6.6.3. It is far from perfect, but if you do as explained in the documentation, TV-out works, at least on my radeon 7500. Upstream is reluctant to apply it as it is doing nasty things, and as it isn't working at resolutions other than 800x600, but it is very helpful nevertheless. Upstream is reluctant as the code is under the GPL, and X.org code is generally released under the BSD license, I do not wish to have dual licenses in the ati package... Someone is looking into implementing this under the BSD license in a cleaner fashion in any case.. Dave. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374986: DRM deadlooping(?) with Radeon X800 GTO and X.org 7.0
Please test ATI video driver stable branch from xf86-video-ati
'ati-1-0-branch' from
git://git.freedesktop.org/git/xorg/driver/xf86-video-ati
This has a number of fixes necessary for some cards. If X only fails
occasionally that is unusual...
Dave.
Summary: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=374986
since 2.6.17-rcSomething X seems to fail at startup, hangs in a kind of
loop while doing
4582 rt_sigaction(SIGCHLD, {SIG_DFL}, {0x2b6d039cdd30, [INT RT_25],
SA_RESTORER|SA_INTERRUPT|SA_ONESHOT|0x31f25d8, 0x2b6d039cd9e8}, 8) = ?
ERESTARTNOINTR (To be restarted)
From what I can see, previous versions did not support my card at all
while in the current, /dev/dri* seems to be opened successfully before
the problem occurs:
4555 write(0, drmOpenByBusid: Searching for Bu..., 53) = 53
4555 geteuid() = 0
4555 write(0, drmOpenDevice: node name is /dev..., 43) = 43
4555 stat(/dev/dri, {st_mode=S_IFDIR|0755, st_size=40, ...}) = 0
4555 stat(/dev/dri/card0, 0x7fff6e5857f0) = -1 ENOENT (No such file or
directory)
4555 unlink(/dev/dri/card0) = -1 ENOENT (No such file or directory)
4555 mknod(/dev/dri/card0, S_IFCHR|0666, makedev(226, 0)) = 0
4555 chown(/dev/dri/card0, 0, 0) = 0
4555 chmod(/dev/dri/card0, 0666) = 0
4555 open(/dev/dri/card0, O_RDWR)= 7
It does not fail if dri X module is not loaded.
Ok, tried that. Compiled, packages created, installed, uncommented dri
module in xorg, restarted X - got deadloop as usual :-(
I'm afraid there's been a misunderstanding; Mesa is only involved when
starting a 3D application, so it's not relevant to your original
problem. As I pointed out before, Robert is seeing a different problem.
One thing you have in common though is that you should report your
problems upstream. :)
Eduard, if you still feel adventurous, you could try current
xf86-video-ati git as well. Maybe there have been other changes that
helped r300 DRI stability.
I fetched this one: git clone
git://anongit.freedesktop.org/git/mesa/drm.git/ mesa
and installed compiled libs over the libs from the Debian package. Has
not changed anything, unfortunately.
Eduard.
--
Myon TV ist Zeitverschwendung
* micsch muss auch nochmal seine TV-Karte einbauen
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
