Reply-To: akpm@linux-foundation.org

On Mon, 19 Mar 2007 03:19:31 -0700 bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=8232
> 
>            Summary: Creator3D Framebuffer (sparc64) on Sbus/UPA workstation
>     Kernel Version: ALL 2.6
>             Status: NEW
>           Severity: normal
>              Owner: jsimmons@infradead.org
>          Submitter: mt1@systella.fr
> 
> 
> Most recent kernel where this bug did *NOT* occur: 2.4.34.1
> Distribution: Debian/testing
> Hardware Environment: U1E/170 with Creator3D (UPA), U2 with creator3D
> Software Environment: debian without X on U1E, debian with Xorg on U2
> Problem Description: Console is white foreground and blanck background by
> default. Sometimes, the screen is cut like this :
> 
> N | N | N | N
> --+---+---+---
> N | G | G | G
> --+---+---+---
> N | W | W | W
> --+---+---+---
> N | G | G | G
> 
> 
> where N is a 'normal' console, 'G' a 'like grey' console (black and white pixels
> like snow), and 'W' a white console (many white pixels). I have tested some
> differents Creator3D fb and this trouble only occurs on Sbus/UPA workstation. On
> a U60 (PCI/UPA), I never see it.
> 
> When I launch Xorg, problem goes away.
> 
> Sometimes, on the same configuration, when X is running, console is not usable
> because foreground _and_ background are black (and a signal is given by the
> framebuffer, screen remains on).
> 
> Steps to reproduce: U1 or U2 with 2.6 kernel and Creator3D fb on UPA Slot.
> I have tested with Creator3D Rev1.
> 
> Regards,
> 
> JKB
> 
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.

*** Bug 8233 has been marked as a duplicate of this bug. ***

*** Bug 8234 has been marked as a duplicate of this bug. ***

I've also been seeing a similar problem for a while with various 2.6 kernels
(currently on 2.6.20). I'll attach a photo showing the problem.

The unusual thing is that this doesn't occur immediately when the
display/framebuffer is initialised -- in fact, it always happens some time after
boot has finished. It might happen after 1 in 10 boots of the system.
The machine doesn't run X, so I haven't seen the problem of both foreground and
background being black.

I'm running Debian Testing on a Sun E450 with a Creator Series 1.

Created attachment 10832 [details]
Photo showing the screen corruption

Reply-To: davem@davemloft.net

From: Andrew Morton <akpm@linux-foundation.org>
Date: Mon, 19 Mar 2007 03:34:25 -0800

> On Mon, 19 Mar 2007 03:19:31 -0700 bugme-daemon@bugzilla.kernel.org wrote:
> 
> > http://bugzilla.kernel.org/show_bug.cgi?id=8232
> > 
> >            Summary: Creator3D Framebuffer (sparc64) on Sbus/UPA workstation
> >     Kernel Version: ALL 2.6
> >             Status: NEW
> >           Severity: normal
> >              Owner: jsimmons@infradead.org
> >          Submitter: mt1@systella.fr
> > 
> > 
> > Most recent kernel where this bug did *NOT* occur: 2.4.34.1
> > Distribution: Debian/testing
> > Hardware Environment: U1E/170 with Creator3D (UPA), U2 with creator3D
> > Software Environment: debian without X on U1E, debian with Xorg on U2
> > Problem Description: Console is white foreground and blanck background by
> > default. Sometimes, the screen is cut like this :
> > 
> > N | N | N | N
> > --+---+---+---
> > N | G | G | G
> > --+---+---+---
> > N | W | W | W
> > --+---+---+---
> > N | G | G | G
> > 
> > 
> > where N is a 'normal' console, 'G' a 'like grey' console (black and white pixels
> > like snow), and 'W' a white console (many white pixels). I have tested some
> > differents Creator3D fb and this trouble only occurs on Sbus/UPA workstation. On
> > a U60 (PCI/UPA), I never see it.
> > 
> > When I launch Xorg, problem goes away.

A quick audit found that we're using the ->dac_rev value before
setting it properly.  One difference between the older creator
cards and the newer ones is the DAC, so perhaps this was the
bug.

Can you test the following patch?  Thanks.  I'll fire up some of
my older systems to see if I can reproduce this one.

commit 2c4f1add7dd2747cd79c220c24e1dbc3dc4a315f
Author: David S. Miller <davem@sunset.davemloft.net>
Date:   Mon Mar 26 16:10:52 2007 -0700

    [FFB]: Initialize dac_rev before using it.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/drivers/video/ffb.c b/drivers/video/ffb.c
index 15854ae..3c01f45 100644
--- a/drivers/video/ffb.c
+++ b/drivers/video/ffb.c
@@ -948,8 +948,9 @@ static int ffb_init_one(struct of_device *op)
 	if ((upa_readl(&fbc->ucsr) & FFB_UCSR_ALL_ERRORS) != 0)
 		upa_writel(FFB_UCSR_ALL_ERRORS, &fbc->ucsr);
 
-	ffb_switch_from_graph(&all->par);
-
+	/* Determine the DAC revision, we must do this before calling
+	 * ffb_switch_from_graph().
+	 */
 	dac = all->par.dac;
 	upa_writel(0x8000, &dac->type);
 	all->par.dac_rev = upa_readl(&dac->value) >> 0x1c;
@@ -960,6 +961,8 @@ static int ffb_init_one(struct of_device *op)
 	if (all->par.flags & FFB_FLAG_AFB)
 		all->par.dac_rev = 10;
 
+	ffb_switch_from_graph(&all->par);
+
 	/* Unblank it just to be sure.  When there are multiple
 	 * FFB/AFB cards in the system, or it is not the OBP
 	 * chosen console, it will have video outputs off in

Reply-To: joel.bertrand@systella.fr

David Miller a 

Reply-To: davem@davemloft.net

From: BERTRAND_Jo

On Tuesday 27 March 2007 00:12, David Miller wrote:
>
> A quick audit found that we're using the ->dac_rev value before
> setting it properly.  One difference between the older creator
> cards and the newer ones is the DAC, so perhaps this was the
> bug.
>
> Can you test the following patch?  Thanks.  I'll fire up some of
> my older systems to see if I can reproduce this one.
>

I've also been seeing this issue, so I can test your fix. Unfortunately this 
is not something that reproduces itself reliably, so it may be a while before 
I can be sure if the fix has worked.

Thanks,
David.

Any updates on testing of the patch?
(Joel, if you system freezes you may still be able to test the patch by patching and compiling the source on a different system say, then transferring and installing new kernel on U2. There is probably a way for you to do this somehow).
Thanks.

I can confirm that I've not seen the issue since I applied the patch. I can't say for sure that it has fixed it, since the issue would only happen occasionally on my system, but it looks good. The patch certainly hasn't broken anything, anyway.

The freeze I have seen has been fixed (IOMMU/Sbus patch) a long time ago. I haven't see any framebuffer trouble when X runs on this workstation. But the last upgrade has broken X and I have to work with text console or with a degraded X mode. On both, I can see the original trouble with randmom black, grey and white squares or lines on the screen. This trouble _only_ occurs on a Creator3D (model 1) in a U2. It is not a broken hardware because I have tried with another Creator3D.

I think that original patch has fixed a part of this bug, but only a part.

Regards,

JKB

We expect this was fixed by commit 37db9a348ad4250bd6009cec1bb108a653d1d220
on March 26.  (2.6.17 and later).  I'll tentatively close the bug, thanks.

I use a regular 2.6.22.1 on U2/SMP workstation with Creator3D, and I can see this bug. Today, it only occurs when creator3D enters (or returns from) powersave mode. It only occurs with creator3D R1 framebuffer (UPA connector like Sbus).

Regards,

JKB

ho mum, drat, thanks.  reopening...

Closing as obsolete - reopen if incorrect