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

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

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

Is it possible to get 17 connected to the scond framebuffer
instead of a dummy device?

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.

> >I tried "echo testing > /dev/tty18" to see if
> >I got something on fb1.
> 
> Beter add ay least one agetty  on /dev/tty17 in
> Your inittab.

Ideally, I want 6 fbcon terminals + 1 xserver on the
second keyboard.  In other words, just like two single-user
machines.  If that isn't possible yet, I want an xserver.
 
> >This crashed. Many pages of oops scrolled by, ending in:
> 
> Seems all "divide by zero" errors is not cleaned :-(
> 
Exactly.  It is of course ok to get a ENODEV or similiar if
my setup is wrong - it was the oopsing I wanted to report.

> >X runs fine using vt7 and the mga driver.  Framebuffer X fails, probably
> >because of vt17 trouble.
> 
> Hm. You can add one dummy console. dumbcon=1
> 
dumbcon=1 and two xservers works for 2.6.0-test11+ruby.  But not
for 2.6.0ruby.  Xserver (or openvt -f -c 17) goes into D-state.

openvt needs the -f (force) option because it cannot determine
wether that vt is in use - a sign of trouble.  openvt -c 5 works
fine (when no other openvt or getty has claimed that vt of course.)

Helge Hafting