Re: Ipfilter pre-Vendor Import Issue
Cy, On Thu, Jul 04, 2013 at 03:10:14PM -0700, Cy Schubert wrote: C Unfortunately it doesn't work any more. Here is what svn spit out at me. C C slippy$ cd $MY_WORK_DIR/current/contrib/ipfilter C slippy$ svn merge --record-only file:///tank/wrepos/wsvn/base/vendor/ipfilte C r/dist@252548 C svn: E205000: Try 'svn help merge' for more information C svn: E205000: Source and target must be different but related branches C svn: E205000: Source and target have no common ancestor: C 'file:///tank/wrepos/wsvn/base/vendor/ipfilter/dist@252548' and C '.@unspecified' C slippy$ AFAIU, the problem is that current contrib/ipfilter was never merged from vendor/ipfilter. So, actually we are dealing with a first import (from subversion viewpoint), not n-th. What I'd prefer to see is the following: - commit new ipfilter untouched to vendor-sys/ipfilter - nuke sys/contrib/ipfilter - svn copy vendor-sys/ipfilter to sys/netpfil/ipfilter In future imports do: - commit newer ipfilter to vendor-sys/ipfilter - svn merge vendor-sys/ipfilter to sys/netpfil/ipfilter What's the reason to keep code in contrib? -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: buildkernel is broken
On Tue, Jul 02, 2013 at 08:45:16PM -0700, Steve Kargl wrote: S On Tue, Jul 02, 2013 at 10:51:57PM -0230, Jonathan Anderson wrote: S On Tuesday, 2 July 2013 at 22:16, Steve Kargl wrote: S It seems that S S # Enable FreeBSD7 compatibility syscalls S options COMPAT_FREEBSD7 S S is required in a kernel config file. If it is mandatory to S have this option on FreeBSD 10, it may be appropriate to S expand the comment to S S S # Enable FreeBSD7 compatibility syscalls S # This option is MANDATORY. Do not remove. S options COMPAT_FREEBSD7 S S So... a non-optional option? S S Yes, it appears to be that way. Not really. It is required only if you also got COMPAT_43, the pre-FreeBSD compat option. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: buildkernel is broken
On Fri, Jul 05, 2013 at 05:03:38PM +0400, Gleb Smirnoff wrote: On Tue, Jul 02, 2013 at 08:45:16PM -0700, Steve Kargl wrote: S On Tue, Jul 02, 2013 at 10:51:57PM -0230, Jonathan Anderson wrote: S On Tuesday, 2 July 2013 at 22:16, Steve Kargl wrote: S It seems that S S # Enable FreeBSD7 compatibility syscalls S options COMPAT_FREEBSD7 S S is required in a kernel config file. If it is mandatory to S have this option on FreeBSD 10, it may be appropriate to S expand the comment to S S S # Enable FreeBSD7 compatibility syscalls S # This option is MANDATORY. Do not remove. S options COMPAT_FREEBSD7 S S So... a non-optional option? S S Yes, it appears to be that way. Not really. It is required only if you also got COMPAT_43, the pre-FreeBSD compat option. So, it's essentially non-optional as the comment above COMPAT_43 is # # Implement system calls compatible with 4.3BSD and older versions of # FreeBSD. You probably do NOT want to remove this as much current code # still relies on the 4.3 emulation. Is do NOT want to remove too strong of a statement? -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Kernel build fails on ARM: Cannot fork: Cannot allocate memory
On 25.06.2013 05:23, Jeff Roberson wrote: On Sun, 23 Jun 2013, Ruslan Bukin wrote: On Sun, Jun 23, 2013 at 07:50:40PM +0300, Konstantin Belousov wrote: On Sun, Jun 23, 2013 at 08:44:25PM +0400, Ruslan Bukin wrote: On Sun, Jun 23, 2013 at 07:16:17PM +0300, Konstantin Belousov wrote: On Sun, Jun 23, 2013 at 06:43:46PM +0400, Ruslan Bukin wrote: Trying to mount root from ufs:/dev/da0 []... WARNING: / was not properly dismounted warning: no time-of-day clock registered, system time will not be set accurately panic: __rw_wlock_hard: recursing but non-recursive rw pmap pv global @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:1289 KDB: enter: panic [ thread pid 1 tid 11 ] Stopped at kdb_enter+0x48: ldrbr15, [r15, r15, ror r15]! db bt Tracing pid 1 tid 11 td 0xc547f620 _end() at 0xde9d0530 scp=0xde9d0530 rlv=0xc1211458 (db_trace_thread+0x34) rsp=0xde9d0514 rfp=0xc12d1b60 Bad frame pointer: 0xc12d1b60 db This is completely broken. It seems that witness triggered the panic, and ddb is unable to obtain a backtrace from the normal panic(9) call. Show the output of the 'show alllocks'. No such command Do you have witness in the kernel config ? If not, add it to the config and retry. Trying to mount root from ufs:/dev/da0 []... WARNING: / was not properly dismounted warning: no time-of-day clock registered, system time will not be set accurately panic: __rw_wlock_hard: recursing but non-recursive rw pmap pv global @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:1289 KDB: enter: panic [ thread pid 1 tid 11 ] Stopped at kdb_enter+0x48: ldrbr15, [r15, r15, ror r15]! db show alllocks Process 1 (kernel) thread 0xc55fc620 (11) exclusive sleep mutex pmap (pmap) r = 0 (0xc5600590) locked @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:729 exclusive rw pmap pv global (pmap pv global) r = 0 (0xc1479dd0) locked @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:728 shared rw vm object (vm object) r = 0 (0xc1551d4c) locked @ /usr/home/br/dev/head/sys/vm/vm_map.c:1809 exclusive sx vm map (user) (vm map (user)) r = 0 (0xc5600528) locked @ /usr/home/br/dev/head/sys/kern/imgact_elf.c:445 exclusive lockmgr ufs (ufs) r = 0 (0xc56f7914) locked @ /usr/home/br/dev/head/sys/kern/imgact_elf.c:821 exclusive sleep mutex Giant (Giant) r = 0 (0xc147c778) locked @ /usr/home/br/dev/head/sys/kern/vfs_mount.c:1093 db Would any of the arm users be interested in testing a larger patch that changes the way the kernel allocations KVA? It also has some UMA code that lessens kernel memory utilization. http://people.freebsd.org/~jeff/vmem.diff Any reports would be helpful. Is there any ETA on getting stack tracing fixed? I suspect the pmap recursion encountered with Kostik's patch exist in the current kernel. The other changes in this patch my fix that as well. Thanks, Jeff Hello Jeff, I apologize for a long time with no respond. The problems that I reported at the origin of this tread are no longer relevant. I've made some really extensive tests on the current HEAD and there is no track of kstack allocation failure on my ARM target now. Thanks a lot for your help! Best regards Zbyszek Bodek ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Ipfilter pre-Vendor Import Issue
In message 20130705084649.gc67...@freebsd.org, Gleb Smirnoff writes: Cy, On Thu, Jul 04, 2013 at 03:10:14PM -0700, Cy Schubert wrote: C Unfortunately it doesn't work any more. Here is what svn spit out at me. C C slippy$ cd $MY_WORK_DIR/current/contrib/ipfilter C slippy$ svn merge --record-only file:///tank/wrepos/wsvn/base/vendor/ipfil te C r/dist@252548 C svn: E205000: Try 'svn help merge' for more information C svn: E205000: Source and target must be different but related branches C svn: E205000: Source and target have no common ancestor: C 'file:///tank/wrepos/wsvn/base/vendor/ipfilter/dist@252548' and C '.@unspecified' C slippy$ AFAIU, the problem is that current contrib/ipfilter was never merged from vendor/ipfilter. So, actually we are dealing with a first import (from subversion viewpoint), not n-th. That's unfortunate. What I'd prefer to see is the following: - commit new ipfilter untouched to vendor-sys/ipfilter - nuke sys/contrib/ipfilter - svn copy vendor-sys/ipfilter to sys/netpfil/ipfilter Having ipfilter in one place instead of two (vendor and vendor-sys) makes a lot more sense. I suppose we could put ipfilter's kernel components in sys/netpfil but what about the userland sources? Also see my reply below regarding keeping it in contrib. In future imports do: - commit newer ipfilter to vendor-sys/ipfilter - svn merge vendor-sys/ipfilter to sys/netpfil/ipfilter What's the reason to keep code in contrib? The reason to keep ipftilter in contrib is to maintain consistency with other contributed software such as bind, nvi, sendmail, pf, and a host of other notable software we don't maintain ourselves. Maintaining consistency with other contributed software should probably be maintained. I'm open to moving all packet filters, e.g. ipfw, pf, and ipfilter into sys/netpfil as long as consistency is maintained across the board. Do you think we should put the userland sources also in the same location or should we maintain a similar separation we do today? I'm open to both however I'd prefer keeping all vendor software (kernel and userland) in one location. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Crashes with current on X220
Hi, I updated my rock solid FreeBSD 10 installation from what was current this January to FreeBSD X220.ovitrap.com 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r252491M: Wed Jul 3 08:45:23 CIT 2013 r...@x220.ovitrap.com:/usr/obj/usr/src/sys/X220 amd64 I have since then frequent crashes. Nothing is seen on the screen. The mouse does not move, the caps lock key does not switch the light. I have restarted the machine last evening without doing anything else. No X, just plain FreeBSD before logging on. The machine might has done a fsck. The machine was frozen this morning. Does anybody else has this experience too? Erich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[CFT] sysutils/bsdconfg (0.9.0) and sysutils/sysrc (5.2)
Hey all, With SVN r252862, bsdconfig(8) and sysrc(8) are alive in HEAD. They are for the most-part vestigial organs that will be enmeshed further as they breathe fresh-air, but for now they certainly won't cause the build the break (100% shell; the only thing that gets compiled are the man-pages) and won't disturb anything else. What's been unfurled into HEAD is exactly the same as what's just been released to ports: sysutils/bsdconfig (latest version 0.9.0) sysutils/sysrc (latest version 5.2) My plan is to merge these to stable/9 in 3 days. Reasons for merge are stated in above-revision log-message (mail will be sent to releng and anybody else that cares to receive it or redirect it). This e-mail is about testing. I have been testing on 9.0-R all this time and there should be no problems with 9.1. But if some brave souls will install the port onto 9.1-R and give it a go, that would be great (this is, afterall, a Call For Testing). If you test bsdconfig on anything higher than 9.1-R (say, 9.1-STABLE), package management may not be kind to you (but there's a work-around, go into the options dialog and set your release as 9.1-RELEASE). This has to do with the way binary packages are stored on the FTP server (of course, if you have your own local repository, success depends on your ability to make the repository look official -- just as you had to with sysinstall). No bother testing bsdconfig on anything older than 9.0-R (while sysrc requires only 4.x or higher). Thanks all so much in-advance. -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
