John Baldwin wrote:
On Monday 28 November 2005 04:51 pm, Scott Long wrote:
John Baldwin wrote:
On Monday 28 November 2005 04:06 pm, Scott Long wrote:
John Baldwin wrote:
On Monday 21 November 2005 01:39 pm, John Baldwin wrote:
jhb 2005-11-21 18:39:17 UTC
FreeBSD src repository
Modified files:
sys/amd64/amd64 machdep.c
Log:
Expand the hack to mask the atpics if 'device atpic' is not in the
kernel during boot up. Now we do a full reset of the 8259As and setup
a simple interrupt handler (we actually borrow the apic one that just
does an immediate iret) to handle any spurious interrupts triggered by
either chip. This should fix some folks that were getting a Trap 30
during bootup of certain SMP AMD systems. This might get pushed into
the 6.0 branch as an errata. For now a suitable workaround is to add
'device atpic' to your kernel config.
Tested by: scottl
Helpful info from: dillon
MFC after: 1 week
Hmm, we probably still need to reprogram the ATPIC on resume as well.
I'm not sure it's actually worth not just compiling the atpic code in on
amd64.
Problems aside, what are the benefits to not having the atpic
unconditionally included on amd64?
Purely space savings. It's whatever the size of atpic.o, elcr.o, and the
bits of atpic_vector.S that make it into exception.o are.
Ok, so it doesn't cut down on runtime overhead? The file sizes look to
be:
atpic.o 15k
elcr.o 2.5k
exception.o 200byte delta
No, there isn't any effect on runtime.
If, down the road, a motherboard shows up without an atpic or one that
is horribly broken, would we be worse off for having the atpic code in
there?
Well, both i386 and amd64 assume an atpic is there. Even if you don't include
'device atpic' on amd64, we do the manual bit banging to the I/O ports that
assume it is there in the code I just changed.
So yeah, might as well just make it conditional then.
Scott
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
