linuxconsole-dev

Re: console_lock too early in printk???

[James S. <jsi...@ac...>]

> Moral of this story:  Don't you DARE use printk for debugging, you might
> introduce more problems than you started with.  :)

Especially with video drivers :-(

> On a more serious note... couldn't issues like these be temporarily side
> stepped by making the console_lock recursive, similar to the monster
> kernel_lock?  You could keep one copy of the entrance count with the lock
> itself, rather than one copy each in the "current" task_struct...

If we really want to fix this problem we have to rethink the console lock.
See my other post.

Re: console_lock too early in printk???

[James S. <jsi...@ac...>]

> Just one?-) I thought about this and the console latency problems a bit.
> Would the following sound reasonable in mid/long-term? 
> 
> 1. Get rid of the tasklet and setup a worker thread, kconsoled, to do
> the dirty work. This has plus side that we can sleep and check if we
> need rescheduling.

That's a interesting idea. The problem is mostly with fbcon. It just takes
to long to draw pixel by pixel. In time I hope to see fbcon move to become 
accelcon where nearly all the drivers use the video cards accel engine to
draw for the console. This should nearly eliminate the latency problems.
Their will still be offb and vesafb which have no accel support but has
more accelerated fbdev drivers come into being this will go away.   
 
> 2. Create a new console semaphore and serialize with consoledriver.write 
> by that means instead of the console spinlock.

This needs to be done. Soon or later we are going to run into video
hardware that is irq driven only. Also once the kernel supports multihead 
we most likely will run into problems. So the locking system needs to be 
thought out. By next week I will have multihead running for mdacon and
vgacon so I will find out. 

> Having done that there's still printk which is the big problem. How about
> if we change semantics, 
> 
> printk: serializes by means of semaphore so can sleep. If in interrupt
> then queue the job for the worker thread to do asynchronously. I think
> most places in interrupts could change to use asynchronous semantics.
> __printk: same but doesn't grab the lock - used inside console code?
> 
> This will leave us with that one ugly case (oopses/panics etc.) which
> simply have to get the job done but maybe console is in inconsistant
> state. So what to do, I'm not sure? Safe way would be to check an
> atomic variable (console_dirty) and abort if no can do. The other strategy
> would be to hope the best and see what happens.
> 
> I must have missed something? Btw. has anyone thought of pushing most
> of console/vt code to user-space?

Do you think you can come up with some code to try out. As I said by next
week I will have multihead running so we can give these ideas a try. As
for moving the console/vt code to userspace. In theory you can do this
using /dev/fbX and /dev/eventX to create a userland console.

Re: console_lock too early in printk???

[Aki M L. <aml...@cc...>]

On Sat, 1 Jul 2000, James Simmons wrote:
> > 1. Get rid of the tasklet and setup a worker thread, kconsoled, to do
> > the dirty work. This has plus side that we can sleep and check if we
> > need rescheduling.
> 
> That's a interesting idea. The problem is mostly with fbcon. It just takes
> to long to draw pixel by pixel. In time I hope to see fbcon move to become 

You tell me about it. On a laptop I have, I always have to be extremely
cautious not to say for example cat bigger text files. If I do, then the
whole machine is pretty much jammed, until it is done. During that time
even keyboard input (ctrl-c or changing virtual terminals) does not work.

> accelcon where nearly all the drivers use the video cards accel engine to
> draw for the console. This should nearly eliminate the latency problems.

Is it currently possible to make a driver which leaves the accel engine
do its work on the background so you don't have to wait by polling the 
hardware until the operation is done? With issues like this, it is still
possible that bigger blits will cause relatively big latencies. Certainly
not in the tens-of-seconds variety but unacceptable for the causes people
keep arguing here about.

> we most likely will run into problems. So the locking system needs to be 
> thought out. By next week I will have multihead running for mdacon and
> vgacon so I will find out. 

I haven't got a picture how multihead will be worked out? Will you have
some per-head structure? Then it is natural to move most of the current 
global variables and locks in this structure.

> Do you think you can come up with some code to try out. As I said by next
> week I will have multihead running so we can give these ideas a try. As

Not so soon, sorry. I don't have time until thursday earliest.

> for moving the console/vt code to userspace. In theory you can do this
> using /dev/fbX and /dev/eventX to create a userland console.

If only you didn't need to printk fatal oopses/panics/etc, the portion of
code which would have to live in kernel would be pretty minimal.


-- 
D.

Re: console_lock too early in printk???

[James S. <jsi...@ac...>]

> Is it currently possible to make a driver which leaves the accel engine
> do its work on the background so you don't have to wait by polling the 
> hardware until the operation is done? With issues like this, it is still
> possible that bigger blits will cause relatively big latencies. Certainly
> not in the tens-of-seconds variety but unacceptable for the causes people
> keep arguing here about.

True. This is a more general problem that needs a more general solution.

> I haven't got a picture how multihead will be worked out? Will you have
> some per-head structure? Then it is natural to move most of the current 
> global variables and locks in this structure.

For the console system yes. I also have rewritten the console code to
reentry since this is required in a multihead enivornment. At least I
hope. As for raw hardware device access like /dev/dsp and /dev/fb I
haven't figured away around that yet.
 
Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: console_lock too early in printk???

[Chris L. <sa...@sk...>]

> > Moral of this story:  Don't you DARE use printk for debugging, you might
> > introduce more problems than you started with.  :)
> Especially with video drivers :-(

Or in my case... the VM system.  :)

> > On a more serious note... couldn't issues like these be temporarily side
> > stepped by making the console_lock recursive, similar to the monster
> > kernel_lock?  You could keep one copy of the entrance count with the lock
> > itself, rather than one copy each in the "current" task_struct...

> If we really want to fix this problem we have to rethink the console lock.
> See my other post.

I agree that a more general solution would be better... but it would
probably not be appropriate for 2.4.0...

-Chris

Re: console_lock too early in printk???

[James S. <jsi...@ac...>]

> > If we really want to fix this problem we have to rethink the console lock.
> > See my other post.
> 
> I agree that a more general solution would be better... but it would
> probably not be appropriate for 2.4.0...

Right. I'm working on it now for 2.5.X :-) I rather have code go in right
away and have it already tested to make sure it works.

Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net