DragonFlyBSD

On Thu, Jul 06, 2006 at 12:54:47AM +1000, Petr Janda wrote:

Hi,

I got my self a smp server box today, a HP Netserver LP 1000r and Im
trying to install DragonFly on it but booting with ACPI brings me to do
the debugger. The message is:

......
acpi0: <HP HWPC213> on motherboard
Debugger("Executed AML Breakpoing opcode")
Stopped at Debugger+0x44: movb $0,in_Debugger.0

Here's a summary from Martin P. Hellwig two years ago about this
breakpoint issue:
http://leaf.dragonflybsd.org/mailarchive/bugs/2004-08/msg00119.html

I'll commit a fix for this now, thanks for the report.

WARNING: ACPI is disabling APM's device You can't run both

This is harmless.

unknown: I/O range not supported
can't fetch resources for \\_SB_.PCI0.ISA_.SIO_.LPT_ -
AE_AML_INVALID_RESOURCE_TYPE

I wonder if Martin also saw this message at that time.

Hi there,

The fix has fixed the breakpoint. However, dmesg still says

unknown: I/O range not supported
can't fetch resources for \\_SB_.PCI0.ISA_.SIO_.LPT_ -
AE_AML_INVALID_RESOURCE_TYPE

Can anyone have look at it and explain to me why this shows up, and fix it possibly?

Cheers

YONETANI Tomokazu wrote:

On Thu, Jul 06, 2006 at 12:54:47AM +1000, Petr Janda wrote:

Hi,

I got my self a smp server box today, a HP Netserver LP 1000r and Im
trying to install DragonFly on it but booting with ACPI brings me to do
the debugger. The message is:

......
acpi0: <HP HWPC213> on motherboard
Debugger("Executed AML Breakpoing opcode")
Stopped at Debugger+0x44: movb $0,in_Debugger.0

Here's a summary from Martin P. Hellwig two years ago about this
breakpoint issue:
http://leaf.dragonflybsd.org/mailarchive/bugs/2004-08/msg00119.html

I'll commit a fix for this now, thanks for the report.

WARNING: ACPI is disabling APM's device You can't run both

This is harmless.

unknown: I/O range not supported
can't fetch resources for \\_SB_.PCI0.ISA_.SIO_.LPT_ -
AE_AML_INVALID_RESOURCE_TYPE

I wonder if Martin also saw this message at that time.

On Thu, Jul 06, 2006 at 06:54:36PM +1000, Petr Janda wrote:

The fix has fixed the breakpoint. However, dmesg still says

unknown: I/O range not supported

This is the same on FreeBSD - acpi_res_set_iorange() is the function
printing this message. It's been implemented as that way for years.

can't fetch resources for \\_SB_.PCI0.ISA_.SIO_.LPT_ -
AE_AML_INVALID_RESOURCE_TYPE

There's several places in ACPI-CA code where it can display this message,
so I'd look at a verbose dmesg output with the following variables set
at boot prompt(don't try to post it to the mailing list) to find which
function in ACPI-CA code is showing the message:

debug.acpi.layer="ACPI_RESOURCES" 
  debug.acpi.level="ACPI_LV_FUNCTIONS"

Can anyone have look at it and explain to me why this shows up, and fix it
possibly?

They're probably as harmless as they are on FreeBSD.
Quickest workaround I can think of is to set
debug.acpi.disabled="resource"
in /boot/loader.conf, but I'm not sure if it has any side effect.
If you're not seeing any problem other than the annoying warning
messages and the LPT port, you can ignore them.

Hmm, Ive set

debug.acpi.disabled="resource"

in boot /boot/loader.conf and /boot/defaults/loader.conf but the message is still there.

Putting
debug.acpi.layer="ACPI_RESOURCES"
debug.acpi.level="ACPI_LV_FUNCTIONS"

in there also seems to have no effect.

YONETANI Tomokazu wrote:

On Thu, Jul 06, 2006 at 06:54:36PM +1000, Petr Janda wrote:

The fix has fixed the breakpoint. However, dmesg still says

unknown: I/O range not supported

This is the same on FreeBSD - acpi_res_set_iorange() is the function
printing this message. It's been implemented as that way for years.

can't fetch resources for \\_SB_.PCI0.ISA_.SIO_.LPT_ -
AE_AML_INVALID_RESOURCE_TYPE

There's several places in ACPI-CA code where it can display this message,
so I'd look at a verbose dmesg output with the following variables set
at boot prompt(don't try to post it to the mailing list) to find which
function in ACPI-CA code is showing the message:

debug.acpi.layer="ACPI_RESOURCES"
debug.acpi.level="ACPI_LV_FUNCTIONS"

Can anyone have look at it and explain to me why this shows up, and fix it
possibly?

They're probably as harmless as they are on FreeBSD.
Quickest workaround I can think of is to set
debug.acpi.disabled="resource"
in /boot/loader.conf, but I'm not sure if it has any side effect.
If you're not seeing any problem other than the annoying warning
messages and the LPT port, you can ignore them.

On Thu, Jul 06, 2006 at 10:59:51PM +1000, Petr Janda wrote:

debug.acpi.disabled="resource"

Oops, that should've been "sysresource" (it's written in acpi(4) BTW).

in boot /boot/loader.conf and /boot/defaults/loader.conf but the message is
still there.

Putting
debug.acpi.layer="ACPI_RESOURCES"
debug.acpi.level="ACPI_LV_FUNCTIONS"

in there also seems to have no effect.

Oops, I forgot saying that you need to reinstall acpi.ko with
debugging enabled to use them:

cd /sys/dev/acpica5
setenv ACPI_DEBUG yes
setenv MAKEOBJDIRPREFIX /usr/obj
make obj && make depend && make && make install

But then of course, it starts dropping into the debugger at the
breakpoint opcode on every reboot :) You might want to create
a custom AML like Martin did.

Do i need to recompile acpi.ko for this one too? Because it still doesnt

work and I dont have the system connected to the internet at the moment
so I cant get the source now.

YONETANI Tomokazu wrote:

On Thu, Jul 06, 2006 at 10:59:51PM +1000, Petr Janda wrote:

debug.acpi.disabled="resource"

Oops, that should've been "sysresource" (it's written in acpi(4) BTW).

On Thu, Jul 06, 2006 at 11:42:36PM +1000, Petr Janda wrote:

debug.acpi.disabled="resource"

Oops, that should've been "sysresource" (it's written in acpi(4) BTW).

Do i need to recompile acpi.ko for this one too?

No, debug.acpi.disabled works without ACPI_DEBUG. But you need "set"
in front of it (in case you never used the boot loader prompt before):

set debug.acpi.disabled="sysresource"

Cheers.

YONETANI Tomokazu wrote:

On Thu, Jul 06, 2006 at 12:54:47AM +1000, Petr Janda wrote:

Hi,

I got my self a smp server box today, a HP Netserver LP 1000r and Im
trying to install DragonFly on it but booting with ACPI brings me to do
the debugger. The message is:

......
acpi0: <HP HWPC213> on motherboard
Debugger("Executed AML Breakpoing opcode")
Stopped at Debugger+0x44: movb $0,in_Debugger.0

Here's a summary from Martin P. Hellwig two years ago about this
breakpoint issue:
http://leaf.dragonflybsd.org/mailarchive/bugs/2004-08/msg00119.html

I'll commit a fix for this now, thanks for the report.

WARNING: ACPI is disabling APM's device You can't run both

This is harmless.

unknown: I/O range not supported
can't fetch resources for \\_SB_.PCI0.ISA_.SIO_.LPT_ -
AE_AML_INVALID_RESOURCE_TYPE

I wonder if Martin also saw this message at that time.

If I remember correctly I saw indeed these kind of messages.
At this moment that box is happily running FBSD 6.1.
But I will reinstall df next week, it's about time I'll dig into it
again (it's a personal test box).

That would be great Martin. I just dont have time for all that debugging
at the moment myself.

Petr

YONETANI Tomokazu wrote:

On Thu, Jul 06, 2006 at 12:54:47AM +1000, Petr Janda wrote:

Hi,

I got my self a smp server box today, a HP Netserver LP 1000r and Im
trying to install DragonFly on it but booting with ACPI brings me to do
the debugger. The message is:

......
acpi0: <HP HWPC213> on motherboard
Debugger("Executed AML Breakpoing opcode")
Stopped at Debugger+0x44: movb $0,in_Debugger.0

Here's a summary from Martin P. Hellwig two years ago about this
breakpoint issue:
http://leaf.dragonflybsd.org/mailarchive/bugs/2004-08/msg00119.html

I'll commit a fix for this now, thanks for the report.

WARNING: ACPI is disabling APM's device You can't run both

This is harmless.

unknown: I/O range not supported
can't fetch resources for \\_SB_.PCI0.ISA_.SIO_.LPT_ -
AE_AML_INVALID_RESOURCE_TYPE

I wonder if Martin also saw this message at that time.

If I remember correctly I saw indeed these kind of messages.
At this moment that box is happily running FBSD 6.1.
But I will reinstall df next week, it's about time I'll dig into it
again (it's a personal test box).

--
mph