Major problem with serial driver and serial_pci_guess_board()

Major problem with serial driver and serial_pci_guess_board()

[Marc Boucher]

Hi folks,

It seems that serial_pci_guess_board() is incorrectly detecting
and claiming devices that it can't handle, like ALI AC97 modems
(and perhaps also others such as VIA, and Intel ICH MC97 codecs),
which are supported by our HSF and HCF modem drivers. But since
the serial driver has falsely claimed the device, our driver's
probe() routine never gets called.

This problem appears to be present in all recent serial driver variants,
including those in 2.6 and the latest RedHat Severn beta. It is
a serious issue preventing our drivers from working correctly.

For example:

00:08.0 Modem: ALi Corporation Intel 537 [M5457 AC-Link Modem]

00:08.0 Class 0703: 10b9:5457
        Subsystem: 103c:0025
        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-
        Interrupt: pin A routed to IRQ 10
        Region 0: Memory at e0002000 (32-bit, non-prefetchable)
[size=4K]
        Region 1: I/O ports at 1400 [size=256]
        Capabilities: [40] 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-


PCI: Enabling device 00:08.0 (0000 -> 0003)
Redundant entry in serial pci_table.  Please send the output of
lspci -vv, this message (10b9,5457,103c,0025)
and the manufacturer and name of serial board or modem board
to serial-pci-info@lists.sourceforge.net.
register_serial(): autoconfig failed

But the serial driver has, despite the autoconfig error messages,
still attached itself to the device, preventing any other
(proper) driver from doing so later.

If the serial driver is statically compiled in the kernel,
it seems that there is no workaround for the user other than
rebuilding the kernel which is not something that your average
new linux user is capable of doing. Doing a setserial uart none
on the port doesn't seem to release the PCI device.

IMHO an init/module parameter should exist to disable the
guessing and perhaps also a list of devices to be
automatically excluded from serial_pci_guess_board().

Opinions?

Arjan, any chance we could get this patched in time for the next
Redhat release?

Regards
Marc

PS: We would include the following PCI IDs in the list of exclusions:

ALI AC-Link
        PCI ID 10B9:5453
        PCI ID 10B9:5457

Intel AC-Link (ICH)
        PCI ID 8086:2416
        PCI ID 8086:2446
        PCI ID 8086:2486
        PCI ID 8086:24C6
        PCI ID 10DE:01C1 (Nvidia variant)

VIA AC-Link
        PCI ID 1106:3068


ATI AC-Link
		PCI ID 1002:434D

SIS AC-Link
		PCI ID 1039:7013

HSF/HSFi (Standard and SmartDAA)

        PCI ID {127A,14F1}:{2013,2014,2015,2016}
        PCI ID {127A,14F1}:4311 (RIPTIDE)
        PCI ID {127A,14F1}:{1023,1024,1025,1026} (else try HCF driver)
        PCI ID {127A,14F1}:{2004,2005,2006} (else try HCF driver)
        PCI ID 127A:2114

        PCI ID 14F1:{2043,2044,2045,2046}
        PCI ID 14F1:{2063,2064,2065,2066}
        PCI ID 14F1:2093
        PCI ID 14F1:{201A,201B}
        PCI ID 14F1:{204A,204B}
        PCI ID 14F1:{2143,2144,2145,2146}
        PCI ID 14F1:{2163,2164,2165,2166}
        PCI ID 14F1:{2343,2344,2345,2346}
        PCI ID 14F1:{2363,2364,2365,2366}
        PCI ID 14F1:{2443,2444,2445,2446}
        PCI ID 14F1:{2463,2464,2465,2466}

        PCI ID 14F1:{2F00,2F01,2F02,2F03,2F04}
        PCI ID 14F1:{2F10,2F11,2F12,2F13,2F14}
        PCI ID 14F1:2702
        PCI ID 14F1:2F02

        PCI ID 14F1:{158B,0001} (Allied Data Technologies)
        PCI ID 14F1:{158B,0005} (Allied Data Technologies)


HCF
        PCI ID {127A,14F1}:{1002,1003,1004,1005} (71DP v90)
        PCI ID {127A,14F1}:{1023,1024,1025,1026} (else try HSF driver)
        PCI ID {127A,14F1}:{2004,2005,2006} (else try HSF driver)
        PCI ID {127A,14F1}:{1033,1034,1035,1036}
        PCI ID {127A,14F1}:{1085}
        PCI ID {127A,14F1}:{4321} (RIPTIDE)
        PCI ID 14F1:{10B3,10B4,10B5,10B6}
        PCI ID 14F1:{1803,1813,1815} (LAN/Modem Combo)
        PCI ID 14F1:{1F10,1F11,1F14,1F15}
        PCI ID 14F1:{1053,1054,1055,1056} (SmartHCF board rev 3)
        PCI ID 14F1:{1052,1057,1059} (SmartHCF board rev 4)
        PCI ID 14F1:{1063,1064,1065,1066} (SmartHCF US-only, Dell)
        PCI ID 14F1:{1453,1454,1455,1456} (SmartHCF mini-PCI board rev
3)
        PCI ID 14F1:{1452,1457,1459} (SmartHCF mini-PCI board rev 4)
        PCI ID 148D:1003 (DIGICOM Systems)
        PCI ID 158B:0015 (Allied Data Technologies Tornado VFM56x-PRC)
        PCI ID 141A:1035 (Apache Micro)

Re: Major problem with serial driver and serial_pci_guess_board()

[Arjan van de Ven]

On Tue, Aug 26, 2003 at 02:27:46PM -0400, Marc Boucher wrote:
> 
> Arjan, any chance we could get this patched in time for the next
> Red Hat release?

I don't take patches that have the sole purpose of facilitating binary
only kernel modules.

Re: Major problem with serial driver and serial_pci_guess_board()

[Marc Boucher]

On Tue, Aug 26, 2003 at 08:29:51PM +0200, Arjan van de Ven wrote:
> On Tue, Aug 26, 2003 at 02:27:46PM -0400, Marc Boucher wrote:
> > 
> > Arjan, any chance we could get this patched in time for the next
> > Red Hat release?
> 
> I don't take patches that have the sole purpose of facilitating binary
> only kernel modules.
> 

We have tried very hard to change Conexant's position on this
but the best that we have been able to achieve is the current
compromise (everything non proprietary, i.e. os-specific part is
distributed in source form, modem modulations are included as
an object file), which is acceptable for most users. Just try to
get a modem vendor to release their IP in source and you will see
how hard/impossible it is, given patent and other issues.
There is also in practice little difference between our current split
and a totally open-source driver for a bus-mastering dma card with firmware.
You won't get the firmware in source, yet both can screw up the system if
they are badly written.

In the practical world, the lack of (or deficient) softmodem support
is a serious weakness and obstacle to linux adoption, which we are
trying to fix.

We have received hundreds of "thank-you" mails from users who are very
happy to have working drivers for their modems.

Now let's not get politics get in the way of fixing a real technical bug,
which is the serial driver incorrectly binding itself to an AC97 device
it can't handle.

Marc

Re: Major problem with serial driver and serial_pci_guess_board()

[Russell King]

On Tue, Aug 26, 2003 at 02:27:46PM -0400, Marc Boucher wrote:
> This problem appears to be present in all recent serial driver variants,
> including those in 2.6 and the latest RedHat Severn beta. It is
> a serious issue preventing our drivers from working correctly.

My only interest is in 2.6, and the messages appear to be from a
2.4 kernel.  It does seem that we are detecting a device incorrectly,
since we aren't finding an 8250-compatible serial port.

Unfortunately, we don't have tables of exclusion, nor do we have
a clean method to do that at present in any kernel.

What I'd like to see is the output from lspci -vvx from a range of
PCI cards with this problem to see if there is characteristic (eg,
the PCI class/programming interface IDs) we can pick up on.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Major problem with serial driver and serial_pci_guess_board()

[Marc Boucher]

Hi Russell,

On Tue, Aug 26, 2003 at 08:16:01PM +0100, Russell King wrote:
> On Tue, Aug 26, 2003 at 02:27:46PM -0400, Marc Boucher wrote:
> > This problem appears to be present in all recent serial driver variants,
> > including those in 2.6 and the latest RedHat Severn beta. It is
> > a serious issue preventing our drivers from working correctly.
> 
> My only interest is in 2.6, and the messages appear to be from a
> 2.4 kernel.  It does seem that we are detecting a device incorrectly,
> since we aren't finding an 8250-compatible serial port.

The messages indeed came from a 2.4 kernel, specifically
2.4.21-20.1.2024.2.1.nptl (included in RedHat Severn).

But a similar problem occurs under 2.6 (tested with Arjan's
2.6.0-0.test4.1.32 rpm):

Serial: 8250/16550 driver $Revision: 1.90 $ IRQ sharing enabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
PCI: Enabling device 0000:00:08.0 (0000 -> 0003)
ttyS2 at I/O 0x1428 (irq = 10) is a 8250
ttyS3 at I/O 0x1440 (irq = 10) is a 8250

[root@xe4000 root]# lspci -vvx -d 10b9:5457
00:08.0 Modem: ALi Corporation Intel 537 [M5457 AC-Link Modem] (prog-if
00 [Generic])
        Subsystem: Hewlett-Packard Company: Unknown device 0025
        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-
        Interrupt: pin A routed to IRQ 10
        Region 0: Memory at e0002000 (32-bit, non-prefetchable)
[size=4K]
        Region 1: I/O ports at 1400 [size=256]
        Capabilities: [40] 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: b9 10 57 54 03 00 90 02 00 00 03 07 00 40 00 00
10: 00 20 00 e0 01 14 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 25 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 ff 01 00 00

After a closer look it seems that most of the boards I previously listed
(especially the newer ones) fortunately use PCI_CLASS_COMMUNICATION_OTHER,
not PCI_CLASS_COMMUNICATION_SERIAL or PCI_CLASS_COMMUNICATION_MODEM which
the serial driver looks for.

Still, the ALI AC-Link MC97 device (in an HP laptop here) uses
PCI_CLASS_COMMUNICATION_MODEM and has I/O ports so it gets picked
up by the serial driver.

> Unfortunately, we don't have tables of exclusion, nor do we have
> a clean method to do that at present in any kernel.

Would it not be possible to include devices we *know* use the confusing
class IDs in the pci_serial_quirks table with an initialization
routine that always fails? (under 2.6; for 2.4 we might need to
implement something equivalent)

> What I'd like to see is the output from lspci -vvx from a range of
> PCI cards with this problem to see if there is characteristic (eg,
> the PCI class/programming interface IDs) we can pick up on.

I'll try to send you that info as we confirm other cases..

Many thanks for the quick response,
Marc

> 
> -- 
> Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
>              http://www.arm.linux.org.uk/personal/aboutme.html
> 

Re: Major problem with serial driver and serial_pci_guess_board()

[Marc Boucher]

On Tue, Aug 26, 2003 at 02:54:29PM -0400, Marc Boucher wrote:
> 
> In the practical world, the lack of (or deficient) softmodem support
> is a serious weakness and obstacle to linux adoption, which we are
> trying to fix.
> 
> We have received hundreds of "thank-you" mails from users who are very
> happy to have working drivers for their modems.

here just fyi a couple of fresh messages from users today, illustrating
the situation.  i'm hoping we can work together to make their life easier/
linux experience better and facilitate the switch from proprietary operating
systems, instead of being too religious about it and getting stuck in radical
positions..

Kind regards
Marc

----- Forwarded message from hasan numanoglu <hasan_numanoglu@yahoo.com> -----

Date: Tue, 26 Aug 2003 15:44:12 -0700 (PDT)
From: hasan numanoglu <hasan_numanoglu@yahoo.com>
Subject: Modem problem
To: modem.support@linuxant.com
X-Spam-Checker-Version: SpamAssassin 2.60-cvs (1.196-2003-07-29-exp) on valve.mbsi.ca
X-Spam-Status: No, hits=0.2 required=5.0 tests=BAYES_40,HTML_MESSAGE,RCVD_IN_NJABL 
	autolearn=no version=2.60-cvs
X-Spam-Level: 

Hi, i have downloaded the modem scaner on your site, and ,it detects
Rockwell International HCF 56k Data/Fax/Voice/Spkp (w/Handset) Modem (rev 01)...
Then i looked the modem chip, it s written conexant, they're same may be...
after that i downloaded the hcf and hsf driver but it's not working... i m
using redhat 9 what's wrong ? dont know...? m very close to make an u turn and
use xp :) you're my last hope.. :)
i downloaded the top links of the driver list ( ?thought they re newest..)
Should i try the rest or am i right????
 
thanks...
 
hasan_numanoglu@yahoo.com
 


---------------------------------
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
----- End forwarded message -----

----- Forwarded message from Jonathan Lyster <info@jslyster.com> -----

Date: Tue, 26 Aug 2003 14:56:54 -0700
From: Jonathan Lyster <info@jslyster.com>
Subject: D480 modem and fax capability
To: services@linuxant.com
User-Agent: Opera7.11/Linux M2 build 406
X-Spam-Checker-Version: SpamAssassin 2.60-cvs (1.196-2003-07-29-exp) on valve.mbsi.ca
X-Spam-Status: No, hits=0.0 required=5.0 tests=BAYES_40 autolearn=ham 
	version=2.60-cvs
X-Spam-Level: 

Folks;


I recently purchased a Dell Inspiron 5100 laptop with an internal Conexant 
D480 modem.
I'm using the Linuxant driver for this modem, of course. (Thank you muchly 
for that!)

I notice however that under Windows XP the modem has fax capability but 
under Linux it
doesn't. Can you give me some idea of when (or if) you'll be adding fax 
support to the
D480 driver?

Keep up the good work, folks; you're doing a Good Thing by making software 
modems
behave themselves under Linux. 8^D


Regards;
  Jonathan Lyster


-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/


----- End forwarded message -----