headers
oster | 1 Aug 2007 02:25
Picon

kern/36714: background/foreground signal lossage in -current with various programs

>Number:         36714
>Category:       kern
>Synopsis:       bringing a background process to the foreground seems to stall the process
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Aug 01 00:25:00 +0000 2007
>Originator:     oster <at> netbsd.org
>Release:        NetBSD 4.99.25
>Organization:
>Environment:
System: NetBSD scrooge 4.99.25 NetBSD 4.99.25 (SCROOGE) #0: Tue Jul 31 12:10:05 CST 2007
oster <at> scrooge:/u1/builds/build21/src/sys/arch/i386/compile/SCROOGE i386
Architecture: i386
Machine: i386
>Description:
	Various programs have issues when started in the background and then 
brought to the foreground.  The problem was first found with emacs20 from 
pkgsrc, but has since been easy to replicate with programs like 'top'
and 'systat'.  The problem is seen on at least i386, amd64, and macppc. 
Kernels 4.99.20 and before appear unaffected.  Kernels 4.99.23 and later 
have the issue.  Shell seems to be irrelevant (csh, tcsh, and sh all have
the same behaviour).

What happens is:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tobias Nygren | 1 Aug 2007 02:55
Picon

Re: kern/36710: panic: NFS assertion (SLP_VALID | SLP_DOREC)

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

From: Tobias Nygren <tnn <at> NetBSD.org>
To: gnats-bugs <at> NetBSD.org
Cc: 
Subject: Re: kern/36710: panic: NFS assertion (SLP_VALID | SLP_DOREC)
Date: Wed, 1 Aug 2007 02:54:05 +0200

 I found out that the default mount options were a bit unusual,
 so I'll mention them here:
 It was using proto=tcp,vers=2,rsize=61440,wsize=61440.
 When I changed it to proto=udp,vers=2,rsize=1024,wsize=1024 the
 problems went away.

 I'm leaving this PR open because I still think there's a bug
 lurking in the NFS code or network stack.
Permalink | Reply | 1 comment |
headers
YAMAMOTO Takashi | 1 Aug 2007 08:46
Picon

Re: kern/36710: panic: NFS assertion (SLP_VALID | SLP_DOREC)

>  It was using proto=tcp,vers=2,rsize=61440,wsize=61440.

what rsize and wsize are actually used in that case?

YAMAMOTO Takashi
Permalink | Reply | 0 comments |
headers
YAMAMOTO Takashi | 1 Aug 2007 08:50
Picon

Re: kern/36710: panic: NFS assertion (SLP_VALID | SLP_DOREC)

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

From: yamt <at> mwd.biglobe.ne.jp (YAMAMOTO Takashi)
To: gnats-bugs <at> NetBSD.org
Cc: kern-bug-people <at> netbsd.org, gnats-admin <at> netbsd.org,
	netbsd-bugs <at> netbsd.org, tnn <at> NetBSD.org
Subject: Re: kern/36710: panic: NFS assertion (SLP_VALID | SLP_DOREC)
Date: Wed,  1 Aug 2007 15:46:38 +0900 (JST)

 >  It was using proto=tcp,vers=2,rsize=61440,wsize=61440.

 what rsize and wsize are actually used in that case?

 YAMAMOTO Takashi
Permalink | Reply | 0 comments |
headers
rumble | 1 Aug 2007 09:35

kern/36716: cd(4) problem with transfers exceeding 65535 bytes

>Number:         36716
>Category:       kern
>Synopsis:       cd(4) problem with transfers exceeding 65535 bytes
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Aug 01 07:35:00 +0000 2007
>Originator:     Stephen M. Rumble
>Release:        4.99.25
>Organization:
>Environment:
NetBSD x31.ephemeral.org 4.99.25 NetBSD 4.99.25 (X31) #1: Tue Jul 31 22:36:09 EDT 2007 
rumble <at> x31.ephemeral.org:/usr/src/sys/arch/i386/compile/X31 i386
>Description:
When reading an EFS file system from CD, cd(4) will often start transfers greater than 65535 bytes. This is
due to the fact that bounce buffering often rounds accesses to 33 sectors (66k). The following errors result:

On my Thinkpad X31:

    piixide0:1: unable to load xfer table DMA map for drive 0, error=22
    piixide0:1:0: lost interrupt
        type: atapi tc_bcount: 67584 tc_skip: 0

    ... repeats indefinitely ...

In QEMU (0.8.2nb2):
(Continue reading)

Permalink | Reply | 1 comment |
headers
alexey | 1 Aug 2007 10:00
Picon

bin/36717: df -i shows negative value in "ifree" column on a lfs partition

>Number:         36717
>Category:       bin
>Synopsis:       df -i shows negative value in "ifree" column on a lfs partition
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Aug 01 08:00:00 +0000 2007
>Originator:     Alexey Lebedev
>Release:        NetBSD 3.1
>Organization:
Moscow Aviation Institute
>Environment:
NetBSD kl.zhtw.org.ru 3.1 NetBSD 3.1 (GENERIC.MP) #0: Tue Oct 31 04:42:38 UTC 2006 
builds <at> b0.netbsd.org:/home/builds/ab/netbsd-3-1-RELEASE/i386/200610302053Z-obj/home/builds/ab/netbsd-3-1-RELEASE/src/sys/arch/i386/compile/GENERIC.MP i386
>Description:
I'm using lfs on partition /usr and some time ago I noticed that daily reports contain wrong information
about free inodes on this partition:

Checking subsystem status:

disks:
Filesystem    Size      Used     Avail Capacity  iused    ifree  %iused  Mounted on
/dev/wd0a     249M      22M      214M     9%     2416    60942     3%   /
/dev/wd0e     340G      42G      263G    13%   364254 -1772906582     0%   /usr
mfs:308        62M     6.0K       59M     0%       10    15860     0%   /tmp
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tobias Nygren | 1 Aug 2007 11:35
Picon

Re: kern/36710: panic: NFS assertion (SLP_VALID | SLP_DOREC)

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

From: Tobias Nygren <tnn <at> NetBSD.org>
To: gnats-bugs <at> NetBSD.org
Cc: yamt <at> mwd.biglobe.ne.jp
Subject: Re: kern/36710: panic: NFS assertion (SLP_VALID | SLP_DOREC)
Date: Wed, 1 Aug 2007 11:31:32 +0200

 On Wed,  1 Aug 2007 06:50:02 +0000 (UTC)
 yamt <at> mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:

 >  what rsize and wsize are actually used in that case?

 The manual page says "kernel managed" size. It's hard to tell.
 I think wsize in the context of tcp mounts means window size.
 At least according to what I can read from tcpdump. I will run
 more dumps with various settings and see what I can come up with.

 I would not be surprised if the client is doing something that
 deviates from the RFCs. NFSv3 for example is not usable because
 the client zeroes out the nanosecond part of the nfstime3
 attributes, causing attribute mismatches. (We don't have any
 export options that can work around this, do we?)
Permalink | Reply | 0 comments |
headers
christos | 1 Aug 2007 12:43
Picon

Re: kern/24276 (uhci host controller halts on amp suspend)

Synopsis: uhci host controller halts on amp suspend

State-Changed-From-To: open->feedback
State-Changed-By: christos <at> netbsd.org
State-Changed-When: Wed, 01 Aug 2007 06:43:05 -0400
State-Changed-Why:
I believe this is fixed in current
Permalink | Reply | 0 comments |
headers
christos | 1 Aug 2007 12:43
Picon

Re: kern/10218 (uhci logs 'host controller halted' after apm resume)

Synopsis: uhci logs 'host controller halted' after apm resume

State-Changed-From-To: open->feedback
State-Changed-By: christos <at> netbsd.org
State-Changed-When: Wed, 01 Aug 2007 06:43:33 -0400
State-Changed-Why:
I believe this is fixed in current
Permalink | Reply | 0 comments |
headers
christos | 1 Aug 2007 12:43
Picon

Re: kern/11051 (uhci is too noisy at resume (still?))

Synopsis: uhci is too noisy at resume (still?)

State-Changed-From-To: open->feedback
State-Changed-By: christos <at> netbsd.org
State-Changed-When: Wed, 01 Aug 2007 06:43:52 -0400
State-Changed-Why:
I believe this is fixed in current
Permalink | Reply | 0 comments |

Gmane