m44rtn/vireo

Vireo is a simple 32-bit mono-tasking operating system for the x86 CPU architecture.

vireo's Issues

assert in function driver_exec()

Vireo build: 3881+

After fixing issue #31, the driver_exec() function asserts with the following output:

The problem seems to be an issue with the ISO9660 driver (TYPE_FS | ISO9660 == 0x2000096), which it may not be able to find on systems with more than 1000 MB of memory. However, it may also indicate a different problem

This does not necessarily seem to be an issue that was created by the fix for issue #31. The only thing changed by the fix for #31 was that the shadow map was placed after the paging tables instead of being allocated at the start of kmalloc memory (0x200000, due to being the being the first thing allocated by kmalloc).

It may therefore be a stability issue, perhaps introduced a long time ago.

To keep track of stability issues, #21 was created. It acts as some sort of timeline.

Edit: I have edited this issue since the information given previously was incorrect (driver_exec() does NOT receive memory pointers, it was simply given the ISO9660 driver type number).

Vireo hates multiple sectors

The system can not read or write to multiple clusters yet. Writing should be an easy fix, however I'm not sure about the read issues. It seems that the entry of the FAT that BirdOS reads isn't the right one. However, the math does 'comply' with the specification and wiki.osdev.

FAT driver does not support delete yet

that.

Vireo keeps CDROM busy?

Vireo build: 926-933, +

Describe the bug
The CDROM keeps spinning even after detecting the drive types. Maybe this is normal, but it could also be caused by the IDENTIFY command or something silly like that.

To Reproduce
Get a real PC/laptop out and test it with the builds specified above.

Additional context
Maybe nuking the thing with a software reset after IDENTIFY is a quick and dirty way to fix it?

Vireo #GPs at keyboard press

Only happens at first boot, not the second.

(boots up, #GPs on button press, use Host+R, it works)

PCIGetDevices() results in a fault (within the IDE driver?)

Vireo build: 921

Describe the bug
results by PCIgetDevices() result in a fault.

I don't really have more information at this point, just want to create this issue so I can easily track it.

Problems loading Conway v0.1-pre1 release

Vireo build: 3658 (v0.1-pre1, release)

Describe the bug
Vireo may have trouble loading conway.elf on systems with more than 79 MB of memory. The system may kernel panic (non present page fault) or halt completely due to a triple fault.

instr() and hexstr() need a malloc

Vireo build: 64

Describe the bug
intstr and hexstr actually need some sort of malloc in order to work 'properly'.

To Reproduce
...

atapi #GP

Vireo build: 1471

Describe the bug
ATAPI_READ always #GP's and I don't really know why. I do know where: it's after the command packet has been sent.

Vireo detects allocated sectors as free sectors

Sector 0x204D is not free (allocated by FreeDOS) but it is seen as one by Vireo.

Vireo does not support ICH IDE devices

Build: 918

Today I tested Vireo on another computer (this time WinXP era). It all went fine: Vireo detected loads of PCI devices and found an IDE device (Device ID 24CB from Intel (Vendor ID: 8086)) and it loaded the appropriate (and only) driver. However, the driver did absolutely nothing, not even the usual "driver mark I" message. Vireo does get past the driver though, for it reports its build number (which is the last thing done before the endless while loop). The driver doesn't hang.

This either comes down to the driver not getting the INIT command (which would be weird, but would explain the driver successfully returning command back to Vireo), or something else. I'll have to look into this. I do want this to work, since the test machine is one of the few machines I own with a serial port.

The machine uses an ICH4 IDE controller. The builds do work on PIIX(4) devices. I tested this in Virtualbox and a laptop from ~1999. Both use Device ID 7111 by Intel.

Reproduction: in Virtualbox open the settings and go to storage. Click on the IDE controller and on the right hand side select ICH6 (which behaves similarly) in the 'Type' dropdown menu. Virtualbox uses PIIX4 by default. Anyway, after doing so, start the machine with build 918.

vireo can't handle 256 mb and 512 mb ram

Vireo build: 222

Describe the bug
Vireo triggers a triple fault when the amount of ram is below 512 mb (haven't tested it with more than 512 except 4096 mb). Depending on the amount of ram it (256/512) it will trigger a triple fault sooner or later. Vireo works without any problem @ 4096 MB

To Reproduce
just launch virtualbox with either 256 or 512 mb of ram with vireo.

Expected behavior
To not do that.

Take a look at the driver system

This issue expands on issue #21.

Maybe the driver system can be improved. Perhaps a little redesign does wonders. Or maybe that's not even necessary.

No cursor

Vireo build: 6

Describe the bug
The cursor won't show up.

To Reproduce
Just launch it in virtualbox, and see it happen. :)

Expected behavior
The cursor SHOULD show up.

Screenshots
Screenshot 1 where you can't see a cursor.

Additional context
Could be ASM_INB

ASM functions

This issue expands on issue #21.

Assembly functions should be used as little as possible to preserve registers (and thus local variable values) in use by the C side of the kernel.

Critical assembly functions (things that can only be done in assembly) should preserve ALL registers.

To do this:

• Phase out all ASM_INx and ASM_OUTx functions, in favor of the inx() and outx() functions.
• Incorporate register preservation in all assembly functions still in use after that.

This WILL massively improve stability in Vireo,

Triple Fault

Vireo build: 1

Describe the bug
The kernel triple faults, I'm not sure where yet.

To Reproduce
Just execute it in virtualbox, and see it happen! :)

Expected behavior
To see hello world printed on the screen.

Additional context
I'm not sure what causes the triple fault just yet. It may be in the assembly part, but it is probably in the c part. I'm accusing screen_basic at the moment, though I'm not certain if it really causes the problem.

Try solving it without executing ASM_OUTB, that could be the problem too.

something pops too much of the stack in v86

The iret stack misses one value at the same place in the stack, compared to the int stack. Where int stack[0] would be 0x636, iret stack[0] would be 0x000.

This is temporarily solved by just reserving a extra dword on the stack

GCC try -O2

Will it work? Will it be better? Will it be smaller? Will it be faster?

Keep watching, to find out!

IDE driver creates 'infinite' loop

Vireo build: 1067+

Describe the bug
When using the variables (p/s)_base_port and (p/s)_ctrl_port set by IDE_enumerate(), the for-loop in IDEDriverInit() suddenly transforms itself to an infinite loop.

GCC's generated code inside the for-loop apparently (for what I've seen) uses ebp to store the drive variable. ebp at one point jumps from 1 to 0x200A00 (for reasons unknown), and thus drive does too. At this point, I would expect the for-loop would stop (since it uses the check drive < IDE_DRIVER_MAX_DRIVES with #define IDE_DRIVER_MAX_DRIVES 4. In commit 4653a7d, this has been changed to just the value 4. However, this should've been reverted back to using the define before pushing.

Anyway, the for-loop keeps counting up from 0x200A000. Eventually, though, Vireo panics with a #GP (of which I don't have a screenshot at the moment).

This doesn't happen when you use hard coded or defined values for the ports (at the port = ...? ... : ... line).

To Reproduce
Use the above named variables, and pass them to the IDE_getDriveType() function.

Expected behavior
I expected that it would work just like it used to: it looks at the primary and secondary controllers to take a look if there are drives attached and what type they are. The for-loop should stop at four drives.

Screenshots
Screenshot of the kernel panic will be shared later (if I don't forget).

Additional context
It may be worth looking at if this still happens if you comment out the line where IDE_getDriveType() is called within the for-loop.

FAT driver may not write files properly

Sometimes, the FAT driver messes up directories. This could be due to the way the IDE driver calls insw() and outsw(). The ATAPI code had this issue and has been fixed in commit e520c85 but the issue has not been fixed for the ATA code.

Of course, it is also possible (and very likely) that the FAT driver itself is responsible.

FAT can't find lowercase filenames

Vireo build: 3000+

Describe the bug
Due to FAT32 driver of Vireo never checking if the given filenames are all uppercase, the files won't be found if a user would feed the driver lowercase filenames.

The driver should convert the filenames to uppercase in the case that this would happen

VESA detection not working

int 0x10 ax=0x4f00 and di=0x2000 succeeds with ax=0x004f. However, the infoblock seems to be returned at a different address than es:di (should be 0000:2000).

I'm unsure what causes the problem here.

ATA/ATAPI no interrupt

While waiting for an interrupt with either ATAPI PIO or ATA DMA, no interrupt is fired for them ever.

This needs to work in order to use DMA (and possibly ATAPI PIO)

Cursor always at line 2

Vireo build: 47

Describe the bug
The cursor is always at line 2, unless you say it should be at line 0.

To Reproduce
Just launch it in virtualbox, and see it happen. :)

Expected behavior
The cursor to be at the specified position (either by using (or not using) '\n' in a string or by using screen_bsaic_move_cursor()).

Screenshots
Screenshot 1

sleep() behaves weird

Vireo build: 1071

Describe the bug
it just does.

Trouble reading drives

Vireo build: 1615

Describe the bug
The winXP machine (BLOBBY) has trouble reading PATA drives, it just hangs. I think it has to do with polling RDY or something like that.

Internal IDE driver hangs on my winXP era machine

Vireo build: 926-931, +

Describe the bug
The internal IDE driver hangs at a 'random' time either during, before or after (trying) to detect the ATAPI device. During which, the ATAPI device spins really hard.

To Reproduce
Pop in a CD with Vireo on it into the machine that's similar (or this exact one) and wait. :)

Expected behavior
I'd hoped it would get past the driver and show Vireo's build message (doesn't happen).

Screenshots
Sure, why not... Screenshot of build 931.

Machine information:
ReactOS detects:
CPU: Intel Pentium 4 @ 1.80GHz
Memory: 512 MB
Motherboard: MSI MS-6398E

Additional context
As you can see in the screenshot the computer uses PCI device 0x24CB8086, which is an Intel ICH4 controller.

TODO

• fix issues in the refman

globalize build string

The build string is now hard coded in two different traces (in main() and in panic()) this should really just be one define in kernel_info.h or something like that. But then there's the problem that the build still has to be passed with every trace, but what if the build string changes??

So, maybe just make a function in the file with the global functions.

By the way, that file should probably be in ./kernel/.

Vireo is unstable

Vireo build: 1334

Describe the bug
Vireo is very unstable and it probably has to do with how the driver system works.

• Some variables are overwritten with new data, while they shouldn't (by pieces of code that shouldn't have access). So that's something to do with pointers.
• Vireo sometimes #GP's during the driver init command routine, without a clear reason. A reboot of the VM often solves this. Maybe the thing that's causing that is also the cause of issue #16.

Additional context
This issue will eventually be split up into multiple, each for every problem. This will happen when more testing has been done and I have more information about the cause of the problem.