- Posts: 1
- Thank you received: 0
FreeAXP - Tru64 V5.1B - frequent crash
- John_Manger
-
- Offline
- Moderator
-
Less
More
13 years 8 months ago #5199
by John_Manger
Replied by John_Manger on topic RE: AdvFS Domain Data inconsistency or disk/HW problem
Hi,
You have had an AdvFS domain panic.
- invalid frag group
- write error or internal inconsistency (in/with the frag group metadata)
- and an AdvFS I/O error (read) of block 10930176 within dsk1h.
The domain is then 'offlined' and inaccessible.
This would normally be attributed to a storage problem - a disk error, or data inconsistency on disk perhaps introduced by previous problems.
The AdvFS domain will only become available again after a reboot.
However you should consider re-creating the volume, as the problem will likely re-occur when the same block or its neighbours is accessed again. Alternatively, you may try to repair the damaged section(s) with fixfdmn(
, but given the I/O error noted earlier, it may not be completely sucessful.
As you observe, this is not the same issue as described in your original post.
regards,
John M
You have had an AdvFS domain panic.
- invalid frag group
- write error or internal inconsistency (in/with the frag group metadata)
- and an AdvFS I/O error (read) of block 10930176 within dsk1h.
The domain is then 'offlined' and inaccessible.
This would normally be attributed to a storage problem - a disk error, or data inconsistency on disk perhaps introduced by previous problems.
The AdvFS domain will only become available again after a reboot.
However you should consider re-creating the volume, as the problem will likely re-occur when the same block or its neighbours is accessed again. Alternatively, you may try to repair the damaged section(s) with fixfdmn(

As you observe, this is not the same issue as described in your original post.
regards,
John M
Please Log in or Create an account to join the conversation.
- John_Manger
-
- Offline
- Moderator
-
Less
More
- Posts: 1
- Thank you received: 0
13 years 8 months ago #5200
by John_Manger
Replied by John_Manger on topic RE: Other logs ...
Also, you may wish to examine the Tru64 binary error log (in /var/adm/) using dia (DECevent) or uerf - and check if there is any additional disk error information visble for the time of the AdvFS error.
And check the main FreeAXP log (not the PuTTY /dev/console log), and see if it reports anything 'odd' for the disk unit used by dsk1.
regards,
John M<hr>
And check the main FreeAXP log (not the PuTTY /dev/console log), and see if it reports anything 'odd' for the disk unit used by dsk1.
regards,
John M<hr>
Please Log in or Create an account to join the conversation.
- abhijit_gt
- Topic Author
- Visitor
-
13 years 8 months ago #5201
by abhijit_gt
Replied by abhijit_gt on topic RE: FreeAXP - Tru64 V5.1B - frequent crash
Hi,
Now I got a crash again moments after running SQLPlus (we installed Oracle 8.1.7 client - same version that is already running on a physical ES40).
When I ran the program from a normal (not 'root'<img src='../images/smiley/wink.gif' alt='smiley'> user account and gave random username/password, it gave some errors and came out (obviously). About 5 seconds later I got this OS crash. So, I think it did not happen due to SQLPlus.
BTW: I have already changed the network card type to DE500 (21140).
******************************************
trap: invalid memory write access from kernel mode
faulting virtual address: 0x000000011ffffca8
pc of faulting instruction: 0xfffffc0000558fd0
ra contents at time of fault: 0xfffffc0000564440
sp contents at time of fault: 0x000000011fffb0b0
panic (cpu 0): kernel memory fault
syncing disks... done
DUMP: blocks available: 1342434
DUMP: blocks wanted: 21554 (partial compressed dump) [OKAY]
DUMP: Device Disk Blocks Available
DUMP:
DUMP: 0x1300013 396520 - 523231 (of 523232) [primary swap]
DUMP.prom: Open: dev 0x5100041, block 523234: SCSI 0 6 0 1 100 0 0
DUMP: Writing header... [1024 bytes at dev 0x1300013, block 523232]
DUMP: Writing data.. [2MB]
DUMP: Writing header... [1024 bytes at dev 0x1300013, block 523232]
DUMP: crash dump complete.
trap: invalid memory write access from kernel mode
faulting virtual address: 0x000000011ffffcfc
pc of faulting instruction: 0xfffffc000055da00
ra contents at time of fault: 0xfffffc000055d9e0
sp contents at time of fault: 0x000000011fffab70
DUMP: second crash dump skipped: 'dump_savecnt' enforced.
halted CPU 0
halt code = 5
HALT instruction executed
PC = fffffc000055ed70
>>>
FreeAXP VLC log for the session that crashed:
*************************************
FreeAXP Virtual Alpha x86 version 2.0.0.377 (Jun 8 2011 11:06:05)
Windows workstation version 5.1 SP 3.0, build 2600 (Service Pack 3, v.3311) suite 100 (WMI Name: Microsoft Windows XP Professional|C:\WINDOWS|\Device\Harddisk0\Partition5)
2 processor cores of family 17, stepping 0a (WMI Name: Intel Pentium III Xeon processor)
File opened at 2011-08-12 18:48:09
%XNV-I-RESTST: NVRAM restored from F:\AXPES40\AXPES40_AXPES40.nvr
DFL-I-MOUNT: cp(control).AXPES40(alpha (AS400)).pcibus(dc21071da).pci6(symbios).disk0.0(file): Mounted file F:\FreeAXP\AXP_V5.1B.iso, handle 0000019C, 1320704 512-byte blocks, 1876/16/44 as DEC RRD42 4.5d SRL0000.
DFL-I-MOUNT: cp(control).AXPES40(alpha (AS400)).pcibus(dc21071da).pci6(symbios).disk0.1(file): Mounted file F:\AXPES40\SYSDISK.vdisk, handle 000001A8, 3907911 512-byte blocks, 186091/7/3 as DEC RZ73 T366 SRL0101.
DFL-I-MOUNT: cp(control).AXPES40(alpha (AS400)).pcibus(dc21071da).pci6(symbios).disk0.3(file): Mounted file F:\AXPES40\swapdisk.vdisk, handle 000001A4, 1954050 512-byte blocks, 3722/15/35 as DEC RZ57 6000 SRL0303.
DFL-I-MOUNT: cp(control).AXPES40(alpha (AS400)).pcibus(dc21071da).pci6(symbios).disk0.4(file): Mounted file F:\AXPES40\DATARECO.img, handle 00000198, 17773524 512-byte blocks, 493709/12/3 as DEC RZ40L 8203 SRL0404.
XTI-I-RESTST: cp(control).AXPES40(alpha (AS400)).pcibus(dc21071da).toy(bq3287): TOY restored from F:\AXPES40\AXPES40_AXPES40.toy
Actor framework started with 9 thread(s)
CTS-I-NEWSESS: New session on cp(control).AXPES40(alpha (AS400)).pcibus(dc21071da).serial0(i16550) from IP address 127.0.0.1
Can not set cache size: SetSystemFileCacheSize not found in KERNEL32.DLL.
AC4-I-DECOMP: Decompressing ROM image... done.
AC4-I-PATCHROM: Patching ROM for speed.
AXP-I-CPUSTRT: cp(control).AXPES40(alpha (AS400)).cpu0(EV4): CPU Starting
ESL-I-EXIT: Normal emulator shutdown requested.
%XNV-I-SAVEST: NVRAM saved to F:\AXPES40\AXPES40_AXPES40.nvr
XTI-I-SAVEST: cp(control).AXPES40(alpha (AS400)).pcibus(dc21071da).toy(bq3287): Flash saved to F:\AXPES40\AXPES40_AXPES40.toy
ASY-I-FREEMEM: cp(control).AXPES40(alpha (AS400)): Freeing memory in use by system...
Bq3287: asserted 322856936 times
de-asserted 322856936 times
re-asserted 174915 times
DFL-I-CLOSE: cp(control).AXPES40(alpha (AS400)).pcibus(dc21071da).pci6(symbios).disk0.0(file): Closing file.
IOC STATISTICS FOR cp(control).AXPES40(alpha (AS400)).pcibus(dc21071da).pci6(symbios).disk0.0(file)
read (async): issued 0 times, completed 0 times
read (sync ): issued 0 times, completed 0 times
write (async): issued 0 times, completed 0 times
write (sync ): issued 0 times, completed 0 times
DFL-I-CLOSE: cp(control).AXPES40(alpha (AS400)).pcibus(dc21071da).pci6(symbios).disk0.1(file): Closing file.
IOC STATISTICS FOR cp(control).AXPES40(alpha (AS400)).pcibus(dc21071da).pci6(symbios).disk0.1(file)
read (async): issued 0 times, completed 0 times
read (sync ): issued 12672 times, completed 0 times
write (async): issued 0 times, completed 0 times
write (sync ): issued 27945 times, completed 0 times
DFL-I-CLOSE: cp(control).AXPES40(alpha (AS400)).pcibus(dc21071da).pci6(symbios).disk0.3(file): Closing file.
IOC STATISTICS FOR cp(control).AXPES40(alpha (AS400)).pcibus(dc21071da).pci6(symbios).disk0.3(file)
read (async): issued 0 times, completed 0 times
read (sync ): issued 5 times, completed 0 times
write (async): issued 0 times, completed 0 times
write (sync ): issued 0 times, completed 0 times
DFL-I-CLOSE: cp(control).AXPES40(alpha (AS400)).pcibus(dc21071da).pci6(symbios).disk0.4(file): Closing file.
IOC STATISTICS FOR cp(control).AXPES40(alpha (AS400)).pcibus(dc21071da).pci6(symbios).disk0.4(file)
read (async): issued 0 times, completed 0 times
read (sync ): issued 910 times, completed 0 times
write (async): issued 0 times, completed 0 times
write (sync ): issued 171 times, completed 0 times
Crash dump files saved in /var/adm/crash.
I need to know why this is unstable. If its only my instance that's behaving like this, what do I need to do get a stable system using FreeAXP.
Thanks,
Abhijit.
Now I got a crash again moments after running SQLPlus (we installed Oracle 8.1.7 client - same version that is already running on a physical ES40).
When I ran the program from a normal (not 'root'<img src='../images/smiley/wink.gif' alt='smiley'> user account and gave random username/password, it gave some errors and came out (obviously). About 5 seconds later I got this OS crash. So, I think it did not happen due to SQLPlus.
BTW: I have already changed the network card type to DE500 (21140).
******************************************
trap: invalid memory write access from kernel mode
faulting virtual address: 0x000000011ffffca8
pc of faulting instruction: 0xfffffc0000558fd0
ra contents at time of fault: 0xfffffc0000564440
sp contents at time of fault: 0x000000011fffb0b0
panic (cpu 0): kernel memory fault
syncing disks... done
DUMP: blocks available: 1342434
DUMP: blocks wanted: 21554 (partial compressed dump) [OKAY]
DUMP: Device Disk Blocks Available
DUMP:
DUMP: 0x1300013 396520 - 523231 (of 523232) [primary swap]
DUMP.prom: Open: dev 0x5100041, block 523234: SCSI 0 6 0 1 100 0 0
DUMP: Writing header... [1024 bytes at dev 0x1300013, block 523232]
DUMP: Writing data.. [2MB]
DUMP: Writing header... [1024 bytes at dev 0x1300013, block 523232]
DUMP: crash dump complete.
trap: invalid memory write access from kernel mode
faulting virtual address: 0x000000011ffffcfc
pc of faulting instruction: 0xfffffc000055da00
ra contents at time of fault: 0xfffffc000055d9e0
sp contents at time of fault: 0x000000011fffab70
DUMP: second crash dump skipped: 'dump_savecnt' enforced.
halted CPU 0
halt code = 5
HALT instruction executed
PC = fffffc000055ed70
>>>
FreeAXP VLC log for the session that crashed:
*************************************
FreeAXP Virtual Alpha x86 version 2.0.0.377 (Jun 8 2011 11:06:05)
Windows workstation version 5.1 SP 3.0, build 2600 (Service Pack 3, v.3311) suite 100 (WMI Name: Microsoft Windows XP Professional|C:\WINDOWS|\Device\Harddisk0\Partition5)
2 processor cores of family 17, stepping 0a (WMI Name: Intel Pentium III Xeon processor)
File opened at 2011-08-12 18:48:09
%XNV-I-RESTST: NVRAM restored from F:\AXPES40\AXPES40_AXPES40.nvr
DFL-I-MOUNT: cp(control).AXPES40(alpha (AS400)).pcibus(dc21071da).pci6(symbios).disk0.0(file): Mounted file F:\FreeAXP\AXP_V5.1B.iso, handle 0000019C, 1320704 512-byte blocks, 1876/16/44 as DEC RRD42 4.5d SRL0000.
DFL-I-MOUNT: cp(control).AXPES40(alpha (AS400)).pcibus(dc21071da).pci6(symbios).disk0.1(file): Mounted file F:\AXPES40\SYSDISK.vdisk, handle 000001A8, 3907911 512-byte blocks, 186091/7/3 as DEC RZ73 T366 SRL0101.
DFL-I-MOUNT: cp(control).AXPES40(alpha (AS400)).pcibus(dc21071da).pci6(symbios).disk0.3(file): Mounted file F:\AXPES40\swapdisk.vdisk, handle 000001A4, 1954050 512-byte blocks, 3722/15/35 as DEC RZ57 6000 SRL0303.
DFL-I-MOUNT: cp(control).AXPES40(alpha (AS400)).pcibus(dc21071da).pci6(symbios).disk0.4(file): Mounted file F:\AXPES40\DATARECO.img, handle 00000198, 17773524 512-byte blocks, 493709/12/3 as DEC RZ40L 8203 SRL0404.
XTI-I-RESTST: cp(control).AXPES40(alpha (AS400)).pcibus(dc21071da).toy(bq3287): TOY restored from F:\AXPES40\AXPES40_AXPES40.toy
Actor framework started with 9 thread(s)
CTS-I-NEWSESS: New session on cp(control).AXPES40(alpha (AS400)).pcibus(dc21071da).serial0(i16550) from IP address 127.0.0.1
Can not set cache size: SetSystemFileCacheSize not found in KERNEL32.DLL.
AC4-I-DECOMP: Decompressing ROM image... done.
AC4-I-PATCHROM: Patching ROM for speed.
AXP-I-CPUSTRT: cp(control).AXPES40(alpha (AS400)).cpu0(EV4): CPU Starting
ESL-I-EXIT: Normal emulator shutdown requested.
%XNV-I-SAVEST: NVRAM saved to F:\AXPES40\AXPES40_AXPES40.nvr
XTI-I-SAVEST: cp(control).AXPES40(alpha (AS400)).pcibus(dc21071da).toy(bq3287): Flash saved to F:\AXPES40\AXPES40_AXPES40.toy
ASY-I-FREEMEM: cp(control).AXPES40(alpha (AS400)): Freeing memory in use by system...
Bq3287: asserted 322856936 times
de-asserted 322856936 times
re-asserted 174915 times
DFL-I-CLOSE: cp(control).AXPES40(alpha (AS400)).pcibus(dc21071da).pci6(symbios).disk0.0(file): Closing file.
IOC STATISTICS FOR cp(control).AXPES40(alpha (AS400)).pcibus(dc21071da).pci6(symbios).disk0.0(file)
read (async): issued 0 times, completed 0 times
read (sync ): issued 0 times, completed 0 times
write (async): issued 0 times, completed 0 times
write (sync ): issued 0 times, completed 0 times
DFL-I-CLOSE: cp(control).AXPES40(alpha (AS400)).pcibus(dc21071da).pci6(symbios).disk0.1(file): Closing file.
IOC STATISTICS FOR cp(control).AXPES40(alpha (AS400)).pcibus(dc21071da).pci6(symbios).disk0.1(file)
read (async): issued 0 times, completed 0 times
read (sync ): issued 12672 times, completed 0 times
write (async): issued 0 times, completed 0 times
write (sync ): issued 27945 times, completed 0 times
DFL-I-CLOSE: cp(control).AXPES40(alpha (AS400)).pcibus(dc21071da).pci6(symbios).disk0.3(file): Closing file.
IOC STATISTICS FOR cp(control).AXPES40(alpha (AS400)).pcibus(dc21071da).pci6(symbios).disk0.3(file)
read (async): issued 0 times, completed 0 times
read (sync ): issued 5 times, completed 0 times
write (async): issued 0 times, completed 0 times
write (sync ): issued 0 times, completed 0 times
DFL-I-CLOSE: cp(control).AXPES40(alpha (AS400)).pcibus(dc21071da).pci6(symbios).disk0.4(file): Closing file.
IOC STATISTICS FOR cp(control).AXPES40(alpha (AS400)).pcibus(dc21071da).pci6(symbios).disk0.4(file)
read (async): issued 0 times, completed 0 times
read (sync ): issued 910 times, completed 0 times
write (async): issued 0 times, completed 0 times
write (sync ): issued 171 times, completed 0 times
Crash dump files saved in /var/adm/crash.
I need to know why this is unstable. If its only my instance that's behaving like this, what do I need to do get a stable system using FreeAXP.
Thanks,
Abhijit.
Please Log in or Create an account to join the conversation.
- abhijit_gt
- Topic Author
- Visitor
-
13 years 8 months ago #5202
by abhijit_gt
Replied by abhijit_gt on topic RE: FreeAXP - Tru64 V5.1B - frequent crash
I can confirm that SQLPlus was not involved in the crash I reported in the previous post. I repeated the same steps again (wrong username/password) after reboot and there was no crash yet. Also, I am able to communicate to a DB running in another machine through SQLPlus.
Abhijit.
Abhijit.
Please Log in or Create an account to join the conversation.
- abhijit_gt
- Topic Author
- Visitor
-
13 years 8 months ago #5203
by abhijit_gt
Replied by abhijit_gt on topic RE: FreeAXP - Tru64 V5.1B - frequent crash
Some more info:
1) Stack trace of the core dump yields this (one liner):
> 0 thread_block() ["../../../../src/kernel/kern/sched_prim.c":3291, 0xfffffc00002e7af0]
(dbx)
2) We had a repeat ADFS panic after this crash and its stack trace goes:
11 domain_panic(dmnP = 0xfffffc00050e2008, format = (nil)) ["../../../../src/kernel/msfs/osf/msfs_io.c":1093, 0xfffffc00003ac21c]
12 bmtr_find(0xfffffc00050e2008, 0xfffffc000098c000, 0x0, 0xfffffe0409a90000, 0xfffffc0000346c64) ["../../../../src/kernel/msfs/bs/bs_bmt_util.c":1238, 0xfffffc000032cf5c]
13 set_recovery_failed(0xfffffc000037bf44, 0x736940, 0x4, 0x260, 0xfffffc0005d50188) ["../../../../src/kernel/msfs/bs/bs_domain.c":7013, 0xfffffc0000346c60]
14 CANT_CLEAR_TWICE(0x4, 0xffffc0, 0x4c17, 0x260, 0x260) ["../../../../src/kernel/msfs/bs/bs_sbm.c":515, 0xfffffc000037bf40]
15 dealloc_bits_page(0x5, 0xfffffc00022c8000, 0xfffffc00050e2008, 0x20010, 0xfffffc0000004c00) ["../../../../src/kernel/msfs/bs/bs_sbm.c":1045, 0xfffffc000037c99c]
16 sbm_return_space_no_sub_ftx(0x120, 0xfffffc0003ec0d50, 0x1, 0xfffffc00050e2008, 0x10) ["../../../../src/kernel/msfs/bs/bs_sbm.c":974, 0xfffffc000037d348]
17 del_range(0x44b060, 0xfffffc00050e2008, 0x10, 0xfffffe0409dff578, 0xfffffc00050e3008) ["../../../../src/kernel/msfs/bs/bs_delete.c":3511, 0xfffffc000033f81c]
18 del_xtnt_array(0x1, 0xfffffc00050e2008, 0xfffffc00050e3538, 0xfffffc0003ec0d50, 0xfffffc0003ec0d50) ["../../../../src/kernel/msfs/bs/bs_delete.c":2815, 0xfffffc000033e964]
19 del_dealloc_stg(0xfffffc00000040d7, 0x1, 0xfffffc00000040cb, 0x40cb, 0xfffffc00050e3620) ["../../../../src/kernel/msfs/bs/bs_delete.c":2605, 0xfffffc000033e4a4]
20 bs_close_one(bfap = 0xfffffc0007982808, options = 1, parentFtxH = struct {
dmnP = 0x40cb00000001
hndl = 12296
level = 14
}) ["../../../../src/kernel/msfs/bs/bs_access.c":6532, 0xfffffc0000322dc8]
21 msfs_inactive(0xfffffc00004cbff4, 0xfffffc000574d200, 0x0, 0xfffffc000574d2d8, 0xfffffc0007982848) ["../../../../src/kernel/msfs/osf/msfs_misc.c":2806, 0xfffffc00003b31e0]
22 vrele(vp = 0xfffffc000574d200) ["../../../../src/kernel/vfs/vfs_subr.c":2754, 0xfffffc00004cbff0]
23 msfs_remove(ndp = 0xfffffe0409dffd10) ["../../../../src/kernel/msfs/osf/msfs_vnops.c":4116, 0xfffffc00003c30e8]
24 unlink(0xfffffc00050e2008, 0x6dff9a0, 0xfffffc000055a4c4, 0x0, 0xa) ["../../../../src/kernel/vfs/vfs_syscalls.c":4002, 0xfffffc00004d14f4]
25 syscall(0xc9, 0x0, 0x0, 0x3ff8018e150, 0x0) ["../../../../src/kernel/arch/alpha/syscall_trap.c":725, 0xfffffc000055a4c0]
26 _Xsyscall(0x8, 0x3ff800de428, 0x14000ab30, 0x140052fc0, 0x1ff) ["../../../../src/kernel/arch/alpha/locore.s":1864, 0xfffffc000055dcdc]
(dbx)
Regards,
Abhijit.
1) Stack trace of the core dump yields this (one liner):
> 0 thread_block() ["../../../../src/kernel/kern/sched_prim.c":3291, 0xfffffc00002e7af0]
(dbx)
2) We had a repeat ADFS panic after this crash and its stack trace goes:
11 domain_panic(dmnP = 0xfffffc00050e2008, format = (nil)) ["../../../../src/kernel/msfs/osf/msfs_io.c":1093, 0xfffffc00003ac21c]
12 bmtr_find(0xfffffc00050e2008, 0xfffffc000098c000, 0x0, 0xfffffe0409a90000, 0xfffffc0000346c64) ["../../../../src/kernel/msfs/bs/bs_bmt_util.c":1238, 0xfffffc000032cf5c]
13 set_recovery_failed(0xfffffc000037bf44, 0x736940, 0x4, 0x260, 0xfffffc0005d50188) ["../../../../src/kernel/msfs/bs/bs_domain.c":7013, 0xfffffc0000346c60]
14 CANT_CLEAR_TWICE(0x4, 0xffffc0, 0x4c17, 0x260, 0x260) ["../../../../src/kernel/msfs/bs/bs_sbm.c":515, 0xfffffc000037bf40]
15 dealloc_bits_page(0x5, 0xfffffc00022c8000, 0xfffffc00050e2008, 0x20010, 0xfffffc0000004c00) ["../../../../src/kernel/msfs/bs/bs_sbm.c":1045, 0xfffffc000037c99c]
16 sbm_return_space_no_sub_ftx(0x120, 0xfffffc0003ec0d50, 0x1, 0xfffffc00050e2008, 0x10) ["../../../../src/kernel/msfs/bs/bs_sbm.c":974, 0xfffffc000037d348]
17 del_range(0x44b060, 0xfffffc00050e2008, 0x10, 0xfffffe0409dff578, 0xfffffc00050e3008) ["../../../../src/kernel/msfs/bs/bs_delete.c":3511, 0xfffffc000033f81c]
18 del_xtnt_array(0x1, 0xfffffc00050e2008, 0xfffffc00050e3538, 0xfffffc0003ec0d50, 0xfffffc0003ec0d50) ["../../../../src/kernel/msfs/bs/bs_delete.c":2815, 0xfffffc000033e964]
19 del_dealloc_stg(0xfffffc00000040d7, 0x1, 0xfffffc00000040cb, 0x40cb, 0xfffffc00050e3620) ["../../../../src/kernel/msfs/bs/bs_delete.c":2605, 0xfffffc000033e4a4]
20 bs_close_one(bfap = 0xfffffc0007982808, options = 1, parentFtxH = struct {
dmnP = 0x40cb00000001
hndl = 12296
level = 14
}) ["../../../../src/kernel/msfs/bs/bs_access.c":6532, 0xfffffc0000322dc8]
21 msfs_inactive(0xfffffc00004cbff4, 0xfffffc000574d200, 0x0, 0xfffffc000574d2d8, 0xfffffc0007982848) ["../../../../src/kernel/msfs/osf/msfs_misc.c":2806, 0xfffffc00003b31e0]
22 vrele(vp = 0xfffffc000574d200) ["../../../../src/kernel/vfs/vfs_subr.c":2754, 0xfffffc00004cbff0]
23 msfs_remove(ndp = 0xfffffe0409dffd10) ["../../../../src/kernel/msfs/osf/msfs_vnops.c":4116, 0xfffffc00003c30e8]
24 unlink(0xfffffc00050e2008, 0x6dff9a0, 0xfffffc000055a4c4, 0x0, 0xa) ["../../../../src/kernel/vfs/vfs_syscalls.c":4002, 0xfffffc00004d14f4]
25 syscall(0xc9, 0x0, 0x0, 0x3ff8018e150, 0x0) ["../../../../src/kernel/arch/alpha/syscall_trap.c":725, 0xfffffc000055a4c0]
26 _Xsyscall(0x8, 0x3ff800de428, 0x14000ab30, 0x140052fc0, 0x1ff) ["../../../../src/kernel/arch/alpha/locore.s":1864, 0xfffffc000055dcdc]
(dbx)
Regards,
Abhijit.
Please Log in or Create an account to join the conversation.
- John_Manger
-
- Offline
- Moderator
-
Less
More
- Posts: 1
- Thank you received: 0
13 years 7 months ago #5204
by John_Manger
Replied by John_Manger on topic RE: 32-bit Only
After further testing and diagnosis, it appears that this issue only occurs under the 32-bit release of FreeAXP. The 64-bit version of FreeAXP and the commercial version 'Avanti' do not have the problem. Thus a 'workaround' is to run the emulator on a 64-bit Windows platform, which will also give improved performance in comparison to a 32-bit host.
John M
John M
Please Log in or Create an account to join the conversation.
Moderators: iamcamiel
Time to create page: 0.220 seconds