Support for cards with vendor 9901 device 9710 is in the uart and ppc drivers. Unfortunately several boards use the same PCI ID, and they don't all work. The code as it exists right now, will support boards which use the built in serial and parallel ports on the 9710 chip. One or two serial, with zero or one LPT will probably work. The board I have is four serial one LPT, which is implemented as two serial on the built in UARTS, and then an ISA bus interface with another two UARTS and a LPT interface on that ISA bus. Possibly implemented with a 16S552 chip. (It has no documentation, of course...) The same chip will also do a USB port (instead of an LPT, or ISA). So the first two serial ports are fine, but the second two serial ports and the LPT fail to probe. How-To-Repeat: Get a 9710 board with four serial and one LPT, and note that only the first two serial ports work.
Hi Tommy, This is probably because the subvendor for your particular card hasn't been added yet. Could you run devinfo -v and provide us with the output, as well as a URL to the specific card that you acquired? Thanks! -Garrett
For future reference. ---------- Forwarded message ---------- From: <tjohnson@bobdbob.com> Date: Mon, May 17, 2010 at 9:36 PM Subject: Re: kern/146647: Some PCIe seral/parallel boards with ID 9901 9710 don't work To: yanefbsd@gmail.com I was poking at the ppc driver over the weekend... In the attached files, it did attach as ppc1-ppc3. It doesn't actually work that way though: I commented out the check which was failing (ppc_detect_port(), the data register doesn't read back correctly). I've also attached the data sheets I managed to find with google. The schematic is from: ftp://220.232.158.86/Moschip/moschip_mcs9901/System Data/MCS9901-4S1P/Schematic Which I suspect is their reference design. The board is a SYBA 4 x Serial / 1 x Parallel Ports PCI-Express Card Model SD-PEX50023 http://www.newegg.com/Product/Product.aspx?Item=N82E16815124073 Thanks for taking a look at this! -Tommy tjohnson@bobdbob.com
Ok... the information you sent me just a while ago was interesting. It appears to be a card with similar attributes to the card I sent out in the past couple of months and Xinli (delphij@) was nice enough to add and MFC. Here's my card (for reference): uart2@pci0:1:0:0: class=3D0x070002 card=3D0x1000a000 chip=3D0x9901971= 0 rev=3D0x00 hdr=3D0x00 vendor =3D 'MosChip Semiconductors (Was: Netmos Technology)' class =3D simple comms subclass =3D UART uart3@pci0:1:0:1: class=3D0x070002 card=3D0x1000a000 chip=3D0x9901971= 0 rev=3D0x00 hdr=3D0x00 vendor =3D 'MosChip Semiconductors (Was: Netmos Technology)' class =3D simple comms subclass =3D UART ppc1@pci0:1:0:2: class=3D0x070103 card=3D0x2000a000 chip=3D0x9901971= 0 rev=3D0x00 hdr=3D0x00 vendor =3D 'MosChip Semiconductors (Was: Netmos Technology)' class =3D simple comms subclass =3D parallel port What's interesting about your card's details is that it isn't detecting the serial uarts based off the 4-port splitter as uarts, and is instead detecting them as parallel ports. Very interesting indeed... I'm not sure what modifications you've made to your local copy of ppc(4), but definitely back out everything (sans the IDs for ppc3), and add the PCI IDs to /sys/dev/uart/uart_bus_pci.c -- and it *should* detect the appropriate uarts. If not, there's some kind of configuration required that hasn't been setup on either the board or something in software that needs to be done that's specific to the card, or something that needs to be added to device.hints so that it properly configures the card irqs, etc. FWIW my card doesn't function with lpt(4) (it's passing interrupts to and from the driver, but I haven't hooked by the pinouts to see whether or not signals are being passed through). I'm working on root-causing what the issue is because it's related to work and impacts productivity with an internal tools release. Thanks for the documentation though -- I'll see what I can do about remedying the ppc(4) <-> lpt(4) issue over the next couple of weeks. Cheers, -Garrett
On Mon, May 17, 2010 at 10:37 PM, Garrett Cooper <yanefbsd@gmail.com> wrote= : > On Sun, May 16, 2010 at 6:56 PM, Garrett Cooper <yanefbsd@gmail.com> wrot= e: >> On Sun, May 16, 2010 at 6:47 PM, Garrett Cooper <yanefbsd@gmail.com> wro= te: >>> On Sun, May 16, 2010 at 5:50 PM, Tommy Johnson <tjohnson@bobdbob.com> w= rote: >>>> >>>>>Number: =A0 =A0 =A0 =A0 146647 >>>>>Category: =A0 =A0 =A0 kern >>>>>Synopsis: =A0 =A0 =A0 Some PCIe seral/parallel boards with ID 9901 971= 0 don't work >>>>>Confidential: =A0 no >>>>>Severity: =A0 =A0 =A0 non-critical >>>>>Priority: =A0 =A0 =A0 low >>>>>Responsible: =A0 =A0freebsd-bugs >>>>>State: =A0 =A0 =A0 =A0 =A0open >>>>>Quarter: >>>>>Keywords: >>>>>Date-Required: >>>>>Class: =A0 =A0 =A0 =A0 =A0sw-bug >>>>>Submitter-Id: =A0 current-users >>>>>Arrival-Date: =A0 Mon May 17 01:00:10 UTC 2010 >>>>>Closed-Date: >>>>>Last-Modified: >>>>>Originator: =A0 =A0 Tommy Johnson >>>>>Release: =A0 =A0 =A0 =A08.0 >>>>>Organization: >>>>>Environment: >>>> FreeBSD teryx 8.0-STABLE FreeBSD 8.0-STABLE #8: Sat May 15 15:49:45 ED= T 2010 =A0 =A0 tjohnson@teryx:/usr/src/sys/amd64/compile/TERYX =A0amd64 >>>>>Description: >>>> Support for cards with vendor 9901 device 9710 is in the uart and ppc = drivers. =A0Unfortunately several boards use the same PCI ID, and they don'= t all work. >>>> >>>> The code as it exists right now, will support boards which use the bui= lt in serial and parallel ports on the 9710 chip. =A0One or two serial, wit= h zero or one LPT will probably work. >>>> >>>> The board I have is four serial one LPT, which is implemented as two s= erial on the built in UARTS, and then an ISA bus interface with another two= UARTS and a LPT interface on that ISA bus. =A0Possibly implemented with a = 16S552 chip. =A0(It has no documentation, of course...) >>>> >>>> The same chip will also do a USB port (instead of an LPT, or ISA). >>>> >>>> So the first two serial ports are fine, but the second two serial port= s and the LPT fail to probe. >>>>>How-To-Repeat: >>>> Get a 9710 board with four serial and one LPT, and note that only the = first two serial ports work. >>>>>Fix: >>> >>> Hi Tommy, >>> =A0 =A0This is probably because the subvendor for your particular card >>> hasn't been added yet. Could you run devinfo -v and provide us with >>> the output, as well as a URL to the specific card that you acquired? >>> Thanks! >> >> =A0 =A0pciconf -lv would be helpful as well so that the devinfo could be >> properly mapped back to the appropriate device. > > Ok... the information you sent me just a while ago was interesting. It > appears to be a card with similar attributes to the card I sent out in > the past couple of months and Xinli (delphij@) was nice enough to add > and MFC. Here's my card (for reference): > > uart2@pci0:1:0:0: =A0 =A0 =A0 class=3D0x070002 card=3D0x1000a000 chip=3D0= x99019710 > rev=3D0x00 hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'MosChip Semiconductors (Was: Netmos Technology= )' > =A0 =A0class =A0 =A0 =A0=3D simple comms > =A0 =A0subclass =A0 =3D UART > uart3@pci0:1:0:1: =A0 =A0 =A0 class=3D0x070002 card=3D0x1000a000 chip=3D0= x99019710 > rev=3D0x00 hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'MosChip Semiconductors (Was: Netmos Technology= )' > =A0 =A0class =A0 =A0 =A0=3D simple comms > =A0 =A0subclass =A0 =3D UART > ppc1@pci0:1:0:2: =A0 =A0 =A0 =A0class=3D0x070103 card=3D0x2000a000 chip= =3D0x99019710 > rev=3D0x00 hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'MosChip Semiconductors (Was: Netmos Technology= )' > =A0 =A0class =A0 =A0 =A0=3D simple comms > =A0 =A0subclass =A0 =3D parallel port > > What's interesting about your card's details is that it isn't > detecting the serial uarts based off the 4-port splitter as uarts, and > is instead detecting them as parallel ports. Very interesting > indeed... > > I'm not sure what modifications you've made to your local copy of > ppc(4), but definitely back out everything (sans the IDs for ppc3), > and add the PCI IDs to /sys/dev/uart/uart_bus_pci.c -- and it *should* > detect the appropriate uarts. If not, there's some kind of > configuration required that hasn't been setup on either the board or > something in software that needs to be done that's specific to the > card, or something that needs to be added to device.hints so that it > properly configures the card irqs, etc. > > FWIW my card doesn't function with lpt(4) (it's passing interrupts to > and from the driver, but I haven't hooked by the pinouts to see > whether or not signals are being passed through). I'm working on > root-causing what the issue is because it's related to work and > impacts productivity with an internal tools release. > > Thanks for the documentation though -- I'll see what I can do about > remedying the ppc(4) <-> lpt(4) issue over the next couple of weeks. lpt(4)'s fine (for the most part). It's a compatibility issue with the particular printer that we've standardized on here at work that's causing bad juju with the lpt(4) and this particular card (weird...). I'm going to see about acquiring one of these cards for testing though in the next week or so.. Thanks, -Garrett
Just to follow up, here's what's going on with this PR. I got the card some time back (thanks!) but I got swamped with other work and didn't start poking at the card until recently. I got 2 of the uarts to probe and attach, and got a third uart to attach, but I don't think that's correct as it has a total of 4 different user visible uarts. I booted up Windows 7 on the box and it was reporting two different pairs of uarts -- one pair was high speed PCI-e and one pair was not. I'll poke around further on it this weekend and see what I can come up with. I apologize for taking so long to reply... Thanks, -Garrett
State Changed From-To: open->suspended it seems like sth must be figured out first before anything can be committed for that PR. suspending this for now. please note, this PR is related to kern/149658 (now on hold)
For bugs matching the following conditions: - Status == In Progress - Assignee == "bugs@FreeBSD.org" - Last Modified Year <= 2017 Do - Set Status to "Open"