Date: Fri, 20 Apr 2007 11:22:05 -0700 From: Marcel Moolenaar <xcllnt@mac.com> To: Jeremy Chadwick <koitsu@FreeBSD.org> Cc: freebsd-stable@FreeBSD.org, Stefan Lambrev <stefan.lambrev@sun-fish.com> Subject: Re: sio0: port may not be enabled Message-ID: <DA5C4BCC-8B13-47B6-BAF3-8199583A7A6A@mac.com> In-Reply-To: <20070420180805.GA18977@icarus.home.lan> References: <4628D63A.3050909@sun-fish.com> <20070420152329.GA16702@icarus.home.lan> <049954BE-364B-4897-87C3-342D0A824C00@mac.com> <20070420180805.GA18977@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 20, 2007, at 11:08 AM, Jeremy Chadwick wrote: > On Fri, Apr 20, 2007 at 09:45:43AM -0700, Marcel Moolenaar wrote: >> >> On Apr 20, 2007, at 8:23 AM, Jeremy Chadwick wrote: >> >>> Look closely at the dmesg line, note what device sio0 is claiming >>> to be >>> associated with (acpi0, not isa0): >>> >>>> sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags >>>> 0x10 on acpi0 >>> >>> This is one of the drawbacks to using ACPI. >> >> This is not a drawback. It's partly why ACPI was designed and >> implemented: >> to describe legacy hardware. > > It's a drawback in the sense that if the technology is newer than what > FreeBSD can handle/is made for, then administrators are forced to look > at alternatives (other hardware or operating systems). I see what you mean. This may also be FreeBSD's drawback (i.e. the support for legacy systems). >>> Some systems apparently tie the serial port to ACPI functionality >>> in a >>> different way. For example, I have a couple boxes which have sio0 >>> attached to acpi0 that work fine. In some other cases, I have ones >>> which result in a non-working serial port unless I disable ACPI >>> (thus >>> sio0 shows up as being attached to isa0). >> >> Could you try uart(4) instead. It seems quite excessive to have to >> disable ACPI just to get a serial port working. I'd like to know >> if this is related to the sio(4) driver or something else. > > Can you provide some directions explaining how to configure the > kernel (other than "device uart") and loader.conf or device.hints > for appropriate variables? I'll be more than happy to try this out. Remove device sio from your kernel configuration. Also, make sure that if acpi is loaded as a module, everything that can attach to acpi is loaded as a module too (i.e. uart). I typically compile-in acpi. It's too fundamental for my tastes to not compile it into the kernel. Don't change your device.hints file. Hints are more likely to interfere than help out. With sio removed from the kernel, its hints won't harm. Don't add hints for uart. We're using acpi, so the hardware/firmware will tell us where serial ports are. There's no need for changes in loader.conf, unless you're using a serial console. In that case you need to tell uart where the console is. The following will put the console on COM1: set hw.uart.console=io:0x3f8 If you have a serial console, then you also want to make sure that you have a login prompt. Change /etc/ttys by replacing ttyd# into ttyu#. To have uart coexist with sio, uart has to create different device special files and you need to make sure that a getty is started for them in order to log in over the serial port. HTH, -- Marcel Moolenaar xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DA5C4BCC-8B13-47B6-BAF3-8199583A7A6A>