Lucent Microelectronics Venus Modem, serial 5.05, and Linux 2.4.0

Lucent Microelectronics Venus Modem, serial 5.05, and Linux 2.4.0

[W. Michael Petullo]

Theodore, et al.,

I have a Lucent Microelectronics Venus Modem (V90, 56KFlex) (rev 0) based
modem which /almost/ works with your serial driver.  Giving the modem
an ATI command returns AEIGPM560LKTF1.  The company that manufactures
the modem calls it a PM560LKC 56K Internal PCI Call Waiting Modem.
At the very end of this message you will find the output `lspci` and
`cat /proc/bus/pci/00/06.0 | od -h` on my computer.

I recently wrote you about some problems I was having with this modem.
I have found some time to play around with version 5.05 of your driver
and the 2.4.0 Linux kernel, and wanted to share what I have found.

First, I added the following to the pci_boards array in serial.c:

...
{       0x11c1, 0x0480,
	0x1668, 0x0500,
	SPCI_FL_BASE1, 1, 115200 },
...

I found this data in the file located in /proc/bus/pci/00/ associated
with my modem.

In order for pci_announce_device to work with my modem, I also had to
change serial_pci_tbl's class_mask field from 0xffff00 to 0xff0000 in
serial.c.  This causes pci_announce_device to announce any communication
device (PCI_BASE_CLASS_COMMUNICATION) instead of just serial ports
(PCI_CLASS_COMMUNICATION_SERIAL).  In order for my modem to be caught,
the mask had to approve PCI_CLASS_COMMUNICATION_OTHER.

Once I made these two changes, I was back to the problems I was having
before, as documented in the message quoted at the bottom of this one.
Once I made the further modifications documented in this quoted email,
version 5.05 of your serial driver worked with my modem.  Of course,
these modifications are far from the ideal; I am still trying to figure
out what is really going on.

I could send a patch with these changes if you would like.  Any comments?

=============== previous message: =========================================

> The modem is auto-detected fine -- sometimes.  The auto-detection process
> does not fail according to any pattern that I can see.

> There are three different results I see after the auto-detection process:

> 1.  The modem is detected correctly.
> 2.  The modem is detected, but as a 8250 type UART.
> 3.  The modem is not detected.

> In serial.c, you seem to perform a check by writing to a possible
> modem's interrupt enable register and reading the result.  This seems to
> be one of the points at which the auto-configuration process occasionally
> fails.  If I make the following change to this code my modem seems to
> be auto-detected correctly all of the time:

>                scratch = serial_inp(info, UART_IER);
>		serial_outp(info, UART_IER, 0);
> #ifdef __i386__
>		outb(0xff, 0x080);
> #endif
>		scratch2 = serial_inp(info, UART_IER);
>		serial_outp(info, UART_IER, 0x0F);
> #ifdef __i386__
>		outb(0, 0x080);
> #endif
> -             scratch3 = serial_inp(info, UART_IER); /* REMOVE */
> +             scratch3 = 0x0f                        /* ADD */
> 		serial_outp(info, UART_IER, scratch);

> If I print the values of scratch, scratch2, and scratch3, they are:

> 00, 00, and 0f for a successfully detected serial port, respectively
> ff, ff, and ff for a serial port which was not detected and does not exist
> and
> 00, 00, and 00 for my modem when detection fails.

> When the modem /is/ detected setserial says ``UART: 16550A, Port: 0xd400,
> IRQ: 5.''

> The reason for my interest in auto-detecting my modem instead of using
> setserial is two-fold.  First, I am using devfs.  This makes running
> setserial awkward because the modem needs to be auto-detected for
> the kernel to make a device entry in my device filesystem for it.
> Second,I use a modular serial driver and a pre-install entry in my
> modules.conf file that runs setserial also seems awkward.

> A related question: why does your serial driver not take parameters
> like parport?  It would be nice to be able to do something like `insmod
> parport_pc.o io=0x3bc,0x378,0x278 irq=none,7,auto` and not need setserial
> at all.

=============== lspci -vvv: ===============================================

00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-751 [Irongate] System Controller (rev 23)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
	Latency: 160
	Region 0: Memory at e0000000 (32-bit, prefetchable) [size=128M]
	Region 1: Memory at eddff000 (32-bit, prefetchable) [size=4K]
	Region 2: I/O ports at d800 [disabled] [size=4]
	Capabilities: [a0] AGP version 1.0
		Status: RQ=15 SBA+ 64bit- FW- Rate=x1,x2
		Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>

00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-751 [Irongate] AGP Bridge (rev 01) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 160
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=160
	I/O behind bridge: 00008000-00008fff
	Memory behind bridge: ede00000-efefffff
	Prefetchable memory behind bridge: d9c00000-ddcfffff
	BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-

00:03.0 SCSI storage controller: Adaptec AIC-7881U (rev 01)
	Subsystem: Adaptec AHA-2940UW SCSI Host Adapter
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 160 (2000ns min, 2000ns max), cache line size 08
	Interrupt: pin A routed to IRQ 10
	Region 0: I/O ports at dc00 [size=256]
	Region 1: Memory at effff000 (32-bit, non-prefetchable) [size=4K]
	Expansion ROM at effe0000 [disabled] [size=64K]
	Capabilities: [dc] Power Management version 1
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:04.0 Multimedia video controller: Brooktree Corporation Bt878 (rev 02)
	Subsystem: Hauppauge computer works Inc.: Unknown device 13eb
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 160 (4000ns min, 10000ns max)
	Interrupt: pin A routed to IRQ 9
	Region 0: Memory at eddfd000 (32-bit, prefetchable) [size=4K]

00:04.1 Multimedia controller: Brooktree Corporation Bt878 (rev 02)
	Subsystem: Hauppauge computer works Inc.: Unknown device 13eb
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 160 (1000ns min, 63750ns max)
	Interrupt: pin A routed to IRQ 9
	Region 0: Memory at eddfe000 (32-bit, prefetchable) [size=4K]

00:06.0 Communication controller: Lucent Microelectronics Venus Modem (V90, 56KFlex)
	Subsystem: Action Tec Electronics Inc: Unknown device 0500
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (63000ns min, 3500ns max)
	Interrupt: pin A routed to IRQ 5
	Region 0: Memory at efffef00 (32-bit, non-prefetchable) [size=256]
	Region 1: I/O ports at d400 [size=256]
	Region 2: I/O ports at d000 [size=256]
	Region 3: I/O ports at cc00 [size=8]
	Capabilities: [f8] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2+ AuxCurrent=0mA PME(D0-,D1-,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 15)
	Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0

00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06) (prog-if 8a [Master SecP PriP])
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Region 4: I/O ports at ffa0 [disabled] [size=16]

00:07.4 SMBus: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 10)
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-

00:09.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] (rev 01)
	Subsystem: Unknown device 4942:4c4c
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 160 (3000ns min, 32000ns max)
	Interrupt: pin A routed to IRQ 11
	Region 0: I/O ports at c800 [size=64]

00:0f.0 Ethernet controller: Digital Equipment Corporation DECchip 21041 [Tulip Pass 3] (rev 21)
	Subsystem: D-Link System Inc DE-530+
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 160
	Interrupt: pin A routed to IRQ 10
	Region 0: I/O ports at c400 [size=128]
	Region 1: Memory at efffee80 (32-bit, non-prefetchable) [size=128]
	Expansion ROM at eff80000 [disabled] [size=256K]

01:05.0 VGA compatible controller: nVidia Corporation Vanta [NV6] (rev 11) (prog-if 00 [VGA])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 160 (1250ns min, 250ns max)
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at ee000000 (32-bit, non-prefetchable) [size=16M]
	Region 1: Memory at da000000 (32-bit, prefetchable) [size=32M]
	Expansion ROM at efef0000 [disabled] [size=64K]
	Capabilities: [60] Power Management version 1
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [44] AGP version 2.0
		Status: RQ=31 SBA- 64bit- FW- Rate=x1,x2
		Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>

=============== cat /proc/bus/pci/00/06.0 | od -h: ========================

0000000 11c1 0480 0107 0290 0000 0780 0000 0000
0000020 ef00 efff d401 0000 d001 0000 cc01 0000
0000040 0000 0000 0000 0000 0040 0000 1668 0500
0000060 0000 0000 00f8 0000 0000 0000 0105 0efc
0000100 0505 0505 0505 0505 0505 0505 0505 0505
*
0000360 0505 0505 0505 0505 0001 e422 0000 0000
0000400

-- 
W. Michael Petullo

:wq
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Lucent Microelectronics Venus Modem, serial 5.05, and Linux 2.4.0

[tytso]

On Sun, Jan 14, 2001 at 08:10:45PM +0100, W. Michael Petullo wrote:
> > In serial.c, you seem to perform a check by writing to a possible
> > modem's interrupt enable register and reading the result.  This seems to
> > be one of the points at which the auto-configuration process occasionally
> > fails.  If I make the following change to this code my modem seems to
> > be auto-detected correctly all of the time:
> 
> >                scratch = serial_inp(info, UART_IER);
> >		serial_outp(info, UART_IER, 0);
> > #ifdef __i386__
> >		outb(0xff, 0x080);
> > #endif
> >		scratch2 = serial_inp(info, UART_IER);
> >		serial_outp(info, UART_IER, 0x0F);
> > #ifdef __i386__
> >		outb(0, 0x080);
> > #endif
> > -             scratch3 = serial_inp(info, UART_IER); /* REMOVE */
> > +             scratch3 = 0x0f                        /* ADD */
> > 		serial_outp(info, UART_IER, scratch);

The problem is that if this doesn't work, there are some serious
questions about the correctness of the Lucent Microelectronic Venus
modem.  I've forwarded this to someone in the Lucent Modem group, who
can hopefully look at this (and maybe can ship me a sample hardware so
I can play with it, although I'd much rather that he tell me how to
work around the hardware bug, or tell me that all you need is a
firmware upgrade to fix the bug in the modem).....

							- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Lucent Microelectronics Venus Modem, serial 5.05, and Linux 2.4.0

[Theodore Ts'o]

On Sun, Jan 14, 2001 at 08:10:45PM +0100, W. Michael Petullo wrote:
> > In serial.c, you seem to perform a check by writing to a possible
> > modem's interrupt enable register and reading the result.  This seems to
> > be one of the points at which the auto-configuration process occasionally
> > fails.  If I make the following change to this code my modem seems to
> > be auto-detected correctly all of the time:
> 
> >                scratch = serial_inp(info, UART_IER);
> >		serial_outp(info, UART_IER, 0);
> > #ifdef __i386__
> >		outb(0xff, 0x080);
> > #endif
> >		scratch2 = serial_inp(info, UART_IER);
> >		serial_outp(info, UART_IER, 0x0F);
> > #ifdef __i386__
> >		outb(0, 0x080);
> > #endif
> > -             scratch3 = serial_inp(info, UART_IER); /* REMOVE */
> > +             scratch3 = 0x0f                        /* ADD */
> > 		serial_outp(info, UART_IER, scratch);

The problem is that if this doesn't work, there are some serious
questions about the correctness of the Lucent Microelectronic Venus
modem.  I've forwarded this to someone in the Lucent Modem group, who
can hopefully look at this (and maybe can ship me a sample hardware so
I can play with it, although I'd much rather that he tell me how to
work around the hardware bug, or tell me that all you need is a
firmware upgrade to fix the bug in the modem).....

							- Ted

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Lucent Microelectronics Venus Modem, serial 5.05, and Linux 2.4.0

[Ed Schulz]

One editorial correction: Our PCI host-controller modem is based on the
Mars DSP1646 or 1648, not the Venus DSP1673.  Venus modems include the
controller function, so require no special Linux code to work.

I'll forward these notes along to our developers, and let you know the
result.

The "sample hardware" is available quite cheaply from many sources,
although it can be hard to tell what really has Mars inside.  Here are some
brand name PCI modems containing Mars:
- Zoom 3025 (with early Windows V.92 code)
- Zoom 2925L for under $50.
- ActionTec DeskLink Pro PCI for $33.
-- 
Ed Schulz
Agere Systems
edschulz@agere.com

Theodore Ts'o wrote:
> 
> On Sun, Jan 14, 2001 at 08:10:45PM +0100, W. Michael Petullo wrote:
> > > In serial.c, you seem to perform a check by writing to a possible
> > > modem's interrupt enable register and reading the result.  This seems to
> > > be one of the points at which the auto-configuration process occasionally
> > > fails.  If I make the following change to this code my modem seems to
> > > be auto-detected correctly all of the time:
> >
> > >                scratch = serial_inp(info, UART_IER);
> > >             serial_outp(info, UART_IER, 0);
> > > #ifdef __i386__
> > >             outb(0xff, 0x080);
> > > #endif
> > >             scratch2 = serial_inp(info, UART_IER);
> > >             serial_outp(info, UART_IER, 0x0F);
> > > #ifdef __i386__
> > >             outb(0, 0x080);
> > > #endif
> > > -             scratch3 = serial_inp(info, UART_IER); /* REMOVE */
> > > +             scratch3 = 0x0f                        /* ADD */
> > >             serial_outp(info, UART_IER, scratch);
> 
> The problem is that if this doesn't work, there are some serious
> questions about the correctness of the Lucent Microelectronic Venus
> modem.  I've forwarded this to someone in the Lucent Modem group, who
> can hopefully look at this (and maybe can ship me a sample hardware so
> I can play with it, although I'd much rather that he tell me how to
> work around the hardware bug, or tell me that all you need is a
> firmware upgrade to fix the bug in the modem).....
> 
>                                                         - Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Lucent Microelectronics Venus Modem, serial 5.05, and Linux 2.4.0

[Theodore Ts'o]

   Date: Tue, 06 Feb 2001 17:37:12 -0500
   From: Ed Schulz <edschulz@agere.com>

   One editorial correction: Our PCI host-controller modem is based on the
   Mars DSP1646 or 1648, not the Venus DSP1673.  Venus modems include the
   controller function, so require no special Linux code to work.

Well, I've received reports that the UART in the Venus chipset may not
be behaving as a standard UART (i.e., it's not acting as a fully
16550-compatible UART should) which is causing the Linux serial code to
fail the "is-there-a-real-UART-here-or-should-I-refuse-to-touch-unknown-
I/O-ports-which-might-format-hard-drives-or-do-other-nasty-things" test.

   I'll forward these notes along to our developers, and let you know the
   result.

If your developers can tell try testing one of these modems under Linux
2.4, that would be great.  Although I don't have one of these boards,
the symptoms that people are sending me sure make it sound like a
hardware bug (or a UART emulation failure, in any case....)

Note that all the test code is doing is writing 0x0f to the UART's IER
register, and trying to read it back.  If the UART is failing this test,
it's pretty buggy.....

						- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Lucent Microelectronics Venus Modem, serial 5.05, and Linux 2.4.0

[Ed Schulz]

My previous note was probably in error.  W. Michael Petullo probably is
really using a PCI internal Venus DSP1673 modem.  I read too quickly and
assumed that we were talking about the "Linmodem" topic.

I will pass the note around here, and will summarize any replies I get. 
Clearly we should try it under Linux 2.4.

Since Venus modems include the controller function along with RAM and
flash, they're generally more expensive than Mars host-contoller modems. 
Here are some models:
- Zoom 2920
- MultiTech MultiModem ZPX MT5634ZPX-PCI
- Actiontec Call Waiting PCI56012-01CW
-- 
Ed Schulz
Agere Systems
+1 732 949 2066 voice
+1 732 949 5025 fax
edschulz@agere.com

Theodore Ts'o wrote:
> 
> On Sun, Jan 14, 2001 at 08:10:45PM +0100, W. Michael Petullo wrote:
> > > In serial.c, you seem to perform a check by writing to a possible
> > > modem's interrupt enable register and reading the result.  This seems to
> > > be one of the points at which the auto-configuration process occasionally
> > > fails.  If I make the following change to this code my modem seems to
> > > be auto-detected correctly all of the time:
> >
> > >                scratch = serial_inp(info, UART_IER);
> > >             serial_outp(info, UART_IER, 0);
> > > #ifdef __i386__
> > >             outb(0xff, 0x080);
> > > #endif
> > >             scratch2 = serial_inp(info, UART_IER);
> > >             serial_outp(info, UART_IER, 0x0F);
> > > #ifdef __i386__
> > >             outb(0, 0x080);
> > > #endif
> > > -             scratch3 = serial_inp(info, UART_IER); /* REMOVE */
> > > +             scratch3 = 0x0f                        /* ADD */
> > >             serial_outp(info, UART_IER, scratch);
> 
> The problem is that if this doesn't work, there are some serious
> questions about the correctness of the Lucent Microelectronic Venus
> modem.  I've forwarded this to someone in the Lucent Modem group, who
> can hopefully look at this (and maybe can ship me a sample hardware so
> I can play with it, although I'd much rather that he tell me how to
> work around the hardware bug, or tell me that all you need is a
> firmware upgrade to fix the bug in the modem).....
> 
>                                                         - Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/