patch for amd64 asm string functions

I'd like to hear opinions on the following:

I've been using the amd64 string functions
(src/common/lib/libc/arch/x86_64/string/) modified by
<fuyuki <at> hadaly.org> (see netbsd-bugs in January)
for months now without incident (except when troubleshooting to make
sure that it wasn't a problem).  I have an EMT64 processor, and after
rebuilding the tree with -mtune=nocona and applying this patch, the
system is noticeably faster.  I have confirmed the results he spoke of
in his emails to netbsd-bugs with his memcpy benchmark (see:
<http://www.hadaly.org/fuyuki/>).

Also, when we move to gcc 4.2, we should probably build the tree with
-mtune=generic, which tunes fairly for both AMD and Intel processors.
Until then--according to what I've read on the GCC lists and such--the
best thing to do is use --mtune=nocona, as the performance hit for AMD
processors is negligable (they do, after all, have to compete, and
that means running code optimized for Intel processors).  On the other
hand, EMT64 processors pay a substantial price (up to 20% loss in some
benchmarks I've seen) for -mtune=k8 (from -march=k8, our default).  I
don't think there's much of a difference between -march=nocona and
-mtune=nocona anyway, especially now that Intel has cloned AMD's
instruction set more faithfully.

The only thing I changed from the author's original patch is adding an
#ifdef _KERNEL...#endif at lines 62 and 81 of memset.S, as the kernel
doesn't do huge memcpy operations AFAIK, and so using the hints there
has virtually no chance of being productive and a substantial chance
of being counterproductive.

Sun Fire X2100

Hello,

Does NetBSD/amd64 work well on a Sun Fire X2100 server?  Is any of the
hardware not recognised by NetBSD?

Thanks,
  - Andy Ball

Re: Sun Fire X2100

On Mon, Aug 06, 2007 at 07:21:39PM -0000, Andrew Ball wrote:
> Does NetBSD/amd64 work well on a Sun Fire X2100 server?  Is any of the
> hardware not recognised by NetBSD?

Here's a dmesg (GENERIC kernel with acpi and acpibut added).

	Geert

NetBSD 3.1 (GENERIC_ACPI) #0: Sun Oct 29 13:51:32 CET 2006
	geert <at> noc.ghen.be:/scratch/obj/sys/arch/amd64/compile/GENERIC_ACPI
total memory = 1022 MB
avail memory = 969 MB
mainbus0 (root)
mainbus0: Intel MP Specification (Version 1.4) (OEM00000 PROD00000000)
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Opteron(tm) Processor 148, 2211.45 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
cpu0: calibrating local timer
cpu0: apic clock running at 201 MHz
cpu0: 16 page colors
mpbios: bus 0 is type PCI   
mpbios: bus 1 is type PCI   
mpbios: bus 2 is type PCI   

Re: Sun Fire X2100

Hello Geert,

  GH> Here's a dmesg (GENERIC kernel with acpi and acpibut added).

That was helpful.  It looks generally positive.  I think many of the
devices that show up as not configured at acpi0 are recognised later
on via more conventional means.  Do you notice any ill effect from
other "not configured" devices?

Thanks,
  - Andy Ball

Re: Sun Fire X2100

On Tue, Aug 07, 2007 at 02:38:24PM -0000, Andrew Ball wrote:
> 
> Hello Geert,
> 
>   GH> Here's a dmesg (GENERIC kernel with acpi and acpibut added).
> 
> That was helpful.  It looks generally positive.  I think many of the
> devices that show up as not configured at acpi0 are recognised later on
> via more conventional means.  Do you notice any ill effect from other
> "not configured" devices?

I've only enabled acpibut(4), combined with powerd(8) so the server shuts
down properly when I press the button.  Furthermore I have the optional
IPMI board for remote management, but it isn't so great.  With NetBSD 4.x
you should be able to query some hardware sensors via the new ipmi(4)
driver but I haven't tested that yet.  I briefly tested NetBSD 4.0_BETA2
but quickly ran into lfs-related panics, but NetBSD 3.1 has been running
flawlessly.

	Geert

Re: Sun Fire X2100

Hello Geert,

  GH> I briefly tested NetBSD 4.0_BETA2 but quickly ran into lfs-
    > related panics, but NetBSD 3.1 has been running flawlessly.

Hopefully the 4.0_BETA2 problems reflect its pre-release nature.  It's
great to hear that 3.1 works.  Thanks a lot for your help.

- Andy Ball

ushare (wip)

Hi All,

	Small problem with ushare on the amd64 platfrom (NetBSD 3.1)

	After installing the above packages, modifying /usr/pkg/etc/ushare.conf and 
trying to run ushare I get the following:

	sysctl: no such file or directory

	I'm not sure whether the problem lies with ushare or libupnp and I'm assuming 
this is purely an amd64 problem, as this ushare ran flawlessly under i386 
3.1 - anybody have any ideas?

Thanks in advance,
Pete.

--

-- 
Real programmers don't comment their code - it was hard to write it should be 
hard to understand.

http://www.teraqube.co.uk

ushare (wip)

Hi All,

	Small problem with ushare on the amd64 platfrom (NetBSD 3.1)

	After installing the above package, modifying /usr/pkg/etc/ushare.conf and 
trying to run ushare I get the following:

	sysctl: no such file or directory

	I'm not sure whether the problem lies with ushare or libupnp and I'm assuming 
this is purely an amd64 problem, as ushare ran flawlessly under i386 3.1 - 
anybody have any ideas?

Thanks in advance,
Pete.

--

-- 
Real programmers don't comment their code - it was hard to write it should be 
hard to understand.

http://www.teraqube.co.uk

WARNING: SPL NOT LOWERED ON SYSCALL 0 0 EXIT

We just got one of these on the pkgsrc bulk-build machine, which is a
4-core (2 x dual-core Opteron) amd64 machine.  Unfortunately, as one
can see from the traceback below, well, it's a bit hard to get a
traceback.

The kernel is -current as of today, cross-compiled on macppc for various
obscure reasons.  Any ideas what causes this?  I am a bit curious about
Opteron erratum 106: 

http://lists.freebsd.org/pipermail/freebsd-amd64/2005-May/004693.html

WARNING: SPL NOT LOWERED ON SYSCALL 0 0 EXIT 536e08 d 
^MStopped in pid 21631.1 (cat) at netbsd:Xsyscall+0x1dd:  movl
$0,%gs:0x28c(%
ri
^Mp)
^Mdb{1}> trace   ^H ^H^H ^H^H ^H
^MXsyscall() at netbsd:Xsyscall+0x1dd
^Mcpu1: spinout while in debugger

--and it then hangs so hard I can't drop back to DDB.  Next time I will
try to get a core, without the traceback, but I'm not optimistic.

--

-- 
  Thor Lancelot Simon	                                     tls <at> rek.tjls.com

  "The inconsistency is startling, though admittedly, if consistency is to
   be abandoned or transcended, there is no problem."	      - Noam Chomsky

Re: WARNING: SPL NOT LOWERED ON SYSCALL 0 0 EXIT

On Sun, Aug 12, 2007 at 10:57:24PM -0400, Thor Lancelot Simon wrote:

> We just got one of these on the pkgsrc bulk-build machine, which is a
> 4-core (2 x dual-core Opteron) amd64 machine.  Unfortunately, as one
> can see from the traceback below, well, it's a bit hard to get a
> traceback.
> 
> The kernel is -current as of today, cross-compiled on macppc for various
> obscure reasons.  Any ideas what causes this?  I am a bit curious about
> Opteron erratum 106: 
> 
> http://lists.freebsd.org/pipermail/freebsd-amd64/2005-May/004693.html

I'll have a look into that. I have new TLB shootdown code for x86 almost
ready to go in.

> WARNING: SPL NOT LOWERED ON SYSCALL 0 0 EXIT 536e08 d 

That should be showing the syscall number but I strongly suspect that
it's broken.

> ^MStopped in pid 21631.1 (cat) at netbsd:Xsyscall+0x1dd:  movl
> $0,%gs:0x28c(%
> ri
> ^Mp)
> ^Mdb{1}> trace   ^H ^H^H ^H^H ^H
> ^MXsyscall() at netbsd:Xsyscall+0x1dd
> ^Mcpu1: spinout while in debugger

If it happens again, can you get the value of %esp from 'show regs' and