Date: Sun, 14 Jul 1996 08:11:46 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, graichen@axp5.physik.fu-berlin.de Cc: hackers@FreeBSD.org, v@godzilla.zeta.org.au Subject: Re: sio / modem problems Message-ID: <199607132211.IAA03154@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> might lose the intermediate steps... I added delays in exactly the >> cases where it seems reasonable for the UART to be slow. >> >but they are not enough :-) - but i solved it (half) - i disabled the "fast AT >cycle option" and now it is detected fine - i found that out after playing If the bus speed is out of spec then it's not surprising that some hardware fails. It's surprising that it only fails in the probe, however. The probe is mostly less demanding than the main code. BTW, there is a problem in the main code for some buggy (Startech?) 16550 UARTs. These UARTs report that there is data ready slightly before the data is ready. This causes doubled characters in the input. Delaying 1us at the critical point would reduce efficiency of the interrupt handler by 33%. >around a bit with the 2.0.5 kernel (the generic detected it but a smaller >kernel built for my system not - 2.0.5 too - this way i found out that it is >some kind of timing problem - it is detected by all kernels if i turned off >the turbo switch of the computer - this way i came to the bios setting) >now the question is - can it be solved by software (some more delays) >because linux detects it fine ? Only if the problem is understood. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607132211.IAA03154>