Project

General

Profile

Bug #2560

ACPI parser fails to identify COM3 on Tyan motherboard

Added by Gary Mills almost 8 years ago. Updated over 7 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Start date:
2012-03-29
Due date:
% Done:

90%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

I have a Tyan S5510GM3NR motherboard that includes a BMC
device with serial-over-lan support. Illumos fails to identify
the COM3 serial port on this board, producing an incomplete
device tree entry like this:

            asy (driver not attached)
                Hardware properties:
                    name='compatible' type=string items=1
                        value='pnpPNP,501'
                    name='acpi-namespace' type=string items=1
                        value='\_SB_.PCI0.SBRG.UAR3'
                    name='model' type=string items=1
                        value='16550A-compatible COM port'

This does work with a Supermicro motherboard, resulting in
this device entry:

            asy, instance #2
                System software properties:
                    name='interrupt-priorities' type=int items=1
                        value=0000000c
                Driver properties:
                    name='ddi-no-autodetach' type=int items=1 dev=none
                        value=00000001
                Hardware properties:
                    name='compatible' type=string items=1
                        value='pnpPNP,501'
                    name='interrupts' type=int items=1
                        value=0000000a
                    name='reg' type=int items=3
                        value=00000001.000003e8.00000008
                    name='acpi-namespace' type=string items=1
                        value='\_SB_.PCI0.SBRG.UAR3'
                    name='model' type=string items=1
                        value='16550A-compatible COM port'
                Register Specifications:
                    Bus Type=0x1, Address=0x3e8, Size=0x8
                Interrupt Specifications:
                    Interrupt Priority=0xc (ipl 12), vector=0xa (10)
               Device Minor Nodes:
                    dev=(106,2)
                        dev_path=/pci@0,0/isa@1f/asy@1,3e8:c
                            spectype=chr type=minor
                            dev_link=/dev/ttyc
                            dev_link=/dev/tty02
                            dev_link=/dev/term/c
                        Minor properties:
                            name='uart' type=string items=1 dev=(106,2)
                                value='16550A'
                    dev=(106,131074)
                        dev_path=/pci@0,0/isa@1f/asy@1,3e8:c,cu
                            spectype=chr type=minor
                            dev_link=/dev/ttyd2
                            dev_link=/dev/cua2
                            dev_link=/dev/cua/c

The cause seems to be different ACPI DSDT tables. This is a
condensed version of the relevant portion for the Tyan board:

    Device (UAR1){
        Name (_PRS, ResourceTemplate ()    {
            StartDependentFn (0x00, 0x00)        {
                /* Info on COM1 */
            }
            StartDependentFnNoPri ()        {
                /* Info on COM1 */
            }
            StartDependentFnNoPri ()        {
                /* Info on COM2 */
            }
            StartDependentFnNoPri ()        {
                /* Info on COM3 */
            }
            StartDependentFnNoPri ()        {
                /* Info on COM4 */
            }
            EndDependentFn ()
        })
    }
    Device (UAR2){
       Name (CRSS, ResourceTemplate ()    {
               /* Info on COM2 */
        })
        Name (_PRS, ResourceTemplate ()    {
            StartDependentFn (0x00, 0x00)        {
                /* Info on COM2 */
        })
    }
    Device (UAR3){
        Name (_PRS, ResourceTemplate ()    {
            StartDependentFn (0x00, 0x00)        {
                /* Info on COM3 */
            }
            EndDependentFn ()
        })
    }

This is the same thing for the Supermicro board:

    Device (UAR1)                {
        Name (_PRS, ResourceTemplate ()    {
            StartDependentFn (0x00, 0x00)        {
                /* Info on COM1 */
            }
            StartDependentFnNoPri ()        {
                /* Info on COM1 */
            }
            StartDependentFnNoPri ()        {
                /* Info on COM2 */
            }
            StartDependentFnNoPri ()        {
                /* Info on COM3 */
            }
            StartDependentFnNoPri ()        {
                /* Info on COM4 */
            }
            EndDependentFn ()
        })
    }
    Device (UAR2){
        Name (_PRS, ResourceTemplate ()    {
            StartDependentFn (0x00, 0x00)        {
                /* Info on COM2 */
            }
            StartDependentFnNoPri ()        {
                /* Info on COM1 */
            }
            StartDependentFnNoPri ()        {
                /* Info on COM2 */
            }
            StartDependentFnNoPri ()        {
                /* Info on COM3 */
            }
            StartDependentFnNoPri ()        {
                /* Info on COM4 */
            }
            EndDependentFn ()
        })
    }
    Device (UAR3){
        Name (_PRS, ResourceTemplate ()    {
            StartDependentFn (0x00, 0x00)        {
                /* Info on COM3 */
            }
            StartDependentFnNoPri ()        {
                /* Info on COM1 */
            }
            StartDependentFnNoPri ()        {
                /* Info on COM2 */
            }
            StartDependentFnNoPri ()        {
                /* Info on COM3 */
            }
            StartDependentFnNoPri ()        {
                /* Info on COM4 */
            }
            EndDependentFn ()
        })
    }

I'll attach more complete sections of the DSDT tables.


Files

tyan-dsdt.txt (5.58 KB) tyan-dsdt.txt Gary Mills, 2012-03-29 02:30 PM
super-dsdt.txt (10.1 KB) super-dsdt.txt Gary Mills, 2012-03-29 02:30 PM
acpica-12.7.tar.gz (451 KB) acpica-12.7.tar.gz Gary Mills, 2012-07-12 09:52 PM

History

#1

Updated by Gary Mills over 7 years ago

Here's some information from a couple of other Unix live CDs. Freebsd 9.0 only detects two serial ports on the Tyan system. This is from `devinfo':

    uart0 pnpinfo _HID=PNP0501 _UID=1 at handle=\_SB_.PCI0.SBRG.UAR1
        Interrupt request lines:
            4
        I/O ports:
            0x3f8-0x3ff
    uart1 pnpinfo _HID=PNP0501 _UID=2 at handle=\_SB_.PCI0.SBRG.UAR2
        Interrupt request lines:
            3
        I/O ports:
            0x2f8-0x2ff

Ubuntu 12.04, on the other hand, detects three, including the BMC serial port. This is from `dmesg':
[    3.451274] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    3.538382] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[    3.638111] serial8250: ttyS2 at I/O 0x3e8 (irq = 4) is a 16550A
[    3.690245] 00:03: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    3.758356] 00:04: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A

#2

Updated by Gary Mills over 7 years ago

  • Assignee set to Gary Mills
  • % Done changed from 0 to 80

After several months of ACPI debugging with Illumos, I have determined the root cause of this problem: The ACPI DSDT table in the BIOS is faulty. It is missing a _CRS method (current resources) for the UAR3 device (COM3) but does contain a valid _PRS method (possible resources). The DSDT table does contain _CRS methods for UAR1 and UAR2, but not for UAR3. The Illumos kernel only examines current resources at boot time.
I now have a workaround for the Illumos kernel that permits it to work. This consists of a modified acpica driver that uses an ACPI function to examine possible resources when there are no current resources for a device in the ACPI tables. With this workaround, I now have a working serial-over-lan console on my Tyan system for the first time.
I have notified Tyan support of the error in their ACPI tables.

#3

Updated by Gary Mills over 7 years ago

I've attached 32 and 64-bit x86 versions of the acpica driver. These should be installed into /kernel/misc and /kernel/misc/amd64/ respectively. Rename the existing acpica files before you do this. You will also need to update the boot archive before rebooting. Nothing should change unless you are using a Tyan motherboard with a faulty UAR3 definition in the ACPI tables.

#4

Updated by Yuri Pankov over 7 years ago

"Fixing" the upstream source doesn't seem the best way to proceed here, you can report the issue upstream and use updated ACPI tables in the meantime (that's what /boot/acpi/tables/ is for, there are a bit of magic involved to correctly name the files).

#5

Updated by Gary Mills over 7 years ago

  • % Done changed from 80 to 90

This change does not modify upstream source, assuming that you mean the Intel ACPICA code. The acpi_enum.c file is the illumos front-end to Intel's code.

#6

Updated by Gordon Ross over 7 years ago

  • Status changed from New to Resolved
changeset:   13766:adffc698eaf5
tag:         tip
user:        Gary Mills <gary_mills@fastmail.fm>
date:        Tue Jul 24 18:52:10 2012 -0500
description:
    2560 ACPI parser fails to identify COM3 on Tyan motherboard
    Reviewed by: Gordon Ross <gwr@nexenta.com>
    Reviewed by: Garrett D'Amore <garrett@damore.org>
    Approved by: Dan McDonald <danmcd@nexenta.com>

Also available in: Atom PDF