From chiimo4 at yahoo.co.jp Sun Mar 1 00:50:17 2009 From: chiimo4 at yahoo.co.jp (Dr. Chidi Imo Office) Date: Sun Mar 1 00:50:24 2009 Subject: GET BACK. Message-ID: <20090301082050.72127.qmail@web4102.mail.ogk.yahoo.co.jp> ????????????????????????????? chiimo4@yahoo.co.jp This is to officially inform you that we have verified your payment & discovered why you have not received your contract/inheritance fund which will now be paid irrevocably following an irrevocable instruction by the presidency and UN.Reply. Dr.Chidi Imo Director of Int. Operations CBN - Dr. Chidi Imo Office From pjd at FreeBSD.org Mon Mar 2 00:40:50 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Mon Mar 2 00:40:56 2009 Subject: cvs commit: src/sys/vm vm_page.c In-Reply-To: <200712190547.lBJ5lpCU039889@repoman.freebsd.org> References: <200712190547.lBJ5lpCU039889@repoman.freebsd.org> Message-ID: <20090302081445.GA2993@garage.freebsd.pl> On Wed, Dec 19, 2007 at 05:47:51AM +0000, Alan Cox wrote: > alc 2007-12-19 05:47:51 UTC > > FreeBSD src repository > > Modified files: > sys/vm vm_page.c > Log: > Eliminate redundant code from vm_page_startup(). > > Revision Changes Path > 1.363 +0 -17 src/sys/vm/vm_page.c > > http://cvsweb.FreeBSD.org/src/sys/vm/vm_page.c.diff?r1=1.362&r2=1.363&f=h > --- src/sys/vm/vm_page.c 2007/12/11 21:20:34 1.362 > +++ src/sys/vm/vm_page.c 2007/12/19 05:47:50 1.363 > @@ -97,7 +97,7 @@ > */ > > #include > -__FBSDID("$FreeBSD: /usr/local/www/cvsroot/FreeBSD/src/sys/vm/vm_page.c,v 1.362 2007/12/11 21:20:34 alc Exp $"); > +__FBSDID("$FreeBSD: /usr/local/www/cvsroot/FreeBSD/src/sys/vm/vm_page.c,v 1.363 2007/12/19 05:47:50 alc Exp $"); > > #include > #include > @@ -201,7 +201,6 @@ vm_offset_t > vm_page_startup(vm_offset_t vaddr) > { > vm_offset_t mapped; > - vm_size_t npages; > vm_paddr_t page_range; > vm_paddr_t new_end; > int i; > @@ -216,9 +215,6 @@ vm_page_startup(vm_offset_t vaddr) > vm_paddr_t low_water, high_water; > int biggestone; > > - vm_paddr_t total; > - > - total = 0; > biggestsize = 0; > biggestone = 0; > nblocks = 0; > @@ -244,7 +240,6 @@ vm_page_startup(vm_offset_t vaddr) > if (phys_avail[i + 1] > high_water) > high_water = phys_avail[i + 1]; > ++nblocks; > - total += size; > } > > end = phys_avail[biggestone+1]; > @@ -308,8 +303,6 @@ vm_page_startup(vm_offset_t vaddr) > #else > #error "Either VM_PHYSSEG_DENSE or VM_PHYSSEG_SPARSE must be defined." > #endif > - npages = (total - (page_range * sizeof(struct vm_page)) - > - (end - new_end)) / PAGE_SIZE; > end = new_end; > > /* > @@ -345,16 +338,6 @@ vm_page_startup(vm_offset_t vaddr) > vm_page_array_size = page_range; > > /* > - * This assertion tests the hypothesis that npages and total are > - * redundant. XXX > - */ > - page_range = 0; > - for (i = 0; phys_avail[i + 1] != 0; i += 2) > - page_range += atop(phys_avail[i + 1] - phys_avail[i]); > - KASSERT(page_range == npages, > - ("vm_page_startup: inconsistent page counts")); > - > - /* > * Initialize the physical memory allocator. > */ > vm_phys_init(); This assertion is triggered on my 7-STABLE machine. It was fine when it was running 6.1, but now after upgrade it panics. If this assert is bogus could you MFC it to 7-STABLE as well? -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20090302/31546ea7/attachment.pgp From alc at cs.rice.edu Thu Mar 5 10:28:13 2009 From: alc at cs.rice.edu (Alan Cox) Date: Thu Mar 5 10:28:25 2009 Subject: cvs commit: src/sys/vm vm_page.c In-Reply-To: <20090302081445.GA2993@garage.freebsd.pl> References: <200712190547.lBJ5lpCU039889@repoman.freebsd.org> <20090302081445.GA2993@garage.freebsd.pl> Message-ID: <49B0149D.7000004@cs.rice.edu> Pawel Jakub Dawidek wrote: > On Wed, Dec 19, 2007 at 05:47:51AM +0000, Alan Cox wrote: > >> alc 2007-12-19 05:47:51 UTC >> >> FreeBSD src repository >> >> Modified files: >> sys/vm vm_page.c >> Log: >> Eliminate redundant code from vm_page_startup(). >> >> Revision Changes Path >> 1.363 +0 -17 src/sys/vm/vm_page.c >> >> http://cvsweb.FreeBSD.org/src/sys/vm/vm_page.c.diff?r1=1.362&r2=1.363&f=h >> --- src/sys/vm/vm_page.c 2007/12/11 21:20:34 1.362 >> +++ src/sys/vm/vm_page.c 2007/12/19 05:47:50 1.363 >> @@ -97,7 +97,7 @@ >> */ >> >> #include >> -__FBSDID("$FreeBSD: /usr/local/www/cvsroot/FreeBSD/src/sys/vm/vm_page.c,v 1.362 2007/12/11 21:20:34 alc Exp $"); >> +__FBSDID("$FreeBSD: /usr/local/www/cvsroot/FreeBSD/src/sys/vm/vm_page.c,v 1.363 2007/12/19 05:47:50 alc Exp $"); >> >> #include >> #include >> @@ -201,7 +201,6 @@ vm_offset_t >> vm_page_startup(vm_offset_t vaddr) >> { >> vm_offset_t mapped; >> - vm_size_t npages; >> vm_paddr_t page_range; >> vm_paddr_t new_end; >> int i; >> @@ -216,9 +215,6 @@ vm_page_startup(vm_offset_t vaddr) >> vm_paddr_t low_water, high_water; >> int biggestone; >> >> - vm_paddr_t total; >> - >> - total = 0; >> biggestsize = 0; >> biggestone = 0; >> nblocks = 0; >> @@ -244,7 +240,6 @@ vm_page_startup(vm_offset_t vaddr) >> if (phys_avail[i + 1] > high_water) >> high_water = phys_avail[i + 1]; >> ++nblocks; >> - total += size; >> } >> >> end = phys_avail[biggestone+1]; >> @@ -308,8 +303,6 @@ vm_page_startup(vm_offset_t vaddr) >> #else >> #error "Either VM_PHYSSEG_DENSE or VM_PHYSSEG_SPARSE must be defined." >> #endif >> - npages = (total - (page_range * sizeof(struct vm_page)) - >> - (end - new_end)) / PAGE_SIZE; >> end = new_end; >> >> /* >> @@ -345,16 +338,6 @@ vm_page_startup(vm_offset_t vaddr) >> vm_page_array_size = page_range; >> >> /* >> - * This assertion tests the hypothesis that npages and total are >> - * redundant. XXX >> - */ >> - page_range = 0; >> - for (i = 0; phys_avail[i + 1] != 0; i += 2) >> - page_range += atop(phys_avail[i + 1] - phys_avail[i]); >> - KASSERT(page_range == npages, >> - ("vm_page_startup: inconsistent page counts")); >> - >> - /* >> * Initialize the physical memory allocator. >> */ >> vm_phys_init(); >> > > This assertion is triggered on my 7-STABLE machine. It was fine when it > was running 6.1, but now after upgrade it panics. If this assert is > bogus could you MFC it to 7-STABLE as well? > > Hmm. The assertion is not bogus. It is a legitimate initialization time consistency check. I removed it from HEAD because no one reported it failing over a period of two years, so I thought it could be removed and the code simplified. Are you using a kernel from before or after the superpages MFC? Alan From pjd at FreeBSD.org Thu Mar 5 13:44:27 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Thu Mar 5 13:44:38 2009 Subject: cvs commit: src/sys/vm vm_page.c In-Reply-To: <49B0149D.7000004@cs.rice.edu> References: <200712190547.lBJ5lpCU039889@repoman.freebsd.org> <20090302081445.GA2993@garage.freebsd.pl> <49B0149D.7000004@cs.rice.edu> Message-ID: <20090305214454.GA2506@garage.freebsd.pl> On Thu, Mar 05, 2009 at 12:06:21PM -0600, Alan Cox wrote: > Pawel Jakub Dawidek wrote: > >This assertion is triggered on my 7-STABLE machine. It was fine when it > >was running 6.1, but now after upgrade it panics. If this assert is > >bogus could you MFC it to 7-STABLE as well? > > > > > > Hmm. The assertion is not bogus. It is a legitimate initialization > time consistency check. I removed it from HEAD because no one reported > it failing over a period of two years, so I thought it could be removed > and the code simplified. > > Are you using a kernel from before or after the superpages MFC? This is RELENG_7 from 2nd March. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20090305/7685688a/attachment.pgp From alc at cs.rice.edu Thu Mar 5 19:30:38 2009 From: alc at cs.rice.edu (Alan Cox) Date: Thu Mar 5 19:30:44 2009 Subject: cvs commit: src/sys/vm vm_page.c In-Reply-To: <20090305214454.GA2506@garage.freebsd.pl> References: <200712190547.lBJ5lpCU039889@repoman.freebsd.org> <20090302081445.GA2993@garage.freebsd.pl> <49B0149D.7000004@cs.rice.edu> <20090305214454.GA2506@garage.freebsd.pl> Message-ID: <49B098D4.3060008@cs.rice.edu> Pawel Jakub Dawidek wrote: > On Thu, Mar 05, 2009 at 12:06:21PM -0600, Alan Cox wrote: > >> Pawel Jakub Dawidek wrote: >> >>> This assertion is triggered on my 7-STABLE machine. It was fine when it >>> was running 6.1, but now after upgrade it panics. If this assert is >>> bogus could you MFC it to 7-STABLE as well? >>> >>> >>> >> Hmm. The assertion is not bogus. It is a legitimate initialization >> time consistency check. I removed it from HEAD because no one reported >> it failing over a period of two years, so I thought it could be removed >> and the code simplified. >> >> Are you using a kernel from before or after the superpages MFC? >> > > This is RELENG_7 from 2nd March. > > Can you please try a kernel from February 25th? Alan From deischen at freebsd.org Mon Mar 9 20:37:29 2009 From: deischen at freebsd.org (Daniel Eischen) Date: Mon Mar 9 20:37:41 2009 Subject: cvs commit: src/lib/libc/gen lockf.c src/lib/libc/sys Symbol.map fcntl.2 src/sys/compat/freebsd32 syscalls.master src/sys/compat/linux linux_file.c src/sys/compat/svr4 svr4_fcntl.c src/sys/conf NOTES files options ... In-Reply-To: <200803261523.m2QFND30047541@repoman.freebsd.org> References: <200803261523.m2QFND30047541@repoman.freebsd.org> Message-ID: On Wed, 26 Mar 2008, Doug Rabson wrote: > dfr 2008-03-26 15:23:13 UTC > > FreeBSD src repository > > Modified files: > lib/libc/sys Symbol.map fcntl.2 [ ... ] > sys/sys fcntl.h lockf.h [ ... ] > Log: > Add the new kernel-mode NFS Lock Manager. To use it instead of the > user-mode lock manager, build a kernel with the NFSLOCKD option and > add '-k' to 'rpc_lockd_flags' in rc.conf. Sorry to notice this 1 year too late, but doesn't this break ABI? You have changed the size (increased) of struct flock and haven't really provided a compat version of fcntl() that will work with binaries built before the change. Is there any way that the new field can be accidentally used by the kernel from a binary built against the older struct flock? Now that we have symbol versioning, the way this normally should be handled is by adding a compat fcntl() for FBSD_1.0 in libc, and placing the new fcntl() in FBSD_1.1. And since libthr wraps fcntl() for cancellation points, I believe it would also need the same compat functions. -- DE From dfr at rabson.org Tue Mar 10 02:18:42 2009 From: dfr at rabson.org (Doug Rabson) Date: Tue Mar 10 02:18:55 2009 Subject: cvs commit: src/lib/libc/gen lockf.c src/lib/libc/sys Symbol.map fcntl.2 src/sys/compat/freebsd32 syscalls.master src/sys/compat/linux linux_file.c src/sys/compat/svr4 svr4_fcntl.c src/sys/conf NOTES files options ... In-Reply-To: References: <200803261523.m2QFND30047541@repoman.freebsd.org> Message-ID: <2E168868-9711-4BF7-A398-FF4195390B7C@rabson.org> On 10 Mar 2009, at 03:21, Daniel Eischen wrote: > On Wed, 26 Mar 2008, Doug Rabson wrote: > >> dfr 2008-03-26 15:23:13 UTC >> >> FreeBSD src repository >> >> Modified files: >> lib/libc/sys Symbol.map fcntl.2 > [ ... ] >> sys/sys fcntl.h lockf.h > [ ... ] >> Log: >> Add the new kernel-mode NFS Lock Manager. To use it instead of the >> user-mode lock manager, build a kernel with the NFSLOCKD option and >> add '-k' to 'rpc_lockd_flags' in rc.conf. > > Sorry to notice this 1 year too late, but doesn't this > break ABI? You have changed the size (increased) of > struct flock and haven't really provided a compat version > of fcntl() that will work with binaries built before > the change. I added new fcntl commands for the new structures. The old commands were renamed to F_OGETLK, F_OSETLK and F_OSETLKW and continue to use the old structures. A new kernel translates old fcntl commands to the equivalent new commands. A new libc will detect when its running on an old kernel and will translate the new fcntl commands to the equivalent old ones. > > Is there any way that the new field can be accidentally > used by the kernel from a binary built against the older > struct flock? No. > > Now that we have symbol versioning, the way this normally > should be handled is by adding a compat fcntl() for > FBSD_1.0 in libc, and placing the new fcntl() in FBSD_1.1. > And since libthr wraps fcntl() for cancellation points, > I believe it would also need the same compat functions. I thought about this but in the end it was simpler to add new fcntl commands. The libthr compat issue is dealt with by calling __fcntl_compat() for commands other than F_DUPFD, F_SETFD, F_SETFL, F_GETFD or F_GETFL.