Subject: Re: Amiga 3000 video strangeness - next thing
To: Michael L. Hitch <mhitch@gemini.msu.montana.edu>
From: Frank Wille <frank@phoenix.owl.de>
List: port-amiga
Date: 06/06/2007 19:59:11
Michael L. Hitch wrote:

> On Sat, 2 Jun 2007, Frank Wille wrote:
> 
>> ite at grfet1:  not configured
>> trap type 0, code = 1c5, v = 30a0014
>> pid = 0, lid = 1, pc = 00101892, ps = 2010, sfc = 1, dfc = 1
>> [...]
>> mutex_enter(?)
>> specificdata_key_create(30a0014,16a0d8,d3e18,1bbf84,d3d34) + c
>> proc_specific_key_create(16a0d8,d3e18) + 12
>> ksem_init(0,0,ad303,dfffffc,0) + 4a
>> main(1bbfb4) + 124
>> start() + 1c2
> 
>  I would be curios to know what's at the trapped instruction.  I'm
> guessing it's in mutex_enter(),

Yes, all those crashes are at the same location in mutex_enter(). When I
disable POSIX-semaphores in my kernel, ksem_init is no longer called, but
then it fails at the next mutex_enter().


> but the stack trace doesn't show that.
> Use the pc value from the trap information:
> 
> x/i 00101892

4 views configured
trap type 0, code = 1c5, v = 308bf10
pid = 0, lid = 1, pc = 000C06C2, ps = 2000, sfc = 1, dfc = 1
Registers:
             0        1        2        3        4        5        6        7
dreg: 00000000 00120B20 00000000 00000000 00120B00 0015DF5C 000C06B6 00053B5A
areg: 0308BF10 0308FFDC 0308BF10 03095D38 03095D48 03095D50 0015DEA8 0DFFFFFC

[...]
db> x/i 0xC06C2
netbsd:mutex_enter+0xc: casl    d0,d1,a0@
db> x/m 0x308BF10
0x308bf10:      00000000                                ....


>  I have a suspicion that it may be the casl instruction. 

Indeed. Always.

Nearly always. Today I had a try which reached askroot, passing all those
CAS instructions.


> I didn't know
> if that would work on all amigas or not.  [I know it's not supported for
> chip memory access and not supposed to be used, but I figured it's
> unlikely there's an amiga configuation that would be using chip memory
> for kernel memory and didn't worry about it.]

True. Should be no problem. I made a small test program with this
instruction and it executed without causing any exception on Chip- and on
Fast-RAM.

I guess it gets into trouble when running into a bus-fault (MMU-exception)
while executing CAS. I don't know if the exception handler is prepared to
emulate the entire read-modify-write cycle of this instruction?


-- 
    _  Frank Wille (frank@phoenix.owl.de)
 _ //  http://sun.hasenbraten.de/~frank/
 \X/   Phx @ #AmigaGer