| SAGA SD Driver News | page 1 2 3
|
|---|
|
|---|
| | 
Martin Soerensen
Posts 232
11 May 2016 05:48
| I seem to be getting some write errors with PFS3 on the 32GB Sandisk card.
This is the kind of error I see:
EXTERNAL LINK
Either error 30 or error 29, although I don't know what the codes mean.
The error doesn't appear at first, then it starts to appear once in a while but eventually it happens constantly when I copy stuff to the partition. Clicking 'retry' will eventually make it continue and it seems that data is written just fine as I have not noticed any corruption on read (I was writing a lot of archives amongst other things, so it would be noticed on extraction).
Rebooting the Amiga causes the error message to go away again, but if I write some files to the partition, they eventually start to appear again.
I will try to set up some more formal tests to see if I can figure out how to trigger this.I tried to run PFSDoctor on the partition, but it seems it cannot access >4GB so I was not able to use it. Looks like a problem with PFSDoctor as PFS3AIO should check for that before it mounts a partition.
| |
| | 
Chris Marsden
Posts 36
11 May 2016 08:09
| Simo Koivukoski wrote:
|
Chris Marsden wrote:
|
Any more news on compatibility, which cards work so far? The 32Gb card i am having problems with is a SanDisk 32Gb microSDHC UHS-1.
EXTERNAL LINK
What make/model is the 128Gb tested above?
|
128GB card is Samsung.
Let's test your SanDisk with the FAT32 format, because fat95 device has partition geometry autosense.
Format your SD card on PC to FAT32 fileformat in normal way. Do not use any Amiga tools like HDToolBox, SDMount or Giggledisk.
Make sure you have:
DEVS:sagasd.devive (v0.9 05/05/2016)
L:fat95 (v3.18 03/01/2013)
DEVS:DOSDrivers/SD0
DEVS:DOSDrivers/SD0.info
Make sure that your DEVS:DOSDrivers/SD0 mountlist uses partition geometry autosense, its contents must be like this:
FileSystem = l:fat95
Unit = 0
Flags = 0
LowCyl = 0
HighCyl = 0
Surfaces = 1
BlocksPerTrack = 1
BlockSize = 512
Buffers = 20
BufMemType = 1
BootPri = 0
Stacksize = 4096
Priority = 5
GlobVec = -1
DosType = 0x46415401
Device = sagasd.device
|
thanks Simo - my 32Gb SanDisk likes FAT!Martin, maybe try formatting to FAT as SanDisk appears to be problematic.
| |
| |
Martin Soerensen
Posts 232
11 May 2016 12:30
| Chris Marsden wrote:
| Martin, maybe try formatting to FAT as SanDisk appears to be problematic.
|
I could do that, but I don't see how the file system should matter much in this regard. Perhaps FAT just has fewer error checks so it still corrupts data, but never reports about it? The root cause should be fixed, whereever it may be and not just circumvented.
I am not relying on the SD card yet, so it is mainly used for testing, so I will stick with PFS3 for now and do some more tests.
Also, is FAT32 optimal for an Amiga performance-wise? I think it would be missing some flags that might be used, amongst other things.Edit: Also, 128GB cards are old news, now they have a 256GB version:
EXTERNAL LINK
Anybody buy it to test the compatibility? :)
| |
| | 
Nixus Minimax
Posts 416
11 May 2016 12:51
| Martin Soerensen wrote:
| | I could do that, but I don't see how the file system should matter much in this regard. |
SDcards are often optimised for FAT, i.e. they expect you to use FAT and use specific access patterns and do internal housekeeping that will work best with FAT.
| |
| |
Martin Soerensen
Posts 232
11 May 2016 12:57
| Nixus Minimax wrote:
| SDcards are often optimised for FAT, i.e. they expect you to use FAT and use specific access patterns and do internal housekeeping that will work best with FAT.
|
That sounds plausible, however should that also not be the same for CF cards? I have not seen this issue when using PFS3 on CF cards.
| |
| | 
Simo Koivukoski
(Apollo Team Member)
Posts 601
11 May 2016 18:12
| Martin Soerensen wrote:
|
I seem to be getting some write errors with PFS3 on the 32GB Sandisk card.
This is the kind of error I see:
EXTERNAL LINK
Either error 30 or error 29, although I don't know what the codes mean.
I tried to run PFSDoctor on the partition, but it seems it cannot access >4GB so I was not able to use it. Looks like a problem with PFSDoctor as PFS3AIO should check for that before it mounts a partition.
|
Write error <number> on block <number>
The device has an error, a block could not be accessed. This indicates
that the device has errors. Make a backup of the partition and
reformat the device. If this doesn't help, consider replacing the
device.
PFSDoctor works just fine. I cannot reproduce this.
EXTERNAL LINK
I have this SanDisk 32GB card and it's formatted with these settings:
EXTERNAL LINK
Cylinders * Heads * Blocks per Track * 512 = size of the disk in bytes
61839 * 16 * 63 * 512 = 31914860544 B = 29.72303 GB (62333712 blocks)
PDS\3 = 0x50445303 (PFS3ds ver18.0)
C:GiggleDisk_AOS68K DEVICE sagasd.device UNIT 0 to DEVS:DOSDrivers/
C:PFSFormat DEVICE SD0: NAME SanDisk32GB QUICK FNSIZE 107 NOICONS
Chris Marsden wrote:
| | thanks Simo - my 32Gb SanDisk likes FAT! |
I think your geometry settings were wrong and FAT95 autosense uses automatically correct ones.
Martin Soerensen wrote:
| | Also, is FAT32 optimal for an Amiga performance-wise? I think it would be missing some flags that might be used, amongst other things. |
Even ISO-9660 CD-ROM filing system do not represent the original Amiga file comments and attribute bits. FAT32 filesystem works as expected.
Nixus Minimax wrote:
| | SDcards are often optimised for FAT, i.e. they expect you to use FAT and use specific access patterns and do internal housekeeping that will work best with FAT. |
It has nothing to do with FAT filesystem.
"Writing to flash memory is slow because data to full pages can not be written before erasing a block of pages. Writing is then possible to the newly erased pages. So in the worst case a need to write one bit of information can trigger the erasure of several pages of flash memory. For this reason it is very preferable to align the file system blocks on a flash device with the erase block size to avoid unnecessary write amplification. SD cards in a native SD card reader can report their preferred erase block size directly in Linux. Just type:
cat /sys/block/mmcblk0/device/preferred_erase_size
to see the erase block size of your SD card. A smaller erase block size is of course better, because the problem with write amplification is smaller then.
16 GB SanDisk Extreme Pro 45 MB/s UHS 1 card reports an erase block size of 4 MB.
8 GB Transcend SDHC Class 6 150x card reports an erase block size of 4 MB.
2 GB Transcend SD 150x card reports an erase block size of 8 kB."
| |
| |
Chris Marsden
Posts 36
13 May 2016 07:16
| Simo, how do you work out cylinders/heads/blocks per track etc for a sd card? If the 'read configuration' of hdtooolbox gets it wrong how do i work out the correct settings?
| |
| |
Simo Koivukoski
(Apollo Team Member)
Posts 601
16 May 2016 19:03
| Chris Marsden wrote:
|
Simo, how do you work out cylinders/heads/blocks per track etc for a sd card? If the 'read configuration' of hdtooolbox gets it wrong how do i work out the correct settings?
|
You can check your cards Max Logical block addressing on Amiga with the C:SDDiag. Or on PC with the WinUAE. I think you are safe when you use 16×63 style legacy sectors.
My 32GB SanDisk shows 62,333,952 Logical blocks:62,333,952 blocks / 16 Heads / 63 Blocks per Track = 61839 Cylinders So I will fill:
61839 Cylinders
16 Heads
63 Blocks per Track
1008 Blocks per Cylinder (16 Heads * 63 Blocks per Track)
If your Logical block addressing is set too high, with SFS or PFS3 AIO the last partition will not mount (with one partition nothing will not mount).
| |
| |
Simo Koivukoski
(Apollo Team Member)
Posts 601
17 May 2016 07:58
| In some circumstances driver did not return the right value for the capacity in blocks, it's updated now:
screen grab : EXTERNAL LINK
sagasd.device 0.9 (05/16/2016), 14348 bytes [ CRC32 : 48F6FCFF ]
| |
| |
Chris Marsden
Posts 36
17 May 2016 22:29
| Thanks for the explanation, time to digest!
| |
| |
Chris Marsden
Posts 36
20 May 2016 07:40
| Simo Koivukoski wrote:
|
In some circumstances driver did not return the right value for the capacity in blocks, it's updated now:
screen grab : EXTERNAL LINK
sagasd.device 0.9 (05/16/2016), 14348 bytes [ CRC32 : 48F6FCFF ]
|
This update resolved my issues with the 32Gb SanDisk - it now partitions (x4 7Gb parts) with pfs3_aio and more importantly the last partition formats and doesnt return NDOS after reboot.
NOTE: one word of caution when installing this update check that the sagasd.device has in fact been updated. do a 'version devs:sagasd.device full' from the cli. it should be dated the 16th May (not the 5th). if not updated properly unmount the sd card and reinstall or just manually copy sagasd.device from the lha archive to devs.
| |
| |
Martin Soerensen
Posts 232
20 May 2016 09:56
| Manually changing the geometry settings seems to have fixed the problems for me, at least for the time being. The updated sagasd.device 0.9c detected some other values than the previous, however they worked even worse. With the new values, it was impossible to even format the partitions without getting write errors. sagasd.device from 16th May detects these values:
Cylinders: 39552
Heads: 6
Blocks per Track: 256
Blocks per Cylinder: 1536 Perhaps PFS3 has some incompatibility with one or more of these values? SDDiag reports 60751872 blocks and 512 block size.
I then set these values manually:
Cylinders: 60269
Heads: 16
Blocks per Cylinder: 1008 It totals to 60751152 blocks, so a bit less than the full drive.
Whether it works 100% time will tell, but so far it looks good, so I think PFS3 works better with more regular geometries.
| |
| |
Simo Koivukoski
(Apollo Team Member)
Posts 601
20 May 2016 17:52
| Martin Soerensen wrote:
| | The updated sagasd.device 0.9c detected some other values than the previous, however they worked even worse. With the new values, it was impossible to even format the partitions without getting write errors. |
Can you reproduce this and copy your SDDiag and mountfile data into EXTERNAL LINK
When you are done, please visit apollo irc channel, and share your link with the team members, tnx.
| |
| |
Martin Soerensen
Posts 232
20 May 2016 21:50
| Here's the output from sddiag along with mountlists for two partitions:
EXTERNAL LINK
The geometry here was read automatically in HDToolBox using sagasd.device from May 16th.
| |
| |
Martin Soerensen
Posts 232
21 May 2016 15:08
| Just a little update. I reconfigured the SD card to 16/63 geometry and did further tests. After writing for an hour, I again got the write error, so using 16/63 does not fix it. It took a lot longer before I saw the error, but it could just be chance rather than having anything to do with the geometry. Once I see one write error, it is very likely though that more will start appearing, usually after a few secs or a min. After a while, they get more and more common until you get a new one immediately. Rebooting often causes the frequency to go down again.
| |
| |
Simo Koivukoski
(Apollo Team Member)
Posts 601
22 May 2016 05:21
| Thanks for the excellent feedback, we are able to reproduce the problem. e. does "APoke ADDRESS=DE000C SIZE=1 VALUE=0F" remove the problem? (you can find apoke from aminet)
| |
| |
Chris Marsden
Posts 36
27 May 2016 11:29
| Simo Koivukoski wrote:
|
In some circumstances driver did not return the right value for the capacity in blocks, it's updated now:
screen grab : EXTERNAL LINK
sagasd.device 0.9 (05/16/2016), 14348 bytes [ CRC32 : 48F6FCFF ]
|
wanted to report:
today after the installation and configuring of roadshow i notices my last SD3 partition went NDOS again.
its been stable since the last sagasd update and i have not actually used it but it has been mounted. its reformatted now and seems fine.
| |
| |
Martin Soerensen
Posts 232
28 May 2016 10:01
| Simo Koivukoski wrote:
| e. does "APoke ADDRESS=DE000C SIZE=1 VALUE=0F" remove the problem? (you can find apoke from aminet)
|
Sorry, I missed this post so haven't tried it until now. And no, it does not remove the problem. I poked the value and then mounted the volumes and when I tried to delete a file, I immediately got the write error message. Does it make a difference when the value is poked (pre/post mount)?
| |
| |
Simo Koivukoski
(Apollo Team Member)
Posts 601
28 May 2016 10:57
| Yes, poke affect only after of the mounting.
| |
| |
Martin Soerensen
Posts 232
28 May 2016 11:19
| Ok, I am testing that now. Have been copying files for ~45 mins with no errors so far. Will report back after more thorough testing.
| |
|
The team will post updates and news about our project here