OSDev.org

well, we're having a nice discussion in other thread about how one can render text on screen. Yet i'm wondering how much of the framebuffer and rendering your kernel knows about and whether or not it's causing you trouble when the kernel panics.

In my situation, i wanted the screen server to be an independent user-level service, but it causes trouble when things go wild and that you want to display a "oops" or something

Kernel only knows how to write in text mode and even this will vanish - there 's going to be a dedicated thread for panic guru mediation mode. But that's future music. In these days I am far away from OS hacking, delving deep in the arcane depths of the art of Integrating and finding Root Functions. *gg* The earliest I can manage to throw a big thing in my os is when summer holidays are there. Yeah, then I can do something biig. *gg*

But in the meantime, for every other thing, kernel asks the GUI service to do the drawing, if we are operating in gui mode. There's a dedicated system window, where all those messages appear. It works fine for 99 percent. The last percent is the really ugly and nasty bugs which cause everything to crap out. *

Stay safe.

welcome to debug sessions darker than night! Be my guest! Another Bug, another Try, but remember: Debug or diiiieeee! Mwaaahahahahahahaaaaa

I'm not sure if this is exactly what you meant but
I use k_printf ,which writes straight to video memory, whenever there is an exception or panic but for everything else i use printf which writes to a buffer that is copied to video memory every 30ms

but in my kernel it is still so early in development that if an exception happens then you must reboot(even a page fault) so maybe i will change it in the future

I writes straight to video memory, but can see a problem down the road, with multi-tasking, gui etc.
So maybe i will implement a beep code for differant things, using the internal speaker.

PS: We could come up with a standard "beep" error code .

Got no framebuffer yet, it also writes to phys mem for the current console.

PS: We could come up with a standard "beep" error code

Why not teach your kernel the morse alphabet, that way a core dump could be quite entertaining ;D

I was always thinking along the lines of doing this when an serious problem happens:

- halt interrupts etc.
- collect all the data needed to display something meaningful and write that to low memory
- switch back to realmode
- let the BIOS activate standard (or perhaps 80 x 50) textmode
- display the information
- halt the system

The only potential problem would be disabled interrupts and a corrupted stack (can we switch to a new one for the exception handlers?) .

In theory you could do it through the currently loaded graphics driver. However, this would be problematic if datastructures, services etc. it needed are corrupted (or responsible for the problem in the first place). Or the graphics driver could be the problem.

For that reason I was thinking about just dropping everything and switching back to the basics with well written routines that can operate without (or as little as possible) dependencies on other stuff.

Hi,

For the previous version of my kernel, the kernel itself had code to dump "critical errors" directly to video display memory (which was mapped into kernel space at a fixed address and into the video drivers address space at whatever address it liked).

This means if the video code crashes, if the scheduler does something nasty or if the kernel itself stuffs everything up badly, the critical error handler still works fine.

It also means I had code to handle every possible video mode (text mode, 16 colour mode, 256 colour mode, 15 bpp, 16 bpp, 24 bpp and 32 bpp, at any possible resolution) built into the middle of a micro-kernel.

I was/am intending to support computers with multiple video cards, and was/am intending to support power management. This means that the kernel's critical error handler would only be able to use the first video card and the first video card could be disabled or in a low power mode. The critical error handler would not always work in this case.

I was/am also intending to support "headless" computers, which have no video card at all.

For the new version of my kernel I want it to be 100% reliable, I want to get the video handling code out of the micro-kernel and I want it to work with multiple video cards, power management and headless systems.

Obviously, I haven't figured out how I'm going to do this yet - I'm hoping to pull a miricle out of my arm pits...


Cheers,

Brendan

I guess for all of that to work you would need a layered system that can reliably detect the state the system is in.

For example. In Windows you have the option of generating a memory dump (on harddisk) if the system goes down. I *assume* they detect if it is "safe" to do that before doing that action.

Brendan: aren't you working on a distributed OS? If so, it might be an option to send an "error report" to the other nodes if the system critically fails (in the case it is a headless system, for example). This, of course, would again assume you can detect if at least the base network drivers are up and running (and you would need some base interrupt handling for this as well).

What are your thoughts on my "proposal"? If the system falls back to realmode I guess you have access to textmode and the harddisk you booted of (through int 13h).

However, I didn't think about what would happen if various components (like video / harddisk) would be in a certain sleep state. I have no idea if a realmode BIOS can cope with that (I would assume it can).

Anyone have any ideas how unix/linux or BeOS, for example, handle this?

Hi,

Rob wrote:Brendan: aren't you working on a distributed OS? If so, it might be an option to send an "error report" to the other nodes if the system critically fails (in the case it is a headless system, for example). This, of course, would again assume you can detect if at least the base network drivers are up and running (and you would need some base interrupt handling for this as well).

For me, if the kernel and messaging is working reliably it's not a critical error - the kernel can either terminate the process, send details to the video driver to display, dump it to disk, inform other machines, etc.

A critical error would be where the kernel no longer trusts itself (or when none of the options above are possible). A double fault, a re-entrancy lock problem in the kernel, an unresolvable GPF or page fault while running kernel code, etc.

The only solution I've thought of so far is to reserve a special area of physical memory that the kernel can write critical error information into. Then I could recover this information after the computer is reset or triple faults - build it into the OS's boot code so that it is displayed reliably using BIOS's video code (or sent over a serial port connection for headless systems).

I'm thinking this is the most reliable way (but I'm also thinking it'd be a pain in the neck for users).

Rob wrote:What are your thoughts on my "proposal"? If the system falls back to realmode I guess you have access to textmode and the harddisk you booted of (through int 13h).

However, I didn't think about what would happen if various components (like video / harddisk) would be in a certain sleep state. I have no idea if a realmode BIOS can cope with that (I would assume it can).

Your idea is a good idea, providing that the OS can return to real mode reliably. If various components are missing (e.g. video) you can try the hard drive, a serial port, a printer port (an interesting idea if you've got a printer that can handle raw ASCII), a network card, etc. If none of these are possible, then you'd really have to wonder what the computer was being used for...

For example, I can imagine an OS running on a headless computer with no hard drives (booted from a CD), but without some form of networking I can't think of any practical purpose for it.

The problem is reliably returning to real mode.

For example, most video cards have a "legacy VGA" mode and a "heap of fancy features" mode. If you return to real mode the BIOS (and the ROM in the video card) might not handle "heap of fancy features" mode properly.

At the moment I'm working on menu-driven code to set a default video mode during boot which also allows the user to test video modes to see if they work right. For 256 colour VBE modes it switches the DAC into 8-bit per primary colour mode. The current "bug" is that if I test a 256 video mode and then return to the 640 * 480 16 colour mode used by the menu system all of the colours are dark because the video BIOS doesn't reset the DAC to 6-bit colour during a video mode switch (e.g. for white it sets the pallete entry to "0x3F, 0x3F, 0x3F" which is dark grey because of the 8-bit DAC). My solution is to write code to restore the DAC to 6-bit colour after testing 256 colour modes, but your kernel and real mode code won't know if the video driver has done this (or anything else that needs restoring before the BIOS will work properly).

I'd expect similar problems for other devices - device drivers putting hardware into a state that the BIOS can't handle. Setting the floppy controller to use DMA transfers when the BIOS uses polling, setting the ATA controller for bus mastered transfers, switching the PIT timer to 1 KHz, telling the sound card to PCI MSI so it doesn't share an IRQ with the network card, etc.


Cheers,

Brendan

I was afraid of that indeed. Hmmmm. I've been examing my Windows installation here a bit and it seems it uses both bootvid.dll during boot and to reset/display that well known blue screen of death.

Looking at the assembly code in that DLL for VidResetDisplay export it seems they are writing all sort of stuff to memory mapped I/O registers of the VGA card to reset it.

I'll see if I can find out exactly what is being send to the video card. Is that something that we could monitor with something like Bochs? It is possible to force a crash in Windows with the kernel debugger.

Here's my take on the situation:

1) Some function calls fatal("Some message which uses %s", "printf-style args")
2) The string is formatted into a buffer.
3) Kernel grabs hold of the currently active display (could be a user-level service or anything) and asks it for a sanity check (ie. scheduler, processes and everything must be working). If this succeeds, the kernel sends the message to this display (which could display a message box or anything).
4) If the above fails, the kernel vga code takes over, and resets the screen to 80x25 text mode.
5) The message is written straight to video memory.

This is obviously a first design and only works on certain systems, but its a good starting point.

Write a special death-module that can handle the most
basic aspects of VM86 and VESA to show the the
death screen, and make sure it doesn't contain bugs.

...and make sure it doesn't contain bugs.

Why not just apply that to the original kernel?

paulbarker wrote:

...and make sure it doesn't contain bugs.

Why not just apply that to the original kernel?

I think because we all try, but fail. Small things are easier to debug.

none of the options in the poll. I use the serial port to display kernel messages. I have the port on my PC and don't use it for something else., Bochs gives me a nice log file ;D

hmmm.. thinking of it this would fit in the option
> kernel doesn't even know there's a framebuffer