The reset program from the ncurses package hangs, even disabling keyboard input. This makes it impossible to interrupt the program or change console if remote login is unavailable, leaving only a cruel power down. Reproducible: Always Steps to Reproduce: 1. call "reset" from virtual terminal Actual Results: 1. screen turns blank 2. console does not respond to keyboard input, not even VT change or Ctrl+Alt+Del 3. ssh login still works 4. ps reveals that reset is still running 5. SIGTERM is enough to terminate reset 6. Keys typed while reset was running get processed (e.g. my Ctrl+Alt+Del) Expected Results: screen cleared, maybe some message about escape character, and command prompt restored Dell Inspiron 8200 Notebook 1600x1200 VESA FB console sys-libs/ncurses-5.4-r5 ==> Kernel .configure <== ... CONFIG_FB_VESA=y # CONFIG_FB_VESA_STD is not set CONFIG_FB_VESA_TNG=y CONFIG_FB_VESA_DEFAULT_MODE="1600x1200@60" CONFIG_VIDEO_SELECT=y ... ==> /proc/fb <== 0 VESA VGA ==> /proc/fb0/modes <== 640x400-8 640x480-8 800x600-8 1024x768-8 1280x1024-8 320x200-16 320x200-32 640x480-16 640x480-32 800x600-16 ==> /proc/fb0/vbe_info <== Version: 3.0 Vendor: NVidia Corporation Product: NV17 () Board OEM rev: Chip Rev A2 OEM string: NVidia ==> emerge info <== Portage 2.0.50-r11 (default-x86-2004.0, gcc-3.3.4, glibc-2.3.3.20040420-r2, 2.6.8-gentoo-r3) ================================================================= System uname: 2.6.8-gentoo-r3 i686 Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz Gentoo Base System version 1.4.16 distcc 2.13 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="ftp:///ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://ftp.easynet.nl/mirror/gentoo/ ftp://ftp.ipv6.uni-muenster.de/pub/linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="X acpi alsa arts avi berkdb bitmap-fonts cdr crypt cups curl divx4linux dvd dvdr encode esd f77 foomaticdb gd gdbm gif gphoto2 gpm gtk gtk2 imagemagick imap imlib innodb ipv6 java jpeg kde libg++ libwww lirc mad maildir mailwrapper mikmod mmx motif mozilla mpeg mule mysql ncurses nls oggvorbis opengl oss pam pcmcia pdflib perl pic png pnp python qt quicktime readline samba sasl sdl slang speex spell sse ssl svga tcltk tcpd tetex truetype trusted unicode usb wavelan x86 xml2 xmms xprint xv zlib"
Could you do # tset -V ncurses 5.4.20040208 # tset -q xterm-color And see what you get? (note that tset and reset are part of ncurses)
Could you please reset, remote-login and look for clues at the end of "dmesg" ?
# tset -V ncurses 5.4.20040208 # tset -q linux no relevant output in dmesg. without remote login, a "sleep 10; killall reset" on another console is just as good - if you know reset is going to be trouble.
Just out of curiosity... Does this happen with framebuffer disabled? It might be a framebuffer issue. You might be able to boot with vga=ask or some other command. Also, can you do: strace -v -s 65535 -o TRACEFILE reset and attach the TRACEFILE it makes? For some reason, I can't get "gdb" to run on it.
Created attachment 41758 [details] strace of reset in 1600x1200 This is "strace -v -s 65535 reset" in 1600x1200 VESA FB TNG mode.
Created attachment 41760 [details] strace of reset in 800x600 This is "strace -v -s 65535 reset" in 800x600 VESA FB TNG mode.
I didn't get vga=ask to work, it still changed to vesa fb mode. I also tried video=vga, but this still changed to vesa mode. Then I appended "video=vesafb:800x600-16" and really got a smaller resolution framebuffer mode. And in this mode, reset worked just fine! So I created another strace and attached both here. By the way, as this might give you a clue: when I "ls" some directory in 1600x1200 console mode, the alignment of the columns is screwed, the wrap a lot and things become rather ugly. "ls --color", on the other hand, works just fine, keeping output neat and tidy. Now with 800x600, "ls" works as well. So it would seem there are some problems with my 1600x1200 vesa-tng mode. But IIRC this ls problem occured with the old vesa fb as well, with vga= something I had to use a DOS program to find out. I'll try to get this configuration back and give reset a try, but it might be some time till I get around to it.
Created attachment 41790 [details] Screenshots of ls in different modes This GPM-made screenshot shows the badly aligned output of ls if I use 1600x1200, how it can be corrected using --color, and that everything looks fine in 800x600.
Can you please confirm if this is an issue with the original vesafb or not?
OK, this problem is a VESAFB-TNG problem. With the standard vesafb and vga=0x345 or vga=0x346 (1660x1200-8 resp. 1600x1200-16) reset terminates normally. The ls-problem described above is still an issue, but I think I'll open a new bug report for this one.
Looking at your /proc/fb0/modes it seems that 1600x1200 is not supported by the VBE of your video card. Could you please post the output of `fbset -i` for this 1600x1200 vesafb-tng mode, and the output of `dmesg | grep vesafb`?
What is the VBE? VESA BIOS Extension? I used the program LFB.EXE mentioned in the gentoo forums to list the available video modes and find the parameter for the vesafb-std vga= parameter. Would this mode be listed there if it was not supported by the VBE? I'll attach the output of LFB.EXE. ==> fbset -i <== mode "1600x1200-60" # D: 162.022 MHz, H: 75.010 kHz, V: 60.008 Hz geometry 1600 1200 1600 1200 8 timings 6172 304 64 46 1 192 3 hsync high vsync high rgba 8/0,8/0,8/0,0/0 endmode Frame buffer device information: Name : VESA VGA Address : 0xe0000000 Size : 16777216 Type : PACKED PIXELS Visual : PSEUDOCOLOR XPanStep : 0 YPanStep : 0 YWrapStep : 0 LineLength : 1600 Accelerator : No ==> dmesg | grep vesafb <== vesafb: NVidia Corporation, NV17 () Board, Chip Rev A2 (OEM: NVidia) vesafb: VBE version: 3.0 vesafb: protected mode interface info at c000:f200 vesafb: pmi: set display start = c00cf245, set palette = c00cf2ca vesafb: pmi: ports = b4c3 b503 ba03 c003 c103 c403 c503 c603 c703 c803 c903 cc03 ce03 cf03 d003 d103 d203 d303 d403 d503 da03 ff03 vesafb: hardware doesn't support DCC transfers vesafb: monitor limits: vf = 0 Hz, hf = 0 kHz, clk = 0 MHz vesafb: scrolling: redraw vesafb: framebuffer at 0xe0000000, mapped to 0xe0807000, size 16384k
Created attachment 43150 [details] Output from LFB.EXE
I updated to 2.6.9-gentoo-r1. This reset bug seems to be resolved there.
Great, thanks for keeping us informed.
