Re: ruby 2.6.0 oops+crash when accessing /dev/tty18

[Helge H. <hel...@ai...>]

Aivils Stoss wrote:
> Long holidays elapse so fast.
> 
> 
>>On Mon, Dec 29, 2003 at 02:28:32PM +0200, Aivils Stoss wrote:
>>
>>>>I have two framebuffers and fbcon, and ruby 2.6.0
>>>>vc 1-16 on fb0 seems to work fine.
>>>
>>>cat /var/log/dmesg | grep Console
>>>should show Your VT-VC configuration.
>>>"Console ... matrox ... take over ... vc:1-16"
>>>"Console ... matrox ... vc:17-32"
>>>and similar
>>>cat /var/log/dmesg | grep "keyboard\.c"
>>>
>>
>>Thanks.
>>
>>This is what I have:
>>Console: Colour VGA+ 80x25 vc:1-16
>>Console: mono dummy device 80x25 vc:17-17
> 
> 
> You must have more. fbcon initializing add some lines, actualy
> "take over" , when takes over VGA console, take_over_console() vt.c
> Secondary matrox_crt2 should come in dmesg to, fbcon_add() fbcon.c.
> 
> According Your dmesg, fbcon was not initialized.
> 
> 
>>Is it possible to get 17 connected to the scond framebuffer
>>instead of a dummy device?
> 
> 
> Yes. But order is hardcoded first all DUMMY then all FB consoles,
> seems this must be vice versa. dumbcon=0
> 1st fb take over VGA and so vc:1-16
That seems to work, yes.

> 2nd fb have vc:17-32
Didn't seem to happen for me.  I'll post more dmesg output
the next time I get a chance to reboot.

So I shouldn't need dumbcon=1 because I have two real framebuffers?
Will my second keyboard attach to vc:17-32 ?

> with hardcoded vgacon and fbcon.
> 
> 
>>Seems there is no 18 then.  Trying to use 17
>>is almost as bad though - letting an xserver use vt17
>>goes into D-state as shown by "ps aux".
>>So I keep running 2.6.0-test11+ruby, where vt17 works.
> 
> ?

My problem is that trying to use vt17 like this:
/usr/X11R6/bin/X :0 vt17
or like this:
openvt -c 17 -f

gives me a process in D-state when using 2.6.0+ruby.
It doesn't matter wether I compile in fbcon or not.
Either approace is fine if I try it with vt5 for example.

2.6.0-test11 + cvs ruby of 30/11 lets me use 
my second keyboard, if I don't compile in fbcon.
The machine boots with vgacon, turns on framebuffers
but no fbcon (leaving no useable console)
and then starts up two xservers.  One using v7 and one using vt17.
I use dumbcon=1 to get a working vt17.
I can then have two users with independent keyboards, logging into
different xservers using xdm.

Booting 2.6.0+ruby gives me a working fbcon on /dev/fb0.
So I can run gettys and switch consoles.  I can also run a
xserver on vt7.  But running a xserver on vt17 (or even doing
a cat /dev/tty17) will leave the process accessing tty17 hung in
D-state according do "ps aux", and possibly hang the machine too.
Running 2.6.0+ruby without fbcon doesn't help.  It crashes in the
same way, but of course I don't get to see any output in that case.

I haven't succeeded in using the second keyboard for anything but
sysrq sequences with 2.6.0+ruby, because of these problems.




Another unrelated problem:
When accessing bios setup or booting plain linux, only one keyboard
is useable.  This is the one connected to the ps2 keyboard port.
Also, only one of the screens works in these cases.

The problem with ruby is that ruby decides that the ps2 keyboard port
is the "extra" one connected to vt17, while my other keyboard, connected
to the ps2 mouse port gets vc:1-16.

Physical setup of two workstations:
screen1:fb0                     screen2:fb1
kbd1:kbd-port                   kbd2:mouse-port
vc:17                           vc:1-16

The problem here is that a console login with ruby uses
kbd2 and screen 1.  Very impractical because of distance.
And I can't just swap the keyboards, because then I get
the same problem when running plain linux, selecting kernels
in the lilo bootprompt, or changing bios setup.

I fixed this for my working X setup by
running an xserver on screen1 using vt17 and
an xserver on screen2 using vt7.

But this breaks in interesting ways with consoles.
With consoles only and no X I get the above mentioned
problem.  If I try to run X too then I get
an xserver on screen1 using kbd1 on vc17, while
fbconsole using kbd2 on vc1:16 uses the same framebuffer.

Clearly not what I want.  I want both console and X on the
same screen, but with the same keyboard!
Again, this _is_ fixable by swapping the keyboard and changing the X
setup a bit, but then I get trouble with bios setup and other
linux kernels again.

The ideal solution is if ruby simply connects the ps2-keyboard-port
to vc:1-16 instead of the mouse-port keyboard by default.
The second best solution is if I can force this setup with kernel 
command line parameters somehow.

Helge Hafting