From owner-freebsd-current@FreeBSD.ORG Sun Apr 3 07:14:50 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 1B942106566B; Sun, 3 Apr 2011 07:14:50 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 5957A152108; Sun, 3 Apr 2011 07:14:48 +0000 (UTC) Message-ID: <4D981E67.8030004@FreeBSD.org> Date: Sun, 03 Apr 2011 00:14:47 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110319 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: jeffr@FreeBSD.org Subject: crash on r220282 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 07:14:50 -0000 #0 sched_switch (td=dwarf2_read_address: Corrupted DWARF expression. ) at /home/svn/head/sys/kern/sched_ule.c:1854 #1 0xffffffff8042b16d in mi_switch (flags=dwarf2_read_address: Corrupted DWARF expression. ) at /home/svn/head/sys/kern/kern_synch.c:450 #2 0xffffffff8045ce3a in sleepq_switch (wchan=dwarf2_read_address: Corrupted DWARF expression. ) at /home/svn/head/sys/kern/subr_sleepqueue.c:538 #3 0xffffffff8045d303 in sleepq_timedwait (wchan=dwarf2_read_address: Corrupted DWARF expression. ) at /home/svn/head/sys/kern/subr_sleepqueue.c:652 #4 0xffffffff8042abe8 in _sleep (ident=Variable "ident" is not available. ) at /home/svn/head/sys/kern/kern_synch.c:230 #5 0xffffffff8065cfa0 in scheduler (dummy=0x0) at /home/svn/head/sys/vm/vm_glue.c:771 #6 0xffffffff803dc2b3 in mi_startup () at /home/svn/head/sys/kern/init_main.c:258 #7 0xffffffff8027164f in btext () #8 0xffffffff80acba60 in bootverbose () #9 0xffffffff80a81a80 in tdq_cpu () #10 0xffffffff80acba60 in bootverbose () #11 0xffffffff80a83800 in sleepq_chains () #12 0xffffffff80caab80 in ?? () #13 0xffffffff80caab28 in ?? () #14 0xfffffe00015d4000 in ?? () #15 0xffffffff80442cd7 in sched_switch (td=dwarf2_read_address: Corrupted DWARF expression. ) at /home/svn/head/sys/kern/sched_ule.c:1848 Previous frame inner to this frame (corrupt stack?) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Sun Apr 3 18:39:58 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C84F1065679 for ; Sun, 3 Apr 2011 18:39:58 +0000 (UTC) (envelope-from christer.solskogen@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 50A558FC0C for ; Sun, 3 Apr 2011 18:39:57 +0000 (UTC) Received: by vws18 with SMTP id 18so4567216vws.13 for ; Sun, 03 Apr 2011 11:39:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=PQVkUixSgy4J0pZgjBc16IDiyZEwdgx2sWYAr3DuGcY=; b=I12Z3Qw9BkiFAu5zGhFIa2fGB0/yVHbUGkwXhGXVdJ0RBt2xfx9vN8+Yae4tZ2HS3p HmryyltpSMoBdo4Sk4i7rnHf8NplhxpnGNKp3vVLsYxsQSeXaKO1KqYwM8QyQhCF8spl xftDuPYoWxpMHgIAnaTg4HxLIvVsudv9zT/4o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=i/UEQJueaxsJ8qK84HBClleRFchX2+KztSRKCgnak+M6RPT6Pb4keNLPoA103Wompc Vns/rSak53ADGq3G2Upoz0DgnI0lgNrb+r9H66jgs1myD1euyA3/XzzzzH2eY1Ygoa37 bqOJsa2mAIKzNgZMeNReCLgNc3NmXloItKbck= Received: by 10.52.88.133 with SMTP id bg5mr8325173vdb.17.1301854534135; Sun, 03 Apr 2011 11:15:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.166.165 with HTTP; Sun, 3 Apr 2011 11:15:14 -0700 (PDT) From: Christer Solskogen Date: Sun, 3 Apr 2011 20:15:14 +0200 Message-ID: To: freebsd-current@freebsd.org, freebsd-ports Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: clang and postgresql90 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 18:39:58 -0000 Hi! I'm just wondering if anyone else has trouble compiling postgresql90 with clang. I get this (and I cant seem to find anything online that somebody else had that same problem): gmake[1]: Leaving directory `/usr/obj/usr/ports/databases/postgresql90-server/work/postgresql-9.0.3/src/timezone' clang -O2 -pipe -march=core2 -O3 -funroll-loops -fno-strict-aliasing -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -L../../src/port - L/usr/local/lib -rpath=/usr/lib:/usr/local/lib -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -Wl,--as-needed -Wl,-R'/usr/local/lib' -Wl,-export-dynamic access/common/heaptuple.o ac cess/common/indextuple.o access/common/printtup.o access/common/reloptions.o access/common/scankey.o access/common/tupconvert.o access/common/tupdesc.o access/gist/gist.o access/gist/gistutil.o access/gis t/gistxlog.o access/gist/gistvacuum.o access/gist/gistget.o access/gist/gistscan.o access/gist/gistproc.o access/gist/gistsplit.o access/hash/hash.o access/hash/hashfunc.o access/hash/hashinsert.o access/ hash/hashovfl.o access/hash/hashpage.o access/hash/hashscan.o access/hash/hashsearch.o access/hash/hashsort.o access/hash/hashutil.o access/heap/heapam.o access/heap/hio.o access/heap/pruneheap.o access/h eap/rewriteheap.o access/heap/syncscan.o access/heap/tuptoaster.o access/heap/visibilitymap.o access/index/genam.o access/index/indexam.o access/nbtree/nbtcompare.o access/nbtree/nbtinsert.o access/nbtree /nbtpage.o access/nbtree/nbtree.o access/nbtree/nbtsearch.o access/nbtree/nbtutils.o access/nbtree/nbtsort.o access/nbtree/nbtxlog.o access/transam/clog.o access/transam/transam.o access/transam/varsup.o access/transam/xact.o access/transam/xlog.o access/transam/xlogutils.o access/transam/rmgr.o access/transam/slru.o access/transam/subtrans.o access/transam/multixact.o access/transam/twophase.o access/tra nsam/twophase_rmgr.o access/gin/ginutil.o access/gin/gininsert.o access/gin/ginxlog.o access/gin/ginentrypage.o access/gin/gindatapage.o access/gin/ginbtree.o access/gin/ginscan.o access/gin/ginget.o acce ss/gin/ginvacuum.o access/gin/ginarrayproc.o access/gin/ginbulk.o access/gin/ginfast.o bootstrap/bootparse.o bootstrap/bootstrap.o catalog/catalog.o catalog/dependency.o catalog/heap.o catalog/index.o cat alog/indexing.o catalog/namespace.o catalog/aclchk.o catalog/pg_aggregate.o catalog/pg_constraint.o catalog/pg_conversion.o catalog/pg_depend.o catalog/pg_enum.o catalog/pg_inherits.o catalog/pg_largeobje ct.o catalog/pg_namespace.o catalog/pg_operator.o catalog/pg_proc.o catalog/pg_db_role_setting.o catalog/pg_shdepend.o catalog/pg_type.o catalog/storage.o catalog/toasting.o parser/analyze.o parser/gram.o parser/keywords.o parser/kwlookup.o parser/parser.o parser/parse_agg.o parser/parse_clause.o parser/parse_coerce.o parser/parse_cte.o parser/parse_expr.o parser/parse_func.o parser/parse_node.o parser/pa rse_oper.o parser/parse_param.o parser/parse_relation.o parser/parse_target.o parser/parse_type.o parser/parse_utilcmd.o parser/scansup.o commands/aggregatecmds.o commands/alter.o commands/analyze.o comma nds/async.o commands/cluster.o commands/comment.o commands/constraint.o commands/conversioncmds.o commands/copy.o commands/dbcommands.o commands/define.o commands/discard.o commands/explain.o commands/for eigncmds.o commands/functioncmds.o commands/indexcmds.o commands/lockcmds.o commands/operatorcmds.o commands/opclasscmds.o commands/portalcmds.o commands/prepare.o commands/proclang.o commands/schemacmds. o commands/sequence.o commands/tablecmds.o commands/tablespace.o commands/trigger.o commands/tsearchcmds.o commands/typecmds.o commands/user.o commands/vacuum.o commands/vacuumlazy.o commands/variable.o commands/view.o executor/execAmi.o executor/execCurrent.o executor/execGrouping.o executor/execJunk.o executor/execMain.o executor/execProcnode.o executor/execQual.o executor/execScan.o executor/execTuples.o executor/execUtils.o executor/functions.o executor/instrument.o executor/nodeAppend.o executor/nodeAgg.o executor/nodeBitmapAnd.o executor/nodeBitmapOr.o executor/nodeBitmapHeapscan.o executor/nodeBitmapIndexscan.o executor/nodeHash.o executor/nodeHashjoin.o executor/nodeIndexscan.o executor/nodeLimit.o executor/nodeLockRows.o executor/nodeMaterial.o executor/nodeMergejoin.o executor/nodeModifyTable.o executor/nodeNestloop.o executor/nodeFunctionscan.o executor/nodeRecursiveunion.o executor/nodeResult.o executor/nodeSeqscan.o executor/nodeSetOp.o executor/nodeSort.o executor/nodeUnique.o executor/nodeValuesscan.o executor/nodeCtescan.o executor/nodeWorktablescan.o executor/nodeGroup.o executor/nodeSubplan.o executor/nodeSubqueryscan.o executor/nodeTidscan.o executor/nodeWindowAgg.o executor/tstoreReceiver.o executor/spi.o foreign/foreign.o lib/dllist.o lib/stringinfo.o libpq/be-fsstubs.o libpq/be-secure.o libpq/auth.o libpq/crypt.o libpq/hba.o libpq/ip.o libpq/md5.o libpq/pqcomm.o libpq/pqformat.o libpq/pqsignal.o main/main.o nodes/nodeFuncs.o nodes/nodes.o nodes/list.o nodes/bitmapset.o nodes/tidbitmap.o nodes/copyfuncs.o nodes/equalfuncs.o nodes/makefuncs.o nodes/outfuncs.o nodes/readfuncs.o nodes/print.o nodes/read.o nodes/params.o nodes/value.o optimizer/geqo/geqo_copy.o optimizer/geqo/geqo_eval.o optimizer/geqo/geqo_main.o optimizer/geqo/geqo_misc.o optimizer/geqo/geqo_mutation.o optimizer/geqo/geqo_pool.o optimizer/geqo/geqo_random.o optimizer/geqo/geqo_recombination.o optimizer/geqo/geqo_selection.o optimizer/geqo/geqo_erx.o optimizer/geqo/geqo_pmx.o optimizer/geqo/geqo_cx.o optimizer/geqo/geqo_px.o optimizer/geqo/geqo_ox1.o optimizer/geqo/geqo_ox2.o optimizer/path/allpaths.o optimizer/path/clausesel.o optimizer/path/costsize.o optimizer/path/equivclass.o optimizer/path/indxpath.o optimizer/path/joinpath.o optimizer/path/joinrels.o optimizer/path/orindxpath.o optimizer/path/pathkeys.o optimizer/path/tidpath.o optimizer/plan/analyzejoins.o optimizer/plan/createplan.o optimizer/plan/initsplan.o optimizer/plan/planagg.o optimizer/plan/planmain.o optimizer/plan/planner.o optimizer/plan/setrefs.o optimizer/plan/subselect.o optimizer/prep/prepjointree.o optimizer/prep/prepqual.o optimizer/prep/preptlist.o optimizer/prep/prepunion.o optimizer/util/clauses.o optimizer/util/joininfo.o optimizer/util/pathnode.o optimizer/util/placeholder.o optimizer/util/plancat.o optimizer/util/predtest.o optimizer/util/relnode.o optimizer/util/restrictinfo.o optimizer/util/tlist.o optimizer/util/var.o port/dynloader.o port/pg_sema.o port/pg_shmem.o postmaster/autovacuum.o postmaster/bgwriter.o postmaster/fork_process.o postmaster/pgarch.o postmaster/pgstat.o postmaster/postmaster.o postmaster/syslogger.o postmaster/walwriter.o regex/regcomp.o regex/regerror.o regex/regexec.o regex/regfree.o replication/walsender.o replication/walreceiverfuncs.o replication/walreceiver.o rewrite/rewriteRemove.o rewrite/rewriteDefine.o rewrite/rewriteHandler.o rewrite/rewriteManip.o rewrite/rewriteSupport.o storage/buffer/buf_table.o storage/buffer/buf_init.o storage/buffer/bufmgr.o storage/buffer/freelist.o storage/buffer/localbuf.o storage/file/fd.o storage/file/buffile.o storage/file/copydir.o storage/freespace/freespace.o storage/freespace/fsmpage.o storage/freespace/indexfsm.o storage/ipc/ipc.o storage/ipc/ipci.o storage/ipc/pmsignal.o storage/ipc/procarray.o storage/ipc/procsignal.o storage/ipc/shmem.o storage/ipc/shmqueue.o storage/ipc/sinval.o storage/ipc/sinvaladt.o storage/ipc/standby.o storage/large_object/inv_api.o storage/lmgr/lmgr.o storage/lmgr/lock.o storage/lmgr/proc.o storage/lmgr/deadlock.o storage/lmgr/lwlock.o storage/lmgr/spin.o storage/lmgr/s_lock.o storage/page/bufpage.o storage/page/itemptr.o storage/smgr/md.o storage/smgr/smgr.o storage/smgr/smgrtype.o tcop/dest.o tcop/fastpath.o tcop/postgres.o tcop/pquery.o tcop/utility.o tsearch/ts_locale.o tsearch/ts_parse.o tsearch/wparser.o tsearch/wparser_def.o tsearch/dict.o tsearch/dict_simple.o tsearch/dict_synonym.o tsearch/dict_thesaurus.o tsearch/dict_ispell.o tsearch/regis.o tsearch/spell.o tsearch/to_tsany.o tsearch/ts_selfuncs.o tsearch/ts_typanalyze.o tsearch/ts_utils.o utils/adt/acl.o utils/adt/arrayfuncs.o utils/adt/array_userfuncs.o utils/adt/arrayutils.o utils/adt/bool.o utils/adt/cash.o utils/adt/char.o utils/adt/date.o utils/adt/datetime.o utils/adt/datum.o utils/adt/domains.o utils/adt/enum.o utils/adt/float.o utils/adt/format_type.o utils/adt/geo_ops.o utils/adt/geo_selfuncs.o utils/adt/int.o utils/adt/int8.o utils/adt/like.o utils/adt/lockfuncs.o utils/adt/misc.o utils/adt/nabstime.o utils/adt/name.o utils/adt/numeric.o utils/adt/numutils.o utils/adt/oid.o utils/adt/oracle_compat.o utils/adt/pseudotypes.o utils/adt/rowtypes.o utils/adt/regexp.o utils/adt/regproc.o utils/adt/ruleutils.o utils/adt/selfuncs.o utils/adt/tid.o utils/adt/timestamp.o utils/adt/varbit.o utils/adt/varchar.o utils/adt/varlena.o utils/adt/version.o utils/adt/xid.o utils/adt/network.o utils/adt/mac.o utils/adt/inet_net_ntop.o utils/adt/inet_net_pton.o utils/adt/ri_triggers.o utils/adt/pg_lzcompress.o utils/adt/pg_locale.o utils/adt/formatting.o utils/adt/ascii.o utils/adt/quote.o utils/adt/pgstatfuncs.o utils/adt/encode.o utils/adt/dbsize.o utils/adt/genfile.o utils/adt/trigfuncs.o utils/adt/tsginidx.o utils/adt/tsgistidx.o utils/adt/tsquery.o utils/adt/tsquery_cleanup.o utils/adt/tsquery_gist.o utils/adt/tsquery_op.o utils/adt/tsquery_rewrite.o utils/adt/tsquery_util.o utils/adt/tsrank.o utils/adt/tsvector.o utils/adt/tsvector_op.o utils/adt/tsvector_parser.o utils/adt/txid.o utils/adt/uuid.o utils/adt/windowfuncs.o utils/adt/xml.o utils/cache/attoptcache.o utils/cache/catcache.o utils/cache/inval.o utils/cache/plancache.o utils/cache/relcache.o utils/cache/relmapper.o utils/cache/spccache.o utils/cache/syscache.o utils/cache/lsyscache.o utils/cache/typcache.o utils/cache/ts_cache.o utils/error/assert.o utils/error/elog.o utils/fmgr/dfmgr.o utils/fmgr/fmgr.o utils/fmgr/funcapi.o utils/hash/dynahash.o utils/hash/hashfn.o utils/hash/pg_crc.o utils/init/globals.o utils/init/miscinit.o utils/init/postinit.o utils/mb/encnames.o utils/mb/conv.o utils/mb/mbutils.o utils/mb/wchar.o utils/mb/wstrcmp.o utils/mb/wstrncmp.o utils/misc/guc.o utils/misc/help_config.o utils/misc/pg_rusage.o utils/misc/ps_status.o utils/misc/superuser.o utils/misc/tzparser.o utils/misc/rbtree.o utils/mmgr/aset.o utils/mmgr/mcxt.o utils/mmgr/portalmem.o utils/resowner/resowner.o utils/sort/logtape.o utils/sort/tuplesort.o utils/sort/tuplestore.o utils/time/combocid.o utils/time/tqual.o utils/time/snapmgr.o utils/fmgrtab.o ../../src/timezone/localtime.o ../../src/timezone/strftime.o ../../src/timezone/pgtz.o ../../src/port/libpgport_srv.a -lxml2 -lssl -lcrypto -lgssapi_krb5 -lcrypt -lm -o postgres clang: warning: argument unused during compilation: '-rpath=/usr/lib:/usr/local/lib' libpq/auth.o: In function `ClientAuthentication': auth.c:(.text+0x51e): undefined reference to `gss_accept_sec_context' auth.c:(.text+0x5c7): undefined reference to `gss_release_buffer' auth.c:(.text+0x6b0): undefined reference to `gss_delete_sec_context' auth.c:(.text+0x6e8): undefined reference to `gss_release_cred' auth.c:(.text+0x70f): undefined reference to `gss_display_name' auth.c:(.text+0x7e8): undefined reference to `gss_release_buffer' auth.c:(.text+0x87d): undefined reference to `gss_release_buffer' libpq/auth.o: In function `pg_GSS_error': auth.c:(.text+0x21b8): undefined reference to `gss_display_status' auth.c:(.text+0x21d8): undefined reference to `gss_release_buffer' auth.c:(.text+0x223a): undefined reference to `gss_display_status' auth.c:(.text+0x225a): undefined reference to `gss_release_buffer' libpq/pqcomm.o: In function `pq_close': pqcomm.c:(.text+0x6d): undefined reference to `gss_delete_sec_context' pqcomm.c:(.text+0x8f): undefined reference to `gss_release_cred' clang: error: linker command failed with exit code 1 (use -v to see invocation) gmake: *** [postgres] Error 1 *** Error code 2 Stop in /usr/ports/databases/postgresql90-server. *** Error code 1 -- chs, From owner-freebsd-current@FreeBSD.ORG Sun Apr 3 18:50:07 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BB63106566C for ; Sun, 3 Apr 2011 18:50:07 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 0A5658FC0C for ; Sun, 3 Apr 2011 18:50:06 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Q6SNA-0007gq-IU for freebsd-current@freebsd.org; Sun, 03 Apr 2011 20:50:04 +0200 Received: from 93-139-189-166.adsl.net.t-com.hr ([93.139.189.166]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 03 Apr 2011 20:50:04 +0200 Received: from gour by 93-139-189-166.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 03 Apr 2011 20:50:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Gour-Gadadhara Dasa Date: Sun, 3 Apr 2011 20:41:57 +0200 Lines: 65 Message-ID: <20110403204157.57d82f50@atmarama.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/7er+i.r_6NZiTLFolMRRBOE"; protocol="application/pgp-signature" X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 93-139-189-166.adsl.net.t-com.hr X-Newsreader: Claws Mail 3.7.8 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) X-Face: 3Cy8q3pLN"sFiKpp%e^3=GTSm2xV5z:O1:| :WC~ei/w@ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 18:50:07 -0000 --Sig_/7er+i.r_6NZiTLFolMRRBOE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello! I've problem with keychain which cannot launch gpg-agent. Here is the result of the attempt to launch it: [gour@atmarama gour] gpg-agent --verbose --debug guru --daemon gpg-agent[80588]: reading options from `/home/gour/.gnupg/gpg-agent.conf'=20 gpg-agent[80588]: enabled debug flags: command cache assuan=20 gpg-agent[80588]: listening on socket `/tmp/gpg-2HgBHJ/S.gpg-agent'=20 gpg-agent[80589]: gpg-agent (GnuPG) 2.0.17 started=20 GPG_AGENT_INFO=3D/tmp/gpg-2HgBHJ/S.gpg-agent:80589:1; export GPG_AGENT_INFO;=20 [1] 80588 bus error gpg-agent --verbose --debug guru --daemon In the log file there are messages like: Apr 3 18:34:01 atmarama kernel: pid 48278 (gpg-agent), uid 1001: exited on signal 10 I've installed gnupg-2.0.17_1 from the ports and my system is: FreeBSD 9.0-CURRENT on x86_64. Any idea? Sincerely, Gour --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 --Sig_/7er+i.r_6NZiTLFolMRRBOE Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQIcBAEBAgAGBQJNmL+GAAoJELhxXPVStcgQCzUP/19000emxFRe9BJQEkavFe39 dnP2EgrUg8GY3vjQ9OWDocElalCzwjflY+kFvTWnBnDh1u6cRxoWROxt+Eicv6Ra yljyTvKu+1i1cTzihaQu2+Exsr4zRFeErgZLj8bW38JPwCXqY9PMdEK9OrOOncri 82mi+d6Kpqiwnfj0GBeu9LnR75pgMy7A12NQjnUX2vp79afeal7t4j2eFnxhkgwK VaiQEMypJqoVtxIUM7vH0GVOTjypPJd3Pu5+pIbVs0X4nP1SuptZnAJpgIanSpsT NMrExskBGouyGI8S0YJy2P3SFmvHVSfo1rkzxeA5cCpLylqlwpGWkiGfrKBgVV+f tsCIdhA+fVAkP17Gc1T5funhyy9KfyHxs1F/T0unxzq4QBR9kpunzXrn0Uqf1IES cz2082kBCgaUd6nJp0oAkZ/DNrijKl7+upYQu1lOp8VpGaVFRumGylV2UYKRPshr 2eD96P/9TsB596xrcaBAt8bDRzGxdIWaBO59QUo8rwNu5JJZvS25zdXAolgg1OMq 29qNpaDfRcQjiACYUPYroN3yfBMjIi9aqfgO2SvOlUmB3zB94G/thRvBLYIXmHM6 OQJbUJZOZ9z6M6zGXKxLo+wFTuHr1g94IHX0HshF6G7LV69DK7ZpyxD0r/jLWQ2L PEHeD7oi0vzP0lk+bhM2 =1tRe -----END PGP SIGNATURE----- --Sig_/7er+i.r_6NZiTLFolMRRBOE-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 3 21:24:04 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4423B106566B; Sun, 3 Apr 2011 21:24:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 187FC8FC0A; Sun, 3 Apr 2011 21:24:03 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p33LO3jQ071353; Sun, 3 Apr 2011 17:24:03 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p33LO3FF071336; Sun, 3 Apr 2011 21:24:03 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 3 Apr 2011 21:24:03 GMT Message-Id: <201104032124.p33LO3FF071336@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 21:24:04 -0000 TB --- 2011-04-03 20:14:22 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-04-03 20:14:22 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-04-03 20:14:22 - cleaning the object tree TB --- 2011-04-03 20:14:33 - cvsupping the source tree TB --- 2011-04-03 20:14:33 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-04-03 20:14:50 - building world TB --- 2011-04-03 20:14:50 - MAKEOBJDIRPREFIX=/obj TB --- 2011-04-03 20:14:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-04-03 20:14:50 - TARGET=sparc64 TB --- 2011-04-03 20:14:50 - TARGET_ARCH=sparc64 TB --- 2011-04-03 20:14:50 - TZ=UTC TB --- 2011-04-03 20:14:50 - __MAKE_CONF=/dev/null TB --- 2011-04-03 20:14:50 - cd /src TB --- 2011-04-03 20:14:50 - /usr/bin/make -B buildworld >>> World build started on Sun Apr 3 20:14:50 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Apr 3 21:19:36 UTC 2011 TB --- 2011-04-03 21:19:36 - generating LINT kernel config TB --- 2011-04-03 21:19:36 - cd /src/sys/sparc64/conf TB --- 2011-04-03 21:19:36 - /usr/bin/make -B LINT TB --- 2011-04-03 21:19:36 - building LINT kernel TB --- 2011-04-03 21:19:36 - MAKEOBJDIRPREFIX=/obj TB --- 2011-04-03 21:19:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-04-03 21:19:36 - TARGET=sparc64 TB --- 2011-04-03 21:19:36 - TARGET_ARCH=sparc64 TB --- 2011-04-03 21:19:36 - TZ=UTC TB --- 2011-04-03 21:19:36 - __MAKE_CONF=/dev/null TB --- 2011-04-03 21:19:36 - cd /src TB --- 2011-04-03 21:19:36 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Apr 3 21:19:37 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_tx_ht.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_sysctl.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ah_osdep.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ath_hal/ah.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/ath_hal/ah.c: In function 'ath_hal_mac_clks': /src/sys/dev/ath/ath_hal/ah.c:433: warning: implicit declaration of function 'IS_5GHZ_FAST_CLOCK_EN' /src/sys/dev/ath/ath_hal/ah.c:433: warning: nested extern declaration of 'IS_5GHZ_FAST_CLOCK_EN' *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-04-03 21:24:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-04-03 21:24:02 - ERROR: failed to build lint kernel TB --- 2011-04-03 21:24:02 - 3137.81 user 693.43 system 4180.42 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sun Apr 3 21:40:46 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96DB8106566B; Sun, 3 Apr 2011 21:40:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5BA0E8FC17; Sun, 3 Apr 2011 21:40:46 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p33LejFT077448; Sun, 3 Apr 2011 17:40:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p33LejLs077443; Sun, 3 Apr 2011 21:40:45 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 3 Apr 2011 21:40:45 GMT Message-Id: <201104032140.p33LejLs077443@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 21:40:46 -0000 TB --- 2011-04-03 20:32:41 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-04-03 20:32:41 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2011-04-03 20:32:41 - cleaning the object tree TB --- 2011-04-03 20:32:52 - cvsupping the source tree TB --- 2011-04-03 20:32:52 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2011-04-03 20:33:07 - building world TB --- 2011-04-03 20:33:07 - MAKEOBJDIRPREFIX=/obj TB --- 2011-04-03 20:33:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-04-03 20:33:07 - TARGET=sun4v TB --- 2011-04-03 20:33:07 - TARGET_ARCH=sparc64 TB --- 2011-04-03 20:33:07 - TZ=UTC TB --- 2011-04-03 20:33:07 - __MAKE_CONF=/dev/null TB --- 2011-04-03 20:33:07 - cd /src TB --- 2011-04-03 20:33:07 - /usr/bin/make -B buildworld >>> World build started on Sun Apr 3 20:33:08 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Apr 3 21:36:49 UTC 2011 TB --- 2011-04-03 21:36:49 - generating LINT kernel config TB --- 2011-04-03 21:36:49 - cd /src/sys/sun4v/conf TB --- 2011-04-03 21:36:49 - /usr/bin/make -B LINT TB --- 2011-04-03 21:36:49 - building LINT kernel TB --- 2011-04-03 21:36:49 - MAKEOBJDIRPREFIX=/obj TB --- 2011-04-03 21:36:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-04-03 21:36:49 - TARGET=sun4v TB --- 2011-04-03 21:36:49 - TARGET_ARCH=sparc64 TB --- 2011-04-03 21:36:49 - TZ=UTC TB --- 2011-04-03 21:36:49 - __MAKE_CONF=/dev/null TB --- 2011-04-03 21:36:49 - cd /src TB --- 2011-04-03 21:36:49 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Apr 3 21:36:49 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_tx_ht.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_sysctl.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ah_osdep.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ath_hal/ah.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/ath_hal/ah.c: In function 'ath_hal_mac_clks': /src/sys/dev/ath/ath_hal/ah.c:433: warning: implicit declaration of function 'IS_5GHZ_FAST_CLOCK_EN' /src/sys/dev/ath/ath_hal/ah.c:433: warning: nested extern declaration of 'IS_5GHZ_FAST_CLOCK_EN' *** Error code 1 Stop in /obj/sun4v.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-04-03 21:40:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-04-03 21:40:45 - ERROR: failed to build lint kernel TB --- 2011-04-03 21:40:45 - 3125.12 user 686.37 system 4083.90 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sun Apr 3 21:48:05 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD1D5106564A; Sun, 3 Apr 2011 21:48:05 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 907668FC15; Sun, 3 Apr 2011 21:48:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p33Lm4Yp018124; Sun, 3 Apr 2011 17:48:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p33Lm4X6018118; Sun, 3 Apr 2011 21:48:04 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 3 Apr 2011 21:48:04 GMT Message-Id: <201104032148.p33Lm4X6018118@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 21:48:05 -0000 TB --- 2011-04-03 20:08:43 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-04-03 20:08:43 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-04-03 20:08:43 - cleaning the object tree TB --- 2011-04-03 20:09:03 - cvsupping the source tree TB --- 2011-04-03 20:09:03 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-04-03 20:09:18 - building world TB --- 2011-04-03 20:09:18 - MAKEOBJDIRPREFIX=/obj TB --- 2011-04-03 20:09:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-04-03 20:09:18 - TARGET=powerpc TB --- 2011-04-03 20:09:18 - TARGET_ARCH=powerpc64 TB --- 2011-04-03 20:09:18 - TZ=UTC TB --- 2011-04-03 20:09:18 - __MAKE_CONF=/dev/null TB --- 2011-04-03 20:09:18 - cd /src TB --- 2011-04-03 20:09:18 - /usr/bin/make -B buildworld >>> World build started on Sun Apr 3 20:09:19 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sun Apr 3 21:44:17 UTC 2011 TB --- 2011-04-03 21:44:17 - generating LINT kernel config TB --- 2011-04-03 21:44:17 - cd /src/sys/powerpc/conf TB --- 2011-04-03 21:44:17 - /usr/bin/make -B LINT TB --- 2011-04-03 21:44:17 - building LINT kernel TB --- 2011-04-03 21:44:17 - MAKEOBJDIRPREFIX=/obj TB --- 2011-04-03 21:44:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-04-03 21:44:17 - TARGET=powerpc TB --- 2011-04-03 21:44:17 - TARGET_ARCH=powerpc64 TB --- 2011-04-03 21:44:17 - TZ=UTC TB --- 2011-04-03 21:44:17 - __MAKE_CONF=/dev/null TB --- 2011-04-03 21:44:17 - cd /src TB --- 2011-04-03 21:44:17 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Apr 3 21:44:17 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_tx_ht.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_sysctl.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ah_osdep.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ath_hal/ah.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/ath_hal/ah.c: In function 'ath_hal_mac_clks': /src/sys/dev/ath/ath_hal/ah.c:433: warning: implicit declaration of function 'IS_5GHZ_FAST_CLOCK_EN' /src/sys/dev/ath/ath_hal/ah.c:433: warning: nested extern declaration of 'IS_5GHZ_FAST_CLOCK_EN' *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-04-03 21:48:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-04-03 21:48:04 - ERROR: failed to build lint kernel TB --- 2011-04-03 21:48:04 - 4611.12 user 1017.61 system 5961.29 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Apr 3 21:54:39 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 189D41065672; Sun, 3 Apr 2011 21:54:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E04A68FC0C; Sun, 3 Apr 2011 21:54:38 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p33Lsct1038768; Sun, 3 Apr 2011 17:54:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p33Lscjd038767; Sun, 3 Apr 2011 21:54:38 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 3 Apr 2011 21:54:38 GMT Message-Id: <201104032154.p33Lscjd038767@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 21:54:39 -0000 TB --- 2011-04-03 20:08:35 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-04-03 20:08:35 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-04-03 20:08:35 - cleaning the object tree TB --- 2011-04-03 20:08:54 - cvsupping the source tree TB --- 2011-04-03 20:08:54 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-04-03 20:09:18 - building world TB --- 2011-04-03 20:09:18 - MAKEOBJDIRPREFIX=/obj TB --- 2011-04-03 20:09:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-04-03 20:09:18 - TARGET=powerpc TB --- 2011-04-03 20:09:18 - TARGET_ARCH=powerpc TB --- 2011-04-03 20:09:18 - TZ=UTC TB --- 2011-04-03 20:09:18 - __MAKE_CONF=/dev/null TB --- 2011-04-03 20:09:18 - cd /src TB --- 2011-04-03 20:09:18 - /usr/bin/make -B buildworld >>> World build started on Sun Apr 3 20:09:19 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Apr 3 21:51:03 UTC 2011 TB --- 2011-04-03 21:51:03 - generating LINT kernel config TB --- 2011-04-03 21:51:03 - cd /src/sys/powerpc/conf TB --- 2011-04-03 21:51:03 - /usr/bin/make -B LINT TB --- 2011-04-03 21:51:03 - building LINT kernel TB --- 2011-04-03 21:51:03 - MAKEOBJDIRPREFIX=/obj TB --- 2011-04-03 21:51:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-04-03 21:51:03 - TARGET=powerpc TB --- 2011-04-03 21:51:03 - TARGET_ARCH=powerpc TB --- 2011-04-03 21:51:03 - TZ=UTC TB --- 2011-04-03 21:51:03 - __MAKE_CONF=/dev/null TB --- 2011-04-03 21:51:03 - cd /src TB --- 2011-04-03 21:51:03 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Apr 3 21:51:03 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_tx_ht.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_sysctl.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ah_osdep.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ath_hal/ah.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/ath_hal/ah.c: In function 'ath_hal_mac_clks': /src/sys/dev/ath/ath_hal/ah.c:433: warning: implicit declaration of function 'IS_5GHZ_FAST_CLOCK_EN' /src/sys/dev/ath/ath_hal/ah.c:433: warning: nested extern declaration of 'IS_5GHZ_FAST_CLOCK_EN' *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-04-03 21:54:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-04-03 21:54:37 - ERROR: failed to build lint kernel TB --- 2011-04-03 21:54:37 - 5198.89 user 901.27 system 6361.99 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Apr 3 22:47:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22E8B106566B; Sun, 3 Apr 2011 22:47:16 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id DC2D08FC08; Sun, 3 Apr 2011 22:47:15 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:b138:26d4:ce6d:1fe4] (unknown [IPv6:2001:7b8:3a7:0:b138:26d4:ce6d:1fe4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id C62205C59; Mon, 4 Apr 2011 00:47:14 +0200 (CEST) Message-ID: <4D98F8F6.3060409@FreeBSD.org> Date: Mon, 04 Apr 2011 00:47:18 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.16pre) Gecko/20110319 Lanikai/3.1.10pre MIME-Version: 1.0 To: Christer Solskogen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: clang and postgresql90 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 22:47:16 -0000 On 2011-04-03 20:15, Christer Solskogen wrote: > I'm just wondering if anyone else has trouble compiling postgresql90 > with clang. I get this (and I cant seem to find anything online that > somebody else had that same problem): ... > libpq/auth.o: In function `ClientAuthentication': > auth.c:(.text+0x51e): undefined reference to `gss_accept_sec_context' > auth.c:(.text+0x5c7): undefined reference to `gss_release_buffer' ... This error is not related to clang, but a problem with postgresql's configure script, in combination with the updated binutils in the base system. You will get the same error if you use gcc. Patch: http://www.andric.com/freebsd/binutils/bu217-databases-postgresql90-server-1.diff Similar one for postgres 8.4: http://www.andric.com/freebsd/binutils/bu217-databases-postgresql84-server-1.diff From owner-freebsd-current@FreeBSD.ORG Mon Apr 4 01:30:52 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDC3F1065676; Mon, 4 Apr 2011 01:30:52 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 958A98FC13; Mon, 4 Apr 2011 01:30:52 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p341UpZk029261; Sun, 3 Apr 2011 21:30:51 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p341Up9J029232; Mon, 4 Apr 2011 01:30:51 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Apr 2011 01:30:51 GMT Message-Id: <201104040130.p341Up9J029232@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 01:30:53 -0000 TB --- 2011-04-04 00:32:57 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-04-04 00:32:57 - starting HEAD tinderbox run for mips/mips TB --- 2011-04-04 00:32:57 - cleaning the object tree TB --- 2011-04-04 00:33:04 - cvsupping the source tree TB --- 2011-04-04 00:33:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2011-04-04 00:33:18 - building world TB --- 2011-04-04 00:33:18 - MAKEOBJDIRPREFIX=/obj TB --- 2011-04-04 00:33:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-04-04 00:33:18 - TARGET=mips TB --- 2011-04-04 00:33:18 - TARGET_ARCH=mips TB --- 2011-04-04 00:33:18 - TZ=UTC TB --- 2011-04-04 00:33:18 - __MAKE_CONF=/dev/null TB --- 2011-04-04 00:33:18 - cd /src TB --- 2011-04-04 00:33:18 - /usr/bin/make -B buildworld >>> World build started on Mon Apr 4 00:33:19 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] ===> usr.sbin/usbdump (all) cc -O -pipe -G0 -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/usbdump/usbdump.c cc1: warnings being treated as errors /src/usr.sbin/usbdump/usbdump.c: In function 'print_apacket': /src/usr.sbin/usbdump/usbdump.c:339: warning: format '%06ju' expects type 'uintmax_t', but argument 4 has type 'suseconds_t' /src/usr.sbin/usbdump/usbdump.c:347: warning: cast increases required alignment of target type /src/usr.sbin/usbdump/usbdump.c: In function 'print_packets': /src/usr.sbin/usbdump/usbdump.c:393: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.sbin/usbdump. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-04-04 01:30:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-04-04 01:30:51 - ERROR: failed to build world TB --- 2011-04-04 01:30:51 - 2521.65 user 612.70 system 3473.38 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Mon Apr 4 02:19:03 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFCA4106564A; Mon, 4 Apr 2011 02:19:03 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 810D58FC1B; Mon, 4 Apr 2011 02:19:03 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p342J2e7089064; Sun, 3 Apr 2011 22:19:02 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p342J2c3088994; Mon, 4 Apr 2011 02:19:02 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Apr 2011 02:19:02 GMT Message-Id: <201104040219.p342J2c3088994@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 02:19:03 -0000 TB --- 2011-04-04 01:14:10 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-04-04 01:14:10 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-04-04 01:14:10 - cleaning the object tree TB --- 2011-04-04 01:14:20 - cvsupping the source tree TB --- 2011-04-04 01:14:20 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-04-04 01:14:32 - building world TB --- 2011-04-04 01:14:32 - MAKEOBJDIRPREFIX=/obj TB --- 2011-04-04 01:14:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-04-04 01:14:32 - TARGET=sparc64 TB --- 2011-04-04 01:14:32 - TARGET_ARCH=sparc64 TB --- 2011-04-04 01:14:32 - TZ=UTC TB --- 2011-04-04 01:14:32 - __MAKE_CONF=/dev/null TB --- 2011-04-04 01:14:32 - cd /src TB --- 2011-04-04 01:14:32 - /usr/bin/make -B buildworld >>> World build started on Mon Apr 4 01:14:34 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] gzip -cn /src/usr.sbin/usbconfig/usbconfig.8 > usbconfig.8.gz ===> usr.sbin/usbdump (all) cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/usbdump/usbdump.c cc1: warnings being treated as errors /src/usr.sbin/usbdump/usbdump.c: In function 'print_apacket': /src/usr.sbin/usbdump/usbdump.c:347: warning: cast increases required alignment of target type /src/usr.sbin/usbdump/usbdump.c: In function 'print_packets': /src/usr.sbin/usbdump/usbdump.c:393: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.sbin/usbdump. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-04-04 02:19:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-04-04 02:19:02 - ERROR: failed to build world TB --- 2011-04-04 02:19:02 - 2949.16 user 628.47 system 3892.17 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Mon Apr 4 02:34:33 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B4B91065673; Mon, 4 Apr 2011 02:34:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5BFAD8FC16; Mon, 4 Apr 2011 02:34:32 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p342YWKv088753; Sun, 3 Apr 2011 22:34:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p342YWpq088730; Mon, 4 Apr 2011 02:34:32 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Apr 2011 02:34:32 GMT Message-Id: <201104040234.p342YWpq088730@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 02:34:33 -0000 TB --- 2011-04-04 01:30:51 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-04-04 01:30:51 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2011-04-04 01:30:51 - cleaning the object tree TB --- 2011-04-04 01:31:01 - cvsupping the source tree TB --- 2011-04-04 01:31:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2011-04-04 01:31:15 - building world TB --- 2011-04-04 01:31:15 - MAKEOBJDIRPREFIX=/obj TB --- 2011-04-04 01:31:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-04-04 01:31:15 - TARGET=sun4v TB --- 2011-04-04 01:31:15 - TARGET_ARCH=sparc64 TB --- 2011-04-04 01:31:15 - TZ=UTC TB --- 2011-04-04 01:31:15 - __MAKE_CONF=/dev/null TB --- 2011-04-04 01:31:15 - cd /src TB --- 2011-04-04 01:31:15 - /usr/bin/make -B buildworld >>> World build started on Mon Apr 4 01:31:15 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] gzip -cn /src/usr.sbin/usbconfig/usbconfig.8 > usbconfig.8.gz ===> usr.sbin/usbdump (all) cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/usbdump/usbdump.c cc1: warnings being treated as errors /src/usr.sbin/usbdump/usbdump.c: In function 'print_apacket': /src/usr.sbin/usbdump/usbdump.c:347: warning: cast increases required alignment of target type /src/usr.sbin/usbdump/usbdump.c: In function 'print_packets': /src/usr.sbin/usbdump/usbdump.c:393: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.sbin/usbdump. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-04-04 02:34:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-04-04 02:34:32 - ERROR: failed to build world TB --- 2011-04-04 02:34:32 - 2937.50 user 627.27 system 3820.42 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Mon Apr 4 02:44:10 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 297201065674; Mon, 4 Apr 2011 02:44:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D4B008FC12; Mon, 4 Apr 2011 02:44:09 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p342i9cL034065; Sun, 3 Apr 2011 22:44:09 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p342i9D4034057; Mon, 4 Apr 2011 02:44:09 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Apr 2011 02:44:09 GMT Message-Id: <201104040244.p342i9D4034057@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 02:44:10 -0000 TB --- 2011-04-04 01:02:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-04-04 01:02:00 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-04-04 01:02:00 - cleaning the object tree TB --- 2011-04-04 01:02:12 - cvsupping the source tree TB --- 2011-04-04 01:02:12 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-04-04 01:02:57 - building world TB --- 2011-04-04 01:02:57 - MAKEOBJDIRPREFIX=/obj TB --- 2011-04-04 01:02:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-04-04 01:02:57 - TARGET=powerpc TB --- 2011-04-04 01:02:57 - TARGET_ARCH=powerpc TB --- 2011-04-04 01:02:57 - TZ=UTC TB --- 2011-04-04 01:02:57 - __MAKE_CONF=/dev/null TB --- 2011-04-04 01:02:57 - cd /src TB --- 2011-04-04 01:02:57 - /usr/bin/make -B buildworld >>> World build started on Mon Apr 4 01:02:57 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.sbin/usbconfig/dump.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -o usbconfig usbconfig.o dump.o -lusb gzip -cn /src/usr.sbin/usbconfig/usbconfig.8 > usbconfig.8.gz ===> usr.sbin/usbdump (all) cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/usbdump/usbdump.c cc1: warnings being treated as errors /src/usr.sbin/usbdump/usbdump.c: In function 'print_apacket': /src/usr.sbin/usbdump/usbdump.c:339: warning: format '%06ju' expects type 'uintmax_t', but argument 4 has type 'suseconds_t' *** Error code 1 Stop in /src/usr.sbin/usbdump. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-04-04 02:44:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-04-04 02:44:08 - ERROR: failed to build world TB --- 2011-04-04 02:44:08 - 5007.23 user 836.77 system 6128.28 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Apr 4 04:25:09 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83FCC106564A; Mon, 4 Apr 2011 04:25:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2A56E8FC17; Mon, 4 Apr 2011 04:25:09 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p344P8Vv077781; Mon, 4 Apr 2011 00:25:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p344P8HU077780; Mon, 4 Apr 2011 04:25:08 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Apr 2011 04:25:08 GMT Message-Id: <201104040425.p344P8HU077780@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 04:25:09 -0000 TB --- 2011-04-04 03:30:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-04-04 03:30:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-04-04 03:30:00 - cleaning the object tree TB --- 2011-04-04 03:30:13 - cvsupping the source tree TB --- 2011-04-04 03:30:13 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-04-04 03:30:29 - building world TB --- 2011-04-04 03:30:29 - MAKEOBJDIRPREFIX=/obj TB --- 2011-04-04 03:30:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-04-04 03:30:29 - TARGET=arm TB --- 2011-04-04 03:30:29 - TARGET_ARCH=arm TB --- 2011-04-04 03:30:29 - TZ=UTC TB --- 2011-04-04 03:30:29 - __MAKE_CONF=/dev/null TB --- 2011-04-04 03:30:29 - cd /src TB --- 2011-04-04 03:30:29 - /usr/bin/make -B buildworld >>> World build started on Mon Apr 4 03:30:30 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] ===> usr.sbin/usbdump (all) cc -O -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/usbdump/usbdump.c cc1: warnings being treated as errors /src/usr.sbin/usbdump/usbdump.c: In function 'print_apacket': /src/usr.sbin/usbdump/usbdump.c:339: warning: format '%06ju' expects type 'uintmax_t', but argument 4 has type 'suseconds_t' /src/usr.sbin/usbdump/usbdump.c:347: warning: cast increases required alignment of target type /src/usr.sbin/usbdump/usbdump.c: In function 'print_packets': /src/usr.sbin/usbdump/usbdump.c:393: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.sbin/usbdump. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-04-04 04:25:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-04-04 04:25:07 - ERROR: failed to build world TB --- 2011-04-04 04:25:08 - 2411.94 user 651.21 system 3307.11 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Mon Apr 4 05:20:45 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 851351065670; Mon, 4 Apr 2011 05:20:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 3F37F8FC1B; Mon, 4 Apr 2011 05:20:45 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p345KiW8088229; Mon, 4 Apr 2011 01:20:44 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p345Ki75088228; Mon, 4 Apr 2011 05:20:44 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Apr 2011 05:20:44 GMT Message-Id: <201104040520.p345Ki75088228@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 05:20:45 -0000 TB --- 2011-04-04 03:30:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-04-04 03:30:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-04-04 03:30:00 - cleaning the object tree TB --- 2011-04-04 03:30:21 - cvsupping the source tree TB --- 2011-04-04 03:30:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-04-04 03:30:35 - building world TB --- 2011-04-04 03:30:35 - MAKEOBJDIRPREFIX=/obj TB --- 2011-04-04 03:30:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-04-04 03:30:35 - TARGET=pc98 TB --- 2011-04-04 03:30:35 - TARGET_ARCH=i386 TB --- 2011-04-04 03:30:35 - TZ=UTC TB --- 2011-04-04 03:30:35 - __MAKE_CONF=/dev/null TB --- 2011-04-04 03:30:35 - cd /src TB --- 2011-04-04 03:30:35 - /usr/bin/make -B buildworld >>> World build started on Mon Apr 4 03:30:35 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.sbin/usbconfig/dump.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -o usbconfig usbconfig.o dump.o -lusb gzip -cn /src/usr.sbin/usbconfig/usbconfig.8 > usbconfig.8.gz ===> usr.sbin/usbdump (all) cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/usbdump/usbdump.c cc1: warnings being treated as errors /src/usr.sbin/usbdump/usbdump.c: In function 'print_apacket': /src/usr.sbin/usbdump/usbdump.c:339: warning: format '%06ju' expects type 'uintmax_t', but argument 4 has type 'suseconds_t' *** Error code 1 Stop in /src/usr.sbin/usbdump. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-04-04 05:20:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-04-04 05:20:43 - ERROR: failed to build world TB --- 2011-04-04 05:20:43 - 5374.63 user 902.53 system 6642.89 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Mon Apr 4 05:21:10 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD0FE106566C; Mon, 4 Apr 2011 05:21:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 76DB78FC1E; Mon, 4 Apr 2011 05:21:10 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p345L9dh089769; Mon, 4 Apr 2011 01:21:09 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p345L96A089767; Mon, 4 Apr 2011 05:21:09 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Apr 2011 05:21:09 GMT Message-Id: <201104040521.p345L96A089767@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 05:21:10 -0000 TB --- 2011-04-04 03:30:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-04-04 03:30:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-04-04 03:30:00 - cleaning the object tree TB --- 2011-04-04 03:30:25 - cvsupping the source tree TB --- 2011-04-04 03:30:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-04-04 03:30:37 - building world TB --- 2011-04-04 03:30:37 - MAKEOBJDIRPREFIX=/obj TB --- 2011-04-04 03:30:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-04-04 03:30:37 - TARGET=i386 TB --- 2011-04-04 03:30:37 - TARGET_ARCH=i386 TB --- 2011-04-04 03:30:37 - TZ=UTC TB --- 2011-04-04 03:30:37 - __MAKE_CONF=/dev/null TB --- 2011-04-04 03:30:37 - cd /src TB --- 2011-04-04 03:30:37 - /usr/bin/make -B buildworld >>> World build started on Mon Apr 4 03:30:45 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.sbin/usbconfig/dump.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -o usbconfig usbconfig.o dump.o -lusb gzip -cn /src/usr.sbin/usbconfig/usbconfig.8 > usbconfig.8.gz ===> usr.sbin/usbdump (all) cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/usbdump/usbdump.c cc1: warnings being treated as errors /src/usr.sbin/usbdump/usbdump.c: In function 'print_apacket': /src/usr.sbin/usbdump/usbdump.c:339: warning: format '%06ju' expects type 'uintmax_t', but argument 4 has type 'suseconds_t' *** Error code 1 Stop in /src/usr.sbin/usbdump. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-04-04 05:21:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-04-04 05:21:09 - ERROR: failed to build world TB --- 2011-04-04 05:21:09 - 5407.24 user 889.99 system 6668.79 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Mon Apr 4 05:50:49 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8B60106564A; Mon, 4 Apr 2011 05:50:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 4F44B8FC12; Mon, 4 Apr 2011 05:50:49 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p345omZk034474; Mon, 4 Apr 2011 01:50:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p345omTv034441; Mon, 4 Apr 2011 05:50:48 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Apr 2011 05:50:48 GMT Message-Id: <201104040550.p345omTv034441@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 05:50:49 -0000 TB --- 2011-04-04 04:25:08 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-04-04 04:25:08 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-04-04 04:25:08 - cleaning the object tree TB --- 2011-04-04 04:25:20 - cvsupping the source tree TB --- 2011-04-04 04:25:20 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-04-04 04:25:48 - building world TB --- 2011-04-04 04:25:48 - MAKEOBJDIRPREFIX=/obj TB --- 2011-04-04 04:25:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-04-04 04:25:48 - TARGET=ia64 TB --- 2011-04-04 04:25:48 - TARGET_ARCH=ia64 TB --- 2011-04-04 04:25:48 - TZ=UTC TB --- 2011-04-04 04:25:48 - __MAKE_CONF=/dev/null TB --- 2011-04-04 04:25:48 - cd /src TB --- 2011-04-04 04:25:48 - /usr/bin/make -B buildworld >>> World build started on Mon Apr 4 04:25:49 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] gzip -cn /src/usr.sbin/usbconfig/usbconfig.8 > usbconfig.8.gz ===> usr.sbin/usbdump (all) cc -O2 -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/usbdump/usbdump.c cc1: warnings being treated as errors /src/usr.sbin/usbdump/usbdump.c: In function 'print_apacket': /src/usr.sbin/usbdump/usbdump.c:347: warning: cast increases required alignment of target type /src/usr.sbin/usbdump/usbdump.c: In function 'print_packets': /src/usr.sbin/usbdump/usbdump.c:393: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.sbin/usbdump. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-04-04 05:50:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-04-04 05:50:48 - ERROR: failed to build world TB --- 2011-04-04 05:50:48 - 4131.95 user 708.39 system 5139.60 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Mon Apr 4 05:57:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19CC51065670 for ; Mon, 4 Apr 2011 05:57:21 +0000 (UTC) (envelope-from yuri.pankov@gmail.com) Received: from darklight.org.ru (darklight.org.ru [IPv6:2001:470:28:4ba::1]) by mx1.freebsd.org (Postfix) with ESMTP id 438078FC08 for ; Mon, 4 Apr 2011 05:57:19 +0000 (UTC) Received: from darklight.org.ru (yuri@darklight.org.ru [IPv6:::1]) by darklight.org.ru (8.14.4/8.14.4) with ESMTP id p345vEOR096656; Mon, 4 Apr 2011 09:57:14 +0400 (MSD) (envelope-from yuri.pankov@gmail.com) Received: (from yuri@localhost) by darklight.org.ru (8.14.4/8.14.4/Submit) id p345vDSX096655; Mon, 4 Apr 2011 09:57:13 +0400 (MSD) (envelope-from yuri.pankov@gmail.com) X-Authentication-Warning: darklight.org.ru: yuri set sender to yuri.pankov@gmail.com using -f Date: Mon, 4 Apr 2011 09:57:13 +0400 From: Yuri Pankov To: Gour-Gadadhara Dasa Message-ID: <20110404055713.GA1289@darklight.org.ru> References: <20110403204157.57d82f50@atmarama.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110403204157.57d82f50@atmarama.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: gpg-agent & bus error (signal 10) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 05:57:21 -0000 On Sun, Apr 03, 2011 at 08:41:57PM +0200, Gour-Gadadhara Dasa wrote: > > Hello! > > I've problem with keychain which cannot launch gpg-agent. Here is the > result of the attempt to launch it: > > [gour@atmarama gour] gpg-agent --verbose --debug guru --daemon > gpg-agent[80588]: reading options from `/home/gour/.gnupg/gpg-agent.conf' > gpg-agent[80588]: enabled debug flags: command cache assuan > gpg-agent[80588]: listening on socket `/tmp/gpg-2HgBHJ/S.gpg-agent' > gpg-agent[80589]: gpg-agent (GnuPG) 2.0.17 started > GPG_AGENT_INFO=/tmp/gpg-2HgBHJ/S.gpg-agent:80589:1; > export GPG_AGENT_INFO; > [1] 80588 bus error gpg-agent --verbose --debug guru --daemon > > In the log file there are messages like: > > Apr 3 18:34:01 atmarama kernel: pid 48278 (gpg-agent), uid 1001: > exited on signal 10 > > I've installed gnupg-2.0.17_1 from the ports and my system is: > FreeBSD 9.0-CURRENT on x86_64. > > Any idea? > > > Sincerely, > Gour > > -- > “In the material world, conceptions of good and bad are > all mental speculations…†(Sri Caitanya Mahaprabhu) > > http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 > > http://lists.freebsd.org/pipermail/freebsd-ports/2011-March/066146.html The workaround is `ln -sf j /etc/malloc.conf`. HTH, Yuri From owner-freebsd-current@FreeBSD.ORG Mon Apr 4 06:21:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FFDE106564A; Mon, 4 Apr 2011 06:21:16 +0000 (UTC) (envelope-from christer.solskogen@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 103E88FC1A; Mon, 4 Apr 2011 06:21:15 +0000 (UTC) Received: by vws18 with SMTP id 18so4803532vws.13 for ; Sun, 03 Apr 2011 23:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=VCmHNJLLVtXk5OC8EL9ZR0/zyTwCDMewlAAmTZBbYBI=; b=oAWt2vc41S1qIP0w7Ozjv7c+ZWUb4cMWAS52x8L8o9HZaRpeZjNH79tXMH2u4z3Sbu I66IpLBbTehYVJQPPyoc5RqZrh9KAVHgiZE9vWGt4FLz7TeGqfRkTc6meb3Pz4VGCR3g sJIhogWwitdj/eJ0B5a2/GaHwwZCpJDoafQUw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=o0GnNOuokVhG+KZatStf3pdJqEybl38RWtyeSgMkiwhOkyIKH9mValM183eR/KOHvO 41ZWXxqL6p37NgyAQwjJiczI/n41mmEja1CEqzJbRM8Cp6I658hNyoW+QchkjmZy2FCF zJL8fkcDloVjfPuEQJOal8O64YZ/0ikOnBzZA= Received: by 10.52.173.108 with SMTP id bj12mr2846405vdc.177.1301898075398; Sun, 03 Apr 2011 23:21:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.166.165 with HTTP; Sun, 3 Apr 2011 23:20:55 -0700 (PDT) In-Reply-To: <4D98F8F6.3060409@FreeBSD.org> References: <4D98F8F6.3060409@FreeBSD.org> From: Christer Solskogen Date: Mon, 4 Apr 2011 08:20:55 +0200 Message-ID: To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: clang and postgresql90 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 06:21:16 -0000 On Mon, Apr 4, 2011 at 12:47 AM, Dimitry Andric wrote: > On 2011-04-03 20:15, Christer Solskogen wrote: >> >> I'm just wondering if anyone else has trouble compiling postgresql90 >> with clang. I get this (and I cant seem to find anything online that >> somebody else had that same problem): > > ... >> >> libpq/auth.o: In function `ClientAuthentication': >> auth.c:(.text+0x51e): undefined reference to `gss_accept_sec_context' >> auth.c:(.text+0x5c7): undefined reference to `gss_release_buffer' > > ... > > This error is not related to clang, but a problem with postgresql's > configure script, in combination with the updated binutils in the base > system. =A0You will get the same error if you use gcc. > > Patch: > http://www.andric.com/freebsd/binutils/bu217-databases-postgresql90-serve= r-1.diff > > Similar one for postgres 8.4: > http://www.andric.com/freebsd/binutils/bu217-databases-postgresql84-serve= r-1.diff > Okay, thanks :-) --=20 chs, From owner-freebsd-current@FreeBSD.ORG Mon Apr 4 08:58:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE1C11065670 for ; Mon, 4 Apr 2011 08:58:16 +0000 (UTC) (envelope-from gour@atmarama.net) Received: from mail.wservices.ch (mail.wservices.ch [91.121.152.196]) by mx1.freebsd.org (Postfix) with ESMTP id 7EE108FC14 for ; Mon, 4 Apr 2011 08:58:16 +0000 (UTC) Received: from localhost (93-139-189-166.adsl.net.t-com.hr [93.139.189.166]) by mail.wservices.ch (Postfix) with ESMTPA id 0145445E41 for ; Mon, 4 Apr 2011 10:37:56 +0200 (CEST) Date: Mon, 4 Apr 2011 10:37:48 +0200 From: Gour-Gadadhara Dasa To: freebsd-current@freebsd.org Message-ID: <20110404103748.7b470f13@atmarama.net> In-Reply-To: <20110404055713.GA1289@darklight.org.ru> References: <20110403204157.57d82f50@atmarama.net> <20110404055713.GA1289@darklight.org.ru> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) X-Face: 3Cy8q3pLN"sFiKpp%e^3=GTSm2xV5z:O1:| :WC~ei/w@ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 08:58:16 -0000 --Sig_/2SNg77wwWN.5YLioDgaLg=a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, 4 Apr 2011 09:57:13 +0400 Yuri Pankov wrote: > http://lists.freebsd.org/pipermail/freebsd-ports/2011-March/066146.html >=20 > The workaround is `ln -sf j /etc/malloc.conf`. Thanks a lot. It solved the issue. :-) Sincerely, Gour --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 --Sig_/2SNg77wwWN.5YLioDgaLg=a Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQIcBAEBAgAGBQJNmYNjAAoJELhxXPVStcgQim0P/REZ6FEONKvYB45iGhM5Pfbb ba8rqeYVPobjj3/UCnvJGXM956/vwuEgfOOhjoPl9xn/wOezVlZPc6JRjYnbXL7M 7qyUKvykaEl5NbdxETNtzHMKmf0muInA88wiDy6mCf7coy9jtepIP0B8juDiAKT3 UrVmzu7xBBcewQjq2WAqI+/9H0Cfrw2E8g41h0PiSC7i7zfzkTBA/u9BWFkoiikv Sb5MUtVq0AEYIVQaFrfC28UUDiv23dK5Z4/WalfmbeSeoya3krzWDQELST32iKEY XGFJnrNsP3UBoW/APJ9+EOrnpwgm5lj2AObAo5VtqfK62Sl9JEE8M0KBtIW0fp1Q 0lh+Po6fGeYHXm9vMUN42gcZ1YVsbv98mb6fc0gi+rOob/BctAaUQuHNzlZOLC6l hL7DFktqYbC1jXFlJe9hlERDIGvtcbukMkn43yR5NPNuFY/HF49Jav8rOY7onF/F vRUNB6fzGXp/QpRGrJMpr+4GO/4wNdqcStcmyDkEEnUtSHIdhNmA13IR3AtdgWAK OaybaxM822mhA8+Pq7WNxKUH9E6/sfDIixugAAd1LnJR+lVkA6H3zI6PyeD1kQnz /0RXZq04T7E4K/RBurbIxzeeglVU95H8ui3w2omPy10j7hk78gMz6o4CGMdTltR7 MR3TB5Qez+kVNdxdKiUl =9cp3 -----END PGP SIGNATURE----- --Sig_/2SNg77wwWN.5YLioDgaLg=a-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 4 18:08:18 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3233A1065670; Mon, 4 Apr 2011 18:08:18 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id AAAF78FC15; Mon, 4 Apr 2011 18:08:17 +0000 (UTC) Received: by gwb15 with SMTP id 15so2676328gwb.13 for ; Mon, 04 Apr 2011 11:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EfLMaC/AC8XXDP+HKtYpN1Z/ELniFgXm5K1acXZv2rs=; b=bAXSY0zIBAuXiKxHLQ0k6PY27CZ4rTEBxtHVRY/5W1vasifLwpMFFlbY1l6jqeofj9 tzRBbnFvWjeaxB/ScfbigxL0ILFlT9lkh8CcKxtueJ0R3187y9njWRbrfXmTv7cZKC9S iLXk9hUbxfufV8yP4SuDr0c4Vt8RBosannMao= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GkkPKX+LCkVq8lM1AM3B4EY08TKLTSch/Cej/mMXtTqaNLTJRd1GxaUZmtKq376T1S N1olonMvaJIyLkufy4YL9B23zmSup6hAtkrMSowQv9vj/RtZhV2FJCwLo4tc+IojV7Vw 4FeGcrhGE3qJ3cVcrWxO2LN6rtvl8k7nddvBY= MIME-Version: 1.0 Received: by 10.90.14.39 with SMTP id 39mr4164095agn.127.1301940496804; Mon, 04 Apr 2011 11:08:16 -0700 (PDT) Received: by 10.90.51.14 with HTTP; Mon, 4 Apr 2011 11:08:16 -0700 (PDT) In-Reply-To: <20110402084431.GB1849@garage.freebsd.pl> References: <20110402084431.GB1849@garage.freebsd.pl> Date: Mon, 4 Apr 2011 11:08:16 -0700 Message-ID: From: Freddie Cash To: Pawel Jakub Dawidek Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Filesystems , FreeBSD-Current , FreeBSD Stable Subject: Re: Any success stories for HAST + ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 18:08:18 -0000 On Sat, Apr 2, 2011 at 1:44 AM, Pawel Jakub Dawidek wrote= : > On Thu, Mar 24, 2011 at 01:36:32PM -0700, Freddie Cash wrote: >> [Not sure which list is most appropriate since it's using HAST + ZFS >> on -RELEASE, -STABLE, and -CURRENT. =C2=A0Feel free to trim the CC: on >> replies.] >> >> I'm having a hell of a time making this work on real hardware, and am >> not ruling out hardware issues as yet, but wanted to get some >> reassurance that someone out there is using this combination (FreeBSD >> + HAST + ZFS) successfully, without kernel panics, without core dumps, >> without deadlocks, without issues, etc. =C2=A0I need to know I'm not >> chasing a dead rabbit. > > I just committed a fix for a problem that might look like a deadlock. > With trociny@ patch and my last fix (to GEOM GATE and hastd) do you > still have any issues? Just to confirm, this is commit r220264, 220265, 220266 to -CURRENT? Looking through the commit logs, I don't see any of these MFC'd to -STABLE yet, so I can't test them directly. The storage box that was having the issues is running 8-STABLE r219754 at the moment (with ZFSv28 and Mikolag's ggate patches). I see there have been a lot of hast/ggate-related MFCs in the past week, but they don't include the deadlock patches. Once the deadlock patches above are MFC'd to -STABLE, I can do an upgrade cycle and test them. I do have the previous 9-CURRENT install saved, just nothing to run it on a= tm. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Mon Apr 4 20:09:37 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 66D2A106566C for ; Mon, 4 Apr 2011 20:09:37 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 6B505150B76 for ; Mon, 4 Apr 2011 20:09:32 +0000 (UTC) Message-ID: <4D9A257C.9070905@FreeBSD.org> Date: Mon, 04 Apr 2011 13:09:32 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110319 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: crash on r220282 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 20:09:37 -0000 Someone suggested I might get better results including the actual panic: panic: Freeing unused sector 4918950 6 c400001f Meanwhile the core.txt.1 file is in my home directory on freefall. Doug #0 sched_switch (td=dwarf2_read_address: Corrupted DWARF expression. ) at /home/svn/head/sys/kern/sched_ule.c:1854 #1 0xffffffff8042b16d in mi_switch (flags=dwarf2_read_address: Corrupted DWARF expression. ) at /home/svn/head/sys/kern/kern_synch.c:450 #2 0xffffffff8045ce3a in sleepq_switch (wchan=dwarf2_read_address: Corrupted DWARF expression. ) at /home/svn/head/sys/kern/subr_sleepqueue.c:538 #3 0xffffffff8045d303 in sleepq_timedwait (wchan=dwarf2_read_address: Corrupted DWARF expression. ) at /home/svn/head/sys/kern/subr_sleepqueue.c:652 #4 0xffffffff8042abe8 in _sleep (ident=Variable "ident" is not available. ) at /home/svn/head/sys/kern/kern_synch.c:230 #5 0xffffffff8065cfa0 in scheduler (dummy=0x0) at /home/svn/head/sys/vm/vm_glue.c:771 #6 0xffffffff803dc2b3 in mi_startup () at /home/svn/head/sys/kern/init_main.c:258 #7 0xffffffff8027164f in btext () #8 0xffffffff80acba60 in bootverbose () #9 0xffffffff80a81a80 in tdq_cpu () #10 0xffffffff80acba60 in bootverbose () #11 0xffffffff80a83800 in sleepq_chains () #12 0xffffffff80caab80 in ?? () #13 0xffffffff80caab28 in ?? () #14 0xfffffe00015d4000 in ?? () #15 0xffffffff80442cd7 in sched_switch (td=dwarf2_read_address: Corrupted DWARF expression. ) at /home/svn/head/sys/kern/sched_ule.c:1848 Previous frame inner to this frame (corrupt stack?) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Apr 4 20:43:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id CB02A1065675; Mon, 4 Apr 2011 20:43:16 +0000 (UTC) Date: Mon, 4 Apr 2011 20:43:16 +0000 From: Alexander Best To: John Baldwin Message-ID: <20110404204316.GA11367@freebsd.org> References: <20110331223339.GA13682@freebsd.org> <201104010843.47367.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201104010843.47367.jhb@freebsd.org> Cc: Alexander Motin , freebsd-current@freebsd.org Subject: Re: multiple issues with devstat_*(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 20:43:16 -0000 On Fri Apr 1 11, John Baldwin wrote: > On Thursday, March 31, 2011 6:33:39 pm Alexander Best wrote: > > hi there, > > > > i think there are multiple issues with devstat. i found the following in > > devicestat.h: > > > > /* > > * These types are intended to aid statistics gathering/display programs. > > * The first 13 types (up to the 'target' flag) are identical numerically > > * to the SCSI device type numbers. The next 3 types designate the device > > * interface. Currently the choices are IDE, SCSI, and 'other'. The last > > * flag specifies whether or not the given device is a passthrough device > > * or not. If it is a passthrough device, the lower 4 bits specify which > > * type of physical device lies under the passthrough device, and the next > > * 4 bits specify the interface. > > */ > > typedef enum { > > DEVSTAT_TYPE_DIRECT = 0x000, > > DEVSTAT_TYPE_SEQUENTIAL = 0x001, > > DEVSTAT_TYPE_PRINTER = 0x002, > > DEVSTAT_TYPE_PROCESSOR = 0x003, > > DEVSTAT_TYPE_WORM = 0x004, > > DEVSTAT_TYPE_CDROM = 0x005, > > DEVSTAT_TYPE_SCANNER = 0x006, > > DEVSTAT_TYPE_OPTICAL = 0x007, > > DEVSTAT_TYPE_CHANGER = 0x008, > > DEVSTAT_TYPE_COMM = 0x009, > > DEVSTAT_TYPE_ASC0 = 0x00a, > > DEVSTAT_TYPE_ASC1 = 0x00b, > > DEVSTAT_TYPE_STORARRAY = 0x00c, > > DEVSTAT_TYPE_ENCLOSURE = 0x00d, > > DEVSTAT_TYPE_FLOPPY = 0x00e, > > DEVSTAT_TYPE_MASK = 0x00f, > > DEVSTAT_TYPE_IF_SCSI = 0x010, > > DEVSTAT_TYPE_IF_IDE = 0x020, > > DEVSTAT_TYPE_IF_OTHER = 0x030, > > DEVSTAT_TYPE_IF_MASK = 0x0f0, > > DEVSTAT_TYPE_PASS = 0x100 > > } devstat_type_flags; > > > > > > also the devstat(9) man page says: > > > > Each device is given a device type. Pass-through devices have the same > > underlying device type and interface as the device they provide an inter- > > face for, but they also have the pass-through flag set. The base device > > types are identical to the SCSI device type numbers, so with SCSI periph- > > erals, the device type returned from an inquiry is usually ORed with the > > SCSI interface type and the pass-through flag if appropriate. The device > > type flags are as follows: > > > > ...so let's get started: > > > > otaku% iostat -n100 > > tty ada0 ada1 md0 cd0 pass0 pass1 pass2 cpu > > tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id > > 1 92 21.18 0 0.01 24.37 12 0.29 0.00 0 0.00 60.27 0 0.01 0.37 0 0.00 0.37 0 0.00 0.00 0 0.00 5 0 4 0 90 > > > > ..so far so good > > > > otaku% iostat -t da > > tty ada0 ada1 md0 cpu > > tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id > > 1 92 21.18 0 0.01 24.37 12 0.29 0.00 0 0.00 5 0 4 0 90 > > > > ...not good! this should include two pass devices! > > This is probably due to the hard drives being IDE (really ATA) rather than > SCSI. I agree this should show the pass devices. hmmmm...one could argue. the drives are ATA, however they are being associated to the CAM subsystem. depends what one considers under "scsi interface". personally i'd like to see them inder "scsi". > > > otaku% iostat -t scsi > > tty cd0 cpu > > tin tout KB/t tps MB/s us ni sy in id > > 1 92 60.27 0 0.01 5 0 4 0 90 > > > > ..what? > > If cd0 is an ATAPI CD-ROM drive, then this shouldn't even show cd0 as all of > your devices are IDE/ATA, not SCSI. > > > otaku% iostat -t ide > > tty cpu > > tin tout us ni sy in id > > 1 92 5 0 4 0 90 > > otaku% iostat -t other > > tty cpu > > tin tout us ni sy in id > > 1 92 5 0 4 0 90 > > > > ...what about md0? ada0? ada1? md0? > > md0 is a memory disk, it is neither SCSI nor IDE. However, -t ide (or even > better, a -t ata), should show all of your other devices (adaX and cd0) along > with their passX devices I think. so md0 should show up under -t other. i don't think there's a -t ata. > > > otaku% iostat -t cd0 > > tty cd0 cpu > > tin tout KB/t tps MB/s us ni sy in id > > 1 92 60.27 0 0.01 5 0 4 0 90 > > > > ...this should also include a pass device > > Agreed. > > > > > otaku% iostat -t pass > > tty pass0 pass1 pass2 cpu > > tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id > > 1 92 0.37 0 0.00 0.37 0 0.00 0.00 0 0.00 5 0 4 0 90 > > > > ...this one's working as expected. > > > > funny thing is i found the following in scsi_pass.c: > > > > softc->device_stats = devstat_new_entry("pass", > > periph->unit_number, 0, > > DEVSTAT_NO_BLOCKSIZE > > | (no_tags ? DEVSTAT_NO_ORDERED_TAGS : 0), > > softc->pd_type | > > DEVSTAT_TYPE_IF_SCSI | > > DEVSTAT_TYPE_PASS, > > DEVSTAT_PRIORITY_PASS); > > > > ...so pass* *should* show up under iostat -t scsi. > > Hmm, pass devices for adaX should not be SCSI though, they should be ide I > think. i think the situation with ATA_CAM should be discussed further. still besides this issue there are many more with devstat(3). i'll try to track all the "devstat_new_entry()" occurrences and see if some issues can be fixed. maybe only the proper DEVSTAT_* args were forgotten. > > -- > John Baldwin -- a13x From owner-freebsd-current@FreeBSD.ORG Mon Apr 4 21:10:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2253C10656AD for ; Mon, 4 Apr 2011 21:10:23 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id AC7148FC17 for ; Mon, 4 Apr 2011 21:10:22 +0000 (UTC) Received: by eyg7 with SMTP id 7so1954061eyg.13 for ; Mon, 04 Apr 2011 14:10:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=Hw5ffds9CpRbyUMzMLY03BTWna0zs8PcNtq7D1PT0RM=; b=XzhC5yfP+9Cf18tIgasyr0DyyTXoGySZLwmpipgCfuEuKPEjygvi0/JQN0EXaDP9H1 AtF7KbY3UvbjgWCScT95T3BdckuRXrlNyxp1kCTBpqRxcLGWe+GF1q5/1uqNUKFdmTIm mUT76mGH5PCUKSOUSWhu8ec9aFGmuKlF0t+Yk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=jn4caVf4rHcze9RnVpiNnNNznemQazcz4pw3+ZWA8m+F+sQf/QsCL524rf1jd4LFUB gkNnzwf9VCilrxb3JXbOz68c8PjAkVFTIFYXqCp/jCHSPE/WnXOWrDUWt0yqgBtHAj/g QXT5CN65kVIqLkjvK7bZnSiY2qh3CPz4PzcjA= MIME-Version: 1.0 Received: by 10.213.105.204 with SMTP id u12mr3826786ebo.130.1301951420277; Mon, 04 Apr 2011 14:10:20 -0700 (PDT) Received: by 10.213.112.212 with HTTP; Mon, 4 Apr 2011 14:10:20 -0700 (PDT) Date: Mon, 4 Apr 2011 17:10:20 -0400 Message-ID: From: Ryan Stone To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Subject: sched_4bsd startup crash trying to run a bound thread on an AP that hasn't started X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 21:10:23 -0000 I'm running into a bootup crash under sched_4bsd on HEAD. The crash happens when I have a thread bound to a single CPU that isn't the BSP, and that thread is scheduled. If the AP that the thread is bound hasn't been started up, kick_other_cpu() crashes because pcpu->pc_curthread is NULL for the AP. I've put a small test kld in http://people.freebsd.org/~rstone/4bsd_bind/ that reproduces the problem. I'm not sure what the best way to address the crash is. ULE is not affected by the problem; it seems to run the swi thread on CPU 0 until CPU 1 is running. Here's a sample backtrace: Fatal trap 12: page fault while in kernel mode^M^M cpuid = 0; apic id = 00^M^M fault virtual address = 0x2fa^M^M fault code = supervisor read data, page not present^M^M instruction pointer = 0x20:0xffffffff803b473b^M^M stack pointer = 0x28:0xffffffff80a2c740^M^M frame pointer = 0x28:0xffffffff80a2c790^M^M code segment = base 0x0, limit 0xfffff, type 0x1b^M^M = DPL 0, pres 1, long 1, def32 0, gran 1^M^M processor eflags = resume, IOPL = 0^M^M current process = 0 (swapper)^M^M trap number = 12^M^M panic: page fault^M^M cpuid = 0^M^M KDB: stack backtrace:^M^M db_trace_self_wrapper() at 0xffffffff801cac8a = db_trace_self_wrapper+0x2a^M^M panic() at 0xffffffff8038ef92 = panic+0x182^M^M trap_fatal() at 0xffffffff8057d32d = trap_fatal+0x2ad^M^M trap() at 0xffffffff8057e01f = trap+0x29f^M^M calltrap() at 0xffffffff80561397 = calltrap+0x8^M^M --- trap 0xc, rip = 0xffffffff803b473b, rsp = 0xffffffff80a2c740, rbp = 0xfffffff f80a2c790 ---^M^M sched_add() at 0xffffffff803b473b = sched_add+0xeb^M^M intr_event_schedule_thread() at 0xffffffff803633e0 = intr_event_schedule_thread+0 xa0^M^M hardclock_device_poll() at 0xffffffff8037f9a5 = hardclock_device_poll+0x35^M^M hardclock() at 0xffffffff80342dd3 = hardclock+0x43^M^M lapic_handle_timer() at 0xffffffff80568033 = lapic_handle_timer+0xf3^M^M Xtimerint() at 0xffffffff80561ecc = Xtimerint+0x8c^M^M From owner-freebsd-current@FreeBSD.ORG Mon Apr 4 21:19:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 753D9106566C; Mon, 4 Apr 2011 21:19:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4AF938FC15; Mon, 4 Apr 2011 21:19:35 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id B6B3346B2C; Mon, 4 Apr 2011 17:19:34 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4F0FB8A01B; Mon, 4 Apr 2011 17:19:34 -0400 (EDT) From: John Baldwin To: Alexander Best Date: Mon, 4 Apr 2011 17:19:33 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <20110331223339.GA13682@freebsd.org> <201104010843.47367.jhb@freebsd.org> <20110404204316.GA11367@freebsd.org> In-Reply-To: <20110404204316.GA11367@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201104041719.33844.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 04 Apr 2011 17:19:34 -0400 (EDT) Cc: Alexander Motin , freebsd-current@freebsd.org Subject: Re: multiple issues with devstat_*(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 21:19:35 -0000 On Monday, April 04, 2011 4:43:16 pm Alexander Best wrote: > On Fri Apr 1 11, John Baldwin wrote: > > This is probably due to the hard drives being IDE (really ATA) rather than > > SCSI. I agree this should show the pass devices. > > hmmmm...one could argue. the drives are ATA, however they are being associated > to the CAM subsystem. depends what one considers under "scsi interface". > personally i'd like to see them inder "scsi". No, SCSI is a transport protocol. Alexandar Motin's work added a new transport layer that speaks ATA and that is what ada uses. CAM does not send SCSI commands to adaX devices AFAIK. > > > otaku% iostat -t ide > > > tty cpu > > > tin tout us ni sy in id > > > 1 92 5 0 4 0 90 > > > otaku% iostat -t other > > > tty cpu > > > tin tout us ni sy in id > > > 1 92 5 0 4 0 90 > > > > > > ...what about md0? ada0? ada1? md0? > > > > md0 is a memory disk, it is neither SCSI nor IDE. However, -t ide (or even > > better, a -t ata), should show all of your other devices (adaX and cd0) along > > with their passX devices I think. > > so md0 should show up under -t other. i don't think there's a -t ata. Yes, I think we should possibly add a -t ata, possibly as an alias for -t ide. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Apr 4 22:27:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EB3E106566B; Mon, 4 Apr 2011 22:27:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id B741A8FC13; Mon, 4 Apr 2011 22:27:35 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p34MRWvB084315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Apr 2011 01:27:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p34MRWo3010564; Tue, 5 Apr 2011 01:27:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p34MRW1B010326; Tue, 5 Apr 2011 01:27:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 5 Apr 2011 01:27:32 +0300 From: Kostik Belousov To: Doug Barton Message-ID: <20110404222732.GZ78089@deviant.kiev.zoral.com.ua> References: <4D9A257C.9070905@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6JKqInvHjCt0b9L3" Content-Disposition: inline In-Reply-To: <4D9A257C.9070905@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_05, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: crash on r220282 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 22:27:36 -0000 --6JKqInvHjCt0b9L3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 04, 2011 at 01:09:32PM -0700, Doug Barton wrote: > Someone suggested I might get better results including the actual panic: >=20 > panic: Freeing unused sector 4918950 6 c400001f >=20 > Meanwhile the core.txt.1 file is in my home directory on freefall. >=20 >=20 > Doug >=20 >=20 > #0 sched_switch (td=3Ddwarf2_read_address: Corrupted DWARF expression. > ) at /home/svn/head/sys/kern/sched_ule.c:1854 > #1 0xffffffff8042b16d in mi_switch (flags=3Ddwarf2_read_address: > Corrupted DWARF expression. > ) at /home/svn/head/sys/kern/kern_synch.c:450 > #2 0xffffffff8045ce3a in sleepq_switch (wchan=3Ddwarf2_read_address: > Corrupted DWARF expression. > ) > at /home/svn/head/sys/kern/subr_sleepqueue.c:538 > #3 0xffffffff8045d303 in sleepq_timedwait (wchan=3Ddwarf2_read_address: > Corrupted DWARF expression. > ) > at /home/svn/head/sys/kern/subr_sleepqueue.c:652 > #4 0xffffffff8042abe8 in _sleep (ident=3DVariable "ident" is not availab= le. > ) at /home/svn/head/sys/kern/kern_synch.c:230 > #5 0xffffffff8065cfa0 in scheduler (dummy=3D0x0) at > /home/svn/head/sys/vm/vm_glue.c:771 > #6 0xffffffff803dc2b3 in mi_startup () at > /home/svn/head/sys/kern/init_main.c:258 > #7 0xffffffff8027164f in btext () > #8 0xffffffff80acba60 in bootverbose () > #9 0xffffffff80a81a80 in tdq_cpu () > #10 0xffffffff80acba60 in bootverbose () > #11 0xffffffff80a83800 in sleepq_chains () > #12 0xffffffff80caab80 in ?? () > #13 0xffffffff80caab28 in ?? () > #14 0xfffffe00015d4000 in ?? () > #15 0xffffffff80442cd7 in sched_switch (td=3Ddwarf2_read_address: > Corrupted DWARF expression. > ) at /home/svn/head/sys/kern/sched_ule.c:1848 > Previous frame inner to this frame (corrupt stack?) The backtrace is for the wrong thread. There should be the thread that panicked, and it is the thread backtrace that is interesting. --6JKqInvHjCt0b9L3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2aRdQACgkQC3+MBN1Mb4gMrwCgwtte0xhq8/gN7xUYWAK0kVF7 z8EAoLEV4Ejzxd7qPVjPTnadZz/z/6IS =o3Rw -----END PGP SIGNATURE----- --6JKqInvHjCt0b9L3-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 4 23:31:55 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 619BE106566B for ; Mon, 4 Apr 2011 23:31:55 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 37CFA8FC0C for ; Mon, 4 Apr 2011 23:31:54 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p34MvBEf054307 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 4 Apr 2011 15:57:12 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4D9A4CE5.5090900@freebsd.org> Date: Mon, 04 Apr 2011 15:57:41 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: KGDB stack traces in the kernel. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 23:31:55 -0000 currently in kernel stack traces I see: [Switching to Thread 100246] 0xffffffff814617f3 in fio_local_to_global_packet () from xxxxxxxxx/mumble.ko (kgdb) bt #0 0xffffffff814617f3 in yyyy () from xxxxxxxxx/mumble.ko #1 0xffffffff8146171f in zzzz () from xxxxxxxxx/mumble.ko [...] #14 0xffffffff805c4b8e in fork_exit (callout=0xffffffff814dfe30 , arg=0x7d8b48000421dbe8, frame=0x814fc340c6c74800) at ../../../kern/kern_fork.c:859 #15 0xf045c748e87d8948 in ?? () #16 0xb5058b4800000000 in ?? () #17 0x000130054800074e in ?? () #18 0x950fc0850c408b00 in ?? () and then the stack trace goes on forever with garbage. #19 0x74c08548c0b60fc0 in ?? () #20 0x814fdb70c6c74816 in ?? () #21 0x0000b800000007bf in ?? () #22 0x48000425b9e80000 in ?? () #23 0x1210c78148e87d8b in ?? () #24 0x4800000bd1ba0000 in ?? () #25 0x3de8814fc340c6c7 in ?? () #26 0x558b4828eb000421 in ?? () #27 0xc68148e8758b48f0 in ?? () #28 0xe87d8b4800001210 in ?? () #29 0xe800001178c78148 in ?? () #30 0x83fc458900041bdc in ?? () #31 0x7d8b480d7400fc7d in ?? () #32 0xc085fffffdfae8e8 in ?? () #33 0x8148e87d8b48cb74 in ?? () #34 0x0bdcba00001210c7 in ?? () #35 0x4fc340c6c7480000 in ?? () #36 0x8b48000420aae881 in ?? () #37 0x000007600548e845 in ?? () #38 0x00000019bfc68948 in ?? () etc is there anyone here with enough gdb/kgdb source experience to know what we would need to put on the stack at fork_exit() to make it stop when it gets there? not only is it annoying but it slows down debugging because kgdb and the ddd front end ask for stacks a LOT. sometimes it actually just hangs as the stack goes into a loop and never ends. I had a quick look but didn't spot how gdb decides it has reached the end of a stack. Julian From owner-freebsd-current@FreeBSD.ORG Mon Apr 4 23:35:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B27791065675; Mon, 4 Apr 2011 23:35:16 +0000 (UTC) (envelope-from david.somayajulu@qlogic.com) Received: from TX2EHSOBE002.bigfish.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by mx1.freebsd.org (Postfix) with ESMTP id 688DB8FC0C; Mon, 4 Apr 2011 23:35:16 +0000 (UTC) Received: from mail54-tx2-R.bigfish.com (10.9.14.239) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.8; Mon, 4 Apr 2011 23:35:15 +0000 Received: from mail54-tx2 (localhost.localdomain [127.0.0.1]) by mail54-tx2-R.bigfish.com (Postfix) with ESMTP id 81A02303DC; Mon, 4 Apr 2011 23:35:15 +0000 (UTC) X-SpamScore: -6 X-BigFish: VPS-6(zz14ffOzz1202hzz8275bh8275dhz2ei2a8h668h839h62h) X-Spam-TCS-SCL: 1:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:avexcashub1.qlogic.com; RD:avexcashub2.qlogic.com; EFVD:NLI Received: from mail54-tx2 (localhost.localdomain [127.0.0.1]) by mail54-tx2 (MessageSwitch) id 1301960114976274_22377; Mon, 4 Apr 2011 23:35:14 +0000 (UTC) Received: from TX2EHSMHS024.bigfish.com (unknown [10.9.14.249]) by mail54-tx2.bigfish.com (Postfix) with ESMTP id E8B81B60051; Mon, 4 Apr 2011 23:35:14 +0000 (UTC) Received: from avexcashub1.qlogic.com (198.70.193.64) by TX2EHSMHS024.bigfish.com (10.9.99.124) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 4 Apr 2011 23:35:14 +0000 Received: from avexmb1.qlogic.org ([fe80::9545:3a4f:c131:467d]) by avexcashub2.qlogic.org ([::1]) with mapi; Mon, 4 Apr 2011 16:35:13 -0700 From: David Somayajulu To: "freebsd-current@freebsd.org" , "freebsd-net@freebsd.org" Date: Mon, 4 Apr 2011 16:35:11 -0700 Thread-Topic: Setting up a running FreeBSD/PCBSD system to enter kgdb on panic Thread-Index: AcvzIPERZdTiJhRiS06wlYIpbVgJvA== Message-ID: <75E1A2A7D185F841A975979B0906BBA6774E1B99D3@AVEXMB1.qlogic.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginatorOrg: qlogic.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Setting up a running FreeBSD/PCBSD system to enter kgdb on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 23:35:16 -0000 Hi All, Is there some way I can setup a running FreeBSD - (I use PCBSD7.2) - to bre= ak into kgdb when the system panics. I am trying to get a stack trace when = "Fatal trap 12: page fault while in kernel mode" happens. thanks david S. ________________________________ This message and any attached documents contain information from QLogic Cor= poration or its wholly-owned subsidiaries that may be confidential. If you = are not the intended recipient, you may not read, copy, distribute, or use = this information. If you have received this transmission in error, please n= otify the sender immediately by reply e-mail and then delete this message. From owner-freebsd-current@FreeBSD.ORG Tue Apr 5 00:07:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0F8E106566C for ; Tue, 5 Apr 2011 00:07:44 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 61D478FC15 for ; Tue, 5 Apr 2011 00:07:44 +0000 (UTC) Received: by wyf23 with SMTP id 23so6018643wyf.13 for ; Mon, 04 Apr 2011 17:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Mwrow5DPN/HbWSF7v58Y8NczqcXUpfKrsCPAOd6uTqs=; b=nN80zovrEur/MxolSdesALFIINWU3dtcWhzGR8+9ghjcPJsnFEQ5QMBVfq5hBP48yb wxZ+pHXWxt20AxolzwgrnfoUdQ2bOv7bQ0vzNHJ2URmOD94NwFzi41K/r6v0qJcC0JNX eeY1AuqgLW538tqs0Ws+5o+HFwRZny/V7WvW8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=qjjX++9SpuX+HRY5wfJken/2fhBMRXIbX0tuSM2MCmrWP+QJLDv8DMftFjBOi5FLIY uOS1x7o/bhfjBh1gM2lC/j6I4ZKvv2Si15+x+fcYkUI6GNGqMzQI2Zvq4c7O70YOeEry 3Z7ENDL5nuRyd/IQXfWWRBs65cYrd6aXQwyrA= Received: by 10.227.206.78 with SMTP id ft14mr98378wbb.136.1301962063221; Mon, 04 Apr 2011 17:07:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.72.200 with HTTP; Mon, 4 Apr 2011 17:07:13 -0700 (PDT) In-Reply-To: <75E1A2A7D185F841A975979B0906BBA6774E1B99D3@AVEXMB1.qlogic.org> References: <75E1A2A7D185F841A975979B0906BBA6774E1B99D3@AVEXMB1.qlogic.org> From: Eitan Adler Date: Mon, 4 Apr 2011 20:07:13 -0400 Message-ID: To: David Somayajulu Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" , "freebsd-current@freebsd.org" Subject: Re: Setting up a running FreeBSD/PCBSD system to enter kgdb on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 00:07:45 -0000 On Mon, Apr 4, 2011 at 7:35 PM, David Somayajulu wrote: > Hi All, > Is there some way I can setup a running FreeBSD - (I use PCBSD7.2) - to break into kgdb when the system panics. I am trying to get a stack trace when "Fatal trap 12: page fault while in kernel mode" happens. debug.debugger_on_panic=1 -- Eitan Adler From owner-freebsd-current@FreeBSD.ORG Tue Apr 5 00:25:48 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D963106566B; Tue, 5 Apr 2011 00:25:48 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 3F4998FC25; Tue, 5 Apr 2011 00:25:47 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p350PiMj054565 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 4 Apr 2011 17:25:46 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4D9A61A7.6080906@freebsd.org> Date: Mon, 04 Apr 2011 17:26:15 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: David Somayajulu References: <75E1A2A7D185F841A975979B0906BBA6774E1B99D3@AVEXMB1.qlogic.org> In-Reply-To: <75E1A2A7D185F841A975979B0906BBA6774E1B99D3@AVEXMB1.qlogic.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , "freebsd-current@freebsd.org" Subject: Re: Setting up a running FreeBSD/PCBSD system to enter kgdb on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 00:25:48 -0000 On 4/4/11 4:35 PM, David Somayajulu wrote: > Hi All, > Is there some way I can setup a running FreeBSD - (I use PCBSD7.2) - to break into kgdb when the system panics. I am trying to get a stack trace when "Fatal trap 12: page fault while in kernel mode" happens. > thanks > david S. sure but firstly have you already got everything set up so you can get into kgdb normally? (serial cable? (or firewire?) ports all set up right? second machine? here are som bits of the puzzle for my machine: from /boot/device.hints: hint.uart.1.at="isa" hint.uart.1.port="0x2F8" hint.uart.1.flags="0x80" hint.uart.1.irq="3" hint.uart.1.baud="115200" in /etc/sysctl.conf: debug.kdb.current=gdb but usually I find it better to go to ddb first and do a ps and backtrace as ps is a pain on gdb and needs macros etc. and of course kgdb needs to be set up correctly the handbook says a lot about that. > ________________________________ > This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Tue Apr 5 01:16:11 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47E8E106564A; Tue, 5 Apr 2011 01:16:11 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0F4DC8FC0A; Tue, 5 Apr 2011 01:16:10 +0000 (UTC) Received: by pvg11 with SMTP id 11so2160146pvg.13 for ; Mon, 04 Apr 2011 18:16:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RK7i9EYGaXBr+Ka0DnF0BCX8DjqpkmbTr4/n0QZNLYM=; b=HiI6g9rl8WuyR7F/7Lu5QEyzUjq+rRYi/Jmg5nOrVZwoyB0CTsePxZiIDkqbbcvED7 WdXg5vU3YN7zhf/Oa+GgJU+fsnCx8sgSUJxii/yMqYagiCe0s63JNiXviSY8SIc1YSaY J2koKnczE5Dzul2WiWM0zz5esf/GvOS9QqkWc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HaQNtUKGQGpyXh9mOpinQoIyv+23sWsJAAIIFNbQGJNOs4b7xIB/F8buXGrddKzrdL Uwlas5SWaSSOb/nw4VgzenU1OA3fmtB73NiKqSjQKVwDb+1QHX1yv9zEkXNynbvIeK3q aG7P4hIwq1++RO/uy+mX0kU82uVjhwahqdHVc= MIME-Version: 1.0 Received: by 10.143.47.6 with SMTP id z6mr1843843wfj.227.1301966169922; Mon, 04 Apr 2011 18:16:09 -0700 (PDT) Received: by 10.68.42.3 with HTTP; Mon, 4 Apr 2011 18:16:09 -0700 (PDT) In-Reply-To: <4D9A61A7.6080906@freebsd.org> References: <75E1A2A7D185F841A975979B0906BBA6774E1B99D3@AVEXMB1.qlogic.org> <4D9A61A7.6080906@freebsd.org> Date: Mon, 4 Apr 2011 18:16:09 -0700 Message-ID: From: Garrett Cooper To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" , "freebsd-current@freebsd.org" , David Somayajulu Subject: Re: Setting up a running FreeBSD/PCBSD system to enter kgdb on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 01:16:11 -0000 On Mon, Apr 4, 2011 at 5:26 PM, Julian Elischer wrote: > On 4/4/11 4:35 PM, David Somayajulu wrote: >> >> Hi All, >> Is there some way I can setup a running FreeBSD - (I use PCBSD7.2) - to >> break into kgdb when the system panics. I am trying to get a stack trace >> when "Fatal trap 12: page fault while in kernel mode" happens. >> thanks >> david S. > > sure but firstly have you already got everything set up so you can get into > kgdb normally? > (serial cable? (or firewire?) ports all set up right? second machine? > > here are som bits of the puzzle for my machine: > > from /boot/device.hints: > > hint.uart.1.at="isa" > hint.uart.1.port="0x2F8" > hint.uart.1.flags="0x80" > hint.uart.1.irq="3" > hint.uart.1.baud="115200" .flags on uart(4) doesn't support 0x20, 0x40, like on sio(4). Interesting. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Apr 5 01:33:29 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 657E01065670; Tue, 5 Apr 2011 01:33:29 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1BF7D8FC0C; Tue, 5 Apr 2011 01:33:28 +0000 (UTC) Received: by iyj12 with SMTP id 12so8120807iyj.13 for ; Mon, 04 Apr 2011 18:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; bh=6O40rcRSin/xe33TZHXy9yPNx3cWyPJhSgT/Y8SDtoE=; b=L4/HxVyY151KQMwQ00uJgufU7TUE9x7e4fU+ZmtuDnuwPcMvQNNM4Wf/Jd0hk4yvj9 JH24dCDMXXPPFT8eL09eGAQCHh8O6iYqHw2DI/qkwSu/ABqAINI4MIIbmo+zdLszJoap a+K6y/o/oU7X7hKU7eKxl3owfpjVoKxJAga/o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=K9V3JL4mRcDsSPDR5AQpjM8ye9PIwiR+fVQRaowebiADKi/HVTqAVxJqGtlh+NE8UG ul/D3vJ9YHXGPHl7UVBz6SvE/SZjjL7VIObJclX50oAOSCEqL2Hn/lY2s/zeZmXQ6HCv ZuVQnXJLqxB1eT8th+GpejvGKiR4SAnawnmdk= Received: by 10.42.163.68 with SMTP id b4mr2667536icy.120.1301965466107; Mon, 04 Apr 2011 18:04:26 -0700 (PDT) Received: from triad.knownspace (216-15-41-8.c3-0.gth-ubr1.lnh-gth.md.cable.rcn.com [216.15.41.8]) by mx.google.com with ESMTPS id c4sm3801336ict.7.2011.04.04.18.04.24 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Apr 2011 18:04:25 -0700 (PDT) Message-Id: From: Justin Hibbits To: Julian Elischer In-Reply-To: <4D9A4CE5.5090900@freebsd.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 4 Apr 2011 21:04:23 -0400 References: <4D9A4CE5.5090900@freebsd.org> X-Mailer: Apple Mail (2.936) Cc: FreeBSD Current Subject: Re: KGDB stack traces in the kernel. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 01:33:29 -0000 On Apr 4, 2011, at 6:57 PM, Julian Elischer wrote: > is there anyone here with enough gdb/kgdb source experience to know > what > we would need to put on the stack at fork_exit() to make it stop > when it > gets there? > > not only is it annoying but it slows down debugging because kgdb and > the ddd > front end ask for stacks a LOT. sometimes it actually just hangs as > the stack > goes into a loop and never ends. > > I had a quick look but didn't spot how gdb decides it has reached > the end of a stack. > > Julian From my experience, it checks for a NULL stack chain pointer. Once that reaches NULL, it's the end of the stack. - Justin From owner-freebsd-current@FreeBSD.ORG Tue Apr 5 11:06:27 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6CCC106566C; Tue, 5 Apr 2011 11:06:27 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8196B8FC16; Tue, 5 Apr 2011 11:06:25 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA01951; Tue, 05 Apr 2011 14:06:24 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Q745X-0005ul-MF; Tue, 05 Apr 2011 14:06:23 +0300 Message-ID: <4D9AF7AE.9090004@FreeBSD.org> Date: Tue, 05 Apr 2011 14:06:22 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110308 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-usb@FreeBSD.org, FreeBSD-Current References: <4D985007.4080308@freebsd.org> In-Reply-To: <4D985007.4080308@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit Cc: Hans Petter Selasky Subject: Re: use_generic and usb probing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 11:06:27 -0000 on 03/04/2011 13:46 Andriy Gapon said the following: > > Mostly out of curiosity (but not only because of that) I wonder why the > use_generic flag and two probing passes are needed in USB driver probing code. > That is, why the standard approach of using different probing return values > (e.g. BUS_PROBE_DEFAULT, BUS_PROBE_GENERIC, etc) wouldn't work here. I couldn't find any historic reason for this, so I am assuming that this is a kludge to work-around inconsistent return values in various USB "newbus" probe routines. Please see here my attempt at cleaning up the basics: http://people.freebsd.org/~avg/usb-use_generic.diff Reviews and testing are welcome. P.S. A side-effect of this patch is removal of a minor annoyance in a form of the following message: Unknown USB device: vendor <> product <> bus <> The message is produced by devd almost any time anything is connected via USB thanks to (1) a nomatch USB entry in the default devd.conf; (2) use_generic=0 probing pass in USB. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Apr 5 11:32:57 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0504E1065670; Tue, 5 Apr 2011 11:32:57 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe08.c2i.net [212.247.154.226]) by mx1.freebsd.org (Postfix) with ESMTP id 244C78FC0C; Tue, 5 Apr 2011 11:32:55 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=6QwXiDozn7Gnsf2tGidwH+ndAwLlGixx7JAIKZICKmI= c=1 sm=1 a=IU0TiZmyZPMA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=6I5d2MoRAAAA:8 a=Vf0mB7oONcDt1KCSLr0A:9 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 109799094; Tue, 05 Apr 2011 13:22:52 +0200 Received-SPF: softfail receiver=mailfe08.swip.net; client-ip=188.126.198.129; envelope-from=hselasky@freebsd.org From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Tue, 5 Apr 2011 13:21:56 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-PRERELEASE; KDE/4.4.5; amd64; ; ) References: <4D985007.4080308@freebsd.org> <4D9AF7AE.9090004@FreeBSD.org> In-Reply-To: <4D9AF7AE.9090004@FreeBSD.org> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201104051321.56319.hselasky@freebsd.org> Cc: freebsd-usb@freebsd.org, Andriy Gapon Subject: Re: use_generic and usb probing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 11:32:57 -0000 On Tuesday 05 April 2011 13:06:22 Andriy Gapon wrote: > on 03/04/2011 13:46 Andriy Gapon said the following: > > Mostly out of curiosity (but not only because of that) I wonder why the > > use_generic flag and two probing passes are needed in USB driver probing > > code. That is, why the standard approach of using different probing > > return values (e.g. BUS_PROBE_DEFAULT, BUS_PROBE_GENERIC, etc) wouldn't > > work here. > > I couldn't find any historic reason for this, so I am assuming that this is > a kludge to work-around inconsistent return values in various USB "newbus" > probe routines. > > Please see here my attempt at cleaning up the basics: > http://people.freebsd.org/~avg/usb-use_generic.diff > > Reviews and testing are welcome. > > P.S. > A side-effect of this patch is removal of a minor annoyance in a form of > the following message: > Unknown USB device: vendor <> product <> bus <> > The message is produced by devd almost any time anything is connected via > USB thanks to (1) a nomatch USB entry in the default devd.conf; (2) > use_generic=0 probing pass in USB. Hi, In the initial USB stack design drivers are supposed to either report match or non-match. The reason for this is that sometimes parameters are passed on from the probe to the attach via the USB attach args. See usbd_lookup_id_by_uaa(). When multiple drivers are probed and match, the information presented by the usb_attach_arg's can get messed up with regard to the attaching driver. It would be better if the newbus could support a probing priority argument! --HPS From owner-freebsd-current@FreeBSD.ORG Tue Apr 5 12:05:09 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED327106566B; Tue, 5 Apr 2011 12:05:09 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id AF8C48FC18; Tue, 5 Apr 2011 12:05:08 +0000 (UTC) Received: by wwc33 with SMTP id 33so328233wwc.31 for ; Tue, 05 Apr 2011 05:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:subject:organization:references :sender:date:in-reply-to:message-id:user-agent:mime-version :content-type; bh=Ug//cj8gOU7r+ZBzLxHLlM/jpS1tdTg1rmEJuXBLH0M=; b=XPhIxNPoY/e/Iq3fgHivi0QtEEVRUFHNKDsy9D+DEwCQ4iQT1HCP5WqPm5LWxGuZAS 03dhLm8tPz8YaLglOZB1MKZVcpRkYA2jD4adHRDy+OzW19QLeIGz/87uNvUZZjXMhIlc I0yjKPHr5H2GHpAcT7iLC7xTu0ygeyfVRmduU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:organization:references:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=KY4YPv8Gxr+RfycpX+td8nlSA+uaqmZAZVslWW2/PfuCh+3CTuGUxXQoQlKMBhJ0Fr ekQd/zRk4be8E1Z6zaZQsbrx/1d0BWHWV9ZzehM7DS7xkYuKWcpGZgTOTIeeJKJ7r54c fKSO9hT/WYAidtfh9sFN3e1t4Rq/6Is1bRdFo= Received: by 10.227.151.15 with SMTP id a15mr8258351wbw.184.1302005107660; Tue, 05 Apr 2011 05:05:07 -0700 (PDT) Received: from localhost ([94.27.39.186]) by mx.google.com with ESMTPS id y29sm3514096wbd.55.2011.04.05.05.05.04 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2011 05:05:05 -0700 (PDT) From: Mikolaj Golub To: Freddie Cash Organization: TOA Ukraine References: <20110402084431.GB1849@garage.freebsd.pl> Sender: Mikolaj Golub Date: Tue, 05 Apr 2011 15:05:02 +0300 In-Reply-To: (Freddie Cash's message of "Mon, 4 Apr 2011 11:08:16 -0700") Message-ID: <86tyecnbtd.fsf@in138.ua3> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: FreeBSD Filesystems , FreeBSD Stable , FreeBSD-Current , Pawel Jakub Dawidek Subject: Re: Any success stories for HAST + ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 12:05:10 -0000 On Mon, 4 Apr 2011 11:08:16 -0700 Freddie Cash wrote: FC> On Sat, Apr 2, 2011 at 1:44 AM, Pawel Jakub Dawidek wrote: >> >> I just committed a fix for a problem that might look like a deadlock. >> With trociny@ patch and my last fix (to GEOM GATE and hastd) do you >> still have any issues? FC> Just to confirm, this is commit r220264, 220265, 220266 to -CURRENT? Yes, r220264 and 220266. As it is stated in the commit log MFC is planned after 1 week. -- Mikolaj Golub From owner-freebsd-current@FreeBSD.ORG Tue Apr 5 12:50:46 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B870310656AC; Tue, 5 Apr 2011 12:50:46 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9315A8FC1F; Tue, 5 Apr 2011 12:50:45 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA03738; Tue, 05 Apr 2011 15:50:43 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4D9B1023.7020407@FreeBSD.org> Date: Tue, 05 Apr 2011 15:50:43 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110309 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Hans Petter Selasky References: <4D985007.4080308@freebsd.org> <4D9AF7AE.9090004@FreeBSD.org> <201104051321.56319.hselasky@freebsd.org> In-Reply-To: <201104051321.56319.hselasky@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-usb@FreeBSD.org Subject: Re: use_generic and usb probing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 12:50:46 -0000 on 05/04/2011 14:21 Hans Petter Selasky said the following: > On Tuesday 05 April 2011 13:06:22 Andriy Gapon wrote: >> on 03/04/2011 13:46 Andriy Gapon said the following: >>> Mostly out of curiosity (but not only because of that) I wonder why the >>> use_generic flag and two probing passes are needed in USB driver probing >>> code. That is, why the standard approach of using different probing >>> return values (e.g. BUS_PROBE_DEFAULT, BUS_PROBE_GENERIC, etc) wouldn't >>> work here. >> >> I couldn't find any historic reason for this, so I am assuming that this is >> a kludge to work-around inconsistent return values in various USB "newbus" >> probe routines. >> >> Please see here my attempt at cleaning up the basics: >> http://people.freebsd.org/~avg/usb-use_generic.diff >> >> Reviews and testing are welcome. >> >> P.S. >> A side-effect of this patch is removal of a minor annoyance in a form of >> the following message: >> Unknown USB device: vendor <> product <> bus <> >> The message is produced by devd almost any time anything is connected via >> USB thanks to (1) a nomatch USB entry in the default devd.conf; (2) >> use_generic=0 probing pass in USB. > > Hi, > > In the initial USB stack design drivers are supposed to either report match or > non-match. The reason for this is that sometimes parameters are passed on from > the probe to the attach via the USB attach args. > > See usbd_lookup_id_by_uaa(). > > When multiple drivers are probed and match, the information presented by the > usb_attach_arg's can get messed up with regard to the attaching driver. > > It would be better if the newbus could support a probing priority argument! I believe that newbus already supports ordering of children on a bus. BTW, does USB have to pass anything from probe to attach? Duplicate lookup is of course not very nice, but duplicate probing pass is not nice either. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Apr 5 12:56:30 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88B0F106564A; Tue, 5 Apr 2011 12:56:30 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe04.c2i.net [212.247.154.98]) by mx1.freebsd.org (Postfix) with ESMTP id BA1D18FC13; Tue, 5 Apr 2011 12:56:29 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=wd7fLirDSts22yawIUsTeMUS9lsm8Llc0grT6RvpTjU= c=1 sm=1 a=IU0TiZmyZPMA:10 a=N659UExz7-8A:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=OCqLyubZUFnFn5f_-YQA:9 a=pILNOxqGKmIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 109559106; Tue, 05 Apr 2011 14:56:28 +0200 Received-SPF: softfail receiver=mailfe04.swip.net; client-ip=188.126.198.129; envelope-from=hselasky@freebsd.org From: Hans Petter Selasky To: Andriy Gapon Date: Tue, 5 Apr 2011 14:55:33 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-PRERELEASE; KDE/4.4.5; amd64; ; ) References: <201104051321.56319.hselasky@freebsd.org> <4D9B1023.7020407@FreeBSD.org> In-Reply-To: <4D9B1023.7020407@FreeBSD.org> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Message-Id: <201104051455.33853.hselasky@freebsd.org> Cc: "freebsd-current@FreeBSD.org" , "freebsd-usb@FreeBSD.org" Subject: Re: use_generic and usb probing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 12:56:30 -0000 On Tuesday 05 April 2011 14:50:43 Andriy Gapon wrote: > > I believe that newbus already supports ordering of children on a bus. > > BTW, does USB have to pass anything from probe to attach? Mostly only the driver info field. To avoid duplicate lookups. > Duplicate lookup is of course not very nice, but duplicate probing pass is > not nice either. This can all be avoided if the bus-drivers are sorted correctly before probing! --HPS From owner-freebsd-current@FreeBSD.ORG Tue Apr 5 16:45:54 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3837C106566B; Tue, 5 Apr 2011 16:45:54 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1A34E8FC13; Tue, 5 Apr 2011 16:45:52 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA07789; Tue, 05 Apr 2011 19:45:51 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4D9B473F.8020607@FreeBSD.org> Date: Tue, 05 Apr 2011 19:45:51 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110309 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Hans Petter Selasky References: <201104051321.56319.hselasky@freebsd.org> <4D9B1023.7020407@FreeBSD.org> <201104051455.33853.hselasky@freebsd.org> In-Reply-To: <201104051455.33853.hselasky@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "freebsd-current@FreeBSD.org" , "freebsd-usb@FreeBSD.org" Subject: Re: use_generic and usb probing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 16:45:54 -0000 on 05/04/2011 15:55 Hans Petter Selasky said the following: > On Tuesday 05 April 2011 14:50:43 Andriy Gapon wrote: >> >> I believe that newbus already supports ordering of children on a bus. >> >> BTW, does USB have to pass anything from probe to attach? > > Mostly only the driver info field. To avoid duplicate lookups. > >> Duplicate lookup is of course not very nice, but duplicate probing pass is >> not nice either. > > This can all be avoided if the bus-drivers are sorted correctly before > probing! Well, I think that that's what probe priorities actually for. I also think that typically ivars should be set by a bus driver. So maybe it's not such a good idea to pass data from probe to attach via ivars in child drivers. But I could be mistaken about that. Practically speaking, you most likely don't have to worry about that for drivers that return BUS_PROBE_SPECIFIC (=0) from their probe methods. And there is only a few "generic" drivers that can be handled on a case by case basis. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Apr 5 19:13:58 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A152106566C; Tue, 5 Apr 2011 19:13:58 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id E9A408FC13; Tue, 5 Apr 2011 19:13:57 +0000 (UTC) Received: by gxk28 with SMTP id 28so328952gxk.13 for ; Tue, 05 Apr 2011 12:13:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KIJYwFEg5+6yEFkgBTlCy2o3RQ7tedqCIu25RT91Ts4=; b=FhKGmJE3BStG8udaH8AjCrMz6L6SS90Z01rxhBcxPhAqtx/PIi4sg/2xgBg8pIOtNE aGz2VYDaArs3nAJuQsNBXl+Dkhb0cndcrz4k09xNGdhkYniWGt3chamSL/XcMyDpziV8 jBL+0pQuQ+RGgBcU1ZWugO294RKRY2ECxM7nI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FNHXK39QXdonQEYEjpav511iqHCMvflOtsGWe1GujXFiykJBmqsXwCtF6JmFHEg5vR qmW4AaEsfy/lo1KTvlIgRP8SeB5uwG04Y3SaNrMcb68FMmfPZAwVteDsEnJ0qdvOcH1/ NQYa3dl01HUFypjPM2IQ2+pkVmE/Ep/L3TXDo= MIME-Version: 1.0 Received: by 10.90.14.39 with SMTP id 39mr928443agn.127.1302030837143; Tue, 05 Apr 2011 12:13:57 -0700 (PDT) Received: by 10.90.51.14 with HTTP; Tue, 5 Apr 2011 12:13:57 -0700 (PDT) In-Reply-To: <86tyecnbtd.fsf@in138.ua3> References: <20110402084431.GB1849@garage.freebsd.pl> <86tyecnbtd.fsf@in138.ua3> Date: Tue, 5 Apr 2011 12:13:57 -0700 Message-ID: From: Freddie Cash To: Mikolaj Golub Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Filesystems , FreeBSD Stable , FreeBSD-Current , Pawel Jakub Dawidek Subject: Re: Any success stories for HAST + ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 19:13:58 -0000 On Tue, Apr 5, 2011 at 5:05 AM, Mikolaj Golub wrote: > On Mon, 4 Apr 2011 11:08:16 -0700 Freddie Cash wrote: > > =C2=A0FC> On Sat, Apr 2, 2011 at 1:44 AM, Pawel Jakub Dawidek wrote: > =C2=A0>> > =C2=A0>> I just committed a fix for a problem that might look like a dead= lock. > =C2=A0>> With trociny@ patch and my last fix (to GEOM GATE and hastd) do = you > =C2=A0>> still have any issues? > > =C2=A0FC> Just to confirm, this is commit r220264, 220265, 220266 to -CUR= RENT? > > Yes, r220264 and 220266. As it is stated in the commit log MFC is planned > after 1 week. Okay. I'll keep an eye out next week for the MFC of those patches to hit -STABLE, and do an upgrade/test cycle after that point. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Tue Apr 5 20:32:53 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58398106564A for ; Tue, 5 Apr 2011 20:32:53 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 2DA388FC12 for ; Tue, 5 Apr 2011 20:32:53 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p35KWpNr059245 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 5 Apr 2011 13:32:52 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4D9B7C92.6030901@freebsd.org> Date: Tue, 05 Apr 2011 13:33:22 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Justin Hibbits References: <4D9A4CE5.5090900@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: KGDB stack traces in the kernel. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 20:32:53 -0000 On 4/4/11 6:04 PM, Justin Hibbits wrote: > On Apr 4, 2011, at 6:57 PM, Julian Elischer wrote: >> is there anyone here with enough gdb/kgdb source experience to know >> what >> we would need to put on the stack at fork_exit() to make it stop >> when it >> gets there? >> >> not only is it annoying but it slows down debugging because kgdb >> and the ddd >> front end ask for stacks a LOT. sometimes it actually just hangs as >> the stack >> goes into a loop and never ends. >> >> I had a quick look but didn't spot how gdb decides it has reached >> the end of a stack. >> >> Julian > > From my experience, it checks for a NULL stack chain pointer. Once > that reaches NULL, it's the end of the stack. > > - Justin > I'll try adding NULL when we build the intial stack up. :-) From owner-freebsd-current@FreeBSD.ORG Tue Apr 5 21:02:49 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC1971065672; Tue, 5 Apr 2011 21:02:49 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8CB8A8FC0A; Tue, 5 Apr 2011 21:02:49 +0000 (UTC) Received: by qwc9 with SMTP id 9so542755qwc.13 for ; Tue, 05 Apr 2011 14:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=n8lXpQ1I2qL8ILuO6lm4XOH+u5Dkl4goDJ/ZMbEV7s0=; b=f0SBqXPQ8ETO4Qmp28Xt1OJcywIzle+d22QvmcSl9MuMO1srQQ+TXwQxPj7Q60hF9+ K7YUMCe2QCiIx47Cvs50ac0b/NTUE0hGKc7HAguM7WKcmh9r6iuDZaSa+4wKnkACPo6V 0vlPqAbo3VG0Wsw60YZomRCjzB0EkhfOut358= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=j4uOs1Y79kPtWhQZ6ijRb38CkemRmpnGwbYtUKgb2N18SrbBdKV5e3Es8S80KyL7Ci VmfTXpOkMwlzcbNaVmucrTapGMnjxl7N5abvwaP+BirgsIaGAp5JJ4eJnvcIwADp+w9E UKnKoEil4X5ne/edQXyVtIjtzgwCy3js5j12o= MIME-Version: 1.0 Received: by 10.229.136.1 with SMTP id p1mr107581qct.218.1302035744644; Tue, 05 Apr 2011 13:35:44 -0700 (PDT) Received: by 10.229.40.138 with HTTP; Tue, 5 Apr 2011 13:35:44 -0700 (PDT) In-Reply-To: <4D9B7C92.6030901@freebsd.org> References: <4D9A4CE5.5090900@freebsd.org> <4D9B7C92.6030901@freebsd.org> Date: Tue, 5 Apr 2011 13:35:44 -0700 Message-ID: From: Navdeep Parhar To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Justin Hibbits , FreeBSD Current Subject: Re: KGDB stack traces in the kernel. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 21:02:50 -0000 On Tue, Apr 5, 2011 at 1:33 PM, Julian Elischer wrote: > On 4/4/11 6:04 PM, Justin Hibbits wrote: >> >> On Apr 4, 2011, at 6:57 PM, Julian Elischer wrote: >>> >>> is there anyone here with enough gdb/kgdb source experience to know wha= t >>> we would need to put on the stack at fork_exit() to make it stop when i= t >>> gets there? >>> >>> not only is it annoying but it slows down debugging because kgdb and th= e >>> ddd >>> front end ask for stacks a LOT. sometimes it actually just hangs as the >>> stack >>> goes into a loop and never ends. >>> >>> I had a quick look but didn't spot how gdb decides it has reached the e= nd >>> of a stack. >>> >>> Julian >> >> From my experience, it checks for a NULL stack chain pointer. =A0Once th= at >> reaches NULL, it's the end of the stack. >> >> - Justin >> > I'll try adding NULL when we build the intial stack up. > :-) What does ddb do? It always seems to get this stuff correct. Navdeep From owner-freebsd-current@FreeBSD.ORG Tue Apr 5 22:48:33 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A59E91065672 for ; Tue, 5 Apr 2011 22:48:33 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 77A7E8FC08 for ; Tue, 5 Apr 2011 22:48:33 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p35MmUwD059669 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 5 Apr 2011 15:48:32 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4D9B9C5D.4000909@freebsd.org> Date: Tue, 05 Apr 2011 15:49:01 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Navdeep Parhar References: <4D9A4CE5.5090900@freebsd.org> <4D9B7C92.6030901@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Justin Hibbits , FreeBSD Current Subject: Re: KGDB stack traces in the kernel. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 22:48:33 -0000 On 4/5/11 1:35 PM, Navdeep Parhar wrote: > On Tue, Apr 5, 2011 at 1:33 PM, Julian Elischer wrote: >> On 4/4/11 6:04 PM, Justin Hibbits wrote: >>> On Apr 4, 2011, at 6:57 PM, Julian Elischer wrote: >>>> is there anyone here with enough gdb/kgdb source experience to know what >>>> we would need to put on the stack at fork_exit() to make it stop when it >>>> gets there? >>>> >>>> not only is it annoying but it slows down debugging because kgdb and the >>>> ddd >>>> front end ask for stacks a LOT. sometimes it actually just hangs as the >>>> stack >>>> goes into a loop and never ends. >>>> >>>> I had a quick look but didn't spot how gdb decides it has reached the end >>>> of a stack. >>>> >>>> Julian >>> From my experience, it checks for a NULL stack chain pointer. Once that >>> reaches NULL, it's the end of the stack. >>> >>> - Justin >>> >> I'll try adding NULL when we build the intial stack up. >> :-) > What does ddb do? It always seems to get this stuff correct. > > Navdeep it has all sorts of special code that knows the intricacies of freebsd's stack. (k)gdb only knows more generic stuff. hmmm set 0 into the saved ebp bit that didn't help.. I'll play a bit more From owner-freebsd-current@FreeBSD.ORG Wed Apr 6 01:15:33 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EE59106564A for ; Wed, 6 Apr 2011 01:15:33 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 17DC08FC12 for ; Wed, 6 Apr 2011 01:15:32 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p361FU3G060062 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 5 Apr 2011 18:15:32 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4D9BBED1.3070402@freebsd.org> Date: Tue, 05 Apr 2011 18:16:01 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: kernel thread creation cleanup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 01:15:33 -0000 I was just looking in the thread creation code after most of a decade NOT looking at it.. boy we really need to go through there with a broom.. the cobwebs are getting thick. Like we always call the code to put an upcall, even though we don't have upcalls any more, and we always create an trap frame on the stack even when we are making kernel threads that don't need it, actually, come to think of it DOES fork even need it? (need to go look) and we go through the fork trampoline even when we are doing kthread creation and could just as well go directly to the final function directly. (All of the above on amd64).. May be slighly different on other hardware, though much of it is encoded in MI code so probably not. This came from looking to see if I could somehow munge the stack to convince kgdb to damn well stop at that point (still failed. if anyone has ideas... :-) From owner-freebsd-current@FreeBSD.ORG Wed Apr 6 07:34:45 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E4701065670; Wed, 6 Apr 2011 07:34:45 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe05.c2i.net [212.247.154.130]) by mx1.freebsd.org (Postfix) with ESMTP id 7F1EB8FC24; Wed, 6 Apr 2011 07:34:43 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=upTJuTb3ngPPUUVVSPoyO7jwIWz3rzPtkQxI490l6Ks= c=1 sm=1 a=IU0TiZmyZPMA:10 a=dBRESv0yCI8A:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=6DktU5ojhI3KT9BTFMwA:9 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 109209700; Wed, 06 Apr 2011 09:34:42 +0200 Received-SPF: softfail receiver=mailfe05.swip.net; client-ip=188.126.198.129; envelope-from=hselasky@freebsd.org From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Wed, 6 Apr 2011 09:33:47 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-PRERELEASE; KDE/4.4.5; amd64; ; ) References: <201104051321.56319.hselasky@freebsd.org> <201104051455.33853.hselasky@freebsd.org> <4D9B473F.8020607@FreeBSD.org> In-Reply-To: <4D9B473F.8020607@FreeBSD.org> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201104060933.47350.hselasky@freebsd.org> Cc: "freebsd-current@FreeBSD.org" , Andriy Gapon Subject: Re: use_generic and usb probing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 07:34:45 -0000 On Tuesday 05 April 2011 18:45:51 Andriy Gapon wrote: > on 05/04/2011 15:55 Hans Petter Selasky said the following: > > On Tuesday 05 April 2011 14:50:43 Andriy Gapon wrote: > >> I believe that newbus already supports ordering of children on a bus. > >> > >> BTW, does USB have to pass anything from probe to attach? > > > > Mostly only the driver info field. To avoid duplicate lookups. > > > >> Duplicate lookup is of course not very nice, but duplicate probing pass > >> is not nice either. > > > > This can all be avoided if the bus-drivers are sorted correctly before > > probing! Hi, > > Well, I think that that's what probe priorities actually for. > I also think that typically ivars should be set by a bus driver. So maybe > it's not such a good idea to pass data from probe to attach via ivars in > child drivers. But I could be mistaken about that. > The same device_t is used to do all the probes! > Practically speaking, you most likely don't have to worry about that for > drivers that return BUS_PROBE_SPECIFIC (=0) from their probe methods. And > there is only a few "generic" drivers that can be handled on a case by > case basis. There are more drivers that needs patching! Please scan all of the kernel files for usbdi.h and the use_generic flag. After looking at subr_usb.c I see your solution is fine as long as the PROBE() method that it attaches is the last one called before ATTACH(). If this is documented in how newbus should function, then please go ahead updating your patch to cover all USB drivers using use_generic. --HPS From owner-freebsd-current@FreeBSD.ORG Wed Apr 6 10:21:48 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED335106566B; Wed, 6 Apr 2011 10:21:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 5140B8FC19; Wed, 6 Apr 2011 10:21:47 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p36ALivx046491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Apr 2011 13:21:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p36ALiBE086780; Wed, 6 Apr 2011 13:21:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p36ALh0E086779; Wed, 6 Apr 2011 13:21:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 6 Apr 2011 13:21:43 +0300 From: Kostik Belousov To: Julian Elischer Message-ID: <20110406102143.GG78089@deviant.kiev.zoral.com.ua> References: <4D9BBED1.3070402@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lJV3HQ6fE/Jb65V8" Content-Disposition: inline In-Reply-To: <4D9BBED1.3070402@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_05, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: FreeBSD Current Subject: Re: kernel thread creation cleanup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 10:21:49 -0000 --lJV3HQ6fE/Jb65V8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 05, 2011 at 06:16:01PM -0700, Julian Elischer wrote: > I was just looking in the thread creation code after most of a decade =20 > NOT looking at it.. > boy we really need to go through there with a broom.. the cobwebs are=20 > getting thick. > Like we always call the code to put an upcall, even though we don't=20 > have upcalls any more, cpu_set_upcall() probably could be renamed to cpu_init_thread(), and cpu_set_upcall_kse() is better named cpu_init_thread_for_user(). IMO, rename would only add a code churn. > and we always create an trap frame on the stack even when we are=20 > making kernel threads > that don't need it, actually, come to think of it DOES fork even need=20 > it? (need to go look) Trap frame for the new thread that is going to usermode after fork is definitely needed. Having fork trampoline executed for all threads is good, because it provides a convenient single point which is passed by all new threads. > and we go through the fork trampoline even when we are doing kthread=20 > creation and could just as well go > directly to the final function directly. (All of the above on amd64).. > May be slighly different on other hardware, though much of it is=20 > encoded in MI code so probably not. >=20 >=20 >=20 > This came from looking to see if I could somehow munge the stack to=20 > convince kgdb to damn well stop at > that point (still failed. if anyone has ideas... :-) Was it for amd64 ? I think the issue with kgdb is lack of the proper dwarf annotations for trampoline. --lJV3HQ6fE/Jb65V8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2cPrcACgkQC3+MBN1Mb4hbOwCfYpPG2Wv55PpHULAxErxmodT5 2U4AoMH9El6cFfmpwicOmHZKj9co49vb =rrFp -----END PGP SIGNATURE----- --lJV3HQ6fE/Jb65V8-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 6 08:13:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBAFA106564A; Wed, 6 Apr 2011 08:13:29 +0000 (UTC) (envelope-from nwf@cs.jhu.edu) Received: from blaze.cs.jhu.edu (blaze.cs.jhu.edu [128.220.13.50]) by mx1.freebsd.org (Postfix) with ESMTP id 825EF8FC12; Wed, 6 Apr 2011 08:13:29 +0000 (UTC) Received: from gradx.cs.jhu.edu (gradx.cs.jhu.edu [128.220.13.52]) by blaze.cs.jhu.edu (8.14.3/8.14.3) with ESMTP id p3680hhV021057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Apr 2011 04:00:43 -0400 (EDT) Received: from gradx.cs.jhu.edu (localhost [127.0.0.1]) by gradx.cs.jhu.edu (8.14.3/8.13.1) with ESMTP id p3680h1d009359; Wed, 6 Apr 2011 04:00:43 -0400 Received: (from nwf@localhost) by gradx.cs.jhu.edu (8.14.3/8.13.8/Submit) id p3680hCM009358; Wed, 6 Apr 2011 04:00:43 -0400 Date: Wed, 6 Apr 2011 04:00:43 -0400 From: Nathaniel W Filardo To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org Message-ID: <20110406080043.GQ609@gradx.cs.jhu.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NEvmWj2iiHf6S+l1" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-08-17) X-Mailman-Approved-At: Wed, 06 Apr 2011 11:12:10 +0000 Cc: Subject: ZFS panic with concurrent recv and read-heavy workload X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 08:13:30 -0000 --NEvmWj2iiHf6S+l1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable When racing two workloads, one doing > zfs recv -v -d testpool and the other > find /testpool -type f -print0 | xargs -0 sha1 I can (seemingly reliably) trigger this panic: panic: Lock buf_hash_table.ht_locks[i].ht_lock not exclusively locked @ /us= r/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.= c:1869 =20 = =20 cpuid =3D 1 = =20 KDB: stack backtrace: = =20 panic() at panic+0x1c8 = =20 _sx_assert() at _sx_assert+0xc4 = =20 _sx_xunlock() at _sx_xunlock+0x98 = =20 arc_evict() at arc_evict+0x614 = =20 arc_get_data_buf() at arc_get_data_buf+0x360 = =20 arc_buf_alloc() at arc_buf_alloc+0x94 = =20 dmu_buf_will_fill() at dmu_buf_will_fill+0xfc dmu_write() at dmu_write+0xec dmu_recv_stream() at dmu_recv_stream+0x8a8 = =20 zfs_ioc_recv() at zfs_ioc_recv+0x354 = =20 zfsdev_ioctl() at zfsdev_ioctl+0xe0 = =20 devfs_ioctl_f() at devfs_ioctl_f+0xe8 = =20 kern_ioctl() at kern_ioctl+0x294 = =20 ioctl() at ioctl+0x198 syscallenter() at syscallenter+0x270 syscall() at syscall+0x74 = =20 -- syscall (54, FreeBSD ELF64, ioctl) %o7=3D0x40c13e24 -- = =20 userland() at 0x40e72cc8 = =20 user trace: trap %o7=3D0x40c13e24 = =20 pc 0x40e72cc8, sp 0x7fdffff4641 pc 0x40c158f4, sp 0x7fdffff4721 = =20 pc 0x40c1e878, sp 0x7fdffff47f1 = =20 pc 0x40c1ce54, sp 0x7fdffff8b01 = =20 pc 0x40c1dbe0, sp 0x7fdffff9431 = =20 pc 0x40c1f718, sp 0x7fdffffd741 = =20 pc 0x10731c, sp 0x7fdffffd831 = =20 pc 0x10c90c, sp 0x7fdffffd8f1 = =20 pc 0x103ef0, sp 0x7fdffffe1d1 = =20 pc 0x4021aff4, sp 0x7fdffffe291 = =20 done The machine is a freshly installed and built sparc64 2-way SMP, running today's -CURRENT with http://people.freebsd.org/~mm/patches/zfs/zfs_ioctl_compat_bugfix.patch applied. Of note, it has only 1G of RAM in it, so kmem_max <=3D 512M. Thoughts? More information? Thanks in advance. --nwf; --NEvmWj2iiHf6S+l1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk2cHasACgkQTeQabvr9Tc+K4QCeOE6VM+JEoPVsvgDXPpIhSuG/ Nq4Ani1uL00nzKfhxpAQRxWCc51hWxw2 =ep5z -----END PGP SIGNATURE----- --NEvmWj2iiHf6S+l1-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 6 12:45:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9DCC106566C for ; Wed, 6 Apr 2011 12:45:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B3B858FC12 for ; Wed, 6 Apr 2011 12:45:13 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 4FF3346B38; Wed, 6 Apr 2011 08:45:13 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D9B448A02A; Wed, 6 Apr 2011 08:45:12 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 6 Apr 2011 08:36:56 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201104060836.56542.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 06 Apr 2011 08:45:12 -0400 (EDT) Cc: Ryan Stone Subject: Re: sched_4bsd startup crash trying to run a bound thread on an AP that hasn't started X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 12:45:13 -0000 On Monday, April 04, 2011 5:10:20 pm Ryan Stone wrote: > I'm running into a bootup crash under sched_4bsd on HEAD. The crash > happens when I have a thread bound to a single CPU that isn't the BSP, > and that thread is scheduled. If the AP that the thread is bound > hasn't been started up, kick_other_cpu() crashes because > pcpu->pc_curthread is NULL for the AP. > > I've put a small test kld in > http://people.freebsd.org/~rstone/4bsd_bind/ that reproduces the > problem. I'm not sure what the best way to address the crash is. ULE > is not affected by the problem; it seems to run the swi thread on CPU > 0 until CPU 1 is running. Hummm. Patching 4BSD to use the same route as ULE may be the best solution for now if that is easiest. Alternatively, you could change 4BSD's sched_add() to not try to kick other CPUs until smp_started is true. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Apr 6 12:45:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AB471065670; Wed, 6 Apr 2011 12:45:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D7C4C8FC13; Wed, 6 Apr 2011 12:45:13 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 897FE46B49; Wed, 6 Apr 2011 08:45:13 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2174B8A02B; Wed, 6 Apr 2011 08:45:13 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 6 Apr 2011 08:37:50 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4D9A4CE5.5090900@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201104060837.50411.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 06 Apr 2011 08:45:13 -0400 (EDT) Cc: Justin Hibbits , FreeBSD Current Subject: Re: KGDB stack traces in the kernel. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 12:45:14 -0000 On Monday, April 04, 2011 9:04:23 pm Justin Hibbits wrote: > On Apr 4, 2011, at 6:57 PM, Julian Elischer wrote: > > is there anyone here with enough gdb/kgdb source experience to know > > what > > we would need to put on the stack at fork_exit() to make it stop > > when it > > gets there? > > > > not only is it annoying but it slows down debugging because kgdb and > > the ddd > > front end ask for stacks a LOT. sometimes it actually just hangs as > > the stack > > goes into a loop and never ends. > > > > I had a quick look but didn't spot how gdb decides it has reached > > the end of a stack. > > > > Julian > > From my experience, it checks for a NULL stack chain pointer. Once > that reaches NULL, it's the end of the stack. No, I removed that because it broke debugging panics due to NULL function pointers. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Apr 6 12:45:14 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AB471065670; Wed, 6 Apr 2011 12:45:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D7C4C8FC13; Wed, 6 Apr 2011 12:45:13 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 897FE46B49; Wed, 6 Apr 2011 08:45:13 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2174B8A02B; Wed, 6 Apr 2011 08:45:13 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 6 Apr 2011 08:37:50 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4D9A4CE5.5090900@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201104060837.50411.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 06 Apr 2011 08:45:13 -0400 (EDT) Cc: Justin Hibbits , FreeBSD Current Subject: Re: KGDB stack traces in the kernel. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 12:45:14 -0000 On Monday, April 04, 2011 9:04:23 pm Justin Hibbits wrote: > On Apr 4, 2011, at 6:57 PM, Julian Elischer wrote: > > is there anyone here with enough gdb/kgdb source experience to know > > what > > we would need to put on the stack at fork_exit() to make it stop > > when it > > gets there? > > > > not only is it annoying but it slows down debugging because kgdb and > > the ddd > > front end ask for stacks a LOT. sometimes it actually just hangs as > > the stack > > goes into a loop and never ends. > > > > I had a quick look but didn't spot how gdb decides it has reached > > the end of a stack. > > > > Julian > > From my experience, it checks for a NULL stack chain pointer. Once > that reaches NULL, it's the end of the stack. No, I removed that because it broke debugging panics due to NULL function pointers. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Apr 6 12:45:14 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 998191065673; Wed, 6 Apr 2011 12:45:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5730C8FC15; Wed, 6 Apr 2011 12:45:14 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id DF36646B4C; Wed, 6 Apr 2011 08:45:13 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7BE5C8A02C; Wed, 6 Apr 2011 08:45:13 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 6 Apr 2011 08:45:11 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4D9A4CE5.5090900@freebsd.org> <4D9B7C92.6030901@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201104060845.11771.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 06 Apr 2011 08:45:13 -0400 (EDT) Cc: Justin Hibbits , Navdeep Parhar , FreeBSD Current Subject: Re: KGDB stack traces in the kernel. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 12:45:14 -0000 On Tuesday, April 05, 2011 4:35:44 pm Navdeep Parhar wrote: > On Tue, Apr 5, 2011 at 1:33 PM, Julian Elischer wrote: > > On 4/4/11 6:04 PM, Justin Hibbits wrote: > >> > >> On Apr 4, 2011, at 6:57 PM, Julian Elischer wrote: > >>> > >>> is there anyone here with enough gdb/kgdb source experience to know what > >>> we would need to put on the stack at fork_exit() to make it stop when it > >>> gets there? > >>> > >>> not only is it annoying but it slows down debugging because kgdb and the > >>> ddd > >>> front end ask for stacks a LOT. sometimes it actually just hangs as the > >>> stack > >>> goes into a loop and never ends. > >>> > >>> I had a quick look but didn't spot how gdb decides it has reached the end > >>> of a stack. > >>> > >>> Julian > >> > >> From my experience, it checks for a NULL stack chain pointer. Once that > >> reaches NULL, it's the end of the stack. > >> > >> - Justin > >> > > I'll try adding NULL when we build the intial stack up. > > :-) > > What does ddb do? It always seems to get this stuff correct. ddb knows to stop when it gets to a non-kernel address, and it uses string compares on function names to identify trap frames. For example in sys/amd64/amd64/db_trace.c: if (strcmp(name, "calltrap") == 0 || strcmp(name, "fork_trampoline") == 0 || strcmp(name, "nmi_calltrap") == 0 || strcmp(name, "Xdblfault") == 0) frame_type = TRAP; Hah, kgdb just needs to be updated (this is from trgt_amd64.c): const struct frame_unwind * kgdb_trgt_trapframe_sniffer(struct frame_info *next_frame) { char *pname; CORE_ADDR pc; pc = frame_pc_unwind(next_frame); pname = NULL; find_pc_partial_function(pc, &pname, NULL, NULL); if (pname == NULL) return (NULL); if (strcmp(pname, "calltrap") == 0 || strcmp(pname, "nmi_calltrap") == 0 || (pname[0] == 'X' && pname[1] != '_')) return (&kgdb_trgt_trapframe_unwind); /* printf("%s: %lx =%s\n", __func__, pc, pname); */ return (NULL); } Can probably just add 'fork_trampoline' to that conditional. I think i386 needs a similar fix in kgdb. Not sure about other architectures: Index: trgt_amd64.c =================================================================== --- trgt_amd64.c (revision 220190) +++ trgt_amd64.c (working copy) @@ -184,6 +184,7 @@ if (pname == NULL) return (NULL); if (strcmp(pname, "calltrap") == 0 || + strcmp(pname, "fork_trampoline") == 0 || strcmp(pname, "nmi_calltrap") == 0 || (pname[0] == 'X' && pname[1] != '_')) return (&kgdb_trgt_trapframe_unwind); Index: trgt_i386.c =================================================================== --- trgt_i386.c (revision 220190) +++ trgt_i386.c (working copy) @@ -374,6 +374,7 @@ if (strcmp(pname, "dblfault_handler") == 0) return (&kgdb_trgt_dblfault_unwind); if (strcmp(pname, "calltrap") == 0 || + strcmp(pname, "fork_trampoline") == 0 || (pname[0] == 'X' && pname[1] != '_')) return (&kgdb_trgt_trapframe_unwind); /* printf("%s: %llx =%s\n", __func__, pc, pname); */ -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Apr 6 12:45:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 998191065673; Wed, 6 Apr 2011 12:45:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5730C8FC15; Wed, 6 Apr 2011 12:45:14 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id DF36646B4C; Wed, 6 Apr 2011 08:45:13 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7BE5C8A02C; Wed, 6 Apr 2011 08:45:13 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 6 Apr 2011 08:45:11 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4D9A4CE5.5090900@freebsd.org> <4D9B7C92.6030901@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201104060845.11771.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 06 Apr 2011 08:45:13 -0400 (EDT) Cc: Justin Hibbits , Navdeep Parhar , FreeBSD Current Subject: Re: KGDB stack traces in the kernel. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 12:45:14 -0000 On Tuesday, April 05, 2011 4:35:44 pm Navdeep Parhar wrote: > On Tue, Apr 5, 2011 at 1:33 PM, Julian Elischer wrote: > > On 4/4/11 6:04 PM, Justin Hibbits wrote: > >> > >> On Apr 4, 2011, at 6:57 PM, Julian Elischer wrote: > >>> > >>> is there anyone here with enough gdb/kgdb source experience to know what > >>> we would need to put on the stack at fork_exit() to make it stop when it > >>> gets there? > >>> > >>> not only is it annoying but it slows down debugging because kgdb and the > >>> ddd > >>> front end ask for stacks a LOT. sometimes it actually just hangs as the > >>> stack > >>> goes into a loop and never ends. > >>> > >>> I had a quick look but didn't spot how gdb decides it has reached the end > >>> of a stack. > >>> > >>> Julian > >> > >> From my experience, it checks for a NULL stack chain pointer. Once that > >> reaches NULL, it's the end of the stack. > >> > >> - Justin > >> > > I'll try adding NULL when we build the intial stack up. > > :-) > > What does ddb do? It always seems to get this stuff correct. ddb knows to stop when it gets to a non-kernel address, and it uses string compares on function names to identify trap frames. For example in sys/amd64/amd64/db_trace.c: if (strcmp(name, "calltrap") == 0 || strcmp(name, "fork_trampoline") == 0 || strcmp(name, "nmi_calltrap") == 0 || strcmp(name, "Xdblfault") == 0) frame_type = TRAP; Hah, kgdb just needs to be updated (this is from trgt_amd64.c): const struct frame_unwind * kgdb_trgt_trapframe_sniffer(struct frame_info *next_frame) { char *pname; CORE_ADDR pc; pc = frame_pc_unwind(next_frame); pname = NULL; find_pc_partial_function(pc, &pname, NULL, NULL); if (pname == NULL) return (NULL); if (strcmp(pname, "calltrap") == 0 || strcmp(pname, "nmi_calltrap") == 0 || (pname[0] == 'X' && pname[1] != '_')) return (&kgdb_trgt_trapframe_unwind); /* printf("%s: %lx =%s\n", __func__, pc, pname); */ return (NULL); } Can probably just add 'fork_trampoline' to that conditional. I think i386 needs a similar fix in kgdb. Not sure about other architectures: Index: trgt_amd64.c =================================================================== --- trgt_amd64.c (revision 220190) +++ trgt_amd64.c (working copy) @@ -184,6 +184,7 @@ if (pname == NULL) return (NULL); if (strcmp(pname, "calltrap") == 0 || + strcmp(pname, "fork_trampoline") == 0 || strcmp(pname, "nmi_calltrap") == 0 || (pname[0] == 'X' && pname[1] != '_')) return (&kgdb_trgt_trapframe_unwind); Index: trgt_i386.c =================================================================== --- trgt_i386.c (revision 220190) +++ trgt_i386.c (working copy) @@ -374,6 +374,7 @@ if (strcmp(pname, "dblfault_handler") == 0) return (&kgdb_trgt_dblfault_unwind); if (strcmp(pname, "calltrap") == 0 || + strcmp(pname, "fork_trampoline") == 0 || (pname[0] == 'X' && pname[1] != '_')) return (&kgdb_trgt_trapframe_unwind); /* printf("%s: %llx =%s\n", __func__, pc, pname); */ -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Apr 6 12:48:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D1B5106568B; Wed, 6 Apr 2011 12:48:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 75CF68FC16; Wed, 6 Apr 2011 12:48:41 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 2994646B38; Wed, 6 Apr 2011 08:48:41 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B2A7B8A027; Wed, 6 Apr 2011 08:48:40 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 6 Apr 2011 08:48:39 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <201104051321.56319.hselasky@freebsd.org> <4D9B473F.8020607@FreeBSD.org> <201104060933.47350.hselasky@freebsd.org> In-Reply-To: <201104060933.47350.hselasky@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201104060848.40278.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 06 Apr 2011 08:48:40 -0400 (EDT) Cc: Andriy Gapon , Hans Petter Selasky , freebsd-usb@freebsd.org Subject: Re: use_generic and usb probing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 12:48:41 -0000 On Wednesday, April 06, 2011 3:33:47 am Hans Petter Selasky wrote: > On Tuesday 05 April 2011 18:45:51 Andriy Gapon wrote: > > on 05/04/2011 15:55 Hans Petter Selasky said the following: > > > On Tuesday 05 April 2011 14:50:43 Andriy Gapon wrote: > > >> I believe that newbus already supports ordering of children on a bus. > > >> > > >> BTW, does USB have to pass anything from probe to attach? > > > > > > Mostly only the driver info field. To avoid duplicate lookups. > > > > > >> Duplicate lookup is of course not very nice, but duplicate probing pass > > >> is not nice either. > > > > > > This can all be avoided if the bus-drivers are sorted correctly before > > > probing! > > Hi, > > > > > Well, I think that that's what probe priorities actually for. > > I also think that typically ivars should be set by a bus driver. So maybe > > it's not such a good idea to pass data from probe to attach via ivars in > > child drivers. But I could be mistaken about that. > > > > The same device_t is used to do all the probes! > > > Practically speaking, you most likely don't have to worry about that for > > drivers that return BUS_PROBE_SPECIFIC (=0) from their probe methods. And > > there is only a few "generic" drivers that can be handled on a case by > > case basis. > > There are more drivers that needs patching! Please scan all of the kernel > files for usbdi.h and the use_generic flag. > > After looking at subr_usb.c I see your solution is fine as long as the PROBE() > method that it attaches is the last one called before ATTACH(). If this is > documented in how newbus should function, then please go ahead updating your > patch to cover all USB drivers using use_generic. Yes. The device_probe() routine is called for the "best" matching driver (based on the return values from device_probe()) before device_attach() is called. Check device_probe_child() for the gory details including: if (pri < 0) { /* * A bit bogus. Call the probe method again to make * sure that we have the right description. */ DEVICE_PROBE(child); #if 0 child->flags |= DF_REBID; #endif } else child->flags &= ~DF_REBID; child->state = DS_ALIVE; -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Apr 6 13:21:22 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D30D0106564A; Wed, 6 Apr 2011 13:21:22 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9F3F78FC0A; Wed, 6 Apr 2011 13:21:21 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA25399; Wed, 06 Apr 2011 16:21:19 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4D9C68CF.1060101@FreeBSD.org> Date: Wed, 06 Apr 2011 16:21:19 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110309 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Hans Petter Selasky References: <201104051321.56319.hselasky@freebsd.org> <201104051455.33853.hselasky@freebsd.org> <4D9B473F.8020607@FreeBSD.org> <201104060933.47350.hselasky@freebsd.org> In-Reply-To: <201104060933.47350.hselasky@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "freebsd-current@FreeBSD.org" , freebsd-usb@FreeBSD.org Subject: Re: use_generic and usb probing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 13:21:22 -0000 on 06/04/2011 10:33 Hans Petter Selasky said the following: > After looking at subr_usb.c I see your solution is fine as long as the PROBE() > method that it attaches is the last one called before ATTACH(). If this is > documented in how newbus should function, then please go ahead updating your > patch to cover all USB drivers using use_generic. Which drivers I have missed? Thanks! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Apr 6 13:29:10 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A7D61065673; Wed, 6 Apr 2011 13:29:10 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe02.c2i.net [212.247.154.34]) by mx1.freebsd.org (Postfix) with ESMTP id 6B2FC8FC0C; Wed, 6 Apr 2011 13:29:08 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=oR3+9dOmPeF3nZCt5Gxyvf/bIpfj8bfjGZkkfp/xES8= c=1 sm=1 a=IU0TiZmyZPMA:10 a=dBRESv0yCI8A:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=PVfhkc0PiHU7cHlbjhEA:9 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 110662836; Wed, 06 Apr 2011 15:29:07 +0200 Received-SPF: softfail receiver=mailfe02.swip.net; client-ip=188.126.198.129; envelope-from=hselasky@freebsd.org From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Wed, 6 Apr 2011 15:28:13 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-PRERELEASE; KDE/4.4.5; amd64; ; ) References: <201104051321.56319.hselasky@freebsd.org> <201104060933.47350.hselasky@freebsd.org> <4D9C68CF.1060101@FreeBSD.org> In-Reply-To: <4D9C68CF.1060101@FreeBSD.org> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201104061528.13220.hselasky@freebsd.org> Cc: "freebsd-current@FreeBSD.org" , Andriy Gapon Subject: Re: use_generic and usb probing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 13:29:10 -0000 On Wednesday 06 April 2011 15:21:19 Andriy Gapon wrote: > on 06/04/2011 10:33 Hans Petter Selasky said the following: > > Which drivers I have missed? > Thanks! Run a kernel test compile including all modules. If that's OK it should be fine. --HPS From owner-freebsd-current@FreeBSD.ORG Wed Apr 6 13:36:43 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95543106567D; Wed, 6 Apr 2011 13:36:43 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7B6998FC12; Wed, 6 Apr 2011 13:36:42 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA25676; Wed, 06 Apr 2011 16:36:40 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4D9C6C67.6090206@FreeBSD.org> Date: Wed, 06 Apr 2011 16:36:39 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110309 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Hans Petter Selasky References: <201104051321.56319.hselasky@freebsd.org> <201104060933.47350.hselasky@freebsd.org> <4D9C68CF.1060101@FreeBSD.org> <201104061528.13220.hselasky@freebsd.org> In-Reply-To: <201104061528.13220.hselasky@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "freebsd-current@FreeBSD.org" , freebsd-usb@FreeBSD.org Subject: Re: use_generic and usb probing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 13:36:43 -0000 on 06/04/2011 16:28 Hans Petter Selasky said the following: > On Wednesday 06 April 2011 15:21:19 Andriy Gapon wrote: >> on 06/04/2011 10:33 Hans Petter Selasky said the following: > >> >> Which drivers I have missed? >> Thanks! > > Run a kernel test compile including all modules. If that's OK it should be > fine. Yes, that's how I tested it. I also used 'glimpse' to find all occurrences of use_generic :) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Apr 6 13:39:48 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B68791065670 for ; Wed, 6 Apr 2011 13:39:48 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 85E768FC17 for ; Wed, 6 Apr 2011 13:39:48 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 81D686160 for ; Wed, 6 Apr 2011 09:39:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1302097187; bh=yPoFCFqEyx5Bg35OlW0XdA6b0oiKc7swhyhjZZ3gAdE=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=jF5LKHkClTOFNwoVeeC+mbRGR6jJPwxXM6CW9mwXN0JGwwwAHP8G7isxYAu1lh5iI l5fPwITtafQabiPQsbMUO/A1y0OA9u+vXq1owKHWEN2QdSmgqCHU7rcy5mQ2WDF DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=qSZgmRblo62l7QrkJIagBTz6fGk3cSiS1xfZg3s5/L4FjOhBGN20Xzs7wjWINiWzV xUObXVQ8tvl64gB6yqYtMkuv/scsVBL/xOZ5ZL46VWskzln47P/0XQdXzosznTP Message-ID: <4D9C6D21.1020006@protected-networks.net> Date: Wed, 06 Apr 2011 09:39:45 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.15) Gecko/20110305 Thunderbird/3.1.9 MIME-Version: 1.0 To: current@FreeBSD.org X-Enigmail-Version: 1.1.2 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: SVN -> CVS burp? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 13:39:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It seem that CVS hasn't seen any "src" updates sine the burp involving "/usr/ports/net/unison232/files/patch-update.mli.diff". Any ideas? imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2cbSEACgkQQv9rrgRC1JLglwCfZj7aMroEyTrk1s6/NfiCS4GK FYsAnR4cWbt6DrsGHqAUPFFVbtlEeAT/ =n3Vi -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Apr 6 13:43:33 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13C03106566B for ; Wed, 6 Apr 2011 13:43:33 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id B19BD8FC1B for ; Wed, 6 Apr 2011 13:43:32 +0000 (UTC) Received: from outgoing.leidinger.net (p5B1561B0.dip.t-dialin.net [91.21.97.176]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id EB8E1844018; Wed, 6 Apr 2011 15:43:28 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id 224F7155E; Wed, 6 Apr 2011 15:43:26 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id p36DhPGK037130; Wed, 6 Apr 2011 15:43:25 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Wed, 06 Apr 2011 15:43:25 +0200 Message-ID: <20110406154325.157845mc2tp09mgw@webmail.leidinger.net> Date: Wed, 06 Apr 2011 15:43:25 +0200 From: Alexander Leidinger To: Kostik Belousov References: <4D9BBED1.3070402@freebsd.org> <20110406102143.GG78089@deviant.kiev.zoral.com.ua> In-Reply-To: <20110406102143.GG78089@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.6) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: EB8E1844018.A1304 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=0, required 6, autolearn=disabled) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1302702209.79979@H8MEcS5PQDiZmSnHBBiFZA X-EBL-Spam-Status: No Cc: FreeBSD Current Subject: Re: kernel thread creation cleanup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 13:43:33 -0000 Quoting Kostik Belousov (from Wed, 6 Apr 2011 13:21:43 +0300): > On Tue, Apr 05, 2011 at 06:16:01PM -0700, Julian Elischer wrote: >> I was just looking in the thread creation code after most of a decade >> NOT looking at it.. >> boy we really need to go through there with a broom.. the cobwebs are >> getting thick. >> Like we always call the code to put an upcall, even though we don't >> have upcalls any more, > cpu_set_upcall() probably could be renamed to cpu_init_thread(), > and cpu_set_upcall_kse() is better named cpu_init_thread_for_user(). > > IMO, rename would only add a code churn. Do not underestimate the impact of misnamed functions. Do not underestimate the usefulness of correcly named functions. Does a change help other developers (to understand or extend) or improves what we have: it is not code churn. Bye, Alexander. -- You can move the world with an idea, but you have to think of it first. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Wed Apr 6 17:08:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 915191065670 for ; Wed, 6 Apr 2011 17:08:22 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2407B8FC1C for ; Wed, 6 Apr 2011 17:08:21 +0000 (UTC) Received: by eyg7 with SMTP id 7so570291eyg.13 for ; Wed, 06 Apr 2011 10:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=4AKPanPxzomJlB2mnBK9+L3e8SLZ7If7BTtGu3CKIuc=; b=DhWVwmomE27Wq6A/6skL/d8lsS5ljxVyQOhktJWBdeVcLTp6pkOZvoKJlVSJxjqXaG ExLSEIzch3HrsVrA+v3rGe45k4Em3s/U8KMu/0OFMNhb2LwBzbZeNLeDE1sZp3vh6VMk 3xWg9YMry838A6SQolFSEGFZeeZAzhqpXe2iE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=QIlbW9cU3MRKZ6OD4N1Pi8St4VPR3A6GufwUG3k2WLLOnLPMqaaYTMlD4Q3NEmCv9Y wdk11PjQ8LKi/naOImJYws2pfClmMFhqMQkuuBC/ZbFfd7/GoazmirajbXvoUgD5no0g wps0dcTeLD5DEnjaxZH5fDaoHr+D2Q+BJvr8w= MIME-Version: 1.0 Received: by 10.213.105.204 with SMTP id u12mr928117ebo.130.1302109700896; Wed, 06 Apr 2011 10:08:20 -0700 (PDT) Received: by 10.213.112.212 with HTTP; Wed, 6 Apr 2011 10:08:20 -0700 (PDT) In-Reply-To: <201104060836.56542.jhb@freebsd.org> References: <201104060836.56542.jhb@freebsd.org> Date: Wed, 6 Apr 2011 13:08:20 -0400 Message-ID: From: Ryan Stone To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: sched_4bsd startup crash trying to run a bound thread on an AP that hasn't started X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 17:08:22 -0000 On Wed, Apr 6, 2011 at 8:36 AM, John Baldwin wrote: > Hummm. =A0Patching 4BSD to use the same route as ULE may be the best solu= tion > for now if that is easiest. =A0Alternatively, you could change 4BSD's > sched_add() to not try to kick other CPUs until smp_started is true. At first I thought that it was a consequence of the way it does CPU affinity, but now I see that it shortcuts if smp_started is not true. How about something like the following for 4BSD? --- sched_4bsd.c (revision 220222) +++ sched_4bsd.c (working copy) @@ -1242,14 +1242,14 @@ } TD_SET_RUNQ(td); - if (td->td_pinned !=3D 0) { + if (smp_started && td->td_pinned !=3D 0) { cpu =3D td->td_lastcpu; ts->ts_runq =3D &runq_pcpu[cpu]; single_cpu =3D 1; CTR3(KTR_RUNQ, "sched_add: Put td_sched:%p(td:%p) on cpu%d runq", ts, = td, cpu); - } else if (td->td_flags & TDF_BOUND) { + } else if (smp_started && (td->td_flags & TDF_BOUND)) { /* Find CPU from bound runq. */ KASSERT(SKE_RUNQ_PCPU(ts), ("sched_add: bound td_sched not on cpu runq")); @@ -1258,7 +1258,7 @@ CTR3(KTR_RUNQ, "sched_add: Put td_sched:%p(td:%p) on cpu%d runq", ts, = td, cpu); - } else if (ts->ts_flags & TSF_AFFINITY) { + } else if (smp_started && (ts->ts_flags & TSF_AFFINITY)) { /* Find a valid CPU for our cpuset */ cpu =3D sched_pickcpu(td); ts->ts_runq =3D &runq_pcpu[cpu]; The flow control is a bit awkward because of the multiple affinity/bound cpu cases. If somebody prefers the code to be structured differently I'd be open to suggestions. Ryan From owner-freebsd-current@FreeBSD.ORG Wed Apr 6 17:13:52 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E689106564A for ; Wed, 6 Apr 2011 17:13:52 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 528418FC18 for ; Wed, 6 Apr 2011 17:13:52 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p36HDo7o064728 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 6 Apr 2011 10:13:51 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4D9C9F6D.4030503@freebsd.org> Date: Wed, 06 Apr 2011 10:14:21 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Kostik Belousov References: <4D9BBED1.3070402@freebsd.org> <20110406102143.GG78089@deviant.kiev.zoral.com.ua> In-Reply-To: <20110406102143.GG78089@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: kernel thread creation cleanup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 17:13:52 -0000 On 4/6/11 3:21 AM, Kostik Belousov wrote: > On Tue, Apr 05, 2011 at 06:16:01PM -0700, Julian Elischer wrote: >> I was just looking in the thread creation code after most of a decade >> NOT looking at it.. >> boy we really need to go through there with a broom.. the cobwebs are >> getting thick. >> Like we always call the code to put an upcall, even though we don't >> have upcalls any more, > cpu_set_upcall() probably could be renamed to cpu_init_thread(), > and cpu_set_upcall_kse() is better named cpu_init_thread_for_user(). yeah, we should have changed the names when they got the new jobs. (when KSE went away) > IMO, rename would only add a code churn. >> and we always create an trap frame on the stack even when we are >> making kernel threads >> that don't need it, actually, come to think of it DOES fork even need >> it? (need to go look) > Trap frame for the new thread that is going to usermode after fork is > definitely needed. Having fork trampoline executed for all threads is > good, because it provides a convenient single point which is passed by > all new threads. One thing the current code does is puts a trap frame on hte stack, whether you will need it or not. the result of that is that the trap frame is the next thing on the stack after fork_exit on the stack so that if you return from fork_exit you hit the frame (which is not set up to work) if you are creating a new kthread. not that you SHOULD return of course... anyhow it's a waste of 192 bytes of stack.. For normal fork/thread_create I guess the frame tries to return to userland, and is needed. >> and we go through the fork trampoline even when we are doing kthread >> creation and could just as well go >> directly to the final function directly. (All of the above on amd64).. >> May be slighly different on other hardware, though much of it is >> encoded in MI code so probably not. >> >> >> >> This came from looking to see if I could somehow munge the stack to >> convince kgdb to damn well stop at >> that point (still failed. if anyone has ideas... :-) > Was it for amd64 ? I think the issue with kgdb is lack of the proper > dwarf annotations for trampoline. It's possible some sort of anotation woudl stop the stack when it saw that return address, but one would think there was some other way too.. it even carries on with a 0 %rbp which is bogus. From owner-freebsd-current@FreeBSD.ORG Wed Apr 6 17:16:32 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15292106566C; Wed, 6 Apr 2011 17:16:32 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id BF5408FC16; Wed, 6 Apr 2011 17:16:31 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p36HGTqY064738 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 6 Apr 2011 10:16:30 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4D9CA00C.20307@freebsd.org> Date: Wed, 06 Apr 2011 10:17:00 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: John Baldwin References: <4D9A4CE5.5090900@freebsd.org> <4D9B7C92.6030901@freebsd.org> <201104060845.11771.jhb@freebsd.org> In-Reply-To: <201104060845.11771.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Justin Hibbits , Navdeep Parhar , FreeBSD Current Subject: Re: KGDB stack traces in the kernel. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 17:16:32 -0000 On 4/6/11 5:45 AM, John Baldwin wrote: > On Tuesday, April 05, 2011 4:35:44 pm Navdeep Parhar wrote: >> On Tue, Apr 5, 2011 at 1:33 PM, Julian Elischer wrote: >>> On 4/4/11 6:04 PM, Justin Hibbits wrote: >>> >> What does ddb do? It always seems to get this stuff correct. > ddb knows to stop when it gets to a non-kernel address, and it uses string > compares on function names to identify trap frames. For example in > sys/amd64/amd64/db_trace.c: > > > if (strcmp(name, "calltrap") == 0 || > strcmp(name, "fork_trampoline") == 0 || > strcmp(name, "nmi_calltrap") == 0 || > strcmp(name, "Xdblfault") == 0) > frame_type = TRAP; > > Hah, kgdb just needs to be updated (this is from trgt_amd64.c): > > const struct frame_unwind * > kgdb_trgt_trapframe_sniffer(struct frame_info *next_frame) > { > char *pname; > CORE_ADDR pc; > > pc = frame_pc_unwind(next_frame); > pname = NULL; > find_pc_partial_function(pc,&pname, NULL, NULL); > if (pname == NULL) > return (NULL); > if (strcmp(pname, "calltrap") == 0 || > strcmp(pname, "nmi_calltrap") == 0 || > (pname[0] == 'X'&& pname[1] != '_')) > return (&kgdb_trgt_trapframe_unwind); > /* printf("%s: %lx =%s\n", __func__, pc, pname); */ > return (NULL); > } > I'll give that a try > Can probably just add 'fork_trampoline' to that conditional. I think i386 > needs a similar fix in kgdb. Not sure about other architectures: > > Index: trgt_amd64.c > =================================================================== > --- trgt_amd64.c (revision 220190) > +++ trgt_amd64.c (working copy) > @@ -184,6 +184,7 @@ > if (pname == NULL) > return (NULL); > if (strcmp(pname, "calltrap") == 0 || > + strcmp(pname, "fork_trampoline") == 0 || > strcmp(pname, "nmi_calltrap") == 0 || > (pname[0] == 'X'&& pname[1] != '_')) > return (&kgdb_trgt_trapframe_unwind); > Index: trgt_i386.c > =================================================================== > --- trgt_i386.c (revision 220190) > +++ trgt_i386.c (working copy) > @@ -374,6 +374,7 @@ > if (strcmp(pname, "dblfault_handler") == 0) > return (&kgdb_trgt_dblfault_unwind); > if (strcmp(pname, "calltrap") == 0 || > + strcmp(pname, "fork_trampoline") == 0 || > (pname[0] == 'X'&& pname[1] != '_')) > return (&kgdb_trgt_trapframe_unwind); > /* printf("%s: %llx =%s\n", __func__, pc, pname); */ > From owner-freebsd-current@FreeBSD.ORG Wed Apr 6 17:16:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15292106566C; Wed, 6 Apr 2011 17:16:32 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id BF5408FC16; Wed, 6 Apr 2011 17:16:31 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p36HGTqY064738 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 6 Apr 2011 10:16:30 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4D9CA00C.20307@freebsd.org> Date: Wed, 06 Apr 2011 10:17:00 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: John Baldwin References: <4D9A4CE5.5090900@freebsd.org> <4D9B7C92.6030901@freebsd.org> <201104060845.11771.jhb@freebsd.org> In-Reply-To: <201104060845.11771.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Justin Hibbits , Navdeep Parhar , FreeBSD Current Subject: Re: KGDB stack traces in the kernel. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 17:16:32 -0000 On 4/6/11 5:45 AM, John Baldwin wrote: > On Tuesday, April 05, 2011 4:35:44 pm Navdeep Parhar wrote: >> On Tue, Apr 5, 2011 at 1:33 PM, Julian Elischer wrote: >>> On 4/4/11 6:04 PM, Justin Hibbits wrote: >>> >> What does ddb do? It always seems to get this stuff correct. > ddb knows to stop when it gets to a non-kernel address, and it uses string > compares on function names to identify trap frames. For example in > sys/amd64/amd64/db_trace.c: > > > if (strcmp(name, "calltrap") == 0 || > strcmp(name, "fork_trampoline") == 0 || > strcmp(name, "nmi_calltrap") == 0 || > strcmp(name, "Xdblfault") == 0) > frame_type = TRAP; > > Hah, kgdb just needs to be updated (this is from trgt_amd64.c): > > const struct frame_unwind * > kgdb_trgt_trapframe_sniffer(struct frame_info *next_frame) > { > char *pname; > CORE_ADDR pc; > > pc = frame_pc_unwind(next_frame); > pname = NULL; > find_pc_partial_function(pc,&pname, NULL, NULL); > if (pname == NULL) > return (NULL); > if (strcmp(pname, "calltrap") == 0 || > strcmp(pname, "nmi_calltrap") == 0 || > (pname[0] == 'X'&& pname[1] != '_')) > return (&kgdb_trgt_trapframe_unwind); > /* printf("%s: %lx =%s\n", __func__, pc, pname); */ > return (NULL); > } > I'll give that a try > Can probably just add 'fork_trampoline' to that conditional. I think i386 > needs a similar fix in kgdb. Not sure about other architectures: > > Index: trgt_amd64.c > =================================================================== > --- trgt_amd64.c (revision 220190) > +++ trgt_amd64.c (working copy) > @@ -184,6 +184,7 @@ > if (pname == NULL) > return (NULL); > if (strcmp(pname, "calltrap") == 0 || > + strcmp(pname, "fork_trampoline") == 0 || > strcmp(pname, "nmi_calltrap") == 0 || > (pname[0] == 'X'&& pname[1] != '_')) > return (&kgdb_trgt_trapframe_unwind); > Index: trgt_i386.c > =================================================================== > --- trgt_i386.c (revision 220190) > +++ trgt_i386.c (working copy) > @@ -374,6 +374,7 @@ > if (strcmp(pname, "dblfault_handler") == 0) > return (&kgdb_trgt_dblfault_unwind); > if (strcmp(pname, "calltrap") == 0 || > + strcmp(pname, "fork_trampoline") == 0 || > (pname[0] == 'X'&& pname[1] != '_')) > return (&kgdb_trgt_trapframe_unwind); > /* printf("%s: %llx =%s\n", __func__, pc, pname); */ > From owner-freebsd-current@FreeBSD.ORG Wed Apr 6 17:21:05 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 360D81065674 for ; Wed, 6 Apr 2011 17:21:05 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id E25658FC1F for ; Wed, 6 Apr 2011 17:21:04 +0000 (UTC) Received: by ywf9 with SMTP id 9so752180ywf.13 for ; Wed, 06 Apr 2011 10:21:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2mefYI23DOumE277csOXse/4eVXdZUAhD8mTuqOJf7Y=; b=ihKjXch+3lv3yH0gTgZ0mIiLIU333SzTE/q1DtEcEF1Rmzd/2icQwP37HjH8gIXRnI JepIbN79R2uCzj3uOESw4ome9MMcpZH40lkqOxFHjpm44K3SZaBRUOC3KdUdf02vyKOP P5UllGEaufmc45J0mAmXXZ+kQpwz9Hn5aakvA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=k3IkDLnsxdqmhXePLKsRZEEeqtq/ZtI2xmWnsUweajdtwG7VNnkrEk28BnMsMqi8KZ olzo2jnj/nm44TaSfr4dIBZoJHnlddqHzirRJQXxIK4vTfoz30AfZPztv9Vu1jSLQz7+ VTBqBS9QZ8WGZbZLQbeetnL03cl0IBmKlMfAQ= MIME-Version: 1.0 Received: by 10.236.136.130 with SMTP id w2mr1372534yhi.141.1302110464163; Wed, 06 Apr 2011 10:21:04 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.236.103.34 with HTTP; Wed, 6 Apr 2011 10:21:04 -0700 (PDT) In-Reply-To: References: <201104060836.56542.jhb@freebsd.org> Date: Wed, 6 Apr 2011 13:21:04 -0400 X-Google-Sender-Auth: XFRki6VuQdvCaAXdHDYPHZwT1Zk Message-ID: From: Attilio Rao To: Ryan Stone Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: sched_4bsd startup crash trying to run a bound thread on an AP that hasn't started X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 17:21:05 -0000 2011/4/6 Ryan Stone : > On Wed, Apr 6, 2011 at 8:36 AM, John Baldwin wrote: >> Hummm. =C2=A0Patching 4BSD to use the same route as ULE may be the best = solution >> for now if that is easiest. =C2=A0Alternatively, you could change 4BSD's >> sched_add() to not try to kick other CPUs until smp_started is true. > > At first I thought that it was a consequence of the way it does CPU > affinity, but now I see that it shortcuts if smp_started is not true. > How about something like the following for 4BSD? > > --- sched_4bsd.c =C2=A0 =C2=A0 =C2=A0 =C2=A0(revision 220222) > +++ sched_4bsd.c =C2=A0 =C2=A0 =C2=A0 =C2=A0(working copy) > @@ -1242,14 +1242,14 @@ > =C2=A0 =C2=A0 =C2=A0 =C2=A0} > =C2=A0 =C2=A0 =C2=A0 =C2=A0TD_SET_RUNQ(td); > > - =C2=A0 =C2=A0 =C2=A0 if (td->td_pinned !=3D 0) { > + =C2=A0 =C2=A0 =C2=A0 if (smp_started && td->td_pinned !=3D 0) { > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cpu =3D td->td_las= tcpu; > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ts->ts_runq =3D &r= unq_pcpu[cpu]; > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0single_cpu =3D 1; > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CTR3(KTR_RUNQ, > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"sch= ed_add: Put td_sched:%p(td:%p) on cpu%d runq", ts, td, > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cpu)= ; > - =C2=A0 =C2=A0 =C2=A0 } else if (td->td_flags & TDF_BOUND) { > + =C2=A0 =C2=A0 =C2=A0 } else if (smp_started && (td->td_flags & TDF_BOUN= D)) { > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* Find CPU from b= ound runq. */ > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0KASSERT(SKE_RUNQ_P= CPU(ts), > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0("sc= hed_add: bound td_sched not on cpu runq")); > @@ -1258,7 +1258,7 @@ > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CTR3(KTR_RUNQ, > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"sch= ed_add: Put td_sched:%p(td:%p) on cpu%d runq", ts, td, > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cpu)= ; > - =C2=A0 =C2=A0 =C2=A0 } else if (ts->ts_flags & TSF_AFFINITY) { > + =C2=A0 =C2=A0 =C2=A0 } else if (smp_started && (ts->ts_flags & TSF_AFFI= NITY)) { > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* Find a valid CP= U for our cpuset */ > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cpu =3D sched_pick= cpu(td); > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ts->ts_runq =3D &r= unq_pcpu[cpu]; > > The flow control is a bit awkward because of the multiple > affinity/bound cpu cases. =C2=A0If somebody prefers the code to be > structured differently I'd be open to suggestions. That is more or less what ULE does -- in ULE it is simpler because it goes via sched_pickcpu(), which still returns always CPU0 if APs still didn't kick off. I would also add a comment on top explaining the check, eventually, but otherwise looks fine. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Wed Apr 6 17:47:58 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03A991065782 for ; Wed, 6 Apr 2011 17:47:58 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 87AB28FC1C for ; Wed, 6 Apr 2011 17:47:56 +0000 (UTC) Received: by wwc33 with SMTP id 33so2019945wwc.31 for ; Wed, 06 Apr 2011 10:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=WWwCSa0YwHI7IDGQWVyJhK3CnZc7dkFaU0wuiiOQngk=; b=VR4dC+e/d95KrHL1ul6oGlkBKVwCDjpzjuTybpbdw4QtFNfynZE1sgtE6/2OEXogyF rc3jeLpy3LJ+xa9koxY2NaTRY+mWd9AZvS/kd/OAanbkgw42sBmFohocT4siQSvACkSP hkN1NrcdC8U4BzsTtRhdqhnk+kvXFSTcX9hjc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=XKUIBL5H+c4gdlJ2bPhq2FyLmdpRzu9jJzTkMoK78sPQs3x/Sc/ekG9zwT7TjdGroG 028P6W7j7GlvpEEH6X85MaxpAGv7SI0LpDkFcoDMXVbxdhwnZ9hxu2QPzXE/hlsPs+YZ F0FtVGMspbpiwwSVV1mnFA3VH+OciBCtP6AuQ= Received: by 10.216.241.4 with SMTP id f4mr1382879wer.42.1302112076053; Wed, 06 Apr 2011 10:47:56 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id k76sm415769wej.19.2011.04.06.10.47.54 (version=SSLv3 cipher=OTHER); Wed, 06 Apr 2011 10:47:55 -0700 (PDT) Sender: Alexander Motin Message-ID: <4D9CA746.6000606@FreeBSD.org> Date: Wed, 06 Apr 2011 20:47:50 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: John Baldwin References: <20110331223339.GA13682@freebsd.org> <201104010843.47367.jhb@freebsd.org> <20110404204316.GA11367@freebsd.org> <201104041719.33844.jhb@freebsd.org> In-Reply-To: <201104041719.33844.jhb@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Best , freebsd-current@freebsd.org Subject: Re: multiple issues with devstat_*(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 17:47:58 -0000 John Baldwin wrote: > On Monday, April 04, 2011 4:43:16 pm Alexander Best wrote: >> On Fri Apr 1 11, John Baldwin wrote: >>> This is probably due to the hard drives being IDE (really ATA) rather than >>> SCSI. I agree this should show the pass devices. >> hmmmm...one could argue. the drives are ATA, however they are being associated >> to the CAM subsystem. depends what one considers under "scsi interface". >> personally i'd like to see them inder "scsi". > > No, SCSI is a transport protocol. Alexandar Motin's work added a new > transport layer that speaks ATA and that is what ada uses. CAM does not > send SCSI commands to adaX devices AFAIK. Generally right, but to be complete: CAM differentiates types at transport and protocol layers. At the protocol layer there are SCSI and ATA protocols (used by da and ada drivers respectively, for example). At the transport layer there never was such thing as "SCSI", there are: SPI, FC, SAS, PPB, USB (several protocols), iSCSI, etc. All of them can handle SCSI commands. Newly added ATA and SATA transports handle both ATA and SCSI commands: ATA -- always, SCSI -- optionally, using ATAPI extension. >>>> otaku% iostat -t ide >>>> tty cpu >>>> tin tout us ni sy in id >>>> 1 92 5 0 4 0 90 >>>> otaku% iostat -t other >>>> tty cpu >>>> tin tout us ni sy in id >>>> 1 92 5 0 4 0 90 >>>> >>>> ...what about md0? ada0? ada1? md0? >>> md0 is a memory disk, it is neither SCSI nor IDE. However, -t ide (or even >>> better, a -t ata), should show all of your other devices (adaX and cd0) along >>> with their passX devices I think. >> so md0 should show up under -t other. i don't think there's a -t ata. > > Yes, I think we should possibly add a -t ata, possibly as an alias for > -t ide. Have no objections, but I would like to clarify what exactly that option should mean. It is simple for cases of SATA and SAS disks -- first is IDE/ATA (ATA/SATA), second is SCSI (SCSI/SAS). But it becomes tricky for ATA/SATA CD/DVD, ZIP/MO, tape drives - they use SCSI protocol commands, but ATA/SATA transport. As result, while adaX devices are definitely IDE (ATA) from any point of view; cdX, daX, saX, etc. can use any transport. So should they be reported as SCSI, respecting command protocol, or IDE (ATA), respecting transport? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Apr 6 18:31:58 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2174106566C for ; Wed, 6 Apr 2011 18:31:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7CC748FC08 for ; Wed, 6 Apr 2011 18:31:58 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0ED5E46B60; Wed, 6 Apr 2011 14:31:58 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 88DE78A01B; Wed, 6 Apr 2011 14:31:57 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 6 Apr 2011 14:29:49 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <201104060836.56542.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201104061429.50185.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 06 Apr 2011 14:31:57 -0400 (EDT) Cc: Ryan Stone Subject: Re: sched_4bsd startup crash trying to run a bound thread on an AP that hasn't started X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 18:31:58 -0000 On Wednesday, April 06, 2011 1:08:20 pm Ryan Stone wrote: > On Wed, Apr 6, 2011 at 8:36 AM, John Baldwin wrote: > > Hummm. Patching 4BSD to use the same route as ULE may be the best solution > > for now if that is easiest. Alternatively, you could change 4BSD's > > sched_add() to not try to kick other CPUs until smp_started is true. > > At first I thought that it was a consequence of the way it does CPU > affinity, but now I see that it shortcuts if smp_started is not true. > How about something like the following for 4BSD? > > --- sched_4bsd.c (revision 220222) > +++ sched_4bsd.c (working copy) > @@ -1242,14 +1242,14 @@ > } > TD_SET_RUNQ(td); > > - if (td->td_pinned != 0) { > + if (smp_started && td->td_pinned != 0) { > cpu = td->td_lastcpu; > ts->ts_runq = &runq_pcpu[cpu]; > single_cpu = 1; > CTR3(KTR_RUNQ, > "sched_add: Put td_sched:%p(td:%p) on cpu%d runq", ts, td, > cpu); > - } else if (td->td_flags & TDF_BOUND) { > + } else if (smp_started && (td->td_flags & TDF_BOUND)) { > /* Find CPU from bound runq. */ > KASSERT(SKE_RUNQ_PCPU(ts), > ("sched_add: bound td_sched not on cpu runq")); > @@ -1258,7 +1258,7 @@ > CTR3(KTR_RUNQ, > "sched_add: Put td_sched:%p(td:%p) on cpu%d runq", ts, td, > cpu); > - } else if (ts->ts_flags & TSF_AFFINITY) { > + } else if (smp_started && (ts->ts_flags & TSF_AFFINITY)) { > /* Find a valid CPU for our cpuset */ > cpu = sched_pickcpu(td); > ts->ts_runq = &runq_pcpu[cpu]; > > The flow control is a bit awkward because of the multiple > affinity/bound cpu cases. If somebody prefers the code to be > structured differently I'd be open to suggestions. Maybe it could do this: if (!smp_started) { cpu = NOCPU; ts->runq = &runq; } else if (td->td_pinned) { ... That would be a smaller patch and I think more obvious to the reader even though it duplicates the global runq selection. I would even be ok with a goto for this case that if !smp_started it just jumps to the global runq bit in the last else. I guess one other option would be something like this: if (smp_started && (td->td_pinned != 0 || td->td_flags & TDF_BOUND || ts->ts_flags & TSF_AFFINITY)) { if (td->td_pinned != 0) cpu = td->td_lastcpu; else if (td->td_flags & TDF_BOUND) { /* Find CPU from bound runq. */ KASSERT(...); cpu = ts->ts_runq - &runq_pcpu[0]; } else /* Find a valid CPU for our cpuset. */ cpu = sched_pickcpu(td); ts->ts_runq = &runq_pcpu[cpu]; single_cpu = 1; CTR3(KTR_RUNQ, ...); } else { /* Global runq case. */ } This also avoids duplicating some common code to all the single_cpu cases. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Apr 6 19:31:26 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98537106566C; Wed, 6 Apr 2011 19:31:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 31D238FC14; Wed, 6 Apr 2011 19:31:25 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p36JVMZC087523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Apr 2011 22:31:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p36JVMGq089422; Wed, 6 Apr 2011 22:31:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p36JVMQd089421; Wed, 6 Apr 2011 22:31:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 6 Apr 2011 22:31:22 +0300 From: Kostik Belousov To: Julian Elischer Message-ID: <20110406193122.GI78089@deviant.kiev.zoral.com.ua> References: <4D9BBED1.3070402@freebsd.org> <20110406102143.GG78089@deviant.kiev.zoral.com.ua> <4D9C9F6D.4030503@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BKnPblWxbRpCNYlk" Content-Disposition: inline In-Reply-To: <4D9C9F6D.4030503@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_20, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: FreeBSD Current Subject: Re: kernel thread creation cleanup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 19:31:26 -0000 --BKnPblWxbRpCNYlk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 06, 2011 at 10:14:21AM -0700, Julian Elischer wrote: > On 4/6/11 3:21 AM, Kostik Belousov wrote: > >On Tue, Apr 05, 2011 at 06:16:01PM -0700, Julian Elischer wrote: > >>I was just looking in the thread creation code after most of a decade > >>NOT looking at it.. > >>boy we really need to go through there with a broom.. the cobwebs are > >>getting thick. > >>Like we always call the code to put an upcall, even though we don't > >>have upcalls any more, > >cpu_set_upcall() probably could be renamed to cpu_init_thread(), > >and cpu_set_upcall_kse() is better named cpu_init_thread_for_user(). >=20 > yeah, we should have changed the names when they got the new jobs. > (when KSE went away) > >IMO, rename would only add a code churn. > >>and we always create an trap frame on the stack even when we are > >>making kernel threads > >>that don't need it, actually, come to think of it DOES fork even need > >>it? (need to go look) > >Trap frame for the new thread that is going to usermode after fork is > >definitely needed. Having fork trampoline executed for all threads is > >good, because it provides a convenient single point which is passed by > >all new threads. >=20 > One thing the current code does is puts a trap frame on hte stack,=20 > whether you will need it or not. > the result of that is that the trap frame is the next thing on the=20 > stack after fork_exit on the stack so that if you return > from fork_exit you hit the frame (which is not set up to work) if you=20 > are creating a new kthread. > not that you SHOULD return of course... > anyhow it's a waste of 192 bytes of stack.. >=20 > For normal fork/thread_create I guess the frame tries to return to=20 > userland, and is needed. The change would require a serious review. I am not quite sure that assumption of existence of trap frame is not engraved in some piece of MD code. >=20 > >>and we go through the fork trampoline even when we are doing kthread > >>creation and could just as well go > >>directly to the final function directly. (All of the above on amd64).. > >>May be slighly different on other hardware, though much of it is > >>encoded in MI code so probably not. > >> > >> > >> > >>This came from looking to see if I could somehow munge the stack to > >>convince kgdb to damn well stop at > >>that point (still failed. if anyone has ideas... :-) > >Was it for amd64 ? I think the issue with kgdb is lack of the proper > >dwarf annotations for trampoline. >=20 > It's possible some sort of anotation woudl stop the stack when > it saw that return address, but one would think there was some other=20 > way too.. > it even carries on with a 0 %rbp which is bogus. Yes, because it relies on unwind tables. --BKnPblWxbRpCNYlk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2cv4oACgkQC3+MBN1Mb4gXiwCgr4ypxH5s99z65Xmb4tevHhkB L7gAn1qH+BwkLKa5uaKm5NMwJROI9cdj =r+Hg -----END PGP SIGNATURE----- --BKnPblWxbRpCNYlk-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 6 20:31:24 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E560106566B; Wed, 6 Apr 2011 20:31:24 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 23FE98FC12; Wed, 6 Apr 2011 20:31:23 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p36KVLTA065397 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 6 Apr 2011 13:31:22 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4D9CCDB7.3000605@freebsd.org> Date: Wed, 06 Apr 2011 13:31:51 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: John Baldwin References: <4D9A4CE5.5090900@freebsd.org> <4D9B7C92.6030901@freebsd.org> <201104060845.11771.jhb@freebsd.org> <4D9CA00C.20307@freebsd.org> In-Reply-To: <4D9CA00C.20307@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Justin Hibbits , Navdeep Parhar , FreeBSD Current Subject: Re: KGDB stack traces in the kernel. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 20:31:24 -0000 On 4/6/11 10:17 AM, Julian Elischer wrote: > On 4/6/11 5:45 AM, John Baldwin wrote: >> On Tuesday, April 05, 2011 4:35:44 pm Navdeep Parhar wrote: >>> On Tue, Apr 5, 2011 at 1:33 PM, Julian >>> Elischer wrote: >>>> On 4/4/11 6:04 PM, Justin Hibbits wrote: >>>> >>> What does ddb do? It always seems to get this stuff correct. >> ddb knows to stop when it gets to a non-kernel address, and it uses >> string >> compares on function names to identify trap frames. For example in >> sys/amd64/amd64/db_trace.c: >> >> >> if (strcmp(name, "calltrap") == 0 || >> strcmp(name, "fork_trampoline") == 0 || >> strcmp(name, "nmi_calltrap") == 0 || >> strcmp(name, "Xdblfault") == 0) >> frame_type = TRAP; >> >> Hah, kgdb just needs to be updated (this is from trgt_amd64.c): >> >> const struct frame_unwind * >> kgdb_trgt_trapframe_sniffer(struct frame_info *next_frame) >> { >> char *pname; >> CORE_ADDR pc; >> >> pc = frame_pc_unwind(next_frame); >> pname = NULL; >> find_pc_partial_function(pc,&pname, NULL, NULL); >> if (pname == NULL) >> return (NULL); >> if (strcmp(pname, "calltrap") == 0 || >> strcmp(pname, "nmi_calltrap") == 0 || >> (pname[0] == 'X'&& pname[1] != '_')) >> return (&kgdb_trgt_trapframe_unwind); >> /* printf("%s: %lx =%s\n", __func__, pc, pname); */ >> return (NULL); >> } >> > > I'll give that a try > >> Can probably just add 'fork_trampoline' to that conditional. I >> think i386 >> needs a similar fix in kgdb. Not sure about other architectures: >> >> Index: trgt_amd64.c >> =================================================================== >> --- trgt_amd64.c (revision 220190) >> +++ trgt_amd64.c (working copy) >> @@ -184,6 +184,7 @@ >> if (pname == NULL) >> return (NULL); >> if (strcmp(pname, "calltrap") == 0 || >> + strcmp(pname, "fork_trampoline") == 0 || BTW this is in 8.x I don't have 9 on a machine I can test this with. While ddb finds fork_trampoline, (k)gdb does not. so I had to add fork_exit a well, but then it gets an error as well. firstly without fork_exit() #0 0xffffffff8144c529 in XXXXXXXX () from blah.ko #1 0xffffffff814dfea5 in XXXXXXXX () from blah.ko #2 0xffffff0063a1f600 in ?? () #3 0xffffffff814dfe30 in XXXXXXXX () from blah.ko #4 0xffffff0063a265f0 in ?? () #5 0xffffff8244290c30 in ?? () #6 0xffffffff805c4b8e in fork_exit (callout=0xffffffff814dfe30 , arg=0x89e475f700000000, frame=0xbad089e445890000) at ../../../kern/kern_fork.c:859 #7 0xf445c7a07d894868 in ?? () #8 0x095d77e800000000 in ?? () #9 0x00095c40e8c78900 in ?? () #10 0x000001bfd8458948 in ?? () [... etc forever] if I add for_exit, it does work but: #6 0xffffff82441c8c30 in ?? () #7 0xffffffff805c4b8e in fork_exit (callout=0xffffffff814dfe30 , arg=0x89e475f700000000, frame=0xbad089e445890000) at ../../../kern/kern_fork.c:859 Previous frame identical to this frame (corrupt stack?) that last error message makes ddd throw up its hands and get confused. it seems to occur all the time however. for example when you use sysctl debug.kdb.enter to enter the debugger, the same thing occurs: this easy to see. #0 kdb_enter (why=0xffffffff80a3494c "sysctl", msg=0xa
) at ../../../kern/subr_kdb.c:352 #1 0xffffffff80626bc9 in kdb_sysctl_enter (oidp=0xffffffff80c6c360, arg1=Variable "arg1" is not available. ) at ../../../kern/subr_kdb.c:174 #2 0xffffffff805fddc3 in sysctl_root (oidp=Variable "oidp" is not available. ) at ../../../kern/kern_sysctl.c:1420 #3 0xffffffff805fe00e in userland_sysctl (td=0xffffff0009a7c000, name=0xffffff824433fa20, namelen=3, old=0x0, oldlenp=Variable "oldlenp" is not available. ) at ../../../kern/kern_sysctl.c:1524 #4 0xffffffff805fe4ba in __sysctl (td=0xffffff0009a7c000, uap=0xffffff824433fbb0) at ../../../kern/kern_sysctl.c:1450 #5 0xffffffff8063429f in syscallenter (td=0xffffff0009a7c000, sa=0xffffff824433fba0) at ../../../kern/subr_trap.c:315 #6 0xffffffff808feafc in syscall (frame=0xffffff824433fc40) at ../../../amd64/amd64/trap.c:888 #7 0xffffffff808e6092 in Xfast_syscall () at ../../../amd64/amd64/exception.S:377 #8 0x000000080073db0c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) do you have any idea what that is all about? looking at frames 7,8,6 I see: Previous frame inner to this frame (corrupt stack?) (kgdb) up 7 #7 0xffffffff808e6092 in Xfast_syscall () at ../../../amd64/amd64/exception.S:377 377 call syscall Current language: auto; currently asm (kgdb) info frame Stack level 7, frame at 0xffffff824433fc40: rip = 0xffffffff808e6092 in Xfast_syscall (../../../amd64/amd64/exception.S:377); saved rip 0x80073db0c called by frame at 0x7fffffffe190, caller of frame at 0xffffff824433fc40 source language asm. Arglist at 0xffffff824433fc38, args: Locals at 0xffffff824433fc38, Previous frame's sp at 0xffffff824433fcf0 Saved registers: rax at 0xffffff824433fc70, rbx at 0xffffff824433fc78, rcx at 0xffffff824433fc58, rdx at 0xffffff824433fc50, rsi at 0xffffff824433fc48, rdi at 0xffffff824433fc40, rbp at 0xffffff824433fc80, r8 at 0xffffff824433fc60, r9 at 0xffffff824433fc68, r10 at 0xffffff824433fc88, r11 at 0xffffff824433fc90, r12 at 0xffffff824433fc98, r13 at 0xffffff824433fca0, r14 at 0xffffff824433fca8, r15 at 0xffffff824433fcb0, rip at 0xffffff824433fcd8, eflags at 0xffffff824433fce8, cs at 0xffffff824433fce0, ss at 0xffffff824433fcf8 (kgdb) up #8 0x000000080073db0c in ?? () (kgdb) info frame Stack level 8, frame at 0x7fffffffe190: rip = 0x80073db0c; saved rip 0x4023a5 caller of frame at 0xffffff824433fc40 Arglist at 0x7fffffffe180, args: Locals at 0x7fffffffe180, Previous frame's sp is 0x7fffffffe190 Saved registers: rax at 0xffffff824433fc70, rbx at 0xffffff824433fc78, rcx at 0xffffff824433fc58, rdx at 0xffffff824433fc50, rsi at 0xffffff824433fc48, rdi at 0xffffff824433fc40, rbp at 0xffffff824433fc80, r8 at 0xffffff824433fc60, r9 at 0xffffff824433fc68, r10 at 0xffffff824433fc88, r11 at 0xffffff824433fc90, r12 at 0xffffff824433fc98, r13 at 0xffffff824433fca0, r14 at 0xffffff824433fca8, r15 at 0xffffff824433fcb0, rip at 0x7fffffffe188, eflags at 0xffffff824433fce8, cs at 0xffffff824433fce0, ss at 0xffffff824433fcf8 (kgdb) down #7 0xffffffff808e6092 in Xfast_syscall () at ../../../amd64/amd64/exception.S:377 377 call syscall (kgdb) down #6 0xffffffff808feafc in syscall (frame=0xffffff824433fc40) at ../../../amd64/amd64/trap.c:888 888 error = syscallenter(td, &sa); Current language: auto; currently c (kgdb) info frame Stack level 6, frame at 0xffffff824433fc40: rip = 0xffffffff808feafc in syscall (../../../amd64/amd64/trap.c:888); saved rip 0xffffffff808e6092 called by frame at 0xffffff824433fc40, caller of frame at 0xffffff824433fb30 source language c. Arglist at 0xffffff824433fc30, args: frame=0xffffff824433fc40 Locals at 0xffffff824433fc30, Previous frame's sp is 0xffffff824433fc40 Saved registers: rbx at 0xffffff824433fc08, rbp at 0xffffff824433fc30, r12 at 0xffffff824433fc10, r13 at 0xffffff824433fc18, r14 at 0xffffff824433fc20, r15 at 0xffffff824433fc28, rip at 0xffffff824433fc38 (kgdb) >> strcmp(pname, "nmi_calltrap") == 0 || >> (pname[0] == 'X'&& pname[1] != '_')) >> return (&kgdb_trgt_trapframe_unwind); >> Index: trgt_i386.c >> =================================================================== >> --- trgt_i386.c (revision 220190) >> +++ trgt_i386.c (working copy) >> @@ -374,6 +374,7 @@ >> if (strcmp(pname, "dblfault_handler") == 0) >> return (&kgdb_trgt_dblfault_unwind); >> if (strcmp(pname, "calltrap") == 0 || >> + strcmp(pname, "fork_trampoline") == 0 || >> (pname[0] == 'X'&& pname[1] != '_')) >> return (&kgdb_trgt_trapframe_unwind); >> /* printf("%s: %llx =%s\n", __func__, pc, pname); */ >> > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Wed Apr 6 20:31:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E560106566B; Wed, 6 Apr 2011 20:31:24 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 23FE98FC12; Wed, 6 Apr 2011 20:31:23 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p36KVLTA065397 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 6 Apr 2011 13:31:22 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4D9CCDB7.3000605@freebsd.org> Date: Wed, 06 Apr 2011 13:31:51 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: John Baldwin References: <4D9A4CE5.5090900@freebsd.org> <4D9B7C92.6030901@freebsd.org> <201104060845.11771.jhb@freebsd.org> <4D9CA00C.20307@freebsd.org> In-Reply-To: <4D9CA00C.20307@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Justin Hibbits , Navdeep Parhar , FreeBSD Current Subject: Re: KGDB stack traces in the kernel. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 20:31:24 -0000 On 4/6/11 10:17 AM, Julian Elischer wrote: > On 4/6/11 5:45 AM, John Baldwin wrote: >> On Tuesday, April 05, 2011 4:35:44 pm Navdeep Parhar wrote: >>> On Tue, Apr 5, 2011 at 1:33 PM, Julian >>> Elischer wrote: >>>> On 4/4/11 6:04 PM, Justin Hibbits wrote: >>>> >>> What does ddb do? It always seems to get this stuff correct. >> ddb knows to stop when it gets to a non-kernel address, and it uses >> string >> compares on function names to identify trap frames. For example in >> sys/amd64/amd64/db_trace.c: >> >> >> if (strcmp(name, "calltrap") == 0 || >> strcmp(name, "fork_trampoline") == 0 || >> strcmp(name, "nmi_calltrap") == 0 || >> strcmp(name, "Xdblfault") == 0) >> frame_type = TRAP; >> >> Hah, kgdb just needs to be updated (this is from trgt_amd64.c): >> >> const struct frame_unwind * >> kgdb_trgt_trapframe_sniffer(struct frame_info *next_frame) >> { >> char *pname; >> CORE_ADDR pc; >> >> pc = frame_pc_unwind(next_frame); >> pname = NULL; >> find_pc_partial_function(pc,&pname, NULL, NULL); >> if (pname == NULL) >> return (NULL); >> if (strcmp(pname, "calltrap") == 0 || >> strcmp(pname, "nmi_calltrap") == 0 || >> (pname[0] == 'X'&& pname[1] != '_')) >> return (&kgdb_trgt_trapframe_unwind); >> /* printf("%s: %lx =%s\n", __func__, pc, pname); */ >> return (NULL); >> } >> > > I'll give that a try > >> Can probably just add 'fork_trampoline' to that conditional. I >> think i386 >> needs a similar fix in kgdb. Not sure about other architectures: >> >> Index: trgt_amd64.c >> =================================================================== >> --- trgt_amd64.c (revision 220190) >> +++ trgt_amd64.c (working copy) >> @@ -184,6 +184,7 @@ >> if (pname == NULL) >> return (NULL); >> if (strcmp(pname, "calltrap") == 0 || >> + strcmp(pname, "fork_trampoline") == 0 || BTW this is in 8.x I don't have 9 on a machine I can test this with. While ddb finds fork_trampoline, (k)gdb does not. so I had to add fork_exit a well, but then it gets an error as well. firstly without fork_exit() #0 0xffffffff8144c529 in XXXXXXXX () from blah.ko #1 0xffffffff814dfea5 in XXXXXXXX () from blah.ko #2 0xffffff0063a1f600 in ?? () #3 0xffffffff814dfe30 in XXXXXXXX () from blah.ko #4 0xffffff0063a265f0 in ?? () #5 0xffffff8244290c30 in ?? () #6 0xffffffff805c4b8e in fork_exit (callout=0xffffffff814dfe30 , arg=0x89e475f700000000, frame=0xbad089e445890000) at ../../../kern/kern_fork.c:859 #7 0xf445c7a07d894868 in ?? () #8 0x095d77e800000000 in ?? () #9 0x00095c40e8c78900 in ?? () #10 0x000001bfd8458948 in ?? () [... etc forever] if I add for_exit, it does work but: #6 0xffffff82441c8c30 in ?? () #7 0xffffffff805c4b8e in fork_exit (callout=0xffffffff814dfe30 , arg=0x89e475f700000000, frame=0xbad089e445890000) at ../../../kern/kern_fork.c:859 Previous frame identical to this frame (corrupt stack?) that last error message makes ddd throw up its hands and get confused. it seems to occur all the time however. for example when you use sysctl debug.kdb.enter to enter the debugger, the same thing occurs: this easy to see. #0 kdb_enter (why=0xffffffff80a3494c "sysctl", msg=0xa
) at ../../../kern/subr_kdb.c:352 #1 0xffffffff80626bc9 in kdb_sysctl_enter (oidp=0xffffffff80c6c360, arg1=Variable "arg1" is not available. ) at ../../../kern/subr_kdb.c:174 #2 0xffffffff805fddc3 in sysctl_root (oidp=Variable "oidp" is not available. ) at ../../../kern/kern_sysctl.c:1420 #3 0xffffffff805fe00e in userland_sysctl (td=0xffffff0009a7c000, name=0xffffff824433fa20, namelen=3, old=0x0, oldlenp=Variable "oldlenp" is not available. ) at ../../../kern/kern_sysctl.c:1524 #4 0xffffffff805fe4ba in __sysctl (td=0xffffff0009a7c000, uap=0xffffff824433fbb0) at ../../../kern/kern_sysctl.c:1450 #5 0xffffffff8063429f in syscallenter (td=0xffffff0009a7c000, sa=0xffffff824433fba0) at ../../../kern/subr_trap.c:315 #6 0xffffffff808feafc in syscall (frame=0xffffff824433fc40) at ../../../amd64/amd64/trap.c:888 #7 0xffffffff808e6092 in Xfast_syscall () at ../../../amd64/amd64/exception.S:377 #8 0x000000080073db0c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) do you have any idea what that is all about? looking at frames 7,8,6 I see: Previous frame inner to this frame (corrupt stack?) (kgdb) up 7 #7 0xffffffff808e6092 in Xfast_syscall () at ../../../amd64/amd64/exception.S:377 377 call syscall Current language: auto; currently asm (kgdb) info frame Stack level 7, frame at 0xffffff824433fc40: rip = 0xffffffff808e6092 in Xfast_syscall (../../../amd64/amd64/exception.S:377); saved rip 0x80073db0c called by frame at 0x7fffffffe190, caller of frame at 0xffffff824433fc40 source language asm. Arglist at 0xffffff824433fc38, args: Locals at 0xffffff824433fc38, Previous frame's sp at 0xffffff824433fcf0 Saved registers: rax at 0xffffff824433fc70, rbx at 0xffffff824433fc78, rcx at 0xffffff824433fc58, rdx at 0xffffff824433fc50, rsi at 0xffffff824433fc48, rdi at 0xffffff824433fc40, rbp at 0xffffff824433fc80, r8 at 0xffffff824433fc60, r9 at 0xffffff824433fc68, r10 at 0xffffff824433fc88, r11 at 0xffffff824433fc90, r12 at 0xffffff824433fc98, r13 at 0xffffff824433fca0, r14 at 0xffffff824433fca8, r15 at 0xffffff824433fcb0, rip at 0xffffff824433fcd8, eflags at 0xffffff824433fce8, cs at 0xffffff824433fce0, ss at 0xffffff824433fcf8 (kgdb) up #8 0x000000080073db0c in ?? () (kgdb) info frame Stack level 8, frame at 0x7fffffffe190: rip = 0x80073db0c; saved rip 0x4023a5 caller of frame at 0xffffff824433fc40 Arglist at 0x7fffffffe180, args: Locals at 0x7fffffffe180, Previous frame's sp is 0x7fffffffe190 Saved registers: rax at 0xffffff824433fc70, rbx at 0xffffff824433fc78, rcx at 0xffffff824433fc58, rdx at 0xffffff824433fc50, rsi at 0xffffff824433fc48, rdi at 0xffffff824433fc40, rbp at 0xffffff824433fc80, r8 at 0xffffff824433fc60, r9 at 0xffffff824433fc68, r10 at 0xffffff824433fc88, r11 at 0xffffff824433fc90, r12 at 0xffffff824433fc98, r13 at 0xffffff824433fca0, r14 at 0xffffff824433fca8, r15 at 0xffffff824433fcb0, rip at 0x7fffffffe188, eflags at 0xffffff824433fce8, cs at 0xffffff824433fce0, ss at 0xffffff824433fcf8 (kgdb) down #7 0xffffffff808e6092 in Xfast_syscall () at ../../../amd64/amd64/exception.S:377 377 call syscall (kgdb) down #6 0xffffffff808feafc in syscall (frame=0xffffff824433fc40) at ../../../amd64/amd64/trap.c:888 888 error = syscallenter(td, &sa); Current language: auto; currently c (kgdb) info frame Stack level 6, frame at 0xffffff824433fc40: rip = 0xffffffff808feafc in syscall (../../../amd64/amd64/trap.c:888); saved rip 0xffffffff808e6092 called by frame at 0xffffff824433fc40, caller of frame at 0xffffff824433fb30 source language c. Arglist at 0xffffff824433fc30, args: frame=0xffffff824433fc40 Locals at 0xffffff824433fc30, Previous frame's sp is 0xffffff824433fc40 Saved registers: rbx at 0xffffff824433fc08, rbp at 0xffffff824433fc30, r12 at 0xffffff824433fc10, r13 at 0xffffff824433fc18, r14 at 0xffffff824433fc20, r15 at 0xffffff824433fc28, rip at 0xffffff824433fc38 (kgdb) >> strcmp(pname, "nmi_calltrap") == 0 || >> (pname[0] == 'X'&& pname[1] != '_')) >> return (&kgdb_trgt_trapframe_unwind); >> Index: trgt_i386.c >> =================================================================== >> --- trgt_i386.c (revision 220190) >> +++ trgt_i386.c (working copy) >> @@ -374,6 +374,7 @@ >> if (strcmp(pname, "dblfault_handler") == 0) >> return (&kgdb_trgt_dblfault_unwind); >> if (strcmp(pname, "calltrap") == 0 || >> + strcmp(pname, "fork_trampoline") == 0 || >> (pname[0] == 'X'&& pname[1] != '_')) >> return (&kgdb_trgt_trapframe_unwind); >> /* printf("%s: %llx =%s\n", __func__, pc, pname); */ >> > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Thu Apr 7 10:59:45 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0984F106564A; Thu, 7 Apr 2011 10:59:45 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 195E98FC0C; Thu, 7 Apr 2011 10:59:43 +0000 (UTC) Received: by fxm11 with SMTP id 11so1993450fxm.13 for ; Thu, 07 Apr 2011 03:59:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=HZvitxj++kmXh6EhYe3lrjeLmG/TEMqnTxEAmWbihdo=; b=NQrHVTOpFo7JipM9CPNWDwVtKgLju5RCibXMAFPNi+ZChnwDwdcFxlyxjuoXwcHZnz HVvCWJK9GxoLvS+oMJFbJMdqAST4pmyBDzVLWg0aW28RS6YOL7h4OTjQlrBtjOOL6KnO g8QWx72fCS9ACARqm5WvdQK16N4RSL77LhiDw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=eQ9KYLmYJOFAH1sVy00KJKdYLvAjXUpwDuO34xwho0imz2wLlhDKon/Qkr3siHRRAH 9rz2jxtU9N2yF9J+fIYL7yOaqKq45mHTZCXaIvvunHlvMkqBuCK8If54CbpBuStesguI 51mt8rvmqCPGW44XAf9+vBZu/4ei/l+JFzu7U= Received: by 10.223.14.207 with SMTP id h15mr723256faa.50.1302173982878; Thu, 07 Apr 2011 03:59:42 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id l4sm447370fan.38.2011.04.07.03.59.41 (version=SSLv3 cipher=OTHER); Thu, 07 Apr 2011 03:59:42 -0700 (PDT) Sender: Alexander Motin Message-ID: <4D9D9917.3030102@FreeBSD.org> Date: Thu, 07 Apr 2011 13:59:35 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Alexander Best References: <20110331223339.GA13682@freebsd.org> <201104010843.47367.jhb@freebsd.org> <20110404204316.GA11367@freebsd.org> In-Reply-To: <20110404204316.GA11367@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org Subject: Re: multiple issues with devstat_*(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 10:59:45 -0000 Alexander Best wrote: > On Fri Apr 1 11, John Baldwin wrote: >> On Thursday, March 31, 2011 6:33:39 pm Alexander Best wrote: >>> i think there are multiple issues with devstat. i found the following in >>> devicestat.h: ... >>> funny thing is i found the following in scsi_pass.c: >>> >>> softc->device_stats = devstat_new_entry("pass", >>> periph->unit_number, 0, >>> DEVSTAT_NO_BLOCKSIZE >>> | (no_tags ? DEVSTAT_NO_ORDERED_TAGS : 0), >>> softc->pd_type | >>> DEVSTAT_TYPE_IF_SCSI | >>> DEVSTAT_TYPE_PASS, >>> DEVSTAT_PRIORITY_PASS); >>> >>> ...so pass* *should* show up under iostat -t scsi. As I can see, this is a bug (or feature) of the libdevstat / devstat_selectdevs(). If you specify any -t, then pass devices will be reported only if you request "pass" specifically. >> Hmm, pass devices for adaX should not be SCSI though, they should be ide I >> think. > > i think the situation with ATA_CAM should be discussed further. still besides > this issue there are many more with devstat(3). > > i'll try to track all the "devstat_new_entry()" occurrences and see if some > issues can be fixed. maybe only the proper DEVSTAT_* args were forgotten. Assuming that SCSI and IDE in -t option means transport type, and assuming that we count everything except ATA and SATA as SCSI, I've made following patch, that should fix issues from the CAM side: http://people.freebsd.org/~mav/cam.devstat.patch Any objections? Or SCSI/IDE there expected to mean command set? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Apr 7 17:12:44 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62038106564A for ; Thu, 7 Apr 2011 17:12:44 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B02268FC13 for ; Thu, 7 Apr 2011 17:12:43 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA19960 for ; Thu, 07 Apr 2011 20:12:39 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4D9DF086.9020906@FreeBSD.org> Date: Thu, 07 Apr 2011 20:12:38 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110309 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: FreeBSD current X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: prefer tsc timecounter when it's good X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 17:12:44 -0000 Guys, what do you think about the following change? The idea is mark TSC as the best timecounter when it's invariant and synchronized between cores. Unfortunately I don't have code to auto-detect the synchronization and keep relying on the corresponding tunable. I thought about auto-setting it for single-package configurations, but even that information is currently not trivial to get out of our mp (i386/amd64) machdep code. --- a/sys/x86/x86/tsc.c +++ b/sys/x86/x86/tsc.c @@ -169,6 +169,9 @@ init_TSC_tc(void) printf("TSC timecounter disabled: APM enabled.\n"); } + if (tsc_is_invariant) + tsc_timecounter.tc_quality = 1200; + #ifdef SMP /* * We can not use the TSC in SMP mode unless the TSCs on all CPUs -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Apr 7 18:55:10 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id C8C941065672; Thu, 7 Apr 2011 18:55:10 +0000 (UTC) Date: Thu, 7 Apr 2011 18:55:10 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20110407185510.GA94830@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline Cc: freebsd-toolchain@freebsd.org Subject: [RFC] adding -Wmissing-include-dirs to CWARNFLAGS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 18:55:10 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi there, i'd like to propose adding -Wmissing-include-dirs to CWARNFLAGS. this will let tinderbox fail, if any new kernel code was committed with (a) broken include dir(s). i ran a test via make toolchains make MAKE_JUST_KERNELS=yes tinderbox and nothing seemed to go wrong with the extra warning enabled. i even found a missing include dir, which should be fixed by the attached patch. opinions? so far i've only tested this with gcc. i think someone on #freebsd-clang told me that -Wmissing-include-dirs is a noop for clang (for whatever reasons). cheers. alex -- a13x --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ccatm.diff" diff --git a/sys/modules/netgraph/atm/ccatm/Makefile b/sys/modules/netgraph/atm/ccatm/Makefile index 5626536..8bf741d 100644 --- a/sys/modules/netgraph/atm/ccatm/Makefile +++ b/sys/modules/netgraph/atm/ccatm/Makefile @@ -12,6 +12,6 @@ KMOD= ng_ccatm SRCS= ng_ccatm.c cc_conn.c cc_data.c cc_dump.c cc_port.c cc_sig.c \ cc_user.c unisap.c -CFLAGS+= -I${LIBBASE} -I${LIBBASE}/netnatm/ccatm -DCCATM_DEBUG +CFLAGS+= -I${LIBBASE} -DCCATM_DEBUG .include --r5Pyd7+fXNt84Ff3-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 7 18:59:25 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B918A106566B; Thu, 7 Apr 2011 18:59:25 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout028.mac.com (asmtpout028.mac.com [17.148.16.103]) by mx1.freebsd.org (Postfix) with ESMTP id A379E8FC0C; Thu, 7 Apr 2011 18:59:25 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp028.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LJA003RUN94ZG70@asmtp028.mac.com>; Thu, 07 Apr 2011 10:58:17 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-04-07_06:2011-04-07, 2011-04-07, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1104070093 From: Chuck Swiger In-reply-to: <4D9DF086.9020906@FreeBSD.org> Date: Thu, 07 Apr 2011 10:58:16 -0700 Message-id: <709EE35F-B124-4670-81BD-FBFE6121928B@mac.com> References: <4D9DF086.9020906@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1084) Cc: FreeBSD current Subject: Re: prefer tsc timecounter when it's good X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 18:59:25 -0000 Hi-- On Apr 7, 2011, at 10:12 AM, Andriy Gapon wrote: > what do you think about the following change? > The idea is mark TSC as the best timecounter when it's invariant and synchronized > between cores. > Unfortunately I don't have code to auto-detect the synchronization and keep > relying on the corresponding tunable. I thought about auto-setting it for > single-package configurations, but even that information is currently not trivial > to get out of our mp (i386/amd64) machdep code. In theory, most machines with P-state invariant TSCs should have their counters completely synchronized, even if there are multiple packages: http://software.intel.com/en-us/forums/showthread.php?t=74798 http://www.intel.com/Assets/PDF/manual/253668.pdf ...the exception would be very large machines with multiple mainboards. Regards, -- -Chuck From owner-freebsd-current@FreeBSD.ORG Thu Apr 7 20:00:32 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id B061D106566B; Thu, 7 Apr 2011 20:00:30 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Thu, 7 Apr 2011 16:00:11 -0400 User-Agent: KMail/1.6.2 References: <4D9DF086.9020906@FreeBSD.org> In-Reply-To: <4D9DF086.9020906@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201104071600.13586.jkim@FreeBSD.org> Cc: Andriy Gapon Subject: Re: prefer tsc timecounter when it's good X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 20:00:32 -0000 On Thursday 07 April 2011 01:12 pm, Andriy Gapon wrote: > Guys, > > what do you think about the following change? > The idea is mark TSC as the best timecounter when it's invariant > and synchronized between cores. Unfortunately I don't have code to > auto-detect the synchronization and keep relying on the > corresponding tunable. I know Intel is claiming that TSCs for all cores/packages reset to zero when they receive a "synchronous" INIT/RESET IPI. I haven't really verified their claim but I think it may be good enough for our AP startup code. However, AMD processors never had such guarantee, AFAIK. > I thought about auto-setting it for single-package configurations, > but even that information is currently not trivial to get out of our > mp (i386/amd64) machdep code. It isn't easy ATM. :-/ > --- a/sys/x86/x86/tsc.c > +++ b/sys/x86/x86/tsc.c > @@ -169,6 +169,9 @@ init_TSC_tc(void) > printf("TSC timecounter disabled: APM enabled.\n"); > } > > + if (tsc_is_invariant) > + tsc_timecounter.tc_quality = 1200; > + > #ifdef SMP > /* > * We can not use the TSC in SMP mode unless the TSCs on all CPUs Although it looks okay, please don't commit it just yet. I am working in this area actively. Also, if the Intel's claim is true, i.e., TSCs reset to zero when APs start, we cannot use TSC as a timecounter hardware until all APs are started properly. Thanks, Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Thu Apr 7 20:01:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 410081065673; Thu, 7 Apr 2011 20:01:23 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 17D9D8FC13; Thu, 7 Apr 2011 20:01:23 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p37K1Lhv069960 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 7 Apr 2011 13:01:22 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4D9E1831.4040707@freebsd.org> Date: Thu, 07 Apr 2011 13:01:53 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Andriy Gapon References: <4D9DF086.9020906@FreeBSD.org> In-Reply-To: <4D9DF086.9020906@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD current Subject: Re: prefer tsc timecounter when it's good X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 20:01:23 -0000 On 4/7/11 10:12 AM, Andriy Gapon wrote: > Guys, > > what do you think about the following change? > The idea is mark TSC as the best timecounter when it's invariant and synchronized > between cores. > Unfortunately I don't have code to auto-detect the synchronization and keep > relying on the corresponding tunable. I thought about auto-setting it for > single-package configurations, but even that information is currently not trivial > to get out of our mp (i386/amd64) machdep code. > > --- a/sys/x86/x86/tsc.c > +++ b/sys/x86/x86/tsc.c > @@ -169,6 +169,9 @@ init_TSC_tc(void) > printf("TSC timecounter disabled: APM enabled.\n"); > } > > + if (tsc_is_invariant) > + tsc_timecounter.tc_quality = 1200; I like this. I have to set the timecounter to TSC manually on my machines as using teh default (fast-acpi) slows my tests down by 10%-20% mind you if one were to be able to put the tunable into /boot, one could put the sysctl into /etc/sysctl.conf to do the same thing.. > + > #ifdef SMP > /* > * We can not use the TSC in SMP mode unless the TSCs on all CPUs > From owner-freebsd-current@FreeBSD.ORG Thu Apr 7 20:53:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEF8F1065670; Thu, 7 Apr 2011 20:53:17 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9AEC58FC15; Thu, 7 Apr 2011 20:53:17 +0000 (UTC) Received: by pzk27 with SMTP id 27so1302001pzk.13 for ; Thu, 07 Apr 2011 13:53:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=krk2NTcrV5M1I13nMnbOjE/MrvI1uJN8ymhZz/isayU=; b=VBXEsLu5UyOTBxKCsKy/BJAY9Ary2NbqlMkg5ip9d9wMqeNpLDSwenSQuwRYyArRU0 sAhnh3WA2jO0/kEoydyK29a+UZWtE+JK0oBGxy+L0qs1q0DtO8g4pJ+IudZhOANUIj1G B3XxKUkx/3qjWGVsf8WhO/olV731eNRv+J/q4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Xh9i0bvlY0nPs8nJi02zSn3StsQC4Zb13hTKN+PjjYhJNyuw3FmA7lmrxJmW7OeoSk i2G3KQVNoL/VUjCz76IrQGlB24ZWvz7dAWvtGyUOpGkG5WwiKZe2nUo/judSbL8DG68M +h8Rq9hMvfuTlhGgkFkSzK36wK2XsX5MZ9cTU= MIME-Version: 1.0 Received: by 10.142.152.3 with SMTP id z3mr1010884wfd.398.1302209596981; Thu, 07 Apr 2011 13:53:16 -0700 (PDT) Received: by 10.68.42.3 with HTTP; Thu, 7 Apr 2011 13:53:16 -0700 (PDT) In-Reply-To: <20110407185510.GA94830@freebsd.org> References: <20110407185510.GA94830@freebsd.org> Date: Thu, 7 Apr 2011 13:53:16 -0700 Message-ID: From: Garrett Cooper To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, freebsd-toolchain@freebsd.org Subject: Re: [RFC] adding -Wmissing-include-dirs to CWARNFLAGS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 20:53:17 -0000 On Thu, Apr 7, 2011 at 11:55 AM, Alexander Best wrote: > hi there, > > i'd like to propose adding -Wmissing-include-dirs to CWARNFLAGS. this will let > tinderbox fail, if any new kernel code was committed with (a) broken include > dir(s). > > i ran a test via > > make toolchains > make MAKE_JUST_KERNELS=yes tinderbox > > and nothing seemed to go wrong with the extra warning enabled. i even found a > missing include dir, which should be fixed by the attached patch. > > opinions? > > so far i've only tested this with gcc. i think someone on #freebsd-clang told > me that -Wmissing-include-dirs is a noop for clang (for whatever reasons). make -f /etc/src.conf -VMODULES_OVERRIDE and make -f /etc/src.conf -VMODULES_OVERRIDE say... (tinderbox should also really ignore these files, but it doesn't currently)? Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Apr 7 20:53:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66E5A1065679; Thu, 7 Apr 2011 20:53:37 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2F4358FC1B; Thu, 7 Apr 2011 20:53:37 +0000 (UTC) Received: by pzk27 with SMTP id 27so1302126pzk.13 for ; Thu, 07 Apr 2011 13:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=agrjJ6GUNGo2kuf28fWJpwfUMzF8D0AaiqE9p3tshag=; b=f6JPgs6XxqmYMKCcTb1r0llJYgsxlF8m2bamh0MxlrKo/ijlBVfu2v9TzudK3j8eMY RY1D0Ua3KorhveMKAnITDcDdMBrCHFJvOlOJ5Eue4ZH74NzapbxdVIhDx0frEk1dsV5M 3Hk+rJUbgjdf5d65nx/5TTjOmacxzo6hKBpEE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=B2pkT9a5UDpfao8HvihQ3g38kl9FmpwVEUHxKssEJFTFmE23LYytZLcLzT8WHCJ+pv b8QEv3H3gVCLO34NwI1U8LBudLkVNabO0QWpue1Uo4n7dwMhlQKQy9bfwkZdBz1cHDac 7vArGWLy12i+hon6tByBDoA2fLhZKel4tzqsg= MIME-Version: 1.0 Received: by 10.142.136.18 with SMTP id j18mr974943wfd.284.1302209616772; Thu, 07 Apr 2011 13:53:36 -0700 (PDT) Received: by 10.68.42.3 with HTTP; Thu, 7 Apr 2011 13:53:36 -0700 (PDT) In-Reply-To: References: <20110407185510.GA94830@freebsd.org> Date: Thu, 7 Apr 2011 13:53:36 -0700 Message-ID: From: Garrett Cooper To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-toolchain@freebsd.org Subject: Re: [RFC] adding -Wmissing-include-dirs to CWARNFLAGS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 20:53:37 -0000 On Thu, Apr 7, 2011 at 1:53 PM, Garrett Cooper wrote: > On Thu, Apr 7, 2011 at 11:55 AM, Alexander Best wro= te: >> hi there, >> >> i'd like to propose adding -Wmissing-include-dirs to CWARNFLAGS. this wi= ll let >> tinderbox fail, if any new kernel code was committed with (a) broken inc= lude >> dir(s). >> >> i ran a test via >> >> make toolchains >> make MAKE_JUST_KERNELS=3Dyes tinderbox >> >> and nothing seemed to go wrong with the extra warning enabled. i even fo= und a >> missing include dir, which should be fixed by the attached patch. >> >> opinions? >> >> so far i've only tested this with gcc. i think someone on #freebsd-clang= told >> me that -Wmissing-include-dirs is a noop for clang (for whatever reasons= ). > > =A0 =A0make -f /etc/src.conf -VMODULES_OVERRIDE and make -f /etc/src.conf > -VMODULES_OVERRIDE say... (tinderbox should also really ignore these > files, but it doesn't currently)? Sorry. Second invocation should have been make.conf, not src.conf. From owner-freebsd-current@FreeBSD.ORG Thu Apr 7 21:22:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id B48B2106566C; Thu, 7 Apr 2011 21:22:25 +0000 (UTC) Date: Thu, 7 Apr 2011 21:22:25 +0000 From: Alexander Best To: Garrett Cooper Message-ID: <20110407212225.GA17091@freebsd.org> References: <20110407185510.GA94830@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Cc: freebsd-current@freebsd.org, freebsd-toolchain@freebsd.org Subject: Re: [RFC] adding -Wmissing-include-dirs to CWARNFLAGS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 21:22:25 -0000 On Thu Apr 7 11, Garrett Cooper wrote: > On Thu, Apr 7, 2011 at 1:53 PM, Garrett Cooper wrote: > > On Thu, Apr 7, 2011 at 11:55 AM, Alexander Best wrote: > >> hi there, > >> > >> i'd like to propose adding -Wmissing-include-dirs to CWARNFLAGS. this will let > >> tinderbox fail, if any new kernel code was committed with (a) broken include > >> dir(s). > >> > >> i ran a test via > >> > >> make toolchains > >> make MAKE_JUST_KERNELS=yes tinderbox > >> > >> and nothing seemed to go wrong with the extra warning enabled. i even found a > >> missing include dir, which should be fixed by the attached patch. > >> > >> opinions? > >> > >> so far i've only tested this with gcc. i think someone on #freebsd-clang told > >> me that -Wmissing-include-dirs is a noop for clang (for whatever reasons). > > > >    make -f /etc/src.conf -VMODULES_OVERRIDE and make -f /etc/src.conf > > -VMODULES_OVERRIDE say... (tinderbox should also really ignore these > > files, but it doesn't currently)? otaku% make -f /etc/src.conf -VMODULES_OVERRIDE netgraph/netgraph netgraph/socket netgraph/bluetooth/bluetooth netgraph/bluetooth/hci netgraph/bluetooth/l2cap netgraph/bluetooth/socket netgraph/bluetooth/ubt tmpfs sound/sound sound/driver/hda usb/uhid procfs pseudofs linux linprocfs linsysfs lindev usb/quirk geom opensolaris dtrace cyclic nfsclient krpc nfs_common nfslock otaku% make -f /etc/make.conf -VMODULES_OVERRIDE netgraph/netgraph netgraph/socket netgraph/bluetooth/bluetooth netgraph/bluetooth/hci netgraph/bluetooth/l2cap netgraph/bluetooth/socket netgraph/bluetooth/ubt tmpfs sound/sound sound/driver/hda usb/uhid procfs pseudofs linux linprocfs linsysfs lindev usb/quirk geom opensolaris dtrace cyclic nfsclient krpc nfs_common nfslock ...however i checked and tinderbox *does* ignore src.conf and make.conf. the _.* log files show that modules were being build which are not returned by the commands above. i think having this flag would be very useful, because it would force people to make sure their include dirs are correct. > > Sorry. Second invocation should have been make.conf, not src.conf. -- a13x From owner-freebsd-current@FreeBSD.ORG Thu Apr 7 21:58:03 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD02A106566B; Thu, 7 Apr 2011 21:58:03 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 734248FC16; Thu, 7 Apr 2011 21:58:03 +0000 (UTC) Received: by pvg11 with SMTP id 11so1326039pvg.13 for ; Thu, 07 Apr 2011 14:58:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=x2JWrkVPYGpTkqlkWFSmRT0BF8szLnlNnVZbl6uNpG8=; b=jeFR98Ys+gAr2rrZkgeuFQENs/YpOnEsPDUrFcksDkqRtAHSz/wtCDPpu69guAMDbp yZmRotAqvS1MGkxeU6vhcSBNv9pnccXqbdhLcJyuvHQnhQ+ABAscFI+Rr8HUp+tOZ1eH ajCE5CDbElRrCBO//jeOSd4SoHq3dLWWqKP6Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=L8nqe6ZXt8UDK8jncuTCmC56gjc38P7k5mPUifWY8D1mNeN6p0wcd4BohCYIFUkQHd tX8vRkZ5I8Fr94flaI6xPZg7uUazUAG1F3taoHkVsIQFRnVn8PECqT1EOVjfjjiTZ0Rh c4FDxwAKMuCqm28nZY5o5AJQYCTEXGdMoAUCI= MIME-Version: 1.0 Received: by 10.142.152.3 with SMTP id z3mr1063382wfd.398.1302213483013; Thu, 07 Apr 2011 14:58:03 -0700 (PDT) Received: by 10.68.42.3 with HTTP; Thu, 7 Apr 2011 14:58:02 -0700 (PDT) In-Reply-To: <20110407212225.GA17091@freebsd.org> References: <20110407185510.GA94830@freebsd.org> <20110407212225.GA17091@freebsd.org> Date: Thu, 7 Apr 2011 14:58:02 -0700 Message-ID: From: Garrett Cooper To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-toolchain@freebsd.org Subject: Re: [RFC] adding -Wmissing-include-dirs to CWARNFLAGS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 21:58:03 -0000 On Thu, Apr 7, 2011 at 2:22 PM, Alexander Best wrote: > On Thu Apr =A07 11, Garrett Cooper wrote: >> On Thu, Apr 7, 2011 at 1:53 PM, Garrett Cooper wrot= e: >> > On Thu, Apr 7, 2011 at 11:55 AM, Alexander Best = wrote: >> >> hi there, >> >> >> >> i'd like to propose adding -Wmissing-include-dirs to CWARNFLAGS. this= will let >> >> tinderbox fail, if any new kernel code was committed with (a) broken = include >> >> dir(s). >> >> >> >> i ran a test via >> >> >> >> make toolchains >> >> make MAKE_JUST_KERNELS=3Dyes tinderbox >> >> >> >> and nothing seemed to go wrong with the extra warning enabled. i even= found a >> >> missing include dir, which should be fixed by the attached patch. >> >> >> >> opinions? >> >> >> >> so far i've only tested this with gcc. i think someone on #freebsd-cl= ang told >> >> me that -Wmissing-include-dirs is a noop for clang (for whatever reas= ons). >> > >> > =A0 =A0make -f /etc/src.conf -VMODULES_OVERRIDE and make -f /etc/src.c= onf >> > -VMODULES_OVERRIDE say... (tinderbox should also really ignore these >> > files, but it doesn't currently)? > > otaku% make -f /etc/src.conf -VMODULES_OVERRIDE > netgraph/netgraph netgraph/socket netgraph/bluetooth/bluetooth =A0netgrap= h/bluetooth/hci netgraph/bluetooth/l2cap netgraph/bluetooth/socket =A0netgr= aph/bluetooth/ubt tmpfs sound/sound sound/driver/hda usb/uhid =A0procfs pse= udofs linux linprocfs linsysfs lindev usb/quirk geom =A0opensolaris dtrace = cyclic nfsclient krpc nfs_common nfslock > otaku% make -f /etc/make.conf -VMODULES_OVERRIDE > netgraph/netgraph netgraph/socket netgraph/bluetooth/bluetooth =A0netgrap= h/bluetooth/hci netgraph/bluetooth/l2cap netgraph/bluetooth/socket =A0netgr= aph/bluetooth/ubt tmpfs sound/sound sound/driver/hda usb/uhid =A0procfs pse= udofs linux linprocfs linsysfs lindev usb/quirk geom =A0opensolaris dtrace = cyclic nfsclient krpc nfs_common nfslock > > ...however i checked and tinderbox *does* ignore src.conf and make.conf. = the > _.* log files show that modules were being build which are not returned b= y > the commands above. > > i think having this flag would be very useful, because it would force peo= ple to > make sure their include dirs are correct. > >> >> Sorry. Second invocation should have been make.conf, not src.conf. Ok then. I stand corrected for not having tested out my claim beforehand. Yes, I agree that adding this flag in the default set is a good idea. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Apr 8 05:43:30 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2BF71065670; Fri, 8 Apr 2011 05:43:30 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E8D178FC0C; Fri, 8 Apr 2011 05:43:29 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id IAA29866; Fri, 08 Apr 2011 08:43:28 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Q84Tg-000GB8-6s; Fri, 08 Apr 2011 08:43:28 +0300 Message-ID: <4D9EA07F.4020201@FreeBSD.org> Date: Fri, 08 Apr 2011 08:43:27 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110308 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jung-uk Kim References: <4D9DF086.9020906@FreeBSD.org> <201104071600.13586.jkim@FreeBSD.org> In-Reply-To: <201104071600.13586.jkim@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: prefer tsc timecounter when it's good X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 05:43:31 -0000 on 07/04/2011 23:00 Jung-uk Kim said the following: > Although it looks okay, please don't commit it just yet. I am working > in this area actively. Also, if the Intel's claim is true, i.e., > TSCs reset to zero when APs start, we cannot use TSC as a timecounter > hardware until all APs are started properly. Great! Thank you for the info and your work. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Apr 8 05:51:14 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25E40106564A; Fri, 8 Apr 2011 05:51:14 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2055E8FC08; Fri, 8 Apr 2011 05:51:12 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id IAA29978; Fri, 08 Apr 2011 08:51:11 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Q84b9-000GBx-DI; Fri, 08 Apr 2011 08:51:11 +0300 Message-ID: <4D9EA24E.2030401@FreeBSD.org> Date: Fri, 08 Apr 2011 08:51:10 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110308 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org References: <20110331223339.GA13682@freebsd.org> <201104010843.47367.jhb@freebsd.org> <20110404204316.GA11367@freebsd.org> <4D9D9917.3030102@FreeBSD.org> In-Reply-To: <4D9D9917.3030102@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: multiple issues with devstat_*(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 05:51:14 -0000 on 07/04/2011 13:59 Alexander Motin said the following: > Any objections? Or SCSI/IDE there expected to mean command set? > Sorry for saying something potentially stupid, but... do we actually have any reason to make that distinction from any practical point? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Apr 8 09:10:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 337E0106566C for ; Fri, 8 Apr 2011 09:10:04 +0000 (UTC) (envelope-from ftp51246-2575596@sh4-5.1blu.de) Received: from sh4-5.1blu.de (sh4-5.1blu.de [213.83.63.54]) by mx1.freebsd.org (Postfix) with ESMTP id DC1FD8FC12 for ; Fri, 8 Apr 2011 09:10:03 +0000 (UTC) Received: from ftp51246-2575596 by sh4-5.1blu.de with local (Exim 4.50) id 1Q87Gz-0000it-MD; Fri, 08 Apr 2011 10:42:34 +0200 Date: Fri, 8 Apr 2011 10:42:33 +0200 From: Matthias Apitz To: freebsd-questions@freebsd.org Message-ID: <20110408084232.GA28116@sh4-5.1blu.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 7.0-RELEASE (i386) User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org Subject: vmware-tools-freebsd && "No drivers for x.org version: 7.6.5." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 09:10:04 -0000 Hello, I have FreeBSD 9-CURRENT up and running in a VMware Workstation 7.x and I tried to install the vmware-tools-freebsd of VMware to get the driver for Xorg, but it seems that X.org 7.6.5. is not supported. My other VM runs a 8-CURRENT with X.org 7.4_1 which works fine. Any idea how to solve this? Should I go back to X.org 7.4_1 in 9-CURRENT? Or should I fake the vmware-tools installer to see X.org as /.4 while it is 7.6.5? Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ From owner-freebsd-current@FreeBSD.ORG Fri Apr 8 10:16:51 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D76B1065675; Fri, 8 Apr 2011 10:16:51 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id C42D78FC15; Fri, 8 Apr 2011 10:16:50 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:28c9:5dc0:39ff:1ba7] (unknown [IPv6:2001:7b8:3a7:0:28c9:5dc0:39ff:1ba7]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 0F8C25C59; Fri, 8 Apr 2011 12:16:50 +0200 (CEST) Message-ID: <4D9EE09F.6050409@FreeBSD.org> Date: Fri, 08 Apr 2011 12:17:03 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.16pre) Gecko/20110319 Lanikai/3.1.10pre MIME-Version: 1.0 To: Matthias Apitz References: <20110408084232.GA28116@sh4-5.1blu.de> In-Reply-To: <20110408084232.GA28116@sh4-5.1blu.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org Subject: Re: vmware-tools-freebsd && "No drivers for x.org version: 7.6.5." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 10:16:51 -0000 On 2011-04-08 10:42, Matthias Apitz wrote: > I have FreeBSD 9-CURRENT up and running in a VMware Workstation 7.x and > I tried to install the vmware-tools-freebsd of VMware to get the driver > for Xorg, but it seems that X.org 7.6.5. is not supported. My other VM > runs a 8-CURRENT with X.org 7.4_1 which works fine. > > Any idea how to solve this? Should I go back to X.org 7.4_1 in > 9-CURRENT? Or should I fake the vmware-tools installer to see X.org as > /.4 while it is 7.6.5? X.org 7.5 already has VMware drivers, so you can just install the x11-drivers/xf86-input-vmmouse and x11-drivers/xf86-video-vmware ports. Alternatively, run "make config" in x11-drivers/xorg-drivers, check the "VMMOUSE" and "VMWARE" entries, and rebuild this meta-port. Btw, I have no idea why these drivers are not enabled by default. They would seem very useful in a default X.org installation. From owner-freebsd-current@FreeBSD.ORG Fri Apr 8 10:23:34 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A036F106564A; Fri, 8 Apr 2011 10:23:34 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 100838FC0A; Fri, 8 Apr 2011 10:23:32 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA04352; Fri, 08 Apr 2011 13:23:30 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Q88qg-000GRr-Hc; Fri, 08 Apr 2011 13:23:30 +0300 Message-ID: <4D9EE221.40200@FreeBSD.org> Date: Fri, 08 Apr 2011 13:23:29 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110308 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: John Baldwin References: <201104072132.p37LWPuu052536@svn.freebsd.org> In-Reply-To: <201104072132.p37LWPuu052536@svn.freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, FreeBSD-Current , svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r220430 - head/sys/amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 10:23:34 -0000 on 08/04/2011 00:32 John Baldwin said the following: > Author: jhb > Date: Thu Apr 7 21:32:25 2011 > New Revision: 220430 > URL: http://svn.freebsd.org/changeset/base/220430 > > Log: > If a system call does not request a full interrupt return, use a fast > path via the sysretq instruction to return from the system call. This was > removed in 190620 and not quite fully restored in 195486. This resolves > most of the performance regression in system call microbenchmarks between > 7 and 8 on amd64. > > Reviewed by: kib > MFC after: 1 week I think that this commit (plus r220431) has broken something in my environment. After updating to the most recent head I started to get semi-random problems in various areas: - named would consistently fail to start, but with different errors (assertions) - ^Z and fg result in a process getting SIGSEGV - X sometimes fails to start complaining about failed VT switch Reverting just these two commits restores sanity. Just in case, my processor is AMD (arch is obviously amd64). > Modified: > head/sys/amd64/amd64/exception.S > > Modified: head/sys/amd64/amd64/exception.S > ============================================================================== > --- head/sys/amd64/amd64/exception.S Thu Apr 7 21:29:34 2011 (r220429) > +++ head/sys/amd64/amd64/exception.S Thu Apr 7 21:32:25 2011 (r220430) > @@ -339,6 +339,9 @@ IDTVEC(prot) > * and the new privilige level. We are still running on the old user stack > * pointer. We have to juggle a few things around to find our stack etc. > * swapgs gives us access to our PCPU space only. > + * > + * We do not support invoking this from a custom %cs or %ss (e.g. using > + * entries from an LDT). > */ > IDTVEC(fast_syscall) > swapgs > @@ -380,6 +383,36 @@ IDTVEC(fast_syscall) > movq %rsp,%rdi > call syscall > movq PCPU(CURPCB),%rax > + testq $PCB_FULL_IRET,PCB_FLAGS(%rax) > + jne 3f > +1: /* Check for and handle AST's on return to userland. */ > + cli > + movq PCPU(CURTHREAD),%rax > + testl $TDF_ASTPENDING | TDF_NEEDRESCHED,TD_FLAGS(%rax) > + je 2f > + sti > + movq %rsp, %rdi > + call ast > + jmp 1b > +2: /* Restore preserved registers. */ > + MEXITCOUNT > + movq TF_RDI(%rsp),%rdi /* bonus; preserve arg 1 */ > + movq TF_RSI(%rsp),%rsi /* bonus: preserve arg 2 */ > + movq TF_RDX(%rsp),%rdx /* return value 2 */ > + movq TF_RAX(%rsp),%rax /* return value 1 */ > + movq TF_RBX(%rsp),%rbx /* C preserved */ > + movq TF_RBP(%rsp),%rbp /* C preserved */ > + movq TF_R12(%rsp),%r12 /* C preserved */ > + movq TF_R13(%rsp),%r13 /* C preserved */ > + movq TF_R14(%rsp),%r14 /* C preserved */ > + movq TF_R15(%rsp),%r15 /* C preserved */ > + movq TF_RFLAGS(%rsp),%r11 /* original %rflags */ > + movq TF_RIP(%rsp),%rcx /* original %rip */ > + movq TF_RSP(%rsp),%r9 /* user stack pointer */ > + movq %r9,%rsp /* original %rsp */ > + swapgs > + sysretq > +3: /* Requested full context restore, use doreti for that. */ > MEXITCOUNT > jmp doreti > -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Apr 8 12:03:39 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C47931065673; Fri, 8 Apr 2011 12:03:39 +0000 (UTC) (envelope-from ftp51246-2575596@sh4-5.1blu.de) Received: from sh4-5.1blu.de (sh4-5.1blu.de [213.83.63.54]) by mx1.freebsd.org (Postfix) with ESMTP id 881058FC08; Fri, 8 Apr 2011 12:03:39 +0000 (UTC) Received: from ftp51246-2575596 by sh4-5.1blu.de with local (Exim 4.50) id 1Q8APZ-0000sZ-2w; Fri, 08 Apr 2011 14:03:37 +0200 Date: Fri, 8 Apr 2011 14:03:36 +0200 From: Matthias Apitz To: Dimitry Andric Message-ID: <20110408120335.GA2648@sh4-5.1blu.de> References: <20110408084232.GA28116@sh4-5.1blu.de> <4D9EE09F.6050409@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4D9EE09F.6050409@FreeBSD.org> X-Operating-System: FreeBSD 7.0-RELEASE (i386) User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org Subject: Re: vmware-tools-freebsd && "No drivers for x.org version: 7.6.5." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 12:03:39 -0000 El día Friday, April 08, 2011 a las 12:17:03PM +0200, Dimitry Andric escribió: > On 2011-04-08 10:42, Matthias Apitz wrote: > >I have FreeBSD 9-CURRENT up and running in a VMware Workstation 7.x and > >I tried to install the vmware-tools-freebsd of VMware to get the driver > >for Xorg, but it seems that X.org 7.6.5. is not supported. My other VM > >runs a 8-CURRENT with X.org 7.4_1 which works fine. > > > >Any idea how to solve this? Should I go back to X.org 7.4_1 in > >9-CURRENT? Or should I fake the vmware-tools installer to see X.org as > >/.4 while it is 7.6.5? > > X.org 7.5 already has VMware drivers, so you can just install the > x11-drivers/xf86-input-vmmouse and x11-drivers/xf86-video-vmware ports. > > Alternatively, run "make config" in x11-drivers/xorg-drivers, check the > "VMMOUSE" and "VMWARE" entries, and rebuild this meta-port. Dimitry, Thanks for your kind & fast answer; does this also mean that I could completely get rid of the VMware' vmware-tools-freebsd? I'm using on the 8-CURRENT system the emulators/open-vom-tools and will install them in the 9-CURRENT too. Thanks again matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ From owner-freebsd-current@FreeBSD.ORG Fri Apr 8 12:38:18 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BC98106570E; Fri, 8 Apr 2011 12:38:18 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id E3F2A8FC19; Fri, 8 Apr 2011 12:38:17 +0000 (UTC) Received: by pvg11 with SMTP id 11so1588468pvg.13 for ; Fri, 08 Apr 2011 05:38:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:date:message-id:subject :from:to:content-type; bh=Eqgo2BZDivofwCn7r58xYw8amYvrS0RBr6VsPBRxb6o=; b=oDG/ANv2TNdSbHipUT4Bfx4ubwEYaXRROVGDoFTZGt4OKwUDJQYthzpEfVTZ8t9F6N UMPqDwu3yTirPmAgBaqQs1GaSOMJCIAQKzYTaoNdHm6k8JQLvBBN9NqcmjZZk0CRt2LF 3GcyqsgZv2rmkqi5ylVqxWUVkNl7tgAUn3gFA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=I0Ol8bZ4LhxlZ/hSFfg3QVN/7gVKFm3S4bNweMMCDowUZPpp7eXSHbEoRzMpKo6ojr l/lQErJe5209wB698LL2N6ux/oHS0DpaUkftRvK6hifHLKCvfRYM0y3UML3pAQ0x8SXh bBiFjoi8Ns1y43HPAaxd2DvutQe4gxO0NxoYg= MIME-Version: 1.0 Received: by 10.142.224.11 with SMTP id w11mr1797876wfg.136.1302266297322; Fri, 08 Apr 2011 05:38:17 -0700 (PDT) Received: by 10.68.47.6 with HTTP; Fri, 8 Apr 2011 05:38:17 -0700 (PDT) Date: Fri, 8 Apr 2011 12:38:17 +0000 Message-ID: From: "b. f." To: Andriy Gapon , freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: svn commit: r220430 - head/sys/amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 12:38:18 -0000 > > Author: jhb > > Date: Thu Apr 7 21:32:25 2011 ... > > URL: http://svn.freebsd.org/changeset/base/220430 ... > > I think that this commit (plus r220431) has broken something in my environment. > After updating to the most recent head I started to get semi-random problems in > various areas: > - named would consistently fail to start, but with different errors (assertions) > - ^Z and fg result in a process getting SIGSEGV > - X sometimes fails to start complaining about failed VT switch > > Reverting just these two commits restores sanity. > > Just in case, my processor is AMD (arch is obviously amd64). I experienced similar problems (UP amd64, AMD Mobile Athlon64 processor) and reported it to kib@ and jhb@. b. From owner-freebsd-current@FreeBSD.ORG Fri Apr 8 12:45:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 83975106566C; Fri, 8 Apr 2011 12:45:13 +0000 (UTC) Date: Fri, 8 Apr 2011 12:45:13 +0000 From: Alexander Best To: Garrett Cooper Message-ID: <20110408124513.GA22745@freebsd.org> References: <20110407185510.GA94830@freebsd.org> <20110407212225.GA17091@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Cc: freebsd-current@freebsd.org, freebsd-toolchain@freebsd.org Subject: Re: [RFC] adding -Wmissing-include-dirs to CWARNFLAGS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 12:45:13 -0000 On Thu Apr 7 11, Garrett Cooper wrote: > On Thu, Apr 7, 2011 at 2:22 PM, Alexander Best wrote: > > On Thu Apr  7 11, Garrett Cooper wrote: > >> On Thu, Apr 7, 2011 at 1:53 PM, Garrett Cooper wrote: > >> > On Thu, Apr 7, 2011 at 11:55 AM, Alexander Best wrote: > >> >> hi there, > >> >> > >> >> i'd like to propose adding -Wmissing-include-dirs to CWARNFLAGS. this will let > >> >> tinderbox fail, if any new kernel code was committed with (a) broken include > >> >> dir(s). > >> >> > >> >> i ran a test via > >> >> > >> >> make toolchains > >> >> make MAKE_JUST_KERNELS=yes tinderbox > >> >> > >> >> and nothing seemed to go wrong with the extra warning enabled. i even found a > >> >> missing include dir, which should be fixed by the attached patch. > >> >> > >> >> opinions? > >> >> > >> >> so far i've only tested this with gcc. i think someone on #freebsd-clang told > >> >> me that -Wmissing-include-dirs is a noop for clang (for whatever reasons). > >> > > >> >    make -f /etc/src.conf -VMODULES_OVERRIDE and make -f /etc/src.conf > >> > -VMODULES_OVERRIDE say... (tinderbox should also really ignore these > >> > files, but it doesn't currently)? > > > > otaku% make -f /etc/src.conf -VMODULES_OVERRIDE > > netgraph/netgraph netgraph/socket netgraph/bluetooth/bluetooth  netgraph/bluetooth/hci netgraph/bluetooth/l2cap netgraph/bluetooth/socket  netgraph/bluetooth/ubt tmpfs sound/sound sound/driver/hda usb/uhid  procfs pseudofs linux linprocfs linsysfs lindev usb/quirk geom  opensolaris dtrace cyclic nfsclient krpc nfs_common nfslock > > otaku% make -f /etc/make.conf -VMODULES_OVERRIDE > > netgraph/netgraph netgraph/socket netgraph/bluetooth/bluetooth  netgraph/bluetooth/hci netgraph/bluetooth/l2cap netgraph/bluetooth/socket  netgraph/bluetooth/ubt tmpfs sound/sound sound/driver/hda usb/uhid  procfs pseudofs linux linprocfs linsysfs lindev usb/quirk geom  opensolaris dtrace cyclic nfsclient krpc nfs_common nfslock > > > > ...however i checked and tinderbox *does* ignore src.conf and make.conf. the > > _.* log files show that modules were being build which are not returned by > > the commands above. > > > > i think having this flag would be very useful, because it would force people to > > make sure their include dirs are correct. > > > >> > >> Sorry. Second invocation should have been make.conf, not src.conf. > > Ok then. I stand corrected for not having tested out my claim beforehand. > > Yes, I agree that adding this flag in the default set is a good idea. cool. so now we need somebody to make the commit. ;) > > Thanks, > -Garrett -- a13x From owner-freebsd-current@FreeBSD.ORG Fri Apr 8 13:05:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E76BD106564A for ; Fri, 8 Apr 2011 13:05:24 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from mx.lissyara.su (mx.lissyara.su [77.73.25.118]) by mx1.freebsd.org (Postfix) with ESMTP id A0E118FC13 for ; Fri, 8 Apr 2011 13:05:24 +0000 (UTC) Received: from [195.93.240.106] (port=20531 helo=lissyara.moskb.local) by mx.lissyara.su with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q8Arn-000BHx-SG for freebsd-current@freebsd.org; Fri, 08 Apr 2011 16:32:47 +0400 Message-ID: <4D9F006F.3020803@lissyara.su> Date: Fri, 08 Apr 2011 16:32:47 +0400 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.23) Gecko/20091202 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <201104072132.p37LWPuu052536@svn.freebsd.org> <4D9EE221.40200@FreeBSD.org> In-Reply-To: <4D9EE221.40200@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-White-List: YES X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-White-List: YES X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: mx.lissyara.su Subject: Re: svn commit: r220430 - head/sys/amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 13:05:25 -0000 08.04.2011 14:23, Andriy Gapon пишет: > on 08/04/2011 00:32 John Baldwin said the following: >> Author: jhb >> Date: Thu Apr 7 21:32:25 2011 >> New Revision: 220430 >> URL: http://svn.freebsd.org/changeset/base/220430 >> >> Log: >> If a system call does not request a full interrupt return, use a fast >> path via the sysretq instruction to return from the system call. This was >> removed in 190620 and not quite fully restored in 195486. This resolves >> most of the performance regression in system call microbenchmarks between >> 7 and 8 on amd64. >> >> Reviewed by: kib >> MFC after: 1 week > I think that this commit (plus r220431) has broken something in my environment. > After updating to the most recent head I started to get semi-random problems in > various areas: > - named would consistently fail to start, but with different errors (assertions) > - ^Z and fg result in a process getting SIGSEGV > - X sometimes fails to start complaining about failed VT switch > > Reverting just these two commits restores sanity. > > Just in case, my processor is AMD (arch is obviously amd64). confirm >> Modified: >> head/sys/amd64/amd64/exception.S >> >> Modified: head/sys/amd64/amd64/exception.S >> ============================================================================== >> --- head/sys/amd64/amd64/exception.S Thu Apr 7 21:29:34 2011 (r220429) >> +++ head/sys/amd64/amd64/exception.S Thu Apr 7 21:32:25 2011 (r220430) >> @@ -339,6 +339,9 @@ IDTVEC(prot) >> * and the new privilige level. We are still running on the old user stack >> * pointer. We have to juggle a few things around to find our stack etc. >> * swapgs gives us access to our PCPU space only. >> + * >> + * We do not support invoking this from a custom %cs or %ss (e.g. using >> + * entries from an LDT). >> */ >> IDTVEC(fast_syscall) >> swapgs >> @@ -380,6 +383,36 @@ IDTVEC(fast_syscall) >> movq %rsp,%rdi >> call syscall >> movq PCPU(CURPCB),%rax >> + testq $PCB_FULL_IRET,PCB_FLAGS(%rax) >> + jne 3f >> +1: /* Check for and handle AST's on return to userland. */ >> + cli >> + movq PCPU(CURTHREAD),%rax >> + testl $TDF_ASTPENDING | TDF_NEEDRESCHED,TD_FLAGS(%rax) >> + je 2f >> + sti >> + movq %rsp, %rdi >> + call ast >> + jmp 1b >> +2: /* Restore preserved registers. */ >> + MEXITCOUNT >> + movq TF_RDI(%rsp),%rdi /* bonus; preserve arg 1 */ >> + movq TF_RSI(%rsp),%rsi /* bonus: preserve arg 2 */ >> + movq TF_RDX(%rsp),%rdx /* return value 2 */ >> + movq TF_RAX(%rsp),%rax /* return value 1 */ >> + movq TF_RBX(%rsp),%rbx /* C preserved */ >> + movq TF_RBP(%rsp),%rbp /* C preserved */ >> + movq TF_R12(%rsp),%r12 /* C preserved */ >> + movq TF_R13(%rsp),%r13 /* C preserved */ >> + movq TF_R14(%rsp),%r14 /* C preserved */ >> + movq TF_R15(%rsp),%r15 /* C preserved */ >> + movq TF_RFLAGS(%rsp),%r11 /* original %rflags */ >> + movq TF_RIP(%rsp),%rcx /* original %rip */ >> + movq TF_RSP(%rsp),%r9 /* user stack pointer */ >> + movq %r9,%rsp /* original %rsp */ >> + swapgs >> + sysretq >> +3: /* Requested full context restore, use doreti for that. */ >> MEXITCOUNT >> jmp doreti >> > From owner-freebsd-current@FreeBSD.ORG Fri Apr 8 13:09:00 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 328301065670; Fri, 8 Apr 2011 13:09:00 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DE30E8FC18; Fri, 8 Apr 2011 13:08:59 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 77E8646B49; Fri, 8 Apr 2011 09:08:59 -0400 (EDT) Received: from jhbmac.hudson-trading.com (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D09AC8A027; Fri, 8 Apr 2011 09:08:58 -0400 (EDT) Message-ID: <4D9F08EA.9090209@FreeBSD.org> Date: Fri, 08 Apr 2011 09:08:58 -0400 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Andriy Gapon References: <201104072132.p37LWPuu052536@svn.freebsd.org> <4D9EE221.40200@FreeBSD.org> In-Reply-To: <4D9EE221.40200@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 08 Apr 2011 09:08:59 -0400 (EDT) Cc: svn-src-head@FreeBSD.org, FreeBSD-Current , svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r220430 - head/sys/amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 13:09:00 -0000 On 4/8/11 6:23 AM, Andriy Gapon wrote: > on 08/04/2011 00:32 John Baldwin said the following: >> Author: jhb >> Date: Thu Apr 7 21:32:25 2011 >> New Revision: 220430 >> URL: http://svn.freebsd.org/changeset/base/220430 >> >> Log: >> If a system call does not request a full interrupt return, use a fast >> path via the sysretq instruction to return from the system call. This was >> removed in 190620 and not quite fully restored in 195486. This resolves >> most of the performance regression in system call microbenchmarks between >> 7 and 8 on amd64. >> >> Reviewed by: kib >> MFC after: 1 week > > I think that this commit (plus r220431) has broken something in my environment. > After updating to the most recent head I started to get semi-random problems in > various areas: > - named would consistently fail to start, but with different errors (assertions) > - ^Z and fg result in a process getting SIGSEGV > - X sometimes fails to start complaining about failed VT switch > > Reverting just these two commits restores sanity. > > Just in case, my processor is AMD (arch is obviously amd64). I think I've found this (I got a bunch of weird core dumps overnight, too). The problem is that ast() can context switch in which case PCB_FULL_IRET might get set, but this code would still do the fast path after ast() returned. I fixed it to recheck the PCB_FULL_IRET flag after returning from ast() and that has fixed the core dumps I was seeing overnight. I also fixed a bug where PCB_FULL_IRET wasn't updated in some of the ia32 compat code, a typo in a comment, and trimmed an extra mov from the doreti path: Index: amd64/exception.S =================================================================== --- amd64/exception.S (revision 221092) +++ amd64/exception.S (working copy) @@ -382,10 +382,10 @@ FAKE_MCOUNT(TF_RIP(%rsp)) movq %rsp,%rdi call syscall - movq PCPU(CURPCB),%rax +1: movq PCPU(CURPCB),%rax testl $PCB_FULL_IRET,PCB_FLAGS(%rax) - jne 3f -1: /* Check for and handle AST's on return to userland. */ + jnz 3f + /* Check for and handle AST's on return to userland. */ cli movq PCPU(CURTHREAD),%rax testl $TDF_ASTPENDING | TDF_NEEDRESCHED,TD_FLAGS(%rax) @@ -661,7 +661,7 @@ doreti_ast: /* * Check for ASTs atomically with returning. Disabling CPU - * interrupts provides sufficient locking eve in the SMP case, + * interrupts provides sufficient locking even in the SMP case, * since we will be informed of any new ASTs by an IPI. */ cli @@ -682,8 +682,7 @@ */ doreti_exit: MEXITCOUNT - movq PCPU(CURTHREAD),%r8 - movq TD_PCB(%r8),%r8 + movq PCPU(CURPCB),%r8 /* * Do not reload segment registers for kernel. Index: ia32/ia32_exception.S =================================================================== --- ia32/ia32_exception.S (revision 221079) +++ ia32/ia32_exception.S (working copy) @@ -46,7 +46,7 @@ subq $TF_ERR,%rsp /* skip over tf_trapno */ movq %rdi,TF_RDI(%rsp) movq PCPU(CURPCB),%rdi - movb $0,PCB_FULL_IRET(%rdi) + andl $~PCB_FULL_IRET,PCB_FLAGS(%rdi) movw %fs,TF_FS(%rsp) movw %gs,TF_GS(%rsp) movw %es,TF_ES(%rsp) -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Apr 8 15:15:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 134E6106567C for ; Fri, 8 Apr 2011 15:15:24 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id A0C528FC18 for ; Fri, 8 Apr 2011 15:15:23 +0000 (UTC) Received: by eyg7 with SMTP id 7so1239921eyg.13 for ; Fri, 08 Apr 2011 08:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=MbbcROi0D+0vUwSQNvM2Za+G+acX3b9yCDQGa8pDnFo=; b=r3f99pYG72WMN48/rIkdjTUiILIqiyCm590x5EDXTtC9s3QhgAGCJc05sWszd4dcuC dbISiOl7p4Ztc9OC+ynRr8tWLZARJi+kIMsXTB+991bfpI6LGdCTGeVMSXJerLmNbu8B cTkYD+Y7wDzzHE6O+xhRM0scGIcPgn6k3YWaM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=J5lnO21+/cvZgTpIJZR4YKpBKQt2kxcPgV61c/zQrBQPZJLySqdxtsiChU1WzOw1tZ cPa2PNPEnRyeONplP+btXuzq9jrBBecPkZFaNDNrlqyAqXLnDD0UQf4PR8mbeVMKbUau G03LlLm+B6t56TyofshWWblohY35bOfoxp18c= MIME-Version: 1.0 Received: by 10.213.21.134 with SMTP id j6mr976585ebb.141.1302275722273; Fri, 08 Apr 2011 08:15:22 -0700 (PDT) Received: by 10.213.31.75 with HTTP; Fri, 8 Apr 2011 08:15:22 -0700 (PDT) Date: Fri, 8 Apr 2011 11:15:22 -0400 Message-ID: From: Ryan Stone To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Subject: [PATCH] Add syslogd option that suppresses hostname logging X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 15:15:24 -0000 I've written a short patch for syslogd that adds a -H option. Setting that option will prevent syslogd from logging the hostname with every log messages. If there are no objections I'm going to commit this in the next couple of days. Index: syslogd.c =================================================================== --- syslogd.c (revision 220452) +++ syslogd.c (working copy) @@ -301,6 +301,7 @@ /* 0=no, 1=numeric, 2=names */ static int KeepKernFac; /* Keep remotely logged kernel facility */ static int needdofsync = 0; /* Are any file(s) waiting to be fsynced? */ +static int LogHost = 1; static struct pidfh *pfh; volatile sig_atomic_t MarkSet, WantDie; @@ -358,7 +359,7 @@ dprintf("madvise() failed: %s\n", strerror(errno)); bindhostname = NULL; - while ((ch = getopt(argc, argv, "468Aa:b:cCdf:kl:m:nop:P:sS:Tuv")) + while ((ch = getopt(argc, argv, "468Aa:b:cCdf:Hkl:m:nop:P:sS:Tuv")) != -1) switch (ch) { case '4': @@ -394,6 +395,9 @@ case 'f': /* configuration file */ ConfFile = optarg; break; + case 'H': /* don't log the origin hostname */ + LogHost = 0; + break; case 'k': /* keep remote kern fac */ KeepKernFac = 1; break; @@ -1150,12 +1154,20 @@ } v++; - v->iov_base = f->f_prevhost; - v->iov_len = strlen(v->iov_base); + if (LogHost) { + v->iov_base = f->f_prevhost; + v->iov_len = strlen(v->iov_base); + v++; + v->iov_base = space; + v->iov_len = 1; + } else { + v->iov_base = nul; + v->iov_len = 0; + v++; + v->iov_base = nul; + v->iov_len = 0; + } v++; - v->iov_base = space; - v->iov_len = 1; - v++; if (msg) { wmsg = strdup(msg); /* XXX iov_base needs a `const' sibling. */ From owner-freebsd-current@FreeBSD.ORG Fri Apr 8 19:35:15 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F18A41065674 for ; Fri, 8 Apr 2011 19:35:15 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.c2i.net [212.247.154.34]) by mx1.freebsd.org (Postfix) with ESMTP id 802138FC16 for ; Fri, 8 Apr 2011 19:35:15 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=oR3+9dOmPeF3nZCt5Gxyvf/bIpfj8bfjGZkkfp/xES8= c=1 sm=1 a=IU0TiZmyZPMA:10 a=Iba5Pj8TEUkA:10 a=WQU8e4WWZSUA:10 a=kj9zAlcOel0A:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=I9e8OeI0s8YJDl6_EUwA:9 a=YQQ5uAi0Li113Qy5L50A:7 a=CjuIK1q_8ugA:10 a=VRswk_N_Q0jjV6_B:21 a=jx-RxEBJv90FUxRe:21 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 111869573 for freebsd-current@freebsd.org; Fri, 08 Apr 2011 21:35:13 +0200 From: Hans Petter Selasky To: "freebsd-current@FreeBSD.org" Date: Fri, 8 Apr 2011 21:34:15 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-PRERELEASE; KDE/4.4.5; amd64; ; ) X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201104082134.15674.hselasky@c2i.net> Subject: Fdisk formatting of disk having bs=1K fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 19:35:16 -0000 Hi, It appears that src/sbin/fdisk.c can only read the MBR of disks having a blocksize different than 512 bytes. When writing a new MBR, the below check fails. Can someone having knowledge into fdisk, fix this issue and MFC to 8- stable? Also I'm curious about the #ifdef __ia64__ . if ((mboot.bootinst_size = sb.st_size) % secsize != 0) secsize = 1024; sb.st_size = sizeof(/boot/mbr) = 512; --HPS My attempt to fix this issue: --- fdisk.c (revision 220305) +++ fdisk.c (local) @@ -508,22 +508,29 @@ const char *fname; int fdesc, n; struct stat sb; + off_t align_size; fname = b_flag ? b_flag : "/boot/mbr"; if ((fdesc = open(fname, O_RDONLY)) == -1 || fstat(fdesc, &sb) == -1) err(1, "%s", fname); - if ((mboot.bootinst_size = sb.st_size) % secsize != 0) - errx(1, "%s: length must be a multiple of sector size", fname); + + align_size = (sb.st_size + secsize - 1); + align_size -= align_size % secsize; + if (align_size == 0) + errx(1, "%s: length must be non-zero", fname); + mboot.bootinst_size = align_size; if (mboot.bootinst != NULL) free(mboot.bootinst); - if ((mboot.bootinst = malloc(mboot.bootinst_size = sb.st_size)) == NULL) + if ((mboot.bootinst = malloc(align_size)) == NULL) errx(1, "%s: unable to allocate read buffer", fname); - if ((n = read(fdesc, mboot.bootinst, mboot.bootinst_size)) == -1 || + if ((n = read(fdesc, mboot.bootinst, sb.st_size)) == -1 || close(fdesc)) err(1, "%s", fname); - if (n != mboot.bootinst_size) + if (n != sb.st_size) errx(1, "%s: short read", fname); + if (align_size != n) + memset(mboot.bootinst + sb.st_size, 0, align_size - sb.st_size); #else if (mboot.bootinst != NULL) free(mboot.bootinst); From owner-freebsd-current@FreeBSD.ORG Fri Apr 8 21:49:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E6E0106566B for ; Fri, 8 Apr 2011 21:49:32 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id C148B8FC08 for ; Fri, 8 Apr 2011 21:49:31 +0000 (UTC) Received: by vxc34 with SMTP id 34so3775984vxc.13 for ; Fri, 08 Apr 2011 14:49:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:in-reply-to :references:x-mailer:mime-version:content-type; bh=Ys+VUjareq13SIHK1I6nryN+oiJ3r5oKTjzMAWZzf1M=; b=FHb1yFDdtmnTeAOQLiFRvhzTmFu9oS85SjzS98aI8zQo6OKVI2NXszcHYKHMAVhHL6 NDrJ5/IWcDE63werk1ZjmKA/EihbjleH8xBU34XuTlLLfk9NL894IpWj0LbASY0XfLf0 sU1KGy/Yb6uWM2plok0pAPP7eoUFZrIrZoaUc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=JhFLrLTZoHZ7zLs4UYLjRBi3rF9v8eZgo5j4pzjS+kPF1WiQ8BeSc8napF8CYxbtoR 0r/yxu8e0/RvKjiYmNZWN1LzdEVIKtIaxqvaurIoG0eU76BdlUw+c9s3FYgOmzm/Bv40 RvtEheNqSBBKJJUIAwQSidd+SPmqAF1gnq1Aw= Received: by 10.220.199.2 with SMTP id eq2mr810107vcb.68.1302297975935; Fri, 08 Apr 2011 14:26:15 -0700 (PDT) Received: from kan.dnsalias.net (c-24-63-226-98.hsd1.ma.comcast.net [24.63.226.98]) by mx.google.com with ESMTPS id f32sm764180vcm.38.2011.04.08.14.26.02 (version=SSLv3 cipher=OTHER); Fri, 08 Apr 2011 14:26:06 -0700 (PDT) Date: Fri, 8 Apr 2011 17:24:59 -0400 From: Alexander Kabaev To: freebsd-current@freebsd.org Message-ID: <20110408172459.78c5d730@kan.dnsalias.net> In-Reply-To: <20110408120335.GA2648@sh4-5.1blu.de> References: <20110408084232.GA28116@sh4-5.1blu.de> <4D9EE09F.6050409@FreeBSD.org> <20110408120335.GA2648@sh4-5.1blu.de> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/VOhi+5/8eMnKHy0VlBQIFan"; protocol="application/pgp-signature" Cc: Matthias Apitz Subject: Re: vmware-tools-freebsd && "No drivers for x.org version: 7.6.5." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 21:49:32 -0000 --Sig_/VOhi+5/8eMnKHy0VlBQIFan Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, 8 Apr 2011 14:03:36 +0200 Matthias Apitz wrote: > El d=EDa Friday, April 08, 2011 a las 12:17:03PM +0200, Dimitry Andric > escribi=F3: >=20 > > On 2011-04-08 10:42, Matthias Apitz wrote: > > >I have FreeBSD 9-CURRENT up and running in a VMware Workstation > > >7.x and I tried to install the vmware-tools-freebsd of VMware to > > >get the driver for Xorg, but it seems that X.org 7.6.5. is not > > >supported. My other VM runs a 8-CURRENT with X.org 7.4_1 which > > >works fine. > > > > > >Any idea how to solve this? Should I go back to X.org 7.4_1 in > > >9-CURRENT? Or should I fake the vmware-tools installer to see > > >X.org as /.4 while it is 7.6.5? > >=20 > > X.org 7.5 already has VMware drivers, so you can just install the > > x11-drivers/xf86-input-vmmouse and x11-drivers/xf86-video-vmware > > ports. > >=20 > > Alternatively, run "make config" in x11-drivers/xorg-drivers, check > > the "VMMOUSE" and "VMWARE" entries, and rebuild this meta-port. >=20 > Dimitry,=20 >=20 > Thanks for your kind & fast answer; does this also mean that I could > completely get rid of the VMware' vmware-tools-freebsd? I'm using on > the 8-CURRENT system the emulators/open-vom-tools and will install > them in the 9-CURRENT too. >=20 > Thanks again >=20 > matthias >=20 I am not Dmirty, but I will answer anyway. If you install open-vm-tools and xf86-input-vmmouse and xf86-video-vmware drivers, you won't need to bother fighting with vmware tools anymore. The open-vm-tools port installs vmware-user-suid-wrapper binary without SUID bit, you will need to fix that. Also, vmblock driver currently crashes FreeBSD-current kernel, so you will need to remove or rename /boot/modules/vmblock.ko and /usr/local/lib/vmware-tools/modules/drivers/vmblock.ko so that vmware-user-suid-wrapper does not load it for you automatically. --=20 Alexander Kabaev --Sig_/VOhi+5/8eMnKHy0VlBQIFan Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iD8DBQFNn31BQ6z1jMm+XZYRAio5AKCKy5EoWIG8hdHmV4P5LVlm2LfKgQCfadyL 5EQeg2mgTmhTNQbLpPXW4c8= =YHvm -----END PGP SIGNATURE----- --Sig_/VOhi+5/8eMnKHy0VlBQIFan-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 8 22:01:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82FF4106566C for ; Fri, 8 Apr 2011 22:01:16 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout030.mac.com (asmtpout030.mac.com [17.148.16.105]) by mx1.freebsd.org (Postfix) with ESMTP id 699108FC0C for ; Fri, 8 Apr 2011 22:01:16 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from sa-nc-finance-165.static.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp030.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LJC0006JT5QI930@asmtp030.mac.com> for freebsd-current@freebsd.org; Fri, 08 Apr 2011 15:01:16 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-04-08_08:2011-04-09, 2011-04-08, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1104080140 From: Marcel Moolenaar In-reply-to: <201104082134.15674.hselasky@c2i.net> Date: Fri, 08 Apr 2011 15:01:01 -0700 Message-id: <127C6AAD-9586-4B85-9297-F4BAF4BC61C3@mac.com> References: <201104082134.15674.hselasky@c2i.net> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1084) Cc: "freebsd-current@FreeBSD.org" Subject: Re: Fdisk formatting of disk having bs=1K fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 22:01:16 -0000 On Apr 8, 2011, at 12:34 PM, Hans Petter Selasky wrote: > Hi, > > It appears that src/sbin/fdisk.c can only read the MBR of disks having a > blocksize different than 512 bytes. When writing a new MBR, the below check > fails. Can someone having knowledge into fdisk, fix this issue and MFC to 8- > stable? Also I'm curious about the #ifdef __ia64__ . You can eliminate the __ia64__ conditional if you want. From the commit log: ======== r95860 | peter | 2002-05-01 06:48:29 +0000 (Wed, 01 May 2002) | 4 lines Add a hack so that fdisk(8) can initialize an ia64 disk. There is no /boot/mbr to read the boot code from (ia64 does not *have* bootblocks!). fdisk depended on magic in the /boot/mbr file to initialize some fields. ======== fdisk is not compiled for ia64 anymore since the introduction of gpart. The same holds for bsdlabel. So, that means that the hack is not needed anymore. FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Sat Apr 9 00:20:11 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B96BB1065672; Sat, 9 Apr 2011 00:20:11 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 808728FC14; Sat, 9 Apr 2011 00:20:11 +0000 (UTC) Received: from SBHFISLREXT03 ([10.132.254.62]) by SCSFISLTC02 (8.14.3/8.14.3) with ESMTP id p38NZtJW028921; Fri, 8 Apr 2011 18:35:55 -0500 Received: from SBHFISLTCGW04.FNFIS.COM (Not Verified[10.132.248.123]) by SBHFISLREXT03 with MailMarshal (v6, 5, 4, 7535) id ; Fri, 08 Apr 2011 18:36:03 -0500 Received: from sbhfisltcgw02.FNFIS.COM ([10.132.248.122]) by SBHFISLTCGW04.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Apr 2011 18:35:55 -0500 Received: from [127.0.0.1] ([10.132.254.136]) by sbhfisltcgw02.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Apr 2011 18:35:54 -0500 References: <20110408084232.GA28116@sh4-5.1blu.de> <4D9EE09F.6050409@FreeBSD.org> <20110408120335.GA2648@sh4-5.1blu.de> From: Devin Teske Content-Type: text/plain; charset=utf-8 In-Reply-To: <20110408120335.GA2648@sh4-5.1blu.de> Message-Id: <187B7694-2094-473A-9A57-4649494A7F3E@vicor.com> Date: Fri, 8 Apr 2011 08:57:11 -0700 To: Matthias Apitz Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (iPad Mail 8G4) X-Mailer: iPad Mail (8G4) X-OriginalArrivalTime: 08 Apr 2011 23:35:54.0780 (UTC) FILETIME=[B4452DC0:01CBF645] X-Mailman-Approved-At: Sat, 09 Apr 2011 01:59:19 +0000 Cc: "freebsd-current@freebsd.org" , Dimitry Andric , "freebsd-questions@freebsd.org" Subject: Re: vmware-tools-freebsd && "No drivers for x.org version: 7.6.5." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 00:20:11 -0000 On Apr 8, 2011, at 5:03 AM, Matthias Apitz wrote: > El d=C3=ADa Friday, April 08, 2011 a las 12:17:03PM +0200, Dimitry Andric= escribi=C3=B3: >=20 >> On 2011-04-08 10:42, Matthias Apitz wrote: >>> I have FreeBSD 9-CURRENT up and running in a VMware Workstation 7.x and >>> I tried to install the vmware-tools-freebsd of VMware to get the driver >>> for Xorg, but it seems that X.org 7.6.5. is not supported. My other VM >>> runs a 8-CURRENT with X.org 7.4_1 which works fine. >>>=20 >>> Any idea how to solve this? A co-worker and I recently went through this. Seems the trick is to install= xf86-video-vmware-10.16.9 (we are using 8.1-RELEASE), then re-run the vmwa= re-config.pl file that you un-packed from the vmware-tools tarball, then ru= n "X -configure" (as root), then copy /root/xorg.conf.new to /etc/X11/xorg.= conf (making appropriate backups first, of course). We were able to achieve= 1600x1200 resolution. --=20 Devin >>> Should I go back to X.org 7.4_1 in >>> 9-CURRENT? Or should I fake the vmware-tools installer to see X.org as >>> /.4 while it is 7.6.5? >>=20 >> X.org 7.5 already has VMware drivers, so you can just install the >> x11-drivers/xf86-input-vmmouse and x11-drivers/xf86-video-vmware ports. >>=20 >> Alternatively, run "make config" in x11-drivers/xorg-drivers, check the >> "VMMOUSE" and "VMWARE" entries, and rebuild this meta-port. >=20 > Dimitry,=20 >=20 > Thanks for your kind & fast answer; does this also mean that I could > completely get rid of the VMware' vmware-tools-freebsd? I'm using on the > 8-CURRENT system the emulators/open-vom-tools and will install them in > the 9-CURRENT too. >=20 > Thanks again >=20 > matthias >=20 > --=20 > Matthias Apitz > t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 > e - w http://www.unixarea.de/ > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.o= rg" _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. _____________ From owner-freebsd-current@FreeBSD.ORG Sat Apr 9 03:15:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2192106566C; Sat, 9 Apr 2011 03:15:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5A5908FC0A; Sat, 9 Apr 2011 03:15:52 +0000 (UTC) Received: by vxc34 with SMTP id 34so3910176vxc.13 for ; Fri, 08 Apr 2011 20:15:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=OSVyy1SxbQee9JlDCjVhRCq8oc9MobQXHo116SEPlkQ=; b=n3SDEe/n0qORgUMsixBVaTMWAnPQxtCDSGbwKYiML8hq0Nw075rRZ6mSbPfK5QpHa+ niaEBptz9vGaOCXYosFrie6J8tchbK55Iucmf3+nPrmNlkbbZcRupH05H7o4Upmu6imp dhZkQgjbbOLhBXb/b6Fri6VfqSh0vMo8/2E3Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=V/BV489mHcV1XQIXLgJkutQ1Nlue6LifIcOVyRH5ddt+7pAvwOc4EkwQGCVKWqPKol ZjhmZufQVBUkUi8hBkikzfv/e/L43cVKkFpBZjQFXZ1Cbg/sQyYGHJL09gstWD58HBvW RKjhfr6QFnRfwEjG+0peKlUARpD+OTmyMn46M= MIME-Version: 1.0 Received: by 10.52.72.17 with SMTP id z17mr1849579vdu.258.1302318951124; Fri, 08 Apr 2011 20:15:51 -0700 (PDT) Received: by 10.52.159.134 with HTTP; Fri, 8 Apr 2011 20:15:51 -0700 (PDT) Date: Sat, 9 Apr 2011 11:15:51 +0800 Message-ID: From: Adrian Chadd To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current , freebsd-mobile@freebsd.org Subject: new mailing list - freebsd-wireless@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 03:15:52 -0000 Hi all, I've just organised a new mailing list for wireless related development, discussion and bug fixing. Please subscribe to freebsd-wireless@freebsd.org and ask wireless related things there. Although I (and others) keep an eye on the other mailing lists, you'll be more likely to get a response if you instead email the wireless list. Thanks, adrian From owner-freebsd-current@FreeBSD.ORG Sat Apr 9 06:34:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F030F106566B; Sat, 9 Apr 2011 06:34:36 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 894768FC13; Sat, 9 Apr 2011 06:34:36 +0000 (UTC) Received: by iwn33 with SMTP id 33so4909951iwn.13 for ; Fri, 08 Apr 2011 23:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=nr+1o3ga5JhKVHay4qEwL+yImKRr9fb7OHVN6/xdCK4=; b=fUPjR7O9gMFBFQKtoPQAK2Y/bib7hRt/WJ0xzAOBEqODauj10lIV3IRMtN4vUG6tIX 8aZpVCw35fvadjUu/Sk9YcUXqq21Ik+IVgD0Sb6ZJ1WCGfUBqMyH/Q26/BPc6FAfhw3L xaqW+YVtudSk3FXCoOzIxweiRWAOBVsu89J0o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=Ecd4lPH0scJw5ABoeqn58OhOdRO/Jxoo76QrM4P8c7p2wIolUY9wJ3r6kzbg89v5X5 7UQxsBR4UB2iNhgqUghNWVTHgqMJRseAby/DICBDcJPdhqNR3uzZK4bJkoDNGfBt6Dyq e/mc5HX+/Q+nIGOxRWPvfGJetAPgucNZRPqQ8= Received: by 10.43.65.132 with SMTP id xm4mr4317389icb.424.1302330876131; Fri, 08 Apr 2011 23:34:36 -0700 (PDT) Received: from DataIX.net (adsl-99-190-87-163.dsl.klmzmi.sbcglobal.net [99.190.87.163]) by mx.google.com with ESMTPS id t1sm1362346ibm.38.2011.04.08.23.34.34 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2011 23:34:35 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p396YXtM072236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Apr 2011 02:34:33 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p396YWXQ072226; Sat, 9 Apr 2011 02:34:32 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Sat, 9 Apr 2011 02:34:31 -0400 From: "J. Hellenthal" To: Adrian Chadd Message-ID: <20110409063431.GC91335@DataIX.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5G06lTa6Jq83wMTw" Content-Disposition: inline In-Reply-To: X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: FreeBSD Net , freebsd-current , freebsd-mobile@freebsd.org Subject: Re: new mailing list - freebsd-wireless@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 06:34:37 -0000 --5G06lTa6Jq83wMTw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 09, 2011 at 11:15:51AM +0800, Adrian Chadd wrote: >Hi all, > >I've just organised a new mailing list for wireless related development, >discussion and bug fixing. > >Please subscribe to freebsd-wireless@freebsd.org and ask wireless related >things there. > >Although I (and others) keep an eye on the other mailing lists, you'll be >more likely to get a response if you instead email the wireless list. > Hey! good idea. --=20 J. Hellenthal --5G06lTa6Jq83wMTw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNn/33AAoJEJBXh4mJ2FR+aF8H/0p3ZbkCRhnC017lu9OQjfa3 8F9u/C8hfPcL0zgms2xqfWpxo+n2We2uzTDkBTf870U76kmeVoakIhAIMWlAjL2s XVO1YPuguutMYXyQmOkslgppxDAF7BvPZ76L6N9BC6EiOndt94VkfRHIb1/Qc9js OQiTEOaE7kthmkPG3pdU4FhbjVutl0p4THumYm3HjOrGrh18k2jzSu8hNi8dcUe0 4OJtXHJITNN055OtFJckMtQQneAZmhZJZj+1h3qIKzrmDZttXqWa85lb9Uj7vtbL Bmzp3al50e5f0eYxrlvxxmPinOi95dq7kzGYZROnlAK0y3qlfozi9QcSxwgdweE= =6+DU -----END PGP SIGNATURE----- --5G06lTa6Jq83wMTw-- From owner-freebsd-current@FreeBSD.ORG Sat Apr 9 08:08:53 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41737106564A; Sat, 9 Apr 2011 08:08:53 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from services.syscare.sk (services.syscare.sk [188.40.39.36]) by mx1.freebsd.org (Postfix) with ESMTP id 007968FC0C; Sat, 9 Apr 2011 08:08:52 +0000 (UTC) Received: from services.syscare.sk (services [188.40.39.36]) by services.syscare.sk (Postfix) with ESMTP id B3C5C94E7F; Sat, 9 Apr 2011 09:43:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.syscare.sk ([188.40.39.36]) by services.syscare.sk (services.rulez.sk [188.40.39.36]) (amavisd-new, port 10024) with ESMTP id EAXcr2jP3HGN; Sat, 9 Apr 2011 09:43:51 +0200 (CEST) Received: from danger-mbp.local (188-167-63-91.dynamic.chello.sk [188.167.63.91]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: danger@rulez.sk) by services.syscare.sk (Postfix) with ESMTPSA id 9113C94E6A; Sat, 9 Apr 2011 09:43:51 +0200 (CEST) Message-ID: <4DA00E3A.8020009@FreeBSD.org> Date: Sat, 09 Apr 2011 09:43:54 +0200 From: Daniel Gerzo Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17pre) Gecko/20110331 Lanikai/3.1.10pre MIME-Version: 1.0 To: current@freebsd.org, hackers@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Fwd: HEADSUP: Call for FreeBSD Status Reports - 1Q/2011 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 08:08:53 -0000 Hello, I would like to remind you that the submission due date (April 15th) is approaching quickly and to this date I have received _only_ 3 submissions. Please try to find a few minutes and submit your reports so that we can inform our community about the progress made in the first quarter of 2011. Thanks! -------- Original Message -------- Subject: HEADSUP: Call for FreeBSD Status Reports - 1Q/2011 Date: Mon, 21 Mar 2011 18:19:23 +0100 From: Daniel Gerzo Organization: The FreeBSD Project To: , Dear all, I would like to remind you that the next round of status reports covering the first quarter of 2011 is due on April 15th, 2011. As this initiative is very popular among our users, I would like to ask you to submit your status reports soon, so that we can compile the report on time. Do not hesitate and write us a few lines; a short description about what you are working on, what your plans and goals are, or any other information that you consider interested is always welcome. This way we can inform our community about your great work! Check out the reports from the past to get some inspiration of what your submission should look like. If you know about a project that should be included in the status report, please let us know as well, so we can poke the responsible people to provide us with something useful. Updates to submissions from the last report are welcome too. Note that the submissions are accepted from anyone involved within the FreeBSD community, you do not have to be a FreeBSD committer. Anything related to FreeBSD can be covered. Please email us the filled-in XML template which can be found at http://www.freebsd.org/news/status/report-sample.xml to monthly@FreeBSD.org, or alternatively use our web based form located at http://www.freebsd.org/cgi/monthly.cgi. For more information, please visit http://www.freebsd.org/news/status/. We are looking forward to see your submissions! -- Kind regards Daniel Gerzo From owner-freebsd-current@FreeBSD.ORG Sat Apr 9 15:39:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 802E91065670; Sat, 9 Apr 2011 15:39:35 +0000 (UTC) (envelope-from eng.mufic@gmail.com) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 449918FC38; Sat, 9 Apr 2011 15:39:34 +0000 (UTC) Received: by pxi6 with SMTP id 6so4222334pxi.17 for ; Sat, 09 Apr 2011 08:39:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=5xw2gds45PGShz/ZIYaG3S71Wh2SWR3JBJAhtd8+X7U=; b=H6RymDQHTA4FUTueX9538mXitAnqzOXq+pvgDTiDrgrm1VW8lsL7Foe/CTw2UZtXmQ Nj02frBu7oNPu+8eUKmQwnw81WzfUMT2OcmdFsFCBlwXTvcXRg+08ejY732sCKxPQwxi OqKdakG42Bv1aAo7lhqfqcZEjWWPL11xNqw6s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=NIBWht3/fNCeIBdQxTNeleNxRwN0EWStkz8Ar0GZ8f9sWeFxfiiTv7H2PQioWZQ+aN UttLy3tUBi6Ie30aPmglw5A3HgNTiYY1hDYASGwY19nk9Yy8WyLPuc/Q/X7s7jQ5INi5 uTcVZGkMhpRdgvpp5MOraC9MGsgPgrrul702o= MIME-Version: 1.0 Received: by 10.142.150.16 with SMTP id x16mr3238332wfd.173.1302361732117; Sat, 09 Apr 2011 08:08:52 -0700 (PDT) Sender: eng.mufic@gmail.com Received: by 10.68.65.200 with HTTP; Sat, 9 Apr 2011 08:08:52 -0700 (PDT) In-Reply-To: References: Date: Sat, 9 Apr 2011 17:08:52 +0200 X-Google-Sender-Auth: W7w9ZoZ64AG0MFGuE216VHojiQ4 Message-ID: From: Mohammed Farrag To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Net , freebsd-current , freebsd-mobile@freebsd.org Subject: Re: new mailing list - freebsd-wireless@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 15:39:35 -0000 On Sat, Apr 9, 2011 at 5:15 AM, Adrian Chadd wrote: > Hi all, > > I've just organised a new mailing list for wireless related development, > discussion and bug fixing. > > Please subscribe to freebsd-wireless@freebsd.org and ask wireless related > things there. > > Although I (and others) keep an eye on the other mailing lists, you'll be > more likely to get a response if you instead email the wireless list. > > Thanks, > > > adrian > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > Good job guy. Congrats -- *Mohammed Farrag* *FreeBSD Contributor* From owner-freebsd-current@FreeBSD.ORG Sat Apr 9 15:59:09 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E47A2106564A; Sat, 9 Apr 2011 15:59:09 +0000 (UTC) (envelope-from chris.richardson.bsd@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3154C8FC20; Sat, 9 Apr 2011 15:59:08 +0000 (UTC) Received: by wwk4 with SMTP id 4so1418451wwk.1 for ; Sat, 09 Apr 2011 08:59:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=gZPTCj7bUeaPzYlATgyoA/xmNwrFUq00/YTEldw4bMg=; b=rC0k/s2VIrqahs38p+ia8VCdigpbMp1PHopsp2kPrNCAUxPQ7QIKuoTsShWMMBLtdk smsNvJ6+YMTJVXKVchVQFIh4GYKUjNiCa+5VII3YR1/qLblgV9Pk8DX4g5y2o+nHPo24 Pe63Ed64uPA/RqR+U+0qeUYl4ikmgyA7cugaQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=u5hQ/OJf1vyjqv5u1UFckyKIUU8Eca6dOxSY3bo55gcvUpbPI3VXH2lV0PmoIXl0WA I727IEPWDVFbYB9DeW5OiKGF/280LZmWNawZ597F6qsihyomHmPdxtIxGDqoYzDAHzpu ZTG2BffeULs9h7ZvYKP3RV47hf02cnaySEYjo= MIME-Version: 1.0 Received: by 10.227.131.23 with SMTP id v23mr3374316wbs.53.1302363096212; Sat, 09 Apr 2011 08:31:36 -0700 (PDT) Received: by 10.227.143.133 with HTTP; Sat, 9 Apr 2011 08:31:36 -0700 (PDT) Date: Sat, 9 Apr 2011 17:31:36 +0200 Message-ID: From: Chris Richardson To: freebsd-hackers@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Kernel Tracking Question.. regarding kernel and boot files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 15:59:10 -0000 Hi all, I am totally new to FreeBSD. I was involved within project which will trace the kernel. I used ktrace but I could not get appropriate results about the files being opened. I don't see any of the boot files boot0-1 or 2 in the ktrace.out file. Where did they go? Is ktrace the best "trace suite" for freebsd kernel? What about going through source code .. Is it better to use Combination of Ecllipse/Qemu and FreeBSD Source tree? Does this method will provide us with someway to see how booting process invokes the kernel to memory ? Any help will be appreciated. Yours, Chris From owner-freebsd-current@FreeBSD.ORG Sat Apr 9 16:38:21 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFE231065670 for ; Sat, 9 Apr 2011 16:38:21 +0000 (UTC) (envelope-from simon@nitro.dk) Received: from emx.nitro.dk (emx.nitro.dk [IPv6:2a01:4f8:120:7384::102]) by mx1.freebsd.org (Postfix) with ESMTP id 49F5B8FC14 for ; Sat, 9 Apr 2011 16:38:21 +0000 (UTC) Received: from mailscan.leto.nitro.dk (mailscan.leto.nitro.dk [127.0.1.4]) by emx.nitro.dk (Postfix) with ESMTP id 58D451981; Sat, 9 Apr 2011 16:38:20 +0000 (UTC) Received: from emx.nitro.dk ([127.0.1.2]) by mailscan.leto.nitro.dk (mailscan.leto.nitro.dk [127.0.1.4]) (amavisd-new, port 10024) with LMTP id PV+QKbJpUOrA; Sat, 9 Apr 2011 16:38:18 +0000 (UTC) Received: from [IPv6:2001:470:28:41b:c62c:3ff:fe2a:b559] (unknown [IPv6:2001:470:28:41b:c62c:3ff:fe2a:b559]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by emx.nitro.dk (Postfix) with ESMTPSA id E6B6C1980; Sat, 9 Apr 2011 16:38:17 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Simon L. B. Nielsen" In-Reply-To: <4D9C6D21.1020006@protected-networks.net> Date: Sat, 9 Apr 2011 18:38:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <944ABFBC-D009-4E11-BE91-3E82F495F57C@nitro.dk> References: <4D9C6D21.1020006@protected-networks.net> To: Michael Butler X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: current@FreeBSD.org Subject: Re: SVN -> CVS burp? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 16:38:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6 Apr 2011, at 15:39, Michael Butler wrote: > It seem that CVS hasn't seen any "src" updates sine the burp involving > "/usr/ports/net/unison232/files/patch-update.mli.diff". svn2cvs was down for a bit on April 6, but as ports isn't in SVN that's = not related to anything there. FWIW, see also: http://twitter.com/clusteradm - --=20 Simon L. B. Nielsen -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk2gi3gACgkQBJx0gP90kKsrfwCbBQf4B7ntp4PPO4QFSHw3Xrdz w5oAnjlPHnrOY2z3MeT8Z13cm0c5eQHg =3DVabl -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sat Apr 9 20:19:40 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E61C106566B; Sat, 9 Apr 2011 20:19:40 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5E5678FC20; Sat, 9 Apr 2011 20:19:38 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA26511; Sat, 09 Apr 2011 23:19:37 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Q8ed6-000L7P-Q2; Sat, 09 Apr 2011 23:19:36 +0300 Message-ID: <4DA0BF57.2090307@FreeBSD.org> Date: Sat, 09 Apr 2011 23:19:35 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110308 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org References: <20110331223339.GA13682@freebsd.org> <201104010843.47367.jhb@freebsd.org> <20110404204316.GA11367@freebsd.org> <4D9D9917.3030102@FreeBSD.org> <4D9EA24E.2030401@FreeBSD.org> In-Reply-To: <4D9EA24E.2030401@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: multiple issues with devstat_*(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 20:19:40 -0000 on 08/04/2011 08:51 Andriy Gapon said the following: > on 07/04/2011 13:59 Alexander Motin said the following: >> Any objections? Or SCSI/IDE there expected to mean command set? >> > > Sorry for saying something potentially stupid, but... do we actually have any > reason to make that distinction from any practical point? And the following could be related here too: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/81497 -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Apr 9 20:35:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27389106564A for ; Sat, 9 Apr 2011 20:35:13 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout019.mac.com (asmtpout019.mac.com [17.148.16.94]) by mx1.freebsd.org (Postfix) with ESMTP id 09F5F8FC08 for ; Sat, 9 Apr 2011 20:35:12 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [10.1.2.92] ([173.200.187.194]) by asmtp019.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LJE005R1JU4HC70@asmtp019.mac.com>; Sat, 09 Apr 2011 13:34:53 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-04-09_07:2011-04-09, 2011-04-09, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1104090086 From: Chuck Swiger In-reply-to: Date: Sat, 09 Apr 2011 13:34:52 -0700 Message-id: References: To: Chris Richardson X-Mailer: Apple Mail (2.1084) Cc: freebsd-hackers@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: Kernel Tracking Question.. regarding kernel and boot files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 20:35:13 -0000 Hi, Chris-- [ ...Reply-to: set to direct towards the most appropriate list... ] On Apr 9, 2011, at 8:31 AM, Chris Richardson wrote: > I am totally new to FreeBSD. I was involved within project which will > trace the kernel. I used ktrace but I could not get appropriate results > about the files being opened. I don't see any of the boot files boot0-1 or 2 > in the ktrace.out file. Where did they go? The bootstrap loader stages are what loads and runs the kernel. ktrace isn't available until afterwards, when the kernel is running. > Is ktrace the best "trace suite" for freebsd kernel? Kinda depends on what you are doing. Setting up good logging and making userland interfaces for getting to useful information (cf vmstat, ps, iostat, etc) is more likely to be useful over the longer run. > What about going through source code .. Is it better to > use Combination of Ecllipse/Qemu and FreeBSD Source tree? Eclipse is an editor. If you like it in particular, free free to use it, otherwise pick something else you'd prefer to use for C code. > Does this method will provide us with someway to see how booting process invokes > the kernel to memory ? Any help will be appreciated. You're asking about the process here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/boot-blocks.html ...? Frankly, none of these are especially big, start by reviewing the source code for 'em. Regards, -- -Chuck From owner-freebsd-current@FreeBSD.ORG Sat Apr 9 21:51:20 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F498106564A; Sat, 9 Apr 2011 21:51:20 +0000 (UTC) (envelope-from chris.richardson.bsd@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id B9C1E8FC14; Sat, 9 Apr 2011 21:51:19 +0000 (UTC) Received: by wyf23 with SMTP id 23so4504531wyf.13 for ; Sat, 09 Apr 2011 14:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Avn8NVJ548QWD/JwzOUFqKhBYWQC9I7oF7ndfZYoS/0=; b=GEWDFK4/kO5v9KASeEIAkFBODIGwcegtijq4BwqZmp3FpbKUINPE+/vmYXCBsFck3G tse5eHBDzP86WMllBcNKn/Xip6gpldFGPzotlBXlZPigWBZsac9OelXFjs4lA8AI/3OJ 8N8ihqxfieIYrXRGxZS8zucY5tJKVrrg3WSxg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=M3KnSH5C3QKM/nZ+xIrbPLt2i3NRbkf4WiEIz9D5dlklE3xMLXNtH+rDNJ6XGTRt4H odfe3O7sa828+lQkVh2f4ojp+ROod5I0NX0w4jJzryr306rw7E4GWBcxkxmW7MNx64i6 A7o361w8n+ARNCBJIuZ0VR6mShEKthepBfkrQ= MIME-Version: 1.0 Received: by 10.227.157.68 with SMTP id a4mr3521839wbx.198.1302385878663; Sat, 09 Apr 2011 14:51:18 -0700 (PDT) Received: by 10.227.143.133 with HTTP; Sat, 9 Apr 2011 14:51:18 -0700 (PDT) In-Reply-To: References: Date: Sat, 9 Apr 2011 23:51:18 +0200 Message-ID: From: Chris Richardson To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: Kernel Tracking Question.. regarding kernel and boot files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 21:51:20 -0000 On Sat, Apr 9, 2011 at 10:34 PM, Chuck Swiger wrote: > Hi, Chris-- > > [ ...Reply-to: set to direct towards the most appropriate list... ] > > On Apr 9, 2011, at 8:31 AM, Chris Richardson wrote: > > I am totally new to FreeBSD. I was involved within project which will > > trace the kernel. I used ktrace but I could not get appropriate results > > about the files being opened. I don't see any of the boot files boot0-1 > or 2 > > in the ktrace.out file. Where did they go? > > The bootstrap loader stages are what loads and runs the kernel. > ktrace isn't available until afterwards, when the kernel is running. > > > Is ktrace the best "trace suite" for freebsd kernel? > > Kinda depends on what you are doing. Setting up good logging and making > userland > interfaces for getting to useful information (cf vmstat, ps, iostat, etc) > is > more likely to be useful over the longer run. > > What about if I wanna see the interaction between boot process and kernel loading. > > What about going through source code .. Is it better to > > use Combination of Ecllipse/Qemu and FreeBSD Source tree? > > Eclipse is an editor. If you like it in particular, free free to use it, > otherwise pick something else you'd prefer to use for C code. > > > Does this method will provide us with someway to see how booting process > invokes > > the kernel to memory ? Any help will be appreciated. > > You're asking about the process here: > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/boot-blocks.html > > ...? Frankly, none of these are especially big, start by reviewing the > source > code for 'em. > > Yeah. this file provides me with the stages in theoretical way. How about implementing it using qemu to emulate livecd to see what is going on boot0. Do you have an idea about that ? Good Luck, > Regards, > -- > -Chuck > > > From owner-freebsd-current@FreeBSD.ORG Sat Apr 9 20:39:09 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57DFF1065670; Sat, 9 Apr 2011 20:39:09 +0000 (UTC) (envelope-from kline@thought.org) Received: from thought.org (plato.thought.org [209.180.213.209]) by mx1.freebsd.org (Postfix) with ESMTP id 2873C8FC12; Sat, 9 Apr 2011 20:39:08 +0000 (UTC) Received: by thought.org (Postfix, from userid 1001) id 347F9E805AA; Sat, 9 Apr 2011 13:20:47 -0700 (PDT) Date: Sat, 9 Apr 2011 13:20:47 -0700 From: Gary Kline To: Daniel Gerzo Message-ID: <20110409202047.GA12600@thought.org> References: <4DA00E3A.8020009@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DA00E3A.8020009@FreeBSD.org> X-Organization: Thought Unlimited. Public service Unix since 1986. X-Of_Interest: With 24++ years of service to the Unix community. User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Sat, 09 Apr 2011 23:03:41 +0000 Cc: hackers@freebsd.org, current@freebsd.org Subject: Re: Fwd: HEADSUP: Call for FreeBSD Status Reports - 1Q/2011 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 20:39:09 -0000 For my short post [to everyone], I'll top post. I am/have-been trying to write a user-side audio, "key-click" driver for every Open OS--essentially the BSD distros and the Linux. I am looking for people interested and who know both python and C/C++. -g On Sat, Apr 09, 2011 at 09:43:54AM +0200, Daniel Gerzo wrote: > Hello, > > I would like to remind you that the submission due date (April 15th) > is approaching quickly and to this date I have received _only_ 3 > submissions. > > Please try to find a few minutes and submit your reports so that we > can inform our community about the progress made in the first > quarter of 2011. > > Thanks! > > -------- Original Message -------- > Subject: HEADSUP: Call for FreeBSD Status Reports - 1Q/2011 > Date: Mon, 21 Mar 2011 18:19:23 +0100 > From: Daniel Gerzo > Organization: The FreeBSD Project > To: , > > Dear all, > > I would like to remind you that the next round of status reports > covering the first quarter of 2011 is due on April 15th, 2011. As this > initiative is very popular among our users, I would like to > ask you to submit your status reports soon, so that we can compile the > report on time. > > Do not hesitate and write us a few lines; a short description about > what you are working on, what your plans and goals are, or any other > information that you consider interested is always welcome. This way > we can inform our community about your great work! > Check out the reports from the past to get some inspiration of what > your submission should look like. > > If you know about a project that should be included in the status > report, please let us know as well, so we can poke the responsible > people to provide us with something useful. Updates to submissions from > the last report are welcome too. > > Note that the submissions are accepted from anyone involved within the > FreeBSD community, you do not have to be a FreeBSD committer. Anything > related to FreeBSD can be covered. > > Please email us the filled-in XML template which can be found at > http://www.freebsd.org/news/status/report-sample.xml to > monthly@FreeBSD.org, or alternatively use our web based form located at > http://www.freebsd.org/cgi/monthly.cgi. > > For more information, please visit http://www.freebsd.org/news/status/. > > We are looking forward to see your submissions! > > -- > Kind regards > Daniel Gerzo > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Gary Kline kline@thought.org http://www.thought.org Public Service Unix Journey Toward the Dawn, E-Book: http://www.thought.org The 7.98a release of Jottings: http://jottings.thought.org