Date: Wed, 28 Feb 1996 03:25:22 +1100 From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@freefall.freebsd.org, uhclem@nemesis.lonestar.org Subject: Re: i386/1042: Warning from sio driver reports wrong device FDIV045 Message-ID: <199602271625.DAA06241@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>[1]The following reply was made to PR i386/1042; it has been noted by GNATS. >Well I guess this additional input won't be in there... :-) It's a bit too easy to have replies noted by GNATS. >[0]Note that the system reports the problem on sio1, when there is nothing >[0]connected to that port. That actual overrun probably occurred on sio0 >[0]or sio3. > >[1]This may be caused by sio1 picking up radiation from the other ports. >This is not the case. One of the WorldBlazers was connected to >sio1 but was not taking calls when the problem was noticed. To simplify >the error report, the modems were moved off the ports to see if the >problem moved. The error message did not follow the modems. >No matter what modem or modems were busy, the error message always >said sio1. There isn't much that can go wrong in counting and reporting the errors. Please report the output from `pstat -t' run while errors are arriving. I usually get error messages for sio0, e.g.: Feb 24 00:07:51 alphplex /kernel: sio0: 2168190 more interrupt-level buffer overflows (total 3476872) I bet you don't get that many errors, especially in one second :-). I was debugging an UMC hardware bug. >[0]2. There doesn't appear to be any documentation on what the kernel >[0] error message is trying to report. > >[1]See the sio man page. >Ok, how do I "fix the application?" (uucico) as the man page cryptically >suggests when the application runs fine on other ports running at 57600 >with faster DCE data rates (28.8 vs 24)? If we have the equivalent of >a TTYHOG or CLIST limits, where are they controlled? (I have already >looked at the LINT kernel.) The man page should say something like "problem in the application mix". An application can't be blamed for not getting enough cpu cycles if it has to compete with too many other applications. TTYHOG can only be controlled by redefining it and recompiling. The clist limits are mostly controlled by TTYHOG. >[0] Since there appears to be code in sio.c that would detect overruns >[0] in the hardware FIFO, report this and lower the trigger value >[0] automatically, either this code isn't working or this isn't the >[0] type of overrun the kernel is trying to report. Again, no >[0] documentation. > >[1]That code has almost always been disabled and doesn't exist in -current. >[1]It tended to drop the trigger level to 1 for transient errors. >Great. :-( It was one of the few parts of the driver that wasn't >goofy. The figure-out-what-type-of-UART-you-have is a bad idea and can >freak on many internal modems. "Reserved" and "0" for apparently-unused >bits mean different things to different silicon vendors. The UART detection hasn't caused any problems that I know of. Checking that the IRQ works is what causes problems. How do you want the UART type to be configured? Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602271625.DAA06241>