Bug 115802 - Unable to set high speed rates on UARTs
Unable to set high speed rates on UARTs
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-02-16 04:40 EST by Paul Black
Modified: 2015-01-04 17:04 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-12-08 12:18:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Paul Black 2004-02-16 04:40:00 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.
Comment 1 David Woodhouse 2004-02-16 06:27:29 EST
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. 
Comment 2 Dave Jones 2004-12-08 00:33:29 EST
is this still a problem with the 2.6.9 updates ?
Comment 3 Paul Black 2004-12-08 04:05:20 EST
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.
Comment 4 David Woodhouse 2004-12-08 06:47:19 EST
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.
Comment 5 Dave Jones 2004-12-08 12:18:51 EST
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.
Comment 6 David Woodhouse 2004-12-08 12:35:03 EST
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.)

Note You need to log in before you can comment on or make changes to this bug.