Date: Mon, 04 Sep 2000 10:25:37 +0200 (IST) From: Roman Shterenzon <roman@harmonic.co.il> To: Allen Campbell <allenc@verinet.com> Cc: freebsd-stable@freebsd.org Subject: Re: bad 16550A maybe? Message-ID: <968055937.39b35c819711e@webmail.harmonic.co.il> In-Reply-To: <39B2BCD8.CCFF9655@verinet.com> References: <Pine.BSF.3.96.1000902074531.8872A-100000@gaia.nimnet.asn.au> <39B19295.3D66E41@verinet.com> <200009030158.TAA01926@nomad.yogotech.com> <39B2BCD8.CCFF9655@verinet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, Just want to throw couple of bits to the thread, having exactly the same problem when syncing my pilot with ThinkPad 600E, adding flag 0x8 to the sio driver solved the problem (I think it did). This flag allows sooner recovery from lost interrupts. I read the code of sio.c but I cannot tell why this flag helps, in my opinion it's not related. Perhaps a coincidence.. But I agree that the trigger should be at least given as flag to the driver, or, if possible via the sysctl interface. Just my 0.02 $ Quoting Allen Campbell <allenc@verinet.com>: > Nate Williams wrote: > > > > > > > Maybe. silo overflows happen because the machine is too slow > to > > > > > service the interrupt before the buffer overflows (but unless > it is a > > > > > 386SX25 you should have enough CPU power). It can also be > caused by > > > > > baud rate mismatches, but that's fairly rare and unusual (you > usually > > > > > get framing errors from a 16550A in this case). This can also > be > > > > > caused by other hardware misbehaving and blocking interrupts. > > > > > > > > I ran a 386SX16 under DOS 5 / DESQView (~10 tasks in 6Mb) using > David > > > > Nugent's BNU FOSSIL driver as a Fidonet mailer/BBS for almost 9 > years, > > > > hardly ever seeing 16550A overflows at 14 byte thresholds, albeit > 14.4k. > > > > > > You actually run a 386SX25? I have a 486/133 that has always > > > experienced intense SILO overflows (yes, it is a true 16550, bought > > > specifically to address this,) under FreeBSD. > > > > Which version of FreeBSD? I've been running (well, I quit the > company, > > but the box is still up) a 486/66 with 4 16550A's running full-blast @ > > 115K on the modems with nary a problem. > > 4.0-STABLE at the moment. The problem began somewhere in the 3.X > series. Prior to 3.X, I never saw a SILO overflow from this machine. > > > The box is a firewall, DNS, email, and modem server for a small > office, > > and is working great. > > > > The only modifications were to continually upgrade the software such > as > > BIND and SENDMAIL where remote root exploits were possible, but > > otherwise it's a stock FreeBSD 2.2.8 system. (No X, of course.) > > > > > I suspect the problem is exasperated by PIO mode IDE and an ISA > > > NE2000. Anyhow, the threshold most definitely MUST be lowered when > > > communicating at >50Kbps with my USR modem. > > > > We're running the same setup (PIO IDE and a NE2000), and I've ran all > 4 > > modems (2 USR Sportsters and 2 USR V.Everythings) full-blast one day > to > > see how well it would handle it. Not once did it even hiccup or lose > > packets. > > Try loading the IDE drive and the NE2000 at the same time. I don't see > SILO overflows while the box is simply driving the serial port, but let > some other host on my network make the NFS exported drives busy while > the modem is working and the SILO overflows erupt. > > Nate, I don't know what to say to this except you only need to search > -questions or usenet to find countless examples of the same problem with > the same symptoms being reported. These people have no agenda other > than fixing the problem. Perhaps the PIC/chipset implementation makes > this less cut and dry and, in your case, you got lucky. Maybe it's the > early version of FreeBSD you are running. Sun spots perhaps? I don't > know. > > > > I would kill for a kernel option that makes patching unnecessary but > > > the attitude, as expressed above, that anything faster than a > 386SX25 > > > can not possibly be too slow seems to preclude this. > > > > I'm with Rod Grimes in stating that something happened in later > releases > > of FreeBSD that makes this difficult or impossible. > > Huh? > > Jim King posted the patch that does the trick earlier in this thread. I > know for fact this works. I've been applying something similar to sio.c > since 3.1-RELEASE. It basically makes a one line change that lowers the > 16550A threshold to 8 bytes. How is it difficult or impossible to > accommodate this with an #ifdef based on a kernel option, i.e. option > 16550_LOW_THRESHOLD... ? > > And here it is again: > > --- sio.c.orig Wed Aug 16 09:29:34 2000 > +++ sio.c Fri Sep 1 14:53:47 2000 > @@ -2345,7 +2345,7 @@ > * latencies are larger. > */ > com->fifo_image = t->c_ospeed <= 4800 > - ? FIFO_ENABLE : FIFO_ENABLE | > FIFO_RX_HIGH; > + ? FIFO_ENABLE : FIFO_ENABLE | > FIFO_RX_MEDH; > #ifdef COM_ESP > /* > * The Hayes ESP card needs the fifo DMA mode bit set > > -- > Allen Campbell | Lurking at the bottom of the > allenc@verinet.com | gravity well, getting old. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" in the body of the message > --Roman Shterenzon, UNIX System Administrator and Consultant [ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?968055937.39b35c819711e>