From owner-freebsd-hackers Sat Jul 13 10:52:34 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA29977 for hackers-outgoing; Sat, 13 Jul 1996 10:52:34 -0700 (PDT) Received: from axp5.physik.fu-berlin.de (axp5.fddi5B.fu-berlin.de [160.45.5.75]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA29966 for ; Sat, 13 Jul 1996 10:52:25 -0700 (PDT) Received: from titania.physik.fu-berlin.de (titania.physik.fu-berlin.de [160.45.33.86]) by axp5.physik.fu-berlin.de (8.7.1/8.7.1) with ESMTP id TAA00506; Sat, 13 Jul 1996 19:52:15 +0200 (MET DST) Received: (from graichen@localhost) by mordillo (8.6.12/8.6.12) id RAA01130; Sat, 13 Jul 1996 17:03:24 +0200 From: Thomas Graichen Message-Id: <199607131503.RAA01130@mordillo> Subject: Re: sio / modem problems To: bde@zeta.org.au (Bruce Evans) Date: Sat, 13 Jul 1996 17:03:24 +0200 (MET DST) Cc: hackers@FreeBSD.org In-Reply-To: <199607112254.IAA18667@godzilla.zeta.org.au> from "Bruce Evans" at Jul 12, 96 08:54:57 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk hasn't Bruce Evans said ? ... > > >> i have an internal creatix phone-master modem - which will be detected in > >> FreeBSD 2.0.5 but not in the 2.1.0 RELEASE or the march 2.2 snap - it's > > The probe didn't change (not even one byte of the source) between 2.0.5R > and 2.1.0R. > > Revision 1.135 on 25 Feb introduced some delays in the probe in the hope > of fixing this problem. These should be in the March 2.2 snap. > > These changes are missing from -stable :-(. (Or `:-)' if they actually > make things worse :-). > > The probe hasn't changed significantly in -current since rev.1.135. > > >I recently fixed a modem detection problem from someone by inserting > >"DELAY(1000);"'s in sioprobe() everywhere the /* EXTRA DELAY? */ comment > >appeared. It's a hack, but clearly some portion of that code is running > > The delays in rev.1.135 are in slightly different places. They are > probably necessary if the UART is actually a bunch of i/o ports under > software control. The software can reasonably take a long time to > complete a sequence of events that it initiates. OTOH, for events > initiated by the host cpu, such as writes to control registers, the > UART needs to respond withing a few hundred nsec to preserve 16550 > compatibility. Otherwise back to back writes to a control register > 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 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 ? t p.s.: thanks to all the people who replied to my question -- thomas graichen graichen@mail.physik.fu-berlin.de graichen@FreeBSD.org perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away antoine de saint-exupery