Re: Mac-only binary, was Re: Modernizing a Macintosh LC III
On Tue, 19 Nov 2013, Patrick McCarthy wrote:
> Unfortunately this didn't work for me (via Penguin, 32bit mode, new
> filesystem), but I'm not clear on what what failed.
>
> The error screen: http://imgur.com/v4uS3ia
>
> Salient bit:
> Data read fault at 0x00000000 in Super Data (pc:0x3e22c)
> BAD KERNEL BUSERR
>
> I haven't had time yet to research in detail but one Google hit brought up a
> message on this list from nearly ten years ago (!):
> http://marc.info/?l=linux-mac68k&m=109564526803428&w=2
That bug report was also from a 68030 machine (Mac IIfx). But I didn't see
this issue when I was testing linux-3.2 builds on a Mac IIfx. Is the crash
intermittent or does it behave the same on every boot?
BTW, no filesystem has been mounted at this point, so reproducing the
crash should be harmless.
>
> In Thorsten's config I noticed these:
>
> # CONFIG_SCSI_GENERIC_NCR5380 is not set
> # CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
>
> My Sarge said it was a 5380, perhaps this is my problem?
This doesn't look to me like a ten-year old mac_scsi bug. I've made some
bug fixes to mac_scsi in recent years but mostly I've focused on the more
capable 68040 models (of those, only the laptops need the mac_scsi driver,
and they have little RAM anyway.)
The backtrace indicates a crash at 0x3e22c, not in the mac_scsi driver but
in cmpxchg_futex_value_locked() when called by futex_init().
The code in the backtrace has a digit cropped by the display...
Code: 200f 0280 ffff e000 2240 52a9 0010 4280 <0e90> 1000 4a80 661c b2af 000c 660
c 226f 0010 0e90 9800 4a80 660a 206f 0004 2081
...but it matches the binary at the right address:
0003e218 <cmpxchg_futex_value_locked>:
3e218: 206f 0008 moveal %sp@(8),%a0
3e21c: 200f movel %sp,%d0
3e21e: 0280 ffff e000 andil #-8192,%d0
3e224: 2240 moveal %d0,%a1
3e226: 52a9 0010 addql #1,%a1@(16)
3e22a: 4280 clrl %d0
3e22c: 0e90 1000 movesl %a0@,%d1
3e230: 4a80 tstl %d0
3e232: 661c bnes 3e250 <cmpxchg_futex_value_locked+0x38>
3e234: b2af 000c cmpl %sp@(12),%d1
3e238: 660c bnes 3e246 <cmpxchg_futex_value_locked+0x2e>
3e23a: 226f 0010 moveal %sp@(16),%a1
3e23e: 0e90 9800 movesl %a1,%a0@
3e242: 4a80 tstl %d0
3e244: 660a bnes 3e250 <cmpxchg_futex_value_locked+0x38>
3e246: 206f 0004 moveal %sp@(4),%a0
3e24a: 2081 movel %d1,%a0@
3e24c: 4280 clrl %d0
3e24e: 6002 bras 3e252 <cmpxchg_futex_value_locked+0x3a>
3e250: 70f2 moveq #-14,%d0
3e252: 220f movel %sp,%d1
3e254: 0281 ffff e000 andil #-8192,%d1
3e25a: 2041 moveal %d1,%a0
3e25c: 53a8 0010 subql #1,%a0@(16)
3e260: 4e75 rts
I would infer that register a0 contains a bogus pointer. The backtrace
says it is NULL. Well, it was set to null by futex_init() just before the
call to cmpxchg_futex_value_locked()...
002c2d7c <futex_init>:
2c2d7c: 4e56 fffc linkw %fp,#-4
2c2d80: 42a7 clrl %sp@-
2c2d82: 42a7 clrl %sp@-
2c2d84: 42a7 clrl %sp@-
2c2d86: 486e fffc pea %fp@(-4)
2c2d8a: 4eb9 0003 e218 jsr 3e218 <cmpxchg_futex_value_locked>
2c2d90: 4fef 0010 lea %sp@(16),%sp
2c2d94: 72f2 moveq #-14,%d1
2c2d96: b280 cmpl %d0,%d1
2c2d98: 670a beqs 2c2da4 <futex_init+0x28>
2c2d9a: 41f9 002a b14c lea 2ab14c <futex_queues>,%a0
2c2da0: 4280 clrl %d0
2c2da2: 600a bras 2c2dae <futex_init+0x32>
2c2da4: 7001 moveq #1,%d0
2c2da6: 23c0 002a b148 movel %d0,2ab148 <futex_cmpxchg_enabled>
2c2dac: 60ec bras 2c2d9a <futex_init+0x1e>
2c2dae: 2200 movel %d0,%d1
2c2db0: e789 lsll #3,%d1
2c2db2: 0681 002a b14c addil #2797900,%d1
2c2db8: 2081 movel %d1,%a0@
2c2dba: 2141 0004 movel %d1,%a0@(4)
2c2dbe: 5280 addql #1,%d0
2c2dc0: 5088 addql #8,%a0
2c2dc2: 0c80 0000 0100 cmpil #256,%d0
2c2dc8: 66e4 bnes 2c2dae <futex_init+0x32>
2c2dca: 4240 clrw %d0
2c2dcc: 4e5e unlk %fp
2c2dce: 4e75 rts
Beats me. I guess I'll have to try another compiler.
Finn
Reply to: