Re: [TESTED] tdfx framebuffer garbles display in 2.6.19.5

2007-03-14 Thread DervishD
Hi Antonino :)

NEW INFORMATION ABOUT THE PROBLEM

 * Antonino A. Daplas <[EMAIL PROTECTED]> dixit:
> On Tue, 2007-03-06 at 07:25 +0100, DervishD wrote:
> > > > With the patch, the scroll slows to a crawl and the system is
> > > > unusable. The time to scroll 30 lines is about a minute or so
> > > > (probably more, I just measured for a while).
> > > > 
> > > > If you want me to test other patches, just tell :)
> > > 
> > > Can you change the mdelay to udelay and use higher/lower delay values
> > > to see if there's any improvement?
> > 
> > Yes, as soon as I can build a new kernel and reboot. Any suggested
> > value?
> 
> You can start with 5 and increment by 5.  So you need not reboot each
> time, compile tdfxfb as a module, and set CONFIG_HW_CONSOLE_BINDING=y
> (under drivers->char).

Until I discovered how to reproduce the bug, I had to reboot for
each test. But I discovered the real problem...

The garbling doesn't happen, no matter the udelay, until I start X.
Once X is started, even with an udelay(100) (which for me makes the
display untolerably slow) the problem happens.

This doesn't happen in latest 2.4.x, but I remember that some
characters "dissappeared" from the screen at some 2.4.x when X was
running. That was a known bug in the X driver of this card, so I'm not
sure if the last X.Org driver has this problem or not. Unfortunately, I
cannot test this directly, the most I can do is to test under Ubuntu,
which uses an older 2.6.x kernel.

If this new discovery doesn't ring any bell for you, I'll make a
test under Ubuntu and after that I'll just wait until I can upgrade X
(which I cannot do now) to latest X.Org (I'm now using 7.0.22).

Thanks for all your help. I'll keep you informed of any change I
notice, and (although I won't be very fast doing it...) you can count on
me to test any patch you want.

Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [TESTED] tdfx framebuffer garbles display in 2.6.19.5

2007-03-14 Thread DervishD
Hi Antonino :)

NEW INFORMATION ABOUT THE PROBLEM

 * Antonino A. Daplas [EMAIL PROTECTED] dixit:
 On Tue, 2007-03-06 at 07:25 +0100, DervishD wrote:
With the patch, the scroll slows to a crawl and the system is
unusable. The time to scroll 30 lines is about a minute or so
(probably more, I just measured for a while).

If you want me to test other patches, just tell :)
   
   Can you change the mdelay to udelay and use higher/lower delay values
   to see if there's any improvement?
  
  Yes, as soon as I can build a new kernel and reboot. Any suggested
  value?
 
 You can start with 5 and increment by 5.  So you need not reboot each
 time, compile tdfxfb as a module, and set CONFIG_HW_CONSOLE_BINDING=y
 (under drivers-char).

Until I discovered how to reproduce the bug, I had to reboot for
each test. But I discovered the real problem...

The garbling doesn't happen, no matter the udelay, until I start X.
Once X is started, even with an udelay(100) (which for me makes the
display untolerably slow) the problem happens.

This doesn't happen in latest 2.4.x, but I remember that some
characters dissappeared from the screen at some 2.4.x when X was
running. That was a known bug in the X driver of this card, so I'm not
sure if the last X.Org driver has this problem or not. Unfortunately, I
cannot test this directly, the most I can do is to test under Ubuntu,
which uses an older 2.6.x kernel.

If this new discovery doesn't ring any bell for you, I'll make a
test under Ubuntu and after that I'll just wait until I can upgrade X
(which I cannot do now) to latest X.Org (I'm now using 7.0.22).

Thanks for all your help. I'll keep you informed of any change I
notice, and (although I won't be very fast doing it...) you can count on
me to test any patch you want.

Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: tdfx framebuffer garbles display in 2.6.19.5

2007-03-07 Thread DervishD
Hi Antonino :)

 * Antonino A. Daplas <[EMAIL PROTECTED]> dixit:
> On Tue, 2007-03-06 at 07:25 +0100, DervishD wrote:
> > > > If you want me to test other patches, just tell :)
> > > 
> > > Can you change the mdelay to udelay and use higher/lower delay values
> > > to see if there's any improvement?

Regarding the delay: I've discovered a weird thing. When the display
is garbled, if I insist on outputting more text to the screen, sooner or
later it de-garbles! In fact, once the display has been garbled (not
easy to do, sometimes I can work for hours in a terminal before it gets
garbled, I can't reproduce it always), a continous output makes it
de-garble and garble again, in cycles.

Looks like an off-by-one error rather than a speed/sync error, am I
completely clueless?

This happens with vanilla 2.6.19.5, not with the patched one, which
I haven't been able to test yet (sorry...).

Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: tdfx framebuffer garbles display in 2.6.19.5

2007-03-07 Thread DervishD
Hi Antonino :)

 * Antonino A. Daplas [EMAIL PROTECTED] dixit:
 On Tue, 2007-03-06 at 07:25 +0100, DervishD wrote:
If you want me to test other patches, just tell :)
   
   Can you change the mdelay to udelay and use higher/lower delay values
   to see if there's any improvement?

Regarding the delay: I've discovered a weird thing. When the display
is garbled, if I insist on outputting more text to the screen, sooner or
later it de-garbles! In fact, once the display has been garbled (not
easy to do, sometimes I can work for hours in a terminal before it gets
garbled, I can't reproduce it always), a continous output makes it
de-garble and garble again, in cycles.

Looks like an off-by-one error rather than a speed/sync error, am I
completely clueless?

This happens with vanilla 2.6.19.5, not with the patched one, which
I haven't been able to test yet (sorry...).

Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: tdfx framebuffer garbles display in 2.6.19.5

2007-03-06 Thread DervishD
Hi Antonino :)

 * Antonino A. Daplas <[EMAIL PROTECTED]> dixit:
> On Tue, 2007-03-06 at 07:25 +0100, DervishD wrote:
> >  * Antonino A. Daplas <[EMAIL PROTECTED]> dixit:
> > > On Thu, 2007-03-01 at 17:01 +0100, DervishD wrote:
> > > >  * Antonino A. Daplas <[EMAIL PROTECTED]> dixit:
> > > > > Can you try this patch?  It might help with the screen
> > > > > corruption.
> > > > 
> > > > With the patch, the scroll slows to a crawl and the system is
> > > > unusable. The time to scroll 30 lines is about a minute or so
> > > > (probably more, I just measured for a while).
> > > > 
> > > > If you want me to test other patches, just tell :)
> > > 
> > > Can you change the mdelay to udelay and use higher/lower delay values
> > > to see if there's any improvement?
> > 
> > Yes, as soon as I can build a new kernel and reboot. Any suggested
> > value?
> 
> You can start with 5 and increment by 5.  So you need not reboot each
> time, compile tdfxfb as a module, and set CONFIG_HW_CONSOLE_BINDING=y
> (under drivers->char).

I've done that for testing, but I haven't build that kernel yet (not
spare time by now).

> Make sure you have vbetool, and use the attached script.

I don't have vbetool, but I'll get it.
 
> The script assumes vbetool is in /usr/sbin, if not just edit. Also,
> unbinding will only work if X (or any graphics app, for that matter) is
> not loaded.

No problem, it will be off while I test. I'll try to make the tests
probably this friday or the weekend, as soon as I can.

Thanks a lot for your interest :)

Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: tdfx framebuffer garbles display in 2.6.19.5

2007-03-06 Thread DervishD
Hi Antonino :)

 * Antonino A. Daplas [EMAIL PROTECTED] dixit:
 On Tue, 2007-03-06 at 07:25 +0100, DervishD wrote:
   * Antonino A. Daplas [EMAIL PROTECTED] dixit:
   On Thu, 2007-03-01 at 17:01 +0100, DervishD wrote:
 * Antonino A. Daplas [EMAIL PROTECTED] dixit:
 Can you try this patch?  It might help with the screen
 corruption.

With the patch, the scroll slows to a crawl and the system is
unusable. The time to scroll 30 lines is about a minute or so
(probably more, I just measured for a while).

If you want me to test other patches, just tell :)
   
   Can you change the mdelay to udelay and use higher/lower delay values
   to see if there's any improvement?
  
  Yes, as soon as I can build a new kernel and reboot. Any suggested
  value?
 
 You can start with 5 and increment by 5.  So you need not reboot each
 time, compile tdfxfb as a module, and set CONFIG_HW_CONSOLE_BINDING=y
 (under drivers-char).

I've done that for testing, but I haven't build that kernel yet (not
spare time by now).

 Make sure you have vbetool, and use the attached script.

I don't have vbetool, but I'll get it.
 
 The script assumes vbetool is in /usr/sbin, if not just edit. Also,
 unbinding will only work if X (or any graphics app, for that matter) is
 not loaded.

No problem, it will be off while I test. I'll try to make the tests
probably this friday or the weekend, as soon as I can.

Thanks a lot for your interest :)

Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: tdfx framebuffer garbles display in 2.6.19.5

2007-03-05 Thread Antonino A. Daplas
On Tue, 2007-03-06 at 07:25 +0100, DervishD wrote:
> Hi Antonino :)
> 
>  * Antonino A. Daplas <[EMAIL PROTECTED]> dixit:
> > On Thu, 2007-03-01 at 17:01 +0100, DervishD wrote:
> > >  * Antonino A. Daplas <[EMAIL PROTECTED]> dixit:
> > > > Can you try this patch?  It might help with the screen
> > > > corruption.
> > > 
> > > With the patch, the scroll slows to a crawl and the system is
> > > unusable. The time to scroll 30 lines is about a minute or so
> > > (probably more, I just measured for a while).
> > > 
> > > If you want me to test other patches, just tell :)
> > 
> > Can you change the mdelay to udelay and use higher/lower delay values
> > to see if there's any improvement?
> 
> Yes, as soon as I can build a new kernel and reboot. Any suggested
> value?

You can start with 5 and increment by 5.  So you need not reboot each
time, compile tdfxfb as a module, and set CONFIG_HW_CONSOLE_BINDING=y
(under drivers->char). Make sure you have vbetool, and use the attached
script.  Thus:

modprobe tdfxfb
unbind.sh
rmmod tdfxfb
edit, make, make modules_install
modprobe tdfxfb
repeat

The script assumes vbetool is in /usr/sbin, if not just edit. Also,
unbinding will only work if X (or any graphics app, for that matter) is
not loaded.

Tony



unbind.sh
Description: application/shellscript


Re: tdfx framebuffer garbles display in 2.6.19.5

2007-03-05 Thread DervishD
Hi Antonino :)

 * Antonino A. Daplas <[EMAIL PROTECTED]> dixit:
> On Thu, 2007-03-01 at 17:01 +0100, DervishD wrote:
> >  * Antonino A. Daplas <[EMAIL PROTECTED]> dixit:
> > > Can you try this patch?  It might help with the screen
> > > corruption.
> > 
> > With the patch, the scroll slows to a crawl and the system is
> > unusable. The time to scroll 30 lines is about a minute or so
> > (probably more, I just measured for a while).
> > 
> > If you want me to test other patches, just tell :)
> 
> Can you change the mdelay to udelay and use higher/lower delay values
> to see if there's any improvement?

Yes, as soon as I can build a new kernel and reboot. Any suggested
value?

Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: tdfx framebuffer garbles display in 2.6.19.5

2007-03-05 Thread Antonino A. Daplas
On Thu, 2007-03-01 at 17:01 +0100, DervishD wrote:
> Hi Antonino :)
> 
>  * Antonino A. Daplas <[EMAIL PROTECTED]> dixit:
> > Can you try this patch?  It might help with the screen corruption.
> 
> With the patch, the scroll slows to a crawl and the system is
> unusable. The time to scroll 30 lines is about a minute or so (probably
> more, I just measured for a while).
> 
> If you want me to test other patches, just tell :)

Can you change the mdelay to udelay and use higher/lower delay values to
see if there's any improvement?

Tony


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: tdfx framebuffer garbles display in 2.6.19.5

2007-03-05 Thread Antonino A. Daplas
On Thu, 2007-03-01 at 17:01 +0100, DervishD wrote:
 Hi Antonino :)
 
  * Antonino A. Daplas [EMAIL PROTECTED] dixit:
  Can you try this patch?  It might help with the screen corruption.
 
 With the patch, the scroll slows to a crawl and the system is
 unusable. The time to scroll 30 lines is about a minute or so (probably
 more, I just measured for a while).
 
 If you want me to test other patches, just tell :)

Can you change the mdelay to udelay and use higher/lower delay values to
see if there's any improvement?

Tony


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: tdfx framebuffer garbles display in 2.6.19.5

2007-03-05 Thread DervishD
Hi Antonino :)

 * Antonino A. Daplas [EMAIL PROTECTED] dixit:
 On Thu, 2007-03-01 at 17:01 +0100, DervishD wrote:
   * Antonino A. Daplas [EMAIL PROTECTED] dixit:
   Can you try this patch?  It might help with the screen
   corruption.
  
  With the patch, the scroll slows to a crawl and the system is
  unusable. The time to scroll 30 lines is about a minute or so
  (probably more, I just measured for a while).
  
  If you want me to test other patches, just tell :)
 
 Can you change the mdelay to udelay and use higher/lower delay values
 to see if there's any improvement?

Yes, as soon as I can build a new kernel and reboot. Any suggested
value?

Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: tdfx framebuffer garbles display in 2.6.19.5

2007-03-05 Thread Antonino A. Daplas
On Tue, 2007-03-06 at 07:25 +0100, DervishD wrote:
 Hi Antonino :)
 
  * Antonino A. Daplas [EMAIL PROTECTED] dixit:
  On Thu, 2007-03-01 at 17:01 +0100, DervishD wrote:
* Antonino A. Daplas [EMAIL PROTECTED] dixit:
Can you try this patch?  It might help with the screen
corruption.
   
   With the patch, the scroll slows to a crawl and the system is
   unusable. The time to scroll 30 lines is about a minute or so
   (probably more, I just measured for a while).
   
   If you want me to test other patches, just tell :)
  
  Can you change the mdelay to udelay and use higher/lower delay values
  to see if there's any improvement?
 
 Yes, as soon as I can build a new kernel and reboot. Any suggested
 value?

You can start with 5 and increment by 5.  So you need not reboot each
time, compile tdfxfb as a module, and set CONFIG_HW_CONSOLE_BINDING=y
(under drivers-char). Make sure you have vbetool, and use the attached
script.  Thus:

modprobe tdfxfb
unbind.sh
rmmod tdfxfb
edit, make, make modules_install
modprobe tdfxfb
repeat

The script assumes vbetool is in /usr/sbin, if not just edit. Also,
unbinding will only work if X (or any graphics app, for that matter) is
not loaded.

Tony



unbind.sh
Description: application/shellscript


Re: tdfx framebuffer garbles display in 2.6.19.5

2007-03-01 Thread DervishD
Hi Antonino :)

 * Antonino A. Daplas <[EMAIL PROTECTED]> dixit:
> Can you try this patch?  It might help with the screen corruption.

With the patch, the scroll slows to a crawl and the system is
unusable. The time to scroll 30 lines is about a minute or so (probably
more, I just measured for a while).

If you want me to test other patches, just tell :)

Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: tdfx framebuffer garbles display in 2.6.19.5

2007-03-01 Thread DervishD
Hi Antonino :)

 * Antonino A. Daplas [EMAIL PROTECTED] dixit:
 Can you try this patch?  It might help with the screen corruption.

With the patch, the scroll slows to a crawl and the system is
unusable. The time to scroll 30 lines is about a minute or so (probably
more, I just measured for a while).

If you want me to test other patches, just tell :)

Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: tdfx framebuffer garbles display in 2.6.19.5

2007-02-28 Thread DervishD
Hi Antonino :)

 * Antonino A. Daplas <[EMAIL PROTECTED]> dixit:
> On Mon, 2007-02-26 at 21:32 +0100, DervishD wrote:
> > Probably setting it back to 4096 will make the problem reappear.
> > Right now I cannot test, but I'll make some experiments.
> 
> Can you try this patch?  It might help with the screen corruption.

I'm doing system maintenance now, and won't have spare time until
friday, probably, but as soon as possible I'll test the patch. Thanks a
lot for your invaluable help :)

If you want me to test more patches, feel free. I'll test them ASAP,
probably this weekend if I can afford the time.

Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: tdfx framebuffer garbles display in 2.6.19.5

2007-02-28 Thread DervishD
Hi Antonino :)

 * Antonino A. Daplas [EMAIL PROTECTED] dixit:
 On Mon, 2007-02-26 at 21:32 +0100, DervishD wrote:
  Probably setting it back to 4096 will make the problem reappear.
  Right now I cannot test, but I'll make some experiments.
 
 Can you try this patch?  It might help with the screen corruption.

I'm doing system maintenance now, and won't have spare time until
friday, probably, but as soon as possible I'll test the patch. Thanks a
lot for your invaluable help :)

If you want me to test more patches, feel free. I'll test them ASAP,
probably this weekend if I can afford the time.

Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: tdfx framebuffer garbles display in 2.6.19.5

2007-02-27 Thread Antonino A. Daplas
On Mon, 2007-02-26 at 21:32 +0100, DervishD wrote:
> Hi Antonino :)
> 
>  * Antonino A. Daplas <[EMAIL PROTECTED]> dixit:
> > On Mon, 2007-02-26 at 18:13 +0100, DervishD wrote:
> > That's why tdfxb limits the vyres to a maximum of 4096. As to why the
> > problem disappeared just by changing this parameter, that I too don't
> > know.
> 
> Probably setting it back to 4096 will make the problem reappear.
> Right now I cannot test, but I'll make some experiments.
> 

Can you try this patch?  It might help with the screen corruption.

Tony

diff --git a/drivers/video/tdfxfb.c b/drivers/video/tdfxfb.c
index 689ce02..bb3ca71 100644
--- a/drivers/video/tdfxfb.c
+++ b/drivers/video/tdfxfb.c
@@ -284,7 +284,8 @@ static inline void banshee_make_room(str
 {
 	/* Note: The Voodoo3's onboard FIFO has 32 slots. This loop
 	 * won't quit if you ask for more. */
-	while((tdfx_inl(par, STATUS) & 0x1f) < size-1);
+	while((tdfx_inl(par, STATUS) & 0x1f) < size-1)
+		mdelay(5);
 }
  
 static int banshee_wait_idle(struct fb_info *info)
@@ -297,7 +298,9 @@ static int banshee_wait_idle(struct fb_i
 
 	while(1) {
 		i = (tdfx_inl(par, STATUS) & STATUS_BUSY) ? 0 : i + 1;
-		if(i == 3) break;
+		if(i == 3)
+			break;
+		mdelay(5);
 	}
 	return 0;
 }


Re: tdfx framebuffer garbles display in 2.6.19.5

2007-02-27 Thread Antonino A. Daplas
On Mon, 2007-02-26 at 21:32 +0100, DervishD wrote:
 Hi Antonino :)
 
  * Antonino A. Daplas [EMAIL PROTECTED] dixit:
  On Mon, 2007-02-26 at 18:13 +0100, DervishD wrote:
  That's why tdfxb limits the vyres to a maximum of 4096. As to why the
  problem disappeared just by changing this parameter, that I too don't
  know.
 
 Probably setting it back to 4096 will make the problem reappear.
 Right now I cannot test, but I'll make some experiments.
 

Can you try this patch?  It might help with the screen corruption.

Tony

diff --git a/drivers/video/tdfxfb.c b/drivers/video/tdfxfb.c
index 689ce02..bb3ca71 100644
--- a/drivers/video/tdfxfb.c
+++ b/drivers/video/tdfxfb.c
@@ -284,7 +284,8 @@ static inline void banshee_make_room(str
 {
 	/* Note: The Voodoo3's onboard FIFO has 32 slots. This loop
 	 * won't quit if you ask for more. */
-	while((tdfx_inl(par, STATUS)  0x1f)  size-1);
+	while((tdfx_inl(par, STATUS)  0x1f)  size-1)
+		mdelay(5);
 }
  
 static int banshee_wait_idle(struct fb_info *info)
@@ -297,7 +298,9 @@ static int banshee_wait_idle(struct fb_i
 
 	while(1) {
 		i = (tdfx_inl(par, STATUS)  STATUS_BUSY) ? 0 : i + 1;
-		if(i == 3) break;
+		if(i == 3)
+			break;
+		mdelay(5);
 	}
 	return 0;
 }


Re: tdfx framebuffer garbles display in 2.6.19.5

2007-02-26 Thread DervishD
Hi Antonino :)

 * Antonino A. Daplas <[EMAIL PROTECTED]> dixit:
> On Mon, 2007-02-26 at 18:13 +0100, DervishD wrote:
> > > Try fbset -a -vyres 600 first and let us know of the result.
> > 
> > After doing this, I no longer can garble the display (before, just a
> > "ls -lR /" was enough to do it, in fact, any big output garbled the
> > display). The only problem with this solution is that the scroll
> > speed has decreased a bit. In fact, the scroll speed is affected by
> > the vyres parameter a lot! The highter the vyres, the faster the
> > scroll, and I cannot reproduce the problem anymore after changing it
> > once!
> 
> Display panning is what makes scrolling fast which is the default
> scroll method if vyres > yres.  Unfortunately, tdfxfb occasionally
> have problems with this method, the higher the vyres, the greater the
> likelihood of screen corruption.

Then I'll try with 4096 and will diminish the number until the
display is stable.

> That's why tdfxb limits the vyres to a maximum of 4096. As to why the
> problem disappeared just by changing this parameter, that I too don't
> know.

Probably setting it back to 4096 will make the problem reappear.
Right now I cannot test, but I'll make some experiments.

Thanks a lot!

Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: tdfx framebuffer garbles display in 2.6.19.5

2007-02-26 Thread DervishD
Hi James :)

 * James Simmons <[EMAIL PROTECTED]> dixit:
> > From time to time, the tdfxfb driver from 2.6.19.5 (sorry, I cannot
> > test in 2.6.20.x because it doesn't compile, the infamous BDF negative
> > offset problem) garbles the display, leaving only a lot of thin lines,
> > just like sync was lost. The display can be repaired by switching to
> > another console, but this is annoying. This happens with a Voodoo 3
> > 3000, using [EMAIL PROTECTED] mode.
> > 
> > Anyone has this problem? Can it be solved changing anything?
> 
> Does not compile? Can you post the compile error. For my setup it does 
> compile. 

I think I didn't explain it well: the tdfxfb driver compiles, but
the *kernel* doesn't. At link time the linker warns about a negative
offset being used and building stops. The driver itself builds perfectly
as far as I can tell.

Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: tdfx framebuffer garbles display in 2.6.19.5

2007-02-26 Thread Antonino A. Daplas
On Mon, 2007-02-26 at 18:13 +0100, DervishD wrote:
> Hi Antonino :)
> 
>  * Antonino A. Daplas <[EMAIL PROTECTED]> dixit:
> > On Mon, 2007-02-26 at 15:47 +0100, DervishD wrote:
> > > From time to time, the tdfxfb driver from 2.6.19.5 (sorry, I cannot
> > > test in 2.6.20.x because it doesn't compile, the infamous BDF negative
> > > offset problem) garbles the display, leaving only a lot of thin lines,
> > > just like sync was lost. The display can be repaired by switching to
> > > another console, but this is annoying. This happens with a Voodoo 3
> > > 3000, using [EMAIL PROTECTED] mode.
> > 
> > Try fbset -a -vyres 600 first and let us know of the result.
> 
> After doing this, I no longer can garble the display (before, just a
> "ls -lR /" was enough to do it, in fact, any big output garbled the
> display). The only problem with this solution is that the scroll speed
> has decreased a bit. In fact, the scroll speed is affected by the vyres
> parameter a lot! The highter the vyres, the faster the scroll, and I
> cannot reproduce the problem anymore after changing it once!

Display panning is what makes scrolling fast which is the default scroll
method if vyres > yres.  Unfortunately, tdfxfb occasionally have
problems with this method, the higher the vyres, the greater the
likelihood of screen corruption. That's why tdfxb limits the vyres to a
maximum of 4096. As to why the problem disappeared just by changing this
parameter, that I too don't know.

Tony


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: tdfx framebuffer garbles display in 2.6.19.5

2007-02-26 Thread DervishD
Hi Antonino :)

 * Antonino A. Daplas <[EMAIL PROTECTED]> dixit:
> On Mon, 2007-02-26 at 15:47 +0100, DervishD wrote:
> > From time to time, the tdfxfb driver from 2.6.19.5 (sorry, I cannot
> > test in 2.6.20.x because it doesn't compile, the infamous BDF negative
> > offset problem) garbles the display, leaving only a lot of thin lines,
> > just like sync was lost. The display can be repaired by switching to
> > another console, but this is annoying. This happens with a Voodoo 3
> > 3000, using [EMAIL PROTECTED] mode.
> 
> Try fbset -a -vyres 600 first and let us know of the result.

After doing this, I no longer can garble the display (before, just a
"ls -lR /" was enough to do it, in fact, any big output garbled the
display). The only problem with this solution is that the scroll speed
has decreased a bit. In fact, the scroll speed is affected by the vyres
parameter a lot! The highter the vyres, the faster the scroll, and I
cannot reproduce the problem anymore after changing it once!

I'm really confused :?

Thanks a lot for the fix :)

Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: tdfx framebuffer garbles display in 2.6.19.5

2007-02-26 Thread James Simmons

> Hi all :)
> 
> From time to time, the tdfxfb driver from 2.6.19.5 (sorry, I cannot
> test in 2.6.20.x because it doesn't compile, the infamous BDF negative
> offset problem) garbles the display, leaving only a lot of thin lines,
> just like sync was lost. The display can be repaired by switching to
> another console, but this is annoying. This happens with a Voodoo 3
> 3000, using [EMAIL PROTECTED] mode.
> 
> Anyone has this problem? Can it be solved changing anything?

Does not compile? Can you post the compile error. For my setup it does 
compile. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: tdfx framebuffer garbles display in 2.6.19.5

2007-02-26 Thread Antonino A. Daplas
On Mon, 2007-02-26 at 15:47 +0100, DervishD wrote:
> Hi all :)
> 
> From time to time, the tdfxfb driver from 2.6.19.5 (sorry, I cannot
> test in 2.6.20.x because it doesn't compile, the infamous BDF negative
> offset problem) garbles the display, leaving only a lot of thin lines,
> just like sync was lost. The display can be repaired by switching to
> another console, but this is annoying. This happens with a Voodoo 3
> 3000, using [EMAIL PROTECTED] mode.
> 
> Anyone has this problem? Can it be solved changing anything?
> 
> Raúl Núñez de Arenas Coronado

Try fbset -a -vyres 600 first and let us know of the result.

Tony


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


tdfx framebuffer garbles display in 2.6.19.5

2007-02-26 Thread DervishD
Hi all :)

From time to time, the tdfxfb driver from 2.6.19.5 (sorry, I cannot
test in 2.6.20.x because it doesn't compile, the infamous BDF negative
offset problem) garbles the display, leaving only a lot of thin lines,
just like sync was lost. The display can be repaired by switching to
another console, but this is annoying. This happens with a Voodoo 3
3000, using [EMAIL PROTECTED] mode.

Anyone has this problem? Can it be solved changing anything?

Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


tdfx framebuffer garbles display in 2.6.19.5

2007-02-26 Thread DervishD
Hi all :)

From time to time, the tdfxfb driver from 2.6.19.5 (sorry, I cannot
test in 2.6.20.x because it doesn't compile, the infamous BDF negative
offset problem) garbles the display, leaving only a lot of thin lines,
just like sync was lost. The display can be repaired by switching to
another console, but this is annoying. This happens with a Voodoo 3
3000, using [EMAIL PROTECTED] mode.

Anyone has this problem? Can it be solved changing anything?

Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: tdfx framebuffer garbles display in 2.6.19.5

2007-02-26 Thread Antonino A. Daplas
On Mon, 2007-02-26 at 15:47 +0100, DervishD wrote:
 Hi all :)
 
 From time to time, the tdfxfb driver from 2.6.19.5 (sorry, I cannot
 test in 2.6.20.x because it doesn't compile, the infamous BDF negative
 offset problem) garbles the display, leaving only a lot of thin lines,
 just like sync was lost. The display can be repaired by switching to
 another console, but this is annoying. This happens with a Voodoo 3
 3000, using [EMAIL PROTECTED] mode.
 
 Anyone has this problem? Can it be solved changing anything?
 
 Raúl Núñez de Arenas Coronado

Try fbset -a -vyres 600 first and let us know of the result.

Tony


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: tdfx framebuffer garbles display in 2.6.19.5

2007-02-26 Thread James Simmons

 Hi all :)
 
 From time to time, the tdfxfb driver from 2.6.19.5 (sorry, I cannot
 test in 2.6.20.x because it doesn't compile, the infamous BDF negative
 offset problem) garbles the display, leaving only a lot of thin lines,
 just like sync was lost. The display can be repaired by switching to
 another console, but this is annoying. This happens with a Voodoo 3
 3000, using [EMAIL PROTECTED] mode.
 
 Anyone has this problem? Can it be solved changing anything?

Does not compile? Can you post the compile error. For my setup it does 
compile. 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: tdfx framebuffer garbles display in 2.6.19.5

2007-02-26 Thread DervishD
Hi Antonino :)

 * Antonino A. Daplas [EMAIL PROTECTED] dixit:
 On Mon, 2007-02-26 at 15:47 +0100, DervishD wrote:
  From time to time, the tdfxfb driver from 2.6.19.5 (sorry, I cannot
  test in 2.6.20.x because it doesn't compile, the infamous BDF negative
  offset problem) garbles the display, leaving only a lot of thin lines,
  just like sync was lost. The display can be repaired by switching to
  another console, but this is annoying. This happens with a Voodoo 3
  3000, using [EMAIL PROTECTED] mode.
 
 Try fbset -a -vyres 600 first and let us know of the result.

After doing this, I no longer can garble the display (before, just a
ls -lR / was enough to do it, in fact, any big output garbled the
display). The only problem with this solution is that the scroll speed
has decreased a bit. In fact, the scroll speed is affected by the vyres
parameter a lot! The highter the vyres, the faster the scroll, and I
cannot reproduce the problem anymore after changing it once!

I'm really confused :?

Thanks a lot for the fix :)

Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: tdfx framebuffer garbles display in 2.6.19.5

2007-02-26 Thread Antonino A. Daplas
On Mon, 2007-02-26 at 18:13 +0100, DervishD wrote:
 Hi Antonino :)
 
  * Antonino A. Daplas [EMAIL PROTECTED] dixit:
  On Mon, 2007-02-26 at 15:47 +0100, DervishD wrote:
   From time to time, the tdfxfb driver from 2.6.19.5 (sorry, I cannot
   test in 2.6.20.x because it doesn't compile, the infamous BDF negative
   offset problem) garbles the display, leaving only a lot of thin lines,
   just like sync was lost. The display can be repaired by switching to
   another console, but this is annoying. This happens with a Voodoo 3
   3000, using [EMAIL PROTECTED] mode.
  
  Try fbset -a -vyres 600 first and let us know of the result.
 
 After doing this, I no longer can garble the display (before, just a
 ls -lR / was enough to do it, in fact, any big output garbled the
 display). The only problem with this solution is that the scroll speed
 has decreased a bit. In fact, the scroll speed is affected by the vyres
 parameter a lot! The highter the vyres, the faster the scroll, and I
 cannot reproduce the problem anymore after changing it once!

Display panning is what makes scrolling fast which is the default scroll
method if vyres  yres.  Unfortunately, tdfxfb occasionally have
problems with this method, the higher the vyres, the greater the
likelihood of screen corruption. That's why tdfxb limits the vyres to a
maximum of 4096. As to why the problem disappeared just by changing this
parameter, that I too don't know.

Tony


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: tdfx framebuffer garbles display in 2.6.19.5

2007-02-26 Thread DervishD
Hi James :)

 * James Simmons [EMAIL PROTECTED] dixit:
  From time to time, the tdfxfb driver from 2.6.19.5 (sorry, I cannot
  test in 2.6.20.x because it doesn't compile, the infamous BDF negative
  offset problem) garbles the display, leaving only a lot of thin lines,
  just like sync was lost. The display can be repaired by switching to
  another console, but this is annoying. This happens with a Voodoo 3
  3000, using [EMAIL PROTECTED] mode.
  
  Anyone has this problem? Can it be solved changing anything?
 
 Does not compile? Can you post the compile error. For my setup it does 
 compile. 

I think I didn't explain it well: the tdfxfb driver compiles, but
the *kernel* doesn't. At link time the linker warns about a negative
offset being used and building stops. The driver itself builds perfectly
as far as I can tell.

Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: tdfx framebuffer garbles display in 2.6.19.5

2007-02-26 Thread DervishD
Hi Antonino :)

 * Antonino A. Daplas [EMAIL PROTECTED] dixit:
 On Mon, 2007-02-26 at 18:13 +0100, DervishD wrote:
   Try fbset -a -vyres 600 first and let us know of the result.
  
  After doing this, I no longer can garble the display (before, just a
  ls -lR / was enough to do it, in fact, any big output garbled the
  display). The only problem with this solution is that the scroll
  speed has decreased a bit. In fact, the scroll speed is affected by
  the vyres parameter a lot! The highter the vyres, the faster the
  scroll, and I cannot reproduce the problem anymore after changing it
  once!
 
 Display panning is what makes scrolling fast which is the default
 scroll method if vyres  yres.  Unfortunately, tdfxfb occasionally
 have problems with this method, the higher the vyres, the greater the
 likelihood of screen corruption.

Then I'll try with 4096 and will diminish the number until the
display is stable.

 That's why tdfxb limits the vyres to a maximum of 4096. As to why the
 problem disappeared just by changing this parameter, that I too don't
 know.

Probably setting it back to 4096 will make the problem reappear.
Right now I cannot test, but I'll make some experiments.

Thanks a lot!

Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/