OSDev.org

Brendan:
The image: http://69.194.132.218/2khz.rar

Because it does not output anything other then when it generates an exception, you would just see a blue line when its running good.

Brendan wrote: I've been trying your last boot images (PIT100hz.img and PIT200hz.img) but I haven't been able to get them to crash - I just get a sea of scrolling "tock!!tick"...

Hmm.. well on my bochs it crashs for the 200hz image. After then I started chipping away the source and ended up with the code in the previous post, then it needed to be at a higher timer frequency to cause a GPF.

Brendan wrote: Also, which version of Bochs are you using? I'm using the CVS version from about a month ago...
.....
It might also help to know how you've compiled Bochs - which optimizations were enabled (and possibly if SMP was enabled, as SMP disables some of the optimizations).

I don't use the CVS ones but the released one which is the bochs-2.2.6-win32msvc-src.zip still up in thier website. The only modifcation done was to support your 64KB ISA BIOS. (I've haven't managed to figure out why I can't get the 128KB BIOS working yet, nor can I understand why when I tried to compile Bochs with SMP enabled it hangs after any BIOS post.)

Brendan wrote: Bochs does have bugs but they are extremely rare for common things (like the CPU itself, PIC, PIT, etc).

Wether its me or bochs, I hope its me actually so then I can say I learn something out of this whole deal, but if it is bochs then I'm afraid I've just went through that for nothing.

Brendan wrote: I haven't been able to reproduce the problem and it's still not precise enough to tell exactly where a bug might be in Bochs....

Just wondering.. do you have that show IPS for bochout.txt enabled and using the option clock: sync=realtime, time0=local? It was an important factor for the two images because I've that the 100hz won't GPF but 200hz GPF on realtime setting, I'm not sure why your not getting GPFs...

Brendan wrote: I'm also not sure which instruction/s trigger the GPF or what is on the stack after the GPF (the error code pushed on the stack by the CPU, etc). Also, are all other IRQs masked?

I've now made a more friendly unhandled exception handler which hopefully will answer all those questions. This is what it outputs on GPF:


Dumping register and stack information..

CS=0008h DS=0010h ES=0010h SS=0018h GS=0010h FS=0010h
EAX=80000002h ESI=00094000h EIP=0009016Fh CR0=00000011h
EDX=00000254h EDI=00084000h ESP=00000F4Ch CR2=00000000h
ECX=00000000h EBX=00000000h EBP=00009000h CR3=00000000h

EFLAG=00210286h Reserved checksum (00000002)

IOPL=0 CF=0 PF=1 AF=0 ZF=0 SF=1 OF=0
ID=1 TF=0 IF=0 DF=0 NT=0 RF=1 VM=0 AC=0 VIF=0 VIP=0

ErrorCode=0000013Bh EXT=1 IDT=1 TI=0 Selector: 39 (27h)
ESP [00h]=00000000h
ESP [04h]=00000000h
ESP [08h]=00000000h
ESP [0Ch]=00000000h

Now I know you notice that this is a external error code that is specifying selector 39 (mapped to IRQ 7). At first I did not mask any IRQs, however I always had a #NP handler and confirm it works properly. The only ISR that was installed is IRQ 0, and only IDT was made was 20h for IRQ 0. This would at least what I think would case a #NP if some other IRQ was servicing (Yes the entire area was zero'd before installing ISRs). But no #NP was generated, so I assume its has nothing to do with that nature. However after you metioned it, I did mask all IRQs but the timer. Why the error code is pointed to IRQ 7 (parallel printer interrupt)? I am clueless.

edit: I forgot to mention that it still does generate the same GPF as shown here after masking IRQs.

mystran wrote: Here's a suggestion:

Run Bochs with the-setting-that-shows-current-ips.
Then set that value as your IPS, and try without realtime sync.

If that will reproduce it, then I'd almost guess that you are getting too many nested interrupts or something..

I think this is what you mean, when bochout outputs the IPS:

00000141389i[VBIOS] VBE Bios $Id: vbe.c,v 1.48 2005/12/26 19:50:26 vruppert Exp $
00000170000i[WGUI ] dimension update x=720 y=400 fontheight=16 fontwidth=9 bpp=8
00000380000i[WGUI ] dimension update x=640 y=480 fontheight=0 fontwidth=0 bpp=8
00000423493i[FDD ] controller reset in software
00000424030i[FDD ] io_write: config control register: 0x00
00005210000i[WGUI ] dimension update x=720 y=400 fontheight=16 fontwidth=9 bpp=8

All what was mentioned above was using this setting. I'm not even sure how to enable/disable it. About nesting interrupts.. correct me if I'm wrong if only one ISR can be servicing at a time, once entered to an ISR the processor will disable interrupts, EFLAGS get pushed into stack, and wether interrupts was enable or not it is restored apon return. So, there can't be nested interrupts, unless for unmaskable interrupts which I'm not familiar with yet.


I'm going to also post the PIC remapping code I used that for now is hard coded masking everything but IRQ 0.. Its actually very much the same as the one in the FAQ, however I'm not entirely sure this is the way to mask IRQs.
Thankye both.

Hi,

Ryu wrote:I'm going to also post the PIC remapping code I used that for now is hard coded masking everything but IRQ 0.. Its actually very much the same as the one in the FAQ, however I'm not entirely sure this is the way to mask IRQs.

Code: Select all

[SNIP]
   mov      al, 0FEh      ; mask all but IRQ-0
   out      021h, al
   mov      al, 0FEh      ; mask all but IRQ-0 (not sure if this does anything for slave)
   out      0A1h, al

This isn't quite right - you're enabling IRQ0 and IRQ8, but disabling the "cascade" line (the "IRQ2" line, which isn't IRQ2).

What you'd want is:
Out of curiousity, what would happen if your OS got an IRQ7?

It's a pain in the neck, but the PIC chips can generate a "spurious interrupt", which is normally IRQ7 for PIC1 and IRQ15 for PIC2 (and can't be masked).

The idea is that if the PIC chip's "INTR" line is high then the CPU is meant to wait for the interrupt number to come from a PIC chip. If the PIC chip doesn't know why the INTR line is high then it'll send a spurious interrupt so that the CPU does receive an interrupt number and doesn't get all messed up (i.e. wait forever).

Bochs does emulate this spurious interrupt - see "iodev/pic.cc" around line 807.

Looking at Bochs' code, it looks like the spurious interrupt is sent if the INTR line was high and there's nothing in the PIC's IRR. This includes when PIC2 raises the INTR line but PIC1 has nothing in it's IRR, which should never happen unless the cascade isn't enabled in PIC1 properly.

Adding all of this up for your OS, if anything generates an IRQ8 then you should get a spurious IRQ7 from the master PIC, which would trigger a general protection fault if you haven't got an IRQ handler for IRQ7. It's possible that this is the problem (although I can't think of any reason why you'd be getting an IRQ8).

Anyway, change your PIC chip initialization code, and let us know if it fixes your GPF trouble...


Cheers,

Brendan