said:
>
> This is IDE? Correct?
Yes it is.
> Try disabling busmastering and see it that
> bypasses the trap. There's heavy disk activity at shutdown and the the
> hardware is not perfect, you can get traps.
>
> Another test is to reduce the shutdown processing by manually shutting
> down as much as possible. Use
>
> SCKILLFEATUREENABLED=ON
>
> in config.sys and use Ctrl-Click on the WarpCenter task list icon to
> shutdown all non-essential processes. Let me know what the results are.
I didn't quite perform these suggestions since I started down an alternative
debugging path but I am kinda skeptical that these would have made a difference
since a) the machine had worked fine beforehand (I don't think it's process
related since just bootup and shutdown is enough to cause the trap) and b) the
trap is late enough in the shutdown process that I think most of the processes
have already stopped (but not so late that the disk dirty flag is cleared).
However, this alternative debugging path may be quite illuminating (but even
stranger than you might expect ... read on).
After trying all the non-invasive debug procedures I could think of, I broke
down and opened the machine up. After reseating stuff and other fiddling with
no behavior change, I attached a second hard drive as a slave to the original.
Call the original drive disk 1 and the added, temporary drive disk two. After
partitioning and formatting disk 2, I did the xcopy /h/o/t/s/e/r/v routine from
1 to 2 after booting to floppy. To make sure that everything went as expected,
I disconnected drive 1, reset drive 2 as master and rebooted (adjusting the BIOS
in the process). Booting went perfectly and, even better, *NO TRAP AT
SHUTDOWN*. Brilliant, I thought. Simply reformat disk1 and reverse the xcopy
process and I should be good to go. So, after reconnecting disk 1 as master and
disk 2 as slave and booting to floppy, I execute a FORMAT C: /FS:HPFS /L to make
sure disk integrity is completely checked. I xcopy back to 1 from 2, disconnect
2 to preserve one known good copy of the system and reboot. Although booting is
fine, it again TRAPS AT SHUTDOWN! This is pretty screwy but fairly
illuminating. It does seem to suggest that the rest of the hardware is okay.
Maybe the drive is becoming flaky? I don't know - it seems to behave well
otherwise.
At this point, one has to consider just replacing drive 1 with drive 2 and
leaving it at that. Although I will consider that, I'd like to leave it as a
last resort since it was supposed to be a temporary solution and I had other
plans for that drive. Is there nothing else I can try? Should I delete the
partition on drive 1, repartition and try again or is this a waste of time? I
know FDISK /MBR in DOS' FDISK resets the master boot record - will it do it with
OS/2's? Would this have any value? Finally, would you say that the drive is
faulty, maybe got a virus or is it just the combination of the drive/motherboard
or some other drive interaction that is causing the problem?
This should pretty much close it for me, though. I'll try a few more ideas
that may come from this thread but I've got other things to do so I'll go for
the fail safe if nothing else works. Thanks for all your suggestions and the
help I've received with this problem.
> Steven
-Rocky
=====================================================
To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-help".
For problems, contact the list owner at
"rollin@scoug.com".
=====================================================
Return to [ 15 |
June |
2002 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International
Business Machines Corporation.
All other trademarks remain the property of their respective owners.
