http://bugs.freedesktop.org/show_bug.cgi?id=25662
--- Comment #9 from Tom Stellard 2010-03-19 23:10:46 PST
---
Created an attachment (id=34250)
--> (http://bugs.freedesktop.org/attachment.cgi?id=34250)
lspci output.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=ema
http://bugs.freedesktop.org/show_bug.cgi?id=25662
--- Comment #8 from Tom Stellard 2010-03-19 23:09:38 PST
---
Here are the results from git bisect:
Starting with the 2.6.31 kernel, KMS works fine until this commit:
3e5cb98dfe87cc61d0a1119dd8aa2b1e4cfab424
After this commit, xdm freezes at
http://bugs.freedesktop.org/show_bug.cgi?id=14099
Corbin Simpson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://bugs.freedesktop.org/show_bug.cgi?id=21650
--- Comment #2 from Corbin Simpson 2010-03-19
16:44:05 PST ---
Is this still a problem with current master kernel, libdrm, and xf86-video-ati?
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are recei
http://bugs.freedesktop.org/show_bug.cgi?id=25746
Corbin Simpson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://bugs.freedesktop.org/show_bug.cgi?id=26123
Corbin Simpson changed:
What|Removed |Added
CC||mostawesomed...@gmail.com
S
On Fri, 19 Mar 2010 13:53:10 -0700
Eric Anholt wrote:
> On Fri, 19 Mar 2010 12:53:20 -0700, Jesse Barnes
> wrote:
> > On Mon, 15 Mar 2010 21:32:41 +0200
> > Surbhi Palande wrote:
> >
> > > The following two patches are quirks that blacklist bios which report
> > > incorrect lid status. These
On Fri, 19 Mar 2010 12:53:20 -0700, Jesse Barnes
wrote:
> On Mon, 15 Mar 2010 21:32:41 +0200
> Surbhi Palande wrote:
>
> > The following two patches are quirks that blacklist bios which report
> > incorrect lid status. These are bioses for machines with a 900 GM.
> > The first one is tested by
On Mon, 15 Mar 2010 21:32:41 +0200
Surbhi Palande wrote:
> The following two patches are quirks that blacklist bios which report
> incorrect lid status. These are bioses for machines with a 900 GM.
> The first one is tested by Ubuntu users and the second one isn't.
> Further testing will be appre
Pauli Nieminen wrote:
> 2010/3/19 Thomas Hellström :
>
>> Pauli, Dave and Jerome,
>>
>> Before reviewing this, Could you describe a bit how this interfaces with the
>> TTM memory accounting. It's important for some systems to be able to set a
>> limit beyond which TTM may not pin any pages.
>>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nicolai Haehnle wrote:
> On Thu, Mar 18, 2010 at 5:38 PM, Luc Verhaegen wrote:
>> So, identify the volatile interfaces, and the more stable interfaces,
>> and then isolate the volatile ones, and then you come to only one
>> conclusion.
>
> Except tha
> It may seem e.g. like the DRM interface is the worst because of rather large
> threads caused by certain kernel developer's problems, but that doesn't mean
> problems wouldn't be created by splitting other areas.
This would probably be best solved by merging libdrm into the Linux kernel tree.
Pulling drm back out of the kernel tree seems like a hard sell, but the
ddx/mesa hw driver/libdrm set seemed like it might be a good candidate for
grouping.
I guess the core question is whether we expect the X-to-ddx and
mesa-to-hw-driver interfaces to be more or less volatile than the ddx-to-
Hi Marek,
indeed the patch you recommended is fixing the red-ish effect with
mesa 7.8 GIT branch!
r300g: remove hacks from translate_vertex_data_swizzle
"commit 821c830f11fc1c3529a186ace1d1ba3ddeab4957"
Feel free to apply to 7.8 GIT.
IIRC with Dave's screen/winsys rework I had no problems, but
On Thu, Mar 18, 2010 at 5:38 PM, Luc Verhaegen wrote:
> So, identify the volatile interfaces, and the more stable interfaces,
> and then isolate the volatile ones, and then you come to only one
> conclusion.
Except that the Mesa core <-> classic driver interface also wants to
change from time to
Hi there,
I'm referring to my Bugreport 15473.
I wanted to use KMS with the latest kernel on my Sony VGN-BZ12VN.
Similiar to Bug 14649 and 14554 `cat /proc/acpi/button/lid/LID0/state`
always reports "state: closed" to me.
A blank screen is the result for me, when booting with KMS enabled.
I fig
From: Randy Dunlap
vmwfgx uses framebuffer interfaces, so it should depend on FB.
Otherwise it has these build errors (e.g., when CONFIG_FB=m):
drivers/built-in.o: In function `vmw_fb_close':
(.text+0x97713): undefined reference to `unregister_framebuffer'
drivers/built-in.o: In function `vmw_fb
http://bugs.freedesktop.org/show_bug.cgi?id=27199
--- Comment #3 from Chris Rankin 2010-03-19 08:48:58
PST ---
Created an attachment (id=34245)
--> (http://bugs.freedesktop.org/attachment.cgi?id=34245)
WoW screenshot, showing lots of artifacts
These artifacts may be a completely different
http://bugs.freedesktop.org/show_bug.cgi?id=27199
--- Comment #2 from Chris Rankin 2010-03-19 08:25:16
PST ---
This crash stopped happening after I added the following hack:
--- a/src/mesa/drivers/dri/r300/r300_cmdbuf.c
+++ b/src/mesa/drivers/dri/r300/r300_cmdbuf.c
@@ -424,7 +424,7 @@ stat
http://bugs.freedesktop.org/show_bug.cgi?id=27199
--- Comment #1 from Chris Rankin 2010-03-19 07:47:07
PST ---
This bus is also present in F12's Mesa 7.7-4 packages.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
http://bugs.freedesktop.org/show_bug.cgi?id=25662
--- Comment #7 from Alex Deucher 2010-03-19 07:43:26 PST ---
(In reply to comment #5)
> I'm not sure if this is a different issue or the same. Behavior looks similar
> and it's the same chipset family I think. We had used KMS already for a w
http://bugs.freedesktop.org/show_bug.cgi?id=25662
--- Comment #6 from Alex Deucher 2010-03-19 07:42:33 PST ---
Do things work any better with a newer drm? 2.3.33/4 or Dave's
drm-radeon-testing branch
(http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=refs/heads/drm-
http://bugs.freedesktop.org/show_bug.cgi?id=27199
Chris Rankin changed:
What|Removed |Added
Attachment #34243|Full stack |Full WoW output, including
descrip
http://bugs.freedesktop.org/show_bug.cgi?id=27199
Summary: Division by Zero error with glDrawRangeElementsEXT()
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Pr
On Fri, Mar 19, 2010 at 11:36 AM, Sedat Dilek wrote:
> Hi,
>
> the last days I was testing Alex Deucher's power-management-2 patches
> for radeon OSS driver.
>
> While testing I saw that especially r300g dri/statetracker with
> OpenArena have problems with mesa 7.8/master GIT branch.
> Mesa r300 "
2010/3/19 Thomas Hellström :
> Pauli, Dave and Jerome,
>
> Before reviewing this, Could you describe a bit how this interfaces with the
> TTM memory accounting. It's important for some systems to be able to set a
> limit beyond which TTM may not pin any pages.
>
> Am I right in assuming that TTM me
Hi,
the last days I was testing Alex Deucher's power-management-2 patches
for radeon OSS driver.
While testing I saw that especially r300g dri/statetracker with
OpenArena have problems with mesa 7.8/master GIT branch.
Mesa r300 "classic" (KMS/DRI2) is working fine here on RV515.
7.8 GIT:
Scenes
http://bugs.freedesktop.org/show_bug.cgi?id=25179
Fabio Pedretti changed:
What|Removed |Added
Summary|File radeon_dma.c function |[DRI1] File radeon_dma.c
When there is allocation failure in radeon_cs_parser_relocs parser->nrelocs
is not cleaned. This causes NULL pointer defeference in radeon_cs_parser_fini
when clean up code is trying to loop over the relocation array and free the
objects.
Fix adds a check for a possible NULL pointer in clean up co
29 matches
Mail list logo
