headers
Christian Biere | 1 Feb 2007 03:40
Picon
Picon
Gravatar

Re: port-alpha/35448: memory management fault trap during heavy network I/O

The following reply was made to PR port-alpha/35448; it has been noted by GNATS.

From: Christian Biere <christianbiere <at> gmx.de>
To: gnats-bugs <at> NetBSD.org
Cc: 
Subject: Re: port-alpha/35448: memory management fault trap during heavy network I/O
Date: Thu, 1 Feb 2007 03:37:52 +0100

 Michael L. Hitch wrote:
 >     Changing the UIO_ADVANCE() to a UIO_RETREAT() which passed 'backup' 
 >  directly and subtracted that from iov_base, and added it to iov_len gave 
 >  me a kernel which did not crash when nfs_writerpc() resent the data.  I've 
 >  also just verified that simply making 'backup' a signed 32 bit also works 
 >  using the UIO_ADVANCE() macro.

 I'd prefer the former because it's cleaner. I take "advance" as a strong
 emphasis that it's meant to move forward. At least I've written a similar
 function before and decided against the more flexible term "add" for
 exactly this reason.

 
 --- sys/nfs/nfs_vnops.c.orig	2007-01-26 21:52:50.000000000 +0100
 +++ sys/nfs/nfs_vnops.c	2007-02-01 03:21:00.000000000 +0100
  <at>  <at>  -251,10 +251,22  <at>  <at>  extern const nfstype nfsv3_type[9];

  int nfs_numasync = 0;
  #define	DIRHDSIZ	_DIRENT_NAMEOFF(dp)
 -#define UIO_ADVANCE(uio, siz) \
 -    (void)((uio)->uio_resid -= (siz), \
 -    (uio)->uio_iov->iov_base = (char *)(uio)->uio_iov->iov_base + (siz), \
(Continue reading)

Permalink | Reply | 0 comments |
headers
hallmann | 1 Feb 2007 10:20
Picon

misc/35534: /etc/rc.d/amd does not set /var/run/amd.pid

>Number:         35534
>Category:       misc
>Synopsis:       /var/run/amd.pid exists but is an empty file
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    misc-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Thu Feb 01 09:20:01 +0000 2007
>Originator:     AHA
>Release:        NetBSD 3.1_STABLE
>Organization:
	Hallmann EDV Dienstleistungen
	Hallmann IT Services 
>Environment:
System: NetBSD kukalda 3.1_STABLE NetBSD 3.1_STABLE (GENERIC.MP) #6: Sun Nov 5 07:19:12 CET 2006
root <at> kukalda:/export/work/build.objs/i386/3.0/export/netbsd/netbsd-3-0/src/sys/arch/i386/compile/GENERIC.MP i386
Architecture: i386
Machine: i386
>Description:
	/etc/rc.d/amd does not set up /var/run/amd.pid correctly.
	/var/run/amd.pid exists but is an empty file.
>How-To-Repeat:
	On a system running amd:
	cat /var/run/amd.pid 
>Fix:
	Sorry, not that used to rc.d magic
(Continue reading)

Permalink | Reply | 0 comments |
headers
fuyuki | 1 Feb 2007 12:20

lib/35535: memcpy() is very slow if not aligned

>Number:         35535
>Category:       lib
>Synopsis:       memcpy() is very slow if not aligned
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    lib-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Thu Feb 01 11:20:00 +0000 2007
>Originator:     Kimura Fuyuki
>Release:        4.99.9
>Organization:
>Environment:
NetBSD lapis.hadaly.org 4.99.9 NetBSD 4.99.9 (LAPIS) #59: Thu Feb  1 16:18:21 JST 2007 
fuyuki <at> lapis.hadaly.org:/usr/obj/sys/arch/amd64/compile/LAPIS amd64
>Description:
On NetBSD/amd64 (perhaps in i386 too) memcpy() could be very slow because no alignment effort has been
taken place.
Sometimes it is very difficult or impossible for applications to align the dest addr so that the minimal
effort should be taken in the library code.

>How-To-Repeat:
Use the following benchmark program to see the the unaligned memcpy() is so slow.

http://www.hadaly.org/fuyuki/memcpy_bench.c

<plain libc>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matt Fleming | 1 Feb 2007 12:40
Picon

Re: misc/35534: /etc/rc.d/amd does not set /var/run/amd.pid

The following reply was made to PR misc/35534; it has been noted by GNATS.

From: Matt Fleming <mjf <at> NetBSD.org>
To: gnats-bugs <at> NetBSD.org
Cc: 
Subject: Re: misc/35534: /etc/rc.d/amd does not set /var/run/amd.pid
Date: Thu, 1 Feb 2007 11:35:12 +0000

 Could you please provide more information about how you start amd. Is
 there an "amd=YES" line in your rc.conf? And could you paste the command_args
 line from /etc/rc.d/amd. Thanks!

 --mjf
Permalink | Reply | 0 comments |
headers
Andreas_Hallmann | 1 Feb 2007 12:55
Picon

Re: misc/35534: /etc/rc.d/amd does not set /var/run/amd.pid

The following reply was made to PR misc/35534; it has been noted by GNATS.

From: Andreas_Hallmann <hallmann <at> ahatec.de>
To: gnats-bugs <at> NetBSD.org
Cc: 
Subject: Re: misc/35534: /etc/rc.d/amd does not set /var/run/amd.pid
Date: Thu, 1 Feb 2007 12:53:01 +0100

 On Thu, Feb 01, 2007 at 11:40:02AM +0000, Matt Fleming wrote:
 > The following reply was made to PR misc/35534; it has been noted by GNATS.
 > 
 > From: Matt Fleming <mjf <at> NetBSD.org>
 > To: gnats-bugs <at> NetBSD.org
 > Cc: 
 > Subject: Re: misc/35534: /etc/rc.d/amd does not set /var/run/amd.pid
 > Date: Thu, 1 Feb 2007 11:35:12 +0000
 > 
 >  Could you please provide more information about how you start amd. Is
 >  there an "amd=YES" line in your rc.conf? And could you paste the command_args
 >  line from /etc/rc.d/amd. Thanks!
 >  

 # grep amd /etc/rc.conf 
 amd=YES amd_flags="-F /etc/amd/master -l syslog:LOG_DAEMON" amd_dir=/amd
 amd=YES amd_flags="-F /etc/amd/master -x all" amd_dir=/amd

 Ups, an older config line is still there, but that should not be the reason.
 Thanks for looking at this ...

 Andreas
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andreas_Hallmann | 1 Feb 2007 13:10
Picon

Re: misc/35534: /etc/rc.d/amd does not set /var/run/amd.pid

The following reply was made to PR misc/35534; it has been noted by GNATS.

From: Andreas_Hallmann <hallmann <at> ahatec.de>
To: gnats-bugs <at> NetBSD.org
Cc: 
Subject: Re: misc/35534: /etc/rc.d/amd does not set /var/run/amd.pid
Date: Thu, 1 Feb 2007 13:09:28 +0100

 On Thu, Feb 01, 2007 at 11:55:02AM +0000, Andreas_Hallmann wrote:
 > The following reply was made to PR misc/35534; it has been noted by GNATS.
 > 
 > From: Andreas_Hallmann <hallmann <at> ahatec.de>
 > To: gnats-bugs <at> NetBSD.org
 > Cc: 
 > Subject: Re: misc/35534: /etc/rc.d/amd does not set /var/run/amd.pid
 > Date: Thu, 1 Feb 2007 12:53:01 +0100
 > 
 >  On Thu, Feb 01, 2007 at 11:40:02AM +0000, Matt Fleming wrote:
 >  > The following reply was made to PR misc/35534; it has been noted by GNATS.
 >  > 
 >  > From: Matt Fleming <mjf <at> NetBSD.org>
 >  > To: gnats-bugs <at> NetBSD.org
 >  > Cc: 
 >  > Subject: Re: misc/35534: /etc/rc.d/amd does not set /var/run/amd.pid
 >  > Date: Thu, 1 Feb 2007 11:35:12 +0000
 >  > 
 >  >  Could you please provide more information about how you start amd. Is
 >  >  there an "amd=YES" line in your rc.conf? And could you paste the command_args
 >  >  line from /etc/rc.d/amd. Thanks!
(Continue reading)

Permalink | Reply | 1 comment |
headers
Matt Fleming | 1 Feb 2007 13:22
Picon

Re: misc/35534: /etc/rc.d/amd does not set /var/run/amd.pid

On Thu, Feb 01, 2007 at 12:10:03PM +0000, Andreas_Hallmann wrote:
>  # grep command_args /etc/rc.d/amd 
>  command_args='-p -a '$amd_dir' -F /etc/amd.conf >/var/run/amd.pid'
>  

This looks correct to me.

>  >  
>  >  # grep amd /etc/rc.conf 
>  >  amd=YES amd_flags="-F /etc/amd/master -l syslog:LOG_DAEMON" amd_dir=/amd
>  >  amd=YES amd_flags="-F /etc/amd/master -x all" amd_dir=/amd

I added both of these lines and still can't reproduce your problem. Are
the permissions correct for /var/run/amd.pid?

What does `ps ax | grep amd` show?

--mjf
Permalink | Reply | 0 comments |
headers
tron | 1 Feb 2007 13:44
Picon

Re: port-amd64/35535 (memcpy() is very slow if not aligned)

Synopsis: memcpy() is very slow if not aligned

Responsible-Changed-From-To: lib-bug-people-≥port-amd64-maintainer
Responsible-Changed-By: tron <at> netbsd.org
Responsible-Changed-When: Thu, 01 Feb 2007 12:44:02 +0000
Responsible-Changed-Why:
This is a NetBSD-amd64 specific problem.
Permalink | Reply | 0 comments |
headers
Matt Fleming | 1 Feb 2007 13:45
Picon

Re: misc/35534: /etc/rc.d/amd does not set /var/run/amd.pid

The following reply was made to PR misc/35534; it has been noted by GNATS.

From: Matt Fleming <mjf <at> NetBSD.org>
To: gnats-bugs <at> NetBSD.org
Cc: misc-bug-people <at> NetBSD.org, gnats-admin <at> NetBSD.org,
	netbsd-bugs <at> NetBSD.org, hallmann <at> ahatec.de
Subject: Re: misc/35534: /etc/rc.d/amd does not set /var/run/amd.pid
Date: Thu, 1 Feb 2007 12:22:15 +0000

 On Thu, Feb 01, 2007 at 12:10:03PM +0000, Andreas_Hallmann wrote:
 >  # grep command_args /etc/rc.d/amd 
 >  command_args='-p -a '$amd_dir' -F /etc/amd.conf >/var/run/amd.pid'
 >  

 This looks correct to me.

 >  >  
 >  >  # grep amd /etc/rc.conf 
 >  >  amd=YES amd_flags="-F /etc/amd/master -l syslog:LOG_DAEMON" amd_dir=/amd
 >  >  amd=YES amd_flags="-F /etc/amd/master -x all" amd_dir=/amd

 I added both of these lines and still can't reproduce your problem. Are
 the permissions correct for /var/run/amd.pid?

 What does `ps ax | grep amd` show?

 --mjf
Permalink | Reply | 0 comments |
headers
tron | 1 Feb 2007 13:48
Picon

Re: port-amd64/35532 (Impossible to update an amd64 to 4.0)

Synopsis: Impossible to update an amd64 to 4.0

Responsible-Changed-From-To: port-amd64-maintainer-≥tron
Responsible-Changed-By: tron <at> netbsd.org
Responsible-Changed-When: Thu, 01 Feb 2007 12:48:50 +0000
Responsible-Changed-Why:
I'll handle this PR.

State-Changed-From-To: open->analyzed
State-Changed-By: tron <at> netbsd.org
State-Changed-When: Thu, 01 Feb 2007 12:48:50 +0000
State-Changed-Why:
Manual Bouyer already fixes this in NetBSD-current:

http://mail-index.netbsd.org/source-changes/2007/01/14/0031.html
http://mail-index.netbsd.org/source-changes/2007/01/17/0024.html

I'll try to build NetBSD-amd64 from the "netbsd-4" changes applied. If the
build doesn't break (because of floppy overflows) I'll request a pullup.
Permalink | Reply | 0 comments |

Gmane