On Mon, 23 Aug 2010 15:17:08 -0600, Jonathan Corbet wrote:
> I went ahead and bisected the problem, which was added between -rc1 and
> -rc2. The end result is this:
Taking the patch at face value, the cause should be a mistake in error
handling. So the first step would be to identify which i2c_t
There's no point in jumping through two indirections. So kill one
and call the kernels agp functions directly.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_agpsupport.c | 40 +++--
drivers/gpu/drm/drm_memory.c | 12 ++
include/drm/drmP.h
No caller (rightly) cares about it, so drop it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_memory.c |4 ++--
include/drm/drmP.h |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_memory.c b/drivers/gpu/drm/drm_memory.c
index 7732
Only used by ioctl, not by any in-tree drivers.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_lock.c | 10 +++---
include/drm/drmP.h |1 -
2 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
index 1973d75
Not used by any current driver.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem.c |4 +---
include/drm/drmP.h|1 -
2 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index bf92d07..cff7317 100644
--- a/dri
Totally unused.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c |2 --
drivers/gpu/drm/drm_stub.c |1 -
include/drm/drmP.h |1 -
3 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index a35a410..5ff
The information supplied by userspace through these ioctls is only
accessible by dev->drw_idr. But there's no in-tree user of that.
Also userspace does not really care about return values of these ioctls,
either. Only hw/xfree86/dri/dri.c from the xserver actually checks the
return from adddraw and
Not used by any in-tree user. So drop it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drawable.c |3 +--
include/drm/drmP.h |2 --
2 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_drawable.c b/drivers/gpu/drm/drm_drawable.c
index c53
It's not used by any driver. The destructor callback is unfortunately
used by the via driver in a rather convoluted piece of code used
to reimplement something resembling broken futexes. I didn't dare
to touch this code. But at least kill the needless NULL assignemt
in the sis driver.
Signed-off-b
Every driver used the default implementation. Fold that one into
the only callsite and drop the callback.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_vm.c |6 ++
drivers/gpu/drm/i810/i810_drv.c |1 -
drivers/gpu/drm/i830/i830_drv.c |1 -
drivers/
All drivers happily copy&pasted the default implementation without
checking whether this callback is used at all. It's not. Sigh.
Kill it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_vm.c |7 ---
drivers/gpu/drm/i810/i810_drv.c |1 -
drivers/gpu/drm/i830/
Not used by any driver (rightly so!). Kill them.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_proc.c | 13 -
include/drm/drmP.h |2 --
2 files changed, 0 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_proc.c b/drivers/gpu/drm/drm_proc.c
index a
Not used by any driver. So drop it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_lock.c |3 ---
include/drm/drmP.h |1 -
2 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
index 566d203..1973d75 100644
--
Not used by any in-kernel driver. So drop it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_lock.c | 18 --
include/drm/drmP.h |3 ---
2 files changed, 0 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
inde
It's not used internally by any driver, only by some generic ioctls.
So don't export it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_scatter.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_scatter.c b/drivers/gpu/drm/drm_scatter.c
index 90
Hi all,
The following patch-pile contains various cleanups in the drm core. All but
patch 12 are resends. I've gone ahead and added the two reviewed-bys that
patch 9 scored on the first submission to the patch.
Patches apply on top of latest drm-core-next. Tested on my agp rv570 (kms and
ums) i94
"ring->space" is unsigned so it's never less than zero.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 51e9c9e..a331898 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbu
On Tue, 24 Aug 2010 00:37:52 +0100
Chris Wilson wrote:
> drm.debug=0x4 should print the right information for this bug.
That doesn't seem to give me any output at all.
One thing I noticed, though, is that I occasionally get something like:
Aug 23 17:43:14 bike kernel: [ 142.920185] [drm:intel
Hi,
Since 2.6.36-rc1 I have an oops when loading the nouveau driver.
The system woks ok expect for the nouveau driver and the console gets
corrupted :(
I attach relevant informations in attached files :
o dmesg output for 2.6.36-rc2-git1
o ksymoops output for the above file
If you need more in
On Mon, 23 Aug 2010 23:36:55 +0100
Chris Wilson wrote:
> Taking the patch at face value, the cause should be a mistake in error
> handling. So the first step would be to identify which i2c_transfer()
> failed.
OK, I tried it, but neither warning triggers.
Don't know if it helps or not, but I tr
https://bugs.freedesktop.org/show_bug.cgi?id=28294
Bug 28294 depends on bug 29722, which changed state.
Bug 29722 Summary: [glsl] Unigine Sanctuary v2.2 assertion failed
https://bugs.freedesktop.org/show_bug.cgi?id=29722
What|Old Value |New Value
https://bugs.freedesktop.org/show_bug.cgi?id=28294
Bug 28294 depends on bug 29722, which changed state.
Bug 29722 Summary: [glsl] Unigine Sanctuary v2.2 assertion failed
https://bugs.freedesktop.org/show_bug.cgi?id=29722
What|Old Value |New Value
https://bugs.freedesktop.org/show_bug.cgi?id=29738
--- Comment #5 from Till Matthiesen 2010-08-23 17:17:27
PDT ---
All I can tell so far is that it looks like this behaviour was introduced
somewhere between 2.6.35-git2 and 2.6.35-git3.
As Alexandre said, it is not straight forward to trigger.
I
Hi,
With 2.6.36-rc2 I see periodic stalls when running with a stock Ubuntu
10.04 userspace. These stalls were not present in 2.6.36-rc1 on an EeePC
900 with an i915.
Attempts to bisect the issue are not successful - most kernels in
between rc1 and rc2 just make the system come up with a black scr
https://bugs.freedesktop.org/show_bug.cgi?id=29738
--- Comment #5 from Till Matthiesen 2010-08-23
17:17:27 PDT ---
All I can tell so far is that it looks like this behaviour was introduced
somewhere between 2.6.35-git2 and 2.6.35-git3.
As Alexandre said, it is not straight forward to trigger.
I
On Tue, 24 Aug 2010 00:35:51 +0100, Sitsofe Wheeler wrote:
> Hi,
>
> With 2.6.36-rc2 I see periodic stalls when running with a stock Ubuntu
> 10.04 userspace. These stalls were not present in 2.6.36-rc1 on an EeePC
> 900 with an i915.
>From the error message, I'd suggest we'd tackle hangcheck -
On Mon, 23 Aug 2010 17:46:41 -0600, Jonathan Corbet wrote:
> On Tue, 24 Aug 2010 00:37:52 +0100
> Chris Wilson wrote:
>
> > drm.debug=0x4 should print the right information for this bug.
>
> That doesn't seem to give me any output at all.
>
> One thing I noticed, though, is that I occasionally
On Tue, 24 Aug 2010 00:37:52 +0100
Chris Wilson wrote:
> drm.debug=0x4 should print the right information for this bug.
That doesn't seem to give me any output at all.
One thing I noticed, though, is that I occasionally get something like:
Aug 23 17:43:14 bike kernel: [ 142.920185] [drm:intel
On Mon, 23 Aug 2010 17:32:25 -0600, Jonathan Corbet wrote:
> On Mon, 23 Aug 2010 23:36:55 +0100
> Chris Wilson wrote:
>
> > Taking the patch at face value, the cause should be a mistake in error
> > handling. So the first step would be to identify which i2c_transfer()
> > failed.
>
> OK, I trie
https://bugs.freedesktop.org/show_bug.cgi?id=29738
--- Comment #4 from Alexandre 2010-08-23 16:37:19 PDT
---
I will try to bisect. It will take a while because I still have not found a
consistent a way to trigger the bug.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=ema
https://bugs.freedesktop.org/show_bug.cgi?id=29738
--- Comment #4 from Alexandre 2010-08-23 16:37:19
PDT ---
I will try to bisect. It will take a while because I still have not found a
consistent a way to trigger the bug.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=ema
On Mon, 23 Aug 2010 23:36:55 +0100
Chris Wilson wrote:
> Taking the patch at face value, the cause should be a mistake in error
> handling. So the first step would be to identify which i2c_transfer()
> failed.
OK, I tried it, but neither warning triggers.
Don't know if it helps or not, but I tr
On Mon, 23 Aug 2010 15:17:08 -0600, Jonathan Corbet wrote:
> I went ahead and bisected the problem, which was added between -rc1 and
> -rc2. The end result is this:
Taking the patch at face value, the cause should be a mistake in error
handling. So the first step would be to identify which i2c_t
On 17 August 2010 23:37, Alex Deucher wrote:
> On Tue, Aug 17, 2010 at 6:12 PM, Daniel J Blueman
> wrote:
>> Hi chaps,
>>
>> On 9 August 2010 14:41, Daniel J Blueman wrote:
>>> On 8 August 2010 17:36, Daniel J Blueman
>>> wrote:
On 5 August 2010 16:23, Alex Deucher wrote:
> On Thu, A
On Mon, 23 Aug 2010 11:01:45 -0600
Jonathan Corbet wrote:
> So I decided to fire up -rc2 today to see what would happen...the
> results are best described by the attached images. Something is
> clearly scrambled between my hardware and the i915 driver. Display with X
> is hosed, but things go w
->masks[type].mask;
--
1.7.0.4
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digita
le
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20100823/58ed2b4f/attachment.pgp>
On Mon, 23 Aug 2010 11:01:45 -0600
Jonathan Corbet wrote:
> So I decided to fire up -rc2 today to see what would happen...the
> results are best described by the attached images. Something is
> clearly scrambled between my hardware and the i915 driver. Display with X
> is hosed, but things go w
The information supplied by userspace through these ioctls is only
accessible by dev->drw_idr. But there's no in-tree user of that.
Also userspace does not really care about return values of these ioctls,
either. Only hw/xfree86/dri/dri.c from the xserver actually checks the
return from adddraw and
Only used by ioctl, not by any in-tree drivers.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_lock.c | 10 +++---
include/drm/drmP.h |1 -
2 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
index 1973d75
All drivers happily copy&pasted the default implementation without
checking whether this callback is used at all. It's not. Sigh.
Kill it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_vm.c |7 ---
drivers/gpu/drm/i810/i810_drv.c |1 -
drivers/gpu/drm/i830/
Every driver used the default implementation. Fold that one into
the only callsite and drop the callback.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_vm.c |6 ++
drivers/gpu/drm/i810/i810_drv.c |1 -
drivers/gpu/drm/i830/i830_drv.c |1 -
drivers/
No caller (rightly) cares about it, so drop it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_memory.c |4 ++--
include/drm/drmP.h |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_memory.c b/drivers/gpu/drm/drm_memory.c
index 7732
Not used by any in-tree user. So drop it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drawable.c |3 +--
include/drm/drmP.h |2 --
2 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_drawable.c b/drivers/gpu/drm/drm_drawable.c
index c53
Totally unused.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c |2 --
drivers/gpu/drm/drm_stub.c |1 -
include/drm/drmP.h |1 -
3 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index a35a410..5ff
It's not used by any driver. The destructor callback is unfortunately
used by the via driver in a rather convoluted piece of code used
to reimplement something resembling broken futexes. I didn't dare
to touch this code. But at least kill the needless NULL assignemt
in the sis driver.
Signed-off-b
Not used by any current driver.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem.c |4 +---
include/drm/drmP.h|1 -
2 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index bf92d07..cff7317 100644
--- a/dri
Not used by any driver. So drop it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_lock.c |3 ---
include/drm/drmP.h |1 -
2 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
index 566d203..1973d75 100644
--
Hi all,
The following patch-pile contains various cleanups in the drm core. All but
patch 12 are resends. I've gone ahead and added the two reviewed-bys that
patch 9 scored on the first submission to the patch.
Patches apply on top of latest drm-core-next. Tested on my agp rv570 (kms and
ums) i94
Not used by any driver (rightly so!). Kill them.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_proc.c | 13 -
include/drm/drmP.h |2 --
2 files changed, 0 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_proc.c b/drivers/gpu/drm/drm_proc.c
index a
There's no point in jumping through two indirections. So kill one
and call the kernels agp functions directly.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_agpsupport.c | 40 +++--
drivers/gpu/drm/drm_memory.c | 12 ++
include/drm/drmP.h
Not used by any in-kernel driver. So drop it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_lock.c | 18 --
include/drm/drmP.h |3 ---
2 files changed, 0 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
inde
It's not used internally by any driver, only by some generic ioctls.
So don't export it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_scatter.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_scatter.c b/drivers/gpu/drm/drm_scatter.c
index 90
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20100823/f0dc7e14/attachment.pgp>
Commit 6ef3d4278034982c13df87c4a51e0445f762d316 introduces seq_file
usage in intel_overlay.c but does not include the header and now
compilation fails on i386. Fix it by including the necessary header.
Signed-off-by: Meelis Roos
diff --git a/drivers/gpu/drm/i915/intel_overlay.c
b/drivers/gpu/
On Wed, Jun 23, 2010 at 07:06:22PM +0200, Dan Carpenter wrote:
> We don't need to check the list cursor in a list_for_each_entry(). It's
> always non-null.
>
Here is another one that never got applied. I has a sad face. :(
regards,
dan carpenter
> Signed-off-by: Dan Carpenter
>
> diff --gi
On Wed, Jun 23, 2010 at 07:03:01PM +0200, Dan Carpenter wrote:
> copy_to_user() returns the number of bytes remaining to be copied and
> I'm pretty sure we want to return a negative error code here.
>
This patch wasn't applied either.
regards,
dan carpenter
> Signed-off-by: Dan Carpenter
>
>
On Sat, Jun 19, 2010 at 03:12:51PM +0200, Dan Carpenter wrote:
> copy_to_user returns the number of bytes remaining to be copied, but we
> want to return a negative error code here. These are returned to
> userspace.
>
I didn't get a response on this patch.
regards,
dan carpenter
> Signed-off-
On Sat, 19 Jun 2010 15:12:51 +0200, Dan Carpenter wrote:
> copy_to_user returns the number of bytes remaining to be copied, but we
> want to return a negative error code here. These are returned to
> userspace.
>
> Signed-off-by: Dan Carpenter
Reviewed-by: Chris Wilson
--
Chris Wilson, Intel
On Wed, 23 Jun 2010 19:03:01 +0200, Dan Carpenter wrote:
> copy_to_user() returns the number of bytes remaining to be copied and
> I'm pretty sure we want to return a negative error code here.
>
> Signed-off-by: Dan Carpenter
Reviewed-by: Chris Wilson
--
Chris Wilson, Intel Open Source Techno
On Mon, 23 Aug 2010 13:38:27 +0300 (EEST), Meelis Roos
wrote:
> Commit 6ef3d4278034982c13df87c4a51e0445f762d316 introduces seq_file
> usage in intel_overlay.c but does not include the header and now
> compilation fails on i386. Fix it by including the necessary header.
>
> Signed-off-by: Meeli
https://bugs.freedesktop.org/show_bug.cgi?id=29762
Summary: [r300g] Coldest: Buffer too small for color buffer 0
(need 3407872 have 2023424) !
Product: Mesa
Version: git
Platform: Other
URL: http://www.coldestgame.com/si
https://bugs.freedesktop.org/show_bug.cgi?id=29762
Summary: [r300g] Coldest: Buffer too small for color buffer 0
(need 3407872 have 2023424) !
Product: Mesa
Version: git
Platform: Other
URL: http://www.coldestgame.com/si
- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- http://lists.freedesktop.org/archives/dri-devel/attachments/20100823/7d120849/attachment-0002.jpg>
-- next part --
A non-text attachment was scrubbed...
Name: x.jpg
Type: imag
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16651
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_modes.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index f1f473e..949326d 100644
--- a/drive
Commit 6ef3d4278034982c13df87c4a51e0445f762d316 causes a build failure
for me:
,
| CC [M] drivers/gpu/drm/i915/intel_overlay.o
| drivers/gpu/drm/i915/intel_overlay.c: In function
'intel_overlay_print_error_state':
| drivers/gpu/drm/i915/intel_overlay.c:1467: error: implicit declaration of
l ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/at
https://bugs.freedesktop.org/show_bug.cgi?id=29754
Pavel Ondračka changed:
What|Removed |Added
URL||http://www.heroesofnewerth.
https://bugs.freedesktop.org/show_bug.cgi?id=29754
Pavel Ondra?ka changed:
What|Removed |Added
URL||http://www.heroesofnewerth.
"ring->space" is unsigned so it's never less than zero.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 51e9c9e..a331898 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbu
https://bugs.freedesktop.org/show_bug.cgi?id=29754
Summary: [r300g, glsl] Heroes of Newerth lockup GPU
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: major
Priority: me
https://bugs.freedesktop.org/show_bug.cgi?id=29754
Summary: [r300g, glsl] Heroes of Newerth lockup GPU
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: major
Priority: me
https://bugs.freedesktop.org/show_bug.cgi?id=29384
--- Comment #34 from pete...@hottemptation.org 2010-08-23 09:12:16 PDT ---
Great!
This bug has one good side, I learned much stuff.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail be
https://bugs.freedesktop.org/show_bug.cgi?id=29384
--- Comment #34 from peterle at hottemptation.org 2010-08-23 09:12:16 PDT ---
Great!
This bug has one good side, I learned much stuff.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=29738
--- Comment #3 from Alex Deucher 2010-08-23 09:00:46 PDT ---
can you bisect the kernel to see what commit is causing the problem?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail bec
https://bugs.freedesktop.org/show_bug.cgi?id=29738
--- Comment #3 from Alex Deucher 2010-08-23 09:00:46 PDT
---
can you bisect the kernel to see what commit is causing the problem?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail be
https://bugs.freedesktop.org/show_bug.cgi?id=29738
--- Comment #2 from Alexandre 2010-08-23 08:54:34 PDT
---
Same error. It happens with xorg 1.9.0 and older versions but only with
2.6.36-rc1. All versions of 2.6.35 (including 2.6.35.2) work well, I could
never generate a bus error.
It sometime
https://bugs.freedesktop.org/show_bug.cgi?id=29738
--- Comment #2 from Alexandre 2010-08-23 08:54:34
PDT ---
Same error. It happens with xorg 1.9.0 and older versions but only with
2.6.36-rc1. All versions of 2.6.35 (including 2.6.35.2) work well, I could
never generate a bus error.
It sometime
Allows e.g. power management daemons to control the backlight level. Inspired
by the corresponding code in radeonfb.
(Updated to add backlight type and make the connector the parent device - mjg)
Signed-off-by: Michel D?nzer
Signed-off-by: Matthew Garrett
---
drivers/gpu/drm/radeon/Kconfig
At Mon, 23 Aug 2010 14:19:22 +0800,
Zhenyu Wang wrote:
>
> On 2010.08.23 08:02:42 +0200, Takashi Iwai wrote:
> >
> > Also, I don't understand the logic of 40bit addr calculation:
> >
> > > static unsigned long intel_gen6_mask_memory(struct agp_bridge_data
> > > *bridge,
> > >
At Mon, 23 Aug 2010 08:02:42 +0200,
I wrote:
>
> At Mon, 23 Aug 2010 13:43:03 +0800,
> Zhenyu Wang wrote:
> >
> > On 2010.08.23 07:29:29 +0200, Takashi Iwai wrote:
> > > > Sandybridge can do 40-bit dma mask. This has been fixed upstream now.
> > >
> > > Could you point where is the upstream GIT
At Mon, 23 Aug 2010 13:43:03 +0800,
Zhenyu Wang wrote:
>
> On 2010.08.23 07:29:29 +0200, Takashi Iwai wrote:
> > > Sandybridge can do 40-bit dma mask. This has been fixed upstream now.
> >
> > Could you point where is the upstream GIT tree and the corresponding
> > commit id?
> >
>
> Linus's tr
At Mon, 23 Aug 2010 09:35:07 +0800,
Zhenyu Wang wrote:
>
> On 2010.08.20 17:36:08 +0200, Takashi Iwai wrote:
> > Sandybridge requires 36bit dma mask, but the current code checks only
> > against i965, thus it gives Oops with i915 probing on 32bit machine:
> >
> >nommu_map_sg: overflow 14a
On 17 August 2010 23:37, Alex Deucher wrote:
> On Tue, Aug 17, 2010 at 6:12 PM, Daniel J Blueman
> wrote:
>> Hi chaps,
>>
>> On 9 August 2010 14:41, Daniel J Blueman wrote:
>>> On 8 August 2010 17:36, Daniel J Blueman wrote:
On 5 August 2010 16:23, Alex Deucher wrote:
> On Thu, Aug 5,
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16651
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_modes.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index f1f473e..949326d 100644
--- a/drive
https://bugs.freedesktop.org/show_bug.cgi?id=29384
--- Comment #33 from Alex Deucher 2010-08-23 07:08:16 PDT ---
(In reply to comment #32)
> Linus didn't included the patch in rc2.
> Typicall delay?
The pull request just went out today, so it should show up as soon as Linus
pulls it.
--
Config
https://bugs.freedesktop.org/show_bug.cgi?id=29384
--- Comment #33 from Alex Deucher 2010-08-23 07:08:16 PDT
---
(In reply to comment #32)
> Linus didn't included the patch in rc2.
> Typicall delay?
The pull request just went out today, so it should show up as soon as Linus
pulls it.
--
Confi
On Mon, 23 Aug 2010 14:48:54 +0800, Zhenyu Wang wrote:
> On 2010.08.23 08:31:42 +0200, Takashi Iwai wrote:
> > > bit 31 bit 11 bit 4
> > > bit 0
> > >|<-physical addr 31:12->|<-physical addr 39:32->|<-cache ctl
> > > 3:1->|valid|
> >
> >
t available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20100823/9cce1ca1/attachment.pgp>
https://bugs.freedesktop.org/show_bug.cgi?id=29680
Nicolas Kaiser changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=29680
Nicolas Kaiser changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=29363
--- Comment #16 from Pavel Ondračka 2010-08-23 06:01:16 PDT
---
With glsl2 merged into master things are looking much better now, terrain is
rendered properly and most of units and buildings too, however there are some
effects which are wrong an
https://bugs.freedesktop.org/show_bug.cgi?id=29363
--- Comment #16 from Pavel Ondra?ka 2010-08-23 06:01:16
PDT ---
With glsl2 merged into master things are looking much better now, terrain is
rendered properly and most of units and buildings too, however there are some
effects which are wrong an
https://bugs.freedesktop.org/show_bug.cgi?id=29384
--- Comment #32 from pete...@hottemptation.org 2010-08-23 05:22:51 PDT ---
Linus didn't included the patch in rc2.
Typicall delay?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail bec
https://bugs.freedesktop.org/show_bug.cgi?id=29384
--- Comment #32 from peterle at hottemptation.org 2010-08-23 05:22:51 PDT ---
Linus didn't included the patch in rc2.
Typicall delay?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail
Commit 6ef3d4278034982c13df87c4a51e0445f762d316 introduces seq_file
usage in intel_overlay.c but does not include the header and now
compilation fails on i386. Fix it by including the necessary header.
Signed-off-by: Meelis Roos
diff --git a/drivers/gpu/drm/i915/intel_overlay.c
b/drivers/gpu/
https://bugs.freedesktop.org/show_bug.cgi?id=29137
--- Comment #16 from Rubén Fernández 2010-08-23 04:43:33
PDT ---
If it is of any help, aplyint that wined3d hack makes all the wine applications
I have tested render correctly except for two games:
One of them still complains about "r300: Max s
https://bugs.freedesktop.org/show_bug.cgi?id=29137
--- Comment #16 from Rub?n Fern?ndez 2010-08-23
04:43:33 PDT ---
If it is of any help, aplyint that wined3d hack makes all the wine applications
I have tested render correctly except for two games:
One of them still complains about "r300: Max s
On Sat, 19 Jun 2010 15:12:51 +0200, Dan Carpenter wrote:
> copy_to_user returns the number of bytes remaining to be copied, but we
> want to return a negative error code here. These are returned to
> userspace.
>
> Signed-off-by: Dan Carpenter
Reviewed-by: Chris Wilson
--
Chris Wilson, Intel
On Wed, 23 Jun 2010 19:03:01 +0200, Dan Carpenter wrote:
> copy_to_user() returns the number of bytes remaining to be copied and
> I'm pretty sure we want to return a negative error code here.
>
> Signed-off-by: Dan Carpenter
Reviewed-by: Chris Wilson
--
Chris Wilson, Intel Open Source Techno
1 - 100 of 111 matches
Mail list logo
