OSDev.org

hello..
Uptill now i was using my own custom bootloader to load my OS. But now as i moved to hard disks.. I need GRUB for this work. GRUB is loading my OS and everything goes fine. But as soon as an outportb function is called, bochs2.2 collapse with:
00000004163i[BIOS ] rombios.c,v 1.138 2005/05/07 15:55:26 vruppert Exp $
00000330070i[KBD ] reset-disable command received
00000480000i[WGUI ] dimension update x=720 y=400 fontheight=16 fontwidth=9 bpp=8
00002463390i[BIOS ] ata0-0: PCHS=10/16/63 translation=none LCHS=10/16/63
00002481033e[HD ] device set to 1 which does not exist
00013990284e[CPU0 ] exception(): 3rd (14) exception with no resolution, shutdown status is 00h, resetting
00013990284i[SYS ] bx_pc_system_c::Reset(SOFTWARE) called
00013990284i[APIC0] local apic in CPU apicid=00 initializing
00013994447i[BIOS ] rombios.c,v 1.138 2005/05/07 15:55:26 vruppert Exp $
00014320050i[KBD ] reset-disable command received
00016455551i[BIOS ] ata0-0: PCHS=10/16/63 translation=none LCHS=10/16/63
00016473194e[HD ] device set to 1 which does not exist
00016484292p[BIOS ] >>PANIC<< floppy recal:f07: ctrl not ready

The error is ">>PANIC<< floppy recal:f07: " although my floppy driver comes too late.. it get collapse in my IDT section where i am initializing PIC.

The code is working fantastically when i am using my boot loader.. And ya i am not much dependent on custom bootloader except E820 memory map.. Now i am using the one from GRUB...

It might help us debug it for you if you show the code where it fails, indicating which line causes that error to occur.

hi... It crash in the first place where outportb is called..

Hi,

viral wrote: Uptill now i was using my own custom bootloader to load my OS. But now as i moved to hard disks.. I need GRUB for this work. GRUB is loading my OS and everything goes fine. But as soon as an outportb function is called, bochs2.2 collapse with:

The problem with your code is that it's triple faulting due to a page fault.

For a recent version of Bochs, add something like this in your "bochsrc.txt" file:

cpu: count=1, ips=11000000, reset_on_triple_fault=0

If this doesn't work (i.e. if your version of Bochs is old) then upgrade it to version 2.2.6. I think the old versions of Bochs had a "./configure" option to set the "reset_on_triple_fault" behaviour, but they've fixed enough bugs since the old versions that upgrading makes more sense anyway.

Once you've done this Bochs will stop when a triple fault occurs (instead of resetting) so that you can look in the Bochs log to see where it crashed and what was in the registers at the time...

The trouble with the floppy that occurs after the triple fault/reset might be caused by Bochs forgetting to reset something properly - if it did reset everything properly then everything would work the same as it did the first time it booted, and you'd get continuous triple faults...


Cheers,

Brendan

Where is PIC1 defined and to what?

Where is PIC1 defined and to what?

#define PIC1 0x20
#define PIC2 0xA0

Brendan is right, the line: means that you're getting a triple-fault causing bochs to reset.
What makes you sure that this triple-fault is being caused by that outportb line?

Hi,

bkilgore wrote: Brendan is right, the line:

Code: Select all

00013990284e[CPU0 ] exception(): 3rd (14) exception with no resolution, shutdown status is 00h, resetting

means that you're getting a triple-fault causing bochs to reset.
What makes you sure that this triple-fault is being caused by that outportb line?

I'm only guessing, but I'd assume that the outportb line has nothing to do with the triple fault at all. My reasoning is that an "out 0x20,al" instruction doesn't access memory (except for EIP), and that it looks like accessing the code and stack isn't a problem (otherwise it would've triple faulted before the outportb line).

While I'm still guessing, I'd assume that when the OS first boots it goes past the outputb line correctly and the triple fault occurs after that. My reasoning here is that if it triple faulted the first time it should triple fault the second time. It seems obvious that the second time around something is different, but the code itself is the same which makes it seem likely that there's different "hardware state" the second time around (or that Bochs or the BIOS failed to reset something properly).

There is another possible reason why it might triple fault the first time but have trouble at the "outputb" line the second time - your code might rely on uninitialized data. When Bochs first starts all memory is full of zeros, but after some of your code has run it'd fill some of the memory with non-zero values. These non-zero values would remain after reset. It's for cases like this I put a "fill all memory with 0xCC" option into my Bochs BIOS ::).

Of course all of that guessing does leave a lot of room for me to be wrong somewhere - without more information (like working out where the triple fault is coming from) it's hard to do more than guess...

Anyway, I'd recommend finding and fixing the triple fault first, and then finding the second fault (the "outputb" line problem). If the second fault is caused by something Bochs is doing wrong during reset then you can ignore it, but if it's caused by your code relying on uninitialized data or something then you'd want to fix that too (even if the "outputb" problem goes away once the triple fault is fixed).


Cheers,

Brendan

Goooo Bendan's BIOS! *adds another stone on Brendan's side*

i'd say the best way for you to find out would be to use bochs' internal debugger, set a breakpoint at your kernel entry point ("pb 0x100000" if you're starting at 1MB, for instance) and then do "cpu-trace on" to see what's actually happening.

I can think of EIP going out of code segment
I can think at wrong DPL and system trying to look for an IO bitmap
I can think of an incomplete kernel loading and garbage being found where you expected "outportb" to stand ...

none of these are really convincing, so you're probably better to do the "trace on" thing ...

what about an irq fired ere IDT is loaded properly (and stuffed with pointers to handlers as is due)?

Just a shot in the dark ...

If I were you, I'd keep irq's disabled and check out the code - how does it behave with irq's locked away?