Red Hat Bugzilla – Bug 75761
Serial driver misidentifies software modem pci card as 16x50 compatible serial pci card.
Last modified: 2007-04-18 12:47:29 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.79 [en] (X11; U; Linux 2.4.18-3 i686; Nav)
Description of problem:
Broadcom makes a pci software modem solution which runs under Linux. Our pci
card has sub-class == 0x3, prog. i/f == 0(generic modem), declares an i/o port
range and a memory range. This device's i/o port registers are in no way
compatible with a 16x50 uart but the serial driver incorrectly think so. The
serial driver then tries to configure our device as if it was a 16x50 uart
therefore accessing invalid registers in our modem. The pci spec lists
programing i/f values 1-4 to denote devices compatible w/ 16X50 uarts so the
serial driver should check that the pci devices' programing i/f corresponds to
one of these values before using the device. If the previous sugestion is not
acceptable, the serial driver should at least have code to prevent it from using
our modem. Checking for vendor id == 0x14e4(Broadcom) and subclass == 0x03 is
enough to identify our modem cards.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1 insert Broadcom pci modem
2 boot the system
Actual Results: you get thie following message(RH 7.2, very similar messages in
Pci: found irq7 for device 00:0e.0 Redundant entry in serial
pci_table. Please send output of lspci-vv, this message (5348,16914,4136,1)
and the manufacturer and name of serial board or modem board to
Expected Results: shouldnt see message described in "Actual Results".
This problem is present in RH versions 7.2,7.3,8.0 and Advanced Server 2.1.
can you send me the driver for this card under a GPL license ?
The modem driver has proprietary code and is not released under a GPL license.
We release the driver in binary form to PC OEM's. I dont think you'd need the
driver to reproduce this problem because the problem happens early in the boot
process way before the modem module is loaded. The problem is that the function
serial_pci_guess_board() in drivers/char/serial.c incorrectly assumes that
devices w/ programing i/f == 0 are 16x50 compatible so it returns true when it
looks at our board. The serial driver then tries to access invalid registers in
which cause pci bus errors.
You release code that links into a GPL program without making it GPL?
You have guts legal wise...
Anyway this makes this bug a "you use binary only kernel modules" bug
Also, PCI2.2 in Appendix D states that Interface class code "0" is
"XT-compatible serial controller", which means 8250 code can drive
I've actually seen such controllers.
Your suggested change would break such systems.
"0" was a bad selection for interface code.
You have misunderstood the problem. The system crashes when *standard* linux
kernel boots with this PCI card inserted. It is irrelevant of the driver code.
Lets not assert any legal statements for the time being and concentrate on
solving the problem for our common customers.
You have looked at the wrong entry in the PCI 2.2 Appendix D table:
"XT-compatible serial controller" is class=7, sub-class=0, i/f=0
while the PCI card in question has class=7, sub-class=3, i/f=0. This defines
"Generic Modem" with no definition of the interface type.
Please let us know what your next steps are going to be.
my next steps are to ignore this bug from now on.
"common customers" would imply that Red Hat could sell support to customers who
use your hardware, and Red Hat Linux can't and won't support your hardware.
I note that the 07/02/00 entry also lists "multi-port serial controller"