Re: [acpi-jp 2706] Re: Odd ACPI behavior
On Mon, 29 Sep 2003, Nate Lawson wrote: On Mon, 29 Sep 2003, Kevin Oberman wrote: ACPI attaches the bus twice. See sys/dev/acpica/acpi.c: 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? Dunno. That's probably an sio(4) problem. It does that on my laptop also. It would be a layering violation for sio(4) to even look at the disabled flag. However, it has to look at this flag for consoles, since new-bus is is not initialized when consoles are attached. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [acpi-jp 2705] Re: Odd ACPI behavior
On 2003-09-29 13:33:06 (-0700), Nate Lawson [EMAIL PROTECTED] wrote: On Mon, 29 Sep 2003, Kevin Oberman wrote: 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. 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 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Odd ACPI behavior
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: Control method Battery on acpi0 acpi_cmbat1: Control method Battery on acpi0 acpi_acad0: AC adapter on acpi0 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled Any idea why this is happening? It does not seem to be a serious issue, but it is very odd. acpidump output, full dmesg, config and whatever available on request. Do you kldload a module at some point during your boot? If so, that would explain the double probe. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Odd ACPI behavior
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: Control method Battery on acpi0 acpi_cmbat1: Control method Battery on acpi0 acpi_acad0: AC adapter on acpi0 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled Any idea why this is happening? It does not seem to be a serious issue, but it is very odd. acpidump output, full dmesg, config and whatever available on request. 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. -- 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
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: Control method Battery on acpi0 acpi_cmbat1: Control method Battery on acpi0 acpi_acad0: AC adapter 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]
Re: [acpi-jp 2704] Re: Odd ACPI behavior
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: Control method Battery on acpi0 acpi_cmbat1: Control method Battery on acpi0 acpi_acad0: AC adapter 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 2706] Re: Odd ACPI behavior
On Mon, 29 Sep 2003, Kevin Oberman wrote: Date: Mon, 29 Sep 2003 13:33:06 -0700 (PDT) From: Nate Lawson [EMAIL PROTECTED] 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? Dunno. That's probably an sio(4) problem. It does that on my laptop also. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
