From owner-freebsd-stable@FreeBSD.ORG Sun Aug 21 21:01:54 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42FC3106564A for ; Sun, 21 Aug 2011 21:01:54 +0000 (UTC) (envelope-from david@wood2.org.uk) Received: from outbound-queue-1.mail.thdo.gradwell.net (outbound-queue-1.mail.thdo.gradwell.net [212.11.70.34]) by mx1.freebsd.org (Postfix) with ESMTP id E7F518FC0A for ; Sun, 21 Aug 2011 21:01:53 +0000 (UTC) Received: from outbound-edge-1.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-1.mail.thdo.gradwell.net (Postfix) with ESMTP id 5B7E321F33; Sun, 21 Aug 2011 21:45:57 +0100 (BST) Received: from argon.wood2.org.uk (HELO argon.wood2.org.uk) (82.71.104.124) (smtp-auth username wood, mechanism cram-md5) by outbound-edge-1.mail.thdo.gradwell.net (qpsmtpd/0.83) with ESMTPA; Sun, 21 Aug 2011 21:45:57 +0100 Message-ID: Date: Sun, 21 Aug 2011 21:44:41 +0100 To: Greg Byshenk From: David Wood References: <20110821154249.GE92605@core.byshenk.net> In-Reply-To: <20110821154249.GE92605@core.byshenk.net> MIME-Version: 1.0 Content-Type: text/plain;charset=us-ascii;format=flowed User-Agent: Turnpike/6.06-M (<+nhRuLNS5oZIqwOH7WWZxwfp$O>) X-Gradwell-MongoId: 4e516e85.7791-6eb1-1 X-Gradwell-Auth-Method: smtpauth X-Gradwell-Auth-Credentials: wood Cc: freebsd-stable@freebsd.org Subject: Re: Serial multiport error Oxford/Startech PEX2S952 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 21:01:54 -0000 Hi Greg, I wrote and contributed the support code for the OXPCIe95x serial chips - and just happened to notice your report. In message <20110821154249.GE92605@core.byshenk.net>, Greg Byshenk writes >I'm having a problem with a StarTech PEX2S952 dual-port serial >card. > >I believe that it should be supported, as it has this entry in >pucdata.c > >[...] > { 0x1415, 0xc158, 0xffff, 0, > "Oxford Semiconductor OXPCIe952 UARTs", > DEFAULT_RCLK * 0x22, > PUC_PORT_NONSTANDARD, 0x10, 0, -1, > .config_function = puc_config_oxford_pcie > }, >[...] It should be supported. The OXPCIe952 is more awkward to support than the OXPCIe954 and OXPCIe958 because it can be configured in so many different ways by the board manufacturer. However, 0xc158 is configuration that is identical in arrangement as the larger chips, so is the configuration I'm most confident of. I've just double-checked the data sheets, and can't see any relevant differences between 0xc158 OXPCIe952 and the OXPCIe954 I tested the code with. I use my OXPCIe954 board on FreeBSD 8.2, and have had success reports from other OXPCIe954 and OXPCIe958 board users (including someone with a 16 port board based on dual OXPCIe958s). I have yet to try FreeBSD 9.x on my hardware. >And, while it is recognized at boot -- after adding > > device puc > options COM_MULTIPORT I'm 99% certain that "options COM_MULTIPORT" relates to the old sio(4) code - I certainly don't need it on 8.x. Does it make any difference if you delete that line and just leave "device puc"? >to my kernel, it doesn't seem to be working. The devices '/dev/cuau2' >and '/dev/cuau3' show up, and I can connect to them, but they don't >seem to pass any traffic. If I connect to the serial console of >another machine (one that I know for certain is working), I get >nothing at all. Have you remembered to set the speed (and other relevant options) on the .init devices? This is a feature (or is it a quirk) of the uart(4) driver that catches many people out. Setting options on the base device is normally a no-op. For example, if the remote device on /dev/cuau2 operates at 115200 bps with hardware handshaking, try: stty -f /dev/cuau2.init speed 115200 crtscts One frustrating aspect of adding puc(4) support for many devices is that you can't be certain of the clock rate multiplier - the same device can crop up on a different manufacturer's board with a different multiplier. This problem doesn't occur with the OXPCIe95x devices as they derive their 62.5MHz UART clock from the PCI Express clock. Consequently, the problem can't be that your board inadvertently operating the UARTs at the wrong speed. >I suspect (?) that it may not be recognized as the proper card. Boot >and pciconf messages are: > >puc0: mem >0xf9dfc000-0xf9dfffff,0xfa000000-0xfa1fffff,0xf9e00000-0xf9ffffff irq >30 at device 0.0 on pci4 That is correct. Are there any more lines afterwards - especially one giving the number of UARTs detected? That line is crucial, as, on these chips, the number of UARTs has to be read from configuration space because you can slave two chips together. My OXPCIe954 board is recognised thus (FreeBSD 8.2 amd64): puc0: mem 0xd5efc000-0xd5efffff,0xd5c00000-0xd5dfffff,0xd5a00000-0xd5bfffff irq 18 at device 0.0 on pci8 puc0: 4 UARTs detected puc0: [FILTER] uart2: <16950 or compatible> on puc0 uart2: [FILTER] uart3: <16950 or compatible> on puc0 uart3: [FILTER] uart4: <16950 or compatible> on puc0 uart4: [FILTER] uart5: <16950 or compatible> on puc0 uart5: [FILTER] >puc0@pci0:4:0:0: class=0x070002 card=0xc1581415 chip=0xc1581415 >rev=0x00 hdr=0x00 > vendor = 'Oxford Semiconductor Ltd' > class = simple comms > subclass = UART > bar [10] = type Memory, range 32, base 0xf9dfc000, size 16384, enabled > bar [14] = type Memory, range 32, base 0xfa000000, size 2097152, enabled > bar [18] = type Memory, range 32, base 0xf9e00000, size 2097152, enabled That is correct. >The kernel is actually FreeBSD 9.0-BETA1 amd64, which is not quite >'STABLE' yet, but I don't think that this should matter. > >Any advice would be much appreciated. The machine is still in >test phase, so I can mess around with it as necessary. Hopefully this gets your Startech board working. I look forward to your feedback. If all else fails, the board I'm using is Lindy 51189. It's a OXPCIe954 board, offering four ports via a breakout cable, and is normally pretty cheap direct from lindy.com (quite possibly cheaper than your two port Startech board!). However, this recommendation comes with the proviso that I haven't yet tried it with FreeBSD 9.x. With best wishes, David -- David Wood david@wood2.org.uk