headers
Kogule Ryo | 1 Nov 2011 02:10

Re: kern/45479: Lock error panic during RabbitMQ running

The patched kernel has never hung last week.  It is very stable.

I appreciate your support.
Permalink | Reply | 0 comments |
headers
yamt | 1 Nov 2011 03:13
Picon

Re: kern/44763 (select/poll direct-set optimization seems racy)

Synopsis: select/poll direct-set optimization seems racy

State-Changed-From-To: feedback->closed
State-Changed-By: yamt <at> NetBSD.org
State-Changed-When: Tue, 01 Nov 2011 02:13:09 +0000
State-Changed-Why:
i don't see the symptom anymore.  thanks!
Permalink | Reply | 0 comments |
headers
Kogule Ryo | 1 Nov 2011 03:15

Re: kern/45479: Lock error panic during RabbitMQ running

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

From: Kogule Ryo <aqua_dabbler <at> me.com>
To: gnats-bugs <at> NetBSD.org, Mindaugas Rasiukevicius <rmind <at> netbsd.org>
Cc: kern-bug-people <at> netbsd.org, gnats-admin <at> netbsd.org, netbsd-bugs <at> netbsd.org
Subject: Re: kern/45479: Lock error panic during RabbitMQ running
Date: Tue, 01 Nov 2011 10:10:06 +0900

 The patched kernel has never hung last week.  It is very stable.

 I appreciate your support.
Permalink | Reply | 0 comments |
headers
Marc Balmer | 1 Nov 2011 08:53
Picon

Re: kern/45441: aio_write and aio_read connected to one pipe don't make progress

Am 12.10.11 22:26, schrieb Alexander Nasonov:
> alnsn <at> NetBSD.org wrote:
>> If you initialize two aiocb structs to connect to one pipe and call aio_read before aio_write, then
aio_error() calls will always be returning EINPROGRESS.
> ...
>> Fix:
>> not known
> 
> The best fix, I think, is return ESPIPE for non-seekable fildes rather
> than silently ignoring aio_offset. This would indirectly solve the issue
> described in this PR.

IMO, this is just a hack.  aio ist fundamentally broken, or rather not
working at the moment due to it's design.  There is another aio PR open,
see there for details.

> 
> Any objections if I commit the patch below? (I'll document ESPIPE as well)
> Alex
> 
> 
> Index: sys/kern/sys_aio.c
> ===================================================================
> RCS file: /cvsroot/src/sys/kern/sys_aio.c,v
> retrieving revision 1.37
> diff -p -u -u -r1.37 sys_aio.c
> --- sys/kern/sys_aio.c	17 Feb 2011 19:02:50 -0000	1.37
> +++ sys/kern/sys_aio.c	12 Oct 2011 20:15:34 -0000
>  <at>  <at>  -360,6 +360,7  <at>  <at>  aio_process(struct aio_job *a_job)
>  	struct proc *p = curlwp->l_proc;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marc Balmer | 1 Nov 2011 08:55
Picon

Re: kern/45441: aio_write and aio_read connected to one pipe don't make progress

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

From: Marc Balmer <mbalmer <at> NetBSD.org>
To: Alexander Nasonov <alnsn <at> yandex.ru>
Cc: gnats-bugs <at> NetBSD.org, kern-bug-people <at> NetBSD.org, gnats-admin <at> NetBSD.org,
        netbsd-bugs <at> NetBSD.org
Subject: Re: kern/45441: aio_write and aio_read connected to one pipe don't
 make progress
Date: Tue, 01 Nov 2011 08:53:16 +0100

 Am 12.10.11 22:26, schrieb Alexander Nasonov:
 > alnsn <at> NetBSD.org wrote:
 >> If you initialize two aiocb structs to connect to one pipe and call aio_read before aio_write, then
aio_error() calls will always be returning EINPROGRESS.
 > ...
 >> Fix:
 >> not known
 > 
 > The best fix, I think, is return ESPIPE for non-seekable fildes rather
 > than silently ignoring aio_offset. This would indirectly solve the issue
 > described in this PR.

 IMO, this is just a hack.  aio ist fundamentally broken, or rather not
 working at the moment due to it's design.  There is another aio PR open,
 see there for details.

 > 
 > Any objections if I commit the patch below? (I'll document ESPIPE as well)
 > Alex
 >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wolfgang Solfrank | 1 Nov 2011 13:55
Picon

PR/45532 CVS commit: src/regress/sys/net/ether_aton_r

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

From: "Wolfgang Solfrank" <ws <at> netbsd.org>
To: gnats-bugs <at> gnats.NetBSD.org
Cc: 
Subject: PR/45532 CVS commit: src/regress/sys/net/ether_aton_r
Date: Tue, 1 Nov 2011 12:52:28 +0000

 Module Name:	src
 Committed By:	ws
 Date:		Tue Nov  1 12:52:28 UTC 2011

 Modified Files:
 	src/regress/sys/net/ether_aton_r: autogen

 Log Message:
 Replace ed usage with awk script.
 Fixes PR toolchain/45532, generating the exact same output as previously.
 Note that it doesn't address Tsutsui's additional check request.

 
 To generate a diff of this commit:
 cvs rdiff -u -r1.1 -r1.2 src/regress/sys/net/ether_aton_r/autogen

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.
Permalink | Reply | 0 comments |
headers
www.NetBSD.org update | 1 Nov 2011 21:00
Picon

NetBSD Nightly Trouble Ticket Report

There are 4881 non-confidential bugs in 52 categories.

Category             critical  serious non-crit    TOTAL           Median TTC
bin                        21      250      370      641         27d 23:50:04
install                    12       43       46      101      8m 12d 11:11:17
kern                      248      932      530     1710      2m 17d 09:47:56
lib                         5       80      111      196         19d 14:40:46
misc                        5       34      117      156         10d 10:48:43
pkg                        76      573      600     1249         12d 10:32:48
port-acorn26                0        2        1        3          1d 03:08:54
port-acorn32                1        2        3        6  1y  4m 28d 05:06:42
port-alpha                 17       33       17       67      6m  5d 14:48:43
port-amd64                  7       22       12       41      3m 13d 11:53:15
port-amiga                  2        8        8       18      1m  4d 23:54:21
port-arc                    0        1        0        1  1y 10m 21d 15:02:22
port-arm                    2        6        3       11      3m  6d 22:45:01
port-atari                  2        3        3        8         15d 02:38:37
port-cats                   0        2        0        2      3m 23d 06:15:06
port-emips                  0        1        0        1             00:07:07
port-evbarm                 1        3        5        9      8m  9d 16:19:15
port-evbmips                0        3        3        6      2m 24d 18:32:41
port-evbppc                 3        0        0        3      4m 19d 14:47:50
port-hp300                  1        0        0        1         18d 05:04:38
port-hp700                  0        1        0        1      7m  6d 11:44:41
port-hpcarm                 2        1        0        3      5m 26d 20:32:13
port-hpcmips                4        5        7       16      1m 22d 20:15:09
port-hpcsh                  1        1        2        4      4m  1d 17:29:07
port-hppa                   0        0        1        1  1y  6m  8d 18:27:05
port-i386                  37       91       64      192      6m 16d 19:16:59
port-ia64                   0        0        1        1  2y  2m 14d 16:17:02
(Continue reading)

Permalink | Reply | 0 comments |
headers
cheusov | 1 Nov 2011 22:15
Picon
Favicon

bin/45556: Two problems with NFS server.

>Number:         45556
>Category:       bin
>Synopsis:       nfs problem. --alldirs works incorrectly
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Nov 01 21:15:00 +0000 2011
>Originator:     Aleksey Cheusov
>Release:        NetBSD 5.99.56
>Organization:
>Environment:
System: NetBSD asrock.chizhovka.net 5.99.56 NetBSD 5.99.56 (GENERIC) #0: Sat Oct 8 16:37:59 UTC 2011
builds <at> b6.netbsd.org:/home/builds/ab/HEAD/amd64/201110081430Z-obj/home/builds/ab/HEAD/src/sys/arch/amd64/compile/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:
1)
  NFS server exports extra directories.

    asrock# cat /etc/exports
    /long                  -network 127.0.0.1 -alldirs
    asrock# ls -l /long
    total 0
    -rw-r--r--  1 root  wheel  0 Nov  1 23:53 long_file
    asrock# ls -l /longer
    total 0
(Continue reading)

Permalink | Reply | 1 comment |
headers
matthew green | 2 Nov 2011 07:10
Picon
Favicon

re: bin/45556: Two problems with NFS server.


i guess your /long and /longer are both on /?  this isn't how NFS works.
see, eg from exports(5):

     space.  The second is to specify the pathname of the root of the filesys-
     tem followed by the -alldirs flag; this form allows the host(s) to mount
     at any point within the filesystem, including regular files.  Note that
     the -alldirs option should not be used as a security measure to make
     clients mount only those subdirectories that they should have access to.
     A client can still access the whole filesystem via individual RPCs if it
     wanted to, even if just one subdirectory has been mounted.  The pathnames

you can really only apply exports across an actual filesystem.

.mrg.
Permalink | Reply | 0 comments |
headers
matthew green | 2 Nov 2011 07:15
Picon
Favicon

re: bin/45556: Two problems with NFS server.

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

From: matthew green <mrg <at> eterna.com.au>
To: gnats-bugs <at> NetBSD.org
Cc: gnats-admin <at> netbsd.org, netbsd-bugs <at> netbsd.org
Subject: re: bin/45556: Two problems with NFS server.
Date: Wed, 02 Nov 2011 17:10:19 +1100

 i guess your /long and /longer are both on /?  this isn't how NFS works.
 see, eg from exports(5):

      space.  The second is to specify the pathname of the root of the filesys-
      tem followed by the -alldirs flag; this form allows the host(s) to mount
      at any point within the filesystem, including regular files.  Note that
      the -alldirs option should not be used as a security measure to make
      clients mount only those subdirectories that they should have access to.
      A client can still access the whole filesystem via individual RPCs if it
      wanted to, even if just one subdirectory has been mounted.  The pathnames

 you can really only apply exports across an actual filesystem.

 
 .mrg.
Permalink | Reply | 0 comments |

Gmane