headers
reed | 1 Nov 2005 04:42

kern/31964: frozen networking with tlp and trafshow

>Number:         31964
>Category:       kern
>Synopsis:       frozen networking with tlp and trafshow
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Nov 01 03:42:00 +0000 2005
>Originator:     reed <at> reedmedia.net
>Release:        NetBSD 2.0.2
>Organization:
http://bsd.reedmedia.net/
>Environment:
	
	
System: NetBSD rainier.reedmedia.net 2.0.2 NetBSD 2.0.2 (GENERIC) #0: Wed Mar 23 08:53:42 UTC 2005
jmc <at> faith.netbsd.org:/home/builds/ab/netbsd-2-0-2-RELEASE/i386/200503220140Z-obj/home/builds/ab/netbsd-2-0-2-RELEASE/src/sys/arch/i386/compile/GENERIC i386
Architecture: i386
Machine: i386
>Description:
Started trafshow using libpcap-0.9.3nb3. When I exited my networking was
dead. When I restart trafshow my networking works again.

Or when I start tcpdump, my networking works again.

If I use "sudo trafshow -p" my networking does not come back up.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nicolas Joly | 1 Nov 2005 08:32
Picon
Picon
Favicon

Re: kern/31963: Wrong VIA Technologies VT82C686A SMBus Controller in pcidevs

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

From: Nicolas Joly <njoly <at> pasteur.fr>
To: gnats-bugs <at> NetBSD.org
Cc: Nicolas Joly <njoly <at> pasteur.fr>
Subject: Re: kern/31963: Wrong VIA Technologies VT82C686A SMBus Controller in pcidevs
Date: Tue, 1 Nov 2005 08:31:44 +0100

 --fUYQa+Pmc3FrFX/N
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline

 On Mon, Oct 31, 2005 at 11:00:05PM +0000, Pavel Cahyna wrote:
 > The following reply was made to PR kern/31963; it has been noted by GNATS.
 > 
 > From: Pavel Cahyna <pcah8322 <at> artax.karlin.mff.cuni.cz>
 > To: gnats-bugs <at> netbsd.org
 > Cc: njoly <at> pasteur.fr
 > Subject: Re: kern/31963: Wrong VIA Technologies VT82C686A SMBus Controller in pcidevs
 > Date: Mon, 31 Oct 2005 23:58:48 +0100
 > 
 >  On Mon, Oct 31, 2005 at 10:49:01PM +0000, njoly <at> pasteur.fr wrote:
 >  > -			 * The VIA VT82C686A SMBus Controller itself as 
 >  > -			 * ISA bridge, but it's wrong !
 >  > +			 * The VIA VT82C686A SMBus Power Management
 >  > +			 * identifies itself as ISA bridge, but it's wrong !
 >  
 >  > -			 * The VIA VT82C686A SMBus Controller itself as 
 >  > -			 * ISA bridge, but it's wrong !
 >  > +			 * The VIA VT82C686A Power Management Controller
(Continue reading)

Permalink | Reply | 0 comments |
headers
YAMAMOTO Takashi | 1 Nov 2005 10:08
Picon

PR/31542 CVS commit: src/sys

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

From: YAMAMOTO Takashi <yamt <at> netbsd.org>
To: gnats-bugs <at> netbsd.org
Cc: 
Subject: PR/31542 CVS commit: src/sys
Date: Tue,  1 Nov 2005 09:07:53 +0000 (UTC)

 Module Name:	src
 Committed By:	yamt
 Date:		Tue Nov  1 09:07:53 UTC 2005

 Modified Files:
 	src/sys/kern: kern_synch.c
 	src/sys/sys: proc.h

 Log Message:
 make scheduler work better when a system has many runnable processes
 by making p_estcpu fixpt_t.  PR/31542.

 1. schedcpu() decreases p_estcpu of all processes
    every seconds, by at least 1 regardless of load average.
 2. schedclock() increases p_estcpu of curproc by 1,
    at about 16 hz.

 in the consequence, if a system has >16 processes
 with runnable lwps, their p_estcpu are not likely increased.

 by making p_estcpu fixpt_t, we can decay it more slowly
 when loadavg is high.  (ie. solve #1.)
(Continue reading)

Permalink | Reply | 0 comments |
headers
yamt | 1 Nov 2005 10:09
Picon

Re: kern/31542

Synopsis: scheduler doesn't work well with many runnable processes

State-Changed-From-To: open->closed
State-Changed-By: yamt <at> netbsd.org
State-Changed-When: Tue, 01 Nov 2005 09:09:57 +0000
State-Changed-Why:
fixed.
Permalink | Reply | 0 comments |
headers
yamt | 1 Nov 2005 10:28
Picon

kern/31966: scheduler multiprocessor problem

>Number:         31966
>Category:       kern
>Synopsis:       scheduler multiprocessor problem
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Nov 01 09:28:00 +0000 2005
>Originator:     YAMAMOTO Takashi <yamt <at> mwd.biglobe.ne.jp>
>Release:        NetBSD 3.99.10
>Organization:

>Environment:
	
	
System: NetBSD kaeru 3.99.10 NetBSD 3.99.10 (build.kaeru.xen.nodebug) #21: Tue Nov 1 15:52:04 JST 2005
takashi <at> kaeru:/home/takashi/work/kernel/build.kaeru.xen.nodebug i386
Architecture: i386
Machine: i386
>Description:
	- decay of p_estcpu is a function of loadavg, which is
	  independent from number of cpus.
	- p_estcpu is increased on each cpus by a constant.
	
	assuming enough number of runnable lwps,
	the above two get more imbalanced if a system has more cpus.
>How-To-Repeat:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Manuel Bouyer | 1 Nov 2005 13:51

Re: port-sparc64/31925: smartd panics NetBSD 2.0.2_STABLE on sparc64

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

From: Manuel Bouyer <bouyer <at> antioche.eu.org>
To: Martin Husemann <martin <at> duskware.de>
Cc: gnats-bugs <at> NetBSD.org
Subject: Re: port-sparc64/31925: smartd panics NetBSD 2.0.2_STABLE on sparc64
Date: Tue, 1 Nov 2005 13:49:59 +0100

 --bp/iNruPH9dso1Pn
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline

 On Mon, Oct 31, 2005 at 01:19:47AM +0100, Martin Husemann wrote:
 > Ok, in -current (modulo a slight kern/kern_physio problem that I avoided by
 > downgrading to r1.61) I can reproduce the problem by running
 > 
 >   smartctl -a /dev/sd0c
 > 
 > in single user mode. IMHO the problem should be fixed in the esiop driver,
 > and the following patch avoids it for me. The real fix probably would
 > avoid setting XS_CTL_DATA_OUT for commands that do not send any data.

 I don't think the check should be in esiop. I think scsipi shoud not set
 XS_CTL_DATA_IN/OUT if there is no data (or more drivers may need to be fixed)
 I think the attached patch should be the right fix, can you test it ?
 My sparc64 doesn't have a esiop adapter in right now, I can put one tomorow
 when I go at work ...

 -- 
 Manuel Bouyer <bouyer <at> antioche.eu.org>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Husemann | 1 Nov 2005 14:47
Picon

Re: port-sparc64/31925: smartd panics NetBSD 2.0.2_STABLE on sparc64

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

From: Martin Husemann <martin <at> duskware.de>
To: Manuel Bouyer <bouyer <at> antioche.eu.org>
Cc: gnats-bugs <at> NetBSD.org
Subject: Re: port-sparc64/31925: smartd panics NetBSD 2.0.2_STABLE on sparc64
Date: Tue, 1 Nov 2005 14:46:05 +0100

 On Tue, Nov 01, 2005 at 01:49:59PM +0100, Manuel Bouyer wrote:
 > I don't think the check should be in esiop.

 That was meant to mean "instead of in sparc64's bus_dmamap code". It's not
 realy clear from the man page if a 0 size map should be considered valid.

 > I think the attached patch should be the right fix, can you test it ?

 It works fine.

 Martin
Permalink | Reply | 0 comments |
headers
Izumi Tsutsui | 1 Nov 2005 14:57
Picon
Gravatar

Re: port-mips/31915: provide centralized wired_map logic

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

From: Izumi Tsutsui <tsutsui <at> ceres.dti.ne.jp>
To: garrett_damore <at> tadpole.com
Cc: gnats-bugs <at> NetBSD.org, port-mips <at> NetBSD.org,
	tsutsui <at> ceres.dti.ne.jp
Subject: Re: port-mips/31915: provide centralized wired_map logic
Date: Tue, 1 Nov 2005 22:56:19 +0900

 In article <43665421.5080505 <at> tadpole.com>
 garrett_damore <at> tadpole.com

 > I've not looked at this yet.  Right now the current MI code uses a fixed 
 > page size.  I can look at extending this so that it can take a page size 
 > as an argument, though frankly I'm not too fond of that as it 
 > complicates the logic to make it work properly.
 > 
 > I need to think about it some more -- I'll get back to you.

 Maybe arc port should handle two regions, one is statically
 wired map for early bootstrap stage and the other is
 bus_space wired map for devices which have large regions.
 The former mappings won't require strict region management,
 so maybe it's just ok to provide a primitive function that
 just takes va, pa0, pa1 and pagesize and then call
 mipsX_TLBWriteIndexedVPS()?

 Anyway, I'll move mipsX_TLBWriteIndexedVPS() to MI mips part
 for interim fix.
 ---
(Continue reading)

Permalink | Reply | 0 comments |
headers
SODA Noriyuki | 1 Nov 2005 15:06
Picon

Re: port-mips/31915: provide centralized wired_map logic

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

From: SODA Noriyuki <soda <at> sra.co.jp>
To: Izumi Tsutsui <tsutsui <at> ceres.dti.ne.jp>
Cc: garrett_damore <at> tadpole.com, gnats-bugs <at> NetBSD.org,
	port-mips <at> NetBSD.org
Subject: Re: port-mips/31915: provide centralized wired_map logic
Date: Tue, 1 Nov 2005 23:05:52 +0900

 >>>>> On Tue, 1 Nov 2005 22:56:19 +0900,
       Izumi Tsutsui <tsutsui <at> ceres.dti.ne.jp> said:

 > Maybe arc port should handle two regions, one is statically
 > wired map for early bootstrap stage and the other is
 > bus_space wired map for devices which have large regions.
 > The former mappings won't require strict region management,

 I guess this doesn't work well.
 Because console is one of things which are needed on the very earlier
 stage, and framebuffer (for console) need the large region.
 --
 soda
Permalink | Reply | 0 comments |
headers
Izumi Tsutsui | 1 Nov 2005 15:31
Picon
Gravatar

Re: port-mips/31915: provide centralized wired_map logic

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

From: Izumi Tsutsui <tsutsui <at> ceres.dti.ne.jp>
To: soda <at> sra.co.jp
Cc: garrett_damore <at> tadpole.com, gnats-bugs <at> NetBSD.org,
	port-mips <at> NetBSD.org, tsutsui <at> ceres.dti.ne.jp
Subject: Re: port-mips/31915: provide centralized wired_map logic
Date: Tue, 1 Nov 2005 23:30:27 +0900

 In article <17255.30272.94435.835085 <at> srapc2586.sra.co.jp>
 soda <at> sra.co.jp wrote:

 > > Maybe arc port should handle two regions, one is statically
 > > wired map for early bootstrap stage and the other is
 > > bus_space wired map for devices which have large regions.
 > > The former mappings won't require strict region management,
 > 
 > I guess this doesn't work well.
 > Because console is one of things which are needed on the very earlier
 > stage, and framebuffer (for console) need the large region.

 Hmm, but with a quick glance, in tga_cnattach() device mem regions
 are allocated by bus_space_map(9) in tga_mappaddrs() so it uses
 the 'managed regions with the default wired map size,'
 which could use the functions in Garrett's patch.
 (hmm, it assumes bus_space functions won't use uvm/pmap functions?)
 I'm not sure whether tga uses a new wired mapping or the PCI region
 already mapped in c_nec_pci.c:c_nec_pci_init(), though.

 The problem here is that there are several direct arc_enter_wired()
(Continue reading)

Permalink | Reply | 0 comments |

Gmane