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): How reproducible: Always 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 RH 7.3,8.0,AS 2.1): 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 serial-pci-info@lists.source Expected Results: shouldnt see message described in "Actual Results". Additional info: 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 our device 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 it properly. I've actually seen such controllers. Your suggested change would break such systems. "0" was a bad selection for interface code.
To arjanv@redhat.com: 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. To davem@redhat.com: 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"