[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] possible pic misbehaviour
From: |
Herbert Poetzl |
Subject: |
[Qemu-devel] possible pic misbehaviour |
Date: |
Mon, 22 May 2006 06:05:36 +0200 |
User-agent: |
Mutt/1.5.6i |
Hi Folks!
I started to play around with installing
NEXT/OPENSTEP last week and despite some
postings stating that it works 'somewhat'
I encountered several issues so far ...
the good news (for me) is that I could
resolve all of them and have it running
quite fine. now to the topic ...
one thing I had to modify was the pic
(i8259) behaviour, in a way which isn't
really obvious from the docs, even worse
the implementation seems to match the
intel documentation perfectly
nevertheless as both operating systems
NEXTSTEP and OPENSTEP seem to require
my (or a similar/better) modification to
handle interrupts correctly, and both
do run quite fine on real hardware, I
suspect a non-obvious deviation in the
implementation.
here is the 'hack' I did to make it work
--- hw/i8259.c 2006-05-22 03:54:47.000000000 +0200
+++ hw/i8259.c 2006-05-22 03:54:47.000000000 +0200
@@ -119,7 +119,7 @@ static int pic_get_irq(PicState *s)
master, the IRQ coming from the slave is not taken into account
for the priority computation. */
mask = s->isr;
- if (s->special_fully_nested_mode && s == &s->pics_state->pics[0])
+ if (/* s->special_fully_nested_mode && */ s == &s->pics_state->pics[0])
mask &= ~(1 << 2);
cur_priority = get_priority(s, mask);
if (priority < cur_priority) {
here is the initialization sequence
observed (debug output) on the pics:
init[0,ICW1] = 11
init[1,ICW1] = 11
init[0,ICW2] = 08
init[1,ICW2] = 70
init[0,ICW3] = 04
init[1,ICW3] = 02
init[0,ICW4] = 01
init[1,ICW4] = 01
init[0,ICW1] = 11
init[0,ICW2] = 40
init[0,ICW3] = 04
init[0,ICW4] = 01
init[1,ICW1] = 11
init[1,ICW2] = 48
init[1,ICW3] = 02
init[1,ICW4] = 01
according to the specs, the full featured
mode is 'initially' turned on unless it
is specified otherwise (which is not the
case in the current implementation), but
the observed init sequence IMHO turns it
off again (ICW4=1), but without this or
some other AEOI functionality the first
irq on the slave pic will basically hang
the OS as the interrupt is not cleared on
the master ...
probably I just missed the obvious, but
I thought I'd better report that here ...
best,
Herbert
PS: will send a few more changes shortly
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-devel] possible pic misbehaviour,
Herbert Poetzl <=