Linmodems Mailing list Archives


Return-Path: <>
Mailing-List: contact; run by ezmlm
Delivered-To: mailing list
Received: (qmail 29567 invoked from network); 11 Mar 2001 04:46:08 -0000
Received: from (
  by with SMTP; 11 Mar 2001 04:46:08 -0000
Received: from ([]
	by with esmtp (Exim 3.16 #5)
	id 14bxjb-0007Oq-00 ; Sat, 10 Mar 2001 23:45:35 -0500
Sender: marv
Message-ID: <>
Date: Sat, 10 Mar 2001 23:44:33 -0500
From: Marvin Stodolsky <>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Shattow <>
Subject: Re: ltmodem: (rant)    flaws in I/O logic?
References: <001201c0a9c1$ab3e8f40$1e47ee9d@lucy>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


A knowledgeable answer will have to await return of coders Mark Spieth
and Chris Hebiesen from conferences next week.  

But it will I'm sure include the following:
1) Little has been decoded out of the proprietary DSP binary, except for
deciphering PCI recognition codes.
2) A clean split of the module support into proprietary and public
serial components has been initiated by Chris, and you may be able to
partially answer your questions by reading the scripts and public code.

Separately I'll send you a 1st version of this new kit.  Please don't
pass it on at this time.  It will per usual be sent out to a test group
of experienced Users for hard testing, once the trivia bugs have been
cleaned up.


> Shattow wrote:
> Hi.  What kind of logic is used to detect the I/O ports and device IDs for
> installed lucent-tech winmodems?
> I have noticed that especially on PCI busses where the PCI bus is on a
> traditional IRQ (0-15), and the devices on the PCI bus have more than one
> device on each Sub-node, that any mis-use of the bus can result in wierd
> things happening. In case none of that made any sense.... i'll illustrate:
> 1.   ltmodem driver scans all predefined I/O ranges on PCI IRQ 11, sub-pci
> node 8.3(a/b/c)
> 2.    soundcard, also on [8.3] freaks out, starts a loud buzzing noise
> 3.    I get annoyed.
> the point is, i am guessing that there is some huge difference between the
> way the closed-source 5.68 driver and the new gimpy-source 5.78 driver
> allocate an IRQ/IO range and get everything communicating.  the
> closed-source driver worked as it should, but the gimpy-source driver acts
> like a herd of wounded animals all running into each other. it works,
> overall, but is not very efficient.  i heard mention of rewriting the driver
> from scratch using the generic serial driver code instead of the full blown
> serial driver.   can i have some more feedback on this from everyone
> interested?  My opinion is that detecting the winmodem device is not very
> useful. There should be a lookup table in an external file '#include'd into
> the driver when compiled.  No need to actually scan a bunch of IO and IRQ
> ports, just add it to the lookup table.  Anyone with a different ID can send
> in a patch with their device and IDs etc....   I am observing that a major
> restructuring of the ltmodem driver is necessary.
> What is going on with the closed-source portion of the driver?    Are there
> just a couple of callback functions and stuff?   i remember seeing some
> hacking notes on a disassembly of the old closed-source driver.  i would
> like to see a description of what parts of the closed portion of the new
> gimpy-source driver do.  i suspect that some of the crucial I/O setup is in
> the closed-source portion, which isn't working optimally with the 2.4.x
> linux kernel.  if this is not true, then it may be a case where rewriting
> the driver is necessary.  if it is true, then there's some issues that need
> to be worked around.
> ideas... many.....   feedback?
> -eric

Webmaster: Russell Nelson
Last modified: Wed Jul 30 11:02:43 EDT 2003