On Wed, 14 Mar 2001, Flavio Stanchina wrote:
> On 12-Mar-01, William F. Maddock wrote:
> > On 12-Mar-01 11:54:36 [EMAIL PROTECTED] Javier A. Ospina wrote:
>
> >> Does any body know what "Program failed (error#8000000B)" is???
> >> I keep getting this message with MiamiDx.
>
> >> Miami does not have this problem. It only comes up with MiamiDx.
> >> People on the MiamiDX have no idea since a never got a reply.
>
> > Not very helpful, I know, but Guru3.0 reports this as a "Line 1111
> > emulator error". I *think* it's got something to do with MMU or FPU
> > instructions.
>
> Yes, in the sense that FPU/MMU instructions start with bit pattern 1111;
> you can emulate missing FPU instructions (for example the missing 68882
> instructions on a 68040) by intercepting that exception and figuring out
> what to do. In this case however, it's certainly a bug that causes the CPU
> to try to execute a random piece of memory as if it was program code: of
> course that memory contains invalid instructions, one of which happens to
> look like an unimplemented FPU instruction.
Yes, any negative integer that isn't "large" appears to be an "F-line"
instruction when interpreted as 68K code. Unfortunately most positive
integers look like legal instructions, so jumping into data often executes
for many instructions before stumbling into something illegal.
Executing code as data either means that:
1) Something that was supposed to be code was overwritten with data.
2) The program jumped to a bad address which happened to be data.
Since #2 is most likely due to some pointer being clobbered (e.g. a return
address on the stack), problems of this form are almost always due to
memory trashing. Of course you also get that error if you try to run a
program built for FPU on a machine without an FPU, but that isn't the
cases here.
> Without furhter analysis it is not possible to determine who is causing
> this problem and how to correct it: it might be MiamiDx, or any one of the
> third-party libraries it is using (such as MUI), or any other program
> running wild over memory currrently in use by MiamiDx, or even faulty
> hardware. The fact that it happens with MiamiDx but not with Miami doesn't
> necessarily mean that it is MiamiDx's fault: it could just be more
> sensitive to a condition that already existed.
In particular, one of the problems with the single address space model of
the AmigaOS, aside from the lack of memory protection, is that the actual
addresses used within a program or module depend on what else was in
memory at the time. Although code *shouldn't* care about the actual
addresses used, *buggy* code is often sensitive to the actual addresses
used. This means that using or not using a completely innocent program
may affect the behavior of another.
That being said, a couple of things to check (aside from system patcehs in
general, especially MCP) are buggy "improved" MUI custom classes and buggy
drivers.
On Mon, 12 Mar 2001, Javier A. Ospina wrote:
>
> A1200 BlizzardPPC/BVisionPPC 200/040, 64 MB, Mediator PCI, Ethernet card
> OS3.9, MUI 3.8
You don't mention what Ethernet card you're using, but if it's a PCI card
for the Mediator I'd suspect the driver, since the Mediator isn't very
mature.
Fred Wright
--
To unsubscribe send "unsubscribe miami-talk-ml" to
"[EMAIL PROTECTED]". For help on list commands send "help" to
"[EMAIL PROTECTED]".
