IWAMOTO Toshihiro | 5 Sep 14:44 2004

Re: Anyone manage to build mozilla from pkgsrc?

At Fri, 13 Aug 2004 17:59:18 +0200,
Matthias Drochner wrote:
> For pkgsrc/mozilla, it might make sense to use gcc34.

I tried gcc3.4.1 from pkgsrc.
With a single line change related to va_copy thing, mozilla could be
built and installed, but mozilla's stabily was no better (it died
pretty quickly).

IWAMOTO Toshihiro

Christopher SEKIYA | 5 Sep 14:47 2004

Re: Anyone manage to build mozilla from pkgsrc?

On Sun, Sep 05, 2004 at 09:44:29PM +0900, IWAMOTO Toshihiro wrote:

> With a single line change related to va_copy thing, mozilla could be
> built and installed, but mozilla's stabily was no better (it died pretty
> quickly).

Something funny ... mozilla, built from ports, on FreeBSD 5 on identical
hardware, does not crash.

If I had to guess, I'd say that the problem is not toolchain; rather, the
problem is somewhere in threads ...

-- Chris
	GPG key FEB9DE7F (91AF 4534 4529 4BCC 31A5  938E 023E EEFB FEB9 DE7F)

Nicolas Joly | 6 Sep 14:03 2004

-current kernel panic (GENERIC.MP+DDB+DIAGNOSTIC) on amd64


I just upgraded my 2 CPUs amd64 workstation running -current, and
noticed that my custom kernels does work work anymore :

NetBSD 2.0G (KAPUT) #4: Mon Sep  6 13:13:40 CEST 2004
        njoly <at> lanfeust.sis.pasteur.fr:/local/src/NetBSD/obj/amd64/sys/arch/amd64/compile/KAPUT
total memory = 1023 MB
avail memory = 973 MB
mainbus0 (root)
root file system type: ffs
cc_microset[0]: delta 1094470782870000, resetting state
cpu1: CPU 1 running
cc_microset[0]: delta 130000, resetting state
cc_microset[1]: delta 130000, resetting state
panic: TLB IPI rendezvous failed (mask 2)
in pid 1.1 (init) at    netbsd:cpu_Debugger+0x5:
db{0}> bt
cpu_Debugger() at netbsd:cpu_Debugger+0x5
panic() at netbsd:panic+0x1c8
pmap_tlb_shootnow() at netbsd:pmap_tlb_shootnow+0x139
pmap_kremove() at netbsd:pmap_kremove+0x97
uvm_pagermapout() at netbsd:uvm_pagermapout+0x23
genfs_getpages() at netbsd:genfs_getpages+0xbca
ubc_fault() at netbsd:ubc_fault+0x16b
uvm_fault() at netbsd:uvm_fault+0x343
trap() at netbsd:trap+0x307
(Continue reading)

kibumh | 8 Sep 07:35 2004

nforce3-250 stability?

I just saw some _scary_ mails about nforce3.
Can I buy a mainboard based on nforce3-250 w/o any worries?


Kibum Han <kibumh <at> gmail.com>

Bill Russell Nicolas | 9 Sep 12:25 2004

MSI K8N nForce3

Does your patch dated October 22, 2003 allow NetBSD to
run on MSI K8N Neo Platinum mobo with an AMD Athlon 64

Here are the specs of the mobo:

• Supports 64-bit AMD® Athlon™ 64 processor (Socket
• Supports up to 3200+, 3400+, 3700+ or higher CPU


• nVIDIA® nForce3 250Gb Chipset
- Supports Athlon™ 64 processor (Socket 754), 800MHz
Hypertransport interface.
- Supports single memory channels, DDR 400/333/266
without ECC support.
- Supports external AGP 4X/8X
- Integrated Serial ATA interface: dual channel 4
S-ATA RAID controller and dual channel
   ATA 133/100/66/33 master mode EIDE controller.
- Integrated an nVIDIA MAC for Gigabit LAN.
- Supports 8 high speed USB2.0 ports.
- AC'97 2.3 compliance.

Main Memory

• Supports 3 slots for 184-pin DDR SDRAM DIMM modules.
• Supports DDR 400/333/266.
(Continue reading)

Richard Rauch | 15 Sep 08:55 2004

Memory errors. Maybe.

This is a point of curiosity moreso than an immediate request for
answers.  I should be able to cross check (finally) on this issue in
a day or so.  At that point, I hope to know whether what I need to do
is replace the system memory or look at it as a motherboard issue.

Here's the situation: I have an nVidia nForce3 chipset on my motherboard.
This has apparently had problems.  (It's a 150 revision, or whatever...)

NetBSD has problems.  GNU/LINUX has fewer.  The GNU/LINUX mentions an
unresolved BIOS issue, recommends upgrading BIOS, and claims to be
implementing a workaround, but warns that there may still be segfaults.
Even with that unspecified workaround, I've had GNU/LINUX crash.

When I cited this issue on this list before, someone initially said
they thought it wasn't serious, but after investigating thought that
it was more serious than they thought at first.

My motherboard's BIOS did not have an update available since January
or before.  One has recently become available, and I'll be trying
that to see what happens.

I've also run memtest86+ on the system.  (The older memtest86
would not run on this machine.)

The results of memtest86+ are interesting.

On most tests, all looks okay.

On test number 5 ("Block move, 64 moves, cached"), I get about 10
errors on each pass.  The errors are at different addresses each
(Continue reading)

Richard Rauch | 15 Sep 11:45 2004

Re: Memory errors. Maybe.

On Wed, Sep 15, 2004 at 01:55:48AM -0500, Richard Rauch wrote:

I've let memtest86+ run for a while to build up some stats.
(Also, for a little bit yet, I am a bit hampered at getting
the self-extracting BIOS upgrade images into a WIN32 box
to expand them...)

The information may be of some interest to someone so I'm
posting.  And then, it may also remind someone of a problem
that they've had with AMD64 systems and we might find some
common points.

>  b) Errors seem to always come in pairs.  The second one is
>     always approx. 16MB after the first one.  Usually (always?)
>     the second digit is 2 less than the first digit.

 b.1) The difference is (16MB - 0x20).

 b.2) If the second in a pair of errors falls close enough to
      the other (less than a meg, certainly), I saw at least one
      case where you get errors at A, A+16MB-0x20, A+16MB-0x20+<fudge>,
      where <fudge> is some small value---i.e., a triple of errors.
      I only saw a case of this happen at one point.  I know it must
      have happened on other occasions, as the total number of errors
      was odd then even.  I don't know how far apart the "odd man out"
      was from the nearest other error.  This suggests to me a cache
      issue.  (That's a little easier for me to believe than that
      I've had two consective bad memory modules.)

(Continue reading)

Richard Rauch | 17 Sep 14:44 2004

Re: Memory errors. Maybe.

For closure of the thread:

It had been suggested in the past that these problems appeared to
be memory related.  I was incredulous that (a) I was so unlucky to
have had 2 memory modules go bad in succession, and (b) that the
memory that had worked 100% when new had suddenly failed after a
couple of months.  Because of alleged BIOS issues, and not-so-warm
views of the nForce3 that I was getting from some other quarters,
I was reluctant to throw $100 at more memory if I wasn't sure that
the problem was not a CPU or motherboard/BIOS issue.

Off-list, Mike Cheponis very helpfully pointed out that such failure
can occur even after a few months, if the memory falls slightly
out of spec for the performance that it is supposed to maintain.
Mike suggested a fan for the memory.  I was lacking the means to
construct a mounting bracket myself for a regular muffin fan and
unable to get a memory-specific fan off-the-(local)-shelf.  I
settled with a $9 heat-sink.

Even without the thermal paste, the sink seems to have made a
difference.  After 2 complete passes, and ~90% of a third pass
(over 9.5 hours), there are no reported errors.

I'll let it continue a while longer, and then kill the system, put
the thermal paste in the heatsink, and then bring it back up.

Many thanks to Mike for not only diagnosing it as a definite memory
problem, but also diagnosing (or at least correctly theorizing)
the nature of the memory problem and suggesting a very cheap way
to fix it.  (Seeing as I have no other DDR 400 systems, I was
(Continue reading)

David Rio Deiros | 29 Sep 20:41 2004

Dual opteron system, bge driver (fatal protection fault)

Hi all,

I am trying to get working NetBSD (amd-64 port) in a dual opteron 
system (checkout the dmesg output at the end of this email). 
In the core of the system I have a TYAN Thunder K8S PRO motherboard. 
It comes with thre NICs.  One 100MEthernet and two gigabit ethernets 
(BCM5704C chipset). The computer comes with a 3ware 7506 4 ports 
RAID controller. I have a RAID 5 already running.
I installed NetBSD 2.0_BETA (This iso: ftp://ftp.netbsd.org/pub/
Everything seems to work pretty good except the gigabits cards. 
Everytime I try to setup the IP parameters (dhclient or ifconfig
manually) the system gets frozen giving me this error:

fatal protection fault in supervisor mode
trap type 4 code 30b rip ............

Problably this one is not the right place to ask for this but:
I am thinking about updating the sources and recompile the kernel.
Can you please that this is the right way to update to current?:

$ cd /usr/src
$ export CVS_RSH=ssh 
$ cvs update -dP        <-------- Am I updating to current?

I am kind of confuse with the different branches and releases. I didn't
find any document about that. Can you point me about any good document?
Last release is 1.6.2. It should be then two branches, one for security
and important patches (-STABLE) and other one which should be -CURRENT 
which eventually will be 2.0 RELEASE. Is that right?
(Continue reading)

Manuel Bouyer | 29 Sep 22:58 2004

Re: Dual opteron system, bge driver (fatal protection fault)

On Wed, Sep 29, 2004 at 11:41:13AM -0700, David Rio Deiros wrote:
> Hi all,
> [....]
> Everything seems to work pretty good except the gigabits cards. 
> [...]
> NetBSD 2.0_BETA (GENERIC.MP) #0: Thu Apr 22 16:55:07 PDT 2004
> mthomas <at> cerealbox.englab.brocade.com:/u2/netbsd-2-0/amd64/obj/sys/arch/amd64/compile/GENERIC.MP

This is old, you should try a recent kernel from


Manuel Bouyer <bouyer <at> antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference