headers
rudolf | 1 Mar 2006 02:16
Picon

Re: motherboard that will run amd64

Rick Kelly wrote:
> Please, somebody name me a motherboard, which is currently available, that
> will run NetBSD/amd64.
> 
> 

Hi,

this one runs here:
http://tyan.com/products/html/thunderk8sr.html
(model S2881G2NR - no scsi)

NetBSD 3.0 (GENERIC.MP) #0: Sun Dec 18 21:55:15 UTC 2005 
builds <at> works.netbsd.org:/home/builds/ab/netbsd-3-0-RELEASE/amd64/200512182024Z-obj/home/builds/ab/netbsd-3-0-RELEASE/src/sys/arch/amd64/compile/GENERIC
.MP
total memory = 2047 MB
avail memory = 1956 MB
mainbus0 (root)
mainbus0: Intel MP Specification (Version 1.4) (TYAN     S2881       )
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Opteron(tm) Processor 248, 2190.97 MHz
cpu0: features: e7dbfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR>
cpu0: features: e7dbfbff<PGE,MCA,CMOV,PAT,PSE36,MPC,NOX,MMXX,MMX>
cpu0: features: e7dbfbff<FXSR,SSE,SSE2,LONG,3DNOW2,3DNOW>
cpu0: I-cache 64 KB 64B/line 2-way, D-cache 64 KB 64B/line 2-way
cpu0: L2 cache 1 MB 64B/line 16-way
cpu0: ITLB 32 4 KB entries fully associative, 8 4 MB entries fully 
associative
cpu0: DTLB 32 4 KB entries fully associative, 8 4 MB entries fully 
associative
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brett Lymn | 1 Mar 2006 03:07
Picon

Re: Hardware RNG support for EM64T systems

On Thu, Feb 23, 2006 at 07:18:11AM -0600, Travis H. wrote:
> 
> So the Nyquist theorem gives an upper bound, not a complete
> characterization.
> 

Indeed - I was told a story about the dangers of this.  It was a
control system for an automated train system, all the modelling and
simulation showed the system was stable - the train pulled up at the
station and came to an orderly stop.  When it came to the actual
demonstration in front of the big wigs, the train pulled into the
station almost stopped, went back the other way, then came back... in
ever increasing swings.  The monitoring of the control system showed
that it thought that the system was nicely damped and settling as
expected when, in fact, the system was oscillating wildly.  The reason
was that the sample rate was too low and it just happened to coincide
with the natural frequency of the system.

> 
> but cryptanalysis
> is full of examples of non-random structure which were too complex to
> notice right away but once detected could be used against the
> system. 
>

Yes, indeed and by making your system more complex you make it more
difficult to tell if you have a hidden structure there... and there
have been quite a few instances of a seemingly benign modification
totally destroying the utility of the system.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan A. Kollasch | 1 Mar 2006 05:03
Gravatar

X and 4GiB of RAM

Hi,
	Is it normal for an amd64 box that has the memory hole remapping
things turned on to reboot whenever X is started?  I'd really like not to
waste 1/8 of the memory in the system just so X11 works.

	Jonathan Kollasch
Permalink | Reply | 0 comments |
headers
Jonathan A. Kollasch | 1 Mar 2006 05:09
Gravatar

why are so many boards not properly routing interrupts?

Hi,

 As the subject might suggest, I'd like some insight on why many
current amd64 boards are not routing interrupts properly.  For instance,
why can Windows x64 get things working and not us?

I'd also like to know if this could be solved by a BIOS fix.

	Jonathan Kollasch
Permalink | Reply | 2 comments |
headers
Martin Husemann | 1 Mar 2006 10:00
Picon

Re: why are so many boards not properly routing interrupts?

On Tue, Feb 28, 2006 at 10:09:31PM -0600, Jonathan A. Kollasch wrote:
> why can Windows x64 get things working and not us?

There are two more or less obvious answers:

 (a) because vendors of course do test on windows
 (b) because windows has working "autoconf(9)" + ACPI integretion

Martin
Permalink | Reply | 0 comments |
headers
Andrew Reilly | 1 Mar 2006 13:38
Favicon

Re: why are so many boards not properly routing interrupts?

On Tue, Feb 28, 2006 at 10:09:31PM -0600, Jonathan A. Kollasch wrote:
>  As the subject might suggest, I'd like some insight on why many
> current amd64 boards are not routing interrupts properly.  For instance,
> why can Windows x64 get things working and not us?
> 
> I'd also like to know if this could be solved by a BIOS fix.

Not a fix as such, but perhaps a hint for a work-around:

I managed to make my GA-K8NF-9 board happily use a plug-in Intel
21143 PCI network card by forcing the PCI slot->interrupt
mapping in the BIOS, rather than leaving it at the default
"auto".  Before this it had always just "timed out", and
basically didn't work, even though it probed OK.

Unfortunately the BIOS on this board doesn't let me do the same
thing for the on-board peripherals, or else I suspect that the
NVidea MCP9 GBE interface on the board might work a bit better.

Something to try, anyway.

--

-- 
Andrew
Permalink | Reply | 0 comments |
headers
Thor Lancelot Simon | 1 Mar 2006 20:46

Bug in x86 ioapic interrupt code for devices with shared interrupts?

One of the NetBSD Foundation servers is a dual-Opteron with an onboard
dual Broadcom gigabit chip.  This chip, as far as I can tell from some
experiments, gets seriously disturbed by the driver's tendency to
acknowledge interrupts even if they're not actually from the device.

But there aren't any such interrupts, in usual operation, until I plug in
an LSI MegaRAID card in one of the system's PCI-X slots.  Then, this
happens:

	1) The MegaRAID gets the same *IRQ* assigned as the first
	   function on the Broadcom chip (which we probe as bge0).

	2) However, these devices are on *different* ioapics (this
	   system has three) so, as far as I can tell, the x86
	   interrupt code _should_ not ever deliver interrupts from
	   the MegaRAID to the driver for the bge, or vice-versa.

	3) Nonetheless, that is precisely what appears to happen,
	   with the consequence that the bge quickly locks up.  It
	   may be the case that the reverse is happening as well,
	   but I haven't managed to test this.

The system is running a uniprocessor amd64 kernel with options MPACPI
and MPACPI_SCANPCI.  It is currently in transit to a new location, so
I can't post a dmesg, but I believe the above gives all the relevant
details.

I wonder if some problem like this one is responsible for other interrupt
problems on the amd64 port as well.  I thought we did not use the IRQ for
anything if ioapic was in use, and the code does basically look that way
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rick Kelly | 2 Mar 2006 17:29

Gigabyte board with -current


Board: Gigabyte GA-K8N51GMF-9
OS: NetBSD-current from last night

This looks a lot better that 3.0.

I put in an fxp network card and an ATI graphics card. I disabled the
on-board video.

Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 3.99.15 (GENERIC) #0: Wed Mar  1 22:22:43 MST 2006
	rmk <at> speedy:/usr/obj/sys/arch/amd64/compile/GENERIC
total memory = 511 MB
avail memory = 483 MB
mainbus0 (root)
mainbus0: Intel MP Specification (Version 1.4) (OEM00000 PROD00000000)
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Athlon(tm) 64 Processor 3400+, 2210.17 MHz
cpu0: features: e7dbfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR>
cpu0: features: e7dbfbff<PGE,MCA,CMOV,PAT,PSE36,MPC,NOX,MMXX,MMX>
cpu0: features: e7dbfbff<FXSR,SSE,SSE2,LONG,3DNOW2,3DNOW>
cpu0: I-cache 64 KB 64B/line 2-way, D-cache 64 KB 64B/line 2-way
cpu0: L2 cache 512 KB 64B/line 16-way
cpu0: ITLB 32 4 KB entries fully associative, 8 4 MB entries fully associative
cpu0: DTLB 32 4 KB entries fully associative, 8 4 MB entries fully associative
cpu0: calibrating local timer
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Johnson | 2 Mar 2006 19:48

Any NetBSD support for Infiniband / ipoib?

    Is anyone aware of any driver projects for Infiniband and ip over 
infiniband? I have found nothing after exhaustive googling, FAQ and 
source reading.

--Jeff

--

-- 

"Abra Capocus" - Bugs Bunny
Permalink | Reply | 0 comments |
headers
Jason Thorpe | 3 Mar 2006 17:49

Re: Bug in x86 ioapic interrupt code for devices with shared interrupts?


On Mar 1, 2006, at 11:46 AM, Thor Lancelot Simon wrote:

> One of the NetBSD Foundation servers is a dual-Opteron with an onboard
> dual Broadcom gigabit chip.  This chip, as far as I can tell from some
> experiments, gets seriously disturbed by the driver's tendency to
> acknowledge interrupts even if they're not actually from the device.

This is a bug in bge(4), plain and simple.  It should not acknowledge  
the interrupt if it did not generate it, period.

-- thorpej
Permalink | Reply | 0 comments |

Gmane