Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
165 user(s) are online (110 user(s) are browsing Forums)

Members: 0
Guests: 165

more...

Headlines

Forum Index


Board index » All Posts (Calgor)




Re: Softhut, Toastscan and Mediator
Just popping in
Just popping in


@tlm

Yeah, I've been trying the website, and also their emails are bouncing back too for a week or so.

Go to top


Re: SFS problem with FastATA MK-III and 160GB drive
Just popping in
Just popping in


Just thought I would let you guys know that this problem has been solved by a beta driver from Elbox. The only change in configuration to my initial post was to use SFS 1.276 (to fix the SFS bug) and the new beta Elbox driver (to fix a bug possibly with interrupt mode - maybe it would have worked with that mode off?).

I can also use PIO5 mode which is slightly faster and get 8.5MB/s without interrupt mode.

Thanks for all the help and suggestions.

Go to top


Re: SFS problem with FastATA MK-III and 160GB drive
Just popping in
Just popping in


@Framiga

I did have to manually type in 0x53465300 in HDToolbox. Will set the caches etc when (if) it starts working.

@Jack

I tried different partition positions, and then it reported no errors, but after I copied a number of large files and rebooted, there went part of my RDB and my main boot partition!

So as shown earlier with sfsformat, writing to one partition writes to another!

Surely there is something I have missed or am doing wrong! Elbox have confirmed that they have it working and many of their customers have it working too. But I guess no one on EAB or amigans.net.

@Calgor

Try disabling MAPROM jumper and also completely reinstall drive.

Go to top


Re: SFS problem with FastATA MK-III and 160GB drive
Just popping in
Just popping in


@joerg

Thanks for the info.

I checked and sfsquery shows all of the partitions have end offset == start offset of next partition. HDToolBox also shows that there are no overlaps of start and end cylinders. Check4gb reports no problems, but it cannot check LBA48.

Mask is set to 0x7FFFFFFE, and MaxTransfer to 0x0001FE00.

Only sdh8 is partially over the 128GB boundary, so formatting sdh6 should not affect sdh7 and vice-versa????

Here are the results of sfsquery followed by:
1. sfscheck sdh6 (first bad block 5247 if format sdh7, first bad block 5248 if format sdh8)
2. sfsformat sdh6
3. sfscheck sdh7 (first bad block at end of partition) and sdh8 (first bad block at start of partition).

I would attach, but I don't know how. I will point Elbox to this thread.

4.SystemBack3:check4gb> sfsquery sdh6:
SFSquery information for sdh6: (SFS Version 1.276)
Start/end-offset : 0x00000001:f83f0000 - 0x0000000e:78538000 bytes
Device API : NSD (64-bit)
Bytes/block : 512 Total blocks : 104860224
Cache accesses : 102 Cache misses : 36 (35%)
Read-ahead cache : 8x 8192 bytes (Copyback)
Flush timeout : act. 20s - inact. 0.5s
Max Name Length : 107
DOS buffers : 80
SFS settings : [RECYCLED]
4.SystemBack3:check4gb> sfsquery sdh7:
SFSquery information for sdh7: (SFS Version 1.276)
Start/end-offset : 0x0000000e:78538000 - 0x0000001a:f8680000 bytes
Device API : NSD (64-bit)
Bytes/block : 512 Total blocks : 104860224
Cache accesses : 36 Cache misses : 14 (38%)
Read-ahead cache : 8x 8192 bytes (Copyback)
Flush timeout : act. 20s - inact. 0.5s
Max Name Length : 107
DOS buffers : 80
SFS settings : [RECYCLED]
4.SystemBack3:check4gb> sfsquery sdh8:
SFSquery information for sdh8: (SFS Version 1.276)
Start/end-offset : 0x0000001a:f8680000 - 0x00000025:1e3bc000 bytes
Device API : NSD (64-bit)
Bytes/block : 512 Total blocks : 85125600
Cache accesses : 51 Cache misses : 18 (35%)
Read-ahead cache : 8x 8192 bytes (Copyback)
Flush timeout : act. 20s - inact. 0.5s
Max Name Length : 107
DOS buffers : 80
SFS settings : [RECYCLED]

4.SystemBack3:check4gb> sfscheck sdh6: 400 lock
Partition start offset : 0x00000001:f83f0000 End offset : 0x0000000e:78538000
Surfaces : 24 Blocks/Track : 252
Bytes/Block : 512 Sectors/Block : 1
Total blocks : 104860224
Device interface : NSD (64-bit)

Checking RootBlocks
...okay
Checking AdminSpaceContainers at block 2
...okay
Checking NodeContainers at block 7
...okay
Checking ObjectContainers at block 3
...okay
Checking Bitmap at block 34 (26216 blocks, 4000 bits/bitmap)
Incorrect block type at block 5248. Expected was 0x42544d50 but it was 0x53465300.
...error in bitmap block at block 5248
...damaged
4.SystemBack3:check4gb> sfsformat drive sdh6: name Games
Press RETURN to begin formatting or CTRL-C to abort:
4.SystemBack3:check4gb> sfscheck sdh6: 400 lock
Partition start offset : 0x00000001:f83f0000 End offset : 0x0000000e:78538000
Surfaces : 24 Blocks/Track : 252
Bytes/Block : 512 Sectors/Block : 1
Total blocks : 104860224
Device interface : NSD (64-bit)

Checking RootBlocks
...okay
Checking AdminSpaceContainers at block 2
...okay
Checking NodeContainers at block 7
...okay
Checking ObjectContainers at block 3
...okay
Checking Bitmap at block 34 (26216 blocks, 4000 bits/bitmap)
...okay
4.SystemBack3:check4gb> sfscheck sdh7: 400 lock
Partition start offset : 0x0000000e:78538000 End offset : 0x0000001a:f8680000
Surfaces : 24 Blocks/Track : 252
Bytes/Block : 512 Sectors/Block : 1
Total blocks : 104860224
Device interface : NSD (64-bit)

Checking RootBlocks
Incorrect block type at block 104860223. Expected was 0x53465300 but it was 0x42544d50.
...damaged
4.SystemBack3:check4gb> sfscheck sdh8: 400 lock
Partition start offset : 0x0000001a:f8680000 End offset : 0x00000025:1e3bc000
Surfaces : 24 Blocks/Track : 252
Bytes/Block : 512 Sectors/Block : 1
Total blocks : 85125600
Device interface : NSD (64-bit)

Checking RootBlocks
Incorrect block type at block 0. Expected was 0x53465300 but it was 0x42544d50.
...damaged

Go to top


Re: SFS problem with FastATA MK-III and 160GB drive
Just popping in
Just popping in


@Joerg

Just my luck that 1.275 had that AmigaOS3.x formatting problem. With 1.276 i can get most partitions to work except for one (sdh6:) which seems to work, but SFSCheck reports it has an error.

For example I have 3 partitions with problems, the rest are fine - sdh6:, sdh7:, sdh8:

If I format with SFS in order sdh6 sdh7 sdh8, then sdh6 reports problem, but sdh7 and sdh8 are okay.

If I then format sdh6, then sfscheck on sdh6 reports no errors, but sdh7 and sdh8 then do have problems even though I didn't do anything to them!

I can repeat these steps and sfscheck always fails on the same blocks within each respective partition (middle of sdh6, rootblocks of sdh7 and sdh8).

At the moment, I am leaving sdh6 with the error and all partitions are remembered on reboot and "seem" to have no problems.

Are there any other tools other than sfscheck I can use to verify the partitions?

EDIT: Also, why is sfscheck expecting or finding block type 0x42544d50? Is that the sfs data block type identifier?

Go to top


Re: SFS problem with FastATA MK-III and 160GB drive
Just popping in
Just popping in


@joerg

Quote:
Sorry, I can't help, but you are not the only one with such problems with FastATA. Another user had the same problems, but unlike you not only with SFS, he had them with FFS as well, and no matter what he changed (HDs, cables, settings in the FastATA config, he even tried using PIO0) made it work.


Well, if Setpatch is loaded before the FastATA driver, then I can use up to 137GB without any problems. It also has the speed up. If Elbox can't fix the issue that is probably what I will end up doing.

Good to know I am not the only one with such problems. I wonder if anyone has got the hardware to work as advertised.

Go to top


SFS problem with FastATA MK-III and 160GB drive
Just popping in
Just popping in


Hi,

First of all thanks to the author for continually updating this great product, works very well!

I have a problem with SFSFormat and SFSCheck not working properly with FastATA controller.

My config is:
- A1200/030 with FastATA Mk-III
- 160GB IDE HD
- OS3.9BB2
- SFS 1.275
- FastATA drivers v8.4, NOSPLIT, RESIDENT, INTERRUPTS, PIO4
- FastATA drivers before SetPatch in startup-sequence
- NSDPatch disabled for scsi.device and 2nd.scsi.device

I have successfully used SFS with no problems on a 320GB hard drive connected to a CSPPC on a SCSI-IDE bridge, but the FastATA is causing grief.

SFSFormat reports no errors, but some of the partitions (up to 50GB in size) above 8GB have errors when using SFSCheck, and with these errors the partition remains uninitialized. Formatting one partition sometimes causes another to have errors:

Checking RootBlocks
Incorrect block type at block XXXXX. Expected was 0x53465300 but it was 0x42544d50.

Checking Bitmap at block YYYYY (....)
Incorrect block type at block ZZZZZ. Expected was 0x42544d50 but it was 0x53465300.

SFSQuery and SFSCheck report NSD 64bit is being used.

I have been at this for a little while with Elbox, but so far they haven't been able to get it to work.

FFS above 137GB with 300MB partition works fine and I have had no problems with it. SFS above 137GB with 300MB partition has same problems as above.

Thanks!

Go to top



TopTop




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project