Re: maxtroxfb deadlock (and generic fbcon race?)

Petr Vandrovec Ing. VTEI (VANDROVE@vc.cvut.cz)
Mon, 18 Jan 1999 18:10:54 MET-1


> > I tried it here (PII/350MHz, G200 and Millenium I), on my both matroxes,
> > and it survived about 3 minutes of switching. With hardware cursor and
> > acceleration. Are you using hardware or software cursor (software cursor
> > is flashing block, hardware cursor is by default small flashing underline)
> > and acceleration?
> I was using the defaults, so acceleration and hardware cursor I think (I
> had set my cursor with echo -e "\033[?17;8;64c", if that makes any
> difference).
It is software generated non-blinking cursor, AKA softcursor. I tried it
here and it survive for two minutes (after that I give up pressing Alt-F1,
Alt-F2... probably I should write some software to do it).
I've found only one problem. If I did
find -name "*.c" -exec sh -c "cat {} >/dev/vcs1"
it stops on first file longer than 4KB (as expected?). After that I pressed
Enter, so console scroll up one line (still no problem, cursor fast switching
on/off in left bottom corner of screen).
After that I switched to VT2 and run "while true; do cat */*.c; done".
After some time of switching between VT1 and VT2 I hit ^C on VT1 and cursor
was left on screen (in left bottom corner, scrolls up together with screen
contents and survives mode switch, so someone probably forget to undraw
(or draw?) softcursor after ^C). But I tried it couple of times (6x) and it
happened only once.
Can someone comment it? (machine has SMP kernel, SMP board, but only one
CPU, kernel is Linus-2.2.0-pre7 + console unrelated fixes (NCP, IPX,
BTFIXUP, ACPI)).
> I will compile a more recent kernel there and try again when I get a
> chance..
OK. It behaved strange, but survived.
Results in 640x480 (virtual 640x480) are a bit worse. Console switch
sometime takes 'visible' time (VT1 does nothing, VT2 cat */*.c) and there
are sometime one or two cursors left on VT1 (I do not know how on VT2 as
it scrolls up pretty fast). Sometime (80%) cursor is drawn only on screen,
does not survive switch VT1 -> VT3 -> VT1, sometime (20%) it is written
into underlying VT buffer and survives console switch.
If someone sees something missing in matroxfb or in VT code, please tell
me, I see nothing wrong in matroxfb if no-one reenters driver. Maybe that
there is some race, but it looks to me more like that we defer something
if fbcon is busy and later we forget to redo it (or redo it correctly).
Best regards,
Petr Vandrovec
vandrove@vc.cvut.cz

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/