Red Hat Bugzilla – Bug 115802
Unable to set high speed rates on UARTs
Last modified: 2015-01-04 17:04:33 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8 Description of problem: Can not set baud rates of 230400 and 460800 with stty. The UART is an Oxsemi 952 which is capable of these speeds (it worked under Fedora Core 1). root@zeebee# stty -F/dev/ttyS4 460800 stty: /dev/ttyS4: unable to perform all requested operations Someone here has looked at the kernel code and reckons it doesn't touch the prescaler or TCR registers (whereas the 2.4.x kernel apparently did in char/serial.c). lspci -vv 0000:02:00.0 Serial controller: Oxford Semiconductor Ltd OX16PCI952 (Dual 16950 UART) (prog-if 06 [16950]) Subsystem: Oxford Semiconductor Ltd: Unknown device 0001 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 11 Region 0: I/O ports at dcf8 Region 1: I/O ports at dce8 [size=8] Region 2: I/O ports at dcc0 [size=32] Region 3: Memory at ff6ff000 (32-bit, non-prefetchable) [size=4K] Region 4: Memory at ff6fe000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 1 Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA PME(D0+,D1-,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Version-Release number of selected component (if applicable): kernel-2.6.1-1.65 How reproducible: Always Steps to Reproduce: 1. stty -F/dev/ttyS4 460800 2. 3. Actual Results: stty: /dev/ttyS4: unable to perform all requested operations Expected Results: No output and the UART speed changed. Additional info: This is using an Oxford Semiconductor PCI 952 dual high speed UART.
The way the 2.4 kernel use TCR was broken. It assumed that the TCR was set to zero in the beginning -- which isn't always the case; sometimes it's initialised to a different value, to make it _appear_ that baud_base is 115200. You can use TCR in that way _only_ if you're going to read the TCR before resetting the hardware at probe time, and adjust baud_base to compensate if it _wasn't_ zero.
is this still a problem with the 2.6.9 updates ?
The error doesn't occur when running the stty command. I've done a loop back test on 952 board and it works. I don't have any external kit to verify that the speeds are actually 460800 but it is definitely not 115200. I reported this on behalf of a colleague. He's still using FC2 test1 with a kernel hacked to do what he wants so he's not interested in upgrading and testing! I would consider this fixed.
Most PC motherboards are capable of at least 460800 baud. You ought to be able to test with one of those. Use the 'Shsmod' program (google) to switch into high-speed mode, then either set the 'magic multiplier' bit with setserial, or change the baud_base according to which type of superio chip it is. We really ought to make the kernel do that for itself.
from my experiences with shsmod, its hit or miss whether it works. When I tested it on a VIA chipset for example the system clock started jumped back and forth 6 hours. Quite amusing, but not too useful. Probably better fixed upstream and inherited that way for Fedora.
Agreed. I got the 'magic multiplier' merged upstream but doing the bit that shsmod does really means we want a proper superio detection and support library/core instead of dropping bits of it into all the random drivers that want it (parport, irda, now serial, etc.)