Re: truss
On Tue, 20 Sep 2011 00:27:22 +0300, Kostik Belousov wrote: KB Could you, please, test the change below ? For me, I still can truss(1) KB or debug with gdb after the change applied. Does truss work for you KB with only this change, without resetting SIGTRAP handler in truss process ? KB KB commit 2ae586c039a55399edc3b34cd40410e0d690a16c KB Author: Konstantin Belousov kos...@pooma.home KB Date: Tue Sep 20 00:25:07 2011 +0300 KB KB Do not deliver SIGTRAP on exec as the normal signal, use ptracestop() KB on syscall exit path. Otherwise, if SIGTRAP is ignored, that tdsendsignal() KB do not want to deliver, and debugger never get a notification of exec. I can confirm - with this patch unmodified truss works when SIGTRAP is ignored. -- Anton Yuzhaninov ___ 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: 9.0 beta2 the new bsdinstaller
From Matthew D. Fuller fulle...@over-yonder.net: I've been meaning to mention this, but we really should document somewhere that it has a _MAXIMUM_ size. I setup a system a few weeks back with GPT, and figured I'd just make the first 'real' partition start at the 1 meg mark. And make everything before that (1 meg - the however many sectors for the pmbr) the freebsd-boot partition. It worked fine, up 'till the point that I tried to boot, and it completely failed to, complaining that the boot code was too big. I had to track around in pmbr to find . . cmp $0x9000,%ax.. . # Don't load past 0x9, . . jae err_big.. . # 545k should be enough for . . mov %ax,%es.. . # any boot code. :) and redo the partition to 512k (leaving a few hundred k unused before the next partition started) before it would boot. That's a little nerve-wracking to hit on a critical system... I don't think there is any particular advantage in aligning GPT partitions on 1 MB boundaries. Nothing sacred about being an integer power of 2, wouldn't it be sufficient for boot partition size to be divisible by 4096 bytes, when the hard drive sector size is 4096 bytes? Tom ___ 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: which include being used?
On 21/09/2011 04:34, Garrett Cooper wrote: On Sep 20, 2011, at 6:19 PM, Kevin Oberman kob6...@gmail.com wrote: To build a new system, you have to start with something. You build the toolcain and gcc. Those have to be built first with the existing compiler and toolchain which uses the existing system include files. Later in buildworld, they are re-built using the new toolchain, compiler, and header files. If you lost your system header files, you will need to restore them before you can re-build the system. Sorry. I'd unpack a tarball from the most recent release. It's the easiest way to fix things :).. I second this suggestion - if the system is damaged enough, this is really the best and most painless way. Because of API ABI stability in FreeBSD STABLE branches, there isn't much that can go wrong even if you repopulate it (temporarily) with another release's sources. signature.asc Description: OpenPGP digital signature
Re: LOR in route.c // scope6.c
On 19 August 2011 05:07, Garrett Cooper yaneg...@gmail.com wrote: Hi, I've periodically seen the following LOR when trying to repro a panic after restarting my network configuration: :lock order reversal: 1st 0xc4142f1c rtentry (rtentry) @ /usr/src/sys/net/routec:362 2nd 0xc3d08604 if_afdata (if_afdata) @ /usr/src/sys/netinet6/scope6.c:417 KDB: stack backtrace: db_trace_self_wrapper(...) _witness_debugger(...) _rw_wlock(...) in6_setscope(...) in6_purgeaddr(...) in6_control(...) ifioctl(...) soo_ioctl(...) kern_ioctl(...) ioctl(...) syscallenter(...) syscall(...) Xint0x80_syscall() I don't have a full backtrace or core for this. This was running r224948 UP with WITNESS. I just got exactly the same LOR on a very fresh current with /etc/rc.d/netif restart, and then I lost the system. Thanks for the report. I hope to dig out the solution... -- wbr, pluknet ___ 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: 9.0 beta2 the new bsdinstaller
On Wed, 21 Sep 2011, Thomas Mueller wrote: From Matthew D. Fuller fulle...@over-yonder.net: I've been meaning to mention this, but we really should document somewhere that it has a _MAXIMUM_ size. I setup a system a few weeks back with GPT, and figured I'd just make the first 'real' partition start at the 1 meg mark. And make everything before that (1 meg - the however many sectors for the pmbr) the freebsd-boot partition. It worked fine, up 'till the point that I tried to boot, and it completely failed to, complaining that the boot code was too big. I had to track around in pmbr to find . . cmp $0x9000,%ax.. . # Don't load past 0x9, . . jae err_big.. . # 545k should be enough for . . mov %ax,%es.. . # any boot code. :) and redo the partition to 512k (leaving a few hundred k unused before the next partition started) before it would boot. That's a little nerve-wracking to hit on a critical system... I don't think there is any particular advantage in aligning GPT partitions on 1 MB boundaries. Agreed. But Windows 7 also starts the main partition at 1M. Taking that as a standard could provide compatibility with other (admittedly poorly-written) disk partitioning software. And it might not, but if it helps with POLA for people used to using GPT elsewhere, that's not a bad reason either. The bug shown above means the freebsd-boot partition should be limited to 512K at present. Another 512K of space after that doesn't really cost anything. If that extra space is needed later, it can be used without repartitioning. ___ 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: 9.0 beta2 the new bsdinstaller
Forgot to add this for reference earlier: http://msdn.microsoft.com/en-us/library/dd758814%28v=sql.100%29.aspx Valid Starting Partition Offsets has some justification for the 1M offset. ___ 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: which include being used?
* Garrett Cooper yaneg...@gmail.com, 20110921 04:34: I'd unpack a tarball from the most recent release. It's the easiest way to fix things :).. Well, sometimes this is sufficient: cd /usr/src/include make install clean That way you'll at least get the default system headers back. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpZsLqAteBT9.pgp Description: PGP signature
Re: 9.0 beta2 the new bsdinstaller
1MB is a magic number. It works with advanced format disks, traditional disks, some odd SSD and most raid configurations. Lucas Holt On Sep 21, 2011, at 4:26 AM, Thomas Mueller mueller6...@bellsouth.net wrote: From Matthew D. Fuller fulle...@over-yonder.net: I've been meaning to mention this, but we really should document somewhere that it has a _MAXIMUM_ size. I setup a system a few weeks back with GPT, and figured I'd just make the first 'real' partition start at the 1 meg mark. And make everything before that (1 meg - the however many sectors for the pmbr) the freebsd-boot partition. It worked fine, up 'till the point that I tried to boot, and it completely failed to, complaining that the boot code was too big. I had to track around in pmbr to find . . cmp $0x9000,%ax.. . # Don't load past 0x9, . . jae err_big.. . # 545k should be enough for . . mov %ax,%es.. . # any boot code. :) and redo the partition to 512k (leaving a few hundred k unused before the next partition started) before it would boot. That's a little nerve-wracking to hit on a critical system... I don't think there is any particular advantage in aligning GPT partitions on 1 MB boundaries. Nothing sacred about being an integer power of 2, wouldn't it be sufficient for boot partition size to be divisible by 4096 bytes, when the hard drive sector size is 4096 bytes? Tom ___ 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 ___ 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
