Side note on Shuttle XPC / AMD X2 (SN95G5V3) (Re: [PATCH] nve(4) locking cleanup)

From: Matthew Dillon <dillon_at_apollo.backplane.com>
Date: Thu, 17 Nov 2005 11:15:00 -0800 (PST)
    I haven't tried booting FreeBSD on my Shuttle XPC / AMD X2 based box,
    but if you have users that are and are hitting either of the following
    two problems, then I was able to implement a solution for DragonFly:

    Problem #1: 

	ICU (traditional 8259) interrupt routing build:  IRQ 7 recieves 
	an unmaskable interrupt for every real interrupt that occurs on
	the system.  Interrupt vector 7 is issued no matter how the 8259
	or LAPIC is programmed.

    Solution:

	This occurs because the '8259' is routed to the cpu via the 
	hypertransport bus, and the Shuttle BIOS has not set the bit
	in the Hyper Transport Transaction Control Register that routes
	it to the LAPIC.  If you have an AMD X2 cpu, the 8259 interrupt
	winds up being routed to BOTH cpus.  BOTH cpus issue an INTA 
	cycle, and of course one of those cycles will always cause the 8259
	to return a spurious interrupt vector (whether the interrupt is
	masked or not).

    DragonFly Commit:

	http://leaf.dragonflybsd.org/mailarchive/commits/2005-11/msg00038.html

    --

    Problem #2:

	MPTable has an entry for IRQ 14 but not IRQ 15.  This can cause
	the ATA driver to lock the system up while attempting to access
	the CD.

    Solution:

	If using the MPTable, a fixup is required.

    DragonFly Commit:

	http://leaf.dragonflybsd.org/mailarchive/commits/2005-10/msg00095.html

    --

    Problem #3:

	ACPI and/or MPTable based interrupt routing is completely broken
	for SMP builds.  The tables report interrupt routing pins > 23
	on a motherboard which only has one IO APIC with only 24 bits (0-23).
	Interrupts cannot be properly routed.

	In addition, note that traditional ISA interrupts will not be 
	properly routed or be properly maskable unless you implement the
	solution for Problem #1.  It is unclear whether this motherboard
	even *routes* the traditional ISA interrupts to the IO APIC at all.
	I assume it must, but I gave up on that line of investigation once
	I managed to get SMP to work with ICU interrupt routing.

	Note that DFly is still running the 'old' ACPI interrupt routing
	code, so FreeBSD's ACPI might (or might not) do a better job.

    Solution:

	ICU mode must be used.  With the fix for Problem #1 in place, ICU
	mode *CAN* be used with the LAPIC's active, and thus can be used 
	while running SMP.

    (For DragonFly I made it possible to build SMP without APIC_IO.  I seem
    to recall that FreeBSD has a similar problem).

						-Matt
Received on Thu Nov 17 2005 - 18:16:39 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:47 UTC