From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (qmail 19484 invoked from network); 11 Jun 1998 20:10:00 -0000 Received: from ts2-05.idf.cyberhighway.net (HELO draken.localnet) (root@209.161.42.35) by mail2.redhat.com with SMTP; 11 Jun 1998 20:10:00 -0000 Received: from localhost (lcr@localhost) by draken.localnet (8.8.5/8.8.5) with SMTP id LAA05281 for ; Thu, 11 Jun 1998 11:31:40 -0600 Date: Thu, 11 Jun 1998 11:31:40 -0600 (MDT) From: "L. C. Robinson" X-Sender: lcr@draken.localnet Reply-To: infynity@cyberhighway.net To: blinux-list@redhat.com Subject: Re: segmentation fault?? and fsck problems. In-Reply-To: <357f91ed.ccs@ccs.covici.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Id: I thought you might have problems with this. I wonder if it's because you might need to set the protocol on the serial port to match your terminal device setup. The command to do this would look something like this: stty speed 19200 cs8 -parenb -cstopb < /dev/ttyS0 This would need to be adjusted for the protocol you are using, of course. You can make stty report the existing protocol by running the stty command with no protocol options (but add '-a' to force stty to report everything). Note the odd direction of the redirection operator '<': this is correct. I suspect that the reason things work better with screader is because you are logged in on a fully booted system, and before you logged in, the getty set the protocols on the serial port correctly. Of course, gettys are not active till the boot process is complete. Screader is not responsible for setting the port up, but it does offer lots of advantages in terms of controlling the output, of course. Has anyone found a way to get speech software like screader, working on a system that is not yet fully operational (during the boot process)? This problem with not having access to the speech resources of the machine before it is fully booted (which I believe is the way things should be), is the reason why I think that the right way to handle the boot message problem for blind users, is to log everything possible, and allow the user to look at the log files after the boot is complete (this could be automated). Extra help should be added where possible, in case things go wrong, by playing wav files, beeping, and the like, to give cues during the boot. This discussion has helped me to get a better idea where to add such things to a modified "initscripts" package which I have been working on. I am, of course, interested in the ideas of others, especially since I am not blind, and do not have any speech hardware, and so have difficulty testing many aspects of the concept. On Thu, 11 Jun 1998, John Covici wrote: > on Thu, 11 Jun 1998 00:31:26 -0600 (MDT) "L. C. Robinson" in > wrote: > >On Wed, 10 Jun 1998, John Covici wrote: > > > >> I didn't want to redirect the whole sysinit process because I had > >> already put in those echo statements and didn't want to confuse things > >> further. Also, I want the screens to remain the same in case > >> something else goes wrong where I need sighted assistance. > > > >You probably just need to do: > >fsck [options] > /dev/ttyS0 > >or something similar. I tried doing: > >exec > /dev/tty6 2> /dev/tty6 < /dev/tty6 > >fsck -fV /dev/hdc2 > >and it worked in interactive mode (hdc2 is a small experimental > >partition I use). > > I wonder if that is because its a tty and not a serial port -- I have > had some other problems with programs redirecting their output to the > serial port -- I can't remember which programs they were, but I know I > had problems with that approach -- that is why I want to run a program > like screader and use that instead. > > >fsck -fV /dev/hdc2 > /dev/tty6 2> /dev/tty6 < /dev/tty6 > >worked similarly. -- L. C. Robinson reply to infynity@cyberhighway.net (a family account) People buy MicroShaft for compatibility, but get incompatibility and instability instead: then they get to buy upgrades to fix it, and get still more problems. This is award winning "innovation".