From owner-freebsd-current@FreeBSD.ORG Sun Nov 7 02:50:26 2010 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 1441E106566B; Sun, 7 Nov 2010 02:50:26 +0000 (UTC) (envelope-from weongyo.jeong@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 C8BDB8FC08; Sun, 7 Nov 2010 02:50:25 +0000 (UTC) Received: by pzk12 with SMTP id 12so205459pzk.13 for ; Sat, 06 Nov 2010 19:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:organization:x-operation-sytem; bh=d3KxkfekhcD4Ndm7Mui5q+PXyovgxlAwzsN5vwlhkk4=; b=lwKjPDe79lOV11qrxB4IgEWQFw/KYK/F2I8svifiFKSagcK4d79dNAlpTi6M76Myu3 IPbziL4qokHZiSs9n/HO8cDcIhCmWnWDviN/MDCUBxisgHMDY79b7GeSFdIeAtWZ0iAO GELpOy3T22ddOlugLZ6VOQqcXQLLVFPsM+aYk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent:organization:x-operation-sytem; b=aDmO7bxkLccsLic4Mb73Zpmjf+3EbBuqKNzeT7GjGEjVi9myZQFBPvGbe8Hd7bIUxZ 4sSWmSMNxv4KUBW1Av1StzoTnSeROYwJ2laY3roX6P+vHv7sWrTNFMZYME8zYLnThiOt vXWuLMgJ1NMHytdg7FNEMI2jxEQrgt+/KNtA0= Received: by 10.142.142.18 with SMTP id p18mr2997649wfd.398.1289096594815; Sat, 06 Nov 2010 19:23:14 -0700 (PDT) Received: from weongyo ([174.35.1.224]) by mx.google.com with ESMTPS id q13sm5017643wfc.5.2010.11.06.19.23.11 (version=SSLv3 cipher=RC4-MD5); Sat, 06 Nov 2010 19:23:12 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Sat, 06 Nov 2010 19:23:18 -0700 From: Weongyo Jeong Date: Sat, 6 Nov 2010 19:23:18 -0700 To: Hans Petter Selasky Message-ID: <20101107022318.GF92881@weongyo> Mail-Followup-To: Hans Petter Selasky , freebsd-current@freebsd.org, freebsd-arch@freebsd.org, Matthew Fleming , freebsd-usb@freebsd.org References: <201011012054.59551.hselasky@c2i.net> <201011051836.39697.hselasky@c2i.net> <201011051930.38530.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201011051930.38530.hselasky@c2i.net> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: freebsd-current@freebsd.org, Matthew Fleming , freebsd-usb@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 02:50:26 -0000 On Fri, Nov 05, 2010 at 07:30:38PM +0100, Hans Petter Selasky wrote: > Hi, > > In the patch attached to this e-mail I included Matthew Fleming's patch > aswell. > > 1) I renamed taskqueue_cancel() into taskqueue_stop(), hence that resembles > the words of the callout and USB API's terminology for doing the same. > > 2) I turns out I need to have code in subr_taskqueue.c to be able to make the > operations atomic. > > 3) I did not update the manpage in this patch. Will do that before a commit. > > 4) My patch implements separate state keeping in "struct task_pair", which > avoids having to change any KPI's for now, like suggested by John Baldwin I > think. > > 5) In my implementation I hard-coded the priority argument to zero, so that > enqueuing is fast. > > Comments are welcome! The patch looks almost you moved usb_process.c code into taskqueue(9) that I means it still follows that a entry which enqueued at last should be executed at last. It seems that at least it's not a general for taskqueue(9). In my humble opinion it looks a trick. I think it'd better to find a general solution to solve it though I used sx(9) lock in my patches. regards, Weongyo Jeong From owner-freebsd-current@FreeBSD.ORG Sun Nov 7 13:53:31 2010 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 3632F1065695; Sun, 7 Nov 2010 13:53:31 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id A7F1A8FC08; Sun, 7 Nov 2010 13:53:30 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id oA7DrTnw094458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Nov 2010 14:53:29 +0100 (CET) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1289138009; bh=jvLTowREG6Ur5MQOOP8Z8tTu6rVrtCircfFLxLtRCkc=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; b=hm1ON2iUR5Fuq6HsdXUYYITuQtFCxselZ3v7Z317smOq040Jc8Ng2XoCv0JxEcJfo /hyvTOcQ9iOXBoLhfvHY/tf6yYUu0nDzOubI4t4vh5dtv2Nel+1JBGW4DV32ZULO3w AP8kAUcQXB/SH5qZEE0yPPaaGiv8F+kYC4/CMZIs= Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id oA7DrTte094457; Sun, 7 Nov 2010 14:53:29 +0100 (CET) (envelope-from uqs@spoerlein.net) Date: Sun, 7 Nov 2010 14:53:29 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: current@FreeBSD.org, fanf@FreeBSD.org Message-ID: <20101107135329.GL85693@acme.spoerlein.net> Mail-Followup-To: current@FreeBSD.org, fanf@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Tricky subversion import, what to do? 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, 07 Nov 2010 13:53:31 -0000 Hello, this is about importing unifdef 2.4, which has no significant code changes, but that's not the point. The wiki is of no help for this particular case. We have no exclusive vendor branch for unifdef, instead it has been converted to svn under vendor/CSRG/dist/usr.bin/unifdef/ and some parts of its history (eg. r1591) are copied from there: A /head/usr.bin/unifdef/Makefile (from /vendor/CSRG/dist/usr.bin/unifdef/Makefile:1590) A /head/usr.bin/unifdef/unifdef.1 (from /vendor/CSRG/dist/usr.bin/unifdef/unifdef.1:1590) A /head/usr.bin/unifdef/unifdef.c (from /vendor/CSRG/dist/usr.bin/unifdef/unifdef.c:1590) So, my first instinct would be to $ svn mv $FSVN/vendor/CSRG/dist/usr.bin/unifdef $FSVN/vendor/unifdef/dist (put all files (or just the necessary subset?) of unifdef-2.4 in vendor/unifdef/dist) $ svn ci $ svn cp $FSVN/vendor/unifdef/dist $FSVN/vendor/unifdef/2.4 $ svn cp $FSVN/vendor/unifdef/dist/unifdef.{c,1} $FSVN/head/contrib/unifdef/ $ svn rm head/usr.bin/unifdef/unifdef.{c,1} (but this part loses the actual history on head, as it was never committed to the vendor branch) (update usr.bin/unidef/Makefile to point to contrib/unifdef) $ svn ci But then again, the first steps could also be: $ svn cp head/usr.bin/unifdef vendor/unifdef/dist; svn ci $ svn cp vendor/unifdef/dist vendor/unifdef/2.3; svn ci This seems more reasonable to me, but I'm not sure what the policy is on "old stuff" under vendor/ From owner-freebsd-current@FreeBSD.ORG Sun Nov 7 14:31:30 2010 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 EF630106566B for ; Sun, 7 Nov 2010 14:31:30 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 929288FC0A for ; Sun, 7 Nov 2010 14:31:30 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAKdH1kyDaFvO/2dsb2JhbACDMJ9KqByQGoRVcwSEWIV9 X-IronPort-AV: E=Sophos;i="4.58,310,1286164800"; d="scan'208";a="99890952" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 07 Nov 2010 09:31:12 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 4D67CB3F55; Sun, 7 Nov 2010 09:31:12 -0500 (EST) Date: Sun, 7 Nov 2010 09:31:12 -0500 (EST) From: Rick Macklem To: pyunyh@gmail.com Message-ID: <794553731.206411.1289140272239.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20101106023345.GC22715@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_206410_719282442.1289140272238" X-Originating-IP: [99.225.56.115] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL4_64) Cc: freebsd-current@freebsd.org Subject: Re: re(4) driver dropping packets when reading NFS 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: Sun, 07 Nov 2010 14:31:31 -0000 ------=_Part_206410_719282442.1289140272238 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit > > I've added a counter of how many times re_rxeof() gets called, but > > then > > returns without handling any received packets (I think because > > RL_RDESC_STAT_OWN is set on the first entry it looks at in the rcv. > > ring.) > > > > This count comes out as almost the same as the # of missed frames > > (see > > "rxe did 0:" in the attached stats). > > > > So, I think what is happenning about 10% of the time is that > > re_rxeof() > > is looking at the ring descriptor before it has been "updated" and > > then > > returns without handling the packet and then it doesn't get called > > again > > because the RL_ISR bit has been cleared. > > > > When "options DEVICE_POLLING" is specified, it works ok, because it > > calls > > re_rxeof() fairly frequently and it doesn't pay any attention to the > > RL_ISR > > bits. > > > > That's one of possible theory. See below for another theory. > Well, my above theory is bunk. I hacked it so it would continue to run re_int_task() until the receive descriptor was valid and it just hummed away until the next frame was received. > > Now, I don't know if this is a hardware flaw on this machine or > > something > > that can be fixed in software? I know diddly about the current > > driver > > I highly doubt it could be hardware issue. > You have much more confidence in the hardware guys than I do;-) (see summary below) > > Another possibility I have in mind is the controller would have > reported RL_ISR_RX_OVERRUN but re(4) didn't check that condition. > The old data sheet I have does not clearly mention when it is set > and what other bits of RL_ISR register is affected from the bit. > If RL_ISR_RX_OVERRUN bit is set when there are no more free RX > descriptors available to controller and RL_ISR_RX_ERR is not set > when RL_ISR_RX_OVERRUN is set, re(4) have ignored that event. > Because driver ignored that error interrupt, the next error > interrupt would be RL_ISR_FIFO_OFLOW error and this time it would > be served in re_rxeof() and will refill RX buffers. > However driver would have lost lots of frames received between the > time window RL_ISR_RX_OVERRUN error and RL_ISR_FIFO_OFLOW error. > RL_ISR_RX_OVERRUN never gets set during the testing I do. > If this theory is correct, the attached patch may mitigate the > issue. > Your re.intr.patch4 had no effect. I've tried a bunch of similar other ones that also had no effect. > > > Otherwise, I can live with "options DEVICE_POLLING". > > This turned out to be my mistake. "options DEVICE_POLLING" doesn't help. (I think I screwed up by running a test without it enabled and then re-running the test after enabling it. It ran fast because I had primed the cache, oops.) Summary sofar: - almost all variants I've tried result in a "missed frame" rate of 8-11%, which gives you about 500Kbytes/sec read rate. here are some of the things I tried that didn't change this: - disabling the hardware offload stuff like checksums - changing the size of the receive ring (except making it really small seemed to degrade perf. a little) - enabling use of the I/O map ** - as noted above "options DEVICE_POLLING" doesn't actually help - enabling RE_TX_MODERATION - changing the value of maxpkts in re_rxeof() smaller seems to make the miss rate slightly higher - when the above is happening, the # of times re_rxeof() finds the first descriptor in the receive ring with the frame still owned by the device is just slightly lower than the # of "missed frames" reported by the chip's stats. - about half of these interrupts are due to RL_ISR_FIFO_OFLOW and the other half RL_ISR_RX_OK. (As noted above, I never see RL_ISR_RX_OVERRUN.) The only combination that I've come up with that reduces the "missed frame" rate significantly is the little patch I passed along before. It does 3 things: - disables msi - doesn't clear RL_IMR in re_intr() - doesn't set RL_IMR in re_int_task(), since the bits weren't cleared (This little patch is attached, in case anyone is interested in trying it.) When I run with this variant the "missed frame" rate drops to less than 2% (1.something) and I get about 5Mbytes/sec read rate on the 100Mbps port. I'm out of ideas w.r.t. what to try. I think it takes someone who knows what actually causes the chip to "miss a frame" to solve it? I don't know why the little patch I descibe above reduces, but does not eliminate the "missed frame" problem. (Since the chip seems to know it "missed the frame", it smells hardware related to me?) I'd think that RL_ISR_FIFO_OFLOW would mean that it ran out of rcv. buffers, but there's 256 of them (and I tried increasing it to 512 with no effect). Again, I think it takes someone familiar with the hardware to say why this would be happening? Anyhow, I'm out of theories/ideas. I can easily test any patch that seems like it ight help. Thanks for your assistance, rick ------=_Part_206410_719282442.1289140272238 Content-Type: text/x-patch; name=if_re.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=if_re.patch LS0tIGlmX3JlLmMuc2F2CTIwMTAtMTEtMDcgMDk6MjY6MzMuMDAwMDAwMDAwIC0wNTAwCisrKyBp Zl9yZS5jCTIwMTAtMTEtMDcgMDk6Mjc6MTIuMDAwMDAwMDAwIC0wNTAwCkBAIC0xNTcsNyArMTU3 LDcgQEAKICNpbmNsdWRlICJtaWlidXNfaWYuaCIKIAogLyogVHVuYWJsZXMuICovCi1zdGF0aWMg aW50IG1zaV9kaXNhYmxlID0gMDsKK3N0YXRpYyBpbnQgbXNpX2Rpc2FibGUgPSAxOwogVFVOQUJM RV9JTlQoImh3LnJlLm1zaV9kaXNhYmxlIiwgJm1zaV9kaXNhYmxlKTsKIHN0YXRpYyBpbnQgcHJl ZmVyX2lvbWFwID0gMDsKIFRVTkFCTEVfSU5UKCJody5yZS5wcmVmZXJfaW9tYXAiLCAmcHJlZmVy X2lvbWFwKTsKQEAgLTIyMjIsNyArMjIyMiw2IEBACiAJc3RhdHVzID0gQ1NSX1JFQURfMihzYywg UkxfSVNSKTsKIAlpZiAoc3RhdHVzID09IDB4RkZGRiB8fCAoc3RhdHVzICYgUkxfSU5UUlNfQ1BM VVMpID09IDApCiAgICAgICAgICAgICAgICAgcmV0dXJuIChGSUxURVJfU1RSQVkpOwotCUNTUl9X UklURV8yKHNjLCBSTF9JTVIsIDApOwogCiAJdGFza3F1ZXVlX2VucXVldWVfZmFzdCh0YXNrcXVl dWVfZmFzdCwgJnNjLT5ybF9pbnR0YXNrKTsKIApAQCAtMjI5Niw3ICsyMjk1LDYgQEAKIAkJcmV0 dXJuOwogCX0KIAotCUNTUl9XUklURV8yKHNjLCBSTF9JTVIsIFJMX0lOVFJTX0NQTFVTKTsKIH0K IAogc3RhdGljIGludAo= ------=_Part_206410_719282442.1289140272238-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 7 17:37:49 2010 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 D954E106564A for ; Sun, 7 Nov 2010 17:37:49 +0000 (UTC) (envelope-from fanf2@hermes.cam.ac.uk) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by mx1.freebsd.org (Postfix) with ESMTP id 9AC6F8FC17 for ; Sun, 7 Nov 2010 17:37:49 +0000 (UTC) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:39568) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1PF8t9-0003Nk-Z8 (Exim 4.72) (return-path ); Sun, 07 Nov 2010 17:18:43 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1PF8t9-0001DP-SQ (Exim 4.67) (return-path ); Sun, 07 Nov 2010 17:18:43 +0000 Date: Sun, 7 Nov 2010 17:18:43 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: =?ISO-8859-15?Q?Ulrich_Sp=F6rlein?= Message-ID: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch X-Mailman-Approved-At: Sun, 07 Nov 2010 18:01:51 +0000 Cc: Tony Finch , freebsd-current@freebsd.org Subject: Re: Tricky subversion import, what to do? 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, 07 Nov 2010 17:37:49 -0000 > this is about importing unifdef 2.4, which has no significant code > changes, but that's not the point. I maintain unifdef and I haven't imported 2.4 because there are no code changes. Please leave it alone. Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. From owner-freebsd-current@FreeBSD.ORG Sun Nov 7 18:02:16 2010 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 1D3A91065696 for ; Sun, 7 Nov 2010 18:02:16 +0000 (UTC) (envelope-from sfourman@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 CB5AF8FC21 for ; Sun, 7 Nov 2010 18:02:15 +0000 (UTC) Received: by qwg8 with SMTP id 8so4038364qwg.13 for ; Sun, 07 Nov 2010 10:02:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=JC0x78vO6UjGH4bNmFGwZAP2wK7BzG/aqA8v8P+dDdY=; b=CkkAc8MFnrjo6YpJD23+bCJRfrPsgj+RBWcDp1DmSbGK3bR15wVVNOn1hem/UTp+8r xkFRO1myS2hkiP6VgJI9cckkS6u/4lyOCYCYuhT5XI23khSf3IewQVqs50VJ+3n3cGvI ugqkSSH6UFZBSI2oPEerAxeX27K95WaTcbspA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=snuIstJcQiK9NMoGX4EKZiaguHH7fxnbQlSRSNVxIP1SeyUCCqgEV+F6JOFKa8gTSj /zh3SrC59w3aPKYQa1VlHHMOaqcI5vCLdAWit0Nf8W/EXWQ1W2QNPzm7sy5SqWClinM4 k6wAEz4YEoc4/wZvqWVSpsvm6IrZxXeYg4tHQ= MIME-Version: 1.0 Received: by 10.229.189.140 with SMTP id de12mr4321110qcb.5.1289152933568; Sun, 07 Nov 2010 10:02:13 -0800 (PST) Received: by 10.229.80.129 with HTTP; Sun, 7 Nov 2010 10:02:13 -0800 (PST) Date: Sun, 7 Nov 2010 12:02:13 -0600 Message-ID: From: "Sam Fourman Jr." To: Jung-uk Kim , David Rhodus , FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: ACPI panic on boot recent HEAD 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, 07 Nov 2010 18:02:16 -0000 Hello list, here is a digital camera pic of a panic that happened while booting yesterdays Source tree http://www.puffybsd.com/IMG_4136.JPG here is a dmesg from a older current http://www.puffybsd.com/amddmesg.txt -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com From owner-freebsd-current@FreeBSD.ORG Sun Nov 7 19:18:08 2010 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 A30E41065670 for ; Sun, 7 Nov 2010 19:18:08 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 15AD18FC1D for ; Sun, 7 Nov 2010 19:18:06 +0000 (UTC) Received: from [77.25.182.25] (helo=tiny.Sisis.de.) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PFAka-0002lE-AU for freebsd-current@freebsd.org; Sun, 07 Nov 2010 20:18:05 +0100 Received: from tiny.Sisis.de. (localhost [127.0.0.1]) by tiny.Sisis.de. (8.14.3/8.14.3) with ESMTP id oA7JIHlq001320 for ; Sun, 7 Nov 2010 20:18:17 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de. (8.14.3/8.14.3/Submit) id oA7JIGwO001319 for freebsd-current@freebsd.org; Sun, 7 Nov 2010 20:18:16 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de.: guru set sender to guru@unixarea.de using -f Date: Sun, 7 Nov 2010 20:18:16 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org Message-ID: <20101107191815.GA1293@tiny> References: <20101104222336.GA6428@current.Sisis.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="/9DWx/yDrRhgMJTb" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20101104222336.GA6428@current.Sisis.de> X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.19 (2009-01-05) X-Con-Id: 51246 X-Originating-IP: 77.25.182.25 Subject: Re: laptop Acer Aspire One D250 / snd_hda(4) && internal mic not recording 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: Sun, 07 Nov 2010 19:18:08 -0000 --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit El día Thursday, November 04, 2010 a las 11:23:36PM +0100, Matthias Apitz escribió: > > > Hello, > > I have the above modell running 9-CURRENT, but can't get the build-in > mic recording, only the jack for the mic in the headset records fine in > Skype; ... I have another mini laptop, for years already, an EeePC 900 in which the internal mic works fine. I thought it would be a good idea to look in detail what the diff is between, because both are using snd_hda(4) for sound. It turned out, surprise I never realized this, that the EeePC has the same problem, but the other way around: only the internal mic is recording and the jack does not. Per default both mic (nid 24 and 25) are in association 2: hdac0: nid 24 0x01a19820 as 2 seq 0 Mic Jack jack 1 loc 1 color Pink misc 8 hdac0: nid 25 0x99a3092f as 2 seq 15 Mic Fixed jack 3 loc 25 color Unknown misc 9 I'm attaching both verbose messages of hdac, maybe some snd_hda(4) expert understands from the diff of both what the problem in both is. Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="hdac-acer.txt" hdac0: mem 0x58340000-0x58343fff irq 16 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: attempting to allocate 1 MSI vectors (1 supported) hdac0: using IRQ 256 for MSI hdac0: Caps: OSS 4, ISS 4, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 hdac0: Probing codec #0... hdac0: HDA Codec #0: Realtek ALC272 hdac0: HDA Codec ID: 0x10ec0272 hdac0: Vendor: 0x10ec hdac0: Device: 0x0272 hdac0: Revision: 0x00 hdac0: Stepping: 0x01 hdac0: PCI Subvendor: 0x022f1025 hdac0: Found audio FG nid=1 startnode=2 endnode=36 total=34 hdac0: hdac0: Processing audio FG cad=0 nid=1... hdac0: GPIO: 0x40000002 NumGPIO=2 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 hdac0: nid 17 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 18 0x99a30930 as 3 seq 0 Mic Fixed jack 3 loc 25 color Unknown misc 9 hdac0: nid 19 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 20 0x99130110 as 1 seq 0 Speaker Fixed jack 3 loc 25 color Unknown misc 1 hdac0: nid 21 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 22 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 23 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 24 0x03a19820 as 2 seq 0 Mic Jack jack 1 loc 3 color Pink misc 8 hdac0: nid 25 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 26 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 27 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 29 0x4016892d as 2 seq 13 Speaker None jack 6 loc 0 color Purple misc 9 hdac0: nid 30 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 33 0x0321401f as 1 seq 15 Headphones Jack jack 1 loc 3 color Green misc 0 hdac0: Patched pins configuration: hdac0: nid 17 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 18 0x99a30930 as 3 seq 0 Mic Fixed jack 3 loc 25 color Unknown misc 9 hdac0: nid 19 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 20 0x99130110 as 1 seq 0 Speaker Fixed jack 3 loc 25 color Unknown misc 1 hdac0: nid 21 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 22 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 23 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 24 0x03a19820 as 2 seq 0 Mic Jack jack 1 loc 3 color Pink misc 8 hdac0: nid 25 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 26 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 27 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 29 0x4016892d as 2 seq 13 Speaker None jack 6 loc 0 color Purple misc 9 [DISABLED] hdac0: nid 30 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 33 0x0321401f as 1 seq 15 Headphones Jack jack 1 loc 3 color Green misc 0 hdac0: 3 associations found: hdac0: Association 0 (1) out: hdac0: Pin nid=20 seq=0 hdac0: Pin nid=33 seq=15 hdac0: Association 1 (2) in: hdac0: Pin nid=24 seq=0 hdac0: Association 2 (3) in: hdac0: Pin nid=18 seq=0 hdac0: Tracing association 0 (1) hdac0: Pin 20 traced to DAC 2 hdac0: Pin 33 traced to DAC 2 and hpredir 0 hdac0: Association 0 (1) trace succeeded hdac0: Tracing association 1 (2) hdac0: Pin 24 traced to ADC 8 hdac0: Association 1 (2) trace succeeded hdac0: Tracing association 2 (3) hdac0: Pin 18 traced to ADC 9 hdac0: Association 2 (3) trace succeeded hdac0: Tracing input monitor hdac0: Tracing nid 11 to out hdac0: nid 11 is input monitor hdac0: Tracing nid 34 to out hdac0: Tracing nid 35 to out hdac0: Tracing other input monitors hdac0: Tracing nid 18 to out hdac0: Tracing nid 24 to out hdac0: Tracing beeper hdac0: GPIO init: data=0x00000000 mask=0x00000000 dir=0x00000000 hdac0: GPIO commit: data=0x00000001 mask=0x00000001 dir=0x00000001 hdac0: Enabling headphone/speaker audio routing switching: hdac0: as=0 sense nid=33 [UNSOL] hdac0: Pin sense: nid=33 res=0x00000000 hdac0: FG config/quirks: gpio0 forcestereo ivref50 ivref80 ivref100 ivref hdac0: hdac0: +-------------------+ hdac0: | DUMPING HDA NODES | hdac0: +-------------------+ hdac0: hdac0: Default Parameter hdac0: ----------------- hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: IN amp: 0x00000000 hdac0: OUT amp: 0x00000000 hdac0: hdac0: nid: 2 hdac0: Name: audio output hdac0: Widget cap: 0x0000041d hdac0: PWR STEREO hdac0: Association: 0 (0x00008001) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: Output amp: 0x00034040 hdac0: mute=0 step=64 size=3 offset=64 hdac0: hdac0: nid: 3 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x0000041d hdac0: PWR STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: Output amp: 0x00034040 hdac0: mute=0 step=64 size=3 offset=64 hdac0: hdac0: nid: 4 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x0000041d hdac0: PWR STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: Output amp: 0x00034040 hdac0: mute=0 step=64 size=3 offset=64 hdac0: hdac0: nid: 5 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 6 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x00000611 hdac0: PWR DIGITAL STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e05e0 hdac0: 16 20 24 bits, 44 48 88 96 192 KHz hdac0: hdac0: nid: 7 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 8 hdac0: Name: audio input hdac0: Widget cap: 0x0010051b hdac0: PWR STEREO hdac0: Association: 1 (0x00000001) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: Input amp: 0x80051f0b hdac0: mute=1 step=31 size=5 offset=11 hdac0: connections: 1 hdac0: | hdac0: + <- nid=35 [audio mixer] hdac0: hdac0: nid: 9 hdac0: Name: audio input hdac0: Widget cap: 0x0010051b hdac0: PWR STEREO hdac0: Association: 2 (0x00000001) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: Input amp: 0x80051f0b hdac0: mute=1 step=31 size=5 offset=11 hdac0: connections: 1 hdac0: | hdac0: + <- nid=34 [audio mixer] hdac0: hdac0: nid: 10 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 11 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: mix (mix) hdac0: Input amp: 0x80051f17 hdac0: mute=1 step=31 size=5 offset=23 hdac0: connections: 8 hdac0: | hdac0: + <- nid=24 [pin: Mic (Pink Jack)] hdac0: + [DISABLED] <- nid=25 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=26 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=27 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=29 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=20 [pin: Speaker (Fixed)] hdac0: + [DISABLED] <- nid=21 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=22 [pin: Speaker (None)] [DISABLED] hdac0: hdac0: nid: 12 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: 0 (0x00008001) hdac0: OSS: pcm, mix hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + <- nid=2 [audio output] hdac0: + <- nid=11 [audio mixer] hdac0: hdac0: nid: 13 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: -2 (0x00000000) hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=3 [audio output] [DISABLED] hdac0: + [DISABLED] <- nid=11 [audio mixer] hdac0: hdac0: nid: 14 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: -2 (0x00000000) hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=4 [audio output] [DISABLED] hdac0: + [DISABLED] <- nid=11 [audio mixer] hdac0: hdac0: nid: 15 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010a hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=2 [audio output] hdac0: + [DISABLED] <- nid=11 [audio mixer] hdac0: hdac0: nid: 16 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x00000611 hdac0: PWR DIGITAL STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e05e0 hdac0: 16 20 24 bits, 44 48 88 96 192 KHz hdac0: hdac0: nid: 17 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x00400700 hdac0: PWR DIGITAL hdac0: Pin cap: 0x00000010 hdac0: OUT hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: connections: 1 hdac0: | hdac0: + <- nid=16 [audio output] [DISABLED] hdac0: hdac0: nid: 18 hdac0: Name: pin: Mic (Fixed) hdac0: Widget cap: 0x00400401 hdac0: PWR STEREO hdac0: Association: 2 (0x00000001) hdac0: OSS: monitor (monitor) hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x99a30930 hdac0: Pin control: 0x00000020 IN hdac0: hdac0: nid: 19 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x00400401 hdac0: PWR STEREO hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: hdac0: nid: 20 hdac0: Name: pin: Speaker (Fixed) hdac0: Widget cap: 0x0040058d hdac0: PWR UNSOL STEREO hdac0: Association: 0 (0x00000001) hdac0: Pin cap: 0x0001003c hdac0: PDC HP OUT IN EAPD hdac0: Pin config: 0x99130110 hdac0: Pin control: 0x00000040 OUT hdac0: EAPD: 0x00000002 hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + <- nid=12 [audio mixer] (selected) hdac0: + [DISABLED] <- nid=13 [audio mixer] [DISABLED] hdac0: hdac0: nid: 21 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x0040058d hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x0001003c hdac0: PDC HP OUT IN EAPD hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: EAPD: 0x00000002 hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=12 [audio mixer] (selected) hdac0: + <- nid=13 [audio mixer] [DISABLED] hdac0: hdac0: nid: 22 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x0040058d hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x00000034 hdac0: PDC OUT IN hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=14 [audio mixer] [DISABLED] hdac0: hdac0: nid: 23 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x0040050c hdac0: PWR hdac0: Pin cap: 0x00000010 hdac0: OUT hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=15 [audio mixer] [DISABLED] hdac0: hdac0: nid: 24 hdac0: Name: pin: Mic (Pink Jack) hdac0: Widget cap: 0x0040058f hdac0: PWR UNSOL STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: mic (mic) hdac0: Pin cap: 0x00001734 hdac0: PDC OUT IN VREF[ 50 80 GROUND HIZ ] hdac0: Pin config: 0x03a19820 hdac0: Pin control: 0x00000024 IN VREFs hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: Input amp: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=14 [audio mixer] [DISABLED] hdac0: hdac0: nid: 25 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x0040058f hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x0000173c hdac0: PDC HP OUT IN VREF[ 50 80 GROUND HIZ ] hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: Input amp: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: connections: 3 hdac0: | hdac0: + [DISABLED] <- nid=12 [audio mixer] (selected) hdac0: + <- nid=13 [audio mixer] [DISABLED] hdac0: + <- nid=14 [audio mixer] [DISABLED] hdac0: hdac0: nid: 26 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x0040058f hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x00001734 hdac0: PDC OUT IN VREF[ 50 80 GROUND HIZ ] hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: Input amp: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=13 [audio mixer] [DISABLED] hdac0: hdac0: nid: 27 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x0040058f hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x0000173c hdac0: PDC HP OUT IN VREF[ 50 80 GROUND HIZ ] hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: Input amp: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: connections: 3 hdac0: | hdac0: + [DISABLED] <- nid=12 [audio mixer] (selected) hdac0: + <- nid=13 [audio mixer] [DISABLED] hdac0: + <- nid=14 [audio mixer] [DISABLED] hdac0: hdac0: nid: 28 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 29 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x00400400 hdac0: PWR hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x4016892d hdac0: Pin control: 0x00000000 hdac0: hdac0: nid: 30 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x00400780 hdac0: PWR DIGITAL UNSOL hdac0: Pin cap: 0x00000014 hdac0: PDC OUT hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: connections: 1 hdac0: | hdac0: + <- nid=6 [audio output] [DISABLED] hdac0: hdac0: nid: 31 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 32 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00040 hdac0: PROC hdac0: hdac0: nid: 33 hdac0: Name: pin: Headphones (Green Jack) hdac0: Widget cap: 0x0040058d hdac0: PWR UNSOL STEREO hdac0: Association: 0 (0x00008000) hdac0: Pin cap: 0x0000001c hdac0: PDC HP OUT hdac0: Pin config: 0x0321401f hdac0: Pin control: 0x000000c0 HP OUT hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 3 hdac0: | hdac0: + <- nid=12 [audio mixer] (selected) hdac0: + [DISABLED] <- nid=13 [audio mixer] [DISABLED] hdac0: + [DISABLED] <- nid=14 [audio mixer] [DISABLED] hdac0: hdac0: nid: 34 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: 2 (0x00000001) hdac0: OSS: monitor hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 10 hdac0: | hdac0: + [DISABLED] <- nid=24 [pin: Mic (Pink Jack)] hdac0: + [DISABLED] <- nid=25 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=26 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=27 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=29 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=20 [pin: Speaker (Fixed)] hdac0: + [DISABLED] <- nid=21 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=22 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=11 [audio mixer] hdac0: + <- nid=18 [pin: Mic (Fixed)] hdac0: hdac0: nid: 35 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: mic, mix hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 10 hdac0: | hdac0: + <- nid=24 [pin: Mic (Pink Jack)] hdac0: + [DISABLED] <- nid=25 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=26 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=27 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=29 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=20 [pin: Speaker (Fixed)] hdac0: + [DISABLED] <- nid=21 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=22 [pin: Speaker (None)] [DISABLED] hdac0: + <- nid=11 [audio mixer] hdac0: + [DISABLED] <- nid=19 [pin: Speaker (None)] [DISABLED] hdac0: pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="hdac-eeepc.txt" hdac0: mem 0xf7eb8000-0xf7ebbfff irq 16 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20090316_0130 hdac0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xf7eb8000 hdac0: attempting to allocate 1 MSI vectors (1 supported) hdac0: using IRQ 256 for MSI hdac0: [MPSAFE] hdac0: [ITHREAD] hdac0: Probing codec #0... hdac0: HDA Codec #0: Realtek ALC662 hdac0: HDA Codec ID: 0x10ec0662 hdac0: Vendor: 0x10ec hdac0: Device: 0x0662 hdac0: Revision: 0x01 hdac0: Stepping: 0x01 hdac0: PCI Subvendor: 0x83371043 hdac0: Found audio FG nid=1 startnode=2 endnode=39 total=37 hdac0: hdac0: Processing audio FG cad=0 nid=1... hdac0: GPIO: 0x40000002 NumGPIO=2 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 hdac0: nid 20 0x99130110 as 1 seq 0 Speaker Fixed jack 3 loc 25 color Unknown misc 1 hdac0: nid 21 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 22 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 24 0x01a19820 as 2 seq 0 Mic Jack jack 1 loc 1 color Pink misc 8 hdac0: nid 25 0x99a3092f as 2 seq 15 Mic Fixed jack 3 loc 25 color Unknown misc 9 hdac0: nid 26 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 27 0x0121401f as 1 seq 15 Headphones Jack jack 1 loc 1 color Green misc 0 hdac0: nid 28 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 29 0x40168a2d as 2 seq 13 Speaker None jack 6 loc 0 color Purple misc 10 hdac0: nid 30 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: Patched pins configuration: hdac0: nid 20 0x99130110 as 1 seq 0 Speaker Fixed jack 3 loc 25 color Unknown misc 1 hdac0: nid 21 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 22 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 24 0x01a19820 as 2 seq 0 Mic Jack jack 1 loc 1 color Pink misc 8 hdac0: nid 25 0x99a3092f as 2 seq 15 Mic Fixed jack 3 loc 25 color Unknown misc 9 hdac0: nid 26 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 27 0x0121401f as 1 seq 15 Headphones Jack jack 1 loc 1 color Green misc 0 hdac0: nid 28 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 29 0x40168a2d as 2 seq 13 Speaker None jack 6 loc 0 color Purple misc 10 [DISABLED] hdac0: nid 30 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: 2 associations found: hdac0: Association 0 (1) out: hdac0: Pin nid=20 seq=0 hdac0: Pin nid=27 seq=15 hdac0: Association 1 (2) in: hdac0: Pin nid=24 seq=0 hdac0: Pin nid=25 seq=15 hdac0: Tracing association 0 (1) hdac0: Pin 20 traced to DAC 2 hdac0: Pin 27 traced to DAC 2 and hpredir 0 hdac0: Association 0 (1) trace succeeded hdac0: Tracing association 1 (2) hdac0: Pin 24 traced to ADC 8 hdac0: Pin 25 traced to ADC 8 hdac0: Association 1 (2) trace succeeded hdac0: Tracing input monitor hdac0: Tracing nid 11 to out hdac0: nid 11 is input monitor hdac0: Tracing nid 35 to out hdac0: Tracing beeper hdac0: Enabling headphone/speaker audio routing switching: hdac0: as=0 sense nid=27 [UNSOL] hdac0: Pin sense: nid=27 res=0x00000000 hdac0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref hdac0: hdac0: +-------------------+ hdac0: | DUMPING HDA NODES | hdac0: +-------------------+ hdac0: hdac0: Default Parameter hdac0: ----------------- hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: IN amp: 0x00000000 hdac0: OUT amp: 0x00000000 hdac0: hdac0: nid: 2 hdac0: Name: audio output hdac0: Widget cap: 0x0000001d hdac0: STEREO hdac0: Association: 0 (0x00008001) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: Output amp: 0x00034040 hdac0: mute=0 step=64 size=3 offset=64 hdac0: hdac0: nid: 3 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x0000001d hdac0: STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: Output amp: 0x00034040 hdac0: mute=0 step=64 size=3 offset=64 hdac0: hdac0: nid: 4 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x0000001d hdac0: STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: Output amp: 0x00034040 hdac0: mute=0 step=64 size=3 offset=64 hdac0: hdac0: nid: 5 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 6 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x00000211 hdac0: DIGITAL STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x001e0160 hdac0: 16 20 24 32 bits, 44 48 96 KHz hdac0: hdac0: nid: 7 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 8 hdac0: Name: audio input hdac0: Widget cap: 0x0010011b hdac0: STEREO hdac0: Association: 1 (0x00008001) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x00060160 hdac0: 16 20 bits, 44 48 96 KHz hdac0: Input amp: 0x80051f09 hdac0: mute=1 step=31 size=5 offset=9 hdac0: connections: 1 hdac0: | hdac0: + <- nid=35 [audio mixer] hdac0: hdac0: nid: 9 [DISABLED] hdac0: Name: audio input hdac0: Widget cap: 0x0010011b hdac0: STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x00060160 hdac0: 16 20 bits, 44 48 96 KHz hdac0: Input amp: 0x80051f09 hdac0: mute=1 step=31 size=5 offset=9 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=34 [audio mixer] [DISABLED] hdac0: hdac0: nid: 10 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 11 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: -2 (0x00008001) hdac0: OSS: mix (mix) hdac0: Input amp: 0x80051f17 hdac0: mute=1 step=31 size=5 offset=23 hdac0: connections: 9 hdac0: | hdac0: + <- nid=24 [pin: Mic (Pink Jack)] hdac0: + <- nid=25 [pin: Mic (Fixed)] hdac0: + [DISABLED] <- nid=26 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=27 [pin: Headphones (Green Jack)] hdac0: + [DISABLED] <- nid=28 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=29 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=20 [pin: Speaker (Fixed)] hdac0: + [DISABLED] <- nid=21 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=22 [pin: Speaker (None)] [DISABLED] hdac0: hdac0: nid: 12 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: 0 (0x00008001) hdac0: OSS: pcm, mix hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + <- nid=2 [audio output] hdac0: + <- nid=11 [audio mixer] hdac0: hdac0: nid: 13 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=3 [audio output] [DISABLED] hdac0: + [DISABLED] <- nid=11 [audio mixer] hdac0: hdac0: nid: 14 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: -2 (0x00000000) hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=4 [audio output] [DISABLED] hdac0: + [DISABLED] <- nid=11 [audio mixer] hdac0: hdac0: nid: 15 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 16 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 17 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 18 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 19 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 20 hdac0: Name: pin: Speaker (Fixed) hdac0: Widget cap: 0x0040018d hdac0: UNSOL STEREO hdac0: Association: 0 (0x00000001) hdac0: Pin cap: 0x0001003c hdac0: PDC HP OUT IN EAPD hdac0: Pin config: 0x99130110 hdac0: Pin control: 0x00000040 OUT hdac0: EAPD: 0x00000002 hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 1 hdac0: | hdac0: + <- nid=12 [audio mixer] hdac0: hdac0: nid: 21 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x0040018d hdac0: UNSOL STEREO hdac0: Pin cap: 0x00010034 hdac0: PDC OUT IN EAPD hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: EAPD: 0x00000002 hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=13 [audio mixer] [DISABLED] hdac0: hdac0: nid: 22 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x0040018d hdac0: UNSOL STEREO hdac0: Pin cap: 0x00000034 hdac0: PDC OUT IN hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=14 [audio mixer] [DISABLED] hdac0: hdac0: nid: 23 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 24 hdac0: Name: pin: Mic (Pink Jack) hdac0: Widget cap: 0x0040018f hdac0: UNSOL STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: mic (mic) hdac0: Pin cap: 0x00001734 hdac0: PDC OUT IN VREF[ 50 80 GROUND HIZ ] hdac0: Pin config: 0x01a19820 hdac0: Pin control: 0x00000024 IN VREFs hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: Input amp: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=14 [audio mixer] [DISABLED] hdac0: hdac0: nid: 25 hdac0: Name: pin: Mic (Fixed) hdac0: Widget cap: 0x0040018f hdac0: UNSOL STEREO hdac0: Association: 1 (0x00008000) hdac0: OSS: monitor (monitor) hdac0: Pin cap: 0x0000173c hdac0: PDC HP OUT IN VREF[ 50 80 GROUND HIZ ] hdac0: Pin config: 0x99a3092f hdac0: Pin control: 0x00000024 IN VREFs hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: Input amp: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=12 [audio mixer] (selected) hdac0: + [DISABLED] <- nid=14 [audio mixer] [DISABLED] hdac0: hdac0: nid: 26 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x0040018d hdac0: UNSOL STEREO hdac0: Pin cap: 0x00000034 hdac0: PDC OUT IN hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=13 [audio mixer] [DISABLED] hdac0: hdac0: nid: 27 hdac0: Name: pin: Headphones (Green Jack) hdac0: Widget cap: 0x0040018f hdac0: UNSOL STEREO hdac0: Association: 0 (0x00008000) hdac0: Pin cap: 0x0000173c hdac0: PDC HP OUT IN VREF[ 50 80 GROUND HIZ ] hdac0: Pin config: 0x0121401f hdac0: Pin control: 0x000000c0 HP OUT hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: Input amp: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: connections: 2 hdac0: | hdac0: + <- nid=12 [audio mixer] (selected) hdac0: + [DISABLED] <- nid=14 [audio mixer] [DISABLED] hdac0: hdac0: nid: 28 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x00400001 hdac0: STEREO hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: hdac0: nid: 29 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x00400000 hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x40168a2d hdac0: Pin control: 0x00000000 hdac0: hdac0: nid: 30 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x00400300 hdac0: DIGITAL hdac0: Pin cap: 0x00000010 hdac0: OUT hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: connections: 1 hdac0: | hdac0: + <- nid=6 [audio output] [DISABLED] hdac0: hdac0: nid: 31 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 32 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00040 hdac0: PROC hdac0: hdac0: nid: 33 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 34 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 10 hdac0: | hdac0: + [DISABLED] <- nid=24 [pin: Mic (Pink Jack)] hdac0: + [DISABLED] <- nid=25 [pin: Mic (Fixed)] hdac0: + [DISABLED] <- nid=26 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=27 [pin: Headphones (Green Jack)] hdac0: + [DISABLED] <- nid=28 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=29 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=20 [pin: Speaker (Fixed)] hdac0: + [DISABLED] <- nid=21 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=22 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=11 [audio mixer] hdac0: hdac0: nid: 35 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: 1 (0x00008001) hdac0: OSS: mic, mix, monitor hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 10 hdac0: | hdac0: + <- nid=24 [pin: Mic (Pink Jack)] hdac0: + <- nid=25 [pin: Mic (Fixed)] hdac0: + [DISABLED] <- nid=26 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=27 [pin: Headphones (Green Jack)] hdac0: + [DISABLED] <- nid=28 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=29 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=20 [pin: Speaker (Fixed)] hdac0: + [DISABLED] <- nid=21 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=22 [pin: Speaker (None)] [DISABLED] hdac0: + <- nid=11 [audio mixer] hdac0: hdac0: nid: 36 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 37 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 38 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: pcm0: at cad 0 nid 1 on hdac0 --/9DWx/yDrRhgMJTb-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 7 19:29:46 2010 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 680901065672; Sun, 7 Nov 2010 19:29:46 +0000 (UTC) (envelope-from yanegomi@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 C9B718FC08; Sun, 7 Nov 2010 19:29:45 +0000 (UTC) Received: by wyb34 with SMTP id 34so2744554wyb.13 for ; Sun, 07 Nov 2010 11:29:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=wWcwyD5EnccsAXH1jrumLYRnpMOCzYzGhS2OwmslR9I=; b=Mc0CUgls/NI2YLPr46G/YQX+0F5zc8PexjwEPfbpxbnAc+s7S51hHFvdFLw4gF2qV9 BT6qncOtkwNBGqH9MObhwwsQO/HEYAY1kwuXwe4extBAFoSI4FcR0niGfMbnr6hb00I1 /QmnFYYcTVlUo2WT1SHqGGHfQYcCMXPWvWLAk= 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=nFqO6tHO9lMx+BVWipS9TWPok85VQWqp59/RYaWRl237/+qS5XLZUYDJu4qf3yWOs3 lCXd/QBEu23ed+9GDojhQASgfN/mEqBQuUkooaYKZRF7fdlZ/lcLYZhiMzWz6LaLGQQo dZKxsvcSMweIpxmcBFRbcDmJCRFFySWEYWQFw= MIME-Version: 1.0 Received: by 10.216.7.210 with SMTP id 60mr3502366wep.30.1289158180847; Sun, 07 Nov 2010 11:29:40 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Sun, 7 Nov 2010 11:29:40 -0800 (PST) In-Reply-To: References: Date: Sun, 7 Nov 2010 11:29:40 -0800 X-Google-Sender-Auth: 33S8BYe-O4KuyoxTdnlgsEeZiH4 Message-ID: From: Garrett Cooper To: "Sam Fourman Jr." Content-Type: text/plain; charset=ISO-8859-1 Cc: David Rhodus , FreeBSD Current , Jung-uk Kim Subject: Re: ACPI panic on boot recent HEAD 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, 07 Nov 2010 19:29:46 -0000 On Sun, Nov 7, 2010 at 10:02 AM, Sam Fourman Jr. wrote: > Hello list, > > here is a digital camera pic of a panic that happened while booting > yesterdays Source tree > > http://www.puffybsd.com/IMG_4136.JPG > > > here is a dmesg from a older current > http://www.puffybsd.com/amddmesg.txt Uh, that looks like geom to me, not acpi... -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Nov 7 20:42:26 2010 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 30EC8106566C; Sun, 7 Nov 2010 20:42:26 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id ACD268FC0C; Sun, 7 Nov 2010 20:42:25 +0000 (UTC) Received: by qyk7 with SMTP id 7so4137504qyk.13 for ; Sun, 07 Nov 2010 12:42:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=gAHZqutfH7JLpCsmmDLQjFX7djW8wB0STSew6Mo+Cgc=; b=WtlnHfpUxhY85RLzenlkYwt1ajtjWhNParjTVTmarhGBVTn+IgYAApeaY6fpXOdFpN x8zrZwSgGj1tfDqETeOTKnRT5nJG5Fb2QuakDF3ZfLezTU59MOTpkTiaAD2gbZiBnzEx YgWlJkgPg1lU5AjxuTAyEsUmc+PYRrHXpfais= 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=M6r/nHdlL3lsdzgaklD7x3wzR3AAIlZWXfHLdgJA+aLHLZARwKESf1tqWCSNMQR44G 4Ffco7TotmIguOa1BmrGhYYpTTdKJ2+ftvrFcGCTNNltYrVN0tkkzPNcxQR/BbbC5mxb YQuMJx9opIs6HWFc4oAJxmL5Rpi+pBGQpe8dY= MIME-Version: 1.0 Received: by 10.229.181.210 with SMTP id bz18mr4424384qcb.43.1289162544776; Sun, 07 Nov 2010 12:42:24 -0800 (PST) Received: by 10.229.80.129 with HTTP; Sun, 7 Nov 2010 12:42:24 -0800 (PST) In-Reply-To: References: Date: Sun, 7 Nov 2010 14:42:24 -0600 Message-ID: From: "Sam Fourman Jr." To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Cc: David Rhodus , FreeBSD Current , Jung-uk Kim Subject: Re: ACPI panic on boot recent HEAD 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, 07 Nov 2010 20:42:26 -0000 On Sun, Nov 7, 2010 at 1:29 PM, Garrett Cooper wrote: > On Sun, Nov 7, 2010 at 10:02 AM, Sam Fourman Jr. wrote: >> Hello list, >> >> here is a digital camera pic of a panic that happened while booting >> yesterdays Source tree >> >> http://www.puffybsd.com/IMG_4136.JPG >> >> >> here is a dmesg from a older current >> http://www.puffybsd.com/amddmesg.txt > > Uh, that looks like geom to me, not acpi... > -Garrett I saw the ACPI warning on top so I blamed ACPI... maybe I was wrong, this stuff is not my strong suit -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com From owner-freebsd-current@FreeBSD.ORG Sun Nov 7 21:29:23 2010 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 B8A14106564A for ; Sun, 7 Nov 2010 21:29:23 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4C76E8FC08 for ; Sun, 7 Nov 2010 21:29:23 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id oA7LTJQ1003010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Nov 2010 22:29:19 +0100 (CET) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1289165359; bh=z1ga7PHBtszaBPlgz4X82ywPRbt26pIt2lqQx4g8rZ8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=oNv3n1rNcEb/GCFI0svERQJX3ihs8uVBGtXzaO4vUHlcqEmI6jnnAIPL8vJ57BFl/ pgMk8BVFWEjDLNFldF9Ng6hHcxRakF9leVJ+sZpXWKYYqtqpND1/LgglzmR0OLxmsc cBEMc+7TxiObInPxg1/8ke1j9JmBe4SPDsej3AiY= Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id oA7LTIuZ003009; Sun, 7 Nov 2010 22:29:18 +0100 (CET) (envelope-from uqs@spoerlein.net) Date: Sun, 7 Nov 2010 22:29:18 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Tony Finch Message-ID: <20101107212918.GP85693@acme.spoerlein.net> Mail-Followup-To: Tony Finch , freebsd-current@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: Tricky subversion import, what to do? 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, 07 Nov 2010 21:29:23 -0000 On Sun, 07.11.2010 at 17:18:43 +0000, Tony Finch wrote: > > this is about importing unifdef 2.4, which has no significant code > > changes, but that's not the point. > > I maintain unifdef and I haven't imported 2.4 because there are no code > changes. Please leave it alone. As I wrote, that's beside the point and not the question at hand. How/where should it end up in our tree? Is it vendor code? Is it contrib code? And if so how to bootstrap the correct subversion history ... Uli From owner-freebsd-current@FreeBSD.ORG Sun Nov 7 22:07:34 2010 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 89D7B1065672; Sun, 7 Nov 2010 22:07:34 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 219B18FC0C; Sun, 7 Nov 2010 22:07:34 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id E779235A82A; Sun, 7 Nov 2010 23:07:32 +0100 (CET) Received: by turtle.stack.nl (Postfix, from userid 1677) id D182D172B6; Sun, 7 Nov 2010 23:07:32 +0100 (CET) Date: Sun, 7 Nov 2010 23:07:32 +0100 From: Jilles Tjoelker To: Garrett Cooper Message-ID: <20101107220732.GB37005@stack.nl> References: <20101105202536.GR85693@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org Subject: Re: Files under src/ not used for building world 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, 07 Nov 2010 22:07:34 -0000 On Fri, Nov 05, 2010 at 09:42:27PM -0700, Garrett Cooper wrote: > On Fri, Nov 5, 2010 at 1:25 PM, Ulrich Spörlein wrote: > > Hey folks, not sure why, but I had a stab at looking which files were > > actually read during building world. > > bin/sh/bltin/echo.1 > I'd talk to jilles@ (weird thing is that this is installed on my machine). This is a man page for sh's echo builtin. It is a little more extensive but otherwise equivalent to the description in sh(1). It is different from bin/echo/echo.1. Unfortunately, sh's echo builtin and /bin/echo work differently. This should not have been allowed to happen, but now we are stuck with it. I suppose bin/sh/bltin/echo.1 can go away. -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Sun Nov 7 23:48:22 2010 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 E18BD1065674; Sun, 7 Nov 2010 23:48:22 +0000 (UTC) (envelope-from yanegomi@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 4DCE38FC1B; Sun, 7 Nov 2010 23:48:21 +0000 (UTC) Received: by wyb34 with SMTP id 34so2877280wyb.13 for ; Sun, 07 Nov 2010 15:48:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=dtxTRWHjbcFib/i8ZYku3LzBhJ25hHU+0rSk+rRduig=; b=ooP86TH4Ib5Y04lz1A9R8Zmy/RM3ekTjK/IiNovTOnyV7IVXxyQt6IOBGkaawZnjbN LLTAvt1W35bv3aJxK4Mx+qKzBb4cTCpHMVO8OgSXXx4wXp/ukBuyWdsEYs2FFZlmP4Hd vgiE8qyfqtlkMGmCJr0M6ixnihmBWwcg1FbPE= 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=Ne5qrCXipj+JxcBp0xy1QoNAKlgr2TCFV5N8pOV+h0mViH4yEIUaaTv42o0l9yUddk t2tXZ++EiVd4DT7O32rXnaRFzKfMNbbuLaipMDUZmh8/Y42HBONLByY8GYZiRdGbloHY Ev/8gGruomB9RXxaCEU7X4/jmrOLVHAhrDzDc= MIME-Version: 1.0 Received: by 10.216.7.210 with SMTP id 60mr3676208wep.30.1289173698919; Sun, 07 Nov 2010 15:48:18 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Sun, 7 Nov 2010 15:48:18 -0800 (PST) In-Reply-To: References: Date: Sun, 7 Nov 2010 15:48:18 -0800 X-Google-Sender-Auth: c1v13gGM4FcsbBTvKmH2-3YSi54 Message-ID: From: Garrett Cooper To: "Sam Fourman Jr." Content-Type: text/plain; charset=ISO-8859-1 Cc: David Rhodus , FreeBSD Current , Jung-uk Kim Subject: Re: ACPI panic on boot recent HEAD 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, 07 Nov 2010 23:48:23 -0000 On Sun, Nov 7, 2010 at 12:42 PM, Sam Fourman Jr. wrote: > On Sun, Nov 7, 2010 at 1:29 PM, Garrett Cooper wrote: >> On Sun, Nov 7, 2010 at 10:02 AM, Sam Fourman Jr. wrote: >>> Hello list, >>> >>> here is a digital camera pic of a panic that happened while booting >>> yesterdays Source tree >>> >>> http://www.puffybsd.com/IMG_4136.JPG >>> >>> >>> here is a dmesg from a older current >>> http://www.puffybsd.com/amddmesg.txt >> >> Uh, that looks like geom to me, not acpi... > > I saw the ACPI warning on top so I blamed ACPI... > maybe I was wrong, this stuff is not my strong suit It's ok :) (one thing to note is that the ACPI warning is present in both cases)... It would be interesting to note what modules you load (in particular the geom ones), and what GEOM options you define in your kernconf, as well as whether or not you built your kernel and world from scratch. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 00:06:45 2010 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 7880D106564A for ; Mon, 8 Nov 2010 00:06:45 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 2D9A08FC14 for ; Mon, 8 Nov 2010 00:06:44 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQEAC/O1kyDaFvO/2dsb2JhbACDMJBWjnCpBJAtgSKDM3MEhFiFfQ X-IronPort-AV: E=Sophos;i="4.58,311,1286164800"; d="scan'208";a="99922751" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 07 Nov 2010 19:06:43 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 06D85B3EB4; Sun, 7 Nov 2010 19:06:44 -0500 (EST) Date: Sun, 7 Nov 2010 19:06:44 -0500 (EST) From: Rick Macklem To: pyunyh@gmail.com Message-ID: <2066420582.220038.1289174803955.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20101106023345.GC22715@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.225.56.115] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL4_64) Cc: alc@freebsd.org, freebsd-current@freebsd.org Subject: Re: re(4) driver dropping packets when reading NFS 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: Mon, 08 Nov 2010 00:06:45 -0000 > > I highly doubt it could be hardware issue. > Looks like the hardware guys may be off the hook. See below. > > It's job of bus_dma(9) and I don't think barrier instructions would > be helpful here as I don't see out-of-order execution in RX > handler. > My current hunch is that something that changed between June 7 and June 15 in head/sys has caused the chip to have difficulties doing DMA, resulting in the Fifo overflows and approx. 10% "missed frames". > > Let's kill driver bug. No one reported this kind of issue so far > and I guess most users took it granted for the poor performance > because they are using low end consumer grade controller. > I think your driver is off the hook, too. > > > re0 statistics: > > Transmit good frames : 101346 > > Receive good frames : 133390 > > Tx errors : 0 > > Rx errors : 0 > > Rx missed frames : 14394 > > Rx frame alignment errs : 0 > > Tx single collisions : 0 > > Tx multiple collisions : 0 > > Rx unicast frames : 133378 > > Rx broadcast frames : 0 > > Rx multicast frames : 12 > > Tx aborts : 0 > > Tx underruns : 0 > > rxe did 0: 14359 > Seeing that someone thought it had worked ok a while back, I decided to try some old kernels I had lying about from head/-current. I found that the one I svn`d on June 7 works well (about 7Mbytes per sec read rate) whereas one svn`d on June 15 had the problem (about 500Kbytes per sec read rate). So what is different between these kernels: - if_re.c is identical - subr_dma.c has a simple change and porting the June 7 one over didn`t make the June 15 one work better - amd64`s busdma_machdep.c is identical so it must be something else. There are a bunch of changes to amd64`s pmap.c, which is why I`ve cc`d Alan, in case he might know if those changes could affect PCIe DMA or similar. Other than that, maybe someone else familiar with the PCIe DMA could look and see if a change done to head between June 7 and 15 might explain it. (and it could be something else, a DMA problem for the chip is just a guess) rick ps: Unfortunately I`ll be on the road for the next month, so I won`t be able to test patches until early Dec. From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 00:08:10 2010 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 00A1C106566B; Mon, 8 Nov 2010 00:08:10 +0000 (UTC) (envelope-from sfourman@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 82C3B8FC08; Mon, 8 Nov 2010 00:08:09 +0000 (UTC) Received: by qwg8 with SMTP id 8so4221376qwg.13 for ; Sun, 07 Nov 2010 16:08:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XkDBTw8vJcX701yTQQW8YAdFybUk+cfj7LjIDtI8sng=; b=j7JXsl/swiN4m/tgW8xC3OCmoOVD60g+hKslEpRH90OEeWjtLpBLTZdh2H4fwOnoeZ BHfhJeKgjdGy/5gYahG9A5astCi+WbhtT6yu0Mjk6UiVESrWfy9dvq8B3UX8bZxrN3mf PsIhuWxG7ZKUAbKzhMo17mYpmJU1wrgKuBeUM= 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=SyhXS8U+y+bAq6o33urVn9bAuw2lBF79v1YiskQoOIfFLpo/YQD9yuJ9BvczpN/koR PUnTSLJUlkZCrJ4cZr1pL27BiE0cwkkeh1tbuo7RU8nWTAb8Mrx2MVoz9Az8o9xY0dyM uiIQCFhlXWYx4sAK1h5UcrUce7TqZX3XJQ1Hc= MIME-Version: 1.0 Received: by 10.229.224.81 with SMTP id in17mr4505496qcb.81.1289174888784; Sun, 07 Nov 2010 16:08:08 -0800 (PST) Received: by 10.229.80.129 with HTTP; Sun, 7 Nov 2010 16:08:08 -0800 (PST) In-Reply-To: References: Date: Sun, 7 Nov 2010 18:08:08 -0600 Message-ID: From: "Sam Fourman Jr." To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: David Rhodus , FreeBSD Current , Jung-uk Kim Subject: Re: ACPI panic on boot recent HEAD 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, 08 Nov 2010 00:08:10 -0000 >> I saw the ACPI warning on top so I blamed ACPI... >> maybe I was wrong, this stuff is not my strong suit > > =A0 =A0It's ok :) (one thing to note is that the ACPI warning is present > in both cases)... It would be interesting to note what modules you > load (in particular the geom ones), and what GEOM options you define > in your kernconf, as well as whether or not you built your kernel and > world from scratch. > Thanks! > -Garrett this kernel is GENERIC + Debugging stuff I built CURRENT with RELENG_8, then I installed the kernel and rebooted I still have a RELENG_8 world, if that matters and this is a ZFS boot machine --=20 Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 00:27:01 2010 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 C8B5C106566B for ; Mon, 8 Nov 2010 00:27:01 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 62E7C8FC08 for ; Mon, 8 Nov 2010 00:27:01 +0000 (UTC) Received: by yxl31 with SMTP id 31so3196843yxl.13 for ; Sun, 07 Nov 2010 16:27:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=Se6x1QKiQ1cal9AFeY6S83zib2C982rHqGp9h5lUfLo=; b=mQv0O49HS/DRQZEr783VM16qU8NXzPLXpNiD6sf1mEGowdhyEk7EszNrQpcBY8f6jt VTgezEJuCgo5WnlS13TKM5gOBF3z5f2gdy4q7kB0qn0rC9Vb2S/yZjxZs/OU12bRPFSp OI0z4ACmLzcWDskLnFCBXXEEF8IUUzoCkjVS0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=q7P/2MArtllHZpfwKyPSHGNDFQ/6IBO8D7aVxGxdLjbCuqAFnm9TJh4mfhDbJfOvRM vCMHt4gI0yDrjk0q/62qX46+nO8RYc0voV+7FLk6WxtGWCZvgK41iwltETriJxS3x6pe giEJgLfcDbQ86bQakYLLCsYWwN5LQu/C2rOws= Received: by 10.150.158.16 with SMTP id g16mr7495983ybe.242.1289176020638; Sun, 07 Nov 2010 16:27:00 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id r29sm1884615ybn.10.2010.11.07.16.26.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 07 Nov 2010 16:26:59 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 7 Nov 2010 16:26:01 -0800 From: Pyun YongHyeon Date: Sun, 7 Nov 2010 16:26:01 -0800 To: Rick Macklem Message-ID: <20101108002601.GC1279@michelle.cdnetworks.com> References: <20101106023345.GC22715@michelle.cdnetworks.com> <2066420582.220038.1289174803955.JavaMail.root@erie.cs.uoguelph.ca> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline In-Reply-To: <2066420582.220038.1289174803955.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.4.2.3i Cc: alc@freebsd.org, freebsd-current@freebsd.org Subject: Re: re(4) driver dropping packets when reading NFS files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@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: Mon, 08 Nov 2010 00:27:01 -0000 --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Nov 07, 2010 at 07:06:44PM -0500, Rick Macklem wrote: > > > > I highly doubt it could be hardware issue. > > > Looks like the hardware guys may be off the hook. See below. > > > > It's job of bus_dma(9) and I don't think barrier instructions would > > be helpful here as I don't see out-of-order execution in RX > > handler. > > > My current hunch is that something that changed between June 7 and > June 15 in head/sys has caused the chip to have difficulties doing > DMA, resulting in the Fifo overflows and approx. 10% "missed frames". > > > > > Let's kill driver bug. No one reported this kind of issue so far > > and I guess most users took it granted for the poor performance > > because they are using low end consumer grade controller. > > > I think your driver is off the hook, too. > > > > > > re0 statistics: > > > Transmit good frames : 101346 > > > Receive good frames : 133390 > > > Tx errors : 0 > > > Rx errors : 0 > > > Rx missed frames : 14394 > > > Rx frame alignment errs : 0 > > > Tx single collisions : 0 > > > Tx multiple collisions : 0 > > > Rx unicast frames : 133378 > > > Rx broadcast frames : 0 > > > Rx multicast frames : 12 > > > Tx aborts : 0 > > > Tx underruns : 0 > > > rxe did 0: 14359 > > > Seeing that someone thought it had worked ok a while back, I decided to > try some old kernels I had lying about from head/-current. I found that > the one I svn`d on June 7 works well (about 7Mbytes per sec read rate) whereas one > svn`d on June 15 had the problem (about 500Kbytes per sec read rate). > > So what is different between these kernels: > - if_re.c is identical > - subr_dma.c has a simple change and porting the June 7 one over didn`t make > the June 15 one work better > - amd64`s busdma_machdep.c is identical > > so it must be something else. There are a bunch of changes to amd64`s pmap.c, > which is why I`ve cc`d Alan, in case he might know if those changes could affect > PCIe DMA or similar. > > Other than that, maybe someone else familiar with the PCIe DMA could look and see > if a change done to head between June 7 and 15 might explain it. (and it could > be something else, a DMA problem for the chip is just a guess) > If that made difference, all other ethernet controllers would have suffered from the similar issues. > rick > ps: Unfortunately I`ll be on the road for the next month, so I won`t be able > to test patches until early Dec. If you have some spare time please try attach one. I guess fast ethernet controller has smaller FIFO size than that of GigE controller so it is frequently triggered the issue on fast ethernet controller than GigE controllers. I still guess that there are cases that an interrupt is not correctly served such that driver missed a lot of frames. --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="re.intr.patch5" Index: sys/pci/if_rlreg.h =================================================================== --- sys/pci/if_rlreg.h (revision 214897) +++ sys/pci/if_rlreg.h (working copy) @@ -218,9 +218,10 @@ #define RL_ISR_TX_OK 0x0004 #define RL_ISR_TX_ERR 0x0008 #define RL_ISR_RX_OVERRUN 0x0010 +#define RL_ISR_RX_DESC_UNAVAIL 0x0010 /* C+ only */ #define RL_ISR_PKT_UNDERRUN 0x0020 #define RL_ISR_LINKCHG 0x0020 /* 8169 only */ -#define RL_ISR_FIFO_OFLOW 0x0040 /* 8139 only */ +#define RL_ISR_FIFO_OFLOW 0x0040 #define RL_ISR_TX_DESC_UNAVAIL 0x0080 /* C+ only */ #define RL_ISR_SWI 0x0100 /* C+ only */ #define RL_ISR_CABLE_LEN_CHGD 0x2000 @@ -236,12 +237,12 @@ #ifdef RE_TX_MODERATION #define RL_INTRS_CPLUS \ (RL_ISR_RX_OK|RL_ISR_RX_ERR|RL_ISR_TX_ERR| \ - RL_ISR_RX_OVERRUN|RL_ISR_PKT_UNDERRUN|RL_ISR_FIFO_OFLOW| \ + RL_ISR_RX_DESC_UNAVAIL|RL_ISR_PKT_UNDERRUN|RL_ISR_FIFO_OFLOW| \ RL_ISR_PCS_TIMEOUT|RL_ISR_SYSTEM_ERR|RL_ISR_TIMEOUT_EXPIRED) #else #define RL_INTRS_CPLUS \ (RL_ISR_RX_OK|RL_ISR_RX_ERR|RL_ISR_TX_ERR|RL_ISR_TX_OK| \ - RL_ISR_RX_OVERRUN|RL_ISR_PKT_UNDERRUN|RL_ISR_FIFO_OFLOW| \ + RL_ISR_RX_DESC_UNAVAIL|RL_ISR_PKT_UNDERRUN|RL_ISR_FIFO_OFLOW| \ RL_ISR_PCS_TIMEOUT|RL_ISR_SYSTEM_ERR|RL_ISR_TIMEOUT_EXPIRED) #endif @@ -873,9 +874,7 @@ int rl_twist_row; int rl_twist_col; int suspended; /* 0 = normal 1 = suspended */ -#ifdef DEVICE_POLLING int rxcycles; -#endif struct task rl_txtask; struct task rl_inttask; Index: sys/dev/re/if_re.c =================================================================== --- sys/dev/re/if_re.c (revision 214897) +++ sys/dev/re/if_re.c (working copy) @@ -1860,7 +1860,7 @@ int i, total_len; struct rl_desc *cur_rx; u_int32_t rxstat, rxvlan; - int maxpkt = 16, rx_npkts = 0; + int rx_npkts = 0; RL_LOCK_ASSERT(sc); @@ -1872,7 +1872,7 @@ sc->rl_ldata.rl_rx_list_map, BUS_DMASYNC_POSTREAD | BUS_DMASYNC_POSTWRITE); - for (i = sc->rl_ldata.rl_rx_prodidx; maxpkt > 0; + for (i = sc->rl_ldata.rl_rx_prodidx; sc->rxcycles > 0; i = RL_RX_DESC_NXT(sc, i)) { if ((ifp->if_drv_flags & IFF_DRV_RUNNING) == 0) break; @@ -2036,7 +2036,7 @@ } } } - maxpkt--; + sc->rxcycles--; if (rxvlan & RL_RDESC_VLANCTL_TAG) { m->m_pkthdr.ether_vtag = bswap16((rxvlan & RL_RDESC_VLANCTL_DATA)); @@ -2058,10 +2058,10 @@ if (rx_npktsp != NULL) *rx_npktsp = rx_npkts; - if (maxpkt) - return (EAGAIN); + if (sc->rxcycles) + return (0); - return (0); + return (EAGAIN); } static void @@ -2243,6 +2243,8 @@ RL_LOCK(sc); status = CSR_READ_2(sc, RL_ISR); + if (status & RL_ISR_FIFO_OFLOW) + status |= RL_ISR_RX_DESC_UNAVAIL; CSR_WRITE_2(sc, RL_ISR, status); if (sc->suspended || @@ -2258,8 +2260,11 @@ } #endif - if (status & (RL_ISR_RX_OK|RL_ISR_RX_ERR|RL_ISR_FIFO_OFLOW)) + if (status & (RL_ISR_RX_OK | RL_ISR_RX_ERR | RL_ISR_FIFO_OFLOW | + RL_ISR_RX_DESC_UNAVAIL)) { + sc->rxcycles = sc->rl_ldata.rl_rx_desc_cnt / 2; rval = re_rxeof(sc, NULL); + } /* * Some chips will ignore a second TX request issued --vtzGhvizbBRQ85DL-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 01:14:33 2010 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 6B613106566C; Mon, 8 Nov 2010 01:14:33 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 0CA0A8FC08; Mon, 8 Nov 2010 01:14:32 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQEAOPd1kyDaFvO/2dsb2JhbACDMJBWjnCpVpAwhFVzBIRYhX0 X-IronPort-AV: E=Sophos;i="4.58,311,1286164800"; d="scan'208";a="98103489" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 07 Nov 2010 20:14:31 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id E04D6B3F49; Sun, 7 Nov 2010 20:14:31 -0500 (EST) Date: Sun, 7 Nov 2010 20:14:31 -0500 (EST) From: Rick Macklem To: pyunyh@gmail.com Message-ID: <74999496.222044.1289178871881.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20101108002601.GC1279@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_222043_2030575660.1289178871880" X-Originating-IP: [99.225.56.115] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL4_64) Cc: alc@freebsd.org, freebsd-current@freebsd.org Subject: Re: re(4) driver dropping packets when reading NFS 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: Mon, 08 Nov 2010 01:14:33 -0000 ------=_Part_222043_2030575660.1289178871880 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit > > If that made difference, all other ethernet controllers would have > suffered from the similar issues. > Well, some commit done between June 7 and June 15 made a difference, but I have no idea what or why. Also, I had a report of very poor read rate from someone using a bge(4) interface, but I have no reason to believe it is because of the same issue. > > If you have some spare time please try attach one. I guess fast > ethernet controller has smaller FIFO size than that of GigE > controller so it is frequently triggered the issue on fast ethernet > controller than GigE controllers. I still guess that there are > cases that an interrupt is not correctly served such that driver > missed a lot of frames. > Patch didn't help. If anything it degrading things a bit (stats are attached). rick ------=_Part_222043_2030575660.1289178871880 Content-Type: text/plain; name=re.stats Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=re.stats cmUwIHN0YXRpc3RpY3M6ClR4IGZyYW1lcyA6IDEwMjAwOQpSeCBmcmFtZXMgOiAxMzMzMTgKVHgg ZXJyb3JzIDogMApSeCBlcnJvcnMgOiAwClJ4IG1pc3NlZCBmcmFtZXMgOiAxNTI0NgpSeCBmcmFt ZSBhbGlnbm1lbnQgZXJycyA6IDAKVHggc2luZ2xlIGNvbGxpc2lvbnMgOiAwClR4IG11bHRpcGxl IGNvbGxpc2lvbnMgOiAwClJ4IHVuaWNhc3QgZnJhbWVzIDogMTMzMzA2ClJ4IGJyb2FkY2FzdCBm cmFtZXMgOiAwClJ4IG11bHRpY2FzdCBmcmFtZXMgOiAxMgpUeCBhYm9ydHMgOiAwClR4IHVuZGVy cnVucyA6IDAK ------=_Part_222043_2030575660.1289178871880-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 01:41:20 2010 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 DEBFD106566B; Mon, 8 Nov 2010 01:41:20 +0000 (UTC) (envelope-from pyunyh@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 A58938FC15; Mon, 8 Nov 2010 01:41:20 +0000 (UTC) Received: by pzk12 with SMTP id 12so321980pzk.13 for ; Sun, 07 Nov 2010 17:41:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=SiFWO5mnsJrnZReZET9uLZELCm4ghqEcDR1pNwW+qcU=; b=iBtNdb9pzML8V+qmRi6tk4IwXLa+p78xzzhYJf+Ihsjwzal5a14R++H1KZQlJJp8N/ zauchrJ8DYOxi0cCgwbLWGJ09PWUbF49idUSfexoPqEq5TyO7wh47RNGMsZU35G+HVLZ 7tvDW5fwiyJXNcEzMRmDHawUWYEOPdvuqm3aY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=X8WeHTvEAugKJk7c7vj/lJ7iEjesQpMsCLlOrPwsVx8s1IzMPg3VpZ0ayDQD5BqW0H bvJ6gY7DgNt8myBmr1e5SO93fjMnN/RS460lyAtXy3Rmba+icBLOV0AUJHxHiPoIX1za w81/75ed3dVY8Xrq822esld1Srpq5nTjrvPb0= Received: by 10.143.43.12 with SMTP id v12mr3951487wfj.344.1289180480196; Sun, 07 Nov 2010 17:41:20 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id w22sm7262893wfd.19.2010.11.07.17.41.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 07 Nov 2010 17:41:19 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 7 Nov 2010 17:40:22 -0800 From: Pyun YongHyeon Date: Sun, 7 Nov 2010 17:40:22 -0800 To: Rick Macklem Message-ID: <20101108014022.GG1279@michelle.cdnetworks.com> References: <20101108002601.GC1279@michelle.cdnetworks.com> <74999496.222044.1289178871881.JavaMail.root@erie.cs.uoguelph.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <74999496.222044.1289178871881.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.4.2.3i Cc: alc@freebsd.org, freebsd-current@freebsd.org Subject: Re: re(4) driver dropping packets when reading NFS files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@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: Mon, 08 Nov 2010 01:41:20 -0000 On Sun, Nov 07, 2010 at 08:14:31PM -0500, Rick Macklem wrote: > > > > If that made difference, all other ethernet controllers would have > > suffered from the similar issues. > > > Well, some commit done between June 7 and June 15 made a difference, > but I have no idea what or why. > > Also, I had a report of very poor read rate from someone using a bge(4) > interface, but I have no reason to believe it is because of the same > issue. > > > > > If you have some spare time please try attach one. I guess fast > > ethernet controller has smaller FIFO size than that of GigE > > controller so it is frequently triggered the issue on fast ethernet > > controller than GigE controllers. I still guess that there are > > cases that an interrupt is not correctly served such that driver > > missed a lot of frames. > > > Patch didn't help. If anything it degrading things a bit (stats are > attached). > By chance, how about disabling RX early interrupt? You can add the following 3 lines of code into re_init_locked(). 2710 /* 2711 * Set the initial RX configuration. 2712 */ 2713 re_set_rxmode(sc); 2714 2715 /* Disable RX early interrupt. */ 2716 cfg = CSR_READ_2(sc, RL_MULTIINTR); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2717 cfg &= 0xF000; ^^^^^^^^^^^^^^ 2718 CSR_WRITE_2(sc, RL_MULTIINTR, cfg); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2719 2720 #ifdef DEVICE_POLLING From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 03:22:25 2010 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 D7944106566B for ; Mon, 8 Nov 2010 03:22:25 +0000 (UTC) (envelope-from fanf2@hermes.cam.ac.uk) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by mx1.freebsd.org (Postfix) with ESMTP id 999AA8FC08 for ; Mon, 8 Nov 2010 03:22:25 +0000 (UTC) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from 87.115.11.126.plusnet.pcl-ag01.dyn.plus.net ([87.115.11.126]:57129 helo=[192.168.1.6]) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1PFIJL-00026s-E6 (Exim 4.72) (return-path ); Mon, 08 Nov 2010 03:22:23 +0000 References: <20101107212918.GP85693@acme.spoerlein.net> In-Reply-To: <20101107212918.GP85693@acme.spoerlein.net> Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <327A7F41-E06F-48AF-8EC2-20DEBBE03491@dotat.at> X-Mailer: iPhone Mail (8B117) From: Tony Finch Date: Mon, 8 Nov 2010 03:22:18 +0000 To: =?utf-8?Q?Ulrich_Sp=C3=B6rlein?= Sender: Tony Finch X-Mailman-Approved-At: Mon, 08 Nov 2010 03:30:04 +0000 Cc: Tony Finch , "freebsd-current@freebsd.org" Subject: Re: Tricky subversion import, what to do? 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, 08 Nov 2010 03:22:25 -0000 On 7 Nov 2010, at 21:29, Ulrich Sp=C3=B6rlein wrote: >=20 > As I wrote, that's beside the point and not the question at hand. How/wher= e should it end up in our tree? Is it vendor code? Is it contrib code? And i= f so how to bootstrap the correct subversion history ... It is FreeBSD code so it is already in the right place in the tree. My git r= epository started life as a personal scratch repository which I used for mai= ntaining the in-tree unifdef. It has grown its own release infrastructure fo= r the convenience of its Linux users (there have been a lot of contributions= from Debian). Because of this a lot of the changes are irrelevant to FreeBS= D so I have not kept the FreeBSD version strictly in sync. Please don't mess around with it because you'll just make my maintenance job= harder. Tony. -- f.anthony.n.finch http://dotat.at/= From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 07:14:05 2010 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 F078F106566B for ; Mon, 8 Nov 2010 07:14:05 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id D6FEC8FC16 for ; Mon, 8 Nov 2010 07:14:05 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PFLvY-000HMU-GH for current@freebsd.org; Mon, 08 Nov 2010 07:14:05 +0000 Date: Mon, 08 Nov 2010 15:14:02 +0800 Message-ID: From: Randy Bush To: FreeBSD current mailing list User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Subject: groff build failure 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, 08 Nov 2010 07:14:06 -0000 very current amd64 ===> gnu/usr.bin/groff/src/preproc/eqn (all) c++ -O2 -pipe -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/preproc/eqn -I. -DHAVE_CONFIG_H -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/include -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../src/include -fstack-protector -fno-rtti -fno-exceptions -c eqn.cpp y.tab.c: In function 'int yygrowstack()': y.tab.c:703: error: invalid conversion from 'void*' to 'short int*' y.tab.c:709: error: invalid conversion from 'void*' to 'YYSTYPE*' *** Error code 1 From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 07:15:25 2010 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 78F35106566C for ; Mon, 8 Nov 2010 07:15:25 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 44C688FC14 for ; Mon, 8 Nov 2010 07:15:24 +0000 (UTC) Received: from [192.168.1.100] (m206-63.dsl.tsoft.com [198.144.206.63]) by ns1.feral.com (8.14.4/8.14.3) with ESMTP id oA87FO1Y099859 for ; Sun, 7 Nov 2010 23:15:24 -0800 (PST) (envelope-from mj@feral.com) Message-ID: <4CD7A397.3040700@feral.com> Date: Sun, 07 Nov 2010 23:15:35 -0800 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.67.166.1]); Sun, 07 Nov 2010 23:15:24 -0800 (PST) Subject: Re: groff build failure 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, 08 Nov 2010 07:15:25 -0000 recent change to yacc by someone who will probably back it out in the morning > very current amd64 > > ===> gnu/usr.bin/groff/src/preproc/eqn (all) > c++ -O2 -pipe -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/preproc/eqn -I. -DHAVE_CONFIG_H -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/include -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../src/include -fstack-protector -fno-rtti -fno-exceptions -c eqn.cpp > y.tab.c: In function 'int yygrowstack()': > y.tab.c:703: error: invalid conversion from 'void*' to 'short int*' > y.tab.c:709: error: invalid conversion from 'void*' to 'YYSTYPE*' > *** Error code 1 > _______________________________________________ > 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 Mon Nov 8 09:00:46 2010 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 DB63C1065679; Mon, 8 Nov 2010 09:00:46 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 3F14F8FC17; Mon, 8 Nov 2010 09:00:45 +0000 (UTC) X-Spam-Status: No X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=0.123, required 5, ALL_TRUSTED -1.00, BAYES_05 -0.50, URIBL_SBL 1.62) X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-ID: oA88o0jo015372 Received: from gkeramidas-glaptop.linux.gr ([74.125.57.34]) (authenticated bits=0) by igloo.linux.gr (8.14.3/8.14.3/Debian-9.4) with ESMTP id oA88o0jo015372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 Nov 2010 10:50:08 +0200 From: Giorgos Keramidas To: current@FreeBSD.org References: <20101107135329.GL85693@acme.spoerlein.net> Date: Mon, 08 Nov 2010 09:50:05 +0100 In-Reply-To: <20101107135329.GL85693@acme.spoerlein.net> ("Ulrich =?iso-8859-1?Q?Sp=F6rlein=22's?= message of "Sun, 7 Nov 2010 14:53:29 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: fanf@FreeBSD.org Subject: Re: Tricky subversion import, what to do? 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, 08 Nov 2010 09:00:46 -0000 On Sun, 7 Nov 2010 14:53:29 +0100, Ulrich Sp=F6rlein wr= ote: > Hello, > > this is about importing unifdef 2.4, which has no significant code > changes, but that's not the point. The wiki is of no help for this > particular case. > > We have no exclusive vendor branch for unifdef, instead it has been > converted to svn under vendor/CSRG/dist/usr.bin/unifdef/ and some > parts of its history (eg. r1591) are copied from there: > > A /head/usr.bin/unifdef/Makefile (from /vendor/CSRG/dist/usr.bin/unifd= ef/Makefile:1590) > A /head/usr.bin/unifdef/unifdef.1 (from /vendor/CSRG/dist/usr.bin/unif= def/unifdef.1:1590) > A /head/usr.bin/unifdef/unifdef.c (from /vendor/CSRG/dist/usr.bin/unif= def/unifdef.c:1590) > > So, my first instinct would be to > > $ svn mv $FSVN/vendor/CSRG/dist/usr.bin/unifdef $FSVN/vendor/unifdef/dist > (put all files (or just the necessary subset?) of unifdef-2.4 in vendor/u= nifdef/dist) > $ svn ci > $ svn cp $FSVN/vendor/unifdef/dist $FSVN/vendor/unifdef/2.4 > $ svn cp $FSVN/vendor/unifdef/dist/unifdef.{c,1} $FSVN/head/contrib/unifd= ef/ > $ svn rm head/usr.bin/unifdef/unifdef.{c,1} > (but this part loses the actual history on head, as it was never > committed to the vendor branch) > (update usr.bin/unidef/Makefile to point to contrib/unifdef) > $ svn ci > > But then again, the first steps could also be: > $ svn cp head/usr.bin/unifdef vendor/unifdef/dist; svn ci > $ svn cp vendor/unifdef/dist vendor/unifdef/2.3; svn ci > > This seems more reasonable to me, but I'm not sure what the policy is on > "old stuff" under vendor/ I think it all depends on how "valuable" the merge history from /vendor/CSRG/dist/usr.bin/unifdef to /vendor/unifdef/dist is. IMO it isn't, because we won't be merging from the CSRG code anymore. So I'd prefer the second option. From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 09:55:11 2010 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 4B2431065672; Mon, 8 Nov 2010 09:55:11 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5DAC08FC0A; Mon, 8 Nov 2010 09:55:10 +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 LAA26760; Mon, 08 Nov 2010 11:55:09 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PFORQ-0003lV-M8; Mon, 08 Nov 2010 11:55:08 +0200 Message-ID: <4CD7C8FC.900@icyb.net.ua> Date: Mon, 08 Nov 2010 11:55:08 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-current@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: Subject: another fuse 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, 08 Nov 2010 09:55:11 -0000 JFYI. Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x0 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff80372a64 stack pointer = 0x28:0xffffff81265486f0 frame pointer = 0x28:0xffffff8126548700 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 4080 (initial thread) trap number = 12 panic: page fault cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff801b9b8a = db_trace_self_wrapper+0x2a kdb_backtrace() at 0xffffffff803b36ba = kdb_backtrace+0x3a panic() at 0xffffffff8037c8b2 = panic+0x1d2 trap_fatal() at 0xffffffff8055b35d = trap_fatal+0x39d trap_pfault() at 0xffffffff8055b638 = trap_pfault+0x2b8 trap() at 0xffffffff8055bd33 = trap+0x603 calltrap() at 0xffffffff80545f78 = calltrap+0x8 --- trap 0xc, rip = 0xffffffff80372a64, rsp = 0xffffff81265486f0, rbp = 0xffffff8126548700 --- crhold() at 0xffffffff80372a64 = crhold+0x4 fdata_alloc() at 0xffffffff80e17a9f = fdata_alloc+0xcf fusedev_open() at 0xffffffff80e1896e = fusedev_open+0xae devfs_open() at 0xffffffff802e8fa7 = devfs_open+0x117 VOP_OPEN_APV() at 0xffffffff805bb0c4 = VOP_OPEN_APV+0x74 vn_open_cred() at 0xffffffff804222bd = vn_open_cred+0x4ad vn_open() at 0xffffffff804223dc = vn_open+0x1c kern_openat() at 0xffffffff80420bad = kern_openat+0x15d kern_open() at 0xffffffff80420f29 = kern_open+0x19 open() at 0xffffffff80420f48 = open+0x18 syscallenter() at 0xffffffff803c0f9e = syscallenter+0x3be syscall() at 0xffffffff8055b6b1 = syscall+0x41 Xfast_syscall() at 0xffffffff80546252 = Xfast_syscall+0xe2 NULL pointer is passed as an argument to crhold. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 10:52:31 2010 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 0EB8F106566C; Mon, 8 Nov 2010 10:52:31 +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 A569E8FC14; Mon, 8 Nov 2010 10:52:30 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oA8AqTnp020220; Mon, 8 Nov 2010 05:52:29 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oA8AqTsQ020219; Mon, 8 Nov 2010 10:52:29 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 8 Nov 2010 10:52:29 GMT Message-Id: <201011081052.oA8AqTsQ020219@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, 08 Nov 2010 10:52:31 -0000 TB --- 2010-11-08 10:10:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-08 10:10:00 - starting HEAD tinderbox run for arm/arm TB --- 2010-11-08 10:10:00 - cleaning the object tree TB --- 2010-11-08 10:10:20 - cvsupping the source tree TB --- 2010-11-08 10:10:20 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2010-11-08 10:11:08 - building world TB --- 2010-11-08 10:11:08 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-08 10:11:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-08 10:11:08 - TARGET=arm TB --- 2010-11-08 10:11:08 - TARGET_ARCH=arm TB --- 2010-11-08 10:11:08 - TZ=UTC TB --- 2010-11-08 10:11:08 - __MAKE_CONF=/dev/null TB --- 2010-11-08 10:11:08 - cd /src TB --- 2010-11-08 10:11:08 - /usr/bin/make -B buildworld >>> World build started on Mon Nov 8 10:11:08 UTC 2010 >>> 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 [...] Making grotty.1 from /src/gnu/usr.bin/groff/src/devices/grotty/../../../../../../contrib/groff/src/devices/grotty/grotty.man gzip -cn grotty.1 > grotty.1.gz ===> gnu/usr.bin/groff/src/preproc (all) ===> gnu/usr.bin/groff/src/preproc/eqn (all) c++ -O -pipe -I/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/preproc/eqn -I. -DHAVE_CONFIG_H -I/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/include -I/src/gnu/usr.bin/groff/src/preproc/eqn/../../../src/include -fno-rtti -fno-exceptions -c eqn.cpp y.tab.c: In function 'int yygrowstack()': y.tab.c:703: error: invalid conversion from 'void*' to 'short int*' y.tab.c:709: error: invalid conversion from 'void*' to 'YYSTYPE*' *** Error code 1 Stop in /src/gnu/usr.bin/groff/src/preproc/eqn. *** Error code 1 Stop in /src/gnu/usr.bin/groff/src/preproc. *** Error code 1 Stop in /src/gnu/usr.bin/groff/src. *** Error code 1 Stop in /src/gnu/usr.bin/groff. *** Error code 1 Stop in /src/gnu/usr.bin. *** Error code 1 Stop in /src/gnu. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-08 10:52:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-08 10:52:29 - ERROR: failed to build world TB --- 2010-11-08 10:52:29 - 1752.26 user 540.84 system 2548.82 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 11:36:10 2010 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 C7D04106566B for ; Mon, 8 Nov 2010 11:36:10 +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 512F78FC19 for ; Mon, 8 Nov 2010 11:36:10 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PFQ1A-0001hn-UZ for freebsd-current@freebsd.org; Mon, 08 Nov 2010 12:36:08 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Nov 2010 12:36:08 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Nov 2010 12:36:08 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Mon, 08 Nov 2010 12:35:55 +0100 Lines: 65 Message-ID: References: <4CD7C8FC.900@icyb.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <4CD7C8FC.900@icyb.net.ua> X-Enigmail-Version: 1.1.2 Cc: freebsd-fs@freebsd.org Subject: Re: another fuse 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, 08 Nov 2010 11:36:10 -0000 On 11/08/10 10:55, Andriy Gapon wrote: > > JFYI. > Fatal trap 12: page fault while in kernel mode Can you find any set of circumstances which make this repeatable? This panic apparently goes like this: 1) used by devfs_open(): 47 static struct cdevsw fuse_cdevsw = { 48 .d_open = fusedev_open, 2) in fusedev_open(): 119 fdata = fdata_alloc(dev, td->td_ucred); 3) in fdata_alloc(): 297 data->daemoncred = crhold(cred); in other words, td->td_ucred from td passed to fusedev_open (presumably when the device is opened from the userland) appears to be NULL. I don't know if there is any normal set of circumstances under which this is expected. > cpuid = 1; apic id = 01 > fault virtual address = 0x0 > fault code = supervisor write data, page not present > instruction pointer = 0x20:0xffffffff80372a64 > stack pointer = 0x28:0xffffff81265486f0 > frame pointer = 0x28:0xffffff8126548700 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 4080 (initial thread) > trap number = 12 > panic: page fault > cpuid = 1 > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff801b9b8a = db_trace_self_wrapper+0x2a > kdb_backtrace() at 0xffffffff803b36ba = kdb_backtrace+0x3a > panic() at 0xffffffff8037c8b2 = panic+0x1d2 > trap_fatal() at 0xffffffff8055b35d = trap_fatal+0x39d > trap_pfault() at 0xffffffff8055b638 = trap_pfault+0x2b8 > trap() at 0xffffffff8055bd33 = trap+0x603 > calltrap() at 0xffffffff80545f78 = calltrap+0x8 > --- trap 0xc, rip = 0xffffffff80372a64, rsp = 0xffffff81265486f0, rbp = > 0xffffff8126548700 --- > crhold() at 0xffffffff80372a64 = crhold+0x4 > fdata_alloc() at 0xffffffff80e17a9f = fdata_alloc+0xcf > fusedev_open() at 0xffffffff80e1896e = fusedev_open+0xae > devfs_open() at 0xffffffff802e8fa7 = devfs_open+0x117 > VOP_OPEN_APV() at 0xffffffff805bb0c4 = VOP_OPEN_APV+0x74 > vn_open_cred() at 0xffffffff804222bd = vn_open_cred+0x4ad > vn_open() at 0xffffffff804223dc = vn_open+0x1c > kern_openat() at 0xffffffff80420bad = kern_openat+0x15d > kern_open() at 0xffffffff80420f29 = kern_open+0x19 > open() at 0xffffffff80420f48 = open+0x18 > syscallenter() at 0xffffffff803c0f9e = syscallenter+0x3be > syscall() at 0xffffffff8055b6b1 = syscall+0x41 > Xfast_syscall() at 0xffffffff80546252 = Xfast_syscall+0xe2 > > NULL pointer is passed as an argument to crhold. > From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 11:38:38 2010 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 611FC106564A; Mon, 8 Nov 2010 11:38:38 +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 009ED8FC14; Mon, 8 Nov 2010 11:38:37 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oA8BcbYB027765; Mon, 8 Nov 2010 06:38:37 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oA8BcbnC027761; Mon, 8 Nov 2010 11:38:37 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 8 Nov 2010 11:38:37 GMT Message-Id: <201011081138.oA8BcbnC027761@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, 08 Nov 2010 11:38:38 -0000 TB --- 2010-11-08 10:10:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-08 10:10:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2010-11-08 10:10:00 - cleaning the object tree TB --- 2010-11-08 10:10:31 - cvsupping the source tree TB --- 2010-11-08 10:10:31 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2010-11-08 10:11:08 - building world TB --- 2010-11-08 10:11:08 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-08 10:11:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-08 10:11:08 - TARGET=pc98 TB --- 2010-11-08 10:11:08 - TARGET_ARCH=i386 TB --- 2010-11-08 10:11:08 - TZ=UTC TB --- 2010-11-08 10:11:08 - __MAKE_CONF=/dev/null TB --- 2010-11-08 10:11:08 - cd /src TB --- 2010-11-08 10:11:08 - /usr/bin/make -B buildworld >>> World build started on Mon Nov 8 10:11:08 UTC 2010 >>> 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 [...] Making grotty.1 from /src/gnu/usr.bin/groff/src/devices/grotty/../../../../../../contrib/groff/src/devices/grotty/grotty.man gzip -cn grotty.1 > grotty.1.gz ===> gnu/usr.bin/groff/src/preproc (all) ===> gnu/usr.bin/groff/src/preproc/eqn (all) c++ -O2 -pipe -I/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/preproc/eqn -I. -DHAVE_CONFIG_H -I/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/include -I/src/gnu/usr.bin/groff/src/preproc/eqn/../../../src/include -fstack-protector -fno-rtti -fno-exceptions -c eqn.cpp y.tab.c: In function 'int yygrowstack()': y.tab.c:703: error: invalid conversion from 'void*' to 'short int*' y.tab.c:709: error: invalid conversion from 'void*' to 'YYSTYPE*' *** Error code 1 Stop in /src/gnu/usr.bin/groff/src/preproc/eqn. *** Error code 1 Stop in /src/gnu/usr.bin/groff/src/preproc. *** Error code 1 Stop in /src/gnu/usr.bin/groff/src. *** Error code 1 Stop in /src/gnu/usr.bin/groff. *** Error code 1 Stop in /src/gnu/usr.bin. *** Error code 1 Stop in /src/gnu. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-08 11:38:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-08 11:38:37 - ERROR: failed to build world TB --- 2010-11-08 11:38:37 - 4164.17 user 786.13 system 5316.24 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 11:43:42 2010 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 3DBD6106564A; Mon, 8 Nov 2010 11:43:42 +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 D13AB8FC14; Mon, 8 Nov 2010 11:43:41 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oA8BhfbT050794; Mon, 8 Nov 2010 06:43:41 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oA8Bhfrh050787; Mon, 8 Nov 2010 11:43:41 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 8 Nov 2010 11:43:41 GMT Message-Id: <201011081143.oA8Bhfrh050787@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, 08 Nov 2010 11:43:42 -0000 TB --- 2010-11-08 10:10:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-08 10:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-11-08 10:10:00 - cleaning the object tree TB --- 2010-11-08 10:10:33 - cvsupping the source tree TB --- 2010-11-08 10:10:33 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-11-08 10:16:02 - building world TB --- 2010-11-08 10:16:02 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-08 10:16:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-08 10:16:02 - TARGET=i386 TB --- 2010-11-08 10:16:02 - TARGET_ARCH=i386 TB --- 2010-11-08 10:16:02 - TZ=UTC TB --- 2010-11-08 10:16:02 - __MAKE_CONF=/dev/null TB --- 2010-11-08 10:16:02 - cd /src TB --- 2010-11-08 10:16:02 - /usr/bin/make -B buildworld >>> World build started on Mon Nov 8 10:16:02 UTC 2010 >>> 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 [...] Making grotty.1 from /src/gnu/usr.bin/groff/src/devices/grotty/../../../../../../contrib/groff/src/devices/grotty/grotty.man gzip -cn grotty.1 > grotty.1.gz ===> gnu/usr.bin/groff/src/preproc (all) ===> gnu/usr.bin/groff/src/preproc/eqn (all) c++ -O2 -pipe -I/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/preproc/eqn -I. -DHAVE_CONFIG_H -I/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/include -I/src/gnu/usr.bin/groff/src/preproc/eqn/../../../src/include -fstack-protector -fno-rtti -fno-exceptions -c eqn.cpp y.tab.c: In function 'int yygrowstack()': y.tab.c:703: error: invalid conversion from 'void*' to 'short int*' y.tab.c:709: error: invalid conversion from 'void*' to 'YYSTYPE*' *** Error code 1 Stop in /src/gnu/usr.bin/groff/src/preproc/eqn. *** Error code 1 Stop in /src/gnu/usr.bin/groff/src/preproc. *** Error code 1 Stop in /src/gnu/usr.bin/groff/src. *** Error code 1 Stop in /src/gnu/usr.bin/groff. *** Error code 1 Stop in /src/gnu/usr.bin. *** Error code 1 Stop in /src/gnu. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-08 11:43:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-08 11:43:41 - ERROR: failed to build world TB --- 2010-11-08 11:43:41 - 4173.80 user 761.53 system 5620.13 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 11:44:53 2010 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 8BD7F106564A; Mon, 8 Nov 2010 11:44:53 +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 31D208FC18; Mon, 8 Nov 2010 11:44:52 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oA8BiqqD056715; Mon, 8 Nov 2010 06:44:52 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oA8BiqiY056710; Mon, 8 Nov 2010 11:44:52 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 8 Nov 2010 11:44:52 GMT Message-Id: <201011081144.oA8BiqiY056710@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 amd64/amd64 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, 08 Nov 2010 11:44:53 -0000 TB --- 2010-11-08 10:10:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-08 10:10:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2010-11-08 10:10:00 - cleaning the object tree TB --- 2010-11-08 10:10:53 - cvsupping the source tree TB --- 2010-11-08 10:10:53 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2010-11-08 10:16:21 - building world TB --- 2010-11-08 10:16:21 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-08 10:16:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-08 10:16:21 - TARGET=amd64 TB --- 2010-11-08 10:16:21 - TARGET_ARCH=amd64 TB --- 2010-11-08 10:16:21 - TZ=UTC TB --- 2010-11-08 10:16:21 - __MAKE_CONF=/dev/null TB --- 2010-11-08 10:16:21 - cd /src TB --- 2010-11-08 10:16:21 - /usr/bin/make -B buildworld >>> World build started on Mon Nov 8 10:16:22 UTC 2010 >>> 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 [...] Making grotty.1 from /src/gnu/usr.bin/groff/src/devices/grotty/../../../../../../contrib/groff/src/devices/grotty/grotty.man gzip -cn grotty.1 > grotty.1.gz ===> gnu/usr.bin/groff/src/preproc (all) ===> gnu/usr.bin/groff/src/preproc/eqn (all) c++ -O2 -pipe -I/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/preproc/eqn -I. -DHAVE_CONFIG_H -I/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/include -I/src/gnu/usr.bin/groff/src/preproc/eqn/../../../src/include -fstack-protector -fno-rtti -fno-exceptions -c eqn.cpp y.tab.c: In function 'int yygrowstack()': y.tab.c:703: error: invalid conversion from 'void*' to 'short int*' y.tab.c:709: error: invalid conversion from 'void*' to 'YYSTYPE*' *** Error code 1 Stop in /src/gnu/usr.bin/groff/src/preproc/eqn. *** Error code 1 Stop in /src/gnu/usr.bin/groff/src/preproc. *** Error code 1 Stop in /src/gnu/usr.bin/groff/src. *** Error code 1 Stop in /src/gnu/usr.bin/groff. *** Error code 1 Stop in /src/gnu/usr.bin. *** Error code 1 Stop in /src/gnu. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-08 11:44:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-08 11:44:52 - ERROR: failed to build world TB --- 2010-11-08 11:44:52 - 4211.39 user 772.97 system 5691.53 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 11:50:28 2010 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 CEBF5106566B; Mon, 8 Nov 2010 11:50:28 +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 A85EB8FC1F; Mon, 8 Nov 2010 11:50:27 +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 NAA29427; Mon, 08 Nov 2010 13:50:26 +0200 (EET) (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 1PFQEz-0003un-QK; Mon, 08 Nov 2010 13:50:25 +0200 Message-ID: <4CD7E401.1010206@freebsd.org> Date: Mon, 08 Nov 2010 13:50:25 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-x11@freebsd.org References: <4CD3B1D2.30003@icyb.net.ua> In-Reply-To: <4CD3B1D2.30003@icyb.net.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit Cc: Subject: Re: radeon_cp_texture: page fault with non-sleepable locks held 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, 08 Nov 2010 11:50:28 -0000 on 05/11/2010 09:27 Andriy Gapon said the following: > > I use FreeSBD head and KDE 4 with all the bells and whistles enabled. > Apparently recent KDE update has enabled even more of them, because I started to > have panics with a kernel that has INVARIANTS and WITNESS enabled. I tried to solve the problem by changing drmdev from mutex to sx: http://people.freebsd.org/~avg/drm-sx.diff The things have improved, I am not getting the panic anymore. Instead I have this LOR now: lock order reversal: 1st 0xffffff0001b968a0 drmdev (drmdev) @ /usr/src/sys/dev/drm/drm_drv.c:791 2nd 0xffffff0072a87200 user map (user map) @ /usr/src/sys/vm/vm_map.c:3548 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff801b8b3a = db_trace_self_wrapper+0x2a kdb_backtrace() at 0xffffffff803a7a6a = kdb_backtrace+0x3a _witness_debugger() at 0xffffffff803bd40c = _witness_debugger+0x2c witness_checkorder() at 0xffffffff803be879 = witness_checkorder+0x959 _sx_slock() at 0xffffffff80378af8 = _sx_slock+0x88 _vm_map_lock_read() at 0xffffffff805109e6 = _vm_map_lock_read+0x36 vm_map_lookup() at 0xffffffff805127b4 = vm_map_lookup+0x54 vm_fault() at 0xffffffff805097f9 = vm_fault+0xf9 trap_pfault() at 0xffffffff80545d0f = trap_pfault+0x11f trap() at 0xffffffff80546597 = trap+0x657 calltrap() at 0xffffffff805305c8 = calltrap+0x8 --- trap 0xc, rip = 0xffffffff8054405d, rsp = 0xffffff81241b47f0, rbp = 0xffffff81241b4870 --- copyin() at 0xffffffff8054405d = copyin+0x3d radeon_cp_texture() at 0xffffffff8022fbd7 = radeon_cp_texture+0x167 drm_ioctl() at 0xffffffff8020fa38 = drm_ioctl+0x318 devfs_ioctl_f() at 0xffffffff802dd649 = devfs_ioctl_f+0x109 kern_ioctl() at 0xffffffff803c1107 = kern_ioctl+0x1f7 ioctl() at 0xffffffff803c12c8 = ioctl+0x168 syscallenter() at 0xffffffff803b57be = syscallenter+0x26e syscall() at 0xffffffff80545e52 = syscall+0x42 Xfast_syscall() at 0xffffffff805308a2 = Xfast_syscall+0xe2 Is this a serious LOR? How can I resolve it? > The panic: > Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex drmdev (drmdev) r = 0 (0xffffff0001b968a0) locked @ > /usr/src/sys/dev/drm/drm_drv.c:791 > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff801b8afa = db_trace_self_wrapper+0x2a > kdb_backtrace() at 0xffffffff803a7afa = kdb_backtrace+0x3a > _witness_debugger() at 0xffffffff803bd49c = _witness_debugger+0x2c > witness_warn() at 0xffffffff803bed32 = witness_warn+0x322 > trap() at 0xffffffff8054639f = trap+0x39f > calltrap() at 0xffffffff80530688 = calltrap+0x8 > --- trap 0xc, rip = 0xffffffff8054411d, rsp = 0xffffff81241917f0, rbp = > 0xffffff8124191870 --- > copyin() at 0xffffffff8054411d = copyin+0x3d > radeon_cp_texture() at 0xffffffff8022fcc7 = radeon_cp_texture+0x167 > drm_ioctl() at 0xffffffff8020fa78 = drm_ioctl+0x318 > devfs_ioctl_f() at 0xffffffff802dd739 = devfs_ioctl_f+0x109 > kern_ioctl() at 0xffffffff803c1197 = kern_ioctl+0x1f7 > ioctl() at 0xffffffff803c1358 = ioctl+0x168 > syscallenter() at 0xffffffff803b584e = syscallenter+0x26e > syscall() at 0xffffffff80545f12 = syscall+0x42 > Xfast_syscall() at 0xffffffff80530962 = Xfast_syscall+0xe2 > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x801f96a1c, rsp = 0x7fffffffe7a8, > rbp = 0xc020644e --- > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x832372000 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff8054411d > stack pointer = 0x28:0xffffff81241917f0 > frame pointer = 0x28:0xffffff8124191870 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 3 > current process = 3439 (initial thread) > trap number = 12 > panic: page fault > cpuid = 0 > > > The panic is quite obvious: drmdev mutex is taken and held in drm_ioctl() and > radeon_cp_texture() can perform copyin and/or copyout, so it's a matter of a > chance (or proper workload) to hit a page fault there. > > What's not obvious is how to properly fix this. > Any ideas? > > Probably less important is what started to trigger the problem. Because the > code hasn't been changed in ages and I have never seen this issue before. > But, d'oh, it seems that this issue has been already reported: > http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg67757.html > > I will appreciate any help. > Thanks! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 11:52:15 2010 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 ABBB0106564A; Mon, 8 Nov 2010 11:52:15 +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 4B0248FC08; Mon, 8 Nov 2010 11:52:15 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oA8BqEu4012062; Mon, 8 Nov 2010 06:52:14 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oA8BqEnt012061; Mon, 8 Nov 2010 11:52:14 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 8 Nov 2010 11:52:14 GMT Message-Id: <201011081152.oA8BqEnt012061@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, 08 Nov 2010 11:52:15 -0000 TB --- 2010-11-08 10:52:29 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-08 10:52:29 - starting HEAD tinderbox run for ia64/ia64 TB --- 2010-11-08 10:52:29 - cleaning the object tree TB --- 2010-11-08 10:52:56 - cvsupping the source tree TB --- 2010-11-08 10:52:56 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2010-11-08 10:53:28 - building world TB --- 2010-11-08 10:53:28 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-08 10:53:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-08 10:53:28 - TARGET=ia64 TB --- 2010-11-08 10:53:28 - TARGET_ARCH=ia64 TB --- 2010-11-08 10:53:28 - TZ=UTC TB --- 2010-11-08 10:53:28 - __MAKE_CONF=/dev/null TB --- 2010-11-08 10:53:28 - cd /src TB --- 2010-11-08 10:53:28 - /usr/bin/make -B buildworld >>> World build started on Mon Nov 8 10:53:29 UTC 2010 >>> 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 [...] Making grotty.1 from /src/gnu/usr.bin/groff/src/devices/grotty/../../../../../../contrib/groff/src/devices/grotty/grotty.man gzip -cn grotty.1 > grotty.1.gz ===> gnu/usr.bin/groff/src/preproc (all) ===> gnu/usr.bin/groff/src/preproc/eqn (all) c++ -O2 -pipe -I/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/preproc/eqn -I. -DHAVE_CONFIG_H -I/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/include -I/src/gnu/usr.bin/groff/src/preproc/eqn/../../../src/include -fno-rtti -fno-exceptions -c eqn.cpp y.tab.c: In function 'int yygrowstack()': y.tab.c:703: error: invalid conversion from 'void*' to 'short int*' y.tab.c:709: error: invalid conversion from 'void*' to 'YYSTYPE*' *** Error code 1 Stop in /src/gnu/usr.bin/groff/src/preproc/eqn. *** Error code 1 Stop in /src/gnu/usr.bin/groff/src/preproc. *** Error code 1 Stop in /src/gnu/usr.bin/groff/src. *** Error code 1 Stop in /src/gnu/usr.bin/groff. *** Error code 1 Stop in /src/gnu/usr.bin. *** Error code 1 Stop in /src/gnu. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-08 11:52:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-08 11:52:14 - ERROR: failed to build world TB --- 2010-11-08 11:52:14 - 2664.38 user 543.05 system 3584.73 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 11:55:05 2010 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 1810A106566B; Mon, 8 Nov 2010 11:55:05 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E8F6E8FC0C; Mon, 8 Nov 2010 11:55:03 +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 NAA29560; Mon, 08 Nov 2010 13:55:02 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PFQJS-0003vD-4w; Mon, 08 Nov 2010 13:55:02 +0200 Message-ID: <4CD7E515.5040209@icyb.net.ua> Date: Mon, 08 Nov 2010 13:55:01 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Ivan Voras References: <4CD7C8FC.900@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: another fuse 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, 08 Nov 2010 11:55:05 -0000 on 08/11/2010 13:35 Ivan Voras said the following: > On 11/08/10 10:55, Andriy Gapon wrote: >> >> JFYI. >> Fatal trap 12: page fault while in kernel mode > > Can you find any set of circumstances which make this repeatable? > > This panic apparently goes like this: > > 1) used by devfs_open(): > 47 static struct cdevsw fuse_cdevsw = { > 48 .d_open = fusedev_open, > > 2) in fusedev_open(): > 119 fdata = fdata_alloc(dev, td->td_ucred); > > 3) in fdata_alloc(): > 297 data->daemoncred = crhold(cred); > > in other words, td->td_ucred from td passed to fusedev_open (presumably > when the device is opened from the userland) appears to be NULL. > > I don't know if there is any normal set of circumstances under which > this is expected. I reliable got this panic when all I was doing is saving an attachment in thunderbird 3 that ran in KDE 4 environment. Not sure what was going on behind the scenes, but shouldn't have been anything out of the ordinary. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 12:04:11 2010 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 61E6910656A6; Mon, 8 Nov 2010 12:04:11 +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 A09038FC17; Mon, 8 Nov 2010 12:04:10 +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 oA8C43LJ086489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Nov 2010 14:04:03 +0200 (EET) (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 oA8C43BL096621; Mon, 8 Nov 2010 14:04:03 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oA8C43j3096620; Mon, 8 Nov 2010 14:04:03 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 8 Nov 2010 14:04:03 +0200 From: Kostik Belousov To: Andriy Gapon Message-ID: <20101108120403.GC2392@deviant.kiev.zoral.com.ua> References: <4CD3B1D2.30003@icyb.net.ua> <4CD7E401.1010206@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i1pIEVnkQA3wUJat" Content-Disposition: inline In-Reply-To: <4CD7E401.1010206@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=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, 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-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: radeon_cp_texture: page fault with non-sleepable locks held 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, 08 Nov 2010 12:04:11 -0000 --i1pIEVnkQA3wUJat Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 08, 2010 at 01:50:25PM +0200, Andriy Gapon wrote: > on 05/11/2010 09:27 Andriy Gapon said the following: > >=20 > > I use FreeSBD head and KDE 4 with all the bells and whistles enabled. > > Apparently recent KDE update has enabled even more of them, because I s= tarted to > > have panics with a kernel that has INVARIANTS and WITNESS enabled. >=20 > I tried to solve the problem by changing drmdev from mutex to sx: > http://people.freebsd.org/~avg/drm-sx.diff I remember that drm lock can be acquired from the interrupt thread, if the card supports interrupts. Changing it to sx cannot work then, because interrupt threads cannot sleep. Most likely, you are getting around it since r600 not yet used interrupts on FreeBSD. I think the solution is to drop drm lock around copyin. >=20 > The things have improved, I am not getting the panic anymore. > Instead I have this LOR now: > lock order reversal: > 1st 0xffffff0001b968a0 drmdev (drmdev) @ /usr/src/sys/dev/drm/drm_drv.c:7= 91 > 2nd 0xffffff0072a87200 user map (user map) @ /usr/src/sys/vm/vm_map.c:3548 > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff801b8b3a =3D db_trace_self_wrapper+0= x2a > kdb_backtrace() at 0xffffffff803a7a6a =3D kdb_backtrace+0x3a > _witness_debugger() at 0xffffffff803bd40c =3D _witness_debugger+0x2c > witness_checkorder() at 0xffffffff803be879 =3D witness_checkorder+0x959 > _sx_slock() at 0xffffffff80378af8 =3D _sx_slock+0x88 > _vm_map_lock_read() at 0xffffffff805109e6 =3D _vm_map_lock_read+0x36 > vm_map_lookup() at 0xffffffff805127b4 =3D vm_map_lookup+0x54 > vm_fault() at 0xffffffff805097f9 =3D vm_fault+0xf9 > trap_pfault() at 0xffffffff80545d0f =3D trap_pfault+0x11f > trap() at 0xffffffff80546597 =3D trap+0x657 > calltrap() at 0xffffffff805305c8 =3D calltrap+0x8 > --- trap 0xc, rip =3D 0xffffffff8054405d, rsp =3D 0xffffff81241b47f0, rbp= =3D > 0xffffff81241b4870 --- > copyin() at 0xffffffff8054405d =3D copyin+0x3d > radeon_cp_texture() at 0xffffffff8022fbd7 =3D radeon_cp_texture+0x167 > drm_ioctl() at 0xffffffff8020fa38 =3D drm_ioctl+0x318 > devfs_ioctl_f() at 0xffffffff802dd649 =3D devfs_ioctl_f+0x109 > kern_ioctl() at 0xffffffff803c1107 =3D kern_ioctl+0x1f7 > ioctl() at 0xffffffff803c12c8 =3D ioctl+0x168 > syscallenter() at 0xffffffff803b57be =3D syscallenter+0x26e > syscall() at 0xffffffff80545e52 =3D syscall+0x42 > Xfast_syscall() at 0xffffffff805308a2 =3D Xfast_syscall+0xe2 >=20 > Is this a serious LOR? I think it is. The d_mmap() cdevsw method acquires drm lock. > How can I resolve it? See above. >=20 > > The panic: > > Kernel page fault with the following non-sleepable locks held: > > exclusive sleep mutex drmdev (drmdev) r =3D 0 (0xffffff0001b968a0) lock= ed @ > > /usr/src/sys/dev/drm/drm_drv.c:791 > > KDB: stack backtrace: > > db_trace_self_wrapper() at 0xffffffff801b8afa =3D db_trace_self_wrapper= +0x2a > > kdb_backtrace() at 0xffffffff803a7afa =3D kdb_backtrace+0x3a > > _witness_debugger() at 0xffffffff803bd49c =3D _witness_debugger+0x2c > > witness_warn() at 0xffffffff803bed32 =3D witness_warn+0x322 > > trap() at 0xffffffff8054639f =3D trap+0x39f > > calltrap() at 0xffffffff80530688 =3D calltrap+0x8 > > --- trap 0xc, rip =3D 0xffffffff8054411d, rsp =3D 0xffffff81241917f0, r= bp =3D > > 0xffffff8124191870 --- > > copyin() at 0xffffffff8054411d =3D copyin+0x3d > > radeon_cp_texture() at 0xffffffff8022fcc7 =3D radeon_cp_texture+0x167 > > drm_ioctl() at 0xffffffff8020fa78 =3D drm_ioctl+0x318 > > devfs_ioctl_f() at 0xffffffff802dd739 =3D devfs_ioctl_f+0x109 > > kern_ioctl() at 0xffffffff803c1197 =3D kern_ioctl+0x1f7 > > ioctl() at 0xffffffff803c1358 =3D ioctl+0x168 > > syscallenter() at 0xffffffff803b584e =3D syscallenter+0x26e > > syscall() at 0xffffffff80545f12 =3D syscall+0x42 > > Xfast_syscall() at 0xffffffff80530962 =3D Xfast_syscall+0xe2 > > --- syscall (54, FreeBSD ELF64, ioctl), rip =3D 0x801f96a1c, rsp =3D 0x= 7fffffffe7a8, > > rbp =3D 0xc020644e --- > >=20 > >=20 > > Fatal trap 12: page fault while in kernel mode > > cpuid =3D 0; apic id =3D 00 > > fault virtual address =3D 0x832372000 > > fault code =3D supervisor read data, page not present > > instruction pointer =3D 0x20:0xffffffff8054411d > > stack pointer =3D 0x28:0xffffff81241917f0 > > frame pointer =3D 0x28:0xffffff8124191870 > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags =3D interrupt enabled, resume, IOPL =3D 3 > > current process =3D 3439 (initial thread) > > trap number =3D 12 > > panic: page fault > > cpuid =3D 0 > >=20 > >=20 > > The panic is quite obvious: drmdev mutex is taken and held in drm_ioctl= () and > > radeon_cp_texture() can perform copyin and/or copyout, so it's a matter= of a > > chance (or proper workload) to hit a page fault there. > >=20 > > What's not obvious is how to properly fix this. > > Any ideas? > >=20 > > Probably less important is what started to trigger the problem. Becaus= e the > > code hasn't been changed in ages and I have never seen this issue befor= e. > > But, d'oh, it seems that this issue has been already reported: > > http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg67757.html > >=20 > > I will appreciate any help. > > Thanks! >=20 >=20 > --=20 > Andriy Gapon --i1pIEVnkQA3wUJat Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzX5zIACgkQC3+MBN1Mb4iYCQCg69m64iuVew7hcbIqf7PdA6G6 KXEAnjxNj7QvJMFQthFHcZ4mNeFNVLwI =gS5A -----END PGP SIGNATURE----- --i1pIEVnkQA3wUJat-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 12:07:47 2010 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 E56B7106566C; Mon, 8 Nov 2010 12:07:47 +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 0664E8FC1C; Mon, 8 Nov 2010 12:07:46 +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 OAA29754; Mon, 08 Nov 2010 14:07:44 +0200 (EET) (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 1PFQVk-0003wZ-Jo; Mon, 08 Nov 2010 14:07:44 +0200 Message-ID: <4CD7E80F.4090100@freebsd.org> Date: Mon, 08 Nov 2010 14:07:43 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Kostik Belousov References: <4CD3B1D2.30003@icyb.net.ua> <4CD7E401.1010206@freebsd.org> <20101108120403.GC2392@deviant.kiev.zoral.com.ua> In-Reply-To: <20101108120403.GC2392@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: radeon_cp_texture: page fault with non-sleepable locks held 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, 08 Nov 2010 12:07:48 -0000 on 08/11/2010 14:04 Kostik Belousov said the following: > On Mon, Nov 08, 2010 at 01:50:25PM +0200, Andriy Gapon wrote: >> on 05/11/2010 09:27 Andriy Gapon said the following: >>> >>> I use FreeSBD head and KDE 4 with all the bells and whistles enabled. >>> Apparently recent KDE update has enabled even more of them, because I started to >>> have panics with a kernel that has INVARIANTS and WITNESS enabled. >> >> I tried to solve the problem by changing drmdev from mutex to sx: >> http://people.freebsd.org/~avg/drm-sx.diff > I remember that drm lock can be acquired from the interrupt thread, if > the card supports interrupts. Changing it to sx cannot work then, because > interrupt threads cannot sleep. Most likely, you are getting around it > since r600 not yet used interrupts on FreeBSD. > > I think the solution is to drop drm lock around copyin. Kostik, thanks a lot for the help! Are familiar enough with the code to tell if drmdev is always held at that place? Or should I first check if it's actually owned and drop/reacquire it accordingly? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 12:09:43 2010 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 6F760106566B; Mon, 8 Nov 2010 12:09:43 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 1492D8FC1E; Mon, 8 Nov 2010 12:09:42 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAFACp310yDaFvO/2dsb2JhbACDMZBSjnKsI5BGgSKDM3MEhFiFfQ X-IronPort-AV: E=Sophos;i="4.58,313,1286164800"; d="scan'208";a="99962753" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 08 Nov 2010 07:09:42 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 09952B3F3A; Mon, 8 Nov 2010 07:09:41 -0500 (EST) Date: Mon, 8 Nov 2010 07:09:41 -0500 (EST) From: Rick Macklem To: pyunyh@gmail.com Message-ID: <970925941.232054.1289218181757.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20101108014022.GG1279@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.225.56.115] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL4_64) Cc: alc@freebsd.org, freebsd-current@freebsd.org Subject: Re: re(4) driver dropping packets when reading NFS 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: Mon, 08 Nov 2010 12:09:43 -0000 > > By chance, how about disabling RX early interrupt? > You can add the following 3 lines of code into re_init_locked(). > > 2710 /* > 2711 * Set the initial RX configuration. > 2712 */ > 2713 re_set_rxmode(sc); > 2714 > 2715 /* Disable RX early interrupt. */ > 2716 cfg = CSR_READ_2(sc, RL_MULTIINTR); > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > 2717 cfg &= 0xF000; > ^^^^^^^^^^^^^^ > 2718 CSR_WRITE_2(sc, RL_MULTIINTR, cfg); > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > 2719 > 2720 #ifdef DEVICE_POLLING > Afraid it didn't help. I've also discovered that the June 7 kernel only performs better sometimes. I see 500Kbytes/sec read rate on it for most of the test runs. (It does work better sometimes, but maybe the -current kernel would too, if I ran for long enough with it.) I can try some other variations of enabling interrupts in early Dec, rick From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 12:10:13 2010 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 A090B1065673 for ; Mon, 8 Nov 2010 12:10:13 +0000 (UTC) (envelope-from admin@kkip.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id E50168FC14 for ; Mon, 8 Nov 2010 12:10:12 +0000 (UTC) Received: from static-78-8-144-74.ssp.dialog.net.pl ([78.8.144.74] helo=[192.168.0.2]) by mainframe.kkip.pl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PFQAX-000HDD-Jj for freebsd-current@freebsd.org; Mon, 08 Nov 2010 12:45:58 +0100 Message-ID: <4CD7E2EB.1070708@kkip.pl> Date: Mon, 08 Nov 2010 12:45:47 +0100 From: Bartosz Stec User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.4) Gecko/20100702 Lanikai/3.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Authenticated-User: admin@kkip.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.6 X-Spam-Score-Int: -85 X-Exim-Version: 4.72 (build at 10-Jun-2010 13:05:33) X-Date: 2010-11-08 12:45:58 X-Connected-IP: 78.8.144.74:65108 X-Message-Linecount: 192 X-Body-Linecount: 182 X-Message-Size: 7846 X-Body-Size: 7460 X-Received-Count: 1 X-Recipient-Count: 1 X-Local-Recipient-Count: 1 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: powerd vs network throughput 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, 08 Nov 2010 12:10:13 -0000 Hello. I'm using r214746 FreeBSD system as a home fileserver/router, with athlon xp mobile onboard: CPU: mobile AMD Athlon(tm) XP 2200+ (1800.10-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x681 Family = 6 Model = 8 Stepping = 1 Features=0x383fbff AMD Features=0xc0480800 I've set powerd in rc.conf: powerd_enable="YES" powerd_flags="-a hadp -b hadp -n max" And it seems to work as intended: # sysctl -a | grep cpu kern.ccpu: 0 kern.sched.cpusetsize: 4 kern.smp.cpus: 1 kern.smp.maxcpus: 1 net.inet.tcp.per_cpu_timers: 0 debug.cpufreq.verbose: 0 debug.cpufreq.lowest: 0 hw.ncpu: 1 hw.acpi.cpu.cx_lowest: C1 security.jail.param.cpuset.id: 0 dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU1 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 787 dev.cpu.0.freq_levels: 1800/-1 1687/-1 1575/-1 1462/-1 1350/-1 1237/-1 1125/-1 1012/-1 900/-1 787/-1 675/-1 562/-1 450/-1 337/-1 225/-1 112/-1 dev.cpu.0.cx_supported: C1/0 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% last 834us dev.acpi_throttle.0.%parent: cpu0 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 PC is connected to home network via 3Com NIC: xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xec00-0xec7f mem 0xdfffff80-0xdfffffff irq 17 at device 6.0 on pci0 miibus0: on xl0 xlphy0: <3Com internal media interface> PHY 0 on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xlphy1: <3Com internal media interface> PHY 24 on miibus0 xlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:50:da:d8:23:cd # ifconfig xl0 xl0: flags=8843 metric 0 mtu 1500 options=82009 ether 00:50:da:d8:23:cd inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 inet6 fe80::250:daff:fed8:23cd%xl0 prefixlen 64 scopeid 0x1 nd6 options=29 media: Ethernet autoselect (100baseTX ) status: active Now here's the problem: When I try to write a file on a samba share on this PC while it's idle, I got ridiculous throughput like 6-120kB/s on 100Mbit link, but If machine is busy, speed increase to 5-6 MB/s. It seems that throughput is limited by CPU frequency and powerd doesn't increase cpu frequency level in this case (I suppose that if CPU is set at very low frequency, it's dealing mostly with interrupt requests from NIC). Is it expected behaviour? I hope not because it makes powerd useless on fileserver ;) If it's worth anything this is ZFS-only RAIDZ system with 1GB RAM. -- Bartosz Stec From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 12:13:23 2010 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 683B61065679; Mon, 8 Nov 2010 12:13:23 +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 4D5C08FC26; Mon, 8 Nov 2010 12:13:21 +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 OAA29823; Mon, 08 Nov 2010 14:13:20 +0200 (EET) (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 1PFQbA-0003x3-Ia; Mon, 08 Nov 2010 14:13:20 +0200 Message-ID: <4CD7E960.1070200@freebsd.org> Date: Mon, 08 Nov 2010 14:13:20 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Ivan Voras References: <4CD7C8FC.900@icyb.net.ua> <4CD7E515.5040209@icyb.net.ua> In-Reply-To: <4CD7E515.5040209@icyb.net.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: another fuse 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, 08 Nov 2010 12:13:23 -0000 on 08/11/2010 13:55 Andriy Gapon said the following: > I reliable got this panic when all I was doing is saving an attachment in > thunderbird 3 that ran in KDE 4 environment. Not sure what was going on behind > the scenes, but shouldn't have been anything out of the ordinary. Perhaps this is my local mistake. I can't see from code and crash dump how NULL pointer is possible there. So perhaps I have some ABI mismatch between kernel and fuse module. I will rebuild fuse kmod and re-test again. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 12:23:09 2010 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 B91BA106566B; Mon, 8 Nov 2010 12:23: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 5E0858FC17; Mon, 8 Nov 2010 12:23:09 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oA8CN886093074; Mon, 8 Nov 2010 07:23:08 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oA8CN8hd093069; Mon, 8 Nov 2010 12:23:08 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 8 Nov 2010 12:23:08 GMT Message-Id: <201011081223.oA8CN8hd093069@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, 08 Nov 2010 12:23:09 -0000 TB --- 2010-11-08 11:38:37 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-08 11:38:37 - starting HEAD tinderbox run for mips/mips TB --- 2010-11-08 11:38:37 - cleaning the object tree TB --- 2010-11-08 11:38:51 - cvsupping the source tree TB --- 2010-11-08 11:38:51 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2010-11-08 11:39:15 - building world TB --- 2010-11-08 11:39:15 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-08 11:39:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-08 11:39:15 - TARGET=mips TB --- 2010-11-08 11:39:15 - TARGET_ARCH=mips TB --- 2010-11-08 11:39:15 - TZ=UTC TB --- 2010-11-08 11:39:15 - __MAKE_CONF=/dev/null TB --- 2010-11-08 11:39:15 - cd /src TB --- 2010-11-08 11:39:15 - /usr/bin/make -B buildworld >>> World build started on Mon Nov 8 11:39:16 UTC 2010 >>> 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 [...] Making grotty.1 from /src/gnu/usr.bin/groff/src/devices/grotty/../../../../../../contrib/groff/src/devices/grotty/grotty.man gzip -cn grotty.1 > grotty.1.gz ===> gnu/usr.bin/groff/src/preproc (all) ===> gnu/usr.bin/groff/src/preproc/eqn (all) c++ -O -pipe -G0 -I/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/preproc/eqn -I. -DHAVE_CONFIG_H -I/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/include -I/src/gnu/usr.bin/groff/src/preproc/eqn/../../../src/include -fno-rtti -fno-exceptions -c eqn.cpp y.tab.c: In function 'int yygrowstack()': y.tab.c:703: error: invalid conversion from 'void*' to 'short int*' y.tab.c:709: error: invalid conversion from 'void*' to 'YYSTYPE*' *** Error code 1 Stop in /src/gnu/usr.bin/groff/src/preproc/eqn. *** Error code 1 Stop in /src/gnu/usr.bin/groff/src/preproc. *** Error code 1 Stop in /src/gnu/usr.bin/groff/src. *** Error code 1 Stop in /src/gnu/usr.bin/groff. *** Error code 1 Stop in /src/gnu/usr.bin. *** Error code 1 Stop in /src/gnu. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-08 12:23:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-08 12:23:08 - ERROR: failed to build world TB --- 2010-11-08 12:23:08 - 1815.44 user 524.55 system 2671.33 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 12:26:51 2010 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 E1E521065670; Mon, 8 Nov 2010 12:26:51 +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 3C4508FC17; Mon, 8 Nov 2010 12:26:50 +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 oA8CQhUu088435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Nov 2010 14:26:43 +0200 (EET) (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 oA8CQhqE022822; Mon, 8 Nov 2010 14:26:43 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oA8CQhCU022821; Mon, 8 Nov 2010 14:26:43 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 8 Nov 2010 14:26:43 +0200 From: Kostik Belousov To: Andriy Gapon Message-ID: <20101108122643.GE2392@deviant.kiev.zoral.com.ua> References: <4CD3B1D2.30003@icyb.net.ua> <4CD7E401.1010206@freebsd.org> <20101108120403.GC2392@deviant.kiev.zoral.com.ua> <4CD7E80F.4090100@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iTK5zgLp6gXhzOi1" Content-Disposition: inline In-Reply-To: <4CD7E80F.4090100@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=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, 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-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: radeon_cp_texture: page fault with non-sleepable locks held 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, 08 Nov 2010 12:26:52 -0000 --iTK5zgLp6gXhzOi1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 08, 2010 at 02:07:43PM +0200, Andriy Gapon wrote: > on 08/11/2010 14:04 Kostik Belousov said the following: > > On Mon, Nov 08, 2010 at 01:50:25PM +0200, Andriy Gapon wrote: > >> on 05/11/2010 09:27 Andriy Gapon said the following: > >>> > >>> I use FreeSBD head and KDE 4 with all the bells and whistles enabled. > >>> Apparently recent KDE update has enabled even more of them, because I= started to > >>> have panics with a kernel that has INVARIANTS and WITNESS enabled. > >> > >> I tried to solve the problem by changing drmdev from mutex to sx: > >> http://people.freebsd.org/~avg/drm-sx.diff > > I remember that drm lock can be acquired from the interrupt thread, if > > the card supports interrupts. Changing it to sx cannot work then, becau= se > > interrupt threads cannot sleep. Most likely, you are getting around it > > since r600 not yet used interrupts on FreeBSD. > >=20 > > I think the solution is to drop drm lock around copyin. >=20 > Kostik, >=20 > thanks a lot for the help! > Are familiar enough with the code to tell if drmdev is always held at that > place? Or should I first check if it's actually owned and drop/reacquire= it > accordingly? I think you can assume that the lock is always owned. --iTK5zgLp6gXhzOi1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzX7IIACgkQC3+MBN1Mb4jB1wCgyV//8jHNz1bQucRshL/u/oh+ c0YAoLWMqVoUJYj4O4p/Xwxirsbwbd7O =MrAg -----END PGP SIGNATURE----- --iTK5zgLp6gXhzOi1-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 12:37:30 2010 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 1000B106564A; Mon, 8 Nov 2010 12:37:30 +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 A3CA78FC14; Mon, 8 Nov 2010 12:37:29 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oA8CbSgL082311; Mon, 8 Nov 2010 07:37:28 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oA8CbSNM082306; Mon, 8 Nov 2010 12:37:28 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 8 Nov 2010 12:37:28 GMT Message-Id: <201011081237.oA8CbSNM082306@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: Mon, 08 Nov 2010 12:37:30 -0000 TB --- 2010-11-08 11:44:52 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-08 11:44:52 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-11-08 11:44:52 - cleaning the object tree TB --- 2010-11-08 11:45:25 - cvsupping the source tree TB --- 2010-11-08 11:45:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-11-08 11:45:43 - building world TB --- 2010-11-08 11:45:43 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-08 11:45:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-08 11:45:43 - TARGET=powerpc TB --- 2010-11-08 11:45:43 - TARGET_ARCH=powerpc64 TB --- 2010-11-08 11:45:43 - TZ=UTC TB --- 2010-11-08 11:45:43 - __MAKE_CONF=/dev/null TB --- 2010-11-08 11:45:43 - cd /src TB --- 2010-11-08 11:45:43 - /usr/bin/make -B buildworld >>> World build started on Mon Nov 8 11:45:43 UTC 2010 >>> 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 [...] Making grotty.1 from /src/gnu/usr.bin/groff/src/devices/grotty/../../../../../../contrib/groff/src/devices/grotty/grotty.man gzip -cn grotty.1 > grotty.1.gz ===> gnu/usr.bin/groff/src/preproc (all) ===> gnu/usr.bin/groff/src/preproc/eqn (all) c++ -O2 -pipe -I/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/preproc/eqn -I. -DHAVE_CONFIG_H -I/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/include -I/src/gnu/usr.bin/groff/src/preproc/eqn/../../../src/include -fstack-protector -fno-rtti -fno-exceptions -c eqn.cpp y.tab.c: In function 'int yygrowstack()': y.tab.c:703: error: invalid conversion from 'void*' to 'short int*' y.tab.c:709: error: invalid conversion from 'void*' to 'YYSTYPE*' *** Error code 1 Stop in /src/gnu/usr.bin/groff/src/preproc/eqn. *** Error code 1 Stop in /src/gnu/usr.bin/groff/src/preproc. *** Error code 1 Stop in /src/gnu/usr.bin/groff/src. *** Error code 1 Stop in /src/gnu/usr.bin/groff. *** Error code 1 Stop in /src/gnu/usr.bin. *** Error code 1 Stop in /src/gnu. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-08 12:37:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-08 12:37:28 - ERROR: failed to build world TB --- 2010-11-08 12:37:28 - 2272.52 user 557.13 system 3156.24 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 12:40:18 2010 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 6F4C8106564A; Mon, 8 Nov 2010 12:40:18 +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 125658FC1E; Mon, 8 Nov 2010 12:40:17 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oA8CeHFu092800; Mon, 8 Nov 2010 07:40:17 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oA8CeHZe092798; Mon, 8 Nov 2010 12:40:17 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 8 Nov 2010 12:40:17 GMT Message-Id: <201011081240.oA8CeHZe092798@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, 08 Nov 2010 12:40:18 -0000 TB --- 2010-11-08 11:52:14 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-08 11:52:14 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-11-08 11:52:14 - cleaning the object tree TB --- 2010-11-08 11:52:36 - cvsupping the source tree TB --- 2010-11-08 11:52:36 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2010-11-08 11:52:57 - building world TB --- 2010-11-08 11:52:57 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-08 11:52:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-08 11:52:57 - TARGET=sparc64 TB --- 2010-11-08 11:52:57 - TARGET_ARCH=sparc64 TB --- 2010-11-08 11:52:57 - TZ=UTC TB --- 2010-11-08 11:52:57 - __MAKE_CONF=/dev/null TB --- 2010-11-08 11:52:57 - cd /src TB --- 2010-11-08 11:52:57 - /usr/bin/make -B buildworld >>> World build started on Mon Nov 8 11:52:58 UTC 2010 >>> 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 [...] Making grotty.1 from /src/gnu/usr.bin/groff/src/devices/grotty/../../../../../../contrib/groff/src/devices/grotty/grotty.man gzip -cn grotty.1 > grotty.1.gz ===> gnu/usr.bin/groff/src/preproc (all) ===> gnu/usr.bin/groff/src/preproc/eqn (all) c++ -O2 -pipe -I/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/preproc/eqn -I. -DHAVE_CONFIG_H -I/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/include -I/src/gnu/usr.bin/groff/src/preproc/eqn/../../../src/include -fstack-protector -fno-rtti -fno-exceptions -c eqn.cpp y.tab.c: In function 'int yygrowstack()': y.tab.c:703: error: invalid conversion from 'void*' to 'short int*' y.tab.c:709: error: invalid conversion from 'void*' to 'YYSTYPE*' *** Error code 1 Stop in /src/gnu/usr.bin/groff/src/preproc/eqn. *** Error code 1 Stop in /src/gnu/usr.bin/groff/src/preproc. *** Error code 1 Stop in /src/gnu/usr.bin/groff/src. *** Error code 1 Stop in /src/gnu/usr.bin/groff. *** Error code 1 Stop in /src/gnu/usr.bin. *** Error code 1 Stop in /src/gnu. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-08 12:40:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-08 12:40:17 - ERROR: failed to build world TB --- 2010-11-08 12:40:17 - 2064.12 user 534.56 system 2882.35 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 12:56:27 2010 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 20B21106564A for ; Mon, 8 Nov 2010 12:56:27 +0000 (UTC) (envelope-from adrian.chadd@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 A5C6E8FC0C for ; Mon, 8 Nov 2010 12:56:26 +0000 (UTC) Received: by wwb34 with SMTP id 34so31662wwb.31 for ; Mon, 08 Nov 2010 04:56:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=VbmIR/UoAkQoKPGo8oKQCJ3UlEpW84P0OtkJlkGx2JM=; b=EU4Uk7ReWTosizGsDfazDI5moSk4D81SIuZRbbZOl2YAFVLiE07vxJjgdraVuz3hkf ekpCawKN9ZaL67OMEM2HtmNOCJId5+rt1jMFvf5OcWomoG2fpR00XNtG7zjaC1XrWcWN VeHLNRhc48dABaLKDzhvgs8jFvvSgYIbb6f58= 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=n9J5U8XtgTGg8d26Birv8EhvUu8MsU+aTPy+0r+53TwYa43oajYc+0CAwc2FbFR/f9 2zeJ/AW3IbOrXPOX8cWVZKo/Zh7v3GbIXw4y9XXgwmGkWTkEIp+oAvgIljBCxpZGi2Ce MSBeyB18f6X/azobtiVlu2YSMNbyxD8hFVGq0= MIME-Version: 1.0 Received: by 10.216.68.21 with SMTP id k21mr2080317wed.107.1289219501313; Mon, 08 Nov 2010 04:31:41 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.168.200 with HTTP; Mon, 8 Nov 2010 04:31:41 -0800 (PST) In-Reply-To: References: Date: Mon, 8 Nov 2010 20:31:41 +0800 X-Google-Sender-Auth: oqniIzezuKLWpguD3ju2Vq4qa2k Message-ID: From: Adrian Chadd To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current Subject: Re: breaking the crunchgen logic into a share/mk file 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, 08 Nov 2010 12:56:27 -0000 Hi all, I plan on committing this later on this week if there are no objections. I don't plan on back-porting it to RELENG_8. Others are more than welcome to. Thanks, Adrian On 5 October 2010 10:36, Adrian Chadd wrote: > Hi, > > I've broken out the crunchgen logic from src/rescue/rescue into a > share/mk file - that way it can be reused in other areas. > > The diff is here: http://people.freebsd.org/~adrian/crunchgen-mk.diff > > This bsd.crunchgen.mk file is generic enough to use in my > busybox-style thing as well as for src/rescue/rescue/. > > Comments, feedback, etc welcome! > > > Adrian > From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 13:03:03 2010 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 963F81065670; Mon, 8 Nov 2010 13:03: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 3E3F28FC17; Mon, 8 Nov 2010 13:03:03 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oA8D320I092059; Mon, 8 Nov 2010 08:03:02 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oA8D32Gx092058; Mon, 8 Nov 2010 13:03:02 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 8 Nov 2010 13:03:02 GMT Message-Id: <201011081303.oA8D32Gx092058@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, 08 Nov 2010 13:03:03 -0000 TB --- 2010-11-08 11:43:41 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-08 11:43:41 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-11-08 11:43:41 - cleaning the object tree TB --- 2010-11-08 11:44:03 - cvsupping the source tree TB --- 2010-11-08 11:44:03 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-11-08 11:44:25 - building world TB --- 2010-11-08 11:44:25 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-08 11:44:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-08 11:44:25 - TARGET=powerpc TB --- 2010-11-08 11:44:25 - TARGET_ARCH=powerpc TB --- 2010-11-08 11:44:25 - TZ=UTC TB --- 2010-11-08 11:44:25 - __MAKE_CONF=/dev/null TB --- 2010-11-08 11:44:25 - cd /src TB --- 2010-11-08 11:44:25 - /usr/bin/make -B buildworld >>> World build started on Mon Nov 8 11:44:26 UTC 2010 >>> 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 [...] Making grotty.1 from /src/gnu/usr.bin/groff/src/devices/grotty/../../../../../../contrib/groff/src/devices/grotty/grotty.man gzip -cn grotty.1 > grotty.1.gz ===> gnu/usr.bin/groff/src/preproc (all) ===> gnu/usr.bin/groff/src/preproc/eqn (all) c++ -O2 -pipe -I/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/preproc/eqn -I. -DHAVE_CONFIG_H -I/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/include -I/src/gnu/usr.bin/groff/src/preproc/eqn/../../../src/include -fstack-protector -fno-rtti -fno-exceptions -c eqn.cpp y.tab.c: In function 'int yygrowstack()': y.tab.c:703: error: invalid conversion from 'void*' to 'short int*' y.tab.c:709: error: invalid conversion from 'void*' to 'YYSTYPE*' *** Error code 1 Stop in /src/gnu/usr.bin/groff/src/preproc/eqn. *** Error code 1 Stop in /src/gnu/usr.bin/groff/src/preproc. *** Error code 1 Stop in /src/gnu/usr.bin/groff/src. *** Error code 1 Stop in /src/gnu/usr.bin/groff. *** Error code 1 Stop in /src/gnu/usr.bin. *** Error code 1 Stop in /src/gnu. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-08 13:03:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-08 13:03:02 - ERROR: failed to build world TB --- 2010-11-08 13:03:02 - 3798.81 user 701.41 system 4761.34 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 13:06:06 2010 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 DC1591065670; Mon, 8 Nov 2010 13:06:06 +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 F08668FC1B; Mon, 8 Nov 2010 13:06:05 +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 PAA01039; Mon, 08 Nov 2010 15:06:02 +0200 (EET) (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 1PFRQA-00041A-5l; Mon, 08 Nov 2010 15:06:02 +0200 Message-ID: <4CD7F5B9.3010606@freebsd.org> Date: Mon, 08 Nov 2010 15:06:01 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Kostik Belousov References: <4CD3B1D2.30003@icyb.net.ua> <4CD7E401.1010206@freebsd.org> <20101108120403.GC2392@deviant.kiev.zoral.com.ua> In-Reply-To: <20101108120403.GC2392@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: radeon_cp_texture: page fault with non-sleepable locks held 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, 08 Nov 2010 13:06:07 -0000 on 08/11/2010 14:04 Kostik Belousov said the following: > On Mon, Nov 08, 2010 at 01:50:25PM +0200, Andriy Gapon wrote: >> on 05/11/2010 09:27 Andriy Gapon said the following: >>> Kernel page fault with the following non-sleepable locks held: >>> exclusive sleep mutex drmdev (drmdev) r = 0 (0xffffff0001b968a0) locked @ >>> /usr/src/sys/dev/drm/drm_drv.c:791 >>> KDB: stack backtrace: >>> db_trace_self_wrapper() at 0xffffffff801b8afa = db_trace_self_wrapper+0x2a >>> kdb_backtrace() at 0xffffffff803a7afa = kdb_backtrace+0x3a >>> _witness_debugger() at 0xffffffff803bd49c = _witness_debugger+0x2c >>> witness_warn() at 0xffffffff803bed32 = witness_warn+0x322 >>> trap() at 0xffffffff8054639f = trap+0x39f Kostik, a tangential question - do you think that it would make sense to put a check like the above (in trap) into copyin/copyout (but non-fatal), so that we can catch such situations pro-actively (without having to wait for a page fault to actually happen)? >>> calltrap() at 0xffffffff80530688 = calltrap+0x8 >>> --- trap 0xc, rip = 0xffffffff8054411d, rsp = 0xffffff81241917f0, rbp = >>> 0xffffff8124191870 --- >>> copyin() at 0xffffffff8054411d = copyin+0x3d >>> radeon_cp_texture() at 0xffffffff8022fcc7 = radeon_cp_texture+0x167 >>> drm_ioctl() at 0xffffffff8020fa78 = drm_ioctl+0x318 >>> devfs_ioctl_f() at 0xffffffff802dd739 = devfs_ioctl_f+0x109 >>> kern_ioctl() at 0xffffffff803c1197 = kern_ioctl+0x1f7 >>> ioctl() at 0xffffffff803c1358 = ioctl+0x168 >>> syscallenter() at 0xffffffff803b584e = syscallenter+0x26e >>> syscall() at 0xffffffff80545f12 = syscall+0x42 >>> Xfast_syscall() at 0xffffffff80530962 = Xfast_syscall+0xe2 >>> --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x801f96a1c, rsp = 0x7fffffffe7a8, >>> rbp = 0xc020644e --- -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 13:07:00 2010 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 A36951065672; Mon, 8 Nov 2010 13:07:00 +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 4AA818FC1B; Mon, 8 Nov 2010 13:06:59 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oA8D6xg2095218; Mon, 8 Nov 2010 08:06:59 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oA8D6xBr095217; Mon, 8 Nov 2010 13:06:59 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 8 Nov 2010 13:06:59 GMT Message-Id: <201011081306.oA8D6xBr095217@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, 08 Nov 2010 13:07:00 -0000 TB --- 2010-11-08 12:23:08 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-08 12:23:08 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2010-11-08 12:23:08 - cleaning the object tree TB --- 2010-11-08 12:23:28 - cvsupping the source tree TB --- 2010-11-08 12:23:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2010-11-08 12:23:46 - building world TB --- 2010-11-08 12:23:46 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-08 12:23:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-08 12:23:46 - TARGET=sun4v TB --- 2010-11-08 12:23:46 - TARGET_ARCH=sparc64 TB --- 2010-11-08 12:23:46 - TZ=UTC TB --- 2010-11-08 12:23:46 - __MAKE_CONF=/dev/null TB --- 2010-11-08 12:23:46 - cd /src TB --- 2010-11-08 12:23:46 - /usr/bin/make -B buildworld >>> World build started on Mon Nov 8 12:23:47 UTC 2010 >>> 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 [...] Making grotty.1 from /src/gnu/usr.bin/groff/src/devices/grotty/../../../../../../contrib/groff/src/devices/grotty/grotty.man gzip -cn grotty.1 > grotty.1.gz ===> gnu/usr.bin/groff/src/preproc (all) ===> gnu/usr.bin/groff/src/preproc/eqn (all) c++ -O2 -pipe -I/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/preproc/eqn -I. -DHAVE_CONFIG_H -I/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/include -I/src/gnu/usr.bin/groff/src/preproc/eqn/../../../src/include -fstack-protector -fno-rtti -fno-exceptions -c eqn.cpp y.tab.c: In function 'int yygrowstack()': y.tab.c:703: error: invalid conversion from 'void*' to 'short int*' y.tab.c:709: error: invalid conversion from 'void*' to 'YYSTYPE*' *** Error code 1 Stop in /src/gnu/usr.bin/groff/src/preproc/eqn. *** Error code 1 Stop in /src/gnu/usr.bin/groff/src/preproc. *** Error code 1 Stop in /src/gnu/usr.bin/groff/src. *** Error code 1 Stop in /src/gnu/usr.bin/groff. *** Error code 1 Stop in /src/gnu/usr.bin. *** Error code 1 Stop in /src/gnu. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-08 13:06:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-08 13:06:59 - ERROR: failed to build world TB --- 2010-11-08 13:06:59 - 2032.94 user 483.83 system 2630.51 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 13:16:25 2010 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 2C536106566B; Mon, 8 Nov 2010 13:16:25 +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 AFAE88FC13; Mon, 8 Nov 2010 13:16:24 +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 oA8DGKEo092214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Nov 2010 15:16:20 +0200 (EET) (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 oA8DGKPH094216; Mon, 8 Nov 2010 15:16:20 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oA8DGKO8094215; Mon, 8 Nov 2010 15:16:20 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 8 Nov 2010 15:16:20 +0200 From: Kostik Belousov To: Andriy Gapon Message-ID: <20101108131620.GG2392@deviant.kiev.zoral.com.ua> References: <4CD3B1D2.30003@icyb.net.ua> <4CD7E401.1010206@freebsd.org> <20101108120403.GC2392@deviant.kiev.zoral.com.ua> <4CD7F5B9.3010606@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gFjys31hhNz6opFj" Content-Disposition: inline In-Reply-To: <4CD7F5B9.3010606@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=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, 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-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: radeon_cp_texture: page fault with non-sleepable locks held 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, 08 Nov 2010 13:16:25 -0000 --gFjys31hhNz6opFj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 08, 2010 at 03:06:01PM +0200, Andriy Gapon wrote: > on 08/11/2010 14:04 Kostik Belousov said the following: > > On Mon, Nov 08, 2010 at 01:50:25PM +0200, Andriy Gapon wrote: > >> on 05/11/2010 09:27 Andriy Gapon said the following: > >>> Kernel page fault with the following non-sleepable locks held: > >>> exclusive sleep mutex drmdev (drmdev) r =3D 0 (0xffffff0001b968a0) lo= cked @ > >>> /usr/src/sys/dev/drm/drm_drv.c:791 > >>> KDB: stack backtrace: > >>> db_trace_self_wrapper() at 0xffffffff801b8afa =3D db_trace_self_wrapp= er+0x2a > >>> kdb_backtrace() at 0xffffffff803a7afa =3D kdb_backtrace+0x3a > >>> _witness_debugger() at 0xffffffff803bd49c =3D _witness_debugger+0x2c > >>> witness_warn() at 0xffffffff803bed32 =3D witness_warn+0x322 > >>> trap() at 0xffffffff8054639f =3D trap+0x39f >=20 > Kostik, >=20 > a tangential question - do you think that it would make sense to put a ch= eck > like the above (in trap) into copyin/copyout (but non-fatal), so that we = can > catch such situations pro-actively (without having to wait for a page fau= lt to > actually happen)? uiomove() already contains WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, "Calling uiomove()"); at the start. For the copyin/out routines, that are implemented in assembler for most (all ?) architectures, this seems to be overkill, IMHO. >=20 > >>> calltrap() at 0xffffffff80530688 =3D calltrap+0x8 > >>> --- trap 0xc, rip =3D 0xffffffff8054411d, rsp =3D 0xffffff81241917f0,= rbp =3D > >>> 0xffffff8124191870 --- > >>> copyin() at 0xffffffff8054411d =3D copyin+0x3d > >>> radeon_cp_texture() at 0xffffffff8022fcc7 =3D radeon_cp_texture+0x167 > >>> drm_ioctl() at 0xffffffff8020fa78 =3D drm_ioctl+0x318 > >>> devfs_ioctl_f() at 0xffffffff802dd739 =3D devfs_ioctl_f+0x109 > >>> kern_ioctl() at 0xffffffff803c1197 =3D kern_ioctl+0x1f7 > >>> ioctl() at 0xffffffff803c1358 =3D ioctl+0x168 > >>> syscallenter() at 0xffffffff803b584e =3D syscallenter+0x26e > >>> syscall() at 0xffffffff80545f12 =3D syscall+0x42 > >>> Xfast_syscall() at 0xffffffff80530962 =3D Xfast_syscall+0xe2 > >>> --- syscall (54, FreeBSD ELF64, ioctl), rip =3D 0x801f96a1c, rsp =3D = 0x7fffffffe7a8, > >>> rbp =3D 0xc020644e --- >=20 > --=20 > Andriy Gapon --gFjys31hhNz6opFj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzX+CMACgkQC3+MBN1Mb4gGuQCeIu9Yqqlvx7aQ8LtspawKM6nu jHQAn3o/nO+90GMVXjbjCVxVSi3XZ2QQ =Niyy -----END PGP SIGNATURE----- --gFjys31hhNz6opFj-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 14:28:57 2010 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 8F089106566B; Mon, 8 Nov 2010 14:28:57 +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 6FC0C8FC08; Mon, 8 Nov 2010 14:28:56 +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 QAA02513; Mon, 08 Nov 2010 16:28:54 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CD80926.2010507@freebsd.org> Date: Mon, 08 Nov 2010 16:28:54 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Nathan Whitehorn References: <4CD3B1D2.30003@icyb.net.ua> <4CD7E401.1010206@freebsd.org> <20101108120403.GC2392@deviant.kiev.zoral.com.ua> <4CD7F5B9.3010606@freebsd.org> <20101108131620.GG2392@deviant.kiev.zoral.com.ua> <4CD80792.7070402@freebsd.org> In-Reply-To: <4CD80792.7070402@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , freebsd-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: radeon_cp_texture: page fault with non-sleepable locks held 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, 08 Nov 2010 14:28:57 -0000 on 08/11/2010 16:22 Nathan Whitehorn said the following: > > The other issue is that this can be a legal thing to do. If you have taken care to > wire the userland buffers ahead of time, there is no problem copying > copyin()/copyout() with sleepable locks held. The sysctl code does this. As such, > you can't check for problems by panicing if sleepable locks are held. Nathan, very good point, thank you. BTW, perhaps drm should be doing the same? It seems that there are quite a few copyin/copyout calls (disguised with macros) in e.g. sys/dev/drm/radeon_state.c and likely all of them are under dev_lock. So it would be painful to add unlock+lock around each such call. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 14:44:17 2010 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 08D8C1065673; Mon, 8 Nov 2010 14:44:17 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id BC7F08FC12; Mon, 8 Nov 2010 14:44:16 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id E8F75582D5; Mon, 8 Nov 2010 08:22:11 -0600 (CST) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id jzHqV0Dsof-J; Mon, 8 Nov 2010 08:22:11 -0600 (CST) Received: from comporellon.tachypleus.net (unknown [76.210.66.181]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 7A70A582CD; Mon, 8 Nov 2010 08:22:11 -0600 (CST) Message-ID: <4CD80792.7070402@freebsd.org> Date: Mon, 08 Nov 2010 08:22:10 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.14) Gecko/20101021 Thunderbird/3.0.9 MIME-Version: 1.0 To: Kostik Belousov References: <4CD3B1D2.30003@icyb.net.ua> <4CD7E401.1010206@freebsd.org> <20101108120403.GC2392@deviant.kiev.zoral.com.ua> <4CD7F5B9.3010606@freebsd.org> <20101108131620.GG2392@deviant.kiev.zoral.com.ua> In-Reply-To: <20101108131620.GG2392@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-x11@freebsd.org, freebsd-current@freebsd.org, Andriy Gapon Subject: Re: radeon_cp_texture: page fault with non-sleepable locks held 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, 08 Nov 2010 14:44:17 -0000 On 11/08/10 07:16, Kostik Belousov wrote: > On Mon, Nov 08, 2010 at 03:06:01PM +0200, Andriy Gapon wrote: > >> on 08/11/2010 14:04 Kostik Belousov said the following: >> >>> On Mon, Nov 08, 2010 at 01:50:25PM +0200, Andriy Gapon wrote: >>> >>>> on 05/11/2010 09:27 Andriy Gapon said the following: >>>> >>>>> Kernel page fault with the following non-sleepable locks held: >>>>> exclusive sleep mutex drmdev (drmdev) r = 0 (0xffffff0001b968a0) locked @ >>>>> /usr/src/sys/dev/drm/drm_drv.c:791 >>>>> KDB: stack backtrace: >>>>> db_trace_self_wrapper() at 0xffffffff801b8afa = db_trace_self_wrapper+0x2a >>>>> kdb_backtrace() at 0xffffffff803a7afa = kdb_backtrace+0x3a >>>>> _witness_debugger() at 0xffffffff803bd49c = _witness_debugger+0x2c >>>>> witness_warn() at 0xffffffff803bed32 = witness_warn+0x322 >>>>> trap() at 0xffffffff8054639f = trap+0x39f >>>>> >> Kostik, >> >> a tangential question - do you think that it would make sense to put a check >> like the above (in trap) into copyin/copyout (but non-fatal), so that we can >> catch such situations pro-actively (without having to wait for a page fault to >> actually happen)? >> > uiomove() already contains > WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, > "Calling uiomove()"); > at the start. > > For the copyin/out routines, that are implemented in assembler for > most (all ?) architectures, this seems to be overkill, IMHO. > The other issue is that this can be a legal thing to do. If you have taken care to wire the userland buffers ahead of time, there is no problem copying copyin()/copyout() with sleepable locks held. The sysctl code does this. As such, you can't check for problems by panicing if sleepable locks are held. -Nathan From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 14:50:52 2010 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 E67F0106564A; Mon, 8 Nov 2010 14:50:52 +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 556F68FC13; Mon, 8 Nov 2010 14:50:51 +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 oA8Eolip098975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Nov 2010 16:50:47 +0200 (EET) (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 oA8EoldF012578; Mon, 8 Nov 2010 16:50:47 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oA8EolaL012577; Mon, 8 Nov 2010 16:50:47 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 8 Nov 2010 16:50:47 +0200 From: Kostik Belousov To: Andriy Gapon Message-ID: <20101108145047.GH2392@deviant.kiev.zoral.com.ua> References: <4CD3B1D2.30003@icyb.net.ua> <4CD7E401.1010206@freebsd.org> <20101108120403.GC2392@deviant.kiev.zoral.com.ua> <4CD7F5B9.3010606@freebsd.org> <20101108131620.GG2392@deviant.kiev.zoral.com.ua> <4CD80792.7070402@freebsd.org> <4CD80926.2010507@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kljy8TnFHfNvTRLN" Content-Disposition: inline In-Reply-To: <4CD80926.2010507@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=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, 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-x11@freebsd.org, freebsd-current@freebsd.org, Nathan Whitehorn Subject: Re: radeon_cp_texture: page fault with non-sleepable locks held 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, 08 Nov 2010 14:50:53 -0000 --kljy8TnFHfNvTRLN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 08, 2010 at 04:28:54PM +0200, Andriy Gapon wrote: > on 08/11/2010 16:22 Nathan Whitehorn said the following: > >=20 > > The other issue is that this can be a legal thing to do. If you have ta= ken care to > > wire the userland buffers ahead of time, there is no problem copying > > copyin()/copyout() with sleepable locks held. The sysctl code does this= . As such, > > you can't check for problems by panicing if sleepable locks are held. >=20 > Nathan, >=20 > very good point, thank you. > BTW, perhaps drm should be doing the same? > It seems that there are quite a few copyin/copyout calls (disguised with = macros) > in e.g. sys/dev/drm/radeon_state.c and likely all of them are under dev_l= ock. > So it would be painful to add unlock+lock around each such call. This would be a DoS, due to the size of the buffers. --kljy8TnFHfNvTRLN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzYDkcACgkQC3+MBN1Mb4jijwCePL+w9ipmTaC51MMQR6tgqxcf /3gAoJsHeLT6J3sdrt5+1Z65UOFjWiiI =v3UB -----END PGP SIGNATURE----- --kljy8TnFHfNvTRLN-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 15:05:05 2010 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 D93851065697; Mon, 8 Nov 2010 15:05:05 +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 A67D68FC1D; Mon, 8 Nov 2010 15:05:05 +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 590B446B06; Mon, 8 Nov 2010 10:05:05 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 85A328A029; Mon, 8 Nov 2010 10:05:04 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 8 Nov 2010 09:42:41 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4CD7C8FC.900@icyb.net.ua> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201011080942.41546.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 08 Nov 2010 10:05:04 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-fs@freebsd.org, Ivan Voras Subject: Re: another fuse 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, 08 Nov 2010 15:05:06 -0000 On Monday, November 08, 2010 6:35:55 am Ivan Voras wrote: > On 11/08/10 10:55, Andriy Gapon wrote: > > > > JFYI. > > Fatal trap 12: page fault while in kernel mode > > Can you find any set of circumstances which make this repeatable? > > This panic apparently goes like this: > > 1) used by devfs_open(): > 47 static struct cdevsw fuse_cdevsw = { > 48 .d_open = fusedev_open, > > 2) in fusedev_open(): > 119 fdata = fdata_alloc(dev, td->td_ucred); > > 3) in fdata_alloc(): > 297 data->daemoncred = crhold(cred); > > in other words, td->td_ucred from td passed to fusedev_open (presumably > when the device is opened from the userland) appears to be NULL. > > I don't know if there is any normal set of circumstances under which > this is expected. No, td_ucred should never be NULL. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 15:05:08 2010 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 0791510656B8; Mon, 8 Nov 2010 15:05:07 +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 B8C628FC20; Mon, 8 Nov 2010 15:05:07 +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 5C93546B3B; Mon, 8 Nov 2010 10:05:07 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 41E2A8A009; Mon, 8 Nov 2010 10:05:06 -0500 (EST) From: John Baldwin To: Matthew Fleming Date: Mon, 8 Nov 2010 09:47:00 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011061522.26533.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011080947.00550.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 08 Nov 2010 10:05:06 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-usb@freebsd.org, Weongyo Jeong , freebsd-current@freebsd.org, freebsd-arch@freebsd.org, Hans Petter Selasky Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system 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, 08 Nov 2010 15:05:08 -0000 On Saturday, November 06, 2010 4:33:17 pm Matthew Fleming wrote: > On Sat, Nov 6, 2010 at 7:22 AM, Hans Petter Selasky wrote: > > Hi, > > > > On Saturday 06 November 2010 14:57:50 Matthew Fleming wrote: > >> > >> I think you're misunderstanding the existing taskqueue(9) implementation. > >> > >> As long as TQ_LOCK is held, the state of ta->ta_pending cannot change, > >> nor can the set of running tasks. So the order of checks is > >> irrelevant. > > > > I agree that the order of checks is not important. That is not the problem. > > > > Cut & paste from suggested taskqueue patch from Fleming: > > > > > +int > >> > +taskqueue_cancel(struct taskqueue *queue, struct task *task) > >> > +{ > >> > + int rc; > >> > + > >> > + TQ_LOCK(queue); > >> > + if (!task_is_running(queue, task)) { > >> > + if ((rc = task->ta_pending) > 0) > >> > + STAILQ_REMOVE(&queue->tq_queue, task, task, > >> > ta_link); + task->ta_pending = 0; > >> > + } else { > >> > + rc = -EBUSY; > > > > What happens in this case if ta_pending > 0. Are you saying this is not > > possible? If ta_pending > 0, shouldn't we also do a STAILQ_REMOVE() ? > > Ah! I see what you mean. > > I'm not quite sure what the best thing to do here is; I agree it would > be nice if taskqueue_cancel(9) dequeued the task, but I believe it > also needs to indicate that the task is currently running. I guess > the best thing would be to return the old pending count by reference > parameter, and 0 or EBUSY to also indicate if there is a task > currently running. > > Adding jhb@ to this mail since he has good thoughts on interfacing. I agree we should always dequeue when possible. I think it should return -EBUSY in that case. That way code that uses 'cancel' followed by a conditional 'drain' to implement a blocking 'cancel' will DTRT. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 15:34:35 2010 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 E85741065670; Mon, 8 Nov 2010 15:34:34 +0000 (UTC) (envelope-from mdf356@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 7467B8FC18; Mon, 8 Nov 2010 15:34:34 +0000 (UTC) Received: by iwn39 with SMTP id 39so6226556iwn.13 for ; Mon, 08 Nov 2010 07:34:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Q3Yh+Akq1iSym1e61foxgBYYRwPfKywY/6SkwmPImWI=; b=ITcUReiQ1Qq6+npAlu+MYy/C+tV+7hfn9dJFlXSRAgcVYAL6htMDDzjvdP9FBOyCJ3 xqHXQmmg3dZTLffKV2XfMU4aS7YJ0rveLpzy1waUIieiU81hiIUcDvvaoep+vLqDqmsm bSKPQAB0xnd504G9JKn3MLrWA7alfB9GXieq0= 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=jz8/c6Ax+rXemiy3JRzfAya/R4KsAa/5OBWvkkJi0BUWqPqB+qkt78OocoYx//nSja TsKH6qhsaLl/2Pn6fGTLavzGBkQgub1do2HzdV5WikYJGCr8Gn7fEC1yAFZNvJU0E1dP 74SnrgWFZpxa8AfXuMvNqW4Fzf8Rnx12vmt70= MIME-Version: 1.0 Received: by 10.231.156.139 with SMTP id x11mr4170511ibw.22.1289230473154; Mon, 08 Nov 2010 07:34:33 -0800 (PST) Received: by 10.231.21.35 with HTTP; Mon, 8 Nov 2010 07:34:33 -0800 (PST) In-Reply-To: <201011080947.00550.jhb@freebsd.org> References: <201011012054.59551.hselasky@c2i.net> <201011061522.26533.hselasky@c2i.net> <201011080947.00550.jhb@freebsd.org> Date: Mon, 8 Nov 2010 07:34:33 -0800 Message-ID: From: Matthew Fleming To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-usb@freebsd.org, Weongyo Jeong , freebsd-current@freebsd.org, freebsd-arch@freebsd.org, Hans Petter Selasky Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system 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, 08 Nov 2010 15:34:35 -0000 On Mon, Nov 8, 2010 at 6:47 AM, John Baldwin wrote: > On Saturday, November 06, 2010 4:33:17 pm Matthew Fleming wrote: >> On Sat, Nov 6, 2010 at 7:22 AM, Hans Petter Selasky w= rote: >> > Hi, >> > >> > On Saturday 06 November 2010 14:57:50 Matthew Fleming wrote: >> >> >> >> I think you're misunderstanding the existing taskqueue(9) implementat= ion. >> >> >> >> As long as TQ_LOCK is held, the state of ta->ta_pending cannot change= , >> >> nor can the set of running tasks. =A0So the order of checks is >> >> irrelevant. >> > >> > I agree that the order of checks is not important. That is not the pro= blem. >> > >> > Cut & paste from suggested taskqueue patch from Fleming: >> > >> > =A0> +int >> >> > +taskqueue_cancel(struct taskqueue *queue, struct task *task) >> >> > +{ >> >> > + =A0 =A0 =A0 int rc; >> >> > + >> >> > + =A0 =A0 =A0 TQ_LOCK(queue); >> >> > + =A0 =A0 =A0 if (!task_is_running(queue, task)) { >> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((rc =3D task->ta_pending) > 0) >> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_REMOVE(&queue-= >tq_queue, task, task, >> >> > ta_link); + =A0 =A0 =A0 =A0 =A0 =A0 =A0 task->ta_pending =3D 0; >> >> > + =A0 =A0 =A0 } else { >> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 rc =3D -EBUSY; >> > >> > What happens in this case if ta_pending > 0. Are you saying this is no= t >> > possible? If ta_pending > 0, shouldn't we also do a STAILQ_REMOVE() ? >> >> Ah! =A0I see what you mean. >> >> I'm not quite sure what the best thing to do here is; I agree it would >> be nice if taskqueue_cancel(9) dequeued the task, but I believe it >> also needs to indicate that the task is currently running. =A0I guess >> the best thing would be to return the old pending count by reference >> parameter, and 0 or EBUSY to also indicate if there is a task >> currently running. >> >> Adding jhb@ to this mail since he has good thoughts on interfacing. > > I agree we should always dequeue when possible. =A0I think it should retu= rn > -EBUSY in that case. =A0That way code that uses 'cancel' followed by a > conditional 'drain' to implement a blocking 'cancel' will DTRT. Do we not also want the old ta_pending to be returned? In the case where a task is pending and is also currently running (admittedly a narrow window), how would we do this? This is why I suggested returning the old ta_pending by reference. This also allows callers who don't care about the old pending to pass NULL and ignore it. Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 16:44:11 2010 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 DFFAB106564A; Mon, 8 Nov 2010 16:44:10 +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 9BB2D8FC0C; Mon, 8 Nov 2010 16:44:10 +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 1250E46B35; Mon, 8 Nov 2010 11:44:10 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0F2B58A009; Mon, 8 Nov 2010 11:44:09 -0500 (EST) From: John Baldwin To: Matthew Fleming Date: Mon, 8 Nov 2010 11:42:45 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011080947.00550.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011081142.46175.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 08 Nov 2010 11:44:09 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-usb@freebsd.org, Weongyo Jeong , freebsd-current@freebsd.org, freebsd-arch@freebsd.org, Hans Petter Selasky Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system 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, 08 Nov 2010 16:44:11 -0000 On Monday, November 08, 2010 10:34:33 am Matthew Fleming wrote: > On Mon, Nov 8, 2010 at 6:47 AM, John Baldwin wrote: > > On Saturday, November 06, 2010 4:33:17 pm Matthew Fleming wrote: > >> On Sat, Nov 6, 2010 at 7:22 AM, Hans Petter Selasky wrote: > >> > Hi, > >> > > >> > On Saturday 06 November 2010 14:57:50 Matthew Fleming wrote: > >> >> > >> >> I think you're misunderstanding the existing taskqueue(9) implementation. > >> >> > >> >> As long as TQ_LOCK is held, the state of ta->ta_pending cannot change, > >> >> nor can the set of running tasks. So the order of checks is > >> >> irrelevant. > >> > > >> > I agree that the order of checks is not important. That is not the problem. > >> > > >> > Cut & paste from suggested taskqueue patch from Fleming: > >> > > >> > > +int > >> >> > +taskqueue_cancel(struct taskqueue *queue, struct task *task) > >> >> > +{ > >> >> > + int rc; > >> >> > + > >> >> > + TQ_LOCK(queue); > >> >> > + if (!task_is_running(queue, task)) { > >> >> > + if ((rc = task->ta_pending) > 0) > >> >> > + STAILQ_REMOVE(&queue->tq_queue, task, task, > >> >> > ta_link); + task->ta_pending = 0; > >> >> > + } else { > >> >> > + rc = -EBUSY; > >> > > >> > What happens in this case if ta_pending > 0. Are you saying this is not > >> > possible? If ta_pending > 0, shouldn't we also do a STAILQ_REMOVE() ? > >> > >> Ah! I see what you mean. > >> > >> I'm not quite sure what the best thing to do here is; I agree it would > >> be nice if taskqueue_cancel(9) dequeued the task, but I believe it > >> also needs to indicate that the task is currently running. I guess > >> the best thing would be to return the old pending count by reference > >> parameter, and 0 or EBUSY to also indicate if there is a task > >> currently running. > >> > >> Adding jhb@ to this mail since he has good thoughts on interfacing. > > > > I agree we should always dequeue when possible. I think it should return > > -EBUSY in that case. That way code that uses 'cancel' followed by a > > conditional 'drain' to implement a blocking 'cancel' will DTRT. > > Do we not also want the old ta_pending to be returned? In the case > where a task is pending and is also currently running (admittedly a > narrow window), how would we do this? This is why I suggested > returning the old ta_pending by reference. This also allows callers > who don't care about the old pending to pass NULL and ignore it. I would be fine with that then. I wonder if taskqueue_cancel() could then return a simple true/false. False if the task is running, and true otherwise? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 16:30:04 2010 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 BD10810656A3 for ; Mon, 8 Nov 2010 16:30:04 +0000 (UTC) (envelope-from joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com) Received: from relay01-haj2.antispameurope.com (relay01-haj2.antispameurope.com [83.246.65.51]) by mx1.freebsd.org (Postfix) with ESMTP id 3C2288FC22 for ; Mon, 8 Nov 2010 16:30:03 +0000 (UTC) Received: by relay01-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 70FAC94091; Mon, 8 Nov 2010 17:19:11 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 8C831160053; Mon, 8 Nov 2010 17:19:09 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id oA8GJ3Yp026804; Mon, 8 Nov 2010 17:19:08 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Nov 2010 17:18:42 +0100 Date: Mon, 08 Nov 2010 17:18:39 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: mav@freebsd.org, marius@alchemy.franken.de Message-ID: <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> In-Reply-To: <20101105192028.GA68728@alchemy.franken.de> User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 08 Nov 2010 16:18:42.0976 (UTC) FILETIME=[9C854A00:01CB7F60] X-Mailman-Approved-At: Mon, 08 Nov 2010 16:46:11 +0000 Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Sense fetching [Was: cdrtools /devel ...] 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, 08 Nov 2010 16:30:04 -0000 Marius Strobl wrote: > On Fri, Nov 05, 2010 at 08:50:49PM +0200, Alexander Motin wrote: > > Hi. > > > > I've reviewed tests that scgcheck does to SCSI subsystem. It shown > > combination of several issues in both CAM, ahci(4) and cdrtools itself. > > Several small patches allow us to pass most of that tests: > > http://people.freebsd.org/~mav/sense/ > > > > ahci_resid.patch: Add support for reporting residual length on data > > underrun. SCSI commands often returns results shorter then expected. > > Returned value allows application to know/check how much data it really > > has. It is also important for sense fetching, as ATAPI and USB devices > > return sense as data in response to REQUEST_SENSE command. > > > > sense_resid.patch: When manually requesting sense data (ATAPI or USB), > > request only as much data as user requested (not the fixed structure > > size), and return respective sense residual length. Your patch to libscg looks definitely OK if we only look at the new corrected kernel driver behavior. There is a problem: In case that there is a sense data residual > 0, libscg will asume that there is less sense data that really present in case that a "new" libscg is runnung on an old kernel. Given the fact that many drives will probably only return 18 bytes of sense data, this will happen every time libscg is told to fetch more sense than the drive is willing to return. Is there a way to distinct an old kernel from a new one? > > pass_autosence.patch: Unless CAM_DIS_AUTOSENSE is set, always fetch > > sense if not done by SIM, independently of CAM_PASS_ERR_RECOVER. As soon > > as device freeze released before returning to user-level, user-level > > application by definition can't reliably fetch sense data if some other > > application (like hald) tries to access device same time. This is what we need! > > cdrtools.patch: Make libscg (part of cdrtools) on FreeBSD to submit > > wanted sense length to CAM and do not clear sense return buffer. It is > > mostly cosmetics, important probably only for scgcheck. I see no advantage in removing the call to fillbytes(). > Please don't commit this to the port directly but let it loop back > via upstream (CC'ed) instead, otherwise we would need to obey the > following, which is undesirable, especially if these really are > mostly cosmetic issues: > /* > * Warning: you may change this source, but if you do that > * you need to change the _scg_version and _scg_auth* string below. > * You may not return "schily" for an SCG_AUTHOR request anymore. > * Choose your name instead of "schily" and make clear that the version > * string is related to a modified source. > */ > > > > > Testers and reviewers welcome. I am especially interested in opinion > > about pass_autosence.patch -- may be we should lower sense fetching even > > deeper, to make it work for all cam_periph_runccb() consumers. Did you test a modified libscg on an unmodified kernel? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 16:47:00 2010 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 F257B1065679; Mon, 8 Nov 2010 16:46:59 +0000 (UTC) (envelope-from mdf356@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 7E09E8FC14; Mon, 8 Nov 2010 16:46:59 +0000 (UTC) Received: by iwn39 with SMTP id 39so6296735iwn.13 for ; Mon, 08 Nov 2010 08:46:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bJjeFYGl3fy966B8YB3YJqHzPhP3c+Lix7MzG1/+ZQE=; b=Q4ITzcxHFehpXE+t+L3Lrpu9hqpxX/QIO5DlGo5llXPWNUHtaQUv5Pqtp5s3DE9SKL vP+Mbr65IcOTsMJfFTzn2pBzXwvQM3CraXfenp4idurSIhxDYcNXx4qdrvFixvZuti0x TaCvMMKPd2xNYSVom4M3k7y8Jp9KCq6YKHVbk= 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=PsxCwpO9RlRHD4yuEXIVTVVCxXH1hig2ucu667KKJbuujS9K4jhltW4i4xLM7lx91H 7Y+N71MIHJQdAhtqiwQpZ7ohASnvPHhSD3CZ2Mxt2IJx9CEdhq8FHTOq4c3TmaRBmnLn HJxaRqiz4ggpL9v0k5+imkOl5RRjkWM2P3ywc= MIME-Version: 1.0 Received: by 10.231.192.73 with SMTP id dp9mr4239441ibb.72.1289234818843; Mon, 08 Nov 2010 08:46:58 -0800 (PST) Received: by 10.231.21.35 with HTTP; Mon, 8 Nov 2010 08:46:58 -0800 (PST) In-Reply-To: <201011081142.46175.jhb@freebsd.org> References: <201011012054.59551.hselasky@c2i.net> <201011080947.00550.jhb@freebsd.org> <201011081142.46175.jhb@freebsd.org> Date: Mon, 8 Nov 2010 08:46:58 -0800 Message-ID: From: Matthew Fleming To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-usb@freebsd.org, Weongyo Jeong , freebsd-current@freebsd.org, freebsd-arch@freebsd.org, Hans Petter Selasky Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system 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, 08 Nov 2010 16:47:00 -0000 On Mon, Nov 8, 2010 at 8:42 AM, John Baldwin wrote: > On Monday, November 08, 2010 10:34:33 am Matthew Fleming wrote: >> On Mon, Nov 8, 2010 at 6:47 AM, John Baldwin wrote: >> > On Saturday, November 06, 2010 4:33:17 pm Matthew Fleming wrote: >> >> On Sat, Nov 6, 2010 at 7:22 AM, Hans Petter Selasky wrote: >> >> > Hi, >> >> > >> >> > On Saturday 06 November 2010 14:57:50 Matthew Fleming wrote: >> >> >> >> >> >> I think you're misunderstanding the existing taskqueue(9) implemen= tation. >> >> >> >> >> >> As long as TQ_LOCK is held, the state of ta->ta_pending cannot cha= nge, >> >> >> nor can the set of running tasks. =A0So the order of checks is >> >> >> irrelevant. >> >> > >> >> > I agree that the order of checks is not important. That is not the = problem. >> >> > >> >> > Cut & paste from suggested taskqueue patch from Fleming: >> >> > >> >> > =A0> +int >> >> >> > +taskqueue_cancel(struct taskqueue *queue, struct task *task) >> >> >> > +{ >> >> >> > + =A0 =A0 =A0 int rc; >> >> >> > + >> >> >> > + =A0 =A0 =A0 TQ_LOCK(queue); >> >> >> > + =A0 =A0 =A0 if (!task_is_running(queue, task)) { >> >> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((rc =3D task->ta_pending) > 0) >> >> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_REMOVE(&que= ue->tq_queue, task, task, >> >> >> > ta_link); + =A0 =A0 =A0 =A0 =A0 =A0 =A0 task->ta_pending =3D 0; >> >> >> > + =A0 =A0 =A0 } else { >> >> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 rc =3D -EBUSY; >> >> > >> >> > What happens in this case if ta_pending > 0. Are you saying this is= not >> >> > possible? If ta_pending > 0, shouldn't we also do a STAILQ_REMOVE()= ? >> >> >> >> Ah! =A0I see what you mean. >> >> >> >> I'm not quite sure what the best thing to do here is; I agree it woul= d >> >> be nice if taskqueue_cancel(9) dequeued the task, but I believe it >> >> also needs to indicate that the task is currently running. =A0I guess >> >> the best thing would be to return the old pending count by reference >> >> parameter, and 0 or EBUSY to also indicate if there is a task >> >> currently running. >> >> >> >> Adding jhb@ to this mail since he has good thoughts on interfacing. >> > >> > I agree we should always dequeue when possible. =A0I think it should r= eturn >> > -EBUSY in that case. =A0That way code that uses 'cancel' followed by a >> > conditional 'drain' to implement a blocking 'cancel' will DTRT. >> >> Do we not also want the old ta_pending to be returned? =A0In the case >> where a task is pending and is also currently running (admittedly a >> narrow window), how would we do this? =A0This is why I suggested >> returning the old ta_pending by reference. =A0This also allows callers >> who don't care about the old pending to pass NULL and ignore it. > > I would be fine with that then. =A0I wonder if taskqueue_cancel() could t= hen > return a simple true/false. =A0False if the task is running, and true > otherwise? Sure, though since we don't really have a bool type in the kernel I'd still prefer to return an int with EBUSY meaning a task was running. Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 17:04:57 2010 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 DB2A1106564A; Mon, 8 Nov 2010 17:04:57 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8D7E58FC1D; Mon, 8 Nov 2010 17:04:57 +0000 (UTC) Received: by pxi1 with SMTP id 1so1067896pxi.13 for ; Mon, 08 Nov 2010 09:04:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IMsU0iLLKZy4M0mTial+VDi0L/cNT9Zi3iPWW1QsgJc=; b=mr1oWxGvvUW4yJDDLgR1FTgfiNfmsZZO5/JshKAkYGPblZxo9Zh9pXHkbl6sO5PVQs W0X1RjaDdHGz1RU43pKvaoK+Ym+TRLUXRcc2Dv7L+sKC275FLOAj/zfHoDvbXuhYpsOY oFiNTLGs3AitH1hnF1Yk2MqyOYSQDsrB7Y+RU= 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=g4PxTTL5VgTQMgwcSJvjADKX5bDc51bPhxWMGxrUx1Gh4dOQFiBRF/vxURoaKE+SWa cCewxnWVoopAgRLU9tK143nQSPCGGnnxDMM4Dpk9d8u9cHlQBkokJXcOkgScFPbKd3cx GLaIJHlxl1ASC8uhDKuR2wuKjvIJ8yTkpaXKo= MIME-Version: 1.0 Received: by 10.42.165.200 with SMTP id l8mr2253305icy.326.1289235894985; Mon, 08 Nov 2010 09:04:54 -0800 (PST) Received: by 10.231.21.35 with HTTP; Mon, 8 Nov 2010 09:04:54 -0800 (PST) In-Reply-To: References: <201011012054.59551.hselasky@c2i.net> <201011080947.00550.jhb@freebsd.org> <201011081142.46175.jhb@freebsd.org> Date: Mon, 8 Nov 2010 09:04:54 -0800 Message-ID: From: Matthew Fleming To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-usb@freebsd.org, Weongyo Jeong , freebsd-current@freebsd.org, freebsd-arch@freebsd.org, Hans Petter Selasky Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system 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, 08 Nov 2010 17:04:58 -0000 On Mon, Nov 8, 2010 at 8:46 AM, Matthew Fleming wrote: > On Mon, Nov 8, 2010 at 8:42 AM, John Baldwin wrote: >> On Monday, November 08, 2010 10:34:33 am Matthew Fleming wrote: >>> On Mon, Nov 8, 2010 at 6:47 AM, John Baldwin wrote: >>> > On Saturday, November 06, 2010 4:33:17 pm Matthew Fleming wrote: >>> >> On Sat, Nov 6, 2010 at 7:22 AM, Hans Petter Selasky wrote: >>> >> > Hi, >>> >> > >>> >> > On Saturday 06 November 2010 14:57:50 Matthew Fleming wrote: >>> >> >> >>> >> >> I think you're misunderstanding the existing taskqueue(9) impleme= ntation. >>> >> >> >>> >> >> As long as TQ_LOCK is held, the state of ta->ta_pending cannot ch= ange, >>> >> >> nor can the set of running tasks. =A0So the order of checks is >>> >> >> irrelevant. >>> >> > >>> >> > I agree that the order of checks is not important. That is not the= problem. >>> >> > >>> >> > Cut & paste from suggested taskqueue patch from Fleming: >>> >> > >>> >> > =A0> +int >>> >> >> > +taskqueue_cancel(struct taskqueue *queue, struct task *task) >>> >> >> > +{ >>> >> >> > + =A0 =A0 =A0 int rc; >>> >> >> > + >>> >> >> > + =A0 =A0 =A0 TQ_LOCK(queue); >>> >> >> > + =A0 =A0 =A0 if (!task_is_running(queue, task)) { >>> >> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((rc =3D task->ta_pending) > 0= ) >>> >> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_REMOVE(&qu= eue->tq_queue, task, task, >>> >> >> > ta_link); + =A0 =A0 =A0 =A0 =A0 =A0 =A0 task->ta_pending =3D 0; >>> >> >> > + =A0 =A0 =A0 } else { >>> >> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 rc =3D -EBUSY; >>> >> > >>> >> > What happens in this case if ta_pending > 0. Are you saying this i= s not >>> >> > possible? If ta_pending > 0, shouldn't we also do a STAILQ_REMOVE(= ) ? >>> >> >>> >> Ah! =A0I see what you mean. >>> >> >>> >> I'm not quite sure what the best thing to do here is; I agree it wou= ld >>> >> be nice if taskqueue_cancel(9) dequeued the task, but I believe it >>> >> also needs to indicate that the task is currently running. =A0I gues= s >>> >> the best thing would be to return the old pending count by reference >>> >> parameter, and 0 or EBUSY to also indicate if there is a task >>> >> currently running. >>> >> >>> >> Adding jhb@ to this mail since he has good thoughts on interfacing. >>> > >>> > I agree we should always dequeue when possible. =A0I think it should = return >>> > -EBUSY in that case. =A0That way code that uses 'cancel' followed by = a >>> > conditional 'drain' to implement a blocking 'cancel' will DTRT. >>> >>> Do we not also want the old ta_pending to be returned? =A0In the case >>> where a task is pending and is also currently running (admittedly a >>> narrow window), how would we do this? =A0This is why I suggested >>> returning the old ta_pending by reference. =A0This also allows callers >>> who don't care about the old pending to pass NULL and ignore it. >> >> I would be fine with that then. =A0I wonder if taskqueue_cancel() could = then >> return a simple true/false. =A0False if the task is running, and true >> otherwise? > > Sure, though since we don't really have a bool type in the kernel I'd > still prefer to return an int with EBUSY meaning a task was running. I'll commit this later today unless there are objections. http://people.freebsd.org/~mdf/0001-Add-a-taskqueue_cancel-9-to-cancel-a-pe= nding-task-wi.patch Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 17:07:12 2010 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 B4601106566C; Mon, 8 Nov 2010 17:07:12 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3E1878FC17; Mon, 8 Nov 2010 17:07:11 +0000 (UTC) Received: by gya6 with SMTP id 6so3656542gya.13 for ; Mon, 08 Nov 2010 09:07:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received: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=mKLa3Rhl/UcBVIRyAaMGm5Q/nCbrZQiygnc0ugu78rw=; b=A3XV+P5mrQmXOKz9L7KZfb7bYXFwW//qua9paFfJh1RJ6uig2tmHkl2Zv2mTfmFgiP t/n/dfyIJ2FVIYlvUDIebhzg5SVI4kzY5ieHUOp/GTuo+rxcPRYOCZjx8hXr42wIaVLl YcNr9r+uQkRRsud/nAT0eZbADQ57nno8EXYrQ= 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=aet/aXVnQY3M3DJkssNRvfM2Xjne+7wCV/FN6RXf1dQFrB/XhLCSUFk7jI2sEDQ27y zM4d2HkmByjxQ0nEq2FktO+YOZcqOj0Uwkq0SLryFbbdcam2tCETyvxwWGV2NoA/redd M6AHDjyYel3npX1w0VzzcG6WcM+qiLWfOjG/Q= Received: by 10.204.83.215 with SMTP id g23mr4999124bkl.211.1289236030919; Mon, 08 Nov 2010 09:07:10 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id p34sm103871bkf.3.2010.11.08.09.07.07 (version=SSLv3 cipher=RC4-MD5); Mon, 08 Nov 2010 09:07:08 -0800 (PST) Sender: Alexander Motin Message-ID: <4CD82E2A.3070407@FreeBSD.org> Date: Mon, 08 Nov 2010 19:06:50 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Joerg Schilling References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> In-Reply-To: <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> 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, freebsd-stable@freebsd.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] 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, 08 Nov 2010 17:07:12 -0000 Joerg Schilling wrote: > Marius Strobl wrote: >> On Fri, Nov 05, 2010 at 08:50:49PM +0200, Alexander Motin wrote: >>> I've reviewed tests that scgcheck does to SCSI subsystem. It shown >>> combination of several issues in both CAM, ahci(4) and cdrtools itself. >>> Several small patches allow us to pass most of that tests: >>> http://people.freebsd.org/~mav/sense/ >>> >>> ahci_resid.patch: Add support for reporting residual length on data >>> underrun. SCSI commands often returns results shorter then expected. >>> Returned value allows application to know/check how much data it really >>> has. It is also important for sense fetching, as ATAPI and USB devices >>> return sense as data in response to REQUEST_SENSE command. >>> >>> sense_resid.patch: When manually requesting sense data (ATAPI or USB), >>> request only as much data as user requested (not the fixed structure >>> size), and return respective sense residual length. > > Your patch to libscg looks definitely OK if we only look at the new corrected > kernel driver behavior. > > There is a problem: > > In case that there is a sense data residual > 0, libscg will asume that there > is less sense data that really present in case that a "new" libscg is runnung > on an old kernel. > > Given the fact that many drives will probably only return 18 bytes of sense > data, this will happen every time libscg is told to fetch more sense than the > drive is willing to return. > > Is there a way to distinct an old kernel from a new one? I don't see the problem. Previous kernel in most cases reported sesnse_resid == 0, lying that there is more sense data then really is. New one should report real (often positive) value. In both cases sesnse_resid value measured from the value submitted to the kernel. >>> pass_autosence.patch: Unless CAM_DIS_AUTOSENSE is set, always fetch >>> sense if not done by SIM, independently of CAM_PASS_ERR_RECOVER. As soon >>> as device freeze released before returning to user-level, user-level >>> application by definition can't reliably fetch sense data if some other >>> application (like hald) tries to access device same time. > > This is what we need! Agree. >>> cdrtools.patch: Make libscg (part of cdrtools) on FreeBSD to submit >>> wanted sense length to CAM and do not clear sense return buffer. It is >>> mostly cosmetics, important probably only for scgcheck. > > I see no advantage in removing the call to fillbytes(). scgcheck tests how much sense data received by counting 0x00 and 0xff bytes. Zero-filling response buffer breaks that check. Though I have no idea if other crdtools' applications depend on these zeros. There could be some internal inconsistency. >> Please don't commit this to the port directly but let it loop back >> via upstream (CC'ed) instead, otherwise we would need to obey the >> following, which is undesirable, especially if these really are >> mostly cosmetic issues: >> /* >> * Warning: you may change this source, but if you do that >> * you need to change the _scg_version and _scg_auth* string below. >> * You may not return "schily" for an SCG_AUTHOR request anymore. >> * Choose your name instead of "schily" and make clear that the version >> * string is related to a modified source. >> */ >> >>> Testers and reviewers welcome. I am especially interested in opinion >>> about pass_autosence.patch -- may be we should lower sense fetching even >>> deeper, to make it work for all cam_periph_runccb() consumers. > > Did you test a modified libscg on an unmodified kernel? Unmodified kernel by default doesn't return any sense data at all for new CAM-based ATA -- this changes should be invariant. New scgcheck runs same bad as old. It just can't become worse. :) Legacy atapicam wrapper ignores sense_len on input and doesn't fill sense_resig on output -- I haven't tested, but it also should be invariant. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 17:23:31 2010 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 508421065673 for ; Mon, 8 Nov 2010 17:23:31 +0000 (UTC) (envelope-from joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com) Received: from relay01-haj2.antispameurope.com (relay01-haj2.antispameurope.com [83.246.65.51]) by mx1.freebsd.org (Postfix) with ESMTP id D1C0D8FC19 for ; Mon, 8 Nov 2010 17:23:30 +0000 (UTC) Received: by relay01-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 0BF7716008A; Mon, 8 Nov 2010 18:23:28 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 7C4EB160082; Mon, 8 Nov 2010 18:23:26 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id oA8HNQ3s028569; Mon, 8 Nov 2010 18:23:26 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Nov 2010 18:23:26 +0100 Date: Mon, 08 Nov 2010 18:23:22 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: mav@FreeBSD.org Message-ID: <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> <4CD82E2A.3070407@FreeBSD.org> In-Reply-To: <4CD82E2A.3070407@FreeBSD.org> User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 08 Nov 2010 17:23:26.0747 (UTC) FILETIME=[A76DB6B0:01CB7F69] X-Mailman-Approved-At: Mon, 08 Nov 2010 17:30:13 +0000 Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] 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, 08 Nov 2010 17:23:31 -0000 Alexander Motin wrote: > > Your patch to libscg looks definitely OK if we only look at the new corrected > > kernel driver behavior. > > > > There is a problem: > > > > In case that there is a sense data residual > 0, libscg will asume that there > > is less sense data that really present in case that a "new" libscg is runnung > > on an old kernel. > > > > Given the fact that many drives will probably only return 18 bytes of sense > > data, this will happen every time libscg is told to fetch more sense than the > > drive is willing to return. > > > > Is there a way to distinct an old kernel from a new one? > > I don't see the problem. Previous kernel in most cases reported > sesnse_resid == 0, lying that there is more sense data then really is. > New one should report real (often positive) value. In both cases > sesnse_resid value measured from the value submitted to the kernel. Did the old kernel return a zero sense_resid for any implemented SCSI transport? Libscg is a generic SCSI transport library and cdrecord is just one user of this lib. > > I see no advantage in removing the call to fillbytes(). > > scgcheck tests how much sense data received by counting 0x00 and 0xff > bytes. Zero-filling response buffer breaks that check. Though I have no > idea if other crdtools' applications depend on these zeros. There could > be some internal inconsistency. O, I need to check other low level transport adaptation layers and think about this statement. > > Did you test a modified libscg on an unmodified kernel? > > Unmodified kernel by default doesn't return any sense data at all for > new CAM-based ATA -- this changes should be invariant. New scgcheck runs > same bad as old. It just can't become worse. :) > > Legacy atapicam wrapper ignores sense_len on input and doesn't fill > sense_resig on output -- I haven't tested, but it also should be invariant. I am not only talking about ATAPI but abut SCSI in general. Do you know the CAM behavior for other SCSI transports? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 17:37:14 2010 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 A4C541065679; Mon, 8 Nov 2010 17:37:14 +0000 (UTC) (envelope-from mavbsd@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 2B2458FC32; Mon, 8 Nov 2010 17:37:13 +0000 (UTC) Received: by gwj16 with SMTP id 16so3708623gwj.13 for ; Mon, 08 Nov 2010 09:37:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received: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=J6iMJgoeWVi8OfHg7wJvIJktNxMfinvbWbpZDwyVoMM=; b=N3dxE/P7PSaaZHVB+cjmJML6yL9AVXJJFNVAbFmSfsMDpERNxFHaRcSIV1hEMAYB3P qFOWxtCjgYWbxkx5caGuLXo98jP1SVksBjh9WuIJ41qfco7MsHG5iGH4RTk1qx7rNNwU 2SU6TGDVMg+R9MO1bQ0BG0YuahnjJKqO6Ou6o= 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=bKyHCwuueJ/v8BgRu8SHAQcomYuFQ1UUHpTb7F8uigb/cvfHAa52TvUc7O6jnAPFDM mnlhfNR8+vqjeHvUhalIHIRMZms3G8LGl80cGvY8byZQoyhwmY6+6c7Pyu29ZBXYQJkV fJW75t1MJ0UpZjh1UFitr1p9Lr5SrVNJ/u1p4= Received: by 10.204.60.199 with SMTP id q7mr684335bkh.39.1289237832362; Mon, 08 Nov 2010 09:37:12 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id p22sm126133bkp.21.2010.11.08.09.37.10 (version=SSLv3 cipher=RC4-MD5); Mon, 08 Nov 2010 09:37:11 -0800 (PST) Sender: Alexander Motin Message-ID: <4CD83535.1010008@FreeBSD.org> Date: Mon, 08 Nov 2010 19:36:53 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Joerg Schilling References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> <4CD82E2A.3070407@FreeBSD.org> <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> In-Reply-To: <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> 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, freebsd-stable@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] 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, 08 Nov 2010 17:37:14 -0000 Joerg Schilling wrote: > Alexander Motin wrote: >>> Your patch to libscg looks definitely OK if we only look at the new corrected >>> kernel driver behavior. >>> >>> There is a problem: >>> >>> In case that there is a sense data residual > 0, libscg will asume that there >>> is less sense data that really present in case that a "new" libscg is runnung >>> on an old kernel. >>> >>> Given the fact that many drives will probably only return 18 bytes of sense >>> data, this will happen every time libscg is told to fetch more sense than the >>> drive is willing to return. >>> >>> Is there a way to distinct an old kernel from a new one? >> I don't see the problem. Previous kernel in most cases reported >> sesnse_resid == 0, lying that there is more sense data then really is. >> New one should report real (often positive) value. In both cases >> sesnse_resid value measured from the value submitted to the kernel. > > Did the old kernel return a zero sense_resid for any implemented SCSI > transport? Libscg is a generic SCSI transport library and cdrecord is just one > user of this lib. Not sure I understand your question. Zero sesnse_resid is absolutely normal situation if device gave same amount of sense as application requested. As I can see, many of SCSI controllers report sesnse_resid properly. I may assume that some, like atapicd don't -- in that case you'll also see 0 there. >>> I see no advantage in removing the call to fillbytes(). >> scgcheck tests how much sense data received by counting 0x00 and 0xff >> bytes. Zero-filling response buffer breaks that check. Though I have no >> idea if other crdtools' applications depend on these zeros. There could >> be some internal inconsistency. > > O, I need to check other low level transport adaptation layers and think about > this statement. > >>> Did you test a modified libscg on an unmodified kernel? >> Unmodified kernel by default doesn't return any sense data at all for >> new CAM-based ATA -- this changes should be invariant. New scgcheck runs >> same bad as old. It just can't become worse. :) >> >> Legacy atapicam wrapper ignores sense_len on input and doesn't fill >> sense_resig on output -- I haven't tested, but it also should be invariant. > > I am not only talking about ATAPI but abut SCSI in general. > > Do you know the CAM behavior for other SCSI transports? I don't have real SCSI CD to test, but a as I can see, most of SCSI controllers return sense data automatically. Sense fetching changes should not affect/break anything there. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 18:25:00 2010 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 D52F2106564A; Mon, 8 Nov 2010 18:25: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 88E508FC16; Mon, 8 Nov 2010 18:25:00 +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 DC04A46B3B; Mon, 8 Nov 2010 13:24:59 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 954D48A01D; Mon, 8 Nov 2010 13:24:58 -0500 (EST) From: John Baldwin To: Matthew Fleming Date: Mon, 8 Nov 2010 13:24:05 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011081142.46175.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011081324.05514.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 08 Nov 2010 13:24:58 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-usb@freebsd.org, Weongyo Jeong , freebsd-current@freebsd.org, freebsd-arch@freebsd.org, Hans Petter Selasky Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system 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, 08 Nov 2010 18:25:01 -0000 On Monday, November 08, 2010 11:46:58 am Matthew Fleming wrote: > On Mon, Nov 8, 2010 at 8:42 AM, John Baldwin wrote: > > On Monday, November 08, 2010 10:34:33 am Matthew Fleming wrote: > >> On Mon, Nov 8, 2010 at 6:47 AM, John Baldwin wrote: > >> > On Saturday, November 06, 2010 4:33:17 pm Matthew Fleming wrote: > >> >> On Sat, Nov 6, 2010 at 7:22 AM, Hans Petter Selasky wrote: > >> >> > Hi, > >> >> > > >> >> > On Saturday 06 November 2010 14:57:50 Matthew Fleming wrote: > >> >> >> > >> >> >> I think you're misunderstanding the existing taskqueue(9) implementation. > >> >> >> > >> >> >> As long as TQ_LOCK is held, the state of ta->ta_pending cannot change, > >> >> >> nor can the set of running tasks. So the order of checks is > >> >> >> irrelevant. > >> >> > > >> >> > I agree that the order of checks is not important. That is not the problem. > >> >> > > >> >> > Cut & paste from suggested taskqueue patch from Fleming: > >> >> > > >> >> > > +int > >> >> >> > +taskqueue_cancel(struct taskqueue *queue, struct task *task) > >> >> >> > +{ > >> >> >> > + int rc; > >> >> >> > + > >> >> >> > + TQ_LOCK(queue); > >> >> >> > + if (!task_is_running(queue, task)) { > >> >> >> > + if ((rc = task->ta_pending) > 0) > >> >> >> > + STAILQ_REMOVE(&queue->tq_queue, task, task, > >> >> >> > ta_link); + task->ta_pending = 0; > >> >> >> > + } else { > >> >> >> > + rc = -EBUSY; > >> >> > > >> >> > What happens in this case if ta_pending > 0. Are you saying this is not > >> >> > possible? If ta_pending > 0, shouldn't we also do a STAILQ_REMOVE() ? > >> >> > >> >> Ah! I see what you mean. > >> >> > >> >> I'm not quite sure what the best thing to do here is; I agree it would > >> >> be nice if taskqueue_cancel(9) dequeued the task, but I believe it > >> >> also needs to indicate that the task is currently running. I guess > >> >> the best thing would be to return the old pending count by reference > >> >> parameter, and 0 or EBUSY to also indicate if there is a task > >> >> currently running. > >> >> > >> >> Adding jhb@ to this mail since he has good thoughts on interfacing. > >> > > >> > I agree we should always dequeue when possible. I think it should return > >> > -EBUSY in that case. That way code that uses 'cancel' followed by a > >> > conditional 'drain' to implement a blocking 'cancel' will DTRT. > >> > >> Do we not also want the old ta_pending to be returned? In the case > >> where a task is pending and is also currently running (admittedly a > >> narrow window), how would we do this? This is why I suggested > >> returning the old ta_pending by reference. This also allows callers > >> who don't care about the old pending to pass NULL and ignore it. > > > > I would be fine with that then. I wonder if taskqueue_cancel() could then > > return a simple true/false. False if the task is running, and true > > otherwise? > > Sure, though since we don't really have a bool type in the kernel I'd > still prefer to return an int with EBUSY meaning a task was running. The only reason I would prefer the other sense (false if already running) is that is what callout_stop()'s return value is (true if it "stopped" the callout, false if it couldn't stop it)). However, returning EBUSY is ok. One difference is that callout_stop() returns false if the callout is not pending (i.e. not on softclock). Right now taskqueue_cancel() returns 0 in that case (ta_pending == 0), but that is probably fine as long as it is documented. If you wanted to return EINVAL instead, that would be fine, too. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 19:03:42 2010 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 54C15106564A for ; Mon, 8 Nov 2010 19:03:42 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 3313D8FC08 for ; Mon, 8 Nov 2010 19:03:41 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.4/8.14.4) with ESMTP id oA8J3f1V087414; Mon, 8 Nov 2010 11:03:41 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.4/8.14.4/Submit) id oA8J3f4N087413; Mon, 8 Nov 2010 11:03:41 -0800 (PST) (envelope-from obrien) Date: Mon, 8 Nov 2010 11:03:41 -0800 From: "David O'Brien" To: Garrett Cooper Message-ID: <20101108190341.GC82268@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Garrett Cooper , freebsd-current@freebsd.org References: <20101105202536.GR85693@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 9.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current@FreeBSD.org Subject: Re: Files under src/ not used for building world X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@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: Mon, 08 Nov 2010 19:03:42 -0000 On Fri, Nov 05, 2010 at 09:42:27PM -0700, Garrett Cooper wrote: > On Fri, Nov 5, 2010 at 1:25 PM, Ulrich Spörlein wrote: > > Hey folks, not sure why, but I had a stab at looking which files were > > actually read during building world. [..] > > usr.bin/cpio/test/*     # move to tools/regression? > > Seems like a legitimate request. Not necessary. I prefer to have the tests under the thing being tested. It makes it much easier to test the util before committing. That said, the tests should be hooked up and referred to in tools/regression/usr.bin/ -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 19:17:30 2010 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 64BA01065673 for ; Mon, 8 Nov 2010 19:17:30 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 4480C8FC12 for ; Mon, 8 Nov 2010 19:17:30 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.4/8.14.4) with ESMTP id oA8IqvsT082845; Mon, 8 Nov 2010 10:52:57 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.4/8.14.4/Submit) id oA8IqvEV082844; Mon, 8 Nov 2010 10:52:57 -0800 (PST) (envelope-from obrien) Date: Mon, 8 Nov 2010 10:52:57 -0800 From: "David O'Brien" To: Randy Bush Message-ID: <20101108185257.GA82268@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Randy Bush , FreeBSD current mailing list References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 9.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? User-Agent: Mutt/1.5.16 (2007-06-09) Cc: FreeBSD current mailing list Subject: Re: groff build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@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: Mon, 08 Nov 2010 19:17:30 -0000 On Mon, Nov 08, 2010 at 03:14:02PM +0800, Randy Bush wrote: > very current amd64 > ===> gnu/usr.bin/groff/src/preproc/eqn (all) > c++ -O2 -pipe -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/preproc/eqn -I. -DHAVE_CONFIG_H -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/include -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../src/include -fstack-protector -fno-rtti -fno-exceptions -c eqn.cpp > y.tab.c: In function 'int yygrowstack()': > y.tab.c:703: error: invalid conversion from 'void*' to 'short int*' > y.tab.c:709: error: invalid conversion from 'void*' to 'YYSTYPE*' Sorry, about this. I will fix my commit. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 19:17:30 2010 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 BF3EF106564A for ; Mon, 8 Nov 2010 19:17:30 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 9F3758FC1B for ; Mon, 8 Nov 2010 19:17:30 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.4/8.14.4) with ESMTP id oA8J0fIX087341; Mon, 8 Nov 2010 11:00:41 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.4/8.14.4/Submit) id oA8J0fGG087340; Mon, 8 Nov 2010 11:00:41 -0800 (PST) (envelope-from obrien) Date: Mon, 8 Nov 2010 11:00:41 -0800 From: "David O'Brien" To: Randy Bush Message-ID: <20101108190041.GB82268@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Randy Bush , FreeBSD current mailing list References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 9.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? User-Agent: Mutt/1.5.16 (2007-06-09) Cc: FreeBSD current mailing list Subject: Re: groff build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@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: Mon, 08 Nov 2010 19:17:30 -0000 On Mon, Nov 08, 2010 at 03:14:02PM +0800, Randy Bush wrote: > ===> gnu/usr.bin/groff/src/preproc/eqn (all) > c++ -O2 -pipe -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/preproc/eqn -I. -DHAVE_CONFIG_H -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/include -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../src/include -fstack-protector -fno-rtti -fno-exceptions -c eqn.cpp > y.tab.c: In function 'int yygrowstack()': > y.tab.c:703: error: invalid conversion from 'void*' to 'short int*' > y.tab.c:709: error: invalid conversion from 'void*' to 'YYSTYPE*' > *** Error code 1 Randy, Can you update to r214990 and confirm things are OK for you? thanks and sorry, -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 20:37:08 2010 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 473841065672; Mon, 8 Nov 2010 20:37:08 +0000 (UTC) (envelope-from mdf356@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 C93C28FC24; Mon, 8 Nov 2010 20:37:07 +0000 (UTC) Received: by iwn39 with SMTP id 39so6506949iwn.13 for ; Mon, 08 Nov 2010 12:37:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=I155nDbwEt9h3lLLqiGD6cPgOWFcZiWcgJYvp7RPhsU=; b=RkXnSGymT0weEJez7fPVi2VchCnFcI7CbVq/eXn+fjhtm2TwNQNJE9LwYX9AmxTk8V JpTBvsqdofAU37j2eysXW9lEXoslGeHilZ5TWAlcc1XIGL/7ehMbaA1vA9hl4daEnMsm gqWgXt+U+Tzk4J+3Lb8+U36e1HdDWdUuMpIwQ= 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=W4z+VGmu0W515mdZi+6jYRIUdfkyVjgtTyHgm1out//T3IZkL/su7ShIJSFLDZuyMT YPPt9d/4Dmima9ji7r6BrcJ+HwADcYlx4f0xMgTyLdRFmB5+8rjWjM/oQol5ePxIJwu4 ck22MS1URXyF8oNtwYSSNJ5hIgB/rN1ic9QE0= MIME-Version: 1.0 Received: by 10.231.192.73 with SMTP id dp9mr4536957ibb.72.1289248626670; Mon, 08 Nov 2010 12:37:06 -0800 (PST) Received: by 10.231.21.35 with HTTP; Mon, 8 Nov 2010 12:37:06 -0800 (PST) In-Reply-To: <201011081324.05514.jhb@freebsd.org> References: <201011012054.59551.hselasky@c2i.net> <201011081142.46175.jhb@freebsd.org> <201011081324.05514.jhb@freebsd.org> Date: Mon, 8 Nov 2010 12:37:06 -0800 Message-ID: From: Matthew Fleming To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-usb@freebsd.org, Weongyo Jeong , freebsd-current@freebsd.org, freebsd-arch@freebsd.org, Hans Petter Selasky Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system 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, 08 Nov 2010 20:37:08 -0000 On Mon, Nov 8, 2010 at 10:24 AM, John Baldwin wrote: > On Monday, November 08, 2010 11:46:58 am Matthew Fleming wrote: >> On Mon, Nov 8, 2010 at 8:42 AM, John Baldwin wrote: >> > On Monday, November 08, 2010 10:34:33 am Matthew Fleming wrote: >> >> On Mon, Nov 8, 2010 at 6:47 AM, John Baldwin wrote: >> >> > On Saturday, November 06, 2010 4:33:17 pm Matthew Fleming wrote: >> >> >> On Sat, Nov 6, 2010 at 7:22 AM, Hans Petter Selasky wrote: >> >> >> > Hi, >> >> >> > >> >> >> > On Saturday 06 November 2010 14:57:50 Matthew Fleming wrote: >> >> >> >> >> >> >> >> I think you're misunderstanding the existing taskqueue(9) imple= mentation. >> >> >> >> >> >> >> >> As long as TQ_LOCK is held, the state of ta->ta_pending cannot = change, >> >> >> >> nor can the set of running tasks. =A0So the order of checks is >> >> >> >> irrelevant. >> >> >> > >> >> >> > I agree that the order of checks is not important. That is not t= he problem. >> >> >> > >> >> >> > Cut & paste from suggested taskqueue patch from Fleming: >> >> >> > >> >> >> > =A0> +int >> >> >> >> > +taskqueue_cancel(struct taskqueue *queue, struct task *task) >> >> >> >> > +{ >> >> >> >> > + =A0 =A0 =A0 int rc; >> >> >> >> > + >> >> >> >> > + =A0 =A0 =A0 TQ_LOCK(queue); >> >> >> >> > + =A0 =A0 =A0 if (!task_is_running(queue, task)) { >> >> >> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((rc =3D task->ta_pending) >= 0) >> >> >> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_REMOVE(&= queue->tq_queue, task, task, >> >> >> >> > ta_link); + =A0 =A0 =A0 =A0 =A0 =A0 =A0 task->ta_pending =3D = 0; >> >> >> >> > + =A0 =A0 =A0 } else { >> >> >> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 rc =3D -EBUSY; >> >> >> > >> >> >> > What happens in this case if ta_pending > 0. Are you saying this= is not >> >> >> > possible? If ta_pending > 0, shouldn't we also do a STAILQ_REMOV= E() ? >> >> >> >> >> >> Ah! =A0I see what you mean. >> >> >> >> >> >> I'm not quite sure what the best thing to do here is; I agree it w= ould >> >> >> be nice if taskqueue_cancel(9) dequeued the task, but I believe it >> >> >> also needs to indicate that the task is currently running. =A0I gu= ess >> >> >> the best thing would be to return the old pending count by referen= ce >> >> >> parameter, and 0 or EBUSY to also indicate if there is a task >> >> >> currently running. >> >> >> >> >> >> Adding jhb@ to this mail since he has good thoughts on interfacing= . >> >> > >> >> > I agree we should always dequeue when possible. =A0I think it shoul= d return >> >> > -EBUSY in that case. =A0That way code that uses 'cancel' followed b= y a >> >> > conditional 'drain' to implement a blocking 'cancel' will DTRT. >> >> >> >> Do we not also want the old ta_pending to be returned? =A0In the case >> >> where a task is pending and is also currently running (admittedly a >> >> narrow window), how would we do this? =A0This is why I suggested >> >> returning the old ta_pending by reference. =A0This also allows caller= s >> >> who don't care about the old pending to pass NULL and ignore it. >> > >> > I would be fine with that then. =A0I wonder if taskqueue_cancel() coul= d then >> > return a simple true/false. =A0False if the task is running, and true >> > otherwise? >> >> Sure, though since we don't really have a bool type in the kernel I'd >> still prefer to return an int with EBUSY meaning a task was running. > > The only reason I would prefer the other sense (false if already running) > is that is what callout_stop()'s return value is (true if it "stopped" th= e > callout, false if it couldn't stop it)). I think the symmetry with callout(9) can't go very far, mostly because callout generally takes a specified mtx before calling the callback, and taskqueue(9) does not. That means fundamentally that, when using a taskqueue(9) the consumer has much less knowledge of the exact state of a task. Thanks, matthew > However, returning EBUSY is ok. =A0One difference is that callout_stop() > returns false if the callout is not pending (i.e. not on softclock). =A0R= ight > now taskqueue_cancel() returns 0 in that case (ta_pending =3D=3D 0), but = that is > probably fine as long as it is documented. =A0If you wanted to return EIN= VAL > instead, that would be fine, too. > > -- > John Baldwin > From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 22:14:55 2010 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 88A8A1065679 for ; Mon, 8 Nov 2010 22:14:55 +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 597198FC1C for ; Mon, 8 Nov 2010 22:14:55 +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 E27E946B0D for ; Mon, 8 Nov 2010 17:14:54 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1E1958A009 for ; Mon, 8 Nov 2010 17:14:54 -0500 (EST) From: John Baldwin To: current@freebsd.org Date: Mon, 8 Nov 2010 17:14:53 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201011081714.53637.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 08 Nov 2010 17:14:54 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.7 required=4.2 tests=BAYES_00,TO_NO_BRKTS_DIRECT autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Subject: Only display ACPI bootmenu key if ACPI is present 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, 08 Nov 2010 22:14:55 -0000 This patch changes the Forth code for the Beastie menu to only display the menu option to enable or disable ACPI if the loader detects ACPI. This avoids displaying a menu item prompting to enable ACPI if the BIOS doesn't actually include ACPI. Any objections? --- //depot/projects/smpng/sys/boot/forth/beastie.4th 2010-11-08 21:53:18.000000000 0000 +++ //depot/user/jhb/ktrace/boot/forth/beastie.4th 2010-11-08 22:14:04.000000000 0000 @@ -140,12 +140,16 @@ fbsdbw-logo ; -: acpienabled? ( -- flag ) +: acpipresent? ( -- flag ) s" hint.acpi.0.rsdp" getenv dup -1 = if drop false exit then 2drop + true +; + +: acpienabled? ( -- flag ) s" hint.acpi.0.disabled" getenv dup -1 <> if s" 0" compare 0<> if @@ -178,8 +182,7 @@ 42 20 2 2 box 13 6 at-xy ." Welcome to FreeBSD!" printmenuitem ." Boot FreeBSD [default]" bootkey ! - s" arch-i386" environment? if - drop + acpipresent? if printmenuitem ." Boot FreeBSD with ACPI " bootacpikey ! acpienabled? if ." disabled" -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 00:28:32 2010 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 DDCED1065670; Tue, 9 Nov 2010 00:28:32 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id C19F38FC21; Tue, 9 Nov 2010 00:28:32 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PFc4d-000KkP-73; Tue, 09 Nov 2010 00:28:32 +0000 Date: Tue, 09 Nov 2010 08:28:27 +0800 Message-ID: From: Randy Bush To: "David O'Brien" In-Reply-To: <20101108190041.GB82268@dragon.NUXI.org> References: <20101108190041.GB82268@dragon.NUXI.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: FreeBSD current mailing list Subject: Re: groff build failure 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, 09 Nov 2010 00:28:32 -0000 > On Mon, Nov 08, 2010 at 03:14:02PM +0800, Randy Bush wrote: >> ===> gnu/usr.bin/groff/src/preproc/eqn (all) >> c++ -O2 -pipe -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/preproc/eqn -I. -DHAVE_CONFIG_H -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/include -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../src/include -fstack-protector -fno-rtti -fno-exceptions -c eqn.cpp >> y.tab.c: In function 'int yygrowstack()': >> y.tab.c:703: error: invalid conversion from 'void*' to 'short int*' >> y.tab.c:709: error: invalid conversion from 'void*' to 'YYSTYPE*' >> *** Error code 1 > Can you update to r214990 and confirm things are OK for you? cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-f ormat-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpo inter-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 /usr/src/usr.bin/yacc/reader.c cc1: warnings being treated as errors /usr/src/usr.bin/yacc/reader.c: In function 'get_literal': /usr/src/usr.bin/yacc/reader.c:722: warning: comparison between signed and unsigned /usr/src/usr.bin/yacc/reader.c:738: warning: comparison between signed and unsigned *** Error code 1 Stop in /usr/src/usr.bin/yacc. *** Error code 1 From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 00:35:20 2010 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 54970106566C for ; Tue, 9 Nov 2010 00:35:20 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (oute.internet-mail-service.net [216.240.47.228]) by mx1.freebsd.org (Postfix) with ESMTP id 397728FC2B for ; Tue, 9 Nov 2010 00:35:20 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oA90XrJ4024752 for ; Mon, 8 Nov 2010 16:34:55 -0800 X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 0D68A2D6026 for ; Mon, 8 Nov 2010 16:34:17 -0800 (PST) Message-ID: <4CD8970D.6030003@freebsd.org> Date: Mon, 08 Nov 2010 16:34:21 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: Subject: kgdb and .ko 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: Tue, 09 Nov 2010 00:35:20 -0000 my usual command set for doing .ko debugging issomething like: %kgdb /sys/amd64/compile/DEBUG/kernel.symbols (kgdb) target remote pu_serial2:7005 (kgdb) sharedlibrary driver.ko (kgdb) directory /home/me/branches/blah/obj/ (kgdb) info sharedlibrary >From To Syms Read Shared Object Library 0xffffffff81222000 0xffffffff8129dac0 Yes home/me/branches/blah/freebsd8-amd64/output/driver.ko but recently the last line has started returning: >From To Syms Read Shared Object Library Yes home/me/branches/blah/freebsd8-amd64/output/driver.ko Now I can guess that the problem might be something to do with readinf symbols as our method of generating the .ko changed a while back but when I look at it I do see: awk -f /sys/conf/kmod_syms.awk driver.ko.debug export_syms | xargs -J% objcopy %driver.ko.debug objcopy --only-keep-debug driver.ko.debug driver.ko.symbols objcopy --strip-debug --add-gnu-debuglink=driver.ko.symbols driver.ko.debug driver.ko so theoretically the plain driver.ko should result in (k)gdb looking up the symbol file driver.ko.symbols which should have all the symbol information needed for debugging.. or am I misreading this? doesn't seem to work but it does seem to improve if I link the .ko file to the symbols file.. this is in 8.1 rather than -current but I can't test -current. From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 00:43:16 2010 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 8FE41106566C; Tue, 9 Nov 2010 00:43:16 +0000 (UTC) (envelope-from erob@gthcfoundation.org) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.freebsd.org (Postfix) with ESMTP id 6CBCE8FC17; Tue, 9 Nov 2010 00:43:16 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from [192.168.0.101] ([74.58.70.113]) by VL-MR-MRZ20.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0LBL00DM7B7VF130@VL-MR-MRZ20.ip.videotron.ca>; Mon, 08 Nov 2010 18:43:08 -0500 (EST) Message-id: <4CD889C0.6050203@gthcfoundation.org> Date: Mon, 08 Nov 2010 18:37:36 -0500 From: Etienne Robillard User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.15) Gecko/20101102 Thunderbird/3.0.10 To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Cc: Subject: Error: stack overflow on boot 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, 09 Nov 2010 00:43:16 -0000 Hi, why is this message happening with 8.1 and sometimes CURRENT ? I tried recompiling the bootloader but the error still happens, forcing user to hit Enter to enter manual boot. Any takes ? :) Many thanks, Etienne From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 00:57:01 2010 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 E5D9F1065674; Tue, 9 Nov 2010 00:57:00 +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 B5FEF8FC24; Tue, 9 Nov 2010 00:57:00 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oA90uxDQ059520; Mon, 8 Nov 2010 19:56:59 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oA90uxxP059510; Tue, 9 Nov 2010 00:56:59 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 9 Nov 2010 00:56:59 GMT Message-Id: <201011090056.oA90uxxP059510@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 amd64/amd64 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: Tue, 09 Nov 2010 00:57:01 -0000 TB --- 2010-11-08 23:15:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-08 23:15:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2010-11-08 23:15:00 - cleaning the object tree TB --- 2010-11-08 23:15:10 - cvsupping the source tree TB --- 2010-11-08 23:15:10 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2010-11-08 23:15:48 - building world TB --- 2010-11-08 23:15:48 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-08 23:15:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-08 23:15:48 - TARGET=amd64 TB --- 2010-11-08 23:15:48 - TARGET_ARCH=amd64 TB --- 2010-11-08 23:15:48 - TZ=UTC TB --- 2010-11-08 23:15:48 - __MAKE_CONF=/dev/null TB --- 2010-11-08 23:15:48 - cd /src TB --- 2010-11-08 23:15:48 - /usr/bin/make -B buildworld >>> World build started on Mon Nov 8 23:15:48 UTC 2010 >>> 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.bin/yacc/main.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 -c /src/usr.bin/yacc/mkpar.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 -c /src/usr.bin/yacc/output.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 -c /src/usr.bin/yacc/reader.c cc1: warnings being treated as errors /src/usr.bin/yacc/reader.c: In function 'get_literal': /src/usr.bin/yacc/reader.c:722: warning: comparison between signed and unsigned /src/usr.bin/yacc/reader.c:738: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/usr.bin/yacc. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-09 00:56:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-09 00:56:59 - ERROR: failed to build world TB --- 2010-11-09 00:56:59 - 4822.95 user 882.77 system 6119.48 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 01:11:22 2010 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 0947A106566B; Tue, 9 Nov 2010 01:11:22 +0000 (UTC) (envelope-from yanegomi@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 674B68FC16; Tue, 9 Nov 2010 01:11:21 +0000 (UTC) Received: by wwb13 with SMTP id 13so194275wwb.31 for ; Mon, 08 Nov 2010 17:11:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=N9ZsSYaPr5cu0/BYkQUShnAiJljckarNZoXJPWWXBMc=; b=pfcLpLUB3JRECK4unVSiZLppxAqX3FnGkixnuFu2A/vHSXM4260zLomNE+CMzZgQSQ fMil3yqhABrhzC0ZTIF9H+c03M4tM4G6IEAAB5rBNvE8vIk10VcSmyehjOmAgD6cMSOk rJ1WdIDxgW2qSvZ6z6TQg4KTivL3+gGsnBmms= 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=n5Zb/EIO4hdFRn+XXGrRQaMCV7c73TumA+q/n6RfdobIoTGxX8zoSfpbHG3ViTax3o 6DGRZ9bAG1RkgdY6eGGDhhoC4LmllMuUw7yIplUXOx1sIlOnSRBuSWsBeYNcqPYIkW+7 juLbXVV84w0B54BAFR8D7ZMj9hYCLNHSIVIog= MIME-Version: 1.0 Received: by 10.216.7.210 with SMTP id 60mr126989wep.30.1289265079410; Mon, 08 Nov 2010 17:11:19 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Mon, 8 Nov 2010 17:11:19 -0800 (PST) In-Reply-To: References: <20101108190041.GB82268@dragon.NUXI.org> Date: Mon, 8 Nov 2010 17:11:19 -0800 X-Google-Sender-Auth: yJKeKmCmfnou27clVOeplicwh9g Message-ID: From: Garrett Cooper To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD current mailing list Subject: Re: groff build failure 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, 09 Nov 2010 01:11:22 -0000 On Mon, Nov 8, 2010 at 4:28 PM, Randy Bush wrote: >> On Mon, Nov 08, 2010 at 03:14:02PM +0800, Randy Bush wrote: >>> =3D=3D=3D> gnu/usr.bin/groff/src/preproc/eqn (all) >>> c++ -O2 -pipe -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../= ../../contrib/groff/src/preproc/eqn -I. -DHAVE_CONFIG_H -I/usr/src/gnu/usr.= bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/include -I/us= r/src/gnu/usr.bin/groff/src/preproc/eqn/../../../src/include -fstack-protec= tor -fno-rtti -fno-exceptions -c eqn.cpp >>> y.tab.c: In function 'int yygrowstack()': >>> y.tab.c:703: error: invalid conversion from 'void*' to 'short int*' >>> y.tab.c:709: error: invalid conversion from 'void*' to 'YYSTYPE*' >>> *** Error code 1 >> Can you update to r214990 and confirm things are OK for you? > > cc -O2 -pipe =A0-std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -= Wall -Wno-f > ormat-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototyp= es -Wpo > inter-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -= Wunused > -parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wred= undant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/usr.bin/y= acc/reader.c > cc1: warnings being treated as errors > /usr/src/usr.bin/yacc/reader.c: In function 'get_literal': > /usr/src/usr.bin/yacc/reader.c:722: warning: comparison between signed an= d unsigned > /usr/src/usr.bin/yacc/reader.c:738: warning: comparison between signed an= d unsigned > *** Error code 1 > > Stop in /usr/src/usr.bin/yacc. > *** Error code 1 Tinderbox agrees :(... From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 01:27:20 2010 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 15B53106564A; Tue, 9 Nov 2010 01:27:20 +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 DDBA78FC23; Tue, 9 Nov 2010 01:27:19 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oA91RJEO070203; Mon, 8 Nov 2010 20:27:19 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oA91RJbb070198; Tue, 9 Nov 2010 01:27:19 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 9 Nov 2010 01:27:19 GMT Message-Id: <201011090127.oA91RJbb070198@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: Tue, 09 Nov 2010 01:27:20 -0000 TB --- 2010-11-09 00:09:56 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-09 00:09:56 - starting HEAD tinderbox run for ia64/ia64 TB --- 2010-11-09 00:09:56 - cleaning the object tree TB --- 2010-11-09 00:10:05 - cvsupping the source tree TB --- 2010-11-09 00:10:05 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2010-11-09 00:10:28 - building world TB --- 2010-11-09 00:10:28 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-09 00:10:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-09 00:10:28 - TARGET=ia64 TB --- 2010-11-09 00:10:28 - TARGET_ARCH=ia64 TB --- 2010-11-09 00:10:28 - TZ=UTC TB --- 2010-11-09 00:10:28 - __MAKE_CONF=/dev/null TB --- 2010-11-09 00:10:28 - cd /src TB --- 2010-11-09 00:10:28 - /usr/bin/make -B buildworld >>> World build started on Tue Nov 9 00:10:29 UTC 2010 >>> 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 -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.bin/yacc/main.c 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 -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/yacc/mkpar.c 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 -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/yacc/output.c 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 -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/yacc/reader.c cc1: warnings being treated as errors /src/usr.bin/yacc/reader.c: In function 'get_literal': /src/usr.bin/yacc/reader.c:722: warning: comparison between signed and unsigned /src/usr.bin/yacc/reader.c:738: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/usr.bin/yacc. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-09 01:27:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-09 01:27:19 - ERROR: failed to build world TB --- 2010-11-09 01:27:19 - 3584.08 user 660.52 system 4643.04 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 02:08:42 2010 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 15681106564A for ; Tue, 9 Nov 2010 02:08:42 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (outg.internet-mail-service.net [216.240.47.230]) by mx1.freebsd.org (Postfix) with ESMTP id ED4C38FC18 for ; Tue, 9 Nov 2010 02:08:41 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oA928eA7028978 for ; Mon, 8 Nov 2010 18:08:40 -0800 X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 7843D2D6015 for ; Mon, 8 Nov 2010 18:08:40 -0800 (PST) Message-ID: <4CD8AD2B.5000505@freebsd.org> Date: Mon, 08 Nov 2010 18:08:43 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: FreeBSD Current References: <4CD8970D.6030003@freebsd.org> In-Reply-To: <4CD8970D.6030003@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: Subject: Re: kgdb and .ko 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: Tue, 09 Nov 2010 02:08:42 -0000 relying to self with more info.. On 11/8/10 4:34 PM, Julian Elischer wrote: > my usual command set for doing .ko debugging issomething like: > %kgdb /sys/amd64/compile/DEBUG/kernel.symbols > (kgdb) target remote pu_serial2:7005 > (kgdb) sharedlibrary driver.ko > (kgdb) directory /home/me/branches/blah/obj/ > > (kgdb) info sharedlibrary >> From To Syms Read Shared Object >> Library > 0xffffffff81222000 0xffffffff8129dac0 Yes > home/me/branches/blah/freebsd8-amd64/output/driver.ko > > but recently the last line has started returning: > >> From To Syms Read Shared Object >> Library > Yes > home/me/branches/blah/freebsd8-amd64/output/driver.ko > > Now I can guess that the problem might be something to do with > readinf symbols as our > method of generating the .ko changed a while back but when I look at > it I do see: > > awk -f /sys/conf/kmod_syms.awk driver.ko.debug export_syms | xargs > -J% objcopy %driver.ko.debug > objcopy --only-keep-debug driver.ko.debug driver.ko.symbols > objcopy --strip-debug --add-gnu-debuglink=driver.ko.symbols > driver.ko.debug driver.ko > > so theoretically the plain driver.ko should result in (k)gdb looking > up the symbol file driver.ko.symbols > which should have all the symbol information needed for debugging.. > or am I misreading this? > > doesn't seem to work but it does seem to improve if I link the .ko > file to the symbols file.. it seems changing the first objcopy line to give the full path name of the symbol file seems to help > > this is in 8.1 rather than -current but I can't test -current. > > _______________________________________________ > 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 Nov 9 02:39:58 2010 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 9FFF61065673 for ; Tue, 9 Nov 2010 02:39:58 +0000 (UTC) (envelope-from kevlo@FreeBSD.org) Received: from ns.kevlo.org (kevlo.org [220.128.136.52]) by mx1.freebsd.org (Postfix) with ESMTP id 29AD68FC1B for ; Tue, 9 Nov 2010 02:39:57 +0000 (UTC) Received: from [127.0.0.1] (kevlo@kevlo.org [220.128.136.52]) by ns.kevlo.org (8.14.3/8.14.3) with ESMTP id oA91xTP3009279; Tue, 9 Nov 2010 09:59:29 +0800 (CST) From: Kevin Lo To: John Baldwin In-Reply-To: <201011081714.53637.jhb@freebsd.org> References: <201011081714.53637.jhb@freebsd.org> Content-Type: text/plain; charset="UTF-8" Date: Tue, 09 Nov 2010 10:00:15 +0800 Message-ID: <1289268015.1982.3.camel@nsl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: Only display ACPI bootmenu key if ACPI is present 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, 09 Nov 2010 02:39:58 -0000 John Baldwin wrote: > This patch changes the Forth code for the Beastie menu to only display the > menu option to enable or disable ACPI if the loader detects ACPI. This avoids > displaying a menu item prompting to enable ACPI if the BIOS doesn't actually > include ACPI. Any objections? I have no objection. This patch makes sense to me. Kevin From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 02:41:32 2010 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 49D09106566C; Tue, 9 Nov 2010 02:41:32 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 168BE8FC23; Tue, 9 Nov 2010 02:41:31 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.4/8.14.4) with ESMTP id oA92fVgn009609; Mon, 8 Nov 2010 18:41:31 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.4/8.14.4/Submit) id oA92fVqe009608; Mon, 8 Nov 2010 18:41:31 -0800 (PST) (envelope-from obrien) Date: Mon, 8 Nov 2010 18:41:31 -0800 From: "David O'Brien" To: Garrett Cooper Message-ID: <20101109024131.GA95515@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Garrett Cooper , FreeBSD current mailing list References: <20101108190041.GB82268@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 9.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? User-Agent: Mutt/1.5.16 (2007-06-09) Cc: FreeBSD current mailing list Subject: Re: groff build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@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: Tue, 09 Nov 2010 02:41:32 -0000 On Mon, Nov 08, 2010 at 05:11:19PM -0800, Garrett Cooper wrote: > Tinderbox agrees :(... TB --- 2010-11-08 23:15:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-08 23:15:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2010-11-08 23:15:00 - cleaning the object tree TB --- 2010-11-08 23:15:10 - cvsupping the source tree TB --- 2010-11-08 23:15:10 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile Why is the tinderbox still using CVS source trees? To some degree the tinderbox agreeing is meaningless as the report from it does not give the GRN[*] the sources are based on. [*] specifically the output of: svn info | grep 'Last Changed Rev:' -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 02:50:48 2010 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 94EAF106564A for ; Tue, 9 Nov 2010 02:50:48 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 745348FC16 for ; Tue, 9 Nov 2010 02:50:48 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.4/8.14.4) with ESMTP id oA92oldF049025; Mon, 8 Nov 2010 18:50:47 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.4/8.14.4/Submit) id oA92olwG049020; Mon, 8 Nov 2010 18:50:47 -0800 (PST) (envelope-from obrien) Date: Mon, 8 Nov 2010 18:50:47 -0800 From: "David O'Brien" To: Randy Bush Message-ID: <20101109025047.GB95515@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Randy Bush , FreeBSD current mailing list References: <20101108190041.GB82268@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 9.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? User-Agent: Mutt/1.5.16 (2007-06-09) Cc: FreeBSD current mailing list Subject: Re: groff build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@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: Tue, 09 Nov 2010 02:50:48 -0000 On Tue, Nov 09, 2010 at 08:28:27AM +0800, Randy Bush wrote: > > On Mon, Nov 08, 2010 at 03:14:02PM +0800, Randy Bush wrote: > >> ===> gnu/usr.bin/groff/src/preproc/eqn (all) > >> c++ -O2 -pipe -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/preproc/eqn -I. -DHAVE_CONFIG_H -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/include -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../src/include -fstack-protector -fno-rtti -fno-exceptions -c eqn.cpp > >> y.tab.c: In function 'int yygrowstack()': > >> y.tab.c:703: error: invalid conversion from 'void*' to 'short int*' > >> y.tab.c:709: error: invalid conversion from 'void*' to 'YYSTYPE*' > >> *** Error code 1 > > Can you update to r214990 and confirm things are OK for you? [..] > Stop in /usr/src/usr.bin/yacc. > *** Error code 1 Hi Randy, You may have mentioned this, so sorry if I missed it. Can you verify this is a 64-bit platform? thanks, -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 02:52:26 2010 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 3B91C106566C; Tue, 9 Nov 2010 02:52:26 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 238578FC19; Tue, 9 Nov 2010 02:52:26 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PFeJt-000Mh3-Ht; Tue, 09 Nov 2010 02:52:25 +0000 Date: Tue, 09 Nov 2010 10:52:23 +0800 Message-ID: From: Randy Bush To: "David O'Brien" In-Reply-To: <20101109025047.GB95515@dragon.NUXI.org> References: <20101108190041.GB82268@dragon.NUXI.org> <20101109025047.GB95515@dragon.NUXI.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: FreeBSD current mailing list Subject: Re: groff build failure 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, 09 Nov 2010 02:52:26 -0000 > Can you verify this is a 64-bit platform? i can verify that this is am64 randy From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 02:55:02 2010 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 BBA071065673; Tue, 9 Nov 2010 02:55:02 +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 806848FC08; Tue, 9 Nov 2010 02:55:02 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oA92t1xw048640; Mon, 8 Nov 2010 21:55:01 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oA92t1nS048637; Tue, 9 Nov 2010 02:55:01 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 9 Nov 2010 02:55:01 GMT Message-Id: <201011090255.oA92t1nS048637@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: Tue, 09 Nov 2010 02:55:03 -0000 TB --- 2010-11-09 01:55:06 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-09 01:55:06 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-11-09 01:55:06 - cleaning the object tree TB --- 2010-11-09 01:55:14 - cvsupping the source tree TB --- 2010-11-09 01:55:14 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2010-11-09 01:55:31 - building world TB --- 2010-11-09 01:55:31 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-09 01:55:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-09 01:55:31 - TARGET=sparc64 TB --- 2010-11-09 01:55:31 - TARGET_ARCH=sparc64 TB --- 2010-11-09 01:55:31 - TZ=UTC TB --- 2010-11-09 01:55:31 - __MAKE_CONF=/dev/null TB --- 2010-11-09 01:55:31 - cd /src TB --- 2010-11-09 01:55:31 - /usr/bin/make -B buildworld >>> World build started on Tue Nov 9 01:55:31 UTC 2010 >>> 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.bin/yacc/main.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 -c /src/usr.bin/yacc/mkpar.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 -c /src/usr.bin/yacc/output.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 -c /src/usr.bin/yacc/reader.c cc1: warnings being treated as errors /src/usr.bin/yacc/reader.c: In function 'get_literal': /src/usr.bin/yacc/reader.c:722: warning: comparison between signed and unsigned /src/usr.bin/yacc/reader.c:738: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/usr.bin/yacc. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-09 02:55:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-09 02:55:01 - ERROR: failed to build world TB --- 2010-11-09 02:55:01 - 2593.66 user 631.03 system 3595.37 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 02:56:11 2010 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 B71841065670 for ; Tue, 9 Nov 2010 02:56:11 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 95C208FC16 for ; Tue, 9 Nov 2010 02:56:11 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.4/8.14.4) with ESMTP id oA92uBqB062050; Mon, 8 Nov 2010 18:56:11 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.4/8.14.4/Submit) id oA92uBl7062049; Mon, 8 Nov 2010 18:56:11 -0800 (PST) (envelope-from obrien) Date: Mon, 8 Nov 2010 18:56:11 -0800 From: "David O'Brien" To: Randy Bush Message-ID: <20101109025611.GC95515@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Randy Bush , FreeBSD current mailing list References: <20101108190041.GB82268@dragon.NUXI.org> <20101109025047.GB95515@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 9.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? User-Agent: Mutt/1.5.16 (2007-06-09) Cc: FreeBSD current mailing list Subject: Re: groff build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@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: Tue, 09 Nov 2010 02:56:11 -0000 On Tue, Nov 09, 2010 at 10:52:23AM +0800, Randy Bush wrote: > > Can you verify this is a 64-bit platform? > > i can verify that this is am64 Ok, that explains why I could not reproduce this under i386. Please try r215027. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 03:01:51 2010 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 100D1106564A; Tue, 9 Nov 2010 03:01:51 +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 DD1AD8FC12; Tue, 9 Nov 2010 03:01:49 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oA931nAL000546; Mon, 8 Nov 2010 22:01:49 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oA931nn0000541; Tue, 9 Nov 2010 03:01:49 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 9 Nov 2010 03:01:49 GMT Message-Id: <201011090301.oA931nn0000541@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: Tue, 09 Nov 2010 03:01:51 -0000 TB --- 2010-11-09 02:02:31 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-09 02:02:31 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2010-11-09 02:02:31 - cleaning the object tree TB --- 2010-11-09 02:02:44 - cvsupping the source tree TB --- 2010-11-09 02:02:44 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2010-11-09 02:03:01 - building world TB --- 2010-11-09 02:03:01 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-09 02:03:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-09 02:03:01 - TARGET=sun4v TB --- 2010-11-09 02:03:01 - TARGET_ARCH=sparc64 TB --- 2010-11-09 02:03:01 - TZ=UTC TB --- 2010-11-09 02:03:01 - __MAKE_CONF=/dev/null TB --- 2010-11-09 02:03:01 - cd /src TB --- 2010-11-09 02:03:01 - /usr/bin/make -B buildworld >>> World build started on Tue Nov 9 02:03:01 UTC 2010 >>> 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.bin/yacc/main.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 -c /src/usr.bin/yacc/mkpar.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 -c /src/usr.bin/yacc/output.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 -c /src/usr.bin/yacc/reader.c cc1: warnings being treated as errors /src/usr.bin/yacc/reader.c: In function 'get_literal': /src/usr.bin/yacc/reader.c:722: warning: comparison between signed and unsigned /src/usr.bin/yacc/reader.c:738: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/usr.bin/yacc. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-09 03:01:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-09 03:01:49 - ERROR: failed to build world TB --- 2010-11-09 03:01:49 - 2591.37 user 633.53 system 3557.64 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 04:10:40 2010 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 253B7106564A for ; Tue, 9 Nov 2010 04:10:40 +0000 (UTC) (envelope-from eirnym@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id AC3938FC13 for ; Tue, 9 Nov 2010 04:10:39 +0000 (UTC) Received: by bwz3 with SMTP id 3so5615893bwz.13 for ; Mon, 08 Nov 2010 20:10:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=6E7StAFJhVWoYHn/QESSkuw6c0vlEEcC5Dr5Pnr5LQs=; b=nC16O8S1IlKc1Q93IY08qRM7Jr4t0V6wO88YrhDik5CB+Bpkwfnkh8GGCUBHAqz9UB OaFGH5Y9p3uYstiezQ11U9vL0taeWi1S7/hZK06uJp4j43LMnYFsmBDtB3fCTORN7QQI Kl0bw9yey3lkyhIkbl9mPK8vZzrmOFWZV9hiY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=ixOWGNdhU96qHr6VkXyplLg9As8vnjnw0gRg4kEfyc5guc6MMy0RS9h9hHpexH6Ihp GtsSunkzuZzrzdL+56hLHNH/y7QTcttLBe5ODaIZQKmMt67Czrz5nvMdCfj2xRHMC3cd RaTmpoSov4eAW0w7/HD3qeTrbXwhxLswBWI30= Received: by 10.204.52.7 with SMTP id f7mr5797913bkg.190.1289275838587; Mon, 08 Nov 2010 20:10:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.123.131 with HTTP; Mon, 8 Nov 2010 20:10:18 -0800 (PST) From: Eir Nym Date: Tue, 9 Nov 2010 07:10:18 +0300 Message-ID: To: FreeBSD Mail Lists Content-Type: text/plain; charset=UTF-8 Subject: Syscons and termcap 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, 09 Nov 2010 04:10:40 -0000 I've compiled -CURRENT kernel with UTF-8 and CONS25 support. ( r214751 ) in xterm emulation mode I have problems with bindings for some keys, such as Home If I start vis(1) and press Home, I always get "^[[H" sequence instead of "^[OH" which is defined in termcap (5) file. I get correct results after switching to cons25. What do I wrong ? Does sc(4) driver in current correctly support xterm-like key bindings? From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 05:42:09 2010 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 B4DB3106566B for ; Tue, 9 Nov 2010 05:42:09 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.67.217]) by mx1.freebsd.org (Postfix) with ESMTP id 78F908FC24 for ; Tue, 9 Nov 2010 05:42:09 +0000 (UTC) Received: by mail.0x20.net (Postfix, from userid 1002) id DC7D539DFE; Tue, 9 Nov 2010 06:26:23 +0100 (CET) Date: Tue, 9 Nov 2010 06:26:23 +0100 From: Lars Engels To: John Baldwin Message-ID: <20101109052623.GS56407@e.0x20.net> References: <201011081714.53637.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mWXp4lmU9bb5aCfX" Content-Disposition: inline In-Reply-To: <201011081714.53637.jhb@freebsd.org> X-Editor: VIM - Vi IMproved 7.2 X-Operation-System: FreeBSD 5.5-RELEASE-p19 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org Subject: Re: Only display ACPI bootmenu key if ACPI is present 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, 09 Nov 2010 05:42:09 -0000 --mWXp4lmU9bb5aCfX Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On Mon, Nov 08, 2010 at 05:14:53PM -0500, John Baldwin wrote: > This patch changes the Forth code for the Beastie menu to only display the > menu option to enable or disable ACPI if the loader detects ACPI. This avoids > displaying a menu item prompting to enable ACPI if the BIOS doesn't actually > include ACPI. Any objections? Good idea! Maybe we should also import PCBSD's patches to the beastie menu? In PCBSD's beastie menu you can toggle some settings like "safe mode", and "ACPI", so the kernel is not loaded as soon as select an option. See http://trac.pcbsd.org/browser/pcbsd/current/system-overlay/boot/beastie.4th Lars --mWXp4lmU9bb5aCfX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkzY238ACgkQKc512sD3afh/sQCgtxLIrpqOx6KU/vz66pDfEYn8 YygAoKNQZ8Hl/TMD5RVRy9J+5bji3CFB =n3Et -----END PGP SIGNATURE----- --mWXp4lmU9bb5aCfX-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 06:40:21 2010 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 2A1C81065672; Tue, 9 Nov 2010 06:40:21 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 0C3FC8FC08; Tue, 9 Nov 2010 06:40:21 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PFhsR-000NRL-VW; Tue, 09 Nov 2010 06:40:20 +0000 Date: Tue, 09 Nov 2010 14:40:18 +0800 Message-ID: From: Randy Bush To: "David O'Brien" In-Reply-To: <20101109025611.GC95515@dragon.NUXI.org> References: <20101108190041.GB82268@dragon.NUXI.org> <20101109025047.GB95515@dragon.NUXI.org> <20101109025611.GC95515@dragon.NUXI.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: FreeBSD current mailing list Subject: Re: groff build failure 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, 09 Nov 2010 06:40:21 -0000 > Please try r215027. worked!!! thank you. randy From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 09:25:55 2010 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 04C871065673; Tue, 9 Nov 2010 09:25:55 +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 11D838FC12; Tue, 9 Nov 2010 09:25:53 +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 LAA18585; Tue, 09 Nov 2010 11:25:51 +0200 (EET) (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 1PFkSc-0007Cd-Vf; Tue, 09 Nov 2010 11:25:50 +0200 Message-ID: <4CD9139D.9060302@freebsd.org> Date: Tue, 09 Nov 2010 11:25:49 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Kostik Belousov References: <4CD3B1D2.30003@icyb.net.ua> <4CD7E401.1010206@freebsd.org> <20101108120403.GC2392@deviant.kiev.zoral.com.ua> In-Reply-To: <20101108120403.GC2392@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: radeon_cp_texture: page fault with non-sleepable locks held 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, 09 Nov 2010 09:25:55 -0000 on 08/11/2010 14:04 Kostik Belousov said the following: > On Mon, Nov 08, 2010 at 01:50:25PM +0200, Andriy Gapon wrote: >> on 05/11/2010 09:27 Andriy Gapon said the following: >>> >>> I use FreeSBD head and KDE 4 with all the bells and whistles enabled. >>> Apparently recent KDE update has enabled even more of them, because I started to >>> have panics with a kernel that has INVARIANTS and WITNESS enabled. >> >> I tried to solve the problem by changing drmdev from mutex to sx: >> http://people.freebsd.org/~avg/drm-sx.diff > I remember that drm lock can be acquired from the interrupt thread, if > the card supports interrupts. Changing it to sx cannot work then, because > interrupt threads cannot sleep. Most likely, you are getting around it > since r600 not yet used interrupts on FreeBSD. > > I think the solution is to drop drm lock around copyin. Kostik, I looked at this some more and now I think that using sx is a step in the right direction. Rationale: 1. it seems that on Linux mutex is a sleepable lock and thus can be safely held across a page fault; and Linux mutex -> FreeBSD sx seems to be a porting technique used for kernel code before[*]. 2. DRM interrupt code uses a different lock - irq_lock, which is locked via DRM_SPINLOCK macro (expands to FreeBSD mutex); apparently even on Linux a sleep-able lock can't be acquired in interrupt handler. I use Linux this and Linux that as a justification, because the DRM code apparently originated with Linux model/idioms in mind, although the original purpose was for the code to be portable. So, what do you think about this aspect? Should you agree with the usage of sx, then the previous question pops back - how to resolve the lock order reversal between drmdev lock and user map lock (which both would be sx). [*] http://www.ukuug.org/events/eurobsdcon2009/papers/dvb_driver_paper.pdf -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 09:48:41 2010 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 44A211065673; Tue, 9 Nov 2010 09:48:41 +0000 (UTC) (envelope-from erob@gthcfoundation.org) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.freebsd.org (Postfix) with ESMTP id 1EC688FC21; Tue, 9 Nov 2010 09:48:40 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from [192.168.0.100] ([74.58.70.113]) by VL-MR-MRZ22.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0LBM00F2N393AD80@VL-MR-MRZ22.ip.videotron.ca>; Tue, 09 Nov 2010 04:48:40 -0500 (EST) Message-id: <4CD91B27.4080602@gthcfoundation.org> Date: Tue, 09 Nov 2010 04:57:59 -0500 From: Etienne Robillard Organization: Green Tea Hackers Club User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.14) Gecko/20101026 Icedove/3.0.9 To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org References: <4CD889C0.6050203@gthcfoundation.org> In-reply-to: <4CD889C0.6050203@gthcfoundation.org> Cc: Subject: Re: Error: stack overflow on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: erob@gthcfoundation.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 09:48:41 -0000 On 08/11/10 06:37 PM, Etienne Robillard wrote: > Hi, why is this message happening with 8.1 and sometimes CURRENT ? > > I tried recompiling the bootloader but the error still happens, > forcing user to hit Enter to enter manual boot. > > Any takes ? :) > > Many thanks, > > Etienne > _______________________________________________ > 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" forgot telling this is happening on amd64 architecture! I don't think its happens on i386 machines types! -- Etienne Robillard Company: Green Tea Hackers Club Occupation: Software Developer E-mail: erob@gthcfoundation.org Work phone: +1 514-962-7703 Website (Company): https://www.gthc.org/ Website (Blog): https://www.gthc.org/blog/ PGP public key fingerprint: F2A9 32EA 8E7C 460F 1728 A1A7 649C 7F17 A086 DDEC During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 10:03:21 2010 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 3ECAC1065672 for ; Tue, 9 Nov 2010 10:03:21 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (unknown [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id CDDC68FC15 for ; Tue, 9 Nov 2010 10:03:20 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id B33602A28CEA; Tue, 9 Nov 2010 11:03:19 +0100 (CET) Date: Tue, 9 Nov 2010 11:03:19 +0100 From: Ed Schouten To: Eir Nym Message-ID: <20101109100319.GV2054@hoeg.nl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vXO+wElmrbrjQnTC" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Mail Lists Subject: Re: Syscons and termcap 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, 09 Nov 2010 10:03:21 -0000 --vXO+wElmrbrjQnTC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Eir, * Eir Nym , 20101109 05:10: > I've compiled -CURRENT kernel with UTF-8 and CONS25 support. ( r214751 ) >=20 > in xterm emulation mode I have problems with bindings for some keys, > such as Home > If I start vis(1) and press Home, I always get "^[[H" sequence instead > of "^[OH" which is defined in termcap (5) file. >=20 > I get correct results after switching to cons25. >=20 > What do I wrong ? Does sc(4) driver in current correctly support > xterm-like key bindings? Yes, but not only must you set TERM=3Dxterm, you must also remove TEKEN_CONS25 from your kernel configuration or run vidcontrol -T xterm on that specific window. There is almost no reason why anyone would want to use the TEKEN_CONS25 option. Depending on whether the terminal is switched to cursor keys mode, it will return ^[[H or ^[OH. See /sys/teken/teken.c, teken_get_sequence(). Greetings, --=20 Ed Schouten WWW: http://80386.nl/ --vXO+wElmrbrjQnTC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkzZHGcACgkQ52SDGA2eCwULIgCbBETza1mFAUKISh141T9f+bjt 2bcAnA3jJ0ZwqcabordSZZGJ/tTPdZGj =1yLw -----END PGP SIGNATURE----- --vXO+wElmrbrjQnTC-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 11:46:12 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 2E706106566C; Tue, 9 Nov 2010 11:46:12 +0000 (UTC) Date: Tue, 9 Nov 2010 11:46:12 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20101109114612.GA58585@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline Subject: kldunload(8) returns 0, although it fail 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, 09 Nov 2010 11:46:12 -0000 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi there, i posted this message on freebsd-questions@, but nobody could help me with it. to me this looks like a bug, so i assume posting it again here on freebsd-current@ might be better. please keep in mind that the issue here is not the fact that the second attempt to unload sound.ko/netgraph.ko fails. it *should* fail, because both modules have dependencies. however it should fail with the first attempt. right now kldunloadf() returns zero, whereas it should actually return EBUSY (just like the second attempt). i've attached two kdump outputs: one for the first 'kldunload' attempt and one for the second. as you can see the problem is that for some reason kldunloadf() returns zero, although it couldn't unload the module. cheers. alex ----- Forwarded message from Alexander Best ----- Date: Fri, 5 Nov 2010 01:15:24 +0000 From: Alexander Best To: freebsd-questions@freebsd.org Subject: Re: kldunload(8) returns 0, although it fail On Wed Nov 3 10, Alexander Best wrote: > hi there, > > is this a known issue with kldunload(8)? this is also very interesting: ***beginn*** otaku% kldstat -v|grep netgraph 7 3 0xffffffff80bfa000 15e68 netgraph.ko (/boot/kernel/netgraph.ko) 6 netgraph otaku% sudo kldunload netgraph otaku% echo $? 0 otaku% kldstat -v|grep netgraph 7 2 0xffffffff80bfa000 15e68 netgraph.ko (/boot/kernel/netgraph.ko) 6 netgraph otaku% ***end*** there seems to be a logical error in the ref counting code. cheers. alex > > ***beginn*** > otaku% kldunload sound > otaku% echo $? > 0 > otaku% kldstat > Id Refs Address Size Name > 1 35 0xffffffff80100000 a2da40 kernel > 2 1 0xffffffff80b2e000 295e8 snd_hda.ko > 3 1 0xffffffff80b58000 85110 sound.ko > 4 1 0xffffffff80bde000 da4bb8 nvidia.ko > 5 4 0xffffffff81983000 418e0 linux.ko > 6 1 0xffffffff819c5000 80e8 ng_ubt.ko > 7 2 0xffffffff819ce000 fa78 ng_hci.ko > 8 2 0xffffffff819de000 2bd0 ng_bluetooth.ko > 9 3 0xffffffff819e1000 15e68 netgraph.ko > 10 1 0xffffffff81c12000 3edb linprocfs.ko > 11 3 0xffffffff81c16000 4698 pseudofs.ko > 12 1 0xffffffff81c1b000 31b3 procfs.ko > 13 1 0xffffffff81c1f000 a37 linsysfs.ko > otaku% kldunload sound > kldunload: attempt to unload file that was loaded by the kernel > kldunload: can't unload file: Device busy > otaku% echo $? > 1 > otaku% > ***end*** > > cheers. > alex > > -- > a13x -- a13x ----- End forwarded message ----- -- a13x --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=kldunload-1st-try 1765 ktrace RET ktrace 0 1765 ktrace CALL execve(0x7fffffffe580,0x7fffffffeb00,0x7fffffffeb18) 1765 ktrace NAMI "/sbin/kldunload" 1765 ktrace NAMI "/libexec/ld-elf.so.1" 1765 kldunload RET execve 0 1765 kldunload CALL mmap(0,0x8000,0x3,0x1002,0xffffffff,0) 1765 kldunload RET mmap 34365239296/0x80053f000 1765 kldunload CALL issetugid 1765 kldunload RET issetugid 0 1765 kldunload CALL open(0x80053a8b2,0,0x1b6) 1765 kldunload NAMI "/etc/libmap.conf" 1765 kldunload RET open 3 1765 kldunload CALL fstat(0x3,0x7fffffffdc10) 1765 kldunload STRU struct stat {dev=98, ino=5841236, mode=-rw-r--r-- , nlink=1, uid=0, gid=0, rdev=23396840, atime=1289300105, stime=1285331572, ctime=1285331572, birthtime=1268953179, size=235, blksize=16384, blocks=4, flags=0x0 } 1765 kldunload RET fstat 0 1765 kldunload CALL read(0x3,0x800542000,0x4000) 1765 kldunload GIO fd 3 read 235 bytes "#libgcc_s.so.1 gcc46/libgcc_s.so.1 #libgomp.so.1 gcc46/libgomp.so.1 #libssp.so.0 gcc46/libssp.so.0 #libstdc++.so.6 gcc46/libstdc++.so.6 #libz.so.5 libz.so.6 #libmd.so.5 libmd.so.1.0 #libmd.so.5 libcrypto.so #libmd.so.5 libmd-test.so.5 " 1765 kldunload RET read 235/0xeb 1765 kldunload CALL read(0x3,0x800542000,0x4000) 1765 kldunload GIO fd 3 read 0 bytes "" 1765 kldunload RET read 0 1765 kldunload CALL close(0x3) 1765 kldunload RET close 0 1765 kldunload CALL open(0x800539a49,0,0x2f) 1765 kldunload NAMI "/var/run/ld-elf.so.hints" 1765 kldunload RET open 3 1765 kldunload CALL read(0x3,0x7fffffffe220,0x80) 1765 kldunload GIO fd 3 read 128 bytes 0x0000 4568 6e74 0100 0000 8000 0000 db00 0000 0000 0000 da00 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 |Ehnt....................................................................| 0x0048 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 |........................................................| 1765 kldunload RET read 128/0x80 1765 kldunload CALL mmap(0,0x9000,0x3,0x1002,0xffffffff,0) 1765 kldunload RET mmap 34365272064/0x800547000 1765 kldunload CALL lseek(0x3,0x80,SEEK_SET) 1765 kldunload RET lseek 128/0x80 1765 kldunload CALL read(0x3,0x800548000,0xdb) 1765 kldunload GIO fd 3 read 219 bytes "/lib:/usr/lib:/usr/lib/compat:/usr/local/lib:/usr/local/lib/compat/pkg:/usr/local/lib/compat:/usr/local/lib/gcc46:/usr/local/lib/gegl-0.1:/usr/local/lib/graphviz:/usr/local/lib/nss:/usr/local/lib/pth:/usr/local/lib/zsh\0" 1765 kldunload RET read 219/0xdb 1765 kldunload CALL close(0x3) 1765 kldunload RET close 0 1765 kldunload CALL access(0x800549000,0) 1765 kldunload NAMI "/lib/libc.so.7" 1765 kldunload RET access 0 1765 kldunload CALL open(0x800540040,0,0x648440) 1765 kldunload NAMI "/lib/libc.so.7" 1765 kldunload RET open 3 1765 kldunload CALL fstat(0x3,0x7fffffffe4a0) 1765 kldunload STRU struct stat {dev=98, ino=3933187, mode=-r--r--r-- , nlink=1, uid=0, gid=0, rdev=17165176, atime=1289300105, stime=1285692928, ctime=1285692928, birthtime=1285692926, size=5139862, blksize=16384, blocks=10080, flags=0x20000 } 1765 kldunload RET fstat 0 1765 kldunload CALL pread(0x3,0x800647420,0x1000,0) 1765 kldunload GIO fd 3 read 4096 bytes 0x0000 7f45 4c46 0201 0109 0000 0000 0000 0000 0300 3e00 0100 0000 c0bc 0200 0000 0000 4000 0000 0000 0000 c087 4c00 0000 0000 0000 0000 4000 3800 0500 4000 2d00 2a00 0100 0000 0500 0000 |.ELF..............>.............@.........L.........@.8...@.-.*.........| 0x0048 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 20f2 1200 0000 0000 20f2 1200 0000 0000 0000 1000 0000 0000 0100 0000 0600 0000 20f2 1200 0000 0000 20f2 2200 0000 0000 |........................ ....... ....................... ....... .".....| 0x0090 20f2 2200 0000 0000 80c3 0100 0000 0000 3073 0300 0000 0000 0000 1000 0000 0000 0200 0000 0600 0000 0094 1400 0000 0000 0094 2400 0000 0000 0094 2400 0000 0000 9001 0000 0000 0000 | .".............0s................................$.......$.............| 0x00d8 9001 0000 0000 0000 0800 0000 0000 0000 0700 0000 0400 0000 905e 1300 0000 0000 905e 2300 0000 0000 905e 2300 0000 0000 0000 0000 0000 0000 1100 0000 0000 0000 0800 0000 0000 0000 |.........................^.......^#......^#.............................| 0x0120 50e5 7464 0400 0000 cca3 1200 0000 0000 cca3 1200 0000 0000 cca3 1200 0000 0000 544e 0000 0000 0000 544e 0000 0000 0000 0400 0000 0000 0000 0508 0000 a20a 0000 4905 0000 0000 0000 |P.td............................TN......TN......................I.......| 0x0168 0000 0000 0000 0000 3107 0000 6100 0000 0402 0000 c509 0000 f303 0000 0000 0000 0808 0000 2608 0000 9206 0000 3305 0000 8601 0000 1f0a 0000 bf08 0000 0000 0000 ef02 0000 3e09 0000 |........1...a.......................&.......3.......................>...| 0x01b0 d505 0000 a105 0000 d100 0000 2f04 0000 7308 0000 8d0a 0000 980a 0000 a904 0000 0000 0000 0000 0000 2b0a 0000 0000 0000 240a 0000 d208 0000 650a 0000 640a 0000 a609 0000 e900 0000 |............/...s.......................+.......$.......e...d...........| 0x01f8 4b00 0000 8204 0000 6906 0000 0000 0000 0c0a 0000 c908 0000 6e06 0000 0000 0000 d008 0000 e302 0000 8809 0000 800a 0000 db02 0000 3809 0000 6104 0000 7407 0000 0000 0000 1c09 0000 |K.......i...............n...........................8...a...t...........| 0x0240 ab08 0000 0000 0000 7903 0000 0000 0000 0000 0000 d508 0000 ec06 0000 0000 0000 e600 0000 4f0a 0000 f804 0000 b104 0000 8c03 0000 0601 0000 6d0a 0000 6803 0000 6c07 0000 0000 0000 |........y...........................O...................m...h...l.......| 0x0288 0000 0000 3d09 0000 0000 0000 c008 0000 0000 0000 a106 0000 0000 0000 5509 0000 0000 0000 1308 0000 0000 0000 5006 0000 8507 0000 0000 0000 8106 0000 5a08 0000 1e02 0000 0000 0000 |....=.......................U...............P...............Z...........| 0x02d0 0c08 0000 0000 0000 0906 0000 9309 0000 3c08 0000 0000 0000 b406 0000 f403 0000 0000 0000 0000 0000 2a08 0000 3c02 0000 0000 0000 c906 0000 0000 0000 0000 0000 9904 0000 ba07 0000 |................<.......................*...<...........................| 0x0318 c501 0000 9607 0000 e009 0000 f902 0000 e904 0000 9805 0000 0000 0000 1309 0000 e609 0000 f209 0000 2c04 0000 9a07 0000 0000 0000 ab09 0000 c709 0000 5801 0000 0408 0000 0000 0000 |........................................,...................X...........| 0x0360 5b0a 0000 e401 0000 0407 0000 0000 0000 4209 0000 fa08 0000 1a07 0000 ac07 0000 0000 0000 1f09 0000 e207 0000 ea04 0000 9301 0000 0000 0000 8c09 0000 6b07 0000 bf07 0000 d303 0000 |[...............B...........................................k...........| 0x03a8 ac09 0000 0000 0000 0000 0000 e608 0000 4f07 0000 0000 0000 2e02 0000 7800 0000 9501 0000 5705 0000 0000 0000 f500 0000 be01 0000 b505 0000 0000 0000 3302 0000 0000 0000 610a 0000 |................O...........x.......W.......................3.......a...| 0x03f0 0000 0000 0000 0000 8509 0000 140a 0000 7b0a 0000 4302 0000 0000 0000 0000 0000 e200 0000 8c0a 0000 9208 0000 4c05 0000 2d07 0000 0000 0000 2106 0000 c608 0000 0000 0000 2402 0000 |................{...C.......................L...-.......!...........$...| 0x0438 0508 0000 4c08 0000 0000 0000 dc06 0000 6508 0000 b001 0000 0000 0000 2408 0000 7e02 0000 0000 0000 2208 0000 4303 0000 4c04 0000 8404 0000 b307 0000 0000 0000 0000 0000 7e07 0000 |....L...........e...........$...~......."...C...L...................~...| 0x0480 0000 0000 0000 0000 8503 0000 4706 0000 5e05 0000 2305 0000 0000 0000 4208 0000 0000 0000 b805 0000 4600 0000 7605 0000 3b06 0000 4c09 0000 7d05 0000 8606 0000 0000 0000 bc05 0000 |............G...^...#.......B...........F...v...;...L...}...............| 0x04c8 0000 0000 0000 0000 5908 0000 7b07 0000 c503 0000 7707 0000 0000 0000 250a 0000 e006 0000 0000 0000 1406 0000 0a06 0000 0000 0000 0000 0000 0000 0000 a902 0000 0c09 0000 0000 0000 |........Y...{.......w.......%...........................................| 0x0510 6108 0000 9303 0000 ab06 0000 0000 0000 2509 0000 a201 0000 db06 0000 0000 0000 790a 0000 0000 0000 8a09 0000 d202 0000 0000 0000 8f06 0000 0000 0000 0000 0000 0000 0000 6b03 0000 |a...............%...............y...................................k...| 0x0558 db04 0000 0000 0000 8a06 0000 7209 0000 5506 0000 c809 0000 0000 0000 ec08 0000 fe07 0000 9008 0000 ca08 0000 5400 0000 3101 0000 7503 0000 0000 0000 0000 0000 0000 0000 0000 0000 |............r...U...........................T...1...u...................| 0x05a0 4305 0000 4100 0000 0000 0000 f609 0000 0000 0000 7e0a 0000 0000 0000 4402 0000 e408 0000 9a06 0000 0000 0000 cc08 0000 0000 0000 5209 0000 1407 0000 a604 0000 ba02 0000 880a 0000 |C...A...............~.......D.......................R...................| 0x05e8 7803 0000 a804 0000 0000 0000 b504 0000 e103 0000 0000 0000 8c05 0000 3909 0000 5a07 0000 e906 0000 0000 0000 0000 0000 af05 0000 6a04 0000 7807 0000 0000 0000 0000 0000 fb09 0000 |x...........................9...Z...................j...x...............| 0x0630 0000 0000 c007 0000 5000 0000 8107 0000 0000 0000 0000 0000 8205 0000 6608 0000 3808 0000 0000 0000 3e0a 0000 3e03 0000 ba05 0000 1f05 0000 190a 0000 cc06 0000 4806 0000 0000 0000 |........P...................f...8.......>...>...................H.......| 0x0678 0000 0000 f308 0000 0000 0000 5b04 0000 3b09 0000 4602 0000 a204 0000 b503 0000 0000 0000 6b08 0000 0000 0000 0000 0000 0000 0000 5007 0000 f509 0000 5800 0000 6e03 0000 0000 0000 |............[...;...F...............k...............P.......X...n.......| 0x06c0 0000 0000 2309 0000 0000 0000 2508 0000 7408 0000 cd08 0000 8004 0000 b008 0000 0000 0000 0000 0000 d405 0000 200a 0000 8804 0000 f809 0000 c405 0000 5205 0000 0000 0000 5005 0000 |....#.......%...t........................... ...............R.......P...| 0x0708 5703 0000 f407 0000 2803 0000 d109 0000 5806 0000 0000 0000 0000 0000 0000 0000 0000 0000 b803 0000 7300 0000 0000 0000 0000 0000 aa05 0000 4109 0000 7709 0000 0000 0000 0703 0000 |W.......(.......X.......................s...............A...w...........| 0x0750 0000 0000 0000 0000 1008 0000 a506 0000 6403 0000 a004 0000 2f0a 0000 0000 0000 570a 0000 8805 0000 2909 0000 bd06 0000 0a02 0000 4d0a 0000 5004 0000 0000 0000 0000 0000 0000 0000 |................d......./.......W.......)...........M...P...............| 0x0798 0000 0000 0000 0000 0000 0000 5401 0000 0000 0000 cd05 0000 4500 0000 0901 0000 7f09 0000 b002 0000 ef06 0000 0000 0000 c109 0000 4e02 0000 d206 0000 cb01 0000 bd09 0000 c407 0000 |............T...........E...........................N...................| 0x07e0 cf08 0000 350a 0000 b507 0000 0000 0000 3602 0000 0d0a 0000 6106 0000 cb04 0000 b903 0000 0409 0000 df02 0000 6407 0000 0000 0000 3002 0000 f309 0000 a300 0000 5906 0000 150a 0000 |....5...........6.......a...................d.......0...........Y.......| 0x0828 0304 0000 3f08 0000 0000 0000 af06 0000 0000 0000 0000 0000 7a03 0000 0307 0000 1a0a 0000 2504 0000 0000 0000 6804 0000 0000 0000 a307 0000 8709 0000 fa04 0000 0207 0000 c300 0000 |....?...................z...........%.......h...........................| 0x0870 6901 0000 d603 0000 7609 0000 ab05 0000 7809 0000 300a 0000 0000 0000 0608 0000 0000 0000 0000 0000 0000 0000 0000 0000 2206 0000 6701 0000 2e08 0000 7a06 0000 1001 0000 4708 0000 |i.......v.......x...0..........................."...g.......z.......G...| 0x08b8 3208 0000 f602 0000 0000 0000 0000 0000 b906 0000 0000 0000 1b0a 0000 e203 0000 0902 0000 4b07 0000 0000 0000 3409 0000 b206 0000 aa09 0000 0000 0000 ea08 0000 4e0a 0000 2e07 0000 |2...................................K.......4...................N.......| 0x0900 1509 0000 6208 0000 9003 0000 b009 0000 f402 0000 4e03 0000 d306 0000 e003 0000 2a0a 0000 7504 0000 7303 0000 220a 0000 9909 0000 3c06 0000 0000 0000 7704 0000 440a 0000 e905 0000 |....b...............N...........*...u...s...".......<.......w...D.......| 0x0948 0000 0000 0f04 0000 7c0a 0000 f207 0000 0000 0000 8d08 0000 b308 0000 710a 0000 a406 0000 0000 0000 7505 0000 4704 0000 6206 0000 0000 0000 7907 0000 b609 0000 cf09 0000 0306 0000 |........|...................q...........u...G...b.......y...............| 0x0990 0000 0000 ba08 0000 0000 0000 7c06 0000 0000 0000 0000 0000 1d03 0000 0000 0000 0000 0000 4007 0000 9f07 0000 0000 0000 7109 0000 9808 0000 0b08 0000 d007 0000 d309 0000 0000 0000 |............|.......................@...........q.......................| 0x09d8 6b04 0000 e603 0000 8b02 0000 d701 0000 a809 0000 7204 0000 6602 0000 0008 0000 480a 0000 3b0a 0000 f900 0000 0000 0000 5409 0000 2501 0000 8f09 0000 7104 0000 0000 0000 6103 0000 |k...................r...f.......H...;...........T...%.......q.......a...| 0x0a20 5407 0000 0000 0000 8e08 0000 2c08 0000 9504 0000 c506 0000 5708 0000 a508 0000 0000 0000 7d08 0000 1101 0000 1109 0000 0000 0000 0000 0000 6a08 0000 f001 0000 c205 0000 4900 0000 |T...........,...........W...........}...................j...........I...| 0x0a68 0000 0000 a10a 0000 0000 0000 2307 0000 c003 0000 0000 0000 7d0a 0000 f406 0000 6501 0000 d507 0000 a909 0000 f200 0000 8408 0000 0000 0000 b003 0000 b908 0000 2e00 0000 0003 0000 |............#...........}.......e.......................................| 0x0ab0 0000 0000 5c06 0000 af00 0000 cd03 0000 4e01 0000 0000 0000 2b08 0000 7a09 0000 510a 0000 0000 0000 8001 0000 0000 0000 cd09 0000 cc03 0000 0000 0000 1104 0000 540a 0000 4400 0000 |....\...........N.......+...z...Q...............................T...D...| 0x0af8 ba06 0000 0000 0000 7105 0000 900a 0000 d305 0000 0000 0000 cd04 0000 2a07 0000 e500 0000 8c07 0000 2107 0000 630a 0000 4a0a 0000 0000 0000 7f08 0000 e308 0000 3a0a 0000 be07 0000 |........q...................*...........!...c...J...............:.......| 0x0b40 4b04 0000 4009 0000 0000 0000 c200 0000 0000 0000 be08 0000 a705 0000 0000 0000 6909 0000 a309 0000 0000 0000 aa07 0000 4609 0000 ad01 0000 0000 0000 f100 0000 5909 0000 0709 0000 |K...@...........................i...............F...............Y.......| 0x0b88 bc06 0000 740a 0000 0000 0000 2101 0000 0000 0000 e107 0000 be00 0000 b105 0000 4304 0000 0000 0000 0000 0000 0000 0000 a706 0000 1005 0000 9407 0000 0000 0000 7309 0000 0000 0000 |....t.......!...................C...............................s.......| 0x0bd0 ae09 0000 e400 0000 0000 0000 0000 0000 470a 0000 3d05 0000 a802 0000 a501 0000 0000 0000 db09 0000 820a 0000 0000 0000 3705 0000 0000 0000 0000 0000 8b05 0000 0000 0000 7b00 0000 |................G...=...........................7...................{...| 0x0c18 bd08 0000 0000 0000 4b0a 0000 f603 0000 3e04 0000 2b02 0000 c207 0000 bd00 0000 8607 0000 e703 0000 080a 0000 0000 0000 1c08 0000 8b08 0000 0000 0000 d808 0000 fa06 0000 de09 0000 |........K.......>...+...................................................| 0x0c60 0000 0000 bc07 0000 270a 0000 0000 0000 5900 0000 d209 0000 aa00 0000 1409 0000 0009 0000 0000 0000 0000 0000 e000 0000 7102 0000 c208 0000 1206 0000 0000 0000 490a 0000 cc07 0000 |........'.......Y...............................q...............I.......| 0x0ca8 0000 0000 8b09 0000 0f05 0000 0000 0000 b407 0000 0000 0000 0000 0000 e105 0000 0707 0000 9a00 0000 0000 0000 6404 0000 0000 0000 0000 0000 0000 0000 dd01 0000 0000 0000 d107 0000 |............................................d...........................| 0x0cf0 0000 0000 1707 0000 0000 0000 0005 0000 e008 0000 a908 0000 0000 0000 1306 0000 9508 0000 8d01 0000 0000 0000 0000 0000 e709 0000 5609 0000 3608 0000 0000 0000 f801 0000 ff03 0000 |....................................................V...6...............| 0x0d38 8208 0000 ad02 0000 0000 0000 ed09 0000 fd03 0000 7507 0000 a209 0000 0000 0000 8200 0000 2603 0000 400a 0000 7509 0000 0000 0000 4a00 0000 0000 0000 c204 0000 0000 0000 d106 0000 |....................u...............&...@...u.......J...................| 0x0d80 6d07 0000 0000 0000 a102 0000 0000 0000 9302 0000 0000 0000 0000 0000 0000 0000 c708 0000 2701 0000 4409 0000 0000 0000 ca07 0000 6500 0000 0000 0000 7d07 0000 3d06 0000 4e08 0000 |m...................................'...D...........e.......}...=...N...| 0x0dc8 6209 0000 3a06 0000 0000 0000 4703 0000 ed00 0000 da03 0000 0000 0000 0000 0000 3f05 0000 0000 0000 530a 0000 6607 0000 6808 0000 fe05 0000 0000 0000 4d09 0000 e605 0000 3209 0000 |b...:.......G...................?.......S...f...h...........M.......2...| 0x0e10 0000 0000 ff08 0000 0000 0000 b802 0000 8906 0000 0000 0000 1b07 0000 4309 0000 8909 0000 db01 0000 3009 0000 a00a 0000 f009 0000 4408 0000 9b08 0000 d102 0000 0000 0000 0000 0000 |............................C...........0...........D...................| 0x0e58 8b07 0000 ff09 0000 0000 0000 2404 0000 6009 0000 3204 0000 230a 0000 0000 0000 0000 0000 ce04 0000 a005 0000 7202 0000 5d0a 0000 f101 0000 7107 0000 6606 0000 7c09 0000 7409 0000 |............$...`...2...#...................r...].......q...f...|...t...| 0x0ea0 fc04 0000 b901 0000 1105 0000 0000 0000 0000 0000 3b07 0000 0000 0000 6e00 0000 8400 0000 0000 0000 3300 0000 6000 0000 1f08 0000 ef01 0000 6207 0000 ea00 0000 de06 0000 0000 0000 |....................;.......n...........3...`...........b...............| 0x0ee8 5204 0000 0e08 0000 7e09 0000 c209 0000 0a07 0000 4105 0000 5a0a 0000 0000 0000 c609 0000 fd05 0000 6e08 0000 fb06 0000 0000 0000 e007 0000 0000 0000 e301 0000 0000 0000 0000 0000 |R.......~...........A...Z...............n...............................| 0x0f30 1a03 0000 0000 0000 e506 0000 7600 0000 6609 0000 ec07 0000 d705 0000 1504 0000 0000 0000 0000 0000 0000 0000 9307 0000 0209 0000 4103 0000 0000 0000 e503 0000 0000 0000 0000 0000 |............v...f...................................A...................| 0x0f78 8902 0000 6b09 0000 9d06 0000 0000 0000 8508 0000 210a 0000 da08 0000 0000 0000 1009 0000 c507 0000 0000 0000 520a 0000 0000 0000 e803 0000 8505 0000 9606 0000 e504 0000 bf09 0000 |....k...............!.......................R...........................| 0x0fc0 9c07 0000 730a 0000 9408 0000 3908 0000 0406 0000 0000 0000 0000 0000 f307 0000 9200 0000 0000 0000 5707 0000 e802 0000 7305 0000 8008 0000 0a0a 0000 0000 0000 |....s.......9...........................W.......s...............| 1765 kldunload RET pread 4096/0x1000 1765 kldunload CALL mmap(0,0x267000,0,0x21002,0xffffffff,0) 1765 kldunload RET mmap 34366377984/0x800655000 1765 kldunload CALL mmap(0x800655000,0x130000,0x5,0x20012,0x3,0) 1765 kldunload RET mmap 34366377984/0x800655000 1765 kldunload CALL mmap(0x800884000,0x1d000,0x3,0x12,0x3,0x12f000) 1765 kldunload RET mmap 34368667648/0x800884000 1765 kldunload CALL mprotect(0x8008a1000,0x1b000,0x3) 1765 kldunload RET mprotect 0 1765 kldunload CALL close(0x3) 1765 kldunload RET close 0 1765 kldunload CALL sysarch(0x81,0x7fffffffe580) 1765 kldunload RET sysarch 0 1765 kldunload CALL munmap(0x80054c000,0x4000) 1765 kldunload RET munmap 0 1765 kldunload CALL mmap(0,0x19000,0x3,0x1002,0xffffffff,0) 1765 kldunload RET mmap 34365292544/0x80054c000 1765 kldunload CALL sigprocmask(SIG_BLOCK,0x800647320,0x7fffffffe550) 1765 kldunload RET sigprocmask 0 1765 kldunload CALL sigprocmask(SIG_SETMASK,0x800647330,0) 1765 kldunload RET sigprocmask 0 1765 kldunload CALL sigprocmask(SIG_BLOCK,0x800647320,0x7fffffffe520) 1765 kldunload RET sigprocmask 0 1765 kldunload CALL sigprocmask(SIG_SETMASK,0x800647330,0) 1765 kldunload RET sigprocmask 0 1765 kldunload CALL kldfind(0x7fffffffed32) 1765 kldunload RET kldfind 3 1765 kldunload CALL kldunloadf(0x3,LINKER_UNLOAD_NORMAL) 1765 kldunload RET kldunloadf 0 1765 kldunload CALL sigprocmask(SIG_BLOCK,0x800647320,0x7fffffffe9a0) 1765 kldunload RET sigprocmask 0 1765 kldunload CALL sigprocmask(SIG_SETMASK,0x800647330,0) 1765 kldunload RET sigprocmask 0 1765 kldunload CALL sigprocmask(SIG_BLOCK,0x800647320,0x7fffffffe950) 1765 kldunload RET sigprocmask 0 1765 kldunload CALL sigprocmask(SIG_SETMASK,0x800647330,0) 1765 kldunload RET sigprocmask 0 1765 kldunload CALL exit(0) --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=kldunload-2nd-try 1775 ktrace RET ktrace 0 1775 ktrace CALL execve(0x7fffffffe580,0x7fffffffeb00,0x7fffffffeb18) 1775 ktrace NAMI "/sbin/kldunload" 1775 ktrace NAMI "/libexec/ld-elf.so.1" 1775 kldunload RET execve 0 1775 kldunload CALL mmap(0,0x8000,0x3,0x1002,0xffffffff,0) 1775 kldunload RET mmap 34365239296/0x80053f000 1775 kldunload CALL issetugid 1775 kldunload RET issetugid 0 1775 kldunload CALL open(0x80053a8b2,0,0x1b6) 1775 kldunload NAMI "/etc/libmap.conf" 1775 kldunload RET open 3 1775 kldunload CALL fstat(0x3,0x7fffffffdc10) 1775 kldunload STRU struct stat {dev=98, ino=5841236, mode=-rw-r--r-- , nlink=1, uid=0, gid=0, rdev=23396840, atime=1289300105, stime=1285331572, ctime=1285331572, birthtime=1268953179, size=235, blksize=16384, blocks=4, flags=0x0 } 1775 kldunload RET fstat 0 1775 kldunload CALL read(0x3,0x800542000,0x4000) 1775 kldunload GIO fd 3 read 235 bytes "#libgcc_s.so.1 gcc46/libgcc_s.so.1 #libgomp.so.1 gcc46/libgomp.so.1 #libssp.so.0 gcc46/libssp.so.0 #libstdc++.so.6 gcc46/libstdc++.so.6 #libz.so.5 libz.so.6 #libmd.so.5 libmd.so.1.0 #libmd.so.5 libcrypto.so #libmd.so.5 libmd-test.so.5 " 1775 kldunload RET read 235/0xeb 1775 kldunload CALL read(0x3,0x800542000,0x4000) 1775 kldunload GIO fd 3 read 0 bytes "" 1775 kldunload RET read 0 1775 kldunload CALL close(0x3) 1775 kldunload RET close 0 1775 kldunload CALL open(0x800539a49,0,0x2f) 1775 kldunload NAMI "/var/run/ld-elf.so.hints" 1775 kldunload RET open 3 1775 kldunload CALL read(0x3,0x7fffffffe220,0x80) 1775 kldunload GIO fd 3 read 128 bytes 0x0000 4568 6e74 0100 0000 8000 0000 db00 0000 0000 0000 da00 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 |Ehnt....................................................................| 0x0048 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 |........................................................| 1775 kldunload RET read 128/0x80 1775 kldunload CALL mmap(0,0x9000,0x3,0x1002,0xffffffff,0) 1775 kldunload RET mmap 34365272064/0x800547000 1775 kldunload CALL lseek(0x3,0x80,SEEK_SET) 1775 kldunload RET lseek 128/0x80 1775 kldunload CALL read(0x3,0x800548000,0xdb) 1775 kldunload GIO fd 3 read 219 bytes "/lib:/usr/lib:/usr/lib/compat:/usr/local/lib:/usr/local/lib/compat/pkg:/usr/local/lib/compat:/usr/local/lib/gcc46:/usr/local/lib/gegl-0.1:/usr/local/lib/graphviz:/usr/local/lib/nss:/usr/local/lib/pth:/usr/local/lib/zsh\0" 1775 kldunload RET read 219/0xdb 1775 kldunload CALL close(0x3) 1775 kldunload RET close 0 1775 kldunload CALL access(0x800549000,0) 1775 kldunload NAMI "/lib/libc.so.7" 1775 kldunload RET access 0 1775 kldunload CALL open(0x800540040,0,0x648440) 1775 kldunload NAMI "/lib/libc.so.7" 1775 kldunload RET open 3 1775 kldunload CALL fstat(0x3,0x7fffffffe4a0) 1775 kldunload STRU struct stat {dev=98, ino=3933187, mode=-r--r--r-- , nlink=1, uid=0, gid=0, rdev=17165176, atime=1289300105, stime=1285692928, ctime=1285692928, birthtime=1285692926, size=5139862, blksize=16384, blocks=10080, flags=0x20000 } 1775 kldunload RET fstat 0 1775 kldunload CALL pread(0x3,0x800647420,0x1000,0) 1775 kldunload GIO fd 3 read 4096 bytes 0x0000 7f45 4c46 0201 0109 0000 0000 0000 0000 0300 3e00 0100 0000 c0bc 0200 0000 0000 4000 0000 0000 0000 c087 4c00 0000 0000 0000 0000 4000 3800 0500 4000 2d00 2a00 0100 0000 0500 0000 |.ELF..............>.............@.........L.........@.8...@.-.*.........| 0x0048 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 20f2 1200 0000 0000 20f2 1200 0000 0000 0000 1000 0000 0000 0100 0000 0600 0000 20f2 1200 0000 0000 20f2 2200 0000 0000 |........................ ....... ....................... ....... .".....| 0x0090 20f2 2200 0000 0000 80c3 0100 0000 0000 3073 0300 0000 0000 0000 1000 0000 0000 0200 0000 0600 0000 0094 1400 0000 0000 0094 2400 0000 0000 0094 2400 0000 0000 9001 0000 0000 0000 | .".............0s................................$.......$.............| 0x00d8 9001 0000 0000 0000 0800 0000 0000 0000 0700 0000 0400 0000 905e 1300 0000 0000 905e 2300 0000 0000 905e 2300 0000 0000 0000 0000 0000 0000 1100 0000 0000 0000 0800 0000 0000 0000 |.........................^.......^#......^#.............................| 0x0120 50e5 7464 0400 0000 cca3 1200 0000 0000 cca3 1200 0000 0000 cca3 1200 0000 0000 544e 0000 0000 0000 544e 0000 0000 0000 0400 0000 0000 0000 0508 0000 a20a 0000 4905 0000 0000 0000 |P.td............................TN......TN......................I.......| 0x0168 0000 0000 0000 0000 3107 0000 6100 0000 0402 0000 c509 0000 f303 0000 0000 0000 0808 0000 2608 0000 9206 0000 3305 0000 8601 0000 1f0a 0000 bf08 0000 0000 0000 ef02 0000 3e09 0000 |........1...a.......................&.......3.......................>...| 0x01b0 d505 0000 a105 0000 d100 0000 2f04 0000 7308 0000 8d0a 0000 980a 0000 a904 0000 0000 0000 0000 0000 2b0a 0000 0000 0000 240a 0000 d208 0000 650a 0000 640a 0000 a609 0000 e900 0000 |............/...s.......................+.......$.......e...d...........| 0x01f8 4b00 0000 8204 0000 6906 0000 0000 0000 0c0a 0000 c908 0000 6e06 0000 0000 0000 d008 0000 e302 0000 8809 0000 800a 0000 db02 0000 3809 0000 6104 0000 7407 0000 0000 0000 1c09 0000 |K.......i...............n...........................8...a...t...........| 0x0240 ab08 0000 0000 0000 7903 0000 0000 0000 0000 0000 d508 0000 ec06 0000 0000 0000 e600 0000 4f0a 0000 f804 0000 b104 0000 8c03 0000 0601 0000 6d0a 0000 6803 0000 6c07 0000 0000 0000 |........y...........................O...................m...h...l.......| 0x0288 0000 0000 3d09 0000 0000 0000 c008 0000 0000 0000 a106 0000 0000 0000 5509 0000 0000 0000 1308 0000 0000 0000 5006 0000 8507 0000 0000 0000 8106 0000 5a08 0000 1e02 0000 0000 0000 |....=.......................U...............P...............Z...........| 0x02d0 0c08 0000 0000 0000 0906 0000 9309 0000 3c08 0000 0000 0000 b406 0000 f403 0000 0000 0000 0000 0000 2a08 0000 3c02 0000 0000 0000 c906 0000 0000 0000 0000 0000 9904 0000 ba07 0000 |................<.......................*...<...........................| 0x0318 c501 0000 9607 0000 e009 0000 f902 0000 e904 0000 9805 0000 0000 0000 1309 0000 e609 0000 f209 0000 2c04 0000 9a07 0000 0000 0000 ab09 0000 c709 0000 5801 0000 0408 0000 0000 0000 |........................................,...................X...........| 0x0360 5b0a 0000 e401 0000 0407 0000 0000 0000 4209 0000 fa08 0000 1a07 0000 ac07 0000 0000 0000 1f09 0000 e207 0000 ea04 0000 9301 0000 0000 0000 8c09 0000 6b07 0000 bf07 0000 d303 0000 |[...............B...........................................k...........| 0x03a8 ac09 0000 0000 0000 0000 0000 e608 0000 4f07 0000 0000 0000 2e02 0000 7800 0000 9501 0000 5705 0000 0000 0000 f500 0000 be01 0000 b505 0000 0000 0000 3302 0000 0000 0000 610a 0000 |................O...........x.......W.......................3.......a...| 0x03f0 0000 0000 0000 0000 8509 0000 140a 0000 7b0a 0000 4302 0000 0000 0000 0000 0000 e200 0000 8c0a 0000 9208 0000 4c05 0000 2d07 0000 0000 0000 2106 0000 c608 0000 0000 0000 2402 0000 |................{...C.......................L...-.......!...........$...| 0x0438 0508 0000 4c08 0000 0000 0000 dc06 0000 6508 0000 b001 0000 0000 0000 2408 0000 7e02 0000 0000 0000 2208 0000 4303 0000 4c04 0000 8404 0000 b307 0000 0000 0000 0000 0000 7e07 0000 |....L...........e...........$...~......."...C...L...................~...| 0x0480 0000 0000 0000 0000 8503 0000 4706 0000 5e05 0000 2305 0000 0000 0000 4208 0000 0000 0000 b805 0000 4600 0000 7605 0000 3b06 0000 4c09 0000 7d05 0000 8606 0000 0000 0000 bc05 0000 |............G...^...#.......B...........F...v...;...L...}...............| 0x04c8 0000 0000 0000 0000 5908 0000 7b07 0000 c503 0000 7707 0000 0000 0000 250a 0000 e006 0000 0000 0000 1406 0000 0a06 0000 0000 0000 0000 0000 0000 0000 a902 0000 0c09 0000 0000 0000 |........Y...{.......w.......%...........................................| 0x0510 6108 0000 9303 0000 ab06 0000 0000 0000 2509 0000 a201 0000 db06 0000 0000 0000 790a 0000 0000 0000 8a09 0000 d202 0000 0000 0000 8f06 0000 0000 0000 0000 0000 0000 0000 6b03 0000 |a...............%...............y...................................k...| 0x0558 db04 0000 0000 0000 8a06 0000 7209 0000 5506 0000 c809 0000 0000 0000 ec08 0000 fe07 0000 9008 0000 ca08 0000 5400 0000 3101 0000 7503 0000 0000 0000 0000 0000 0000 0000 0000 0000 |............r...U...........................T...1...u...................| 0x05a0 4305 0000 4100 0000 0000 0000 f609 0000 0000 0000 7e0a 0000 0000 0000 4402 0000 e408 0000 9a06 0000 0000 0000 cc08 0000 0000 0000 5209 0000 1407 0000 a604 0000 ba02 0000 880a 0000 |C...A...............~.......D.......................R...................| 0x05e8 7803 0000 a804 0000 0000 0000 b504 0000 e103 0000 0000 0000 8c05 0000 3909 0000 5a07 0000 e906 0000 0000 0000 0000 0000 af05 0000 6a04 0000 7807 0000 0000 0000 0000 0000 fb09 0000 |x...........................9...Z...................j...x...............| 0x0630 0000 0000 c007 0000 5000 0000 8107 0000 0000 0000 0000 0000 8205 0000 6608 0000 3808 0000 0000 0000 3e0a 0000 3e03 0000 ba05 0000 1f05 0000 190a 0000 cc06 0000 4806 0000 0000 0000 |........P...................f...8.......>...>...................H.......| 0x0678 0000 0000 f308 0000 0000 0000 5b04 0000 3b09 0000 4602 0000 a204 0000 b503 0000 0000 0000 6b08 0000 0000 0000 0000 0000 0000 0000 5007 0000 f509 0000 5800 0000 6e03 0000 0000 0000 |............[...;...F...............k...............P.......X...n.......| 0x06c0 0000 0000 2309 0000 0000 0000 2508 0000 7408 0000 cd08 0000 8004 0000 b008 0000 0000 0000 0000 0000 d405 0000 200a 0000 8804 0000 f809 0000 c405 0000 5205 0000 0000 0000 5005 0000 |....#.......%...t........................... ...............R.......P...| 0x0708 5703 0000 f407 0000 2803 0000 d109 0000 5806 0000 0000 0000 0000 0000 0000 0000 0000 0000 b803 0000 7300 0000 0000 0000 0000 0000 aa05 0000 4109 0000 7709 0000 0000 0000 0703 0000 |W.......(.......X.......................s...............A...w...........| 0x0750 0000 0000 0000 0000 1008 0000 a506 0000 6403 0000 a004 0000 2f0a 0000 0000 0000 570a 0000 8805 0000 2909 0000 bd06 0000 0a02 0000 4d0a 0000 5004 0000 0000 0000 0000 0000 0000 0000 |................d......./.......W.......)...........M...P...............| 0x0798 0000 0000 0000 0000 0000 0000 5401 0000 0000 0000 cd05 0000 4500 0000 0901 0000 7f09 0000 b002 0000 ef06 0000 0000 0000 c109 0000 4e02 0000 d206 0000 cb01 0000 bd09 0000 c407 0000 |............T...........E...........................N...................| 0x07e0 cf08 0000 350a 0000 b507 0000 0000 0000 3602 0000 0d0a 0000 6106 0000 cb04 0000 b903 0000 0409 0000 df02 0000 6407 0000 0000 0000 3002 0000 f309 0000 a300 0000 5906 0000 150a 0000 |....5...........6.......a...................d.......0...........Y.......| 0x0828 0304 0000 3f08 0000 0000 0000 af06 0000 0000 0000 0000 0000 7a03 0000 0307 0000 1a0a 0000 2504 0000 0000 0000 6804 0000 0000 0000 a307 0000 8709 0000 fa04 0000 0207 0000 c300 0000 |....?...................z...........%.......h...........................| 0x0870 6901 0000 d603 0000 7609 0000 ab05 0000 7809 0000 300a 0000 0000 0000 0608 0000 0000 0000 0000 0000 0000 0000 0000 0000 2206 0000 6701 0000 2e08 0000 7a06 0000 1001 0000 4708 0000 |i.......v.......x...0..........................."...g.......z.......G...| 0x08b8 3208 0000 f602 0000 0000 0000 0000 0000 b906 0000 0000 0000 1b0a 0000 e203 0000 0902 0000 4b07 0000 0000 0000 3409 0000 b206 0000 aa09 0000 0000 0000 ea08 0000 4e0a 0000 2e07 0000 |2...................................K.......4...................N.......| 0x0900 1509 0000 6208 0000 9003 0000 b009 0000 f402 0000 4e03 0000 d306 0000 e003 0000 2a0a 0000 7504 0000 7303 0000 220a 0000 9909 0000 3c06 0000 0000 0000 7704 0000 440a 0000 e905 0000 |....b...............N...........*...u...s...".......<.......w...D.......| 0x0948 0000 0000 0f04 0000 7c0a 0000 f207 0000 0000 0000 8d08 0000 b308 0000 710a 0000 a406 0000 0000 0000 7505 0000 4704 0000 6206 0000 0000 0000 7907 0000 b609 0000 cf09 0000 0306 0000 |........|...................q...........u...G...b.......y...............| 0x0990 0000 0000 ba08 0000 0000 0000 7c06 0000 0000 0000 0000 0000 1d03 0000 0000 0000 0000 0000 4007 0000 9f07 0000 0000 0000 7109 0000 9808 0000 0b08 0000 d007 0000 d309 0000 0000 0000 |............|.......................@...........q.......................| 0x09d8 6b04 0000 e603 0000 8b02 0000 d701 0000 a809 0000 7204 0000 6602 0000 0008 0000 480a 0000 3b0a 0000 f900 0000 0000 0000 5409 0000 2501 0000 8f09 0000 7104 0000 0000 0000 6103 0000 |k...................r...f.......H...;...........T...%.......q.......a...| 0x0a20 5407 0000 0000 0000 8e08 0000 2c08 0000 9504 0000 c506 0000 5708 0000 a508 0000 0000 0000 7d08 0000 1101 0000 1109 0000 0000 0000 0000 0000 6a08 0000 f001 0000 c205 0000 4900 0000 |T...........,...........W...........}...................j...........I...| 0x0a68 0000 0000 a10a 0000 0000 0000 2307 0000 c003 0000 0000 0000 7d0a 0000 f406 0000 6501 0000 d507 0000 a909 0000 f200 0000 8408 0000 0000 0000 b003 0000 b908 0000 2e00 0000 0003 0000 |............#...........}.......e.......................................| 0x0ab0 0000 0000 5c06 0000 af00 0000 cd03 0000 4e01 0000 0000 0000 2b08 0000 7a09 0000 510a 0000 0000 0000 8001 0000 0000 0000 cd09 0000 cc03 0000 0000 0000 1104 0000 540a 0000 4400 0000 |....\...........N.......+...z...Q...............................T...D...| 0x0af8 ba06 0000 0000 0000 7105 0000 900a 0000 d305 0000 0000 0000 cd04 0000 2a07 0000 e500 0000 8c07 0000 2107 0000 630a 0000 4a0a 0000 0000 0000 7f08 0000 e308 0000 3a0a 0000 be07 0000 |........q...................*...........!...c...J...............:.......| 0x0b40 4b04 0000 4009 0000 0000 0000 c200 0000 0000 0000 be08 0000 a705 0000 0000 0000 6909 0000 a309 0000 0000 0000 aa07 0000 4609 0000 ad01 0000 0000 0000 f100 0000 5909 0000 0709 0000 |K...@...........................i...............F...............Y.......| 0x0b88 bc06 0000 740a 0000 0000 0000 2101 0000 0000 0000 e107 0000 be00 0000 b105 0000 4304 0000 0000 0000 0000 0000 0000 0000 a706 0000 1005 0000 9407 0000 0000 0000 7309 0000 0000 0000 |....t.......!...................C...............................s.......| 0x0bd0 ae09 0000 e400 0000 0000 0000 0000 0000 470a 0000 3d05 0000 a802 0000 a501 0000 0000 0000 db09 0000 820a 0000 0000 0000 3705 0000 0000 0000 0000 0000 8b05 0000 0000 0000 7b00 0000 |................G...=...........................7...................{...| 0x0c18 bd08 0000 0000 0000 4b0a 0000 f603 0000 3e04 0000 2b02 0000 c207 0000 bd00 0000 8607 0000 e703 0000 080a 0000 0000 0000 1c08 0000 8b08 0000 0000 0000 d808 0000 fa06 0000 de09 0000 |........K.......>...+...................................................| 0x0c60 0000 0000 bc07 0000 270a 0000 0000 0000 5900 0000 d209 0000 aa00 0000 1409 0000 0009 0000 0000 0000 0000 0000 e000 0000 7102 0000 c208 0000 1206 0000 0000 0000 490a 0000 cc07 0000 |........'.......Y...............................q...............I.......| 0x0ca8 0000 0000 8b09 0000 0f05 0000 0000 0000 b407 0000 0000 0000 0000 0000 e105 0000 0707 0000 9a00 0000 0000 0000 6404 0000 0000 0000 0000 0000 0000 0000 dd01 0000 0000 0000 d107 0000 |............................................d...........................| 0x0cf0 0000 0000 1707 0000 0000 0000 0005 0000 e008 0000 a908 0000 0000 0000 1306 0000 9508 0000 8d01 0000 0000 0000 0000 0000 e709 0000 5609 0000 3608 0000 0000 0000 f801 0000 ff03 0000 |....................................................V...6...............| 0x0d38 8208 0000 ad02 0000 0000 0000 ed09 0000 fd03 0000 7507 0000 a209 0000 0000 0000 8200 0000 2603 0000 400a 0000 7509 0000 0000 0000 4a00 0000 0000 0000 c204 0000 0000 0000 d106 0000 |....................u...............&...@...u.......J...................| 0x0d80 6d07 0000 0000 0000 a102 0000 0000 0000 9302 0000 0000 0000 0000 0000 0000 0000 c708 0000 2701 0000 4409 0000 0000 0000 ca07 0000 6500 0000 0000 0000 7d07 0000 3d06 0000 4e08 0000 |m...................................'...D...........e.......}...=...N...| 0x0dc8 6209 0000 3a06 0000 0000 0000 4703 0000 ed00 0000 da03 0000 0000 0000 0000 0000 3f05 0000 0000 0000 530a 0000 6607 0000 6808 0000 fe05 0000 0000 0000 4d09 0000 e605 0000 3209 0000 |b...:.......G...................?.......S...f...h...........M.......2...| 0x0e10 0000 0000 ff08 0000 0000 0000 b802 0000 8906 0000 0000 0000 1b07 0000 4309 0000 8909 0000 db01 0000 3009 0000 a00a 0000 f009 0000 4408 0000 9b08 0000 d102 0000 0000 0000 0000 0000 |............................C...........0...........D...................| 0x0e58 8b07 0000 ff09 0000 0000 0000 2404 0000 6009 0000 3204 0000 230a 0000 0000 0000 0000 0000 ce04 0000 a005 0000 7202 0000 5d0a 0000 f101 0000 7107 0000 6606 0000 7c09 0000 7409 0000 |............$...`...2...#...................r...].......q...f...|...t...| 0x0ea0 fc04 0000 b901 0000 1105 0000 0000 0000 0000 0000 3b07 0000 0000 0000 6e00 0000 8400 0000 0000 0000 3300 0000 6000 0000 1f08 0000 ef01 0000 6207 0000 ea00 0000 de06 0000 0000 0000 |....................;.......n...........3...`...........b...............| 0x0ee8 5204 0000 0e08 0000 7e09 0000 c209 0000 0a07 0000 4105 0000 5a0a 0000 0000 0000 c609 0000 fd05 0000 6e08 0000 fb06 0000 0000 0000 e007 0000 0000 0000 e301 0000 0000 0000 0000 0000 |R.......~...........A...Z...............n...............................| 0x0f30 1a03 0000 0000 0000 e506 0000 7600 0000 6609 0000 ec07 0000 d705 0000 1504 0000 0000 0000 0000 0000 0000 0000 9307 0000 0209 0000 4103 0000 0000 0000 e503 0000 0000 0000 0000 0000 |............v...f...................................A...................| 0x0f78 8902 0000 6b09 0000 9d06 0000 0000 0000 8508 0000 210a 0000 da08 0000 0000 0000 1009 0000 c507 0000 0000 0000 520a 0000 0000 0000 e803 0000 8505 0000 9606 0000 e504 0000 bf09 0000 |....k...............!.......................R...........................| 0x0fc0 9c07 0000 730a 0000 9408 0000 3908 0000 0406 0000 0000 0000 0000 0000 f307 0000 9200 0000 0000 0000 5707 0000 e802 0000 7305 0000 8008 0000 0a0a 0000 0000 0000 |....s.......9...........................W.......s...............| 1775 kldunload RET pread 4096/0x1000 1775 kldunload CALL mmap(0,0x267000,0,0x21002,0xffffffff,0) 1775 kldunload RET mmap 34366377984/0x800655000 1775 kldunload CALL mmap(0x800655000,0x130000,0x5,0x20012,0x3,0) 1775 kldunload RET mmap 34366377984/0x800655000 1775 kldunload CALL mmap(0x800884000,0x1d000,0x3,0x12,0x3,0x12f000) 1775 kldunload RET mmap 34368667648/0x800884000 1775 kldunload CALL mprotect(0x8008a1000,0x1b000,0x3) 1775 kldunload RET mprotect 0 1775 kldunload CALL close(0x3) 1775 kldunload RET close 0 1775 kldunload CALL sysarch(0x81,0x7fffffffe580) 1775 kldunload RET sysarch 0 1775 kldunload CALL munmap(0x80054c000,0x4000) 1775 kldunload RET munmap 0 1775 kldunload CALL mmap(0,0x19000,0x3,0x1002,0xffffffff,0) 1775 kldunload RET mmap 34365292544/0x80054c000 1775 kldunload CALL sigprocmask(SIG_BLOCK,0x800647320,0x7fffffffe550) 1775 kldunload RET sigprocmask 0 1775 kldunload CALL sigprocmask(SIG_SETMASK,0x800647330,0) 1775 kldunload RET sigprocmask 0 1775 kldunload CALL sigprocmask(SIG_BLOCK,0x800647320,0x7fffffffe520) 1775 kldunload RET sigprocmask 0 1775 kldunload CALL sigprocmask(SIG_SETMASK,0x800647330,0) 1775 kldunload RET sigprocmask 0 1775 kldunload CALL kldfind(0x7fffffffed32) 1775 kldunload RET kldfind 3 1775 kldunload CALL kldunloadf(0x3,LINKER_UNLOAD_NORMAL) 1775 kldunload RET kldunloadf -1 errno 16 Device busy 1775 kldunload CALL write(0x2,0x7fffffffda90,0xb) 1775 kldunload GIO fd 2 wrote 11 bytes "kldunload: " 1775 kldunload RET write 11/0xb 1775 kldunload CALL write(0x2,0x7fffffffdb70,0x11) 1775 kldunload GIO fd 2 wrote 17 bytes "can't unload file" 1775 kldunload RET write 17/0x11 1775 kldunload CALL write(0x2,0x8007769d4,0x2) 1775 kldunload GIO fd 2 wrote 2 bytes ": " 1775 kldunload RET write 2 1775 kldunload CALL readlink(0x80077687f,0x7fffffffd690,0x400) 1775 kldunload NAMI "/etc/malloc.conf" 1775 kldunload RET readlink -1 errno 2 No such file or directory 1775 kldunload CALL issetugid 1775 kldunload RET issetugid 0 1775 kldunload CALL break(0x800000) 1775 kldunload RET break 0 1775 kldunload CALL mmap(0,0x400000,0x3,0x1002,0xffffffff,0) 1775 kldunload RET mmap 34368897024/0x8008bc000 1775 kldunload CALL mmap(0x800cbc000,0x344000,0x3,0x1002,0xffffffff,0) 1775 kldunload RET mmap 34373091328/0x800cbc000 1775 kldunload CALL munmap(0x8008bc000,0x344000) 1775 kldunload RET munmap 0 1775 kldunload CALL stat(0x7fffffffdc50,0x7fffffffdbd0) 1775 kldunload NAMI "/usr/share/nls/C/libc.cat" 1775 kldunload RET stat -1 errno 2 No such file or directory 1775 kldunload CALL stat(0x7fffffffdc50,0x7fffffffdbd0) 1775 kldunload NAMI "/usr/share/nls/libc/C" 1775 kldunload RET stat -1 errno 2 No such file or directory 1775 kldunload CALL stat(0x7fffffffdc50,0x7fffffffdbd0) 1775 kldunload NAMI "/usr/local/share/nls/C/libc.cat" 1775 kldunload RET stat -1 errno 2 No such file or directory 1775 kldunload CALL stat(0x7fffffffdc50,0x7fffffffdbd0) 1775 kldunload NAMI "/usr/local/share/nls/libc/C" 1775 kldunload RET stat -1 errno 2 No such file or directory 1775 kldunload CALL madvise(0x800c07000,0x1000,MADV_FREE) 1775 kldunload RET madvise 0 1775 kldunload CALL madvise(0x800c08000,0x1000,MADV_FREE) 1775 kldunload RET madvise 0 1775 kldunload CALL write(0x2,0x7fffffffda90,0xc) 1775 kldunload GIO fd 2 wrote 12 bytes "Device busy " 1775 kldunload RET write 12/0xc 1775 kldunload CALL sigprocmask(SIG_BLOCK,0x800647320,0x7fffffffe000) 1775 kldunload RET sigprocmask 0 1775 kldunload CALL sigprocmask(SIG_SETMASK,0x800647330,0) 1775 kldunload RET sigprocmask 0 1775 kldunload CALL sigprocmask(SIG_BLOCK,0x800647320,0x7fffffffdfb0) 1775 kldunload RET sigprocmask 0 1775 kldunload CALL sigprocmask(SIG_SETMASK,0x800647330,0) 1775 kldunload RET sigprocmask 0 1775 kldunload CALL exit(0x1) --4Ckj6UjgE2iN1+kY-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 13:03:52 2010 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 92317106564A; Tue, 9 Nov 2010 13:03:52 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 0584D8FC0A; Tue, 9 Nov 2010 13:03:52 +0000 (UTC) Received: from [193.31.11.193] (helo=current.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PFnrZ-0004Ra-3m; Tue, 09 Nov 2010 14:03:49 +0100 Received: from current.Sisis.de (current [127.0.0.1]) by current.Sisis.de (8.14.3/8.14.3) with ESMTP id oA9D3mDw010155; Tue, 9 Nov 2010 14:03:48 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by current.Sisis.de (8.14.3/8.14.3/Submit) id oA9D3mXD010154; Tue, 9 Nov 2010 14:03:48 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: current.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Tue, 9 Nov 2010 14:03:48 +0100 From: Matthias Apitz To: Alexander Motin Message-ID: <20101109130348.GA10059@current.Sisis.de> References: <4CD337DA.7030902@FreeBSD.org> <20101104230735.GA6686@current.Sisis.de> <4CD33E0B.1070304@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4CD33E0B.1070304@FreeBSD.org> X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.19 (2009-01-05) X-Con-Id: 51246 X-Originating-IP: 193.31.11.193 Cc: freebsd-multimedia@freebsd.org, FreeBSD-Current Subject: Re: laptop Acer Aspire One D250 / snd_hda(4) && internal mic not recording 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: Tue, 09 Nov 2010 13:03:52 -0000 El día Friday, November 05, 2010 a las 01:13:15AM +0200, Alexander Motin escribió: > Matthias Apitz wrote: > > El día Friday, November 05, 2010 a las 12:46:50AM +0200, Alexander Motin escribió: > >> Matthias Apitz wrote: > >>> mixer(1) let me set for recoding only 'mic' or 'rec'. I'm attaching as > >>> well the output of verbose messages grep'ed for pcm and hdac. > >> Your CODEC configured to provide built-in microphone on separate device > >> pcm1. You may record from there (Skype allows to choose device) or > >> reconfigure CODEC using hints. > > > > In Skype in let me choose between > > /dev/dsp > > /dev/dsp0 > > /dev/dsp1 > > > > When I set mic to /dev/dsp0 it records from the jack (headphone mic), > > when I set it to /dev/dsp1 there is no recording. And the mixer for the > > pcm1 says: > > > > # mixer -f /dev/mixer1 > > Mixer rec is currently set to 100:100 > > Mixer monitor is currently set to 100:100 > > Recording source: monitor > > That's strange. I would expect it working. > > > Would you be so kind and give me the lines for reconfigure CODEC using > > hints? I'm really lost in this. > > OK, try this: > hint.hdac.0.cad0.nid18.config="as=2 seq=1" Hi Alexander, While trying to get understandig of the verbose boot messages of snd_hda(4), I found the following which seems to match the problem (only recording from Jack): hdac0: nid 18 0x99a30930 as 3 seq 0 Mic Fixed jack 3 loc 25 color Unknown misc 9 ... hdac0: nid 24 0x03a19820 as 2 seq 0 Mic Jack jack 1 loc 3 color Pink misc 8 i.e. the nid's are 18 (internal mic) and 24 (Jack); But in the DUMPING's Playback/Record Paths the nid=18 and nid=24 look different: 24: pcm0: Record: pcm0: pcm0: nid=8 [audio input] pcm0: | pcm0: + <- nid=35 [audio mixer] [src: mic, mix] pcm0: | pcm0: + <- nid=24 [pin: Mic (Pink Jack)] [src: mic] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: Input Mix: pcm0: pcm0: nid=11 [audio mixer] pcm0: | pcm0: + <- nid=24 [pin: Mic (Pink Jack)] [src: mic] 18: pcm1: Record: pcm1: pcm1: nid=9 [audio input] pcm1: | pcm1: + <- nid=34 [audio mixer] [src: monitor] pcm1: | pcm1: + <- nid=18 [pin: Mic (Fixed)] [src: monitor] (there is no 'Input Mix:' section part for nid=18) Can this cause the problem? What else could I debug to nail this down? 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 Tue Nov 9 08:02:10 2010 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 19DEC106566B; Tue, 9 Nov 2010 08:02:10 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh7.mail.rice.edu (mh7.mail.rice.edu [128.42.199.46]) by mx1.freebsd.org (Postfix) with ESMTP id D66E98FC13; Tue, 9 Nov 2010 08:02:09 +0000 (UTC) Received: from mh7.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh7.mail.rice.edu (Postfix) with ESMTP id CA29528F809; Tue, 9 Nov 2010 02:02:08 -0600 (CST) X-Virus-Scanned: by amavis-2.6.4 at mh7.mail.rice.edu, auth channel Received: from mh7.mail.rice.edu ([127.0.0.1]) by mh7.mail.rice.edu (mh7.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id 57apkCFrayfn; Tue, 9 Nov 2010 02:02:08 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh7.mail.rice.edu (Postfix) with ESMTPSA id 4970D28F800; Tue, 9 Nov 2010 02:02:08 -0600 (CST) Message-ID: <4CD8FFFF.3070106@rice.edu> Date: Tue, 09 Nov 2010 02:02:07 -0600 From: Alan Cox User-Agent: Thunderbird 2.0.0.24 (X11/20100725) MIME-Version: 1.0 To: Andriy Gapon References: <4CA0DA49.2090006@freebsd.org> <4CA3A48A.5070300@freebsd.org> <4CA3BD1E.5070807@rice.edu> <4CA5911E.3000101@freebsd.org> <4CAE0060.7050607@freebsd.org> <4CAECC4D.90707@rice.edu> <4CD1AA45.7000504@freebsd.org> <4CD1AD80.2090903@rice.edu> <4CD1D4AA.3060309@freebsd.org> In-Reply-To: <4CD1D4AA.3060309@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 09 Nov 2010 13:44:13 +0000 Cc: Alan Cox , freebsd-current@freebsd.org Subject: Re: minidump size on 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: Tue, 09 Nov 2010 08:02:10 -0000 Andriy Gapon wrote: > So, here is the next version of the patch: > http://people.freebsd.org/~avg/amd64-minidump.4.diff > > Changes since the last version: > 1. libkvm - try to support both the new and the previous formats/versions of > amd64 minidump. I am not entirely sure about style in which I handled handling > of version 1 minidump. Identifier names like pmapsize (for "page map size") and > page_map could also be improved, perhaps. > 2. kernel - implemented dumping of 1GB pages via "fake" 512 x 2MB pages per > Alan's suggestion. > > The change is only compile tested so far. Not sure if it's possible to test > handling 1GB pages yet :-) > > As always, reviews, testing and suggestions are very welcome. > The kernel portion of the patch looks correct. If I were to make one stylistic suggestion, it would be to make the control flow of the outer and inner loops as similar as possible, that is, for (... if ((pdp[i] & PG_V) == 0) { ... continue; } if ((pdp[i] & PG_PS) != 0) { ... continue; } for (... if ((pd[j] & PG_V) == 0) continue; if ((pd[j] & PG_PS) != 0) { ... continue; } for (... if ((pt[x] & PG_V) == 0) continue; ... I think this would make the code a little easier to follow. Alan From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 13:45:56 2010 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 A8DE81065698; Tue, 9 Nov 2010 13:45:56 +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 C1BC38FC1B; Tue, 9 Nov 2010 13:45:55 +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 PAA25243; Tue, 09 Nov 2010 15:45:53 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CD95090.2010405@freebsd.org> Date: Tue, 09 Nov 2010 15:45:52 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Lars Engels References: <201011081714.53637.jhb@freebsd.org> <20101109052623.GS56407@e.0x20.net> In-Reply-To: <20101109052623.GS56407@e.0x20.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Only display ACPI bootmenu key if ACPI is present 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, 09 Nov 2010 13:45:56 -0000 on 09/11/2010 07:26 Lars Engels said the following: > Maybe we should also import PCBSD's patches to the beastie menu? > In PCBSD's beastie menu you can toggle some settings like "safe mode", > and "ACPI", so the kernel is not loaded as soon as select an option. > > See > http://trac.pcbsd.org/browser/pcbsd/current/system-overlay/boot/beastie.4th Lars, not sure if I got your suggestion correctly, this is what I have in my local tree: diff --git a/sys/boot/i386/loader/loader.rc b/sys/boot/i386/loader/loader.rc index 6443f3f..cb2f723 100644 --- a/sys/boot/i386/loader/loader.rc +++ b/sys/boot/i386/loader/loader.rc @@ -5,7 +5,7 @@ include /boot/loader.4th \ Reads and processes loader.conf variables -start +initialize \ Tests for password -- executes autoboot first if a password was defined check-password With this kernel and modules are _not_ loaded before presenting the menu. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 13:48:48 2010 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 024BB10656A9; Tue, 9 Nov 2010 13:48:48 +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 CA6268FC31; Tue, 9 Nov 2010 13:48:47 +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 81D4E46B1A; Tue, 9 Nov 2010 08:48:47 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 927DC8A027; Tue, 9 Nov 2010 08:48:46 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 9 Nov 2010 08:44:28 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20101109114612.GA58585@freebsd.org> In-Reply-To: <20101109114612.GA58585@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201011090844.28609.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 09 Nov 2010 08:48:46 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Alexander Best Subject: Re: kldunload(8) returns 0, although it fail 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, 09 Nov 2010 13:48:48 -0000 On Tuesday, November 09, 2010 6:46:12 am Alexander Best wrote: > hi there, > > i posted this message on freebsd-questions@, but nobody could help me with it. > to me this looks like a bug, so i assume posting it again here on > freebsd-current@ might be better. > > please keep in mind that the issue here is not the fact that the second attempt > to unload sound.ko/netgraph.ko fails. it *should* fail, because both modules > have dependencies. however it should fail with the first attempt. right now > kldunloadf() returns zero, whereas it should actually return EBUSY (just like > the second attempt). > > i've attached two kdump outputs: one for the first 'kldunload' attempt and one > for the second. as you can see the problem is that for some reason kldunloadf() > returns zero, although it couldn't unload the module. Did you get an error message in dmesg? If you have manually loaded netgraph.ko (via netgraph_load="YES" in loader.conf or an explicit kldload) and then loaded other modules that depend on it (such as ng_foo.ko) then this is expected behavior. What your kldunload has done is to remove the manual reference from loader.conf or 'kldload netgraph.ko'. What this changes is what happens when you do 'kldunload ng_foo.ko'. If you unload ng_foo.ko now, then netgraph.ko will also be unloaded when its last reference drops (in this case it looks like you actually have two ng_*.ko objects loaded, so you would have to unload both of them, but I will assume a single ng_foo.ko to make the explanation simpler). If you had not done 'kldunload netgraph.ko' but had done 'kldunload ng_foo.ko', then the manual reference would have kept netgraph.ko loaded. All this logic exists so that if you do 'kldload foo.ko' and it auto-loads bar.ko as a dependency, then doing 'kldunload bar.ko' will unload both foo.ko and bar.ko. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 14:05:22 2010 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 D5EBB106566C; Tue, 9 Nov 2010 14:05:22 +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 6F47A8FC22; Tue, 9 Nov 2010 14:05:22 +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 oA9E5Isg009798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Nov 2010 16:05:18 +0200 (EET) (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 oA9E5IFp027316; Tue, 9 Nov 2010 16:05:18 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oA9E5I5b027315; Tue, 9 Nov 2010 16:05:18 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 9 Nov 2010 16:05:18 +0200 From: Kostik Belousov To: Andriy Gapon Message-ID: <20101109140518.GV2392@deviant.kiev.zoral.com.ua> References: <4CD3B1D2.30003@icyb.net.ua> <4CD7E401.1010206@freebsd.org> <20101108120403.GC2392@deviant.kiev.zoral.com.ua> <4CD9139D.9060302@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gR2gBiFPsZkfqe6l" Content-Disposition: inline In-Reply-To: <4CD9139D.9060302@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.5 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-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: radeon_cp_texture: page fault with non-sleepable locks held 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, 09 Nov 2010 14:05:23 -0000 --gR2gBiFPsZkfqe6l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 09, 2010 at 11:25:49AM +0200, Andriy Gapon wrote: > on 08/11/2010 14:04 Kostik Belousov said the following: > > On Mon, Nov 08, 2010 at 01:50:25PM +0200, Andriy Gapon wrote: > >> on 05/11/2010 09:27 Andriy Gapon said the following: > >>> > >>> I use FreeSBD head and KDE 4 with all the bells and whistles enabled. > >>> Apparently recent KDE update has enabled even more of them, because I= started to > >>> have panics with a kernel that has INVARIANTS and WITNESS enabled. > >> > >> I tried to solve the problem by changing drmdev from mutex to sx: > >> http://people.freebsd.org/~avg/drm-sx.diff > > I remember that drm lock can be acquired from the interrupt thread, if > > the card supports interrupts. Changing it to sx cannot work then, becau= se > > interrupt threads cannot sleep. Most likely, you are getting around it > > since r600 not yet used interrupts on FreeBSD. > >=20 > > I think the solution is to drop drm lock around copyin. >=20 > Kostik, >=20 > I looked at this some more and now I think that using sx is a step in the= right > direction. >=20 > Rationale: > 1. it seems that on Linux mutex is a sleepable lock and thus can be safel= y held > across a page fault; and Linux mutex -> FreeBSD sx seems to be a porting > technique used for kernel code before[*]. > 2. DRM interrupt code uses a different lock - irq_lock, which is locked v= ia > DRM_SPINLOCK macro (expands to FreeBSD mutex); apparently even on Linux a "even on Linux". Heh. > sleep-able lock can't be acquired in interrupt handler. >=20 > I use Linux this and Linux that as a justification, because the DRM code > apparently originated with Linux model/idioms in mind, although the origi= nal > purpose was for the code to be portable. >=20 > So, what do you think about this aspect? > Should you agree with the usage of sx, then the previous question pops ba= ck - I do not agree. > how to resolve the lock order reversal between drmdev lock and user map l= ock > (which both would be sx). Easiest would be for DRM to provide wrappers for copyin/copyout that unlock, do operation and lock. Where is the reverse order (user map -> drm) ? >=20 > [*] http://www.ukuug.org/events/eurobsdcon2009/papers/dvb_driver_paper.pdf > --=20 > Andriy Gapon --gR2gBiFPsZkfqe6l Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzZVR0ACgkQC3+MBN1Mb4igNwCdGq0Gj0h8j/rE8m/9BH7vwc9c aecAoLzwf6qiJ7K+hLQeRQ0tAU2tYuJI =574k -----END PGP SIGNATURE----- --gR2gBiFPsZkfqe6l-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 14:08:02 2010 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 62C721065670; Tue, 9 Nov 2010 14:08:02 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.67.217]) by mx1.freebsd.org (Postfix) with ESMTP id 1F41C8FC1F; Tue, 9 Nov 2010 14:08:01 +0000 (UTC) Received: by mail.0x20.net (Postfix, from userid 1002) id BA00039DFE; Tue, 9 Nov 2010 15:08:02 +0100 (CET) Date: Tue, 9 Nov 2010 15:08:02 +0100 From: Lars Engels To: Andriy Gapon Message-ID: <20101109140802.GD56407@e.0x20.net> References: <201011081714.53637.jhb@freebsd.org> <20101109052623.GS56407@e.0x20.net> <4CD95090.2010405@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="S2CovAv8lqFB/Tem" Content-Disposition: inline In-Reply-To: <4CD95090.2010405@freebsd.org> X-Editor: VIM - Vi IMproved 7.2 X-Operation-System: FreeBSD 5.5-RELEASE-p19 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org Subject: Re: Only display ACPI bootmenu key if ACPI is present 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, 09 Nov 2010 14:08:02 -0000 --S2CovAv8lqFB/Tem Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 09, 2010 at 03:45:52PM +0200, Andriy Gapon wrote: > on 09/11/2010 07:26 Lars Engels said the following: > > Maybe we should also import PCBSD's patches to the beastie menu? > > In PCBSD's beastie menu you can toggle some settings like "safe mode", > > and "ACPI", so the kernel is not loaded as soon as select an option. > >=20 > > See > > http://trac.pcbsd.org/browser/pcbsd/current/system-overlay/boot/beastie= =2E4th >=20 > Lars, >=20 > not sure if I got your suggestion correctly, this is what I have in my lo= cal tree: > diff --git a/sys/boot/i386/loader/loader.rc b/sys/boot/i386/loader/loader= =2Erc > index 6443f3f..cb2f723 100644 > --- a/sys/boot/i386/loader/loader.rc > +++ b/sys/boot/i386/loader/loader.rc > @@ -5,7 +5,7 @@ > include /boot/loader.4th >=20 > \ Reads and processes loader.conf variables > -start > +initialize >=20 > \ Tests for password -- executes autoboot first if a password was defined > check-password >=20 > With this kernel and modules are _not_ loaded before presenting the menu. That's also an appreciated improvement, but what PCBSD does is that you can toggle several options, so when you select an option, the kernel is not loaded immediately after but you are still in the menu and can select / toggle another option. That way you have a multi-selection, e.g. select safe mode but enable acpi. Maybe we could also add a menu entry to boot without any modules, so loaders.conf gets overridden? --S2CovAv8lqFB/Tem Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkzZVcIACgkQKc512sD3afgF+ACbBzfHN0X9yTi9U0/oIJh5iQgs iccAoM0/VZHTJCTT6V1JTmbIs7VJXe4g =Eo71 -----END PGP SIGNATURE----- --S2CovAv8lqFB/Tem-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 14:10:28 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 21D1C106566C; Tue, 9 Nov 2010 14:10:28 +0000 (UTC) Date: Tue, 9 Nov 2010 14:10:28 +0000 From: Alexander Best To: John Baldwin Message-ID: <20101109141028.GA75878@freebsd.org> References: <20101109114612.GA58585@freebsd.org> <201011090844.28609.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201011090844.28609.jhb@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: kldunload(8) returns 0, although it fail 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, 09 Nov 2010 14:10:28 -0000 On Tue Nov 9 10, John Baldwin wrote: > On Tuesday, November 09, 2010 6:46:12 am Alexander Best wrote: > > hi there, > > > > i posted this message on freebsd-questions@, but nobody could help me with it. > > to me this looks like a bug, so i assume posting it again here on > > freebsd-current@ might be better. > > > > please keep in mind that the issue here is not the fact that the second attempt > > to unload sound.ko/netgraph.ko fails. it *should* fail, because both modules > > have dependencies. however it should fail with the first attempt. right now > > kldunloadf() returns zero, whereas it should actually return EBUSY (just like > > the second attempt). > > > > i've attached two kdump outputs: one for the first 'kldunload' attempt and one > > for the second. as you can see the problem is that for some reason kldunloadf() > > returns zero, although it couldn't unload the module. > > Did you get an error message in dmesg? If you have manually loaded > netgraph.ko (via netgraph_load="YES" in loader.conf or an explicit kldload) > and then loaded other modules that depend on it (such as ng_foo.ko) then this > is expected behavior. What your kldunload has done is to remove the manual > reference from loader.conf or 'kldload netgraph.ko'. What this changes is what > happens when you do 'kldunload ng_foo.ko'. If you unload ng_foo.ko now, then > netgraph.ko will also be unloaded when its last reference drops (in this case > it looks like you actually have two ng_*.ko objects loaded, so you would have > to unload both of them, but I will assume a single ng_foo.ko to make the > explanation simpler). If you had not done 'kldunload netgraph.ko' but had > done 'kldunload ng_foo.ko', then the manual reference would have kept netgraph.ko > loaded. > > All this logic exists so that if you do 'kldload foo.ko' and it auto-loads bar.ko > as a dependency, then doing 'kldunload bar.ko' will unload both foo.ko and bar.ko. i have ng_ubt_load="YES" in my loader.conf and kldstat says: Id Refs Address Size Name 1 37 0xffffffff80100000 a2ddb8 kernel 2 1 0xffffffff80b2e000 295e8 snd_hda.ko 3 1 0xffffffff80b58000 85110 sound.ko 4 1 0xffffffff80bde000 cf79e0 nvidia.ko 5 5 0xffffffff818d6000 418c0 linux.ko 6 1 0xffffffff81918000 80e8 ng_ubt.ko 7 2 0xffffffff81921000 fa78 ng_hci.ko 8 2 0xffffffff81931000 2bd0 ng_bluetooth.ko 9 3 0xffffffff81934000 15e68 netgraph.ko 10 1 0xffffffff81a12000 3efb linprocfs.ko 11 3 0xffffffff81a16000 4698 pseudofs.ko 12 1 0xffffffff81a1b000 31b3 procfs.ko 13 1 0xffffffff81a1f000 a37 linsysfs.ko 14 1 0xffffffff81a20000 6f4 rtc.ko also the same happens with sound.ko. i have snd_hda_load="yes". and i think snd_hda is the only dependecy for sound.ko. there was no error message in dmesg for the first kldunload attempt. i think i understand the logic, however the current behavior does not confirm to the description in kldunload(2). cheers. alex > > -- > John Baldwin -- a13x From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 14:33:02 2010 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 CF121106564A; Tue, 9 Nov 2010 14:33:02 +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 E58FB8FC1A; Tue, 9 Nov 2010 14:33:01 +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 QAA26132; Tue, 09 Nov 2010 16:32:59 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CD95B9B.3030703@freebsd.org> Date: Tue, 09 Nov 2010 16:32:59 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Lars Engels References: <201011081714.53637.jhb@freebsd.org> <20101109052623.GS56407@e.0x20.net> <4CD95090.2010405@freebsd.org> <20101109140802.GD56407@e.0x20.net> In-Reply-To: <20101109140802.GD56407@e.0x20.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Only display ACPI bootmenu key if ACPI is present 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, 09 Nov 2010 14:33:02 -0000 on 09/11/2010 16:08 Lars Engels said the following: > That's also an appreciated improvement, but what PCBSD does is that you > can toggle several options, so when you select an option, the kernel is > not loaded immediately after but you are still in the menu and can > select / toggle another option. That way you have a multi-selection, > e.g. select safe mode but enable acpi. > Maybe we could also add a menu entry to boot without any modules, so > loaders.conf gets overridden? That sounds cool. Like e.g. selecting verbose single-user boot completely from the menu. Good idea. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 15:20:09 2010 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 E95B4106564A for ; Tue, 9 Nov 2010 15:20:09 +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 3C8718FC16 for ; Tue, 9 Nov 2010 15:20:08 +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 RAA26947 for ; Tue, 09 Nov 2010 17:20:07 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CD966A7.2020207@freebsd.org> Date: Tue, 09 Nov 2010 17:20:07 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: ATA: driver bug: Unable to set devclass 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, 09 Nov 2010 15:20:10 -0000 Since one of the recent updates (not sure which revision though) I started to get "Unable to set devclass" messages in boot dmesg. I'd say that I see the message every other boot, i.e. not always. I added some more debug code there and here's a tack trace: driver bug: Unable to set devclass (child = 0xffffff00070d0100, devname: (null)) #0 0xffffffff803ae127 at device_probe_child+0x127 #1 0xffffffff803ae40c at device_probe+0x7c #2 0xffffffff803ae4a1 at device_probe_and_attach+0x11 #3 0xffffffff803ae56a at bus_generic_attach+0x1a #4 0xffffffff801df93c at ata_identify+0x2ec #5 0xffffffff801dfcdb at ata_boot_attach+0x6b #6 0xffffffff803a8577 at run_interrupt_driven_config_hooks+0xf7 #7 0xffffffff803a8993 at boot_run_interrupt_driven_config_hooks+0x23 #8 0xffffffff8032f227 at mi_startup+0xc7 #9 0xffffffff801719cc at btext+0x2c >From kgdb: (kgdb) p *(device_t)0xffffff00070d0100 $1 = {ops = 0xffffff0001b07000, link = {tqe_next = 0xffffff0001a65100, tqe_prev = 0xffffff0006eb0130}, devlink = {tqe_next = 0xffffff0001a65100, tqe_prev = 0xffffff000706e318}, parent = 0xffffff0006eb0100, children = {tqh_first = 0xffffff0001a5b200, tqh_last = 0xffffff0001a5b208}, driver = 0xffffffff8079bc80, devclass = 0xffffff0001add080, unit = 0, nameunit = 0xffffff00070931a0 "ad0", desc = 0xffffff000711e7c0 "ST3320620A/3.AAF", busy = 0, state = DS_ATTACHED, devflags = 0, flags = 89, order = 0, ivars = 0xffffff000711e5e0, softc = 0xffffff000706a400, sysctl_ctx = {tqh_first = 0xffffff000711e600, tqh_last = 0xffffff000711e708}, sysctl_tree = 0xffffff00070f9500} Apparently sometimes something happens too soon? :-) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 16:00:25 2010 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 4A2CB10656AC; Tue, 9 Nov 2010 16:00:25 +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 AB9128FC26; Tue, 9 Nov 2010 16:00:05 +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 3341D46B06; Tue, 9 Nov 2010 11:00:05 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 20ACC8A01D; Tue, 9 Nov 2010 11:00:04 -0500 (EST) From: John Baldwin To: Alexander Best Date: Tue, 9 Nov 2010 09:37:39 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20101109114612.GA58585@freebsd.org> <201011090844.28609.jhb@freebsd.org> <20101109141028.GA75878@freebsd.org> In-Reply-To: <20101109141028.GA75878@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011090937.40121.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 09 Nov 2010 11:00:04 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org Subject: Re: kldunload(8) returns 0, although it fail 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, 09 Nov 2010 16:00:25 -0000 On Tuesday, November 09, 2010 9:10:28 am Alexander Best wrote: > On Tue Nov 9 10, John Baldwin wrote: > > On Tuesday, November 09, 2010 6:46:12 am Alexander Best wrote: > > > hi there, > > > > > > i posted this message on freebsd-questions@, but nobody could help me with it. > > > to me this looks like a bug, so i assume posting it again here on > > > freebsd-current@ might be better. > > > > > > please keep in mind that the issue here is not the fact that the second attempt > > > to unload sound.ko/netgraph.ko fails. it *should* fail, because both modules > > > have dependencies. however it should fail with the first attempt. right now > > > kldunloadf() returns zero, whereas it should actually return EBUSY (just like > > > the second attempt). > > > > > > i've attached two kdump outputs: one for the first 'kldunload' attempt and one > > > for the second. as you can see the problem is that for some reason kldunloadf() > > > returns zero, although it couldn't unload the module. > > > > Did you get an error message in dmesg? If you have manually loaded > > netgraph.ko (via netgraph_load="YES" in loader.conf or an explicit kldload) > > and then loaded other modules that depend on it (such as ng_foo.ko) then this > > is expected behavior. What your kldunload has done is to remove the manual > > reference from loader.conf or 'kldload netgraph.ko'. What this changes is what > > happens when you do 'kldunload ng_foo.ko'. If you unload ng_foo.ko now, then > > netgraph.ko will also be unloaded when its last reference drops (in this case > > it looks like you actually have two ng_*.ko objects loaded, so you would have > > to unload both of them, but I will assume a single ng_foo.ko to make the > > explanation simpler). If you had not done 'kldunload netgraph.ko' but had > > done 'kldunload ng_foo.ko', then the manual reference would have kept netgraph.ko > > loaded. > > > > All this logic exists so that if you do 'kldload foo.ko' and it auto-loads bar.ko > > as a dependency, then doing 'kldunload bar.ko' will unload both foo.ko and bar.ko. > > i have ng_ubt_load="YES" in my loader.conf and kldstat says: > > Id Refs Address Size Name > 1 37 0xffffffff80100000 a2ddb8 kernel > 2 1 0xffffffff80b2e000 295e8 snd_hda.ko > 3 1 0xffffffff80b58000 85110 sound.ko > 4 1 0xffffffff80bde000 cf79e0 nvidia.ko > 5 5 0xffffffff818d6000 418c0 linux.ko > 6 1 0xffffffff81918000 80e8 ng_ubt.ko > 7 2 0xffffffff81921000 fa78 ng_hci.ko > 8 2 0xffffffff81931000 2bd0 ng_bluetooth.ko > 9 3 0xffffffff81934000 15e68 netgraph.ko > 10 1 0xffffffff81a12000 3efb linprocfs.ko > 11 3 0xffffffff81a16000 4698 pseudofs.ko > 12 1 0xffffffff81a1b000 31b3 procfs.ko > 13 1 0xffffffff81a1f000 a37 linsysfs.ko > 14 1 0xffffffff81a20000 6f4 rtc.ko > > also the same happens with sound.ko. i have snd_hda_load="yes". and i think > snd_hda is the only dependecy for sound.ko. > > there was no error message in dmesg for the first kldunload attempt. > > i think i understand the logic, however the current behavior does not confirm > to the description in kldunload(2). Hmm, ok, fair enough. Do you get the same behavior if you kldload ng_ubt.ko after boot? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 16:08:24 2010 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 1D5461065780 for ; Tue, 9 Nov 2010 16:08:24 +0000 (UTC) (envelope-from rbgarga@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 CAC208FC1A for ; Tue, 9 Nov 2010 16:08:23 +0000 (UTC) Received: by gwj16 with SMTP id 16so4572880gwj.13 for ; Tue, 09 Nov 2010 08:08:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=f9z7iKqCb/S1t7r7VyulH1cyZGCgfIC8a7jaOF9atGk=; b=oHqmat8t31tb/vPgTRKlGoupNb0geqDSyb+qrZqgf8t/jX2klfvxD7Btrv2avqAAMY TGiR+1Bzd+dqnoVxHifxTCkvk0g3/RYu4IMv0yWUBevfE4xO+sMaYncYa2usp0m/nnFn XHt/lVzjf+l1pJL2j3TQCTW9lh7+WUkILixcQ= 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=epuIBbk8hTCN3Y413+Y6NEqIosRhNZjDUUR/EzO/s6HHLi/OYi27NOqks6QAIeAYf6 vwKlFETdxKSanhc/nK5cDAoDpMGZh17Jf8zyqYSuJY5/IvRSauNgXWJseZ/c+Ht1NxHB TKgCAWMgZ4XqaSBUJpAzg7rr23m5yLqeCPJNk= Received: by 10.216.87.20 with SMTP id x20mr997858wee.52.1289318902153; Tue, 09 Nov 2010 08:08:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.182.10 with HTTP; Tue, 9 Nov 2010 08:08:01 -0800 (PST) In-Reply-To: <20101109100319.GV2054@hoeg.nl> References: <20101109100319.GV2054@hoeg.nl> From: Renato Botelho Date: Tue, 9 Nov 2010 14:08:01 -0200 Message-ID: To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Eir Nym , FreeBSD Mail Lists Subject: Re: Syscons and termcap 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, 09 Nov 2010 16:08:24 -0000 On Tue, Nov 9, 2010 at 8:03 AM, Ed Schouten wrote: > Hello Eir, > > * Eir Nym , 20101109 05:10: >> I've compiled -CURRENT kernel with UTF-8 and CONS25 support. ( r214751 ) >> >> in xterm emulation mode I have problems with bindings for some keys, >> such as Home >> If I start vis(1) and press Home, I always get "^[[H" sequence instead >> of "^[OH" which is defined in termcap (5) file. >> >> I get correct results after switching to cons25. >> >> What do I wrong ? Does sc(4) driver in current correctly support >> xterm-like key bindings? > > Yes, but not only must you set TERM=3Dxterm, you must also remove > TEKEN_CONS25 from your kernel configuration or run vidcontrol -T xterm > on that specific window. There is almost no reason why anyone would want > to use the TEKEN_CONS25 option. > > Depending on whether the terminal is switched to cursor keys mode, it > will return ^[[H or ^[OH. See /sys/teken/teken.c, teken_get_sequence(). Hi Ed, Well, few weeks ago I moved from ISO-8859-1 to UTF-8 on my Xorg environment, and after reading this I decided to make a test. I rebuilt my 9.0-current (r215031) with option TEKEN_UTF8 in kernel config, and after configure my syscons to use cp850-* fonts i can see UTF-8 chars properly \o/ The only thing i cannot do here is to type chars with accent like =E1=E9 on console, because it seems to don't respect deadkeys, when I press ' the char ' is show and never wait the next char to compose a new one when necessary. Is it a knwon issue or i'm doing something wrong? I'm using us.iso.kbd Regards --=20 Renato Botelho From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 16:45:14 2010 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 41C7C10656A4 for ; Tue, 9 Nov 2010 16:45:14 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (outu.internet-mail-service.net [216.240.47.244]) by mx1.freebsd.org (Postfix) with ESMTP id 0BAD08FC29 for ; Tue, 9 Nov 2010 16:45:13 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oA9GjDni012180; Tue, 9 Nov 2010 08:45:13 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 702822D6015; Tue, 9 Nov 2010 08:45:11 -0800 (PST) Message-ID: <4CD97A9A.8000007@freebsd.org> Date: Tue, 09 Nov 2010 08:45:14 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: FreeBSD Current , alc@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: Subject: limits to memory on 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: Tue, 09 Nov 2010 16:45:14 -0000 During the discussion at MeetBSD the question came up as to what the real limiting factors were with regard to how much RAM a system could have. it was put to us that the limit was currently around 512 GB, though no-one at teh discussion knew what the mechanism of the limitation was or what might ligh beyond it. Could anyone who knows, pipe upt and let use know what the factors are, and if the current limit is overcome, what the next one after that will be? Julian From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 17:04:11 2010 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 B9CC9106564A; Tue, 9 Nov 2010 17:04:11 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 145638FC1E; Tue, 9 Nov 2010 17:04:10 +0000 (UTC) Received: by bwz2 with SMTP id 2so276774bwz.13 for ; Tue, 09 Nov 2010 09:04:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=jdvz9OP1uWYEbRswMdWUHQhZg3yqQ5SNHO4fZxgNHWA=; b=RtAaehBsrxFRdXzji0SB1799uoECqDy/m0aTY6578r90jGuLxbLVaDagRacJqvxvyS nDZonLNe52MBEbJ+E+i/k+HGEy5eu+v+YI974enOlZnQr9BpywhOVxa4hrJ1MtYpF+CP IKpVd9cThPwIxyT9Hn03vVKj9D8rmpGCSQmnM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=wXYJrMN/Hy5ZdUxi13ke7Kn3hN6XTHoQidqp4SYuPenqbi/w6WCQo0mSpnYih3kueY Sca5CtZdRGkfNdBX5yZhiOT1W61l6TVJZoqJWb7z0mWtcQ6ddeF75ny9InsX1ciuo+4n V+5LodHUSSLrwtzDW1uNrCP+ih+GDIAvtLNn8= Received: by 10.204.122.8 with SMTP id j8mr6675096bkr.135.1289322249791; Tue, 09 Nov 2010 09:04:09 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id d27sm1191655bkw.2.2010.11.09.09.04.07 (version=SSLv3 cipher=RC4-MD5); Tue, 09 Nov 2010 09:04:08 -0800 (PST) Sender: Alexander Motin Message-ID: <4CD97F04.6010009@FreeBSD.org> Date: Tue, 09 Nov 2010 19:04:04 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Andriy Gapon , current References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: Re: ATA: driver bug: Unable to set devclass 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, 09 Nov 2010 17:04:11 -0000 Andriy Gapon wrote: > Since one of the recent updates (not sure which revision though) I started to get > "Unable to set devclass" messages in boot dmesg. I'd say that I see the message > every other boot, i.e. not always. > > I added some more debug code there and here's a tack trace: > > driver bug: Unable to set devclass (child = 0xffffff00070d0100, devname: (null)) > #0 0xffffffff803ae127 at device_probe_child+0x127 > #1 0xffffffff803ae40c at device_probe+0x7c > #2 0xffffffff803ae4a1 at device_probe_and_attach+0x11 > #3 0xffffffff803ae56a at bus_generic_attach+0x1a > #4 0xffffffff801df93c at ata_identify+0x2ec > #5 0xffffffff801dfcdb at ata_boot_attach+0x6b > #6 0xffffffff803a8577 at run_interrupt_driven_config_hooks+0xf7 > #7 0xffffffff803a8993 at boot_run_interrupt_driven_config_hooks+0x23 > #8 0xffffffff8032f227 at mi_startup+0xc7 > #9 0xffffffff801719cc at btext+0x2c > >>From kgdb: > (kgdb) p *(device_t)0xffffff00070d0100 > $1 = {ops = 0xffffff0001b07000, link = {tqe_next = 0xffffff0001a65100, tqe_prev = > 0xffffff0006eb0130}, devlink = {tqe_next = 0xffffff0001a65100, tqe_prev = > 0xffffff000706e318}, > parent = 0xffffff0006eb0100, children = {tqh_first = 0xffffff0001a5b200, > tqh_last = 0xffffff0001a5b208}, driver = 0xffffffff8079bc80, devclass = > 0xffffff0001add080, unit = 0, > nameunit = 0xffffff00070931a0 "ad0", desc = 0xffffff000711e7c0 > "ST3320620A/3.AAF", busy = 0, state = DS_ATTACHED, devflags = 0, flags = 89, order > = 0, ivars = 0xffffff000711e5e0, > softc = 0xffffff000706a400, sysctl_ctx = {tqh_first = 0xffffff000711e600, > tqh_last = 0xffffff000711e708}, sysctl_tree = 0xffffff00070f9500} > > Apparently sometimes something happens too soon? :-) What controller is there? Any other differences/interesting things in verbose dmesg? Any new "CONNECT requested" messages or anything else? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 17:11:10 2010 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 D62BE106566B; Tue, 9 Nov 2010 17:11:10 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id BB0158FC14; Tue, 9 Nov 2010 17:11:10 +0000 (UTC) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 942D95B89; Tue, 9 Nov 2010 09:04:53 -0800 (PST) To: Julian Elischer In-reply-to: Your message of "Tue, 09 Nov 2010 08:45:14 PST." <4CD97A9A.8000007@freebsd.org> References: <4CD97A9A.8000007@freebsd.org> Comments: In-reply-to Julian Elischer message dated "Tue, 09 Nov 2010 08:45:14 -0800." Date: Tue, 09 Nov 2010 09:04:53 -0800 From: Bakul Shah Message-Id: <20101109170453.942D95B89@mail.bitblocks.com> Cc: alc@freebsd.org, FreeBSD Current Subject: Re: limits to memory on 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: Tue, 09 Nov 2010 17:11:10 -0000 On Tue, 09 Nov 2010 08:45:14 PST Julian Elischer wrote: > During the discussion at MeetBSD the question came up as to what the real > limiting factors were with regard to how much RAM a system could have. > it was put to us that the limit was currently around 512 GB, though no-one > at teh discussion knew what the mechanism of the limitation was or > what might ligh beyond it. > > Could anyone who knows, pipe upt and let use know what the factors are, > and if the current limit is overcome, what the next one after that will be? You mean beyond architectural limits? >From Wikipedia: Larger physical address space: The original implementation of the AMD64 architecture implemented 40-bit physical addresses and so could address up to 1 TB (2^40 bytes) of RAM. Current implementations of the AMD64 architecture (starting from AMD 10h microarchitecture) extend this to 48-bit physical addresses and therefore can address up to 256 TB of RAM. The architecture permits extending this to 52 bits in the future (limited by the page table entry format); this would allow addressing of up to 4 PB of RAM. From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 17:13:25 2010 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 D4648106566B; Tue, 9 Nov 2010 17:13:25 +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 E77AF8FC21; Tue, 9 Nov 2010 17:13:24 +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 TAA28662; Tue, 09 Nov 2010 19:13:20 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CD98130.6020705@freebsd.org> Date: Tue, 09 Nov 2010 19:13:20 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Alexander Motin References: <4CD97F04.6010009@FreeBSD.org> In-Reply-To: <4CD97F04.6010009@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: current Subject: Re: ATA: driver bug: Unable to set devclass 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, 09 Nov 2010 17:13:25 -0000 on 09/11/2010 19:04 Alexander Motin said the following: > Andriy Gapon wrote: >> Since one of the recent updates (not sure which revision though) I started to get >> "Unable to set devclass" messages in boot dmesg. I'd say that I see the message >> every other boot, i.e. not always. >> >> I added some more debug code there and here's a tack trace: >> >> driver bug: Unable to set devclass (child = 0xffffff00070d0100, devname: (null)) >> #0 0xffffffff803ae127 at device_probe_child+0x127 >> #1 0xffffffff803ae40c at device_probe+0x7c >> #2 0xffffffff803ae4a1 at device_probe_and_attach+0x11 >> #3 0xffffffff803ae56a at bus_generic_attach+0x1a >> #4 0xffffffff801df93c at ata_identify+0x2ec >> #5 0xffffffff801dfcdb at ata_boot_attach+0x6b >> #6 0xffffffff803a8577 at run_interrupt_driven_config_hooks+0xf7 >> #7 0xffffffff803a8993 at boot_run_interrupt_driven_config_hooks+0x23 >> #8 0xffffffff8032f227 at mi_startup+0xc7 >> #9 0xffffffff801719cc at btext+0x2c >> >> >From kgdb: >> (kgdb) p *(device_t)0xffffff00070d0100 >> $1 = {ops = 0xffffff0001b07000, link = {tqe_next = 0xffffff0001a65100, tqe_prev = >> 0xffffff0006eb0130}, devlink = {tqe_next = 0xffffff0001a65100, tqe_prev = >> 0xffffff000706e318}, >> parent = 0xffffff0006eb0100, children = {tqh_first = 0xffffff0001a5b200, >> tqh_last = 0xffffff0001a5b208}, driver = 0xffffffff8079bc80, devclass = >> 0xffffff0001add080, unit = 0, >> nameunit = 0xffffff00070931a0 "ad0", desc = 0xffffff000711e7c0 >> "ST3320620A/3.AAF", busy = 0, state = DS_ATTACHED, devflags = 0, flags = 89, order >> = 0, ivars = 0xffffff000711e5e0, >> softc = 0xffffff000706a400, sysctl_ctx = {tqh_first = 0xffffff000711e600, >> tqh_last = 0xffffff000711e708}, sysctl_tree = 0xffffff00070f9500} >> >> Apparently sometimes something happens too soon? :-) > > What controller is there? Any other differences/interesting things in > verbose dmesg? Any new "CONNECT requested" messages or anything else? It's SB700 integrated controller (ATI IXP700/800 UDMA133 controller). This happens during boot, there are no other unusual ata-related messages. I have device ahci in kernel, but no ATA_CAM option, so PATA stuff works via "pure" ata code. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 17:20:41 2010 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 6545A106566C; Tue, 9 Nov 2010 17:20:41 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (outv.internet-mail-service.net [216.240.47.245]) by mx1.freebsd.org (Postfix) with ESMTP id E89B18FC21; Tue, 9 Nov 2010 17:20:40 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oA9HKcjq014132; Tue, 9 Nov 2010 09:20:39 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id C260B2D6011; Tue, 9 Nov 2010 09:20:37 -0800 (PST) Message-ID: <4CD982E9.70500@freebsd.org> Date: Tue, 09 Nov 2010 09:20:41 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Bakul Shah References: <4CD97A9A.8000007@freebsd.org> <20101109170453.942D95B89@mail.bitblocks.com> In-Reply-To: <20101109170453.942D95B89@mail.bitblocks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: alc@freebsd.org, FreeBSD Current Subject: Re: limits to memory on 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: Tue, 09 Nov 2010 17:20:41 -0000 On 11/9/10 9:04 AM, Bakul Shah wrote: > On Tue, 09 Nov 2010 08:45:14 PST Julian Elischer wrote: >> During the discussion at MeetBSD the question came up as to what the real >> limiting factors were with regard to how much RAM a system could have. >> it was put to us that the limit was currently around 512 GB, though no-one >> at teh discussion knew what the mechanism of the limitation was or >> what might ligh beyond it. >> >> Could anyone who knows, pipe upt and let use know what the factors are, >> and if the current limit is overcome, what the next one after that will be? > You mean beyond architectural limits? no, though of course they are relevant. I was thinking more of details like limits to the KVM space or any limitations there may be on the size of the direct-map region, or maybe some limit on some data structure size in the kernel. Since I don 't know the details, this is exactly the question.. what IS the limit? > > From Wikipedia: > > Larger physical address space: The original > implementation of the AMD64 architecture implemented > 40-bit physical addresses and so could address up to 1 TB > (2^40 bytes) of RAM. Current implementations of the AMD64 > architecture (starting from AMD 10h microarchitecture) > extend this to 48-bit physical addresses and therefore > can address up to 256 TB of RAM. The architecture permits > extending this to 52 bits in the future (limited by the > page table entry format); this would allow addressing of > up to 4 PB of RAM. > From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 17:45:43 2010 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 C1A591065673 for ; Tue, 9 Nov 2010 17:45:43 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (unknown [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 472A48FC19 for ; Tue, 9 Nov 2010 17:45:43 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 6B5322A28CEA; Tue, 9 Nov 2010 18:45:42 +0100 (CET) Date: Tue, 9 Nov 2010 18:45:42 +0100 From: Ed Schouten To: Renato Botelho Message-ID: <20101109174542.GM2054@hoeg.nl> References: <20101109100319.GV2054@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UZwaptqO+BtzVOeY" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Eir Nym , FreeBSD Mail Lists Subject: Re: Syscons and termcap 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, 09 Nov 2010 17:45:43 -0000 --UZwaptqO+BtzVOeY Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Renato Botelho , 20101109 17:08: > Well, few weeks ago I moved from ISO-8859-1 to UTF-8 on my Xorg > environment, and after reading this I decided to make a test. >=20 > I rebuilt my 9.0-current (r215031) with option TEKEN_UTF8 in kernel > config, and after configure my syscons to use cp850-* fonts i can > see UTF-8 chars properly \o/ Well, the point here is that it just performs some really hackish translation to CP437, not CP850, on the output path. It is really not robust. Copy-pasting is also broken because of it, because it pastes CP437 characters. > The only thing i cannot do here is to type chars with accent like =E1=E9 > on console, because it seems to don't respect deadkeys, when I > press ' the char ' is show and never wait the next char to compose > a new one when necessary. Is it a knwon issue or i'm doing > something wrong? This is a known issue, since there is no translation from Unicode code points to UTF-8 sequences. In other words, if you press =EB, the keyboard layer will properly send a 235 to Syscons, but instead of encoding it as 0xC3 0xA9, will just emit a single byte, having value 0xE9. Maybe a patch like this could already get that working, but it's just a quick hack. http://80386.nl/pub/syscons-utf8.txt Greetings, --=20 Ed Schouten WWW: http://80386.nl/ --UZwaptqO+BtzVOeY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkzZiMYACgkQ52SDGA2eCwX9mwCePYMo6g9ZpNm6i4Co6R8sWxaT r9IAnR3YMLIPIyI5BRiNUMFVRfunJjB0 =2SLm -----END PGP SIGNATURE----- --UZwaptqO+BtzVOeY-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 17:59:00 2010 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 B23E01065670 for ; Tue, 9 Nov 2010 17:59:00 +0000 (UTC) (envelope-from gljennjohn@googlemail.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 6434A8FC18 for ; Tue, 9 Nov 2010 17:59:00 +0000 (UTC) Received: by gwj16 with SMTP id 16so4682567gwj.13 for ; Tue, 09 Nov 2010 09:58:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=Enyhg3EK0K6/IqG9q+iq+xFPF6D2NxztYyXNsgCggFY=; b=dlrawQbMI7L34dcpcPhebVGGmA9cIL5buZPjJU6Rt25NSNG/HHBWSr9lmTEX4Uv3Ex YnkmpydBz94YUaTsRZXy8XaJlRUo0HufUQb7UysCjE+IwQ5FRMB80/yDBZ3yfnMW5Efn 8bpSjIBxaNRvLPDt7JC1ZjIikxpi0OHfTFm8A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=FlbtiLPyffIH8qWiBH9Pwy8HSy0fxE8+i5sVIWpo+V027S27lyWPPu3sNk1T7eAnZb r6yYbJecNpWE19mBILVOLG3ymw6eld05AcAqVomebDJRrewgAHw9WhuCeB1dEfrV94hl RFprIc87zRCnhRXrxzK+6fUVc5dzGGalrOrM8= Received: by 10.223.70.139 with SMTP id d11mr2652245faj.36.1289325538755; Tue, 09 Nov 2010 09:58:58 -0800 (PST) Received: from ernst.jennejohn.org (p578E2049.dip.t-dialin.net [87.142.32.73]) by mx.google.com with ESMTPS id k21sm833395faa.25.2010.11.09.09.58.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Nov 2010 09:58:57 -0800 (PST) Date: Tue, 9 Nov 2010 18:58:55 +0100 From: Gary Jennejohn To: Renato Botelho Message-ID: <20101109185855.38586eb2@ernst.jennejohn.org> In-Reply-To: References: <20101109100319.GV2054@hoeg.nl> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Ed Schouten , Eir Nym , FreeBSD, Lists Subject: Re: Syscons and termcap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 17:59:00 -0000 On Tue, 9 Nov 2010 14:08:01 -0200 Renato Botelho wrote: [snip stuff from Ed] > Well, few weeks ago I moved from ISO-8859-1 to UTF-8 on my Xorg > environment, and after reading this I decided to make a test. > > I rebuilt my 9.0-current (r215031) with option TEKEN_UTF8 in kernel > config, and after configure my syscons to use cp850-* fonts i can > see UTF-8 chars properly \o/ > > The only thing i cannot do here is to type chars with accent like áé > on console, because it seems to don't respect deadkeys, when I > press ' the char ' is show and never wait the next char to compose > a new one when necessary. Is it a knwon issue or i'm doing > something wrong? > > I'm using us.iso.kbd > This may seem like a stupid comment, but I'd say that the "iso" does not imply UTF-8 support. In fact, there seem to be only ISO or code page keymaps under /usr/share/syscons/keymaps. But I'm no keymap expert. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 17:59:05 2010 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 F1F5B106572E; Tue, 9 Nov 2010 17:59:05 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh4.mail.rice.edu (mh4.mail.rice.edu [128.42.199.11]) by mx1.freebsd.org (Postfix) with ESMTP id BC6A58FC1D; Tue, 9 Nov 2010 17:59:05 +0000 (UTC) Received: from mh4.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh4.mail.rice.edu (Postfix) with ESMTP id 197C728F7F0; Tue, 9 Nov 2010 11:59:05 -0600 (CST) X-Virus-Scanned: by amavis-2.6.4 at mh4.mail.rice.edu, auth channel Received: from mh4.mail.rice.edu ([127.0.0.1]) by mh4.mail.rice.edu (mh4.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id j7-SWtG-nMk8; Tue, 9 Nov 2010 11:59:05 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh4.mail.rice.edu (Postfix) with ESMTPSA id 832E628F7EA; Tue, 9 Nov 2010 11:59:04 -0600 (CST) Message-ID: <4CD98BE7.7030208@rice.edu> Date: Tue, 09 Nov 2010 11:59:03 -0600 From: Alan Cox User-Agent: Thunderbird 2.0.0.24 (X11/20100725) MIME-Version: 1.0 To: Julian Elischer References: <4CD97A9A.8000007@freebsd.org> <20101109170453.942D95B89@mail.bitblocks.com> <4CD982E9.70500@freebsd.org> In-Reply-To: <4CD982E9.70500@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 09 Nov 2010 18:08:38 +0000 Cc: alc@freebsd.org, FreeBSD Current Subject: Re: limits to memory on 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: Tue, 09 Nov 2010 17:59:06 -0000 Julian Elischer wrote: > On 11/9/10 9:04 AM, Bakul Shah wrote: >> On Tue, 09 Nov 2010 08:45:14 PST Julian >> Elischer wrote: >>> During the discussion at MeetBSD the question came up as to what the >>> real >>> limiting factors were with regard to how much RAM a system could have. >>> it was put to us that the limit was currently around 512 GB, though >>> no-one >>> at teh discussion knew what the mechanism of the limitation was or >>> what might ligh beyond it. >>> >>> Could anyone who knows, pipe upt and let use know what the factors are, >>> and if the current limit is overcome, what the next one after that >>> will be? >> You mean beyond architectural limits? > > no, though of course they are relevant. > I was thinking more of details like limits to the KVM space or > any limitations there may be on the size of the direct-map region, > or maybe some limit on some data structure size in the kernel. > Since I don 't know the details, this is exactly the question.. > what IS the limit? The changes to support more than 512GB RAM should be straightforward. Off the top of my head, it will require some constant definitions in vmparam.h to change, and the allocation of some additional PDP-level page table pages in create_pagetables(). In contrast, the changes to break the original 2GB KVM barrier involved touching a number of different places in the kernel. Alan From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 18:12:30 2010 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 21D391065673 for ; Tue, 9 Nov 2010 18:12:30 +0000 (UTC) (envelope-from rbgarga@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 A6C098FC15 for ; Tue, 9 Nov 2010 18:12:29 +0000 (UTC) Received: by wwb13 with SMTP id 13so293061wwb.31 for ; Tue, 09 Nov 2010 10:12:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=sU2ZsRtOAW2stbUl42SnS7q2ek50InC24PoFtdVDa2U=; b=KXwuUAVgWrl4EY0hOrhGzwtZqNFDhkydmmBOQlG+yuxeU8ysCwmHGGHNXDeqJaWVGr 0lzXSlaVIB0xblE95yAwBH1lna4fAGZFZiJO962f1UFGoD/KolmFmMuKLgLQNVRxsjA4 Z+QEJ3wJc0aXU/FOTWGIWAFE91IUqlr27zSlM= 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=l3xuPIApuuRsr3Atylm9LdEoZJUa8MUlGQ6fm6TzVIKoMYdxk41er178ScGHyxp6zw 2SuV4DwsBVFvUpn4dKgj2G0Nm34mQ2Nj+Dxex3MiYZ2anRXRb7xoNPx+XTQUMUZCE7C7 /wXiyxzQQny0mWzuqtGbO/JPKnrtQdGpbPSyc= Received: by 10.227.134.142 with SMTP id j14mr7070200wbt.228.1289326346793; Tue, 09 Nov 2010 10:12:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.182.10 with HTTP; Tue, 9 Nov 2010 10:12:04 -0800 (PST) In-Reply-To: <20101109174542.GM2054@hoeg.nl> References: <20101109100319.GV2054@hoeg.nl> <20101109174542.GM2054@hoeg.nl> From: Renato Botelho Date: Tue, 9 Nov 2010 16:12:04 -0200 Message-ID: To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Eir Nym , FreeBSD Mail Lists Subject: Re: Syscons and termcap 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, 09 Nov 2010 18:12:30 -0000 On Tue, Nov 9, 2010 at 3:45 PM, Ed Schouten wrote: > * Renato Botelho , 20101109 17:08: >> Well, few weeks ago I moved from ISO-8859-1 to UTF-8 on my Xorg >> environment, and after reading this I decided to make a test. >> >> I rebuilt my 9.0-current (r215031) with option TEKEN_UTF8 in kernel >> config, and after configure my syscons to use cp850-* fonts i can >> see UTF-8 chars properly \o/ > > Well, the point here is that it just performs some really hackish > translation to CP437, not CP850, on the output path. It is really not > robust. Copy-pasting is also broken because of it, because it pastes > CP437 characters. OK, i changed my fonts to cp437. >> The only thing i cannot do here is to type chars with accent like =E1=E9 >> on console, because it seems to don't respect deadkeys, when I >> press ' the char ' is show and never wait the next char to compose >> a new one when necessary. Is it a knwon issue or i'm doing >> something wrong? > > This is a known issue, since there is no translation from Unicode code > points to UTF-8 sequences. In other words, if you press =EB, the keyboard > layer will properly send a 235 to Syscons, but instead of encoding it as > 0xC3 0xA9, will just emit a single byte, having value 0xE9. > > Maybe a patch like this could already get that working, but it's just a > quick hack. > > =A0 =A0 =A0 =A0http://80386.nl/pub/syscons-utf8.txt It had no effect on console but, i don't know why, screwed up my Xorg keymap, some meta keys (Mod4) stop working even if I run a setxkbmap like this: /usr/local/bin/setxkbmap -rules xorg -symbols "pc(pc105)+sun_vndr/usb(sun_usb)+pc(pc105)+us(intl)" Now i back old kernel and everything is working fine. It's not something I need, but would be nice to have console working with UTF-8 and accent keys :) --=20 Renato Botelho From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 18:14:53 2010 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 EB13A1065674; Tue, 9 Nov 2010 18:14:52 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8AE898FC18; Tue, 9 Nov 2010 18:14:52 +0000 (UTC) Received: by yxf34 with SMTP id 34so116375yxf.13 for ; Tue, 09 Nov 2010 10:14:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received: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=aIEBIX+J5I2X/qKgklk8miz5HGAJTbl7IFB8KPS8jK4=; b=GLAPK1a3RfoshbGL2j06xl4U2C2oscbzEKNu5SPB7yuYEJ0wg8KYMxUmv2Dq/Qd4wC DJp+WeDIHAt0AhpBWNN3WUK0/g/BPE6rPgjECygRE+eHu9ROzuIT6Op+q1408DNVbfFC LMnhfYO2y0AOcJf6Yhhf7DerYCqQxommzuyj8= 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=nH7dSODcmV6GOvGkM0iOuZyd1XMd9Zj+vtF+j+15EogssYCoETxgIIPZBVHAlNOL6Q mSonTXvShVTFYHH3g/D+ZW7LeSzasF1r4JE9qz0Vr9+XwKAEotJFqqHv409muDrID+2f MWh21IovFa2rCgbp79RMmmJD2FPpEVNGo04ew= Received: by 10.204.68.142 with SMTP id v14mr6646251bki.106.1289326490998; Tue, 09 Nov 2010 10:14:50 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id t10sm1235771bkj.16.2010.11.09.10.14.48 (version=SSLv3 cipher=RC4-MD5); Tue, 09 Nov 2010 10:14:49 -0800 (PST) Sender: Alexander Motin Message-ID: <4CD98F84.10907@FreeBSD.org> Date: Tue, 09 Nov 2010 20:14:28 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Andriy Gapon References: <4CD97F04.6010009@FreeBSD.org> <4CD98130.6020705@freebsd.org> In-Reply-To: <4CD98130.6020705@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: current Subject: Re: ATA: driver bug: Unable to set devclass 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, 09 Nov 2010 18:14:53 -0000 Andriy Gapon wrote: > on 09/11/2010 19:04 Alexander Motin said the following: >> Andriy Gapon wrote: >>> Since one of the recent updates (not sure which revision though) I started to get >>> "Unable to set devclass" messages in boot dmesg. I'd say that I see the message >>> every other boot, i.e. not always. >>> >>> I added some more debug code there and here's a tack trace: >>> >>> driver bug: Unable to set devclass (child = 0xffffff00070d0100, devname: (null)) >>> #0 0xffffffff803ae127 at device_probe_child+0x127 >>> #1 0xffffffff803ae40c at device_probe+0x7c >>> #2 0xffffffff803ae4a1 at device_probe_and_attach+0x11 >>> #3 0xffffffff803ae56a at bus_generic_attach+0x1a >>> #4 0xffffffff801df93c at ata_identify+0x2ec >>> #5 0xffffffff801dfcdb at ata_boot_attach+0x6b >>> #6 0xffffffff803a8577 at run_interrupt_driven_config_hooks+0xf7 >>> #7 0xffffffff803a8993 at boot_run_interrupt_driven_config_hooks+0x23 >>> #8 0xffffffff8032f227 at mi_startup+0xc7 >>> #9 0xffffffff801719cc at btext+0x2c >>> >>> >From kgdb: >>> (kgdb) p *(device_t)0xffffff00070d0100 >>> $1 = {ops = 0xffffff0001b07000, link = {tqe_next = 0xffffff0001a65100, tqe_prev = >>> 0xffffff0006eb0130}, devlink = {tqe_next = 0xffffff0001a65100, tqe_prev = >>> 0xffffff000706e318}, >>> parent = 0xffffff0006eb0100, children = {tqh_first = 0xffffff0001a5b200, >>> tqh_last = 0xffffff0001a5b208}, driver = 0xffffffff8079bc80, devclass = >>> 0xffffff0001add080, unit = 0, >>> nameunit = 0xffffff00070931a0 "ad0", desc = 0xffffff000711e7c0 >>> "ST3320620A/3.AAF", busy = 0, state = DS_ATTACHED, devflags = 0, flags = 89, order >>> = 0, ivars = 0xffffff000711e5e0, >>> softc = 0xffffff000706a400, sysctl_ctx = {tqh_first = 0xffffff000711e600, >>> tqh_last = 0xffffff000711e708}, sysctl_tree = 0xffffff00070f9500} >>> >>> Apparently sometimes something happens too soon? :-) >> What controller is there? Any other differences/interesting things in >> verbose dmesg? Any new "CONNECT requested" messages or anything else? > > It's SB700 integrated controller (ATI IXP700/800 UDMA133 controller). > This happens during boot, there are no other unusual ata-related messages. > I have device ahci in kernel, but no ATA_CAM option, so PATA stuff works via > "pure" ata code. Hmm. There was not much changes in ATA last time and I can't expect what of them could affect PATA. Probe code wasn't changed for long time. This check was actually added after some ata(4) bug found two years ago. So I am not sure your problem is something new. May be something else just triggered it again. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 18:18:01 2010 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 BC9D31065670 for ; Tue, 9 Nov 2010 18:18:01 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (unknown [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 7AF328FC20 for ; Tue, 9 Nov 2010 18:18:01 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id D71A42A28CEA; Tue, 9 Nov 2010 19:18:00 +0100 (CET) Date: Tue, 9 Nov 2010 19:18:00 +0100 From: Ed Schouten To: Gary Jennejohn Message-ID: <20101109181800.GN2054@hoeg.nl> References: <20101109100319.GV2054@hoeg.nl> <20101109185855.38586eb2@ernst.jennejohn.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NKVD0s4KxL2BHkeN" Content-Disposition: inline In-Reply-To: <20101109185855.38586eb2@ernst.jennejohn.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Renato Botelho , Eir Nym , FreeBSD Mail Lists Subject: Re: Syscons and termcap 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, 09 Nov 2010 18:18:01 -0000 --NKVD0s4KxL2BHkeN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Gary Jennejohn , 20101109 18:58: > This may seem like a stupid comment, but I'd say that the "iso" does > not imply UTF-8 support. In fact, there seem to be only ISO or code > page keymaps under /usr/share/syscons/keymaps. But I'm no keymap > expert. Well, the funny thing about Unicode is that the first 256 codepoints are equal to ISO-8859-1, so if you recode ISO-8859-1 to the multibyte representation of UTF-8, it all works. This is why you could use such a keymap without issues. --=20 Ed Schouten WWW: http://80386.nl/ --NKVD0s4KxL2BHkeN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkzZkFgACgkQ52SDGA2eCwXD0gCfUIEzGfcc1c1IaTNvT5EAnwVn 1kQAnjH5ABV92g7w5fGTxY8eMxVjFgjO =WxNw -----END PGP SIGNATURE----- --NKVD0s4KxL2BHkeN-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 18:21:52 2010 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 0157A1065674; Tue, 9 Nov 2010 18:21:52 +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 0063E8FC25; Tue, 9 Nov 2010 18:21:50 +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 UAA29498; Tue, 09 Nov 2010 20:21:49 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CD9913D.4050401@freebsd.org> Date: Tue, 09 Nov 2010 20:21:49 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Alexander Motin References: <4CD97F04.6010009@FreeBSD.org> <4CD98130.6020705@freebsd.org> <4CD98F84.10907@FreeBSD.org> In-Reply-To: <4CD98F84.10907@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: current Subject: Re: ATA: driver bug: Unable to set devclass 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, 09 Nov 2010 18:21:52 -0000 on 09/11/2010 20:14 Alexander Motin said the following: > Hmm. There was not much changes in ATA last time and I can't expect what > of them could affect PATA. Probe code wasn't changed for long time. > > This check was actually added after some ata(4) bug found two years ago. > So I am not sure your problem is something new. May be something else > just triggered it again. Added some more debugging code, will try to get more info. Thanks! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 18:25:12 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id EBD72106566B; Tue, 9 Nov 2010 18:25:12 +0000 (UTC) Date: Tue, 9 Nov 2010 18:25:12 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20101109182512.GA16204@freebsd.org> References: <20101030232244.GA35209@freebsd.org> <20101105214700.GT85693@acme.spoerlein.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20101105214700.GT85693@acme.spoerlein.net> Cc: Subject: Re: issue with "options DDB" 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, 09 Nov 2010 18:25:13 -0000 On Fri Nov 5 10, Ulrich Spörlein wrote: > On Sat, 30.10.2010 at 23:22:44 +0000, Alexander Best wrote: > > hi there, > > > > with "options DDB" in my kernel conf i run into the following issue with my > > kernel modules: > > > > link_elf_lookup_symbol: missing symbol hash table > > KLD file snd_hda.ko is missing dependencies > > KLD file sound.ko is missing dependencies > > KLD file nvidia.ko is missing dependencies > > KLD file linux.ko is missing dependencies > > KLD file ng_ubt.ko is missing dependencies > > KLD file ng_hci.ko is missing dependencies > > KLD file ng_bluetooth.ko is missing dependencies > > KLD file netgraph.ko is missing dependencies > > link_elf_lookup_symbol: missing symbol hash table > > > > removing the option solves the issue. any advice? > > > > cheers. > > alex > > > > ps: i'm running HEAD (r214542; amd64). > > You failed to mention the command that you run. I assume 'buildkernel'? > Please note that you need and update-to-date "buildworld" for the kernel > tools to be there, so please try the following (with options DDB): > > cd /usr/src > make clean; make cleandir; make clean > make buildworld > make buildkernel KERNCONF=YOURKERNEL hmmm....seems there is a problem with gcc. this is what i get during buildworld: clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector -fconserve-space -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/tinfo2.cc clang++: warning: argument unused during compilation: '-fconserve-space' clang++: warning: argument unused during compilation: '-fno-implicit-templates' clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector -fconserve-space -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vec.cc clang++: warning: argument unused during compilation: '-fconserve-space' clang++: warning: argument unused during compilation: '-fno-implicit-templates' clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector -fconserve-space -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vterminate.cc clang++: warning: argument unused during compilation: '-fconserve-space' clang++: warning: argument unused during compilation: '-fno-implicit-templates' clang -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -std=gnu99 -fstack-protector -c /usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/libiberty/cp-demangle.c building static supc++ library ranlib libsupc++.a ===> gnu/lib/libobjc (all) gcc -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DHAVE_GTHR_DEFAULT -DIN_GCC -DIN_TARGET_LIBS -I. -I/usr/src/gnu/lib/libobjc/../../usr.bin/cc/cc_tools -I/usr/src/gnu/lib/libobjc/../../../contrib/libobjc/objc -I/usr/src/gnu/lib/libobjc/../../../contrib/libobjc -I/usr/src/gnu/lib/libobjc/../../../contrib/gcc/config -I/usr/src/gnu/lib/libobjc/../../../contrib/gcc -I/usr/src/gnu/lib/libobjc/../../../contrib/gcclibs/include -fexceptions -frandom-seed=RepeatabilityConsideredGood -g -std=gnu99 -fstack-protector -c /usr/src/gnu/lib/libobjc/../../../contrib/libobjc/archive.c *** Signal 11 Stop in /usr/src/gnu/lib/libobjc. *** Error code 1 Stop in /usr/src/gnu/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. i've ran buildworld twice (with a clean /usr/src and non-existing /usr/obj/*) and got the error twice, so it's not a hardware problem it seems. if i'm not mistaken the gcc that is being used for buildworld is not the one in /usr/bin, but a fresh build in /usr/obj, right? this is the bt from "gdb /usr/obj/usr/src/tmp/usr/bin/gcc gcc.core". i hope i picked the correct gcc executable: Core was generated by `gcc'. Program terminated with signal 11, Segmentation fault. #0 host_detect_local_cpu (argc=Variable "argc" is not available. ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/config/i386/driver-i386.c:272 272 return concat ("-m", argv[0], "=", cpu, NULL); (gdb) bt #0 host_detect_local_cpu (argc=Variable "argc" is not available. ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/config/i386/driver-i386.c:272 #1 0x000000000040c754 in eval_spec_function (func=Cannot access memory at address 0x0 ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5520 #2 0x00000000004093f2 in do_spec_1 (spec=Variable "spec" is not available. ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5591 #3 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 #4 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 #5 0x0000000000409398 in do_spec_1 (spec=Variable "spec" is not available. ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5413 #6 0x0000000000409545 in do_spec_1 (spec=Variable "spec" is not available. ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5193 #7 0x0000000000409398 in do_spec_1 (spec=Variable "spec" is not available. ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5413 #8 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 #9 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 #10 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 #11 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 #12 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 #13 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 #14 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 #15 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 #16 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 #17 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 #18 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 #19 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 #20 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 #21 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 #22 0x00000000004003ec in do_spec_2 (spec=0x1
) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:4490 #23 0x000000000040033d in do_spec (spec=0x1
) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:4458 #24 0x00000000004036d1 in main (argc=23, argv=0x7fffffffe240) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:6712 cheers. alex > > If it fails again, try > env __MAKE_CONF=/dev/null make buildkernel KERNCONF=YOURKERNEL > > Oh, and the actual kernel config might help as well. > > hth > Uli -- a13x From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 18:45:13 2010 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 4597F1065670; Tue, 9 Nov 2010 18:45:13 +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 5D7C58FC26; Tue, 9 Nov 2010 18:45:11 +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 UAA29771; Tue, 09 Nov 2010 20:45:03 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CD996AF.2070300@freebsd.org> Date: Tue, 09 Nov 2010 20:45:03 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Alan Cox References: <4CA0DA49.2090006@freebsd.org> <4CA3A48A.5070300@freebsd.org> <4CA3BD1E.5070807@rice.edu> <4CA5911E.3000101@freebsd.org> <4CAE0060.7050607@freebsd.org> <4CAECC4D.90707@rice.edu> <4CD1AA45.7000504@freebsd.org> <4CD1AD80.2090903@rice.edu> <4CD1D4AA.3060309@freebsd.org> <4CD8FFFF.3070106@rice.edu> In-Reply-To: <4CD8FFFF.3070106@rice.edu> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Alan Cox , freebsd-current@freebsd.org Subject: Re: minidump size on 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: Tue, 09 Nov 2010 18:45:13 -0000 on 09/11/2010 10:02 Alan Cox said the following: > The kernel portion of the patch looks correct. If I were to make one stylistic > suggestion, it would be to make the control flow of the outer and inner loops as > similar as possible, that is, > > for (... > if ((pdp[i] & PG_V) == 0) { > ... > continue; > } > if ((pdp[i] & PG_PS) != 0) { > ... > continue; > } > for (... > if ((pd[j] & PG_V) == 0) > continue; > if ((pd[j] & PG_PS) != 0) { > ... > continue; > } > for (... > if ((pt[x] & PG_V) == 0) > continue; > ... > > I think this would make the code a little easier to follow. This is a very nice suggestion, thank you. Besides the uniformity some horizontal space is saved too :-) Updated patch (only kernel part) is here: http://people.freebsd.org/~avg/amd64-minidump.5.diff -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 19:17:08 2010 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 7C8AF1065679; Tue, 9 Nov 2010 19:17:08 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (outx.internet-mail-service.net [216.240.47.247]) by mx1.freebsd.org (Postfix) with ESMTP id 5ABD68FC25; Tue, 9 Nov 2010 19:17:08 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oA9JH5hV019398; Tue, 9 Nov 2010 11:17:05 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id BA8282D6015; Tue, 9 Nov 2010 11:17:04 -0800 (PST) Message-ID: <4CD99E34.10002@freebsd.org> Date: Tue, 09 Nov 2010 11:17:08 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Alan Cox References: <4CD97A9A.8000007@freebsd.org> <20101109170453.942D95B89@mail.bitblocks.com> <4CD982E9.70500@freebsd.org> <4CD98BE7.7030208@rice.edu> In-Reply-To: <4CD98BE7.7030208@rice.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: alc@freebsd.org, sbruno@freebsd.org, FreeBSD Current Subject: Re: limits to memory on 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: Tue, 09 Nov 2010 19:17:08 -0000 On 11/9/10 9:59 AM, Alan Cox wrote: > Julian Elischer wrote: >> On 11/9/10 9:04 AM, Bakul Shah wrote: >>> On Tue, 09 Nov 2010 08:45:14 PST Julian >>> Elischer wrote: >>>> During the discussion at MeetBSD the question came up as to what >>>> the real >>>> limiting factors were with regard to how much RAM a system could >>>> have. >>>> it was put to us that the limit was currently around 512 GB, >>>> though no-one >>>> at teh discussion knew what the mechanism of the limitation was or >>>> what might ligh beyond it. >>>> >>>> Could anyone who knows, pipe upt and let use know what the >>>> factors are, >>>> and if the current limit is overcome, what the next one after >>>> that will be? >>> You mean beyond architectural limits? >> >> no, though of course they are relevant. >> I was thinking more of details like limits to the KVM space or >> any limitations there may be on the size of the direct-map region, >> or maybe some limit on some data structure size in the kernel. >> Since I don 't know the details, this is exactly the question.. >> what IS the limit? > > The changes to support more than 512GB RAM should be > straightforward. Off the top of my head, it will require some > constant definitions in vmparam.h to change, and the allocation of > some additional PDP-level page table pages in create_pagetables(). > In contrast, the changes to break the original 2GB KVM barrier > involved touching a number of different places in the kernel. Alan, since some people (e.g. Sean Bruno) were hitting this, do you think you could provide a patch to allow people to test this? Sean in Particular seemed keen to try go to 1TB ram in a machine he had access to. Julian > > Alan > > > > From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 20:06:16 2010 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 35F8810656A3; Tue, 9 Nov 2010 20:06:16 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id D42418FC24; Tue, 9 Nov 2010 20:06:15 +0000 (UTC) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id DF7ED5AC93; Tue, 9 Nov 2010 20:46:06 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id DCC2D5AC92; Tue, 9 Nov 2010 20:46:06 +0100 (CET) X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id BA3105CD43; Tue, 9 Nov 2010 20:46:06 +0100 (CET) Received: from wep4035.physik.uni-wuerzburg.de ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.5.2HF105) with ESMTP id 2010110920460609-91105 ; Tue, 9 Nov 2010 20:46:06 +0100 Date: Tue, 9 Nov 2010 20:46:05 +0100 From: Alexey Shuvaev To: Alexander Best Message-ID: <20101109194605.GB45046@wep4035.physik.uni-wuerzburg.de> References: <20101030232244.GA35209@freebsd.org> <20101105214700.GT85693@acme.spoerlein.net> <20101109182512.GA16204@freebsd.org> MIME-Version: 1.0 In-Reply-To: <20101109182512.GA16204@freebsd.org> Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.21 (2010-09-15) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.5.2HF105 | October 15, 2010) at 11/09/2010 08:46:06 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.5.2HF105 | October 15, 2010) at 11/09/2010 08:46:06 PM Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: issue with "options DDB" 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, 09 Nov 2010 20:06:16 -0000 On Tue, Nov 09, 2010 at 06:25:12PM +0000, Alexander Best wrote: > On Fri Nov 5 10, Ulrich Sp=F6rlein wrote: > > On Sat, 30.10.2010 at 23:22:44 +0000, Alexander Best wrote: > > > hi there, > > >=20 > > > with "options DDB" in my kernel conf i run into the following issue w= ith my > > > kernel modules: > > >=20 > > > link=5Felf=5Flookup=5Fsymbol: missing symbol hash table > > > KLD file snd=5Fhda.ko is missing dependencies > > > KLD file sound.ko is missing dependencies > > > KLD file nvidia.ko is missing dependencies > > > KLD file linux.ko is missing dependencies > > > KLD file ng=5Fubt.ko is missing dependencies > > > KLD file ng=5Fhci.ko is missing dependencies > > > KLD file ng=5Fbluetooth.ko is missing dependencies > > > KLD file netgraph.ko is missing dependencies > > > link=5Felf=5Flookup=5Fsymbol: missing symbol hash table > > >=20 > > > removing the option solves the issue. any advice? > > >=20 > > > cheers. > > > alex > > >=20 > > > ps: i'm running HEAD (r214542; amd64). > >=20 > > You failed to mention the command that you run. I assume 'buildkernel'? > > Please note that you need and update-to-date "buildworld" for the kernel > > tools to be there, so please try the following (with options DDB): > >=20 > > cd /usr/src > > make clean; make cleandir; make clean > > make buildworld > > make buildkernel KERNCONF=3DYOURKERNEL >=20 > hmmm....seems there is a problem with gcc. this is what i get during > buildworld: >=20 >=20 > clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=3Dnative -DI= N=5FGLIBCPP=5FV3 -DHAVE=5FCONFIG=5FH -I/usr/src/gnu/lib/libsupc++/../../../= contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libst= dc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src= /gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=3DRepeatabilityConsidered= Good -g -fstack-protector -fconserve-space -fno-implicit-templates -ffuncti= on-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../contrib/= libstdc++/libsupc++/tinfo2.cc > clang++: warning: argument unused during compilation: '-fconserve-space' ^^^^^^^^^^^ > clang++: warning: argument unused during compilation: '-fno-implicit-temp= lates' > clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=3Dnative -DI= N=5FGLIBCPP=5FV3 -DHAVE=5FCONFIG=5FH -I/usr/src/gnu/lib/libsupc++/../../../= contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libst= dc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src= /gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=3DRepeatabilityConsidered= Good -g -fstack-protector -fconserve-space -fno-implicit-templates -ffuncti= on-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../contrib/= libstdc++/libsupc++/vec.cc > clang++: warning: argument unused during compilation: '-fconserve-space' > clang++: warning: argument unused during compilation: '-fno-implicit-temp= lates' > clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=3Dnative -DI= N=5FGLIBCPP=5FV3 -DHAVE=5FCONFIG=5FH -I/usr/src/gnu/lib/libsupc++/../../../= contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libst= dc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src= /gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=3DRepeatabilityConsidered= Good -g -fstack-protector -fconserve-space -fno-implicit-templates -ffuncti= on-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../contrib/= libstdc++/libsupc++/vterminate.cc > clang++: warning: argument unused during compilation: '-fconserve-space' > clang++: warning: argument unused during compilation: '-fno-implicit-temp= lates' > clang -O2 -pipe -fno-strict-aliasing -funroll-loops -march=3Dnative -DIN= =5FGLIBCPP=5FV3 -DHAVE=5FCONFIG=5FH -I/usr/src/gnu/lib/libsupc++/../../../c= ontrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstd= c++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/= gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=3DRepeatabilityConsideredG= ood -g -std=3Dgnu99 -fstack-protector -c /usr/src/gnu/lib/libsupc++/../../= ../contrib/gcclibs/libiberty/cp-demangle.c > building static supc++ library > ranlib libsupc++.a > =3D=3D=3D> gnu/lib/libobjc (all) > gcc -O2 -pipe -fno-strict-aliasing -funroll-loops -march=3Dnative -DHAVE= =5FGTHR=5FDEFAULT -DIN=5FGCC -DIN=5FTARGET=5FLIBS -I. -I/usr/src/gnu/lib/li= bobjc/../../usr.bin/cc/cc=5Ftools -I/usr/src/gnu/lib/libobjc/../../../contr= ib/libobjc/objc -I/usr/src/gnu/lib/libobjc/../../../contrib/libobjc -I/usr/= src/gnu/lib/libobjc/../../../contrib/gcc/config -I/usr/src/gnu/lib/libobjc/= ../../../contrib/gcc -I/usr/src/gnu/lib/libobjc/../../../contrib/gcclibs/in= clude -fexceptions -frandom-seed=3DRepeatabilityConsideredGood -g -std=3Dgn= u99 -fstack-protector -c /usr/src/gnu/lib/libobjc/../../../contrib/libobjc= /archive.c > *** Signal 11 >=20 > Stop in /usr/src/gnu/lib/libobjc. > *** Error code 1 >=20 > Stop in /usr/src/gnu/lib. > *** Error code 1 >=20 > Stop in /usr/src. > *** Error code 1 >=20 > Stop in /usr/src. > *** Error code 1 >=20 > Stop in /usr/src. > *** Error code 1 >=20 > Stop in /usr/src. >=20 >=20 > i've ran buildworld twice (with a clean /usr/src and non-existing /usr/ob= j/*) > and got the error twice, so it's not a hardware problem it seems. >=20 > if i'm not mistaken the gcc that is being used for buildworld is not the = one in > /usr/bin, but a fresh build in /usr/obj, right? >=20 > this is the bt from "gdb /usr/obj/usr/src/tmp/usr/bin/gcc gcc.core". i ho= pe i > picked the correct gcc executable: >=20 >=20 > Core was generated by `gcc'. > Program terminated with signal 11, Segmentation fault. > #0 host=5Fdetect=5Flocal=5Fcpu (argc=3DVariable "argc" is not available. > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/config/i386/drive= r-i386.c:272 > 272 return concat ("-m", argv[0], "=3D", cpu, NULL); > (gdb) bt > #0 host=5Fdetect=5Flocal=5Fcpu (argc=3DVariable "argc" is not available. > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/config/i386/drive= r-i386.c:272 > #1 0x000000000040c754 in eval=5Fspec=5Ffunction (func=3DCannot access me= mory at address 0x0 > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5520 > #2 0x00000000004093f2 in do=5Fspec=5F1 (spec=3DVariable "spec" is not av= ailable. > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5591 > #3 0x000000000040c4d2 in handle=5Fbraces (p=3DCannot access memory at ad= dress 0x0 > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > #4 0x0000000000408d99 in do=5Fspec=5F1 (spec=3DVariable "spec" is not av= ailable. > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > #5 0x0000000000409398 in do=5Fspec=5F1 (spec=3DVariable "spec" is not av= ailable. > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5413 > #6 0x0000000000409545 in do=5Fspec=5F1 (spec=3DVariable "spec" is not av= ailable. > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5193 > #7 0x0000000000409398 in do=5Fspec=5F1 (spec=3DVariable "spec" is not av= ailable. > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5413 > #8 0x000000000040c4d2 in handle=5Fbraces (p=3DCannot access memory at ad= dress 0x0 > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > #9 0x0000000000408d99 in do=5Fspec=5F1 (spec=3DVariable "spec" is not av= ailable. > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > #10 0x000000000040c4d2 in handle=5Fbraces (p=3DCannot access memory at ad= dress 0x0 > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > #11 0x0000000000408d99 in do=5Fspec=5F1 (spec=3DVariable "spec" is not av= ailable. > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > #12 0x000000000040c4d2 in handle=5Fbraces (p=3DCannot access memory at ad= dress 0x0 > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > #13 0x0000000000408d99 in do=5Fspec=5F1 (spec=3DVariable "spec" is not av= ailable. > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > #14 0x000000000040c4d2 in handle=5Fbraces (p=3DCannot access memory at ad= dress 0x0 > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > #15 0x0000000000408d99 in do=5Fspec=5F1 (spec=3DVariable "spec" is not av= ailable. > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > #16 0x000000000040c4d2 in handle=5Fbraces (p=3DCannot access memory at ad= dress 0x0 > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > #17 0x0000000000408d99 in do=5Fspec=5F1 (spec=3DVariable "spec" is not av= ailable. > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > #18 0x000000000040c4d2 in handle=5Fbraces (p=3DCannot access memory at ad= dress 0x0 > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > #19 0x0000000000408d99 in do=5Fspec=5F1 (spec=3DVariable "spec" is not av= ailable. > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > #20 0x000000000040c4d2 in handle=5Fbraces (p=3DCannot access memory at ad= dress 0x0 > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > #21 0x0000000000408d99 in do=5Fspec=5F1 (spec=3DVariable "spec" is not av= ailable. > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > #22 0x00000000004003ec in do=5Fspec=5F2 (spec=3D0x1
) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:4490 > #23 0x000000000040033d in do=5Fspec (spec=3D0x1
) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:4458 > #24 0x00000000004036d1 in main (argc=3D23, argv=3D0x7fffffffe240) at /usr= /src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:6712 >=20 So, you are trying to do a mixed clang+gcc build. Which architecture is thi= s? Does the problem occur in the case of a pure gcc build? HTH, Alexey. = From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 23:25:28 2010 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 67C7F1065670; Tue, 9 Nov 2010 23:25:28 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 1CB718FC14; Tue, 9 Nov 2010 23:25:27 +0000 (UTC) Received: by qyk4 with SMTP id 4so1522691qyk.13 for ; Tue, 09 Nov 2010 15:25:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.238.197 with SMTP id kt5mr6988621qcb.25.1289343493913; Tue, 09 Nov 2010 14:58:13 -0800 (PST) Received: by 10.229.41.68 with HTTP; Tue, 9 Nov 2010 14:58:13 -0800 (PST) X-Originating-IP: [93.203.39.47] In-Reply-To: <201011081714.53637.jhb@freebsd.org> References: <201011081714.53637.jhb@freebsd.org> Date: Tue, 9 Nov 2010 23:58:13 +0100 Message-ID: From: "C. P. Ghost" To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: Only display ACPI bootmenu key if ACPI is present 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, 09 Nov 2010 23:25:28 -0000 On Mon, Nov 8, 2010 at 11:14 PM, John Baldwin wrote: > This patch changes the Forth code for the Beastie menu to only display th= e > menu option to enable or disable ACPI if the loader detects ACPI. =A0This= avoids > displaying a menu item prompting to enable ACPI if the BIOS doesn't actua= lly > include ACPI. =A0Any objections? Wouldn't that be a POLA violation? Some admins may be used to the current menu, and would be scratching head as what went wrong. Maybe it would be better to keep the menu option, but make it non-selectable and print next to it something like "(not available)"? -cpghost. --=20 Cordula's Web. http://www.cordula.ws/ From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 23:45:03 2010 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 26797106566B; Tue, 9 Nov 2010 23:45:03 +0000 (UTC) (envelope-from yanegomi@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 7EFDA8FC15; Tue, 9 Nov 2010 23:45:02 +0000 (UTC) Received: by wwb22 with SMTP id 22so38281wwb.31 for ; Tue, 09 Nov 2010 15:45:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=umCdrdFm1oMObgltn2TRhZokvS6/rb3fLjwwUJfb+Dw=; b=DAmmz7R1sr5CmIvM/MPZrcqzz1aadPL1yeX86z2DsfxVuSI2/84Ydi5M0waEKVx2SN WLKuy8f7/XXZpototZsCKdTgceEMcsSywMMSiDmrYID1KrbY1G4IsV0Jmcwkr67h8HbY uEWNFWE4o6cSRI4jzoEi/yo99axiHYO1zUysE= 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=vLF45HBSzxLN+GbmxUBwjzPuj+DDGtucIbLLcjrHDwN92s2r5bO/KO+latgNPK9sGX pKPWPfWFs+0wxTWinEf6dBp63jEcLSg3c6EY1gGsIJWgYyOsa28KD28aLehntwulHE+/ fnuqTMBhacOfIY+c+mMuTLQTEEHaU42DalgXI= MIME-Version: 1.0 Received: by 10.216.35.139 with SMTP id u11mr473499wea.15.1289346300254; Tue, 09 Nov 2010 15:45:00 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Tue, 9 Nov 2010 15:45:00 -0800 (PST) In-Reply-To: References: <201011081714.53637.jhb@freebsd.org> Date: Tue, 9 Nov 2010 15:45:00 -0800 X-Google-Sender-Auth: lsQdCFfJ23QOEf66QSqJS01_-LE Message-ID: From: Garrett Cooper To: "C. P. Ghost" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: Only display ACPI bootmenu key if ACPI is present 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, 09 Nov 2010 23:45:03 -0000 On Tue, Nov 9, 2010 at 2:58 PM, C. P. Ghost wrote: > On Mon, Nov 8, 2010 at 11:14 PM, John Baldwin wrote: >> This patch changes the Forth code for the Beastie menu to only display t= he >> menu option to enable or disable ACPI if the loader detects ACPI. =A0Thi= s avoids >> displaying a menu item prompting to enable ACPI if the BIOS doesn't actu= ally >> include ACPI. =A0Any objections? > > Wouldn't that be a POLA violation? Some admins may be used to the > current menu, and would be scratching head as what went wrong. > Maybe it would be better to keep the menu option, but make it > non-selectable and print next to it something like "(not available)"? Yeah... seems like it would be; besides, I'm kind of used to pressing numbers 4 and 6 when I have a boot menu :). Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 23:58:29 2010 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 6748D106564A; Tue, 9 Nov 2010 23:58:29 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4FDB18FC0C; Tue, 9 Nov 2010 23:58:29 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id oA9NwRFK028665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Nov 2010 15:58:27 -0800 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 660071CC0E; Tue, 9 Nov 2010 15:58:27 -0800 (PST) To: Garrett Cooper In-reply-to: Your message of "Tue, 09 Nov 2010 15:45:00 PST." Date: Tue, 09 Nov 2010 15:58:27 -0800 From: "Kevin Oberman" Message-Id: <20101109235827.660071CC0E@ptavv.es.net> Cc: "C. P. Ghost" , current@freebsd.org Subject: Re: Only display ACPI bootmenu key if ACPI is present 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, 09 Nov 2010 23:58:29 -0000 > Date: Tue, 9 Nov 2010 15:45:00 -0800 > From: Garrett Cooper > Sender: owner-freebsd-current@freebsd.org > > On Tue, Nov 9, 2010 at 2:58 PM, C. P. Ghost wrote: > > On Mon, Nov 8, 2010 at 11:14 PM, John Baldwin wrote: > >> This patch changes the Forth code for the Beastie menu to only display the > >> menu option to enable or disable ACPI if the loader detects ACPI.  This avoids > >> displaying a menu item prompting to enable ACPI if the BIOS doesn't actually > >> include ACPI.  Any objections? > > > > Wouldn't that be a POLA violation? Some admins may be used to the > > current menu, and would be scratching head as what went wrong. > > Maybe it would be better to keep the menu option, but make it > > non-selectable and print next to it something like "(not available)"? > > Yeah... seems like it would be; besides, I'm kind of used to > pressing numbers 4 and 6 when I have a boot menu :). > Thanks! Wait a minute. The menu is a POLA violation. I'm used to hitting 'boot -s' and entering just '4' is clearly not the way the Lord meant it to be. (I edit the loader.4th file to turn it off o my personal systems, being an old curmudgeon.) If you are going to use a menu at all, why not make it as functional as possible? If someone has menus on and hits '4' with the PCBSD menu, it won't do what it does now, but it won't really do anything at all until you tell it to go. As POLA violations go this is nothing compared to when the menu appeared. I say, "Go 4 IT!" -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-current@FreeBSD.ORG Wed Nov 10 01:31:26 2010 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 C95B2106566B for ; Wed, 10 Nov 2010 01:31:26 +0000 (UTC) (envelope-from yanegomi@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 5AB5B8FC19 for ; Wed, 10 Nov 2010 01:31:25 +0000 (UTC) Received: by wwb22 with SMTP id 22so128252wwb.31 for ; Tue, 09 Nov 2010 17:31:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=X4a0vT7Hd3WsJUnX6IG0vbhC2nXwnXqjfGUA4MwW3l0=; b=Loxfu3mrB/UOXugXAwjIkH2Xy2MhOFtevPIgrQC3zPHOMRm1KfaSamPcAt/jfdhmQe cqlmX+LXwp71JQOjynl1OxYcjZyXwvgLCLyJ1TzbzZ/IMnTP6Fdz1dppRWfi8rlR0jVf tvsPHo1adc+xOFqmQbFzVbgCAQOZMMRi8Nqtg= 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=wzBqWgGJP9sAj3tkaowL577uVyywcYE4r0XBymXs22rUTbkF2ZQ7goZCFzf3rm1q3g LVPOAc8aHxZBWR4Y/W6BomeYXUyJFOi7nXCFiLZ4VlEeU/5zR3WqdQh0b6FrDpgzGoSH 8vl355U5qALn+Q1+jgdeOSGHr5p/TLia+f/gc= MIME-Version: 1.0 Received: by 10.216.82.197 with SMTP id o47mr7684467wee.45.1289352684814; Tue, 09 Nov 2010 17:31:24 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Tue, 9 Nov 2010 17:31:24 -0800 (PST) In-Reply-To: <20101109235827.660071CC0E@ptavv.es.net> References: <20101109235827.660071CC0E@ptavv.es.net> Date: Tue, 9 Nov 2010 17:31:24 -0800 X-Google-Sender-Auth: opZ-8OvXmBJ99-PQCvLoSTLAPbU Message-ID: From: Garrett Cooper To: Kevin Oberman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "C. P. Ghost" , current@freebsd.org Subject: Re: Only display ACPI bootmenu key if ACPI is present 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, 10 Nov 2010 01:31:27 -0000 On Tue, Nov 9, 2010 at 3:58 PM, Kevin Oberman wrote: >> Date: Tue, 9 Nov 2010 15:45:00 -0800 >> From: Garrett Cooper >> Sender: owner-freebsd-current@freebsd.org >> >> On Tue, Nov 9, 2010 at 2:58 PM, C. P. Ghost wrote: >> > On Mon, Nov 8, 2010 at 11:14 PM, John Baldwin wrote: >> >> This patch changes the Forth code for the Beastie menu to only displa= y the >> >> menu option to enable or disable ACPI if the loader detects ACPI. =A0= This avoids >> >> displaying a menu item prompting to enable ACPI if the BIOS doesn't a= ctually >> >> include ACPI. =A0Any objections? >> > >> > Wouldn't that be a POLA violation? Some admins may be used to the >> > current menu, and would be scratching head as what went wrong. >> > Maybe it would be better to keep the menu option, but make it >> > non-selectable and print next to it something like "(not available)"? >> >> =A0 =A0 Yeah... seems like it would be; besides, I'm kind of used to >> pressing numbers 4 and 6 when I have a boot menu :). > > Wait a minute. The menu is a POLA violation. I'm used to hitting > 'boot -s' and entering just '4' is clearly not the way the Lord > meant it to be. (I edit the loader.4th file to turn it off o my personal > systems, being an old curmudgeon.) I use a bit easier means on some systems: /boot/defaults/loader.conf:#beastie_disable=3D"NO" # Turn the beastie boot menu on and off > If you are going to use a menu at all, why not make it as functional as > possible? If someone has menus on and hits '4' with the PCBSD menu, it > won't do what it does now, but it won't really do anything at all until > you tell it to go. As POLA violations go this is nothing compared to > when the menu appeared. Whatever... people are going to gripe either way with this change, so I guess making people think is more important than misleading them into thinking things work. It's just easier to slap someone on the hand if they hit ACPI, and less annoying for automated expect scripts because they don't have to hit a different number, but I suppose if they were smart they would use the loader prompt anyhow instead of the menu *shrugs*. So, this is a "I understand, slap me on the hand if I hit 4 or 6" agreement :). Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Nov 10 05:18:59 2010 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 1A7C4106566B; Wed, 10 Nov 2010 05:18:59 +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 28BA18FC15; Wed, 10 Nov 2010 05:18:57 +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 HAA09247; Wed, 10 Nov 2010 07:18:55 +0200 (EET) (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 1PG35C-000Abe-Vx; Wed, 10 Nov 2010 07:18:55 +0200 Message-ID: <4CDA2B3E.9030402@freebsd.org> Date: Wed, 10 Nov 2010 07:18:54 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Kostik Belousov References: <4CD3B1D2.30003@icyb.net.ua> <4CD7E401.1010206@freebsd.org> <20101108120403.GC2392@deviant.kiev.zoral.com.ua> <4CD9139D.9060302@freebsd.org> <20101109140518.GV2392@deviant.kiev.zoral.com.ua> In-Reply-To: <20101109140518.GV2392@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: radeon_cp_texture: page fault with non-sleepable locks held 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, 10 Nov 2010 05:18:59 -0000 on 09/11/2010 16:05 Kostik Belousov said the following: > Easiest would be for DRM to provide wrappers for copyin/copyout that > unlock, do operation and lock. I am a little bit worried about this approach in general. Driver state may be changed by a process running in parallel while the lock is dropped. And I don't think that we have any mechanism in DRM to check for that and to restart operations or otherwise account for the state change. The code seems to be written with an assumption that it runs in exclusive mode from DRM ioctl start to its completion. > Where is the reverse order (user map -> drm) ? You mean the following or the opposite? 1st 0xffffff0001b968a0 drmdev (drmdev) @ /usr/src/sys/dev/drm/drm_drv.c:791 2nd 0xffffff000a621510 user map (user map) @ /usr/src/sys/vm/vm_map.c:3548 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff801b8b3a = db_trace_self_wrapper+0x2a kdb_backtrace() at 0xffffffff803a7a8a = kdb_backtrace+0x3a _witness_debugger() at 0xffffffff803bd42c = _witness_debugger+0x2c witness_checkorder() at 0xffffffff803be899 = witness_checkorder+0x959 _sx_slock() at 0xffffffff80378af8 = _sx_slock+0x88 _vm_map_lock_read() at 0xffffffff80510a06 = _vm_map_lock_read+0x36 vm_map_lookup() at 0xffffffff805127d4 = vm_map_lookup+0x54 vm_fault() at 0xffffffff80509819 = vm_fault+0xf9 trap_pfault() at 0xffffffff80545d6f = trap_pfault+0x11f trap() at 0xffffffff805465f7 = trap+0x657 calltrap() at 0xffffffff80530628 = calltrap+0x8 --- trap 0xc, rip = 0xffffffff805440bd, rsp = 0xffffff8123fe37f0, rbp = 0xffffff8123fe3870 --- copyin() at 0xffffffff805440bd = copyin+0x3d radeon_cp_texture() at 0xffffffff8022fbd7 = radeon_cp_texture+0x167 drm_ioctl() at 0xffffffff8020fa38 = drm_ioctl+0x318 devfs_ioctl_f() at 0xffffffff802dd649 = devfs_ioctl_f+0x109 kern_ioctl() at 0xffffffff803c1127 = kern_ioctl+0x1f7 ioctl() at 0xffffffff803c12e8 = ioctl+0x168 syscallenter() at 0xffffffff803b57de = syscallenter+0x26e syscall() at 0xffffffff80545eb2 = syscall+0x42 Xfast_syscall() at 0xffffffff80530902 = Xfast_syscall+0xe2 If you meant the opposite order, how can I check it? I guess that it could be in a mmap() call for drm cdev. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Nov 10 05:58:16 2010 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 D05D81065672 for ; Wed, 10 Nov 2010 05:58:16 +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 1E22A8FC14 for ; Wed, 10 Nov 2010 05:58:15 +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 HAA10014 for ; Wed, 10 Nov 2010 07:58:14 +0200 (EET) (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 1PG3hG-000AeV-9B for freebsd-current@FreeBSD.ORG; Wed, 10 Nov 2010 07:58:14 +0200 Message-ID: <4CDA3475.3060101@freebsd.org> Date: Wed, 10 Nov 2010 07:58:13 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Subject: panic: uma_zalloc_arg: Returning an empty bucket. 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, 10 Nov 2010 05:58:16 -0000 I've been doing some stress-testing for VM+ZFS on a kernel with WITNESS+INVARIANTS and I have already stumbled into some curious panics. Here's another one: Unread portion of the kernel message buffer: panic: uma_zalloc_arg: Returning an empty bucket. cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff801b8b3a = db_trace_self_wrapper+0x2a kdb_backtrace() at 0xffffffff803a7a8a = kdb_backtrace+0x3a panic() at 0xffffffff80370632 = panic+0x1d2 uma_zalloc_arg() at 0xffffffff80507850 = uma_zalloc_arg+0x300 kmem_cache_alloc() at 0xffffffff80dac385 = kmem_cache_alloc+0x15 arc_buf_alloc() at 0xffffffff80c016e4 = arc_buf_alloc+0x34 arc_read_nolock() at 0xffffffff80c0389d = arc_read_nolock+0x2bd arc_read() at 0xffffffff80c03dff = arc_read+0x7f dbuf_prefetch() at 0xffffffff80c0826a = dbuf_prefetch+0x15a dmu_zfetch_dofetch() at 0xffffffff80c21444 = dmu_zfetch_dofetch+0x104 dmu_zfetch() at 0xffffffff80c21c89 = dmu_zfetch+0x5e9 dbuf_read() at 0xffffffff80c06c04 = dbuf_read+0x454 dmu_buf_hold_array_by_dnode() at 0xffffffff80c0a58d = dmu_buf_hold_array_by_dnode+0x27d dmu_read() at 0xffffffff80c0a80f = dmu_read+0xbf zfs_freebsd_getpages() at 0xffffffff80c6c9b5 = zfs_freebsd_getpages+0x8c5 VOP_GETPAGES_APV() at 0xffffffff805a6618 = VOP_GETPAGES_APV+0xe8 vnode_pager_getpages() at 0xffffffff80523c09 = vnode_pager_getpages+0xb9 vm_fault() at 0xffffffff8050a67a = vm_fault+0xf5a trap_pfault() at 0xffffffff80545d6f = trap_pfault+0x11f trap() at 0xffffffff80546448 = trap+0x4a8 calltrap() at 0xffffffff80530628 = calltrap+0x8 (kgdb) bt #0 doadump () at pcpu.h:224 #1 0xffffffff8036fc9a in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:306 #2 0xffffffff80370668 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:609 #3 0xffffffff80507850 in uma_zalloc_arg (zone=0xffffff00071c6e00, udata=0xffffff00071c8380, flags=2) at /usr/src/sys/vm/uma_core.c:2132 #4 0xffffffff80dac385 in kmem_cache_alloc (cache=Variable "cache" is not available. ) at /usr/src/sys/modules/opensolaris/../../cddl/compat/opensolaris/kern/opensolaris_kmem.c:196 #5 0xffffffff80c016e4 in arc_buf_alloc (spa=0xffffff00071e5000, size=131072, tag=Variable "tag" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:1344 #6 0xffffffff80c0389d in arc_read_nolock (pio=0x0, spa=0xffffff00071e5000, bp=0xffffff8002c71e80, done=0, private=0x0, priority=6, zio_flags=3, arc_flags=0xffffff812673b2bc, zb=0xffffff812673b280) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:2931 #7 0xffffffff80c03dff in arc_read (pio=0x0, spa=0xffffff00071e5000, bp=0xffffff8002c71e80, pbuf=0xffffff00abaa31b0, done=0, private=0x0, priority=6, zio_flags=3, arc_flags=0xffffff812673b2bc, zb=0xffffff812673b280) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:2832 #8 0xffffffff80c0826a in dbuf_prefetch (dn=0xffffff00b440f000, blkid=221) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:1641 #9 0xffffffff80c21444 in dmu_zfetch_dofetch (zf=0xffffff00b440f2b8, zs=0xffffff0126bb6480) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_zfetch.c:308 #10 0xffffffff80c21c89 in dmu_zfetch (zf=0xffffff00b440f2b8, offset=Variable "offset" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_zfetch.c:526 #11 0xffffffff80c06c04 in dbuf_read (db=0xffffff0031970b60, zio=0xffffff0078bb2328, flags=54) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:568 #12 0xffffffff80c0a58d in dmu_buf_hold_array_by_dnode (dn=0xffffff00b440f000, offset=Variable "offset" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:235 #13 0xffffffff80c0a80f in dmu_read (os=Variable "os" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:572 #14 0xffffffff80c6c9b5 in zfs_freebsd_getpages (ap=Variable "ap" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:4348 #15 0xffffffff805a6618 in VOP_GETPAGES_APV (vop=0xffffffff80cd8680, a=0xffffff812673b740) at vnode_if.c:2666 #16 0xffffffff80523c09 in vnode_pager_getpages (object=Variable "object" is not available. ) at vnode_if.h:1154 #17 0xffffffff8050a67a in vm_fault (map=0xffffff00ab3d5c40, vaddr=35585523712, fault_type=1 '\001', fault_flags=Variable "fault_flags" is not available. ) at vm_pager.h:130 #18 0xffffffff80545d6f in trap_pfault (frame=0xffffff812673bc40, usermode=1) at /usr/src/sys/amd64/amd64/trap.c:729 #19 0xffffffff80546448 in trap (frame=0xffffff812673bc40) at /usr/src/sys/amd64/amd64/trap.c:403 #20 0xffffffff80530628 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #21 0x0000000800858fe6 in ?? () -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Nov 10 06:34:08 2010 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 A5303106566B; Wed, 10 Nov 2010 06:34:08 +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 892F28FC0C; Wed, 10 Nov 2010 06:34:07 +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 IAA10495; Wed, 10 Nov 2010 08:34:06 +0200 (EET) (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 1PG4Fx-000Agy-QS; Wed, 10 Nov 2010 08:34:05 +0200 Message-ID: <4CDA3CDD.5000404@freebsd.org> Date: Wed, 10 Nov 2010 08:34:05 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Ivan Voras References: <4CD7C8FC.900@icyb.net.ua> <4CD7E515.5040209@icyb.net.ua> <4CD7E960.1070200@freebsd.org> In-Reply-To: <4CD7E960.1070200@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: another fuse 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: Wed, 10 Nov 2010 06:34:08 -0000 on 08/11/2010 14:13 Andriy Gapon said the following: > on 08/11/2010 13:55 Andriy Gapon said the following: >> I reliable got this panic when all I was doing is saving an attachment in >> thunderbird 3 that ran in KDE 4 environment. Not sure what was going on behind >> the scenes, but shouldn't have been anything out of the ordinary. > > Perhaps this is my local mistake. I can't see from code and crash dump how NULL > pointer is possible there. So perhaps I have some ABI mismatch between kernel > and fuse module. > I will rebuild fuse kmod and re-test again. Yes, the rebuild has helped. I wish this could be nicely automated. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Nov 10 06:41:17 2010 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 3B179106566C for ; Wed, 10 Nov 2010 06:41:17 +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 9601A8FC1D for ; Wed, 10 Nov 2010 06:41:16 +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 IAA10603 for ; Wed, 10 Nov 2010 08:41:15 +0200 (EET) (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 1PG4Ms-000AhT-Mm for freebsd-current@FreeBSD.ORG; Wed, 10 Nov 2010 08:41:14 +0200 Message-ID: <4CDA3E8A.50004@freebsd.org> Date: Wed, 10 Nov 2010 08:41:14 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4CDA3475.3060101@freebsd.org> In-Reply-To: <4CDA3475.3060101@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit Subject: Re: panic: uma_zalloc_arg: Returning an empty bucket. 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, 10 Nov 2010 06:41:17 -0000 on 10/11/2010 07:58 Andriy Gapon said the following: > > I've been doing some stress-testing for VM+ZFS on a kernel with > WITNESS+INVARIANTS and I have already stumbled into some curious panics. > > Here's another one: > Unread portion of the kernel message buffer: > panic: uma_zalloc_arg: Returning an empty bucket. Looks like this particular panic was caused by my local changes for draining per-CPU caches in very low memory conditions. > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff801b8b3a = db_trace_self_wrapper+0x2a > kdb_backtrace() at 0xffffffff803a7a8a = kdb_backtrace+0x3a > panic() at 0xffffffff80370632 = panic+0x1d2 > uma_zalloc_arg() at 0xffffffff80507850 = uma_zalloc_arg+0x300 > kmem_cache_alloc() at 0xffffffff80dac385 = kmem_cache_alloc+0x15 > arc_buf_alloc() at 0xffffffff80c016e4 = arc_buf_alloc+0x34 > arc_read_nolock() at 0xffffffff80c0389d = arc_read_nolock+0x2bd > arc_read() at 0xffffffff80c03dff = arc_read+0x7f > dbuf_prefetch() at 0xffffffff80c0826a = dbuf_prefetch+0x15a > dmu_zfetch_dofetch() at 0xffffffff80c21444 = dmu_zfetch_dofetch+0x104 > dmu_zfetch() at 0xffffffff80c21c89 = dmu_zfetch+0x5e9 > dbuf_read() at 0xffffffff80c06c04 = dbuf_read+0x454 > dmu_buf_hold_array_by_dnode() at 0xffffffff80c0a58d = > dmu_buf_hold_array_by_dnode+0x27d > dmu_read() at 0xffffffff80c0a80f = dmu_read+0xbf > zfs_freebsd_getpages() at 0xffffffff80c6c9b5 = zfs_freebsd_getpages+0x8c5 > VOP_GETPAGES_APV() at 0xffffffff805a6618 = VOP_GETPAGES_APV+0xe8 > vnode_pager_getpages() at 0xffffffff80523c09 = vnode_pager_getpages+0xb9 > vm_fault() at 0xffffffff8050a67a = vm_fault+0xf5a > trap_pfault() at 0xffffffff80545d6f = trap_pfault+0x11f > trap() at 0xffffffff80546448 = trap+0x4a8 > calltrap() at 0xffffffff80530628 = calltrap+0x8 > > (kgdb) bt > #0 doadump () at pcpu.h:224 > #1 0xffffffff8036fc9a in kern_reboot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:306 > #2 0xffffffff80370668 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:609 > #3 0xffffffff80507850 in uma_zalloc_arg (zone=0xffffff00071c6e00, > udata=0xffffff00071c8380, flags=2) at /usr/src/sys/vm/uma_core.c:2132 > #4 0xffffffff80dac385 in kmem_cache_alloc (cache=Variable "cache" is not available. > ) at > /usr/src/sys/modules/opensolaris/../../cddl/compat/opensolaris/kern/opensolaris_kmem.c:196 > #5 0xffffffff80c016e4 in arc_buf_alloc (spa=0xffffff00071e5000, size=131072, > tag=Variable "tag" is not available. > ) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:1344 > #6 0xffffffff80c0389d in arc_read_nolock (pio=0x0, spa=0xffffff00071e5000, > bp=0xffffff8002c71e80, done=0, private=0x0, priority=6, zio_flags=3, > arc_flags=0xffffff812673b2bc, zb=0xffffff812673b280) at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:2931 > #7 0xffffffff80c03dff in arc_read (pio=0x0, spa=0xffffff00071e5000, > bp=0xffffff8002c71e80, pbuf=0xffffff00abaa31b0, done=0, private=0x0, priority=6, > zio_flags=3, arc_flags=0xffffff812673b2bc, zb=0xffffff812673b280) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:2832 > #8 0xffffffff80c0826a in dbuf_prefetch (dn=0xffffff00b440f000, blkid=221) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:1641 > #9 0xffffffff80c21444 in dmu_zfetch_dofetch (zf=0xffffff00b440f2b8, > zs=0xffffff0126bb6480) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_zfetch.c:308 > #10 0xffffffff80c21c89 in dmu_zfetch (zf=0xffffff00b440f2b8, offset=Variable > "offset" is not available. > ) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_zfetch.c:526 > #11 0xffffffff80c06c04 in dbuf_read (db=0xffffff0031970b60, > zio=0xffffff0078bb2328, flags=54) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:568 > #12 0xffffffff80c0a58d in dmu_buf_hold_array_by_dnode (dn=0xffffff00b440f000, > offset=Variable "offset" is not available. > ) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:235 > #13 0xffffffff80c0a80f in dmu_read (os=Variable "os" is not available. > ) at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:572 > #14 0xffffffff80c6c9b5 in zfs_freebsd_getpages (ap=Variable "ap" is not available. > ) at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:4348 > #15 0xffffffff805a6618 in VOP_GETPAGES_APV (vop=0xffffffff80cd8680, > a=0xffffff812673b740) at vnode_if.c:2666 > #16 0xffffffff80523c09 in vnode_pager_getpages (object=Variable "object" is not > available. > ) at vnode_if.h:1154 > #17 0xffffffff8050a67a in vm_fault (map=0xffffff00ab3d5c40, vaddr=35585523712, > fault_type=1 '\001', fault_flags=Variable "fault_flags" is not available. > ) at vm_pager.h:130 > #18 0xffffffff80545d6f in trap_pfault (frame=0xffffff812673bc40, usermode=1) at > /usr/src/sys/amd64/amd64/trap.c:729 > #19 0xffffffff80546448 in trap (frame=0xffffff812673bc40) at > /usr/src/sys/amd64/amd64/trap.c:403 > #20 0xffffffff80530628 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 > #21 0x0000000800858fe6 in ?? () -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Nov 10 07:32:04 2010 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 8DFFB106566C; Wed, 10 Nov 2010 07:32: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 5189A8FC1F; Wed, 10 Nov 2010 07:32:04 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oAA7W3sl084412; Wed, 10 Nov 2010 02:32:03 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oAA7W3PE084407; Wed, 10 Nov 2010 07:32:03 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 10 Nov 2010 07:32:03 GMT Message-Id: <201011100732.oAA7W3PE084407@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: Wed, 10 Nov 2010 07:32:04 -0000 TB --- 2010-11-10 07:31:37 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-10 07:31:37 - starting HEAD tinderbox run for mips/mips TB --- 2010-11-10 07:31:37 - cleaning the object tree TB --- 2010-11-10 07:31:46 - cvsupping the source tree TB --- 2010-11-10 07:31:46 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2010-11-10 07:32:02 - building world TB --- 2010-11-10 07:32:02 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-10 07:32:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-10 07:32:02 - TARGET=mips TB --- 2010-11-10 07:32:02 - TARGET_ARCH=mips TB --- 2010-11-10 07:32:02 - TZ=UTC TB --- 2010-11-10 07:32:02 - __MAKE_CONF=/dev/null TB --- 2010-11-10 07:32:02 - cd /src TB --- 2010-11-10 07:32:02 - /usr/bin/make -B buildworld "/src/Makefile.inc1", line 138: Unknown target mips:mips. *** Error code 1 Stop in /src. TB --- 2010-11-10 07:32:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-10 07:32:03 - ERROR: failed to build world TB --- 2010-11-10 07:32:03 - 2.52 user 10.20 system 25.35 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Wed Nov 10 07:58:21 2010 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 1CC48106566B; Wed, 10 Nov 2010 07:58:21 +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 B96EC8FC1A; Wed, 10 Nov 2010 07:58:20 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oAA7wJI8063161; Wed, 10 Nov 2010 02:58:19 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oAA7wJuN063160; Wed, 10 Nov 2010 07:58:19 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 10 Nov 2010 07:58:19 GMT Message-Id: <201011100758.oAA7wJuN063160@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: Wed, 10 Nov 2010 07:58:21 -0000 TB --- 2010-11-10 07:52:29 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-10 07:52:29 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-11-10 07:52:29 - cleaning the object tree TB --- 2010-11-10 07:52:59 - cvsupping the source tree TB --- 2010-11-10 07:52:59 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-11-10 07:53:18 - building world TB --- 2010-11-10 07:53:18 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-10 07:53:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-10 07:53:18 - TARGET=powerpc TB --- 2010-11-10 07:53:18 - TARGET_ARCH=powerpc64 TB --- 2010-11-10 07:53:18 - TZ=UTC TB --- 2010-11-10 07:53:18 - __MAKE_CONF=/dev/null TB --- 2010-11-10 07:53:18 - cd /src TB --- 2010-11-10 07:53:18 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 10 07:53:19 UTC 2010 >>> 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 [...] cc -o rtermcap /src/usr.sbin/sysinstall/rtermcap.c -ltermcap ===> gnu/usr.bin/cc/cc_tools (obj,depend,all) LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-gather.awk /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/c.opt /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/common.opt /src/gnu/usr.bin/cc/cc_tools/freebsd.opt > optionlist LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-functions.awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opth-gen.awk < optionlist > options.h LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-functions.awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/optc-gen.awk -v header_name="config.h system.h coretypes.h tm.h" < optionlist > options.c TARGET_CPU_DEFAULT="\"powerpc64\"" HEADERS="auto-host.h ansidecl.h" DEFINES="" /bin/sh /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/mkconfig.sh bconfig.h TARGET_CPU_DEFAULT="\"powerpc64\"" HEADERS="options.h rs600064/rs600064.h dbxelf.h elfos-undef.h elfos.h freebsd-native.h freebsd-spec.h freebsd.h rs600064/biarch64.h rs600064/default64.h rs600064/freebsd.h defaults.h" DEFINES="" /bin/sh /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/mkconfig.sh tm.h make: don't know how to make /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config/rs600064/rs600064.c. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-10 07:58:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-10 07:58:19 - ERROR: failed to build world TB --- 2010-11-10 07:58:19 - 206.66 user 69.12 system 350.71 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Nov 10 08:34:12 2010 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 4EF251065672; Wed, 10 Nov 2010 08:34:12 +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 D887C8FC12; Wed, 10 Nov 2010 08:34:11 +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 oAA8Y8JP000677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Nov 2010 10:34:08 +0200 (EET) (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 oAA8Y8p0036569; Wed, 10 Nov 2010 10:34:08 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oAA8Y8T8036568; Wed, 10 Nov 2010 10:34:08 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 10 Nov 2010 10:34:08 +0200 From: Kostik Belousov To: Andriy Gapon Message-ID: <20101110083408.GC2392@deviant.kiev.zoral.com.ua> References: <4CD3B1D2.30003@icyb.net.ua> <4CD7E401.1010206@freebsd.org> <20101108120403.GC2392@deviant.kiev.zoral.com.ua> <4CD9139D.9060302@freebsd.org> <20101109140518.GV2392@deviant.kiev.zoral.com.ua> <4CDA2B3E.9030402@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yOV8wujajMQrgQLM" Content-Disposition: inline In-Reply-To: <4CDA2B3E.9030402@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.7 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-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: radeon_cp_texture: page fault with non-sleepable locks held 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, 10 Nov 2010 08:34:12 -0000 --yOV8wujajMQrgQLM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 10, 2010 at 07:18:54AM +0200, Andriy Gapon wrote: > on 09/11/2010 16:05 Kostik Belousov said the following: > > Easiest would be for DRM to provide wrappers for copyin/copyout that > > unlock, do operation and lock. >=20 > I am a little bit worried about this approach in general. > Driver state may be changed by a process running in parallel while the lo= ck is > dropped. And I don't think that we have any mechanism in DRM to check fo= r that > and to restart operations or otherwise account for the state change. The= code > seems to be written with an assumption that it runs in exclusive mode fro= m DRM > ioctl start to its completion. >=20 > > Where is the reverse order (user map -> drm) ? >=20 > You mean the following or the opposite? >=20 > 1st 0xffffff0001b968a0 drmdev (drmdev) @ /usr/src/sys/dev/drm/drm_drv.c:7= 91 > 2nd 0xffffff000a621510 user map (user map) @ /usr/src/sys/vm/vm_map.c:3548 > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff801b8b3a =3D db_trace_self_wrapper+0= x2a > kdb_backtrace() at 0xffffffff803a7a8a =3D kdb_backtrace+0x3a > _witness_debugger() at 0xffffffff803bd42c =3D _witness_debugger+0x2c > witness_checkorder() at 0xffffffff803be899 =3D witness_checkorder+0x959 > _sx_slock() at 0xffffffff80378af8 =3D _sx_slock+0x88 > _vm_map_lock_read() at 0xffffffff80510a06 =3D _vm_map_lock_read+0x36 > vm_map_lookup() at 0xffffffff805127d4 =3D vm_map_lookup+0x54 > vm_fault() at 0xffffffff80509819 =3D vm_fault+0xf9 > trap_pfault() at 0xffffffff80545d6f =3D trap_pfault+0x11f > trap() at 0xffffffff805465f7 =3D trap+0x657 > calltrap() at 0xffffffff80530628 =3D calltrap+0x8 > --- trap 0xc, rip =3D 0xffffffff805440bd, rsp =3D 0xffffff8123fe37f0, rbp= =3D > 0xffffff8123fe3870 --- > copyin() at 0xffffffff805440bd =3D copyin+0x3d > radeon_cp_texture() at 0xffffffff8022fbd7 =3D radeon_cp_texture+0x167 > drm_ioctl() at 0xffffffff8020fa38 =3D drm_ioctl+0x318 > devfs_ioctl_f() at 0xffffffff802dd649 =3D devfs_ioctl_f+0x109 > kern_ioctl() at 0xffffffff803c1127 =3D kern_ioctl+0x1f7 > ioctl() at 0xffffffff803c12e8 =3D ioctl+0x168 > syscallenter() at 0xffffffff803b57de =3D syscallenter+0x26e > syscall() at 0xffffffff80545eb2 =3D syscall+0x42 > Xfast_syscall() at 0xffffffff80530902 =3D Xfast_syscall+0xe2 >=20 > If you meant the opposite order, how can I check it? > I guess that it could be in a mmap() call for drm cdev. Explicitely insert the reversed order into the witness array and watch. --yOV8wujajMQrgQLM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzaWP8ACgkQC3+MBN1Mb4h4ugCcDp3xrnYTuWHdQZYtdlk1D78A kPMAnRQ4Kr+WltgIDSyaNiKGb7vExGe3 =VeFf -----END PGP SIGNATURE----- --yOV8wujajMQrgQLM-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 10 10:17:19 2010 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 8D995106564A for ; Wed, 10 Nov 2010 10:17:19 +0000 (UTC) (envelope-from rbgarga@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 20CC28FC08 for ; Wed, 10 Nov 2010 10:17:18 +0000 (UTC) Received: by wya21 with SMTP id 21so587326wya.13 for ; Wed, 10 Nov 2010 02:17:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=W1GkOcOnpgrFSgQV9ekpXy67PvC7yvpPk/uB4YmoIDo=; b=E43TxELxWk6pKYjjlahUn6gDnkQY0UltQoJHmwVhn8QBjuJQreb3ZIFrmED34GQhNe aCXAMAwkBcsGwyNsDgKXj7M2OZaCq1aJr/T5+Mfa/+LSZfzXB57GL9sPgvBUHStgJNKy XOuB/ZfZ80n3C+LAeh7v5cD3WJ31YQxopFlE8= 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=Ds85F0PtQNeL4zfDsjJefDSSYcr6zVVYKDJOSqZcODp4+Rjo/F3Bk4f+A7likhdf4e fKtg5CNR5sPEskSQjKOyLVAspwISWlh0eoodfji/KJUGylECGR+wv1OkJc7AKXhxdtJq fgCAUWyHTs8cQ7AA6NoKl1zQb8PCyvbo/xux4= Received: by 10.216.87.20 with SMTP id x20mr883293wee.52.1289384236412; Wed, 10 Nov 2010 02:17:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.182.10 with HTTP; Wed, 10 Nov 2010 02:16:56 -0800 (PST) In-Reply-To: <20101109191326.GP2054@hoeg.nl> References: <20101109100319.GV2054@hoeg.nl> <20101109174542.GM2054@hoeg.nl> <20101109191326.GP2054@hoeg.nl> From: Renato Botelho Date: Wed, 10 Nov 2010 08:16:56 -0200 Message-ID: To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: Syscons and termcap 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, 10 Nov 2010 10:17:19 -0000 On Tue, Nov 9, 2010 at 5:13 PM, Ed Schouten wrote: > * Renato Botelho , 20101109 19:12: >> It had no effect on console but, i don't know why, screwed up >> my Xorg keymap, some meta keys (Mod4) stop working even >> if I run a setxkbmap like this: > > Oh yes. d'oh! I forgot that that specific input path is used by both the > console and the raw keyboard interface used by Xorg. I've updated the > patch to only emit UTF-8 when using K_XLATE keyboard mode, which is used > on the console. > > =A0 =A0 =A0 =A0http://80386.nl/pub/syscons-utf8.txt Now Xorg is working properly, but it has no effect on console. I'm using cp437 fonts and us.iso.kbd --=20 Renato Botelho From owner-freebsd-current@FreeBSD.ORG Wed Nov 10 14:46:51 2010 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 A8A3C106564A for ; Wed, 10 Nov 2010 14:46:51 +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 76A008FC0A for ; Wed, 10 Nov 2010 14:46:51 +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 19A9F46B0C; Wed, 10 Nov 2010 09:46:51 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0F1788A027; Wed, 10 Nov 2010 09:46:50 -0500 (EST) From: John Baldwin To: "C. P. Ghost" Date: Wed, 10 Nov 2010 08:57:35 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201011081714.53637.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011100857.35286.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 10 Nov 2010 09:46:50 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: current@freebsd.org Subject: Re: Only display ACPI bootmenu key if ACPI is present 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, 10 Nov 2010 14:46:51 -0000 On Tuesday, November 09, 2010 5:58:13 pm C. P. Ghost wrote: > On Mon, Nov 8, 2010 at 11:14 PM, John Baldwin wrote: > > This patch changes the Forth code for the Beastie menu to only display the > > menu option to enable or disable ACPI if the loader detects ACPI. This avoids > > displaying a menu item prompting to enable ACPI if the BIOS doesn't actually > > include ACPI. Any objections? > > Wouldn't that be a POLA violation? Some admins may be used to the > current menu, and would be scratching head as what went wrong. > Maybe it would be better to keep the menu option, but make it > non-selectable and print next to it something like "(not available)"? Hmmm, I'll see if I can leave the numbering unchanged but not list the item perhaps. Note that we already have the "alternate" numbering on other platforms so the menu is already inconsistent across FreeBSD platforms. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Nov 10 16:01:55 2010 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 B3D63106564A; Wed, 10 Nov 2010 16:01:55 +0000 (UTC) (envelope-from sdrhodus@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 57D748FC0A; Wed, 10 Nov 2010 16:01:55 +0000 (UTC) Received: by gya6 with SMTP id 6so472006gya.13 for ; Wed, 10 Nov 2010 08:01:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:in-reply-to :mime-version:content-transfer-encoding:content-type:message-id:cc :x-mailer:from:subject:date:to; bh=BM8gmP8n1wVj2UMz7NZjyKtyJtTZDnfM76AxWO9/A44=; b=FcaVitzZnd9q7ejhSZEG3YMHfJCq0q5VYGmLZC+MvkjG8snXFjbTHCIonkToijTqRE nAXIrfLLlW8I+HQMlAZeEQewageBF986qMpzm9jMjQ5LnOO8SoBh99pvnxCCe3mIMdem PXdIKjVQeILbtWnNaKD0IZ9J+LpTnI3qbPXk8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=gJKBVBVDZ+p4LXfBzMriz5te0JowBgyVewfsOrEEX5TihqMHo30E3sAjHFyGIGAZux mWAEjEWwBlF7ft2q53CDQcUA7J+IUZ21ZQi2CE2g4RSW8/8p9P4JBOQ7IQZDr8KiWUME 9NWZcSKIkM9QcVXldNEdhcfclu0oGEh56cga4= Received: by 10.151.79.1 with SMTP id g1mr11491494ybl.375.1289404914609; Wed, 10 Nov 2010 08:01:54 -0800 (PST) Received: from [10.79.254.223] ([166.137.12.90]) by mx.google.com with ESMTPS id q8sm1691980ybk.0.2010.11.10.08.01.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Nov 2010 08:01:52 -0800 (PST) References: <201011081714.53637.jhb@freebsd.org> In-Reply-To: <201011081714.53637.jhb@freebsd.org> Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8B117) From: David Rhodus Date: Wed, 10 Nov 2010 11:01:32 -0500 To: John Baldwin Cc: "current@freebsd.org" Subject: Re: Only display ACPI bootmenu key if ACPI is present 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, 10 Nov 2010 16:01:55 -0000 What are the chances the detection fails and one still needs to disable ACPI= and can't because it's not showing as a option ? Thanks, David Rhodus On Nov 8, 2010, at 5:14 PM, John Baldwin wrote: > This patch changes the Forth code for the Beastie menu to only display the= > menu option to enable or disable ACPI if the loader detects ACPI. This av= oids > displaying a menu item prompting to enable ACPI if the BIOS doesn't actual= ly > include ACPI. Any objections? >=20 > --- //depot/projects/smpng/sys/boot/forth/beastie.4th 2010-11-08 21:53:= 18.000000000 0000 > +++ //depot/user/jhb/ktrace/boot/forth/beastie.4th 2010-11-08 22:14:04.= 000000000 0000 > @@ -140,12 +140,16 @@ > fbsdbw-logo > ; >=20 > -: acpienabled? ( -- flag ) > +: acpipresent? ( -- flag ) > s" hint.acpi.0.rsdp" getenv > dup -1 =3D if > drop false exit > then > 2drop > + true > +; > + > +: acpienabled? ( -- flag ) > s" hint.acpi.0.disabled" getenv > dup -1 <> if > s" 0" compare 0<> if > @@ -178,8 +182,7 @@ > 42 20 2 2 box > 13 6 at-xy ." Welcome to FreeBSD!" > printmenuitem ." Boot FreeBSD [default]" bootkey ! > - s" arch-i386" environment? if > - drop > + acpipresent? if > printmenuitem ." Boot FreeBSD with ACPI " bootacpikey ! > acpienabled? if > ." disabled" >=20 > --=20 > John Baldwin > _______________________________________________ > 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 Nov 10 16:31:20 2010 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 2573B1065679 for ; Wed, 10 Nov 2010 16:31:20 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 997BD8FC1C for ; Wed, 10 Nov 2010 16:31:19 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id oAAG7Aef091615; Wed, 10 Nov 2010 09:07:10 -0700 (MST) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: Date: Wed, 10 Nov 2010 09:07:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201011081714.53637.jhb@freebsd.org> To: David Rhodus X-Mailer: Apple Mail (2.1081) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: "current@freebsd.org" Subject: Re: Only display ACPI bootmenu key if ACPI is present 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, 10 Nov 2010 16:31:20 -0000 If the loader can't detect acpi, the kernel can't either. Scott On Nov 10, 2010, at 9:01 AM, David Rhodus wrote: > What are the chances the detection fails and one still needs to = disable ACPI and can't because it's not showing as a option ? >=20 > Thanks, > David Rhodus >=20 > On Nov 8, 2010, at 5:14 PM, John Baldwin wrote: >=20 >> This patch changes the Forth code for the Beastie menu to only = display the >> menu option to enable or disable ACPI if the loader detects ACPI. = This avoids >> displaying a menu item prompting to enable ACPI if the BIOS doesn't = actually >> include ACPI. Any objections? >>=20 >> --- //depot/projects/smpng/sys/boot/forth/beastie.4th 2010-11-08 = 21:53:18.000000000 0000 >> +++ //depot/user/jhb/ktrace/boot/forth/beastie.4th 2010-11-08 = 22:14:04.000000000 0000 >> @@ -140,12 +140,16 @@ >> fbsdbw-logo >> ; >>=20 >> -: acpienabled? ( -- flag ) >> +: acpipresent? ( -- flag ) >> s" hint.acpi.0.rsdp" getenv >> dup -1 =3D if >> drop false exit >> then >> 2drop >> + true >> +; >> + >> +: acpienabled? ( -- flag ) >> s" hint.acpi.0.disabled" getenv >> dup -1 <> if >> s" 0" compare 0<> if >> @@ -178,8 +182,7 @@ >> 42 20 2 2 box >> 13 6 at-xy ." Welcome to FreeBSD!" >> printmenuitem ." Boot FreeBSD [default]" bootkey ! >> - s" arch-i386" environment? if >> - drop >> + acpipresent? if >> printmenuitem ." Boot FreeBSD with ACPI " bootacpikey ! >> acpienabled? if >> ." disabled" >>=20 >> --=20 >> John Baldwin >> _______________________________________________ >> 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" > _______________________________________________ > 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 Nov 10 16:41:56 2010 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 26D28106566C; Wed, 10 Nov 2010 16:41:56 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7ADFE8FC13; Wed, 10 Nov 2010 16:41:55 +0000 (UTC) Received: by bwz2 with SMTP id 2so929834bwz.13 for ; Wed, 10 Nov 2010 08:41:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=Q+xWq8lYneGJrbYDjhybtq+ve2jdW8EsXGfnJX65cnU=; b=Y/wr73R91UXa+0JPTQQisLgI2c2E/HehRdwwHxmcwLMiy0julC5f4xIezHpsw0+6r+ YXTrPE5K6zPQ5YSO+Sqa6Wq19bW30LPg0sTvwX4htqC5gfwE0o9pzxahYGjgDP5lx8JJ GbmwWr9oLgJdzj/U+Fxs1xK7Tw8I1/hUsozwg= 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; b=MSk/SqsysxmZenaJWy7Y7D0sZGY0NOiuHKRB4yfTiRXWtRbe6rI3I4HunKGEZmGsJZ vDtRgEDZ1w781iWzuOBNKF3H2wJHGASRM47OUt9+iE16y8YS7ErP8VFmwstBbckh5nh8 +QTe5hC3oMUpvAI1Dli4NymFhy1ivHFEkR1Fo= Received: by 10.204.76.18 with SMTP id a18mr8150378bkk.179.1289407314292; Wed, 10 Nov 2010 08:41:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.23.6 with HTTP; Wed, 10 Nov 2010 08:41:31 -0800 (PST) In-Reply-To: <4CD5AC6D.2020705@rice.edu> References: <4CCC31C1.5090602@icyb.net.ua> <4CCC8752.7030403@gmail.com> <4CD5AC6D.2020705@rice.edu> From: Jia-Shiun Li Date: Thu, 11 Nov 2010 00:41:31 +0800 Message-ID: To: Alan Cox Content-Type: text/plain; charset=UTF-8 Cc: alc@freebsd.org, Andriy Gapon , current@freebsd.org Subject: Re: panic: invalid PDPE on recend 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: Wed, 10 Nov 2010 16:41:56 -0000 On Sun, Nov 7, 2010 at 3:28 AM, Alan Cox wrote: > This is a different type of BIOS misconfiguration than your machine had. > > I'm attaching a possible patch for this one. > Sorry for replying late. This patch works for me. The source tree was cvsup on Sunday before previous mail. Thank you! Jia-Shiun. From owner-freebsd-current@FreeBSD.ORG Wed Nov 10 16:58:09 2010 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 6F61D106566B for ; Wed, 10 Nov 2010 16:58:09 +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 3CCBF8FC13 for ; Wed, 10 Nov 2010 16:58:09 +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 D3A4B46B23; Wed, 10 Nov 2010 11:58:08 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7EE9C8A009; Wed, 10 Nov 2010 11:58:07 -0500 (EST) From: John Baldwin To: "C. P. Ghost" Date: Wed, 10 Nov 2010 11:58:06 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201011081714.53637.jhb@freebsd.org> <201011100857.35286.jhb@freebsd.org> In-Reply-To: <201011100857.35286.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011101158.06793.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 10 Nov 2010 11:58:07 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: current@freebsd.org Subject: Re: Only display ACPI bootmenu key if ACPI is present 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, 10 Nov 2010 16:58:09 -0000 On Wednesday, November 10, 2010 8:57:35 am John Baldwin wrote: > On Tuesday, November 09, 2010 5:58:13 pm C. P. Ghost wrote: > > On Mon, Nov 8, 2010 at 11:14 PM, John Baldwin wrote: > > > This patch changes the Forth code for the Beastie menu to only display the > > > menu option to enable or disable ACPI if the loader detects ACPI. This avoids > > > displaying a menu item prompting to enable ACPI if the BIOS doesn't actually > > > include ACPI. Any objections? > > > > Wouldn't that be a POLA violation? Some admins may be used to the > > current menu, and would be scratching head as what went wrong. > > Maybe it would be better to keep the menu option, but make it > > non-selectable and print next to it something like "(not available)"? > > Hmmm, I'll see if I can leave the numbering unchanged but not list > the item perhaps. Note that we already have the "alternate" numbering on > other platforms so the menu is already inconsistent across FreeBSD platforms. It turned out to be easier to leave a blank line to do this, but this patch does that. It leaves the numbers unchanged but simply omits the '2' option if the system does not support ACPI. --- //depot/projects/smpng/sys/boot/forth/beastie.4th 2010-11-08 21:53:18.000000000 0000 +++ //depot/user/jhb/ktrace/boot/forth/beastie.4th 2010-11-10 14:50:44.000000000 0000 @@ -140,12 +140,16 @@ fbsdbw-logo ; -: acpienabled? ( -- flag ) +: acpipresent? ( -- flag ) s" hint.acpi.0.rsdp" getenv dup -1 = if drop false exit then 2drop + true +; + +: acpienabled? ( -- flag ) s" hint.acpi.0.disabled" getenv dup -1 <> if s" 0" compare 0<> if @@ -180,11 +184,18 @@ printmenuitem ." Boot FreeBSD [default]" bootkey ! s" arch-i386" environment? if drop - printmenuitem ." Boot FreeBSD with ACPI " bootacpikey ! - acpienabled? if - ." disabled" + acpipresent? if + printmenuitem ." Boot FreeBSD with ACPI " bootacpikey ! + acpienabled? if + ." disabled" + else + ." enabled" + then else - ." enabled" + menuidx @ + 1+ dup + menuidx ! + -2 bootacpikey ! then else -2 bootacpikey ! -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Nov 10 18:26:07 2010 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 C2105106566C; Wed, 10 Nov 2010 18:26:07 +0000 (UTC) (envelope-from pluknet@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 2B5EB8FC13; Wed, 10 Nov 2010 18:26:06 +0000 (UTC) Received: by qwj8 with SMTP id 8so121508qwj.13 for ; Wed, 10 Nov 2010 10:26:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jJXPW5Gg9GsBZGAn+awKJIbu1ydDK9tuxD64unKKGM0=; b=FU7SlrNdE5y9LiKpPOnMSHmCyuKvbAMoTOsbKZW273rdBEm2F9Wo7pHfmlU1yQO+xB qTT/oAm3pjpXTwhi4ZJHsI459AorzAPwvb7NDWWt86frBLYx9SBwc807vrNE17tY3eSa 1V8HY0KlGwwmMH+z/7Rc20x4/naFWBnpw9jzE= 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=lJHWAgGvYAb8is7hKUx3JemolyJu2JABok9CxR3qnTloN5HF77lbUrQr7C5K9XKBq5 SFdyP4tb9i0w80OfeBAgTuIiBMNJURHFECjWec3wmmpHgOE4kO0/CYr9EDJnUnj57p9o lJTwYPy0QkOTjZE+/Q3nMyGPuHKuaHkwVhH8U= MIME-Version: 1.0 Received: by 10.229.229.135 with SMTP id ji7mr5330367qcb.100.1289413566167; Wed, 10 Nov 2010 10:26:06 -0800 (PST) Received: by 10.229.69.135 with HTTP; Wed, 10 Nov 2010 10:26:06 -0800 (PST) In-Reply-To: <4CDA3CDD.5000404@freebsd.org> References: <4CD7C8FC.900@icyb.net.ua> <4CD7E515.5040209@icyb.net.ua> <4CD7E960.1070200@freebsd.org> <4CDA3CDD.5000404@freebsd.org> Date: Wed, 10 Nov 2010 21:26:06 +0300 Message-ID: From: Sergey Kandaurov To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Ivan Voras Subject: Re: another fuse 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: Wed, 10 Nov 2010 18:26:07 -0000 On 10 November 2010 09:34, Andriy Gapon wrote: > on 08/11/2010 14:13 Andriy Gapon said the following: >> on 08/11/2010 13:55 Andriy Gapon said the following: >>> I reliable got this panic when all I was doing is saving an attachment = in >>> thunderbird 3 that ran in KDE 4 environment. =A0Not sure what was going= on behind >>> the scenes, but shouldn't have been anything out of the ordinary. >> >> Perhaps this is my local mistake. =A0I can't see from code and crash dum= p how NULL >> pointer is possible there. =A0So perhaps I have some ABI mismatch betwee= n kernel >> and fuse module. >> I will rebuild fuse kmod and re-test again. > > Yes, the rebuild has helped. > I wish this could be nicely automated. Hi. If I understood you correctly, then you need PORTS_MODULES set in /etc/make.conf. --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Wed Nov 10 18:45:03 2010 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 4EA62106566B; Wed, 10 Nov 2010 18:45:03 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh5.mail.rice.edu (mh5.mail.rice.edu [128.42.199.32]) by mx1.freebsd.org (Postfix) with ESMTP id 109908FC12; Wed, 10 Nov 2010 18:45:02 +0000 (UTC) Received: from mh5.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh5.mail.rice.edu (Postfix) with ESMTP id 5200428F751; Wed, 10 Nov 2010 12:45:02 -0600 (CST) X-Virus-Scanned: by amavis-2.6.4 at mh5.mail.rice.edu, auth channel Received: from mh5.mail.rice.edu ([127.0.0.1]) by mh5.mail.rice.edu (mh5.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id icnvKZ75EoQH; Wed, 10 Nov 2010 12:45:02 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh5.mail.rice.edu (Postfix) with ESMTPSA id CE34328F7A0; Wed, 10 Nov 2010 12:45:01 -0600 (CST) Message-ID: <4CDAE82C.2040708@rice.edu> Date: Wed, 10 Nov 2010 12:45:00 -0600 From: Alan Cox User-Agent: Thunderbird 2.0.0.24 (X11/20100725) MIME-Version: 1.0 To: Andriy Gapon References: <4CA0DA49.2090006@freebsd.org> <4CA3A48A.5070300@freebsd.org> <4CA3BD1E.5070807@rice.edu> <4CA5911E.3000101@freebsd.org> <4CAE0060.7050607@freebsd.org> <4CAECC4D.90707@rice.edu> <4CD1AA45.7000504@freebsd.org> <4CD1AD80.2090903@rice.edu> <4CD1D4AA.3060309@freebsd.org> <4CD8FFFF.3070106@rice.edu> <4CD996AF.2070300@freebsd.org> In-Reply-To: <4CD996AF.2070300@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 10 Nov 2010 19:07:02 +0000 Cc: Alan Cox , freebsd-current@freebsd.org Subject: Re: minidump size on 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: Wed, 10 Nov 2010 18:45:03 -0000 Andriy Gapon wrote: > on 09/11/2010 10:02 Alan Cox said the following: > >> The kernel portion of the patch looks correct. If I were to make one stylistic >> suggestion, it would be to make the control flow of the outer and inner loops as >> similar as possible, that is, >> >> for (... >> if ((pdp[i] & PG_V) == 0) { >> ... >> continue; >> } >> if ((pdp[i] & PG_PS) != 0) { >> ... >> continue; >> } >> for (... >> if ((pd[j] & PG_V) == 0) >> continue; >> if ((pd[j] & PG_PS) != 0) { >> ... >> continue; >> } >> for (... >> if ((pt[x] & PG_V) == 0) >> continue; >> ... >> >> I think this would make the code a little easier to follow. >> > > This is a very nice suggestion, thank you. > Besides the uniformity some horizontal space is saved too :-) > Updated patch (only kernel part) is here: > http://people.freebsd.org/~avg/amd64-minidump.5.diff > > In the later loop, where you actually write the page directory pages, the "va += ..." in the following looks like a bug because you also update "va" in for (...): + + /* 1GB page is represented as 512 2MB pages in a dump */ + if ((pdp[i] & PG_PS) != 0) { + va += NBPDP; My last three comments are: 1. I would move the assignment i = (va >> PDPSHIFT) & ((1ul << NPDPEPGSHIFT) - 1); so that it comes after pmapsize += PAGE_SIZE; 2. The outermost ()'s aren't needed in the following statement: j = ((va >> PDRSHIFT) & ((1ul << NPDEPGSHIFT) - 1)); 3. I would suggest rewriting the following: + pa = pdp[i] & PG_PS_FRAME; + for (j = 0; j < NPDEPG; j++) + fakepd[j] = (pa + (j << PDRSHIFT)) | + PG_V | PG_PS | PG_RW | PG_A | PG_M; fakepd[0] = pdp[i]; for (j = 1; j < NPDEPG; j++) fakepd[j] = fakepd[j - 1] + NBPDR; Then, whatever properties the pdp entry has will be inherited by the pd entry. From owner-freebsd-current@FreeBSD.ORG Wed Nov 10 19:08:39 2010 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 58C73106566C; Wed, 10 Nov 2010 19:08:39 +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 182408FC1B; Wed, 10 Nov 2010 19:08:37 +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 VAA26702; Wed, 10 Nov 2010 21:08:35 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CDAEDB2.4010704@freebsd.org> Date: Wed, 10 Nov 2010 21:08:34 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Sergey Kandaurov References: <4CD7C8FC.900@icyb.net.ua> <4CD7E515.5040209@icyb.net.ua> <4CD7E960.1070200@freebsd.org> <4CDA3CDD.5000404@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Ivan Voras Subject: Re: another fuse 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: Wed, 10 Nov 2010 19:08:39 -0000 on 10/11/2010 20:26 Sergey Kandaurov said the following: > Hi. > If I understood you correctly, then you need > PORTS_MODULES set in /etc/make.conf. It was a long time ago when I tried it last time, but I remember having problems with it during upgrades. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Nov 10 19:42:46 2010 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 348FB106566C; Wed, 10 Nov 2010 19:42: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 0DA538FC0C; Wed, 10 Nov 2010 19:42:44 +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 VAA27160; Wed, 10 Nov 2010 21:42:42 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CDAF5B1.4040501@freebsd.org> Date: Wed, 10 Nov 2010 21:42:41 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Sergey Kandaurov References: <4CD7C8FC.900@icyb.net.ua> <4CD7E515.5040209@icyb.net.ua> <4CD7E960.1070200@freebsd.org> <4CDA3CDD.5000404@freebsd.org> <4CDAEDB2.4010704@freebsd.org> In-Reply-To: <4CDAEDB2.4010704@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Ivan Voras Subject: Re: another fuse 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: Wed, 10 Nov 2010 19:42:46 -0000 on 10/11/2010 21:08 Andriy Gapon said the following: > on 10/11/2010 20:26 Sergey Kandaurov said the following: >> Hi. >> If I understood you correctly, then you need >> PORTS_MODULES set in /etc/make.conf. > > It was a long time ago when I tried it last time, but I remember having problems > with it during upgrades. I think this is what it was/is. If a port in PORTS_MODULES has dependencies, then buildkernel would try to install those dependencies even if they are already installed. And that, obviously, would fail. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Nov 10 20:18:44 2010 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 C5C731065697; Wed, 10 Nov 2010 20:18:44 +0000 (UTC) (envelope-from yanegomi@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 D44748FC1B; Wed, 10 Nov 2010 20:18:43 +0000 (UTC) Received: by wya21 with SMTP id 21so1218791wya.13 for ; Wed, 10 Nov 2010 12:18:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=ZBBfufQUZ146StgDszFB2/UvQATpM1G14gpMtjs5ZU0=; b=KQ2N+7AMsTqTSFeGJ158mPfHrAS9TDoNNX93u9bDP4ii13Pp7yrnuqEd3xccBPJXqK ZFJFkMGO9f9BhuQWeElnDATtyBap+d9m1YwONQycvOQuEJEwO2sW9RWtF+rjpHIF/JTE fSGFiXW+53qrc8J8z2S+GpafGCG2JnV3e0yWw= 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=FOu7eS65HP4mY777/xXOXW9NP2NT8gIcbmE5Po+9lxopgWy2jGvd5scIZm0ROso1V8 450tR/mmHwhXjOKZWw0Tzis0OxqrAkSA4oGpO9XabysHQZtVGk3xvG+PoVFet+C8fzf6 n2S3tEHXqeh/2FslcWShDFPv3WPG0eSKW35SM= MIME-Version: 1.0 Received: by 10.216.175.18 with SMTP id y18mr8885463wel.30.1289420322665; Wed, 10 Nov 2010 12:18:42 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Wed, 10 Nov 2010 12:18:42 -0800 (PST) In-Reply-To: <4CDAF5B1.4040501@freebsd.org> References: <4CD7C8FC.900@icyb.net.ua> <4CD7E515.5040209@icyb.net.ua> <4CD7E960.1070200@freebsd.org> <4CDA3CDD.5000404@freebsd.org> <4CDAEDB2.4010704@freebsd.org> <4CDAF5B1.4040501@freebsd.org> Date: Wed, 10 Nov 2010 12:18:42 -0800 X-Google-Sender-Auth: -JRvsaMOZ3PeCq9259iCRjUctSY Message-ID: From: Garrett Cooper To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, Sergey Kandaurov , Ivan Voras , freebsd-current@freebsd.org Subject: Re: another fuse 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: Wed, 10 Nov 2010 20:18:44 -0000 On Wed, Nov 10, 2010 at 11:42 AM, Andriy Gapon wrote: > on 10/11/2010 21:08 Andriy Gapon said the following: >> on 10/11/2010 20:26 Sergey Kandaurov said the following: >>> Hi. >>> If I understood you correctly, then you need >>> PORTS_MODULES set in /etc/make.conf. >> >> It was a long time ago when I tried it last time, but I remember having = problems >> with it during upgrades. > > I think this is what it was/is. > If a port in PORTS_MODULES has dependencies, then buildkernel would try t= o install > those dependencies even if they are already installed. =A0And that, obvio= usly, would > fail. Didn't know about this knob -- cool! And FWIW, all it does is a: all install: deinstall reinstall (huh?) reinstall: deinstall reinstall (huh?) clean Seems like it should be: clean all [deinstall] install clean or: clean all install -DFORCE_PKG_REGISTER clean the first clean is just in case the PORTSWORKDIR is dirty. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Nov 10 20:21:39 2010 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 5100A1065673; Wed, 10 Nov 2010 20:21:39 +0000 (UTC) (envelope-from yanegomi@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 5D01D8FC17; Wed, 10 Nov 2010 20:21:37 +0000 (UTC) Received: by wya21 with SMTP id 21so1221731wya.13 for ; Wed, 10 Nov 2010 12:21:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=7Rnux6gzTQowlwVRDy8ov7o4lqrdqINruw1qCpoEXyE=; b=m3E+GFhLd+O+gnQc8gXZI93mKN3dDN+/rJf0VKyCKZs7QnE1QspZy5ivsFOkG6cHTg yz7rISTZKDjsaq5BHcL1UINmWjuc/Scm+AnoilXMZPBz4Cm5ESqn2o1ccqPtY3nLK0qG AtiV4iFsR6NoVvs5GX/n8BF6WbyJt7vTsItCY= 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=fs28eHzdxA85xV6vwXX6+o5vYhr9r3CsPzhz0ODn7b8nC5WMwUJv/8WPrtuARWfTEK l9eZuvxPKJx21qdyoTPyt+QZfd/E27VCT8WSYpLkeNg3s23gOWriVn7u2zXV6e7heUBv SboaJcO+WiVQp8EJpMaWgBAl9KV706t7G1XlI= MIME-Version: 1.0 Received: by 10.216.7.210 with SMTP id 60mr1544969wep.30.1289420496884; Wed, 10 Nov 2010 12:21:36 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Wed, 10 Nov 2010 12:21:36 -0800 (PST) In-Reply-To: References: <4CD7C8FC.900@icyb.net.ua> <4CD7E515.5040209@icyb.net.ua> <4CD7E960.1070200@freebsd.org> <4CDA3CDD.5000404@freebsd.org> <4CDAEDB2.4010704@freebsd.org> <4CDAF5B1.4040501@freebsd.org> Date: Wed, 10 Nov 2010 12:21:36 -0800 X-Google-Sender-Auth: V2owgFY86dIsGIPTYZZW1uYjaJ8 Message-ID: From: Garrett Cooper To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, Sergey Kandaurov , Ivan Voras , freebsd-current@freebsd.org Subject: Re: another fuse 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: Wed, 10 Nov 2010 20:21:39 -0000 On Wed, Nov 10, 2010 at 12:18 PM, Garrett Cooper wrot= e: > On Wed, Nov 10, 2010 at 11:42 AM, Andriy Gapon wrote: >> on 10/11/2010 21:08 Andriy Gapon said the following: >>> on 10/11/2010 20:26 Sergey Kandaurov said the following: >>>> Hi. >>>> If I understood you correctly, then you need >>>> PORTS_MODULES set in /etc/make.conf. >>> >>> It was a long time ago when I tried it last time, but I remember having= problems >>> with it during upgrades. >> >> I think this is what it was/is. >> If a port in PORTS_MODULES has dependencies, then buildkernel would try = to install >> those dependencies even if they are already installed. =A0And that, obvi= ously, would >> fail. > > Didn't know about this knob -- cool! > > And FWIW, all it does is a: > > all > install: deinstall reinstall (huh?) > reinstall: deinstall reinstall (huh?) > clean > > Seems like it should be: > > clean > all > [deinstall] > install > clean > > or: > > clean > all > install -DFORCE_PKG_REGISTER > clean > > the first clean is just in case the PORTSWORKDIR is dirty. And FWIW an even better idea might be to align the port with the process in use, i.e. clean (i.e. NO_CLEAN, KERNFAST, etc not specified) -> [${PORTSDIR}/${PORT}] clean buildkernel -> [${PORTSDIR}/${PORT}] all installkernel -> [${PORTSDIR}/${PORT}] deinstall install *shrugs* -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Nov 10 20:26:21 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id DF31D1065675; Wed, 10 Nov 2010 20:26:21 +0000 (UTC) Date: Wed, 10 Nov 2010 20:26:21 +0000 From: Alexander Best To: Alexey Shuvaev Message-ID: <20101110202621.GA53505@freebsd.org> References: <20101030232244.GA35209@freebsd.org> <20101105214700.GT85693@acme.spoerlein.net> <20101109182512.GA16204@freebsd.org> <20101109194605.GB45046@wep4035.physik.uni-wuerzburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20101109194605.GB45046@wep4035.physik.uni-wuerzburg.de> Cc: freebsd-current@freebsd.org Subject: Re: issue with "options DDB" 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, 10 Nov 2010 20:26:22 -0000 On Tue Nov 9 10, Alexey Shuvaev wrote: > On Tue, Nov 09, 2010 at 06:25:12PM +0000, Alexander Best wrote: > > On Fri Nov 5 10, Ulrich Spörlein wrote: > > > On Sat, 30.10.2010 at 23:22:44 +0000, Alexander Best wrote: > > > > hi there, > > > > > > > > with "options DDB" in my kernel conf i run into the following issue with my > > > > kernel modules: > > > > > > > > link_elf_lookup_symbol: missing symbol hash table > > > > KLD file snd_hda.ko is missing dependencies > > > > KLD file sound.ko is missing dependencies > > > > KLD file nvidia.ko is missing dependencies > > > > KLD file linux.ko is missing dependencies > > > > KLD file ng_ubt.ko is missing dependencies > > > > KLD file ng_hci.ko is missing dependencies > > > > KLD file ng_bluetooth.ko is missing dependencies > > > > KLD file netgraph.ko is missing dependencies > > > > link_elf_lookup_symbol: missing symbol hash table > > > > > > > > removing the option solves the issue. any advice? > > > > > > > > cheers. > > > > alex > > > > > > > > ps: i'm running HEAD (r214542; amd64). > > > > > > You failed to mention the command that you run. I assume 'buildkernel'? > > > Please note that you need and update-to-date "buildworld" for the kernel > > > tools to be there, so please try the following (with options DDB): > > > > > > cd /usr/src > > > make clean; make cleandir; make clean > > > make buildworld > > > make buildkernel KERNCONF=YOURKERNEL > > > > hmmm....seems there is a problem with gcc. this is what i get during > > buildworld: > > > > > > clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector -fconserve-space -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/tinfo2.cc > > clang++: warning: argument unused during compilation: '-fconserve-space' > ^^^^^^^^^^^ > > > clang++: warning: argument unused during compilation: '-fno-implicit-templates' > > clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector -fconserve-space -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vec.cc > > clang++: warning: argument unused during compilation: '-fconserve-space' > > clang++: warning: argument unused during compilation: '-fno-implicit-templates' > > clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector -fconserve-space -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vterminate.cc > > clang++: warning: argument unused during compilation: '-fconserve-space' > > clang++: warning: argument unused during compilation: '-fno-implicit-templates' > > clang -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -std=gnu99 -fstack-protector -c /usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/libiberty/cp-demangle.c > > building static supc++ library > > ranlib libsupc++.a > > ===> gnu/lib/libobjc (all) > > gcc -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DHAVE_GTHR_DEFAULT -DIN_GCC -DIN_TARGET_LIBS -I. -I/usr/src/gnu/lib/libobjc/../../usr.bin/cc/cc_tools -I/usr/src/gnu/lib/libobjc/../../../contrib/libobjc/objc -I/usr/src/gnu/lib/libobjc/../../../contrib/libobjc -I/usr/src/gnu/lib/libobjc/../../../contrib/gcc/config -I/usr/src/gnu/lib/libobjc/../../../contrib/gcc -I/usr/src/gnu/lib/libobjc/../../../contrib/gcclibs/include -fexceptions -frandom-seed=RepeatabilityConsideredGood -g -std=gnu99 -fstack-protector -c /usr/src/gnu/lib/libobjc/../../../contrib/libobjc/archive.c > > *** Signal 11 > > > > Stop in /usr/src/gnu/lib/libobjc. > > *** Error code 1 > > > > Stop in /usr/src/gnu/lib. > > *** Error code 1 > > > > Stop in /usr/src. > > *** Error code 1 > > > > Stop in /usr/src. > > *** Error code 1 > > > > Stop in /usr/src. > > *** Error code 1 > > > > Stop in /usr/src. > > > > > > i've ran buildworld twice (with a clean /usr/src and non-existing /usr/obj/*) > > and got the error twice, so it's not a hardware problem it seems. > > > > if i'm not mistaken the gcc that is being used for buildworld is not the one in > > /usr/bin, but a fresh build in /usr/obj, right? > > > > this is the bt from "gdb /usr/obj/usr/src/tmp/usr/bin/gcc gcc.core". i hope i > > picked the correct gcc executable: > > > > > > Core was generated by `gcc'. > > Program terminated with signal 11, Segmentation fault. > > #0 host_detect_local_cpu (argc=Variable "argc" is not available. > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/config/i386/driver-i386.c:272 > > 272 return concat ("-m", argv[0], "=", cpu, NULL); > > (gdb) bt > > #0 host_detect_local_cpu (argc=Variable "argc" is not available. > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/config/i386/driver-i386.c:272 > > #1 0x000000000040c754 in eval_spec_function (func=Cannot access memory at address 0x0 > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5520 > > #2 0x00000000004093f2 in do_spec_1 (spec=Variable "spec" is not available. > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5591 > > #3 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > > #4 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > > #5 0x0000000000409398 in do_spec_1 (spec=Variable "spec" is not available. > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5413 > > #6 0x0000000000409545 in do_spec_1 (spec=Variable "spec" is not available. > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5193 > > #7 0x0000000000409398 in do_spec_1 (spec=Variable "spec" is not available. > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5413 > > #8 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > > #9 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > > #10 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > > #11 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > > #12 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > > #13 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > > #14 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > > #15 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > > #16 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > > #17 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > > #18 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > > #19 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > > #20 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > > #21 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > > #22 0x00000000004003ec in do_spec_2 (spec=0x1
) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:4490 > > #23 0x000000000040033d in do_spec (spec=0x1
) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:4458 > > #24 0x00000000004036d1 in main (argc=23, argv=0x7fffffffe240) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:6712 > > > So, you are trying to do a mixed clang+gcc build. Which architecture is this? > Does the problem occur in the case of a pure gcc build? i just tried and with gcc buildworld succeeds. cheers. alex > > HTH, > Alexey. -- a13x From owner-freebsd-current@FreeBSD.ORG Wed Nov 10 21:32:15 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id DDAFD1065674; Wed, 10 Nov 2010 21:32:15 +0000 (UTC) Date: Wed, 10 Nov 2010 21:32:15 +0000 From: Alexander Best To: Alexey Shuvaev Message-ID: <20101110213215.GA68484@freebsd.org> References: <20101030232244.GA35209@freebsd.org> <20101105214700.GT85693@acme.spoerlein.net> <20101109182512.GA16204@freebsd.org> <20101109194605.GB45046@wep4035.physik.uni-wuerzburg.de> <20101110202621.GA53505@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20101110202621.GA53505@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: issue with "options DDB" 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, 10 Nov 2010 21:32:15 -0000 On Wed Nov 10 10, Alexander Best wrote: > On Tue Nov 9 10, Alexey Shuvaev wrote: > > On Tue, Nov 09, 2010 at 06:25:12PM +0000, Alexander Best wrote: > > > On Fri Nov 5 10, Ulrich Spörlein wrote: > > > > On Sat, 30.10.2010 at 23:22:44 +0000, Alexander Best wrote: > > > > > hi there, > > > > > > > > > > with "options DDB" in my kernel conf i run into the following issue with my > > > > > kernel modules: > > > > > > > > > > link_elf_lookup_symbol: missing symbol hash table > > > > > KLD file snd_hda.ko is missing dependencies > > > > > KLD file sound.ko is missing dependencies > > > > > KLD file nvidia.ko is missing dependencies > > > > > KLD file linux.ko is missing dependencies > > > > > KLD file ng_ubt.ko is missing dependencies > > > > > KLD file ng_hci.ko is missing dependencies > > > > > KLD file ng_bluetooth.ko is missing dependencies > > > > > KLD file netgraph.ko is missing dependencies > > > > > link_elf_lookup_symbol: missing symbol hash table > > > > > > > > > > removing the option solves the issue. any advice? > > > > > > > > > > cheers. > > > > > alex > > > > > > > > > > ps: i'm running HEAD (r214542; amd64). > > > > > > > > You failed to mention the command that you run. I assume 'buildkernel'? > > > > Please note that you need and update-to-date "buildworld" for the kernel > > > > tools to be there, so please try the following (with options DDB): > > > > > > > > cd /usr/src > > > > make clean; make cleandir; make clean > > > > make buildworld > > > > make buildkernel KERNCONF=YOURKERNEL > > > > > > hmmm....seems there is a problem with gcc. this is what i get during > > > buildworld: > > > > > > > > > clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector -fconserve-space -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/tinfo2.cc > > > clang++: warning: argument unused during compilation: '-fconserve-space' > > ^^^^^^^^^^^ > > > > > clang++: warning: argument unused during compilation: '-fno-implicit-templates' > > > clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector -fconserve-space -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vec.cc > > > clang++: warning: argument unused during compilation: '-fconserve-space' > > > clang++: warning: argument unused during compilation: '-fno-implicit-templates' > > > clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector -fconserve-space -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vterminate.cc > > > clang++: warning: argument unused during compilation: '-fconserve-space' > > > clang++: warning: argument unused during compilation: '-fno-implicit-templates' > > > clang -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -std=gnu99 -fstack-protector -c /usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/libiberty/cp-demangle.c > > > building static supc++ library > > > ranlib libsupc++.a > > > ===> gnu/lib/libobjc (all) > > > gcc -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DHAVE_GTHR_DEFAULT -DIN_GCC -DIN_TARGET_LIBS -I. -I/usr/src/gnu/lib/libobjc/../../usr.bin/cc/cc_tools -I/usr/src/gnu/lib/libobjc/../../../contrib/libobjc/objc -I/usr/src/gnu/lib/libobjc/../../../contrib/libobjc -I/usr/src/gnu/lib/libobjc/../../../contrib/gcc/config -I/usr/src/gnu/lib/libobjc/../../../contrib/gcc -I/usr/src/gnu/lib/libobjc/../../../contrib/gcclibs/include -fexceptions -frandom-seed=RepeatabilityConsideredGood -g -std=gnu99 -fstack-protector -c /usr/src/gnu/lib/libobjc/../../../contrib/libobjc/archive.c > > > *** Signal 11 > > > > > > Stop in /usr/src/gnu/lib/libobjc. > > > *** Error code 1 > > > > > > Stop in /usr/src/gnu/lib. > > > *** Error code 1 > > > > > > Stop in /usr/src. > > > *** Error code 1 > > > > > > Stop in /usr/src. > > > *** Error code 1 > > > > > > Stop in /usr/src. > > > *** Error code 1 > > > > > > Stop in /usr/src. > > > > > > > > > i've ran buildworld twice (with a clean /usr/src and non-existing /usr/obj/*) > > > and got the error twice, so it's not a hardware problem it seems. > > > > > > if i'm not mistaken the gcc that is being used for buildworld is not the one in > > > /usr/bin, but a fresh build in /usr/obj, right? > > > > > > this is the bt from "gdb /usr/obj/usr/src/tmp/usr/bin/gcc gcc.core". i hope i > > > picked the correct gcc executable: > > > > > > > > > Core was generated by `gcc'. > > > Program terminated with signal 11, Segmentation fault. > > > #0 host_detect_local_cpu (argc=Variable "argc" is not available. > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/config/i386/driver-i386.c:272 > > > 272 return concat ("-m", argv[0], "=", cpu, NULL); > > > (gdb) bt > > > #0 host_detect_local_cpu (argc=Variable "argc" is not available. > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/config/i386/driver-i386.c:272 > > > #1 0x000000000040c754 in eval_spec_function (func=Cannot access memory at address 0x0 > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5520 > > > #2 0x00000000004093f2 in do_spec_1 (spec=Variable "spec" is not available. > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5591 > > > #3 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > > > #4 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > > > #5 0x0000000000409398 in do_spec_1 (spec=Variable "spec" is not available. > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5413 > > > #6 0x0000000000409545 in do_spec_1 (spec=Variable "spec" is not available. > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5193 > > > #7 0x0000000000409398 in do_spec_1 (spec=Variable "spec" is not available. > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5413 > > > #8 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > > > #9 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > > > #10 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > > > #11 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > > > #12 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > > > #13 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > > > #14 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > > > #15 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > > > #16 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > > > #17 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > > > #18 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > > > #19 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > > > #20 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > > > #21 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > > > #22 0x00000000004003ec in do_spec_2 (spec=0x1
) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:4490 > > > #23 0x000000000040033d in do_spec (spec=0x1
) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:4458 > > > #24 0x00000000004036d1 in main (argc=23, argv=0x7fffffffe240) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:6712 > > > > > So, you are trying to do a mixed clang+gcc build. Which architecture is this? > > Does the problem occur in the case of a pure gcc build? > > i just tried and with gcc buildworld succeeds. maybe i should cd to /usr/sr/usr.bin/clang and install it before doing builworld. maybe my clang version contains an already fixed bug? 'clang -v' reports: FreeBSD clang version 2.8 (branches/release_28 114020) 20100917 Target: x86_64-undermydesk-freebsd9.0 Thread model: posix cheers. alex > > cheers. > alex > > > > > HTH, > > Alexey. > > -- > a13x -- a13x From owner-freebsd-current@FreeBSD.ORG Wed Nov 10 21:58:39 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id C4681106566B; Wed, 10 Nov 2010 21:58:39 +0000 (UTC) Date: Wed, 10 Nov 2010 21:58:39 +0000 From: Alexander Best To: John Baldwin Message-ID: <20101110215839.GA74943@freebsd.org> References: <20101109114612.GA58585@freebsd.org> <201011090844.28609.jhb@freebsd.org> <20101109141028.GA75878@freebsd.org> <201011090937.40121.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201011090937.40121.jhb@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: kldunload(8) returns 0, although it fail 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, 10 Nov 2010 21:58:39 -0000 On Tue Nov 9 10, John Baldwin wrote: > On Tuesday, November 09, 2010 9:10:28 am Alexander Best wrote: > > On Tue Nov 9 10, John Baldwin wrote: > > > On Tuesday, November 09, 2010 6:46:12 am Alexander Best wrote: > > > > hi there, > > > > > > > > i posted this message on freebsd-questions@, but nobody could help me with it. > > > > to me this looks like a bug, so i assume posting it again here on > > > > freebsd-current@ might be better. > > > > > > > > please keep in mind that the issue here is not the fact that the second attempt > > > > to unload sound.ko/netgraph.ko fails. it *should* fail, because both modules > > > > have dependencies. however it should fail with the first attempt. right now > > > > kldunloadf() returns zero, whereas it should actually return EBUSY (just like > > > > the second attempt). > > > > > > > > i've attached two kdump outputs: one for the first 'kldunload' attempt and one > > > > for the second. as you can see the problem is that for some reason kldunloadf() > > > > returns zero, although it couldn't unload the module. > > > > > > Did you get an error message in dmesg? If you have manually loaded > > > netgraph.ko (via netgraph_load="YES" in loader.conf or an explicit kldload) > > > and then loaded other modules that depend on it (such as ng_foo.ko) then this > > > is expected behavior. What your kldunload has done is to remove the manual > > > reference from loader.conf or 'kldload netgraph.ko'. What this changes is what > > > happens when you do 'kldunload ng_foo.ko'. If you unload ng_foo.ko now, then > > > netgraph.ko will also be unloaded when its last reference drops (in this case > > > it looks like you actually have two ng_*.ko objects loaded, so you would have > > > to unload both of them, but I will assume a single ng_foo.ko to make the > > > explanation simpler). If you had not done 'kldunload netgraph.ko' but had > > > done 'kldunload ng_foo.ko', then the manual reference would have kept netgraph.ko > > > loaded. > > > > > > All this logic exists so that if you do 'kldload foo.ko' and it auto-loads bar.ko > > > as a dependency, then doing 'kldunload bar.ko' will unload both foo.ko and bar.ko. > > > > i have ng_ubt_load="YES" in my loader.conf and kldstat says: > > > > Id Refs Address Size Name > > 1 37 0xffffffff80100000 a2ddb8 kernel > > 2 1 0xffffffff80b2e000 295e8 snd_hda.ko > > 3 1 0xffffffff80b58000 85110 sound.ko > > 4 1 0xffffffff80bde000 cf79e0 nvidia.ko > > 5 5 0xffffffff818d6000 418c0 linux.ko > > 6 1 0xffffffff81918000 80e8 ng_ubt.ko > > 7 2 0xffffffff81921000 fa78 ng_hci.ko > > 8 2 0xffffffff81931000 2bd0 ng_bluetooth.ko > > 9 3 0xffffffff81934000 15e68 netgraph.ko > > 10 1 0xffffffff81a12000 3efb linprocfs.ko > > 11 3 0xffffffff81a16000 4698 pseudofs.ko > > 12 1 0xffffffff81a1b000 31b3 procfs.ko > > 13 1 0xffffffff81a1f000 a37 linsysfs.ko > > 14 1 0xffffffff81a20000 6f4 rtc.ko > > > > also the same happens with sound.ko. i have snd_hda_load="yes". and i think > > snd_hda is the only dependecy for sound.ko. > > > > there was no error message in dmesg for the first kldunload attempt. > > > > i think i understand the logic, however the current behavior does not confirm > > to the description in kldunload(2). > > Hmm, ok, fair enough. Do you get the same behavior if you kldload ng_ubt.ko > after boot? i'll try that in a minute. this behavior also seems very odd: 1) kldstat reports netgraph.ko *not* loaded 2) kldload netgraph 3) kldunload netgraph fails with EBUSY, although kldstat reports only a single REF for netgraph. could this be caused by an out of sync kernel and world? cheers. alex > > -- > John Baldwin -- a13x From owner-freebsd-current@FreeBSD.ORG Wed Nov 10 22:07:21 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id C395C1065673; Wed, 10 Nov 2010 22:07:21 +0000 (UTC) Date: Wed, 10 Nov 2010 22:07:21 +0000 From: Alexander Best To: John Baldwin Message-ID: <20101110220721.GA76154@freebsd.org> References: <20101109114612.GA58585@freebsd.org> <201011090844.28609.jhb@freebsd.org> <20101109141028.GA75878@freebsd.org> <201011090937.40121.jhb@freebsd.org> <20101110215839.GA74943@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101110215839.GA74943@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: kldunload(8) returns 0, although it fail 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, 10 Nov 2010 22:07:21 -0000 On Wed Nov 10 10, Alexander Best wrote: > On Tue Nov 9 10, John Baldwin wrote: > > On Tuesday, November 09, 2010 9:10:28 am Alexander Best wrote: > > > On Tue Nov 9 10, John Baldwin wrote: > > > > On Tuesday, November 09, 2010 6:46:12 am Alexander Best wrote: > > > > > hi there, > > > > > > > > > > i posted this message on freebsd-questions@, but nobody could help me with it. > > > > > to me this looks like a bug, so i assume posting it again here on > > > > > freebsd-current@ might be better. > > > > > > > > > > please keep in mind that the issue here is not the fact that the second attempt > > > > > to unload sound.ko/netgraph.ko fails. it *should* fail, because both modules > > > > > have dependencies. however it should fail with the first attempt. right now > > > > > kldunloadf() returns zero, whereas it should actually return EBUSY (just like > > > > > the second attempt). > > > > > > > > > > i've attached two kdump outputs: one for the first 'kldunload' attempt and one > > > > > for the second. as you can see the problem is that for some reason kldunloadf() > > > > > returns zero, although it couldn't unload the module. > > > > > > > > Did you get an error message in dmesg? If you have manually loaded > > > > netgraph.ko (via netgraph_load="YES" in loader.conf or an explicit kldload) > > > > and then loaded other modules that depend on it (such as ng_foo.ko) then this > > > > is expected behavior. What your kldunload has done is to remove the manual > > > > reference from loader.conf or 'kldload netgraph.ko'. What this changes is what > > > > happens when you do 'kldunload ng_foo.ko'. If you unload ng_foo.ko now, then > > > > netgraph.ko will also be unloaded when its last reference drops (in this case > > > > it looks like you actually have two ng_*.ko objects loaded, so you would have > > > > to unload both of them, but I will assume a single ng_foo.ko to make the > > > > explanation simpler). If you had not done 'kldunload netgraph.ko' but had > > > > done 'kldunload ng_foo.ko', then the manual reference would have kept netgraph.ko > > > > loaded. > > > > > > > > All this logic exists so that if you do 'kldload foo.ko' and it auto-loads bar.ko > > > > as a dependency, then doing 'kldunload bar.ko' will unload both foo.ko and bar.ko. > > > > > > i have ng_ubt_load="YES" in my loader.conf and kldstat says: > > > > > > Id Refs Address Size Name > > > 1 37 0xffffffff80100000 a2ddb8 kernel > > > 2 1 0xffffffff80b2e000 295e8 snd_hda.ko > > > 3 1 0xffffffff80b58000 85110 sound.ko > > > 4 1 0xffffffff80bde000 cf79e0 nvidia.ko > > > 5 5 0xffffffff818d6000 418c0 linux.ko > > > 6 1 0xffffffff81918000 80e8 ng_ubt.ko > > > 7 2 0xffffffff81921000 fa78 ng_hci.ko > > > 8 2 0xffffffff81931000 2bd0 ng_bluetooth.ko > > > 9 3 0xffffffff81934000 15e68 netgraph.ko > > > 10 1 0xffffffff81a12000 3efb linprocfs.ko > > > 11 3 0xffffffff81a16000 4698 pseudofs.ko > > > 12 1 0xffffffff81a1b000 31b3 procfs.ko > > > 13 1 0xffffffff81a1f000 a37 linsysfs.ko > > > 14 1 0xffffffff81a20000 6f4 rtc.ko > > > > > > also the same happens with sound.ko. i have snd_hda_load="yes". and i think > > > snd_hda is the only dependecy for sound.ko. > > > > > > there was no error message in dmesg for the first kldunload attempt. > > > > > > i think i understand the logic, however the current behavior does not confirm > > > to the description in kldunload(2). > > > > Hmm, ok, fair enough. Do you get the same behavior if you kldload ng_ubt.ko > > after boot? just tested and the behavior is *not* the same. when i do kldload ng_ubt after boot everything seems fine. netgraph gets loaded and has a REF count of 2. if i try doing `kldunload netgraph` i get EBUSY the first time i run that command. when i add ng_ubt_load=yes to /boot/loader.conf kldstat reports a REF count of 3 for netgraph.ko and i get the behavior i described beforehand. cheers. alex > > i'll try that in a minute. this behavior also seems very odd: > > 1) kldstat reports netgraph.ko *not* loaded > 2) kldload netgraph > 3) kldunload netgraph fails with EBUSY, although kldstat reports only a single > REF for netgraph. > > could this be caused by an out of sync kernel and world? > > cheers. > alex > > > > > -- > > John Baldwin > > -- > a13x -- a13x From owner-freebsd-current@FreeBSD.ORG Wed Nov 10 22:22:11 2010 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 5BC3E106566B; Wed, 10 Nov 2010 22:22:11 +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 19F298FC0C; Wed, 10 Nov 2010 22:22:10 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oAAMMA6q016348; Wed, 10 Nov 2010 17:22:10 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oAAMMAQf016347; Wed, 10 Nov 2010 22:22:10 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 10 Nov 2010 22:22:10 GMT Message-Id: <201011102222.oAAMMAQf016347@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: Wed, 10 Nov 2010 22:22:11 -0000 TB --- 2010-11-10 22:21:49 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-10 22:21:49 - starting HEAD tinderbox run for mips/mips TB --- 2010-11-10 22:21:49 - cleaning the object tree TB --- 2010-11-10 22:21:49 - cvsupping the source tree TB --- 2010-11-10 22:21:49 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2010-11-10 22:22:07 - building world TB --- 2010-11-10 22:22:07 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-10 22:22:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-10 22:22:07 - TARGET=mips TB --- 2010-11-10 22:22:07 - TARGET_ARCH=mips TB --- 2010-11-10 22:22:07 - TZ=UTC TB --- 2010-11-10 22:22:07 - __MAKE_CONF=/dev/null TB --- 2010-11-10 22:22:07 - cd /src TB --- 2010-11-10 22:22:07 - /usr/bin/make -B buildworld "/src/Makefile.inc1", line 138: Unknown target mips:mips. *** Error code 1 Stop in /src. TB --- 2010-11-10 22:22:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-10 22:22:10 - ERROR: failed to build world TB --- 2010-11-10 22:22:10 - 2.12 user 6.92 system 20.59 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Wed Nov 10 22:26:50 2010 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 812EF1065674; Wed, 10 Nov 2010 22:26:50 +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 51ABC8FC19; Wed, 10 Nov 2010 22:26:50 +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 046F646B06; Wed, 10 Nov 2010 17:26:50 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id EF81D8A009; Wed, 10 Nov 2010 17:26:48 -0500 (EST) From: John Baldwin To: Alexander Best Date: Wed, 10 Nov 2010 17:17:50 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20101109114612.GA58585@freebsd.org> <20101110215839.GA74943@freebsd.org> <20101110220721.GA76154@freebsd.org> In-Reply-To: <20101110220721.GA76154@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011101717.51062.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 10 Nov 2010 17:26:49 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org Subject: Re: kldunload(8) returns 0, although it fail 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, 10 Nov 2010 22:26:50 -0000 On Wednesday, November 10, 2010 5:07:21 pm Alexander Best wrote: > On Wed Nov 10 10, Alexander Best wrote: > > On Tue Nov 9 10, John Baldwin wrote: > > > On Tuesday, November 09, 2010 9:10:28 am Alexander Best wrote: > > > > On Tue Nov 9 10, John Baldwin wrote: > > > > > On Tuesday, November 09, 2010 6:46:12 am Alexander Best wrote: > > > > > > hi there, > > > > > > > > > > > > i posted this message on freebsd-questions@, but nobody could help me with it. > > > > > > to me this looks like a bug, so i assume posting it again here on > > > > > > freebsd-current@ might be better. > > > > > > > > > > > > please keep in mind that the issue here is not the fact that the second attempt > > > > > > to unload sound.ko/netgraph.ko fails. it *should* fail, because both modules > > > > > > have dependencies. however it should fail with the first attempt. right now > > > > > > kldunloadf() returns zero, whereas it should actually return EBUSY (just like > > > > > > the second attempt). > > > > > > > > > > > > i've attached two kdump outputs: one for the first 'kldunload' attempt and one > > > > > > for the second. as you can see the problem is that for some reason kldunloadf() > > > > > > returns zero, although it couldn't unload the module. > > > > > > > > > > Did you get an error message in dmesg? If you have manually loaded > > > > > netgraph.ko (via netgraph_load="YES" in loader.conf or an explicit kldload) > > > > > and then loaded other modules that depend on it (such as ng_foo.ko) then this > > > > > is expected behavior. What your kldunload has done is to remove the manual > > > > > reference from loader.conf or 'kldload netgraph.ko'. What this changes is what > > > > > happens when you do 'kldunload ng_foo.ko'. If you unload ng_foo.ko now, then > > > > > netgraph.ko will also be unloaded when its last reference drops (in this case > > > > > it looks like you actually have two ng_*.ko objects loaded, so you would have > > > > > to unload both of them, but I will assume a single ng_foo.ko to make the > > > > > explanation simpler). If you had not done 'kldunload netgraph.ko' but had > > > > > done 'kldunload ng_foo.ko', then the manual reference would have kept netgraph.ko > > > > > loaded. > > > > > > > > > > All this logic exists so that if you do 'kldload foo.ko' and it auto-loads bar.ko > > > > > as a dependency, then doing 'kldunload bar.ko' will unload both foo.ko and bar.ko. > > > > > > > > i have ng_ubt_load="YES" in my loader.conf and kldstat says: > > > > > > > > Id Refs Address Size Name > > > > 1 37 0xffffffff80100000 a2ddb8 kernel > > > > 2 1 0xffffffff80b2e000 295e8 snd_hda.ko > > > > 3 1 0xffffffff80b58000 85110 sound.ko > > > > 4 1 0xffffffff80bde000 cf79e0 nvidia.ko > > > > 5 5 0xffffffff818d6000 418c0 linux.ko > > > > 6 1 0xffffffff81918000 80e8 ng_ubt.ko > > > > 7 2 0xffffffff81921000 fa78 ng_hci.ko > > > > 8 2 0xffffffff81931000 2bd0 ng_bluetooth.ko > > > > 9 3 0xffffffff81934000 15e68 netgraph.ko > > > > 10 1 0xffffffff81a12000 3efb linprocfs.ko > > > > 11 3 0xffffffff81a16000 4698 pseudofs.ko > > > > 12 1 0xffffffff81a1b000 31b3 procfs.ko > > > > 13 1 0xffffffff81a1f000 a37 linsysfs.ko > > > > 14 1 0xffffffff81a20000 6f4 rtc.ko > > > > > > > > also the same happens with sound.ko. i have snd_hda_load="yes". and i think > > > > snd_hda is the only dependecy for sound.ko. > > > > > > > > there was no error message in dmesg for the first kldunload attempt. > > > > > > > > i think i understand the logic, however the current behavior does not confirm > > > > to the description in kldunload(2). > > > > > > Hmm, ok, fair enough. Do you get the same behavior if you kldload ng_ubt.ko > > > after boot? > > just tested and the behavior is *not* the same. when i do kldload ng_ubt after > boot everything seems fine. netgraph gets loaded and has a REF count of 2. if i > try doing `kldunload netgraph` i get EBUSY the first time i run that command. > when i add ng_ubt_load=yes to /boot/loader.conf kldstat reports a REF count of > 3 for netgraph.ko and i get the behavior i described beforehand. Try doing 'kldload netgraph.ko' and then 'kldload ng_ubt.ko' (along with manually loading any other netgraph modules so that nothing is loaded magically as a dependency) and see what behavior that gives you. When you load modules from the loader, they and all their dependencies are treated as if you had manually loaded them similar to kldload. This because the kernel can't determine which modules loaded by the loader were silent dependencies. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Nov 10 22:47:06 2010 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 2CB98106566B; Wed, 10 Nov 2010 22:47:06 +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 C02448FC1C; Wed, 10 Nov 2010 22:47:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oAAMl46X091244; Wed, 10 Nov 2010 17:47:04 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oAAMl476091242; Wed, 10 Nov 2010 22:47:04 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 10 Nov 2010 22:47:04 GMT Message-Id: <201011102247.oAAMl476091242@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: Wed, 10 Nov 2010 22:47:06 -0000 TB --- 2010-11-10 22:41:54 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-10 22:41:54 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-11-10 22:41:54 - cleaning the object tree TB --- 2010-11-10 22:41:57 - cvsupping the source tree TB --- 2010-11-10 22:41:57 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-11-10 22:42:13 - building world TB --- 2010-11-10 22:42:13 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-10 22:42:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-10 22:42:13 - TARGET=powerpc TB --- 2010-11-10 22:42:13 - TARGET_ARCH=powerpc64 TB --- 2010-11-10 22:42:13 - TZ=UTC TB --- 2010-11-10 22:42:13 - __MAKE_CONF=/dev/null TB --- 2010-11-10 22:42:13 - cd /src TB --- 2010-11-10 22:42:13 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 10 22:42:14 UTC 2010 >>> 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 [...] cc -o rtermcap /src/usr.sbin/sysinstall/rtermcap.c -ltermcap ===> gnu/usr.bin/cc/cc_tools (obj,depend,all) LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-gather.awk /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/c.opt /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/common.opt /src/gnu/usr.bin/cc/cc_tools/freebsd.opt > optionlist LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-functions.awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opth-gen.awk < optionlist > options.h LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-functions.awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/optc-gen.awk -v header_name="config.h system.h coretypes.h tm.h" < optionlist > options.c TARGET_CPU_DEFAULT="\"powerpc64\"" HEADERS="auto-host.h ansidecl.h" DEFINES="" /bin/sh /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/mkconfig.sh bconfig.h TARGET_CPU_DEFAULT="\"powerpc64\"" HEADERS="options.h rs600064/rs600064.h dbxelf.h elfos-undef.h elfos.h freebsd-native.h freebsd-spec.h freebsd.h rs600064/biarch64.h rs600064/default64.h rs600064/freebsd.h defaults.h" DEFINES="" /bin/sh /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/mkconfig.sh tm.h make: don't know how to make /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config/rs600064/rs600064.c. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-10 22:47:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-10 22:47:04 - ERROR: failed to build world TB --- 2010-11-10 22:47:04 - 206.12 user 55.98 system 309.95 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 11 00:32:55 2010 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 D56F3106566B for ; Thu, 11 Nov 2010 00:32:55 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id AAE108FC16 for ; Thu, 11 Nov 2010 00:32:55 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.4/8.14.4) with ESMTP id oAB0WtX5007197 for ; Wed, 10 Nov 2010 16:32:55 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.4/8.14.4/Submit) id oAB0WsCk007196 for freebsd-current@freebsd.org; Wed, 10 Nov 2010 16:32:54 -0800 (PST) (envelope-from obrien) Date: Wed, 10 Nov 2010 16:32:54 -0800 From: "David O'Brien" To: freebsd-current@freebsd.org Message-ID: <20101111003254.GA7139@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 9.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? User-Agent: Mutt/1.5.16 (2007-06-09) Subject: Non-sleepable locks PANIC in sf(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@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: Thu, 11 Nov 2010 00:32:55 -0000 Script started on Wed Nov 10 15:56:31 2010 FreeBSD 9.0-CURRENT #644 r215099M: Wed Nov 10 11:45:01 PST 2010 obrien@dragon:/usr/obj/4kib/i386/compile/DRAGON-WITNESS i386 WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. [..] Setting hostname: dragon.NUXI.org. sf0: port 0x8800-0x88ff mem 0xfa480000-0xfa4fffff irq 26 at device 4.0 on pci3 miibus1: on sf0 ukphy0: PHY 1 on miibus1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sf0: Ethernet address: 00:00:d1:ed:81:95 sf1: port 0x8400-0x84ff mem 0xfa380000-0xfa3fffff irq 27 at device 5.0 on pci3 miibus2: on sf1 ukphy1: PHY 1 on miibus2 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sf1: Ethernet address: 00:00:d1:ed:81:96 sf2: port 0x8000-0x80ff mem 0xfa300000-0xfa37ffff irq 24 at device 6.0 on pci3 miibus3: on sf2 ukphy2: PHY 1 on miibus3 ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sf2: Ethernet address: 00:00:d1:ed:81:97 sf3: port 0x7800-0x78ff mem 0xfa200000-0xfa27ffff irq 25 at device 7.0 on pci3 miibus4: on sf3 ukphy3: PHY 1 on miibus4 ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sf3: Ethernet address: 00:00:d1:ed:81:98 Expensive timeout(9) function: 0xc061b270(0xc65965a0) 1.987919972 s [..] Starting Network: lo0 bge0 sf0 em0. [..] sf0: flags=8843 metric 0 mtu 1500 options=b ether 00:00:d1:ed:81:95 inet 74.95.12.85 netmask 0xfffffffc broadcast 74.95.12.87 inet6 fe80::200:d1ff:feed:8195%sf0 prefixlen 64 tentative scopeid 0x5 nd6 options=29 media: Ethernet autoselect (100baseTX ) status: active [..] Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex sf0 (network driver) r = 0 (0xc722b584) locked @ /usr/obj/4kib/modules/sf/../../dev/sf/if_sf.c:1862 KDB: stack backtrace: db_trace_self_wrapper(c08870ef,c6be8a80,4,c0a83ba0,c704164c,...) at 0xc04ed726 = db_trace_self_wrapper+0x26 kdb_backtrace(746,0,ffffffff,c0a83b94,daaa2ac0,...) at 0xc061152a = kdb_backtrace+0x2a _witness_debugger(c08898ba,daaa2ad4,4,1,0,...) at 0xc0626256 = _witness_debugger+0x26 witness_warn(5,0,c08b2265,246,c70415a0,...) at 0xc062776d = witness_warn+0x1fd trap(daaa2bac) at 0xc08214bd = trap+0x2ad calltrap() at 0xc080b93c = calltrap+0x6 --- trap 0xc, eip = 0xc08077c4, esp = 0xdaaa2bec, ebp = 0xdaaa2c00 --- _bus_dmamap_sync(c6cbac80,c724a000,2,daaa2c28,daaa2c30,...) at 0xc08077c4 = _bus_dmamap_sync+0x54 sf_newbuf(c722b584,4,c7223bbd,603,c06051d5,...) at 0xc7220173 = sf_newbuf+0xf3 sf_intr(c722a000,c0947ec0,4,c0882361,c65d4238,...) at 0xc7221c48 = sf_intr+0x248 intr_event_execute_handlers(c658f7f8,c65d4200,c087ef80,533,c65d4270,...) at 0xc05b47b5 = intr_event_execute_handlers+0x125 ithread_loop(c65dd830,daaa2d28,c087ed0e,33b,c658f7f8,...) at 0xc05b55ac = ithread_loop+0xac fork_exit(c05b5500,c65dd830,daaa2d28) at 0xc05b24e8 = fork_exit+0xb8 fork_trampoline() at 0xc080b9e4 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdaaa2d60, ebp = 0 --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x400000c fault code = supervisor read, page not present instruction pointer = 0x20:0xc08077c4 stack pointer = 0x28:0xdaaa2bec frame pointer = 0x28:0xdaaa2c00 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq26: sf0) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c08870ef,d31206e,2c66000a,70797420,78302065,...) at 0xc04ed726 = db_trace_self_wrapper+0x26 kdb_backtrace(c08b0bbd,0,c086c89f,daaa2a88,0,...) at 0xc061152a = kdb_backtrace+0x2a panic(c086c89f,c08b226c,c7041748,1,1,...) at 0xc05de537 = panic+0x117 trap_fatal(5,0,c08b2265,246,c70415a0,...) at 0xc0820ee5 = trap_fatal+0x325 trap(daaa2bac) at 0xc08214ce = trap+0x2be calltrap() at 0xc080b93c = calltrap+0x6 --- trap 0xc, eip = 0xc08077c4, esp = 0xdaaa2bec, ebp = 0xdaaa2c00 --- _bus_dmamap_sync(c6cbac80,c724a000,2,daaa2c28,daaa2c30,...) at 0xc08077c4 = _bus_dmamap_sync+0x54 sf_newbuf(c722b584,4,c7223bbd,603,c06051d5,...) at 0xc7220173 = sf_newbuf+0xf3 sf_intr(c722a000,c0947ec0,4,c0882361,c65d4238,...) at 0xc7221c48 = sf_intr+0x248 intr_event_execute_handlers(c658f7f8,c65d4200,c087ef80,533,c65d4270,...) at 0xc05b47b5 = intr_event_execute_handlers+0x125 ithread_loop(c65dd830,daaa2d28,c087ed0e,33b,c658f7f8,...) at 0xc05b55ac = ithread_loop+0xac fork_exit(c05b5500,c65dd830,daaa2d28) at 0xc05b24e8 = fork_exit+0xb8 fork_trampoline() at 0xc080b9e4 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdaaa2d60, ebp = 0 --- Uptime: 40s Physical memory: 3203 MB Dumping 116 MB: (CTRL-C to abort) panic: Trying sleep, but thread marked as sleeping prohibited cpuid = 0 Uptime: 40s Automatic reboot in 15 seconds - press a key on the console to abort panic: Trying sleep, but thread marked as sleeping prohibited cpuid = 0 Uptime: 40s Automatic reboot in 15 seconds - press a key on the console to abort panic: Trying sleep, but thread marked as sleeping prohibited cpuid = 0 Uptime: 40s [EOT] Script done on Wed Nov 10 15:58:52 2010 thoughts? -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Thu Nov 11 10:29:12 2010 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 06340106564A; Thu, 11 Nov 2010 10:29:12 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 27D458FC08; Thu, 11 Nov 2010 10:29:10 +0000 (UTC) Received: by bwz2 with SMTP id 2so1745219bwz.13 for ; Thu, 11 Nov 2010 02:29:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received: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=IBkmn7OjqaG8WH8tmY8jbDAX2tB+EFBeKS8TkX98YRo=; b=Im8CNONFvQTsxaC/ORkRK9l2KSrirGk9O0x3ONTGEzEL/QHLLUNfB6sC6ykQWW4U5A cwNvB6wnEgz22xVgUABtb41mQFxhj3Vi1OUAGAU2MsGBMf7rfkS43QgZjsr75VLIMeD7 otLa5gKixxFsoncTuRUD+qnbFyw/vDdMwHRbM= 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=puHTSR07x7EZyr2Yer1RraanUVyXIpAjDQ+4c97ebMUP27VTHwyTzNuwCy6te2PyS1 7Bajt99mILHleAdHp8+ip8npwIRgLzTe+ic0PurArYm3rPDOgb13XnM/A8O3bx0t2HHc Kos4RANrezdPhpCV2Y+aKY8SzBFJDEThs7NvY= Received: by 10.204.27.20 with SMTP id g20mr1051611bkc.114.1289471349947; Thu, 11 Nov 2010 02:29:09 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id r21sm845182bkj.22.2010.11.11.02.29.07 (version=SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 02:29:08 -0800 (PST) Sender: Alexander Motin Message-ID: <4CDBC55B.1040307@FreeBSD.org> Date: Thu, 11 Nov 2010 12:28:43 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Joerg Schilling References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> <4CD82E2A.3070407@FreeBSD.org> <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> <4CD83535.1010008@FreeBSD.org> <4cdbbfef.v4cr/k2jZr9gdpyF%Joerg.Schilling@fokus.fraunhofer.de> In-Reply-To: <4cdbbfef.v4cr/k2jZr9gdpyF%Joerg.Schilling@fokus.fraunhofer.de> 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, freebsd-stable@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] 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, 11 Nov 2010 10:29:12 -0000 Joerg Schilling wrote: > Alexander Motin wrote: >>>>> Given the fact that many drives will probably only return 18 bytes of sense >>>>> data, this will happen every time libscg is told to fetch more sense than the >>>>> drive is willing to return. >>>>> >>>>> Is there a way to distinct an old kernel from a new one? >>>> I don't see the problem. Previous kernel in most cases reported >>>> sesnse_resid == 0, lying that there is more sense data then really is. >>>> New one should report real (often positive) value. In both cases >>>> sesnse_resid value measured from the value submitted to the kernel. >>> Did the old kernel return a zero sense_resid for any implemented SCSI >>> transport? Libscg is a generic SCSI transport library and cdrecord is just one >>> user of this lib. >> Not sure I understand your question. Zero sesnse_resid is absolutely >> normal situation if device gave same amount of sense as application >> requested. As I can see, many of SCSI controllers report sesnse_resid >> properly. I may assume that some, like atapicd don't -- in that case >> you'll also see 0 there. > > FreeBSD-CAM did try to fetcth more than 18 bytes of sense data and it may be > that some drives did return only 18 bytes. In this case, I would asume that > there is a resid > 0. As I have said, many drivers return resid properly, but some others - don't. These changes should just improve situation. >>> Do you know the CAM behavior for other SCSI transports? >> I don't have real SCSI CD to test, but a as I can see, most of SCSI >> controllers return sense data automatically. Sense fetching changes >> should not affect/break anything there. > > The question still remains whether the previous implementation did return resid >> 0 in some cases. In this case, I would need to implement both variants in the > libscg adaption layer and I would need to know whether I am running on an old > version or on a new version kernel. Do you know of a simple method to implement > this distinction? Yes, some drivers were permanently reporting zero resid, while others (mostly real SCSI) were reporting proper values. Now it is the same, just more cases should work properly. Why do you want/need to distinguish them? You should already handle non-zero resid properly. Zero resid may be wrong in some cases, but at first I don't see fatal problem from it and at second I don't see what can you do about it. If I am missing something - sorry, explain it to me please. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Nov 11 10:29:51 2010 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 E63741065673 for ; Thu, 11 Nov 2010 10:29:51 +0000 (UTC) (envelope-from eirnym@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7053C8FC22 for ; Thu, 11 Nov 2010 10:29:51 +0000 (UTC) Received: by bwz2 with SMTP id 2so1745910bwz.13 for ; Thu, 11 Nov 2010 02:29:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=/OEP0B5BHjYMNmh1Lw2E1Q8Jh0zzRfTTy97K7nepuk4=; b=NEbQwF4uJFBt3tHIY9IqX+Vq5J4wHJkG4g8r3jYGokYxMk9HXLGzJc8BtB2Ihkp4hr yY5R5u9t79nlocbp0kWz249KWoE9H4aonhf+21RDqM/DOSq/ooHPUsIFM9gz4LdbGaKr cnYSncBS4fjHCw9V462VK6n/AzIamb5Y5kmUg= 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=rIWE1oxJrsydDMkUqXuPS4/4bkVPgUsr11nnTI3gZvcZQtPBArIrvJfoB0CjCEXksu JD7t+wqSXfad2Ez6FofCaMxzecpIzwejbkxD/K55pWc9ng/tx/g5LcBzCOFnTMv05VrQ oz1RN/HQ6sw8rB/6rnin6l/6kITQIVnJBrKbM= Received: by 10.204.62.139 with SMTP id x11mr1088956bkh.28.1289471389423; Thu, 11 Nov 2010 02:29:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.123.131 with HTTP; Thu, 11 Nov 2010 02:29:29 -0800 (PST) In-Reply-To: <20101109174542.GM2054@hoeg.nl> References: <20101109100319.GV2054@hoeg.nl> <20101109174542.GM2054@hoeg.nl> From: Eir Nym Date: Thu, 11 Nov 2010 13:29:29 +0300 Message-ID: To: Ed Schouten Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Renato Botelho , FreeBSD Mail Lists Subject: Re: Syscons and termcap 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, 11 Nov 2010 10:29:52 -0000 On 9 November 2010 20:45, Ed Schouten wrote: > * Renato Botelho , 20101109 17:08: >> Well, few weeks ago I moved from ISO-8859-1 to UTF-8 on my Xorg >> environment, and after reading this I decided to make a test. >> >> I rebuilt my 9.0-current (r215031) with option TEKEN_UTF8 in kernel >> config, and after configure my syscons to use cp850-* fonts i can >> see UTF-8 chars properly \o/ > > Well, the point here is that it just performs some really hackish > translation to CP437, not CP850, on the output path. It is really not > robust. Copy-pasting is also broken because of it, because it pastes > CP437 characters. > >> The only thing i cannot do here is to type chars with accent like =C3=A1= =C3=A9 >> on console, because it seems to don't respect deadkeys, when I >> press ' the char ' is show and never wait the next char to compose >> a new one when necessary. Is it a knwon issue or i'm doing >> something wrong? > > This is a known issue, since there is no translation from Unicode code > points to UTF-8 sequences. In other words, if you press =C3=AB, the keybo= ard > layer will properly send a 235 to Syscons, but instead of encoding it as > 0xC3 0xA9, will just emit a single byte, having value 0xE9. > > Maybe a patch like this could already get that working, but it's just a > quick hack. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0http://80386.nl/pub/syscons-utf8.txt > > Greetings, > -- > =C2=A0Ed Schouten > =C2=A0WWW: http://80386.nl/ > Thanks Ed, I'll move back to CONS25 before I can load codepage into kernel. I don't like to always see question marks instread normal characters in SC_PIXEL_MODE. PS: I prefer kernel console driver for some reasons. From owner-freebsd-current@FreeBSD.ORG Thu Nov 11 11:27:53 2010 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 44DD1106566B; Thu, 11 Nov 2010 11:27:53 +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 47EF08FC25; Thu, 11 Nov 2010 11:27:51 +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 NAA11008; Thu, 11 Nov 2010 13:27:49 +0200 (EET) (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 1PGVJl-000EhC-7i; Thu, 11 Nov 2010 13:27:49 +0200 Message-ID: <4CDBD333.5040007@freebsd.org> Date: Thu, 11 Nov 2010 13:27:47 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Kostik Belousov References: <4CD3B1D2.30003@icyb.net.ua> <4CD7E401.1010206@freebsd.org> <20101108120403.GC2392@deviant.kiev.zoral.com.ua> <4CD9139D.9060302@freebsd.org> <20101109140518.GV2392@deviant.kiev.zoral.com.ua> <4CDA2B3E.9030402@freebsd.org> <20101110083408.GC2392@deviant.kiev.zoral.com.ua> In-Reply-To: <20101110083408.GC2392@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: radeon_cp_texture: page fault with non-sleepable locks held 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, 11 Nov 2010 11:27:53 -0000 on 10/11/2010 10:34 Kostik Belousov said the following: > On Wed, Nov 10, 2010 at 07:18:54AM +0200, Andriy Gapon wrote: >> on 09/11/2010 16:05 Kostik Belousov said the following: >>> Easiest would be for DRM to provide wrappers for copyin/copyout that >>> unlock, do operation and lock. >> >> I am a little bit worried about this approach in general. >> Driver state may be changed by a process running in parallel while the lock is >> dropped. And I don't think that we have any mechanism in DRM to check for that >> and to restart operations or otherwise account for the state change. The code >> seems to be written with an assumption that it runs in exclusive mode from DRM >> ioctl start to its completion. >> >>> Where is the reverse order (user map -> drm) ? >> >> You mean the following or the opposite? >> >> 1st 0xffffff0001b968a0 drmdev (drmdev) @ /usr/src/sys/dev/drm/drm_drv.c:791 >> 2nd 0xffffff000a621510 user map (user map) @ /usr/src/sys/vm/vm_map.c:3548 >> KDB: stack backtrace: >> db_trace_self_wrapper() at 0xffffffff801b8b3a = db_trace_self_wrapper+0x2a >> kdb_backtrace() at 0xffffffff803a7a8a = kdb_backtrace+0x3a >> _witness_debugger() at 0xffffffff803bd42c = _witness_debugger+0x2c >> witness_checkorder() at 0xffffffff803be899 = witness_checkorder+0x959 >> _sx_slock() at 0xffffffff80378af8 = _sx_slock+0x88 >> _vm_map_lock_read() at 0xffffffff80510a06 = _vm_map_lock_read+0x36 >> vm_map_lookup() at 0xffffffff805127d4 = vm_map_lookup+0x54 >> vm_fault() at 0xffffffff80509819 = vm_fault+0xf9 >> trap_pfault() at 0xffffffff80545d6f = trap_pfault+0x11f >> trap() at 0xffffffff805465f7 = trap+0x657 >> calltrap() at 0xffffffff80530628 = calltrap+0x8 >> --- trap 0xc, rip = 0xffffffff805440bd, rsp = 0xffffff8123fe37f0, rbp = >> 0xffffff8123fe3870 --- >> copyin() at 0xffffffff805440bd = copyin+0x3d >> radeon_cp_texture() at 0xffffffff8022fbd7 = radeon_cp_texture+0x167 >> drm_ioctl() at 0xffffffff8020fa38 = drm_ioctl+0x318 >> devfs_ioctl_f() at 0xffffffff802dd649 = devfs_ioctl_f+0x109 >> kern_ioctl() at 0xffffffff803c1127 = kern_ioctl+0x1f7 >> ioctl() at 0xffffffff803c12e8 = ioctl+0x168 >> syscallenter() at 0xffffffff803b57de = syscallenter+0x26e >> syscall() at 0xffffffff80545eb2 = syscall+0x42 >> Xfast_syscall() at 0xffffffff80530902 = Xfast_syscall+0xe2 >> >> If you meant the opposite order, how can I check it? >> I guess that it could be in a mmap() call for drm cdev. > > Explicitely insert the reversed order into the witness array and watch. Here it is: lock order reversal: 1st 0xffffff0001a51b30 user map (user map) @ /usr/src/sys/vm/vm_map.c:1400 2nd 0xffffff0001b968a0 drmdev (drmdev) @ /usr/src/sys/dev/drm/drm_vm.c:84 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff801b8b3a = db_trace_self_wrapper+0x2a kdb_backtrace() at 0xffffffff803a7a8a = kdb_backtrace+0x3a _witness_debugger() at 0xffffffff803bd42c = _witness_debugger+0x2c witness_checkorder() at 0xffffffff803be899 = witness_checkorder+0x959 _sx_xlock() at 0xffffffff803789b8 = _sx_xlock+0x88 drm_mmap() at 0xffffffff8021587a = drm_mmap+0x18a dev_pager_getpages() at 0xffffffff804fdcce = dev_pager_getpages+0xce vm_object_populate() at 0xffffffff80515c2f = vm_object_populate+0x9f pmap_object_init_pt() at 0xffffffff8053d600 = pmap_object_init_pt+0xa0 vm_map_pmap_enter() at 0xffffffff8050f1b7 = vm_map_pmap_enter+0x97 vm_map_insert() at 0xffffffff8050fa5d = vm_map_insert+0x45d vm_map_find() at 0xffffffff8051097d = vm_map_find+0xdd vm_mmap() at 0xffffffff80514158 = vm_mmap+0x578 mmap() at 0xffffffff80514903 = mmap+0x383 syscallenter() at 0xffffffff803b57de = syscallenter+0x26e syscall() at 0xffffffff80545f92 = syscall+0x42 Xfast_syscall() at 0xffffffff805309e2 = Xfast_syscall+0xe2 -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Nov 11 10:05:40 2010 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 72C521065672 for ; Thu, 11 Nov 2010 10:05:40 +0000 (UTC) (envelope-from joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com) Received: from relay03-haj2.antispameurope.com (relay03-haj2.antispameurope.com [83.246.65.53]) by mx1.freebsd.org (Postfix) with ESMTP id 016438FC0A for ; Thu, 11 Nov 2010 10:05:39 +0000 (UTC) Received: by relay03-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id E3E247D4013; Thu, 11 Nov 2010 11:05:37 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay03-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 34ED063C239; Thu, 11 Nov 2010 11:05:36 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id oABA5ZAW000889; Thu, 11 Nov 2010 11:05:35 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Nov 2010 11:05:36 +0100 Date: Thu, 11 Nov 2010 11:05:35 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: mav@FreeBSD.org Message-ID: <4cdbbfef.v4cr/k2jZr9gdpyF%Joerg.Schilling@fokus.fraunhofer.de> References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> <4CD82E2A.3070407@FreeBSD.org> <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> <4CD83535.1010008@FreeBSD.org> In-Reply-To: <4CD83535.1010008@FreeBSD.org> User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 11 Nov 2010 10:05:36.0084 (UTC) FILETIME=[FC21E940:01CB8187] X-Mailman-Approved-At: Thu, 11 Nov 2010 11:58:48 +0000 Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] 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, 11 Nov 2010 10:05:40 -0000 Alexander Motin wrote: > >>> Given the fact that many drives will probably only return 18 bytes of sense > >>> data, this will happen every time libscg is told to fetch more sense than the > >>> drive is willing to return. > >>> > >>> Is there a way to distinct an old kernel from a new one? > >> I don't see the problem. Previous kernel in most cases reported > >> sesnse_resid == 0, lying that there is more sense data then really is. > >> New one should report real (often positive) value. In both cases > >> sesnse_resid value measured from the value submitted to the kernel. > > > > Did the old kernel return a zero sense_resid for any implemented SCSI > > transport? Libscg is a generic SCSI transport library and cdrecord is just one > > user of this lib. > > Not sure I understand your question. Zero sesnse_resid is absolutely > normal situation if device gave same amount of sense as application > requested. As I can see, many of SCSI controllers report sesnse_resid > properly. I may assume that some, like atapicd don't -- in that case > you'll also see 0 there. FreeBSD-CAM did try to fetcth more than 18 bytes of sense data and it may be that some drives did return only 18 bytes. In this case, I would asume that there is a resid > 0. > > Do you know the CAM behavior for other SCSI transports? > > I don't have real SCSI CD to test, but a as I can see, most of SCSI > controllers return sense data automatically. Sense fetching changes > should not affect/break anything there. The question still remains whether the previous implementation did return resid > 0 in some cases. In this case, I would need to implement both variants in the libscg adaption layer and I would need to know whether I am running on an old version or on a new version kernel. Do you know of a simple method to implement this distinction? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From owner-freebsd-current@FreeBSD.ORG Thu Nov 11 10:33:07 2010 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 8A99E10656A8 for ; Thu, 11 Nov 2010 10:33:07 +0000 (UTC) (envelope-from joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com) Received: from relay01-haj2.antispameurope.com (relay01-haj2.antispameurope.com [83.246.65.51]) by mx1.freebsd.org (Postfix) with ESMTP id 16CF58FC1F for ; Thu, 11 Nov 2010 10:33:06 +0000 (UTC) Received: by relay01-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id B40C01600D4; Thu, 11 Nov 2010 11:33:04 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 31E5B1600B1; Thu, 11 Nov 2010 11:33:03 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id oABAX3S6001742; Thu, 11 Nov 2010 11:33:03 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Nov 2010 11:33:04 +0100 Date: Thu, 11 Nov 2010 11:33:03 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: mav@FreeBSD.org Message-ID: <4cdbc65f.bo+mYNFB2GPwXmq7%Joerg.Schilling@fokus.fraunhofer.de> References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> <4CD82E2A.3070407@FreeBSD.org> <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> <4CD83535.1010008@FreeBSD.org> <4cdbbfef.v4cr/k2jZr9gdpyF%Joerg.Schilling@fokus.fraunhofer.de> <4CDBC55B.1040307@FreeBSD.org> In-Reply-To: <4CDBC55B.1040307@FreeBSD.org> User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 11 Nov 2010 10:33:04.0173 (UTC) FILETIME=[D27855D0:01CB818B] X-Mailman-Approved-At: Thu, 11 Nov 2010 12:00:33 +0000 Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] 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, 11 Nov 2010 10:33:07 -0000 Alexander Motin wrote: > > The question still remains whether the previous implementation did return resid > >> 0 in some cases. In this case, I would need to implement both variants in the > > libscg adaption layer and I would need to know whether I am running on an old > > version or on a new version kernel. Do you know of a simple method to implement > > this distinction? > > Yes, some drivers were permanently reporting zero resid, while others > (mostly real SCSI) were reporting proper values. Now it is the same, > just more cases should work properly. > > Why do you want/need to distinguish them? You should already handle > non-zero resid properly. Zero resid may be wrong in some cases, but at > first I don't see fatal problem from it and at second I don't see what > can you do about it. > > If I am missing something - sorry, explain it to me please. Compare the number of sense bytes I like to request (18) with the number previous FreeBSD versions did actually request. It is obvious that in case there is a resid reported onm an old kernel, libscg (with your chanhge) would believe that probably less that the absolute minumum of sense data is available. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From owner-freebsd-current@FreeBSD.ORG Thu Nov 11 13:07:10 2010 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 4EFF5106566B; Thu, 11 Nov 2010 13:07: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 1214A8FC0A; Thu, 11 Nov 2010 13:07:09 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oABD7998052295; Thu, 11 Nov 2010 08:07:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oABD79og052286; Thu, 11 Nov 2010 13:07:09 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 11 Nov 2010 13:07:09 GMT Message-Id: <201011111307.oABD79og052286@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: Thu, 11 Nov 2010 13:07:10 -0000 TB --- 2010-11-11 13:06:50 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-11 13:06:50 - starting HEAD tinderbox run for mips/mips TB --- 2010-11-11 13:06:50 - cleaning the object tree TB --- 2010-11-11 13:06:50 - cvsupping the source tree TB --- 2010-11-11 13:06:50 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2010-11-11 13:07:08 - building world TB --- 2010-11-11 13:07:08 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-11 13:07:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-11 13:07:08 - TARGET=mips TB --- 2010-11-11 13:07:08 - TARGET_ARCH=mips TB --- 2010-11-11 13:07:08 - TZ=UTC TB --- 2010-11-11 13:07:08 - __MAKE_CONF=/dev/null TB --- 2010-11-11 13:07:08 - cd /src TB --- 2010-11-11 13:07:08 - /usr/bin/make -B buildworld "/src/Makefile.inc1", line 138: Unknown target mips:mips. *** Error code 1 Stop in /src. TB --- 2010-11-11 13:07:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-11 13:07:09 - ERROR: failed to build world TB --- 2010-11-11 13:07:09 - 2.20 user 7.94 system 18.30 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 11 13:07:31 2010 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 6A96E1065694; Thu, 11 Nov 2010 13:07:31 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 884CB8FC08; Thu, 11 Nov 2010 13:07:30 +0000 (UTC) Received: by bwz2 with SMTP id 2so1889170bwz.13 for ; Thu, 11 Nov 2010 05:07:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received: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=a+pDfTT/zJsOxqc61Ol7WgkltbK1q8HNA3j1kujoJrQ=; b=rb+dMtjoYOvHnUg+J03C+pDstOgGpdMNfsp4e8BRN+8ZWj0DCHCdTW/iB+twBRdpjF l0HcEfypqvdpt48s/LyToeZgC0C1/pubTl2s31KS4n62INEt0/ftwos2wokLnM996k5B ytZaY5hX3KdxvtArO2IIgGiZ482aSV0ZXmTxM= 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=FxafP9goUSkzLj23mec3y3Ogy48FcQJlI+3u0WibEwH4nALNl/xwC7zgVa0gl2NDBK u5rJr8at9SlxI+0n4lHyB8hfCCsTA3Nr+KxdHfnrX0GAGTPjQGU14Bus/ijw5KdDbk20 m9X4vP3sZzj0SdFbV3zYUNFqaYvtzlurVS4E4= Received: by 10.204.76.67 with SMTP id b3mr1332240bkk.62.1289480848796; Thu, 11 Nov 2010 05:07:28 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 4sm919804bki.1.2010.11.11.05.07.26 (version=SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 05:07:27 -0800 (PST) Sender: Alexander Motin Message-ID: <4CDBEA8B.1020306@FreeBSD.org> Date: Thu, 11 Nov 2010 15:07:23 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Joerg Schilling References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> <4CD82E2A.3070407@FreeBSD.org> <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> <4CD83535.1010008@FreeBSD.org> <4cdbbfef.v4cr/k2jZr9gdpyF%Joerg.Schilling@fokus.fraunhofer.de> <4CDBC55B.1040307@FreeBSD.org> <4cdbc65f.bo+mYNFB2GPwXmq7%Joerg.Schilling@fokus.fraunhofer.de> In-Reply-To: <4cdbc65f.bo+mYNFB2GPwXmq7%Joerg.Schilling@fokus.fraunhofer.de> 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, freebsd-stable@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] 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, 11 Nov 2010 13:07:31 -0000 Joerg Schilling wrote: > Alexander Motin wrote: > >>> The question still remains whether the previous implementation did return resid >>>> 0 in some cases. In this case, I would need to implement both variants in the >>> libscg adaption layer and I would need to know whether I am running on an old >>> version or on a new version kernel. Do you know of a simple method to implement >>> this distinction? >> Yes, some drivers were permanently reporting zero resid, while others >> (mostly real SCSI) were reporting proper values. Now it is the same, >> just more cases should work properly. >> >> Why do you want/need to distinguish them? You should already handle >> non-zero resid properly. Zero resid may be wrong in some cases, but at >> first I don't see fatal problem from it and at second I don't see what >> can you do about it. >> >> If I am missing something - sorry, explain it to me please. > > Compare the number of sense bytes I like to request (18) with the number > previous FreeBSD versions did actually request. It is obvious that in case > there is a resid reported onm an old kernel, libscg (with your chanhge) would > believe that probably less that the absolute minumum of sense data is available. Kernel code I have changed affects only controllers without automatic sense fetching. For such controllers CAM previously always reported zero sense_resid, independently of requested size (which actually was also ignored in this case). So previously whatever you asked for 18 or 32 bytes - sense_resid was always zero, like if you got full 18 or 32 bytes. That was wrong. Now, in the same situation, if device wants to return let's say 20 bytes -- you will get 0 and 12 bytes of sense_resid respectively, meaning 18 and 20 bytes of received sense. AFAIK sense_resid always measured from the requested sense_len. In my patch for libscg you may see that I have changed both request and response paths. Resulted sense_count should be absolutely the same. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Nov 11 13:28:52 2010 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 90E44106566B; Thu, 11 Nov 2010 13:28:52 +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 B53498FC08; Thu, 11 Nov 2010 13:28:51 +0000 (UTC) Received: by fxm19 with SMTP id 19so1277894fxm.13 for ; Thu, 11 Nov 2010 05:28:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received: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=yZyM3gleemwPTCnpdko7NZf+EbCOFHP1Uk2zwbC8N44=; b=DR91x+fwCrStGLnv6wxRB3RVyU8cP216qRnN1R0Az5UqXQLRqdaHFTFgrKySZ70RdY B9v9PG0rLOHLoA2H6tCl7t3HbN+SpJqusw7zBVyU4o3OmmJRZuv691253J53HqsDe4V6 xda6Pi6StgjmZ3PXxZlpm45cdl2noV0drsK+k= 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=OBeNX+ckUDfEF0K2C+NI2OQPDCu89qKyy2WFojEswsJexiR+4dr9xI0fkPv+GeotBR BOEJxdYKYeBOai/BD1wZCUUgqdKbXvFkrKfnl0nXIAIkUAFzq0PUe0Rwq5INcKCdfG+T QzyrCPTgyS7I8neqtrRGx8tgyz8obpbCS1gt0= Received: by 10.204.54.82 with SMTP id p18mr1306551bkg.205.1289482130301; Thu, 11 Nov 2010 05:28:50 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id p22sm926623bkp.21.2010.11.11.05.28.48 (version=SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 05:28:49 -0800 (PST) Sender: Alexander Motin Message-ID: <4CDBEF8D.5080001@FreeBSD.org> Date: Thu, 11 Nov 2010 15:28:45 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Joerg Schilling References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> <4CD82E2A.3070407@FreeBSD.org> <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> <4CD83535.1010008@FreeBSD.org> <4cdbbfef.v4cr/k2jZr9gdpyF%Joerg.Schilling@fokus.fraunhofer.de> <4CDBC55B.1040307@FreeBSD.org> <4cdbc65f.bo+mYNFB2GPwXmq7%Joerg.Schilling@fokus.fraunhofer.de> <4CDBEA8B.1020306@FreeBSD.org> <4cdbece1.EWYSqdvnx6XWF8EF%Joerg.Schilling@fokus.fraunhofer.de> In-Reply-To: <4cdbece1.EWYSqdvnx6XWF8EF%Joerg.Schilling@fokus.fraunhofer.de> 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, freebsd-stable@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] 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, 11 Nov 2010 13:28:52 -0000 Joerg Schilling wrote: > Alexander Motin wrote: > >>> Compare the number of sense bytes I like to request (18) with the number >>> previous FreeBSD versions did actually request. It is obvious that in case >>> there is a resid reported onm an old kernel, libscg (with your chanhge) would >>> believe that probably less that the absolute minumum of sense data is available. >> Kernel code I have changed affects only controllers without automatic >> sense fetching. For such controllers CAM previously always reported zero >> sense_resid, independently of requested size (which actually was also >> ignored in this case). So previously whatever you asked for 18 or 32 >> bytes - sense_resid was always zero, like if you got full 18 or 32 >> bytes. That was wrong. Now, in the same situation, if device wants to >> return let's say 20 bytes -- you will get 0 and 12 bytes of sense_resid >> respectively, meaning 18 and 20 bytes of received sense. >> >> AFAIK sense_resid always measured from the requested sense_len. In my >> patch for libscg you may see that I have changed both request and >> response paths. Resulted sense_count should be absolutely the same. > > What is the requested size with the various HBAs in earlier kernels? For HBAs with automatic sense fetching -- as passed in sence_len request field. In case of libscg it was SSD_FULL_SIZE before and I've set it to be real value now. Returned sense_resid should be real in both cases, respecting submitted sense_len. For HBAs without sense fetching, CAM was always requesting SSD_FULL_SIZE and returned fake zero sense_resid, like if it just completely fulfilled sense_len from request. Now it should start honor sense_len on request and return real sense_resid on reply, relative to sense_len. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Nov 11 13:17:28 2010 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 874111065679 for ; Thu, 11 Nov 2010 13:17:28 +0000 (UTC) (envelope-from joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com) Received: from relay01-haj2.antispameurope.com (relay01-haj2.antispameurope.com [83.246.65.51]) by mx1.freebsd.org (Postfix) with ESMTP id 11D138FC1F for ; Thu, 11 Nov 2010 13:17:27 +0000 (UTC) Received: by relay01-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 1D9EF16008C; Thu, 11 Nov 2010 14:17:26 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 622DE160049; Thu, 11 Nov 2010 14:17:25 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id oABDHOf3007031; Thu, 11 Nov 2010 14:17:24 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Nov 2010 14:17:24 +0100 Date: Thu, 11 Nov 2010 14:17:21 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: mav@FreeBSD.org Message-ID: <4cdbece1.EWYSqdvnx6XWF8EF%Joerg.Schilling@fokus.fraunhofer.de> References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> <4CD82E2A.3070407@FreeBSD.org> <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> <4CD83535.1010008@FreeBSD.org> <4cdbbfef.v4cr/k2jZr9gdpyF%Joerg.Schilling@fokus.fraunhofer.de> <4CDBC55B.1040307@FreeBSD.org> <4cdbc65f.bo+mYNFB2GPwXmq7%Joerg.Schilling@fokus.fraunhofer.de> <4CDBEA8B.1020306@FreeBSD.org> In-Reply-To: <4CDBEA8B.1020306@FreeBSD.org> User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 11 Nov 2010 13:17:24.0928 (UTC) FILETIME=[C7F02400:01CB81A2] X-Mailman-Approved-At: Thu, 11 Nov 2010 13:29:40 +0000 Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] 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, 11 Nov 2010 13:17:28 -0000 Alexander Motin wrote: > > Compare the number of sense bytes I like to request (18) with the number > > previous FreeBSD versions did actually request. It is obvious that in case > > there is a resid reported onm an old kernel, libscg (with your chanhge) would > > believe that probably less that the absolute minumum of sense data is available. > > Kernel code I have changed affects only controllers without automatic > sense fetching. For such controllers CAM previously always reported zero > sense_resid, independently of requested size (which actually was also > ignored in this case). So previously whatever you asked for 18 or 32 > bytes - sense_resid was always zero, like if you got full 18 or 32 > bytes. That was wrong. Now, in the same situation, if device wants to > return let's say 20 bytes -- you will get 0 and 12 bytes of sense_resid > respectively, meaning 18 and 20 bytes of received sense. > > AFAIK sense_resid always measured from the requested sense_len. In my > patch for libscg you may see that I have changed both request and > response paths. Resulted sense_count should be absolutely the same. What is the requested size with the various HBAs in earlier kernels? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From owner-freebsd-current@FreeBSD.ORG Thu Nov 11 13:32:08 2010 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 F1B651065698; Thu, 11 Nov 2010 13:32:08 +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 90D518FC18; Thu, 11 Nov 2010 13:32:08 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oABDW7XR027458; Thu, 11 Nov 2010 08:32:07 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oABDW7sx027457; Thu, 11 Nov 2010 13:32:07 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 11 Nov 2010 13:32:07 GMT Message-Id: <201011111332.oABDW7sx027457@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: Thu, 11 Nov 2010 13:32:09 -0000 TB --- 2010-11-11 13:27:04 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-11 13:27:04 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-11-11 13:27:04 - cleaning the object tree TB --- 2010-11-11 13:27:06 - cvsupping the source tree TB --- 2010-11-11 13:27:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-11-11 13:27:23 - building world TB --- 2010-11-11 13:27:23 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-11 13:27:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-11 13:27:23 - TARGET=powerpc TB --- 2010-11-11 13:27:23 - TARGET_ARCH=powerpc64 TB --- 2010-11-11 13:27:23 - TZ=UTC TB --- 2010-11-11 13:27:23 - __MAKE_CONF=/dev/null TB --- 2010-11-11 13:27:23 - cd /src TB --- 2010-11-11 13:27:23 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 11 13:27:23 UTC 2010 >>> 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 [...] cc -o rtermcap /src/usr.sbin/sysinstall/rtermcap.c -ltermcap ===> gnu/usr.bin/cc/cc_tools (obj,depend,all) LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-gather.awk /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/c.opt /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/common.opt /src/gnu/usr.bin/cc/cc_tools/freebsd.opt > optionlist LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-functions.awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opth-gen.awk < optionlist > options.h LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-functions.awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/optc-gen.awk -v header_name="config.h system.h coretypes.h tm.h" < optionlist > options.c TARGET_CPU_DEFAULT="\"powerpc64\"" HEADERS="auto-host.h ansidecl.h" DEFINES="" /bin/sh /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/mkconfig.sh bconfig.h TARGET_CPU_DEFAULT="\"powerpc64\"" HEADERS="options.h rs600064/rs600064.h dbxelf.h elfos-undef.h elfos.h freebsd-native.h freebsd-spec.h freebsd.h rs600064/biarch64.h rs600064/default64.h rs600064/freebsd.h defaults.h" DEFINES="" /bin/sh /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/mkconfig.sh tm.h make: don't know how to make /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config/rs600064/rs600064.c. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-11 13:32:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-11 13:32:07 - ERROR: failed to build world TB --- 2010-11-11 13:32:07 - 205.97 user 54.25 system 303.04 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 11 13:45:49 2010 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 429BE106566B for ; Thu, 11 Nov 2010 13:45:49 +0000 (UTC) (envelope-from joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com) Received: from relay03-haj2.antispameurope.com (relay03-haj2.antispameurope.com [83.246.65.53]) by mx1.freebsd.org (Postfix) with ESMTP id C04388FC1B for ; Thu, 11 Nov 2010 13:45:48 +0000 (UTC) Received: by relay03-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 75F4463C214; Thu, 11 Nov 2010 14:45:45 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay03-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id B195C63C24E; Thu, 11 Nov 2010 14:45:42 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id oABDjg5P007828; Thu, 11 Nov 2010 14:45:42 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Nov 2010 14:45:42 +0100 Date: Thu, 11 Nov 2010 14:45:42 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: mav@FreeBSD.org Message-ID: <4cdbf386.cAc+PtgM+41jseN5%Joerg.Schilling@fokus.fraunhofer.de> References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> <4CD82E2A.3070407@FreeBSD.org> <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> <4CD83535.1010008@FreeBSD.org> <4cdbbfef.v4cr/k2jZr9gdpyF%Joerg.Schilling@fokus.fraunhofer.de> <4CDBC55B.1040307@FreeBSD.org> <4cdbc65f.bo+mYNFB2GPwXmq7%Joerg.Schilling@fokus.fraunhofer.de> <4CDBEA8B.1020306@FreeBSD.org> <4cdbece1.EWYSqdvnx6XWF8EF%Joerg.Schilling@fokus.fraunhofer.de> <4CDBEF8D.5080001@FreeBSD.org> In-Reply-To: <4CDBEF8D.5080001@FreeBSD.org> User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 11 Nov 2010 13:45:42.0628 (UTC) FILETIME=[BBD89A40:01CB81A6] X-Mailman-Approved-At: Thu, 11 Nov 2010 14:47:33 +0000 Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] 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, 11 Nov 2010 13:45:49 -0000 Alexander Motin wrote: > > What is the requested size with the various HBAs in earlier kernels? > > For HBAs with automatic sense fetching -- as passed in sence_len request > field. In case of libscg it was SSD_FULL_SIZE before and I've set it to > be real value now. Returned sense_resid should be real in both cases, > respecting submitted sense_len. > > For HBAs without sense fetching, CAM was always requesting SSD_FULL_SIZE > and returned fake zero sense_resid, like if it just completely fulfilled > sense_len from request. Now it should start honor sense_len on request > and return real sense_resid on reply, relative to sense_len. Then your patch to libscg seems to be OK and without risk. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From owner-freebsd-current@FreeBSD.ORG Thu Nov 11 15:52:45 2010 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 3148D10656A6; Thu, 11 Nov 2010 15:52:45 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (unknown [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id C27CD8FC1C; Thu, 11 Nov 2010 15:52:44 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 00AD02A28D04; Thu, 11 Nov 2010 16:52:43 +0100 (CET) Date: Thu, 11 Nov 2010 16:52:43 +0100 From: Ed Schouten To: current@FreeBSD.org, toolchain@FreeBSD.org Message-ID: <20101111155243.GL2054@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CdchzlyJM2/27Jxw" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: libcompiler_rt now part of FreeBSD's base system 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, 11 Nov 2010 15:52:45 -0000 --CdchzlyJM2/27Jxw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello all, I just committed libcompiler_rt.a to HEAD. Even though I don't expect serious issues -- especially not on the tier 1 architectures -- be sure to contact me in case something goes wrong. I hooked it up to the build in a separate commit, so if your system starts to act weird, just revert r215127. Thanks to everyone who helped testing this! --=20 Ed Schouten WWW: http://80386.nl/ ----- Forwarded message from Ed Schouten ----- > Date: Thu, 11 Nov 2010 15:48:27 +0000 (UTC) > From: Ed Schouten > To: src-committers@freebsd.org, svn-src-all@freebsd.org, > svn-src-head@freebsd.org > Subject: svn commit: r215127 - in head: . gnu/lib/libgcc lib sys/sys >=20 > Author: ed > Date: Thu Nov 11 15:48:27 2010 > New Revision: 215127 > URL: http://svn.freebsd.org/changeset/base/215127 >=20 > Log: > Replace libgcc.a by libcompiler_rt.a. > =20 > libcompiler_rt.a is a BSD licensed C language runtime, which implements > many routines which are linked into binaries on architectures where > certain functionality is missing (e.g. 64 bits mul/div on i386). > =20 > Unfortunately, libcompiler_rt cannot replace libgcc entirely. Certain > features, such as an unwinder for exception handling, are missing. > That's why only libgcc.a is replaced for now, because this one does seem > to be complete. > =20 > Tested by: rene (amd64), nwhitehorn (powerpc), droso (i386 exprun) > and many others. Thanks! > Obtained from: user/ed/compiler-rt >=20 > ----- End forwarded message ----- --CdchzlyJM2/27Jxw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkzcEUsACgkQ52SDGA2eCwVMlQCeM9WWGe1pNaoOXeRefQgyQsv2 njsAn059E1CFRm5ojJjMF67ReBO7BJCv =k5rL -----END PGP SIGNATURE----- --CdchzlyJM2/27Jxw-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 11 16:18:30 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 20CD8106566C; Thu, 11 Nov 2010 16:18:30 +0000 (UTC) Date: Thu, 11 Nov 2010 16:18:30 +0000 From: Alexander Best To: Alexey Shuvaev Message-ID: <20101111161830.GA15345@freebsd.org> References: <20101030232244.GA35209@freebsd.org> <20101105214700.GT85693@acme.spoerlein.net> <20101109182512.GA16204@freebsd.org> <20101109194605.GB45046@wep4035.physik.uni-wuerzburg.de> <20101110202621.GA53505@freebsd.org> <20101110213215.GA68484@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20101110213215.GA68484@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: issue with "options DDB" 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, 11 Nov 2010 16:18:30 -0000 On Wed Nov 10 10, Alexander Best wrote: > On Wed Nov 10 10, Alexander Best wrote: > > On Tue Nov 9 10, Alexey Shuvaev wrote: > > > On Tue, Nov 09, 2010 at 06:25:12PM +0000, Alexander Best wrote: > > > > On Fri Nov 5 10, Ulrich Spörlein wrote: > > > > > On Sat, 30.10.2010 at 23:22:44 +0000, Alexander Best wrote: > > > > > > hi there, > > > > > > > > > > > > with "options DDB" in my kernel conf i run into the following issue with my > > > > > > kernel modules: > > > > > > > > > > > > link_elf_lookup_symbol: missing symbol hash table > > > > > > KLD file snd_hda.ko is missing dependencies > > > > > > KLD file sound.ko is missing dependencies > > > > > > KLD file nvidia.ko is missing dependencies > > > > > > KLD file linux.ko is missing dependencies > > > > > > KLD file ng_ubt.ko is missing dependencies > > > > > > KLD file ng_hci.ko is missing dependencies > > > > > > KLD file ng_bluetooth.ko is missing dependencies > > > > > > KLD file netgraph.ko is missing dependencies > > > > > > link_elf_lookup_symbol: missing symbol hash table > > > > > > > > > > > > removing the option solves the issue. any advice? > > > > > > > > > > > > cheers. > > > > > > alex > > > > > > > > > > > > ps: i'm running HEAD (r214542; amd64). > > > > > > > > > > You failed to mention the command that you run. I assume 'buildkernel'? > > > > > Please note that you need and update-to-date "buildworld" for the kernel > > > > > tools to be there, so please try the following (with options DDB): > > > > > > > > > > cd /usr/src > > > > > make clean; make cleandir; make clean > > > > > make buildworld > > > > > make buildkernel KERNCONF=YOURKERNEL > > > > > > > > hmmm....seems there is a problem with gcc. this is what i get during > > > > buildworld: > > > > > > > > > > > > clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector -fconserve-space -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/tinfo2.cc > > > > clang++: warning: argument unused during compilation: '-fconserve-space' > > > ^^^^^^^^^^^ > > > > > > > clang++: warning: argument unused during compilation: '-fno-implicit-templates' > > > > clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector -fconserve-space -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vec.cc > > > > clang++: warning: argument unused during compilation: '-fconserve-space' > > > > clang++: warning: argument unused during compilation: '-fno-implicit-templates' > > > > clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector -fconserve-space -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vterminate.cc > > > > clang++: warning: argument unused during compilation: '-fconserve-space' > > > > clang++: warning: argument unused during compilation: '-fno-implicit-templates' > > > > clang -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -std=gnu99 -fstack-protector -c /usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/libiberty/cp-demangle.c > > > > building static supc++ library > > > > ranlib libsupc++.a > > > > ===> gnu/lib/libobjc (all) > > > > gcc -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DHAVE_GTHR_DEFAULT -DIN_GCC -DIN_TARGET_LIBS -I. -I/usr/src/gnu/lib/libobjc/../../usr.bin/cc/cc_tools -I/usr/src/gnu/lib/libobjc/../../../contrib/libobjc/objc -I/usr/src/gnu/lib/libobjc/../../../contrib/libobjc -I/usr/src/gnu/lib/libobjc/../../../contrib/gcc/config -I/usr/src/gnu/lib/libobjc/../../../contrib/gcc -I/usr/src/gnu/lib/libobjc/../../../contrib/gcclibs/include -fexceptions -frandom-seed=RepeatabilityConsideredGood -g -std=gnu99 -fstack-protector -c /usr/src/gnu/lib/libobjc/../../../contrib/libobjc/archive.c > > > > *** Signal 11 > > > > > > > > Stop in /usr/src/gnu/lib/libobjc. > > > > *** Error code 1 > > > > > > > > Stop in /usr/src/gnu/lib. > > > > *** Error code 1 > > > > > > > > Stop in /usr/src. > > > > *** Error code 1 > > > > > > > > Stop in /usr/src. > > > > *** Error code 1 > > > > > > > > Stop in /usr/src. > > > > *** Error code 1 > > > > > > > > Stop in /usr/src. > > > > > > > > > > > > i've ran buildworld twice (with a clean /usr/src and non-existing /usr/obj/*) > > > > and got the error twice, so it's not a hardware problem it seems. > > > > > > > > if i'm not mistaken the gcc that is being used for buildworld is not the one in > > > > /usr/bin, but a fresh build in /usr/obj, right? > > > > > > > > this is the bt from "gdb /usr/obj/usr/src/tmp/usr/bin/gcc gcc.core". i hope i > > > > picked the correct gcc executable: > > > > > > > > > > > > Core was generated by `gcc'. > > > > Program terminated with signal 11, Segmentation fault. > > > > #0 host_detect_local_cpu (argc=Variable "argc" is not available. > > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/config/i386/driver-i386.c:272 > > > > 272 return concat ("-m", argv[0], "=", cpu, NULL); > > > > (gdb) bt > > > > #0 host_detect_local_cpu (argc=Variable "argc" is not available. > > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/config/i386/driver-i386.c:272 > > > > #1 0x000000000040c754 in eval_spec_function (func=Cannot access memory at address 0x0 > > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5520 > > > > #2 0x00000000004093f2 in do_spec_1 (spec=Variable "spec" is not available. > > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5591 > > > > #3 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 > > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > > > > #4 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. > > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > > > > #5 0x0000000000409398 in do_spec_1 (spec=Variable "spec" is not available. > > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5413 > > > > #6 0x0000000000409545 in do_spec_1 (spec=Variable "spec" is not available. > > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5193 > > > > #7 0x0000000000409398 in do_spec_1 (spec=Variable "spec" is not available. > > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5413 > > > > #8 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 > > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > > > > #9 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. > > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > > > > #10 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 > > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > > > > #11 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. > > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > > > > #12 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 > > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > > > > #13 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. > > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > > > > #14 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 > > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > > > > #15 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. > > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > > > > #16 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 > > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > > > > #17 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. > > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > > > > #18 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 > > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > > > > #19 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. > > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > > > > #20 0x000000000040c4d2 in handle_braces (p=Cannot access memory at address 0x0 > > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884 > > > > #21 0x0000000000408d99 in do_spec_1 (spec=Variable "spec" is not available. > > > > ) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274 > > > > #22 0x00000000004003ec in do_spec_2 (spec=0x1
) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:4490 > > > > #23 0x000000000040033d in do_spec (spec=0x1
) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:4458 > > > > #24 0x00000000004036d1 in main (argc=23, argv=0x7fffffffe240) at /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:6712 > > > > > > > So, you are trying to do a mixed clang+gcc build. Which architecture is this? > > > Does the problem occur in the case of a pure gcc build? > > > > i just tried and with gcc buildworld succeeds. > > maybe i should cd to /usr/sr/usr.bin/clang and install it before doing > builworld. maybe my clang version contains an already fixed bug? ok i did a complete buildworld/installworld with gcc as compiler. then i switched back to clang, but the problem still occurs. :( > > 'clang -v' reports: > > FreeBSD clang version 2.8 (branches/release_28 114020) 20100917 > Target: x86_64-undermydesk-freebsd9.0 > Thread model: posix > > cheers. > alex > > > > > cheers. > > alex > > > > > > > > HTH, > > > Alexey. > > > > -- > > a13x > > -- > a13x -- a13x From owner-freebsd-current@FreeBSD.ORG Thu Nov 11 17:47:44 2010 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 28F4B1065673; Thu, 11 Nov 2010 17:47: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 19F608FC17; Thu, 11 Nov 2010 17:47: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 TAA16320; Thu, 11 Nov 2010 19:47:31 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CDC2C33.1020803@freebsd.org> Date: Thu, 11 Nov 2010 19:47:31 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Alan Cox References: <4CA0DA49.2090006@freebsd.org> <4CA3A48A.5070300@freebsd.org> <4CA3BD1E.5070807@rice.edu> <4CA5911E.3000101@freebsd.org> <4CAE0060.7050607@freebsd.org> <4CAECC4D.90707@rice.edu> <4CD1AA45.7000504@freebsd.org> <4CD1AD80.2090903@rice.edu> <4CD1D4AA.3060309@freebsd.org> <4CD8FFFF.3070106@rice.edu> <4CD996AF.2070300@freebsd.org> <4CDAE82C.2040708@rice.edu> In-Reply-To: <4CDAE82C.2040708@rice.edu> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Alan Cox , freebsd-current@freebsd.org Subject: Re: minidump size on 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: Thu, 11 Nov 2010 17:47:44 -0000 on 10/11/2010 20:45 Alan Cox said the following: > Andriy Gapon wrote: >> on 09/11/2010 10:02 Alan Cox said the following: >> >>> The kernel portion of the patch looks correct. If I were to make one stylistic >>> suggestion, it would be to make the control flow of the outer and inner loops as >>> similar as possible, that is, >>> >>> for (... >>> if ((pdp[i] & PG_V) == 0) { >>> ... >>> continue; >>> } >>> if ((pdp[i] & PG_PS) != 0) { >>> ... >>> continue; >>> } >>> for (... >>> if ((pd[j] & PG_V) == 0) >>> continue; >>> if ((pd[j] & PG_PS) != 0) { >>> ... >>> continue; >>> } >>> for (... >>> if ((pt[x] & PG_V) == 0) >>> continue; >>> ... >>> >>> I think this would make the code a little easier to follow. >>> >> >> This is a very nice suggestion, thank you. >> Besides the uniformity some horizontal space is saved too :-) >> Updated patch (only kernel part) is here: >> http://people.freebsd.org/~avg/amd64-minidump.5.diff >> >> > > In the later loop, where you actually write the page directory pages, the "va += > ..." in the following looks like a bug because you also update "va" in for (...): > > + > + /* 1GB page is represented as 512 2MB pages in a dump */ > + if ((pdp[i] & PG_PS) != 0) { > + va += NBPDP; Yes, thank you - a copy/paste bug. > My last three comments are: > > 1. I would move the assignment > > i = (va >> PDPSHIFT) & ((1ul << NPDPEPGSHIFT) - 1); > > > so that it comes after > > pmapsize += PAGE_SIZE; OK. > 2. The outermost ()'s aren't needed in the following statement: > > j = ((va >> PDRSHIFT) & ((1ul << NPDEPGSHIFT) - 1)); > Yes. > 3. I would suggest rewriting the following: > > + pa = pdp[i] & PG_PS_FRAME; > + for (j = 0; j < NPDEPG; j++) > + fakepd[j] = (pa + (j << PDRSHIFT)) | > + PG_V | PG_PS | PG_RW | PG_A | PG_M; > > > > fakepd[0] = pdp[i]; > for (j = 1; j < NPDEPG; j++) > fakepd[j] = fakepd[j - 1] + NBPDR; > > > Then, whatever properties the pdp entry has will be inherited by the pd entry. Very nice, thank you! I overlooked the fact that "super" PDPE and "super" PDE have identical layout. I am going to commit this code tonight after applying the above changes. Thank you very much for all the guidance and help! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Nov 11 18:36:18 2010 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 06283106564A; Thu, 11 Nov 2010 18:36:18 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 87E068FC1B; Thu, 11 Nov 2010 18:36:17 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id oABIaBPc079508; Thu, 11 Nov 2010 10:36:11 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id oABIaBFO079507; Thu, 11 Nov 2010 10:36:11 -0800 (PST) (envelope-from sgk) Date: Thu, 11 Nov 2010 10:36:11 -0800 From: Steve Kargl To: Ed Schouten Message-ID: <20101111183611.GB79418@troutmask.apl.washington.edu> References: <20101111155243.GL2054@hoeg.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101111155243.GL2054@hoeg.nl> User-Agent: Mutt/1.4.2.3i Cc: toolchain@freebsd.org, current@freebsd.org Subject: Re: libcompiler_rt now part of FreeBSD's base system 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, 11 Nov 2010 18:36:18 -0000 On Thu, Nov 11, 2010 at 04:52:43PM +0100, Ed Schouten wrote: > Hello all, > > I just committed libcompiler_rt.a to HEAD. Even though I don't expect > serious issues -- especially not on the tier 1 architectures -- be sure > to contact me in case something goes wrong. I hooked it up to the build > in a separate commit, so if your system starts to act weird, just revert > r215127. > > Thanks to everyone who helped testing this! > Perhaps, a note in src/UPDATING to record the revision number and the __FreeBSD_version is merited. -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Nov 11 19:29:16 2010 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 75C561065679 for ; Thu, 11 Nov 2010 19:29:16 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 2C88B8FC1B for ; Thu, 11 Nov 2010 19:29:15 +0000 (UTC) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id E801F9CB051; Thu, 11 Nov 2010 20:29:13 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by lev.vlakno.cz (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogvD8NOVdfiM; Thu, 11 Nov 2010 20:29:13 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 7950B9CB5E9; Thu, 11 Nov 2010 20:29:13 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.4/8.14.4/Submit) id oABJTDNL015243; Thu, 11 Nov 2010 20:29:13 +0100 (CET) (envelope-from rdivacky) Date: Thu, 11 Nov 2010 20:29:13 +0100 From: Roman Divacky To: Ed Schouten Message-ID: <20101111192913.GA14762@freebsd.org> References: <20101111155243.GL2054@hoeg.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101111155243.GL2054@hoeg.nl> User-Agent: Mutt/1.4.2.3i Cc: toolchain@FreeBSD.org, current@FreeBSD.org Subject: Re: libcompiler_rt now part of FreeBSD's base system 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, 11 Nov 2010 19:29:16 -0000 On Thu, Nov 11, 2010 at 04:52:43PM +0100, Ed Schouten wrote: > Hello all, > > I just committed libcompiler_rt.a to HEAD. Even though I don't expect > serious issues -- especially not on the tier 1 architectures -- be sure > to contact me in case something goes wrong. I hooked it up to the build > in a separate commit, so if your system starts to act weird, just revert > r215127. great! can you share some more info about: - what is the plan for the unwinder etc? I know there's something from apple (not opensourced yet?) and others (tm) (not announced publicly yet I think) - how often(ever?) do you plan to update? while there's not much going on in compiler-rt repo it's not dead - do you plan to tackle libc++ now? :-P roman From owner-freebsd-current@FreeBSD.ORG Thu Nov 11 19:32:44 2010 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 351D9106566B; Thu, 11 Nov 2010 19:32:44 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id C974D8FC1A; Thu, 11 Nov 2010 19:32:43 +0000 (UTC) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 295145ACAB; Thu, 11 Nov 2010 20:32:25 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 25A675AC91; Thu, 11 Nov 2010 20:32:25 +0100 (CET) X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 039305CD54; Thu, 11 Nov 2010 20:32:25 +0100 (CET) Received: from wep4035.physik.uni-wuerzburg.de ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.5.2HF105) with ESMTP id 2010111120322476-105161 ; Thu, 11 Nov 2010 20:32:24 +0100 Date: Thu, 11 Nov 2010 20:32:23 +0100 From: Alexey Shuvaev To: Alexander Best Message-ID: <20101111193223.GA83129@wep4035.physik.uni-wuerzburg.de> References: <20101030232244.GA35209@freebsd.org> <20101105214700.GT85693@acme.spoerlein.net> <20101109182512.GA16204@freebsd.org> <20101109194605.GB45046@wep4035.physik.uni-wuerzburg.de> <20101110202621.GA53505@freebsd.org> <20101110213215.GA68484@freebsd.org> <20101111161830.GA15345@freebsd.org> MIME-Version: 1.0 In-Reply-To: <20101111161830.GA15345@freebsd.org> Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.21 (2010-09-15) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.5.2HF105 | October 15, 2010) at 11/11/2010 08:32:24 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.5.2HF105 | October 15, 2010) at 11/11/2010 08:32:24 PM Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: issue with "options DDB" 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, 11 Nov 2010 19:32:44 -0000 On Thu, Nov 11, 2010 at 04:18:30PM +0000, Alexander Best wrote: > On Wed Nov 10 10, Alexander Best wrote: > > On Wed Nov 10 10, Alexander Best wrote: > > > On Tue Nov 9 10, Alexey Shuvaev wrote: > > > > On Tue, Nov 09, 2010 at 06:25:12PM +0000, Alexander Best wrote: > > > > > On Fri Nov 5 10, Ulrich Sp=F6rlein wrote: > > > > > > On Sat, 30.10.2010 at 23:22:44 +0000, Alexander Best wrote: > > > > > > > hi there, > > > > > > >=20 > > > > > > > with "options DDB" in my kernel conf i run into the following= issue with my > > > > > > > kernel modules: > > > > > > >=20 > > > > > > > link=5Felf=5Flookup=5Fsymbol: missing symbol hash table > > > > > > > KLD file snd=5Fhda.ko is missing dependencies > > > > > > > KLD file sound.ko is missing dependencies > > > > > > > KLD file nvidia.ko is missing dependencies > > > > > > > KLD file linux.ko is missing dependencies > > > > > > > KLD file ng=5Fubt.ko is missing dependencies > > > > > > > KLD file ng=5Fhci.ko is missing dependencies > > > > > > > KLD file ng=5Fbluetooth.ko is missing dependencies > > > > > > > KLD file netgraph.ko is missing dependencies > > > > > > > link=5Felf=5Flookup=5Fsymbol: missing symbol hash table > > > > > > >=20 > > > > > > > removing the option solves the issue. any advice? > > > > > > >=20 > > > > > > > cheers. > > > > > > > alex > > > > > > >=20 > > > > > > > ps: i'm running HEAD (r214542; amd64). > > > > > >=20 > > > > > > You failed to mention the command that you run. I assume 'build= kernel'? > > > > > > Please note that you need and update-to-date "buildworld" for t= he kernel > > > > > > tools to be there, so please try the following (with options DD= B): > > > > > >=20 > > > > > > cd /usr/src > > > > > > make clean; make cleandir; make clean > > > > > > make buildworld > > > > > > make buildkernel KERNCONF=3DYOURKERNEL > > > > >=20 > > > > > hmmm....seems there is a problem with gcc. this is what i get dur= ing > > > > > buildworld: > > > > >=20 > > > > >=20 > > > > > clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=3Dna= tive -DIN=5FGLIBCPP=5FV3 -DHAVE=5FCONFIG=5FH -I/usr/src/gnu/lib/libsupc++/.= ./../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contr= ib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I= /usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=3DRepeatabilityCo= nsideredGood -g -fstack-protector -fconserve-space -fno-implicit-templates = -ffunction-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../= contrib/libstdc++/libsupc++/tinfo2.cc > > > > > clang++: warning: argument unused during compilation: '-fconserve= -space' > > > > ^^^^^^^^^^^ > > > >=20 > > > > > clang++: warning: argument unused during compilation: '-fno-impli= cit-templates' > > > > > clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=3Dna= tive -DIN=5FGLIBCPP=5FV3 -DHAVE=5FCONFIG=5FH -I/usr/src/gnu/lib/libsupc++/.= ./../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contr= ib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I= /usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=3DRepeatabilityCo= nsideredGood -g -fstack-protector -fconserve-space -fno-implicit-templates = -ffunction-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../= contrib/libstdc++/libsupc++/vec.cc > > > > > clang++: warning: argument unused during compilation: '-fconserve= -space' > > > > > clang++: warning: argument unused during compilation: '-fno-impli= cit-templates' > > > > > clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=3Dna= tive -DIN=5FGLIBCPP=5FV3 -DHAVE=5FCONFIG=5FH -I/usr/src/gnu/lib/libsupc++/.= ./../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contr= ib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I= /usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=3DRepeatabilityCo= nsideredGood -g -fstack-protector -fconserve-space -fno-implicit-templates = -ffunction-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../= contrib/libstdc++/libsupc++/vterminate.cc > > > > > clang++: warning: argument unused during compilation: '-fconserve= -space' > > > > > clang++: warning: argument unused during compilation: '-fno-impli= cit-templates' > > > > > clang -O2 -pipe -fno-strict-aliasing -funroll-loops -march=3Dnati= ve -DIN=5FGLIBCPP=5FV3 -DHAVE=5FCONFIG=5FH -I/usr/src/gnu/lib/libsupc++/../= ../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib= /libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/u= sr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=3DRepeatabilityCons= ideredGood -g -std=3Dgnu99 -fstack-protector -c /usr/src/gnu/lib/libsupc++= /../../../contrib/gcclibs/libiberty/cp-demangle.c > > > > > building static supc++ library > > > > > ranlib libsupc++.a > > > > > =3D=3D=3D> gnu/lib/libobjc (all) > > > > > gcc -O2 -pipe -fno-strict-aliasing -funroll-loops -march=3Dnative= -DHAVE=5FGTHR=5FDEFAULT -DIN=5FGCC -DIN=5FTARGET=5FLIBS -I. -I/usr/src/gnu= /lib/libobjc/../../usr.bin/cc/cc=5Ftools -I/usr/src/gnu/lib/libobjc/../../.= ./contrib/libobjc/objc -I/usr/src/gnu/lib/libobjc/../../../contrib/libobjc = -I/usr/src/gnu/lib/libobjc/../../../contrib/gcc/config -I/usr/src/gnu/lib/l= ibobjc/../../../contrib/gcc -I/usr/src/gnu/lib/libobjc/../../../contrib/gcc= libs/include -fexceptions -frandom-seed=3DRepeatabilityConsideredGood -g -s= td=3Dgnu99 -fstack-protector -c /usr/src/gnu/lib/libobjc/../../../contrib/= libobjc/archive.c > > > > > *** Signal 11 > > > > >=20 > > > > > Stop in /usr/src/gnu/lib/libobjc. > > > > > *** Error code 1 > > > > >=20 > > > > > Stop in /usr/src/gnu/lib. > > > > > *** Error code 1 > > > > >=20 > > > > > Stop in /usr/src. > > > > > *** Error code 1 > > > > >=20 > > > > > Stop in /usr/src. > > > > > *** Error code 1 > > > > >=20 > > > > > Stop in /usr/src. > > > > > *** Error code 1 > > > > >=20 > > > > > Stop in /usr/src. > > > > >=20 > > > > >=20 [snip] > > > > >=20 > > > > So, you are trying to do a mixed clang+gcc build. Which architectur= e is this? > > > > Does the problem occur in the case of a pure gcc build? > > >=20 > > > i just tried and with gcc buildworld succeeds. > >=20 > > maybe i should cd to /usr/sr/usr.bin/clang and install it before doing > > builworld. maybe my clang version contains an already fixed bug? >=20 > ok i did a complete buildworld/installworld with gcc as compiler. then i > switched back to clang, but the problem still occurs. :( >=20 Show your make.conf and src.conf (in full). = From owner-freebsd-current@FreeBSD.ORG Thu Nov 11 19:35:41 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id C53A8106566B; Thu, 11 Nov 2010 19:35:41 +0000 (UTC) Date: Thu, 11 Nov 2010 19:35:41 +0000 From: Alexander Best To: Alexey Shuvaev Message-ID: <20101111193541.GA48265@freebsd.org> References: <20101030232244.GA35209@freebsd.org> <20101105214700.GT85693@acme.spoerlein.net> <20101109182512.GA16204@freebsd.org> <20101109194605.GB45046@wep4035.physik.uni-wuerzburg.de> <20101110202621.GA53505@freebsd.org> <20101110213215.GA68484@freebsd.org> <20101111161830.GA15345@freebsd.org> <20101111193223.GA83129@wep4035.physik.uni-wuerzburg.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20101111193223.GA83129@wep4035.physik.uni-wuerzburg.de> Cc: freebsd-current@freebsd.org Subject: Re: issue with "options DDB" 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, 11 Nov 2010 19:35:41 -0000 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Thu Nov 11 10, Alexey Shuvaev wrote: > On Thu, Nov 11, 2010 at 04:18:30PM +0000, Alexander Best wrote: > > On Wed Nov 10 10, Alexander Best wrote: > > > On Wed Nov 10 10, Alexander Best wrote: > > > > On Tue Nov 9 10, Alexey Shuvaev wrote: > > > > > On Tue, Nov 09, 2010 at 06:25:12PM +0000, Alexander Best wrote: > > > > > > On Fri Nov 5 10, Ulrich Spörlein wrote: > > > > > > > On Sat, 30.10.2010 at 23:22:44 +0000, Alexander Best wrote: > > > > > > > > hi there, > > > > > > > > > > > > > > > > with "options DDB" in my kernel conf i run into the following issue with my > > > > > > > > kernel modules: > > > > > > > > > > > > > > > > link_elf_lookup_symbol: missing symbol hash table > > > > > > > > KLD file snd_hda.ko is missing dependencies > > > > > > > > KLD file sound.ko is missing dependencies > > > > > > > > KLD file nvidia.ko is missing dependencies > > > > > > > > KLD file linux.ko is missing dependencies > > > > > > > > KLD file ng_ubt.ko is missing dependencies > > > > > > > > KLD file ng_hci.ko is missing dependencies > > > > > > > > KLD file ng_bluetooth.ko is missing dependencies > > > > > > > > KLD file netgraph.ko is missing dependencies > > > > > > > > link_elf_lookup_symbol: missing symbol hash table > > > > > > > > > > > > > > > > removing the option solves the issue. any advice? > > > > > > > > > > > > > > > > cheers. > > > > > > > > alex > > > > > > > > > > > > > > > > ps: i'm running HEAD (r214542; amd64). > > > > > > > > > > > > > > You failed to mention the command that you run. I assume 'buildkernel'? > > > > > > > Please note that you need and update-to-date "buildworld" for the kernel > > > > > > > tools to be there, so please try the following (with options DDB): > > > > > > > > > > > > > > cd /usr/src > > > > > > > make clean; make cleandir; make clean > > > > > > > make buildworld > > > > > > > make buildkernel KERNCONF=YOURKERNEL > > > > > > > > > > > > hmmm....seems there is a problem with gcc. this is what i get during > > > > > > buildworld: > > > > > > > > > > > > > > > > > > clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector -fconserve-space -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/tinfo2.cc > > > > > > clang++: warning: argument unused during compilation: '-fconserve-space' > > > > > ^^^^^^^^^^^ > > > > > > > > > > > clang++: warning: argument unused during compilation: '-fno-implicit-templates' > > > > > > clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector -fconserve-space -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vec.cc > > > > > > clang++: warning: argument unused during compilation: '-fconserve-space' > > > > > > clang++: warning: argument unused during compilation: '-fno-implicit-templates' > > > > > > clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector -fconserve-space -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vterminate.cc > > > > > > clang++: warning: argument unused during compilation: '-fconserve-space' > > > > > > clang++: warning: argument unused during compilation: '-fno-implicit-templates' > > > > > > clang -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -std=gnu99 -fstack-protector -c /usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/libiberty/cp-demangle.c > > > > > > building static supc++ library > > > > > > ranlib libsupc++.a > > > > > > ===> gnu/lib/libobjc (all) > > > > > > gcc -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DHAVE_GTHR_DEFAULT -DIN_GCC -DIN_TARGET_LIBS -I. -I/usr/src/gnu/lib/libobjc/../../usr.bin/cc/cc_tools -I/usr/src/gnu/lib/libobjc/../../../contrib/libobjc/objc -I/usr/src/gnu/lib/libobjc/../../../contrib/libobjc -I/usr/src/gnu/lib/libobjc/../../../contrib/gcc/config -I/usr/src/gnu/lib/libobjc/../../../contrib/gcc -I/usr/src/gnu/lib/libobjc/../../../contrib/gcclibs/include -fexceptions -frandom-seed=RepeatabilityConsideredGood -g -std=gnu99 -fstack-protector -c /usr/src/gnu/lib/libobjc/../../../contrib/libobjc/archive.c > > > > > > *** Signal 11 > > > > > > > > > > > > Stop in /usr/src/gnu/lib/libobjc. > > > > > > *** Error code 1 > > > > > > > > > > > > Stop in /usr/src/gnu/lib. > > > > > > *** Error code 1 > > > > > > > > > > > > Stop in /usr/src. > > > > > > *** Error code 1 > > > > > > > > > > > > Stop in /usr/src. > > > > > > *** Error code 1 > > > > > > > > > > > > Stop in /usr/src. > > > > > > *** Error code 1 > > > > > > > > > > > > Stop in /usr/src. > > > > > > > > > > > > > [snip] > > > > > > > > > > > So, you are trying to do a mixed clang+gcc build. Which architecture is this? > > > > > Does the problem occur in the case of a pure gcc build? > > > > > > > > i just tried and with gcc buildworld succeeds. > > > > > > maybe i should cd to /usr/sr/usr.bin/clang and install it before doing > > > builworld. maybe my clang version contains an already fixed bug? > > > > ok i did a complete buildworld/installworld with gcc as compiler. then i > > switched back to clang, but the problem still occurs. :( > > > Show your make.conf and src.conf (in full). attached them both. -- a13x --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="src.conf" # CLANG options .if !defined(CC) || ${CC} == "cc" CC=clang .endif .if !defined(CXX) || ${CXX} == "c++" CXX=clang++ .endif # Don't die on warnings NO_WERROR= WERROR= # Don't forget this when using Jails! NO_FSCHG= # Enable debugging symbols for world DEBUG_FLAGS = -g # BUILDWORLD options BOOT2_UFS=UFS2_ONLY # don't need UFS1 support anymore #KLD_DEBUG=yes #MALLOC_PRODUCTION=yes # disable assertions and statistics WITHOUT_ACCT=true #WITHOUT_ACPI=true # needed by VirtualBox WITHOUT_AMD=true WITHOUT_APM=true WITHOUT_AT=true WITHOUT_ATM=true WITHOUT_AUDIT=true WITHOUT_BIND=true WITHOUT_BSNMP=true WITHOUT_CALENDAR=true WITHOUT_CDDL=true WITHOUT_CTM=true WITHOUT_CVS=true WITHOUT_FLOPPY=true WITHOUT_FREEBSD_UPDATE=true WITHOUT_GAMES=true #WITHOUT_GNU=true WITHOUT_GPIB=true WITHOUT_HTML=true WITH_IDEA=true WITHOUT_INET6=true #WITHOUT_INFO=true # needed by ports (`install-info`) WITHOUT_IPFILTER=true WITHOUT_IPFW=true WITHOUT_IPX=true WITHOUT_JAIL=true WITHOUT_LPR=true #WITHOUT_MAILWRAPPER=true WITHOUT_NCP=true WITHOUT_NDIS=true WITHOUT_NETCAT=true WITHOUT_NIS=true WITHOUT_NLS=true WITHOUT_NLS_CATALOGS=true WITHOUT_NS_CACHING=true WITHOUT_PAM_SUPPORT=true WITHOUT_PF=true WITHOUT_PMC=true WITHOUT_PPP=true WITHOUT_PROFILE=true WITHOUT_QUOTAS=true WITHOUT_RCMDS=true WITHOUT_RCS=true WITHOUT_ROUTED=true WITHOUT_SHAREDOCS=true WITHOUT_SYSINSTALL=true WITHOUT_TCSH=true WITHOUT_TELNET=true --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="make.conf" # WORLD/KERNEL options KERNCONF = ARUNDEL MODULES_OVERRIDE = \ netgraph/netgraph \ netgraph/socket netgraph/bluetooth/bluetooth netgraph/bluetooth/hci \ netgraph/bluetooth/l2cap netgraph/bluetooth/socket netgraph/bluetooth/ubt \ linux tmpfs sound/sound sound/driver/hda usb/uhid \ procfs pseudofs linprocfs linsysfs lindev usb/quirk geom # GCC46 options #.if empty(.CURDIR:M/usr/src*) && empty(.CURDIR:M/usr/obj*) && exists(/usr/local/bin/gcc46) && exists(/usr/local/bin/g++46) && exists(/usr/local/bin/cpp46) #CC = /usr/local/bin/gcc46 #CXX = /usr/local/bin/g++46 #CPP = /usr/local/bin/cpp46 #.endif # compiler flags CPUTYPE ?= native COPTFLAGS = -O0 -pipe -fno-builtin -fno-strict-aliasing -funroll-loops CFLAGS = -O2 -pipe -fno-strict-aliasing -funroll-loops#-fno-builtin (don't use => corrupted gcc) #CFLAGS=-O3 -march=athlon64 CXXFLAGS += -fconserve-space # SENDMAIL options SENDMAIL_MC = /etc/mail/freebsd.mc SENDMAIL_SUBMIT_MC = /etc/mail/freebsd.submit.mc # PORTS options OVERRIDE_LINUX_BASE_PORT = f10 OVERRIDE_LINUX_NONBASE_PORTS = f10 DA4 = yes WITH_BSDEL = yes WITH_256_COLOR = yes # added by use.perl 2010-10-14 16:57:25 PERL_VERSION=5.12.2 --zhXaljGHf11kAtnf-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 11 19:58:29 2010 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 E665C106566B for ; Thu, 11 Nov 2010 19:58:29 +0000 (UTC) (envelope-from marek_sal@wp.pl) Received: from mx4.wp.pl (mx4.wp.pl [212.77.101.8]) by mx1.freebsd.org (Postfix) with ESMTP id 775118FC0C for ; Thu, 11 Nov 2010 19:58:29 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 19145 invoked from network); 11 Nov 2010 20:31:47 +0100 Received: from cwx170.internetdsl.tpnet.pl (HELO marekdesktop) (marek_sal@[83.19.131.170]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 11 Nov 2010 20:31:47 +0100 Message-ID: <64FA2044DA694411995A309FF342396C@marekdesktop> From: "Marek Salwerowicz" To: Date: Thu, 11 Nov 2010 20:31:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [4WKG] X-Mailman-Approved-At: Thu, 11 Nov 2010 21:51:56 +0000 Subject: Atheros bluetooth unrecognizable 0cf3:3002 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, 11 Nov 2010 19:58:30 -0000 Hi, I have built-in bluetooth atheros. On ubuntu linux it is shown as (lsusb): Bus 003 Device 006: ID 0cf3:3002 Atheros Communications, Inc. Unfortunately, FreeBSD-Current can't see it as bluetooth device (despite loading ng_ubt module to kernel... ): ugen0.4: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON What modules should I load into kernel to see it as bluetooth device? -- Marek Salwerowicz From owner-freebsd-current@FreeBSD.ORG Thu Nov 11 22:31:57 2010 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 827B41065672 for ; Thu, 11 Nov 2010 22:31:57 +0000 (UTC) (envelope-from pyunyh@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 38B558FC08 for ; Thu, 11 Nov 2010 22:31:56 +0000 (UTC) Received: by gwj20 with SMTP id 20so1158058gwj.13 for ; Thu, 11 Nov 2010 14:31:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:subject :message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=C267PAagVRVTHb02SIG6+gyat10rvi8BLJGVwn+Xwak=; b=FX4C9XeS1101Q4Y+zWcj+xDYOj4HDZiwm6romCTT6EruJ3ZHZPqkfzkbngcn6bBy0Y uCxfHPD73xk/4NNjyCMuqkp+BRXByNVfmdCbU2nt9taPF0L4bJPVwaXidyUtAV+J09bJ aWvF3K9N+IUfqQDewspWJ5Miqc03g91X0Rh6U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=goOntxgJJKZ2OYitLSrXpBFzZivUX51ZgR6kR7lNbZg/s4mShPMV3MKmdmOCd2h+/n IBuWRlH0pDVRroaOV1KFTJAR7mJNL/ii/CPNndteBrauGuzpLxPFXF7Cq79vnsRtk0FZ DWvZv6nsagY9jun98aJDuhE1oZw7qswudTAHg= Received: by 10.101.188.7 with SMTP id q7mr931699anp.207.1289514716282; Thu, 11 Nov 2010 14:31:56 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id d15sm2848603ana.0.2010.11.11.14.31.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 14:31:54 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 11 Nov 2010 14:30:59 -0800 From: Pyun YongHyeon Date: Thu, 11 Nov 2010 14:30:59 -0800 To: obrien@freebsd.org, freebsd-current@freebsd.org Message-ID: <20101111223059.GK17566@michelle.cdnetworks.com> References: <20101111003254.GA7139@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101111003254.GA7139@dragon.NUXI.org> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: Non-sleepable locks PANIC in sf(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@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: Thu, 11 Nov 2010 22:31:57 -0000 On Wed, Nov 10, 2010 at 04:32:54PM -0800, David O'Brien wrote: > Script started on Wed Nov 10 15:56:31 2010 > FreeBSD 9.0-CURRENT #644 r215099M: Wed Nov 10 11:45:01 PST 2010 > obrien@dragon:/usr/obj/4kib/i386/compile/DRAGON-WITNESS i386 > WARNING: WITNESS option enabled, expect reduced performance. > WARNING: DIAGNOSTIC option enabled, expect reduced performance. > [..] > Setting hostname: dragon.NUXI.org. > sf0: port 0x8800-0x88ff mem 0xfa480000-0xfa4fffff irq 26 at device 4.0 on pci3 > miibus1: on sf0 > ukphy0: PHY 1 on miibus1 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > sf0: Ethernet address: 00:00:d1:ed:81:95 > sf1: port 0x8400-0x84ff mem 0xfa380000-0xfa3fffff irq 27 at device 5.0 on pci3 > miibus2: on sf1 > ukphy1: PHY 1 on miibus2 > ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > sf1: Ethernet address: 00:00:d1:ed:81:96 > sf2: port 0x8000-0x80ff mem 0xfa300000-0xfa37ffff irq 24 at device 6.0 on pci3 > miibus3: on sf2 > ukphy2: PHY 1 on miibus3 > ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > sf2: Ethernet address: 00:00:d1:ed:81:97 > sf3: port 0x7800-0x78ff mem 0xfa200000-0xfa27ffff irq 25 at device 7.0 on pci3 > miibus4: on sf3 > ukphy3: PHY 1 on miibus4 > ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > sf3: Ethernet address: 00:00:d1:ed:81:98 > Expensive timeout(9) function: 0xc061b270(0xc65965a0) 1.987919972 s > [..] > Starting Network: lo0 bge0 sf0 em0. > [..] > sf0: flags=8843 metric 0 mtu 1500 > options=b > ether 00:00:d1:ed:81:95 > inet 74.95.12.85 netmask 0xfffffffc broadcast 74.95.12.87 > inet6 fe80::200:d1ff:feed:8195%sf0 prefixlen 64 tentative scopeid 0x5 > nd6 options=29 > media: Ethernet autoselect (100baseTX ) > status: active > [..] > Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex sf0 (network driver) r = 0 (0xc722b584) locked @ /usr/obj/4kib/modules/sf/../../dev/sf/if_sf.c:1862 > KDB: stack backtrace: > db_trace_self_wrapper(c08870ef,c6be8a80,4,c0a83ba0,c704164c,...) at 0xc04ed726 = db_trace_self_wrapper+0x26 > kdb_backtrace(746,0,ffffffff,c0a83b94,daaa2ac0,...) at 0xc061152a = kdb_backtrace+0x2a > _witness_debugger(c08898ba,daaa2ad4,4,1,0,...) at 0xc0626256 = _witness_debugger+0x26 > witness_warn(5,0,c08b2265,246,c70415a0,...) at 0xc062776d = witness_warn+0x1fd > trap(daaa2bac) at 0xc08214bd = trap+0x2ad > calltrap() at 0xc080b93c = calltrap+0x6 > --- trap 0xc, eip = 0xc08077c4, esp = 0xdaaa2bec, ebp = 0xdaaa2c00 --- > _bus_dmamap_sync(c6cbac80,c724a000,2,daaa2c28,daaa2c30,...) at 0xc08077c4 = _bus_dmamap_sync+0x54 > sf_newbuf(c722b584,4,c7223bbd,603,c06051d5,...) at 0xc7220173 = sf_newbuf+0xf3 > sf_intr(c722a000,c0947ec0,4,c0882361,c65d4238,...) at 0xc7221c48 = sf_intr+0x248 > intr_event_execute_handlers(c658f7f8,c65d4200,c087ef80,533,c65d4270,...) at 0xc05b47b5 = intr_event_execute_handlers+0x125 > ithread_loop(c65dd830,daaa2d28,c087ed0e,33b,c658f7f8,...) at 0xc05b55ac = ithread_loop+0xac > fork_exit(c05b5500,c65dd830,daaa2d28) at 0xc05b24e8 = fork_exit+0xb8 > fork_trampoline() at 0xc080b9e4 = fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xdaaa2d60, ebp = 0 --- > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x400000c > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc08077c4 > stack pointer = 0x28:0xdaaa2bec > frame pointer = 0x28:0xdaaa2c00 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 12 (irq26: sf0) > trap number = 12 > panic: page fault > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper(c08870ef,d31206e,2c66000a,70797420,78302065,...) at 0xc04ed726 = db_trace_self_wrapper+0x26 > kdb_backtrace(c08b0bbd,0,c086c89f,daaa2a88,0,...) at 0xc061152a = kdb_backtrace+0x2a > panic(c086c89f,c08b226c,c7041748,1,1,...) at 0xc05de537 = panic+0x117 > trap_fatal(5,0,c08b2265,246,c70415a0,...) at 0xc0820ee5 = trap_fatal+0x325 > trap(daaa2bac) at 0xc08214ce = trap+0x2be > calltrap() at 0xc080b93c = calltrap+0x6 > --- trap 0xc, eip = 0xc08077c4, esp = 0xdaaa2bec, ebp = 0xdaaa2c00 --- > _bus_dmamap_sync(c6cbac80,c724a000,2,daaa2c28,daaa2c30,...) at 0xc08077c4 = _bus_dmamap_sync+0x54 > sf_newbuf(c722b584,4,c7223bbd,603,c06051d5,...) at 0xc7220173 = sf_newbuf+0xf3 > sf_intr(c722a000,c0947ec0,4,c0882361,c65d4238,...) at 0xc7221c48 = sf_intr+0x248 > intr_event_execute_handlers(c658f7f8,c65d4200,c087ef80,533,c65d4270,...) at 0xc05b47b5 = intr_event_execute_handlers+0x125 > ithread_loop(c65dd830,daaa2d28,c087ed0e,33b,c658f7f8,...) at 0xc05b55ac = ithread_loop+0xac > fork_exit(c05b5500,c65dd830,daaa2d28) at 0xc05b24e8 = fork_exit+0xb8 > fork_trampoline() at 0xc080b9e4 = fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xdaaa2d60, ebp = 0 --- > Uptime: 40s > Physical memory: 3203 MB > Dumping 116 MB: (CTRL-C to abort) panic: Trying sleep, but thread marked as sleeping prohibited > cpuid = 0 > Uptime: 40s > Automatic reboot in 15 seconds - press a key on the console to abort > panic: Trying sleep, but thread marked as sleeping prohibited > cpuid = 0 > Uptime: 40s > Automatic reboot in 15 seconds - press a key on the console to abort > panic: Trying sleep, but thread marked as sleeping prohibited > cpuid = 0 > Uptime: 40s > [EOT] > Script done on Wed Nov 10 15:58:52 2010 > > thoughts? Does sf(4) use shared interrupt? From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 00:11:17 2010 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 38E6E106566B for ; Fri, 12 Nov 2010 00:11:17 +0000 (UTC) (envelope-from maksim.yevmenkin@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 E375A8FC1A for ; Fri, 12 Nov 2010 00:11:16 +0000 (UTC) Received: by ywa8 with SMTP id 8so1093947ywa.13 for ; Thu, 11 Nov 2010 16:11:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:in-reply-to :mime-version:content-transfer-encoding:content-type:message-id:cc :x-mailer:from:subject:date:to; bh=Chklaw4QSkqDid+6xn3O7SY6LuqHwzJVJpMm4gsSzJU=; b=QrueAGKw5vhTrqGEopwRnYD0az7QyB0LRo0PZMglz9uqPdCI72NPZ11HpSydOQS8fP 3/vKQy2TBTY3FWk2rgw0xMHNsKFdQNmURGSIiO7Xl+IcDXXlwfZ5i+3aYAHXSl74iqpY YsXT/eQljE1NwC01o0VCTtcA88is4L9CQGepM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=D9xQZ1DpQwQDX7g5ibNcgi9Dm72WTxM96v8Y3ozu+6Zmq+DxCb40kpqhA2UTrqFNJ4 MzcwFBsoaancIdbM9z5x8Z7ogM43KWhBTk/UGtTCnATEITFRTEa5ady564bupMwigYIe Oq+btLWE84PI8ruDw6Yhi2Pgsrq/Y80O8HN/M= Received: by 10.150.196.19 with SMTP id t19mr2801725ybf.299.1289519023596; Thu, 11 Nov 2010 15:43:43 -0800 (PST) Received: from [10.8.164.39] ([166.205.137.70]) by mx.google.com with ESMTPS id j7sm1890150yha.18.2010.11.11.15.43.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 15:43:42 -0800 (PST) References: <64FA2044DA694411995A309FF342396C@marekdesktop> In-Reply-To: <64FA2044DA694411995A309FF342396C@marekdesktop> Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8B117) From: maksim yevmenkin Date: Thu, 11 Nov 2010 15:43:10 -0800 To: Marek Salwerowicz Cc: "" Subject: Re: Atheros bluetooth unrecognizable 0cf3:3002 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, 12 Nov 2010 00:11:17 -0000 Please try fw dowloader from Http://people.freebsd.org/~emax/ath3kfw.tar.gz Thanks, Max On Nov 11, 2010, at 11:31 AM, "Marek Salwerowicz" wrote: > Hi, >=20 > I have built-in bluetooth atheros. On ubuntu linux it is shown as (lsusb):= > Bus 003 Device 006: ID 0cf3:3002 Atheros Communications, Inc. >=20 >=20 > Unfortunately, FreeBSD-Current can't see it as bluetooth device (despite l= oading ng_ubt module to kernel... ): >=20 > ugen0.4: at usbus0, cfg=3D0 md=3DHOST spd=3D= FULL (12Mbps) pwr=3DON >=20 > What modules should I load into kernel to see it as bluetooth device? >=20 > --=20 > Marek Salwerowicz=20 > _______________________________________________ > 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 Fri Nov 12 03:51:43 2010 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 834181065674; Fri, 12 Nov 2010 03:51:43 +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 42C5E8FC1D; Fri, 12 Nov 2010 03:51:42 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oAC3pg2N096272; Thu, 11 Nov 2010 22:51:42 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oAC3pgs9096267; Fri, 12 Nov 2010 03:51:42 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Nov 2010 03:51:42 GMT Message-Id: <201011120351.oAC3pgs9096267@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: Fri, 12 Nov 2010 03:51:43 -0000 TB --- 2010-11-12 03:51:12 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-12 03:51:12 - starting HEAD tinderbox run for mips/mips TB --- 2010-11-12 03:51:12 - cleaning the object tree TB --- 2010-11-12 03:51:12 - cvsupping the source tree TB --- 2010-11-12 03:51:12 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2010-11-12 03:51:41 - building world TB --- 2010-11-12 03:51:41 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-12 03:51:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-12 03:51:41 - TARGET=mips TB --- 2010-11-12 03:51:41 - TARGET_ARCH=mips TB --- 2010-11-12 03:51:41 - TZ=UTC TB --- 2010-11-12 03:51:41 - __MAKE_CONF=/dev/null TB --- 2010-11-12 03:51:41 - cd /src TB --- 2010-11-12 03:51:41 - /usr/bin/make -B buildworld "/src/Makefile.inc1", line 138: Unknown target mips:mips. *** Error code 1 Stop in /src. TB --- 2010-11-12 03:51:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-12 03:51:42 - ERROR: failed to build world TB --- 2010-11-12 03:51:42 - 2.14 user 7.21 system 29.84 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 04:17:06 2010 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 F2D401065674; Fri, 12 Nov 2010 04:17: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 912388FC1C; Fri, 12 Nov 2010 04:17:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oAC4H49B073327; Thu, 11 Nov 2010 23:17:04 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oAC4H4qZ073323; Fri, 12 Nov 2010 04:17:04 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Nov 2010 04:17:04 GMT Message-Id: <201011120417.oAC4H4qZ073323@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: Fri, 12 Nov 2010 04:17:06 -0000 TB --- 2010-11-12 04:11:46 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-12 04:11:46 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-11-12 04:11:46 - cleaning the object tree TB --- 2010-11-12 04:11:50 - cvsupping the source tree TB --- 2010-11-12 04:11:50 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-11-12 04:12:09 - building world TB --- 2010-11-12 04:12:09 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-12 04:12:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-12 04:12:09 - TARGET=powerpc TB --- 2010-11-12 04:12:09 - TARGET_ARCH=powerpc64 TB --- 2010-11-12 04:12:09 - TZ=UTC TB --- 2010-11-12 04:12:09 - __MAKE_CONF=/dev/null TB --- 2010-11-12 04:12:09 - cd /src TB --- 2010-11-12 04:12:09 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 12 04:12:11 UTC 2010 >>> 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 [...] cc -o rtermcap /src/usr.sbin/sysinstall/rtermcap.c -ltermcap ===> gnu/usr.bin/cc/cc_tools (obj,depend,all) LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-gather.awk /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/c.opt /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/common.opt /src/gnu/usr.bin/cc/cc_tools/freebsd.opt > optionlist LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-functions.awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opth-gen.awk < optionlist > options.h LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-functions.awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/optc-gen.awk -v header_name="config.h system.h coretypes.h tm.h" < optionlist > options.c TARGET_CPU_DEFAULT="\"powerpc64\"" HEADERS="auto-host.h ansidecl.h" DEFINES="" /bin/sh /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/mkconfig.sh bconfig.h TARGET_CPU_DEFAULT="\"powerpc64\"" HEADERS="options.h rs600064/rs600064.h dbxelf.h elfos-undef.h elfos.h freebsd-native.h freebsd-spec.h freebsd.h rs600064/biarch64.h rs600064/default64.h rs600064/freebsd.h defaults.h" DEFINES="" /bin/sh /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/mkconfig.sh tm.h make: don't know how to make /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config/rs600064/rs600064.c. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-12 04:17:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-12 04:17:04 - ERROR: failed to build world TB --- 2010-11-12 04:17:04 - 205.58 user 55.39 system 317.88 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 04:41:20 2010 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 E234A106566B for ; Fri, 12 Nov 2010 04:41:20 +0000 (UTC) (envelope-from wilkinsa@dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 430E68FC1A for ; Fri, 12 Nov 2010 04:41:19 +0000 (UTC) Received: from ednmsw520.dsto.defence.gov.au (ednmsw520.dsto.defence.gov.au [131.185.68.60]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id oAC4HqnK015263 for ; Fri, 12 Nov 2010 14:47:52 +1030 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw520.dsto.defence.gov.au (Clearswift SMTPRS 5.4.0) with ESMTP id for ; Fri, 12 Nov 2010 14:54:58 +1030 Received: from stlex511.dsto.defence.gov.au ([203.6.60.49]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Nov 2010 14:54:57 +1030 Received: from stlux550.dsto.defence.gov.au ([203.6.60.61]) by stlex511.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.4675); Fri, 12 Nov 2010 12:24:56 +0800 Received: from stlux550.dsto.defence.gov.au (localhost [127.0.0.1]) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3) with ESMTP id oAC4OuHq047721 for ; Fri, 12 Nov 2010 12:24:56 +0800 (WST) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3/Submit) id oAC4Ouv5047720 for freebsd-current@freebsd.org; Fri, 12 Nov 2010 12:24:56 +0800 (WST) (envelope-from wilkinsa) Date: Fri, 12 Nov 2010 12:24:56 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20101112042456.GD46709@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org References: <20101111155243.GL2054@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20101111155243.GL2054@hoeg.nl> Organisation: Defence Science Technology Organisation X-Message-Flag: "Please Restore Line Breaks If Necessary" User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 12 Nov 2010 04:24:56.0576 (UTC) FILETIME=[8FA64000:01CB8221] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-6.500.1024-17760.003 X-TM-AS-Result: No--4.826700-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Transfer-Encoding: 7bit Subject: Re: libcompiler_rt now part of FreeBSD's base system [SEC=UNCLASSIFIED] 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, 12 Nov 2010 04:41:21 -0000 0n Thu, Nov 11, 2010 at 04:52:43PM +0100, Ed Schouten wrote: >I just committed libcompiler_rt.a to HEAD. Even though I don't expect >serious issues -- especially not on the tier 1 architectures -- be sure >to contact me in case something goes wrong. I hooked it up to the build >in a separate commit, so if your system starts to act weird, just revert >r215127. Can you please explain to us what this actually brings to the table for freebsd ? I know it replaces libgcc ... but why is that such a good thing ? -Alex IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 08:55:04 2010 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 126C51065745 for ; Fri, 12 Nov 2010 08:55:04 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id 794F88FC19 for ; Fri, 12 Nov 2010 08:55:03 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5OBHFxb9I47YZ7HELXzI6cL6pwPTRnd5uxbD1DPQ4WY= c=1 sm=1 a=WrOSKJTHxIAA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=NzkW3RTSaLTf7hCE9sEA:9 a=ioilf2Ov2yRrbH5r_ihfYaVGlCYA:4 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 47547891; Fri, 12 Nov 2010 09:55:01 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 12 Nov 2010 09:56:04 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <06D5F9F6F655AD4C92E28B662F7F853E039E389A@seaxch09.desktop.isilon.com> In-Reply-To: <06D5F9F6F655AD4C92E28B662F7F853E039E389A@seaxch09.desktop.isilon.com> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011120956.04501.hselasky@c2i.net> Cc: Matthew Fleming Subject: Re: sleep bug in taskqueue(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, 12 Nov 2010 08:55:04 -0000 On Thursday 29 April 2010 01:59:58 Matthew Fleming wrote: > It looks to me like taskqueue_drain(taskqueue_thread, foo) will not > correctly detect whether or not a task is currently running. The check > is against a field in the taskqueue struct, but for the taskqueue_thread > queue with more than one thread, multiple threads can simultaneously be > running a task, thus stomping over the tq_running field. > > I have not seen any problem with the code as-is in actual use, so this > is purely an inspection bug. > > The following patch should fix the problem. Because it changes the size > of struct task I'm not sure if it would be suitable for MFC. > 1) The u_char is going to leave a hole in that structure on ARM platforms for example. 2) The existing taskqueue implementation also has a missing check for the pending count wrapping to zero. I.E. it should stick at 0xFFFF and not wrap to 0. --HPS From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 09:05:10 2010 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 4571C10656A8 for ; Fri, 12 Nov 2010 09:05:10 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id C0DDA8FC19 for ; Fri, 12 Nov 2010 09:05:09 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5OBHFxb9I47YZ7HELXzI6cL6pwPTRnd5uxbD1DPQ4WY= c=1 sm=1 a=WrOSKJTHxIAA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=ufIGlTigpa4yK7jz1iQA:9 a=koMamTD_mdDjrzO4wUYA:7 a=9-pG42uRGKA6spH_fxcGWkS4wjEA:4 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 47553019; Fri, 12 Nov 2010 10:05:07 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 12 Nov 2010 10:06:10 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <06D5F9F6F655AD4C92E28B662F7F853E039E389A@seaxch09.desktop.isilon.com> In-Reply-To: <06D5F9F6F655AD4C92E28B662F7F853E039E389A@seaxch09.desktop.isilon.com> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011121006.10183.hselasky@c2i.net> Cc: Matthew Fleming Subject: Re: sleep bug in taskqueue(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, 12 Nov 2010 09:05:10 -0000 On Thursday 29 April 2010 01:59:58 Matthew Fleming wrote: > struct task { > - STAILQ_ENTRY(task) ta_link; /* link for queue */ > - u_short ta_pending; /* count times queued */ > - u_short ta_priority; /* Priority */ > - task_fn_t *ta_func; /* task handler */ > - void *ta_context; /* argument for handler */ > + STAILQ_ENTRY(task) ta_link; /* (q) link for queue */ > + u_char ta_flags; /* (q) state of this task */ > +#define TA_FLAGS_RUNNING 0x01 > + u_short ta_pending; /* (q) count times queued */ > + u_short ta_priority; /* (c) Priority */ > + task_fn_t *ta_func; /* (c) task handler */ > + void *ta_context; /* (c) argument for handler */ Hi, I would rather implement TAILQ_ENTRY() here, and put some magic in the "tqe_prev" field, hence the u_char you add, will be padded to a bigger size on non-intel platforms anyway. task->ta_pending = 0; - queue->tq_running = task; + task->ta_entry.tqe_prev = (void *)1; TQ_UNLOCK(queue); task->ta_func(task->ta_context, pending); TQ_LOCK(queue); - queue->tq_running = NULL; + task->ta_entry.tqe_prev = (void *)0; wakeup(task); } ... + while (task->ta_entry != (void *)0) --HPS From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 09:07:40 2010 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 197DF1065675 for ; Fri, 12 Nov 2010 09:07:40 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id 9DA168FC1C for ; Fri, 12 Nov 2010 09:07:39 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=sEolSJAlcSxSMaOm1MQ0bvrIu+BNAN+OqG2UAUgC4Ok= c=1 sm=1 a=WrOSKJTHxIAA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=NfZfBIl9gYmS0lq_rVEA:9 a=sVW8itN138z2eO1VaZuicetP3xIA:4 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 48026953; Fri, 12 Nov 2010 10:07:37 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 12 Nov 2010 10:08:41 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <06D5F9F6F655AD4C92E28B662F7F853E039E389A@seaxch09.desktop.isilon.com> <201011121006.10183.hselasky@c2i.net> In-Reply-To: <201011121006.10183.hselasky@c2i.net> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011121008.41122.hselasky@c2i.net> Cc: Matthew Fleming Subject: Re: sleep bug in taskqueue(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, 12 Nov 2010 09:07:40 -0000 On Friday 12 November 2010 10:06:10 you wrote: > - queue->tq_running = NULL; forgot this check: /* don't clear if queued again */ if (task->ta_entry.tqe_prev == (void *)1) > + task->ta_entry.tqe_prev = (void *)0; > wakeup(task); From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 09:54:00 2010 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 2B4071065674 for ; Fri, 12 Nov 2010 09:54:00 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id E3A918FC15 for ; Fri, 12 Nov 2010 09:53:59 +0000 (UTC) Received: from lawrence1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id D7C817E84A; Fri, 12 Nov 2010 20:35:45 +1100 (EST) Message-ID: <4CDD0A71.7020708@freebsd.org> Date: Fri, 12 Nov 2010 20:35:45 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-AU; rv:1.9.2.9) Gecko/20101006 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lauren.room52.net Cc: Subject: [HEADS UP] Significant TCP work committed to head 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, 12 Nov 2010 09:54:00 -0000 Hi All, A quick note that this evening, I made the first in a series of upcoming commits to head that modify the TCP stack fairly significantly. I have no reason to believe you'll notice any issues, but TCP is a complex beast and it's possible things might crop up. The changes are mostly related to congestion control, so the sorts of issues that are likely to crop up if any will most probably be subtle and difficult to even detect. The first svn revision in question is r215166. The next few commits I plan to make will be basically zero impact and then another significant patch will follow in a few weeks. If you bump into an issue that you think might be related to this work, please roll back r215166 from your tree and attempt to reporoduce before reporting the problem. Please CC me directly with your problem report and post to freebsd-current@ or freebsd-net@ as well. Lots more information about what all this does and how to use it will be following in the coming weeks, but in the meantime, just keep this note in the back of your mind. For the curious, some information about the project is available at [1,2]. Cheers, Lawrence [1] http://caia.swin.edu.au/freebsd/5cc/ [2] http://www.freebsd.org/news/status/report-2010-07-2010-09.html#Five-New-TCP-Congestion-Control-Algorithms-for-FreeBSD From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 10:55:44 2010 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 373C91065670; Fri, 12 Nov 2010 10:55: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 058488FC17; Fri, 12 Nov 2010 10:55:42 +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 MAA27499; Fri, 12 Nov 2010 12:55:41 +0200 (EET) (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 1PGrID-000INZ-0z; Fri, 12 Nov 2010 12:55:41 +0200 Message-ID: <4CDD1CDB.6020409@freebsd.org> Date: Fri, 12 Nov 2010 12:54:19 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-x11@freebsd.org, Konstantin Belousov References: <4CD3B1D2.30003@icyb.net.ua> <4CD7E401.1010206@freebsd.org> In-Reply-To: <4CD7E401.1010206@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit Cc: Subject: Re: radeon_cp_texture: page fault with non-sleepable locks held 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, 12 Nov 2010 10:55:44 -0000 on 08/11/2010 13:50 Andriy Gapon said the following: > on 05/11/2010 09:27 Andriy Gapon said the following: >> >> I use FreeSBD head and KDE 4 with all the bells and whistles enabled. >> Apparently recent KDE update has enabled even more of them, because I started to >> have panics with a kernel that has INVARIANTS and WITNESS enabled. > > I tried to solve the problem by changing drmdev from mutex to sx: > http://people.freebsd.org/~avg/drm-sx.diff Quite surprisingly for me, it seems that this patch has solved the following problem for me: http://thread.gmane.org/gmane.os.freebsd.devel.x11/9849 Or maybe this is just a coincidence. Could there be a logical explanation for this? > The things have improved, I am not getting the panic anymore. > Instead I have this LOR now: > lock order reversal: > 1st 0xffffff0001b968a0 drmdev (drmdev) @ /usr/src/sys/dev/drm/drm_drv.c:791 > 2nd 0xffffff0072a87200 user map (user map) @ /usr/src/sys/vm/vm_map.c:3548 > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff801b8b3a = db_trace_self_wrapper+0x2a > kdb_backtrace() at 0xffffffff803a7a6a = kdb_backtrace+0x3a > _witness_debugger() at 0xffffffff803bd40c = _witness_debugger+0x2c > witness_checkorder() at 0xffffffff803be879 = witness_checkorder+0x959 > _sx_slock() at 0xffffffff80378af8 = _sx_slock+0x88 > _vm_map_lock_read() at 0xffffffff805109e6 = _vm_map_lock_read+0x36 > vm_map_lookup() at 0xffffffff805127b4 = vm_map_lookup+0x54 > vm_fault() at 0xffffffff805097f9 = vm_fault+0xf9 > trap_pfault() at 0xffffffff80545d0f = trap_pfault+0x11f > trap() at 0xffffffff80546597 = trap+0x657 > calltrap() at 0xffffffff805305c8 = calltrap+0x8 > --- trap 0xc, rip = 0xffffffff8054405d, rsp = 0xffffff81241b47f0, rbp = > 0xffffff81241b4870 --- > copyin() at 0xffffffff8054405d = copyin+0x3d > radeon_cp_texture() at 0xffffffff8022fbd7 = radeon_cp_texture+0x167 > drm_ioctl() at 0xffffffff8020fa38 = drm_ioctl+0x318 > devfs_ioctl_f() at 0xffffffff802dd649 = devfs_ioctl_f+0x109 > kern_ioctl() at 0xffffffff803c1107 = kern_ioctl+0x1f7 > ioctl() at 0xffffffff803c12c8 = ioctl+0x168 > syscallenter() at 0xffffffff803b57be = syscallenter+0x26e > syscall() at 0xffffffff80545e52 = syscall+0x42 > Xfast_syscall() at 0xffffffff805308a2 = Xfast_syscall+0xe2 > > Is this a serious LOR? > How can I resolve it? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 14:18:49 2010 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 0B489106566C for ; Fri, 12 Nov 2010 14:18:49 +0000 (UTC) (envelope-from mdf356@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 B5B728FC12 for ; Fri, 12 Nov 2010 14:18:48 +0000 (UTC) Received: by gxk9 with SMTP id 9so1936405gxk.13 for ; Fri, 12 Nov 2010 06:18:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=IUqLvQCRT16Dy2hsyEYOff26n99EONvYCjksXkzg3Go=; b=sqVzL8QiISKviomwTFyH0rUDP+dBszouLhEBacHCrxCzBYrGr4U7xVcAwUVRdN8y0X oZJk3ADqN9bVjaNr7GlhRW3UNEIXFPpiuEAtsC1nkjZhHm1qlHDbyZ8ERm7+yd06tr/N h+yP12e3lfx8iAHwK3N6lhwIIvbaIaNeg8OVg= 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=I2bjj0G+oSGWPq8+1ui0KrEfj6wWuZXnEBN1qZZ9/6Q/BE97ubhwffHg1YJoStx/t/ 4pdvtHAikQYaxYav1z7X2K8UdxgLc0RrhWGQ5Abro/JBjxuyGSDQiSwT59/PyOFPbSOu oVMJaoqL0XKvJ8C4tDRMw+Idb4y2rsBCgmSeQ= MIME-Version: 1.0 Received: by 10.42.211.131 with SMTP id go3mr1919282icb.393.1289571527024; Fri, 12 Nov 2010 06:18:47 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.231.21.35 with HTTP; Fri, 12 Nov 2010 06:18:46 -0800 (PST) In-Reply-To: <201011120956.04501.hselasky@c2i.net> References: <06D5F9F6F655AD4C92E28B662F7F853E039E389A@seaxch09.desktop.isilon.com> <201011120956.04501.hselasky@c2i.net> Date: Fri, 12 Nov 2010 06:18:46 -0800 X-Google-Sender-Auth: zIFuVX9Ki84cAymiyVzh3-UJdkc Message-ID: From: mdf@FreeBSD.org To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: sleep bug in taskqueue(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, 12 Nov 2010 14:18:49 -0000 On Fri, Nov 12, 2010 at 12:56 AM, Hans Petter Selasky wr= ote: > On Thursday 29 April 2010 01:59:58 Matthew Fleming wrote: >> It looks to me like taskqueue_drain(taskqueue_thread, foo) will not >> correctly detect whether or not a task is currently running. =A0The chec= k >> is against a field in the taskqueue struct, but for the taskqueue_thread >> queue with more than one thread, multiple threads can simultaneously be >> running a task, thus stomping over the tq_running field. >> >> I have not seen any problem with the code as-is in actual use, so this >> is purely an inspection bug. >> >> The following patch should fix the problem. =A0Because it changes the si= ze >> of struct task I'm not sure if it would be suitable for MFC. >> > > 1) The u_char is going to leave a hole in that structure on ARM platforms= for > example. > > 2) The existing taskqueue implementation also has a missing check for the > pending count wrapping to zero. I.E. it should stick at 0xFFFF and not wr= ap to > 0. This commit mail is rather old, and this fix was incorrect, because the task cannot be referenced after it has been run. Some task handlers will free the task as part of the handler. Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 14:22:17 2010 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 D6C80106566B for ; Fri, 12 Nov 2010 14:22:17 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by mx1.freebsd.org (Postfix) with ESMTP id 344668FC16 for ; Fri, 12 Nov 2010 14:22:16 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=4dE6tNKVm/0afO7MQGRPv7y2YwMo4emTIiDjbh74onY= c=1 sm=1 a=WrOSKJTHxIAA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=6I5d2MoRAAAA:8 a=8kQB0OdkAAAA:8 a=cUOH5WmIVjWt6NUKwbwA:9 a=Hed6BA7jrvOL-rD0coUSZYBcI7EA:4 a=wPNLvfGTeEIA:10 a=SV7veod9ZcQA:10 a=9aOQ2cSd83gA: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 48426232; Fri, 12 Nov 2010 15:22:15 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 12 Nov 2010 15:23:17 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <06D5F9F6F655AD4C92E28B662F7F853E039E389A@seaxch09.desktop.isilon.com> <201011120956.04501.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011121523.18044.hselasky@c2i.net> Cc: mdf@freebsd.org Subject: Re: sleep bug in taskqueue(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, 12 Nov 2010 14:22:17 -0000 On Friday 12 November 2010 15:18:46 mdf@freebsd.org wrote: > On Fri, Nov 12, 2010 at 12:56 AM, Hans Petter Selasky wrote: > > On Thursday 29 April 2010 01:59:58 Matthew Fleming wrote: > >> It looks to me like taskqueue_drain(taskqueue_thread, foo) will not > >> correctly detect whether or not a task is currently running. The check > >> is against a field in the taskqueue struct, but for the taskqueue_thread > >> queue with more than one thread, multiple threads can simultaneously be > >> running a task, thus stomping over the tq_running field. > >> > >> I have not seen any problem with the code as-is in actual use, so this > >> is purely an inspection bug. > >> > >> The following patch should fix the problem. Because it changes the size > >> of struct task I'm not sure if it would be suitable for MFC. > > > > 1) The u_char is going to leave a hole in that structure on ARM platforms > > for example. > > > > 2) The existing taskqueue implementation also has a missing check for the > > pending count wrapping to zero. I.E. it should stick at 0xFFFF and not > > wrap to 0. > > This commit mail is rather old, and this fix was incorrect, because > the task cannot be referenced after it has been run. Some task > handlers will free the task as part of the handler. Ok, maybe the e-mail got stuck somewhere. Have you fixed the above mentioned issues in a newer patch? --HPS From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 14:57:27 2010 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 9115E10656A3; Fri, 12 Nov 2010 14:57:27 +0000 (UTC) (envelope-from flo@smeets.im) Received: from mail.solomo.de (mail.solomo.de [IPv6:2a01:238:42c7:9a00::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1E88F8FC1B; Fri, 12 Nov 2010 14:57:27 +0000 (UTC) Received: from mail.solomo.de (localhost [127.0.0.1]) by mail.solomo.de (Postfix) with ESMTP id D83AA5C62; Fri, 12 Nov 2010 15:57:25 +0100 (CET) X-Virus-Scanned: amavisd-new at vistream.de Received: from mail.solomo.de ([127.0.0.1]) by mail.solomo.de (mail.solomo.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5ZZ6DAreOcNU; Fri, 12 Nov 2010 15:57:21 +0100 (CET) Received: from nibbler.vistream.local (relay3.vistream.de [87.139.10.28]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.solomo.de (Postfix) with ESMTPSA id 05C665C61; Fri, 12 Nov 2010 15:57:20 +0100 (CET) Message-ID: <4CDD55D0.10004@smeets.im> Date: Fri, 12 Nov 2010 15:57:20 +0100 From: Florian Smeets User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b3pre Thunderbird/3.1.6 MIME-Version: 1.0 To: Ed Schouten References: <20101111155243.GL2054@hoeg.nl> In-Reply-To: <20101111155243.GL2054@hoeg.nl> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: toolchain@FreeBSD.org, current@FreeBSD.org, sparc64@freebsd.org Subject: Re: libcompiler_rt now part of FreeBSD's base system 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, 12 Nov 2010 14:57:27 -0000 On 11.11.10 16:52, Ed Schouten wrote: > I just committed libcompiler_rt.a to HEAD. Even though I don't expect > serious issues -- especially not on the tier 1 architectures -- be sure > to contact me in case something goes wrong. I hooked it up to the build > in a separate commit, so if your system starts to act weird, just revert > r215127. > Hi Ed, i'm at r215149 on sparc64, and my compiler stopped working. buildworld stops after 42 lines (http://smeets.im/~flo/bw.log). cc1 dumps a 1GB core file. Program terminated with signal 4, Illegal instruction. #0 0x00000000004ced80 in ?? () (gdb) where #0 0x00000000004ced80 in ?? () #1 0x00000000004cedb0 in ?? () Previous frame identical to this frame (corrupt stack?) Right now i cannot go back to r215126 to verify that it really is this change which is causing it :-) Previously the system was running a build from around Nov. 1st Anything i can do to narrow this down? -- Florian Smeets From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 16:01:56 2010 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 0EEB3106564A; Fri, 12 Nov 2010 16:01:56 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 9B3988FC20; Fri, 12 Nov 2010 16:01:55 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id D213C2A28D04; Fri, 12 Nov 2010 17:01:54 +0100 (CET) Date: Fri, 12 Nov 2010 17:01:54 +0100 From: Ed Schouten To: Florian Smeets Message-ID: <20101112160154.GW2054@hoeg.nl> References: <20101111155243.GL2054@hoeg.nl> <4CDD55D0.10004@smeets.im> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qhIxone6Wj/jtFUc" Content-Disposition: inline In-Reply-To: <4CDD55D0.10004@smeets.im> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: toolchain@FreeBSD.org, FreeBSD Current , sparc64@freebsd.org Subject: Re: libcompiler_rt now part of FreeBSD's base system 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, 12 Nov 2010 16:01:56 -0000 --qhIxone6Wj/jtFUc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Florian, others, * Florian Smeets , 20101112 15:57: > i'm at r215149 on sparc64, and my compiler stopped working. buildworld > stops after 42 lines (http://smeets.im/~flo/bw.log). cc1 dumps a 1GB > core file. I'll look into as soon as possible, but to prevent additional breakage, I've switched sparc64 back to the original libgcc. --=20 Ed Schouten WWW: http://80386.nl/ --qhIxone6Wj/jtFUc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkzdZPIACgkQ52SDGA2eCwV1lgCdH3RbqgKyLM5AlbEqIZElJfyD 5OsAnRl+UIcIpJ8OMGwp9bYFNA0LRPb8 =FncD -----END PGP SIGNATURE----- --qhIxone6Wj/jtFUc-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 16:38:40 2010 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 5CCF0106564A for ; Fri, 12 Nov 2010 16:38:40 +0000 (UTC) (envelope-from mdf356@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 116E48FC08 for ; Fri, 12 Nov 2010 16:38:39 +0000 (UTC) Received: by gwj20 with SMTP id 20so1584352gwj.13 for ; Fri, 12 Nov 2010 08:38:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=2QYyZvlkiIbmEfEuzWDjp6GhSSUP90Tt3k6d8hNnjhI=; b=swOZU7jr1bPRQzGqcL88jtftSksZbAeacPMmoB40ZdqnrLI+7vQs4cH7Xx9zz12/vf MCAbWU/2NV6J5vWX9MOV4lHNFqNtWZ/55E/ejKW44CaXYL5cimIift/apD1fEwbDCMv7 pwYQSOQwc8xhP/edVdc+jBtEb+4wXJrCYnNX4= 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=tjpyZi6hOXf9gK89t31bpKv9IJBlq56aqcE77fiNNTZ586Ji1ozPKisXmAjpMS5crD 6ue5x8p6INsNKVmKgCqyXSkDlyd5vZKEcHsMI/6v04qLUQ3SUgd1y5KrnZHOgtXt0LE6 8i9pJdC4TSUQt+PjuPrt9NU2CE2aAv7QCdS9s= MIME-Version: 1.0 Received: by 10.231.156.139 with SMTP id x11mr2246825ibw.22.1289579918775; Fri, 12 Nov 2010 08:38:38 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.231.21.35 with HTTP; Fri, 12 Nov 2010 08:38:38 -0800 (PST) In-Reply-To: <201011121523.18044.hselasky@c2i.net> References: <06D5F9F6F655AD4C92E28B662F7F853E039E389A@seaxch09.desktop.isilon.com> <201011120956.04501.hselasky@c2i.net> <201011121523.18044.hselasky@c2i.net> Date: Fri, 12 Nov 2010 08:38:38 -0800 X-Google-Sender-Auth: TneMxbln8ifCI6N6_2JAkM2Zzi0 Message-ID: From: mdf@FreeBSD.org To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: sleep bug in taskqueue(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, 12 Nov 2010 16:38:40 -0000 On Fri, Nov 12, 2010 at 6:23 AM, Hans Petter Selasky wro= te: > On Friday 12 November 2010 15:18:46 mdf@freebsd.org wrote: >> On Fri, Nov 12, 2010 at 12:56 AM, Hans Petter Selasky > wrote: >> > On Thursday 29 April 2010 01:59:58 Matthew Fleming wrote: >> >> It looks to me like taskqueue_drain(taskqueue_thread, foo) will not >> >> correctly detect whether or not a task is currently running. =A0The c= heck >> >> is against a field in the taskqueue struct, but for the taskqueue_thr= ead >> >> queue with more than one thread, multiple threads can simultaneously = be >> >> running a task, thus stomping over the tq_running field. >> >> >> >> I have not seen any problem with the code as-is in actual use, so thi= s >> >> is purely an inspection bug. >> >> >> >> The following patch should fix the problem. =A0Because it changes the= size >> >> of struct task I'm not sure if it would be suitable for MFC. >> > >> > 1) The u_char is going to leave a hole in that structure on ARM platfo= rms >> > for example. >> > >> > 2) The existing taskqueue implementation also has a missing check for = the >> > pending count wrapping to zero. I.E. it should stick at 0xFFFF and not >> > wrap to 0. >> >> This commit mail is rather old, and this fix was incorrect, because >> the task cannot be referenced after it has been run. =A0Some task >> handlers will free the task as part of the handler. > > Ok, maybe the e-mail got stuck somewhere. Have you fixed the above mentio= ned > issues in a newer patch? If you look at the file history for subr_taskqueue.c: http://svn.freebsd.org/viewvc/base/head/sys/kern/subr_taskqueue.c You will see quite a few commits by me. The most recent relating to detecting if a task is running is being MFC'd today: Revision 213813 - (view) (annotate) - [select for diffs] Modified Wed Oct 13 22:59:04 2010 UTC (4 weeks, 1 day ago) by mdf File length: 10831 byte(s) Diff to previous 213739 Use a safer mechanism for determining if a task is currently running, that does not rely on the lifetime of pointers being the same. This also restores the task KBI. Suggested by: jhb MFC after: 1 month Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 17:25:59 2010 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 8D52F1065672; Fri, 12 Nov 2010 17:25:59 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout024.mac.com (asmtpout024.mac.com [17.148.16.99]) by mx1.freebsd.org (Postfix) with ESMTP id 72E3B8FC1E; Fri, 12 Nov 2010 17:25:59 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from sa-nc-common-155.static.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp024.mac.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTPSA id <0LBS00IXF5MFK090@asmtp024.mac.com>; Fri, 12 Nov 2010 08:25:35 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-11-12_08:2010-11-12, 2010-11-12, 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-1004200000 definitions=main-1011120115 From: Marcel Moolenaar In-reply-to: <20101111155243.GL2054@hoeg.nl> Date: Fri, 12 Nov 2010 08:25:27 -0800 Message-id: <4183CFBE-8C83-4BF1-A7AE-31D701A2DA44@mac.com> References: <20101111155243.GL2054@hoeg.nl> To: Ed Schouten X-Mailer: Apple Mail (2.1081) Cc: toolchain@FreeBSD.org, current@FreeBSD.org Subject: Re: libcompiler_rt now part of FreeBSD's base system 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, 12 Nov 2010 17:25:59 -0000 On Nov 11, 2010, at 7:52 AM, Ed Schouten wrote: > Hello all, > > I just committed libcompiler_rt.a to HEAD. Even though I don't expect > serious issues -- especially not on the tier 1 architectures -- be sure > to contact me in case something goes wrong. I hooked it up to the build > in a separate commit, so if your system starts to act weird, just revert > r215127. I'm testing ia64, right now. I see the following: pluto2# chroot /tank/release/current /bin/tcsh # cd /lib # ls -al *gcc* *compiler* -r--r--r-- 1 0 0 104952 Nov 12 15:55 libgcc_s.so.1 # cd /usr/lib # ls -al *gcc* *compiler* -r--r--r-- 1 0 0 172434 Nov 12 15:53 libcompiler_rt.a -r--r--r-- 1 0 0 209196 Nov 12 15:53 libcompiler_rt_p.a lrwxr-xr-x 1 0 0 16 Nov 12 15:53 libgcc.a -> libcompiler_rt.a -r--r--r-- 1 0 0 60754 Nov 12 15:55 libgcc_eh.a -r--r--r-- 1 0 0 65706 Nov 12 15:55 libgcc_eh_p.a lrwxr-xr-x 1 0 0 18 Nov 12 15:53 libgcc_p.a -> libcompiler_rt_p.a lrwxr-xr-x 1 0 0 18 Nov 12 15:55 libgcc_s.so -> /lib/libgcc_s.so.1 This looks like an inconsistency to me. Aren't we building a shared libcompiler_rt to replace the shared libgcc? Should I worry about the EH support? BTW: The chroot seems functional from the minimal testing I've done so far. We're not DOA! :-) -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 17:58:39 2010 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 D87A8106564A; Fri, 12 Nov 2010 17:58:39 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id C1AE48FC0C; Fri, 12 Nov 2010 17:58:39 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id oACHwdEh027303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 Nov 2010 09:58:39 -0800 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id EE9D81CC13; Fri, 12 Nov 2010 09:58:38 -0800 (PST) To: Lawrence Stewart In-reply-to: Your message of "Fri, 12 Nov 2010 20:35:45 +1100." <4CDD0A71.7020708@freebsd.org> Date: Fri, 12 Nov 2010 09:58:38 -0800 From: "Kevin Oberman" Message-Id: <20101112175838.EE9D81CC13@ptavv.es.net> Cc: freebsd-current@FreeBSD.org Subject: Re: [HEADS UP] Significant TCP work committed to head 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, 12 Nov 2010 17:58:39 -0000 > Date: Fri, 12 Nov 2010 20:35:45 +1100 > From: Lawrence Stewart > Sender: owner-freebsd-current@freebsd.org > > Hi All, > > A quick note that this evening, I made the first in a series of upcoming > commits to head that modify the TCP stack fairly significantly. I have > no reason to believe you'll notice any issues, but TCP is a complex > beast and it's possible things might crop up. The changes are mostly > related to congestion control, so the sorts of issues that are likely to > crop up if any will most probably be subtle and difficult to even > detect. The first svn revision in question is r215166. The next few > commits I plan to make will be basically zero impact and then another > significant patch will follow in a few weeks. > > If you bump into an issue that you think might be related to this work, > please roll back r215166 from your tree and attempt to reporoduce before > reporting the problem. Please CC me directly with your problem report > and post to freebsd-current@ or freebsd-net@ as well. > > Lots more information about what all this does and how to use it will be > following in the coming weeks, but in the meantime, just keep this note > in the back of your mind. For the curious, some information about the > project is available at [1,2]. > > Cheers, > Lawrence > > [1] http://caia.swin.edu.au/freebsd/5cc/ > [2] > http://www.freebsd.org/news/status/report-2010-07-2010-09.html#Five-New-TCP-Congestion-Control-Algorithms-for-FreeBSD Lawrence, Great news! I've been looking forward to having these congestion algorithms for a while and this is clearly a big step to getting there. Do you intend to MFC this for 8.2? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 18:26:27 2010 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 7CD38106564A for ; Fri, 12 Nov 2010 18:26:27 +0000 (UTC) (envelope-from g.veniamin@googlemail.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 0B6A78FC0A for ; Fri, 12 Nov 2010 18:26:26 +0000 (UTC) Received: by eyb7 with SMTP id 7so2046651eyb.13 for ; Fri, 12 Nov 2010 10:26:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=F8p2lZP3wxdGoTwuP+0vrs6G/4Am/LTBdwpObXOjALo=; b=kE8DQJoITfM+b7tbcT0sTg/YV/q+nrhb4D7M7Q86AJvTl1pyqYciUPiQQGMSl4l/6C D9gC4HjTBGheDI475WWKGYJF6bSHBELVqObISywzg6OmLuCxdE8L9QzQLBP15wEEqlYA fOK07reRRPiaiqSYbZAZ2jiWOzmCK2jrxG8l8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=kSPVcsg38hquUxpnIkx4xkWCpUVrFb1idJjblIEYctnRVuwBOupZd6NceXadzx+SO1 zBzHEu7BRtoRn81P/Tbrfue1TWMPWqdHsMC8OtKZvGcq+qwB9y516IvyWJaHPN0npcrc u58+Qyn4YJBnXo9NzLVGBS6j8N9m4mnelsa8c= Received: by 10.213.12.193 with SMTP id y1mr3280139eby.60.1289584669717; Fri, 12 Nov 2010 09:57:49 -0800 (PST) Received: from zlobook.local (zlonet.ru [94.78.205.21]) by mx.google.com with ESMTPS id w20sm3437814eeh.18.2010.11.12.09.57.47 (version=SSLv3 cipher=RC4-MD5); Fri, 12 Nov 2010 09:57:48 -0800 (PST) Message-ID: <4CDD8019.30009@googlemail.com> Date: Sat, 13 Nov 2010 00:57:45 +0700 From: Veniamin Gvozdikov User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; ru; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: MacBookPro7,1 and FreeBSD 8.1 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, 12 Nov 2010 18:26:27 -0000 Hi everybody. I have the macbook and I tryed install FreeBSD 8.1. But I have froze loading. I have it's: with acpi (default loading) http://img203.imageshack.us/img203/2556/dscn2822u.jpg disable acpi http://img152.imageshack.us/img152/1796/dscn2823.jpg verbose mode (option 5 at the boot menu) http://img822.imageshack.us/img822/8069/dscn2825gm.jpg From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 18:36:39 2010 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 606B3106566C; Fri, 12 Nov 2010 18:36: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 224D38FC13; Fri, 12 Nov 2010 18:36:38 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oACIaclG033988; Fri, 12 Nov 2010 13:36:38 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oACIacOi033982; Fri, 12 Nov 2010 18:36:38 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Nov 2010 18:36:38 GMT Message-Id: <201011121836.oACIacOi033982@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: Fri, 12 Nov 2010 18:36:39 -0000 TB --- 2010-11-12 18:36:20 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-12 18:36:20 - starting HEAD tinderbox run for mips/mips TB --- 2010-11-12 18:36:20 - cleaning the object tree TB --- 2010-11-12 18:36:20 - cvsupping the source tree TB --- 2010-11-12 18:36:20 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2010-11-12 18:36:37 - building world TB --- 2010-11-12 18:36:37 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-12 18:36:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-12 18:36:37 - TARGET=mips TB --- 2010-11-12 18:36:37 - TARGET_ARCH=mips TB --- 2010-11-12 18:36:37 - TZ=UTC TB --- 2010-11-12 18:36:37 - __MAKE_CONF=/dev/null TB --- 2010-11-12 18:36:37 - cd /src TB --- 2010-11-12 18:36:37 - /usr/bin/make -B buildworld "/src/Makefile.inc1", line 138: Unknown target mips:mips. *** Error code 1 Stop in /src. TB --- 2010-11-12 18:36:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-12 18:36:38 - ERROR: failed to build world TB --- 2010-11-12 18:36:38 - 2.14 user 7.11 system 17.56 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 18:37:00 2010 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 BF7EB10656C4; Fri, 12 Nov 2010 18:37:00 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 1CCCE8FC17; Fri, 12 Nov 2010 18:36:59 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id oACIMUZM022041; Fri, 12 Nov 2010 19:22:30 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id oACIMTw1022040; Fri, 12 Nov 2010 19:22:29 +0100 (CET) (envelope-from marius) Date: Fri, 12 Nov 2010 19:22:29 +0100 From: Marius Strobl To: Florian Smeets Message-ID: <20101112182229.GA20533@alchemy.franken.de> References: <20101111155243.GL2054@hoeg.nl> <4CDD55D0.10004@smeets.im> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CDD55D0.10004@smeets.im> User-Agent: Mutt/1.4.2.3i Cc: Ed Schouten , sparc64@freebsd.org, current@freebsd.org, toolchain@freebsd.org Subject: Re: libcompiler_rt now part of FreeBSD's base system 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, 12 Nov 2010 18:37:00 -0000 On Fri, Nov 12, 2010 at 03:57:20PM +0100, Florian Smeets wrote: > On 11.11.10 16:52, Ed Schouten wrote: > > I just committed libcompiler_rt.a to HEAD. Even though I don't expect > > serious issues -- especially not on the tier 1 architectures -- be sure > > to contact me in case something goes wrong. I hooked it up to the build > > in a separate commit, so if your system starts to act weird, just revert > > r215127. > > > > Hi Ed, > > i'm at r215149 on sparc64, and my compiler stopped working. buildworld > stops after 42 lines (http://smeets.im/~flo/bw.log). cc1 dumps a 1GB > core file. > > Program terminated with signal 4, Illegal instruction. > #0 0x00000000004ced80 in ?? () > (gdb) where > #0 0x00000000004ced80 in ?? () > #1 0x00000000004cedb0 in ?? () > Previous frame identical to this frame (corrupt stack?) > > Right now i cannot go back to r215126 to verify that it really is this > change which is causing it :-) Previously the system was running a build > from around Nov. 1st > I was just about to report the same based on a test of r214838. With debugging symbols I get a more meaningful though: nimrod# gdb /tmp/objrt.old/usr/home/marius/co/compiler-rt/gnu/usr.bin/cc/cc1/cc1 /tmp/objrt/usr/home/marius/co/compiler-rt/tmp/usr/home/marius/co/compiler-rt/tools/build/cc1.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc64-marcel-freebsd"...(no debugging symbols found)... Core was generated by `cc1'. Program terminated with signal 4, Illegal instruction. #0 0x00000000004c0aa0 in __ctzdi2 () (gdb) bt #0 0x00000000004c0aa0 in __ctzdi2 () #1 0x00000000004c0ad0 in __ctzdi2 () (gdb) The corresponding assembler code is: 00000000004c0aa0 <__ctzdi2>: 4c0aa0: 9d e3 bf 40 save %sp, -192, %sp 4c0aa4: 82 10 00 18 mov %i0, %g1 4c0aa8: 80 a0 00 18 cmp %g0, %i0 4c0aac: 85 3e 30 20 srax %i0, 0x20, %g2 4c0ab0: b0 40 3f ff addc %g0, -1, %i0 4c0ab4: 90 38 00 18 xnor %g0, %i0, %o0 4c0ab8: 84 0e 00 02 and %i0, %g2, %g2 4c0abc: 90 0a 00 01 and %o0, %g1, %o0 4c0ac0: b0 0e 20 20 and %i0, 0x20, %i0 4c0ac4: 90 12 00 02 or %o0, %g2, %o0 4c0ac8: 7f ff ff f6 call 4c0aa0 <__ctzdi2> 4c0acc: 91 32 20 00 srl %o0, 0, %o0 4c0ad0: b0 06 00 08 add %i0, %o0, %i0 4c0ad4: 81 cf e0 08 rett %i7 + 8 4c0ad8: 91 3a 20 00 sra %o0, 0, %o0 4c0adc: 01 00 00 00 nop I think what happens here is that GCC uses __ctzdi2() to implement __builtin_ctz(), while the libcompiler-rt version of __ctzdi2() uses __builtin_ctz(), so __ctzdi2() is called recursively until the stack overflows. Note that GCC has code like: int __ctzsi2 (uSI x) { return __builtin_ctz (x); } and rwindow_save() returns SIGILL, so I think this theory is correct but I've no idea how to solve that. Another thing that worries me is that by switching to libcompiler-rt we lose all the assembler optimizations libgcc has for sparc64. When building with libcompiler-rt the buildworld time increases by 2.6% on sparc64. I guess this mostly is due to the fact that now both libcompiler-rt and libgcc are built though. Do you have an idea how to benchmark the possible performance loss with libcompiler-rt for typical applications? Marius From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 18:47:05 2010 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 74A0A1065670; Fri, 12 Nov 2010 18:47:05 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id 278D58FC21; Fri, 12 Nov 2010 18:47:04 +0000 (UTC) Received: from 62-64-132-95.pool.ukrtel.net ([95.132.64.62] helo=localhost) by fsm1.ukr.net with esmtps ID 1PGyeM-000LF7-9k ; Fri, 12 Nov 2010 20:47:02 +0200 Date: Fri, 12 Nov 2010 20:47:00 +0200 From: Ivan Klymenko To: freebsd-questions@freebsd.org, freebsd-current@freebsd.org Message-ID: <20101112204700.0f51550b@ukr.net> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Kris Moore Subject: Error 1: gpart create -s GPT ad0 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, 12 Nov 2010 18:47:05 -0000 Hello! People. I use the alternate installer pc-sysinstall based on FreeBSD 9.0-CURRENT r215176 When you load the virtual machine qemu disk ad0 is determined by: http://img573.imageshack.us/i/qemu1.png/ but when trying to create a section displays the following error: http://img80.imageshack.us/i/qemu.png/ Think all options for gpart are correct - what can there be a problem? Thanks! From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 19:01:56 2010 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 760A6106566B; Fri, 12 Nov 2010 19:01:56 +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 1516B8FC13; Fri, 12 Nov 2010 19:01:55 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oACJ1tUb010035; Fri, 12 Nov 2010 14:01:55 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oACJ1toC010034; Fri, 12 Nov 2010 19:01:55 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Nov 2010 19:01:55 GMT Message-Id: <201011121901.oACJ1toC010034@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: Fri, 12 Nov 2010 19:01:56 -0000 TB --- 2010-11-12 18:56:34 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-12 18:56:34 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-11-12 18:56:34 - cleaning the object tree TB --- 2010-11-12 18:56:36 - cvsupping the source tree TB --- 2010-11-12 18:56:36 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-11-12 18:57:12 - building world TB --- 2010-11-12 18:57:12 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-12 18:57:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-12 18:57:12 - TARGET=powerpc TB --- 2010-11-12 18:57:12 - TARGET_ARCH=powerpc64 TB --- 2010-11-12 18:57:12 - TZ=UTC TB --- 2010-11-12 18:57:12 - __MAKE_CONF=/dev/null TB --- 2010-11-12 18:57:12 - cd /src TB --- 2010-11-12 18:57:12 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 12 18:57:13 UTC 2010 >>> 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 [...] cc -o rtermcap /src/usr.sbin/sysinstall/rtermcap.c -ltermcap ===> gnu/usr.bin/cc/cc_tools (obj,depend,all) LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-gather.awk /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/c.opt /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/common.opt /src/gnu/usr.bin/cc/cc_tools/freebsd.opt > optionlist LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-functions.awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opth-gen.awk < optionlist > options.h LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-functions.awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/optc-gen.awk -v header_name="config.h system.h coretypes.h tm.h" < optionlist > options.c TARGET_CPU_DEFAULT="\"powerpc64\"" HEADERS="auto-host.h ansidecl.h" DEFINES="" /bin/sh /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/mkconfig.sh bconfig.h TARGET_CPU_DEFAULT="\"powerpc64\"" HEADERS="options.h rs600064/rs600064.h dbxelf.h elfos-undef.h elfos.h freebsd-native.h freebsd-spec.h freebsd.h rs600064/biarch64.h rs600064/default64.h rs600064/freebsd.h defaults.h" DEFINES="" /bin/sh /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/mkconfig.sh tm.h make: don't know how to make /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config/rs600064/rs600064.c. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-12 19:01:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-12 19:01:55 - ERROR: failed to build world TB --- 2010-11-12 19:01:55 - 205.91 user 53.91 system 320.29 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 20:24:49 2010 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 AC60C10656C9; Fri, 12 Nov 2010 20:24:49 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 0892A8FC08; Fri, 12 Nov 2010 20:24:48 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=omSrwDgyMf70S47Fr5SNr0rQzcmIOo0IafWlB/wSLLo= c=1 sm=1 a=WrOSKJTHxIAA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=6I5d2MoRAAAA:8 a=8kQB0OdkAAAA:8 a=gAC1W530OKRNHEib3a0A:9 a=k-Ta0indbs3rS3vNmGxkMflgXVgA:4 a=wPNLvfGTeEIA:10 a=SV7veod9ZcQA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 49134547; Fri, 12 Nov 2010 21:24:46 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 12 Nov 2010 21:25:47 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <06D5F9F6F655AD4C92E28B662F7F853E039E389A@seaxch09.desktop.isilon.com> <201011121523.18044.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011122125.47922.hselasky@c2i.net> Cc: mdf@freebsd.org Subject: Re: sleep bug in taskqueue(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, 12 Nov 2010 20:24:49 -0000 On Friday 12 November 2010 17:38:38 mdf@freebsd.org wrote: > On Fri, Nov 12, 2010 at 6:23 AM, Hans Petter Selasky wrote: > > On Friday 12 November 2010 15:18:46 mdf@freebsd.org wrote: > >> On Fri, Nov 12, 2010 at 12:56 AM, Hans Petter Selasky > > > > wrote: > >> > On Thursday 29 April 2010 01:59:58 Matthew Fleming wrote: > >> >> It looks to me like taskqueue_drain(taskqueue_thread, foo) will not > >> >> correctly detect whether or not a task is currently running. The > >> >> check is against a field in the taskqueue struct, but for the > >> >> taskqueue_thread queue with more than one thread, multiple threads > >> >> can simultaneously be running a task, thus stomping over the > >> >> tq_running field. > >> >> > >> >> I have not seen any problem with the code as-is in actual use, so > >> >> this is purely an inspection bug. > >> >> > >> >> The following patch should fix the problem. Because it changes the > >> >> size of struct task I'm not sure if it would be suitable for MFC. > >> > > >> > 1) The u_char is going to leave a hole in that structure on ARM > >> > platforms for example. > >> > > >> > 2) The existing taskqueue implementation also has a missing check for > >> > the pending count wrapping to zero. I.E. it should stick at 0xFFFF > >> > and not wrap to 0. > >> > >> This commit mail is rather old, and this fix was incorrect, because > >> the task cannot be referenced after it has been run. Some task > >> handlers will free the task as part of the handler. > > > > Ok, maybe the e-mail got stuck somewhere. Have you fixed the above > > mentioned issues in a newer patch? > > If you look at the file history for subr_taskqueue.c: > > http://svn.freebsd.org/viewvc/base/head/sys/kern/subr_taskqueue.c > > You will see quite a few commits by me. The most recent relating to > detecting if a task is running is being MFC'd today: Yes, and I see that this code needs an overflow check, which is one of the issues still not fixed: Before: /* * Count multiple enqueues. */ if (task->ta_pending) { task->ta_pending++; TQ_UNLOCK(queue); return 0; } After: /* * Count multiple enqueues. */ if (task->ta_pending) { if (task->ta_pending != 0xFFFF) task->ta_pending++; TQ_UNLOCK(queue); return 0; } Else the ta_pending can wrap to zero and the code will not do what it announces it does. --HPS From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 20:32:23 2010 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 019B41065675 for ; Fri, 12 Nov 2010 20:32:23 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.swip.net [212.247.154.65]) by mx1.freebsd.org (Postfix) with ESMTP id 8827E8FC14 for ; Fri, 12 Nov 2010 20:32:22 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=iBCGAMPDYtSF9sDXX85uHY3wcnYctfVT8vFpe3qPflY= c=1 sm=1 a=CSu41JAXLW0A:10 a=IkcTkHD0fZMA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=p6EGUZYCAAAA:20 a=B_LHE_dpAAAA:20 a=1Yw9oJTAAAAA:20 a=TYkW9fTRee4fKu3c0VoA:9 a=7EJkcC6tYPXxahRc74QA:7 a=z8NL5oJKDiKBUeZyOvGof1HDzvQA:4 a=QEXdDO2ut3YA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 48543427 for freebsd-current@freebsd.org; Fri, 12 Nov 2010 21:32:21 +0100 To: freebsd-current@freebsd.org From: Hans Petter Selasky X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?utf-8?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?utf-8?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7CoTlKM?= =?utf-8?q?usi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' Date: Fri, 12 Nov 2010 21:33:23 +0100 MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201011122133.23061.hselasky@c2i.net> Subject: Re: MacBookPro7,1 and FreeBSD 8.1 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, 12 Nov 2010 20:32:23 -0000 On Friday 12 November 2010 18:28:02 Veniamin Gvozdikov wrote: > Hi everybody. > I have the macbook and I tryed install FreeBSD 8.1. But I have froze > loading. > > I have it's: > with acpi (default loading) > http://img203.imageshack.us/img203/2556/dscn2822u.jpg > > disable acpi > http://img152.imageshack.us/img152/1796/dscn2823.jpg > > verbose mode (option 5 at the boot menu) > http://img822.imageshack.us/img822/8069/dscn2825gm.jpg This might be because your model is not listed in a quirk-table: grep -ri macbook /usr/src/sys/amd64 /usr/src/sys/amd64/amd64/machdep.c --HPS From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 20:33:54 2010 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 495821065670 for ; Fri, 12 Nov 2010 20:33:54 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id D56848FC25 for ; Fri, 12 Nov 2010 20:33:53 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 1005B2A28D04; Fri, 12 Nov 2010 21:33:53 +0100 (CET) Date: Fri, 12 Nov 2010 21:33:53 +0100 From: Ed Schouten To: Hans Petter Selasky Message-ID: <20101112203353.GY2054@hoeg.nl> References: <4CDD8019.30009@googlemail.com> <201011122133.23061.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QwxUbhVDsLnptIHF" Content-Disposition: inline In-Reply-To: <201011122133.23061.hselasky@c2i.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: MacBookPro7,1 and FreeBSD 8.1 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, 12 Nov 2010 20:33:54 -0000 --QwxUbhVDsLnptIHF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Hans Petter Selasky , 20101112 21:33: > This might be because your model is not listed in a quirk-table: >=20 > grep -ri macbook /usr/src/sys/amd64 >=20 > /usr/src/sys/amd64/amd64/machdep.c If only we could live without that hack... I remember we once did this for all MacBooks, no specific revision whatsoever. --=20 Ed Schouten WWW: http://80386.nl/ --QwxUbhVDsLnptIHF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkzdpLEACgkQ52SDGA2eCwWabQCfeCAoeZBRlA1Nt+GluhqXGMCA h1EAn3LS5iOFhmWs6GY9vX734FYkV/7z =8Ip3 -----END PGP SIGNATURE----- --QwxUbhVDsLnptIHF-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 21:24:53 2010 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 2CEB91065679 for ; Fri, 12 Nov 2010 21:24:53 +0000 (UTC) (envelope-from mdf356@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 E36AF8FC0A for ; Fri, 12 Nov 2010 21:24:52 +0000 (UTC) Received: by iwn39 with SMTP id 39so3948105iwn.13 for ; Fri, 12 Nov 2010 13:24:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=YD4wAfraGyxyAwVUI6dSdJcg5dVZaVj1zom/31DoagU=; b=BS0533Y0t7+iRD9am5JiHdzOoXcMlusQoQHUuCh19b2qFydCFpPYk2D6nlX3u0kvnY 6Zc+kwFF+BsXCn75oOzYf6d+EjpuQdgcUnd6KbNPu4hqgNWK0rZ1wpOCKQyT8egdVjuh kbfZLEHVdV0il9xqN+A4tLbOYJ02dimv+Jd48= 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=Dv7Cn+I2UOqFYDv9PaxagUMNXOv42cz2qqKxrSXxkmkDUxriv1Lc980i1QGFjEBvWG vb6zM5QZ/47U8QW6fs9prkVo8YUhM5d+P5ZC68xuhB3HY09oikO5TGlTy9PXCqIAT00S zUgItPCrfPyHpcz+TiYhErRirwplRKPmmZPHY= MIME-Version: 1.0 Received: by 10.42.171.66 with SMTP id i2mr2329810icz.460.1289597091321; Fri, 12 Nov 2010 13:24:51 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.231.21.35 with HTTP; Fri, 12 Nov 2010 13:24:51 -0800 (PST) In-Reply-To: <201011122125.47922.hselasky@c2i.net> References: <06D5F9F6F655AD4C92E28B662F7F853E039E389A@seaxch09.desktop.isilon.com> <201011121523.18044.hselasky@c2i.net> <201011122125.47922.hselasky@c2i.net> Date: Fri, 12 Nov 2010 13:24:51 -0800 X-Google-Sender-Auth: Ie0CsD7lr9zj3aJpzSEBphwIHAw Message-ID: From: mdf@FreeBSD.org To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: sleep bug in taskqueue(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, 12 Nov 2010 21:24:53 -0000 On Fri, Nov 12, 2010 at 12:25 PM, Hans Petter Selasky wr= ote: > On Friday 12 November 2010 17:38:38 mdf@freebsd.org wrote: >> On Fri, Nov 12, 2010 at 6:23 AM, Hans Petter Selasky > wrote: >> > On Friday 12 November 2010 15:18:46 mdf@freebsd.org wrote: >> >> On Fri, Nov 12, 2010 at 12:56 AM, Hans Petter Selasky >> > >> > wrote: >> >> > On Thursday 29 April 2010 01:59:58 Matthew Fleming wrote: >> >> >> It looks to me like taskqueue_drain(taskqueue_thread, foo) will no= t >> >> >> correctly detect whether or not a task is currently running. =A0Th= e >> >> >> check is against a field in the taskqueue struct, but for the >> >> >> taskqueue_thread queue with more than one thread, multiple threads >> >> >> can simultaneously be running a task, thus stomping over the >> >> >> tq_running field. >> >> >> >> >> >> I have not seen any problem with the code as-is in actual use, so >> >> >> this is purely an inspection bug. >> >> >> >> >> >> The following patch should fix the problem. =A0Because it changes = the >> >> >> size of struct task I'm not sure if it would be suitable for MFC. >> >> > >> >> > 1) The u_char is going to leave a hole in that structure on ARM >> >> > platforms for example. >> >> > >> >> > 2) The existing taskqueue implementation also has a missing check f= or >> >> > the pending count wrapping to zero. I.E. it should stick at 0xFFFF >> >> > and not wrap to 0. >> >> >> >> This commit mail is rather old, and this fix was incorrect, because >> >> the task cannot be referenced after it has been run. =A0Some task >> >> handlers will free the task as part of the handler. >> > >> > Ok, maybe the e-mail got stuck somewhere. Have you fixed the above >> > mentioned issues in a newer patch? >> >> If you look at the file history for subr_taskqueue.c: >> >> http://svn.freebsd.org/viewvc/base/head/sys/kern/subr_taskqueue.c >> >> You will see quite a few commits by me. =A0The most recent relating to >> detecting if a task is running is being MFC'd today: > > Yes, and I see that this code needs an overflow check, which is one of th= e > issues still not fixed: You keep bringing this up. It is not a new issue. It is not a bug in any of the patches. It is extremely unlikely that a task will be queued 65536 times before execution. It is more worthy of an assert rather than a check, because if a task is enqueued that many times without being run then there's likely a stuck task in the queue. The patch you posted will lie as well, so I would not consider it sufficient if someone wanted to address the issue. Thanks, matthew > > Before: > > =A0 =A0 =A0 =A0/* > =A0 =A0 =A0 =A0 * Count multiple enqueues. > =A0 =A0 =A0 =A0 */ > =A0 =A0 =A0 =A0if (task->ta_pending) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0task->ta_pending++; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0TQ_UNLOCK(queue); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return 0; > =A0 =A0 =A0 =A0} > > > After: > > =A0 =A0 =A0 =A0/* > =A0 =A0 =A0 =A0 * Count multiple enqueues. > =A0 =A0 =A0 =A0 */ > =A0 =A0 =A0 =A0if (task->ta_pending) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (task->ta_pending !=3D 0xFFFF) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0task->ta_pending++; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0TQ_UNLOCK(queue); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return 0; > =A0 =A0 =A0 =A0} > > Else the ta_pending can wrap to zero and the code will not do what it > announces it does. > > --HPS > From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 21:31:02 2010 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 90C6E1065693; Fri, 12 Nov 2010 21:31:02 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.swip.net [212.247.154.65]) by mx1.freebsd.org (Postfix) with ESMTP id C93B48FC1E; Fri, 12 Nov 2010 21:30:59 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=iBCGAMPDYtSF9sDXX85uHY3wcnYctfVT8vFpe3qPflY= c=1 sm=1 a=WrOSKJTHxIAA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=6I5d2MoRAAAA:8 a=8kQB0OdkAAAA:8 a=PiGfvTupYdVhF0xfVjIA:9 a=OzW2NldnKsWvCzN3wavqk1pPJkAA:4 a=wPNLvfGTeEIA:10 a=SV7veod9ZcQA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 48558525; Fri, 12 Nov 2010 22:30:58 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 12 Nov 2010 22:31:58 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <06D5F9F6F655AD4C92E28B662F7F853E039E389A@seaxch09.desktop.isilon.com> <201011122125.47922.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011122231.58779.hselasky@c2i.net> Cc: mdf@freebsd.org Subject: Re: sleep bug in taskqueue(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, 12 Nov 2010 21:31:02 -0000 On Friday 12 November 2010 22:24:51 mdf@freebsd.org wrote: > On Fri, Nov 12, 2010 at 12:25 PM, Hans Petter Selasky wrote: > > On Friday 12 November 2010 17:38:38 mdf@freebsd.org wrote: > >> On Fri, Nov 12, 2010 at 6:23 AM, Hans Petter Selasky > > > > wrote: > >> > On Friday 12 November 2010 15:18:46 mdf@freebsd.org wrote: > >> >> On Fri, Nov 12, 2010 at 12:56 AM, Hans Petter Selasky > >> >> > >> > > >> > wrote: > >> >> > On Thursday 29 April 2010 01:59:58 Matthew Fleming wrote: > >> >> >> It looks to me like taskqueue_drain(taskqueue_thread, foo) will > >> >> >> not correctly detect whether or not a task is currently running. > >> >> >> The check is against a field in the taskqueue struct, but for > >> >> >> the taskqueue_thread queue with more than one thread, multiple > >> >> >> threads can simultaneously be running a task, thus stomping over > >> >> >> the tq_running field. > >> >> >> > >> >> >> I have not seen any problem with the code as-is in actual use, so > >> >> >> this is purely an inspection bug. > >> >> >> > >> >> >> The following patch should fix the problem. Because it changes > >> >> >> the size of struct task I'm not sure if it would be suitable for > >> >> >> MFC. > >> >> > > >> >> > 1) The u_char is going to leave a hole in that structure on ARM > >> >> > platforms for example. > >> >> > > >> >> > 2) The existing taskqueue implementation also has a missing check > >> >> > for the pending count wrapping to zero. I.E. it should stick at > >> >> > 0xFFFF and not wrap to 0. > >> >> > >> >> This commit mail is rather old, and this fix was incorrect, because > >> >> the task cannot be referenced after it has been run. Some task > >> >> handlers will free the task as part of the handler. > >> > > >> > Ok, maybe the e-mail got stuck somewhere. Have you fixed the above > >> > mentioned issues in a newer patch? > >> > >> If you look at the file history for subr_taskqueue.c: > >> > >> http://svn.freebsd.org/viewvc/base/head/sys/kern/subr_taskqueue.c > >> > >> You will see quite a few commits by me. The most recent relating to > > > >> detecting if a task is running is being MFC'd today: > > Yes, and I see that this code needs an overflow check, which is one of > > the > > > issues still not fixed: > You keep bringing this up. It is not a new issue. It is not a bug in > any of the patches. It is extremely unlikely that a task will be > queued 65536 times before execution. It is more worthy of an assert > rather than a check, because if a task is enqueued that many times > without being run then there's likely a stuck task in the queue. > > The patch you posted will lie as well, so I would not consider it > sufficient if someone wanted to address the issue. In the USB world, many of the taskqueue enqueue calls result directly from IOCTL's, so I consider this a real issue! --HPS From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 22:37:15 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 262611065670; Fri, 12 Nov 2010 22:37:15 +0000 (UTC) Date: Fri, 12 Nov 2010 22:37:15 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20101112223715.GA1356@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: www/chromium crashing whole system 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, 12 Nov 2010 22:37:15 -0000 hi there, i'm having an issue with www/chromium. sometimes it will completely lock up my system without producing a core dump. i'm running HEAD (r215102; amd64). this time however chrome.core made it to disk somehow: Core was generated by `chrome'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libX11.so.6...done. Loaded symbols for /usr/local/lib/libX11.so.6 Reading symbols from /usr/local/lib/libXrender.so.1...done. Loaded symbols for /usr/local/lib/libXrender.so.1 Reading symbols from /usr/local/lib/libXss.so.1...done. Loaded symbols for /usr/local/lib/libXss.so.1 Reading symbols from /usr/local/lib/libXext.so.6...done. Loaded symbols for /usr/local/lib/libXext.so.6 Reading symbols from /usr/local/lib/libexecinfo.so.1...done. Loaded symbols for /usr/local/lib/libexecinfo.so.1 Reading symbols from /usr/local/lib/libgtk-x11-2.0.so.0...done. Loaded symbols for /usr/local/lib/libgtk-x11-2.0.so.0 Reading symbols from /usr/local/lib/libgdk-x11-2.0.so.0...done. Loaded symbols for /usr/local/lib/libgdk-x11-2.0.so.0 Reading symbols from /usr/local/lib/libatk-1.0.so.0...done. Loaded symbols for /usr/local/lib/libatk-1.0.so.0 Reading symbols from /usr/local/lib/libgdk_pixbuf-2.0.so.0...done. Loaded symbols for /usr/local/lib/libgdk_pixbuf-2.0.so.0 Reading symbols from /usr/local/lib/libpangocairo-1.0.so.0...done. Loaded symbols for /usr/local/lib/libpangocairo-1.0.so.0 Reading symbols from /usr/local/lib/libXinerama.so.1...done. Loaded symbols for /usr/local/lib/libXinerama.so.1 Reading symbols from /usr/local/lib/libXi.so.6...done. Loaded symbols for /usr/local/lib/libXi.so.6 Reading symbols from /usr/local/lib/libXrandr.so.2...done. Loaded symbols for /usr/local/lib/libXrandr.so.2 Reading symbols from /usr/local/lib/libXcursor.so.1...done. Loaded symbols for /usr/local/lib/libXcursor.so.1 Reading symbols from /usr/local/lib/libXcomposite.so.1...done. Loaded symbols for /usr/local/lib/libXcomposite.so.1 Reading symbols from /usr/local/lib/libXdamage.so.1...done. Loaded symbols for /usr/local/lib/libXdamage.so.1 Reading symbols from /usr/local/lib/libpangoft2-1.0.so.0...done. Loaded symbols for /usr/local/lib/libpangoft2-1.0.so.0 Reading symbols from /usr/local/lib/libgio-2.0.so.0...done. Loaded symbols for /usr/local/lib/libgio-2.0.so.0 Reading symbols from /usr/local/lib/libXfixes.so.3...done. Loaded symbols for /usr/local/lib/libXfixes.so.3 Reading symbols from /usr/local/lib/libcairo.so.2...done. Loaded symbols for /usr/local/lib/libcairo.so.2 Reading symbols from /usr/local/lib/libpango-1.0.so.0...done. Loaded symbols for /usr/local/lib/libpango-1.0.so.0 Reading symbols from /lib/libm.so.5...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /usr/local/lib/libfreetype.so.9...done. Loaded symbols for /usr/local/lib/libfreetype.so.9 Reading symbols from /usr/local/lib/libfontconfig.so.1...done. Loaded symbols for /usr/local/lib/libfontconfig.so.1 Reading symbols from /usr/local/lib/libgobject-2.0.so.0...done. Loaded symbols for /usr/local/lib/libgobject-2.0.so.0 Reading symbols from /usr/local/lib/libgmodule-2.0.so.0...done. Loaded symbols for /usr/local/lib/libgmodule-2.0.so.0 Reading symbols from /usr/local/lib/libgthread-2.0.so.0...done. Loaded symbols for /usr/local/lib/libgthread-2.0.so.0 Reading symbols from /usr/local/lib/libglib-2.0.so.0...done. Loaded symbols for /usr/local/lib/libglib-2.0.so.0 Reading symbols from /usr/local/lib/nss/libnss3.so.1...done. Loaded symbols for /usr/local/lib/nss/libnss3.so.1 Reading symbols from /usr/local/lib/nss/libsmime3.so.1...done. Loaded symbols for /usr/local/lib/nss/libsmime3.so.1 Reading symbols from /usr/local/lib/nss/libnssutil3.so.1...done. Loaded symbols for /usr/local/lib/nss/libnssutil3.so.1 Reading symbols from /usr/local/lib/libplds4.so.1...done. Loaded symbols for /usr/local/lib/libplds4.so.1 Reading symbols from /usr/local/lib/libplc4.so.1...done. Loaded symbols for /usr/local/lib/libplc4.so.1 Reading symbols from /usr/local/lib/libnspr4.so.1...done. Loaded symbols for /usr/local/lib/libnspr4.so.1 Reading symbols from /lib/libz.so.6...done. Loaded symbols for /lib/libz.so.6 Reading symbols from /usr/local/lib/libjpeg.so.11...done. Loaded symbols for /usr/local/lib/libjpeg.so.11 Reading symbols from /usr/local/lib/libpng.so.6...done. Loaded symbols for /usr/local/lib/libpng.so.6 Reading symbols from /usr/local/lib/libgconf-2.so.4...done. Loaded symbols for /usr/local/lib/libgconf-2.so.4 Reading symbols from /usr/local/lib/libxml2.so.5...done. Loaded symbols for /usr/local/lib/libxml2.so.5 Reading symbols from /usr/local/lib/libexpat.so.6...done. Loaded symbols for /usr/local/lib/libexpat.so.6 Reading symbols from /usr/local/lib/libasound.so.2...done. Loaded symbols for /usr/local/lib/libasound.so.2 Reading symbols from /usr/lib/libbz2.so.4...done. Loaded symbols for /usr/lib/libbz2.so.4 Reading symbols from /usr/local/lib/libdbus-glib-1.so.2...done. Loaded symbols for /usr/local/lib/libdbus-glib-1.so.2 Reading symbols from /usr/local/lib/libdbus-1.so.3...done. Loaded symbols for /usr/local/lib/libdbus-1.so.3 Reading symbols from /usr/lib/libstdc++.so.6...done. Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/libthr.so.3...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/local/lib/libxcb.so.2...done. Loaded symbols for /usr/local/lib/libxcb.so.2 Reading symbols from /usr/local/lib/libXau.so.6...done. Loaded symbols for /usr/local/lib/libXau.so.6 Reading symbols from /usr/local/lib/libXdmcp.so.6...done. Loaded symbols for /usr/local/lib/libXdmcp.so.6 Reading symbols from /usr/local/lib/libpthread-stubs.so.0...done. Loaded symbols for /usr/local/lib/libpthread-stubs.so.0 Reading symbols from /usr/lib/librpcsvc.so.5...done. Loaded symbols for /usr/lib/librpcsvc.so.5 Reading symbols from /usr/local/lib/libpixman-1.so.9...done. Loaded symbols for /usr/local/lib/libpixman-1.so.9 Reading symbols from /usr/local/lib/libglitz.so.1...done. Loaded symbols for /usr/local/lib/libglitz.so.1 Reading symbols from /usr/local/lib/libxcb-render-util.so.0...done. Loaded symbols for /usr/local/lib/libxcb-render-util.so.0 Reading symbols from /usr/local/lib/libxcb-render.so.0...done. Loaded symbols for /usr/local/lib/libxcb-render.so.0 Reading symbols from /usr/local/lib/libintl.so.9...done. Loaded symbols for /usr/local/lib/libintl.so.9 Reading symbols from /usr/local/lib/libiconv.so.3...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /usr/local/lib/libpcre.so.0...done. Loaded symbols for /usr/local/lib/libpcre.so.0 Reading symbols from /usr/local/lib/libORBit-2.so.0...done. Loaded symbols for /usr/local/lib/libORBit-2.so.0 Reading symbols from /lib/libgcc_s.so.1...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /usr/local/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so...done. Loaded symbols for /usr/local/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so Reading symbols from /usr/local/lib/pango/1.6.0/modules/pango-basic-fc.so...done. Loaded symbols for /usr/local/lib/pango/1.6.0/modules/pango-basic-fc.so Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x00000008026d76a2 in symlook_default (name=0x806797dbc "__sys_sigreturn", hash=92647454, refobj=0x802722c00, defobj_out=0x7fffffbfe160, ventry=0x802717790, flags=1) at /usr/src/libexec/rtld-elf/rtld.c:2675 2675 symp = symlook_list(name, hash, &list_main, &obj, ventry, flags, [New Thread 2ee6b40 (LWP 100245)] [New Thread 2ee6000 (LWP 100212)] (gdb) bt #0 0x00000008026d76a2 in symlook_default (name=0x806797dbc "__sys_sigreturn", hash=92647454, refobj=0x802722c00, defobj_out=0x7fffffbfe160, ventry=0x802717790, flags=1) at /usr/src/libexec/rtld-elf/rtld.c:2675 #1 0x00000008026d815c in find_symdef (symnum=217, refobj=0x802722c00, defobj_out=0x7fffffbfe1a8, flags=1, cache=0x0) at /usr/src/libexec/rtld-elf/rtld.c:1205 #2 0x00000008026d8233 in _rtld_bind (obj=0x802722c00, reloff=Variable "reloff" is not available. ) at /usr/src/libexec/rtld-elf/rtld.c:557 #3 0x00000008026d487d in _rtld_bind_start () at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:99 #4 0xffffffff91969eb2 in ?? () #5 0x0000000000000000 in ?? () #6 0x0000000000000000 in ?? () #7 0xfffffffffffffbd0 in ?? () #8 0x00007fffffbfe260 in ?? () #9 0x00007fffffbfe260 in ?? () #10 0x0000000000000000 in ?? () #11 0x0000000002ee6000 in ?? () #12 0x0000000002ee6cb8 in ?? () #13 0x0000000000000206 in ?? () #14 0x0000000000000000 in ?? () #15 0x0000000802722c00 in ?? () #16 0x0000000000000024 in ?? () #17 0x000000080679fc26 in handle_signal (actp=Variable "actp" is not available. ) at /usr/src/lib/libthr/thread/thr_sig.c:254 #18 0x000000080679fd5f in thr_sighandler (sig=20, info=0x7fffffbfea00, _ucp=0x7fffffbfe690) at /usr/src/lib/libthr/thread/thr_sig.c:181 #19 #20 0x00000008069cad6c in read () at read.S:3 #21 0x000000080679dc70 in __read (fd=15, buf=0x7fffffbfef84, nbytes=4) at /usr/src/lib/libthr/thread/thr_syscalls.c:460 #22 0x000000000043871f in (anonymous namespace)::ShutdownDetector::ThreadMain () #23 0x0000000000984caa in ThreadFunc () #24 0x000000080679b81e in thread_start (curthread=0x2ee6b40) at /usr/src/lib/libthr/thread/thr_create.c:273 #25 0x0000000000000000 in ?? () Cannot access memory at address 0x7fffffbff000 cheers. alex -- a13x From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 00:54:53 2010 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 480271065696 for ; Sat, 13 Nov 2010 00:54:53 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 09F228FC0C for ; Sat, 13 Nov 2010 00:54:53 +0000 (UTC) Received: from lawrence1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 9C2D97E853; Sat, 13 Nov 2010 11:54:51 +1100 (EST) Message-ID: <4CDDE1DB.3010007@freebsd.org> Date: Sat, 13 Nov 2010 11:54:51 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-AU; rv:1.9.2.9) Gecko/20101006 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Kevin Oberman References: <20101112175838.EE9D81CC13@ptavv.es.net> In-Reply-To: <20101112175838.EE9D81CC13@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lauren.room52.net Cc: freebsd-current@freebsd.org Subject: Re: [HEADS UP] Significant TCP work committed to head 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, 13 Nov 2010 00:54:53 -0000 On 11/13/10 04:58, Kevin Oberman wrote: >> Date: Fri, 12 Nov 2010 20:35:45 +1100 >> From: Lawrence Stewart >> Sender: owner-freebsd-current@freebsd.org >> >> Hi All, >> >> A quick note that this evening, I made the first in a series of upcoming >> commits to head that modify the TCP stack fairly significantly. I have >> no reason to believe you'll notice any issues, but TCP is a complex >> beast and it's possible things might crop up. The changes are mostly >> related to congestion control, so the sorts of issues that are likely to >> crop up if any will most probably be subtle and difficult to even >> detect. The first svn revision in question is r215166. The next few >> commits I plan to make will be basically zero impact and then another >> significant patch will follow in a few weeks. >> >> If you bump into an issue that you think might be related to this work, >> please roll back r215166 from your tree and attempt to reporoduce before >> reporting the problem. Please CC me directly with your problem report >> and post to freebsd-current@ or freebsd-net@ as well. >> >> Lots more information about what all this does and how to use it will be >> following in the coming weeks, but in the meantime, just keep this note >> in the back of your mind. For the curious, some information about the >> project is available at [1,2]. >> >> Cheers, >> Lawrence >> >> [1] http://caia.swin.edu.au/freebsd/5cc/ >> [2] >> http://www.freebsd.org/news/status/report-2010-07-2010-09.html#Five-New-TCP-Congestion-Control-Algorithms-for-FreeBSD > > Lawrence, > > Great news! I've been looking forward to having these congestion > algorithms for a while and this is clearly a big step to getting there. HTCP and CUBIC should become available next week (the zero impact commits I mentioned in my email above) and then a chunk of additional infrastructure is needed in order to add our delay based algorithm modules to the tree. We anticipate having all the code in head by the time Christmas rolls around assuming no major issues crop up. > Do you intend to MFC this for 8.2? No. I wouldn't feel comfortable unleashing this on people with only 2 weeks of soak time in head. The current MFC schedule is 3 months from yesterday, so it will be in stable/8 and hopefully stable/7 as well shortly after 8.2 and 7.4 are released. Cheers, Lawrence From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 02:11:10 2010 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 4B288106566B; Sat, 13 Nov 2010 02:11:10 +0000 (UTC) (envelope-from jamesbrandongooch@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 AC4278FC0A; Sat, 13 Nov 2010 02:11:09 +0000 (UTC) Received: by wyb36 with SMTP id 36so605654wyb.13 for ; Fri, 12 Nov 2010 18:11:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=XTZtD7hKiaN8YOXPK3hT+aftPBaAHfLBCbTu3Tf4Keo=; b=oC5Ztad57ScrtV0Dv8/CGBiHVwCqTyM0HZc6lVQtqtMYd5zWQ7kTMllCOtElG4BKsl xcuEgga2bMLYj4hH+uTLBQxuf1eMFFcllTz/oNwLV8zHjMsaiS5TBI8/S/8fpnQr1Bzd d4hIw8PmDv6G6gNTLiG91IkCAzp/xIaJRWgHM= 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=Y4qttIXt0J2ILt/McwctD1RAMO5KOolgNHQfvhqkmrykZqd/U9QrgOTp0p3E7xagLA Bw5i8N5IriEatVYIF3xeIRA2a4GIusi5su3ukQ4N5ET/ltOF2eh3+DRfSQ+JBRFZ9XAp DMRfgfHKCeK6/CxChKs/eVkxlY6Y/mn1xch9A= MIME-Version: 1.0 Received: by 10.216.171.75 with SMTP id q53mr2596431wel.74.1289612661936; Fri, 12 Nov 2010 17:44:21 -0800 (PST) Received: by 10.216.12.80 with HTTP; Fri, 12 Nov 2010 17:44:21 -0800 (PST) In-Reply-To: <4CD45209.5010607@FreeBSD.org> References: <4CD45209.5010607@FreeBSD.org> Date: Fri, 12 Nov 2010 19:44:21 -0600 Message-ID: From: Brandon Gooch To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-scsi@freebsd.org, FreeBSD-Current , FreeBSD Stable Subject: Re: Sense fetching [Was: cdrtools /devel ...] 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, 13 Nov 2010 02:11:10 -0000 2010/11/5 Alexander Motin : > Hi. > > I've reviewed tests that scgcheck does to SCSI subsystem. It shown > combination of several issues in both CAM, ahci(4) and cdrtools itself. > Several small patches allow us to pass most of that tests: > http://people.freebsd.org/~mav/sense/ > > ahci_resid.patch: Add support for reporting residual length on data > underrun. SCSI commands often returns results shorter then expected. > Returned value allows application to know/check how much data it really > has. It is also important for sense fetching, as ATAPI and USB devices > return sense as data in response to REQUEST_SENSE command. > > sense_resid.patch: When manually requesting sense data (ATAPI or USB), > request only as much data as user requested (not the fixed structure > size), and return respective sense residual length. > > pass_autosence.patch: Unless CAM_DIS_AUTOSENSE is set, always fetch > sense if not done by SIM, independently of CAM_PASS_ERR_RECOVER. As soon > as device freeze released before returning to user-level, user-level > application by definition can't reliably fetch sense data if some other > application (like hald) tries to access device same time. > > cdrtools.patch: Make libscg (part of cdrtools) on FreeBSD to submit > wanted sense length to CAM and do not clear sense return buffer. It is > mostly cosmetics, important probably only for scgcheck. > > Testers and reviewers welcome. I am especially interested in opinion > about pass_autosence.patch -- may be we should lower sense fetching even > deeper, to make it work for all cam_periph_runccb() consumers. > Hey mav, sorry to chime in after so long here, but have some of these patches been committed (as of r215179)? Which patches are still applicable for testing? I assume the cdrtools patch for sure... -Brandon From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 03:29:16 2010 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 61383106566B; Sat, 13 Nov 2010 03:29:16 +0000 (UTC) (envelope-from kris@pcbsd.org) Received: from que21.charter.net (que21.charter.net [209.225.8.22]) by mx1.freebsd.org (Postfix) with ESMTP id C6BC98FC0A; Sat, 13 Nov 2010 03:29:15 +0000 (UTC) Received: from imp10 ([10.20.200.15]) by mta11.charter.net (InterMail vM.7.09.02.04 201-2219-117-106-20090629) with ESMTP id <20101113030931.EYAM4123.mta11.charter.net@imp10>; Fri, 12 Nov 2010 22:09:31 -0500 Received: from moorefam.homeunix.org ([96.38.85.215]) by imp10 with smtp.charter.net id WT9W1f0054elNjk05T9WDh; Fri, 12 Nov 2010 22:09:31 -0500 X-Authority-Analysis: v=1.0 c=1 a=w2b0zq1-BLkA:10 a=kj9zAlcOel0A:10 a=5-53UvGwAAAA:8 a=OfTdGeCWB8lyK5gGdogA:9 a=Smf42ZUPJcS8hhAeIOrqES8BcDUA:4 a=CjuIK1q_8ugA:10 Received: by moorefam.homeunix.org (sSMTP sendmail emulation); Fri, 12 Nov 2010 22:09:30 -0500 Date: Fri, 12 Nov 2010 22:09:30 -0500 From: Kris Moore To: Ivan Klymenko Message-ID: <20101113030930.GB57734@pcbsd.org> References: <20101112204700.0f51550b@ukr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101112204700.0f51550b@ukr.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org, Kris Moore Subject: Re: Error 1: gpart create -s GPT ad0 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, 13 Nov 2010 03:29:16 -0000 On Fri, Nov 12, 2010 at 08:47:00PM +0200, Ivan Klymenko wrote: > Hello! People. > > I use the alternate installer pc-sysinstall based on FreeBSD > 9.0-CURRENT r215176 > When you load the virtual machine qemu disk ad0 is determined by: > http://img573.imageshack.us/i/qemu1.png/ > but when trying to create a section displays the following error: > http://img80.imageshack.us/i/qemu.png/ > Think all options for gpart are correct - what can there be a problem? > > Thanks! The gpart syntax looks correct, and ad0 is being used elsewhere in your install process successfully. Is this a fresh disk / image? Perhaps something has broken in the gpart command? -- Kris Moore PC-BSD Software From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 04:02:10 2010 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 7A8EE106566B for ; Sat, 13 Nov 2010 04:02:10 +0000 (UTC) (envelope-from yanegomi@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 B55118FC08 for ; Sat, 13 Nov 2010 04:02:09 +0000 (UTC) Received: by wwj40 with SMTP id 40so660171wwj.31 for ; Fri, 12 Nov 2010 20:02:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=Im59eNuMwB7WelfiHNvsllFKflo2H5+4S1mDeLsCAWg=; b=cMFvEmIdL7BIpfFK2YtSFHvBRo2qXwOedZdqkauvNvfh8sV7mkN/DsQoX5I2pQfSdX JelGMfhm4NnyhdgnD5JXPtzkMwZUJq3aDe/opxIm/ujVLV+EcLQvKpvgx8GFYiBDRmJ3 KN7HMow2DhBgHU7KDefyLcxIXdhO3ws/3HZDs= 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=ANIr8kr7oWWXlzW5w0ztcrpmlO8A7fEx8WhCZ89/L7pwUGgFXIrE5pW334VX3cZtfL GlrMJwxk+eoQhU8rVxc2IvsVxFMkXUYHJRmovOXG5csZ+cSwiZ8GH056d7Gg1vuBq0YA JVdOpelNxft0Mm8VKN4z+W1AmXlFD+euQqb8k= MIME-Version: 1.0 Received: by 10.216.7.210 with SMTP id 60mr4667801wep.30.1289620928241; Fri, 12 Nov 2010 20:02:08 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Fri, 12 Nov 2010 20:02:08 -0800 (PST) In-Reply-To: <20101113030930.GB57734@pcbsd.org> References: <20101112204700.0f51550b@ukr.net> <20101113030930.GB57734@pcbsd.org> Date: Fri, 12 Nov 2010 20:02:08 -0800 X-Google-Sender-Auth: enDPpjT_PgRgUyuPG9szXw2-J4Q Message-ID: From: Garrett Cooper To: Kris Moore Content-Type: text/plain; charset=ISO-8859-1 Cc: Ivan Klymenko , freebsd-current@freebsd.org, freebsd-questions@freebsd.org, Kris Moore Subject: Re: Error 1: gpart create -s GPT ad0 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, 13 Nov 2010 04:02:10 -0000 On Fri, Nov 12, 2010 at 7:09 PM, Kris Moore wrote: > On Fri, Nov 12, 2010 at 08:47:00PM +0200, Ivan Klymenko wrote: >> Hello! People. >> >> I use the alternate installer pc-sysinstall based on FreeBSD >> 9.0-CURRENT r215176 >> When you load the virtual machine qemu disk ad0 is determined by: >> http://img573.imageshack.us/i/qemu1.png/ >> but when trying to create a section displays the following error: >> http://img80.imageshack.us/i/qemu.png/ >> Think all options for gpart are correct - what can there be a problem? >> >> Thanks! > > The gpart syntax looks correct, and ad0 is being used elsewhere in your install process successfully. Is this a fresh disk / image? Perhaps something has broken in the gpart command? According to the gpart(8) manpage, the invocation is correct. It'd be interesting to see what the log displayed yields, but before then have you tried kern.geom.debugflags=16? I did a quick scan of lib/libgeom and sys/geom, and all of the places (minus one) that returned EINVAL were due to incorrect sector size. What are you using for your disk? Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 05:38:25 2010 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 1F9441065698 for ; Sat, 13 Nov 2010 05:38:25 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward4.mail.yandex.net (forward4.mail.yandex.net [77.88.46.9]) by mx1.freebsd.org (Postfix) with ESMTP id B15488FC12 for ; Sat, 13 Nov 2010 05:38:24 +0000 (UTC) Received: from smtp3.mail.yandex.net (smtp3.mail.yandex.net [77.88.46.103]) by forward4.mail.yandex.net (Yandex) with ESMTP id D5E1F6AD924E; Sat, 13 Nov 2010 08:38:22 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1289626702; bh=v5Y9iv9Kj/vyR/6miKlm3/9OlOrmNmW7LGVA+ZH2Cq0=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=mAlcCoo05ND/6nIgw26Wy2wPU99SxgRtwXU9OPgS9lGWkqxQXPcc6tUqWOy2ispS3 yHL77D4L0DeOvCp88oXuvcwB4i22E5he1ZuJqGCnfndubCL7YVBT1L4RZG2mQ4PLM1 pSwAhxvIAsn0dXUbg9mk9wT1O+z+x2X06ExZGIUE= Received: from [127.0.0.1] (ns.kirov.so-cdu.ru [77.72.136.145]) by smtp3.mail.yandex.net (Yandex) with ESMTPSA id 6C5EE2780A5; Sat, 13 Nov 2010 08:38:22 +0300 (MSK) Message-ID: <4CDE2448.7050905@yandex.ru> Date: Sat, 13 Nov 2010 08:38:16 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Ivan Klymenko References: <20101112204700.0f51550b@ukr.net> In-Reply-To: <20101112204700.0f51550b@ukr.net> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEF7ECCA3CD6E9D8F2B2C1D23" X-Yandex-TimeMark: 1289626702 X-Yandex-Spam: 1 X-Yandex-Front: smtp3.mail.yandex.net Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org, Kris Moore Subject: Re: Error 1: gpart create -s GPT ad0 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, 13 Nov 2010 05:38:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEF7ECCA3CD6E9D8F2B2C1D23 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 12.11.2010 21:47, Ivan Klymenko wrote: > http://img80.imageshack.us/i/qemu.png/ > Think all options for gpart are correct - what can there be a problem? This was temporary regression and it is fixed now in r215118. In any case it is harmless. --=20 WBR, Andrey V. Elsukov --------------enigEF7ECCA3CD6E9D8F2B2C1D23 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJM3iRMAAoJEAHF6gQQyKF6XZYH/j4pKqkCb9yjrcZVljo/6ETT EWBp1VOjFexlukoXo/YOLp3PhBPNdwoFUPoCcqoON6x4m5r9ZR/odpfBH/5r4Vbk DHpILLudPEngfEZNbfJi95f1SvBlZDJQA/qsi6U9ytmJpcRd2rXdcBK7MuJrlvaJ yg0J63I+e7sRNC6FD3fiGKsgTIS0djJhX9kUekl47FEM9mCeZ5E726aaM8AKXBZv UCiG+S/bFwfMfP8Z2/g5WhE0JVOQhwVmc+MO8qA7046m7cnMx02y1wiqQyYtjHza qAVbKDjfRW/nFJ/ajZx76rY8/NpdXi+l70MVRwAe+oH5pzUDR3LWprAfCugLkLs= =Dypt -----END PGP SIGNATURE----- --------------enigEF7ECCA3CD6E9D8F2B2C1D23-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 05:45:07 2010 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 26B601065672 for ; Sat, 13 Nov 2010 05:45:07 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward13.mail.yandex.net (forward13.mail.yandex.net [95.108.130.120]) by mx1.freebsd.org (Postfix) with ESMTP id BFC608FC1C for ; Sat, 13 Nov 2010 05:45:06 +0000 (UTC) Received: from smtp14.mail.yandex.net (smtp14.mail.yandex.net [95.108.131.192]) by forward13.mail.yandex.net (Yandex) with ESMTP id DBF971080220; Sat, 13 Nov 2010 08:45:04 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1289627104; bh=12LksOQgiHueDCxV/XLmdy0xip0gQN0ayFs+yzU7bxY=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=k1Ey4Fdc6D1EDOhDCRymtC7q50eSP0L5MC/9l3jZMP9U7sOken6+NIcgzxzAHwfwE 2EBBuJWXxpuT4ehDZlrTnpR7X7AE9tvDlklcToHq2bSDzwM7cxNDampFX+gF/BY8ER 4UV9YI+zXJBEtBelIAxrhOUT2TiU2jpjekXkpb18= Received: from [127.0.0.1] (mail.kirov.so-cdu.ru [77.72.136.145]) by smtp14.mail.yandex.net (Yandex) with ESMTPSA id 74EEE19B808C; Sat, 13 Nov 2010 08:45:04 +0300 (MSK) Message-ID: <4CDE25DE.9060403@yandex.ru> Date: Sat, 13 Nov 2010 08:45:02 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Ivan Klymenko References: <20101112204700.0f51550b@ukr.net> In-Reply-To: <20101112204700.0f51550b@ukr.net> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7487ADCCAE783561A5B36958" X-Yandex-TimeMark: 1289627104 X-Yandex-Spam: 1 X-Yandex-Front: smtp14.mail.yandex.net Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org, Kris Moore Subject: Re: Error 1: gpart create -s GPT ad0 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, 13 Nov 2010 05:45:07 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7487ADCCAE783561A5B36958 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 12.11.2010 21:47, Ivan Klymenko wrote: > I use the alternate installer pc-sysinstall based on FreeBSD > 9.0-CURRENT r215176 Hmm, are you sure that your kernel is based on r215176? --=20 WBR, Andrey V. Elsukov --------------enig7487ADCCAE783561A5B36958 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJM3iXeAAoJEAHF6gQQyKF6FOoH/jQLwQ4FawtmaMsgnFWjdonP Fs3YRHRqbR3WTMpj7sqha8O30ads6CA7WA15Kg5XhA4TyPtEEtrdY19E5RoBgHht h3X2Akw65b1+dKoyZHeNCTAyoc2+AdazwyU4S4RW1DfyWtj6x9/K31FchJV3/k1t o+9JNWCc2b4bjlhzqetj8T0zrOETREV6ByrDLMJPBDroQfDUUYw8AQn7AagXk5id J9LwyPlpv1WOdVp4aVwPeGR1AVwn9GeiMBSehyoDCJfXCe8SXxQLgowp7AhpYikL cs13hhdkq/JkRHArwVHelFXszogGXXBRlSNlv7n2/d5D/y4G6eTUufPIU3Btqbw= =uVIJ -----END PGP SIGNATURE----- --------------enig7487ADCCAE783561A5B36958-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 07:34:06 2010 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 632B3106564A; Sat, 13 Nov 2010 07:34:06 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id 1E27C8FC08; Sat, 13 Nov 2010 07:34:05 +0000 (UTC) Received: from 62-64-132-95.pool.ukrtel.net ([95.132.64.62] helo=localhost) by fsm1.ukr.net with esmtps ID 1PHAce-000NlE-My ; Sat, 13 Nov 2010 09:34:04 +0200 Date: Sat, 13 Nov 2010 09:34:03 +0200 From: Ivan Klymenko To: "Andrey V. Elsukov" Message-ID: <20101113093403.7d95899a@ukr.net> In-Reply-To: <4CDE25DE.9060403@yandex.ru> References: <20101112204700.0f51550b@ukr.net> <4CDE25DE.9060403@yandex.ru> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org, Kris Moore Subject: Re: Error 1: gpart create -s GPT ad0 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, 13 Nov 2010 07:34:06 -0000 =D0=92 Sat, 13 Nov 2010 08:45:02 +0300 "Andrey V. Elsukov" =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On 12.11.2010 21:47, Ivan Klymenko wrote: > > I use the alternate installer pc-sysinstall based on FreeBSD > > 9.0-CURRENT r215176 >=20 > Hmm, are you sure that your kernel is based on r215176? >=20 no doubt! :) From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 07:35:16 2010 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 E1B801065672; Sat, 13 Nov 2010 07:35:16 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id 9CA568FC1E; Sat, 13 Nov 2010 07:35:16 +0000 (UTC) Received: from 62-64-132-95.pool.ukrtel.net ([95.132.64.62] helo=localhost) by fsm1.ukr.net with esmtps ID 1PHAdn-000O08-3V ; Sat, 13 Nov 2010 09:35:15 +0200 Date: Sat, 13 Nov 2010 09:35:14 +0200 From: Ivan Klymenko To: Kris Moore Message-ID: <20101113093514.52344f03@ukr.net> In-Reply-To: <20101113030930.GB57734@pcbsd.org> References: <20101112204700.0f51550b@ukr.net> <20101113030930.GB57734@pcbsd.org> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org, Kris Moore Subject: Re: Error 1: gpart create -s GPT ad0 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, 13 Nov 2010 07:35:17 -0000 =D0=92 Fri, 12 Nov 2010 22:09:30 -0500 Kris Moore =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Fri, Nov 12, 2010 at 08:47:00PM +0200, Ivan Klymenko wrote: > > Hello! People. > >=20 > > I use the alternate installer pc-sysinstall based on FreeBSD > > 9.0-CURRENT r215176 > > When you load the virtual machine qemu disk ad0 is determined by: > > http://img573.imageshack.us/i/qemu1.png/ > > but when trying to create a section displays the following error: > > http://img80.imageshack.us/i/qemu.png/ > > Think all options for gpart are correct - what can there be a > > problem? > >=20 > > Thanks! >=20 > The gpart syntax looks correct, and ad0 is being used elsewhere in > your install process successfully. Is this a fresh disk / image? > Perhaps something has broken in the gpart command? >=20 Thank you! Now try to recreate the virtual disk ... From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 08:00:42 2010 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 A21A51065672; Sat, 13 Nov 2010 08:00:42 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id 5BCCB8FC15; Sat, 13 Nov 2010 08:00:41 +0000 (UTC) Received: from 62-64-132-95.pool.ukrtel.net ([95.132.64.62] helo=localhost) by fsm1.ukr.net with esmtps ID 1PHB2O-0001sw-Q3 ; Sat, 13 Nov 2010 10:00:40 +0200 Date: Sat, 13 Nov 2010 10:00:39 +0200 From: Ivan Klymenko To: Ivan Klymenko Message-ID: <20101113100039.04772f02@ukr.net> In-Reply-To: <20101113093514.52344f03@ukr.net> References: <20101112204700.0f51550b@ukr.net> <20101113030930.GB57734@pcbsd.org> <20101113093514.52344f03@ukr.net> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org, Kris Moore , Kris Moore Subject: Re: Error 1: gpart create -s GPT ad0 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, 13 Nov 2010 08:00:42 -0000 =D0=92 Sat, 13 Nov 2010 09:35:14 +0200 Ivan Klymenko =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > =D0=92 Fri, 12 Nov 2010 22:09:30 -0500 > Kris Moore =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >=20 > > On Fri, Nov 12, 2010 at 08:47:00PM +0200, Ivan Klymenko wrote: > > > Hello! People. > > >=20 > > > I use the alternate installer pc-sysinstall based on FreeBSD > > > 9.0-CURRENT r215176 > > > When you load the virtual machine qemu disk ad0 is determined by: > > > http://img573.imageshack.us/i/qemu1.png/ > > > but when trying to create a section displays the following error: > > > http://img80.imageshack.us/i/qemu.png/ > > > Think all options for gpart are correct - what can there be a > > > problem? > > >=20 > > > Thanks! > >=20 > > The gpart syntax looks correct, and ad0 is being used elsewhere in > > your install process successfully. Is this a fresh disk / image? > > Perhaps something has broken in the gpart command? > >=20 >=20 > Thank you! > Now try to recreate the virtual disk ... But it did not help avoid the problem :( From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 08:01:43 2010 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 764F3106564A; Sat, 13 Nov 2010 08:01:43 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward3.mail.yandex.net (forward3.mail.yandex.net [77.88.46.8]) by mx1.freebsd.org (Postfix) with ESMTP id 1F1888FC21; Sat, 13 Nov 2010 08:01:42 +0000 (UTC) Received: from smtp3.mail.yandex.net (smtp3.mail.yandex.net [77.88.46.103]) by forward3.mail.yandex.net (Yandex) with ESMTP id 4095856D9436; Sat, 13 Nov 2010 11:01:41 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1289635301; bh=2trJ2d+oIsgxIxO+LXGQJ4zsOEj53Rp1GqKK+EpmZdc=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=NgJ8WnLReOBYd5BYSgjC6gvY24thsIzL6yr0ElIRMI/wX4dAu4WO0kFwW4fNGVxPh zWbzWCW9lLJTsuECs7erUSUrbtjIxIPcXZu2835fzfehpEfJN05yatDATi35yKNp5V GahE4Tz98Y2k7LsJBvk71YObgqB/wTlwgdQuIAiA= Received: from [127.0.0.1] (mail.kirov.so-cdu.ru [77.72.136.145]) by smtp3.mail.yandex.net (Yandex) with ESMTPSA id CC21F278093; Sat, 13 Nov 2010 11:01:40 +0300 (MSK) Message-ID: <4CDE45E0.8040205@yandex.ru> Date: Sat, 13 Nov 2010 11:01:36 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Ivan Klymenko References: <20101112204700.0f51550b@ukr.net> <4CDE25DE.9060403@yandex.ru> <20101113093403.7d95899a@ukr.net> In-Reply-To: <20101113093403.7d95899a@ukr.net> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig467C4B3A49BCF154135489B0" X-Yandex-TimeMark: 1289635301 X-Yandex-Spam: 1 X-Yandex-Front: smtp3.mail.yandex.net Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org, Kris Moore Subject: Re: Error 1: gpart create -s GPT ad0 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, 13 Nov 2010 08:01:43 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig467C4B3A49BCF154135489B0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 13.11.2010 10:34, Ivan Klymenko wrote: >> Hmm, are you sure that your kernel is based on r215176? >> >=20 > no doubt! :) Do you use custom ISO image? Can you mount it and show output of command: # ident /mnt/boot/kernel/kernel.symbols | grep g_part.c --=20 WBR, Andrey V. Elsukov --------------enig467C4B3A49BCF154135489B0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJM3kXjAAoJEAHF6gQQyKF6vrgH/1yH4fKbnqF2GUGKDLEA6CY4 pC0IAQcijzVI0DfV4UlVqWGYLwRcz8XkcRTnJuqC5Cfq0lVqnIhWiZUp+ATcODZY FkAMgqEArDPqAk7a38g2K9AcBL/PY1z5hOH/bh2PBat1pRHYG7hFn7vMOUDhOhP0 Vlh5067iFDhTY5ubmk8m4KGodXXMfV6i263u0Y8uHu/Ou+tqhrEyEeIpQMMdU09J BZ1oLBde/eA+0iZu+3MIe4UGvRK9eDktEpVqHfwZep9OWSlI2jU7LRfpoX7V9XS2 WPgMD1V4q6G4HOCry7P5MgeYne2nhomah+9kx3B+Nw2M87c/HJP1SWf0kt4KjCA= =mrWS -----END PGP SIGNATURE----- --------------enig467C4B3A49BCF154135489B0-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 08:10:34 2010 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 A8AE310656C1; Sat, 13 Nov 2010 08:10:34 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id 5FDBA8FC22; Sat, 13 Nov 2010 08:10:34 +0000 (UTC) Received: from 62-64-132-95.pool.ukrtel.net ([95.132.64.62] helo=localhost) by fsm1.ukr.net with esmtps ID 1PHBBx-0003Xs-AG ; Sat, 13 Nov 2010 10:10:33 +0200 Date: Sat, 13 Nov 2010 10:10:32 +0200 From: Ivan Klymenko To: Garrett Cooper Message-ID: <20101113101032.04382096@ukr.net> In-Reply-To: References: <20101112204700.0f51550b@ukr.net> <20101113030930.GB57734@pcbsd.org> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org, Kris Moore , Kris Moore Subject: Re: Error 1: gpart create -s GPT ad0 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, 13 Nov 2010 08:10:34 -0000 =D0=92 Fri, 12 Nov 2010 20:02:08 -0800 Garrett Cooper =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Fri, Nov 12, 2010 at 7:09 PM, Kris Moore wrote: > > On Fri, Nov 12, 2010 at 08:47:00PM +0200, Ivan Klymenko wrote: > >> Hello! People. > >> > >> I use the alternate installer pc-sysinstall based on FreeBSD > >> 9.0-CURRENT r215176 > >> When you load the virtual machine qemu disk ad0 is determined by: > >> http://img573.imageshack.us/i/qemu1.png/ > >> but when trying to create a section displays the following error: > >> http://img80.imageshack.us/i/qemu.png/ > >> Think all options for gpart are correct - what can there be a > >> problem? > >> > >> Thanks! > > > > The gpart syntax looks correct, and ad0 is being used elsewhere in > > your install process successfully. Is this a fresh disk / image? > > Perhaps something has broken in the gpart command? >=20 > According to the gpart(8) manpage, the invocation is correct. It'd > be interesting to see what the log displayed yields, but before then > have you tried kern.geom.debugflags=3D16?=20 no. after booting the system immediately executed script pc-sysinstall now try to force the kern.geom.debugflags =3D 16 before running pc-sysinstall > I did a quick scan of > lib/libgeom and sys/geom, and all of the places (minus one) that > returned EINVAL were due to incorrect sector size. What are you using > for your disk? >=20 > Thanks, > -Garrett I'm afraid I do not quite understand the essence last question ... : ( I created a virtual disk command: qemu-img create name_disk.img 40G All the breakdown of disk partitions running script pc-sysinstall in accordance with my config file pcinstall.cfg From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 08:16:23 2010 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 1F8BD106566B for ; Sat, 13 Nov 2010 08:16:23 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id B5CA88FC08 for ; Sat, 13 Nov 2010 08:16:22 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1PHB2J-0003Y3-PF for freebsd-current@freebsd.org; Sat, 13 Nov 2010 00:00:35 -0800 Message-ID: <30205790.post@talk.nabble.com> Date: Sat, 13 Nov 2010 00:00:35 -0800 (PST) From: Jakub Lach To: freebsd-current@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: jakub_lach@mailplus.pl References: <4CD45209.5010607@FreeBSD.org> Subject: Re: Sense fetching [Was: cdrtools /devel ...] 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, 13 Nov 2010 08:16:23 -0000 In spirit of Brandon Gooch's mail (although I have lurked whole time) , I'm currently on FreeBSD 8.1-STABLE #0 r215179 amd64, and I'm also willing to test any relevant patches, preferably after consensus is reached. regards, - Jakub Lach -- View this message in context: http://old.nabble.com/Sense-fetching--Was%3A-cdrtools--devel-...--tp30144086p30205790.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 08:24:00 2010 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 65098106564A; Sat, 13 Nov 2010 08:23:59 +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 2E2D28FC16; Sat, 13 Nov 2010 08:23:58 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oAD8NwK1086971; Sat, 13 Nov 2010 03:23:58 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oAD8Nwih086969; Sat, 13 Nov 2010 08:23:58 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 13 Nov 2010 08:23:58 GMT Message-Id: <201011130823.oAD8Nwih086969@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: Sat, 13 Nov 2010 08:24:00 -0000 TB --- 2010-11-13 06:25:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-13 06:25:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2010-11-13 06:25:00 - cleaning the object tree TB --- 2010-11-13 06:25:36 - cvsupping the source tree TB --- 2010-11-13 06:25:36 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2010-11-13 06:26:02 - building world TB --- 2010-11-13 06:26:02 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-13 06:26:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-13 06:26:02 - TARGET=pc98 TB --- 2010-11-13 06:26:02 - TARGET_ARCH=i386 TB --- 2010-11-13 06:26:02 - TZ=UTC TB --- 2010-11-13 06:26:02 - __MAKE_CONF=/dev/null TB --- 2010-11-13 06:26:02 - cd /src TB --- 2010-11-13 06:26:02 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 13 06:26:02 UTC 2010 >>> 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 Sat Nov 13 08:12:51 UTC 2010 TB --- 2010-11-13 08:12:51 - generating LINT kernel config TB --- 2010-11-13 08:12:51 - cd /src/sys/pc98/conf TB --- 2010-11-13 08:12:51 - /usr/bin/make -B LINT TB --- 2010-11-13 08:12:51 - building LINT kernel TB --- 2010-11-13 08:12:51 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-13 08:12:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-13 08:12:51 - TARGET=pc98 TB --- 2010-11-13 08:12:51 - TARGET_ARCH=i386 TB --- 2010-11-13 08:12:51 - TZ=UTC TB --- 2010-11-13 08:12:51 - __MAKE_CONF=/dev/null TB --- 2010-11-13 08:12:51 - cd /src TB --- 2010-11-13 08:12:51 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Nov 13 08:12:51 UTC 2010 >>> 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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_gre.c 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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_iso88025subr.c 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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_lagg.c 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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_loop.c 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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_llatbl.c cc1: warnings being treated as errors /src/sys/net/if_llatbl.c: In function 'llentry_free': /src/sys/net/if_llatbl.c:124: warning: format '%ld' expects type 'long int', but argument 4 has type 'size_t' *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-13 08:23:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-13 08:23:58 - ERROR: failed to build lint kernel TB --- 2010-11-13 08:23:58 - 5437.59 user 1110.79 system 7137.57 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 08:24:41 2010 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 303931065695; Sat, 13 Nov 2010 08:24:41 +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 DDE348FC1B; Sat, 13 Nov 2010 08:24:40 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oAD8OeBd090179; Sat, 13 Nov 2010 03:24:40 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oAD8OepA090170; Sat, 13 Nov 2010 08:24:40 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 13 Nov 2010 08:24:40 GMT Message-Id: <201011130824.oAD8OepA090170@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: Sat, 13 Nov 2010 08:24:41 -0000 TB --- 2010-11-13 08:23:58 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-13 08:23:58 - starting HEAD tinderbox run for mips/mips TB --- 2010-11-13 08:23:58 - cleaning the object tree TB --- 2010-11-13 08:23:58 - cvsupping the source tree TB --- 2010-11-13 08:23:58 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2010-11-13 08:24:39 - building world TB --- 2010-11-13 08:24:39 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-13 08:24:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-13 08:24:39 - TARGET=mips TB --- 2010-11-13 08:24:39 - TARGET_ARCH=mips TB --- 2010-11-13 08:24:39 - TZ=UTC TB --- 2010-11-13 08:24:39 - __MAKE_CONF=/dev/null TB --- 2010-11-13 08:24:39 - cd /src TB --- 2010-11-13 08:24:39 - /usr/bin/make -B buildworld "/src/Makefile.inc1", line 138: Unknown target mips:mips. *** Error code 1 Stop in /src. TB --- 2010-11-13 08:24:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-13 08:24:40 - ERROR: failed to build world TB --- 2010-11-13 08:24:40 - 2.07 user 5.94 system 41.88 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 08:25:11 2010 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 238D010656B1; Sat, 13 Nov 2010 08:25:11 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id D16378FC2D; Sat, 13 Nov 2010 08:25:09 +0000 (UTC) Received: from 62-64-132-95.pool.ukrtel.net ([95.132.64.62] helo=localhost) by fsm1.ukr.net with esmtps ID 1PHBQ4-0005l2-L9 ; Sat, 13 Nov 2010 10:25:08 +0200 Date: Sat, 13 Nov 2010 10:25:07 +0200 From: Ivan Klymenko To: "Andrey V. Elsukov" Message-ID: <20101113102507.5ac13b04@ukr.net> In-Reply-To: <4CDE45E0.8040205@yandex.ru> References: <20101112204700.0f51550b@ukr.net> <4CDE25DE.9060403@yandex.ru> <20101113093403.7d95899a@ukr.net> <4CDE45E0.8040205@yandex.ru> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org, Kris Moore Subject: Re: Error 1: gpart create -s GPT ad0 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, 13 Nov 2010 08:25:11 -0000 =D0=92 Sat, 13 Nov 2010 11:01:36 +0300 "Andrey V. Elsukov" =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On 13.11.2010 10:34, Ivan Klymenko wrote: > >> Hmm, are you sure that your kernel is based on r215176? > >> > >=20 > > no doubt! :) >=20 > Do you use custom ISO image? yes. > Can you mount it and show > output of command: > # ident /mnt/boot/kernel/kernel.symbols | grep g_part.c >=20 Once mounted iso image of my drive to /mnt ident error: /mnt/boot/kernel/kernel.symbols: No such file or directory because this file (kernel.symbols) is really not in the iso image... From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 08:25:50 2010 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 6880B106567A; Sat, 13 Nov 2010 08:25:50 +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 3B67A8FC1A; Sat, 13 Nov 2010 08:25:50 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oAD8PnVi095755; Sat, 13 Nov 2010 03:25:49 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oAD8PnmU095748; Sat, 13 Nov 2010 08:25:49 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 13 Nov 2010 08:25:49 GMT Message-Id: <201011130825.oAD8PnmU095748@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: Sat, 13 Nov 2010 08:25:50 -0000 TB --- 2010-11-13 06:25:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-13 06:25:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-11-13 06:25:00 - cleaning the object tree TB --- 2010-11-13 06:25:38 - cvsupping the source tree TB --- 2010-11-13 06:25:38 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-11-13 06:26:03 - building world TB --- 2010-11-13 06:26:03 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-13 06:26:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-13 06:26:03 - TARGET=i386 TB --- 2010-11-13 06:26:03 - TARGET_ARCH=i386 TB --- 2010-11-13 06:26:03 - TZ=UTC TB --- 2010-11-13 06:26:03 - __MAKE_CONF=/dev/null TB --- 2010-11-13 06:26:03 - cd /src TB --- 2010-11-13 06:26:03 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 13 06:26:04 UTC 2010 >>> 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 Sat Nov 13 08:12:54 UTC 2010 TB --- 2010-11-13 08:12:54 - generating LINT kernel config TB --- 2010-11-13 08:12:54 - cd /src/sys/i386/conf TB --- 2010-11-13 08:12:54 - /usr/bin/make -B LINT TB --- 2010-11-13 08:12:54 - building LINT kernel TB --- 2010-11-13 08:12:54 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-13 08:12:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-13 08:12:54 - TARGET=i386 TB --- 2010-11-13 08:12:54 - TARGET_ARCH=i386 TB --- 2010-11-13 08:12:54 - TZ=UTC TB --- 2010-11-13 08:12:54 - __MAKE_CONF=/dev/null TB --- 2010-11-13 08:12:54 - cd /src TB --- 2010-11-13 08:12:54 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Nov 13 08:12:54 UTC 2010 >>> 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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_gre.c 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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_iso88025subr.c 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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_lagg.c 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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_loop.c 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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_llatbl.c cc1: warnings being treated as errors /src/sys/net/if_llatbl.c: In function 'llentry_free': /src/sys/net/if_llatbl.c:124: warning: format '%ld' expects type 'long int', but argument 4 has type 'size_t' *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-13 08:25:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-13 08:25:49 - ERROR: failed to build lint kernel TB --- 2010-11-13 08:25:49 - 5555.14 user 1088.00 system 7249.11 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 08:30:54 2010 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 0E1A61065674; Sat, 13 Nov 2010 08:30:54 +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 A0C8F8FC1A; Sat, 13 Nov 2010 08:30:53 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oAD8UqYP053718; Sat, 13 Nov 2010 03:30:52 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oAD8Uqar053715; Sat, 13 Nov 2010 08:30:52 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 13 Nov 2010 08:30:52 GMT Message-Id: <201011130830.oAD8Uqar053715@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: Sat, 13 Nov 2010 08:30:54 -0000 TB --- 2010-11-13 08:25:49 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-13 08:25:49 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-11-13 08:25:49 - cleaning the object tree TB --- 2010-11-13 08:25:52 - cvsupping the source tree TB --- 2010-11-13 08:25:52 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-11-13 08:26:08 - building world TB --- 2010-11-13 08:26:08 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-13 08:26:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-13 08:26:08 - TARGET=powerpc TB --- 2010-11-13 08:26:08 - TARGET_ARCH=powerpc64 TB --- 2010-11-13 08:26:08 - TZ=UTC TB --- 2010-11-13 08:26:08 - __MAKE_CONF=/dev/null TB --- 2010-11-13 08:26:08 - cd /src TB --- 2010-11-13 08:26:08 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 13 08:26:09 UTC 2010 >>> 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 [...] cc -o rtermcap /src/usr.sbin/sysinstall/rtermcap.c -ltermcap ===> gnu/usr.bin/cc/cc_tools (obj,depend,all) LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-gather.awk /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/c.opt /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/common.opt /src/gnu/usr.bin/cc/cc_tools/freebsd.opt > optionlist LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-functions.awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opth-gen.awk < optionlist > options.h LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-functions.awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/optc-gen.awk -v header_name="config.h system.h coretypes.h tm.h" < optionlist > options.c TARGET_CPU_DEFAULT="\"powerpc64\"" HEADERS="auto-host.h ansidecl.h" DEFINES="" /bin/sh /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/mkconfig.sh bconfig.h TARGET_CPU_DEFAULT="\"powerpc64\"" HEADERS="options.h rs600064/rs600064.h dbxelf.h elfos-undef.h elfos.h freebsd-native.h freebsd-spec.h freebsd.h rs600064/biarch64.h rs600064/default64.h rs600064/freebsd.h defaults.h" DEFINES="" /bin/sh /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/mkconfig.sh tm.h make: don't know how to make /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config/rs600064/rs600064.c. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-13 08:30:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-13 08:30:52 - ERROR: failed to build world TB --- 2010-11-13 08:30:52 - 206.48 user 56.21 system 302.92 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 08:34:19 2010 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 D9C60106566C; Sat, 13 Nov 2010 08:34:19 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward2.mail.yandex.net (forward2.mail.yandex.net [77.88.46.7]) by mx1.freebsd.org (Postfix) with ESMTP id 81D148FC17; Sat, 13 Nov 2010 08:34:19 +0000 (UTC) Received: from smtp4.mail.yandex.net (smtp4.mail.yandex.net [77.88.46.104]) by forward2.mail.yandex.net (Yandex) with ESMTP id BCB7F38A80DB; Sat, 13 Nov 2010 11:34:17 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1289637257; bh=G6ieXzyvKfBcn0MNEn95Y2ERYHJA3kefcSvKZsZOs/Q=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=MIb40QrF0kB636V5+PB94YDfj/agpdhdowys3z7jZNQ3mOpXE4TTZqgZRIAEFvscK eiLzRZPfAJh5itGQj3W4YawGguu4su7mwieEeZr8YdfrYYmq7pdOh+9gL3p0UFgxBB pkeOvwwqiS5Dd6zCC6v+krd4Cw109ZYPn3L604BI= Received: from [127.0.0.1] (mail.kirov.so-cdu.ru [77.72.136.145]) by smtp4.mail.yandex.net (Yandex) with ESMTPSA id 539F21280AE; Sat, 13 Nov 2010 11:34:17 +0300 (MSK) Message-ID: <4CDE4D84.6060107@yandex.ru> Date: Sat, 13 Nov 2010 11:34:12 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Ivan Klymenko References: <20101112204700.0f51550b@ukr.net> <4CDE25DE.9060403@yandex.ru> <20101113093403.7d95899a@ukr.net> <4CDE45E0.8040205@yandex.ru> <20101113102507.5ac13b04@ukr.net> In-Reply-To: <20101113102507.5ac13b04@ukr.net> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDAB19A430AA08D68E7646B8D" X-Yandex-TimeMark: 1289637257 X-Yandex-Spam: 1 X-Yandex-Front: smtp4.mail.yandex.net Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org, Kris Moore Subject: Re: Error 1: gpart create -s GPT ad0 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, 13 Nov 2010 08:34:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDAB19A430AA08D68E7646B8D Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 13.11.2010 11:25, Ivan Klymenko wrote: > Once mounted iso image of my drive to /mnt > ident error: /mnt/boot/kernel/kernel.symbols: No such file or directory= > because this file (kernel.symbols) is really not in the iso image... So, I can not reproduce this error. And I still think that you use older revision and you should rebuild your ISO image with fresh sources. --=20 WBR, Andrey V. Elsukov --------------enigDAB19A430AA08D68E7646B8D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJM3k2IAAoJEAHF6gQQyKF67SQH/inC51mIQtWsavTbP1BO2RLo +I7rjlFGzqs79CZKbSi/4ItWk6Jjzo7dW111H+Igti2vYc8vN6ZLe5w+KvARKuqY XvFi9C+gWrxjylBxcMeeABqfOKvdg42xQSpv9Xvj6nBvUByhVW+DGdMOOn/LWmGq q3ADARoRH8y72b+zQ1OgIcfgR4qqpkmHflLrfC3NexiQmHtnEqVnLnWM7eWvqjHL qt5yoZJTOQ4Jiusf63BPFYuOoA7M1ebeCT/F5QxFh5KaLdFHZtU2JDVh+9ysNKS5 XrffQ4nvS61l/reEWi94BvAuMadC97dSWT4qjS89THyrPWiEtB5PcR1G/Ztvb+I= =YJ9m -----END PGP SIGNATURE----- --------------enigDAB19A430AA08D68E7646B8D-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 08:38:17 2010 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 1666F1065670; Sat, 13 Nov 2010 08:38:17 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id C11F98FC0A; Sat, 13 Nov 2010 08:38:16 +0000 (UTC) Received: from 62-64-132-95.pool.ukrtel.net ([95.132.64.62] helo=localhost) by fsm1.ukr.net with esmtps ID 1PHBck-0007Rd-Jm ; Sat, 13 Nov 2010 10:38:14 +0200 Date: Sat, 13 Nov 2010 10:38:13 +0200 From: Ivan Klymenko To: Ivan Klymenko Message-ID: <20101113103813.588f82fd@ukr.net> In-Reply-To: <20101113101032.04382096@ukr.net> References: <20101112204700.0f51550b@ukr.net> <20101113030930.GB57734@pcbsd.org> <20101113101032.04382096@ukr.net> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Kris Moore , freebsd-questions@freebsd.org, Kris Moore , Garrett Cooper Subject: Re: Error 1: gpart create -s GPT ad0 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, 13 Nov 2010 08:38:17 -0000 =D0=92 Sat, 13 Nov 2010 10:10:32 +0200 Ivan Klymenko =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > =D0=92 Fri, 12 Nov 2010 20:02:08 -0800 > Garrett Cooper =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >=20 > > On Fri, Nov 12, 2010 at 7:09 PM, Kris Moore wrote: > > > On Fri, Nov 12, 2010 at 08:47:00PM +0200, Ivan Klymenko wrote: > > >> Hello! People. > > >> > > >> I use the alternate installer pc-sysinstall based on FreeBSD > > >> 9.0-CURRENT r215176 > > >> When you load the virtual machine qemu disk ad0 is determined by: > > >> http://img573.imageshack.us/i/qemu1.png/ > > >> but when trying to create a section displays the following error: > > >> http://img80.imageshack.us/i/qemu.png/ > > >> Think all options for gpart are correct - what can there be a > > >> problem? > > >> > > >> Thanks! > > > > > > The gpart syntax looks correct, and ad0 is being used elsewhere in > > > your install process successfully. Is this a fresh disk / image? > > > Perhaps something has broken in the gpart command? > >=20 > > According to the gpart(8) manpage, the invocation is correct. > > It'd be interesting to see what the log displayed yields, but > > before then have you tried kern.geom.debugflags=3D16?=20 >=20 > no. > after booting the system immediately executed script pc-sysinstall > now try to force the kern.geom.debugflags =3D 16 before running > pc-sysinstall did not help ... http://img152.imageshack.us/i/qemu2.png/ on the version of the source code a couple of weeks ago it worked fine .... I just updated the source tree and recompiled my CD/DVD ISO image... >=20 > > I did a quick scan of > > lib/libgeom and sys/geom, and all of the places (minus one) that > > returned EINVAL were due to incorrect sector size. What are you > > using for your disk? > >=20 > > Thanks, > > -Garrett >=20 > I'm afraid I do not quite understand the essence > last question ... : ( > I created a virtual disk command: > qemu-img create name_disk.img 40G > All the breakdown of disk partitions running script pc-sysinstall in > accordance with my config file pcinstall.cfg From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 08:40:04 2010 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 7F7351065694; Sat, 13 Nov 2010 08:40:04 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id 3879B8FC17; Sat, 13 Nov 2010 08:40:04 +0000 (UTC) Received: from 62-64-132-95.pool.ukrtel.net ([95.132.64.62] helo=localhost) by fsm1.ukr.net with esmtps ID 1PHBeV-0007la-9e ; Sat, 13 Nov 2010 10:40:03 +0200 Date: Sat, 13 Nov 2010 10:40:01 +0200 From: Ivan Klymenko To: "Andrey V. Elsukov" Message-ID: <20101113104001.592ea436@ukr.net> In-Reply-To: <4CDE4D84.6060107@yandex.ru> References: <20101112204700.0f51550b@ukr.net> <4CDE25DE.9060403@yandex.ru> <20101113093403.7d95899a@ukr.net> <4CDE45E0.8040205@yandex.ru> <20101113102507.5ac13b04@ukr.net> <4CDE4D84.6060107@yandex.ru> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org, Kris Moore Subject: Re: Error 1: gpart create -s GPT ad0 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, 13 Nov 2010 08:40:04 -0000 =D0=92 Sat, 13 Nov 2010 11:34:12 +0300 "Andrey V. Elsukov" =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On 13.11.2010 11:25, Ivan Klymenko wrote: > > Once mounted iso image of my drive to /mnt > > ident error: /mnt/boot/kernel/kernel.symbols: No such file or > > directory because this file (kernel.symbols) is really not in the > > iso image... >=20 > So, I can not reproduce this error. And I still think that you use > older revision and you should rebuild your ISO image with fresh > sources. >=20 well ... but it will take a little time ... From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 08:49:37 2010 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 29FDB106567A; Sat, 13 Nov 2010 08:49:37 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward15.mail.yandex.net (forward15.mail.yandex.net [95.108.130.119]) by mx1.freebsd.org (Postfix) with ESMTP id C4BE98FC18; Sat, 13 Nov 2010 08:49:35 +0000 (UTC) Received: from smtp12.mail.yandex.net (smtp12.mail.yandex.net [95.108.131.191]) by forward15.mail.yandex.net (Yandex) with ESMTP id 3DA8D44585E2; Sat, 13 Nov 2010 11:49:34 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1289638174; bh=uju4CxTJmKzo2QX/8BnDf7nraXc1eHifCf96b3/lDKs=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=UhhVKBRyoc459+3JItz39Mbq5NtU1Kz/ISRXLHxNOApATNQCkMspwQNv9F2yShRWm aI7kF3SicHrHkN7VoJGvmcFatBSzjAkyRt5Zxrh5j3QI16VMBochzlz1q9btzBBtXd 57mF8/t4y3UAK5ZyWniYnORwIrDiuhCE7FF1xsVE= Received: from [127.0.0.1] (mail.kirov.so-cdu.ru [77.72.136.145]) by smtp12.mail.yandex.net (Yandex) with ESMTPSA id C3E4F13E809B; Sat, 13 Nov 2010 11:49:33 +0300 (MSK) Message-ID: <4CDE5119.5060602@yandex.ru> Date: Sat, 13 Nov 2010 11:49:29 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Ivan Klymenko References: <20101112204700.0f51550b@ukr.net> <4CDE25DE.9060403@yandex.ru> <20101113093403.7d95899a@ukr.net> <4CDE45E0.8040205@yandex.ru> <20101113102507.5ac13b04@ukr.net> <4CDE4D84.6060107@yandex.ru> <20101113104001.592ea436@ukr.net> In-Reply-To: <20101113104001.592ea436@ukr.net> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7407E82C94EDA1FE70AFA26B" X-Yandex-TimeMark: 1289638174 X-Yandex-Spam: 1 X-Yandex-Front: smtp12.mail.yandex.net Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org, Kris Moore Subject: Re: Error 1: gpart create -s GPT ad0 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, 13 Nov 2010 08:49:37 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7407E82C94EDA1FE70AFA26B Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 13.11.2010 11:40, Ivan Klymenko wrote: >> So, I can not reproduce this error. And I still think that you use >> older revision and you should rebuild your ISO image with fresh >> sources. >> >=20 > well ... > but it will take a little time ... Just a note - as you may see from tinderbox's emails at the moment building of fresh current is broken :) --=20 WBR, Andrey V. Elsukov --------------enig7407E82C94EDA1FE70AFA26B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJM3lEcAAoJEAHF6gQQyKF6eukH/090j9iBxw87InzaYDZsp2TH ep/JlbLQmu/48hkEgyVGlH073uDkTCMaTX64wb+qNoUBZ//UKZG1S8xKZzWo8WeL N9mVktPwNjCU+1NN+uQ8yuhWf2odIvvUXpmBDBZYyrvobA6hYom8USMGw2bXYR9t 3gNP4V+cpNJ6tCYfdOR55epxVhD213ZSTnj7uX68ruhP0DFU7HJaZg0KBrZXCPHH GzID1cRTJd/FjFnXE0xKDYXqjOynylPdeyvxGfV2Ya4AFRitIOiP0zFcYw7MyQL8 rxHGhANU5SO0+y64z2HKUTkYXz4hF4kXPtOT3Pfbx5Mu+HY9YgUT/1Hllp/U5BI= =Kaf7 -----END PGP SIGNATURE----- --------------enig7407E82C94EDA1FE70AFA26B-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 08:54:12 2010 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 F1245106564A; Sat, 13 Nov 2010 08:54:12 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id A99368FC17; Sat, 13 Nov 2010 08:54:12 +0000 (UTC) Received: from 253-99-179-94.pool.ukrtel.net ([94.179.99.253] helo=localhost) by fsm1.ukr.net with esmtps ID 1PHBsB-000AKr-FG ; Sat, 13 Nov 2010 10:54:11 +0200 Date: Sat, 13 Nov 2010 10:54:10 +0200 From: Ivan Klymenko To: "Andrey V. Elsukov" Message-ID: <20101113105410.16eb685f@ukr.net> In-Reply-To: <4CDE5119.5060602@yandex.ru> References: <20101112204700.0f51550b@ukr.net> <4CDE25DE.9060403@yandex.ru> <20101113093403.7d95899a@ukr.net> <4CDE45E0.8040205@yandex.ru> <20101113102507.5ac13b04@ukr.net> <4CDE4D84.6060107@yandex.ru> <20101113104001.592ea436@ukr.net> <4CDE5119.5060602@yandex.ru> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org, Kris Moore Subject: Re: Error 1: gpart create -s GPT ad0 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, 13 Nov 2010 08:54:13 -0000 =D0=92 Sat, 13 Nov 2010 11:49:29 +0300 "Andrey V. Elsukov" =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On 13.11.2010 11:40, Ivan Klymenko wrote: > >> So, I can not reproduce this error. And I still think that you use > >> older revision and you should rebuild your ISO image with fresh > >> sources. > >> > >=20 > > well ... > > but it will take a little time ... >=20 > Just a note - as you may see from tinderbox's emails at the moment > building of fresh current is broken :) >=20 Thanks! I saw it - watch for the mailing too ;) From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 09:03:03 2010 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 01022106564A; Sat, 13 Nov 2010 09:03:03 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id AF6FF8FC1C; Sat, 13 Nov 2010 09:03:02 +0000 (UTC) Received: from 253-99-179-94.pool.ukrtel.net ([94.179.99.253] helo=localhost) by fsm1.ukr.net with esmtps ID 1PHC0j-000BUi-B4 ; Sat, 13 Nov 2010 11:03:01 +0200 Date: Sat, 13 Nov 2010 11:03:00 +0200 From: Ivan Klymenko To: "Andrey V. Elsukov" Message-ID: <20101113110300.1bb0909b@ukr.net> In-Reply-To: <4CDE2448.7050905@yandex.ru> References: <20101112204700.0f51550b@ukr.net> <4CDE2448.7050905@yandex.ru> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org, Kris Moore Subject: Re: Error 1: gpart create -s GPT ad0 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, 13 Nov 2010 09:03:03 -0000 =D0=92 Sat, 13 Nov 2010 08:38:16 +0300 "Andrey V. Elsukov" =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On 12.11.2010 21:47, Ivan Klymenko wrote: > > http://img80.imageshack.us/i/qemu.png/ > > Think all options for gpart are correct - what can there be a > > problem? >=20 > This was temporary regression and it is fixed now in r215118. > In any case it is harmless. >=20 I am ashamed ... :( You were right! I have an ISO audit r215110 ... Is the current system on a PC r215176 now try to rebuild the ISO it From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 09:03:36 2010 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 2EE9B106566B; Sat, 13 Nov 2010 09:03:36 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 6E6A28FC14; Sat, 13 Nov 2010 09:03:35 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id C08C1A68243; Sat, 13 Nov 2010 17:03:31 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id EsoYoFKCCbOW; Sat, 13 Nov 2010 17:03:23 +0800 (CST) Received: from delta.delphij.net (c-76-102-26-215.hsd1.ca.comcast.net [76.102.26.215]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 6FFA5A67DDF; Sat, 13 Nov 2010 17:03:22 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:subject:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=YgVXIWFD7GB8650ZRU+vaAi1oDuGu/Y4ysNEbCsfPhOfNHgGIz9tBdc6VOOakEVfx p/Z7K55MIsMK9O5kWulyQ== Message-ID: <4CDE5453.1020400@delphij.net> Date: Sat, 13 Nov 2010 01:03:15 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.15) Gecko/20101028 Thunderbird/3.0.10 ThunderBrowse/3.3.2 MIME-Version: 1.0 To: FreeBSD Current , FreeBSD-STABLE Mailing List X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: Call for Area SATA II RAID controller testers [Fwd: svn commit: r215234 - head/sys/dev/arcmsr] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 09:03:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I have just committed a new vendor release of arcmsr(4) driver. This is intended for 8.2-RELEASE so please test if you could. Thanks in advance! (Note: I have a tarball at http://people.freebsd.org/~delphij/misc/arcmsr.tar.xz which can be used for 8.x system, untar over /usr/src and rebuild the kernel or module depending on your configuration). - -------- Original Message -------- Subject: svn commit: r215234 - head/sys/dev/arcmsr Date: Sat, 13 Nov 2010 08:58:36 +0000 (UTC) From: Xin LI To: src-committers@FreeBSD.ORG, svn-src-all@FreeBSD.ORG, svn-src-head@FreeBSD.ORG Author: delphij Date: Sat Nov 13 08:58:36 2010 New Revision: 215234 URL: http://svn.freebsd.org/changeset/base/215234 Log: Update to vendor release 1.20.00.19. Bug fixes: * Fixed "inquiry data fails comparion at DV1 step" * Fixed bad range input in bus_alloc_resource for ADAPTER_TYPE_B * Fixed arcmsr driver prevent arcsas support for Areca SAS HBA ARC13x0 Many thanks to Areca for continuing to support FreeBSD. This commit is intended for MFC before 8.2-RELEASE. Submitted by: Ching-Lung Huang -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJM3lRTAAoJEATO+BI/yjfBs3wH/24ViOUPwdDjr9lDsX6RaWCQ Ux+9YsekrXLVks61zH8B1dW1rXmthk+aiXpE223UYkcb2M5sLgOQCBYlSDoSwJXu q8iLLZ9Dg6hWpLiS1u6sCj3jjsQbsDVuW1BCrCTSr/eOp6AbXI19GEDouPxVKkt3 wc1amh3eo6ZQAWnxksk+6/HK4nGJOQhjuEC8llybSsImeqqzoEGhRyqJVGa3NO7q fZfTX108QItRmx9Uavh3/2Sa4WA9RWWky+QUSg3hPZg1kNSYJOHuCHgEQIGEE+9R qG38IjHP+NPw0jZVAE7Qap0rA/iMY5FOKeLTjH0PvRBsFeRiPP22KRvdf8eQBM8= =X4q7 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 09:34:14 2010 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 8CAC4106566B; Sat, 13 Nov 2010 09:34:14 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id AE7708FC14; Sat, 13 Nov 2010 09:34:13 +0000 (UTC) Received: by bwz2 with SMTP id 2so3794627bwz.13 for ; Sat, 13 Nov 2010 01:34:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received: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=JYmhMzNeU5OnbnDeUrtS0qRDtJv+dv+6J3HXRmLkOLc=; b=blUU6zzlg0GENwyADU+RZS0V1/ejTnubAGC57nrxVtp7Qjqj4a7aDstkxbslKAEOqh cN/ZpaeXYHpO9y0hhjWC/Hz/yK8p6MJoeFQeBnlBFazkLjpmp9wR/7DVq7g4NiDu8Zsn g4uaAbQAmMFXgrjoT0UjTg/+tryGKpw+GTiMI= 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=EyHpdeynSoto2XbB2vJRTb08CQJ2MTZNPe5HtvcQibh7KO2SGt6Ef1JJ4oe1YMVoDY q4a5+dkiJRnB7GJsJBmZYWHS47njKIoYgetQES9fF/e8Oeao/2vXe15KbRBhScv4K0JK rW2OoG/RacUEbaakWnj/XMgvPvSW0HykSyNtQ= Received: by 10.204.116.74 with SMTP id l10mr3840744bkq.113.1289640851774; Sat, 13 Nov 2010 01:34:11 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 4sm1950121bki.1.2010.11.13.01.34.08 (version=SSLv3 cipher=RC4-MD5); Sat, 13 Nov 2010 01:34:09 -0800 (PST) Sender: Alexander Motin Message-ID: <4CDE5B8C.4000102@FreeBSD.org> Date: Sat, 13 Nov 2010 11:34:04 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Brandon Gooch References: <4CD45209.5010607@FreeBSD.org> In-Reply-To: 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 Stable Subject: Re: Sense fetching [Was: cdrtools /devel ...] 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, 13 Nov 2010 09:34:14 -0000 Brandon Gooch wrote: > 2010/11/5 Alexander Motin : >> Hi. >> >> I've reviewed tests that scgcheck does to SCSI subsystem. It shown >> combination of several issues in both CAM, ahci(4) and cdrtools itself. >> Several small patches allow us to pass most of that tests: >> http://people.freebsd.org/~mav/sense/ >> >> ahci_resid.patch: Add support for reporting residual length on data >> underrun. SCSI commands often returns results shorter then expected. >> Returned value allows application to know/check how much data it really >> has. It is also important for sense fetching, as ATAPI and USB devices >> return sense as data in response to REQUEST_SENSE command. >> >> sense_resid.patch: When manually requesting sense data (ATAPI or USB), >> request only as much data as user requested (not the fixed structure >> size), and return respective sense residual length. >> >> pass_autosence.patch: Unless CAM_DIS_AUTOSENSE is set, always fetch >> sense if not done by SIM, independently of CAM_PASS_ERR_RECOVER. As soon >> as device freeze released before returning to user-level, user-level >> application by definition can't reliably fetch sense data if some other >> application (like hald) tries to access device same time. >> >> cdrtools.patch: Make libscg (part of cdrtools) on FreeBSD to submit >> wanted sense length to CAM and do not clear sense return buffer. It is >> mostly cosmetics, important probably only for scgcheck. >> >> Testers and reviewers welcome. I am especially interested in opinion >> about pass_autosence.patch -- may be we should lower sense fetching even >> deeper, to make it work for all cam_periph_runccb() consumers. > > Hey mav, sorry to chime in after so long here, but have some of these > patches been committed (as of r215179)? > > Which patches are still applicable for testing? I assume the cdrtools > patch for sure... Now uncommitted pass_autosence.patch and possibly cdrtools.patch. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 10:13:53 2010 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 3B0361065674; Sat, 13 Nov 2010 10:13:53 +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 04CF88FC18; Sat, 13 Nov 2010 10:13:51 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oADADpg5097386; Sat, 13 Nov 2010 05:13:51 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oADADpjF097385; Sat, 13 Nov 2010 10:13:51 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 13 Nov 2010 10:13:51 GMT Message-Id: <201011131013.oADADpjF097385@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: Sat, 13 Nov 2010 10:13:53 -0000 TB --- 2010-11-13 08:24:40 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-13 08:24:40 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-11-13 08:24:40 - cleaning the object tree TB --- 2010-11-13 08:25:01 - cvsupping the source tree TB --- 2010-11-13 08:25:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-11-13 08:25:18 - building world TB --- 2010-11-13 08:25:18 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-13 08:25:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-13 08:25:18 - TARGET=powerpc TB --- 2010-11-13 08:25:18 - TARGET_ARCH=powerpc TB --- 2010-11-13 08:25:18 - TZ=UTC TB --- 2010-11-13 08:25:18 - __MAKE_CONF=/dev/null TB --- 2010-11-13 08:25:18 - cd /src TB --- 2010-11-13 08:25:18 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 13 08:25:18 UTC 2010 >>> 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 Sat Nov 13 10:04:58 UTC 2010 TB --- 2010-11-13 10:04:58 - generating LINT kernel config TB --- 2010-11-13 10:04:58 - cd /src/sys/powerpc/conf TB --- 2010-11-13 10:04:58 - /usr/bin/make -B LINT TB --- 2010-11-13 10:04:58 - building LINT kernel TB --- 2010-11-13 10:04:58 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-13 10:04:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-13 10:04:58 - TARGET=powerpc TB --- 2010-11-13 10:04:58 - TARGET_ARCH=powerpc TB --- 2010-11-13 10:04:58 - TZ=UTC TB --- 2010-11-13 10:04:58 - __MAKE_CONF=/dev/null TB --- 2010-11-13 10:04:58 - cd /src TB --- 2010-11-13 10:04:58 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Nov 13 10:04:59 UTC 2010 >>> 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/net/if_gre.c 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/net/if_iso88025subr.c 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/net/if_lagg.c 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/net/if_loop.c 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/net/if_llatbl.c cc1: warnings being treated as errors /src/sys/net/if_llatbl.c: In function 'llentry_free': /src/sys/net/if_llatbl.c:124: warning: format '%ld' expects type 'long int', but argument 4 has type 'size_t' *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-13 10:13:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-13 10:13:51 - ERROR: failed to build lint kernel TB --- 2010-11-13 10:13:51 - 5119.05 user 951.78 system 6550.84 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 11:24:51 2010 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 68115106564A for ; Sat, 13 Nov 2010 11:24:51 +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 DE8728FC18 for ; Sat, 13 Nov 2010 11:24:50 +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 oADBOlVC079898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Nov 2010 13:24:47 +0200 (EET) (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 oADBOl16036606; Sat, 13 Nov 2010 13:24:47 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oADBOluT036605; Sat, 13 Nov 2010 13:24:47 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 13 Nov 2010 13:24:47 +0200 From: Kostik Belousov To: Alexander Best Message-ID: <20101113112447.GF2392@deviant.kiev.zoral.com.ua> References: <20101112223715.GA1356@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CB10VOgVmqyNpfLi" Content-Disposition: inline In-Reply-To: <20101112223715.GA1356@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=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, 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: www/chromium crashing whole system 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, 13 Nov 2010 11:24:51 -0000 --CB10VOgVmqyNpfLi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 12, 2010 at 10:37:15PM +0000, Alexander Best wrote: > hi there, >=20 > i'm having an issue with www/chromium. sometimes it will completely lock = up my > system without producing a core dump. i'm running HEAD (r215102; amd64). Core dump of the kernel or the process ? You probably should follow the usual procedure for the deadlock debugging, see dev handbook. >=20 > this time however chrome.core made it to disk somehow: >=20 =2E.. > Loaded symbols for /libexec/ld-elf.so.1 > #0 0x00000008026d76a2 in symlook_default (name=3D0x806797dbc "__sys_sigr= eturn", hash=3D92647454, refobj=3D0x802722c00, defobj_out=3D0x7fffffbfe160,= ventry=3D0x802717790, flags=3D1) at /usr/src/libexec/rtld-elf/rtld.c:2675 Please show the output of "info locals" in the frame 0. > 2675 symp =3D symlook_list(name, hash, &list_main, &obj, ventry, flags, > [New Thread 2ee6b40 (LWP 100245)] > [New Thread 2ee6000 (LWP 100212)] > (gdb) bt > #0 0x00000008026d76a2 in symlook_default (name=3D0x806797dbc "__sys_sigr= eturn", hash=3D92647454, refobj=3D0x802722c00, defobj_out=3D0x7fffffbfe160,= ventry=3D0x802717790, flags=3D1) at /usr/src/libexec/rtld-elf/rtld.c:2675 > #1 0x00000008026d815c in find_symdef (symnum=3D217, refobj=3D0x802722c00= , defobj_out=3D0x7fffffbfe1a8, flags=3D1, cache=3D0x0) at /usr/src/libexec/= rtld-elf/rtld.c:1205 > #2 0x00000008026d8233 in _rtld_bind (obj=3D0x802722c00, reloff=3DVariabl= e "reloff" is not available. > ) at /usr/src/libexec/rtld-elf/rtld.c:557 > #3 0x00000008026d487d in _rtld_bind_start () at /usr/src/libexec/rtld-el= f/amd64/rtld_start.S:99 > #4 0xffffffff91969eb2 in ?? () > #5 0x0000000000000000 in ?? () > #6 0x0000000000000000 in ?? () > #7 0xfffffffffffffbd0 in ?? () > #8 0x00007fffffbfe260 in ?? () > #9 0x00007fffffbfe260 in ?? () > #10 0x0000000000000000 in ?? () > #11 0x0000000002ee6000 in ?? () > #12 0x0000000002ee6cb8 in ?? () > #13 0x0000000000000206 in ?? () > #14 0x0000000000000000 in ?? () > #15 0x0000000802722c00 in ?? () > #16 0x0000000000000024 in ?? () > #17 0x000000080679fc26 in handle_signal (actp=3DVariable "actp" is not av= ailable. > ) at /usr/src/lib/libthr/thread/thr_sig.c:254 > #18 0x000000080679fd5f in thr_sighandler (sig=3D20, info=3D0x7fffffbfea00= , _ucp=3D0x7fffffbfe690) at /usr/src/lib/libthr/thread/thr_sig.c:181 > #19 > #20 0x00000008069cad6c in read () at read.S:3 > #21 0x000000080679dc70 in __read (fd=3D15, buf=3D0x7fffffbfef84, nbytes= =3D4) at /usr/src/lib/libthr/thread/thr_syscalls.c:460 > #22 0x000000000043871f in (anonymous namespace)::ShutdownDetector::Thread= Main () > #23 0x0000000000984caa in ThreadFunc () > #24 0x000000080679b81e in thread_start (curthread=3D0x2ee6b40) at /usr/sr= c/lib/libthr/thread/thr_create.c:273 > #25 0x0000000000000000 in ?? () > Cannot access memory at address 0x7fffffbff000 >=20 > cheers. > alex >=20 > --=20 > a13x > _______________________________________________ > 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" --CB10VOgVmqyNpfLi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzedX4ACgkQC3+MBN1Mb4hQlwCg0vWlmYVj6EFDxanso//CUN5a 1CcAn2+Tbv8c+NrxTyysDcZSjctc5340 =UEZC -----END PGP SIGNATURE----- --CB10VOgVmqyNpfLi-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 11:59:00 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 2479C106566B; Sat, 13 Nov 2010 11:59:00 +0000 (UTC) Date: Sat, 13 Nov 2010 11:59:00 +0000 From: Alexander Best To: Kostik Belousov Message-ID: <20101113115900.GA14975@freebsd.org> References: <20101112223715.GA1356@freebsd.org> <20101113112447.GF2392@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101113112447.GF2392@deviant.kiev.zoral.com.ua> Cc: freebsd-current@freebsd.org Subject: Re: www/chromium crashing whole system 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, 13 Nov 2010 11:59:00 -0000 On Sat Nov 13 10, Kostik Belousov wrote: > On Fri, Nov 12, 2010 at 10:37:15PM +0000, Alexander Best wrote: > > hi there, > > > > i'm having an issue with www/chromium. sometimes it will completely lock up my > > system without producing a core dump. i'm running HEAD (r215102; amd64). > Core dump of the kernel or the process ? a kernel core dump never gets produced. and this is the first time a process dump made it to disk. > > You probably should follow the usual procedure for the deadlock > debugging, see dev handbook. i have all those options in my kernel conf. still the computer just locks up without any chance to enter the debugger. nothing works any longer. > > > > > this time however chrome.core made it to disk somehow: > > > ... > > > Loaded symbols for /libexec/ld-elf.so.1 > > #0 0x00000008026d76a2 in symlook_default (name=0x806797dbc "__sys_sigreturn", hash=92647454, refobj=0x802722c00, defobj_out=0x7fffffbfe160, ventry=0x802717790, flags=1) at /usr/src/libexec/rtld-elf/rtld.c:2675 > Please show the output of "info locals" in the frame 0. (gdb) frame 0 #0 0x00000008026d76a2 in symlook_default (name=0x806797dbc "__sys_sigreturn", hash=92647454, refobj=0x802722c00, defobj_out=0x7fffffbfe160, ventry=0x802717790, flags=1) at /usr/src/libexec/rtld-elf/rtld.c:2675 2675 symp = symlook_list(name, hash, &list_main, &obj, ventry, flags, (gdb) info locals donelist = {objs = 0x7fffffbfde90, num_alloc = 64, num_used = 0} def = (const Elf_Sym *) 0x0 symp = (const Elf_Sym *) 0x7fffffbfe0e0 obj = Variable "obj" is not available. cheers. alex > > > 2675 symp = symlook_list(name, hash, &list_main, &obj, ventry, flags, > > [New Thread 2ee6b40 (LWP 100245)] > > [New Thread 2ee6000 (LWP 100212)] > > (gdb) bt > > #0 0x00000008026d76a2 in symlook_default (name=0x806797dbc "__sys_sigreturn", hash=92647454, refobj=0x802722c00, defobj_out=0x7fffffbfe160, ventry=0x802717790, flags=1) at /usr/src/libexec/rtld-elf/rtld.c:2675 > > #1 0x00000008026d815c in find_symdef (symnum=217, refobj=0x802722c00, defobj_out=0x7fffffbfe1a8, flags=1, cache=0x0) at /usr/src/libexec/rtld-elf/rtld.c:1205 > > #2 0x00000008026d8233 in _rtld_bind (obj=0x802722c00, reloff=Variable "reloff" is not available. > > ) at /usr/src/libexec/rtld-elf/rtld.c:557 > > #3 0x00000008026d487d in _rtld_bind_start () at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:99 > > #4 0xffffffff91969eb2 in ?? () > > #5 0x0000000000000000 in ?? () > > #6 0x0000000000000000 in ?? () > > #7 0xfffffffffffffbd0 in ?? () > > #8 0x00007fffffbfe260 in ?? () > > #9 0x00007fffffbfe260 in ?? () > > #10 0x0000000000000000 in ?? () > > #11 0x0000000002ee6000 in ?? () > > #12 0x0000000002ee6cb8 in ?? () > > #13 0x0000000000000206 in ?? () > > #14 0x0000000000000000 in ?? () > > #15 0x0000000802722c00 in ?? () > > #16 0x0000000000000024 in ?? () > > #17 0x000000080679fc26 in handle_signal (actp=Variable "actp" is not available. > > ) at /usr/src/lib/libthr/thread/thr_sig.c:254 > > #18 0x000000080679fd5f in thr_sighandler (sig=20, info=0x7fffffbfea00, _ucp=0x7fffffbfe690) at /usr/src/lib/libthr/thread/thr_sig.c:181 > > #19 > > #20 0x00000008069cad6c in read () at read.S:3 > > #21 0x000000080679dc70 in __read (fd=15, buf=0x7fffffbfef84, nbytes=4) at /usr/src/lib/libthr/thread/thr_syscalls.c:460 > > #22 0x000000000043871f in (anonymous namespace)::ShutdownDetector::ThreadMain () > > #23 0x0000000000984caa in ThreadFunc () > > #24 0x000000080679b81e in thread_start (curthread=0x2ee6b40) at /usr/src/lib/libthr/thread/thr_create.c:273 > > #25 0x0000000000000000 in ?? () > > Cannot access memory at address 0x7fffffbff000 > > > > cheers. > > alex > > > > -- > > a13x > > _______________________________________________ > > 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" -- a13x From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 12:28:59 2010 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 67C8B1065693; Sat, 13 Nov 2010 12:28:59 +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 AD2808FC17; Sat, 13 Nov 2010 12:28:58 +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 oADCSrwY085264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Nov 2010 14:28:53 +0200 (EET) (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 oADCSrAh037031; Sat, 13 Nov 2010 14:28:53 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oADCSrSP037030; Sat, 13 Nov 2010 14:28:53 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 13 Nov 2010 14:28:53 +0200 From: Kostik Belousov To: Alexander Best Message-ID: <20101113122853.GG2392@deviant.kiev.zoral.com.ua> References: <20101112223715.GA1356@freebsd.org> <20101113112447.GF2392@deviant.kiev.zoral.com.ua> <20101113115900.GA14975@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ECRja8HA1lJ2QMij" Content-Disposition: inline In-Reply-To: <20101113115900.GA14975@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.7 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: www/chromium crashing whole system 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, 13 Nov 2010 12:28:59 -0000 --ECRja8HA1lJ2QMij Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 13, 2010 at 11:59:00AM +0000, Alexander Best wrote: > On Sat Nov 13 10, Kostik Belousov wrote: > > On Fri, Nov 12, 2010 at 10:37:15PM +0000, Alexander Best wrote: > > > hi there, > > >=20 > > > i'm having an issue with www/chromium. sometimes it will completely l= ock up my > > > system without producing a core dump. i'm running HEAD (r215102; amd6= 4). > > Core dump of the kernel or the process ? >=20 > a kernel core dump never gets produced. and this is the first time a proc= ess > dump made it to disk. >=20 > >=20 > > You probably should follow the usual procedure for the deadlock > > debugging, see dev handbook. >=20 > i have all those options in my kernel conf. still the computer just locks= up > without any chance to enter the debugger. nothing works any longer. Do you use serial or firewire console ? Since you run chromium, you should run X server, and you cannot use syscons for ddb while in X. >=20 > >=20 > > >=20 > > > this time however chrome.core made it to disk somehow: > > >=20 > > ... > >=20 > > > Loaded symbols for /libexec/ld-elf.so.1 > > > #0 0x00000008026d76a2 in symlook_default (name=3D0x806797dbc "__sys_= sigreturn", hash=3D92647454, refobj=3D0x802722c00, defobj_out=3D0x7fffffbfe= 160, ventry=3D0x802717790, flags=3D1) at /usr/src/libexec/rtld-elf/rtld.c:2= 675 > > Please show the output of "info locals" in the frame 0. >=20 > (gdb) frame 0 > #0 0x00000008026d76a2 in symlook_default (name=3D0x806797dbc "__sys_sigr= eturn", hash=3D92647454, refobj=3D0x802722c00, defobj_out=3D0x7fffffbfe160,= ventry=3D0x802717790, flags=3D1) at /usr/src/libexec/rtld-elf/rtld.c:2675 > 2675 symp =3D symlook_list(name, hash, &list_main, &obj, ventry, flags, > (gdb) info locals > donelist =3D {objs =3D 0x7fffffbfde90, num_alloc =3D 64, num_used =3D 0} > def =3D (const Elf_Sym *) 0x0 Right, this is what I suspected. def is NULL, but the code path selected seems to be the one which happens when def !=3D NULL. This is either a random memory corruption inside the process, or might be some other usermode issue. It is very unlikely that it has anything with kernel deadlock. > symp =3D (const Elf_Sym *) 0x7fffffbfe0e0 > obj =3D Variable "obj" is not available. >=20 > cheers. > alex >=20 > >=20 > > > 2675 symp =3D symlook_list(name, hash, &list_main, &obj, ventry, fla= gs, > > > [New Thread 2ee6b40 (LWP 100245)] > > > [New Thread 2ee6000 (LWP 100212)] > > > (gdb) bt > > > #0 0x00000008026d76a2 in symlook_default (name=3D0x806797dbc "__sys_= sigreturn", hash=3D92647454, refobj=3D0x802722c00, defobj_out=3D0x7fffffbfe= 160, ventry=3D0x802717790, flags=3D1) at /usr/src/libexec/rtld-elf/rtld.c:2= 675 > > > #1 0x00000008026d815c in find_symdef (symnum=3D217, refobj=3D0x80272= 2c00, defobj_out=3D0x7fffffbfe1a8, flags=3D1, cache=3D0x0) at /usr/src/libe= xec/rtld-elf/rtld.c:1205 > > > #2 0x00000008026d8233 in _rtld_bind (obj=3D0x802722c00, reloff=3DVar= iable "reloff" is not available. > > > ) at /usr/src/libexec/rtld-elf/rtld.c:557 > > > #3 0x00000008026d487d in _rtld_bind_start () at /usr/src/libexec/rtl= d-elf/amd64/rtld_start.S:99 > > > #4 0xffffffff91969eb2 in ?? () > > > #5 0x0000000000000000 in ?? () > > > #6 0x0000000000000000 in ?? () > > > #7 0xfffffffffffffbd0 in ?? () > > > #8 0x00007fffffbfe260 in ?? () > > > #9 0x00007fffffbfe260 in ?? () > > > #10 0x0000000000000000 in ?? () > > > #11 0x0000000002ee6000 in ?? () > > > #12 0x0000000002ee6cb8 in ?? () > > > #13 0x0000000000000206 in ?? () > > > #14 0x0000000000000000 in ?? () > > > #15 0x0000000802722c00 in ?? () > > > #16 0x0000000000000024 in ?? () > > > #17 0x000000080679fc26 in handle_signal (actp=3DVariable "actp" is no= t available. > > > ) at /usr/src/lib/libthr/thread/thr_sig.c:254 > > > #18 0x000000080679fd5f in thr_sighandler (sig=3D20, info=3D0x7fffffbf= ea00, _ucp=3D0x7fffffbfe690) at /usr/src/lib/libthr/thread/thr_sig.c:181 > > > #19 > > > #20 0x00000008069cad6c in read () at read.S:3 > > > #21 0x000000080679dc70 in __read (fd=3D15, buf=3D0x7fffffbfef84, nbyt= es=3D4) at /usr/src/lib/libthr/thread/thr_syscalls.c:460 > > > #22 0x000000000043871f in (anonymous namespace)::ShutdownDetector::Th= readMain () > > > #23 0x0000000000984caa in ThreadFunc () > > > #24 0x000000080679b81e in thread_start (curthread=3D0x2ee6b40) at /us= r/src/lib/libthr/thread/thr_create.c:273 > > > #25 0x0000000000000000 in ?? () > > > Cannot access memory at address 0x7fffffbff000 > > >=20 > > > cheers. > > > alex > > >=20 > > > --=20 > > > a13x > > > _______________________________________________ > > > 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" >=20 >=20 >=20 > --=20 > a13x --ECRja8HA1lJ2QMij Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzehIQACgkQC3+MBN1Mb4ihHgCgun/dmo5GllvdM82ix2RcKEUh uPEAoKFmDGT+OUaf9uVJZyJzBKqhqsb3 =V+1A -----END PGP SIGNATURE----- --ECRja8HA1lJ2QMij-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 12:38:46 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 535CA1065679; Sat, 13 Nov 2010 12:38:46 +0000 (UTC) Date: Sat, 13 Nov 2010 12:38:46 +0000 From: Alexander Best To: Kostik Belousov Message-ID: <20101113123846.GA21390@freebsd.org> References: <20101112223715.GA1356@freebsd.org> <20101113112447.GF2392@deviant.kiev.zoral.com.ua> <20101113115900.GA14975@freebsd.org> <20101113122853.GG2392@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101113122853.GG2392@deviant.kiev.zoral.com.ua> Cc: freebsd-current@freebsd.org Subject: Re: www/chromium crashing whole system 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, 13 Nov 2010 12:38:46 -0000 On Sat Nov 13 10, Kostik Belousov wrote: > On Sat, Nov 13, 2010 at 11:59:00AM +0000, Alexander Best wrote: > > On Sat Nov 13 10, Kostik Belousov wrote: > > > On Fri, Nov 12, 2010 at 10:37:15PM +0000, Alexander Best wrote: > > > > hi there, > > > > > > > > i'm having an issue with www/chromium. sometimes it will completely lock up my > > > > system without producing a core dump. i'm running HEAD (r215102; amd64). > > > Core dump of the kernel or the process ? > > > > a kernel core dump never gets produced. and this is the first time a process > > dump made it to disk. > > > > > > > > You probably should follow the usual procedure for the deadlock > > > debugging, see dev handbook. > > > > i have all those options in my kernel conf. still the computer just locks up > > without any chance to enter the debugger. nothing works any longer. > Do you use serial or firewire console ? Since you run chromium, you > should run X server, and you cannot use syscons for ddb while in X. nope. all i have is a usb mouse and a usb keyboard. ;) > > > > > > > > > > > > > > this time however chrome.core made it to disk somehow: > > > > > > > ... > > > > > > > Loaded symbols for /libexec/ld-elf.so.1 > > > > #0 0x00000008026d76a2 in symlook_default (name=0x806797dbc "__sys_sigreturn", hash=92647454, refobj=0x802722c00, defobj_out=0x7fffffbfe160, ventry=0x802717790, flags=1) at /usr/src/libexec/rtld-elf/rtld.c:2675 > > > Please show the output of "info locals" in the frame 0. > > > > (gdb) frame 0 > > #0 0x00000008026d76a2 in symlook_default (name=0x806797dbc "__sys_sigreturn", hash=92647454, refobj=0x802722c00, defobj_out=0x7fffffbfe160, ventry=0x802717790, flags=1) at /usr/src/libexec/rtld-elf/rtld.c:2675 > > 2675 symp = symlook_list(name, hash, &list_main, &obj, ventry, flags, > > (gdb) info locals > > donelist = {objs = 0x7fffffbfde90, num_alloc = 64, num_used = 0} > > def = (const Elf_Sym *) 0x0 > Right, this is what I suspected. def is NULL, but the code path selected > seems to be the one which happens when def != NULL. This is either a > random memory corruption inside the process, or might be some other > usermode issue. It is very unlikely that it has anything with kernel > deadlock. hmmm...but isn't the concept of UNIX that user applications cannot cause a system to crash (protected mode)? i tried detaching and attaching my keyboard after chromium crashed my system and the lights of the keyboard didn't even went on. so in fact everything crashed and not just X. cheers. alex > > > symp = (const Elf_Sym *) 0x7fffffbfe0e0 > > obj = Variable "obj" is not available. > > > > cheers. > > alex > > > > > > > > > 2675 symp = symlook_list(name, hash, &list_main, &obj, ventry, flags, > > > > [New Thread 2ee6b40 (LWP 100245)] > > > > [New Thread 2ee6000 (LWP 100212)] > > > > (gdb) bt > > > > #0 0x00000008026d76a2 in symlook_default (name=0x806797dbc "__sys_sigreturn", hash=92647454, refobj=0x802722c00, defobj_out=0x7fffffbfe160, ventry=0x802717790, flags=1) at /usr/src/libexec/rtld-elf/rtld.c:2675 > > > > #1 0x00000008026d815c in find_symdef (symnum=217, refobj=0x802722c00, defobj_out=0x7fffffbfe1a8, flags=1, cache=0x0) at /usr/src/libexec/rtld-elf/rtld.c:1205 > > > > #2 0x00000008026d8233 in _rtld_bind (obj=0x802722c00, reloff=Variable "reloff" is not available. > > > > ) at /usr/src/libexec/rtld-elf/rtld.c:557 > > > > #3 0x00000008026d487d in _rtld_bind_start () at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:99 > > > > #4 0xffffffff91969eb2 in ?? () > > > > #5 0x0000000000000000 in ?? () > > > > #6 0x0000000000000000 in ?? () > > > > #7 0xfffffffffffffbd0 in ?? () > > > > #8 0x00007fffffbfe260 in ?? () > > > > #9 0x00007fffffbfe260 in ?? () > > > > #10 0x0000000000000000 in ?? () > > > > #11 0x0000000002ee6000 in ?? () > > > > #12 0x0000000002ee6cb8 in ?? () > > > > #13 0x0000000000000206 in ?? () > > > > #14 0x0000000000000000 in ?? () > > > > #15 0x0000000802722c00 in ?? () > > > > #16 0x0000000000000024 in ?? () > > > > #17 0x000000080679fc26 in handle_signal (actp=Variable "actp" is not available. > > > > ) at /usr/src/lib/libthr/thread/thr_sig.c:254 > > > > #18 0x000000080679fd5f in thr_sighandler (sig=20, info=0x7fffffbfea00, _ucp=0x7fffffbfe690) at /usr/src/lib/libthr/thread/thr_sig.c:181 > > > > #19 > > > > #20 0x00000008069cad6c in read () at read.S:3 > > > > #21 0x000000080679dc70 in __read (fd=15, buf=0x7fffffbfef84, nbytes=4) at /usr/src/lib/libthr/thread/thr_syscalls.c:460 > > > > #22 0x000000000043871f in (anonymous namespace)::ShutdownDetector::ThreadMain () > > > > #23 0x0000000000984caa in ThreadFunc () > > > > #24 0x000000080679b81e in thread_start (curthread=0x2ee6b40) at /usr/src/lib/libthr/thread/thr_create.c:273 > > > > #25 0x0000000000000000 in ?? () > > > > Cannot access memory at address 0x7fffffbff000 > > > > > > > > cheers. > > > > alex > > > > > > > > -- > > > > a13x > > > > _______________________________________________ > > > > 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" > > > > > > > > -- > > a13x -- a13x From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 12:41:51 2010 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 697BB106566B; Sat, 13 Nov 2010 12:41:51 +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 ADB588FC14; Sat, 13 Nov 2010 12:41:50 +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 oADCfkms086436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Nov 2010 14:41:46 +0200 (EET) (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 oADCfkEu037148; Sat, 13 Nov 2010 14:41:46 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oADCfkh2037147; Sat, 13 Nov 2010 14:41:46 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 13 Nov 2010 14:41:46 +0200 From: Kostik Belousov To: Alexander Best Message-ID: <20101113124146.GH2392@deviant.kiev.zoral.com.ua> References: <20101112223715.GA1356@freebsd.org> <20101113112447.GF2392@deviant.kiev.zoral.com.ua> <20101113115900.GA14975@freebsd.org> <20101113122853.GG2392@deviant.kiev.zoral.com.ua> <20101113123846.GA21390@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+TK353/LLu+MSpeP" Content-Disposition: inline In-Reply-To: <20101113123846.GA21390@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.7 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: www/chromium crashing whole system 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, 13 Nov 2010 12:41:51 -0000 --+TK353/LLu+MSpeP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 13, 2010 at 12:38:46PM +0000, Alexander Best wrote: > On Sat Nov 13 10, Kostik Belousov wrote: > > On Sat, Nov 13, 2010 at 11:59:00AM +0000, Alexander Best wrote: > > > On Sat Nov 13 10, Kostik Belousov wrote: > > > > On Fri, Nov 12, 2010 at 10:37:15PM +0000, Alexander Best wrote: > > > > > hi there, > > > > >=20 > > > > > i'm having an issue with www/chromium. sometimes it will complete= ly lock up my > > > > > system without producing a core dump. i'm running HEAD (r215102; = amd64). > > > > Core dump of the kernel or the process ? > > >=20 > > > a kernel core dump never gets produced. and this is the first time a = process > > > dump made it to disk. > > >=20 > > > >=20 > > > > You probably should follow the usual procedure for the deadlock > > > > debugging, see dev handbook. > > >=20 > > > i have all those options in my kernel conf. still the computer just l= ocks up > > > without any chance to enter the debugger. nothing works any longer. > > Do you use serial or firewire console ? Since you run chromium, you > > should run X server, and you cannot use syscons for ddb while in X. >=20 > nope. all i have is a usb mouse and a usb keyboard. ;) >=20 > >=20 > > >=20 > > > >=20 > > > > >=20 > > > > > this time however chrome.core made it to disk somehow: > > > > >=20 > > > > ... > > > >=20 > > > > > Loaded symbols for /libexec/ld-elf.so.1 > > > > > #0 0x00000008026d76a2 in symlook_default (name=3D0x806797dbc "__= sys_sigreturn", hash=3D92647454, refobj=3D0x802722c00, defobj_out=3D0x7ffff= fbfe160, ventry=3D0x802717790, flags=3D1) at /usr/src/libexec/rtld-elf/rtld= .c:2675 > > > > Please show the output of "info locals" in the frame 0. > > >=20 > > > (gdb) frame 0 > > > #0 0x00000008026d76a2 in symlook_default (name=3D0x806797dbc "__sys_= sigreturn", hash=3D92647454, refobj=3D0x802722c00, defobj_out=3D0x7fffffbfe= 160, ventry=3D0x802717790, flags=3D1) at /usr/src/libexec/rtld-elf/rtld.c:2= 675 > > > 2675 symp =3D symlook_list(name, hash, &list_main, &obj, ventry, fla= gs, > > > (gdb) info locals > > > donelist =3D {objs =3D 0x7fffffbfde90, num_alloc =3D 64, num_used =3D= 0} > > > def =3D (const Elf_Sym *) 0x0 > > Right, this is what I suspected. def is NULL, but the code path selected > > seems to be the one which happens when def !=3D NULL. This is either a > > random memory corruption inside the process, or might be some other > > usermode issue. It is very unlikely that it has anything with kernel > > deadlock. >=20 > hmmm...but isn't the concept of UNIX that user applications cannot cause a > system to crash (protected mode)? >=20 > i tried detaching and attaching my keyboard after chromium crashed my sys= tem > and the lights of the keyboard didn't even went on. so in fact everything > crashed and not just X. If I said it unclear, let me repeat, the usermode crash dump you got probably has nothing common with the kernel issue. Kernel problem should be taken care of first, and we cannot move forward without proper debugging tools (see above). >=20 > cheers. > alex >=20 > >=20 > > > symp =3D (const Elf_Sym *) 0x7fffffbfe0e0 > > > obj =3D Variable "obj" is not available. > > >=20 > > > cheers. > > > alex > > >=20 > > > >=20 > > > > > 2675 symp =3D symlook_list(name, hash, &list_main, &obj, ventry,= flags, > > > > > [New Thread 2ee6b40 (LWP 100245)] > > > > > [New Thread 2ee6000 (LWP 100212)] > > > > > (gdb) bt > > > > > #0 0x00000008026d76a2 in symlook_default (name=3D0x806797dbc "__= sys_sigreturn", hash=3D92647454, refobj=3D0x802722c00, defobj_out=3D0x7ffff= fbfe160, ventry=3D0x802717790, flags=3D1) at /usr/src/libexec/rtld-elf/rtld= .c:2675 > > > > > #1 0x00000008026d815c in find_symdef (symnum=3D217, refobj=3D0x8= 02722c00, defobj_out=3D0x7fffffbfe1a8, flags=3D1, cache=3D0x0) at /usr/src/= libexec/rtld-elf/rtld.c:1205 > > > > > #2 0x00000008026d8233 in _rtld_bind (obj=3D0x802722c00, reloff= =3DVariable "reloff" is not available. > > > > > ) at /usr/src/libexec/rtld-elf/rtld.c:557 > > > > > #3 0x00000008026d487d in _rtld_bind_start () at /usr/src/libexec= /rtld-elf/amd64/rtld_start.S:99 > > > > > #4 0xffffffff91969eb2 in ?? () > > > > > #5 0x0000000000000000 in ?? () > > > > > #6 0x0000000000000000 in ?? () > > > > > #7 0xfffffffffffffbd0 in ?? () > > > > > #8 0x00007fffffbfe260 in ?? () > > > > > #9 0x00007fffffbfe260 in ?? () > > > > > #10 0x0000000000000000 in ?? () > > > > > #11 0x0000000002ee6000 in ?? () > > > > > #12 0x0000000002ee6cb8 in ?? () > > > > > #13 0x0000000000000206 in ?? () > > > > > #14 0x0000000000000000 in ?? () > > > > > #15 0x0000000802722c00 in ?? () > > > > > #16 0x0000000000000024 in ?? () > > > > > #17 0x000000080679fc26 in handle_signal (actp=3DVariable "actp" i= s not available. > > > > > ) at /usr/src/lib/libthr/thread/thr_sig.c:254 > > > > > #18 0x000000080679fd5f in thr_sighandler (sig=3D20, info=3D0x7fff= ffbfea00, _ucp=3D0x7fffffbfe690) at /usr/src/lib/libthr/thread/thr_sig.c:181 > > > > > #19 > > > > > #20 0x00000008069cad6c in read () at read.S:3 > > > > > #21 0x000000080679dc70 in __read (fd=3D15, buf=3D0x7fffffbfef84, = nbytes=3D4) at /usr/src/lib/libthr/thread/thr_syscalls.c:460 > > > > > #22 0x000000000043871f in (anonymous namespace)::ShutdownDetector= ::ThreadMain () > > > > > #23 0x0000000000984caa in ThreadFunc () > > > > > #24 0x000000080679b81e in thread_start (curthread=3D0x2ee6b40) at= /usr/src/lib/libthr/thread/thr_create.c:273 > > > > > #25 0x0000000000000000 in ?? () > > > > > Cannot access memory at address 0x7fffffbff000 > > > > >=20 > > > > > cheers. > > > > > alex > > > > >=20 > > > > > --=20 > > > > > a13x > > > > > _______________________________________________ > > > > > freebsd-current@freebsd.org mailing list > > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@fre= ebsd.org" > > >=20 > > >=20 > > >=20 > > > --=20 > > > a13x >=20 >=20 >=20 > --=20 > a13x --+TK353/LLu+MSpeP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzeh4oACgkQC3+MBN1Mb4hMwQCgssJw9ep4cjD21cuThZoAYJZe pt8An1/DVKGJPYnKYZUyDUyc0ePQT9Gg =M9u6 -----END PGP SIGNATURE----- --+TK353/LLu+MSpeP-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 12:47:58 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 55A4D106566C; Sat, 13 Nov 2010 12:47:58 +0000 (UTC) Date: Sat, 13 Nov 2010 12:47:58 +0000 From: Alexander Best To: Kostik Belousov Message-ID: <20101113124758.GA23469@freebsd.org> References: <20101112223715.GA1356@freebsd.org> <20101113112447.GF2392@deviant.kiev.zoral.com.ua> <20101113115900.GA14975@freebsd.org> <20101113122853.GG2392@deviant.kiev.zoral.com.ua> <20101113123846.GA21390@freebsd.org> <20101113124146.GH2392@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101113124146.GH2392@deviant.kiev.zoral.com.ua> Cc: freebsd-current@freebsd.org Subject: Re: www/chromium crashing whole system 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, 13 Nov 2010 12:47:58 -0000 On Sat Nov 13 10, Kostik Belousov wrote: > On Sat, Nov 13, 2010 at 12:38:46PM +0000, Alexander Best wrote: > > On Sat Nov 13 10, Kostik Belousov wrote: > > > On Sat, Nov 13, 2010 at 11:59:00AM +0000, Alexander Best wrote: > > > > On Sat Nov 13 10, Kostik Belousov wrote: > > > > > On Fri, Nov 12, 2010 at 10:37:15PM +0000, Alexander Best wrote: > > > > > > hi there, > > > > > > > > > > > > i'm having an issue with www/chromium. sometimes it will completely lock up my > > > > > > system without producing a core dump. i'm running HEAD (r215102; amd64). > > > > > Core dump of the kernel or the process ? > > > > > > > > a kernel core dump never gets produced. and this is the first time a process > > > > dump made it to disk. > > > > > > > > > > > > > > You probably should follow the usual procedure for the deadlock > > > > > debugging, see dev handbook. > > > > > > > > i have all those options in my kernel conf. still the computer just locks up > > > > without any chance to enter the debugger. nothing works any longer. > > > Do you use serial or firewire console ? Since you run chromium, you > > > should run X server, and you cannot use syscons for ddb while in X. > > > > nope. all i have is a usb mouse and a usb keyboard. ;) > > > > > > > > > > > > > > > > > > > > > > > > > > this time however chrome.core made it to disk somehow: > > > > > > > > > > > ... > > > > > > > > > > > Loaded symbols for /libexec/ld-elf.so.1 > > > > > > #0 0x00000008026d76a2 in symlook_default (name=0x806797dbc "__sys_sigreturn", hash=92647454, refobj=0x802722c00, defobj_out=0x7fffffbfe160, ventry=0x802717790, flags=1) at /usr/src/libexec/rtld-elf/rtld.c:2675 > > > > > Please show the output of "info locals" in the frame 0. > > > > > > > > (gdb) frame 0 > > > > #0 0x00000008026d76a2 in symlook_default (name=0x806797dbc "__sys_sigreturn", hash=92647454, refobj=0x802722c00, defobj_out=0x7fffffbfe160, ventry=0x802717790, flags=1) at /usr/src/libexec/rtld-elf/rtld.c:2675 > > > > 2675 symp = symlook_list(name, hash, &list_main, &obj, ventry, flags, > > > > (gdb) info locals > > > > donelist = {objs = 0x7fffffbfde90, num_alloc = 64, num_used = 0} > > > > def = (const Elf_Sym *) 0x0 > > > Right, this is what I suspected. def is NULL, but the code path selected > > > seems to be the one which happens when def != NULL. This is either a > > > random memory corruption inside the process, or might be some other > > > usermode issue. It is very unlikely that it has anything with kernel > > > deadlock. > > > > hmmm...but isn't the concept of UNIX that user applications cannot cause a > > system to crash (protected mode)? > > > > i tried detaching and attaching my keyboard after chromium crashed my system > > and the lights of the keyboard didn't even went on. so in fact everything > > crashed and not just X. > If I said it unclear, let me repeat, the usermode crash dump you got > probably has nothing common with the kernel issue. oh sorry. indeed i misunderstood you there. well i guess this is the problem most regular users have. we don't own any serial/firewire consoles. all i can offer is to add kernel OPTIONS. however none of them seem to be able to prevent the lock up and instead letting me enter the debugger or trigger a kernel core dump. i even have watchdog running, but without any sucess. i guess all i can hope for is that maybe at some point a kernel dump does make it to disk. cheers. alex > > Kernel problem should be taken care of first, and we cannot move > forward without proper debugging tools (see above). > > > > cheers. > > alex > > > > > > > > > symp = (const Elf_Sym *) 0x7fffffbfe0e0 > > > > obj = Variable "obj" is not available. > > > > > > > > cheers. > > > > alex > > > > > > > > > > > > > > > 2675 symp = symlook_list(name, hash, &list_main, &obj, ventry, flags, > > > > > > [New Thread 2ee6b40 (LWP 100245)] > > > > > > [New Thread 2ee6000 (LWP 100212)] > > > > > > (gdb) bt > > > > > > #0 0x00000008026d76a2 in symlook_default (name=0x806797dbc "__sys_sigreturn", hash=92647454, refobj=0x802722c00, defobj_out=0x7fffffbfe160, ventry=0x802717790, flags=1) at /usr/src/libexec/rtld-elf/rtld.c:2675 > > > > > > #1 0x00000008026d815c in find_symdef (symnum=217, refobj=0x802722c00, defobj_out=0x7fffffbfe1a8, flags=1, cache=0x0) at /usr/src/libexec/rtld-elf/rtld.c:1205 > > > > > > #2 0x00000008026d8233 in _rtld_bind (obj=0x802722c00, reloff=Variable "reloff" is not available. > > > > > > ) at /usr/src/libexec/rtld-elf/rtld.c:557 > > > > > > #3 0x00000008026d487d in _rtld_bind_start () at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:99 > > > > > > #4 0xffffffff91969eb2 in ?? () > > > > > > #5 0x0000000000000000 in ?? () > > > > > > #6 0x0000000000000000 in ?? () > > > > > > #7 0xfffffffffffffbd0 in ?? () > > > > > > #8 0x00007fffffbfe260 in ?? () > > > > > > #9 0x00007fffffbfe260 in ?? () > > > > > > #10 0x0000000000000000 in ?? () > > > > > > #11 0x0000000002ee6000 in ?? () > > > > > > #12 0x0000000002ee6cb8 in ?? () > > > > > > #13 0x0000000000000206 in ?? () > > > > > > #14 0x0000000000000000 in ?? () > > > > > > #15 0x0000000802722c00 in ?? () > > > > > > #16 0x0000000000000024 in ?? () > > > > > > #17 0x000000080679fc26 in handle_signal (actp=Variable "actp" is not available. > > > > > > ) at /usr/src/lib/libthr/thread/thr_sig.c:254 > > > > > > #18 0x000000080679fd5f in thr_sighandler (sig=20, info=0x7fffffbfea00, _ucp=0x7fffffbfe690) at /usr/src/lib/libthr/thread/thr_sig.c:181 > > > > > > #19 > > > > > > #20 0x00000008069cad6c in read () at read.S:3 > > > > > > #21 0x000000080679dc70 in __read (fd=15, buf=0x7fffffbfef84, nbytes=4) at /usr/src/lib/libthr/thread/thr_syscalls.c:460 > > > > > > #22 0x000000000043871f in (anonymous namespace)::ShutdownDetector::ThreadMain () > > > > > > #23 0x0000000000984caa in ThreadFunc () > > > > > > #24 0x000000080679b81e in thread_start (curthread=0x2ee6b40) at /usr/src/lib/libthr/thread/thr_create.c:273 > > > > > > #25 0x0000000000000000 in ?? () > > > > > > Cannot access memory at address 0x7fffffbff000 > > > > > > > > > > > > cheers. > > > > > > alex > > > > > > > > > > > > -- > > > > > > a13x > > > > > > _______________________________________________ > > > > > > 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" > > > > > > > > > > > > > > > > -- > > > > a13x > > > > > > > > -- > > a13x -- a13x From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 12:51:12 2010 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 CF8281065673; Sat, 13 Nov 2010 12:51:12 +0000 (UTC) (envelope-from yanegomi@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 33AAA8FC14; Sat, 13 Nov 2010 12:51:11 +0000 (UTC) Received: by wwj40 with SMTP id 40so921915wwj.31 for ; Sat, 13 Nov 2010 04:51:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=JH2rj0CV5prt+tLmAh9FmgTVc961F5O56uWGKl//ZNI=; b=bpf3Umg1nHRab2shMufpXVwaOJC4QQrl+ii1G+YfzuUo/OFdsTihkDFEm99pwkw7bu wsPgz0/ZxVHoI87OV3taPwyULX0llemUGyqJ8cSPgg4nTu2shM+bBfQ8F5NsgnlKp7Wn DPBCTTPv+PlaKHkIA/Jm92RZIxioOdQ2ifYvg= 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=bIdqxRMz4lVX+X4WpuzoRcA4peq/voTUVZANqLMOfWJvEqP0GfxIQx0iPk3S+JfkbZ OArFR8Acr0gvzfqjYFs3V2cqK3J8u8//mnBYtTtfrJa0Np24YRqoArVoglCQUKHs02wF lKzC0jsEmbInoY9yQJSPk+KoX0+yYaTKCdmhQ= MIME-Version: 1.0 Received: by 10.216.175.18 with SMTP id y18mr3542678wel.30.1289652670829; Sat, 13 Nov 2010 04:51:10 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Sat, 13 Nov 2010 04:51:10 -0800 (PST) In-Reply-To: <20101113124758.GA23469@freebsd.org> References: <20101112223715.GA1356@freebsd.org> <20101113112447.GF2392@deviant.kiev.zoral.com.ua> <20101113115900.GA14975@freebsd.org> <20101113122853.GG2392@deviant.kiev.zoral.com.ua> <20101113123846.GA21390@freebsd.org> <20101113124146.GH2392@deviant.kiev.zoral.com.ua> <20101113124758.GA23469@freebsd.org> Date: Sat, 13 Nov 2010 04:51:10 -0800 X-Google-Sender-Auth: kjOT7IJVBEYk2W8cxWemKS1PlLk Message-ID: From: Garrett Cooper To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , freebsd-current@freebsd.org Subject: Re: www/chromium crashing whole system 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, 13 Nov 2010 12:51:12 -0000 On Sat, Nov 13, 2010 at 4:47 AM, Alexander Best wrote= : > On Sat Nov 13 10, Kostik Belousov wrote: >> On Sat, Nov 13, 2010 at 12:38:46PM +0000, Alexander Best wrote: >> > On Sat Nov 13 10, Kostik Belousov wrote: >> > > On Sat, Nov 13, 2010 at 11:59:00AM +0000, Alexander Best wrote: >> > > > On Sat Nov 13 10, Kostik Belousov wrote: >> > > > > On Fri, Nov 12, 2010 at 10:37:15PM +0000, Alexander Best wrote: >> > > > > > hi there, >> > > > > > >> > > > > > i'm having an issue with www/chromium. sometimes it will compl= etely lock up my >> > > > > > system without producing a core dump. i'm running HEAD (r21510= 2; amd64). >> > > > > Core dump of the kernel or the process ? >> > > > >> > > > a kernel core dump never gets produced. and this is the first time= a process >> > > > dump made it to disk. >> > > > >> > > > > >> > > > > You probably should follow the usual procedure for the deadlock >> > > > > debugging, see dev handbook. >> > > > >> > > > i have all those options in my kernel conf. still the computer jus= t locks up >> > > > without any chance to enter the debugger. nothing works any longer= . >> > > Do you use serial or firewire console ? Since you run chromium, you >> > > should run X server, and you cannot use syscons for ddb while in X. >> > >> > nope. all i have is a usb mouse and a usb keyboard. ;) >> > >> > > >> > > > >> > > > > >> > > > > > >> > > > > > this time however chrome.core made it to disk somehow: >> > > > > > >> > > > > ... >> > > > > >> > > > > > Loaded symbols for /libexec/ld-elf.so.1 >> > > > > > #0 =A00x00000008026d76a2 in symlook_default (name=3D0x806797db= c "__sys_sigreturn", hash=3D92647454, refobj=3D0x802722c00, defobj_out=3D0x= 7fffffbfe160, ventry=3D0x802717790, flags=3D1) at /usr/src/libexec/rtld-elf= /rtld.c:2675 >> > > > > Please show the output of "info locals" in the frame 0. >> > > > >> > > > (gdb) frame 0 >> > > > #0 =A00x00000008026d76a2 in symlook_default (name=3D0x806797dbc "_= _sys_sigreturn", hash=3D92647454, refobj=3D0x802722c00, defobj_out=3D0x7fff= ffbfe160, ventry=3D0x802717790, flags=3D1) at /usr/src/libexec/rtld-elf/rtl= d.c:2675 >> > > > 2675 =A0 =A0 =A0 =A0 =A0 =A0symp =3D symlook_list(name, hash, &lis= t_main, &obj, ventry, flags, >> > > > (gdb) info locals >> > > > donelist =3D {objs =3D 0x7fffffbfde90, num_alloc =3D 64, num_used = =3D 0} >> > > > def =3D (const Elf_Sym *) 0x0 >> > > Right, this is what I suspected. def is NULL, but the code path sele= cted >> > > seems to be the one which happens when def !=3D NULL. This is either= a >> > > random memory corruption inside the process, or might be some other >> > > usermode issue. It is very unlikely that it has anything with kernel >> > > deadlock. >> > >> > hmmm...but isn't the concept of UNIX that user applications cannot cau= se a >> > system to crash (protected mode)? >> > >> > i tried detaching and attaching my keyboard after chromium crashed my = system >> > and the lights of the keyboard didn't even went on. so in fact everyth= ing >> > crashed and not just X. >> If I said it unclear, let me repeat, the usermode crash dump you got >> probably has nothing common with the kernel issue. > > oh sorry. indeed i misunderstood you there. well i guess this is the prob= lem > most regular users have. we don't own any serial/firewire consoles. all i= can > offer is to add kernel OPTIONS. however none of them seem to be able to p= revent > the lock up and instead letting me enter the debugger or trigger a kernel= core > dump. > > i even have watchdog running, but without any sucess. i guess all i can h= ope > for is that maybe at some point a kernel dump does make it to disk. If userland hasn't completely locked up, you could login remotely, i.e. ssh, and poke at the box (if even for a brief period of time before it goes down). HTH, -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 13:26:32 2010 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 37B751065675 for ; Sat, 13 Nov 2010 13:26:32 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id F19818FC13 for ; Sat, 13 Nov 2010 13:26:31 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1PHG7j-0007Lq-GN for freebsd-current@freebsd.org; Sat, 13 Nov 2010 05:26:31 -0800 Message-ID: <30206153.post@talk.nabble.com> Date: Sat, 13 Nov 2010 05:26:31 -0800 (PST) From: Jakub Lach To: freebsd-current@freebsd.org In-Reply-To: <4CDE5B8C.4000102@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: jakub_lach@mailplus.pl References: <4CD45209.5010607@FreeBSD.org> <4CDE5B8C.4000102@FreeBSD.org> Subject: Re: Sense fetching [Was: cdrtools /devel ...] 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, 13 Nov 2010 13:26:32 -0000 Hello. scgcheck after applying all patches: Ready to start test for second SCSI open? Enter to continue: First SCSI open OK - device usable **********> Checking for second SCSI open. Second SCSI open for same device succeeded, 1 additional file descriptor(s) used. Second SCSI open is usable Closing second SCSI. Checking first SCSI. First SCSI open is still usable ----------> Second SCSI open test PASSED. First SCSI open is still usable Ready to start test for succeeded command? Enter to continue: **********> Checking for succeeded SCSI command. Executing 'inquiry' command on Bus 1 Target 0, Lun 0 timeout 40s CDB: 12 00 00 00 24 00 cmd finished after 0.002s timeout 40s Inquiry Data : 05 80 00 32 5B 00 00 00 48 4C 2D 44 54 2D 53 54 44 56 44 52 41 4D 20 47 53 41 2D 55 32 30 4E 20 48 58 31 31 ----------> SCSI succeeded command test PASSED Ready to start test for failing command? Enter to continue: **********> Testing for failed SCSI command. scgcheck: Input/output error. inquiry: scsi sendcmd: retryable error CDB: 12 00 00 FF 24 00 status: 0x0 (GOOD STATUS) resid: 36 cmd finished after 0.038s timeout 40s ----------> SCSI Transport return != SCG_NO_ERROR (1) ----------> SCSI status byte set to 0 (0x0) ----------> SCSI failed command test FAILED Ready to start test for sense data count? Enter to continue: **********> Testing for SCSI sense data count. **********> Testing if at least CCS_SENSE_LEN (18) is supported... Sense Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------> Method 0x00: expected: 18 reported: 18 max found: 0 Sense Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------> Method 0xFF: expected: 18 reported: 18 max found: 18 ----------> Wanted 18 sense bytes, got it. **********> Testing for 32 bytes of sense data... Sense Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------> Method 0x00: expected: 32 reported: 32 max found: 0 Sense Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----------> Method 0xFF: expected: 32 reported: 32 max found: 32 ----------> Wanted 32 sense bytes, got it. ----------> Got a maximum of 32 sense bytes ----------> SCSI sense count test PASSED ----------> SCSI status byte test NOT YET READY Ready to start test for working DMA residual count? Enter to continue: **********> Testing for working DMA residual count. **********> Testing for working DMA residual count == 0. CDB cnt: 36 DMA cnt: 36 got really: 36 (System says: RDMA cnt: 36 resid 0) CDB cnt: 36 DMA cnt: 36 got really: 36 (System says: RDMA cnt: 36 resid 0) ----------> Wanted 36 bytes, got it. ----------> SCSI DMA residual count == 0 test PASSED Ready to start test for working DMA residual count == DMA count? Enter to continue: resid: 36 CDB cnt: 0 DMA cnt: 36 got really: 0 (System says: RDMA cnt: 0 resid 36) resid: 36 CDB cnt: 0 DMA cnt: 36 got really: 0 (System says: RDMA cnt: 0 resid 36) ----------> Wanted 0 bytes, got it. ----------> SCSI DMA residual count == DMA count test PASSED Ready to start test for working DMA residual count == 1? Enter to continue: **********> Testing for working DMA residual count == 1. resid: 1 CDB cnt: 36 DMA cnt: 37 got really: 36 (System says: RDMA cnt: 36 resid 1) resid: 1 CDB cnt: 36 DMA cnt: 37 got really: 36 (System says: RDMA cnt: 36 resid 1) ----------> Wanted 36 bytes, got it. ----------> SCSI DMA residual count == 1 test PASSED Ready to start test for working DMA overrun detection? Enter to continue: **********> Testing for working DMA overrun detection. DMA overrun, resid: -1 CDB cnt: 36 DMA cnt: 35 got really: 36 (System says: RDMA cnt: 36 resid -1) DMA overrun, resid: -1 CDB cnt: 36 DMA cnt: 35 got really: 36 (System says: RDMA cnt: 36 resid -1) ----------> Wanted 36 bytes, got it - DMA overrun not blocked. ----------> Wanted 35 bytes, got (36) ----------> Libscg says 35 bytes but got (36) ----------> SCSI DMA overrun test FAILED ----------> SCSI transport code test NOT YET READY What is more important, writing CD-Rs and DVD-Rs works. Thanks for help, - Jakub Lach -- View this message in context: http://old.nabble.com/Sense-fetching--Was%3A-cdrtools--devel-...--tp30144086p30206153.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 13:05:44 2010 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 BF93B106564A for ; Sat, 13 Nov 2010 13:05:44 +0000 (UTC) (envelope-from crockabiscuit@yahoo.com) Received: from nm1-vm0.bullet.mail.ne1.yahoo.com (nm1-vm0.bullet.mail.ne1.yahoo.com [98.138.91.74]) by mx1.freebsd.org (Postfix) with SMTP id 831758FC08 for ; Sat, 13 Nov 2010 13:05:44 +0000 (UTC) Received: from [98.138.90.48] by nm1.bullet.mail.ne1.yahoo.com with NNFMP; 13 Nov 2010 12:52:10 -0000 Received: from [98.138.88.234] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 13 Nov 2010 12:52:10 -0000 Received: from [127.0.0.1] by omp1034.mail.ne1.yahoo.com with NNFMP; 13 Nov 2010 12:52:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 716286.94184.bm@omp1034.mail.ne1.yahoo.com Received: (qmail 81324 invoked by uid 60001); 13 Nov 2010 12:52:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1289652730; bh=fOqNqq0vFoXOS6Pgfg7oZ7qdKSWBbaXB6bfbz8neHHg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=5jS72pPZnywaIeZNwnkQKyikiLsFCPQA78bkc9Al/uN2zJL0ilwYJlhIr0sEVuyksy1FWYzUFM0Rryx5xQ709lT7zfJhJGe0EsjfLwfcK+MPfFLvi8RA965En1F4JBtlNMDH6NJ8SL+y9d2e0RRTmp+6/ytUkq44XzeAMQJy5Ac= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=r+bMn2HJBAfViClpJch61hXnL0jqxOFMiE+f/OiJUZidvMlhVF3VxWxPjaYsGDHbofgxBYDK55RPS7mgc4fRWHpLSddpGcbq+jVKE7SpfNSWlilhy/2P3murAU6N+qutXbsCbaF7Re8Qcj9M84UuQgYwndcLcI9Y/7ogygEahYU=; Message-ID: <512851.76377.qm@web120315.mail.ne1.yahoo.com> X-YMail-OSG: VJk0BZYVM1l1RSNDaYTeZpGAgootQopG_isl30.feZgQ8hO Y06zKj2KCQo0erj1Xhs6cWgHkL5lBGM1kOLMh69j.e1mYJeuHIBx1Ammt7R. YYAawknqw65RAnhmZBJF2E_94sDDgLDvt7LWqEx5awDnGsymOfXFiVC1eah1 I8I7jm74sdwT3k7337P1UqWdZCjzYt8mdSwmw Received: from [180.68.85.212] by web120315.mail.ne1.yahoo.com via HTTP; Sat, 13 Nov 2010 04:52:10 PST X-Mailer: YahooMailClassic/11.4.9 YahooMailWebService/0.8.107.285259 Date: Sat, 13 Nov 2010 04:52:10 -0800 (PST) From: crocket To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Sat, 13 Nov 2010 13:39:04 +0000 Subject: Keymaps in X11 and consoles should be the same with TEKEN_XTERM 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: Sat, 13 Nov 2010 13:05:44 -0000 TEKEN_XTERM turns on xterm mode. I compiled a kernel with TEKEN_XTERM, and changed cons25 to xterm in /etc/ttys. When I executed vim on a console, the keyboard acted weirdly. After setting TERM back to cons25 again, vim acted normally again on consoles. I could assign xterm console characters in /etc/termcap to fkeys by writing keychanges="fkeycode consolecharacter" in /etc/rc.conf, but it is just a quick hack, and it is just a solution for me but not for everyone. I would be glad keymaps in X11 and consoles became the same with TEKEN_XTERM in the kernel. If the keymaps in consoles and X11 are the same, 99% of configurations I needed to make in applications will be unneeded. It will benefit everyone. From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 14:02:33 2010 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 CA24A106566B; Sat, 13 Nov 2010 14:02:33 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id 83B7E8FC0C; Sat, 13 Nov 2010 14:02:33 +0000 (UTC) Received: from 253-99-179-94.pool.ukrtel.net ([94.179.99.253] helo=localhost) by fsm1.ukr.net with esmtps ID 1PHGga-0006i3-5y ; Sat, 13 Nov 2010 16:02:32 +0200 Date: Sat, 13 Nov 2010 16:02:30 +0200 From: Ivan Klymenko To: Ivan Klymenko Message-ID: <20101113160230.08838c9b@ukr.net> In-Reply-To: <20101113110300.1bb0909b@ukr.net> References: <20101112204700.0f51550b@ukr.net> <4CDE2448.7050905@yandex.ru> <20101113110300.1bb0909b@ukr.net> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Andrey V. Elsukov" , freebsd-questions@freebsd.org, Kris Moore , freebsd-current@freebsd.org Subject: Re: Error 1: gpart create -s GPT ad0 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, 13 Nov 2010 14:02:33 -0000 =D0=92 Sat, 13 Nov 2010 11:03:00 +0200 Ivan Klymenko =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > =D0=92 Sat, 13 Nov 2010 08:38:16 +0300 > "Andrey V. Elsukov" =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >=20 > > On 12.11.2010 21:47, Ivan Klymenko wrote: > > > http://img80.imageshack.us/i/qemu.png/ > > > Think all options for gpart are correct - what can there be a > > > problem? > >=20 > > This was temporary regression and it is fixed now in r215118. > > In any case it is harmless. > >=20 >=20 > I am ashamed ... :( > You were right! > I have an ISO audit r215110 ... >=20 > Is the current system on a PC r215176 >=20 > now try to rebuild the ISO it I rebuild the ISO image based on r215176 and gpart did not return an error. Thank you all! Topic can be closed. :) From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 16:55:07 2010 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 36D26106564A for ; Sat, 13 Nov 2010 16:55:07 +0000 (UTC) (envelope-from eirnym@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id B0D318FC15 for ; Sat, 13 Nov 2010 16:55:06 +0000 (UTC) Received: by bwz2 with SMTP id 2so3999670bwz.13 for ; Sat, 13 Nov 2010 08:55:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=WGigoBuSeCjNIcikU4lLmyno6n0NOCH0x22L3ec2qI4=; b=x+9jelNQ/sc61Org0jBWdO2btDSOEGXgV3+VWTYPZlyObuX/pDU5JaYM/3/rdKmW2R evv9QupNpl9R64uqIsOpR4hKpQmAsadDrCY+O+MRqv7Z0K4O4ngWhHFiDRYlnxZLuOGo EwfrcuJ3TM/U0riRyBS7EAumoL2t/iTa/jq6E= 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; b=g13FOOP2uME1nRNodgBOsAhr79o2UWd6R221fTTjYs7O2f383gg70yMYD4LZgnHlY8 UkGEJFjgFpn9oy2nYSyacMLptxa0K5qCZYIy4DMTkpG79DDLgdIgmIhVHL+VSQQB15hu m2u3AE2AEoeXPpTLqxVJqY4E7Ggw1cW0XNiNQ= Received: by 10.204.52.7 with SMTP id f7mr4121540bkg.190.1289667305533; Sat, 13 Nov 2010 08:55:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.123.131 with HTTP; Sat, 13 Nov 2010 08:54:45 -0800 (PST) In-Reply-To: <512851.76377.qm@web120315.mail.ne1.yahoo.com> References: <512851.76377.qm@web120315.mail.ne1.yahoo.com> From: Eir Nym Date: Sat, 13 Nov 2010 19:54:45 +0300 Message-ID: To: crocket Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org Subject: Re: Keymaps in X11 and consoles should be the same with TEKEN_XTERM 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: Sat, 13 Nov 2010 16:55:07 -0000 On 13 November 2010 15:52, crocket wrote: > TEKEN_XTERM turns on xterm mode. > I compiled a kernel with TEKEN_XTERM, and changed cons25 to xterm in /etc/ttys. > > When I executed vim on a console, the keyboard acted weirdly. > After setting TERM back to cons25 again, vim acted normally again on consoles. > I could assign xterm console characters in /etc/termcap to fkeys by writing keychanges="fkeycode consolecharacter" in /etc/rc.conf, but it is just a quick hack, and it is just a solution for me but not for everyone. > Oh... you can do `vidcontrol -T xterm` and your keybindings will be correct. > I would be glad keymaps in X11 and consoles became the same with TEKEN_XTERM in the kernel. > If the keymaps in consoles and X11 are the same, 99% of configurations I needed to make in applications will be unneeded. It will benefit everyone. > > As Ed said some days before, you should use TEKEN_XTERM _or_ TEKEN_CONS25 in your kernel. From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 17:24:40 2010 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 99D6B1065670 for ; Sat, 13 Nov 2010 17:24:40 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 30A678FC24 for ; Sat, 13 Nov 2010 17:24:40 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 128A22A28D04; Sat, 13 Nov 2010 18:24:39 +0100 (CET) Date: Sat, 13 Nov 2010 18:24:39 +0100 From: Ed Schouten To: crocket Message-ID: <20101113172439.GZ2054@hoeg.nl> References: <512851.76377.qm@web120315.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HRnx18n0jmP0CroI" Content-Disposition: inline In-Reply-To: <512851.76377.qm@web120315.mail.ne1.yahoo.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: Keymaps in X11 and consoles should be the same with TEKEN_XTERM 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: Sat, 13 Nov 2010 17:24:40 -0000 --HRnx18n0jmP0CroI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * crocket , 20101113 13:52: > TEKEN_XTERM turns on xterm mode. > I compiled a kernel with TEKEN_XTERM, and changed cons25 to xterm in > /etc/ttys. >=20 > When I executed vim on a console, the keyboard acted weirdly. Keep in mind that this list is supposed to discuss FreeBSD -CURRENT; not FreeBSD 8.x. Please don't use xterm mode on FreeBSD 8. It doesn't come with any support whatsoever. --=20 Ed Schouten WWW: http://80386.nl/ --HRnx18n0jmP0CroI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkzeydcACgkQ52SDGA2eCwVXDgCeKnUtf5Ql3tx/mf4PxbkwCzI6 k2AAniAOhZdxCgCLwtsi0+kyAfiptAwr =ldw8 -----END PGP SIGNATURE----- --HRnx18n0jmP0CroI-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 17:26:49 2010 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 253BC1065670 for ; Sat, 13 Nov 2010 17:26:49 +0000 (UTC) (envelope-from crockabiscuit@yahoo.com) Received: from nm7-vm1.bullet.mail.ne1.yahoo.com (nm7-vm1.bullet.mail.ne1.yahoo.com [98.138.90.250]) by mx1.freebsd.org (Postfix) with SMTP id CF7318FC08 for ; Sat, 13 Nov 2010 17:26:48 +0000 (UTC) Received: from [98.138.90.55] by nm7.bullet.mail.ne1.yahoo.com with NNFMP; 13 Nov 2010 17:26:48 -0000 Received: from [98.138.89.170] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 13 Nov 2010 17:26:48 -0000 Received: from [127.0.0.1] by omp1026.mail.ne1.yahoo.com with NNFMP; 13 Nov 2010 17:26:48 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 298773.73350.bm@omp1026.mail.ne1.yahoo.com Received: (qmail 57328 invoked by uid 60001); 13 Nov 2010 17:26:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1289669208; bh=MexcpCJFdIA4sg9J2p0IlvCHPpKIqoHEK7s9a3JO5Vs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=j1htunz58g44xQthm7VwaNu/8dPhFXhhBcCQDp2uC6z9PU0+Qc/K0DkE8pfDuJePvv6GfYmoNjtj22UQYdozkYJy4spQ2vgOaGrPZiLMg0RaJp0H4XkMY2ffkrnqgjMZ8vBsc65+t6WRPYetgPMBhdbR7gantYkiSFTMe6WMKjI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=i0FcZof3bXyFgj5DF813PNF6omlZONCSTjl2RwVEJes618xePHuslaatbUAU3r7B+AxtwW2oRXFsmT6vtctlI6gc2R2G3mCGniqkS+qVaVtfFOkL25NZHjVbGsSM649RC4v4W+R9OsNaBeC6Fa4Tt9eypxKOqynSSOTtARvDEzg=; Message-ID: <199606.57296.qm@web120309.mail.ne1.yahoo.com> X-YMail-OSG: IuR5BQ4VM1kbChU_puWk4AmJHzsJFU.Q5Ycknm6ll8OBpaN ZWSiSk8dwusZzprqTuMWdgSFMmfFlilR5irLDsI9f59yCBtvZ9UjX3CNBJxR oBGVbSz6G2A_LQTDDmp6WYGNaOoPEYiQVoURdJRkbaznQet5kgvbomfYApWd o.Xz0gU3YuGPABajeNjoVs4R7NhAuzfd1PXZEZm_jb0HIbMdTk1A6R197dGh DIAjrBa3k1GET4gUGaQ-- Received: from [180.68.85.212] by web120309.mail.ne1.yahoo.com via HTTP; Sat, 13 Nov 2010 09:26:47 PST X-Mailer: YahooMailClassic/11.4.9 YahooMailWebService/0.8.107.285259 Date: Sat, 13 Nov 2010 09:26:47 -0800 (PST) From: crocket To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: Keymaps in X11 and consoles should be the same with TEKEN_XTERM 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: Sat, 13 Nov 2010 17:26:49 -0000 --- On Sat, 11/13/10, Eir Nym wrote: > From: Eir Nym > Subject: Re: Keymaps in X11 and consoles should be the same with TEKEN_XTERM in the kernel. > To: "crocket" > Cc: freebsd-current@freebsd.org > Date: Saturday, November 13, 2010, 4:54 PM > On 13 November 2010 15:52, crocket > > wrote: > > TEKEN_XTERM turns on xterm mode. > > I compiled a kernel with TEKEN_XTERM, and changed > cons25 to xterm in /etc/ttys. > > > > When I executed vim on a console, the keyboard acted > weirdly. > > After setting TERM back to cons25 again, vim acted > normally again on consoles. > > I could assign xterm console characters in > /etc/termcap to fkeys by writing keychanges="fkeycode > consolecharacter" in /etc/rc.conf, but it is just a quick > hack, and it is just a solution for me but not for > everyone. > > > > Oh... you can do `vidcontrol -T xterm` and your keybindings > will be correct. When I execute 'vidcontrol -T xterm', "vidcontrol: illegal option -- T" is displayed. Ah, I use FreeBSD 8.1-RELEASE, not -CURRENT. Maybe that's why I don't have -T option. I posted my message here because development of TEKEN_XTERM is an ongoing process. > > > I would be glad keymaps in X11 and consoles became the > same with TEKEN_XTERM in the kernel. > > If the keymaps in consoles and X11 are the same, 99% > of configurations I needed to make in applications will be > unneeded. It will benefit everyone. > > > > > > As Ed said some days before, you should use TEKEN_XTERM > _or_ > TEKEN_CONS25 in your kernel. I don't understand what you answered to. However, TEKEN_CONS25 is not in my kernel configuration. And There was a typo. "I would be glad keymaps in X11 and consoles became the same with TEKEN_XTERM in the kernel" should be "I would be glad "if" keymaps in X11 and consoles became the same with TEKEN_XTERM in the kernel" Do you think xterm way(instead of syscons way) of key symbol to console character conversion should become the default in 9.0-RELEASE? I think it should be since syscons is being replaced by teken, which uses xterm. I'm not sure if I used terms right. PS. teken reminds me of tekken, an arcade game. From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 17:32:15 2010 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 3C9901065673 for ; Sat, 13 Nov 2010 17:32:15 +0000 (UTC) (envelope-from crockabiscuit@yahoo.com) Received: from nm17-vm0.bullet.mail.ne1.yahoo.com (nm17-vm0.bullet.mail.ne1.yahoo.com [98.138.91.58]) by mx1.freebsd.org (Postfix) with SMTP id 004548FC17 for ; Sat, 13 Nov 2010 17:32:14 +0000 (UTC) Received: from [98.138.90.49] by nm17.bullet.mail.ne1.yahoo.com with NNFMP; 13 Nov 2010 17:32:14 -0000 Received: from [98.138.89.199] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 13 Nov 2010 17:32:14 -0000 Received: from [127.0.0.1] by omp1057.mail.ne1.yahoo.com with NNFMP; 13 Nov 2010 17:32:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 948308.2681.bm@omp1057.mail.ne1.yahoo.com Received: (qmail 64296 invoked by uid 60001); 13 Nov 2010 17:32:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1289669533; bh=Y+ktsLlxK47hRZtO9gDPt3QOlTzQ4RkZR6j/z372dew=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=2pNJRcOnoXNEfpl5SRvzPpc5HkHOCIgc/1XRhqyJKR2dCvPV2mLVdxKtFbVhlB+X1Fb3qQ//U/QlWsln1KDQcU5+b1O8B1uCo7EJROawFZUGreESrllqN5V4zvpRI4EB9L44VPCYg0nMmYpgeiPZGB6p53WOxOm8bOyO/f9e8wU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=XqkNi40a6qfHlWzBo1Q/epqplIFXQFtPgZ9EUMIK4CaeDPImQn4QreQnkYDKugOKONb4ggdJMNVXXtkR1fiPQk/d1NKvlT6oYpnNFXdcmTo89dSF5q51fp1wwd0xaffszyVnShMahtU9Pvt9fBmpV770/T7wO4aDiyXRfNHECGY=; Message-ID: <759081.64178.qm@web120315.mail.ne1.yahoo.com> X-YMail-OSG: MkgLS5IVM1nBd_bI_K5vK42HF0Fv3zoZxavvgoukMCOgPVu rrbBrYRSgmKziRFa3YMngqJA9bwXpNYsG1RlFtCL0cTid.vVfam.jnpJAdw3 JNN9ZLLjDP8_Z2_m2r4rbIBdJYyj9.84SDSFRwm0T24cxa_R2B9D82Aixejd 2gyXgVgWe4tzMasZA0b59KgtOAxktHe4o.aQ5 Received: from [180.68.85.212] by web120315.mail.ne1.yahoo.com via HTTP; Sat, 13 Nov 2010 09:32:13 PST X-Mailer: YahooMailClassic/11.4.9 YahooMailWebService/0.8.107.285259 Date: Sat, 13 Nov 2010 09:32:13 -0800 (PST) From: crocket To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: Keymaps in X11 and consoles should be the same with TEKEN_XTERM 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: Sat, 13 Nov 2010 17:32:15 -0000 Does Delete key match \E[3~ on FreeBSD-CURRENT xterm mode? It's nice to see backspace key match ^?(ASCII DEL), too, since ^H(Ctrl-H) is reserved by such applications as vim and emacs. From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 18:19:05 2010 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 56A531065670; Sat, 13 Nov 2010 18:19:05 +0000 (UTC) (envelope-from jamesbrandongooch@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 635698FC13; Sat, 13 Nov 2010 18:19:04 +0000 (UTC) Received: by wwj40 with SMTP id 40so1127917wwj.31 for ; Sat, 13 Nov 2010 10:19:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gLWMC3n9RgOVqCs8HlNzEPZkHAbNYz215ojbg+6SC2s=; b=lG54Cz4n/BjL8cvnRO18e5p5T+oBkYWGF2a7elEggxx3AUvhwpjkOSuVWBSiqegPu1 6OIusNA6ne1AIHZPKZS9SYVcLBI4sOpSTLMg+uREeNkJBF66gkP0AV4isvT6yAkdjoot CASiUn51FNGdIiSn7KhJC6mJgtyUE6MVkeHDg= 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=b8nZ69wHMurqKcAqlXbaNMpKGGpn9A+E2utgzQjkWBnklR/dqZLsSBxkQQQ7FM/IG1 +Tk4eZlH74RiGyDVAG+MPAsM/vzX3wRDblJXecHNVIBW1AgBdtHbQhwDFKOwSKtjtK4q P2Pz8lZJHbx8jlbfsnAux2YgifnLoHOMXprmA= MIME-Version: 1.0 Received: by 10.216.93.9 with SMTP id k9mr3250012wef.89.1289672343001; Sat, 13 Nov 2010 10:19:03 -0800 (PST) Received: by 10.216.12.80 with HTTP; Sat, 13 Nov 2010 10:19:02 -0800 (PST) In-Reply-To: <4CDE5B8C.4000102@FreeBSD.org> References: <4CD45209.5010607@FreeBSD.org> <4CDE5B8C.4000102@FreeBSD.org> Date: Sat, 13 Nov 2010 12:19:02 -0600 Message-ID: From: Brandon Gooch To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-scsi@freebsd.org, FreeBSD-Current , FreeBSD Stable Subject: Re: Sense fetching [Was: cdrtools /devel ...] 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, 13 Nov 2010 18:19:05 -0000 On Sat, Nov 13, 2010 at 3:34 AM, Alexander Motin wrote: > Brandon Gooch wrote: >> 2010/11/5 Alexander Motin : >>> Hi. >>> >>> I've reviewed tests that scgcheck does to SCSI subsystem. It shown >>> combination of several issues in both CAM, ahci(4) and cdrtools itself. >>> Several small patches allow us to pass most of that tests: >>> http://people.freebsd.org/~mav/sense/ >>> >>> ahci_resid.patch: Add support for reporting residual length on data >>> underrun. SCSI commands often returns results shorter then expected. >>> Returned value allows application to know/check how much data it really >>> has. It is also important for sense fetching, as ATAPI and USB devices >>> return sense as data in response to REQUEST_SENSE command. >>> >>> sense_resid.patch: When manually requesting sense data (ATAPI or USB), >>> request only as much data as user requested (not the fixed structure >>> size), and return respective sense residual length. >>> >>> pass_autosence.patch: Unless CAM_DIS_AUTOSENSE is set, always fetch >>> sense if not done by SIM, independently of CAM_PASS_ERR_RECOVER. As soo= n >>> as device freeze released before returning to user-level, user-level >>> application by definition can't reliably fetch sense data if some other >>> application (like hald) tries to access device same time. >>> >>> cdrtools.patch: Make libscg (part of cdrtools) on FreeBSD to submit >>> wanted sense length to CAM and do not clear sense return buffer. It is >>> mostly cosmetics, important probably only for scgcheck. >>> >>> Testers and reviewers welcome. I am especially interested in opinion >>> about pass_autosence.patch -- may be we should lower sense fetching eve= n >>> deeper, to make it work for all cam_periph_runccb() consumers. >> >> Hey mav, sorry to chime in after so long here, but have some of these >> patches been committed (as of r215179)? >> >> Which patches are still applicable for testing? I assume the cdrtools >> patch for sure... > > Now uncommitted pass_autosence.patch and possibly cdrtools.patch. > OK. Patched kernel and cdrtools has resulted in a working cdrecord (burned an ISO successfully) and an endless stream of: ... (pass0:ata0:0:0:0): Requesting SCSI sense data (pass0:ata0:0:0:0): SCSI status error (pass0:ata0:0:0:0): Requesting SCSI sense data (pass0:ata0:0:0:0): SCSI status error (pass0:ata0:0:0:0): Requesting SCSI sense data (pass0:ata0:0:0:0): SCSI status error (pass0:ata0:0:0:0): Requesting SCSI sense data (pass0:ata0:0:0:0): SCSI status error ... ad infinitum until I start cdrecord: (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): Requesting SCSI sense data (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:4,8 (Logical unit not ready, long write in progress) (cd0:ata0:0:0:0): Error 16, Unretryable error (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): Requesting SCSI sense data (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:4,8 (Logical unit not ready, long write in progress) (cd0:ata0:0:0:0): Error 16, Unretryable error (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): Requesting SCSI sense data (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:4,8 (Logical unit not ready, long write in progress) (cd0:ata0:0:0:0): Error 16, Unretryable error (pass0:ata0:0:0:0): SCSI status error (pass0:ata0:0:0:0): Requesting SCSI sense data cdrecord output: brandon@x300:~$ sudo cdrecord dev=3D0,0,0 Fedora-14-i686-Live-Desktop.iso (11-13 11:41) cdrecord: No write mode specified. cdrecord: Assuming -sao mode. cdrecord: If your drive does not accept -sao, try -tao. cdrecord: Future versions of cdrecord may have different drive dependent defaults. Cdrecord-ProDVD-ProBD-Clone 3.00 (amd64-unknown-freebsd9.0) Copyright (C) 1995-2010 J=F6rg Schilling scsidev: '0,0,0' scsibus: 0 target: 0 lun: 0 Using libscg version 'schily-0.9'. Device type : Removable CD-ROM Version : 0 Response Format: 2 Capabilities : Vendor_info : 'MATSHITA' Identifikation : 'DVD-RAM UJ-844 ' Revision : 'RC02' Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). Driver flags : MMC-3 SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO cdrecord: Warning: Cannot read drive buffer. cdrecord: Warning: The DMA speed test has been skipped. Starting to write CD/DVD/BD at speed 16 in real SAO mode for single session= . Last chance to quit, starting real write 0 seconds. Operation starts. Turning BURN-Free off cdrecord: WARNING: Drive returns wrong startsec (0) using -150 load: 0.00 cmd: cdrecord 2111 [nanslp] 302.32r 0.12u 1.83s 0% 13380k load: 0.00 cmd: cdrecord 2111 [nanslp] 306.11r 0.12u 1.87s 0% 13380k load: 0.00 cmd: cdrecord 2111 [nanslp] 306.66r 0.12u 1.87s 0% 13380k Track 01: Total bytes read/written: 719323136/719323136 (351232 sectors). After cdrecord completed, the messages reappeared on the console: ... (pass0:ata0:0:0:0): Requesting SCSI sense data (pass0:ata0:0:0:0): SCSI status error (pass0:ata0:0:0:0): Requesting SCSI sense data (pass0:ata0:0:0:0): SCSI status error (pass0:ata0:0:0:0): Requesting SCSI sense data (pass0:ata0:0:0:0): SCSI status error (pass0:ata0:0:0:0): Requesting SCSI sense data (pass0:ata0:0:0:0): SCSI status error ... But most important part: It works, and it burned very quickly! The CD was created, and fully functional (I booted the Fedora image and completed an installation). Let me know what's next... -Brandon From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 18:50:02 2010 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 11C0A106566C for ; Sat, 13 Nov 2010 18:50:02 +0000 (UTC) (envelope-from kientzle@FreeBSD.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id CC6DF8FC13 for ; Sat, 13 Nov 2010 18:50:01 +0000 (UTC) Received: from [10.123.2.178] (DIR-655 [192.168.1.65]) by monday.kientzle.com (8.14.3/8.14.3) with ESMTP id oADIDL9q034789 for ; Sat, 13 Nov 2010 18:13:21 GMT (envelope-from kientzle@freebsd.org) From: Tim Kientzle Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 13 Nov 2010 10:13:21 -0800 Message-Id: <8B87F6CB-577B-476F-B6DA-F72E9183AD4C@freebsd.org> To: freebsd-current@FreeBSD.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Cc: Subject: 8-STABLE on -CURRENT with clang? 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, 13 Nov 2010 18:50:02 -0000 Has anyone else tried "make buildworld" on an 8-STABLE checkout on a = recent -CURRENT using clang? I'm seeing failures building GCC and was wondering if this was something = messed-up locally and whether it was worth even trying to fix. Tim From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 18:57:15 2010 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 ED746106564A for ; Sat, 13 Nov 2010 18:57:15 +0000 (UTC) (envelope-from eirnym@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7A8538FC1C for ; Sat, 13 Nov 2010 18:57:15 +0000 (UTC) Received: by bwz2 with SMTP id 2so4058019bwz.13 for ; Sat, 13 Nov 2010 10:57:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=/c+aA4gbP5+RdVFab6DeoV0ZbYApNq5tCKwEeT5j8OY=; b=PAcLxb9uFo/c3LQ0SRQXlIgOTLJhn1RtGJ9vv30twRGf+CknPKWdKgJ5f4bQsrMFs+ MOybBsuDwvrxGIZCep6f+eRjurrw23wGLTm54p0FvEDdwNu3KCuS+foIo/PrHfvIQULf dJepzGFXLoSSG5J5wbQZbczD768kUaTwN+ymc= 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=tjwAXXcEnuSmbhtlt9Dm7ZpQ08JR1TbUak5qgQ8HnH0Uj5J29UnzRUe4ccvLOJZ5g6 aAk7fefIqhwqmyPdbTyh2LU2vfmN0+2eUYKzanHqelrge67ly4071DAkbok8UP711RLj 8Sec0Zc+sjqEwEfPwFQphng4wYgTNfv7UCvoA= MIME-Version: 1.0 Received: by 10.204.119.133 with SMTP id z5mr4265539bkq.82.1289674634381; Sat, 13 Nov 2010 10:57:14 -0800 (PST) Received: by 10.204.123.131 with HTTP; Sat, 13 Nov 2010 10:57:14 -0800 (PST) In-Reply-To: <759081.64178.qm@web120315.mail.ne1.yahoo.com> References: <759081.64178.qm@web120315.mail.ne1.yahoo.com> Date: Sat, 13 Nov 2010 21:57:14 +0300 Message-ID: From: Eir Nym To: crocket Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org Subject: Re: Keymaps in X11 and consoles should be the same with TEKEN_XTERM 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: Sat, 13 Nov 2010 18:57:16 -0000 On 13/11/2010, crocket wrote: > Does Delete key match \E[3~ on FreeBSD-CURRENT xterm mode? > It's nice to see backspace key match ^?(ASCII DEL), too, since ^H(Ctrl-H) is > reserved by such applications as vim and emacs. > For witch action C-H is reserved in vim(1) ? vim, emacs, zsh, and many others use termcap(5) to determine which key generate which sequence. Please note, that xterm and xterm-colors termcap entries are differs, and last is not usable in FreeBSD-CURRENT TEKEN_XTERM console. From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 20:13:05 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 7AF571065750; Sat, 13 Nov 2010 20:13:05 +0000 (UTC) Date: Sat, 13 Nov 2010 20:13:05 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20101113201305.GA93785@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: libc_r removal? 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, 13 Nov 2010 20:13:05 -0000 hi there, any reason to keep lib/libc_r still around? it has been detached from the build process on all supported branches (r162846; 4 years ago). cheers. alex -- a13x From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 20:18:17 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 8AA51106566B; Sat, 13 Nov 2010 20:18:17 +0000 (UTC) Date: Sat, 13 Nov 2010 20:18:17 +0000 From: Alexander Best To: Tim Kientzle Message-ID: <20101113201817.GA95570@freebsd.org> References: <8B87F6CB-577B-476F-B6DA-F72E9183AD4C@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8B87F6CB-577B-476F-B6DA-F72E9183AD4C@freebsd.org> Cc: freebsd-current@FreeBSD.org Subject: Re: 8-STABLE on -CURRENT with clang? 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, 13 Nov 2010 20:18:17 -0000 On Sat Nov 13 10, Tim Kientzle wrote: > Has anyone else tried "make buildworld" on an 8-STABLE checkout on a recent -CURRENT using clang? > > I'm seeing failures building GCC and was wondering if this was something messed-up locally and whether it was worth even trying to fix. can you check if this is the same issue you are experiencing: http://www.mail-archive.com/freebsd-current@freebsd.org/msg126137.html cheers. alex > > Tim > -- a13x From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 20:27:34 2010 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 D8D6B106566C; Sat, 13 Nov 2010 20:27:34 +0000 (UTC) (envelope-from yanegomi@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 467548FC15; Sat, 13 Nov 2010 20:27:33 +0000 (UTC) Received: by wyb36 with SMTP id 36so1197141wyb.13 for ; Sat, 13 Nov 2010 12:27:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=YI/xM2rtWOlsSEcOuQn5zm5t0DZeNDBIZyxJU6e7VGE=; b=oy/q2PLCdqUt7wS0eoaMYCqjJBY4Br9Gc7rdWDOf2JNNjKCKGjQanZWHak/vSjZnXg 36aljDH6J+9LbiKVFGl+ZYdhuNkoOPojPZMXwNELbR1bTqO21Scgw5AGtUBGanQNzCQf 9zv0N1qa7IDtZDHwkMNy9BEDBtWkSAvtotW94= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=uu4+KSwNiy86kmJbeSEbyLoFw7CrqGNMnw6m4r/Xq3v/GLZLM/JbYyz1gpRfGTwcxu nsuJV6hnCnjE1VIy88Rles/EvAKI0bZIovOFKglma0F/L5YjnvBYRf3RbCrOLOSiLqRj sbNRpLULH9n2bXPHSN0lx66EssDVYYy123tJE= MIME-Version: 1.0 Received: by 10.216.175.18 with SMTP id y18mr3949267wel.30.1289680053013; Sat, 13 Nov 2010 12:27:33 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Sat, 13 Nov 2010 12:27:32 -0800 (PST) Date: Sat, 13 Nov 2010 12:27:32 -0800 X-Google-Sender-Auth: dfs28oX4MG-_MYtTafbu_2W3_w8 Message-ID: From: Garrett Cooper To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current Subject: [PATCH] Unbreak buildworld post-r215254 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, 13 Nov 2010 20:27:34 -0000 Looks like buildworld is broken when TARGET/TARGET_ARCH isn't specified: $ make buildworld "/usr/src/Makefile.inc1", line 127: Malformed conditional (${TARGET_ARCH} == "mips" && ${TARGET} == "mips") "/usr/src/Makefile.inc1", line 128: warning: "TARGET_ARCH of mips is deprecated in favor of mipsel or mipseb" "/usr/src/Makefile.inc1", line 134: if-less endif "/usr/src/Makefile.inc1", line 152: Unknown target mipsel:amd64. *** Error code 1 This change fixed it: $ svn diff Makefile.inc1 Index: Makefile.inc1 =================================================================== --- Makefile.inc1 (revision 215254) +++ Makefile.inc1 (working copy) @@ -124,7 +124,8 @@ TARGET= ${TARGET_ARCH:C/mipse[lb]/mips/:C/armeb/arm} .endif # Legacy names, for a transition period mips:mips -> mipsel:mips -.if ${TARGET_ARCH} == "mips" && ${TARGET} == "mips" +.if defined(TARGET_ARCH) && defined(TARGET) && ${TARGET_ARCH} == "mips" && \ + ${TARGET} == "mips" .warning "TARGET_ARCH of mips is deprecated in favor of mipsel or mipseb" .if defined(TARGET_BIG_ENDIAN) TARGET_ARCH=mipseb @@ -133,7 +134,8 @@ .endif .endif # arm with TARGET_BIG_ENDIAN -> armeb -.if ${TARGET_ARCH} == "arm" && defined(TARGET_BIG_ENDIAN) +.if defined(TARGET_ARCH) && ${TARGET_ARCH} == "arm" && \ + defined(TARGET_BIG_ENDIAN) .warning "TARGET_ARCH of arm with TARGET_BIG_ENDIAN is deprecated. use armeb" TARGET_ARCH=armeb .endif Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 22:08:49 2010 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 D90D71065674; Sat, 13 Nov 2010 22:08:49 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B14828FC0C; Sat, 13 Nov 2010 22:08:49 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 58ABE46B2A; Sat, 13 Nov 2010 17:08:49 -0500 (EST) Date: Sat, 13 Nov 2010 22:08:49 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alexander Best In-Reply-To: <20101113124758.GA23469@freebsd.org> Message-ID: References: <20101112223715.GA1356@freebsd.org> <20101113112447.GF2392@deviant.kiev.zoral.com.ua> <20101113115900.GA14975@freebsd.org> <20101113122853.GG2392@deviant.kiev.zoral.com.ua> <20101113123846.GA21390@freebsd.org> <20101113124146.GH2392@deviant.kiev.zoral.com.ua> <20101113124758.GA23469@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kostik Belousov , freebsd-current@freebsd.org Subject: Re: www/chromium crashing whole system 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, 13 Nov 2010 22:08:49 -0000 On Sat, 13 Nov 2010, Alexander Best wrote: >>> i tried detaching and attaching my keyboard after chromium crashed my >>> system and the lights of the keyboard didn't even went on. so in fact >>> everything crashed and not just X. >> If I said it unclear, let me repeat, the usermode crash dump you got >> probably has nothing common with the kernel issue. > > oh sorry. indeed i misunderstood you there. well i guess this is the problem > most regular users have. we don't own any serial/firewire consoles. all i > can offer is to add kernel OPTIONS. however none of them seem to be able to > prevent the lock up and instead letting me enter the debugger or trigger a > kernel core dump. > > i even have watchdog running, but without any sucess. i guess all i can hope > for is that maybe at some point a kernel dump does make it to disk. Do you have a second box you can run X11 on, and SSH into the box that will run Chromium? If it is really Chromium triggering the crash, this might allow you to access the console when it crashes. However, if it's Chromium triggering an X11-related crash, it might well not. (Also, it might well not because of timing differences, but it is worth a try). Another thing to consider is starting Chromium when switched to a text virtual console from X11, which would leave you in text mode for DDB, or at least let you see something interesting on the console. If regular crashdumps appear unreliable, try setting up a textdump with an automatic reboot, that might provde more reliable (small chance, but it could). Robert From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 22:11:39 2010 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 5A358106566B; Sat, 13 Nov 2010 22:11:39 +0000 (UTC) (envelope-from yanegomi@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 8E7DA8FC21; Sat, 13 Nov 2010 22:11:38 +0000 (UTC) Received: by wwj40 with SMTP id 40so1245308wwj.31 for ; Sat, 13 Nov 2010 14:11:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=0ltOnmB3srhFtLRBJIgB5lCSIqxOKAQC/RdVziGZJqk=; b=viZngxfW/XmhuLJNtHpTMQFNnGqdNSTyArGk4i8vVqXz1V+63kJ8aioDbRD1Vr25Mq G0NKVvntj9hIXgTXBuhUDxitxe54vVAgXAVrpwZJGh/lW7Ff6+mQxvr0Hv4YHz0f9xzB knPiEV6EDtIIlVHY4KjHgXj2vVt8DhDaiYQDY= 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=i82fqCwk3dF2mWMVUVMTmPRzZo6DDwG6YyGAgEv4SL3+qsthpDaowkifwh9kIj+4tK AWZvdmq7OyJXZkWC82Tmq7C9fd8V/WzFl1A7ftBOwPH7Tj9Zbz6hp/IrCxzw+jxCXTpc 3qOlLctxhHpodnI6wzxBbqHWEqVO8cSe9o3Ms= MIME-Version: 1.0 Received: by 10.216.175.18 with SMTP id y18mr4030283wel.30.1289686296543; Sat, 13 Nov 2010 14:11:36 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Sat, 13 Nov 2010 14:11:36 -0800 (PST) In-Reply-To: References: <20101112223715.GA1356@freebsd.org> <20101113112447.GF2392@deviant.kiev.zoral.com.ua> <20101113115900.GA14975@freebsd.org> <20101113122853.GG2392@deviant.kiev.zoral.com.ua> <20101113123846.GA21390@freebsd.org> <20101113124146.GH2392@deviant.kiev.zoral.com.ua> <20101113124758.GA23469@freebsd.org> Date: Sat, 13 Nov 2010 14:11:36 -0800 X-Google-Sender-Auth: JEuPzbCbORrt9tK6C6l6NFfGLrs Message-ID: From: Garrett Cooper To: Robert Watson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , Alexander Best , freebsd-current@freebsd.org Subject: Re: www/chromium crashing whole system 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, 13 Nov 2010 22:11:39 -0000 On Sat, Nov 13, 2010 at 2:08 PM, Robert Watson wrote: > > On Sat, 13 Nov 2010, Alexander Best wrote: > >>>> i tried detaching and attaching my keyboard after chromium crashed my >>>> system and the lights of the keyboard didn't even went on. so in fact >>>> everything crashed and not just X. >>> >>> If I said it unclear, let me repeat, the usermode crash dump you got >>> probably has nothing common with the kernel issue. >> >> oh sorry. indeed i misunderstood you there. well i guess this is the >> problem most regular users have. we don't own any serial/firewire consol= es. >> all i can offer is to add kernel OPTIONS. however none of them seem to b= e >> able to prevent the lock up and instead letting me enter the debugger or >> trigger a kernel core dump. >> >> i even have watchdog running, but without any sucess. i guess all i can >> hope for is that maybe at some point a kernel dump does make it to disk. > > Do you have a second box you can run X11 on, and SSH into the box that wi= ll > run Chromium? =A0If it is really Chromium triggering the crash, this migh= t > allow you to access the console when it crashes. =A0However, if it's Chro= mium > triggering an X11-related crash, it might well not. =A0(Also, it might we= ll > not because of timing differences, but it is worth a try). > > Another thing to consider is starting Chromium when switched to a text > virtual console from X11, which would leave you in text mode for DDB, or = at > least let you see something interesting on the console. > > If regular crashdumps appear unreliable, try setting up a textdump with a= n > automatic reboot, that might provde more reliable (small chance, but it > could). Isn't there also DEADLKRES that might be helpful in this case (if Alex is really dealing with a livelock in the kernel)...? Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 22:13:44 2010 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 13518106566B; Sat, 13 Nov 2010 22:13:44 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DD3548FC18; Sat, 13 Nov 2010 22:13:43 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 960AB46B2A; Sat, 13 Nov 2010 17:13:43 -0500 (EST) Date: Sat, 13 Nov 2010 22:13:43 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Garrett Cooper In-Reply-To: Message-ID: References: <20101112223715.GA1356@freebsd.org> <20101113112447.GF2392@deviant.kiev.zoral.com.ua> <20101113115900.GA14975@freebsd.org> <20101113122853.GG2392@deviant.kiev.zoral.com.ua> <20101113123846.GA21390@freebsd.org> <20101113124146.GH2392@deviant.kiev.zoral.com.ua> <20101113124758.GA23469@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kostik Belousov , Alexander Best , freebsd-current@freebsd.org Subject: Re: www/chromium crashing whole system 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, 13 Nov 2010 22:13:44 -0000 On Sat, 13 Nov 2010, Garrett Cooper wrote: > Isn't there also DEADLKRES that might be helpful in this case (if > Alex is really dealing with a livelock in the kernel)...? The deadlock resolver is compiled into the GENERIC kernel on -CURRENT, so I'm assuming it hasn't helped (or perhaps is even part of the problem). I think the best thing to do at this point is to try to get into DDB. Of the schemes I suggested to work around the X11 issue, switching to a virtual console before starting Chromium may work best, since it will continue to use the local X server, etc. Robert From owner-freebsd-current@FreeBSD.ORG Sat Nov 13 22:30:05 2010 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 32D68106566C; Sat, 13 Nov 2010 22:30:05 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-30.mx.aerioconnect.net [216.240.47.90]) by mx1.freebsd.org (Postfix) with ESMTP id F39D78FC18; Sat, 13 Nov 2010 22:30:04 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oADMHY71027668; Sat, 13 Nov 2010 14:17:34 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 9D6452D6014; Sat, 13 Nov 2010 14:17:33 -0800 (PST) Message-ID: <4CDF0E7F.3060406@freebsd.org> Date: Sat, 13 Nov 2010 14:17:35 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Robert Watson References: <20101112223715.GA1356@freebsd.org> <20101113112447.GF2392@deviant.kiev.zoral.com.ua> <20101113115900.GA14975@freebsd.org> <20101113122853.GG2392@deviant.kiev.zoral.com.ua> <20101113123846.GA21390@freebsd.org> <20101113124146.GH2392@deviant.kiev.zoral.com.ua> <20101113124758.GA23469@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: Kostik Belousov , Alexander Best , freebsd-current@freebsd.org Subject: Re: www/chromium crashing whole system 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, 13 Nov 2010 22:30:05 -0000 On 11/13/10 2:08 PM, Robert Watson wrote: > > On Sat, 13 Nov 2010, Alexander Best wrote: > >>>> i tried detaching and attaching my keyboard after chromium >>>> crashed my system and the lights of the keyboard didn't even went >>>> on. so in fact everything crashed and not just X. >>> If I said it unclear, let me repeat, the usermode crash dump you >>> got probably has nothing common with the kernel issue. >> >> oh sorry. indeed i misunderstood you there. well i guess this is >> the problem most regular users have. we don't own any >> serial/firewire consoles. all i can offer is to add kernel OPTIONS. >> however none of them seem to be able to prevent the lock up and >> instead letting me enter the debugger or trigger a kernel core dump. >> >> i even have watchdog running, but without any sucess. i guess all i >> can hope for is that maybe at some point a kernel dump does make it >> to disk. > > Do you have a second box you can run X11 on, and SSH into the box > that will run Chromium? If it is really Chromium triggering the > crash, this might allow you to access the console when it crashes. > However, if it's Chromium triggering an X11-related crash, it might > well not. (Also, it might well not because of timing differences, > but it is worth a try). > > Another thing to consider is starting Chromium when switched to a > text virtual console from X11, which would leave you in text mode > for DDB, or at least let you see something interesting on the console. > > If regular crashdumps appear unreliable, try setting up a textdump > with an automatic reboot, that might provde more reliable (small > chance, but it could). we did have some people working on an ethernet version of the dcons/remote debugging stuff I guess it only supports a small subset of ethernet chips though.. Anyone know the status of that work? > Robert > _______________________________________________ > 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 Sat Nov 13 22:30:05 2010 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 69A421065673; Sat, 13 Nov 2010 22:30:05 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-30.mx.aerioconnect.net [216.240.47.90]) by mx1.freebsd.org (Postfix) with ESMTP id 376F88FC1A; Sat, 13 Nov 2010 22:30:05 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oADMJkro027892; Sat, 13 Nov 2010 14:19:46 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 923572D6011; Sat, 13 Nov 2010 14:19:45 -0800 (PST) Message-ID: <4CDF0F03.10703@freebsd.org> Date: Sat, 13 Nov 2010 14:19:47 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Robert Watson References: <20101112223715.GA1356@freebsd.org> <20101113112447.GF2392@deviant.kiev.zoral.com.ua> <20101113115900.GA14975@freebsd.org> <20101113122853.GG2392@deviant.kiev.zoral.com.ua> <20101113123846.GA21390@freebsd.org> <20101113124146.GH2392@deviant.kiev.zoral.com.ua> <20101113124758.GA23469@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: Kostik Belousov , Alexander Best , freebsd-current@freebsd.org, Garrett Cooper Subject: Re: www/chromium crashing whole system 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, 13 Nov 2010 22:30:05 -0000 On 11/13/10 2:13 PM, Robert Watson wrote: > > On Sat, 13 Nov 2010, Garrett Cooper wrote: > >> Isn't there also DEADLKRES that might be helpful in this case (if >> Alex is really dealing with a livelock in the kernel)...? > > The deadlock resolver is compiled into the GENERIC kernel on > -CURRENT, so I'm assuming it hasn't helped (or perhaps is even part > of the problem). I think the best thing to do at this point is to > try to get into DDB. Of the schemes I suggested to work around the > X11 issue, switching to a virtual console before starting Chromium > may work best, since it will continue to use the local X server, etc. An alternate way of handling this: Turn on the VNC X server and use that from a remote place, leaving the console free. > > Robert > _______________________________________________ > 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 Sat Nov 13 23:38:36 2010 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 A4AC1106564A; Sat, 13 Nov 2010 23:38:36 +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 739B48FC0A; Sat, 13 Nov 2010 23:38:36 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id oADNcZif035137; Sat, 13 Nov 2010 18:38:35 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id oADNcZkA035129; Sat, 13 Nov 2010 23:38:35 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 13 Nov 2010 23:38:35 GMT Message-Id: <201011132338.oADNcZkA035129@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: Sat, 13 Nov 2010 23:38:36 -0000 TB --- 2010-11-13 21:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-13 21:00:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-11-13 21:00:00 - cleaning the object tree TB --- 2010-11-13 21:00:24 - cvsupping the source tree TB --- 2010-11-13 21:00:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-11-13 21:00:51 - building world TB --- 2010-11-13 21:00:51 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-13 21:00:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-13 21:00:51 - TARGET=i386 TB --- 2010-11-13 21:00:51 - TARGET_ARCH=i386 TB --- 2010-11-13 21:00:51 - TZ=UTC TB --- 2010-11-13 21:00:51 - __MAKE_CONF=/dev/null TB --- 2010-11-13 21:00:51 - cd /src TB --- 2010-11-13 21:00:51 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 13 21:00:51 UTC 2010 >>> 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 Sat Nov 13 22:46:32 UTC 2010 TB --- 2010-11-13 22:46:32 - generating LINT kernel config TB --- 2010-11-13 22:46:32 - cd /src/sys/i386/conf TB --- 2010-11-13 22:46:32 - /usr/bin/make -B LINT TB --- 2010-11-13 22:46:32 - building LINT kernel TB --- 2010-11-13 22:46:32 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-13 22:46:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-13 22:46:32 - TARGET=i386 TB --- 2010-11-13 22:46:32 - TARGET_ARCH=i386 TB --- 2010-11-13 22:46:32 - TZ=UTC TB --- 2010-11-13 22:46:32 - __MAKE_CONF=/dev/null TB --- 2010-11-13 22:46:32 - cd /src TB --- 2010-11-13 22:46:32 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Nov 13 22:46:32 UTC 2010 >>> 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 >>> Kernel build for LINT completed on Sat Nov 13 23:13:00 UTC 2010 TB --- 2010-11-13 23:13:00 - building GENERIC kernel TB --- 2010-11-13 23:13:00 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-13 23:13:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-13 23:13:00 - TARGET=i386 TB --- 2010-11-13 23:13:00 - TARGET_ARCH=i386 TB --- 2010-11-13 23:13:00 - TZ=UTC TB --- 2010-11-13 23:13:00 - __MAKE_CONF=/dev/null TB --- 2010-11-13 23:13:00 - cd /src TB --- 2010-11-13 23:13:00 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Nov 13 23:13:00 UTC 2010 >>> 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 >>> Kernel build for GENERIC completed on Sat Nov 13 23:33:39 UTC 2010 TB --- 2010-11-13 23:33:39 - WARNING: no kernel config for GENERIC64 TB --- 2010-11-13 23:33:39 - building PAE kernel TB --- 2010-11-13 23:33:39 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-13 23:33:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-13 23:33:39 - TARGET=i386 TB --- 2010-11-13 23:33:39 - TARGET_ARCH=i386 TB --- 2010-11-13 23:33:39 - TZ=UTC TB --- 2010-11-13 23:33:39 - __MAKE_CONF=/dev/null TB --- 2010-11-13 23:33:39 - cd /src TB --- 2010-11-13 23:33:39 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Sat Nov 13 23:33:40 UTC 2010 >>> 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 -O -pipe -std=c99 -g -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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/xdr/xdr_mbuf.c cc -c -O -pipe -std=c99 -g -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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/xdr/xdr_mem.c cc -c -O -pipe -std=c99 -g -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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/xdr/xdr_reference.c cc -c -O -pipe -std=c99 -g -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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/xdr/xdr_sizeof.c cc -c -O -pipe -std=c99 -g -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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/dev/arcmsr/arcmsr.c cc1: warnings being treated as errors /src/sys/dev/arcmsr/arcmsr.c: In function 'arcmsr_action': /src/sys/dev/arcmsr/arcmsr.c:2475: warning: cast from pointer to integer of different size *** Error code 1 Stop in /obj/i386.i386/src/sys/PAE. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-13 23:38:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-13 23:38:35 - ERROR: failed to build PAE kernel TB --- 2010-11-13 23:38:35 - 7437.82 user 1346.66 system 9515.07 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full