Messages in this thread | | | From | "Petr Vandrovec Ing. VTEI" <> | Date | Mon, 18 Jan 1999 18:10:54 MET-1 | Subject | Re: maxtroxfb deadlock (and generic fbcon race?) |
| |
> > 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/
| |