Re: truss
On Fri, 09 Sep 2011 15:56:41 -0700, Xin LI wrote: XL -BEGIN PGP SIGNED MESSAGE- XL Hash: SHA256 XL XL On 08/31/11 07:35, Anton Yuzhaninov wrote: It seems to be truss(1) is broken on current :~ truss /bin/echo x x truss: can not get etype: No such process FreeBSD 9.0-BETA1 #0 r224884M i386 from ktrace of turss 3162 trussCALL __sysctl(0xbfbfea00,0x4,0xbfbfe9e0,0xbfbfea10,0,0) 3162 truss SCTL kern.proc.sv_name.3163 3162 trussRET __sysctl -1 errno 3 No such process XL XL Can't seem to be reproducable here, did I missed anything? (note that XL you may need a full world/kernel build). XL Problem still here after svn up and rebuild world/kernel :~ ktrace -t+ truss /usr/bin/true truss: can not get etype: No such process Full ktrace: http://dl.dropbox.com/u/8798217/tmp/truss_ktrace.txt FreeBSD 9.0-BETA2 #1 r225504M i386 Kernel config is not GENERIC - main difference - DTrace added: http://dl.dropbox.com/u/8798217/tmp/kernconf.txt -- 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: ataidle + notebook hdd + 9.0-BETA2
On 14/09/2011 04:59, Nenhum_de_Nos wrote: rush# ataidle -P 243 /dev/ada0 (pass0:ata2:0:0:0): SETFEATURES. ACB: ef 05 00 00 00 40 00 00 00 00 f3 00 (pass0:ata2:0:0:0): CAM status: CCB request completed with an error Failed to configure APM: No error: 0 Can you post the output of ataidle /dev/ada0 to see what features the disk supports? -- Bruce Cran ___ 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
Segfault in libthr.so on 9.0-BETA2 (with stunnel FWIW)
Hi list, I've recently migrated my services from a box running 8.1-STABLE to another one running 9.0-BETA2. I run stunnel 4.28 on 8.1-STABLE, and it has run flawlessly so far. I compiled manually this very version on 9.0-BETA2. But I get the following segfault: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 803008c00 (LWP 100496/stunnel)] 0x00080110d359 in gmtime_r () from /lib/libc.so.7 (gdb) thread [Current thread is 3 (Thread 803008c00 (LWP 100496/stunnel))] (gdb) bt #0 0x00080110d359 in gmtime_r () from /lib/libc.so.7 #1 0x00080110cdde in gmtime_r () from /lib/libc.so.7 #2 0x00080110dab4 in gmtime_r () from /lib/libc.so.7 #3 0x00080110dcc8 in gmtime_r () from /lib/libc.so.7 #4 0x000800e1d9e8 in pthread_once () from /lib/libthr.so.3 #5 0x00080110ca9f in timegm () from /lib/libc.so.7 #6 0x000805dff8d9 in OPENSSL_gmtime () from /usr/local/lib/libcrypto.so.7 #7 0x000805e74631 in ASN1_UTCTIME_adj () from /usr/local/lib/libcrypto.so.7 #8 0x000805e9462d in X509_time_adj_ex () from /usr/local/lib/libcrypto.so.7 #9 0x000805e9478c in X509_cmp_time () from /usr/local/lib/libcrypto.so.7 #10 0x000805e9496d in internal_verify () from /usr/local/lib/libcrypto.so.7 #11 0x000805e95f46 in X509_verify_cert () from /usr/local/lib/libcrypto.so.7 #12 0x000805b7f4c8 in ssl_verify_cert_chain () from /usr/local/lib/libssl.so.7 #13 0x000805b5d6e3 in ssl3_get_client_certificate () from /usr/local/lib/libssl.so.7 #14 0x000805b612bc in ssl3_accept () from /usr/local/lib/libssl.so.7 #15 0x00406f6e in init_ssl (c=0x803093000) at client.c:329 #16 0x004069a6 in do_client (c=0x803093000) at client.c:202 #17 0x0040676b in run_client (c=0x803093000) at client.c:150 #18 0x004066cf in client (arg=0x803093000) at client.c:123 #19 0x000800e18224 in pthread_getprio () from /lib/libthr.so.3 #20 0x in ?? () Note that I tried with the newest version of stunnel, it crashes at the same place. I also tried libssl.so both from the base system and from the ports, same thing. Regards, -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne ___ 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: ataidle + notebook hdd + 9.0-BETA2
On Wednesday, September 14, 2011 05:59:05 AM Nenhum_de_Nos wrote: rush# ataidle -P 243 /dev/ada0 (pass0:ata2:0:0:0): SETFEATURES. ACB: ef 05 00 00 00 40 00 00 00 00 f3 00 (pass0:ata2:0:0:0): CAM status: CCB request completed with an error Failed to configure APM: No error: 0 so, is this still needed after ada took place ? How can I do it now if needed ? You can use camcontrol idle/standby/sleep instead of ataidle. - Pieter ___ 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: Segfault in libthr.so on 9.0-BETA2 (with stunnel FWIW)
On Wed, Sep 14, 2011 at 02:36:07PM +0200, Jeremie Le Hen wrote: Hi list, I've recently migrated my services from a box running 8.1-STABLE to another one running 9.0-BETA2. I run stunnel 4.28 on 8.1-STABLE, and it has run flawlessly so far. I compiled manually this very version on 9.0-BETA2. But I get the following segfault: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 803008c00 (LWP 100496/stunnel)] 0x00080110d359 in gmtime_r () from /lib/libc.so.7 (gdb) thread [Current thread is 3 (Thread 803008c00 (LWP 100496/stunnel))] (gdb) bt #0 0x00080110d359 in gmtime_r () from /lib/libc.so.7 #1 0x00080110cdde in gmtime_r () from /lib/libc.so.7 #2 0x00080110dab4 in gmtime_r () from /lib/libc.so.7 #3 0x00080110dcc8 in gmtime_r () from /lib/libc.so.7 #4 0x000800e1d9e8 in pthread_once () from /lib/libthr.so.3 #5 0x00080110ca9f in timegm () from /lib/libc.so.7 #6 0x000805dff8d9 in OPENSSL_gmtime () from /usr/local/lib/libcrypto.so.7 #7 0x000805e74631 in ASN1_UTCTIME_adj () from /usr/local/lib/libcrypto.so.7 #8 0x000805e9462d in X509_time_adj_ex () from /usr/local/lib/libcrypto.so.7 #9 0x000805e9478c in X509_cmp_time () from /usr/local/lib/libcrypto.so.7 #10 0x000805e9496d in internal_verify () from /usr/local/lib/libcrypto.so.7 #11 0x000805e95f46 in X509_verify_cert () from /usr/local/lib/libcrypto.so.7 #12 0x000805b7f4c8 in ssl_verify_cert_chain () from /usr/local/lib/libssl.so.7 #13 0x000805b5d6e3 in ssl3_get_client_certificate () from /usr/local/lib/libssl.so.7 #14 0x000805b612bc in ssl3_accept () from /usr/local/lib/libssl.so.7 #15 0x00406f6e in init_ssl (c=0x803093000) at client.c:329 #16 0x004069a6 in do_client (c=0x803093000) at client.c:202 #17 0x0040676b in run_client (c=0x803093000) at client.c:150 #18 0x004066cf in client (arg=0x803093000) at client.c:123 #19 0x000800e18224 in pthread_getprio () from /lib/libthr.so.3 #20 0x in ?? () Note that I tried with the newest version of stunnel, it crashes at the same place. I also tried libssl.so both from the base system and from the ports, same thing. You need to compile both libc and libthr with debugging symbols and do a backtrace with such libraries. pgpvXUeoZClco.pgp Description: PGP signature
FreeBSD Status Report April - June, 2011
FreeBSD Quarterly Status Report - April-June, 2011 Introduction This report covers FreeBSD-related projects between April and June 2011. It is the second of the four reports planned for 2011. Since this quarter, the work is being focused on the next major version of FreeBSD, 9.0, which is to be released in September. Thanks to all the reporters for the excellent work! This report contains 36 entries and we hope you enjoy reading it. Please note that the deadline for submissions covering the period between July and September 2011 is October 15th, 2011. __ Projects * Clang replacing GCC in the base system * Fix clang warnings * libarchive, bsdtar, bsdcpio * ZFS pool version 28 FreeBSD Team Reports * ArabBSD * The FreeBSD Foundation Network Infrastructure * DIstributed Firewall and Flow-shaper Using Statistical Evidence (DIFFUSE) * FreeBSD IPv6-only Support * IPv6 RA Handling Improvements * netmap * New ipfw features * TCP User Timeout Option (UTO) Kernel * Intel GPU Driver * OpenAFS port * Overhaul of the mii(4)-subsystem * Status Report for NFS Documentation * FreeBSD June 6th, 2011 Doc Sprint * The FreeBSD Dutch Documentation Project * The FreeBSD Japanese Documentation Project Architectures * FreeBSD on the Sony Playstation 3 * FreeBSD/arm on Marvell Armada XP * FreeBSD/powerpc on AppliedMicro APM86290 * FreeBSD/powerpc64 on IBM pSeries machines * FreeBSD/sparc64 Ports * Chromium * FreeBSD Haskell Ports * KDE-FreeBSD * libvirt networking port * Portbuilder * Ports Collection Miscellaneous * bsd_day(2011) Google Summer of Code * Capsicum adaptation and core libraries * Disk device error counters * Google Summer of Code * nvi-iconv * Replacing the Regular Expression Code __ ArabBSD URL: https://sites.google.com/site/arabbsd/ Contact: Mohammed Farrag mfar...@freebsd.org FreeBSD Awareness, Handbook Translation and FreeBSD Kernel Development Summer Course. Open tasks: 1. FreeBSD Kernel Development Summer Course. __ bsd_day(2011) URL: http://bsdday.eu/2011 Contact: Martin Matuska m...@freebsd.org Contact: Gábor Páli p...@freebsd.org The purpose of this one-day event is to gather Central European developers of today's open-source BSD systems to popularize their work and their organizations, and to meet each other in the real life. We would also like to motivate potential future developers and users, especially undergraduate university students to work with BSD systems. This year's BSD-Day will be held in Bratislava, Slovakia at Slovak University of Technology, Faculty of Electrical Engineering and Information Technology on November 5, 2011. Everybody is welcome! Open tasks: 1. Apply. We are looking for you! __ Capsicum adaptation and core libraries URL: http://www.cl.cam.ac.uk/research/security/capsicum URL: http://wiki.FreeBSD.org/SOC2011IlyaBakulin Contact: Ilya Bakulin ki...@freebsd.org Some applications from the base system received sandboxing support, current task is to adapt lightweight resolver daemon for using it in sandboxes -- this fixes problems with applications that need to convert IP addresses into domain names while in sandbox. Open tasks: 1. Add sandboxing to even more applications in the base system. 2. Help Jonathan Anderson and Robert Watson to merge FreeBSD-Capsicum into FreeBSD-HEAD. __ Chromium URL: http://www.chromium.org/Home URL: http://trillian.chruetertee.org/chromium Contact: Chromium on FreeBSD Team chrom...@freebsd.org During the last quarter we have been keeping the Chromium browser up to date, with new major releases being imported into the Ports Collection the same day as the upstream release. As time passes by, more patches are incorporated or otherwise became obsolete by virtue of upstream code cleanups. Version 13 is already available from the Chruëtertee repository, with 70 patches less than version 12. __ Clang replacing GCC in the base system URL: http://wiki.FreeBSD.org/BuildingFreeBSDWithClang URL: http://wiki.FreeBSD.org/PortsAndClang Contact: Dimitry Andric d...@freebsd.org Contact: Roman Divacky rdiva...@freebsd.org Contact: Brooks Davis bro...@freebsd.org Contact: Pawel Worach pawel.wor...@gmail.com We imported newer snapshot of clang/llvm. This features quite a lot
Re: RELENG_8 / mpt / zpool Errors
I don't know what's out there having chosen only one such card for home use. So you'll need to do your own research. Start with looking at any card with the right chip and then look for evidence that people have used said card with FreeBSD. LSI has the SAS 9200-8e, which is based on the SAS 2008 chipset, which the mps (not the mpt) driver claims to support. We are currently using another controller that uses the SAS 2008 chipset in this same box for the internal OS drives and have not had any problems with it. So, that makes me feel good. Does anyone have any recommendation for or against the 9200-8e? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Tim Gustafsont...@soe.ucsc.edu Baskin School of Engineering 831-459-5354 UC Santa Cruz Baskin Engineering 317B -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ___ 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
Thinkpad CD-ROM hotplug with ATA_CAM
Ahoy. I have some Thinkpad T40-T43s running -CURRENT (as recent as yesterday's sources) with ATA_CAM enabled. If I remove the CD-ROM and proceed to run camcontrol rescan all, the system hangs with the cursor still at the end of the the line. Is there a correct way of doing this, or does it just not work right now? Back in the old ATA days, I'd be able to detach the channel with atacontrol, remove the CD-ROM, and put it back without any trouble. -Boris ___ 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: Segfault in libthr.so on 9.0-BETA2 (with stunnel FWIW)
On Wed, Sep 14, 2011 at 03:59:53PM +0300, Kostik Belousov wrote: On Wed, Sep 14, 2011 at 02:36:07PM +0200, Jeremie Le Hen wrote: Hi list, I've recently migrated my services from a box running 8.1-STABLE to another one running 9.0-BETA2. I run stunnel 4.28 on 8.1-STABLE, and it has run flawlessly so far. I compiled manually this very version on 9.0-BETA2. But I get the following segfault: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 803008c00 (LWP 100496/stunnel)] 0x00080110d359 in gmtime_r () from /lib/libc.so.7 (gdb) thread [Current thread is 3 (Thread 803008c00 (LWP 100496/stunnel))] (gdb) bt #0 0x00080110d359 in gmtime_r () from /lib/libc.so.7 #1 0x00080110cdde in gmtime_r () from /lib/libc.so.7 #2 0x00080110dab4 in gmtime_r () from /lib/libc.so.7 #3 0x00080110dcc8 in gmtime_r () from /lib/libc.so.7 #4 0x000800e1d9e8 in pthread_once () from /lib/libthr.so.3 #5 0x00080110ca9f in timegm () from /lib/libc.so.7 #6 0x000805dff8d9 in OPENSSL_gmtime () from /usr/local/lib/libcrypto.so.7 #7 0x000805e74631 in ASN1_UTCTIME_adj () from /usr/local/lib/libcrypto.so.7 #8 0x000805e9462d in X509_time_adj_ex () from /usr/local/lib/libcrypto.so.7 #9 0x000805e9478c in X509_cmp_time () from /usr/local/lib/libcrypto.so.7 #10 0x000805e9496d in internal_verify () from /usr/local/lib/libcrypto.so.7 #11 0x000805e95f46 in X509_verify_cert () from /usr/local/lib/libcrypto.so.7 #12 0x000805b7f4c8 in ssl_verify_cert_chain () from /usr/local/lib/libssl.so.7 #13 0x000805b5d6e3 in ssl3_get_client_certificate () from /usr/local/lib/libssl.so.7 #14 0x000805b612bc in ssl3_accept () from /usr/local/lib/libssl.so.7 #15 0x00406f6e in init_ssl (c=0x803093000) at client.c:329 #16 0x004069a6 in do_client (c=0x803093000) at client.c:202 #17 0x0040676b in run_client (c=0x803093000) at client.c:150 #18 0x004066cf in client (arg=0x803093000) at client.c:123 #19 0x000800e18224 in pthread_getprio () from /lib/libthr.so.3 #20 0x in ?? () Note that I tried with the newest version of stunnel, it crashes at the same place. I also tried libssl.so both from the base system and from the ports, same thing. You need to compile both libc and libthr with debugging symbols and do a backtrace with such libraries. Here it is: #0 0x000807509359 in tzload (name=0x807536281 posixrules, sp=0x7fbf8e80, doextend=0) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:393 #1 0x000807508dde in tzparse (name=0x7fbeec95 , sp=0x7fbf8e80, lastditch=Variable lastditch is not available. ) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1001 #2 0x000807509ab4 in tzload (name=Variable name is not available. ) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:579 #3 0x000807509cc8 in gmtload (sp=0x80776f6c0) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1196 #4 0x00080ce5d9e8 in _pthread_once (once_control=0x80776af00, init_routine=0x807509cf0 gmt_init) at /usr/src/lib/libthr/thread/thr_once.c:87 #5 0x000807508a9f in gmtsub (timep=0x7fbfdaf8, offset=0, tmp=0x7fbfdb00) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1485 #6 0x00080e7e58d9 in OPENSSL_gmtime () from /usr/local/lib/libcrypto.so.7 #7 0x00080e85a631 in ASN1_UTCTIME_adj () from /usr/local/lib/libcrypto.so.7 #8 0x00080e87a62d in X509_time_adj_ex () from /usr/local/lib/libcrypto.so.7 #9 0x00080e87a78c in X509_cmp_time () from /usr/local/lib/libcrypto.so.7 #10 0x00080e87a96d in internal_verify () from /usr/local/lib/libcrypto.so.7 #11 0x00080e87bf46 in X509_verify_cert () from /usr/local/lib/libcrypto.so.7 #12 0x000809ec94c8 in ssl_verify_cert_chain () from /usr/local/lib/libssl.so.7 #13 0x000809ea76e3 in ssl3_get_client_certificate () from /usr/local/lib/libssl.so.7 #14 0x000809eab2bc in ssl3_accept () from /usr/local/lib/libssl.so.7 #15 0x004076f9 in ?? () #16 0x004082cf in ?? () #17 0x00408c50 in ?? () #18 0x00408d17 in ?? () #19 0x00080ce58224 in thread_start (curthread=0x80d408c00) at /usr/src/lib/libthr/thread/thr_create.c:284 #20 0x in ?? () Error accessing memory address 0x7fbfe000: Bad address. -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne ___ 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: Segfault in libthr.so on 9.0-BETA2 (with stunnel FWIW)
On Wednesday, September 14, 2011 8:59:53 am Kostik Belousov wrote: On Wed, Sep 14, 2011 at 02:36:07PM +0200, Jeremie Le Hen wrote: Hi list, I've recently migrated my services from a box running 8.1-STABLE to another one running 9.0-BETA2. I run stunnel 4.28 on 8.1-STABLE, and it has run flawlessly so far. I compiled manually this very version on 9.0-BETA2. But I get the following segfault: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 803008c00 (LWP 100496/stunnel)] 0x00080110d359 in gmtime_r () from /lib/libc.so.7 (gdb) thread [Current thread is 3 (Thread 803008c00 (LWP 100496/stunnel))] (gdb) bt #0 0x00080110d359 in gmtime_r () from /lib/libc.so.7 #1 0x00080110cdde in gmtime_r () from /lib/libc.so.7 #2 0x00080110dab4 in gmtime_r () from /lib/libc.so.7 #3 0x00080110dcc8 in gmtime_r () from /lib/libc.so.7 #4 0x000800e1d9e8 in pthread_once () from /lib/libthr.so.3 #5 0x00080110ca9f in timegm () from /lib/libc.so.7 #6 0x000805dff8d9 in OPENSSL_gmtime () from /usr/local/lib/libcrypto.so.7 #7 0x000805e74631 in ASN1_UTCTIME_adj () from /usr/local/lib/libcrypto.so.7 #8 0x000805e9462d in X509_time_adj_ex () from /usr/local/lib/libcrypto.so.7 #9 0x000805e9478c in X509_cmp_time () from /usr/local/lib/libcrypto.so.7 #10 0x000805e9496d in internal_verify () from /usr/local/lib/libcrypto.so.7 #11 0x000805e95f46 in X509_verify_cert () from /usr/local/lib/libcrypto.so.7 #12 0x000805b7f4c8 in ssl_verify_cert_chain () from /usr/local/lib/libssl.so.7 #13 0x000805b5d6e3 in ssl3_get_client_certificate () from /usr/local/lib/libssl.so.7 #14 0x000805b612bc in ssl3_accept () from /usr/local/lib/libssl.so.7 #15 0x00406f6e in init_ssl (c=0x803093000) at client.c:329 #16 0x004069a6 in do_client (c=0x803093000) at client.c:202 #17 0x0040676b in run_client (c=0x803093000) at client.c:150 #18 0x004066cf in client (arg=0x803093000) at client.c:123 #19 0x000800e18224 in pthread_getprio () from /lib/libthr.so.3 #20 0x in ?? () Note that I tried with the newest version of stunnel, it crashes at the same place. I also tried libssl.so both from the base system and from the ports, same thing. You need to compile both libc and libthr with debugging symbols and do a backtrace with such libraries. You really only need symbols from libc. timegm() probably inlines time1() and maybe even gmtsub() which calls pthread_once() to invoke the static routine gmt_init() in src/lib/libc/stdtime/localtime.c. I wonder if this is similar to the crashes seen in cvsup when parsing /usr/share/zoneinfo/UTC (as gmt_init() is going to parse /usr/share/zoneinfo/UTC as well). -- John Baldwin ___ 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: Thinkpad CD-ROM hotplug with ATA_CAM
on 14/09/2011 18:11 Boris Kochergin said the following: camcontrol rescan all I think that this command may screw up communication between kernel and HDD from which the OS runs. Perhaps using a specific bus number would work better. -- Andriy Gapon ___ 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 9/12/2011 9:57 AM, Fbsd8 wrote: Here are some problems that I fell need to be addressed in the 9.0 bsdinstaller. 7. On the partition editor screen the option finish should be the first in the list (ie; left most side) so if user accepts this config, hitting enter moves to next menu screen instead of having to tab over taking more time and effort. I noticed as well, there is no way to turn off SoftUpdates with Journaling. e.g. despite unselecting that option, I ended up with a file system below. # mount /dev/ada0p3 on / (ufs, local, journaled soft-updates) devfs on /dev (devfs, local, multilabel) /dev/ada0p4 on /usr (ufs, local, journaled soft-updates) /dev/ada0p5 on /var (ufs, local, journaled soft-updates) In the partition editor, OK and Options both have the same hotkeys (O). Also if you change from the suggested partition default, it always wants to add a boot partition even if there is one already there. e.g. go to guided, delete / and the swap and add some partitions. When you create a new / it will say it needs a boot partition, but that already exists and now there will be two. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ 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
Identification of HTT cores on newer (CPUID leaf 11) Intel processors
When FreeBSD examines the CPU topology using CPUID leaf 11 in topo_probe_0xb(), it never sets hyperthreading_cpus. At the end of topo_probe_0x4() it sets hyperthreading_cpus = cpu_logical. Adding that assignment to line 316 of sys/amd64/amd64/mp_machdep.c seems to do the right thing on a system with two quad-core E5620 CPUs. The APIC IDs that appear when SMT is enabled in the BIOS get marked AP/HT. Do you agree? Thanks, Andrew -- Andrew Boyerabo...@averesystems.com ___ 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
USB Keyboard don't Work
Hi... i'm using FreeBSD 8.2 I change the Hard Drive to another position. and FreeBSD don't boot. Appers to change the position o HardDrive. I need to run this command: # mountroot ufs:/dev/ad4s1a but.. the usb keyboard dont work. I tried to run set hint.atkbd.0.flags=0x1 boot -S but the usb keyboard still not working... ___ 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: USB Keyboard don't Work
On Wednesday 14 September 2011 20:46:35 Alisson wrote: Hi... i'm using FreeBSD 8.2 I change the Hard Drive to another position. and FreeBSD don't boot. Appers to change the position o HardDrive. I need to run this command: # mountroot ufs:/dev/ad4s1a but.. the usb keyboard dont work. I tried to run set hint.atkbd.0.flags=0x1 boot -S but the usb keyboard still not working... Hi, This is a known issue. Maybe you need to upgrade to 8-stable before the USB keyboard will work at this point. Is the USB keyboard enumerated before the mountroot prompt? --HPS ___ 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: USB Keyboard don't Work
On Wednesday 14 September 2011 20:46:35 Alisson wrote: Hi... i'm using FreeBSD 8.2 I change the Hard Drive to another position. and FreeBSD don't boot. Appers to change the position o HardDrive. I need to run this command: # mountroot ufs:/dev/ad4s1a but.. the usb keyboard dont work. I tried to run Also try: set hint.atkbd.0.flags=0x1 set hint.atkbd.0.disabled=1 boot -S but the usb keyboard still not working... --HPS ___ 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
Hello, Fbsd8. You wrote 12 сентября 2011 г., 17:57:41: 7. On the partition editor screen the option finish should be the first in the list (ie; left most side) so if user accepts this config, hitting enter moves to next menu screen instead of having to tab over taking more time and effort. And again: there is no way to change block size/frag size/inode number in GUI. Only SU/SU+J/Version present in Options and here is no way to change options after partition creation (adding to dialog) but BEFORE real FS are created (changes are committed). -- // Black Lion AKA Lev Serebryakov l...@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
Re: Identification of HTT cores on newer (CPUID leaf 11) Intel processors
on 14/09/2011 20:59 Andrew Boyer said the following: When FreeBSD examines the CPU topology using CPUID leaf 11 in topo_probe_0xb(), it never sets hyperthreading_cpus. At the end of topo_probe_0x4() it sets hyperthreading_cpus = cpu_logical. Adding that assignment to line 316 of sys/amd64/amd64/mp_machdep.c seems to do the right thing on a system with two quad-core E5620 CPUs. The APIC IDs that appear when SMT is enabled in the BIOS get marked AP/HT. Do you agree? I agree, but... But see this: http://thread.gmane.org/gmane.os.freebsd.devel.hackers/44007/focus=44024 Someone long ago has decided that new HTT is not the same as old HTT and that some rules that apply to old HTT should not apply to new HTT. Even the name. I think that that's not correct. But it doesn't seem that I am able to engage into a discussion the person who made that decision. Also I can not find any other interested developer either. Anyway, hyperthreading_cpus variable is useless beyond dmesg cosmetics. And I don't think that any of my changes affected the dmesg output. In my avgBSD I have different SMP topology code, but it's not ready yet to be submitted for merge into the main tree. -- Andriy Gapon ___ 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: Identification of HTT cores on newer (CPUID leaf 11) Intel processors
On Sep 14, 2011, at 3:56 PM, Andriy Gapon wrote: on 14/09/2011 20:59 Andrew Boyer said the following: When FreeBSD examines the CPU topology using CPUID leaf 11 in topo_probe_0xb(), it never sets hyperthreading_cpus. At the end of topo_probe_0x4() it sets hyperthreading_cpus = cpu_logical. Adding that assignment to line 316 of sys/amd64/amd64/mp_machdep.c seems to do the right thing on a system with two quad-core E5620 CPUs. The APIC IDs that appear when SMT is enabled in the BIOS get marked AP/HT. Do you agree? I agree, but... But see this: http://thread.gmane.org/gmane.os.freebsd.devel.hackers/44007/focus=44024 Someone long ago has decided that new HTT is not the same as old HTT and that some rules that apply to old HTT should not apply to new HTT. Even the name. I think that that's not correct. But it doesn't seem that I am able to engage into a discussion the person who made that decision. Also I can not find any other interested developer either. Anyway, hyperthreading_cpus variable is useless beyond dmesg cosmetics. And I don't think that any of my changes affected the dmesg output. In my avgBSD I have different SMP topology code, but it's not ready yet to be submitted for merge into the main tree. -- Andriy Gapon Actually, it's not useless. If you don't set it to something other than zero the machdep.hyperthreading_allowed tunable doesn't do anything, since it can't tell which CPUs are actually HTT. -Andrew -- Andrew Boyerabo...@averesystems.com ___ 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: Segfault in libthr.so on 9.0-BETA2 (with stunnel FWIW)
On Wed, Sep 14, 2011 at 05:42:21PM +0200, Jeremie Le Hen wrote: On Wed, Sep 14, 2011 at 03:59:53PM +0300, Kostik Belousov wrote: On Wed, Sep 14, 2011 at 02:36:07PM +0200, Jeremie Le Hen wrote: Hi list, I've recently migrated my services from a box running 8.1-STABLE to another one running 9.0-BETA2. I run stunnel 4.28 on 8.1-STABLE, and it has run flawlessly so far. I compiled manually this very version on 9.0-BETA2. But I get the following segfault: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 803008c00 (LWP 100496/stunnel)] 0x00080110d359 in gmtime_r () from /lib/libc.so.7 (gdb) thread [Current thread is 3 (Thread 803008c00 (LWP 100496/stunnel))] (gdb) bt #0 0x00080110d359 in gmtime_r () from /lib/libc.so.7 #1 0x00080110cdde in gmtime_r () from /lib/libc.so.7 #2 0x00080110dab4 in gmtime_r () from /lib/libc.so.7 #3 0x00080110dcc8 in gmtime_r () from /lib/libc.so.7 #4 0x000800e1d9e8 in pthread_once () from /lib/libthr.so.3 #5 0x00080110ca9f in timegm () from /lib/libc.so.7 #6 0x000805dff8d9 in OPENSSL_gmtime () from /usr/local/lib/libcrypto.so.7 #7 0x000805e74631 in ASN1_UTCTIME_adj () from /usr/local/lib/libcrypto.so.7 #8 0x000805e9462d in X509_time_adj_ex () from /usr/local/lib/libcrypto.so.7 #9 0x000805e9478c in X509_cmp_time () from /usr/local/lib/libcrypto.so.7 #10 0x000805e9496d in internal_verify () from /usr/local/lib/libcrypto.so.7 #11 0x000805e95f46 in X509_verify_cert () from /usr/local/lib/libcrypto.so.7 #12 0x000805b7f4c8 in ssl_verify_cert_chain () from /usr/local/lib/libssl.so.7 #13 0x000805b5d6e3 in ssl3_get_client_certificate () from /usr/local/lib/libssl.so.7 #14 0x000805b612bc in ssl3_accept () from /usr/local/lib/libssl.so.7 #15 0x00406f6e in init_ssl (c=0x803093000) at client.c:329 #16 0x004069a6 in do_client (c=0x803093000) at client.c:202 #17 0x0040676b in run_client (c=0x803093000) at client.c:150 #18 0x004066cf in client (arg=0x803093000) at client.c:123 #19 0x000800e18224 in pthread_getprio () from /lib/libthr.so.3 #20 0x in ?? () Note that I tried with the newest version of stunnel, it crashes at the same place. I also tried libssl.so both from the base system and from the ports, same thing. You need to compile both libc and libthr with debugging symbols and do a backtrace with such libraries. Here it is: #0 0x000807509359 in tzload (name=0x807536281 posixrules, sp=0x7fbf8e80, doextend=0) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:393 #1 0x000807508dde in tzparse (name=0x7fbeec95 , sp=0x7fbf8e80, lastditch=Variable lastditch is not available. ) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1001 #2 0x000807509ab4 in tzload (name=Variable name is not available. ) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:579 #3 0x000807509cc8 in gmtload (sp=0x80776f6c0) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1196 #4 0x00080ce5d9e8 in _pthread_once (once_control=0x80776af00, init_routine=0x807509cf0 gmt_init) at /usr/src/lib/libthr/thread/thr_once.c:87 #5 0x000807508a9f in gmtsub (timep=0x7fbfdaf8, offset=0, tmp=0x7fbfdb00) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1485 #6 0x00080e7e58d9 in OPENSSL_gmtime () from /usr/local/lib/libcrypto.so.7 #7 0x00080e85a631 in ASN1_UTCTIME_adj () from /usr/local/lib/libcrypto.so.7 #8 0x00080e87a62d in X509_time_adj_ex () from /usr/local/lib/libcrypto.so.7 #9 0x00080e87a78c in X509_cmp_time () from /usr/local/lib/libcrypto.so.7 #10 0x00080e87a96d in internal_verify () from /usr/local/lib/libcrypto.so.7 #11 0x00080e87bf46 in X509_verify_cert () from /usr/local/lib/libcrypto.so.7 #12 0x000809ec94c8 in ssl_verify_cert_chain () from /usr/local/lib/libssl.so.7 #13 0x000809ea76e3 in ssl3_get_client_certificate () from /usr/local/lib/libssl.so.7 #14 0x000809eab2bc in ssl3_accept () from /usr/local/lib/libssl.so.7 #15 0x004076f9 in ?? () #16 0x004082cf in ?? () #17 0x00408c50 in ?? () #18 0x00408d17 in ?? () #19 0x00080ce58224 in thread_start (curthread=0x80d408c00) at /usr/src/lib/libthr/thread/thr_create.c:284 #20 0x in ?? () Error accessing memory address 0x7fbfe000: Bad address. tzload() allocates ~80KB for the local variables. The backtrace you provided shows the nested call to tzload(), so there is total 160KB of the stack space consumed. By default, stack for the amd64 thread is 4MB, that should be plenty. This is not
Re: Identification of HTT cores on newer (CPUID leaf 11) Intel processors
on 14/09/2011 23:02 Andrew Boyer said the following: Actually, it's not useless. If you don't set it to something other than zero the machdep.hyperthreading_allowed tunable doesn't do anything, since it can't tell which CPUs are actually HTT. Ah, you are right. That works correctly with my (not yet published) patch that doesn't make distinction between HTT flavors. But in the main tree SMT != HTT. -- Andriy Gapon ___ 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: svn commit: r225474 - in head/sys: amd64/amd64 amd64/ia32 i386/i386 ia64/ia32 ia64/ia64 kern powerpc/aim powerpc/booke sparc64/sparc64 sys
On Sun, Sep 11, 2011 at 9:05 AM, Konstantin Belousov k...@freebsd.org wrote: Author: kib Date: Sun Sep 11 16:05:09 2011 New Revision: 225474 URL: http://svn.freebsd.org/changeset/base/225474 Log: Inline the syscallenter() and syscallret(). This reduces the time measured by the syscall entry speed microbenchmarks by ~10% on amd64. Submitted by: jhb Approved by: re (bz) MFC after: 2 weeks This change completely breaks ZFS mounting (for some odd reason) with the following backtrace. #0 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:260 260 /usr/src/sys/kern/kern_shutdown.c: No such file or directory. in /usr/src/sys/kern/kern_shutdown.c (kgdb) #0 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:260 #1 0x802b1cd0 in db_dump (dummy=Variable dummy is not available. ) at /usr/src/sys/ddb/db_command.c:537 #2 0x802b12c1 in db_command (last_cmdp=0x809b96c0, cmd_table=Variable cmd_table is not available. ) at /usr/src/sys/ddb/db_command.c:448 #3 0x802b1510 in db_command_loop () at /usr/src/sys/ddb/db_command.c:501 #4 0x802b3664 in db_trap (type=Variable type is not available. ) at /usr/src/sys/ddb/db_main.c:229 #5 0x804b29d1 in kdb_trap (type=3, code=0, tf=0xff8231a5f3d0) at /usr/src/sys/kern/subr_kdb.c:631 #6 0x80646ac8 in trap (frame=0xff8231a5f3d0) at /usr/src/sys/amd64/amd64/trap.c:590 #7 0x8063113f in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #8 0x804b277b in kdb_enter (why=0x806e022b panic, msg=0x80 Address 0x80 out of bounds) at cpufunc.h:63 #9 0x8047db5c in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:599 #10 0x8046e5cc in _mtx_assert (m=Variable m is not available. ) at /usr/src/sys/kern/kern_mutex.c:706 #11 0x80620f31 in vm_page_free_toq (m=0xfe021bf3d1f0) at /usr/src/sys/vm/vm_page.c:1756 #12 0x80c77938 in zfs_freebsd_getpages () from /boot/kernel/zfs.ko #13 0x8046ebd6 in _mtx_unlock_flags (m=0xfe0006dc7000, opts=421100272, file=0xfe0006dc70e8 ¸PÎ\200, line=1) at /usr/src/sys/kern/kern_mutex.c:223 Previous frame inner to this frame (corrupt stack?) (kgdb) Here's my system info: $ uname -a FreeBSD streetfighter.ixsystems.com 9.0-BETA2 FreeBSD 9.0-BETA2 #2 r225558M: Wed Sep 14 12:09:35 PDT 2011 gcoo...@streetfighter.ixsystems.com:/usr/obj/usr/src/sys/STREETFIGHTER amd64 $ mount /dev/ada0p2 on / (ufs, local, soft-updates) devfs on /dev (devfs, local) tank/scratch on /scratch (zfs, local, nfsv4acls) tank/usr on /usr (zfs, local, nfsv4acls) tank/usr/home on /usr/home (zfs, local, nfsv4acls) tank/usr/src on /usr/src (zfs, local, nfsv4acls) tank/var on /var (zfs, local, nfsv4acls) I tried inspecting 'm' (the mutex), but the value had been optimized out (for some odd reason). I can provide more details offline if interested. Thanks, -Garrett ___ 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: USB Keyboard don't Work
On Wed, Sep 14, 2011 at 12:12 PM, Hans Petter Selasky hsela...@c2i.net wrote: On Wednesday 14 September 2011 20:46:35 Alisson wrote: Hi... i'm using FreeBSD 8.2 I change the Hard Drive to another position. and FreeBSD don't boot. Appers to change the position o HardDrive. I need to run this command: # mountroot ufs:/dev/ad4s1a but.. the usb keyboard dont work. I tried to run Also try: set hint.atkbd.0.flags=0x1 set hint.atkbd.0.disabled=1 boot -S but the usb keyboard still not working... You may also need to build and load kbdmux if your vendor's legacy keyboard handling in the BIOS is broken. HTH, -Garrett ___ 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: svn commit: r225474 - in head/sys: amd64/amd64 amd64/ia32 i386/i386 ia64/ia32 ia64/ia64 kern powerpc/aim powerpc/booke sparc64/sparc64 sys
[It seems that distribution list can be trimmed without any bad consequences] On Wed, Sep 14, 2011 at 01:50:51PM -0700, Garrett Cooper wrote: On Sun, Sep 11, 2011 at 9:05 AM, Konstantin Belousov k...@freebsd.org wrote: Author: kib Date: Sun Sep 11 16:05:09 2011 New Revision: 225474 URL: http://svn.freebsd.org/changeset/base/225474 Log: Inline the syscallenter() and syscallret(). This reduces the time measured by the syscall entry speed microbenchmarks by ~10% on amd64. Submitted by: jhb Approved by: re (bz) MFC after: 2 weeks This change completely breaks ZFS mounting (for some odd reason) with the following backtrace. #0 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:260 260 /usr/src/sys/kern/kern_shutdown.c: No such file or directory. in /usr/src/sys/kern/kern_shutdown.c (kgdb) #0 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:260 #1 0x802b1cd0 in db_dump (dummy=Variable dummy is not available. ) at /usr/src/sys/ddb/db_command.c:537 #2 0x802b12c1 in db_command (last_cmdp=0x809b96c0, cmd_table=Variable cmd_table is not available. ) at /usr/src/sys/ddb/db_command.c:448 #3 0x802b1510 in db_command_loop () at /usr/src/sys/ddb/db_command.c:501 #4 0x802b3664 in db_trap (type=Variable type is not available. ) at /usr/src/sys/ddb/db_main.c:229 #5 0x804b29d1 in kdb_trap (type=3, code=0, tf=0xff8231a5f3d0) at /usr/src/sys/kern/subr_kdb.c:631 #6 0x80646ac8 in trap (frame=0xff8231a5f3d0) at /usr/src/sys/amd64/amd64/trap.c:590 #7 0x8063113f in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #8 0x804b277b in kdb_enter (why=0x806e022b panic, msg=0x80 Address 0x80 out of bounds) at cpufunc.h:63 #9 0x8047db5c in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:599 #10 0x8046e5cc in _mtx_assert (m=Variable m is not available. ) at /usr/src/sys/kern/kern_mutex.c:706 #11 0x80620f31 in vm_page_free_toq (m=0xfe021bf3d1f0) at /usr/src/sys/vm/vm_page.c:1756 #12 0x80c77938 in zfs_freebsd_getpages () from /boot/kernel/zfs.ko #13 0x8046ebd6 in _mtx_unlock_flags (m=0xfe0006dc7000, opts=421100272, file=0xfe0006dc70e8 ?P?\200, line=1) at /usr/src/sys/kern/kern_mutex.c:223 Previous frame inner to this frame (corrupt stack?) (kgdb) The backtrace is impossible and truncated. You probably used unmatched kernel for vmcore, or might be, the zfs.ko is installed without debugging symbols. The change you pointed the finger to has very low probability of causing the panic for vm_page_free_toq(), it is for unrelated part of the kernel. Can you do full rebuild of the kernel without any possible local changes and retest ? If still getting panic, make sure that both kernel and all modules are installed with debug symbols. pgpcgUnppk79u.pgp Description: PGP signature
Re: Segfault in libthr.so on 9.0-BETA2 (with stunnel FWIW)
On Wed, Sep 14, 2011 at 11:04:56PM +0300, Kostik Belousov wrote: tzload() allocates ~80KB for the local variables. The backtrace you provided shows the nested call to tzload(), so there is total 160KB of the stack space consumed. Isn't it a little bit hungry? To do this on stack? Softwares with a large amount of threads might want to reduce their stack size dramatically, and so much space might not be available. By default, stack for the amd64 thread is 4MB, that should be plenty. This is not the case for ezm3. Possibly, stunnel also reduces the size of the thread stack. Correct, I checked stunnel source, it reduces it to 64KB by default. However it is possible to override it from the config file. Raising solves the problem indeed. Please, try the patch below. I did not tested it, only compiled. I see that now tzload allocates only ~300 bytes on the stack. I've also tried it, leaving the default stack size chosen by stunnel. It works. Please go ahead and commit it if it's still possible. Thanks. Regards, -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne ___ 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
changing a zfs pool to another machine
Hi... I have a zfs pool with 3 harddrives (ad8,ad10,ad15) I need to change to another machine... when I try to boot freebsd in the another machine with this 3 harddrives... goes to mountroot prompt. so.. I need to boot with set vfs.root.mountfrom=zfs:tank/root but don't work... goes ever to mountroot prompt.. ___ 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
2011/9/14 Lev Serebryakov l...@freebsd.org: Hello, Fbsd8. You wrote 12 сентября 2011 г., 17:57:41: 7. On the partition editor screen the option finish should be the first in the list (ie; left most side) so if user accepts this config, hitting enter moves to next menu screen instead of having to tab over taking more time and effort. And again: there is no way to change block size/frag size/inode number in GUI. Only SU/SU+J/Version present in Options and here is no way to change options after partition creation (adding to dialog) but BEFORE real FS are created (changes are committed). First, I don't think you get SU+J (soft-updates and full FS journal), which is a bad combination. I think you get SUJ (journal of metadata) which is a very different and is, I believe the preferred default setup. Second, I frequently want custom newfs options, most notably -b, -f, and -i. There was no way to do this with sysinstall and is still no way to do this with bsdinstall. I suggest an option to specify additional newfs options. The test should note that this is for knowledgeable users and that defaults should be used if you don't understand the significance of any options. It should also provide the options that will be passed to newfs if nothing is done. (I'd like to see this in any case, just to avoid confusion on SU+J vs. SUJ.) Of course, all of these are issues that exist with the old installer, but I think can be improved with the move to bsdinstall. -- R. Kevin Oberman, Network Engineer - Retired E-mail: kob6...@gmail.com ___ 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: ataidle + notebook hdd + 9.0-BETA2
Hi. On 14.09.2011 06:59, Nenhum_de_Nos wrote: I just installed BETA2 on WD notebook disk: ada0 at ata2 bus 0 scbus1 target 0 lun 0 ada0: WDC WD5000BPVT-00HXZT1 01.01A01 ATA-8 SATA 2.x device ada0: 150.000MB/s transfers (SATA, UDMA5, PIO 8192bytes) ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 and tried as usual to make the disk last a little longer: rush# ataidle -P 243 /dev/ad4 ataidle: error: identify device /dev/ad4 rush# ataidle -P 243 /dev/ada0 (pass0:ata2:0:0:0): SETFEATURES. ACB: ef 05 00 00 00 40 00 00 00 00 f3 00 (pass0:ata2:0:0:0): CAM status: CCB request completed with an error Failed to configure APM: No error: 0 so, is this still needed after ada took place ? How can I do it now if needed ? Strange CAM status I would say. But try this patch for ataidle: --- ataidle.c.prev 2010-11-04 16:17:28.0 +0200 +++ ataidle.c 2011-09-09 19:30:14.0 +0300 @@ -125,7 +125,7 @@ atacmd_cam(ATA *ata, int atacmd, int fea if (atacmd == ATA__IDENTIFY || atacmd == ATA__ATAPI_IDENTIFY) direction = CAM_DIR_IN; else - direction = CAM_DIR_OUT; + direction = CAM_DIR_NONE; memset((ccb-ccb_h)[1], 0, sizeof(struct ccb_ataio) - sizeof(struct ccb_hdr)); -- Alexander Motin ___ 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: RELENG_8 / mpt / zpool Errors
On Sep 15, 2011 12:42 AM, Tim Gustafson t...@soe.ucsc.edu wrote: I don't know what's out there having chosen only one such card for home use. So you'll need to do your own research. Start with looking at any card with the right chip and then look for evidence that people have used said card with FreeBSD. LSI has the SAS 9200-8e, which is based on the SAS 2008 chipset, which the mps (not the mpt) driver claims to support. We are currently using another controller that uses the SAS 2008 chipset in this same box for the internal OS drives and have not had any problems with it. So, that makes me feel good. Does anyone have any recommendation for or against the 9200-8e? The SAS 2008 chip (SAS 6G) is the one that the FreeBSD mps driver has problems with when used with port expanders. It's the older SAS 3G chip that works OK with FreeBSD I think. ___ 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: cvsup broken on amd64?
I'm also using cvsup again, due to a problem I had with csup back in February 2011 http://www.mail-archive.com/freebsd-stable@freebsd.org/msg114 813.html . I didn't open a PR; I was under some time pressure and cvsup worked. There is a solution of the csup problem: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/154954 I've opened this PR, but nobody has paid to it attentions. :( -- Alexander Zagrebin ___ 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