This bug is terrible to read about. I still can't believe that INT 25 and
26 were not going through the buffer cache.
Anything that blindly writes a sector before it reads it is broken, unless
it's wiping something out. So you can assume that a read to a specific
sector will always precede a wri
sv32r:Push fsPush fsc:NopRestr: ;0f a1 pop fs ;66 0f a1 popw fs ;0f a9 pop gas ;66 0f a9 popw gsretfI To: "Technical discussion and questions for FreeDOS developers." ;Cc: "Bernd Böckmann" ;Subject: [Freedos-devel] DOSL
> I ask this because some recent activity by Bernd and ECM who have been
> working on a kernel Divide by Zero error.
>
> Very, very, very basically, part of the 32-bit kernel was assuming the GS
> register would remain unchanged. But, the buffer was moving because of that
> register.
Now tha
Since the exact cause of this bug has not been identified, we seem to be
assuming it is a dirty buffer issue.
This is very likely the case. However, there is something else to consider as
well.
Did anyone do any testing of this under a 16-bit version of the kernel?
I ask this because some rece
Hallo Herr Eric Auer via Freedos-devel,
am Dienstag, 5. August 2025 um 02:00 schrieben Sie:
> Hi Tom,
>> cache INVALIDATION is only needed because the BUFFERS cache
>> might have stale data that are not yet on disk.
>> It's a brute force clutch, not a real solution.
> Scary. How about triggeri
