Janina points out a serious flaw in speakup. Several times at work we have had important servers down for an extended period of time because a serial doubletalk lt was unplugged from its serial port. I cannot say for sure whether the hang was caused during a boot (a reboot) or after the boot was completed. We sometimes have power failures long enough to discharge an UPS when nobody is around. Crashes or hangs like this are a really bad thing, because they cause service interruptions for our users. They could be prevented by limiting the amount of data that speakup would output into an overloaded or unplugged synthesizer. Of course, if speakup is no longer supporting serial synthesizers, I guess the problem is going away. I would prefer that the problem be fixed, rather than just requiring software synthesizers. It may be that folks like John would like at times for the kernel to stop and wait for speakup to catch up when it gets behind. If so, I propose that a kernel parameter be added to cause speakup to make the kernel wait for speakup to catch up, but without that kernel parameter, speakup would simply throw away its output when it couldn't get the synthesizer to take it. D. Curtis Willoughby On Thu, 9 Oct 2014 16:34:12 -0400 Janina Sajka <janina@xxxxxxxxxxx> wrote: > I should probably add I haven't seen Speakup hangs recently. > I do believe you can easily create one, though, by calling Speakup to > talk to one of the four ttyS? devices and then not hooking something up > at that address. I believe this would hang the boot still, but this si > much NOT a big deal. On Thu, 09 Oct 2014 11:08:04 -0500 "John G. Heim" <jheim@xxxxxxxxxxxxx> wrote: > Hmmm... I don't know. I have to say that I remain unconvinced. I've > never seen speakup cause a kernel panic. On the other hand, I have > witnessed the false cause effect. Something happens that causes a kernel > panic and since speakup is part of the kernel, it naturally has > problems. You were on a development server, right? Isn't it more likely > that one of the developers crashed the server amd that, in turn, caused > problems for speakup? I run some development servers here at the UW math > department and it happens all the time. Somebody causes an OOM (out of > memory) event and, yes, that crashes speakup. > I once asked on the kernel developers list for comments on what's wrong > with the speakup code. There is that one biggie, of course, speakup > writes directly to the serial port. But all the other criticisms were > things like not following naming conventions, poor indentation, etc. > Maybe the people who mattered didn't bother to answer my question. But > there wasn't anything in there that would tend to indicate that speakup > is prone to causing kernel panics. Now, any software package can have a > bug. But I have no reason to believe that speakup is particularly > unstable. Quite the contrary in fact. > And even if there is a bug in speakup that can cause a kernel panic, > that's an argument for finding the bug and fixing it. Not for abandoning > it entirely. > On 10/09/14 08:34, Deedra Waters wrote: > > Janina, > > > > speakup was the cause because when bossman came down to hook up a > > monitor and look, the panick messages had something to do with speakup. > > > > As for backing up their work, they were trying to fix their fuck-up to > > begin with. The initial problem wasn't with speakup. However when i was > > helping them debug it, speakup made the kernel panick and crash. > > > > Debian i dont think likes people with root access on their box to begin > > with, but i think they kind of didn't like speakup in their kernel to > > begin with. > > > > I suspect on the other hand that if speakup was a user-space app, it > > wouldn't have mattered to them so much. If a userspace program crashes > > it doesn't take down the whole box. When speakup does though, it takes > > down the whole box. > > > > _______________________________________________ Speakup mailing list Speakup@xxxxxxxxxxxxxxxxx http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
