OSDev.org

I suggest this become a thread where member can post resume of their attemps in testing other member's OSes so that we know who tested what and can start instant messages to help improving each other's solution.

edit: oh, and don't worry: i might be doing lot of filtering/merging/etc. on your posts so that it keeps the resume of the problems/solving, but maybe not keeping all the messages exchanged.

ok, i can test a few..i would like to test micro-kernel OSs
however, my system has:
1.8Ghz P4, 256MB-Ram, geforce 2 mx, IDE HD 80 GB(not to be overwritten) and a 3.5" floppy drive(rare )

I assume this is in response to my comment earlier about having tried Clicker and The Mobius unsuccessfully!

Well, I will start of:

When I tested The Mobius, I get a corrupted text mode screen, which scrolled by with various colours (it looks like it was scrolling indefinately but just putting bad characters/attributes in video memory). I will try again soon.

Clicker froze for me but I can't remember where, I will retry soon.

Clicker Froze on my system (p200, 32mb ram, Nvidia TNT2 32mb video, 2.5Gb HD,3.5 floppy) and Mobius did the same things to mine as it did to DaryID's, corrupt text screen.

Clicker is currently still compiled and distributed in "debug mode": it waits the end user to press space bar (or [Shift+Space]) to advance step by step ...
check http://clicker.sourceforge.net/docs/cake/debug.html for more infos...

BTW Pype, tried Clicker again, works fine.

You certainly love your debugging messages!

Daryl.

Good idea for the thread, btw.

I've made a new build of the Mobius sources and uploaded a floppy disk image to http://www.themobius.co.uk/mobius-mini-20030115.img.gz. I've just tested this image on the test PC I have here and it works OK, but I'd appreciate feedback from anyone who tries it. If all goes well then I'll make this an official release through SourceForge.

What you should expect to see:

• GRUB (press Enter to boot Mobius)
• A kernel startup/hardware detection screen
• A graphical console screen at 320x200, or at 640x480 if you have an S3 Trio64 card

Some bugs you might see:

• A page fault early on during boot at a fairly high address (around 0x80000000)
• The coloured text thing some of you have described

I don't know what's causing either of these, since I can't reproduce the symptoms myself.

Try your code on a AMD Anthlon...my PC is a Systemax...i'm testing your OS now...

whyme_t: yes, I've noticed that before. For some reason, you can download a .gz file with Internet Explorer and it will decompress itself as it downloads (but the .gz extension stays). I'm not sure whether that's because of the SourceForge web server or IE.

17Mobius testing report (summary for build mini-20030115.img)

_______
BOCHS \_________________

• Pype:ran in 320x200 only, but the last line of the display was screwed. moreover, i have no "." character but two ";" on the keyboard
• abless : the window was really small...but I had access to the command line and could browse through a file system...
• Perica : it seems to work fine - And yes: the last line of the Display is Screwed. I didn't get any errors or Page Faults.
• DarylD: Tried in Bochs 2.0, get a working console, nothing graphical seems to appear though although the console has BIG fonts (obviously running 320x200.)
  

_______
VmWare \___________________________

• df : vmware dies after loading it all -- BUG F(104):1147 bugNr=116 -- not very helpfull stuff... thats in vmware latest win32 release, and no devices in the steup, just floppy disk and 64mb memory. -- thread kernel/1 interrupt 14 at 18:c000d4c9: 80007803c
• DarylD : Tried "The Mobius" again using the latest boot floppy image in VMWare, I get a triple fault after the modules are loaded. I have memory set to 32Mb and nothing else particularily special setup.
  

______
RealPC \__________________

• hanoi: M?bius ends in a page fault, i get an debugging shell -- Thread Kernel /1: Interrupt 14 at 18:80091a70:80091a70

It shouldn't need to (that 80091a70 address is within one of the drivers). As I said to Pype.Clicker, who IM'd me with a similar report, I'm getting the same symptoms on one of the machines here, so I should be able to put all the reports together and fix this bug. It looks like something is messing up the page tables early on in kernel initialisation.

..

Maybe we should get in touch with thisRich Robbins guy - he seems to know quite a bit about setting up and testing operating systems...

Ah, a VMware test. Very useful, I hadn't thought of trying that. I'll get myself a copy tomorrow and try it myself.

Your laptop seems to exhibit the same symptoms as the others. Unfortunately, the only place I can reproduce that bug isn't on my test machine. Sigh.

Methinks so too. It's as if page table entries are being corrupted. Out of interest, what happens if you use the 'pte' debugger command on the faulting virtual address? It should tell you where it's mapped and with what flags. On the system which crashes here I'm seeing gibberish there; the virtual address is way beyond addressable physical memory, and the only reason it crashed was that the Present bit was randomly cleared.

Hmm.