Broken Directory/Disc Error with 9th July 17 Iyonix softload

Hi,

I updated my Iyonix beta Softload and HardDisc image from 8th May 17 Beta Softload to 9th July 17 one and after rebooting in to the Beta ROM I get a lots of broken directory errors.

Running Disknight 1.51 gives lots of files with invalid length messages.

My other drive states that the drive is not understood and asks if it needs formatting.

So rebooting back in to 5.22 gives no such errors and running Disknight on both discs gives no errors.

Looking at CVS I notice changes to Filecore3.74 & 5 so could these be causing the issue.

Both discs were formatted a long time ago by what ever version of HForm was on the drive.

I can’t save the error messages because the drives show up as in error on 5.23 9th July.

The one drive, the main one, is formatted as 112G and the other as 128G if this helps.

Try *Verify on both OS versions.
Contact Druck – the Author – to make sure you have the latest version of Disknight – and if he has any advice.

Curious, nothing unusual seen here with machines in daily use:

• Titanium with 64G SSD (ie. SATA) and 27736 directories
• Risc PC with 15GB Compact Flash card (ie. PATA) and 15394 directories
• Beagleboard xM with a USB boot stick (ie. SCSI)

One of the test drives is a 512B sectored 160GB of spinning rust, also fine.

Do you know if FileCore 3.74 (16-Jun-2017) or FileCore 3.75 (06-Jul-2017) is where the change happens? The two distinct areas were deliberately submitted with a few weeks in between so that all the people using the nightly builds would have chance to try each change in isolation (and the work was originally done back in April), but maybe you’re the only Iyonix user doing so?

The only difference I can think of is the Iyonix uses DMA for background transfers, so is unique in that sense, but that doesn’t tally with DiscKnight finding issues since it just grabs the raw sectors without using FileCore’s directory handling at all.

There’s an update (1.52) to DiscKnight in the works, but as you’ve not reformatted the drive that’s not needed in this instance.

Hi,

Do you know if FileCore 3.74 (16-Jun-2017) or FileCore 3.75 (06-Jul-2017) is where the change happens?

Well I haven’t got a version after the 8th May 17 apart from the 9th July 17 one so can’t test it but if someone can supply one I’d be happy to test it.

that doesn’t tally with DiscKnight finding issues since it just grabs the raw sectors without using FileCore’s directory handling at all.

Strange so could something in the boot sequence be causing the issue? I’ll try it with a clean boot choices.

Another thought is my Iyonix is feed to the monitor via a KVM so will check that as well.

Ok tried a clean boot.choices and still the same.

Checked my copy of Disknight and it says 1.51 from the menu but output file says 1.50.

Below are extracts from the logs.

To recap the Iyonix is ok on 5.22 and 5.23 Beta softload 8th May 17 but not on 9th July 17 beta softload.

Disc 4 shows the errors and starts to verify.

DiscKnight 1.50 (08-Apr-2013) [32bit] Serial no. xxxxxx

Arguments: -t -s ADFS 4

Boot Block – Defect List
Boot Block CRC is OK

Map 1 – Checksums
Zone Checks OK
Cross checks OK
Map 2 – Checksums
Zone Checks OK
Cross checks OK
Map – Disc Record
Map disc record matches boot record

Checking directory structure
……………..

• Directory $.!Boot.Choices120717 size invalid (&FFFFFFFF)

• Directory $.!Boot.Choices120717 directory name length invalid (is -1) – CLEARING

• File $.!Boot.Choices120717.Recovered SIN=&050FF302 conflicts over shared sector(s) 4-7,8-11,12-15

• Directory entry $.!Boot.Choices120717 does not match sub-directory size (is &00002000, should be &00000800)

• Directory $.!Boot.Disabled size invalid (&280296CA)

Disc5 – 128G one shows unformatted error and will not verify.

DiscKnight 1.50 (08-Apr-2013) [32bit] Serial no. xxxxxx

Arguments: -t -s ADFS 5

Boot Block – Defect List
Boot Block CRC is OK

Map 1 – Checksums

• Map 1, Zone 0 is Bad (zonecheck is &71, should be &FD)
• Map 1, Zone 1 is Bad (zonecheck is &87, should be &B0)
• Map 1, Zone 2 is Bad (zonecheck is &9E, should be &83)
• Map 1, Zone 3 is Bad (zonecheck is &3B, should be &F8)
• Map 1, Zone 4 is Bad (zonecheck is &3C, should be &D3)
• Map 1, Zone 5 is Bad (zonecheck is &68, should be &8C)
• Map 1, Zone 6 is Bad (zonecheck is &4E, should be &13)
• Map 1, Zone 7 is Bad (zonecheck is &97, should be &DA)

So will look at this when i can but off to work now.

FWIW there are no obvious problems reported by the OS or DiscKnight with today’s softload on my Iyonix (75GB HDD).

My copy of DiscKnight identifies itself as 1.51 (15-Dec-2013) when running, so it looks like you’ve definitely got a funny install there Doug. But if it verifies fine with the older ROMs then I’m not sure that would explain the failure with the newer one.

Random thought, but is Doug the only of us to have tried a system with two hard discs?

Random thought, but is Doug the only of us to have tried a system with two hard discs?

No, the above mentioned Titanium has the SSD and 160GB drives, I just forgot this morning I’d set the spindown delay and the drive was therefore silent, but it is actually plugged in. It has 9650 directories on it.

Doug: if you run DiscKnight with the ‘statistics’ option ticked that’ll print out the boot record too which might give some hints. Those &FFFFFFFF values are certainly fishy. You can capture the boot record from BASIC too:

DIM block% 4096
drive%=5
SYS"ADFS_SectorDiscOp",0,1,drive%<<29,block%,4096
OSCLI("SAVE dump " + STR$~block% + " +1000")

Random thought, but is Doug the only of us to have tried a system with two hard discs?

I have an Iyonix with two hard drives. It is all good with the flashed OS5.22. However attempting to softload O5.23 (12-Jul-17) just stalls the boot and deposits itself at the command prompt. Drive 4 is reporting “Error when reading ADFS::4.$ – Disc not understood – has it been formatted?”. Drive 5 accesses OK. I have not tried DiscKnight.

FWIW, just ran last nights soft load on Iyonix booting from an 80GB :4 with a 40GB :5 and all seems fine in use after a quick bit of testing. (I don’t have DiscKnight)

I have an Iyonix with two hard drives.

Moving on, it seems I had an Iyonix with two drives, its networking went awry and is now no longer working. Power supply??? My previous post could therefore be unreliable.

went awry and is now no longer working.

This is what happens when you leave powerful computers around for too long and they become sentient. They take a look at the world around them (it was the outside world interface that went first, note) and then they choose the mathematically logical solution…

networking went awry

Ah, I noticed I had no network when I booted to 5.23, didn’t think much of it as I’d not updated !Boot. I now see going back to 5.22 no network. Hmm. I see on start up it fails on finding !Boot.choices.boot.predesk.Monitor, so, probably not the correct fix, but the fastest before I go to work, I just created an empty obey file called Monitor in predesk, re-booted and now network gets correctly set up on 5.22 and 5.23 softloaded. So, maybe just check there are no errors on boot that might be stopping the network set up.

Ok so I’ve got a copy of the boot sector for Drive 4 which is formatted to 112G when running 5.22 so what do I do with it now?

I’ve also tried to get a new update of DiscKnight but there seems an issue with the website. I did dig out an old version , 1.47, and used my previous 1.51 upgrade on that and again it shows 1.51 (15-Dec-2013) from the iconbar menu but the output file shows 1.50 (08-Apr-2013).

I am running a full DiscKnight check on the drive but I did that last night and also asked it to repair and it came back with zero repairs.

I notice Will who have stated the upgrade works has drives less than 100G could this be a factor on the Iyonix?

To rule out anything on my system I might install a totally clean boot/disc image, hiding the old stuff in a directory called old, and see what that does with the new upgrade.

Failing that it would be good to get a softload with 3.74 in it just to try and narrow things down.

Ok put everything in an old directory and put a clean boot on, rebooted and had some screen issues so copied over my old monitor file and set that up in 5.22 and then booted in to 5.23 9th July and I got no broken directory issues on drive 4 but drive 5 showing as unformatted.

Run Diskight on the drive 4 and lots of errors with fiels in the “old” directory and it says 2345 files found but not referenced including ones in a directory lost & found which is not on the hard drive according to filer.

So boot back to 5.22 and run diskight again and it says all is OK.

Boot in to 5.23 8th May 17 and everything is fine including a scan via Disknight.

Anyway off to work now but will have more time on Friday/Weekend to look at this.

Hmm. I see on start up it fails on finding !Boot.choices.boot.predesk.Monitor, so, probably not the correct fix, but the fastest before I go to work, I just created an empty obey file called Monitor in predesk, re-booted and now network gets correctly set up on 5.22 and 5.23 softloaded. So, maybe just check there are no errors on boot that might be stopping the network set up.

Many thanks, that was the issue here too. The Iyonix is now booting fully on both OS5.22 and OS5.23.

This also means that my early post on the failure of one drive in OS5.23 is valid after all.

Both drives are 120GB which DiscKnight 1.50 show as good under OS5.22, with OS5.23 Drive 5 is still good but Drive 4 shows multiple failures.

In a fit of enthusiasm I reformatted Drive 4 with the new !HForm 2.74 under OS5.23 and it now works with OS5.23, it just does not work with OS5.22!

Failing that it would be good to get a softload with 3.74 in it just to try and narrow things down.

I’ve put such a thing here for anyone able to try, though ideally more people would run the nightly builds so there’s a chance of spotting issues without having to manually wind back.

In a fit of enthusiasm I reformatted Drive 4 with the new !HForm 2.74 under OS5.23 and it now works with OS5.23, it just does not work with OS5.22!

That sounds right. HForm will have spotted that the newer FileCore was present and chosen a smaller/more efficient file granularity, which OS 5.22 doesn’t know about. You can manually force it to use a larger granularity (it’s step 9 of 10 in the User Guide chapter on HForm), say it picked an LFAU of 8192 then keep doubling that number until it fits 2 ¹⁹ fragments).

This is the same situation as for long filenames, if a newer FileCore is present long filenames are selected by default unless manually overridden. Formatting on a long filenames OS then reverting to a short filenames OS leaves you not being able to mount the drive on the older one.

Did you happen to grab the boot block before the fit of enthusiasm kicked in?

Did you happen to grab the boot block before the fit of enthusiasm kicked in?

Of course not.

A take 2 then, hopefully valid.

Drive 4 was reformatted with the OS5.22 !HForm 2.70, it is now good again on OS5.22.

It does fail on the FileCore 3.74 test ROM.

The boot block dump is here

HTH.

Hi Rob,

I have sent you boot block dumps when running 5.22 and also 5.23 9th July 16.

I have also tried the 3.74 ROM version and it gives the same issue as the 9th July ROM namely broken directories and errors from Disknight.

On the subject of DiscKnight I have now got another 1.51 version and that correctly reports itself as 1.51 when running and not 1.50.

The boot block dump is here

and

I have sent you boot block dumps when running 5.22 and also 5.23 9th July 16.

having written all those out to a disc, they all look entirely normal, then using HForm (which reads in the parameters) the disc formatted and mounted fine here. So that’s an investigative dead end.

Looks like we’ll have to do this the hard way, so here are 5 ROMs which apply the 5 changes from 3.73 to 3.74. Hopefully one of those will show where to look.

Looks like we’ll have to do this the hard way, so here are 5 ROMs which apply the 5 changes from 3.73 to 3.74.

The issue appears with ROM d. a, b and c all read drive 4, ROM d didn’t.

Is that enough info?

Rob,

Ok will look at the 5 ROM’s either later today or over the weekend.

In the meantime I have reformted the Drive 5 , which came up as unformatted with 5.23 9th July, and it nows says 149GB rather than 128GB and when I boot in to 5.23 9th July it now is understood.

So this begs the question in that I must of formatted it down to 128GB in the past to get round the Iyonix DMA limit issues and is this the root of the problem as the other drive is formatted less than it’s capacity as well.

One final point is I can’t at this stage remember how to format it down to 128GB again to test if it then fails so any pointers would be gratefully recieved.

OK tried the 5 ROM’s and a,b & c boot up OK without broken directory messages on Drive 4 but d & e fail and report broken directory.

The issue appears with ROM d. a, b and c all read drive 4, ROM d didn’t [and] OK tried the 5 ROM’s and a,b & c boot up OK without broken directory messages on Drive 4 but d & e fail and report broken directory.

Well I wasn’t expecting that, step (d) was the change to reading the defect list with MiscOp_Mount. Old ADFS needs to get some of the hardware specific parameters from the end of the boot block and assumes the only time FileCore uses this entry point it will ask for disc address &C00 and snoops the block read before returning to FileCore.

FileCore now reads this aligned to 4k (because it doesn’t know the sector size prior to mounting, so must align to the highest supported sector size). I suspect that that results in the LBA flag ending up clear, but the drives that don’t mount are new enough that they don’t work in CHS mode any more.

So I’ve changed ADFS to calculate the buffer offset properly, hopefully that’ll restore normality.

A quick survey of the other FileCore clients:

• RAMFS and SDFS don’t use the boot block in MiscOp_Mount.
• SCSIFS does it properly, reads the boot block of its own accord, then fulfils FileCore’s request once the parameters are recovered.
• New ADFS doesn’t use the boot block in MiscOp_Mount because all SATA drives support LBA, though when a PATA backend is written it’ll need to hook out the flags like old ADFS.

One final point is I can’t at this stage remember how to format it down to 128GB again to test if it then fails so any pointers would be gratefully recieved.

You just need to reduce the product of cylinders x heads x sectors to hit the target you want. Most commonly the cylinders is the one to twiddle. For the boot block dump you emailed to me the values were 266305/16/63 which you plug into HForm. The LFAU was 32768 (though it could have been 16384 even prior to FileCore 3.75, looks like a mistake when it was originally formatted).

So I’ve changed ADFS to calculate the buffer offset properly, hopefully that’ll restore normality.

It does, thanks.

Hi Rob

I have tried the updated ROM and it will not boot.

I go in to the softload sequence and it then stalls at the following line:

foundpage=128512 foundphysicaladdr=df600000.

I tried a second download just in case and still the same.

Update – OK after at least 10 attempts to reboot or power on/select softload it actually went through the start up and I got to the desktop. Now in the desktop I can access the directories/files without any broken directory issues but I got a wierd screen breakup and Disknight ran and then paused and the screen cleared after 2 minutes. The screen breakup started when the disc was being accessed. I wonder if my PSU is starting to fail as this is the first time I have left it on for nearly all day for at least a year or so and I had just copied 105GB over to the newly formated drive 5 an hour or so ago. I may reformat drive 4 on Saturday just incase there are other issues in play as well.

Update2 – Weird screen breakup came back and then stopped again after 2minutes. I am still running Disknight, which has found no errors yet, but it’s getting late so may come back to this on Saturday. I also now remember an issue with the display that was similar a couple of years ago and that disappeared and it wasn’t exactly like this from memory.

Update3 – The screen issue and hang is now happening when trying to go in to 5.22 now as well so looks like I have another issue. Anyway one to look at in the morning now