Mojo 0.1.2 released - please test and comment

[Combuster]

Tested 0.1.3 alpha (floppy version) on some real machines

got a panic on the first box (Dione):

Code: Select all

mem block (multiboot): 0x00000000 - 0x000a0000, 0x000a0000, type = 1
mem block (multiboot): 0x00100000 - 0x02000000, 0x01f00000, type = 1
mem block (multiboot): 0xfec00000 - 0xfec00800, 0x00000800, type = 2
KERNEL PANIC ASSERT: src/kernel/multiboot.c:171 failed expression: '0 == g_boot_
memory_map[i].base_high'

The Athlon XP box (Phobos) boots as expected, but gives some wrong information about the CPU (which runs at ~1.7GHz, gets reported as 674.620 Mhz)

(specifications)

[clange]

@cyr1x:

Just before the kernel assert panic it should print which address is wrong. Could you please tell me the address???

@Combuster:

Hmmm, weird with the panic. It happens because the upper 32 bit of the base address is not 0. But on the other hand it also makes sense if you consider the BIOS area to be just below the top of the memory - then the upper 32 bits could be 0xffffffff. I need to have some more info about your memory map. I have uploaded a new alpha version (build 844) and also a small DOS tool that can dump the more memory map info. Could you please test with the new image or use the DOS tool and transcribe the new memory map dump. Thanks.

clange

[Combuster]

The new image gives the same assert (now on line 236), but without any other useful info.

As for the meminfo.exe dump:

Code: Select all

method #1: (...)
   conventional memory : 639 kb

method #2: (...)
   extended memory: 31744 kb / 31 mb

method #3: (...)
   extended #1       : 15360 (15 mb)
   extended #2       : 15360 (15 mb)
   configuration #1  : 15360
   configuration #2  : 256

method #4: (...)
   0x0000000000000000, 0x00000000000a0000, type = 1
   0x0000000000100000, 0x0000000001f00000, type = 1
   0x00000000fec00000, 0x0000000000000800, type = 2
   0x00000000fee00000, 0x0000000000000400, type = 2
   0x00000000fffc0000, 0x0000000000040000, type = 2

[clange]

Hi Combuster

Thanks for testing again. Before the panic the kernel should display some memory map entries. Does the last entry have non-zero values in the upper 32 bits?

The memory map dumped by my DOS tool says it doesn't - but it could easily contain bugs (here is the code http://softwarewizard.dk/mojo/tools/meminfo.zip - it requires Turbo C). If you ran meminfo.exe on a writable disk it wrote a file meminfo.bin. Could you post that too please.

clange

[Combuster]

I used the 844 floppy version I got from your site today. Once it panics I get a red screen with *only* the panic message and some ASCII art. Whatever it prints before that gets overwritten too fast to be even readable.


I had a go on some of my other machines, and added one success and one fail.
Io worked correctly and I couldn't find any issues.
Iapetus however panics with "PANIC: error in mark_physical_memory", again with no other visible information.

[clange]

Ok, this makes more sense to me. It panics after the kernel init it seems. I have to improve the way I handle panics as not to obscure debug info. Ill post when I have made progress.

EDIT: I was wrong - I hadn't disabled the red panic screen - it is fixed now and I have uploaded a new version (still build 844)

EDIT2: there seems to be an extra character in the binary memory map file. At offset 0xe a 0x0d character has been inserted (it seems). It could be a character added by translating line endings.

clange

[Combuster]

I get garbage readings on dione:

Code: Select all

(...)
mem block (multiboot): 0x3317e831fec00000, 0x1ff0750f0000800, type = 2
KERNEL PANIC ASSERT: src/kernel/multiboot.c:236 failed expression: '0 == g_boot_
memory_map[i].base_high'

Iapetus gives a correct dump - the only interesting bit is that it isn't sorted and has acpi reclaimable area's:

Code: Select all

(...)
memory map size: 7
mem block (multiboot): 0x0000000000000000, 0x00000000000a0000, type = 1
mem block (multiboot): 0x0000000000100000, 0x0000000007ef0000, type = 1
mem block (multiboot): 0x0000000007ffec00, 0x0000000000000400, type = 2
mem block (multiboot): 0x0000000007ff0000, 0x000000000000ec00, type = 3
mem block (multiboot): 0x00000000fec00000, 0x0000000000010000, type = 2
mem block (multiboot): 0x00000000fee00000, 0x0000000000010000, type = 2
mem block (multiboot): 0x00000000fff80000, 0x0000000000080000, type = 2
 * Multiboot Startup
 * Memory Startup
 * Multiboot data parsed
PANIC: Error in mark_physical_memory

[clange]

Hi Combuster

I have improved my memory routines and it should work on both Dione and Iapetus.

To make it work on Dione I try to detect if the machine is capable of more than 4 gb address space. If not I clear the upper parts of the memory map entries - this should make it work I hope. I have implemented a new and more general method in my memory initialization so it can cope with Iapetus' memory map.

@cyr1x: this new build should also work with your machine now.

I hope you find some time to test. Thanks.

clange

[Combuster]

Still a fail on dione - it gets more garbage readings, yet also detects that PAE support is present, then panics again.

Iapetus fixed.

I tried some debugging code and stumbled upon a BIOS bug in Dione though - 0xE820 refuses to overwrite the high dword for type 2 memory ranges. (tested by filling in the struct with 0xee prior to the bios call). The good way to fix this is by loading the structure with zeroes before calling the BIOS, but I don't think you want to be patching GRUB sources.

It also explains why your DOS app did get the right memory map.

*heads off checking his own e820 code*

[edit]A quick google didn't find that as a known bug either...[/edit]

[clange]

Hi Combuster

I decided to handle Dione by adding a kernel parameter that tells the kernel to ignore the upper 32 bits of the memory map. This seems to be the easiest way around the problem.

This is the current kernel parameters (edit the GRUB command line if you want to try them out)
- loglevel=n
n is from 0 to 4 both inclusive. 0 (default) prints only a minimum and 4 prints all log messages
- disablegui
shows the kernel log during boot instead of the tui progress indicator
- 32bitonly
- clears the upper 32 bit of the bios memory map (for compability with buggy bios)
- language=nn (us, de, dk)
- passed on to init process and will select the system language.


I have uploaded the newest version (build 857). The disablegui and 32bitonly parameters are used in the images. I hope it works now.

clange