Re: ipfw bug on i386

В Mon, 12 Apr 2010 10:42:25 +0400 "Andrey V. Elsukov" пишет: > On 12.04.2010 10:07, Hizel Ildar wrote: > > Hey! I'm fix this bug :D > > > > patch: > > > > foo# diff -ruN main.c~ main.c > > --- main.c~ 2010-03-04 19:54:56.0 +0300 > > +++ main.c 2010-04-12 09:37:21.0 +0400

Re: ipfw bug on i386

On Mon, Apr 12, 2010 at 11:15:45AM +0400, Hizel Ildar wrote: > ?? Mon, 12 Apr 2010 10:42:25 +0400 > "Andrey V. Elsukov" ??: > > > On 12.04.2010 10:07, Hizel Ildar wrote: > > > Hey! I'm fix this bug :D > > > > > > patch: > > > > > > foo# diff -ruN main.c~ main.c > > > --- main.c~ 2010-

Re: When will we can use ZFS v24?

On Fri, Apr 9, 2010 at 6:44 PM, Dan Nelson wrote: > In the last episode (Apr 08), Garrett Cooper said: >> On Thu, Apr 8, 2010 at 2:30 PM, Chuck Swiger wrote: >> > On Apr 8, 2010, at 2:18 PM, krad wrote: >> > [ ... ] >> >>> is that even possible with CDDL? >> >> >> >> im not a lawyer but it wouldn

Re: ports and PBIs

On Sun, Apr 11, 2010 at 03:44:37PM -0700, Julian Elischer wrote: > On 4/11/10 12:20 PM, Kostik Belousov wrote: > >On Sun, Apr 11, 2010 at 12:13:12PM -0700, Julian Elischer wrote: > >>On 4/11/10 11:44 AM, Kostik Belousov wrote: > >>>On Sun, Apr 11, 2010 at 11:23:33AM -0700, Julian Elischer wrote: >

Re: When will we can use ZFS v24?

On Mon, Apr 12, 2010 at 3:48 AM, Tom Evans wrote: > On Fri, Apr 9, 2010 at 6:44 PM, Dan Nelson wrote: >> In the last episode (Apr 08), Garrett Cooper said: >>> On Thu, Apr 8, 2010 at 2:30 PM, Chuck Swiger wrote: >>> > On Apr 8, 2010, at 2:18 PM, krad wrote: >>> > [ ... ] >>> >>> is that even pos

Re: LOR on em in HEAD ( was Re: em driver regression

On Friday 09 April 2010 3:09:24 pm Jack Vogel wrote: > Someone else also pointed this out. I'm dubious about its claim. > This happens because there is an RX lock taken in rxeof, its held > thru the call into the stack, it then encounters another lock there > and hence this complaint. I've had the

Re: Trivial PR, fix shutdown of rc services started with onestart

On Saturday 10 April 2010 5:33:35 am Dominic Fandrey wrote: > This morning I took a look at my outstanding PRs. There > is a PR I consider old and trivial: > > This one proposes a change that always treats rc script execution > of active services as if _enable="YES" was set. > This ensures, among

Re: Trivial PR, fix shutdown of rc services started with onestart

On 12/04/2010 16:53, John Baldwin wrote: > On Saturday 10 April 2010 5:33:35 am Dominic Fandrey wrote: >> This morning I took a look at my outstanding PRs. There >> is a PR I consider old and trivial: >> >> This one proposes a change that always treats rc script execution >> of active services as i

Re: Trivial PR, fix shutdown of rc services started with onestart

On Monday 12 April 2010 11:17:16 am Dominic Fandrey wrote: > On 12/04/2010 16:53, John Baldwin wrote: > > On Saturday 10 April 2010 5:33:35 am Dominic Fandrey wrote: > >> This morning I took a look at my outstanding PRs. There > >> is a PR I consider old and trivial: > >> > >> This one proposes a c

Re: LOR on em in HEAD ( was Re: em driver regression

On Mon, Apr 12, 2010 at 7:52 AM, John Baldwin wrote: > On Friday 09 April 2010 3:09:24 pm Jack Vogel wrote: > > Someone else also pointed this out. I'm dubious about its claim. > > This happens because there is an RX lock taken in rxeof, its held > > thru the call into the stack, it then encounte

Re: Trivial PR, fix shutdown of rc services started with onestart

John Baldwin wrote: On Monday 12 April 2010 11:17:16 am Dominic Fandrey wrote: On 12/04/2010 16:53, John Baldwin wrote: [...] Considering that they are the responsible party, do they not get notified by GNATS whenever I submit a follow-up to the PR? Ah, in that case they probably do. Stil

Re: LOR on em in HEAD ( was Re: em driver regression

On Monday 12 April 2010 12:26:06 pm Jack Vogel wrote: > On Mon, Apr 12, 2010 at 7:52 AM, John Baldwin wrote: > > > On Friday 09 April 2010 3:09:24 pm Jack Vogel wrote: > > > Someone else also pointed this out. I'm dubious about its claim. > > > This happens because there is an RX lock taken in rx

Re: Trivial PR, fix shutdown of rc services started with onestart

On 4/12/2010 9:45 AM, Miroslav Lachman wrote: > I have bad experiences with freebsd-rc mailing list - no responses to my > direct e-mails and no responses for PRs (PR sent more than year ago, > direct e-mails 3 month ago without any reaction). > I don't know who is responsible person for rc syste

Re: Trivial PR, fix shutdown of rc services started with onestart

Doug Barton wrote: On 4/12/2010 9:45 AM, Miroslav Lachman wrote: I have bad experiences with freebsd-rc mailing list - no responses to my direct e-mails and no responses for PRs (PR sent more than year ago, direct e-mails 3 month ago without any reaction). I don't know who is responsible person

[head tinderbox] failure on i386/pc98

TB --- 2010-04-13 00:50:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-04-13 00:50:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2010-04-13 00:50:00 - cleaning the object tree TB --- 2010-04-13 00:50:22 - cvsupping the source tree TB --- 2010-04-13 00:50:22 - /usr/bin/c

[head tinderbox] failure on i386/i386

TB --- 2010-04-13 00:50:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-04-13 00:50:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-04-13 00:50:00 - cleaning the object tree TB --- 2010-04-13 00:50:23 - cvsupping the source tree TB --- 2010-04-13 00:50:23 - /usr/bin/c

[head tinderbox] failure on amd64/amd64

TB --- 2010-04-13 00:50:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-04-13 00:50:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2010-04-13 00:50:00 - cleaning the object tree TB --- 2010-04-13 00:50:34 - cvsupping the source tree TB --- 2010-04-13 00:50:34 - /usr/bin

[head tinderbox] failure on ia64/ia64

TB --- 2010-04-13 01:39:41 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-04-13 01:39:41 - starting HEAD tinderbox run for ia64/ia64 TB --- 2010-04-13 01:39:41 - cleaning the object tree TB --- 2010-04-13 01:40:03 - cvsupping the source tree TB --- 2010-04-13 01:40:03 - /usr/bin/c

[head tinderbox] failure on powerpc/powerpc

TB --- 2010-04-13 02:08:48 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-04-13 02:08:48 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-04-13 02:08:48 - cleaning the object tree TB --- 2010-04-13 02:09:06 - cvsupping the source tree TB --- 2010-04-13 02:09:06 - /usr

[head tinderbox] failure on sparc64/sparc64

TB --- 2010-04-13 02:34:19 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-04-13 02:34:19 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-04-13 02:34:19 - cleaning the object tree TB --- 2010-04-13 02:34:38 - cvsupping the source tree TB --- 2010-04-13 02:34:38 - /usr

[head tinderbox] failure on sparc64/sun4v

TB --- 2010-04-13 02:55:42 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-04-13 02:55:42 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2010-04-13 02:55:42 - cleaning the object tree TB --- 2010-04-13 02:55:55 - cvsupping the source tree TB --- 2010-04-13 02:55:55 - /usr/b

Re: SIGSEGV in dc, at bcode.c:277 (function reset_bmachine())

В Sat, 10 Apr 2010 17:14:54 -0700 David Wolfskill пишет: > As these things go, this probably isn't as critical as most thinsg > disussed on this list, but I happened to notice it today, built a > debugging world and at least cornered the annoying little varmint. > > Sorry; no patch at this time.