On 10/30/06, Christos Zoulas <christos@astron.com> wrote:
> In article <bc8ff1fd0610300556t4b023573o3ac1af20b32fb110@mail.gmail.com>,
> Chavdar Ivanov <ci4ic4@gmail.com> wrote:
> >-=-=-=-=-=-
> >
> >Attempts to try to use npx off different bus while keeping MPACPI
> >basic configuration failed.
> >
> >Not knowing how to proceed to debug the kernel in such a situation (
> >or for any other for that matter ) I decided to try to locate where
> >the hang in the npx code takes place.
> >
> >I noticed, that the last two lines printed were:
> >
> >npx0: at acpi0...
> >npx0: io...
> >
> >but not the usual next:
> >
> >npx0: using exception 16
> >
> >The latter one is printed by npx_acpi.c; a few sprinkled aprint_error
> >() showed me that the hang is in npxprobe1, which is in isa/npx.c. A
> >few more aprintfs narrowed down the hang to a single statement - the
> >sole 'write_eflags(save_eflags);'. The asm code in the latter does not
> >mean anything to me, so I just commented this line out of npx.c and
> >now I have the system running properly with two CPUs and floating
> >point with the proper exception 16...
> >
> >I don't know if this merits a PR.
> >
> >No idea if this is correct and if so, why. Having this running, I
> >think I can now commit the 20GB partition currently occupied by
> >FreeBSD to NetBSD again. I will have to switch to compatible the SATA
> >controller's mode, as it is still not recognized, which is just a
> >minor annoyance (and probably better anyway, judging by the earlier
> >benchmark results).
> >
> >The (partial) dmesg.boot and output from lspci -v(with the latest pci
> >database)  are included, in case anyone is interested.
>
> Can you please cvs update and try again?

I did exactly that - v 1.114 seems to correct the problem with npx,
most likely just returning from the added if block.

>
> christos
>
>

Thanks,

Chavdar