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

[Scott Long]

I looked up this box and it looks pretty interesting, but I don't have 
funds to buy one for myself at the moment.  Is the motherboard logic any 
different from normal NF4 boards?  Could you try booting the FreeBSD 
6.0-bootonly disk to see if at least sysinstall comes up and can talk
to your drives and network chips?

Scott

Matthew Dillon wrote:

>     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
> 
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"