From owner-freebsd-current@FreeBSD.ORG Tue Sep 30 00:07:06 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1405816A4B3 for ; Tue, 30 Sep 2003 00:07:06 -0700 (PDT) Received: from gateway.nixsys.be (gateway.nixsys.be [195.144.77.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88B134403B for ; Tue, 30 Sep 2003 00:07:04 -0700 (PDT) (envelope-from philip@nixsys.be) Received: from hermes.nixsys.be (hermes.nixsys.be [195.144.77.45]) by gateway.nixsys.be (Postfix) with ESMTP id BDCC9C155 for ; Tue, 30 Sep 2003 09:07:02 +0200 (CEST) Received: by hermes.nixsys.be (Postfix, from userid 1001) id 5DA5851; Tue, 30 Sep 2003 09:07:02 +0200 (CEST) Date: Tue, 30 Sep 2003 09:07:02 +0200 From: Philip Paeps To: acpi-jp@jp.FreeBSD.org, current@freebsd.org Message-ID: <20030930070702.GB648@hermes.nixsys.be> Mail-Followup-To: acpi-jp@jp.FreeBSD.org, current@freebsd.org References: <20030929202116.C3ED35D08@ptavv.es.net> <20030929133012.M78288@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030929133012.M78288@root.org> X-Date-in-Rome: pridie Kalendas Octobres MMDCCLVI ab Urbe Condida X-PGP-Fingerprint: FA74 3C27 91A6 79D5 F6D3 FC53 BF4B D0E6 049D B879 X-Message-Flag: Get a proper mailclient! Mutt: User-Agent: Mutt/1.5.4i Subject: Re: [acpi-jp 2705] Re: Odd ACPI behavior X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2003 07:07:06 -0000 On 2003-09-29 13:33:06 (-0700), Nate Lawson wrote: > On Mon, 29 Sep 2003, Kevin Oberman wrote: > > > From: John Baldwin > > > On 29-Sep-2003 Kevin Oberman wrote: > > > > I recently noticed that, when I boot with ACPI on my IBM T30, I get > > > > errors trying to probe the BIOS disabled sio1. This does not happen > > > > under apm and happens twice(?) when booting with ACPI and happens even > > > > though I have the line 'hint.sio.1.disabled="1"' in > > > > /boot/device.hints. > > > > > > Do you kldload a module at some point during your boot? If so, that > > > would explain the double probe. > > > > Yes, it would, but I am not loading any kernel modules except the slightly > > automatic loads of ACPI, itself and a few others which should not cause a > > probe: ntfs, linux, linprocfs, and daemon_saver. > > ACPI attaches the bus twice. See sys/dev/acpica/acpi.c: There's a bit more weirdness in this regard. I think the ACPI attaching twice is part of the story, but it doesn't appear to be all. As far as I can tell, it's also to do with acpi attaching after something else is already attached. The really funny thing is that acpi tries to attach (twice?) every time the module is 'tickled' in some way. Using my acpi_asus driver as an example: Just booting the machine with acpi and my module loading after the kernel: Preloaded elf kernel "/boot/kernel/kernel" at 0xc04fc000. [...] Preloaded elf module "/boot/kernel/acpi_asus.ko" at 0xc04fc374. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04fc424. For some reason, acpi always insists on being the last module loaded. That might be something in my configuration though? It's slightly annoying as acpi_asus depends on acpi. Then we get the first acpi attachment, which for some reason always fails on me: sio0: configured irq 3 not in bitmap of probed irqs 0 sio0: port may not be enabled A bit later, there's the second attachment, which works, but complains about a nonexistent sio: sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled When I unload the acpi_asus module, nothing funny happens, when I reload it, however: sio4: configured irq 3 not in bitmap of probed irqs 0 sio4: port may not be enabled It appears as though 2 and 3 are skipped because they're marked as disabled in device.hints. Funny that it doesn't try a sio4 at boottime, only if it's loaded after acpi is already present. When I boot, acpi_asus loads before acpi, complaining that it needs acpi, and loads it, then acpi tries to load, complaining that it's already there. Then we get the mysterious sio1, which doesn't exist, popping up. Very odd stuff, I've been looking into this, but as it's not really a problem (everything works), I've not looked too hard yet :-) - Philip [of course, I might be very wrong :-)] -- Philip Paeps Please don't CC me, I am subscribed to the list. BOFH Excuse #166: /pub/lunch