I'm seeing corruption on the screen if I use anything that scrols like
pine or menuconfig.
It goes away if I disable preempt.
Gerhard
--
Gerhard Mack
[email protected]
<>< As a computer I find your faith in technology amusing.
> I'm seeing corruption on the screen if I use anything that scrols like
> pine or menuconfig.
>
> It goes away if I disable preempt.
Preempt and the VT console system are not friends. There are way to many
global variables which have there states altered in many spots.
On Mon, 2003-06-16 at 14:27, James Simmons wrote:
> Preempt and the VT console system are not friends. There are way to many
> global variables which have there states altered in many spots.
So why is this not an SMP race, too?
Robert Love
> On Mon, 2003-06-16 at 14:27, James Simmons wrote:
>
> > Preempt and the VT console system are not friends. There are way to many
> > global variables which have there states altered in many spots.
>
> So why is this not an SMP race, too?
For userland<->kernel transactions we have the console_semaphore to
protect us. It is also used for console_callback. The console_semaphore is
not used internally to protect global variables :-( To do this properly
would take quite a bit of work.
On Mon, 2003-06-16 at 16:34, James Simmons wrote:
> For userland<->kernel transactions we have the console_semaphore to
> protect us. It is also used for console_callback. The console_semaphore is
> not used internally to protect global variables :-( To do this properly
> would take quite a bit of work.
It looks like all these globals need a lock -- they can race on SMP or
with kernel preemption.
Is it really going to be that hard to wrap a lock around their access,
because I think this is going to bite SMP users.
Robert Love
> > For userland<->kernel transactions we have the console_semaphore to
> > protect us. It is also used for console_callback. The console_semaphore is
> > not used internally to protect global variables :-( To do this properly
> > would take quite a bit of work.
>
> It looks like all these globals need a lock -- they can race on SMP or
> with kernel preemption.
>
> Is it really going to be that hard to wrap a lock around their access,
> because I think this is going to bite SMP users.
For things like fg_console and currcon it will be. Those variables are
used everyway like mad. That is a whole lot of locks. I doubt this issue
will be solved until 2.7.X.
On Tue, 17 Jun 2003, James Simmons wrote:
> > > For userland<->kernel transactions we have the console_semaphore to
> > > protect us. It is also used for console_callback. The console_semaphore is
> > > not used internally to protect global variables :-( To do this properly
> > > would take quite a bit of work.
> >
> > It looks like all these globals need a lock -- they can race on SMP or
> > with kernel preemption.
> >
> > Is it really going to be that hard to wrap a lock around their access,
> > because I think this is going to bite SMP users.
>
> For things like fg_console and currcon it will be. Those variables are
> used everyway like mad. That is a whole lot of locks. I doubt this issue
> will be solved until 2.7.X.
Interestingly enough it's not console switching that does it.. it's
scrolling also as I mentioned before it's not just with preempt enabled.
I wonder if theres another problem somewhere?
Gerhard
--
Gerhard Mack
[email protected]
<>< As a computer I find your faith in technology amusing.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 18 of June 2003 02:50, Gerhard Mack wrote:
> On Tue, 17 Jun 2003, James Simmons wrote:
> > > > For userland<->kernel transactions we have the console_semaphore to
> > > > protect us. It is also used for console_callback. The
> > > > console_semaphore is not used internally to protect global variables
> > > > :-( To do this properly would take quite a bit of work.
> > >
> > > It looks like all these globals need a lock -- they can race on SMP or
> > > with kernel preemption.
> > >
> > > Is it really going to be that hard to wrap a lock around their access,
> > > because I think this is going to bite SMP users.
> >
> > For things like fg_console and currcon it will be. Those variables are
> > used everyway like mad. That is a whole lot of locks. I doubt this issue
> > will be solved until 2.7.X.
>
> Interestingly enough it's not console switching that does it.. it's
> scrolling also as I mentioned before it's not just with preempt enabled.
>
> I wonder if theres another problem somewhere?
I've got simmilar problem with 2.5.72, sometimes keyboard stops to respond (in
X windows). Mouse is usefull, all i have to do is restart Xwindows and
everything is running well.
- --
Grzegorz Jaskiewicz
K4 Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE+8FNtqu082fCQYIgRAkjyAJ9tWkOANrS9jEWo9XytzhM1k9bNEQCfXRzd
3IgRlKPiiJUt3z0gf791bUA=
=Z8VM
-----END PGP SIGNATURE-----
> > Interestingly enough it's not console switching that does it.. it's
> > scrolling also as I mentioned before it's not just with preempt enabled.
> >
> > I wonder if theres another problem somewhere?
> I've got simmilar problem with 2.5.72, sometimes keyboard stops to respond (in
> X windows). Mouse is usefull, all i have to do is restart Xwindows and
> everything is running well.
So scrolling is the issue. Which console drivers are you using?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 18 of June 2003 17:38, James Simmons wrote:
> > I've got simmilar problem with 2.5.72, sometimes keyboard stops to
> > respond (in X windows). Mouse is usefull, all i have to do is restart
> > Xwindows and everything is running well.
>
> So scrolling is the issue. Which console drivers are you using?
Config attached.
- --
Grzegorz Jaskiewicz
K4 Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE+8JFSqu082fCQYIgRAkNXAJ4/erq9miy/S0zYIeKjV16hARsk4wCfUdX3
WqxUG+XJfGyBjxUatjwM5h8=
=Gg8X
-----END PGP SIGNATURE-----
On Wed, 18 Jun 2003, James Simmons wrote:
> Date: Wed, 18 Jun 2003 17:38:50 +0100 (BST)
> From: James Simmons <[email protected]>
> To: Grzegorz Jaskiewicz <[email protected]>
> Cc: Gerhard Mack <[email protected]>, Robert Love <[email protected]>,
> [email protected]
> Subject: Re: Linux 2.5.71 - random console corruption
>
>
> > > Interestingly enough it's not console switching that does it.. it's
> > > scrolling also as I mentioned before it's not just with preempt enabled.
> > >
> > > I wonder if theres another problem somewhere?
> > I've got simmilar problem with 2.5.72, sometimes keyboard stops to respond (in
> > X windows). Mouse is usefull, all i have to do is restart Xwindows and
> > everything is running well.
>
> So scrolling is the issue. Which console drivers are you using?
Scrolling and screen clearing. If the machine is loaded the screen may
not clear all of the way.
I have the following enabled:
CONFIG_FB_ATY=y
CONFIG_FB_ATY_CT=y
I get this on starup:
atyfb: using auxiliary register aperture
atyfb: 3D RAGE IIC (AGP) [0x475a rev 0x7a] 8M SDRAM, 14.31818 MHz XTAL, 230 MHz
If you need me to try anything just ask.
Gerhard
--
Gerhard Mack
[email protected]
<>< As a computer I find your faith in technology amusing.
> > > I've got simmilar problem with 2.5.72, sometimes keyboard stops to
> > > respond (in X windows). Mouse is usefull, all i have to do is restart
> > > Xwindows and everything is running well.
> >
> > So scrolling is the issue. Which console drivers are you using?
> Config attached.
You have way to many fbdev drivers turned on. Also the console drivers are
messed up. Slect one Fbdev driver and framebuffer console or just use
vgacon.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 18 of June 2003 21:28, James Simmons wrote:
> > Config attached.
>
> You have way to many fbdev drivers turned on. Also the console drivers are
> messed up. Slect one Fbdev driver and framebuffer console or just use
> vgacon.
Shouldn't those drivers detect if they are or not the ones, and if none of
them is - leave vgacon , if one of them does the job it should set vgacon off
and use fb ?
What if i will have to decide about configuration for distribution ? where
everyone nowdays want to boot with logo/fb and so on ?
- --
Grzegorz Jaskiewicz
K4 Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE+8Malqu082fCQYIgRAjMSAJ4uCzn4EH4pgXstsRSnVBlZiZObggCdEYI8
vCupyDNBt9J9DvSYpE4pxoA=
=vnmZ
-----END PGP SIGNATURE-----
On Tue, 17 Jun 2003, James Simmons wrote:
>
> > > For userland<->kernel transactions we have the console_semaphore to
> > > protect us. It is also used for console_callback. The console_semaphore is
> > > not used internally to protect global variables :-( To do this properly
> > > would take quite a bit of work.
> >
> > It looks like all these globals need a lock -- they can race on SMP or
> > with kernel preemption.
> >
> > Is it really going to be that hard to wrap a lock around their access,
> > because I think this is going to bite SMP users.
>
> For things like fg_console and currcon it will be. Those variables are
> used everyway like mad. That is a whole lot of locks. I doubt this issue
> will be solved until 2.7.X.
Given that it has just become easy to replicate, I suspect that it will
get fixed by someone looking at the recent changes. Agreed, a perfect fix
may wait, but when preempt fails regularly and SMP works, as described in
posts and by some mail, I don't think a rewrite is needed, just one or a
few locks.
My guess only.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.