Nicolas Joly | 1 Jun 11:53 2004
Picon
Picon

Re: Low-memory freezes now fixed

On Mon, May 31, 2004 at 10:46:13PM +0900, Christopher SEKIYA wrote:
> All,
> 
> Thanks to fvdl's patient mentoring, we've isolated the code fragment
> that would cause the amd64 to hang when physical memory became
> exhausted.  My machine has been problem-free for the last 48 hours,
> so things look good ...

This is great ! I just updated my amd64 workstation and i can confirm
that this annoying problem does not occur anymore.

Great job, thanks a lot.

--

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.

Nicolas Joly | 2 Jun 23:04 2004
Picon
Picon

Incorrect kernel threads cuptime after boot


Hi,

I sometimes, but not very often, see that 3 kernel threads (swapper,
pagedaemon and aiodoned) show incorrect cputime just after boot :

njoly <at> lanfeust [~]> top
  PID USERNAME PRI NICE   SIZE   RES STATE      TIME   WCPU    CPU COMMAND
    0 root     -18    0     0K  155M schedu/0    ???  0.00%  0.00% [swapper]
   12 root     -18    0     0K  155M pgdaem/0    ???  0.00%  0.00% [pagedaemon]
   14 root     -18    0     0K  155M aiodon/0    ???  0.00%  0.00% [aiodoned]

njoly <at> lanfeust [~]> sysstat ps
USER      PID %CPU %MEM    VSZ   RSS TT  STAT STARTED       TIME COMMAND
root        0  0.0  0.0      0 158760 ??  DLs   2:21PM  71582788: (swapper)
root       12  0.0  0.0      0 158760 ??  DL    2:21PM  71582788: (pagedaemon)
root       14  0.0  0.0      0 158760 ??  DL    2:21PM  71582788: (aiodoned)

I already experienced this behaviour on 2 of our amd64 machines (2CPUs
and 4CPUs) running -current (2.0F 20040602).

njoly <at> lanfeust [~]> uname -a
NetBSD lanfeust.sis.pasteur.fr 2.0F NetBSD 2.0F (LANFEUST) #2: Wed Jun  2 14:27:13 CEST 2004 
njoly <at> lanfeust.sis.pasteur.fr:/local/src/NetBSD/obj/amd64/sys/arch/amd64/compile/LANFEUST amd64

Is this a known problem ?

Thanks in advance,
Regards.

(Continue reading)

Martin Husemann | 3 Jun 01:02 2004
Picon

Re: Incorrect kernel threads cuptime after boot

On Wed, Jun 02, 2004 at 11:04:34PM +0200, Nicolas Joly wrote:
> I sometimes, but not very often, see that 3 kernel threads (swapper,
> pagedaemon and aiodoned) show incorrect cputime just after boot :

Do you have rtclocaltime=YES in /etc/rc.conf?

Martin

Christopher SEKIYA | 3 Jun 04:07 2004
Picon

Possible fix for resets under heavy load

All,

For those who were experiencing spontaneous reboots under heavy load, please
try the appended patch.  It brings the amd64 pmap into closer alignment with
the i386 pmap; namely, the use of splay tree macros and more cpu locking.
(Also, it removes i386-specific cruft).

It seems to do the right thing on my machine.

If there is no objection, I'll commit it over the weekend and request a
pullup.

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

Index: amd64/pmap.c
===================================================================
RCS file: /cvsroot/src/sys/arch/amd64/amd64/pmap.c,v
retrieving revision 1.9.2.1
diff -u -r1.9.2.1 pmap.c
--- amd64/pmap.c	1 Jun 2004 04:34:52 -0000	1.9.2.1
+++ amd64/pmap.c	2 Jun 2004 08:00:37 -0000
 <at>  <at>  -435,6 +435,24  <at>  <at> 
 #define PVE_HIWAT (PVE_LOWAT + (PVE_PER_PVPAGE * 2))
 					/* high water mark */

+static __inline int
+pv_compare(struct pv_entry *a, struct pv_entry *b)
+{
+	if (a->pv_pmap < b->pv_pmap)
(Continue reading)

Nicolas Joly | 3 Jun 09:58 2004
Picon
Picon

Re: Incorrect kernel threads cuptime after boot

On Thu, Jun 03, 2004 at 01:02:21AM +0200, Martin Husemann wrote:
> On Wed, Jun 02, 2004 at 11:04:34PM +0200, Nicolas Joly wrote:
> > I sometimes, but not very often, see that 3 kernel threads (swapper,
> > pagedaemon and aiodoned) show incorrect cputime just after boot :
> 
> Do you have rtclocaltime=YES in /etc/rc.conf?

No, as i don't have any other OS on that machine.

njoly <at> lanfeust [~]> /etc/rc.d/rtclocaltime rcvar
# rtclocaltime
$rtclocaltime=NO

--

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.

Frank van der Linden | 3 Jun 12:35 2004
Picon

Re: Possible fix for resets under heavy load

On Thu, Jun 03, 2004 at 11:07:00AM +0900, Christopher SEKIYA wrote:
> 
> For those who were experiencing spontaneous reboots under heavy load, please
> try the appended patch.  It brings the amd64 pmap into closer alignment with
> the i386 pmap; namely, the use of splay tree macros and more cpu locking.
> (Also, it removes i386-specific cruft).
> 
> It seems to do the right thing on my machine.
> 
> If there is no objection, I'll commit it over the weekend and request a
> pullup.

Don't remove the "if (lidx != 0)" code.. it's needed to avoid a recursive
lock, since pm_lock is equal to pm_obj[0].vmobjlock.

A cleaner solution is to make pm_lock seperate, init it seperately too,
and use that for global pmap locking.

Make sure to test any changes with LOCKDEBUG.

Also, there is no such thing as i386-specific cruft, since the idea
is to keep the pmaps in sync, and eventually use the same pmap for
both platforms. When I committed the amd64 port, the pmap did work
on i386 too (with modified pmap.h and pte.h files), but I haven't
tested that in a long time, it has probably bitrotted. However,
it is still my intention to merge them.

A pullup isn't a good idea for changes like this without more thorough
testing and making sure it actually fixes the reset problem.

(Continue reading)

Christian Hattemer | 4 Jun 12:31 2004
Picon

Successfull install on Tyan Thunder K8S

Hi,

I've successfully installed a 2.0_BETA on this Tyan Thunder K8S box. At
least this is what the BIOS reports, didn't look inside. It is a dual
Opteron. dmesg is attached.

All is fine, including X. It just doesn't want to boot directly from the
harddisk. I have to boot from CD, interrupt the bootloader and load the
kernel from hd. The hd is an easyRAID (standalone RAID controller). Seems it
doesn't accept the bootloader. Due to a problem with downloading the sets I
had to restart sysinst and it said that the bootsector doesn't look right.
So I let it reinstall the boot stuff. Later I reinstalled the boot
stuff once more by hand, and reinstalled the whole system to use a smaller /
instead of the whole-disk-/ sysinst nowadays suggests. But it still doesn't
boot from hd...

I also tried to build something from pkgsrc using both CPUs. I was told to
use "make -j2" for that, but it produces odd messages (looks like a pkgsrc
debug mode) and fails rather early with being unable to cd to somewhere.
However it seems that both CPUs get some load anyway. Would it still be
faster if -j2 would work? Is this a flaw in pkgsrc?

Bye, Chris

Attachment (dmesg-amd64): application/octet-stream, 7494 bytes
Christopher SEKIYA | 4 Jun 14:17 2004
Picon

Re: Successfull install on Tyan Thunder K8S

On Fri, Jun 04, 2004 at 12:31:21PM +0200, Christian Hattemer wrote:

> It just doesn't want to boot directly from the harddisk.

There's usually a BIOS option like "Support legacy INT19 handling".  This needs
to be turned on -- my Asus K8V needed it before it would boot from HD.

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

Manuel Bouyer | 4 Jun 14:29 2004
Picon

Re: Successfull install on Tyan Thunder K8S

On Fri, Jun 04, 2004 at 12:31:21PM +0200, Christian Hattemer wrote:
> I also tried to build something from pkgsrc using both CPUs. I was told to
> use "make -j2" for that, but it produces odd messages (looks like a pkgsrc
> debug mode) and fails rather early with being unable to cd to somewhere.
> However it seems that both CPUs get some load anyway. Would it still be
> faster if -j2 would work? Is this a flaw in pkgsrc?

It would be faster with -j2, but pkgsrc doesn't really support it.
Something that works for some packages is:
make configure; make MAKE_FLAGS=-j2
The base system can be built with -j.

--

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

Christian Hattemer | 8 Jun 01:21 2004
Picon

Re: Successfull install on Tyan Thunder K8S

Christopher SEKIYA wrote:

>> It just doesn't want to boot directly from the harddisk.
> 
> There's usually a BIOS option like "Support legacy INT19 handling".  This
> needs
> to be turned on -- my Asus K8V needed it before it would boot from HD.

I saw no other INT19 related options beside "Allow option ROMs to capture
INT 19". It was already on and doesn't seem to have to do with the problem.
Wasn't INT19 used to do a reset?

However, while being there I took the chance to have a second look at the
other options and found "Use PCIIDE BusMaster". I enabled that and
reinstalled the bootcode. It boots fine now.

Bye, Chris


Gmane