From owner-freebsd-acpi@FreeBSD.ORG Sun Jul 9 18:05:28 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0372F16A4DE; Sun, 9 Jul 2006 18:05:28 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id A17C043D45; Sun, 9 Jul 2006 18:05:27 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.150] (pptp0.pn.xcllnt.net [192.168.4.150]) by ns1.xcllnt.net (8.13.6/8.13.6) with ESMTP id k69I5JmH013080; Sun, 9 Jul 2006 11:05:20 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <20060709.014658.-460542464.imp@bsdimp.com> References: <44AD6F67.9060804@root.org> <200607071240.57062.jhb@freebsd.org> <20060709.014658.-460542464.imp@bsdimp.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Sun, 9 Jul 2006 11:05:15 -0700 To: "M. Warner Losh" X-Mailer: Apple Mail (2.752.2) Cc: freebsd-acpi@freebsd.org, atkin901@yahoo.com Subject: Re: acpi on msi-9218 (-current) swaps sio0 and sio1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2006 18:05:28 -0000 On Jul 9, 2006, at 12:46 AM, M. Warner Losh wrote: > Finally, there's the redundant specification problem. People want > sio0 to attach to this thing in the back of the computer that's > labeled COMA, and whose resources are this or that. They know from > their computer's documentation that this is COM1, and windows assigns > it to COM1. This desire is due in part to it being the way we've > always selected sio0. It traditionally has been the serial port at > address 0x3f8. There's also the problem that the low level kernel > console driver wants to talk to the port by address, while the newbus > system wants to talk to it by how it probed. So you get odd > cross-threading when these two don't agree. If the cross threading > didn't exist, and the right thing happened, users wouldn't care how > that happened. uart(4) has this problem solved already. It seems to me from following the various mailing lists that it's probably time to think about phasing out sio(4), because problems tend to come up with sio(4) from time to time that have already been solved with uart(4). > ... The third problem could > also be solved with hints and some minor adjustments to newbus. I disagree. It's misusing hints that's causing the cross-threading. If hints were to be used for enumeration only and you have a different means to select the low-level serial console then cross-threading is avoided. This is exactly what uart(4) does. As such, you can even pick a port on a multi-I/O PCI card for the low-level serial console without causing interference with any of the other problems you mentioned. The reason is simply that you select the low-level serial console by the one attribute that matters: the I/O address (either I/O port or memory mapped I/O). -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net