[Bug #11875] radeonfb lockup in .28-rc (bisected)

[Bug #11875] radeonfb lockup in .28-rc (bisected)

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.27.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11875
Subject		: radeonfb lockup in .28-rc (bisected)
Submitter	: James Cloos <cloos-GRsvFm/Gh/pBDgjK7y7TUQ@public.gmane.org>
Date		: 2008-10-28 0:00 (6 days old)
References	: http://marc.info/?l=linux-kernel&m=122515210200530&w=4
Handled-By	: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>

[Bug #11875] radeonfb lockup in .28-rc (bisected)

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.27.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11875
Subject		: radeonfb lockup in .28-rc (bisected)
Submitter	: James Cloos <cloos-GRsvFm/Gh/pBDgjK7y7TUQ@public.gmane.org>
Date		: 2008-10-28 0:00 (13 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b1ee26bab14886350ba12a5c10cbc0696ac679bf
References	: http://marc.info/?l=linux-kernel&m=122515210200530&w=4
Handled-By	: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>

Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

[Benjamin Herrenschmidt]

On Sun, 2008-11-09 at 18:59 +0100, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.27.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11875
> Subject		: radeonfb lockup in .28-rc (bisected)
> Submitter	: James Cloos <cloos-GRsvFm/Gh/pBDgjK7y7TUQ@public.gmane.org>
> Date		: 2008-10-28 0:00 (13 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b1ee26bab14886350ba12a5c10cbc0696ac679bf
> References	: http://marc.info/?l=linux-kernel&m=122515210200530&w=4
> Handled-By	: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> 

FYI. I'm back at work today, at which point I'll have a similar machine
to one of the victims which should allow me to either reproduce & fix,
or if I can't, send a workaround in the form of disabling that
specific acceleration unless explicitely enabled from the command line.

So expect a patch later today.

Cheers,
Ben.

Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

[Benjamin Herrenschmidt]

On Sun, 2008-11-09 at 18:59 +0100, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.27.  Please verify if it still should be listed and let me know
> (either way).

Allright, so I finally managed to find a machine to reproduce it and
I have a patch that fixes it here. I'm basically implementing the same
thing as X which is to ensure the bitmap is padded to 32 pixels. The
core fbcon has support for that to a certain extent so it's a fairly
small change.

Note that there was another bug, I think I was missing one
wait_for_fifo() though fixing that didn't make a difference here.

However, it's possible that this significantly impacts the performances,
maybe to the point where we may want to back out the imageblt
acceleration.

David, would you mind testing on your machine ? It's the one that shows
the biggest performance improvement, and I would like to know how much
it is affected by that patch. As long as the "worst case" performance
is still reasonable, I'm ok to take the hit if the improvement for you
is still significant.

Cheers,
Ben.

radeonfb: Fix accel problems with new imageblit hook

Some radeon chips have issues with color expansion of pixmaps that
aren't a multiple of 32 pixels wide. This works around it the same
way X does by requesting the right pitch alignment from fbcon and
then using the chip scissors to do clipping to the requested size.

Signed-off-by: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
---

If confirmed by the reporters (in CC), please apply for .28 as it
fixes a regression.

Index: linux-work/drivers/video/aty/radeon_accel.c
===================================================================
--- linux-work.orig/drivers/video/aty/radeon_accel.c	2008-11-10 14:05:06.000000000 +1100
+++ linux-work/drivers/video/aty/radeon_accel.c	2008-11-10 14:34:45.000000000 +1100
@@ -179,7 +179,7 @@ static void radeonfb_prim_imageblit(stru
 
 	radeonfb_set_creg(rinfo, DP_GUI_MASTER_CNTL, &rinfo->dp_gui_mc_cache,
 			  rinfo->dp_gui_mc_base |
-			  GMC_BRUSH_NONE |
+			  GMC_BRUSH_NONE | GMC_DST_CLIP_LEAVE |
 			  GMC_SRC_DATATYPE_MONO_FG_BG |
 			  ROP3_S |
 			  GMC_BYTE_ORDER_MSB_TO_LSB |
@@ -189,9 +189,6 @@ static void radeonfb_prim_imageblit(stru
 	radeonfb_set_creg(rinfo, DP_SRC_FRGD_CLR, &rinfo->dp_src_fg_cache, fg);
 	radeonfb_set_creg(rinfo, DP_SRC_BKGD_CLR, &rinfo->dp_src_bg_cache, bg);
 
-	radeon_fifo_wait(rinfo, 1);
-	OUTREG(DST_Y_X, (image->dy << 16) | image->dx);
-
 	/* Ensure the dst cache is flushed and the engine idle before
 	 * issuing the operation.
 	 *
@@ -205,13 +202,19 @@ static void radeonfb_prim_imageblit(stru
 
 	/* X here pads width to a multiple of 32 and uses the clipper to
 	 * adjust the result. Is that really necessary ? Things seem to
-	 * work ok for me without that and the doco doesn't seem to imply
+	 * work ok for me without that and the doco doesn't seem to imply]
 	 * there is such a restriction.
 	 */
-	OUTREG(DST_WIDTH_HEIGHT, (image->width << 16) | image->height);
+	radeon_fifo_wait(rinfo, 4);
+	OUTREG(SC_TOP_LEFT, (image->dy << 16) | image->dx);
+	OUTREG(SC_BOTTOM_RIGHT, ((image->dy + image->height) << 16) |
+	       (image->dx + image->width));
+	OUTREG(DST_Y_X, (image->dy << 16) | image->dx);
+
+	OUTREG(DST_HEIGHT_WIDTH, (image->height << 16) | ((image->width + 31) & ~31));
 
-	src_bytes = (((image->width * image->depth) + 7) / 8) * image->height;
-	dwords = (src_bytes + 3) / 4;
+	dwords = (image->width + 31) >> 5;
+	dwords *= image->height;
 	bits = (u32*)(image->data);
 
 	while(dwords >= 8) {
Index: linux-work/drivers/video/aty/radeon_base.c
===================================================================
--- linux-work.orig/drivers/video/aty/radeon_base.c	2008-11-10 14:01:50.000000000 +1100
+++ linux-work/drivers/video/aty/radeon_base.c	2008-11-10 14:36:26.000000000 +1100
@@ -1875,6 +1875,7 @@ static int __devinit radeon_set_fbinfo (
 	info->fbops = &radeonfb_ops;
 	info->screen_base = rinfo->fb_base;
 	info->screen_size = rinfo->mapped_vram;
+
 	/* Fill fix common fields */
 	strlcpy(info->fix.id, rinfo->name, sizeof(info->fix.id));
         info->fix.smem_start = rinfo->fb_base_phys;
@@ -1889,8 +1890,25 @@ static int __devinit radeon_set_fbinfo (
         info->fix.mmio_len = RADEON_REGSIZE;
 	info->fix.accel = FB_ACCEL_ATI_RADEON;
 
+	/* Allocate colormap */
 	fb_alloc_cmap(&info->cmap, 256, 0);
 
+	/* Setup pixmap used for acceleration */
+#define PIXMAP_SIZE	(2048 * 4)
+
+	info->pixmap.addr = kmalloc(PIXMAP_SIZE, GFP_KERNEL);
+	if (!info->pixmap.addr) {
+		printk(KERN_ERR "radeonfb: Failed to allocate pixmap !\n");
+		noaccel = 1;
+		goto bail;
+	}
+	info->pixmap.size = PIXMAP_SIZE;
+	info->pixmap.flags = FB_PIXMAP_SYSTEM;
+	info->pixmap.scan_align = 4;
+	info->pixmap.buf_align = 4;
+	info->pixmap.access_align = 32;
+
+bail:
 	if (noaccel)
 		info->flags |= FBINFO_HWACCEL_DISABLED;
 

Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

[Paul Collins]

Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:

> On Sun, 2008-11-09 at 18:59 +0100, Rafael J. Wysocki wrote:
>> This message has been generated automatically as a part of a report
>> of recent regressions.
>> 
>> The following bug entry is on the current list of known regressions
>> from 2.6.27.  Please verify if it still should be listed and let me know
>> (either way).
>
> Allright, so I finally managed to find a machine to reproduce it and
> I have a patch that fixes it here. I'm basically implementing the same
> thing as X which is to ensure the bitmap is padded to 32 pixels.

Works great here (as you might expect).

-- 
Paul Collins
Wellington, New Zealand

Dag vijandelijk luchtschip de huismeester is dood

Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

[Benjamin Herrenschmidt]

On Mon, 2008-11-10 at 20:13 +1300, Paul Collins wrote:
> Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org> writes:
> 
> > On Sun, 2008-11-09 at 18:59 +0100, Rafael J. Wysocki wrote:
> >> This message has been generated automatically as a part of a report
> >> of recent regressions.
> >> 
> >> The following bug entry is on the current list of known regressions
> >> from 2.6.27.  Please verify if it still should be listed and let me know
> >> (either way).
> >
> > Allright, so I finally managed to find a machine to reproduce it and
> > I have a patch that fixes it here. I'm basically implementing the same
> > thing as X which is to ensure the bitmap is padded to 32 pixels.
> 
> Works great here (as you might expect).

Yeah, well, Albook G4 with rv350, I think we have the same machine :-)

Ben.

Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

[David Miller]

From: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
Date: Mon, 10 Nov 2008 16:46:25 +1100

> David, would you mind testing on your machine ? It's the one that shows
> the biggest performance improvement, and I would like to know how much
> it is affected by that patch. As long as the "worst case" performance
> is still reasonable, I'm ok to take the hit if the improvement for you
> is still significant.

I will test this out at the very next opportunity.

Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

[Andreas Schwab]

Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org> writes:

> radeonfb: Fix accel problems with new imageblit hook
>
> Some radeon chips have issues with color expansion of pixmaps that
> aren't a multiple of 32 pixels wide. This works around it the same
> way X does by requesting the right pitch alignment from fbcon and
> then using the chip scissors to do clipping to the requested size.

Unfortunately this does not fix the suspend regression on PowerBook6,7.
Instead I have to use the workaround in
<http://marc.info/?l=linux-kernel&m=122515268301239&w=2>.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab-l3A5Bk7waGM@public.gmane.org
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

[Benjamin Herrenschmidt]

On Mon, 2008-11-10 at 21:39 +0100, Andreas Schwab wrote:
> Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org> writes:
> 
> > radeonfb: Fix accel problems with new imageblit hook
> >
> > Some radeon chips have issues with color expansion of pixmaps that
> > aren't a multiple of 32 pixels wide. This works around it the same
> > way X does by requesting the right pitch alignment from fbcon and
> > then using the chip scissors to do clipping to the requested size.
> 
> Unfortunately this does not fix the suspend regression on PowerBook6,7.
> Instead I have to use the workaround in
> <http://marc.info/?l=linux-kernel&m=122515268301239&w=2>.

Strange. The suspend problem happens also when X hasn't been launched at all ?

Ben.

Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

[Andreas Schwab]

Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org> writes:

> On Mon, 2008-11-10 at 21:39 +0100, Andreas Schwab wrote:
>> Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org> writes:
>> 
>> > radeonfb: Fix accel problems with new imageblit hook
>> >
>> > Some radeon chips have issues with color expansion of pixmaps that
>> > aren't a multiple of 32 pixels wide. This works around it the same
>> > way X does by requesting the right pitch alignment from fbcon and
>> > then using the chip scissors to do clipping to the requested size.
>> 
>> Unfortunately this does not fix the suspend regression on PowerBook6,7.
>> Instead I have to use the workaround in
>> <http://marc.info/?l=linux-kernel&m=122515268301239&w=2>.
>
> Strange. The suspend problem happens also when X hasn't been launched at all ?

There seems to be some race involved here.  I cannot reproduce the
problem ATM.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab-l3A5Bk7waGM@public.gmane.org
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

[Benjamin Herrenschmidt]

> There seems to be some race involved here.  I cannot reproduce the
> problem ATM.

I wonder if it's related to the new acceleration at all then.

I've tried various suspend/resume cycles in straight console mode using
directly snooze -f (kernel ioctl) and from X using ubuntu intrepid and
gnome power manager and it worked fine on a 5,6 which should be fairly
similar to your 6,7 I think.

It's possible that there's yet another X related race though. I've seen
cases of X whacking the chip -after- it has religuished the console back
to the kernel (back to KD_TEXT) in the past which is very wrong, though
I didn't spot that during my testing, there could be some race lurking
there.

Can you describe your problem more precisely ? I didn't see (or forgot)
your initial report. Did it crash on suspend or wakeup ? what symptoms ?

Note also that on PowerBooks, there's a platform hook that allows
radeonfb to wake up the video chip _very_ early, thus allowing easier
debugging of the boot process, so even races like that on wakeup would
surprise me since we do wakup up the chip before we even get a chance to
schedule userspace again (in fact before we even bring back the L2
cache !)  

Cheers,
Ben.

Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

[Andreas Schwab]

Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org> writes:

> Can you describe your problem more precisely ?

It crashes during suspend (after the console was switched away from X),
but I can only see a frame buffer with apparently random contents when
it happens.  When suspend works then those random frame buffer contents
are only briefly visible before the screen is cleared.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab-l3A5Bk7waGM@public.gmane.org
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

[Benjamin Herrenschmidt]

On Tue, 2008-11-11 at 00:54 +0100, Andreas Schwab wrote:
> 
> > Can you describe your problem more precisely ?
> 
> It crashes during suspend (after the console was switched away from X),
> but I can only see a frame buffer with apparently random contents when
> it happens.  When suspend works then those random frame buffer contents
> are only briefly visible before the screen is cleared.

Does it actually switches away from X ?

IE. You see the console before the crap on console or not ?

I've seen what you describe happening when doing snooze -f (direct
kernel ioctl) straight from within X. It seems to me that the problem
was that for some reason it didn't switch the console, which would
definitely make it crash. I need to double check what's up, it's
possible that the kernel fails to switch it properly or fails to wait
for X to ack the switch.

In any case, I doesn't seem to be directly related to those radeonfb
changes, though a clash with X like that is indeed more likely to
actually happen if radeonfb relies more heavily on acceleration.

I'll have a look later today at the console switch from X in the kernel
see if it's been broken in a way or another.

Note: I just did some tests using both echo "mem" >/sys/power/state and
snooze -f and it worked fine. IE, the console switch away from X worked.
So while I think I observed your problem once, I also cannot reproduce
it now.

I wonder if there's a race condition in the VT switch. It's possible
that it could be yet another case of X whacking the chip after it has
effectively relinguished control of the VT to the kernel, or it could be
a kernel race.

Cheers,
Ben.

Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

[Linus Torvalds]

On Tue, 11 Nov 2008, Benjamin Herrenschmidt wrote:
> 
> In any case, I doesn't seem to be directly related to those radeonfb
> changes, though a clash with X like that is indeed more likely to
> actually happen if radeonfb relies more heavily on acceleration.

Just a silly question, without actually looking at the code - since you 
now do acceleration in radeonfb, do you wait for everything to drain 
before you switch consoles? 

There could be races that depend on timing, where perhaps X is unhappy 
about being entered with the acceleration engine busy, or conversely the 
radeonfb code is unhappy about perhaps some still-in-progress X thing that 
hasn't been synchronously waited for..

Before, radeonfb_imageblit() would always end up doing a 
"radeon_engine_idle()", so in practice, I think just about any fbcon 
access ended up idling the engine. Now, we can probably do a lot more 
without syncronizing - maybe there's insufficient synchronization at the 
switch-over from X to text-mode or vice versa?

		Linus

Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

[Benjamin Herrenschmidt]

On Mon, 2008-11-10 at 18:47 -0800, Linus Torvalds wrote:
> 
> On Tue, 11 Nov 2008, Benjamin Herrenschmidt wrote:
> > 
> > In any case, I doesn't seem to be directly related to those radeonfb
> > changes, though a clash with X like that is indeed more likely to
> > actually happen if radeonfb relies more heavily on acceleration.
> 
> Just a silly question, without actually looking at the code - since you 
> now do acceleration in radeonfb, do you wait for everything to drain 
> before you switch consoles? 

radeonfb has been doing acceleration for some time :-) Just not color
expansion, only blits and solid fills (so basically scrolling). That is
a lot less common though and thus it's possible that existing races
didn't show up until now.

It does drain the engine in various cases, typically mode change,
blanking, sync callback. fbcon core should at least sync if not blank
when switching to KD_GRAPHICS (or at least used to, I need to double
check). I have additional guards also that disable use of the engine
when sleeping.

> There could be races that depend on timing, where perhaps X is unhappy 
> about being entered with the acceleration engine busy, or conversely the 
> radeonfb code is unhappy about perhaps some still-in-progress X thing that 
> hasn't been synchronously waited for..

Yes. From what's been reported, the more likely thing would be a race
when switching away from X.

> Before, radeonfb_imageblit() would always end up doing a 
> "radeon_engine_idle()", so in practice, I think just about any fbcon 
> access ended up idling the engine. Now, we can probably do a lot more 
> without syncronizing - maybe there's insufficient synchronization at the 
> switch-over from X to text-mode or vice versa?

Switch over from X should restore KD_TEXT which should turn to a call to
set_par() that idles the engine before anything gets written to the
screen, but those code path are intricated between the VT code and fbcon
and things may well be subtely broken. I'll dig later today after I'm
done with some other emergency.

At one point, I fixed a crapload of VT bugs where things were done
without any locking, nowadays, everything should pretty much be covered
by the console semaphore, but maybe there's still a problem there.
Another area to look at is X itself. I've had problems with X (or the
DRM) still whacking the card after handing back the console to the
kernel in the past, so it wouldn't surprise me if there was something
bogus there too.

I also had problems with fbcon trying to draw before it re-initialized
the card (ie, it -should- call set_par before any new draw operation
when switching back from KD_GRAPHICS, if not, we don't properly get to
reconfigure the engine before we try to use it, which can be fatal), but
those were fixed last time I looked.

Anyway, I'll dig and let you know what I find.

Cheers,
Ben.

Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

[Andreas Schwab]

It looks like you are observing the same failure mode that I do.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab-l3A5Bk7waGM@public.gmane.org
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

[Benjamin Herrenschmidt]

On Tue, 2008-11-11 at 10:31 +0100, Andreas Schwab wrote:
> It looks like you are observing the same failure mode that I do.

Yup, once, haven't reproduced it ever since though :-(

Ben.

Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

[David Miller]

From: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
Date: Mon, 10 Nov 2008 16:46:25 +1100

> David, would you mind testing on your machine ? It's the one that shows
> the biggest performance improvement, and I would like to know how much
> it is affected by that patch. As long as the "worst case" performance
> is still reasonable, I'm ok to take the hit if the improvement for you
> is still significant.

Finally got around to this, we lose about a full second in the
"cat rfc3261.txt" benchmark:

2.6.28-rc4 vanilla:

7.634
7.704
7.688

2.6.28rc4+patch:

8.712
8.685
8.702

Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

[Benjamin Herrenschmidt]

On Thu, 2008-11-13 at 15:11 -0800, David Miller wrote:
> From: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> Date: Mon, 10 Nov 2008 16:46:25 +1100
> 
> > David, would you mind testing on your machine ? It's the one that shows
> > the biggest performance improvement, and I would like to know how much
> > it is affected by that patch. As long as the "worst case" performance
> > is still reasonable, I'm ok to take the hit if the improvement for you
> > is still significant.
> 
> Finally got around to this, we lose about a full second in the
> "cat rfc3261.txt" benchmark:
> 
> 2.6.28-rc4 vanilla:
> 
> 7.634
> 7.704
> 7.688
> 
> 2.6.28rc4+patch:
> 
> 8.712
> 8.685
> 8.702

How does it compare with not having the acceleration ? ie. I don't think
I can do anything about it, except maybe optimize for the case where the
pixmap is already aligned (and thus doesn't need scissors), the main
question is is the acceleration still worth it or not at all since it's
generally not worth it on other architectures.

Cheers,
Ben.

Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

[David Miller]

From: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
Date: Fri, 14 Nov 2008 11:54:20 +1100

> How does it compare with not having the acceleration ?

I'll find out for you.

Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

[David Miller]

From: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Date: Thu, 13 Nov 2008 18:50:59 -0800 (PST)

> From: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> Date: Fri, 14 Nov 2008 11:54:20 +1100
> 
> > How does it compare with not having the acceleration ?
> 
> I'll find out for you.

It makes a huge difference, with the acceleration patch:

commit b1ee26bab14886350ba12a5c10cbc0696ac679bf
Author: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
Date:   Wed Oct 15 22:03:46 2008 -0700

    radeonfb: accelerate imageblit and other improvements

reverted, the test case takes 25 seconds or more instead of
the 7 or 8 seconds we're seeing now.

Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

[Benjamin Herrenschmidt]

> It makes a huge difference, with the acceleration patch:
> 
> commit b1ee26bab14886350ba12a5c10cbc0696ac679bf
> Author: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> Date:   Wed Oct 15 22:03:46 2008 -0700
> 
>     radeonfb: accelerate imageblit and other improvements
> 
> reverted, the test case takes 25 seconds or more instead of
> the 7 or 8 seconds we're seeing now.

Ok, thanks a lot for those tests !

So I consider the loss of perfs due to the workaround to be minor enough
here. I'll submit the patch for inclusion.

I might look at not doing the clipping in cases things are already
aligned later but I doubt it's going to be worth the pain,

Cheers,
Ben.

Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

[David Miller]

From: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
Date: Fri, 14 Nov 2008 14:29:11 +1100

> 
> So I consider the loss of perfs due to the workaround to be minor enough
> here. I'll submit the patch for inclusion.

BTW, there is a warning generated by this fix, the src_bytes
variable becomes unused or something like that.

Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

[Benjamin Herrenschmidt]

On Thu, 2008-11-13 at 20:28 -0800, David Miller wrote:
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date: Fri, 14 Nov 2008 14:29:11 +1100
> 
> > 
> > So I consider the loss of perfs due to the workaround to be minor enough
> > here. I'll submit the patch for inclusion.
> 
> BTW, there is a warning generated by this fix, the src_bytes
> variable becomes unused or something like that.

Ok thanks. I'll check that asap. I think I did remove the use some
intermediary variable indeed, probably forgot to remove its declaration
too.

Cheers,
Ben.

[Bug #11875] radeonfb lockup in .28-rc (bisected)

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.27.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11875
Subject		: radeonfb lockup in .28-rc (bisected)
Submitter	: James Cloos <cloos-GRsvFm/Gh/pBDgjK7y7TUQ@public.gmane.org>
Date		: 2008-10-28 0:00 (20 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b1ee26bab14886350ba12a5c10cbc0696ac679bf
References	: http://marc.info/?l=linux-kernel&m=122515210200530&w=4
		  http://lkml.org/lkml/2008/11/10/12
Handled-By	: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
Patch		: http://lkml.org/lkml/2008/11/10/12

Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

[Benjamin Herrenschmidt]

On Tue, 2008-11-11 at 10:31 +0100, Andreas Schwab wrote:
> It looks like you are observing the same failure mode that I do.

The lockup when shutting down isn't happening for me anymore with recent
X (ubuntu intrepid) btw.

I haven't quite figured out what's up yet.

Cheers,
Ben.

Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

[Benjamin Herrenschmidt]

On Tue, 2008-11-11 at 10:31 +0100, Andreas Schwab wrote:
> It looks like you are observing the same failure mode that I do.

BTW> I've been running a torture scripts that does an ls -lR / in a
console and constantly chvt between that console and X and so far
haven't got it to crash...

Cheers,
Ben.

2.6.28-rc6-git1: Reported regressions from 2.6.27

[Rafael J. Wysocki]

This message contains a list of some regressions from 2.6.27, for which there
are no fixes in the mainline I know of.  If any of them have been fixed already,
please let me know.

If you know of any other unresolved regressions from 2.6.27, please let me know
either and I'll add them to the list.  Also, please let me know if any of the
entries below are invalid.

Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.


Listed regressions statistics:

  Date          Total  Pending  Unresolved
  ----------------------------------------
  2008-11-22       93       25          15
  2008-11-16       89       32          18
  2008-11-09       73       40          27
  2008-11-02       55       41          29
  2008-10-25       26       25          20


Unresolved regressions
----------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12064
Subject		: [regression] Measured 688 cycles TSC warp; marking TSC unstable
Submitter	: Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org>
Date		: 2008-11-16 19:27:43 (7 days old)
References	: http://marc.info/?l=linux-kernel&m=122686370308852&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12061
Subject		: snd_hda_intel: power_save: sound cracks on powerdown
Submitter	: Jens Weibler <bugzilla-kernel-6hJTtV8wudIr9FUcG+3rRQ@public.gmane.org>
Date		: 2008-11-18 12:07 (5 days old)
Handled-By	: Takashi Iwai <tiwai-l3A5Bk7waGM@public.gmane.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12034
Subject		: snd-hda-intel on Realtek ALC268 chip shows only Master volume (for playback)
Submitter	: Sergey <azure-IGUVrPOATOfsG83rWm+8vg@public.gmane.org>
Date		: 2008-11-15 04:20 (8 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12031
Subject		: DRM enabled kernel hangs hard on resume on x60
Submitter	: Jens Axboe <jens.axboe-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Date		: 2008-11-12 18:42 (11 days old)
References	: http://marc.info/?l=linux-kernel&m=122651551216820&w=4
Handled-By	: Jesse Barnes <jbarnes-Y1mF5jBUw70BENJcbMCuUQ@public.gmane.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12028
Subject		: i915 DRM is broken in 2.6.28-rc4
Submitter	: Adam Tkac <vonsch-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-11-14 01:50 (9 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11996
Subject		: Tracing framework regression in 2.6.28-rc3
Submitter	: Pekka Paalanen <pq-X3B1VOXEql0@public.gmane.org>
Date		: 2008-11-09 10:13 (14 days old)
References	: http://marc.info/?l=linux-kernel&m=122624392229317&w=4
Handled-By	: Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11970
Subject		: gettimeofday return a old time in mmbench
Submitter	: alexs <alex.shi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date		: 2008-11-06 23:57 (17 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=99ebcf8285df28f32fd2d1c19a7166e70f00309c
Handled-By	: Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
		  Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
		  Yanmin Zhang <yanmin_zhang-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11965
Subject		: regression introduced by - timers: fix itimer/many thread hang
Submitter	: Doug Chapman <doug.chapman-VXdhtT5mjnY@public.gmane.org>
Date		: 2008-11-06 11:03 (17 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f06febc96ba8e0af80bcc3eaec0a109e88275fac
References	: http://marc.info/?l=linux-kernel&m=122596943416648&w=4
Handled-By	: Frank Mayhar <fmayhar-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
		  Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
		  Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11958
Subject		: [2.6.27.x =&gt; 2.6.28-rc3] Xorg crash with xf86MapVidMem error
Submitter	: Tomasz Chmielewski <tch-Nem3ZqsbT/g@public.gmane.org>
Date		: 2008-11-05 05:37 (18 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11947
Subject		: 2.6.28-rc VC switching with Intel graphics broken
Submitter	: Romano Giannetti <romano.giannetti-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-11-03 12:10 (20 days old)
Handled-By	: Jesse Barnes <jbarnes-Y1mF5jBUw70BENJcbMCuUQ@public.gmane.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11913
Subject		: USB/INPUT: slab error in cache_alloc_debugcheck_after(): double free?
Submitter	: Helge Deller <deller-Mmb7MZpHnFY@public.gmane.org>
Date		: 2008-10-30 23:11 (24 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=cb8f488c33539f096580e202f5438a809195008f
References	: http://marc.info/?l=linux-kernel&m=122540833301394&w=4
Handled-By	: Jiri Kosina <jkosina-AlSwsSmVLrQ@public.gmane.org>
		  Jiri Slaby <jirislaby-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
		  Jiri Kosina <jkosina-AlSwsSmVLrQ@public.gmane.org>
		  Jiri Slaby <jirislaby-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
		  Denys Vlasenko <vda.linux-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11906
Subject		: 2.6.28-rc2 seems to fail at powering down the monitor when it should
Submitter	: Gene Heskett <gene.heskett-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-10-30 6:39 (24 days old)
References	: http://marc.info/?l=linux-kernel&m=122534879721424&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11858
Subject		: Timeout regression introduced by 242f9dcb8ba6f68fcd217a119a7648a4f69290e9
Submitter	: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Date		: 2008-10-26 9:46 (28 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=242f9dcb8ba6f68fcd217a119a7648a4f69290e9
References	: http://marc.info/?l=linux-kernel&m=122501447326698&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11849
Subject		: default IRQ affinity change in v2.6.27 (breaking several SMP PPC based systems)
Submitter	: Kumar Gala <galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
Date		: 2008-10-24 12:45 (30 days old)
References	: http://marc.info/?l=linux-kernel&m=122485245924125&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11828
Subject		: Linux 2.6.27-git3: no SD card reader
Submitter	: J.A. Magallón <jamagallon-sh/6fXdz2Rs@public.gmane.org>
Date		: 2008-10-14 0:54 (40 days old)
References	: http://marc.info/?l=linux-kernel&m=122394573904699&w=4


Regressions with patches
------------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12082
Subject		: IRQ and MSI allocations broken without sparse irq
Submitter	: Jesper Dangaard Brouer <hawk-dAYI7NvHqcQ@public.gmane.org>
Date		: 2008-11-20 19:48 (3 days old)
References	: http://marc.info/?l=linux-kernel&m=122721060501073&w=4
Handled-By	: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Patch		: http://marc.info/?l=linux-kernel&m=122722773824802&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12081
Subject		: xen: pin correct PGD on suspend
Submitter	: Ian Campbell <Ian.Campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
Date		: 2008-11-21 10:21 (2 days old)
References	: http://marc.info/?l=linux-kernel&m=122726293324850&w=4
Handled-By	: Ian Campbell <Ian.Campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
Patch		: http://marc.info/?l=linux-kernel&m=122726293324850&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12047
Subject		: ACPI toshiba: only register rfkill if bt is enabled
Submitter	: Andrey Borzenkov <arvidjaar-JGs/UdohzUI@public.gmane.org>
Date		: 2008-10-28 19:10 (26 days old)
References	: http://marc.info/?l=linux-kernel&m=122522113619025&w=2
Handled-By	: Frederik Deweerdt <frederik.deweerdt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Patch		: http://marc.info/?l=linux-kernel&m=122526843117478&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12038
Subject		: Suspend regression in stable kernel 2.6.27.4 on Mac mini Core Duo
Submitter	: Tino Keitel <tino.keitel-Mmb7MZpHnFY@public.gmane.org>
Date		: 2008-11-09 20:28 (14 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=66036f5862883fcc9f7ff8550685a5a3de1a57e4
References	: http://marc.info/?l=linux-kernel&m=122626258429689&w=4
Handled-By	: Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>
Patch		: http://marc.info/?l=linux-kernel&m=122661443120581&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12020
Subject		: scsi_times_out NULL pointer dereference
Submitter	: Bernd Schubert <bs-PKu+Ek1N2UGzQB+pC5nmwQ@public.gmane.org>
Date		: 2008-11-13 10:30 (10 days old)
Handled-By	: James Bottomley <James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
Patch		: http://bugzilla.kernel.org/show_bug.cgi?id=12020#c4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11982
Subject		: Fan level 7 after resume wit 2.6.28-rc3
Submitter	: Tino Keitel <tino.keitel-rAwCM5oiXHA@public.gmane.org>
Date		: 2008-11-05 7:33 (18 days old)
References	: http://marc.info/?l=linux-kernel&m=122587043409186&w=4
Handled-By	: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>
Patch		: http://bugzilla.kernel.org/attachment.cgi?id=18744&action=view


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11925
Subject		: cdrom: missing compat ioctls
Submitter	: Andreas Schwab <schwab-l3A5Bk7waGM@public.gmane.org>
Date		: 2008-10-31 14:02 (23 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=33c2dca4957bd0da3e1af7b96d0758d97e708ef6
Handled-By	: Andreas Schwab <schwab-l3A5Bk7waGM@public.gmane.org>
Patch		: http://marc.info/?l=linux-kernel&m=122548923531545&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11898
Subject		: mke2fs hang on AIC79 device.
Submitter	: alexs <alex.shi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date		: 2008-10-30 01:17 (24 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f0c0a376d0fcd4c5579ecf5e95f88387cba85211
Handled-By	: James Bottomley <James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
		  Mike Christie <michaelc-hcNo3dDEHLuVc3sceRu5cw@public.gmane.org>
Patch		: http://bugzilla.kernel.org/show_bug.cgi?id=11898#c28
		  http://bugzilla.kernel.org/show_bug.cgi?id=11898#c36


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11875
Subject		: radeonfb lockup in .28-rc (bisected)
Submitter	: James Cloos <cloos-GRsvFm/Gh/pBDgjK7y7TUQ@public.gmane.org>
Date		: 2008-10-28 0:00 (26 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b1ee26bab14886350ba12a5c10cbc0696ac679bf
References	: http://marc.info/?l=linux-kernel&m=122515210200530&w=4
		  http://lkml.org/lkml/2008/11/10/12
Handled-By	: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
Patch		: http://lkml.org/lkml/2008/11/10/12


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11822
Subject		: ACPI Warning (nspredef-0858): _SB_.PCI0.LPC_.EC__.BAT0._BIF: Return Package type mismatch at index 9 - found Buffer, expected String [20080926]
Submitter	: Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date		: 2008-10-25 01:26 (29 days old)
Handled-By	: Robert Moore <Robert.Moore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
		  Lin Ming <ming.m.lin-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Patch		: http://bugzilla.kernel.org/attachment.cgi?id=18949&action=view


For details, please visit the bug entries and follow the links given in
references.

As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 2.6.27,
unresolved as well as resolved, at:

http://bugzilla.kernel.org/show_bug.cgi?id=11808

Please let me know if there are any Bugzilla entries that should be added to
the list in there.

Thanks,
Rafael

[Bug #11822] ACPI Warning (nspredef-0858): _SB_.PCI0.LPC_.EC__.BAT0._BIF: Return Package type mismatch at index 9 - found Buffer, expected String [20080926]

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.27.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11822
Subject		: ACPI Warning (nspredef-0858): _SB_.PCI0.LPC_.EC__.BAT0._BIF: Return Package type mismatch at index 9 - found Buffer, expected String [20080926]
Submitter	: Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date		: 2008-10-25 01:26 (29 days old)
Handled-By	: Robert Moore <Robert.Moore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
		  Lin Ming <ming.m.lin-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Patch		: http://bugzilla.kernel.org/attachment.cgi?id=18949&action=view

[Bug #11858] Timeout regression introduced by 242f9dcb8ba6f68fcd217a119a7648a4f69290e9

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.27.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11858
Subject		: Timeout regression introduced by 242f9dcb8ba6f68fcd217a119a7648a4f69290e9
Submitter	: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Date		: 2008-10-26 9:46 (28 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=242f9dcb8ba6f68fcd217a119a7648a4f69290e9
References	: http://marc.info/?l=linux-kernel&m=122501447326698&w=4

[Bug #11828] Linux 2.6.27-git3: no SD card reader

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.27.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11828
Subject		: Linux 2.6.27-git3: no SD card reader
Submitter	: J.A. Magallón <jamagallon-sh/6fXdz2Rs@public.gmane.org>
Date		: 2008-10-14 0:54 (40 days old)
References	: http://marc.info/?l=linux-kernel&m=122394573904699&w=4

[Bug #11849] default IRQ affinity change in v2.6.27 (breaking several SMP PPC based systems)

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.27.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11849
Subject		: default IRQ affinity change in v2.6.27 (breaking several SMP PPC based systems)
Submitter	: Kumar Gala <galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
Date		: 2008-10-24 12:45 (30 days old)
References	: http://marc.info/?l=linux-kernel&m=122485245924125&w=4

[Bug #11875] radeonfb lockup in .28-rc (bisected)

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.27.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11875
Subject		: radeonfb lockup in .28-rc (bisected)
Submitter	: James Cloos <cloos-GRsvFm/Gh/pBDgjK7y7TUQ@public.gmane.org>
Date		: 2008-10-28 0:00 (26 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b1ee26bab14886350ba12a5c10cbc0696ac679bf
References	: http://marc.info/?l=linux-kernel&m=122515210200530&w=4
		  http://lkml.org/lkml/2008/11/10/12
Handled-By	: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
Patch		: http://lkml.org/lkml/2008/11/10/12

[Bug #11898] mke2fs hang on AIC79 device.

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.27.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11898
Subject		: mke2fs hang on AIC79 device.
Submitter	: alexs <alex.shi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date		: 2008-10-30 01:17 (24 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f0c0a376d0fcd4c5579ecf5e95f88387cba85211
Handled-By	: James Bottomley <James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
		  Mike Christie <michaelc-hcNo3dDEHLuVc3sceRu5cw@public.gmane.org>
Patch		: http://bugzilla.kernel.org/show_bug.cgi?id=11898#c28
		  http://bugzilla.kernel.org/show_bug.cgi?id=11898#c36

[Bug #11913] USB/INPUT: slab error in cache_alloc_debugcheck_after(): double free?

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.27.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11913
Subject		: USB/INPUT: slab error in cache_alloc_debugcheck_after(): double free?
Submitter	: Helge Deller <deller-Mmb7MZpHnFY@public.gmane.org>
Date		: 2008-10-30 23:11 (24 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=cb8f488c33539f096580e202f5438a809195008f
References	: http://marc.info/?l=linux-kernel&m=122540833301394&w=4
Handled-By	: Jiri Kosina <jkosina-AlSwsSmVLrQ@public.gmane.org>
		  Jiri Slaby <jirislaby-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
		  Jiri Kosina <jkosina-AlSwsSmVLrQ@public.gmane.org>
		  Jiri Slaby <jirislaby-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
		  Denys Vlasenko <vda.linux-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>

[Bug #11925] cdrom: missing compat ioctls

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.27.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11925
Subject		: cdrom: missing compat ioctls
Submitter	: Andreas Schwab <schwab-l3A5Bk7waGM@public.gmane.org>
Date		: 2008-10-31 14:02 (23 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=33c2dca4957bd0da3e1af7b96d0758d97e708ef6
Handled-By	: Andreas Schwab <schwab-l3A5Bk7waGM@public.gmane.org>
Patch		: http://marc.info/?l=linux-kernel&m=122548923531545&w=2

[Bug #11906] 2.6.28-rc2 seems to fail at powering down the monitor when it should

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.27.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11906
Subject		: 2.6.28-rc2 seems to fail at powering down the monitor when it should
Submitter	: Gene Heskett <gene.heskett-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-10-30 6:39 (24 days old)
References	: http://marc.info/?l=linux-kernel&m=122534879721424&w=4

[Bug #11958] [2.6.27.x => 2.6.28-rc3] Xorg crash with xf86MapVidMem error

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.27.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11958
Subject		: [2.6.27.x => 2.6.28-rc3] Xorg crash with xf86MapVidMem error
Submitter	: Tomasz Chmielewski <tch-Nem3ZqsbT/g@public.gmane.org>
Date		: 2008-11-05 05:37 (18 days old)

[Bug #11947] 2.6.28-rc VC switching with Intel graphics broken

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.27.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11947
Subject		: 2.6.28-rc VC switching with Intel graphics broken
Submitter	: Romano Giannetti <romano.giannetti-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-11-03 12:10 (20 days old)
Handled-By	: Jesse Barnes <jbarnes-Y1mF5jBUw70BENJcbMCuUQ@public.gmane.org>

[Bug #11965] regression introduced by - timers: fix itimer/many thread hang

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.27.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11965
Subject		: regression introduced by - timers: fix itimer/many thread hang
Submitter	: Doug Chapman <doug.chapman-VXdhtT5mjnY@public.gmane.org>
Date		: 2008-11-06 11:03 (17 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f06febc96ba8e0af80bcc3eaec0a109e88275fac
References	: http://marc.info/?l=linux-kernel&m=122596943416648&w=4
Handled-By	: Frank Mayhar <fmayhar-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
		  Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
		  Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>

[Bug #11996] Tracing framework regression in 2.6.28-rc3

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.27.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11996
Subject		: Tracing framework regression in 2.6.28-rc3
Submitter	: Pekka Paalanen <pq-X3B1VOXEql0@public.gmane.org>
Date		: 2008-11-09 10:13 (14 days old)
References	: http://marc.info/?l=linux-kernel&m=122624392229317&w=4
Handled-By	: Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org>

[Bug #11970] gettimeofday return a old time in mmbench

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.27.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11970
Subject		: gettimeofday return a old time in mmbench
Submitter	: alexs <alex.shi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date		: 2008-11-06 23:57 (17 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=99ebcf8285df28f32fd2d1c19a7166e70f00309c
Handled-By	: Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
		  Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
		  Yanmin Zhang <yanmin_zhang-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>

[Bug #12020] scsi_times_out NULL pointer dereference

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.27.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12020
Subject		: scsi_times_out NULL pointer dereference
Submitter	: Bernd Schubert <bs-PKu+Ek1N2UGzQB+pC5nmwQ@public.gmane.org>
Date		: 2008-11-13 10:30 (10 days old)
Handled-By	: James Bottomley <James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
Patch		: http://bugzilla.kernel.org/show_bug.cgi?id=12020#c4

[Bug #11982] Fan level 7 after resume wit 2.6.28-rc3

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.27.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11982
Subject		: Fan level 7 after resume wit 2.6.28-rc3
Submitter	: Tino Keitel <tino.keitel-rAwCM5oiXHA@public.gmane.org>
Date		: 2008-11-05 7:33 (18 days old)
References	: http://marc.info/?l=linux-kernel&m=122587043409186&w=4
Handled-By	: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>
Patch		: http://bugzilla.kernel.org/attachment.cgi?id=18744&action=view

[Bug #12031] DRM enabled kernel hangs hard on resume on x60

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.27.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12031
Subject		: DRM enabled kernel hangs hard on resume on x60
Submitter	: Jens Axboe <jens.axboe-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Date		: 2008-11-12 18:42 (11 days old)
References	: http://marc.info/?l=linux-kernel&m=122651551216820&w=4
Handled-By	: Jesse Barnes <jbarnes-Y1mF5jBUw70BENJcbMCuUQ@public.gmane.org>

[Bug #12034] snd-hda-intel on Realtek ALC268 chip shows only Master volume (for playback)

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.27.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12034
Subject		: snd-hda-intel on Realtek ALC268 chip shows only Master volume (for playback)
Submitter	: Sergey <azure-IGUVrPOATOfsG83rWm+8vg@public.gmane.org>
Date		: 2008-11-15 04:20 (8 days old)

[Bug #12028] i915 DRM is broken in 2.6.28-rc4

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.27.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12028
Subject		: i915 DRM is broken in 2.6.28-rc4
Submitter	: Adam Tkac <vonsch-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-11-14 01:50 (9 days old)

[Bug #12038] Suspend regression in stable kernel 2.6.27.4 on Mac mini Core Duo

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.27.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12038
Subject		: Suspend regression in stable kernel 2.6.27.4 on Mac mini Core Duo
Submitter	: Tino Keitel <tino.keitel-Mmb7MZpHnFY@public.gmane.org>
Date		: 2008-11-09 20:28 (14 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=66036f5862883fcc9f7ff8550685a5a3de1a57e4
References	: http://marc.info/?l=linux-kernel&m=122626258429689&w=4
Handled-By	: Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>
Patch		: http://marc.info/?l=linux-kernel&m=122661443120581&w=4

[Bug #12047] ACPI toshiba: only register rfkill if bt is enabled

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.27.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12047
Subject		: ACPI toshiba: only register rfkill if bt is enabled
Submitter	: Andrey Borzenkov <arvidjaar-JGs/UdohzUI@public.gmane.org>
Date		: 2008-10-28 19:10 (26 days old)
References	: http://marc.info/?l=linux-kernel&m=122522113619025&w=2
Handled-By	: Frederik Deweerdt <frederik.deweerdt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Patch		: http://marc.info/?l=linux-kernel&m=122526843117478&w=2

[Bug #12061] snd_hda_intel: power_save: sound cracks on powerdown

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.27.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12061
Subject		: snd_hda_intel: power_save: sound cracks on powerdown
Submitter	: Jens Weibler <bugzilla-kernel-6hJTtV8wudIr9FUcG+3rRQ@public.gmane.org>
Date		: 2008-11-18 12:07 (5 days old)
Handled-By	: Takashi Iwai <tiwai-l3A5Bk7waGM@public.gmane.org>

[Bug #12064] [regression] Measured 688 cycles TSC warp; marking TSC unstable

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.27.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12064
Subject		: [regression] Measured 688 cycles TSC warp; marking TSC unstable
Submitter	: Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org>
Date		: 2008-11-16 19:27:43 (7 days old)
References	: http://marc.info/?l=linux-kernel&m=122686370308852&w=2

[Bug #12081] xen: pin correct PGD on suspend

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.27.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12081
Subject		: xen: pin correct PGD on suspend
Submitter	: Ian Campbell <Ian.Campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
Date		: 2008-11-21 10:21 (2 days old)
References	: http://marc.info/?l=linux-kernel&m=122726293324850&w=4
Handled-By	: Ian Campbell <Ian.Campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
Patch		: http://marc.info/?l=linux-kernel&m=122726293324850&w=4

[Bug #12082] IRQ and MSI allocations broken without sparse irq

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.27.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12082
Subject		: IRQ and MSI allocations broken without sparse irq
Submitter	: Jesper Dangaard Brouer <hawk-dAYI7NvHqcQ@public.gmane.org>
Date		: 2008-11-20 19:48 (3 days old)
References	: http://marc.info/?l=linux-kernel&m=122721060501073&w=4
Handled-By	: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Patch		: http://marc.info/?l=linux-kernel&m=122722773824802&w=4

Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

[Benjamin Herrenschmidt]

On Sat, 2008-11-22 at 21:28 +0100, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.27.  Please verify if it still should be listed and let me know
> (either way).

The patch should definitely be merged as it fixes a problem. Andrew,
will you send it to Linus ? There's no fbdev maintainer anymore...

Here's the up to date patch (same as previously posted minus a warning
that was due to a now unused variable that I removed in this one). It
doesn't fix -other- problems reported with suspend & shutdown that have
been elusive so far (I really haven't reproduced despite some serious
torturing) and could be X bugs in the first place. I'll continue
investigating them but in the meantime, this should go in.

radeonfb: Fix problem with color expansion & alignment

The engine on some radeon variants locks up if color expansion is
called for non aligned source data. This patch enables a feature of
the core fbdev to request aligned input pixmaps and uses the HW
clipping engine to clip the output to the requested size

Signed-off-by: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
---

Index: linux-work/drivers/video/aty/radeon_accel.c
===================================================================
--- linux-work.orig/drivers/video/aty/radeon_accel.c	2008-11-23 10:10:16.000000000 +1100
+++ linux-work/drivers/video/aty/radeon_accel.c	2008-11-23 10:12:34.000000000 +1100
@@ -174,12 +174,12 @@ static void radeonfb_prim_imageblit(stru
 				    const struct fb_image *image,
 				    u32 fg, u32 bg)
 {
-	unsigned int src_bytes, dwords;
+	unsigned int dwords;
 	u32 *bits;
 
 	radeonfb_set_creg(rinfo, DP_GUI_MASTER_CNTL, &rinfo->dp_gui_mc_cache,
 			  rinfo->dp_gui_mc_base |
-			  GMC_BRUSH_NONE |
+			  GMC_BRUSH_NONE | GMC_DST_CLIP_LEAVE |
 			  GMC_SRC_DATATYPE_MONO_FG_BG |
 			  ROP3_S |
 			  GMC_BYTE_ORDER_MSB_TO_LSB |
@@ -189,9 +189,6 @@ static void radeonfb_prim_imageblit(stru
 	radeonfb_set_creg(rinfo, DP_SRC_FRGD_CLR, &rinfo->dp_src_fg_cache, fg);
 	radeonfb_set_creg(rinfo, DP_SRC_BKGD_CLR, &rinfo->dp_src_bg_cache, bg);
 
-	radeon_fifo_wait(rinfo, 1);
-	OUTREG(DST_Y_X, (image->dy << 16) | image->dx);
-
 	/* Ensure the dst cache is flushed and the engine idle before
 	 * issuing the operation.
 	 *
@@ -205,13 +202,19 @@ static void radeonfb_prim_imageblit(stru
 
 	/* X here pads width to a multiple of 32 and uses the clipper to
 	 * adjust the result. Is that really necessary ? Things seem to
-	 * work ok for me without that and the doco doesn't seem to imply
+	 * work ok for me without that and the doco doesn't seem to imply]
 	 * there is such a restriction.
 	 */
-	OUTREG(DST_WIDTH_HEIGHT, (image->width << 16) | image->height);
+	radeon_fifo_wait(rinfo, 4);
+	OUTREG(SC_TOP_LEFT, (image->dy << 16) | image->dx);
+	OUTREG(SC_BOTTOM_RIGHT, ((image->dy + image->height) << 16) |
+	       (image->dx + image->width));
+	OUTREG(DST_Y_X, (image->dy << 16) | image->dx);
+
+	OUTREG(DST_HEIGHT_WIDTH, (image->height << 16) | ((image->width + 31) & ~31));
 
-	src_bytes = (((image->width * image->depth) + 7) / 8) * image->height;
-	dwords = (src_bytes + 3) / 4;
+	dwords = (image->width + 31) >> 5;
+	dwords *= image->height;
 	bits = (u32*)(image->data);
 
 	while(dwords >= 8) {
Index: linux-work/drivers/video/aty/radeon_base.c
===================================================================
--- linux-work.orig/drivers/video/aty/radeon_base.c	2008-11-23 10:10:16.000000000 +1100
+++ linux-work/drivers/video/aty/radeon_base.c	2008-11-23 10:11:02.000000000 +1100
@@ -1875,6 +1875,7 @@ static int __devinit radeon_set_fbinfo (
 	info->fbops = &radeonfb_ops;
 	info->screen_base = rinfo->fb_base;
 	info->screen_size = rinfo->mapped_vram;
+
 	/* Fill fix common fields */
 	strlcpy(info->fix.id, rinfo->name, sizeof(info->fix.id));
         info->fix.smem_start = rinfo->fb_base_phys;
@@ -1889,8 +1890,25 @@ static int __devinit radeon_set_fbinfo (
         info->fix.mmio_len = RADEON_REGSIZE;
 	info->fix.accel = FB_ACCEL_ATI_RADEON;
 
+	/* Allocate colormap */
 	fb_alloc_cmap(&info->cmap, 256, 0);
 
+	/* Setup pixmap used for acceleration */
+#define PIXMAP_SIZE	(2048 * 4)
+
+	info->pixmap.addr = kmalloc(PIXMAP_SIZE, GFP_KERNEL);
+	if (!info->pixmap.addr) {
+		printk(KERN_ERR "radeonfb: Failed to allocate pixmap !\n");
+		noaccel = 1;
+		goto bail;
+	}
+	info->pixmap.size = PIXMAP_SIZE;
+	info->pixmap.flags = FB_PIXMAP_SYSTEM;
+	info->pixmap.scan_align = 4;
+	info->pixmap.buf_align = 4;
+	info->pixmap.access_align = 32;
+
+bail:
 	if (noaccel)
 		info->flags |= FBINFO_HWACCEL_DISABLED;
 

Re: [Bug #12047] ACPI toshiba: only register rfkill if bt is enabled

[Frederik Deweerdt]

On Sat, Nov 22, 2008 at 09:28:19PM +0100, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.27.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12047
> Subject		: ACPI toshiba: only register rfkill if bt is enabled
> Submitter	: Andrey Borzenkov <arvidjaar-JGs/UdohzUI@public.gmane.org>
> Date		: 2008-10-28 19:10 (26 days old)
> References	: http://marc.info/?l=linux-kernel&m=122522113619025&w=2
> Handled-By	: Frederik Deweerdt <frederik.deweerdt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Patch		: http://marc.info/?l=linux-kernel&m=122526843117478&w=2
This went to -mm, I just mailed Andrew about this and should go to
mainline soon.
Regards,
Frederik

Re: [Bug #11965] regression introduced by - timers: fix itimer/many thread hang

[Ingo Molnar]

* Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:

> This message has been generated automatically as a part of a report 
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions 
> from 2.6.27.  Please verify if it still should be listed and let me 
> know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11965
> Subject		: regression introduced by - timers: fix itimer/many thread hang
> Submitter	: Doug Chapman <doug.chapman-VXdhtT5mjnY@public.gmane.org>
> Date		: 2008-11-06 11:03 (17 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f06febc96ba8e0af80bcc3eaec0a109e88275fac
> References	: http://marc.info/?l=linux-kernel&m=122596943416648&w=4
> Handled-By	: Frank Mayhar <fmayhar-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> 		  Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
> 		  Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>

the hang is fixed by:

  commit ad474caca3e2a0550b7ce0706527ad5ab389a4d4
  Author: Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  Date:   Mon Nov 10 15:39:30 2008 +0100

    fix for account_group_exec_runtime(), make sure ->signal can't be freed under rq->lock

	Ingo

Re: [Bug #11965] regression introduced by - timers: fix itimer/many thread hang

[Rafael J. Wysocki]

On Sunday, 23 of November 2008, Ingo Molnar wrote:
> 
> * Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> 
> > This message has been generated automatically as a part of a report 
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions 
> > from 2.6.27.  Please verify if it still should be listed and let me 
> > know (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11965
> > Subject		: regression introduced by - timers: fix itimer/many thread hang
> > Submitter	: Doug Chapman <doug.chapman-VXdhtT5mjnY@public.gmane.org>
> > Date		: 2008-11-06 11:03 (17 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f06febc96ba8e0af80bcc3eaec0a109e88275fac
> > References	: http://marc.info/?l=linux-kernel&m=122596943416648&w=4
> > Handled-By	: Frank Mayhar <fmayhar-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> > 		  Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
> > 		  Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
> 
> the hang is fixed by:
> 
>   commit ad474caca3e2a0550b7ce0706527ad5ab389a4d4
>   Author: Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>   Date:   Mon Nov 10 15:39:30 2008 +0100
> 
>     fix for account_group_exec_runtime(), make sure ->signal can't be freed under rq->lock

Thanks for the info and thanks for closing the bug. :-)

Rafael

Re: [Bug #11996] Tracing framework regression in 2.6.28-rc3

[Pekka Paalanen]

On Sat, 22 Nov 2008 21:28:17 +0100 (CET)
"Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote:

> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.27.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11996
> Subject		: Tracing framework regression in 2.6.28-rc3
> Submitter	: Pekka Paalanen <pq-X3B1VOXEql0@public.gmane.org>
> Date		: 2008-11-09 10:13 (14 days old)
> References	: http://marc.info/?l=linux-kernel&m=122624392229317&w=4
> Handled-By	: Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org>

Tested 2.6.28-rc6, this bug is fixed.

-- 
Pekka Paalanen
http://www.iki.fi/pq/

Re: [Bug #11996] Tracing framework regression in 2.6.28-rc3

[Ingo Molnar]

* Pekka Paalanen <pq-X3B1VOXEql0@public.gmane.org> wrote:

> On Sat, 22 Nov 2008 21:28:17 +0100 (CET)
> "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> 
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.27.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11996
> > Subject		: Tracing framework regression in 2.6.28-rc3
> > Submitter	: Pekka Paalanen <pq-X3B1VOXEql0@public.gmane.org>
> > Date		: 2008-11-09 10:13 (14 days old)
> > References	: http://marc.info/?l=linux-kernel&m=122624392229317&w=4
> > Handled-By	: Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org>
> 
> Tested 2.6.28-rc6, this bug is fixed.

via:

commit ee51a1de7e3837577412be269e0100038068e691
Author: Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
Date:   Thu Nov 13 14:58:31 2008 +0100

    tracing: fix mmiotrace resizing crash
    
    Pekka reported a crash when resizing the mmiotrace tracer (if only
    mmiotrace is enabled).
    
    This happens because in that case we do not allocate the max buffer,
    but we try to use it.
    
    Make ring_buffer_resize() idempotent against NULL buffers.
    
    Reported-by: Pekka Paalanen <pq-X3B1VOXEql0@public.gmane.org>
    Signed-off-by: Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>

	Ingo

Re: [Bug #12064] [regression] Measured 688 cycles TSC warp; marking TSC unstable

[Frans Pop]

On Saturday 22 November 2008, Rafael J. Wysocki wrote:
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12064
> Date		: 2008-11-16 19:27:43 (7 days old)
> References	: http://marc.info/?l=linux-kernel&m=122686370308852&w=2

Looks to be fixed in -rc6:

-Calibrating delay using timer specific routine.. 6198.05 BogoMIPS (lpj=12396107)
+Calibrating delay using timer specific routine.. 6399.82 BogoMIPS (lpj=12799647)
[...]
-checking TSC synchronization [CPU#0 -> CPU#1]:
-Measured 696 cycles TSC warp between CPUs, turning off TSC clock.
-Marking TSC unstable due to check_tsc_sync_source failed
+checking TSC synchronization [CPU#0 -> CPU#1]: passed.

So, BogoMIPS value on CPU#1 is in line with CPU#0 again and TSC passes.
No idea what commit would be responsible.

Cheers,
FJP

Re: [Bug #12064] [regression] Measured 688 cycles TSC warp; marking TSC unstable

[Ingo Molnar]

* Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org> wrote:

> On Saturday 22 November 2008, Rafael J. Wysocki wrote:
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12064
> > Date		: 2008-11-16 19:27:43 (7 days old)
> > References	: http://marc.info/?l=linux-kernel&m=122686370308852&w=2
> 
> Looks to be fixed in -rc6:
> 
> -Calibrating delay using timer specific routine.. 6198.05 BogoMIPS (lpj=12396107)
> +Calibrating delay using timer specific routine.. 6399.82 BogoMIPS (lpj=12799647)
> [...]
> -checking TSC synchronization [CPU#0 -> CPU#1]:
> -Measured 696 cycles TSC warp between CPUs, turning off TSC clock.
> -Marking TSC unstable due to check_tsc_sync_source failed
> +checking TSC synchronization [CPU#0 -> CPU#1]: passed.
> 
> So, BogoMIPS value on CPU#1 is in line with CPU#0 again and TSC passes.
> No idea what commit would be responsible.

this one from Venki fixed it:

| commit 93ce99e849433ede4ce8b410b749dc0cad1100b2
| Author: Venki Pallipadi <venkatesh.pallipadi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
| Date:   Mon Nov 17 14:43:58 2008 -0800
| 
|    x86: add rdtsc barrier to TSC sync check

	Ingo

Re: [linux-pm] 2.6.28-rc6-git1: Reported regressions from 2.6.27

[Alan Stern]

On Sat, 22 Nov 2008, Rafael J. Wysocki wrote:

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11858
> Subject		: Timeout regression introduced by 242f9dcb8ba6f68fcd217a119a7648a4f69290e9
> Submitter	: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Date		: 2008-10-26 9:46 (28 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=242f9dcb8ba6f68fcd217a119a7648a4f69290e9
> References	: http://marc.info/?l=linux-kernel&m=122501447326698&w=4

This has been fixed by commit 2920ebbd65f3e80c318adf5191ac0987142bda80.

Alan Stern

Re: [Bug #11982] Fan level 7 after resume wit 2.6.28-rc3

[Tino Keitel]

On Sat, Nov 22, 2008 at 21:28:17 +0100, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.27.  Please verify if it still should be listed and let me know
> (either way).

git log drivers/misc/thinkpad_acpi.c shows no changes since August 1st,
so I thing it's save to assume that the regression still exists.

Regards,
Tino

Re: [Bug #12038] Suspend regression in stable kernel 2.6.27.4 on Mac mini Core Duo

[Tino Keitel]

On Sat, Nov 22, 2008 at 21:28:19 +0100, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.27.  Please verify if it still should be listed and let me know
> (either way).

Hi,

2.6.28-rc6 (or more precisely:
ed313489badef16d700f5a3be50e8fd8f8294bc8) still hangs my Mac after
resume, and git log drivers/acpi/sleep/main.c shows no relevant commits.

Regards,
Tino

Re: [Bug #12038] Suspend regression in stable kernel 2.6.27.4 on Mac mini Core Duo

[Justin P. Mattock]

On Mon, 2008-11-24 at 09:03 +0100, Tino Keitel wrote:
> On Sat, Nov 22, 2008 at 21:28:19 +0100, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.27.  Please verify if it still should be listed and let me know
> > (either way).
> 
> Hi,
> 
> 2.6.28-rc6 (or more precisely:
> ed313489badef16d700f5a3be50e8fd8f8294bc8) still hangs my Mac after
> resume, and git log drivers/acpi/sleep/main.c shows no relevant commits.
> 
> Regards,
> Tino
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

I'm not getting a freeze here(was getting strange cpu frequencies
though); My setup here is the latest xserver from intrepid
readeon, and s2ram app. echo mem > /sys/power/state gives
me a black screen, then an instant reboot. s2ram recovers
as expected. Although I'm not sure what the setup is with macmini,
I've a macbook pro ati chipset.

regards;
-- 
Justin P. Mattock <justinmattock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Re: [Bug #11947] 2.6.28-rc VC switching with Intel graphics broken

[Romano Giannetti (lists)]

Rafael J. Wysocki wrote:
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11947
> Subject		: 2.6.28-rc VC switching with Intel graphics broken
> Submitter	: Romano Giannetti <romano.giannetti-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date		: 2008-11-03 12:10 (20 days old)
> Handled-By	: Jesse Barnes <jbarnes-Y1mF5jBUw70BENJcbMCuUQ@public.gmane.org>
> 

Still with us on -rc6, nasty, reproducible, no clues on what can be.

VC switch locks or delay the systems minutes, resuming from suspend locks hard 
the machine.

2.6.28-rc is unusable here.

Jesse, any hints? My suspicion that it can be the same thing happened with bug 
10620 is wrong? (It was a very similar error about vblank...)

Romano

-- 
Sorry for the disclaimer --- ¡I cannot stop it!


--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.

This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. 

Re: [Bug #12031] DRM enabled kernel hangs hard on resume on x60

[Rafael J. Wysocki]

On Saturday, 22 of November 2008, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.27.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12031
> Subject		: DRM enabled kernel hangs hard on resume on x60
> Submitter	: Jens Axboe <jens.axboe-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> Date		: 2008-11-12 18:42 (11 days old)
> References	: http://marc.info/?l=linux-kernel&m=122651551216820&w=4
> Handled-By	: Jesse Barnes <jbarnes-Y1mF5jBUw70BENJcbMCuUQ@public.gmane.org>

I can reproduce this problem on Toshiba Portege R500, with the same symptoms
(please see the bug entry for details).

Well, we have at lease three DRM-related regressions in 2.6.28-rc and no
visible reaction from the developers/maintainers of the code in question. :-(

Thanks,
Rafael

Re: [Bug #12031] DRM enabled kernel hangs hard on resume on x60

[Jesse Barnes]

On Monday, November 24, 2008 5:36 am Rafael J. Wysocki wrote:
> On Saturday, 22 of November 2008, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.27.  Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12031
> > Subject		: DRM enabled kernel hangs hard on resume on x60
> > Submitter	: Jens Axboe <jens.axboe@oracle.com>
> > Date		: 2008-11-12 18:42 (11 days old)
> > References	: http://marc.info/?l=linux-kernel&m=122651551216820&w=4
> > Handled-By	: Jesse Barnes <jbarnes@virtuousgeek.org>
>
> I can reproduce this problem on Toshiba Portege R500, with the same
> symptoms (please see the bug entry for details).
>
> Well, we have at lease three DRM-related regressions in 2.6.28-rc and no
> visible reaction from the developers/maintainers of the code in question.
> :-(

Sorry, I've been away for awhile.  I'll dig through the latest info on these 
regressions today.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Bug #11947] 2.6.28-rc VC switching with Intel graphics broken

[Jesse Barnes]

On Monday, November 24, 2008 12:47 am Romano Giannetti (lists) wrote:
> Rafael J. Wysocki wrote:
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11947
> > Subject		: 2.6.28-rc VC switching with Intel graphics broken
> > Submitter	: Romano Giannetti <romano.giannetti@gmail.com>
> > Date		: 2008-11-03 12:10 (20 days old)
> > Handled-By	: Jesse Barnes <jbarnes@virtuousgeek.org>
>
> Still with us on -rc6, nasty, reproducible, no clues on what can be.
>
> VC switch locks or delay the systems minutes, resuming from suspend locks
> hard the machine.
>
> 2.6.28-rc is unusable here.
>
> Jesse, any hints? My suspicion that it can be the same thing happened with
> bug 10620 is wrong? (It was a very similar error about vblank...)

Just added to the bug, it looks like a DUP of an issue Keith just fixed last 
week (now to make sure the patch makes it upstream quickly).

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Bug #11947] 2.6.28-rc VC switching with Intel graphics broken

[Bernhard Schmidt]

Hello,

> On Monday, November 24, 2008 12:47 am Romano Giannetti (lists) wrote:
>> Rafael J. Wysocki wrote:
>>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11947
>>> Subject		: 2.6.28-rc VC switching with Intel graphics broken
>>> Submitter	: Romano Giannetti <romano.giannetti@gmail.com>
>>> Date		: 2008-11-03 12:10 (20 days old)
>>> Handled-By	: Jesse Barnes <jbarnes@virtuousgeek.org>
>> Still with us on -rc6, nasty, reproducible, no clues on what can be.
>>
>> VC switch locks or delay the systems minutes, resuming from suspend locks
>> hard the machine.
>>
>> 2.6.28-rc is unusable here.
>>
>> Jesse, any hints? My suspicion that it can be the same thing happened with
>> bug 10620 is wrong? (It was a very similar error about vblank...)
> 
> Just added to the bug, it looks like a DUP of an issue Keith just fixed last 
> week (now to make sure the patch makes it upstream quickly).

I can confirm that, with the patch from 
http://lists.freedesktop.org/archives/intel-gfx/2008-November/000614.html 
applied on top of current git head (rejected hunk in 
drivers/gpu/drm/i915/915_irq.c due to the additional 
dev_priv->irq_mask_reg = ~0; in git between the removed lines, I kept 
it) I can suspend/resume and do a VC switch again.

Big thanks!

Bernhard

Re: [Bug #11947] 2.6.28-rc VC switching with Intel graphics broken

[Jesse Barnes]

On Monday, November 24, 2008 11:13 am Bernhard Schmidt wrote:
> Hello,
>
> > On Monday, November 24, 2008 12:47 am Romano Giannetti (lists) wrote:
> >> Rafael J. Wysocki wrote:
> >>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11947
> >>> Subject		: 2.6.28-rc VC switching with Intel graphics broken
> >>> Submitter	: Romano Giannetti <romano.giannetti@gmail.com>
> >>> Date		: 2008-11-03 12:10 (20 days old)
> >>> Handled-By	: Jesse Barnes <jbarnes@virtuousgeek.org>
> >>
> >> Still with us on -rc6, nasty, reproducible, no clues on what can be.
> >>
> >> VC switch locks or delay the systems minutes, resuming from suspend
> >> locks hard the machine.
> >>
> >> 2.6.28-rc is unusable here.
> >>
> >> Jesse, any hints? My suspicion that it can be the same thing happened
> >> with bug 10620 is wrong? (It was a very similar error about vblank...)
> >
> > Just added to the bug, it looks like a DUP of an issue Keith just fixed
> > last week (now to make sure the patch makes it upstream quickly).
>
> I can confirm that, with the patch from
> http://lists.freedesktop.org/archives/intel-gfx/2008-November/000614.html
> applied on top of current git head (rejected hunk in
> drivers/gpu/drm/i915/915_irq.c due to the additional
> dev_priv->irq_mask_reg = ~0; in git between the removed lines, I kept
> it) I can suspend/resume and do a VC switch again.
>
> Big thanks!

Excellent, thanks for confirming.  I just pinged the maintainer, hopefully we 
can get this patch pushed quickly.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Bug #11947] 2.6.28-rc VC switching with Intel graphics broken

[Romano Giannetti (lists)]

[resent - sorry, LKML sent it back --- my bad]
Jesse Barnes wrote:
> 
> Just added to the bug, it looks like a DUP of an issue Keith just fixed last 
> week (now to make sure the patch makes it upstream quickly).
> 
Tried the patch and tested, it works ok. VC switching and suspend/resume 
fixed. More details on bugzilla.

Tested-by: Romano Giannetti <romano.giannetti-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Thanks to all!
     Romano

-- 
Sorry for the disclaimer --- ¡I cannot stop it!


--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.

This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. 

Re: [Bug #11947] 2.6.28-rc VC switching with Intel graphics broken

[Ingo Molnar]

* Bernhard Schmidt <berni-wpePDvIxQxvMZTq/7ZfH4Q@public.gmane.org> wrote:

> Hello,
>
>> On Monday, November 24, 2008 12:47 am Romano Giannetti (lists) wrote:
>>> Rafael J. Wysocki wrote:
>>>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11947
>>>> Subject		: 2.6.28-rc VC switching with Intel graphics broken
>>>> Submitter	: Romano Giannetti <romano.giannetti-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>> Date		: 2008-11-03 12:10 (20 days old)
>>>> Handled-By	: Jesse Barnes <jbarnes-Y1mF5jBUw70BENJcbMCuUQ@public.gmane.org>
>>> Still with us on -rc6, nasty, reproducible, no clues on what can be.
>>>
>>> VC switch locks or delay the systems minutes, resuming from suspend locks
>>> hard the machine.
>>>
>>> 2.6.28-rc is unusable here.
>>>
>>> Jesse, any hints? My suspicion that it can be the same thing happened with
>>> bug 10620 is wrong? (It was a very similar error about vblank...)
>>
>> Just added to the bug, it looks like a DUP of an issue Keith just fixed 
>> last week (now to make sure the patch makes it upstream quickly).
>
> I can confirm that, with the patch from  
> http://lists.freedesktop.org/archives/intel-gfx/2008-November/000614.html 
> applied on top of current git head (rejected hunk in  
> drivers/gpu/drm/i915/915_irq.c due to the additional  
> dev_priv->irq_mask_reg = ~0; in git between the removed lines, I kept  
> it) I can suspend/resume and do a VC switch again.
>
> Big thanks!

here it is below plaintext as well, merged up to latest -git.

	Ingo

------------------->
From 60174462808051477793776c67282364bc94ded3 Mon Sep 17 00:00:00 2001
From: Keith Packard <keithp-aN4HjG94KOLQT0dZR+AlfA@public.gmane.org>
Date: Tue, 18 Nov 2008 09:30:25 -0800
Subject: [PATCH] drm: move drm vblank initialization/cleanup to driver load/unload

drm vblank initialization keeps track of the changes in driver-supplied
frame counts across vt switch and mode setting, but only if you let it by
not tearing down the drm vblank structure.

Signed-off-by: Keith Packard <keithp-aN4HjG94KOLQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
---
 drivers/gpu/drm/drm_drv.c       |    2 ++
 drivers/gpu/drm/drm_irq.c       |    4 +---
 drivers/gpu/drm/i915/i915_dma.c |    5 +++++
 drivers/gpu/drm/i915/i915_drv.h |    2 ++
 drivers/gpu/drm/i915/i915_irq.c |    5 -----
 include/drm/drmP.h              |    1 +
 6 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 3ab1e9c..996097a 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -305,6 +305,8 @@ static void drm_cleanup(struct drm_device * dev)
 		return;
 	}
 
+	drm_vblank_cleanup(dev);
+
 	drm_lastclose(dev);
 
 	if (drm_core_has_MTRR(dev) && drm_core_has_AGP(dev) &&
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 15c8dab..1e787f8 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -94,7 +94,7 @@ static void vblank_disable_fn(unsigned long arg)
 	}
 }
 
-static void drm_vblank_cleanup(struct drm_device *dev)
+void drm_vblank_cleanup(struct drm_device *dev)
 {
 	/* Bail if the driver didn't call drm_vblank_init() */
 	if (dev->num_crtcs == 0)
@@ -278,8 +278,6 @@ int drm_irq_uninstall(struct drm_device * dev)
 
 	free_irq(dev->pdev->irq, dev);
 
-	drm_vblank_cleanup(dev);
-
 	return 0;
 }
 EXPORT_SYMBOL(drm_irq_uninstall);
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 0d215e3..9a1450e 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -856,6 +856,11 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags)
 
 	spin_lock_init(&dev_priv->user_irq_lock);
 
+	ret = drm_vblank_init(dev, I915_NUM_PIPE);
+
+	if (ret)
+		return ret;
+
 	return ret;
 }
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ef1c0b8..ec78190 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -47,6 +47,8 @@ enum pipe {
 	PIPE_B,
 };
 
+#define I915_NUM_PIPE	2
+
 /* Interface history:
  *
  * 1.1: Original.
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 82752d6..a60af31 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -483,14 +483,9 @@ void i915_driver_irq_preinstall(struct drm_device * dev)
 int i915_driver_irq_postinstall(struct drm_device *dev)
 {
 	drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev->dev_private;
-	int ret, num_pipes = 2;
-
 	/* Set initial unmasked IRQs to just the selected vblank pipes. */
 	dev_priv->irq_mask_reg = ~0;
 
-	ret = drm_vblank_init(dev, num_pipes);
-	if (ret)
-		return ret;
 
 	dev_priv->vblank_pipe = DRM_I915_VBLANK_PIPE_A | DRM_I915_VBLANK_PIPE_B;
 	dev_priv->irq_mask_reg &= ~I915_DISPLAY_PIPE_A_VBLANK_INTERRUPT;
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 28c7f16..d5e8e5c 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1151,6 +1151,7 @@ extern u32 drm_vblank_count(struct drm_device *dev, int crtc);
 extern void drm_handle_vblank(struct drm_device *dev, int crtc);
 extern int drm_vblank_get(struct drm_device *dev, int crtc);
 extern void drm_vblank_put(struct drm_device *dev, int crtc);
+extern void drm_vblank_cleanup(struct drm_device *dev);
 /* Modesetting support */
 extern int drm_modeset_ctl(struct drm_device *dev, void *data,
 			   struct drm_file *file_priv);

Re: [Bug #11947] 2.6.28-rc VC switching with Intel graphics broken

[Rafael J. Wysocki]

On Wednesday, 26 of November 2008, Ingo Molnar wrote:
> 
> * Bernhard Schmidt <berni-wpePDvIxQxvMZTq/7ZfH4Q@public.gmane.org> wrote:
> 
> > Hello,
> >
> >> On Monday, November 24, 2008 12:47 am Romano Giannetti (lists) wrote:
> >>> Rafael J. Wysocki wrote:
> >>>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11947
> >>>> Subject		: 2.6.28-rc VC switching with Intel graphics broken
> >>>> Submitter	: Romano Giannetti <romano.giannetti-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >>>> Date		: 2008-11-03 12:10 (20 days old)
> >>>> Handled-By	: Jesse Barnes <jbarnes-Y1mF5jBUw70BENJcbMCuUQ@public.gmane.org>
> >>> Still with us on -rc6, nasty, reproducible, no clues on what can be.
> >>>
> >>> VC switch locks or delay the systems minutes, resuming from suspend locks
> >>> hard the machine.
> >>>
> >>> 2.6.28-rc is unusable here.
> >>>
> >>> Jesse, any hints? My suspicion that it can be the same thing happened with
> >>> bug 10620 is wrong? (It was a very similar error about vblank...)
> >>
> >> Just added to the bug, it looks like a DUP of an issue Keith just fixed 
> >> last week (now to make sure the patch makes it upstream quickly).
> >
> > I can confirm that, with the patch from  
> > http://lists.freedesktop.org/archives/intel-gfx/2008-November/000614.html 
> > applied on top of current git head (rejected hunk in  
> > drivers/gpu/drm/i915/915_irq.c due to the additional  
> > dev_priv->irq_mask_reg = ~0; in git between the removed lines, I kept  
> > it) I can suspend/resume and do a VC switch again.
> >
> > Big thanks!
> 
> here it is below plaintext as well, merged up to latest -git.

Well, I still have a resume issue with this patch applied on Toshiba Portege
R500 (please see http://bugzilla.kernel.org/show_bug.cgi?id=12031#c9 for
details).

Thanks,
Rafael

 
> ------------------->
> From 60174462808051477793776c67282364bc94ded3 Mon Sep 17 00:00:00 2001
> From: Keith Packard <keithp-aN4HjG94KOLQT0dZR+AlfA@public.gmane.org>
> Date: Tue, 18 Nov 2008 09:30:25 -0800
> Subject: [PATCH] drm: move drm vblank initialization/cleanup to driver load/unload
> 
> drm vblank initialization keeps track of the changes in driver-supplied
> frame counts across vt switch and mode setting, but only if you let it by
> not tearing down the drm vblank structure.
> 
> Signed-off-by: Keith Packard <keithp-aN4HjG94KOLQT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
> ---
>  drivers/gpu/drm/drm_drv.c       |    2 ++
>  drivers/gpu/drm/drm_irq.c       |    4 +---
>  drivers/gpu/drm/i915/i915_dma.c |    5 +++++
>  drivers/gpu/drm/i915/i915_drv.h |    2 ++
>  drivers/gpu/drm/i915/i915_irq.c |    5 -----
>  include/drm/drmP.h              |    1 +
>  6 files changed, 11 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 3ab1e9c..996097a 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -305,6 +305,8 @@ static void drm_cleanup(struct drm_device * dev)
>  		return;
>  	}
>  
> +	drm_vblank_cleanup(dev);
> +
>  	drm_lastclose(dev);
>  
>  	if (drm_core_has_MTRR(dev) && drm_core_has_AGP(dev) &&
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 15c8dab..1e787f8 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -94,7 +94,7 @@ static void vblank_disable_fn(unsigned long arg)
>  	}
>  }
>  
> -static void drm_vblank_cleanup(struct drm_device *dev)
> +void drm_vblank_cleanup(struct drm_device *dev)
>  {
>  	/* Bail if the driver didn't call drm_vblank_init() */
>  	if (dev->num_crtcs == 0)
> @@ -278,8 +278,6 @@ int drm_irq_uninstall(struct drm_device * dev)
>  
>  	free_irq(dev->pdev->irq, dev);
>  
> -	drm_vblank_cleanup(dev);
> -
>  	return 0;
>  }
>  EXPORT_SYMBOL(drm_irq_uninstall);
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 0d215e3..9a1450e 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -856,6 +856,11 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags)
>  
>  	spin_lock_init(&dev_priv->user_irq_lock);
>  
> +	ret = drm_vblank_init(dev, I915_NUM_PIPE);
> +
> +	if (ret)
> +		return ret;
> +
>  	return ret;
>  }
>  
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index ef1c0b8..ec78190 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -47,6 +47,8 @@ enum pipe {
>  	PIPE_B,
>  };
>  
> +#define I915_NUM_PIPE	2
> +
>  /* Interface history:
>   *
>   * 1.1: Original.
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 82752d6..a60af31 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -483,14 +483,9 @@ void i915_driver_irq_preinstall(struct drm_device * dev)
>  int i915_driver_irq_postinstall(struct drm_device *dev)
>  {
>  	drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev->dev_private;
> -	int ret, num_pipes = 2;
> -
>  	/* Set initial unmasked IRQs to just the selected vblank pipes. */
>  	dev_priv->irq_mask_reg = ~0;
>  
> -	ret = drm_vblank_init(dev, num_pipes);
> -	if (ret)
> -		return ret;
>  
>  	dev_priv->vblank_pipe = DRM_I915_VBLANK_PIPE_A | DRM_I915_VBLANK_PIPE_B;
>  	dev_priv->irq_mask_reg &= ~I915_DISPLAY_PIPE_A_VBLANK_INTERRUPT;
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 28c7f16..d5e8e5c 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -1151,6 +1151,7 @@ extern u32 drm_vblank_count(struct drm_device *dev, int crtc);
>  extern void drm_handle_vblank(struct drm_device *dev, int crtc);
>  extern int drm_vblank_get(struct drm_device *dev, int crtc);
>  extern void drm_vblank_put(struct drm_device *dev, int crtc);
> +extern void drm_vblank_cleanup(struct drm_device *dev);
>  /* Modesetting support */
>  extern int drm_modeset_ctl(struct drm_device *dev, void *data,
>  			   struct drm_file *file_priv);
> 
> 



-- 
Everyone knows that debugging is twice as hard as writing a program
in the first place.  So if you're as clever as you can be when you write it,
how will you ever debug it? --- Brian Kernighan