Mattise 3.0 Released!

[pcmattman]

Hi everyone,

Just announcing that Mattise 3.0 is now released and up. You can download it at http://www.sf.net/projects/mattise. I've put up ZIP, GZ and BZ2 archives so you can download the one that suits you the best (bandwidth, software, etc...).

Please try it out and tell me what you think. Support requests or bug reports (or similar) should go into the trackers (as well as here) on the SF site, or you can email mattise at wikiforall dot net.

Thanks!

[xyzzy]

I tried running in QEMU. It boots OK, and I can use the shell. However, running nasm from the bin directory resulted in a page fault one time I booted. I closed QEMU and started it again and NASM worked fine. Running strings from the bin directory always gives me a pagefault and then hangs:

Code: Select all

Extra Debugging Information:
EFLAGS: 0x3257
CR3: 0x5fb7000, CR2: 0x10b026cf
error code: 0x0
EIP: b0269783
GPRs:
EAX: b0000000, EBX: 0, ECX: 104de0, EDX: 11bf30, ESI: 10000038, EDI: d003ff48
ESP: 11bf4c, EBP: f0

Fault occured at <outside_kernel b0269783>
Page fault with EIP=b0269783, EBP=f0
Call stack:
0: <outside_kernel b0269783> eip=b0269783 [op=26978e00], ebp=f0

EDIT: This is using the build with the HD image

[pcmattman]

Running strings? What do you mean by that?

Also, on that dump it seems that the CPU is executing inside the kernel heap, and trying to access the userspace heap. Are you able to tell me exactly what you did to get that dump (if it's reproduceable).

[xyzzy]

'strings' being a program included with binutils, it's in the bin directory on the hard disk. Sometimes it just hangs rather than pagefaulting, but it hasn't run properly once for me.

[Combuster]

I tried running on real hardware, and after grub having loaded the ramdisk, something gets printed to screen (two more lines), after which it immediately wipes the screen again and only a flashing cursor remains where the text ended. The second box showed identical results.

Grub reads "Matisse (bochs)" so I was wondering whether it does require the VBE backdoor or should it run on stock VGA hardware too?

Hardware: Io and Uranus [ specs ]

Edit: after 3 minutes of blank I got a welcome screen

[inflater]

Tried on rHW too. After GRUB loaded the "ramfs.bin", it changed the text mode and right after that, it printed something, "Welcome to Mattise 3.0" was all I could read, and immediately the PC rebooted. Nice try.

[pcmattman]

It sounds to me like it's running out of memory. I've always tested with 256 MB (but it *should* work with as little as 64 MB).

This is exactly why I wanted to release - now I know there's issues that need to be fixed

Thanks AlexExtreme, inflater and Combuster!

[Troy Martin]

Just tested it in Virtual PC!

meminfo does squat, ls and cd don't work, and backspacing doesn't remove a the character from the buffer. More bugs for 3.0.1!

[pcmattman]

meminfo doesn't do anything because I haven't reimplemented kGetAvailMem after I switched to a bitmap from a stack for page allocation.

Also, "ls" and "cd" won't work unless you have a hard drive image (though you should be able to do "cd /ramfs" and then ls in that).

And as for the backspace problem - are you certain? It works for me 95% of the time.

EDIT: Also, fixes in 3.0.1 which will come out very soon will be in just a floppy image, so there's no need to patch and the download size is reduced.

[pcmattman]

Double posting to bump the thread so it's "unread" for all.

I've released 3.0.1 on the same page as above, which basically contains a lot of bugfixes (including a much better FAT driver) and, just for you Troy, I made sure meminfo prints something

The archive contains just the floppy image, so if you downloaded a HDD archive before you'll need to overwrite the mattise.img file.

Thanks everyone!

[inflater]

(but it *should* work with as little as 64 MB).

The testbed has 98MB... BTW if it really is a not-enough-memory problem, it's weird, my OS can boot with as low as 2 MB RAM, altough has a min. 4MB run limit. Ah, different design I guess.

But eh. It booted now!! ... with this:

"Welcome to Mattise 3.0". Yay.
"You fail at not crashing this OS". Yay. Mine never crashed. Well at least, unless you invoke the crash from the setup menu, or juice up the PIT dramatically...
"The exception was number 0, proces 1" - something for you.
"Now go contemplate your failure while this OS loops forever". Yay, it's frozen!

CR3 - 0C01000h, CR2 - 0

Now it's bochs time. It displayed

PAGE FAULT
EIP = 0x105271, CS=0x8, PID=-1
CR3 = 0xC01000, CR2 = 0

PAGE FAULT
EIP = 0x0, CS = 0x8, PID=1
CR3 = 0xC01000, CR2 = 0

This time, it omitted the "you fail at not crashing this OS". I think it needed another 98-32 MB of RAM to display it...

Now adjusting bochsrc "megs = 32" to "megs = 512" it works. You're pretty RAM hungry.

ls - "minish could not find folder /hd0/"
cd /ramfs/ and then ls - works ok

echo (500 stupid characters) - 500 stupid characters displayed again. So that's where you needed the RAM

So it works afterall, but really, you should optimize it a bit. lol.

Regards
inflater

[Combuster]

Tested on Rhea (i had it connected for testing my own OS, so why not).
Prints the welcome screen, and the infamous "you fail at not crashing me" (err 0, pid 1, cr3 0xc01000, and amazingly enough, cr2=0)

Io still stalls with a blanked screen for three minutes (always fun to crash OSes with computers that don't have an IDE controller)
I let it run on for a while this time, and it did get to a shell, which turned out to be completely ignorant of my keyboard

Uranus also stalls with the same black screen (takes longer than Io). Then displays the welcome message and locks up. (i.e. no change)

[pcmattman]

@Combuster: I'm sure I wrote the code to support the lack of an IDE controller, but it looks like it doesn't work. Thanks for trying it out again. I don't have any real hardware available unfortunately ).

@inflater: My OS allocates things like heaps and stuff from the outset (also the page bitmap is rather large). The kernel heap alone is 32 MB, but I may be able to reduce that now that the device manager doesn't use the kernel heap.

It looks like for both of you you're having trouble loading the shell. I'll try reducing the memory I give my emulators (VPC, VMware, Bochs and QEMU) and see if I can reproduce your behaviour.

This time, it omitted the "you fail at not crashing this OS"

Hehe, actually, I removed them for page faults because they are the most common exception thrown in my OS, and I got sick of reading "you fail" all the time .

ls - "minish could not find folder /hd0/"
cd /ramfs/ and then ls - works ok

No hard drive image, so no "/hd0/". I don't yet have a real VFS so this is just a fake default string. When I get around to writing a VFS there'll be true mountpoints and things like that.

So it works afterall, but really, you should optimize it a bit. lol.

I agree - and thanks for taking the time to test. I'm going to try to reproduce your behaviour and then fix it. I know for sure I can reduce memory usage by at least 20 MB if I think things through correctly.

Tested on Rhea (i had it connected for testing my own OS, so why not).
Prints the welcome screen, and the infamous "you fail at not crashing me" (err 0, pid 1, cr3 0xc01000, and amazingly enough, cr2=0)

It's interesting that this is PID=1, which isn't actually the shell. That means that it's crashing somewhere else - CR2 = 0 but the "you fail" message shouldn't come up on a page fault? If it is actually a page fault then there's something else wrong. I'll look up your system specs and try to figure out what might be going on.

Io still stalls with a blanked screen for three minutes (always fun to crash OSes with computers that don't have an IDE controller)
I let it run on for a while this time, and it did get to a shell, which turned out to be completely ignorant of my keyboard

How fast is the Io processor? I have some issues with load times especially in Bochs that I put down to a slow page allocator. But 3 minutes is a long time to wait.

The lack of keyboard usage is something I've experienced in Bochs only and I think it might be because I don't reset the keyboard at all in my TTY driver - so I'll look into that before I release next.

Uranus also stalls with the same black screen (takes longer than Io). Then displays the welcome message and locks up. (i.e. no change)

Again, can't load the shell it seems. I can't figure out why :S. I'd imagine there are many differences between Bochs' simulation and a real CPU, but I also think VMWare and VPC are closer to the real hardware and it works in them.

Thanks Combuster for trying the system, I'll definitely take this in and try to get some fixes out. It seems I have some memory issues that I need to think about

[Combuster]

I posted a link to all the specs before, but if I look at the stats CPU power isn't quite the issue
Rhea: Pentium II @400, doesn't noticeably stall, panics
Io: 2x Pentium II @266, stalls some 3 minutes, locks up at shell without keyboard
Uranus: Celeron @466, stalls even longer, doesn't get to the shell.

One thing you might want to try in bochs is to smack the keyboard a few times during boot to fill the buffer and see if the driver can empty that. (I'm using a KVM so it'll have seen several keypresses flying by when I switched between testbed and my main pc). But IMO the lag is more nasty.

[froggey]

I broke it!

Code: Select all

$ cd /ramfs
$ asdf!

And then it page faulted:

Code: Select all

EIP=0xc0006f30, CS=0x8, PID=5
CR3=0x3466000, CR2=0x6d61733b

Extra Debugging Information:
EFLAGS: 0xa87
CR3: 0x3466000, CR2: 0x6d61723b
error code: 0x2
EIP: c0006f30
GPRs:
EAX: 612f7366, EBX: 20, ECX: 10001890, EDX: 6d61722f, ESI: 10001888, EDI: 0
ESP: 50007efc, EBP: 50007f28

Fault occured at <outside_kernel c0006f30>
Page fault with EIP=c0006f30, EBP=50007f28
Call stack:
0: <outside_kernel c0006f30> eip=c0006f30 [op=890c4289], ebp=50007f28
next ebp=50007f48
0: <outside_kernel c0001905> eip=c0001905, ebp=50007f48
next ebp=50007fe8
1: <outside_kernel c000184d> eip=c000184d, ebp=50007fe8
next ebp=50008024
2: <outside_kernel c000008c> eip=c000008c, ebp=50008024
next ebp=50008028
3: <unsafe_return_from_thread_entry+0x0> eip=1044f5, ebp=50008028
next ebp=1044f5
4: <outside_kernel c0000080> eip=c0000080, ebp=1044f5
next ebp=83e58955
5: <outside_kernel 90e808ec> eip=90e808ec, ebp=83e58955
Killing and continuing