Re: HEADS UP! 6.0-RELEASE coming

From: Scott Long (scottl_at_samsco.org)
Date: 10/31/05

  • Next message: Warner Losh: "Re: HEADS UP! 6.0-RELEASE coming"
    Date: Mon, 31 Oct 2005 10:42:32 -0700
    To: Warner Losh <imp@bsdimp.com>
    
    

    Warner Losh wrote:
    >>>The ACPI+sio problem is known. I have a motherboard with a similar
    >>>problem, though a different brand than yours. I solved it by removing
    >>>the ACPI attachment from the sio code. The better solution is to allow
    >>>loader hints to override ACPI hints. I tried talking to John Baldwin
    >>>about this but didn't get much of a response.
    >>
    >>I've tried all suggestions so far, but to no avail on most servers. Too
    >>many broken ACPI implementations I fear... Too bad motherboard vendors
    >>don't take the time to push proper software in their flash.
    >
    >
    > Right now acpi tells us there's a device, and we use it. Loader hints
    > should be used to map locations to device instances. It is more
    > general than just ACPI, however. People want to bind sio to a
    > specific port that comes out the back. People also want to bind rl0
    > to the card in slot 3.
    >
    > Consider my system:
    > sio0 pnpinfo _HID=PNP0501 _UID=1 at handle=\_SB_.PCI0.SBRG.UAR1
    > sio1 pnpinfo _HID=PNP0501 _UID=2 at handle=\_SB_.PCI0.SBRG.UAR2
    >
    > On this system, UAR1 is the port that comes out the back, so I have
    > what I want. However, I'd like to be able to say:
    >
    > hint.sio.0.at="acpi"
    > hint.sio.0.location="\_SB_.PCI0.SBRG.UAR2"
    >
    > or
    >
    > hint.sio.0.at="acpi"
    > hint.sio.0.location="UAR2"
    >
    > or
    >
    > hint.fxp.0.at="pci"
    > hint.fxp.0.location="bus=2 slot=3 function=0"
    > hint.fxp.1.at="pci"
    > hint.fxp.1.location="pci2:2:0"
    >
    > Since we really want to map the devices in some arbitrary ACPI tree to
    > instances in the system, rather than mapping devices that happen to
    > live at a specific resource address to specific instances in the tree.
    >
    > However, there are a number of issues in doing this generically and
    > with error cases. How does one deal with the different syntaxes?
    > What extensions to the newbus system are there? etc.
    >
    > Warner

    Well, in my case at least, what ACPI says about the sio resources is
    simply wrong, and I'm not smart enough to figure out how to correct the
    ASL or get it loaded correctly on boot. It would be easier if the
    sio-acpi attachment honored the hints that already exist for the purpose
    of describing the sio resources. Last I checked, neither Windows nor
    Linux nor Solaris required users to read the ACPI 2.0 spec to get their
    comms ports working. Having the flexibility to do what you describe
    above would be nice, but allowing mortal users to get their hardware
    working would be ever nicer.

    Scott
    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  • Next message: Warner Losh: "Re: HEADS UP! 6.0-RELEASE coming"

    Relevant Pages

    • Re: HEADS UP! 6.0-RELEASE coming
      ... On Mon, 31 Oct 2005, Warner Losh wrote: ... >> Well, in my case at least, what ACPI says about the sio resources is ... >> Linux nor Solaris required users to read the ACPI 2.0 spec to get their ... I could have sworn that the AML that you'd posted a while ago ...
      (freebsd-stable)
    • Re: FDC/ACPI/GEOM problems
      ... On Tue, 2004-09-28 at 16:04, M. Warner Losh wrote: ... I have spent a little time today looking at this problem in more detail. ... Apparently systems only hang with ACPI ...
      (freebsd-current)
    • Re: HEADS UP: PCI Chnages
      ... : On Fri, 23 Apr 2004, M. Warner Losh wrote: ... :>: We probably just need to reprogram the PCI link devices on resume. ... Or are your comments just for the!acpi case? ... I was consuing PCI link devices and PCI devices. ...
      (freebsd-current)
    • Re: Better device probe values
      ... On Wednesday 23 February 2005 03:50 pm, Warner Losh wrote: ... >> Several typos, but that's minor. ... MPTable is just preferred to PCIBIOS, and ACPI is preferred to ...
      (freebsd-arch)
    • Re: Better device probe values
      ... On Wednesday 23 February 2005 03:50 pm, Warner Losh wrote: ... >> Several typos, but that's minor. ... MPTable is just preferred to PCIBIOS, and ACPI is preferred to ...
      (freebsd-arch)