[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] 1.16.0 still no go



Thanks, Mark

Top posting and wasting bandwidth.

Knowing what the problem isn't is a big step forward.

HDDriver is the latest, cables are short, drive seems to work some of the time, not like the last 8 I have had, have enough TT parts to do serious swapping, the Sparemint files are fine, 1.16.0 runs on a TT, so I either have a scsi problem, irreplaceable bad memory (16 meg 30-pin SIMM) or a drive with failing bearings. Most likely the drive. Darn. First good one, for a while, I have ever had. That is probably the only reason RWABS would fail. Maybe that is where my tcp_sendsegment bug lives, too.

The hardest part here is finding a new SCSI drive of less than 29 gig size. If you have to format them, it takes most of a day. Euros in an envelope to Atari Fachmarket is probably what I will do.

I do find freemint to be very useful, and intend to get it working.

Again, thanks for the info. Now I know at least a couple of things to investigate, and a couple of things that are OK.

Jim


On Sat, 7 Aug 2004, Mark Duckworth wrote:

On Sat, 2004-08-07 at 00:14, Jim DeClercq wrote:
Now that I had my drive back, comes the problem of putting the files back
on it, using, of course, mint with single tos, to load the files needed
for multitasking.

I had made CD backups of my mint drive, because while I have worn out two
data tapes, at about 50USD, I have never worn out a CD. But, that did not
work. If one writes to a mint drive often enough, one will eventually see
a screen warning that a bit has already been cleared for something, which
means that the file system is now dead, and you can start over. That is a
small bug in Mint that badly needs squashing.


You mean RWABS Fail?  I've never seen such a message.  I certainly write
to my ext2 drives a lot.  I have 1 8 gig SCSI HDD that backs up all my
other filesystems, both vfat and ext2.

I did have a tape backup, and that worked, and I am back in business
again.


That's definitely good.

The fact that CDs could not be used for backup was a disappointment to me,
since those can be had for 29 cents US, and do not wear out.


Hrmm.  Again this is something I've not heard of.  I would think Anodyne
software would be more vocal about a problem like this.

This sort of thing, either bugs in MiNT, or merely that I run some
programs that get stuck, such as Gemvelope, are why I am not very
enthusiastic about compiling things. If I start, and I have started,
something will go wrong and I will lose what I started.


Understandable.  Problems of this nature are why I am only getting into
development now.  When I first started out on Atari I routinely lost all
of my data.

So, will somebody please look at those kernel files on the Sparemint site?
I think there are some problems there.

Well, I don't know much about everything else, but those files on the
sparemint site are obviously not corrupt.  If you drive got so messed up
that nothing would touch it except install.prg from ICD then it's likely
you have a legitimately crashed HDD... it happens.  See, even if the OS
completely screwed up, the defect list a completely hardware (scsi
protocol) driven thing from my understanding that the OS has NOTHING to
do with.  In other words if you have scsi verify on, the os will try to
write say a block of data to x area.  It writes the data and read
verifies it.  If the data comes back wrong, it internally adds this
block to the defect list and uses some spare blocks at the end of the
disk instead.  The drive handles this internally, but I think this is
all controllable during a format process.

I could be really wrong here, but this sounds like a serious hardware
issue.  I've had problems like this with my old Mega ST2, which BTW
ended up in the garbage can.  The only thing left from it is the ICD
Link2, both scsi hdd and computer are gone because they did crap like
you described every other week.  Now I have 2 TT's, a Falcon, 2 Mega
STe's and a 1040 and I don't have those probs.

The very first thing I'd do here is buy a very low mileage scsi hard
drive and I would throw your ram into a stress tester and make sure it's
not broken.  I mean, the way TOS is, it makes sense that it's likely
that the exact same portion of memory would be used for your disk cache
on every boot.  Well what if that portion of your ram happens to be
bad.  Try swapping simms around to see if things go differently.

Then I would also disconnect ALL the other scsi devices.  I would also
buy a brand new scsi cable.  I know this is all pricey but I'd hedge my
bets on that if you did all of it and you went over everything with a
fine tooth comb, you'd quickly find that freemint isn't the problem.

It's unfortunate but you've got some hardware probs there.

I vaguely remember you saying you run a TT?  Well I have 2 TT's both
running Freemint 1.16.0, one of them with a Nova Mach 64.  It works and
works pretty well, so there's a solvable problem somewhere that doesn't
involve code.

Now I'm sure I could probably go through archives and find this out, but
what HD Driver software do you use?  You should be using Hd-driver 7.8
or above, if you have a CT60 falcon, 8.13, no question.  (Some users
have had to revert to less than HD-Driver 8 for strange reasons on a
CT60.).

Thanks,
Mark