Re: [acpi-jp 2704] Re: Odd ACPI behavior

2003-09-29 Thread Kevin Oberman
> Date: Mon, 29 Sep 2003 13:33:06 -0700 (PDT)
> From: Nate Lawson <[EMAIL PROTECTED]>
> Sender: [EMAIL PROTECTED]
> 
> On Mon, 29 Sep 2003, Kevin Oberman wrote:
> > > Date: Mon, 29 Sep 2003 16:04:25 -0400 (EDT)
> > > From: John Baldwin <[EMAIL PROTECTED]>
> > >
> > > 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.
> > > >>From my dmesg:
> > > > sio0: type 16550A
> > > > sio1: configured irq 3 not in bitmap of probed irqs 0
> > > > sio1: port may not be enabled
> > > > acpi_cmbat0:  on acpi0
> > > > acpi_cmbat1:  on acpi0
> > > > acpi_acad0:  on acpi0
> > > > sio1: configured irq 3 not in bitmap of probed irqs 0
> > > > sio1: port may not be enabled
> > >
> > > 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:
> 
> /*
>  * Scan all of the child devices we have created and let them probe/attach.
>  */
> ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, "first bus_generic_attach\n"));
> bus_generic_attach(bus);
> 
> /*
>  * Some of these children may have attached others as part of their attach
>  * process (eg. the root PCI bus driver), so rescan.
>  */
> ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, "second bus_generic_attach\n"));
> bus_generic_attach(bus);

Thanks. That explains why I get the message twice, but why do I get it
at all when the device is disabled in the device.hints file?
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]   Phone: +1 510 486-8634
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: [acpi-jp 2704] Re: Odd ACPI behavior

2003-09-29 Thread Nate Lawson
On Mon, 29 Sep 2003, Kevin Oberman wrote:
> > Date: Mon, 29 Sep 2003 16:04:25 -0400 (EDT)
> > From: John Baldwin <[EMAIL PROTECTED]>
> >
> > 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.
> > >>From my dmesg:
> > > sio0: type 16550A
> > > sio1: configured irq 3 not in bitmap of probed irqs 0
> > > sio1: port may not be enabled
> > > acpi_cmbat0:  on acpi0
> > > acpi_cmbat1:  on acpi0
> > > acpi_acad0:  on acpi0
> > > sio1: configured irq 3 not in bitmap of probed irqs 0
> > > sio1: port may not be enabled
> >
> > 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:

/*
 * Scan all of the child devices we have created and let them probe/attach.
 */
ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, "first bus_generic_attach\n"));
bus_generic_attach(bus);

/*
 * Some of these children may have attached others as part of their attach
 * process (eg. the root PCI bus driver), so rescan.
 */
ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, "second bus_generic_attach\n"));
bus_generic_attach(bus);

-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"