Description of problem: When using RedHat 8.0 with GNOME, programs that use inb to read from an IO port appear to create spurious carriage returns when they are run inside a gnome-terminal. I first noticed the trouble when running programs using a data acquisition device driver I wrote, but I was able to reproduce the same effect with just a small foo.c program that is compiled with gcc and run as root so the ioperm call will work. It appears that calling inb somehow generates extra carriage returns which are output to the gnome-terminal and then interpreted as user input. In this case, the input was processed at the command line, but if foo had been waiting for user input (eg press return to continue) it would have processed the extra CRs. When foo is run from a standard Ctrl+Alt+F1 console, no extra CRs appear. Both foo.c and the gnome-terminal output it produces are included below. Thanks for your help with this, W.Tucker PostNorder(at)aol.com Version-Release number of selected component (if applicable): 2.0.1 How reproducible: Very, although the number of carriage returns varies. Steps to Reproduce: 1. Compile and run as root the following foo.c that calls inb --------------- Start foo.c ---------------------- #include <stdio.h> #include <asm/io.h> // for inb int main( void ) { long usec; unsigned char value; ioperm( 0x378, 5, 1 ); printf( "Testing ...\n" ); usec = 300000; while( usec-- ) value = inb( 0x379 ); printf( "Finished\n" ); return( 0 ); } --------------- End foo.c ---------------------- Actual results: --------------- Start actual output from foo ---------------------- Testing ... Finished [root@Linux foo]# [root@Linux foo]# [root@Linux foo]# [root@Linux foo]# [root@Linux foo]# [root@Linux foo]# [root@Linux foo]# [root@Linux foo]# --------------- End actual output from foo ---------------------- Expected results: --------------- Expected output from foo ---------------------- Testing ... Finished [root@Linux foo]# --------------- End expected output from foo ---------------------- Additional info:
I can't reproduce this problem with vte-0.11.11-13. I'm going to assume it has been fixed, but if you continue to have issues, feel free to reopen.