Add a cast here to silence a Gcc warning.
drivers/gpu/drm/gma500/mid_bios.c:214:28: warning:
cast from pointer to integer of different size [-Wpointer-to-int-cast]
Signed-off-by: Dan Carpenter
---
Compile tested only.
diff --git a/drivers/gpu/drm/gma500/mid_bios.c
b/drivers/gpu/drm/gma500/mid
From: Michel Dänzer
It can be the case e.g. when switching to console for panic output.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43941
Signed-off-by: Michel Dänzer
---
v2: Still call msleep() in the normal case. Only compile tested.
drivers/gpu/drm/radeon/atom.c |2 ++
1 f
On Die, 2012-01-03 at 21:04 +0100, Daniel Vetter wrote:
> On Tue, Jan 03, 2012 at 07:16:25PM +0100, Michel Dänzer wrote:
> > On Die, 2012-01-03 at 18:09 +, Dave Airlie wrote:
> > > 2012/1/3 Michel Dänzer :
> > > > From: Michel Dänzer
> > > >
> > > > It can be called from atomic context, e.g.
On Mit, 2012-01-04 at 00:52 +, Alan Cox wrote:
> On Tue, 03 Jan 2012 19:25:46 +0100
> Michel Dänzer wrote:
> > On Die, 2012-01-03 at 18:09 +, Alan Cox wrote:
> > > On Tue, 3 Jan 2012 19:04:00 +0100
> > > Michel Dänzer wrote:
> > >
> > > > From: Michel Dänzer
> > > >
> > > > It can b
On Wed, Jan 04, 2012 at 11:33:40AM +0100, Michel Dänzer wrote:
> From: Michel Dänzer
>
> It can be the case e.g. when switching to console for panic output.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43941
>
> Signed-off-by: Michel Dänzer
> ---
>
> v2: Still call msleep() in t
> > So lets stick to practice, and the real world. Screwing up everything
> > else because of a crappy problem in your Atom BIOS code sucks but hey it
> > happens. screwing up everything because of a theoretical concern is just
> > dumb.
>
> Thanks for the flowers, but it's not just a theoretical
On Mit, 2012-01-04 at 11:54 +0100, Daniel Vetter wrote:
> On Wed, Jan 04, 2012 at 11:33:40AM +0100, Michel Dänzer wrote:
> > From: Michel Dänzer
> >
> > It can be the case e.g. when switching to console for panic output.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43941
> >
On Wed, 4 Jan 2012 10:26:10 +0300
Dan Carpenter wrote:
> Add a cast here to silence a Gcc warning.
> drivers/gpu/drm/gma500/mid_bios.c:214:28: warning:
> cast from pointer to integer of different size
> [-Wpointer-to-int-cast]
>
> Signed-off-by: Dan Carpenter
> ---
> Compile tested only.
It'
On Wed, Jan 04, 2012 at 12:29:24PM +0100, Michel Dänzer wrote:
> On Mit, 2012-01-04 at 11:54 +0100, Daniel Vetter wrote:
> > On Wed, Jan 04, 2012 at 11:33:40AM +0100, Michel Dänzer wrote:
> > > From: Michel Dänzer
> > >
> > > It can be the case e.g. when switching to console for panic output.
>
On Mit, 2012-01-04 at 12:44 +0100, Daniel Vetter wrote:
> On Wed, Jan 04, 2012 at 12:29:24PM +0100, Michel Dänzer wrote:
> > On Mit, 2012-01-04 at 11:54 +0100, Daniel Vetter wrote:
> > > On Wed, Jan 04, 2012 at 11:33:40AM +0100, Michel Dänzer wrote:
> > > > From: Michel Dänzer
> > > >
> > > > I
https://bugs.freedesktop.org/show_bug.cgi?id=43719
--- Comment #3 from Andy Furniss 2012-01-04
03:53:20 PST ---
(In reply to comment #2)
> Created attachment 55095 [details] [review]
> Fix agp on top of ttm tt rework
>
> Should fix the bug let me know
Yes, this fixes it.
--
Configure bugmail
2012/1/4 Alan Cox :
>> > So lets stick to practice, and the real world. Screwing up everything
>> > else because of a crappy problem in your Atom BIOS code sucks but hey it
>> > happens. screwing up everything because of a theoretical concern is just
>> > dumb.
>>
>> Thanks for the flowers, but it'
> I think Alan's simply wrong.
In what way ? You stated this, then go on below to say what I did ?
> Splattering the entire driver for
> these two corner cases which don't happen at all under normal
> circumstances is imho utter nonsense.
Which is what I said
| > > Is this only special cases li
> Every modesetting operation can happen in atomic context or not in
> atomic context, thanks to the wonder of oops printing and also kgdb,
> trying to figure out which table in this one person's bios is the
> "root" cause and special casing for it is insane since tomorrow 20
> other BIOSes could c
On Wed, Jan 04, 2012 at 12:09:36PM +, Alan Cox wrote:
> > I think Alan's simply wrong.
>
> In what way ? You stated this, then go on below to say what I did ?
>
> > Splattering the entire driver for
> > these two corner cases which don't happen at all under normal
> > circumstances is imho ut
On Wed, Jan 04, 2012 at 12:09:36PM +, Alan Cox wrote:
> > I think Alan's simply wrong.
>
> In what way ? You stated this, then go on below to say what I did ?
>
> > Splattering the entire driver for
> > these two corner cases which don't happen at all under normal
> > circumstances is imho ut
https://bugs.freedesktop.org/show_bug.cgi?id=24215
Johannes Obermayr changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=36037
Johannes Obermayr changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=24861
Johannes Obermayr changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
> unnusual contexts). I'm not sure whether your proposed instrumentation is
> really worth it though - in i915-land we don't bother with this. But maybe
In i915 land it's specific code paths so effectively it is marked up. We
don't do it for every random delay in all the connectors and other bits.
On Wed, Jan 04, 2012 at 01:28:28PM +, Alan Cox wrote:
> > unnusual contexts). I'm not sure whether your proposed instrumentation is
> > really worth it though - in i915-land we don't bother with this. But maybe
>
> In i915 land it's specific code paths so effectively it is marked up. We
> don'
> Well, hotplug is alreay a giant pain because of the single lock to rule
> them all design of the current kms code: Long delays already stall
> everything else (well, cursor updates and pageflips) and we have tons of
Yes I hit this with the gma500, it's one reason I did the GTT based
scrolling.
https://bugs.freedesktop.org/show_bug.cgi?id=44130
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
> Attached is patch to fix this, so sorry about that, i must have lost my
> agp change along the way when working on the patchset. This patch is not
> extensively tested, i will do more testing tomorrow on more gpu, might
> even found an nvidia agp i can try. Again sorry for breaking this.
Thanks
On Wed, Jan 4, 2012 at 10:36 AM, James Simmons wrote:
>
>> Attached is patch to fix this, so sorry about that, i must have lost my
>> agp change along the way when working on the patchset. This patch is not
>> extensively tested, i will do more testing tomorrow on more gpu, might
>> even found an
> >> Attached is patch to fix this, so sorry about that, i must have lost my
> >> agp change along the way when working on the patchset. This patch is not
> >> extensively tested, i will do more testing tomorrow on more gpu, might
> >> even found an nvidia agp i can try. Again sorry for breaking t
On Wed, Jan 4, 2012 at 11:04 AM, James Simmons wrote:
>
>> >> Attached is patch to fix this, so sorry about that, i must have lost my
>> >> agp change along the way when working on the patchset. This patch is not
>> >> extensively tested, i will do more testing tomorrow on more gpu, might
>> >> ev
On Tue, 2011-12-27 at 12:06 -0500, Joel Sass wrote:
> --- ./intel_lvds.old2011-12-20 13:25:49.368291249 -0500
> +++ ./intel_lvds.c2011-12-20 13:26:05.160291248 -0500
> @@ -709,6 +709,14 @@
> },
> {
> .callback = intel_no_lvds_dmi_callback,
> +.ident = "Clientr
Hello,
I've been directed here by Stephane Graber. I need to blacklist the LVDS
port on some hp t5745 thin client.
Here is the bug link:
https://bugs.launchpad.net/bugs/911916
And i attached the following patch to this bug:
--- linux-3.2.0/drivers/gpu/drm/i915/intel_lvds.c 2011-12-24
10:23:08
Hello,
I've been directed here by Stephane Graber. I need to blacklist the LVDS
port on hp st5747 thin client.
Here is the bug link:
https://bugs.launchpad.net/bugs/911920
And i attached the following patch to this bug:
--- linux-3.2.0/drivers/gpu/drm/i915/intel_lvds.c 2011-12-24
10:23:08.000
On Wed, 2012-01-04 at 14:08 -0500, Marc Gariépy wrote:
> Hello,
>
> I've been directed here by Stephane Graber. I need to blacklist the
> LVDS port on some hp t5745 thin client.
>
> Here is the bug link:
> https://bugs.launchpad.net/bugs/911916
Does this actually work? The bug above doesn't inc
This reverts commit 5c2680ddbe14b24771d24841dd66881f90d3d740 otherwise
when we unbind the device we get this:
sh-4.1# echo ":00:0d.0" > unbind
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [] []
nouveau_bo_move_ntfy+0x1d/0xc0 [nouveau]
RSP: 0018:88012deb
The code to figure out how many pages to shrink the pool
ends up capping the 'count' at _manager->options.max_size - which is OK.
Except that the 'count' is also used when accounting for how many pages
are recycled - which we end up with the invalid values. This fixes
it by using a different value
Otherwise we are doing redundant work. Especially since the 'unbind'
and 'unpopulate' have been merged and nouveau driver ends up calling
it quite excessivly. On a GeForce 8600 GT with Gnome Shell (GNOME 3)
we end up spending about 54% CPU time in __change_page_attr_set_clr
checking the page flags.
When I was debugging some DMA API accounting error (which were found to be
with the DMA API debug code), I encountered a couple of issues:
1). Doing "unbind" on the PCI device would crash the kernel _only_ with the
nouveau driver. The readon worked fine. This was due to:
"drm/ttm: callb
https://bugs.freedesktop.org/show_bug.cgi?id=44466
Bug #: 44466
Summary: Assertion 'LLVMOffsetOfElement' when running Furmark
with wine
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
Sorry for the mistake, i made a typo when correcting the indentation issue
i had.
here is the correct patch and also the dmidecode from the thin client.
--- linux-3.2.0/drivers/gpu/drm/i915/intel_lvds.c 2011-12-24
10:23:08.0 -0500
+++ intel_lvds.c2012-01-04 14:03:49.134573275 -0500
@
https://bugs.freedesktop.org/show_bug.cgi?id=44466
--- Comment #1 from Laurent carlier 2012-01-04 15:03:09
PST ---
It doesn't assert with DRAW_USE_LLVM=0
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=44466
--- Comment #2 from Laurent carlier 2012-01-04 15:07:14
UTC ---
...mesa-7.11.2 seem also to be affected by this bug
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
https://bugs.freedesktop.org/show_bug.cgi?id=39782
--- Comment #9 from Chris Rankin 2012-01-04 15:35:06
PST ---
The following commit does not resolve this bug:
commit 7b181d16c3b954bf567563e90e5e94bda833fab8
Author: Christian König
Date: Wed Jan 4 15:59:29 2012 +0100
vl/mpeg2: simple fi
Here are the rest of the 3.3 pending changes.
This has a bunch of small bug fixes and overlay plane support for i915.
The following changes since commit 7a7e8734ac3235efafd34819b27fbdf5417e6d60:
Merge branch 'drm-radeon-testing' of ../drm-radeon-next into drm-core-next
(2012-01-03 09:45:12 +
note: looks like I need to rebase this patch after exynos drm driver
was pulled to drm-next.. if there are some other consumers that are
waiting to be pulled, let me know and I'll just rebase on top of that.
(Either way, it would be a trivial merge conflict.. just add FALSE as
additional arg to dr
On 01/04/2012 12:37 AM, Alex Deucher wrote:
On Tue, Jan 3, 2012 at 6:12 PM, Helge Deller wrote:
On 01/03/2012 03:27 PM, Alex Deucher wrote:
On Mon, Jan 2, 2012 at 5:07 PM, Helge Dellerwrote:
I'm facing the problem with the radeon drm driver, that I now manually
need
to set the kernel mo
Samuel Thibault, le Fri 16 Sep 2011 18:30:50 +0200, a écrit :
> Keith Packard, le Thu 15 Sep 2011 09:22:48 -0500, a écrit :
> > On Thu, 15 Sep 2011 10:12:59 +0200, Samuel Thibault
> > wrote:
> >
> > > At home only. At work, with a different VGA screen, I'm still getting
> > > the issue.
> >
> >
On Tue, 03 Jan 2012 19:25:46 +0100
Michel D?nzer wrote:
> On Die, 2012-01-03 at 18:09 +, Alan Cox wrote:
> > On Tue, 3 Jan 2012 19:04:00 +0100
> > Michel D?nzer wrote:
> >
> > > From: Michel D?nzer
> > >
> > > It can be called from atomic context, e.g. when switching to console for
> >
On 01/03/2012 03:27 PM, Alex Deucher wrote:
> On Mon, Jan 2, 2012 at 5:07 PM, Helge Deller wrote:
>> I'm facing the problem with the radeon drm driver, that I now manually need
>> to set the kernel module parameter radeon.no_wb to 1 at bootup, else X just
>> hangs in average up to 8 seconds per mi
calc_mclk() returns zero on success and negative on failure but clk is
a u32.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/nouveau/nv50_pm.c
b/drivers/gpu/drm/nouveau/nv50_pm.c
index 0393721..3508de9 100644
--- a/drivers/gpu/drm/nouveau/nv50_pm.c
+++ b/drivers/gpu/drm/nouveau/nv50_
Add a cast here to silence a Gcc warning.
drivers/gpu/drm/gma500/mid_bios.c:214:28: warning:
cast from pointer to integer of different size [-Wpointer-to-int-cast]
Signed-off-by: Dan Carpenter
---
Compile tested only.
diff --git a/drivers/gpu/drm/gma500/mid_bios.c
b/drivers/gpu/drm/gma500/mid
From: Michel D?nzer
It can be the case e.g. when switching to console for panic output.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43941
Signed-off-by: Michel D?nzer
---
v2: Still call msleep() in the normal case. Only compile tested.
drivers/gpu/drm/radeon/atom.c |2 ++
1 f
On Die, 2012-01-03 at 21:04 +0100, Daniel Vetter wrote:
> On Tue, Jan 03, 2012 at 07:16:25PM +0100, Michel D?nzer wrote:
> > On Die, 2012-01-03 at 18:09 +, Dave Airlie wrote:
> > > 2012/1/3 Michel D?nzer :
> > > > From: Michel D?nzer
> > > >
> > > > It can be called from atomic context, e.g.
On Mit, 2012-01-04 at 00:52 +, Alan Cox wrote:
> On Tue, 03 Jan 2012 19:25:46 +0100
> Michel D?nzer wrote:
> > On Die, 2012-01-03 at 18:09 +, Alan Cox wrote:
> > > On Tue, 3 Jan 2012 19:04:00 +0100
> > > Michel D?nzer wrote:
> > >
> > > > From: Michel D?nzer
> > > >
> > > > It can b
On Wed, Jan 04, 2012 at 11:33:40AM +0100, Michel D?nzer wrote:
> From: Michel D?nzer
>
> It can be the case e.g. when switching to console for panic output.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43941
>
> Signed-off-by: Michel D?nzer
> ---
>
> v2: Still call msleep() in t
> > So lets stick to practice, and the real world. Screwing up everything
> > else because of a crappy problem in your Atom BIOS code sucks but hey it
> > happens. screwing up everything because of a theoretical concern is just
> > dumb.
>
> Thanks for the flowers, but it's not just a theoretical
On Mit, 2012-01-04 at 11:54 +0100, Daniel Vetter wrote:
> On Wed, Jan 04, 2012 at 11:33:40AM +0100, Michel D?nzer wrote:
> > From: Michel D?nzer
> >
> > It can be the case e.g. when switching to console for panic output.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43941
> >
On Wed, 4 Jan 2012 10:26:10 +0300
Dan Carpenter wrote:
> Add a cast here to silence a Gcc warning.
> drivers/gpu/drm/gma500/mid_bios.c:214:28: warning:
> cast from pointer to integer of different size
> [-Wpointer-to-int-cast]
>
> Signed-off-by: Dan Carpenter
> ---
> Compile tested only.
It'
On Wed, Jan 04, 2012 at 12:29:24PM +0100, Michel D?nzer wrote:
> On Mit, 2012-01-04 at 11:54 +0100, Daniel Vetter wrote:
> > On Wed, Jan 04, 2012 at 11:33:40AM +0100, Michel D?nzer wrote:
> > > From: Michel D?nzer
> > >
> > > It can be the case e.g. when switching to console for panic output.
>
On Mit, 2012-01-04 at 12:44 +0100, Daniel Vetter wrote:
> On Wed, Jan 04, 2012 at 12:29:24PM +0100, Michel D?nzer wrote:
> > On Mit, 2012-01-04 at 11:54 +0100, Daniel Vetter wrote:
> > > On Wed, Jan 04, 2012 at 11:33:40AM +0100, Michel D?nzer wrote:
> > > > From: Michel D?nzer
> > > >
> > > > I
https://bugs.freedesktop.org/show_bug.cgi?id=43719
--- Comment #3 from Andy Furniss 2012-01-04
03:53:20 PST ---
(In reply to comment #2)
> Created attachment 55095 [details] [review]
> Fix agp on top of ttm tt rework
>
> Should fix the bug let me know
Yes, this fixes it.
--
Configure bugmail
2012/1/4 Alan Cox :
>> > So lets stick to practice, and the real world. Screwing up everything
>> > else because of a crappy problem in your Atom BIOS code sucks but hey it
>> > happens. screwing up everything because of a theoretical concern is just
>> > dumb.
>>
>> Thanks for the flowers, but it'
> I think Alan's simply wrong.
In what way ? You stated this, then go on below to say what I did ?
> Splattering the entire driver for
> these two corner cases which don't happen at all under normal
> circumstances is imho utter nonsense.
Which is what I said
| > > Is this only special cases li
> Every modesetting operation can happen in atomic context or not in
> atomic context, thanks to the wonder of oops printing and also kgdb,
> trying to figure out which table in this one person's bios is the
> "root" cause and special casing for it is insane since tomorrow 20
> other BIOSes could c
On Wed, Jan 04, 2012 at 12:09:36PM +, Alan Cox wrote:
> > I think Alan's simply wrong.
>
> In what way ? You stated this, then go on below to say what I did ?
>
> > Splattering the entire driver for
> > these two corner cases which don't happen at all under normal
> > circumstances is imho ut
On Wed, Jan 04, 2012 at 12:09:36PM +, Alan Cox wrote:
> > I think Alan's simply wrong.
>
> In what way ? You stated this, then go on below to say what I did ?
>
> > Splattering the entire driver for
> > these two corner cases which don't happen at all under normal
> > circumstances is imho ut
https://bugs.freedesktop.org/show_bug.cgi?id=24215
Johannes Obermayr changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=36037
Johannes Obermayr changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=24861
Johannes Obermayr changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
> unnusual contexts). I'm not sure whether your proposed instrumentation is
> really worth it though - in i915-land we don't bother with this. But maybe
In i915 land it's specific code paths so effectively it is marked up. We
don't do it for every random delay in all the connectors and other bits.
On Wed, Jan 04, 2012 at 01:28:28PM +, Alan Cox wrote:
> > unnusual contexts). I'm not sure whether your proposed instrumentation is
> > really worth it though - in i915-land we don't bother with this. But maybe
>
> In i915 land it's specific code paths so effectively it is marked up. We
> don'
> Well, hotplug is alreay a giant pain because of the single lock to rule
> them all design of the current kms code: Long delays already stall
> everything else (well, cursor updates and pageflips) and we have tons of
Yes I hit this with the gma500, it's one reason I did the GTT based
scrolling.
https://bugs.freedesktop.org/show_bug.cgi?id=44130
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
> Attached is patch to fix this, so sorry about that, i must have lost my
> agp change along the way when working on the patchset. This patch is not
> extensively tested, i will do more testing tomorrow on more gpu, might
> even found an nvidia agp i can try. Again sorry for breaking this.
Thanks
On Wed, Jan 4, 2012 at 10:36 AM, James Simmons
wrote:
>
>> Attached is patch to fix this, so sorry about that, i must have lost my
>> agp change along the way when working on the patchset. This patch is not
>> extensively tested, i will do more testing tomorrow on more gpu, might
>> even found an
> >> Attached is patch to fix this, so sorry about that, i must have lost my
> >> agp change along the way when working on the patchset. This patch is not
> >> extensively tested, i will do more testing tomorrow on more gpu, might
> >> even found an nvidia agp i can try. Again sorry for breaking t
On Wed, Jan 4, 2012 at 11:04 AM, James Simmons
wrote:
>
>> >> Attached is patch to fix this, so sorry about that, i must have lost my
>> >> agp change along the way when working on the patchset. This patch is not
>> >> extensively tested, i will do more testing tomorrow on more gpu, might
>> >> e
ble
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120104/21e8d9da/attachment.pgp>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120104/e1ebb422/attachment.htm>
;http://lists.freedesktop.org/archives/dri-devel/attachments/20120104/e1af1645/attachment.html>
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120104/473e28c1/attachment.pgp>
This reverts commit 5c2680ddbe14b24771d24841dd66881f90d3d740 otherwise
when we unbind the device we get this:
sh-4.1# echo ":00:0d.0" > unbind
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [] []
nouveau_bo_move_ntfy+0x1d/0xc0 [nouveau]
RSP: 0018:88012deb
The code to figure out how many pages to shrink the pool
ends up capping the 'count' at _manager->options.max_size - which is OK.
Except that the 'count' is also used when accounting for how many pages
are recycled - which we end up with the invalid values. This fixes
it by using a different value
Otherwise we are doing redundant work. Especially since the 'unbind'
and 'unpopulate' have been merged and nouveau driver ends up calling
it quite excessivly. On a GeForce 8600 GT with Gnome Shell (GNOME 3)
we end up spending about 54% CPU time in __change_page_attr_set_clr
checking the page flags.
When I was debugging some DMA API accounting error (which were found to be
with the DMA API debug code), I encountered a couple of issues:
1). Doing "unbind" on the PCI device would crash the kernel _only_ with the
nouveau driver. The readon worked fine. This was due to:
"drm/ttm: callb
https://bugs.freedesktop.org/show_bug.cgi?id=44466
Bug #: 44466
Summary: Assertion 'LLVMOffsetOfElement' when running Furmark
with wine
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
t; > + DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
> > + DMI_MATCH(DMI_BOARD_NAME, "hp st5745"),
>
> I would normally expect HP to capitalize their own name correctly.
>
> - ajax
>
-- next part --
An HTM
https://bugs.freedesktop.org/show_bug.cgi?id=44466
--- Comment #1 from Laurent carlier 2012-01-04
15:03:09 PST ---
It doesn't assert with DRAW_USE_LLVM=0
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=44466
--- Comment #2 from Laurent carlier 2012-01-04
15:07:14 UTC ---
...mesa-7.11.2 seem also to be affected by this bug
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
cklist when testing your code ***
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: config-r3641
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120104/699344fa/attachment.asc>
https://bugs.freedesktop.org/show_bug.cgi?id=39782
--- Comment #9 from Chris Rankin 2012-01-04
15:35:06 PST ---
The following commit does not resolve this bug:
commit 7b181d16c3b954bf567563e90e5e94bda833fab8
Author: Christian K?nig
Date: Wed Jan 4 15:59:29 2012 +0100
vl/mpeg2: simple fi
signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120104/54c1f1e6/attachment.pgp>
note: looks like I need to rebase this patch after exynos drm driver
was pulled to drm-next.. if there are some other consumers that are
waiting to be pulled, let me know and I'll just rebase on top of that.
(Either way, it would be a trivial merge conflict.. just add FALSE as
additional arg to dr
On 01/04/2012 12:37 AM, Alex Deucher wrote:
> On Tue, Jan 3, 2012 at 6:12 PM, Helge Deller wrote:
>> On 01/03/2012 03:27 PM, Alex Deucher wrote:
>>>
>>> On Mon, Jan 2, 2012 at 5:07 PM, Helge Dellerwrote:
I'm facing the problem with the radeon drm driver, that I now manually
need
calc_mclk() returns zero on success and negative on failure but clk is
a u32.
v2: Martin Peres:
- clk should be an int, not a u32
Signed-off-by: Martin Peres
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/nouveau/nv50_pm.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff -
92 matches
Mail list logo
