Re: Side note on Shuttle XPC / AMD X2 (SN95G5V3) (Re: [PATCH] nve(4)
Scott Long
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...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
Scott Long
Matthew Dillon
Matthew Dillon
Matthew Dillon
:
:I looked up this box and it looks pretty interesting, but I don't have
: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
I'd be happy to. If you point me at an ISO image I can boot it up and
try to run through the install. Even better if its SMP (I think all
FreeBSD distributions are SMP by default now, right?).
I suspect that the MB logic is considerably different. I have an
ASUS A8N-SLI Deluxe NF4 system as well (its our package building box),
also with an AMD X2 in it, and it did not exhibit any of the problems
I have had with the shuttle.
The ASUS has a different ethernet device... sk driver instead of nv.
The BIOS on that MB also reports reasonable numbers in the MPTable and
otherwise seems to be less confused then Shuttle's BIOS. The MP Table
on the ASUS lists 6 pure PCI busses while the one on the Shuttle
lists only 3. Both MB's have only one IO APIC. The BIOSes are clearly
very different. Shuttle's is more 'raw'.
Matthew Dillon
Joseph Gelinas
> :
> :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
>
> I'd be happy to. If you point me at an ISO image I can boot it up and
> try to run through the install. Even better if its SMP (I think all
> FreeBSD distributions are SMP by default now, right?).
>
> I suspect that the MB logic is considerably different. I have an
> ASUS A8N-SLI Deluxe NF4 system as well (its our package building box),
> also with an AMD X2 in it, and it did not exhibit any of the problems
> I have had with the shuttle.
>
> The ASUS has a different ethernet device... sk driver instead of nv.
> The BIOS on that MB also reports reasonable numbers in the MPTable and
> otherwise seems to be less confused then Shuttle's BIOS. The MP Table
> on the ASUS lists 6 pure PCI busses while the one on the Shuttle
> lists only 3. Both MB's have only one IO APIC. The BIOSes are clearly
> very different. Shuttle's is more 'raw'.
>
> -Matt
>
-Current's GENERIC has SMP enabled by default (and the nve driver) so I
would assume the recent snapshots would have it enable as well.
ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/Nov_2005/7-CURRENT-SNAP009-amd64-bootonly.iso