#DF with APIC

[boxcounter]

Hey guys, I have a problem with PIC and APIC, this is it:
My OS is 32-bit, using APIC on a UP bochs "virtual machine". Before setup APIC, I mask all IRQs in both master and slave PIC. When the "sti" instructioin is executed, I got a #DF. All ISR are setup correctlly, they do just one thing - break into bochs debugger(using magic bp). None of them get called before the #DF.

According the "APIC Programming" thread, I remap both master and slave PIC before mask. It works. But I don't understand.

Base on my understanding, remapping is to correct the vectors of every IRQLine. But all IRQLines are masked, cpu should get no PIC IRQ at all. Why remapping works for me ?

Thanks in advance!

[Combuster]

Bochs has excellent logging facilities. You can use them to find out the exact cause of interrupt handler 9 being called.

[boxcounter]

Bochs has excellent logging facilities. You can use them to find out the exact cause of interrupt handler 9 being called.

Thansk for reply.

I checked the log as you suggest, but got nothing. Because I didn'f find a log level option from "man bochsrc", I think I have checked the whole log file.

I put a magic bp before sti and another one in the first line of #DF handler. Here is the log snippet:

00450547098i[CPU0 ] [450547098] Stopped on MAGIC BREAKPOINT
00450547098i[XGUI ] Mouse capture off
00450547099i[XGUI ] Mouse capture off
00450547104i[CPU0 ] [450547104] Stopped on MAGIC BREAKPOINT
00450547104i[XGUI ] Mouse capture off
00450547105i[XGUI ] Mouse capture off

I can't find any clue. Would u please give me some more help? Thanks a lot!

[Combuster]

Because I didn'f find a log level option from "man bochsrc"

But you also didn't read it properly:

Code: Select all

486 .TP
487 .I "debug:"
488 This  setting  tells  Bochs what  to  do  with
489 messages intended to assist in debugging.  You
490 can set  this  to  fatal  (but you shouldn't),
491 report (print information to the  console), or
492 ignore (do nothing). You should generally  set
493 this  to  ignore,  unless  you are  trying  to
494 diagnose a particular problem.
495 
496 .B NOTE:
497 When  action=report,   Bochs   may  spit  out
498 thousands of debug messages per second, which
499 can impact performance and fill up your disk.
500 
501 Example:
502   debug: action=ignore

[boxcounter]

Because I didn'f find a log level option from "man bochsrc"

But you also didn't read it properly:

Code: Select all

486 .TP
487 .I "debug:"
488 This  setting  tells  Bochs what  to  do  with
489 messages intended to assist in debugging.  You
490 can set  this  to  fatal  (but you shouldn't),
491 report (print information to the  console), or
492 ignore (do nothing). You should generally  set
493 this  to  ignore,  unless  you are  trying  to
494 diagnose a particular problem.
495 
496 .B NOTE:
497 When  action=report,   Bochs   may  spit  out
498 thousands of debug messages per second, which
499 can impact performance and fill up your disk.
500 
501 Example:
502   debug: action=ignore

Thanks! Thanks a lot! I fogot the sample file I will reread the manual carefully.

[boxcounter]

Hey, I stll can't find any clue .

Here is the log snippet with "debug: action=report"

00450547098i[CPU0 ] [450547098] Stopped on MAGIC BREAKPOINT
00450547098d[CTRL ] searching for component 'keyboard_mouse' in list 'bochs'
00450547098d[CTRL ] searching for component 'mouse' in list 'keyboard_mouse'
00450547098d[CTRL ] searching for component 'enabled' in list 'mouse'
00450547098d[XGUI ] replacing the mouse bitmaps
00450547098i[XGUI ] Mouse capture off
00450547098d[KBD ] PS/2 mouse disabled
00450547099d[CTRL ] searching for component 'keyboard_mouse' in list 'bochs'
00450547099d[CTRL ] searching for component 'mouse' in list 'keyboard_mouse'
00450547099d[CTRL ] searching for component 'enabled' in list 'mouse'
00450547099d[XGUI ] replacing the mouse bitmaps
00450547099i[XGUI ] Mouse capture off
00450547099d[KBD ] PS/2 mouse disabled
00450547100d[CPU0 ] inhibit interrupts mask = 1
00450547102d[CPU0 ] interrupt(): vector = 08, TYPE = 0, EXT = 1
00450547102d[CPU0 ] interrupt(): INTERRUPT TO SAME PRIVILEGE
00450547104i[CPU0 ] [450547104] Stopped on MAGIC BREAKPOINT

What cause int8(#DF) ?
Thanks.

[Combuster]

It's an external interrupt, and it was already pending since it raises an interrupt directly after the STI.

It makes me believe you didn't actually reconfigure the PIC because then it wouldn't nag for an interrupt.

[boxcounter]

It's an external interrupt, and it was already pending since it raises an interrupt directly after the STI.

It makes me believe you didn't actually reconfigure the PIC because then it wouldn't nag for an interrupt.

Yes, #DF doesn't occur after remapping.

Thanks for your hints, I found out the source of #DF:

There is a pending timer IRQ in master PIC (the value of IRR is 0x1), the default vector offset is 0x8, so vector of the pending timer IRQ is 8, the vector of #DF

So the answer to my first question is remmaping removes all the pending IRQs.

Thanks, Combuster. Thansk a lot

[boxcounter]

I have another question:

How does the timer IRQ be sent to CPU while the IMR is set to 0xFF ?

I've checked the master PIC IMR in #DF handler, it's still 0xFF, not changed by some other part of my os. This can also be proved by log:

136486 00450550389d[PIC ] IO write to 0021 = ff
136487 00450550389d[PIC ] setting master pic IMR to ff
136488 00450550390d[PIC ] IO write to 00a1 = ff
136489 00450550390d[PIC ] setting slave pic IMR to ff
136490 00450550405d[CPU0 ] inhibit interrupts mask = 1
136491 00450550407d[CPU0 ] interrupt(): vector = 08, TYPE = 0, EXT = 1
136492 00450550407d[CPU0 ] interrupt(): INTERRUPT TO SAME PRIVILEGE
136493 00450550409i[CPU0 ] [450550409] Stopped on MAGIC BREAKPOINT

Thansk!