- Thank you received: 0
FreeAXP - Tru64 V5.1B - frequent crash
- John_Manger
- Offline
- Moderator
Less
More
13 years 5 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(, 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
Please Log in or Create an account to join the conversation.
- John_Manger
- Offline
- Moderator
Less
More
- Thank you received: 0
13 years 5 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 5 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 5 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 5 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
- Thank you received: 0
13 years 5 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.236 seconds