Re: [PATCH] fix shell bug in ${var%pattern} expansion

2010-10-13 Thread David O'Brien
On Wed, Oct 13, 2010 at 11:42:48PM +0200, Jilles Tjoelker wrote: > Style bug: > > +growstrstackblock(int n) { > The opening brace should be on its own line. Indeed. I'm surprised I did that. Thank you for catching it. > Your test is too fragile: it often fails to detect the bug. Calling like >

Re: [PATCH] fix shell bug in ${var%pattern} expansion

2010-10-13 Thread Jilles Tjoelker
On Mon, Oct 11, 2010 at 07:19:14PM -0700, David O'Brien wrote: > At $WORK we hit a bug where ${var%/*} was not producing the correct > expansion. There are two patches to fix this. I prefer the first > as I feel it is cleaner from an API perspective. I've also added > a regression testcase that

Re: Locked up nfsd after avg@ sendfile patch

2010-10-13 Thread Andriy Gapon
on 13/10/2010 19:17 Sam Fourman Jr. said the following: > full procstat -kk -a > > http://www.puffybsd.com/fnfs.txt It seems that thread 100281 is stuck waiting on zio and other threads are waiting on it (because it set zilog->zl_writer and hasn't unset it) or other stuck threads in chain: 10

[head tinderbox] failure on sparc64/sun4v

2010-10-13 Thread FreeBSD Tinderbox
TB --- 2010-10-13 13:47:40 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-10-13 13:47:40 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2010-10-13 13:47:40 - cleaning the object tree TB --- 2010-10-13 13:49:43 - cvsupping the source tree TB --- 2010-10-13 13:49:43 - /usr/b

Re: [PATCH] Netdump for review and testing -- preliminary version

2010-10-13 Thread Ryan Stone
On Fri, Oct 8, 2010 at 9:15 PM, Robert Watson wrote: > + /* > +* get and fill a header mbuf, then chain data as an > extended > +* mbuf. > +*/ > + MGETHDR(m, M_DONTWAIT, MT_DATA); > > The idea of calling into the mbuf allo

[head tinderbox] failure on sparc64/sparc64

2010-10-13 Thread FreeBSD Tinderbox
TB --- 2010-10-13 11:48:20 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-10-13 11:48:20 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-10-13 11:48:20 - cleaning the object tree TB --- 2010-10-13 11:50:44 - cvsupping the source tree TB --- 2010-10-13 11:50:44 - /usr

Re: Locked up nfsd after avg@ sendfile patch

2010-10-13 Thread Sam Fourman Jr.
On Wed, Oct 13, 2010 at 10:59 AM, Sam Fourman Jr. wrote: > > procstat -kk -a | fgrep zil_commit >> >> -- >> Andriy Gapon >> > > > > full procstat -kk -a http://www.puffybsd.com/fnfs.txt -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com _

Re: Locked up nfsd after avg@ sendfile patch

2010-10-13 Thread Andriy Gapon
on 13/10/2010 18:59 Sam Fourman Jr. said the following: > > procstat -kk -a | fgrep zil_commit > > -- > Andriy Gapon > > > > I rebooted... Next time it locks up, I will run that.. it locks up pretty > regular, > should not be a few hours You might want to save complete procstat -

Re: Locked up nfsd after avg@ sendfile patch

2010-10-13 Thread Andriy Gapon
on 13/10/2010 18:13 Sam Fourman Jr. said the following: > > FNFS# uname -a > FreeBSD FNFS.PuffyBSD.Com 9.0-CURRENT FreeBSD > 9.0-CURRENT #23: Wed Oct 13 08:07:13 CDT 2010 > r...@fnfs.puffybsd.com:/usr/obj/usr/src/sys/FNFS amd64 > FNFS# > > > running CURRENT as of

Re: Locked up nfsd after avg@ sendfile patch

2010-10-13 Thread Sam Fourman Jr.
> procstat -kk -a | fgrep zil_commit > > -- > Andriy Gapon > I rebooted... Next time it locks up, I will run that.. it locks up pretty regular, should not be a few hours -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com ___ freebsd-

Locked up nfsd after avg@ sendfile patch

2010-10-13 Thread Sam Fourman Jr.
FNFS# uname -a FreeBSD FNFS.PuffyBSD.Com 9.0-CURRENT FreeBSD 9.0-CURRENT #23: Wed Oct 13 08:07:13 CDT 2010 r...@fnfs.puffybsd.com:/usr/obj/usr/src/sys/FNFS amd64 FNFS# running CURRENT as of - r213742 FNFS# top -PS last pid: 65634; load averages: 3.39, 2.81, 1.62 up 0+01:47:43 10:07:35 3

Re: 3 different ral(4) pcmcia card (same chip) give the same error

2010-10-13 Thread Sergey V. Dyatko
On Wed, 13 Oct 2010 14:46:17 +0100 Anton Shterenlikht wrote: > Is damien@ still active in ral(4) development? > I'm posting here in case he's not. > > many thanks > anton > As far I know damien@ leave Project long time ago, not so far I ask him for RT3090 support. Hi didn't reply, even on !...

Re: mfi and Dell PERC 6/i

2010-10-13 Thread Danilo Baio
On Wed, Aug 25, 2010 at 10:51 AM, Danilo Baio wrote: > > > On Wed, Aug 25, 2010 at 10:24 AM, Ian FREISLICH wrote: > >> Danilo Baio wrote: >> > > Scott Long wrote: >> > > The firmware on the controller crashed. The best I can suggest is to >> look >> > > for newer firmware (mfiutil can flash fir

3 different ral(4) pcmcia card (same chip) give the same error

2010-10-13 Thread Anton Shterenlikht
Is damien@ still active in ral(4) development? I'm posting here in case he's not. many thanks anton - Forwarded message from Anton Shterenlikht - Date: Tue, 12 Oct 2010 12:07:35 +0100 From: Anton Shterenlikht To: dam...@freebsd.org Subject: 3 different ral(4) pcmcia devices give the s

Re: [PATCH] Netdump for review and testing -- preliminary version

2010-10-13 Thread Ed Maste
On Wed, Oct 13, 2010 at 01:04:54PM +0200, Attilio Rao wrote: > 2010/10/9 Robert Watson : > > (1) Did you consider using tftp as the network dump protocol, rather than a > > custom protocol? ??It's also a simple UDP-based, ACKed file transfer > > protocol, with the advantage that it's widely suppo

NFSv3 + 8.1 + rpc.[lockd|statd] issues

2010-10-13 Thread Eric Crist
Hey folks, We have a machine running FreeBSD 8.1-RELEASEp1 acting as an NFS server hosting 3 ZFS file systems on an external enclosure. There are a bunch of machines, ranging from 4.11, 7.1, and 8.x systems acting as NFS clients to this server. Running dmesg on the NFS server shows no errors a

Re: [PATCH] Netdump for review and testing -- preliminary version

2010-10-13 Thread Attilio Rao
2010/10/9 Robert Watson : > On Fri, 8 Oct 2010, Attilio Rao wrote: > >>> GENERAL FRAMEWORK ARCHITECTURE >>> >>> Netdump is composed, right now, by an userland "server" and a kernel >>> "client". The former is run on the target machine (where the dump will >>> phisically happen) and it is responsibl

Re: HEADS UP: device name checking on device registration

2010-10-13 Thread Jaakko Heinonen
On 2010-10-12, Andriy Gapon wrote: > on 12/10/2010 16:36 Matthew Jacob said the following: > > Good workaround, still a nasty surprising bug. > > Yeah. I also would prefer ignoring such a partition or somehow sanitizing its > name or etc. panic(9) on bad internal state of a kernel sounds approp