Re (2): [Oberon] Trap in storing a FAT file.

[eas-lab at absamail.co.za]

Chris,

cg> ... the WHILE terminating condition is expected to occur
 before the linked-list finds it's tail at c.next = NIL.
 
cg> I'm guessing that it does NOT !
I'm guessing that your machine is testing (which was not done before) 
that  c.next = NIL occurs before the WHILE terminating condition is 
satisfied.

> Do you see a reason why this would happen
> only on one specific machine and only in 
> half of the store attempts?  These 
> circumstances suggest a low level hardware
> problem---ATADisks.Mod for example.

Well, without looking at the code again, because I
don't have the trap info, I remember that the 
'while loop' had a 2 or 3 variable exit condition.
Quiet complex.
Remember every IDE is unique, when in use,
I.e. which sectors are used.
And each run will use a different set of sectors.
There's no way that combinations can be tested.
Is your partition getting towards filled up ?

re. ATADisks.Mod , my experience of the trap
facility is that it is reliable in showing the last
few procedures executed before the trap.
And it show no ATADisks.Mod problem.

Are you using 'StandAlone' i.e. non-DOSbased/Linuxbased ?
Can you try onother partion, or other IDE ?
At one stage I used to swap my 5 IDEs between the
2 machines is if they were floppies - it's no big deal.
I always boot via floppy - DOS, Linux, n-o.


as 
cg> Compiler.Compile *\f

Will have to try that during the weekend.
=============
*** later:
cg> I'm guessing that your machine is testing (which was not done before) 
that  c.next = NIL occurs before the WHILE terminating condition is 
satisfied.

cg> Compiler.Compile *\f

> Sure enough, the exection error is in this statement in 
> OFSFATVolumes.AssignDirectoryEntry.
> 
> WHILE (c.type # dcSentinel) & 
> ((c.type # dcFree) OR (c.entry.dirInfo.num < direntry.dirInfo.num)) 
> DO p := c; c := c.next END;
> 
> Seems I need to make a comprehensive study of installable file 
> systems and FAT.  For now, this is the Kernel.Log after turning 
> on Trace and Detail in the module (and recompiling and 
> reloading of course).  OFSFATVolumes should have written a 
> raft of information which isn't there.  Enough for now.

I'm guessing that you have just got an unlucky combination
that tests the trap condition.   Or many files ?
I don't use the FAT facility very much.
Without making a deep study of the FAT structure it
could be a big job to fix it.

If we had a bigger user-base and better organisation, your 
much appreciated task of locating the fault would be done,
and the team that specialises in FAT would just quickly fix it.
That's how linux works.


> TRAP -14 PC Native 05.01.2003
> CS:=0000001B DS:=00000020 ES:=00000020 SS:=00000023 CR0=80040031
> FPS=00000000
> EIP=0002B243 ESI=00377748 EDI=003E3324 ESP=0011E280 CR2=00000000
> SBT=0012001C
> EAX=00000000 EBX=00000000 ECX=003DAC4C EDX=00000003 CR3=0009D000
> KFL=00003246
> EBP=0011E298 FS:=00000000 GS:=00000000 ERR=00000004 CR4=00000000
> TCK=0000C878
> EFLAGS=00013293 (OCPAZS=010101 IT=10 D=0 IOPL=11 NT=0 AC,VM,RF=001)
> OFSFATVolumes PC=22443, OFSFATVolumes PC=24169, OFSFATFiles PC=2781, OFS
> PC=4688, 
> Files PC=2024, ET PC=14016, ET PC=14672, ET PC=15089, Oberon PC=4860, 
> TextFrames PC=12027, ...

Where does this come from ?!?

-- Chris Glur.