https://bugs.freedesktop.org/show_bug.cgi?id=26092
Christian Schmitt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
At Mon, 02 Jul 2012 15:46:29 -0400,
Adam Jackson wrote:
>
> On 6/26/12 3:21 AM, Takashi Iwai wrote:
>
> > From: Takashi Iwai
> > Subject: [PATCH] drm: edid: Don't add inferred modes with higher resolution
> >
> > When a monitor EDID doesn't give the preferred bit, driver assumes
> > that the mod
When a monitor EDID doesn't give the preferred bit, driver assumes
that the mode with the higest resolution and rate is the preferred
mode. Meanwhile the recent changes for allowing more modes in the
GFT/CVT ranges give actually more modes, and some modes may be over
the native size. Thus such a
On Mon, 2 Jul 2012 14:54:58 -0700
Ben Widawsky wrote:
> > +#define _GNU_SOURCE
> > +
> > #include
> > #include
> > #include
>
> I can't reproduce this. Can anyone else confirm this is broken, and if
> so that the above patch fixes it?
See the manpage, it depends on the glibc version. Libd
On 02.07.2012 19:27, Jerome Glisse wrote:
On Mon, Jul 2, 2012 at 1:05 PM, Christian König wrote:
On 02.07.2012 18:41, Jerome Glisse wrote:
On Mon, Jul 2, 2012 at 12:26 PM, Christian König
wrote:
On 02.07.2012 17:39, j.gli...@gmail.com wrote:
From: Jerome Glisse
GPU reset need to be exclus
On 02.07.2012 18:40, j.gli...@gmail.com wrote:
From: Jerome Glisse
In gem idle/busy ioctl the radeon object was derefenced after
drm_gem_object_unreference_unlocked which in case the object
have been destroyed lead to use of a possibly free pointer with
possibly wrong data.
Signed-off-by: Jero
https://bugs.freedesktop.org/show_bug.cgi?id=51594
Michel Dänzer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=26496
Michel Dänzer changed:
What|Removed |Added
CC||kevinba...@gmail.com
--- Comment #15 fro
* Gross, Andy [120619 14:17]:
> Tony,
>
> Please queue this patch at your earliest convenience.
>
> We had some discussion on the splitting out of the DMM/Tiler driver
> from the omapdrm driver. There might be some interest in leveraging
> the Tiler for omapfb. However, we agreed this can be d
Hi Linus,
one regression fix, two radeon fixes (one for an oops), and an i915 fix
to unload framebuffers earlier.
We originally were going to leave the i915 fix until -next, but grub2 in
some situations causes vesafb/efifb to be loaded now, and this causes big
slowdowns, and I have reports in
Don't return success if scheduling the IB fails, otherwise
we end up with an oops in ttm_eu_fence_buffer_objects.
Signed-off-by: Christian König
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_cs.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/dr
https://bugs.freedesktop.org/show_bug.cgi?id=51658
--- Comment #9 from Roland Scheidegger 2012-07-03 05:20:47
PDT ---
(In reply to comment #8)
> A summary of all of the patches follows.
>
> r200 essential patches (1st 3 patches) for gnome shell:
> "Essential patch to disable texture formats tha
On Tue, Jul 03, 2012 at 11:59:51AM +0100, Mel Gorman wrote:
> On Tue, Jul 03, 2012 at 10:19:28AM +1000, Dave Chinner wrote:
> > On Mon, Jul 02, 2012 at 08:35:16PM +0100, Mel Gorman wrote:
> > > Adding dri-devel and a few others because an i915 patch contributed to
> > > the regression.
> > >
> > >
On Tue, Jul 3, 2012 at 9:31 AM, Daniel Vetter wrote:
> Well, presuming I understand things correctly the cpu die only goes into
> the lowest sleep state (which iirc switches off l3 caches and
> interconnects) when both the cpu and gpu are in the lowest sleep state.
> rc6 is that deep-sleep state
On Tue, Jul 3, 2012 at 8:11 AM, Christian König wrote:
> Don't return success if scheduling the IB fails, otherwise
> we end up with an oops in ttm_eu_fence_buffer_objects.
>
> Signed-off-by: Christian König
> Cc: sta...@vger.kernel.org
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon
On Tue, Jul 03, 2012 at 02:04:14PM +0100, Mel Gorman wrote:
> On Mon, Jul 02, 2012 at 08:35:16PM +0100, Mel Gorman wrote:
> > >
> > >
> > It was obvious very quickly that there were two distinct regression so I
> > ran two bisections. One led to a XFS and the other led to an i915 patch
> > that en
On Tue, Jul 3, 2012 at 5:26 AM, Christian König wrote:
> On 02.07.2012 19:27, Jerome Glisse wrote:
>>
>> On Mon, Jul 2, 2012 at 1:05 PM, Christian König
>> wrote:
>>>
>>> On 02.07.2012 18:41, Jerome Glisse wrote:
On Mon, Jul 2, 2012 at 12:26 PM, Christian König
wrote:
>
>
On Tue, Jul 03, 2012 at 11:59:51AM +0100, Mel Gorman wrote:
> > Can you run latencytop to see
> > if there is excessive starvation/wait times for allocation
> > completion?
>
> I'm not sure what format you are looking for. latencytop is shit for
> capturing information throughout a test and it do
On Mon, Jul 02, 2012 at 08:35:16PM +0100, Mel Gorman wrote:
> >
> >
> It was obvious very quickly that there were two distinct regression so I
> ran two bisections. One led to a XFS and the other led to an i915 patch
> that enables RC6 to reduce power usage.
>
> [c999a223: xfs: introduce an alloc
On Tue, Jul 03, 2012 at 02:31:19PM +0200, Daniel Vetter wrote:
> On Tue, Jul 03, 2012 at 11:59:51AM +0100, Mel Gorman wrote:
> > On Tue, Jul 03, 2012 at 10:19:28AM +1000, Dave Chinner wrote:
> > > On Mon, Jul 02, 2012 at 08:35:16PM +0100, Mel Gorman wrote:
> > > > Adding dri-devel and a few others
On 03.07.2012 16:09, Jerome Glisse wrote:
On Tue, Jul 3, 2012 at 5:26 AM, Christian König wrote:
[SNIP]
Yeah, but I thought that fixing those oops as the second step. I see the
fact that suspend/resume is unpinning all the ttm memory and then pinning it
again as a bug that needs to be fixed. Or
https://bugzilla.kernel.org/show_bug.cgi?id=44121
--- Comment #1 from Alex Deucher 2012-07-03 14:53:04
---
Can you dump the following registers using radeonreg or avivotool
(http://cgit.freedesktop.org/~airlied/radeontool/) with the patch applied and
reverted and attach both results?
CC_RB
On Tue, Jul 3, 2012 at 10:52 AM, Christian König
wrote:
> On 03.07.2012 16:09, Jerome Glisse wrote:
>>
>> On Tue, Jul 3, 2012 at 5:26 AM, Christian König
>> wrote:
>>>
>>> [SNIP]
>>>
>>> Yeah, but I thought that fixing those oops as the second step. I see the
>>> fact that suspend/resume is unpin
https://bugzilla.kernel.org/show_bug.cgi?id=44121
--- Comment #2 from Jean Delvare 2012-07-03 15:27:00 ---
With 3.5-rc5 kernel (failing) :
0x98F40x0001 (1)
0x3F880x0001 (1)
0x9B7C0x (0)
0x89500xfffcf001 (-200703)
0x98FC0x (0)
With commit 416a2bd2
https://bugzilla.kernel.org/show_bug.cgi?id=44121
--- Comment #3 from Jérôme Glisse 2012-07-03 15:42:09
---
Created an attachment (id=74671)
--> (https://bugzilla.kernel.org/attachment.cgi?id=74671)
properly disable render backend
Does this patch fix it ?
--
Configure bugmail: https://
The link generated by the release script was incorrect. They should be
http://dri.freedesktop.org/libdrm/libdrm-2.4.37.tar.gz
http://dri.freedesktop.org/libdrm/libdrm-2.4.37.tar.bz2
On Fri, 29 Jun 2012 11:17:47 -0700
Ben Widawsky wrote:
> I botched the 2.3.36 release quite royally. Here is 2.6.
https://bugzilla.kernel.org/show_bug.cgi?id=44121
--- Comment #4 from Jean Delvare 2012-07-03 16:21:27 ---
I tested the patch in comment #3 but unfortunately it doesn't solve the
problem.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving th
https://bugzilla.kernel.org/show_bug.cgi?id=44121
--- Comment #5 from Jean Delvare 2012-07-03 16:39:19 ---
With this patch applied, I get:
0x98F40x0001 (1)
0x3F880x0001 (1)
0x9B7C0x00fe (16646144)
0x89500xfffcf001 (-200703)
0x98FC0x (0)
0x89540x00
On Tue, 3 Jul 2012 12:21:27 +0300
Lauri Kasanen wrote:
> On Mon, 2 Jul 2012 14:54:58 -0700
> Ben Widawsky wrote:
>
> > > +#define _GNU_SOURCE
> > > +
> > > #include
> > > #include
> > > #include
> >
> > I can't reproduce this. Can anyone else confirm this is broken, and if
> > so that th
https://bugzilla.kernel.org/show_bug.cgi?id=44121
Jérôme Glisse changed:
What|Removed |Added
Attachment #74671|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=44121
--- Comment #7 from Alex Deucher 2012-07-03 17:31:40
---
Created an attachment (id=74711)
--> (https://bugzilla.kernel.org/attachment.cgi?id=74711)
possible fix
or this variant. Although AFAIK, programming the USER register variants
shoul
Maybe I'm doing something wrong, but my cloned repo of
drm-radeon-testing is giving build errors. What I'm
seeing is
[...]
CC drivers/gpu/drm/radeon/radeon_gem.o
drivers/gpu/drm/radeon/radeon_gem.c: In function ‘radeon_gem_create_ioctl’:
drivers/gpu/drm/radeon/radeon_gem.c:
https://bugzilla.kernel.org/show_bug.cgi?id=44121
--- Comment #8 from Alex Deucher 2012-07-03 18:00:24
---
Does booting up a clean kernel without any patches applied or reverted work if
you manually set the following registers to their "patch reverted" values using
radeonreg? Just to be sur
https://bugzilla.kernel.org/show_bug.cgi?id=44121
--- Comment #9 from Jean Delvare 2012-07-03 18:08:29 ---
Patch from comment #6 doesn't work, testing patch from comment #7 now.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail be
On Tue, Jul 3, 2012 at 6:02 PM, David Witbrodt wrote:
> Maybe I'm doing something wrong, but my cloned repo of
> drm-radeon-testing is giving build errors. What I'm
> seeing is
Oh I wasn't aware anyone still used it, I just pushed a branch for
Jerome the other day to test something, its known br
https://bugzilla.kernel.org/show_bug.cgi?id=44121
--- Comment #10 from Jean Delvare 2012-07-03 18:56:15 ---
Patch from comment #7 did not work either. Then I followed the instructions
from comment #8, but it also did not help.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi
https://bugzilla.kernel.org/show_bug.cgi?id=44121
Alex Deucher changed:
What|Removed |Added
Attachment #74711|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=44121
--- Comment #12 from Jean Delvare 2012-07-03 21:40:52 ---
Patch from comment #11 didn't work at all, not only it didn't fix the original
issue but it even caused additional trouble (gdm wouldn't even show up.)
--
Configure bugmail: https://
> Oh I wasn't aware anyone still used it, I just pushed a branch for
> Jerome the other day to test something, its known broken.
Oh, boy... sorry for the noise, then. This was caused by
the way I am using git: I cloned the Linus Torvalds tree,
and then used 'git add' to include several tree
ches are from xfs_alloc_vextent, 55% are from the work threads,
and the rest are CPU idling events, which is exactly as I'd expect.
> > A pert top profile comparison might be informative,
> > too...
> >
>
> I'm not sure if this is what you really wanted. I thou
On Mon, Jul 02, 2012 at 11:43:04AM +0100, Alan Cox wrote:
> On Mon, 2 Jul 2012 07:06:59 +0900
> Mattia Dongili wrote:
...
> > a did put some printks here and there and psb_driver_init seems to
> > never return from gma_backlight_init.
>
> Is it ok if you just comment out gma_backlight_init (at wh
On Tue, Jul 03, 2012 at 07:11:31AM +0900, Mattia Dongili wrote:
> On Mon, Jul 02, 2012 at 11:43:04AM +0100, Alan Cox wrote:
> > On Mon, 2 Jul 2012 07:06:59 +0900
> > Mattia Dongili wrote:
> ...
> > > a did put some printks here and there and psb_driver_init seems to
> > > never return from gma_bac
On Mon, Jul 02, 2012 at 08:35:16PM +0100, Mel Gorman wrote:
> Adding dri-devel and a few others because an i915 patch contributed to
> the regression.
>
> On Mon, Jul 02, 2012 at 03:32:15PM +0100, Mel Gorman wrote:
> > On Mon, Jul 02, 2012 at 02:32:26AM -0400, Christoph Hellwig wrote:
> > > > It i
https://bugs.freedesktop.org/show_bug.cgi?id=26092
Christian Schmitt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
At Mon, 02 Jul 2012 15:46:29 -0400,
Adam Jackson wrote:
>
> On 6/26/12 3:21 AM, Takashi Iwai wrote:
>
> > From: Takashi Iwai
> > Subject: [PATCH] drm: edid: Don't add inferred modes with higher resolution
> >
> > When a monitor EDID doesn't give the preferred bit, driver assumes
> > that the mod
When a monitor EDID doesn't give the preferred bit, driver assumes
that the mode with the higest resolution and rate is the preferred
mode. Meanwhile the recent changes for allowing more modes in the
GFT/CVT ranges give actually more modes, and some modes may be over
the native size. Thus such a
On Mon, 2 Jul 2012 14:54:58 -0700
Ben Widawsky wrote:
> > +#define _GNU_SOURCE
> > +
> > #include
> > #include
> > #include
>
> I can't reproduce this. Can anyone else confirm this is broken, and if
> so that the above patch fixes it?
See the manpage, it depends on the glibc version. Libd
On 02.07.2012 19:27, Jerome Glisse wrote:
> On Mon, Jul 2, 2012 at 1:05 PM, Christian K?nig
> wrote:
>> On 02.07.2012 18:41, Jerome Glisse wrote:
>>> On Mon, Jul 2, 2012 at 12:26 PM, Christian K?nig
>>> wrote:
On 02.07.2012 17:39, j.glisse at gmail.com wrote:
> From: Jerome Glisse
On 02.07.2012 18:40, j.glisse at gmail.com wrote:
> From: Jerome Glisse
>
> In gem idle/busy ioctl the radeon object was derefenced after
> drm_gem_object_unreference_unlocked which in case the object
> have been destroyed lead to use of a possibly free pointer with
> possibly wrong data.
>
> Sign
https://bugs.freedesktop.org/show_bug.cgi?id=51594
Michel D?nzer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=26496
Michel D?nzer changed:
What|Removed |Added
CC||kevinbanjo at gmail.com
--- Comment #15
* Gross, Andy [120619 14:17]:
> Tony,
>
> Please queue this patch at your earliest convenience.
>
> We had some discussion on the splitting out of the DMM/Tiler driver
> from the omapdrm driver. There might be some interest in leveraging
> the Tiler for omapfb. However, we agreed this can be d
Hi Linus,
one regression fix, two radeon fixes (one for an oops), and an i915 fix
to unload framebuffers earlier.
We originally were going to leave the i915 fix until -next, but grub2 in
some situations causes vesafb/efifb to be loaded now, and this causes big
slowdowns, and I have reports in
Don't return success if scheduling the IB fails, otherwise
we end up with an oops in ttm_eu_fence_buffer_objects.
Signed-off-by: Christian K?nig
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_cs.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu
https://bugs.freedesktop.org/show_bug.cgi?id=51658
--- Comment #9 from Roland Scheidegger 2012-07-03
05:20:47 PDT ---
(In reply to comment #8)
> A summary of all of the patches follows.
>
> r200 essential patches (1st 3 patches) for gnome shell:
> "Essential patch to disable texture formats tha
On Tue, Jul 03, 2012 at 11:59:51AM +0100, Mel Gorman wrote:
> On Tue, Jul 03, 2012 at 10:19:28AM +1000, Dave Chinner wrote:
> > On Mon, Jul 02, 2012 at 08:35:16PM +0100, Mel Gorman wrote:
> > > Adding dri-devel and a few others because an i915 patch contributed to
> > > the regression.
> > >
> > >
.freedesktop.org/archives/dri-devel/attachments/20120703/9d001245/attachment.html>
On Tue, Jul 3, 2012 at 8:11 AM, Christian K?nig
wrote:
> Don't return success if scheduling the IB fails, otherwise
> we end up with an oops in ttm_eu_fence_buffer_objects.
>
> Signed-off-by: Christian K?nig
> Cc: stable at vger.kernel.org
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/ra
On Tue, Jul 03, 2012 at 02:04:14PM +0100, Mel Gorman wrote:
> On Mon, Jul 02, 2012 at 08:35:16PM +0100, Mel Gorman wrote:
> > >
> > >
> > It was obvious very quickly that there were two distinct regression so I
> > ran two bisections. One led to a XFS and the other led to an i915 patch
> > that en
On Tue, Jul 3, 2012 at 5:26 AM, Christian K?nig
wrote:
> On 02.07.2012 19:27, Jerome Glisse wrote:
>>
>> On Mon, Jul 2, 2012 at 1:05 PM, Christian K?nig
>> wrote:
>>>
>>> On 02.07.2012 18:41, Jerome Glisse wrote:
On Mon, Jul 2, 2012 at 12:26 PM, Christian K?nig
wrote:
>
>
reasingly complex storage layers and the 100+ function deep call
> chains that occur.
>
I understand the patches motivation. For these tests I'm being deliberately
a bit of a dummy and just capturing information. This might allow me to
actually get through all the results and identify some of
On Tue, Jul 03, 2012 at 11:59:51AM +0100, Mel Gorman wrote:
> > Can you run latencytop to see
> > if there is excessive starvation/wait times for allocation
> > completion?
>
> I'm not sure what format you are looking for. latencytop is shit for
> capturing information throughout a test and it do
On Mon, Jul 02, 2012 at 08:35:16PM +0100, Mel Gorman wrote:
> >
> >
> It was obvious very quickly that there were two distinct regression so I
> ran two bisections. One led to a XFS and the other led to an i915 patch
> that enables RC6 to reduce power usage.
>
> [c999a223: xfs: introduce an alloc
On Tue, Jul 03, 2012 at 02:31:19PM +0200, Daniel Vetter wrote:
> On Tue, Jul 03, 2012 at 11:59:51AM +0100, Mel Gorman wrote:
> > On Tue, Jul 03, 2012 at 10:19:28AM +1000, Dave Chinner wrote:
> > > On Mon, Jul 02, 2012 at 08:35:16PM +0100, Mel Gorman wrote:
> > > > Adding dri-devel and a few others
On 03.07.2012 16:09, Jerome Glisse wrote:
> On Tue, Jul 3, 2012 at 5:26 AM, Christian K?nig
> wrote:
>> [SNIP]
>> Yeah, but I thought that fixing those oops as the second step. I see the
>> fact that suspend/resume is unpinning all the ttm memory and then pinning it
>> again as a bug that needs t
https://bugzilla.kernel.org/show_bug.cgi?id=44121
--- Comment #1 from Alex Deucher 2012-07-03
14:53:04 ---
Can you dump the following registers using radeonreg or avivotool
(http://cgit.freedesktop.org/~airlied/radeontool/) with the patch applied and
reverted and attach both results?
CC_RB
On Tue, Jul 3, 2012 at 10:52 AM, Christian K?nig
wrote:
> On 03.07.2012 16:09, Jerome Glisse wrote:
>>
>> On Tue, Jul 3, 2012 at 5:26 AM, Christian K?nig
>> wrote:
>>>
>>> [SNIP]
>>>
>>> Yeah, but I thought that fixing those oops as the second step. I see the
>>> fact that suspend/resume is unpin
https://bugzilla.kernel.org/show_bug.cgi?id=44121
--- Comment #2 from Jean Delvare 2012-07-03 15:27:00
---
With 3.5-rc5 kernel (failing) :
0x98F40x0001 (1)
0x3F880x0001 (1)
0x9B7C0x (0)
0x89500xfffcf001 (-200703)
0x98FC0x (0)
With commit 416a2bd
https://bugzilla.kernel.org/show_bug.cgi?id=44121
--- Comment #3 from J?r?me Glisse 2012-07-03
15:42:09 ---
Created an attachment (id=74671)
--> (https://bugzilla.kernel.org/attachment.cgi?id=74671)
properly disable render backend
Does this patch fix it ?
--
Configure bugmail: https://
The link generated by the release script was incorrect. They should be
http://dri.freedesktop.org/libdrm/libdrm-2.4.37.tar.gz
http://dri.freedesktop.org/libdrm/libdrm-2.4.37.tar.bz2
On Fri, 29 Jun 2012 11:17:47 -0700
Ben Widawsky wrote:
> I botched the 2.3.36 release quite royally. Here is 2.6.
https://bugzilla.kernel.org/show_bug.cgi?id=44121
--- Comment #4 from Jean Delvare 2012-07-03 16:21:27
---
I tested the patch in comment #3 but unfortunately it doesn't solve the
problem.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving t
https://bugzilla.kernel.org/show_bug.cgi?id=44121
--- Comment #5 from Jean Delvare 2012-07-03 16:39:19
---
With this patch applied, I get:
0x98F40x0001 (1)
0x3F880x0001 (1)
0x9B7C0x00fe (16646144)
0x89500xfffcf001 (-200703)
0x98FC0x (0)
0x89540x0
On Tue, 3 Jul 2012 12:21:27 +0300
Lauri Kasanen wrote:
> On Mon, 2 Jul 2012 14:54:58 -0700
> Ben Widawsky wrote:
>
> > > +#define _GNU_SOURCE
> > > +
> > > #include
> > > #include
> > > #include
> >
> > I can't reproduce this. Can anyone else confirm this is broken, and if
> > so that th
https://bugzilla.kernel.org/show_bug.cgi?id=44121
J?r?me Glisse changed:
What|Removed |Added
Attachment #74671|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=44121
--- Comment #7 from Alex Deucher 2012-07-03
17:31:40 ---
Created an attachment (id=74711)
--> (https://bugzilla.kernel.org/attachment.cgi?id=74711)
possible fix
or this variant. Although AFAIK, programming the USER register variants
shoul
Maybe I'm doing something wrong, but my cloned repo of
drm-radeon-testing is giving build errors. What I'm
seeing is
[...]
CC drivers/gpu/drm/radeon/radeon_gem.o
drivers/gpu/drm/radeon/radeon_gem.c: In function ?radeon_gem_create_ioctl?:
drivers/gpu/drm/radeon/radeon_gem.c:
https://bugzilla.kernel.org/show_bug.cgi?id=44121
--- Comment #8 from Alex Deucher 2012-07-03
18:00:24 ---
Does booting up a clean kernel without any patches applied or reverted work if
you manually set the following registers to their "patch reverted" values using
radeonreg? Just to be sur
https://bugzilla.kernel.org/show_bug.cgi?id=44121
--- Comment #9 from Jean Delvare 2012-07-03 18:08:29
---
Patch from comment #6 doesn't work, testing patch from comment #7 now.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail b
On Tue, Jul 3, 2012 at 6:02 PM, David Witbrodt
wrote:
> Maybe I'm doing something wrong, but my cloned repo of
> drm-radeon-testing is giving build errors. What I'm
> seeing is
Oh I wasn't aware anyone still used it, I just pushed a branch for
Jerome the other day to test something, its known b
https://bugzilla.kernel.org/show_bug.cgi?id=44121
--- Comment #10 from Jean Delvare 2012-07-03 18:56:15
---
Patch from comment #7 did not work either. Then I followed the instructions
from comment #8, but it also did not help.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cg
https://bugzilla.kernel.org/show_bug.cgi?id=44121
Alex Deucher changed:
What|Removed |Added
Attachment #74711|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=44121
--- Comment #12 from Jean Delvare 2012-07-03 21:40:52
---
Patch from comment #11 didn't work at all, not only it didn't fix the original
issue but it even caused additional trouble (gdm wouldn't even show up.)
--
Configure bugmail: https:/
> Oh I wasn't aware anyone still used it, I just pushed a branch for
> Jerome the other day to test something, its known broken.
Oh, boy... sorry for the noise, then. This was caused by
the way I am using git: I cloned the Linus Torvalds tree,
and then used 'git add' to include several tree
83 matches
Mail list logo
