Visopsys 0.76 Released

[andymc]

A new release -- consisting mainly of fixes and improvements to existing things -- has been posted to the download page http://www.visopsys.org/downloads.htm:

This maintenance release is focused on improved quality, rather than new features. The EXT (Linux) filesystem driver has been re-engineered, the Disk Manager program has been fixed in numerous ways, and hardware drivers and subsystems such as USB, APIC, and RTC have been tuned.

More details are here: http://www.visopsys.org/change-log.htm

Enjoy!

[ronaldlees]

Andy - thanx for the updated source and ISO. I recompiled the whole system with debug info ( g) but without optimization (-O0). Wow, the synced source and ISO sure make a big difference when single stepping through the code! It all lines up better now.

Anyway, when running Visopsys on the Debian/Qemu emulator, an issue still exists with version 0.76. On the first "step through" It executed up thru the following lines, but thereafter could not find files, and displayed a series of kernel debug messages until giving up with a panic:

Code: Select all

                // Just kickstart the device
                kernelDebug(debug_io, "IDE disk %02x kickstart ATAPI device", diskNum);
                status = sendAtapiPacket(diskNum, 0, ATAPI_PACKET_START);
                if (status < 0)
                {
                        // Oops, didn't work -- try a full startup
                        status = atapiStartStop(diskNum, 1);
                        if (status < 0)
                                return (status);
                }

                (the "inside" status returns < 0)

On a second run, Visopsys executed fine through the entire setup, mounting the filesystem OK, and then loading the splash bitmap (kernelImageLoad(splash)), busy.bmp, and a bunch of other graphic files. It subsequently executed kernelWindowInitialize(), windowStart(), setupWindowVariables(), and then loaded some font files with kernelFontLoad(). Unfortunately, it died when executing:

Code: Select all

 kernelFindFile("/programs/imgboot") (which returned a status indicating that the file could not be found).

It seems that there is a an intermittent problem accessing the drive, but only on particular versions of the Qemu emulator. Weird. Very weird. If I put a breakpoint at startStopAtapi(), and single step through the function, it'll work every time. When there is no breakpoint at startStopAtapi(), it'll error - sometimes. The same thing seems to happen with sendAtapiPacket(). To me it seems like a timing or interrupt thing. It's very hard to chase this bug (which could be a Qemu thing) - because everything works OK when I single step through it. I guess we have a dancing bug.

-Ron

[nextvolume]

It's most likely interrupt related, as disabling APIC makes the kernel boot fine on affected QEMU versions (the one I have installed on my system is among them)

[ronaldlees]

It's most likely interrupt related, as disabling APIC makes the kernel boot fine on affected QEMU versions (the one I have installed on my system is among them)

Yes, based upon what Andy has said, I guess I'd concur. I don't yet understand the kernel (and its hardware interaction) well enough to give my own opinion on it.

Like I wrote, by single stepping, I can "fix" the problem. If I'd be willing to keep stepping, I could keep the OS going ... LOL. It'd be a little tedious though! The way the problem manifest itself, relative to startStopAtapi() and sendAtapiPacket() is interesting. When there's no breakpoint, they (almost) never return. I must pause the debugger to continue, and it drops into the kernel's idle loop.

Stepping through the code, I'm beginning to pick up a feeling for how the kernel is built. Andy has a nice caching arrangement, so when single stepping disk related code, you spend a lot of time picking up the cache, rather than a direct disk access. I think that is the reason that the OS tends to go further if it can get past the initial physical disk reads. Then - it picks the data up from cache, and there's no status error.

Perhaps these posts should be moved to the Qemu thread.

[andymc]

Hi guys,

Yes, I agree that it's probably APIC-related, and by their nature, interrupt-centered problems tend to be difficult to pin down, because they're often timing-sensitive.

One thing about the APIC is that it's faster than the old PICs (even in the emulators), so I already had to fix a handful of problems where the APIC was racing the code. In this case, we may be seeing the APIC racing the ATAPI driver code, producing an interrupt before the code is fully ready for it, for example. What you found there might be quite helpful Ron.

Andy

[ronaldlees]

Hi guys,

Yes, I agree that it's probably APIC-related, and by their nature, interrupt-centered problems tend to be difficult to pin down, because they're often timing-sensitive.

One thing about the APIC is that it's faster than the old PICs (even in the emulators), so I already had to fix a handful of problems where the APIC was racing the code. In this case, we may be seeing the APIC racing the ATAPI driver code, producing an interrupt before the code is fully ready for it, for example. What you found there might be quite helpful Ron.

Andy

This is new terrain for me. I'm glad you're the expert on this one Andy! The hardware is a little like a lurking thread in a multithreaded traditional application program (the only terrain I'm really familiar with) - as the latter does something unexpected or messes with globals. When I first found how ridiculously simple it was to single step Visopsys, I thought I'd be contributing some. Premature on that - I'm afraid

In the traditional programming world, with multi-threading, we'd have IPC. I guess that's a work in progress on Visopsys?

[andymc]

In Visopsys, threads share data memory (and page tables) with their parent and siblings. They're very lightweight, only using their own process context structures, and stack. IPC isn't needed so badly there. But, for proper process-to-process communication, there's not much, yet. There's shared memory and signals. No pipes or other formal IPC.