Disk reading

[neon]

Hey everyone,

I am trying to fix a bug in a program when its reading another program from disk. For the most part, it works without error. However, it only works if both programs are one of the first programs copied to disk. If they are not, the loading program crashes while trying to read (for an unknown reason) passed track 79:

Code: Select all

00073027725p[FDD  ] >>PANIC<< io: norm r/w parms out of range: sec#10h cyl#50h eot#00h head#00h

For debugging, I am having the loading program print out different variables for each sector read. However the last three, where it (sometimes...see first paragraph for details) fails at:

Code: Select all

fsys_fat::read curCluster: 799 physSector: 830
drive::rawread: sector 830 geometry: sectorsPerTrack 18 heads 2 totalSectors: 1422 tracks: 79
reading head 1 track 23 sector 3 on drive 0

fsys_fat::read curCluster: 1543 physSector: 1574
drive::rawread: sector 1574 geometry: sectorsPerTrack 18 heads 2 totalSectors: 1422 tracks: 79
reading head 1 track 43 sector 9 on drive 0

fsys_fat::read curCluster: 2864 physSector: 2895
drive::rawread: sector 2895 geometry: sectorsPerTrack 18 heads 2 totalSectors: 1422 tracks: 79
reading head 0 track 80 sector 16 on drive 0
<< crashes here >>

I grouped them so to make it easier to read. Each group is what the program prints out for each sector read.

The last sector is where it crashes at with the above error from bochs. curCluster is the interesting one though. This value has been taken from the FAT (FAT12 filesystem) so I wonder how it can be so high? It seems to be pointing to an invalid sector.

I am not quite sure what is going on here...How can the value read from the FAT be wrong? And only in certain cases (Please see first paragraph for details.)? What else can be causing something like this to happen?

Any help is greatly appreciated

[egos]

Are you sure that the FS structure on the disk (image) is correct? Cluster and sector numbers must be checked for hitting at available range by system software in any way. It allows to discover the error in FS structure. If this checking is produced in your code then you have an error in recalculation of the sector number from the cluster one or of the CHS number from the linear one.

[neon]

Are you sure that the FS structure on the disk (image) is correct?

I have to assume so -- I use VFD and Windows to copy the files over. No special programs used besides VFD.

Cluster and sector numbers must be checked for hitting at available range by system software in any way.

Very true--I will be updating the code later for that. For now I want to focus on the crash

If this checking is produced in your code then you have an error in recalculation of the cluster number from the sector one or of the CHS number from the linear one.

That is what I thought at first; however it does not explain why it only fails when the two program files are not the first copied to disk. i.e., If I copy the program files to disk first, followed by all other files, it works fine without error. Also, you can see the LBA to CHS results (and their initial values) from my original post (the programs output)...they all seem fine...

[bewing]

Seem fine? Your geometry says that the max tracks is 79, and the access that crashes says that it's trying to access track 80. Sounds like a bad CHS conversion to me!

[Troy Martin]

This a nifty formula for LBA -> CHS:

Code: Select all

CYL = LBA / (HPC * SPT)
HEAD = (LBA % (HPC * SPT)) / SPT
SECT = (LBA % (HPC * SPT)) % SPT + 1

It works, so make sure what you're using is similar to that.

[neon]

Thanks Troy Seems to be working now. Granted my filesystem code is saying my file is corrupt (which happens when the next FAT entry it reads is 0 while loading a file) but its getting into the loaded program now without any noticeable errors...Dont know whats wrong with the filesystem code though... *back to bug hunting*

*edit: Hm... After deleting all programs from disk again, and building all programs but krnldr (the problematic program of this thread) last, it works now without error... (filesystem code returns it loaded successfully)...

Oh well; if I run into any more problem again Ill post back here. Thanks again for everyone's help

[Troy Martin]

1) You're welcome.
2) Woot, I didn't know I could solve C-based OS dev problems!

EDIT: It's possible your code is breaking when it finds the root dir entry for krnldr, so if you have something in place to stop the unwanted execution of krnldr, check that code out.

[neon]

Sorry, not done yet. Problem appeared again:

Code: Select all

00219905648p[FDD  ] >>PANIC<< io: norm r/w parms out of range: sec#0ch cyl#51h eot#00h head#00h

Im going to see if I can post more info once I run the debug version again...

Here is the program output again. I separated it into groups again so that you can see each sector being read better... It crashes as soon as it reads from the 81st track.

Code: Select all

fsys_fat::read: curCluster 1545 physSector 1576 
drive::rawread: absSector 11 absHead 1 absCyl 43 geometry: sectorsPerTrack 18
 heads 2 totalSectors 1422 tracks 79 
disk::readsector: reading head 1 track 43 sector 11 on drive 0 to 0x73FC
 
fsys_fat::read: curCluster 2896 physSector 2927 
drive::rawread: absSector 12 absHead 0 absCyl 81 geometry: sectorsPerTrack 18
 heads 2 totalSectors 1422 tracks 79 
*** warning: attempt to read cylinder [81] exceeds disk cylinders [79] 
disk::readsector: reading head 0 track 81 sector 12 on drive 0

Does anyone know of any other ideas? absSector, absHead, and absCyl are set using Troys formula:

Code: Select all

int absCyl = sector / (geometry.heads * geometry.sectors);
int absHead= (sector % (geometry.heads * geometry.sectors)) / geometry.sectors;
int absSector = (sector % (geometry.heads * geometry.sectors)) % geometry.sectors + 1;

...Where sector is the LBA sector and geometry.sectors are the sectors per track.

Thanks for the suggestions so far

Seem fine? Your geometry says that the max tracks is 79, and the access that crashes says that it's trying to access track 80. Sounds like a bad CHS conversion to me!

The reason why I am not sure of that is the semi-randomness of thus bug

[Troy Martin]

Sorry, not done yet.

Ahh man, that sucks.

OT: Do you know what Windows looks for in a floppy's boot sector to detect the filesystem?

[thooot]

There are only 2844 clusters on a typical floppy drive but you're trying to read cluster 2896. So of course bochs is complaining that the read is out of range. It must be some problem with your FS code that figures out what cluster to read.

[neon]

There are only 2844 clusters on a typical floppy drive but you're trying to read cluster 2896. So of course bochs is complaining that the read is out of range. It must be some problem with your FS code that figures out what cluster to read.

Of course The problem is that the cluster I get to read is from the FAT itself I suspect it should be fine as it does work alot of times; only under certain circumstances it fails (please see first post for more info.)

(Then again, that's what I said about the LBA->CHS conversion code so Ill take a closer look...)

*edit: k, still not quite sure but instead of preloading the entire FAT table I decided to only reload the correct sector (got the idea from the Wiki code) and it seems to be working now. (Then again, I have said that before too )