From owner-freebsd-hackers@freebsd.org Sun May 28 04:45:30 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 65FE3D85DA4 for ; Sun, 28 May 2017 04:45:30 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 4FDFE1EAB for ; Sun, 28 May 2017 04:45:30 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from Alfreds-MacBook-Pro-2.local (unknown [IPv6:2601:645:8003:a4d6:3d60:52ca:455b:2dfc]) by elvis.mu.org (Postfix) with ESMTPSA id A70433494EF9; Sat, 27 May 2017 21:45:24 -0700 (PDT) Subject: Re: [PATCH] bitset(9): Add some operations To: Sebastian Huber , freebsd-hackers@freebsd.org References: <1495198830-10573-1-git-send-email-sebastian.huber@embedded-brains.de> From: Alfred Perlstein Organization: FreeBSD Message-ID: Date: Sat, 27 May 2017 21:45:24 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1495198830-10573-1-git-send-email-sebastian.huber@embedded-brains.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 May 2017 04:45:30 -0000 Would you consider using "3" instead of "2" as that would match what machine opcodes typically are named. ex: OR3 instead of OR2. Search for addl3 vs addl2 in this paper: http://minnie.tuhs.org/CompArch/Resources/webext3.pdf -Alfred On 5/19/17 6:00 AM, Sebastian Huber wrote: > Add BIT_OR2(), BIT_AND2(), BIT_NAND2(), BIT_XOR() and BIT_XOR2(). > --- > share/man/man9/bitset.9 | 91 +++++++++++++++++++++++++++++++++++++++++++++++++ > sys/sys/bitset.h | 30 ++++++++++++++++ > 2 files changed, 121 insertions(+) > > diff --git a/share/man/man9/bitset.9 b/share/man/man9/bitset.9 > index ef55115..4842225 100644 > --- a/share/man/man9/bitset.9 > +++ b/share/man/man9/bitset.9 > @@ -48,8 +48,13 @@ > .Nm BIT_OVERLAP , > .Nm BIT_CMP , > .Nm BIT_OR , > +.Nm BIT_OR2 , > .Nm BIT_AND , > +.Nm BIT_AND2 , > .Nm BIT_NAND , > +.Nm BIT_NAND2 , > +.Nm BIT_XOR , > +.Nm BIT_XOR2 , > .Nm BIT_CLR_ATOMIC , > .Nm BIT_SET_ATOMIC , > .Nm BIT_SET_ATOMIC_ACQ , > @@ -95,8 +100,13 @@ > .Fa "const SETSIZE" "struct STRUCTNAME *bitset1" "struct STRUCTNAME *bitset2" > .Fc > .Fn BIT_OR "const SETSIZE" "struct STRUCTNAME *dst" "struct STRUCTNAME *src" > +.Fn BIT_OR2 "const SETSIZE" "struct STRUCTNAME *dst" "struct STRUCTNAME *src1" "struct STRUCTNAME *src2" > .Fn BIT_AND "const SETSIZE" "struct STRUCTNAME *dst" "struct STRUCTNAME *src" > +.Fn BIT_AND2 "const SETSIZE" "struct STRUCTNAME *dst" "struct STRUCTNAME *src1" "struct STRUCTNAME *src2" > .Fn BIT_NAND "const SETSIZE" "struct STRUCTNAME *dst" "struct STRUCTNAME *src" > +.Fn BIT_NAND2 "const SETSIZE" "struct STRUCTNAME *dst" "struct STRUCTNAME *src1" "struct STRUCTNAME *src2" > +.Fn BIT_XOR "const SETSIZE" "struct STRUCTNAME *dst" "struct STRUCTNAME *src" > +.Fn BIT_XOR2 "const SETSIZE" "struct STRUCTNAME *dst" "struct STRUCTNAME *src1" "struct STRUCTNAME *src2" > .\" > .Fn BIT_CLR_ATOMIC "const SETSIZE" "size_t bit" "struct STRUCTNAME *bitset" > .Fn BIT_SET_ATOMIC "const SETSIZE" "size_t bit" "struct STRUCTNAME *bitset" > @@ -312,6 +322,23 @@ is composed of multiple machine words, > performs multiple individually atomic operations.) > .Pp > The > +.Fn BIT_OR2 > +macro computes > +.Fa src1 > +bitwise or > +.Fa src2 > +and assigns the result to > +.Fa dst . > +(It is the > +.Nm > +equivalent of the scalar: > +.Fa dst > += > +.Fa src1 > +| > +.Fa src2 . ) > +.Pp > +The > .Fn BIT_AND > macro clears bits absent from > .Fa src > @@ -328,6 +355,23 @@ is similar, with the same atomic semantics as > .Fn BIT_OR_ATOMIC . > .Pp > The > +.Fn BIT_AND2 > +macro computes > +.Fa src1 > +bitwise and > +.Fa src2 > +and assigns the result to > +.Fa dst . > +(It is the > +.Nm > +equivalent of the scalar: > +.Fa dst > += > +.Fa src1 > +& > +.Fa src2 . ) > +.Pp > +The > .Fn BIT_NAND > macro clears bits set in > .Fa src > @@ -339,6 +383,53 @@ equivalent of the scalar: > .Fa dst > &= > .Fa ~ src . ) > +.Pp > +The > +.Fn BIT_NAND2 > +macro computes > +.Fa src1 > +bitwise and not > +.Fa src2 > +and assigns the result to > +.Fa dst . > +(It is the > +.Nm > +equivalent of the scalar: > +.Fa dst > += > +.Fa src1 > +& ~ > +.Fa src2 . ) > +.Pp > +The > +.Fn BIT_XOR > +macro toggles bits set in > +.Fa src > +in > +.Fa dst . > +(It is the > +.Nm > +equivalent of the scalar: > +.Fa dst > +^= > +.Fa src . ) > +.Pp > +The > +.Fn BIT_XOR2 > +macro computes > +.Fa src1 > +bitwise exclusive or > +.Fa src2 > +and assigns the result to > +.Fa dst . > +(It is the > +.Nm > +equivalent of the scalar: > +.Fa dst > += > +.Fa src1 > +^ > +.Fa src2 . ) > .Sh BITSET_T_INITIALIZER EXAMPLE > .Bd -literal > BITSET_DEFINE(_myset, MYSETSIZE); > diff --git a/sys/sys/bitset.h b/sys/sys/bitset.h > index 723c39b..8bc9e3d 100644 > --- a/sys/sys/bitset.h > +++ b/sys/sys/bitset.h > @@ -122,18 +122,48 @@ > (d)->__bits[__i] |= (s)->__bits[__i]; \ > } while (0) > > +#define BIT_OR2(_s, d, s1, s2) do { \ > + __size_t __i; \ > + for (__i = 0; __i < __bitset_words((_s)); __i++) \ > + (d)->__bits[__i] = (s1)->__bits[__i] | (s2)->__bits[__i];\ > +} while (0) > + > #define BIT_AND(_s, d, s) do { \ > __size_t __i; \ > for (__i = 0; __i < __bitset_words((_s)); __i++) \ > (d)->__bits[__i] &= (s)->__bits[__i]; \ > } while (0) > > +#define BIT_AND2(_s, d, s1, s2) do { \ > + __size_t __i; \ > + for (__i = 0; __i < __bitset_words((_s)); __i++) \ > + (d)->__bits[__i] = (s1)->__bits[__i] & (s2)->__bits[__i];\ > +} while (0) > + > #define BIT_NAND(_s, d, s) do { \ > __size_t __i; \ > for (__i = 0; __i < __bitset_words((_s)); __i++) \ > (d)->__bits[__i] &= ~(s)->__bits[__i]; \ > } while (0) > > +#define BIT_NAND2(_s, d, s1, s2) do { \ > + __size_t __i; \ > + for (__i = 0; __i < __bitset_words((_s)); __i++) \ > + (d)->__bits[__i] = (s1)->__bits[__i] & ~(s2)->__bits[__i];\ > +} while (0) > + > +#define BIT_XOR(_s, d, s) do { \ > + __size_t __i; \ > + for (__i = 0; __i < __bitset_words((_s)); __i++) \ > + (d)->__bits[__i] ^= (s)->__bits[__i]; \ > +} while (0) > + > +#define BIT_XOR2(_s, d, s1, s2) do { \ > + __size_t __i; \ > + for (__i = 0; __i < __bitset_words((_s)); __i++) \ > + (d)->__bits[__i] = (s1)->__bits[__i] ^ (s2)->__bits[__i];\ > +} while (0) > + > #define BIT_CLR_ATOMIC(_s, n, p) \ > atomic_clear_long(&(p)->__bits[__bitset_word(_s, n)], \ > __bitset_mask((_s), n)) From owner-freebsd-hackers@freebsd.org Sun May 28 08:11:14 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B947ED859F1 for ; Sun, 28 May 2017 08:11:14 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from rayleigh.systella.fr (rayleigh.systella.fr [213.41.150.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "rayleigh.systella.fr", Issuer "rayleigh.systella.fr" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6BF7318C9 for ; Sun, 28 May 2017 08:11:14 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from [192.168.10.20] ([192.168.10.20]) (authenticated bits=0) by rayleigh.systella.fr (8.15.2/8.15.2/Debian-8) with ESMTPSA id v4S8AlhA002026 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Sun, 28 May 2017 10:10:52 +0200 Subject: Deadlock in pkg_jobs_update_universe_item_priority was Re: Issue with pkg upgrade on diskless workstation To: freebsd-hackers@freebsd.org, pkgsrc-users@NetBSD.org References: <20170514082046.GA15092@lonesome.com> From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= Message-ID: <6c18a445-93c6-8a65-cc0c-eedbef3eabc1@systella.fr> Date: Sun, 28 May 2017 10:10:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at rayleigh X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 May 2017 08:11:14 -0000 Hello, Deadlock I have seen is not related to NFS locks. I have added some debug traces in libpkg and I have seen that pkg enters in deadlock in pkg_jobs_update_universe_item_priority() function. More precisely, a loop doesn't end : line 712 of pkg_jobs_universe.c while (rdeps_func(it->pkg, &d) == EPKG_OK) { HASH_FIND_STR(universe->items, d->uid, found); if (found == NULL) { continue; } LL_FOREACH(found, cur) { ... } } Best regards, JKB From owner-freebsd-hackers@freebsd.org Sun May 28 13:35:06 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B1E3FD85058 for ; Sun, 28 May 2017 13:35:06 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6F0681C31; Sun, 28 May 2017 13:35:06 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from [78.47.166.52] (helo=sslproxy04.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1dEyLR-00057Q-7c; Sun, 28 May 2017 15:34:57 +0200 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy04.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dEyLQ-0004iN-VI; Sun, 28 May 2017 15:34:57 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id CB91B2A0929; Sun, 28 May 2017 15:35:43 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Nge0AxUQvdcW; Sun, 28 May 2017 15:35:41 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 8B2262A160A; Sun, 28 May 2017 15:35:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id khCNd1acDfa3; Sun, 28 May 2017 15:35:41 +0200 (CEST) Received: from zimbra.eb.localhost (zimbra.eb.localhost [192.168.96.204]) by mail.embedded-brains.de (Postfix) with ESMTP id 74D4E2A0929; Sun, 28 May 2017 15:35:41 +0200 (CEST) Date: Sun, 28 May 2017 15:35:41 +0200 (CEST) From: Sebastian Huber To: Alfred Perlstein Cc: freebsd-hackers@freebsd.org Message-ID: <1209023277.129369.1495978541048.JavaMail.zimbra@embedded-brains.de> In-Reply-To: References: <1495198830-10573-1-git-send-email-sebastian.huber@embedded-brains.de> Subject: Re: [PATCH] bitset(9): Add some operations MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.96.204] X-Mailer: Zimbra 8.7.2_GA_1736 (zclient/8.7.2_GA_1736) Thread-Topic: bitset(9): Add some operations Thread-Index: sPzf2sz/ZR2Crn0LLI08nE4iSKWFUw== X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.99.2/23425/Sun May 28 11:00:11 2017) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 May 2017 13:35:06 -0000 Hello Alfred, ----- Alfred Perlstein schrieb: > Would you consider using "3" instead of "2" as that would match what > machine opcodes typically are named. ex: OR3 instead of OR2. my reasoning was that the existing macros had one input operand and the new have two input operands. The existing macros don't follow your pattern. If you really don't like the new names, we can change them of course. > > Search for addl3 vs addl2 in this paper: > http://minnie.tuhs.org/CompArch/Resources/webext3.pdf I don't know a second architecture that has such opcode names. On most architectures the assembler is smart enough to figure out the number of operands. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber at embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. From owner-freebsd-hackers@freebsd.org Mon May 29 11:22:36 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45CD6CFC5A1 for ; Mon, 29 May 2017 11:22:36 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 237B6757DA for ; Mon, 29 May 2017 11:22:36 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: by mailman.ysv.freebsd.org (Postfix) id 22C89CFC5A0; Mon, 29 May 2017 11:22:36 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 225CECFC59F for ; Mon, 29 May 2017 11:22:36 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DE3E8757D8 for ; Mon, 29 May 2017 11:22:35 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: by mail-yw0-x235.google.com with SMTP id l74so27440405ywe.2 for ; Mon, 29 May 2017 04:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuxi-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=L+x+ScOAM7QEQI19e2QFGDbnCdeHtEBfDuhHCMgdI2g=; b=rTELPCtFKCbLvkiqdUlx6PC/y5aFUUqwqweOvhQ2qnOpvADlGdn9M4qDaZDuFyMQ8R l5uQiXyLA3I8NRhr5+GkuvpqHBQ3T8mroTTRdSAr7vVeQTAZFsW5NCaQ8slfoVfVkL6F QsRSJazM5Wt8JBcPVHuCqJHRbxnf3a+Mg94L7nbos/G2Z/oh+cb9+rh+A1yMAMavlcIl d5D+4yPDLEPGwdtwZkOHGfG9+4owcT5sd9K4DQhQzEENF1Ft5x+lrGahJVLv1+mWpteQ YauB9NyUcqkYiy54KmXWzDvXe0x9wofXVW8huZopBRp8Vec6YjKp2j1HgyLGHcSkopk7 IDcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=L+x+ScOAM7QEQI19e2QFGDbnCdeHtEBfDuhHCMgdI2g=; b=JVjrGDNEV5ujP5Q/T9PmSTxtWLh57O2o2uNhcu2ox+X6gLPU3Di5f4tHRhRTJ4XDtC XFKFySMATj5hRU8sW7+PkE5HrSC/3KzwRn110OjuFrFsSBr1zOeFNvgrj+JlL6IEOsq3 y2sjTLGaDvNzOam5kOL/v5IAPlLTmN8vOXKA5cg05G0rJwtZAWzRLF/UCw8zaAeM9lIF va6xAUX2HRLJ/EZhTAPuCKXPm5kiW2UPNgSxaDK0DZUW/59tI7+dhAtJB6GtHvJSa02s 703eyyZVn/+AwVL+2VPZYbj9NluVkl4rcyUsEjYl6EZjNjSjrV4CNf/SXoV6gCifeWZ+ VAxw== X-Gm-Message-State: AODbwcCDSere36ReQ/ucPnrWB6STvCmjBeCey6KclIFSkQxFfqbVfQ+q Cs4LNRskurcOPGlFY+QV+Io0cbRSIirN X-Received: by 10.13.234.16 with SMTP id t16mr11513474ywe.150.1496056954947; Mon, 29 May 2017 04:22:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.114.85 with HTTP; Mon, 29 May 2017 04:22:04 -0700 (PDT) In-Reply-To: <20170524085514.GA4210@brick> References: <20170524085514.GA4210@brick> From: Ed Schouten Date: Mon, 29 May 2017 13:22:04 +0200 Message-ID: Subject: Re: Serial line terminal size. To: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Cc: hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 11:22:36 -0000 Hi Edward, 2017-05-24 10:55 GMT+02:00 Edward Tomasz Napiera=C5=82a = : > There's a problem with serial consoles - after logging in, the terminal > size is not set, ie it looks like this (notice the "0 rows; 0 columns;"): Wouldn't it make more sense for getty to set this up properly, as opposed to putting it in all of the shell rc files? --=20 Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 From owner-freebsd-hackers@freebsd.org Mon May 29 14:20:12 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A295FD27415 for ; Mon, 29 May 2017 14:20:12 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 8AC717B6A4 for ; Mon, 29 May 2017 14:20:12 +0000 (UTC) (envelope-from ian@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 8730BD27413; Mon, 29 May 2017 14:20:12 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86AA0D27412 for ; Mon, 29 May 2017 14:20:12 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1C5257B6A3 for ; Mon, 29 May 2017 14:20:11 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: c42e0453-4479-11e7-b96e-2378c10e3beb X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id c42e0453-4479-11e7-b96e-2378c10e3beb; Mon, 29 May 2017 14:19:04 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v4TEItOn001209; Mon, 29 May 2017 08:18:55 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1496067535.95269.1.camel@freebsd.org> Subject: Re: Serial line terminal size. From: Ian Lepore To: Ed Schouten , Edward Tomasz =?iso-8859-2?Q?Napiera=B3a?= Cc: hackers@freebsd.org Date: Mon, 29 May 2017 08:18:55 -0600 In-Reply-To: References: <20170524085514.GA4210@brick> Content-Type: text/plain; charset="iso-8859-2" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 14:20:12 -0000 On Mon, 2017-05-29 at 13:22 +0200, Ed Schouten wrote: > Hi Edward, > > 2017-05-24 10:55 GMT+02:00 Edward Tomasz Napierała >: > > > > There's a problem with serial consoles - after logging in, the > > terminal > > size is not set, ie it looks like this (notice the "0 rows; 0 > > columns;"): > Wouldn't it make more sense for getty to set this up properly, as > opposed to putting it in all of the shell rc files? > I was thinking exactly the same thing a few days ago, but then I looked at the source code to getty and kinda backed away slowly and quietly, as one might do with any sleeping monster. -- Ian From owner-freebsd-hackers@freebsd.org Mon May 29 14:58:54 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55F46D4E514 for ; Mon, 29 May 2017 14:58:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 304707CC75 for ; Mon, 29 May 2017 14:58:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 2F7F6D4E513; Mon, 29 May 2017 14:58:54 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F154D4E512 for ; Mon, 29 May 2017 14:58:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 05C107CC74 for ; Mon, 29 May 2017 14:58:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x233.google.com with SMTP id a10so7750187itg.1 for ; Mon, 29 May 2017 07:58:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=6nuqCKebmhI407+fLZyDnvPO3/Q5E+6FFPzePUhaIx8=; b=kDOuwAtnlMXrdnriR+pt4lha24nGjjtWvVhHSqqfCp2YeCy/fuXDoIU1S2s9pf7Vjb 1xwcicYqN21Ao66IN5BRBUjNAaWYlkwQUuL39F16wb30wIflisoXZS1ILfPtTuHzUm2r xGEb02g5Ny3dVsvXE0U0dHQLMR5sOtJlfsLbuo9qSjrvMa8xuPfrdFkmNjh5LtDeCzV5 MYyYZ79Ooq0bQ0mZAwsG5V1OoWgo0uHG1/ZNifi3QlZuj4e5eORQSXtFuLHZOC9txp35 vGr79BtFn8ExIoXO1eaUKh3EWwKWGEKTxEWvCAjf2MAqByTESL6l30XnsPAcoLQjqzwQ jtig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=6nuqCKebmhI407+fLZyDnvPO3/Q5E+6FFPzePUhaIx8=; b=PQOLtkDDEnl2m3JA03VpV0tlqVQbY/+s+87ed52lKZX6zn4LblT1hLn9NDCIetAsT7 DmqLAJNVrVxvPEgbgkPO0hHwjf/osbBoYEdcQ5W3XfA0S5BxTRpE2w+u4VCOvX0jgLEo YZn5Wd+4d2BnMeIWBwaZ2pzZ1IDMXkke27BnBEMEtKnloYOFvY3bD5UVEE1n/+GmmD9J a67P957Ew8v3hHYfdvZYWELsPui8xH0GFQBn1XUDfgbQFECSaSGcpF0Qmzxgj1XC29Ae HlK7NEUP9HWS121HC2Nby3mquhu6tIGYQ+8KtQYtAQaKqwlENz6+P1bjjo6SuwY0x8SX fRig== X-Gm-Message-State: AODbwcA+xiXXEoNdaaZK0If8QhP+giWReIPU6CiuPdKufHQKO1t1fD6q h4LGNcbOt7RT6s5qefgubYToqmdUpQrm X-Received: by 10.36.83.145 with SMTP id n139mr14558590itb.0.1496069933143; Mon, 29 May 2017 07:58:53 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.192.69 with HTTP; Mon, 29 May 2017 07:58:52 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: References: <20170524085514.GA4210@brick> From: Warner Losh Date: Mon, 29 May 2017 08:58:52 -0600 X-Google-Sender-Auth: yg1TJCdWyN4DmBNacxJPWVJlgHk Message-ID: Subject: Re: Serial line terminal size. To: Ed Schouten Cc: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 14:58:54 -0000 On Mon, May 29, 2017 at 5:22 AM, Ed Schouten wrote: > Hi Edward, > > 2017-05-24 10:55 GMT+02:00 Edward Tomasz Napiera=C5=82a : > > There's a problem with serial consoles - after logging in, the terminal > > size is not set, ie it looks like this (notice the "0 rows; 0 columns;"= ): > > Wouldn't it make more sense for getty to set this up properly, as > opposed to putting it in all of the shell rc files? > No. It wouldn't. You couldn't turn it off then. Warner From owner-freebsd-hackers@freebsd.org Mon May 29 18:23:31 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 37217D7D1C7 for ; Mon, 29 May 2017 18:23:31 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 112FF84B8F for ; Mon, 29 May 2017 18:23:31 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 0D77ED7D1C6; Mon, 29 May 2017 18:23:31 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0D0C2D7D1C5 for ; Mon, 29 May 2017 18:23:31 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A32FA84B8E; Mon, 29 May 2017 18:23:30 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-wm0-x22c.google.com with SMTP id 7so64782508wmo.1; Mon, 29 May 2017 11:23:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=3RyIMqaAXC37svXPdON64cN4U82qb39ZOuLJBvD510o=; b=AKBVhAB6MGvYUWnjFU7bZda3PiEbrXhjZeZTe1O+BuIZ1pJidaAwRWHg2k+KJZbeVk VkU6IlQ4BapLB3G12ScCGXTm87wISzt3zv/RjBB8nKiQJcqxzh96BnKc2yw6vlHDYzJx uHSGCsqEgkXif29KMYD46jzMppPWLsEf1pTBjS7hklMIi46XxD4RTt6SUlWEebk+HDyx pMeXYykuXzjr4IRYy6nyEDRfJ5dRrOkhcpbY+82UVyVFANaioRXkDiMuTsu7pVBzL+1O jKdoj4pn/OPBC0zBl4FZInZxuhpVdJ5Rq55ePCz9WL30v7JFIwtb6wt4awv/HpEmYzpN EhjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=3RyIMqaAXC37svXPdON64cN4U82qb39ZOuLJBvD510o=; b=qyVPp8W3ZO09FFl31BDgxYZ6sWalrSzTAUdrFFj88++H6yDdhI98VIaFNACyFJZOzg XJfycfnxAlQMUMZgk7C0gHnpnpOwh2Hke9l+thI7QyslB0Wzh8/oyhmZoitI6im0Ekbw D75ROVdJTZKN6+in9cHn9YcPcIcBbnrUk4JO1CQOjwQHSl1OJvAAdO0oNHGI+kaIrHVC CdCFhW7rmuX64/kLyjILzFuNH/RO0f7VW2n3U7rUy+piwprmvelZlthyb6trJkyf9+Pz EUV8OmbKcWJST3ZmusYO507xR91mqXnn2mMsPbZ9/oKMGGfBmM5Lvjw8VY6Ef33yOPxJ nyvg== X-Gm-Message-State: AODbwcCQ/ATuoNsz7nLw8yN/gFWzP3h9MCfkZABev3omsIrRdA9iK1sZ +OtET7nhtSzrpw== X-Received: by 10.223.170.195 with SMTP id i3mr13816110wrc.49.1496082209158; Mon, 29 May 2017 11:23:29 -0700 (PDT) Received: from brick (cpc92310-cmbg19-2-0-cust934.5-4.cable.virginm.net. [82.9.227.167]) by smtp.gmail.com with ESMTPSA id m17sm12318824wmi.6.2017.05.29.11.23.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 May 2017 11:23:28 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Mon, 29 May 2017 19:23:26 +0100 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: "Rodney W. Grimes" Cc: Ian Lepore , Ed Schouten , hackers@freebsd.org Subject: Re: Serial line terminal size. Message-ID: <20170529182326.GB25108@brick> References: <1496067535.95269.1.camel@freebsd.org> <201705291810.v4TIATJx023275@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201705291810.v4TIATJx023275@pdx.rh.CN85.dnsmgr.net> User-Agent: Mutt/1.8.2 (2017-04-18) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 18:23:31 -0000 On 0529T1110, Rodney W. Grimes wrote: > [ Charset ISO-8859-2 unsupported, converting... ] > > On Mon, 2017-05-29 at 13:22 +0200, Ed Schouten wrote: > > > Hi Edward, > > > > > > 2017-05-24 10:55 GMT+02:00 Edward Tomasz Napiera?a > > >: > > > > > > > > There's a problem with serial consoles - after logging in, the > > > > terminal > > > > size is not set, ie it looks like this (notice the "0 rows; 0 > > > > columns;"): > > > Wouldn't it make more sense for getty to set this up properly, as > > > opposed to putting it in all of the shell rc files? > > > > > > > I was thinking exactly the same thing a few days ago, but then I looked > > at the source code to getty and kinda backed away slowly and quietly, > > as one might do with any sleeping monster. > > Now that I can agree with. Getty has never been a friendly place. > > I also think this belongs in Getty despite Warners concern that you > can not turn it off, as Getty alread does Termios stuff, which > you control via /etc/ttys, so there is a place to make a knob should > it be implemented in getty. It's still something that the _user_ - as opposed to the system administrator - couldn't turn off. Not sure it's actually important, though. > This is a specific issue to hardwired terminals, which is what > getty was written for. > > It could also fixes the issues that I have pointed out in > https://reviews.freebsd.org/D10642 with col/row not being > reset between logins which yields the propose patch ineffective. If getty did reset the terminal size upon logoff, that would unbreak the mechanism. Now, why doesn't it do that? Isn't it expected to do so - to revert the terminal and serial port to some predefined initial state? If it does - why doesn't this include the terminal size? From owner-freebsd-hackers@freebsd.org Mon May 29 18:10:40 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3B429D7CA70 for ; Mon, 29 May 2017 18:10:40 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 25B4183F27 for ; Mon, 29 May 2017 18:10:40 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 21A37D7CA6F; Mon, 29 May 2017 18:10:40 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2136DD7CA6E for ; Mon, 29 May 2017 18:10:40 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EE56983F26; Mon, 29 May 2017 18:10:39 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v4TIATN1023276; Mon, 29 May 2017 11:10:29 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v4TIATJx023275; Mon, 29 May 2017 11:10:29 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201705291810.v4TIATJx023275@pdx.rh.CN85.dnsmgr.net> Subject: Re: Serial line terminal size. In-Reply-To: <1496067535.95269.1.camel@freebsd.org> To: Ian Lepore Date: Mon, 29 May 2017 11:10:29 -0700 (PDT) CC: Ed Schouten , =?ISO-8859-2?Q?Edward_Tomasz_Napiera=B3a?= , hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Mon, 29 May 2017 20:31:17 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 18:10:40 -0000 [ Charset ISO-8859-2 unsupported, converting... ] > On Mon, 2017-05-29 at 13:22 +0200, Ed Schouten wrote: > > Hi Edward, > > > > 2017-05-24 10:55 GMT+02:00 Edward Tomasz Napiera?a > >: > > > > > > There's a problem with serial consoles - after logging in, the > > > terminal > > > size is not set, ie it looks like this (notice the "0 rows; 0 > > > columns;"): > > Wouldn't it make more sense for getty to set this up properly, as > > opposed to putting it in all of the shell rc files? > > > > I was thinking exactly the same thing a few days ago, but then I looked > at the source code to getty and kinda backed away slowly and quietly, > as one might do with any sleeping monster. Now that I can agree with. Getty has never been a friendly place. I also think this belongs in Getty despite Warners concern that you can not turn it off, as Getty alread does Termios stuff, which you control via /etc/ttys, so there is a place to make a knob should it be implemented in getty. This is a specific issue to hardwired terminals, which is what getty was written for. It could also fixes the issues that I have pointed out in https://reviews.freebsd.org/D10642 with col/row not being reset between logins which yields the propose patch ineffective. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Mon May 29 18:33:53 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C56BD7D4BC for ; Mon, 29 May 2017 18:33:53 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 1526C850F7 for ; Mon, 29 May 2017 18:33:53 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 11B2BD7D4BB; Mon, 29 May 2017 18:33:53 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11651D7D4BA for ; Mon, 29 May 2017 18:33:53 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A697F850EF; Mon, 29 May 2017 18:33:52 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v4TIXp4m023461; Mon, 29 May 2017 11:33:51 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v4TIXpZ5023460; Mon, 29 May 2017 11:33:51 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201705291833.v4TIXpZ5023460@pdx.rh.CN85.dnsmgr.net> Subject: Re: Serial line terminal size. In-Reply-To: <20170529182326.GB25108@brick> To: "Edward Tomasz Napiera?a" Date: Mon, 29 May 2017 11:33:51 -0700 (PDT) CC: hackers@freebsd.org, Ian Lepore , Ed Schouten X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Mon, 29 May 2017 20:32:00 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 18:33:53 -0000 > On 0529T1110, Rodney W. Grimes wrote: > > [ Charset ISO-8859-2 unsupported, converting... ] > > > On Mon, 2017-05-29 at 13:22 +0200, Ed Schouten wrote: > > > > Hi Edward, > > > > > > > > 2017-05-24 10:55 GMT+02:00 Edward Tomasz Napiera?a > > > >: > > > > > > > > > > There's a problem with serial consoles - after logging in, the > > > > > terminal > > > > > size is not set, ie it looks like this (notice the "0 rows; 0 > > > > > columns;"): > > > > Wouldn't it make more sense for getty to set this up properly, as > > > > opposed to putting it in all of the shell rc files? > > > > > > > > > > I was thinking exactly the same thing a few days ago, but then I looked > > > at the source code to getty and kinda backed away slowly and quietly, > > > as one might do with any sleeping monster. > > > > Now that I can agree with. Getty has never been a friendly place. > > > > I also think this belongs in Getty despite Warners concern that you > > can not turn it off, as Getty alread does Termios stuff, which > > you control via /etc/ttys, so there is a place to make a knob should > > it be implemented in getty. > > It's still something that the _user_ - as opposed to the system > administrator - couldn't turn off. Not sure it's actually important, > though. > > > This is a specific issue to hardwired terminals, which is what > > getty was written for. > > > > It could also fixes the issues that I have pointed out in > > https://reviews.freebsd.org/D10642 with col/row not being > > reset between logins which yields the propose patch ineffective. > > If getty did reset the terminal size upon logoff, that would unbreak > the mechanism. Now, why doesn't it do that? Isn't it expected to > do so - to revert the terminal and serial port to some predefined > initial state? If it does - why doesn't this include the terminal > size? I have a feeling that issue is in the tty layer, or perhaps getty is not closing the terminal so that the reset mechanism can fire. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Tue May 30 01:48:37 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D5F68D89587 for ; Tue, 30 May 2017 01:48:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-63.reflexion.net [208.70.210.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8B3936FE52 for ; Tue, 30 May 2017 01:48:36 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18216 invoked from network); 30 May 2017 01:49:49 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 30 May 2017 01:49:49 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Mon, 29 May 2017 21:48:30 -0400 (EDT) Received: (qmail 9279 invoked from network); 30 May 2017 01:48:30 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 May 2017 01:48:30 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 5AE35EC7652; Mon, 29 May 2017 18:48:29 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: cpuset_setithread and PROC_LOCK vs. thread_lock usage: Is this correct? Message-Id: <433AC404-E85D-4910-8638-4EBC3ACBBCDB@dsl-only.net> Date: Mon, 29 May 2017 18:48:28 -0700 Cc: FreeBSD PowerPC ML To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 01:48:37 -0000 [FYI: The source referenced is from head -r317820.] In the process of trying to get evidence related to a periodic/random kernel panic for TARGET_ARCH=3Dpowerpc I ran into what follows. I've no evidence that it is tied to the panics. It is just something that I read that looked a little odd to me. But it looked like a good thing to ask about, at least based on my level of ignorance of such things for the kernel. (The more I learn the better.) I normally see the likes of: thread_lock(td); tdset =3D td->td_cpuset; and: thread_lock(td); error =3D cpuset_shadow(td->td_cpuset, nset, mask); but in cpuset_setithread the comments read like a PROC_LOCK is in use instead: int cpuset_setithread(lwpid_t id, int cpu) { . . . struct proc *p; . . . error =3D cpuset_which(CPU_WHICH_TID, id, &p, &td, &old_set); if (error !=3D 0 || ((cs_id =3D alloc_unr(cpuset_unr)) =3D=3D = CPUSET_INVALID)) goto out; /* cpuset_which() returns with PROC_LOCK held. */ old_set =3D td->td_cpuset; . . . That seems true for !error but is a different lock than used elsewhere (those thread_lock's). cpuset_which does seem to end up with the PROC_LOCK as indicated: int cpuset_which(cpuwhich_t which, id_t id, struct proc **pp, struct thread = **tdp, struct cpuset **setp) { . . . case CPU_WHICH_TID: if (id =3D=3D -1) { PROC_LOCK(curproc); p =3D curproc; td =3D curthread; break; } td =3D tdfind(id, -1); if (td =3D=3D NULL) return (ESRCH); p =3D td->td_proc; break; . . . error =3D p_cansched(curthread, p); if (error) { PROC_UNLOCK(p); return (error); } if (td =3D=3D NULL) td =3D FIRST_THREAD_IN_PROC(p); *pp =3D p; *tdp =3D td; return (0); } (tdfind does rw_rlock on tidhash_lock, PROC_LOCK on td->td_proc. It only PROC_UNLOCK's for PRS_NEW and is comments to return with the proc lock held. No thread_lock's involved.) So it appears to me that in cpuset_setithread : /* cpuset_which() returns with PROC_LOCK held. */ old_set =3D td->td_cpuset; might happen with no thread_lock protecting the td use (say to avoid reading during updates). (This might also apply to what old_set points to.) Similarly for: cpuset_setithread(lwpid_t id, int cpu) { . . . struct cpuset *parent, *old_set; . . . error =3D cpuset_shadow(parent, nset, &mask); . . . it does not appear that a thread_lock is involved around the cpuset_shadow operation, unlike elsewhere. Is this lack of thread_lock involvement in fact okay for some reason in each case? =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Tue May 30 04:11:38 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4A6CAFB0AB for ; Tue, 30 May 2017 04:11:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-63.reflexion.net [208.70.210.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9DEA57667A for ; Tue, 30 May 2017 04:11:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 763 invoked from network); 30 May 2017 04:11:36 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 30 May 2017 04:11:36 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 30 May 2017 00:11:36 -0400 (EDT) Received: (qmail 29728 invoked from network); 30 May 2017 04:11:36 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 May 2017 04:11:36 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id AD683EC8FB8; Mon, 29 May 2017 21:11:35 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: A good backtrace from a head -r317820 powerpc random/periodic panic: execution of garbage at 0x0090a030 (in .hash section) [more analysis; corrections] Date: Mon, 29 May 2017 21:11:35 -0700 References: <1CE8346B-04F3-48AB-A3E9-6DF3B86B8D1A@dsl-only.net> <8C88BB6F-E747-42A1-9DDC-35EC6D865141@dsl-only.net> <83A22794-AD54-4D27-951A-986E6FA693DB@dsl-only.net> To: Justin Hibbits , Nathan Whitehorn , FreeBSD PowerPC ML , freebsd-hackers@freebsd.org In-Reply-To: <83A22794-AD54-4D27-951A-986E6FA693DB@dsl-only.net> Message-Id: X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 04:11:39 -0000 On 2017-May-27, at 4:40 AM, Mark Millard wrote: > [I compare a new panic's register values > to prior panic's values.] >=20 > On 2017-May-26, at 10:29 PM, Mark Millard wrote: >=20 >> [Additional information that does not need to >> interlace with the prior material, so see >> after. A somewhat better backtrace reported >> by ddb. And so on.] >>=20 >>=20 >> On 2017-May-26, at 7:14 PM, Mark Millard = wrote: >>=20 >>> I lucked out and got a vmcore.9 for a random >>> panic that I could manage to backtrace for >>> one of my test builds of -r317820. It appears >>> that not all that much happened before it got >>> the panic so much context was better preserved >>> this time. >>>=20 >>> (I do not explore from ddb as I've had that >>> panic and mess up the dump just made by >>> replacing it. So this is a manual backtrace >>> from the debug.minidump=3D0 style vmcore.9 >>> file. objdump was used on the >>> /boot/kernel/kernel to find code.) >>>=20 >>> Being able to see the problem is very >>> sensitive to kernel memory layout. This >>> is why I'm sticking with -r317820 built >>> production style: the kind of context >>> the problem was first observed in. >>> Attempting a debug kernel build simply >>> did not repeat the problem for days >>> (vs. the usual hours for builds like >>> this). >>>=20 >>>=20 >>> So below is the backtrace: >>>=20 >>> (I do not show what trap_fatal calls: >>> starting with trap_fatal and going toward >>> larger memory addresses. . .) >>>=20 >>> [vmcore.9's >>> offset >>> in file >>> when no >>> 0x prefix] >>>=20 >>> 013e83b0 df 5e 55 50 00 8f 34 5c fa 50 05 af fa 50 05 af = |.^UP..4\.P...P..| >>> 0x008f3454 mr r3,r26 >>> 0x008f3458 bl 008f2030 >>> 0x008f345c b 008f34c8 >>>=20 >>> 013e83c0 fa 50 05 af fa 50 05 af fa 50 05 af fa 50 05 af = |.P...P...P...P..| >>> * >>> 013e83e0 df 5e 54 00 fa 50 05 af fa 50 05 af fa 50 05 af = |.^T..P...P...P..| >>> 013e83f0 fa 50 05 af fa 50 05 af 00 d1 ca ac df 5e 54 00 = |.P...P.......^T.| >>> 013e8400 df 5e 54 20 00 53 3a d0 fa 50 05 af fa 50 05 af |.^T = .S:..P...P..| >>> 013e8410 fa 50 05 af fa 50 05 af 00 d1 ca ac df 5e 54 20 = |.P...P.......^T | >>> 013e8420 df 5e 54 d0 00 53 3a d0 00 00 00 00 00 00 00 00 = |.^T..S:.........| >>> 013e8430 00 00 00 00 00 00 00 00 00 d1 ca ac 00 00 00 0f = |................| >>> 013e8440 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >>> * >>> 013e8460 00 00 00 54 7f ff ff ff 00 00 00 00 ff ff ff aa = |...T............| >>> 013e8470 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >>> * >>> 013e8490 00 d4 c4 5c 00 d4 c4 5c 00 17 99 dd 00 17 9a 5c = |...\...\.......\| >>> 013e84a0 00 00 17 9a 00 d4 c4 6c df 5e 54 ec 00 00 00 54 = |.......l.^T....T| >>> 013e84b0 df 5e 54 d0 7f ff ff ff 05 aa 36 c0 05 aa 39 e8 = |.^T.......6...9.| >>> 013e84c0 00 00 00 00 00 00 00 00 00 d1 ca ac df 5e 54 d0 = |.............^T.| >>> 013e84d0 df 5e 55 80 00 53 3a d0 05 91 d0 00 05 91 d3 28 = |.^U..S:........(| >>> 013e84e0 df 5e 55 00 00 00 00 00 00 d1 ca ac 00 00 00 0f = |.^U.............| >>> 013e84f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >>> 013e8500 00 00 00 00 00 00 00 00 00 d4 bd ec 00 cb 98 98 = |................| >>> 013e8510 00 d4 c4 5c 00 d4 c4 5c 00 17 99 f8 00 17 99 f8 = |...\...\........| >>> 013e8520 00 00 17 99 fa 69 b8 79 00 17 9a 0a 00 00 17 99 = |.....i.y........| >>> 013e8530 f8 1c 2f cc df 5e 55 88 01 47 d6 c0 01 43 a2 00 = |../..^U..G...C..| >>> 013e8540 41 eb 30 00 0a 00 00 00 00 d2 6e 4c df 5e 55 50 = |A.0.......nL.^UP| >>>=20 >>> 013e8550 df 5e 55 80 00 8e 7d 40 df 5e 55 9c 00 00 00 28 = |.^U...}@.^U....(| >>> 0x008e7d28 mfmsr r0 >>> 0x008e7d2c or r0,r0,r9 >>> 0x008e7d30 mtmsr r0 >>> 0x008e7d34 isync >>> 0x008e7d38 mr r3,r25 >>> 0x008e7d3c bl 008f222c >>> 0x008e7d40 lwz r11,0(r1) >>>=20 >>> 013e8560 00 00 00 00 00 00 17 9a 06 40 c2 a8 01 43 a2 00 = |.........@...C..| >>> 013e8570 41 eb 30 00 0a 00 00 00 00 00 00 00 00 08 10 32 = |A.0............2| >>>=20 >>> r0 r1 >>> 013e8580 df 5e 56 40 00 10 08 f8 00 00 00 04 df 5e 56 40 = |.^V@.........^V@| >>> The struct trapframe starts is 0x 013e8588 in the >>> vmcore.9 file. The 0x00108f8 is as shown below: >>>=20 >>> 0x001008ec isync >>> 0x001008f0 addi r3,r1,8 >>> 0x001008f4 bl 008e7ba4 >>> 0x001008f8 mfmsr r3 >>> 0x001008fc andi. r3,r3,32767 >>>=20 >>> 013e8590 01 47 d6 c0 00 00 00 28 01 47 c6 c0 00 00 00 04 = |.G.....(.G......| >>> r2 r3 r4 r5 >>>=20 >>> 013e85a0 00 00 00 04 00 00 00 0f 00 00 00 00 00 d4 c0 3c = |...............<| >>> r6 r7 r8 r9 >>>=20 >>> 013e85b0 01 47 d6 c0 df 5e 56 80 14 3d 60 da 00 00 00 00 = |.G...^V..=3D`.....| >>> r10 r11 r12 r13 >>>=20 >>> 013e85c0 00 d4 bd ec 00 cb 98 98 00 d4 c4 5c 00 d4 c4 5c = |...........\...\| >>> r14 r15 r16 r17 >>>=20 >>> 013e85d0 00 17 99 f8 00 17 99 f8 00 00 17 99 fa 69 b8 79 = |.............i.y| >>> r18 r19 r20 r21 >>>=20 >>> 013e85e0 00 17 9a 0a 00 00 17 99 f8 1c 2f cc 00 00 17 9a = |........../.....| >>> r22 r32 r24 r25 >>>=20 >>> 013e85f0 06 40 c2 a8 01 43 a2 00 00 eb a7 80 01 47 d6 c0 = |.@...C.......G..| >>> r26 r27 r28 r29 >>>=20 >>> 013e8600 00 d1 ca ac df 5e 56 40 00 53 5a d0 20 00 90 44 = |.....^V@.SZ. ..D| >>> r30 r31 lr cr >>>=20 >>> xer ctr srr0 srr1 >>> 013e8610 00 00 00 00 00 00 00 00 00 90 a0 30 00 08 10 32 = |...........0...2| >>> Note: objdump shows no code at 0x0090a030. 0x0090a030 is >>> inside what objdump -x reports as the section .hash (Idx >>> 2). >>>=20 >>> exc dar dsisr (booke dbcer0) >>> 013e8620 00 00 07 00 41 eb 30 00 0a 00 00 00 01 47 c6 c0 = |....A.0......G..| >>> The 0x00007000 above is the framep->exc (exception code) >>> (program in this case). >>>=20 >>> 013e8630 00 eb a7 80 01 47 60 10 00 d1 ca ac df 5e 56 40 = |.....G`......^V@| >>>=20 >>> At this point the above does not match the below >>> part of the stack trace. >>>=20 >>> The lr part of struct trapframe was: 0x00535ad0 so >>> showing around that: >>>=20 >>> 00535ab8 stwu r1,-32(r1) >>> 00535abc mflr r0 >>> 00535ac0 stw r29,20(r1) >>> 00535ac4 stw r30,24(r1) >>> 00535ac8 stw r31,28(r1) >>> 00535acc stw r0,36(r1) >>> 00535ad0 mr r31,r1 >>> 00535ad4 mr r29,r3 >>>=20 >>> Back to the stack backtrace. . . >>>=20 >>> 013e8640 df 5e 56 80 00 53 59 dc 00 17 99 f8 00 17 99 f8 = |.^V..SY.........| >>> 0x005359c8 bl 008ea420 >>> 0x005359cc mr r3,r28 >>> 0x005359d0 mr r4,r27 >>> 0x005359d4 mr r5,r25 >>> 0x005359d8 bl 005356ec >>> 0x005359dc mfsprg r9,0 >>>=20 >>> I show around 0x005356ec >>> from the sched_add+0x19c bl that is above >>> because the routine is not referenced >>> in the stack tracce but the above indicates >>> that it should have been called: >>> 0x005356ec stwu r1,-32(r1) >>> 0x005356f0 mflr r0 >>> 0x005356f4 stw r28,16(r1) >>> 0x005356f8 stw r29,20(r1) >>> 0x005356fc stw r30,24(r1) >>> 0x00535700 stw r31,28(r1) >>> 0x00535704 stw r0,36(r1) >>> . . . >>>=20 >>> Back to the stack backtrace again. . . >>>=20 >>> 013e8650 00 00 17 99 fa 69 b8 79 00 17 9a 0a 00 00 00 04 = |.....i.y........| >>> 013e8660 f8 1c 2f cc 00 00 17 9a 06 40 c2 a8 01 43 a2 00 = |../......@...C..| >>> 013e8670 01 47 c6 c0 01 47 60 10 00 d1 b4 30 df 5e 56 80 = |.G...G`....0.^V.| >>>=20 >>> 013e8680 df 5e 56 b0 00 4a 87 8c 00 d2 5b 10 00 00 00 04 = |.^V..J....[.....| >>> 0x004a8780 mr r3,r28 >>> 0x004a8784 li r4,4 >>> 0x004a8788 bl 0053583c = >>> 0x004a878c lwz r9,0(r28) >>>=20 >>> 013e8690 df 5e 56 b0 00 00 17 9a 06 40 c2 a8 01 43 a2 00 = |.^V......@...C..| >>> 013e86a0 00 00 00 00 01 46 81 c0 00 d1 b4 30 df 5e 56 b0 = |.....F.....0.^V.| >>>=20 >>> 013e86b0 df 5e 56 f0 00 4a 97 0c 00 00 00 00 00 00 00 04 = |.^V..J..........| >>> 0x004a9700 bl 005000ec >>> 0x004a9704 mr r3,r27 >>> 0x004a9708 bl 004a86bc = >>> 0x004a970c lwz r11,0(r1) >>>=20 >>> 013e86c0 df 5e 56 e0 01 47 d6 c0 01 47 d6 c0 01 45 4d 40 = |.^V..G...G...EM@| >>> 013e86d0 df 5e 56 f0 00 8e a4 44 06 40 c2 a8 00 00 17 9a = |.^V....D.@......| >>> 013e86e0 78 00 00 00 00 e9 56 00 00 d1 c8 20 df 5e 56 f0 = |x.....V.... .^V.| >>>=20 >>> 013e86f0 df 5e 57 50 00 51 79 6c df 5e 58 78 01 47 d6 c0 = |.^WP.Qyl.^Xx.G..| >>> 0x00517960 lwz r3,264(r29) >>> 0x00517964 li r4,0 >>> 0x00517968 bl 004a965c >>> 0x0051796c lwz r11,0(r1) >>>=20 >>> 013e8700 01 47 d7 b8 00 00 00 00 00 d1 ab 24 00 00 00 04 = |.G.........$....| >>> 013e8710 00 c9 66 bc 00 c4 5d 48 00 c9 66 bc 00 d4 c5 3c = |..f...]H..f....<| >>> 013e8720 00 d0 53 00 00 eb a7 80 00 00 00 01 00 00 00 00 = |..S.............| >>> 013e8730 df 5e 59 8c 00 00 00 00 df 5e 58 78 00 00 17 99 = |.^Y......^Xx....| >>> 013e8740 f8 1c 2f cc d0 01 dd 00 00 d2 5b 10 df 5e 57 50 = |../.......[..^WP| >>>=20 >>> 013e8750 df 5e 57 a0 00 8a b2 70 df 5e 57 60 df 5e 57 60 = |.^W....p.^W`.^W`| >>> 0x008ab264 mr r3,r27 >>> 0x008ab268 mr r4,r28 >>> 0x008ab26c bl 00517540 >>> 0x008ab270 li r3,0 >>>=20 >>> 013e8760 df 5e 57 a0 df 5e 58 78 05 86 37 00 00 00 00 04 = |.^W..^Xx..7.....| >>> 013e8770 00 00 00 00 05 9b f2 00 00 c9 66 bc 01 47 d6 c0 = |..........f..G..| >>> 013e8780 df 5e 59 8c 00 f6 1d 10 00 00 17 99 f8 1c 2f cc = |.^Y.........../.| >>> 013e8790 d0 01 dd 00 d0 01 dd 30 00 d2 5b 10 df 5e 57 a0 = |.......0..[..^W.| >>>=20 >>> 013e87a0 df 5e 58 20 00 8a d1 10 00 d2 6e 5c df 5e 57 b0 |.^X = ......n\.^W.| >>> 0x008ad100 mr r3,r26 >>> 0x008ad104 mr r4,r27 >>> 0x008ad108 li r5,0 >>> 0x008ad10c bl 008aafc0 >>> 0x008ad110 lwz r11,0(r1) >>>=20 >>> 013e87b0 df 5e 57 e0 00 4a 96 00 00 00 17 99 00 00 00 00 = |.^W..J..........| >>> 013e87c0 f8 1c 2f cc 0a 3f a0 12 df 5e 58 78 05 86 37 00 = |../..?...^Xx..7.| >>> 013e87d0 01 48 b1 00 05 86 37 80 00 d4 bd ec 00 cb 98 98 = |.H....7.........| >>> 013e87e0 00 c9 66 bc 00 c4 5d 48 00 c9 66 bc 00 d4 c5 3c = |..f...]H..f....<| >>> 013e87f0 df 5e 59 e0 00 eb a7 80 00 c9 66 bc 01 47 d6 c0 = |.^Y.......f..G..| >>> 013e8800 df 5e 59 8c df 5e 58 78 01 47 d6 c0 00 00 00 00 = |.^Y..^Xx.G......| >>> 013e8810 00 f6 1d 10 00 00 00 01 00 d2 6b c8 df 5e 58 20 = |..........k..^X | >>>=20 >>> 013e8820 df 5e 58 40 00 8e 1e 48 00 00 00 00 00 eb a7 80 = |.^X@...H........| >>> So 0x13e8820 from vmcore.9 has start of struct trapeframe. >>> The 0x8e1e48 is from: >>> 0x008e1e34 lwz r0,56(r28) >>> 0x008e1e38 mtctr r0 >>> 0x008e1e3c mr r3,r28 >>> 0x008e1e40 lwz r4,64(r28) >>> 0x008e1e44 bctrl >>> 0x008e1e48 addi r29,r29,-1 >>>=20 >>> 013e8830 01 47 d7 94 00 00 00 01 00 d2 6e 4c df 5e 58 40 = |.G........nL.^X@| >>> 013e8840 df 5e 58 70 00 8e 7c 9c 00 d1 ca ac df 5e 58 50 = |.^Xp..|......^XP| >>> 013e8850 00 cd f0 74 00 00 00 01 00 00 00 01 00 eb a7 80 = |...t............| >>> 013e8860 41 eb 30 00 0a 00 00 00 00 00 00 00 00 00 90 32 = |A.0............2| >>> 013e8870 df 5e 59 30 00 10 08 f8 00 04 90 32 df 5e 59 30 = |.^Y0.......2.^Y0| >>> 013e8880 01 47 d6 c0 00 00 00 00 0d 0b bf e3 00 00 00 00 = |.G..............| >>> 013e8890 0d 0b bf e3 00 19 eb 7c 00 00 00 00 00 00 00 44 = |.......|.......D| >>> 013e88a0 01 fc a0 55 00 00 90 32 d0 01 dd 00 00 00 00 00 = |...U...2........| >>> 013e88b0 00 d4 bd ec 00 cb 98 98 00 c9 66 bc 00 c4 5d 48 = |..........f...]H| >>> 013e88c0 00 c9 66 bc 00 d4 c5 3c df 5e 59 e0 00 eb a7 80 = |..f....<.^Y.....| >>> 013e88d0 00 c9 66 bc 01 47 d6 c0 df 5e 59 8c 00 00 00 01 = |..f..G...^Y.....| >>> 013e88e0 00 00 00 01 00 eb a7 80 00 00 00 00 00 8e 3b f8 = |..............;.| >>>=20 >>> srr0 >>> 013e88f0 00 d2 6b f0 df 5e 59 30 00 8e 3c 14 40 00 00 42 = |..k..^Y0..<.@..B| >>> The 0x00833c14 from the trap frame is the srr0 (conceptual lr): >>> 0x008e3c04 stw r31,28(r1) >>> 0x008e3c08 stw r0,36(r1) >>> 0x008e3c0c mr r31,r1 >>> 0x008e3c10 bcl- 20,4*cr7+so,008e3c14 = >>> 0x008e3c14 mflr r30 >>> 0x008e3c18 lwz r0,-32(r30) >>>=20 >>> 013e8900 20 00 00 00 00 8e 3b f8 00 8e 3c 80 00 00 90 32 | = .....;...<....2| >>>=20 >>> exc >>> 013e8910 00 00 09 00 41 eb 30 00 0a 00 00 00 00 00 00 00 = |....A.0.........| >>> The 0x00009000 above is the framep->exc (exception code) >>> (decrementer in this case). >>>=20 >>> 013e8920 eb 10 25 b5 55 7e c4 22 00 00 00 00 00 00 00 04 = |..%.U~."........| >>>=20 >>> 013e8930 df 5e 59 50 00 00 00 01 00 00 00 01 00 eb a7 80 = |.^YP............| >>> (trap [above] means no lr filled in here) >>>=20 >>> 013e8940 00 00 00 00 00 d4 ca 34 00 d2 6b f0 df 5e 59 50 = |.......4..k..^YP| >>>=20 >>> 013e8950 df 5e 59 70 00 8e 31 9c 00 00 00 02 00 eb a7 80 = |.^Yp..1.........| >>> 0x008e318c bl 008ad8b8 >>> 0x008e3190 lwz r29,0(r29) >>> 0x008e3194 mtctr r29 >>> 0x008e3198 bctrl >>> 0x008e319c bl 008ad7b8 >>>=20 >>> 013e8960 00 f2 d5 fc 00 00 00 01 00 d1 ca ac df 5e 59 70 = |.............^Yp| >>>=20 >>> 013e8970 df 5e 5a 50 00 53 6e 7c fa 50 05 af fa 50 05 af = |.^ZP.Sn|.P...P..| >>> 0x00536e78 bl 008e3144 >>> 0x00536e7c stw r28,136(r27) >>>=20 >>>=20 >>> 013e8980 fa 50 05 af fa 50 05 af fa 50 05 af ff ff ff fe = |.P...P...P......| >>> 013e8990 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| >>> 013e89a0 ff ff ff ff ff ff ff ff ff ff ff ff fa 50 05 af = |.............P..| >>> 013e89b0 fa 50 05 af 00 00 00 02 ff ff ff ff 00 00 01 f0 = |.P..............| >>> 013e89c0 ff ff ff fe ff ff ff ff ff ff ff ff ff ff ff ff = |................| >>> 013e89d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| >>> 013e89e0 ff ff ff fe ff ff ff ff ff ff ff ff ff ff ff ff = |................| >>> 013e89f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| >>> 013e8a00 df 5e 5a 20 fa 50 05 af 00 00 00 00 00 00 00 00 |.^Z = .P..........| >>> 013e8a10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >>> * >>> 013e8a30 00 00 00 00 00 53 69 a8 df 5e 5a 98 00 00 00 00 = |.....Si..^Z.....| >>> 013e8a40 01 47 96 e0 01 47 d6 c0 00 d1 b3 70 df 5e 5a 50 = |.G...G.....p.^ZP| >>>=20 >>> 013e8a50 df 5e 5a 80 00 4a 3c b4 df 5e 5a 60 df 5e 5a 60 = |.^Z..J<..^Z`.^Z`| >>> 0x004a3ca0 bl 008ea420 >>> 0x004a3ca4 mr r3,r27 >>> 0x004a3ca8 mr r4,r26 >>> 0x004a3cac mtctr r25 >>> 0x004a3cb0 bctrl >>> 0x004a3cb4 lwz r0,108(r28) >>>=20 >>> 013e8a60 df 5e 5a 80 00 00 00 00 00 00 00 00 00 00 00 00 = |.^Z.............| >>> 013e8a70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >>>=20 >>> 013e8a80 00 00 00 00 00 8f 18 d0 00 53 69 a8 00 00 00 00 = |.........Si.....| >>> 0x008f18c0 lwz r3,8(r1) >>> 0x008f18c4 lwz r4,12(r1) >>> 0x008f18c8 lwz r5,16(r1) >>> 0x008f18cc bl 004a3bbc >>> 0x008f18d0 addi r1,r1,16 >>> 0x008f18d4 b 001008f8 >>>=20 >>>=20 >>> So that is an example context for the failure. >>>=20 >>> It has taken weeks to get this. It may be some >>> time before I get another for comparison/contrast. >>>=20 >>> And sticking with the same build vs. trying some more >>> to find a better way to get more evidence is not >>> obvious to me at this point. >>=20 >> I should have mentioned that this is >> TARGET_ARCH=3Dpowerpc but used on a so-called PowerMac >> G5 "Quad Core". >>=20 >> I've had 2 more examples, with the same 0x0090a030 >> srr0 and such (vmcore.0 and vmcore.1) (I have added >> one more little block of code for detecting an earlier >> problem symptom not being currently seen so the build >> is slight different from the earlier report.) >>=20 >> Looking around in vmcore.0 I find 3 examples of >> "00 90 a0 30" in areas overlapping with objdump -x's >> coverage. . . >>=20 >> 00c77fd0 00 00 00 00 00 00 00 00 00 90 a0 30 00 08 10 32 = |...........0...2| >> [ ] >>=20 >> (from sorted objdump -x output:) >> 00c775a8 l O .data 00000dc0 seqprog >> 00c78368 l O .data 0000000c seeprom_long_ewen I forgot to subtract the 0x1000 vmcore header size from 00c77fd0 in what I looked up with objdump -x, so correcting: 00c75010 g .data 00000000 tmpstk 00c77010 g O .data 00000004 dtrace_invop_calltrap_addr tmpstk is involved via dbtrap:=20 dbtrap: /* Write the trap vector to SPRG3 by computing LR & 0xff00 */ mflr %r1 andi. %r1,%r1,0xff00 mtsprg3 %r1 lwz %r1,TRAP_TOCBASE(0) /* get new SP */ lwz %r1,tmpstk@got(%r1) addi %r1,%r1,TMPSTKSZ-16 =20 FRAME_SETUP(PC_DBSAVE) /* Call C trap code: */ addi %r3,%r1,8 bl CNAME(db_trap_glue) . . . I missed the below in vmcore.1 (vmcore.2 matches other than 0x30 vs. = 0x70): [ ] 00d4d090 00 ca 8a ac 00 10 00 03 00 10 00 03 00 90 a0 30 = |...............0| 00d4d090 00 ca 8a ac 00 10 00 03 00 10 00 03 00 90 a0 70 = |...............p| 00d4c090 g O .sbss 00000004 db_cmd_table 00d4c094 g O .sbss 00000004 db_dot 00d4c098 g O .sbss 00000004 db_last_addr 00d4c09c g O .sbss 00000004 db_prev 00d4c0a0 g O .sbss 00000004 db_next That puts the 0x0090a0?0 in db_prev . I also missed: [ ] 00f2c070 00 00 00 00 df 5e 55 90 00 00 00 00 00 90 a0 30 = |.....^U........0| 00f2c070 00 00 00 00 df 5e 55 90 00 00 00 00 00 90 a0 70 = |.....^U........p| 00f2b020 l O .bss 000004a0 kdb_pcb 00f2b4c0 l O .bss 00000004 kobj_mutex_inited That puts the 0x0090a0?0 in kdb_pcb.pcb_lr . kdb_pcb is tied kdb_trap(.) use. >> [ ] >> 00f65820 41 eb 30 00 0a 00 00 00 00 90 a0 30 00 08 10 32 = |A.0........0...2| >> . . . >> 00f65870 00 90 a0 30 00 08 10 32 00 00 00 00 df 5d 30 00 = |...0...2.....]0.| >> [ ] >>=20 >> (from sorted objdump -x output:) >> 00f64780 g O .bss 00020000 __pcpu >> 00f84780 l O .bss 00000004 ap_letgo Again I forgot to subtract off 0x1000 from the vmcore offset but it happened to work out anyway here for how little information I reported at the time. It turns out that the two references are: __pcpu[0].pc_tempsave[7] __pcpu[0].pc_dbsave[7] and: #define CPUSAVE_SRR0 7 /* where SRR0 gets saved */ Overall that means that all the copies of the 0x0090a0?0 value are a consequence of having reached the illegal instruction at the bad address. Looking at prior modulo 4 addresses before the 0x009070?0 shows they are all illegal instructions for such memory contents. Which suggests that the jump involved was directly to the 0x0090a0?0 address, but it is not clear where it was when it jumped or how it came up with a 0x0090a0?0 address. > Making some comparisons across > two examples of the panic, prior > vs. newest. . . >=20 > The srr0 was different by 0x40: >=20 >> For vmcore.1 I went ahead and tried exploring >> some with ddb --and had no new panics. . . >> (Hand transcriptions of pictures) >>=20 >> fatal kernel trap: >> exception =3D 0x700 (program) >> srr0 =3D 0x90a030 > vs.=3D 0x90a070 >> srr1 =3D 0x81032 >> lr =3D 0x535ad0 >> curthread =3D 0x147d6c0 >> pic =3D 11, comm =3D idle: cpu0 >>=20 >> [ thread pid 11 tid 100003 ] >> Stopped at _etext+0xb8fc: illegal instruction 0 >> db> bt >> 0xdf5e55d0: at sched_wakeup+0xa4 >> 0xdf5e55f0: at setrunnable+0x9c >> 0xdf5e5610: at sleepq_resume_thread+0x17c >> 0xdf5e5640: at sleepq_timeout+0xc8 >> 0xdf5e5680: at softclock_call_cc+0x1f0 >> 0xdf5e56f0: at callout_process+0x27c >> 0xdf5e57a0: at timercb+0x4c4 >> 0xdf5e5820: at decr_intr+0xf0 >> 0xdf5e5840: at powerpc_interrupt+0xf4 >> 0xdf5e5870: at kernel DECR trap >> by cpu_idle_60x+0x88 (so: srr0) >> srr1=3D0x9032 >> r1 =3D0xdf5e5930 >> cr =3D0x40000042 >> xer =3D0x20000000 >> ctr =3D0x8e3bf8 >> saved LR(0xfffffffd) is invalid. So sometime while sched_wakeup is active on the stack a jump to a bad 0x0090a0?0 address is executed. > Below I show an alternate example > values were they are different, where > the patch that I attempted was also > involved for the new figures. >=20 >> db> show reg (but reformatted >> r0 =3D0x4 >> r1 =3D0xdf5e5590 >> r2 =3D0x147d6c0 >> r3 =3D0x54 testppc64size+0x34 > vs.=3D0x78 dlmisssize+0x8 >> r4 =3D0x591d000 > vs.=3D0x5aa4360 >> r5 =3D0 >> r6 =3D0 >> r7 =3D0xf >> r8 =3D0 >> r9 =3D0xd4c03c cold >> r10 =3D0x147d6c0 >> r11 =3D0xdf5e55d0 >> r12 =3D0 >> r13 =3D0 >> r14 =3D0xd4bdec sdt_probe_func >> r15 =3D0xcb9898 std_lockstat___spin__release >> r16 =3D0xd4c45c callwheelmask >> r17 =3D0xd4c45c callwheelmask >> r18 =3D0x55925 > vs.=3D0x15c267 fdt_property+0x113 >> r19 =3D0x559a4 > vs.=3D0x15c2e6 fdt_property+0x192 >> r20 =3D0x559 dsmisssize+0x469 > vs.=3D0x15c2 dsmisssize+0x14d2 >> r21 =3D0x591d000 > vs.=3D0x5aa4360 >> r22 =3D0x566430 sleepq_timeout >> r23 =3D0x114 dsmisssize+0x24 >> r24 =3D0 >> r25 =3D0 >> r26 =3D0x1 >> r27 =3D0 >> r28 =3D0xeba780 tdq_cpu >> r29 =3D0x147d6c0 >> r30 =3D0xd1caac >> r31 =3D0xdf5e5590 > srr0 =3D0x90a030 _etext+0xb8fc > vs.=3D0x90c070 _etext+0xb8fc >> srr1 =3D0x81032 >> lr =3D0x535ad0 sched_affinity+0x18 >> ctr =3D0 >> cr =3D0x20009034 > vs.=3D0x20009044 >> xer =3D0 >> dar =3D0x419df5d4 > vs.=3D0x41d276f4 >> dsisr=3D0x24000000 > vs.=3D0xa0000000 >> _etext+0xb8fc: illegal instruction 0 >>=20 >>=20 >> Just for completeness: acttrace also showed: >>=20 >> Tracing command less pid 1144 tid 100150 td 0x5bc8a20 (CPU 3) >> 0xd25a59f0: at powrpc_dispatch_intr+0xc8 >> 0xd25a5a20: at openpic_dispatch+0x90 >> 0xd25a5a50: at powerpc_interrupt+0xc0 >> 0xd25a5a80: at user EXI trap >> by 0x181c68c (so: ssr0) >> r1 =3D0xffffdb30 >> cr =3D0x44020624 >> xer=3D0 >> ctr=3D0x41989570 >=20 > The newer example panic had CPU3 more like CPU 1 and 2 below. >=20 >> Tracing command idle pid 11 tid 100004 td 0x147d360 (CPU 1) >> saved LR(0x4c) in invalid >>=20 >> Tracing command idle pid 11 tid 100005 td 0x147d360 (CPU 2) >> saved LR(0x4c) in invalid Since tmpstk has the trap content shown (including the trap frame) (the thread stack agrees but for the vmcore offset): 00c77f40 df 5e 55 90 00 10 0c 54 00 00 00 04 df 5e 55 90 = |.^U....T.....^U.| 00c77f50 01 47 d6 c0 00 00 00 78 05 aa 43 60 00 00 00 00 = |.G.....x..C`....| 00c77f60 00 00 00 00 00 00 00 0f 00 00 00 00 00 d4 c0 3c = |...............<| 00c77f70 01 47 d6 c0 df 5e 55 d0 00 00 00 00 00 00 00 00 = |.G...^U.........| 00c77f80 00 d4 bd ec 00 cb 98 98 00 d4 c4 5c 00 d4 c4 5c = |...........\...\| 00c77f90 00 15 c2 67 00 15 c2 e6 00 00 15 c2 05 aa 43 60 = |...g..........C`| 00c77fa0 00 56 64 30 00 00 01 14 00 00 00 00 00 00 00 00 = |.Vd0............| 00c77fb0 00 00 00 01 00 00 00 00 00 eb a7 80 01 47 d6 c0 = |.............G..| 00c77fc0 00 d1 ca ac df 5e 55 90 00 53 5a d0 20 00 90 44 = |.....^U..SZ. ..D| [ lr ] [ srr0 ] 00c77fd0 00 00 00 00 00 00 00 00 00 90 a0 70 00 08 10 32 = |...........p...2| 00c77fe0 00 00 07 00 00 00 00 00 00 00 00 00 01 c4 4f 00 = |..............O.| 00c77ff0 00 00 00 00 00 10 01 40 00 00 00 00 00 00 00 00 = |.......@........| and that lr (also in show reg's output) is in: 0x535ab8 : stwu r1,-32(r1) 0x535abc : mflr r0 0x535ac0 : stw r29,20(r1) 0x535ac4 : stw r30,24(r1) 0x535ac8 : stw r31,28(r1) 0x535acc : stw r0,36(r1) 0x535ad0 : mr r31,r1 which is also an odd place for lr to point. As for srr0: 0x90a060 <.hash+47324>: .long 0xad6 0x90a064 <.hash+47328>: .long 0x0 0x90a068 <.hash+47332>: .long 0x85 0x90a06c <.hash+47336>: .long 0x0 0x90a070 <.hash+47340>: .long 0x0 0x90a074 <.hash+47344>: .long 0x532 0x90a078 <.hash+47348>: .long 0x0 0x90a07c <.hash+47352>: .long 0x0 0x90a080 <.hash+47356>: .long 0x0 I have not found any indication why the lr and srr0 values end up as they are above or what code jumped to 0x0090a0?0. Sort of preventing fetches from being allowed for the bad-jump's target area I've not had any ideas for finding what code jumped. But I've not figured out how to do that protection of some pages either. (And I'm not sure that FreeBSD is designed to deal with failing to fetch on powerpc.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Tue May 30 09:20:21 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D845FB762E2; Tue, 30 May 2017 09:20:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7E3D77E299; Tue, 30 May 2017 09:20:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v4U9K877049578 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 May 2017 12:20:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v4U9K877049578 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v4U9K7sS049575; Tue, 30 May 2017 12:20:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 30 May 2017 12:20:07 +0300 From: Konstantin Belousov To: Mark Millard Cc: freebsd-hackers@freebsd.org, FreeBSD PowerPC ML Subject: Re: cpuset_setithread and PROC_LOCK vs. thread_lock usage: Is this correct? Message-ID: <20170530092007.GH82323@kib.kiev.ua> References: <433AC404-E85D-4910-8638-4EBC3ACBBCDB@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <433AC404-E85D-4910-8638-4EBC3ACBBCDB@dsl-only.net> User-Agent: Mutt/1.8.2 (2017-04-18) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 09:20:21 -0000 On Mon, May 29, 2017 at 06:48:28PM -0700, Mark Millard wrote: > [FYI: The source referenced is from head > -r317820.] > > In the process of trying to get evidence > related to a periodic/random kernel panic > for TARGET_ARCH=powerpc I ran into what > follows. I've no evidence that it is tied > to the panics. It is just something that > I read that looked a little odd to me. > > But it looked like a good thing to ask > about, at least based on my level of > ignorance of such things for the kernel. > (The more I learn the better.) > > I normally see the likes of: > > thread_lock(td); > tdset = td->td_cpuset; > > and: > > thread_lock(td); > error = cpuset_shadow(td->td_cpuset, nset, mask); > > but in cpuset_setithread the comments read like > a PROC_LOCK is in use instead: > > int > cpuset_setithread(lwpid_t id, int cpu) > { > . . . > struct proc *p; > . . . > error = cpuset_which(CPU_WHICH_TID, id, &p, &td, &old_set); > if (error != 0 || ((cs_id = alloc_unr(cpuset_unr)) == CPUSET_INVALID)) > goto out; > > /* cpuset_which() returns with PROC_LOCK held. */ > old_set = td->td_cpuset; > . . . > > That seems true for !error but is a different > lock than used elsewhere (those thread_lock's). > > cpuset_which does seem to end up with the PROC_LOCK > as indicated: > > int > cpuset_which(cpuwhich_t which, id_t id, struct proc **pp, struct thread **tdp, > struct cpuset **setp) > { > . . . > case CPU_WHICH_TID: > if (id == -1) { > PROC_LOCK(curproc); > p = curproc; > td = curthread; > break; > } > td = tdfind(id, -1); > if (td == NULL) > return (ESRCH); > p = td->td_proc; > break; > . . . > error = p_cansched(curthread, p); > if (error) { > PROC_UNLOCK(p); > return (error); > } > if (td == NULL) > td = FIRST_THREAD_IN_PROC(p); > *pp = p; > *tdp = td; > return (0); > } > > (tdfind does rw_rlock on tidhash_lock, > PROC_LOCK on td->td_proc. It only > PROC_UNLOCK's for PRS_NEW and > is comments to return with the proc > lock held. No thread_lock's involved.) > > So it appears to me that in cpuset_setithread : > > /* cpuset_which() returns with PROC_LOCK held. */ > old_set = td->td_cpuset; > > might happen with no thread_lock protecting the > td use (say to avoid reading during updates). (This > might also apply to what old_set points to.) > > Similarly for: > > cpuset_setithread(lwpid_t id, int cpu) > { > . . . > struct cpuset *parent, *old_set; > . . . > error = cpuset_shadow(parent, nset, &mask); > . . . > > it does not appear that a thread_lock is involved > around the cpuset_shadow operation, unlike > elsewhere. > > Is this lack of thread_lock involvement in fact > okay for some reason in each case? This is a comment noting the lock which is held there. The pattern where some function is entered unlocked and returns with some lock held is not uncommon but also not used too often, so the note to reader helps. On the other hand, the note does not imply that the action of reading td_cpuset is protected by the proc lock, it happens accidently under it. Read of the pointer is atomic on all supported architectures, so taking the thread lock around the read is useless, unless some consistency between the pointer value and some other values are needed. The thread lock only protects updates to the td_cpuset thread member, it does not protect the dereferenced structure. Look for the comment in sys/cpuset.h for explanation of the locking model for struct cpuset. In this case, I suspect that what is needed is a ref count on the dereferenced cpuset, at least it seems so according to the locking annotations on struct cpuset. But if the td_cpuset for ithread is only manipulated by the cpuset_setithread(), then the process lock exclusion might provide the sufficient protection against parallel updates (preventing leaks), and even more important, prevents sudden deconstruction of old_set while cpuset_setithread() uses it to set a new one. From owner-freebsd-hackers@freebsd.org Fri Jun 2 13:15:38 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AE11CBF7BC7 for ; Fri, 2 Jun 2017 13:15:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-5.reflexion.net [208.70.210.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 72E122014 for ; Fri, 2 Jun 2017 13:15:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 30599 invoked from network); 2 Jun 2017 13:15:31 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 2 Jun 2017 13:15:31 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Fri, 02 Jun 2017 09:15:31 -0400 (EDT) Received: (qmail 26439 invoked from network); 2 Jun 2017 13:15:31 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 Jun 2017 13:15:31 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 55A01EC8257; Fri, 2 Jun 2017 06:15:30 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: On a old PowerMac G5: two 32-bit powerpc FreeBSD vmcore's from having protected most wired kernel memory from execution: what is common Message-Id: Date: Fri, 2 Jun 2017 06:15:29 -0700 To: Justin Hibbits , Nathan Whitehorn , FreeBSD PowerPC ML , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 13:15:38 -0000 Based on the changed page protections. . . Instead of illegal instruction the periodic/random kernel panic reported for both example panics: fatal kernel trap: exception =3D 0x400 instruction storage interrupt virtual address =3D 0x90a0f0 srr0 =3D 0x90a0f0 srr1 =3D 0x10001032 lr =3D 0x535ad0 (sched_affinity+0x18 ???) curthread =3D 0x147d360 pid =3D 11, comm =3D idle: cpu1 [ thread pid 11 tid 100003 ] Stopped at etext+0xb8fc: illegal instruction 0 (So it looks like I disabled execute in that area correctly.) Most levels of the backtraces are different between vmcore.5 and vmcore.6 . But the lowest level ones are the same. In particular the prior bl is to tdq_add from sched_add but the 0x90a0f0 it jumps to when getting the 0x400 exception is wildly different than the 0x5356ec for the bl to tdq_add. For reference: sched_affinity through sched_affinity+0x18 is: 00535ab8 stwu r1,-32(r1) 00535abc mflr r0 00535ac0 stw r29,20(r1) 00535ac4 stw r30,24(r1) 00535ac8 stw r31,28(r1) 00535acc stw r0,36(r1) 00535ad0 mr r31,r1 So 00535ad0 is an odd spot for a lr value. backtrace summary for vmcore.5: (Listing the LR values, not 4 back from that.) trapexit+0x0 (after trapagain+0x4) for 0x400 trap 0x90a0f0 from .hash section (bad address) sched_add+0x1a0 005359c4 bl 004cde6c 005359c8 bl 008ea4e0 005359cc mr r3,r28 005359d0 mr r4,r27 005359d4 mr r5,r25 005359d8 bl 005356ec 005359dc mfsprg r9,0 (from here until cpu_idle_60x+0x88 is not common with vmcore.6) intr_event_schedule_thread+0xd0 004a8780 mr r3,r28 004a8784 li r4,4 004a8788 bl 0053583c = 004a878c lwz r9,0(r28) intr_event_handle+0x114 powerpc_dispatch_intr+0xcc openpic_dispatch+0x94 powerpc_interrupt+0xc4 trapexit+0x0 (after trapagain+0x4) for 0x500 trap (vmcore.6: 0x900) cpu_idle_60x+0x88 . . . (not shown) backtrace summary for vmcore.6: (Listing the LR values, not 4 back from that.) trapexit+0x0 (after trapagain+0x4) for 0x400 trap 0x90a0f0 from .hash section (bad address) sched_add+0x1a0 005359c4 bl 004cde6c 005359c8 bl 008ea4e0 005359cc mr r3,r28 005359d0 mr r4,r27 005359d4 mr r5,r25 005359d8 bl 005356ec 005359dc mfsprg r9,0 (from here until cpu_idle_60x+0x88 is not common with vmcore.5) sched_wakeup+0xa8 00535c0c mr r3,r29 00535c10 li r4,0 00535c14 bl 0053583c 00535c18 lwz r11,0(r1) setrunnable+0xa0 sleepq_resume_thread+0x180 sleepq_timeout+0xcc softclock_call_cc+0x1f4 callout_process+0x280 handleevents+0x2ac timercb+0x4c4 decr_intr+0xf4 powerpc_dispatch_intr+0xf8 trapexit+0x0 (after trapagain+0x4) for 0x900 trap (vmcore.5: 0x500) cpu_idle_60x+0x88 . . . (not shown) =46rom the vmcore.5: (The formatting depends on mono-spaced text) [ ]: trapexit+0x0 (after trapagain+0x4) 013ed680 df 5e a7 40 00 10 08 f8 00 00 00 04 df 5e a7 40 = |.^.@.........^.@| 013ed690 01 47 d3 60 00 00 00 14 01 47 e3 60 00 00 00 04 = |.G.`.....G.`....| 013ed6a0 00 00 00 04 00 fd 98 7f 00 00 00 00 00 d4 c0 50 = |...............P| 013ed6b0 01 47 d3 60 df 5e a7 80 df 5d 0d 00 00 00 00 00 = |.G.`.^...]......| 013ed6c0 00 d4 be 00 00 cb 98 98 00 c9 66 bc 00 c4 5e a8 = |..........f...^.| 013ed6d0 00 c9 66 bc 00 d4 c5 4c df 5e a9 e0 00 eb a8 00 = |..f....L.^......| 013ed6e0 00 c9 66 bc 01 47 d3 60 00 00 00 00 df 5e a8 78 = |..f..G.`.....^.x| 013ed6f0 01 44 0e 00 01 47 d3 60 00 eb af 00 01 47 d3 60 = |.D...G.`.....G.`| 013ed700 00 d1 ca ac df 5e a7 40 00 53 5a d0 20 00 90 34 = |.....^.@.SZ. ..4| [ ]: sched_affinity+0x18 [ ]: =46rom .hash section 013ed710 00 00 00 00 00 8d ef b4 00 90 a0 f0 10 00 10 32 = |...............2| [0x400 trap] 013ed720 00 00 04 00 41 a1 e5 68 0a 00 00 00 01 47 e3 60 = |....A..h.....G.`| 013ed730 00 eb af 00 01 47 d3 60 00 d1 ca ac df 5e a7 40 = |.....G.`.....^.@| [ ]: sched_add+0x1a0 013ed740 df 5e a7 80 00 53 59 dc 00 c9 66 bc 00 d4 c5 4c = |.^...SY...f....L| 013ed750 df 5e a9 e0 00 eb a8 00 00 c9 66 bc 00 00 00 04 = |.^........f.....| 013ed760 00 00 00 00 df 5e a8 78 01 44 0e 00 01 47 d3 60 = |.....^.x.D...G.`| 013ed770 01 47 e3 60 01 51 ff 80 00 d1 b4 30 df 5e a7 80 = |.G.`.Q.....0.^..| [ ]: intr_event_schedule_thread+0xd0 013ed780 df 5e a7 b0 00 4a 87 8c 6d 0c 21 5c df 5e 00 00 = |.^...J..m.!\.^..| 013ed790 df 5e a7 b0 00 00 00 7c 00 00 00 00 01 47 d3 60 = |.^.....|.....G.`| 013ed7a0 00 00 00 01 00 00 00 00 00 d2 6e 70 df 5e a7 b0 = |..........np.^..| [ ]: intr_event_handle+0x114 013ed7b0 df 5e a7 e0 00 4a 95 fc 00 c9 66 bc 00 00 00 00 = |.^...J....f.....| 013ed7c0 df 5e a9 8c df 5e a8 78 df 5e a8 78 01 44 0e 00 = |.^...^.x.^.x.D..| 013ed7d0 00 02 10 a0 01 48 b2 80 00 d2 6e 70 df 5e a7 e0 = |.....H....np.^..| [ ]: powerpc_dispatch_intr+0xcc 013ed7e0 df 5e a8 10 00 8e 91 8c df 5e a7 f0 00 cf 48 a8 = |.^.......^....H.| 013ed7f0 df 5e a8 10 df 5e a8 78 01 47 d3 60 df 5e a8 78 = |.^...^.x.G.`.^.x| 013ed800 00 02 10 a0 01 4c d4 00 00 d2 70 2c df 5e a8 10 = |.....L....p,.^..| [ ]: openpic_dispatch+0x94 013ed810 df 5e a8 40 00 8e c9 48 ec 94 8e 64 e6 38 8f 72 = |.^.@...H...d.8.r| 013ed820 df 5e a8 40 00 00 00 02 00 00 00 00 00 eb af 00 = |.^.@............| 013ed830 41 a1 e5 68 01 48 b1 00 00 d2 6e 60 df 5e a8 40 = |A..h.H....n`.^.@| [ ]: powerpc_interrupt+0xc4 013ed840 df 5e a8 70 00 8e 7d 28 8b 00 00 00 00 00 55 c4 = |.^.p..}(......U.| 013ed850 00 cd f0 74 00 00 00 03 00 00 00 03 00 eb af 00 = |...t............| 013ed860 41 a1 e5 68 0a 00 00 00 00 00 00 00 00 00 90 32 = |A..h...........2| [ ]: trapexit+0x0 (after trapagain+0x4) 013ed870 df 5e a9 30 00 10 08 f8 00 04 90 32 df 5e a9 30 = |.^.0.......2.^.0| 013ed880 01 47 d3 60 00 00 00 00 7f a3 8e 84 00 00 00 00 = |.G.`............| 013ed890 7f a3 8e 84 00 fd 98 7f 00 00 00 00 00 00 00 44 = |...............D| 013ed8a0 01 fc a0 55 00 00 90 32 df 5d 0d 00 00 00 00 00 = |...U...2.]......| 013ed8b0 00 d4 be 00 00 cb 98 98 00 c9 66 bc 00 c4 5e a8 = |..........f...^.| 013ed8c0 00 c9 66 bc 00 d4 c5 4c df 5e a9 e0 00 eb a8 00 = |..f....L.^......| 013ed8d0 00 c9 66 bc 01 47 d3 60 df 5e a9 8c 00 00 00 03 = |..f..G.`.^......| 013ed8e0 00 00 00 03 00 eb af 00 00 00 00 00 00 8e 3c b8 = |..............<.| 013ed8f0 00 d2 6c 04 df 5e a9 30 00 8e 3c d4 40 00 00 42 = |..l..^.0..<.@..B| [ ]: cpu_idle_60x+0x88 013ed900 20 00 00 00 00 8e 3c b8 00 8e 3d 40 00 00 90 32 | = .....<...=3D@...2| [0x500 trap] 013ed910 00 00 05 00 41 a1 e5 68 0a 00 00 00 00 00 00 00 = |....A..h........| 013ed920 0b 5c 71 7c 79 c0 d7 fc 00 00 00 00 00 00 00 04 = |.\q|y...........| [ignore? ] (see above trap frame) 013ed930 df 5e a9 50 00 00 00 03 00 00 00 03 00 eb af 00 = |.^.P............| 013ed940 00 00 00 00 00 d4 ca 44 00 d2 6c 04 df 5e a9 50 = |.......D..l..^.P| [ ]: cpu_idle+0x58 013ed950 df 5e a9 70 00 8e 32 5c 00 00 00 02 00 eb af 00 = |.^.p..2\........| 013ed960 00 f2 d6 7c 00 00 00 03 00 d1 ca ac df 5e a9 70 = |...|.........^.p| [ ]: sched_idletd+0x4d4 013ed970 df 5e aa 50 00 53 6e 7c df 5e a9 80 00 00 00 00 = |.^.P.Sn|.^......| 013ed980 df 5e a9 b0 01 47 d3 60 df 5e a9 90 ff ff ff fd = |.^...G.`.^......| 013ed990 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| 013ed9a0 ff ff ff ff ff ff ff ff ff ff ff ff df 5e a9 b0 = |.............^..| 013ed9b0 df 5e a9 d0 00 00 00 02 ff ff ff ff 00 00 01 e5 = |.^..............| 013ed9c0 ff ff ff fd ff ff ff ff ff ff ff ff ff ff ff ff = |................| 013ed9d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| 013ed9e0 ff ff ff fd ff ff ff ff ff ff ff ff ff ff ff ff = |................| 013ed9f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| 013eda00 df 5e aa 20 00 f6 4a 00 00 00 00 00 00 00 00 00 |.^. = ..J.........| 013eda10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| * 013eda30 00 00 00 00 00 53 69 a8 df 5e aa 98 00 00 00 00 = |.....Si..^......| 013eda40 01 47 96 e0 01 47 d3 60 00 d1 b3 70 df 5e aa 50 = |.G...G.`...p.^.P| [ ]: fork_exit+0xb4 013eda50 df 5e aa 80 00 4a 3c b4 df 5e aa 60 df 5e aa 60 = |.^...J<..^.`.^.`| 013eda60 df 5e aa 80 00 00 00 00 00 00 00 00 00 00 00 00 = |.^..............| 013eda70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| [ ]: fork_tramoline+0x10 013eda80 00 00 00 00 00 8f 19 90 00 53 69 a8 00 00 00 00 = |.........Si.....| 013eda90 df 5e aa 98 00 00 00 00 00 00 00 00 00 00 00 00 = |.^..............| 013edaa0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| =46rom the vmcore.6: [ ]: trapexit+0x0 (after trapagain+0x4) 013ed4d0 df 5e a5 90 00 10 08 f8 00 00 00 04 df 5e a5 90 = |.^...........^..| 013ed4e0 01 47 d3 60 00 00 00 54 05 91 b0 00 00 00 00 00 = |.G.`...T........| 013ed4f0 00 00 00 00 00 00 00 0f 00 00 00 00 00 d4 c0 50 = |...............P| 013ed500 01 47 d3 60 df 5e a5 d0 00 00 00 00 00 00 00 00 = |.G.`.^..........| 013ed510 00 d4 be 00 00 cb 98 98 00 d4 c4 6c 00 d4 c4 6c = |...........l...l| 013ed520 00 11 11 97 00 11 12 16 00 00 11 11 05 91 b0 00 = |................| 013ed530 00 56 64 30 00 00 01 14 00 00 00 00 00 00 00 00 = |.Vd0............| 013ed540 00 00 00 01 00 00 00 00 00 eb af 00 01 47 d3 60 = |.............G.`| 013ed550 00 d1 ca ac df 5e a5 90 00 53 5a d0 20 00 90 34 = |.....^...SZ. ..4| [ ]: sched_affinity+0x18 [ ]: =46rom .hash section 013ed560 00 00 00 00 00 00 00 00 00 90 a0 f0 10 00 10 32 = |...............2| [0x400 trap] 013ed570 00 00 04 00 01 81 a4 7c 0a 00 00 00 05 91 b0 00 = |.......|........| 013ed580 00 eb af 00 01 47 d3 60 00 d1 ca ac df 5e a5 90 = |.....G.`.....^..| [ ]: sched_add+0x1a0 013ed590 df 5e a5 d0 00 53 59 dc 00 00 00 01 00 d4 c5 4c = |.^...SY........L| 013ed5a0 df 5e 00 00 00 00 00 40 df 5e a5 b0 00 00 00 04 = |.^.....@.^......| 013ed5b0 df 5e a5 d0 00 00 00 00 00 00 00 01 00 00 00 00 = |.^..............| 013ed5c0 05 91 b3 28 05 91 b0 00 00 d1 ca ac df 5e a5 d0 = |...(.........^..| [ ]: sched_wakeup+0xa8 013ed5d0 df 5e a5 f0 00 53 5c 18 00 00 00 00 00 00 00 00 = |.^...S\.........| 013ed5e0 01 42 b0 80 05 91 b0 00 00 d1 c4 c4 df 5e a5 f0 = |.B...........^..| [ ]: setrunnable+0xa0 013ed5f0 df 5e a6 10 00 50 26 08 df 5e a6 00 00 cb 98 98 = |.^...P&..^......| 013ed600 df 5e a6 40 00 d4 c4 6c 00 d1 d5 34 df 5e a6 10 = |.^.@...l...4.^..| [ ]: sleepq_resume_thread+0x180 013ed610 df 5e a6 40 00 56 43 2c 00 56 64 30 00 00 01 14 = |.^.@.VC,.Vd0....| 013ed620 df 5e a6 40 00 00 00 00 00 00 00 01 00 00 11 11 = |.^.@............| 013ed630 8a d3 94 2a 05 91 b0 00 00 d1 d5 34 df 5e a6 40 = |...*.......4.^.@| [ ]: sleepq_timeout+0xcc 013ed640 df 5e a6 80 00 56 64 fc 00 c9 66 bc 00 00 00 00 = |.^...Vd...f.....| 013ed650 00 00 11 11 00 00 00 00 97 a0 fc 3d 80 96 c0 38 = |...........=3D...8| 013ed660 df 5e a6 80 00 8e a5 04 00 d2 5b 10 05 91 b2 a0 = |.^........[.....| 013ed670 00 e9 58 00 00 00 00 00 00 d1 c8 20 df 5e a6 80 |..X........ = .^..| [ ]: softclock_call_cc+0x1f4 013ed680 df 5e a6 f0 00 51 63 84 00 d2 5b 10 df 5e a6 90 = |.^...Qc...[..^..| 013ed690 df 5e a6 f0 00 8a ca a8 df 5e a6 a0 00 00 00 0f = |.^.......^......| 013ed6a0 df 5e a7 10 00 4c e2 f4 68 fc 88 02 00 00 00 04 = |.^...L..h.......| 013ed6b0 df 5e a6 d0 00 00 00 02 00 11 11 97 00 11 12 16 = |.^..............| 013ed6c0 00 00 11 11 d7 a0 9d 9d 00 11 11 8a 00 00 11 11 = |................| 013ed6d0 97 a0 9d 9d 00 00 11 12 17 00 00 00 00 00 11 12 = |................| 013ed6e0 17 00 00 00 00 e9 58 00 00 d1 c8 20 df 5e a6 f0 |......X.... = .^..| [ ]: callout_process+0x280 013ed6f0 df 5e a7 50 00 51 77 c0 df 5e a8 78 01 47 d3 60 = |.^.P.Qw..^.x.G.`| 013ed700 01 47 d4 58 00 00 00 00 00 d1 ab 24 00 00 00 04 = |.G.X.......$....| 013ed710 00 c9 66 bc 00 c4 5e a8 00 c9 66 bc 00 d4 c5 4c = |..f...^...f....L| 013ed720 00 d0 53 00 00 eb a8 00 00 00 00 01 00 00 00 00 = |..S.............| 013ed730 df 5e a9 8c 00 00 00 00 df 5e a8 78 00 00 11 11 = |.^.......^.x....| 013ed740 97 a0 9d 9d df 5d 0d 00 00 d2 5b 10 df 5e a7 50 = |.....]....[..^.P| [ ]: handleevents+0x2ac 013ed750 df 5e a7 a0 00 8a b2 70 df 5e a7 60 df 5e a7 60 = |.^.....p.^.`.^.`| 013ed760 df 5e a7 a0 00 53 49 dc 00 d2 5b 10 00 00 00 04 = |.^...SI...[.....| 013ed770 df 5e a7 c0 05 9b d2 00 00 c9 66 bc 01 47 d3 60 = |.^........f..G.`| 013ed780 df 5e a9 8c 00 f6 1d 90 00 00 11 11 97 a0 9d 9d = |.^..............| 013ed790 df 5d 0d 00 df 5d 0d 30 00 d2 5b 10 df 5e a7 a0 = |.]...].0..[..^..| [ ]: timercb+0x4c4 013ed7a0 df 5e a8 20 00 8a d1 10 00 d2 6e 70 df 5e a7 b0 |.^. = ......np.^..| 013ed7b0 df 5e a7 e0 00 4a 96 00 00 00 11 11 00 00 00 00 = |.^...J..........| 013ed7c0 97 a0 9d 9d 53 27 aa d0 df 5e a8 78 05 86 37 00 = |....S'...^.x..7.| 013ed7d0 df 5e a7 f0 05 86 37 80 00 d4 be 00 00 cb 98 98 = |.^....7.........| 013ed7e0 00 c9 66 bc 00 c4 5e a8 00 c9 66 bc 00 d4 c5 4c = |..f...^...f....L| 013ed7f0 df 5e a9 e0 00 eb a8 00 00 c9 66 bc 01 47 d3 60 = |.^........f..G.`| 013ed800 df 5e a9 8c df 5e a8 78 01 47 d3 60 00 00 00 00 = |.^...^.x.G.`....| 013ed810 00 f6 1d 90 00 00 00 01 00 d2 6b dc df 5e a8 20 = |..........k..^. | [ ]: decr_intr+0xf4 013ed820 df 5e a8 40 00 8e 1f 08 00 00 00 00 00 00 00 04 = |.^.@............| 013ed830 01 47 d4 34 00 00 00 01 00 d2 6e 60 df 5e a8 40 = |.G.4......n`.^.@| [ ]: powerpc_dispatch_intr+0xf8 013ed840 df 5e a8 70 00 8e 7d 5c 00 d1 ca ac df 5e a8 50 = |.^.p..}\.....^.P| 013ed850 00 cd f0 74 00 00 00 03 00 00 00 03 00 eb af 00 = |...t............| 013ed860 01 81 a4 7c 0a 00 00 00 00 00 00 00 00 00 90 32 = |...|...........2| [ ]: trapexit+0x0 (after trapagain+0x4) 013ed870 df 5e a9 30 00 10 08 f8 00 04 90 32 df 5e a9 30 = |.^.0.......2.^.0| 013ed880 01 47 d3 60 00 00 00 00 0d 0a d2 89 00 00 00 00 = |.G.`............| 013ed890 0d 0a d2 89 00 19 e9 a4 00 00 00 00 00 00 00 44 = |...............D| 013ed8a0 01 fc a0 55 00 00 90 32 df 5d 0d 00 00 00 00 00 = |...U...2.]......| 013ed8b0 00 d4 be 00 00 cb 98 98 00 c9 66 bc 00 c4 5e a8 = |..........f...^.| 013ed8c0 00 c9 66 bc 00 d4 c5 4c df 5e a9 e0 00 eb a8 00 = |..f....L.^......| 013ed8d0 00 c9 66 bc 01 47 d3 60 df 5e a9 8c 00 00 00 03 = |..f..G.`.^......| 013ed8e0 00 00 00 03 00 eb af 00 00 00 00 00 00 8e 3c b8 = |..............<.| 013ed8f0 00 d2 6c 04 df 5e a9 30 00 8e 3c d4 40 00 00 42 = |..l..^.0..<.@..B| [ ]: cpu_idle_60x+0x88 013ed900 20 00 00 00 00 8e 3c b8 00 8e 3d 40 00 00 90 32 | = .....<...=3D@...2| [0x900 trap] 013ed910 00 00 09 00 01 81 a4 7c 0a 00 00 00 00 00 00 00 = |.......|........| 013ed920 8a 95 8e 6d 80 4a 8c 8c 00 00 00 00 00 00 00 04 = |...m.J..........| [ignore? ] (see above trap frame) 013ed930 df 5e a9 50 00 00 00 03 00 00 00 03 00 eb af 00 = |.^.P............| 013ed940 00 00 00 00 00 d4 ca 44 00 d2 6c 04 df 5e a9 50 = |.......D..l..^.P| [ ]: cpu_idle+0x58 013ed950 df 5e a9 70 00 8e 32 5c 00 00 00 02 00 eb af 00 = |.^.p..2\........| 013ed960 00 f2 d6 7c 00 00 00 03 00 d1 ca ac df 5e a9 70 = |...|.........^.p| [ ]: sched_idletd+0x4d4 013ed970 df 5e aa 50 00 53 6e 7c df 5e a9 80 00 00 00 00 = |.^.P.Sn|.^......| 013ed980 df 5e a9 b0 01 47 d3 60 00 d2 5b 10 ff ff ff fd = |.^...G.`..[.....| 013ed990 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| 013ed9a0 ff ff ff ff ff ff ff ff ff ff ff ff df 5e a9 b0 = |.............^..| 013ed9b0 df 5e a9 d0 00 00 00 02 ff ff ff ff 00 00 01 e5 = |.^..............| 013ed9c0 ff ff ff fd ff ff ff ff ff ff ff ff ff ff ff ff = |................| 013ed9d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| 013ed9e0 ff ff ff fd ff ff ff ff ff ff ff ff ff ff ff ff = |................| 013ed9f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| 013eda00 df 5e aa 50 00 f6 4a 00 00 00 00 00 00 00 00 00 = |.^.P..J.........| 013eda10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| * 013eda30 00 00 00 00 00 53 69 a8 df 5e aa 98 00 00 00 00 = |.....Si..^......| 013eda40 01 47 96 e0 01 47 d3 60 00 d1 b3 70 df 5e aa 50 = |.G...G.`...p.^.P| [ ]: fork_exit+0xb4 013eda50 df 5e aa 80 00 4a 3c b4 df 5e aa 60 fa 50 05 af = |.^...J<..^.`.P..| 013eda60 df 5e aa 80 00 00 00 00 00 00 00 00 00 00 00 00 = |.^..............| 013eda70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| [ ]: fork_tramoline+0x10 013eda80 00 00 00 00 00 8f 19 90 00 53 69 a8 00 00 00 00 = |.........Si.....| 013eda90 df 5e aa 98 00 00 00 00 00 00 00 00 00 00 00 00 = |.^..............| 013edaa0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| FYI: The memory protection debugging hack in (and some before): void moea64_kenter_attr(mmu_t mmu, vm_offset_t va, vm_paddr_t pa, = vm_memattr_t ma) is currently: # svnlite diff /usr/src/sys/powerpc/aim/mmu_oea64.c = = Index: = /usr/src/sys/powerpc/aim/mmu_oea64.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/powerpc/aim/mmu_oea64.c (revision 317820) +++ /usr/src/sys/powerpc/aim/mmu_oea64.c (working copy) @@ -1752,6 +1752,18 @@ PV_PAGE_UNLOCK(m); } =20 +#if defined(AIM) && !defined(__powerpc64__) +// +// Part of PowerMac G5 HACK FOR PROBLEM FINDING. . . +// (G5 used via 32-bit FreeBSD.) +// + +extern char _GOT_START_[]; // beginning of .got/.got.plt +extern char _GOT_END_[]; // ending of .got/.got.plt + +extern vm_offset_t __startkernel, __endkernel; +#endif + /* * Map a wired page into kernel virtual address space. */ @@ -1762,6 +1774,52 @@ struct pvo_entry *pvo, *oldpvo; =20 pvo =3D alloc_pvo_entry(0); +#if defined(AIM) && !defined(__powerpc64__) + // + // PowerMac G5 HACK FOR PROBLEM FINDING. . . + // (G5 used via 32-bit FreeBSD.) + // + // As a problem-finding-aid try to catch some examples of + // jumping to non-code in the kernel before it tries to + // execute that that code. Hopefully this will show where + // the bad jump into the likes of the .hash section is + // happening. (dbb bt and vmcore.*'s have not lead to + // that information so far.) + // + if (cpu_features & PPC_FEATURE_64) + { + // First deal with pages that should have the original + // VM_PROT_EXECUTE status for something on the page + // (most pages in the kernel area). So pages with some + // byte(s) from .text, .got, or .got.plt, along with + // any requested from before where __startkernel + // indicates. Also any va requested from a page + // containing where __endkernel indicates or later + // gets VM_PROT_EXECUTE if such a va is requested. + // + // So: have just the rest of the kernel area not have + // VM_PROT_EXECUTE status in hopes that it will report + // where the code is that is making bad jumps to + // non-code, such as jumping into the .hash section + // instead of reporting on illegal instructions + // from the incorrect traget area. + // + if ( va < ((vm_offset_t)(etext+(PAGE_SIZE-1)) & = ~PAGE_MASK) ) + pvo->pvo_pte.prot =3D VM_PROT_READ | = VM_PROT_WRITE | VM_PROT_EXECUTE; + + else if ( ((vm_offset_t)_GOT_START_ & ~PAGE_MASK) <=3D = va + && va < ((vm_offset_t)(_GOT_END_+(PAGE_SIZE-1)) = & ~PAGE_MASK) + ) + pvo->pvo_pte.prot =3D VM_PROT_READ | = VM_PROT_WRITE | VM_PROT_EXECUTE; + + else if ( va < (__endkernel & ~PAGE_MASK) ) + pvo->pvo_pte.prot =3D VM_PROT_READ | = VM_PROT_WRITE; + + else // Otherwise do as before the HACK: + pvo->pvo_pte.prot =3D VM_PROT_READ | = VM_PROT_WRITE | VM_PROT_EXECUTE; + } + else +#endif pvo->pvo_pte.prot =3D VM_PROT_READ | VM_PROT_WRITE | = VM_PROT_EXECUTE; pvo->pvo_pte.pa =3D (pa & ~ADDR_POFF) | moea64_calc_wimg(pa, = ma); pvo->pvo_vaddr |=3D PVO_WIRED; Being va based for when to avoid VM_PROT_EXECUTE this way means that the openfirmware related virtual addresses that go through this code still get VM_PROT_EXECUTE --even if some had pa's in the loaded kernel's address range (if such were possible). Note: While 32-bit powerpc FreeBSD uses a relocatable kernel format it seems to not actually change the code addresses on the G5 from what objdump reports when looking at /boot/kernel/kernel . =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Fri Jun 2 20:59:28 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7EC33AFB5EB for ; Fri, 2 Jun 2017 20:59:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-5.reflexion.net [208.70.210.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4299D772F8 for ; Fri, 2 Jun 2017 20:59:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10834 invoked from network); 2 Jun 2017 21:00:46 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 2 Jun 2017 21:00:46 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Fri, 02 Jun 2017 16:59:25 -0400 (EDT) Received: (qmail 14412 invoked from network); 2 Jun 2017 20:59:25 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 Jun 2017 20:59:25 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id EB30FEC918C; Fri, 2 Jun 2017 13:59:24 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: On a old PowerMac G5: two 32-bit powerpc FreeBSD vmcore's from having protected most wired kernel memory from execution: what is common Date: Fri, 2 Jun 2017 13:59:24 -0700 References: To: Justin Hibbits , Nathan Whitehorn , FreeBSD PowerPC ML , freebsd-hackers@freebsd.org In-Reply-To: Message-Id: <5B968644-462C-40AC-AFB6-48B19AAE87D8@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 20:59:28 -0000 [I'm adding a comparison/contrast of the values that ddb reported for register values going with the vmcore.5 and vmcore.6 contexts.] On 2017-Jun-2, at 6:15 AM, Mark Millard wrote: > Based on the changed page protections. . . > Instead of illegal instruction the periodic/random kernel panic > reported for both example panics: >=20 > fatal kernel trap: >=20 > exception =3D 0x400 instruction storage interrupt > virtual address =3D 0x90a0f0 > srr0 =3D 0x90a0f0 > srr1 =3D 0x10001032 > lr =3D 0x535ad0 > (sched_affinity+0x18 ???) > curthread =3D 0x147d360 > pid =3D 11, comm =3D idle: cpu1 >=20 > [ thread pid 11 tid 100003 ] > Stopped at etext+0xb8fc: illegal instruction 0 >=20 > (So it looks like I disabled execute in that > area correctly.) >=20 >=20 > Most levels of the backtraces are different > between vmcore.5 and vmcore.6 . But the > lowest level ones are the same. >=20 > In particular the prior bl is to tdq_add > from sched_add but the 0x90a0f0 it jumps > to when getting the 0x400 exception is > wildly different than the 0x5356ec for the > bl to tdq_add. >=20 > For reference: sched_affinity through > sched_affinity+0x18 is: >=20 > 00535ab8 stwu r1,-32(r1) > 00535abc mflr r0 > 00535ac0 stw r29,20(r1) > 00535ac4 stw r30,24(r1) > 00535ac8 stw r31,28(r1) > 00535acc stw r0,36(r1) > 00535ad0 mr r31,r1 >=20 > So 00535ad0 is an odd spot for a lr value. >=20 >=20 > backtrace summary for vmcore.5: > (Listing the LR values, not 4 back from that.) >=20 > trapexit+0x0 (after trapagain+0x4) for 0x400 trap > 0x90a0f0 from .hash section (bad address) > sched_add+0x1a0 > 005359c4 bl 004cde6c > 005359c8 bl 008ea4e0 > 005359cc mr r3,r28 > 005359d0 mr r4,r27 > 005359d4 mr r5,r25 > 005359d8 bl 005356ec > 005359dc mfsprg r9,0 >=20 > (from here until cpu_idle_60x+0x88 is not common with vmcore.6) > intr_event_schedule_thread+0xd0 > 004a8780 mr r3,r28 > 004a8784 li r4,4 > 004a8788 bl 0053583c = > 004a878c lwz r9,0(r28) > intr_event_handle+0x114 > powerpc_dispatch_intr+0xcc > openpic_dispatch+0x94 > powerpc_interrupt+0xc4 > trapexit+0x0 (after trapagain+0x4) for 0x500 trap (vmcore.6: 0x900) >=20 > cpu_idle_60x+0x88 > . . . (not shown) >=20 >=20 > backtrace summary for vmcore.6: > (Listing the LR values, not 4 back from that.) >=20 > trapexit+0x0 (after trapagain+0x4) for 0x400 trap > 0x90a0f0 from .hash section (bad address) > sched_add+0x1a0 > 005359c4 bl 004cde6c > 005359c8 bl 008ea4e0 > 005359cc mr r3,r28 > 005359d0 mr r4,r27 > 005359d4 mr r5,r25 > 005359d8 bl 005356ec > 005359dc mfsprg r9,0 >=20 > (from here until cpu_idle_60x+0x88 is not common with vmcore.5) > sched_wakeup+0xa8 > 00535c0c mr r3,r29 > 00535c10 li r4,0 > 00535c14 bl 0053583c > 00535c18 lwz r11,0(r1) > setrunnable+0xa0 > sleepq_resume_thread+0x180 > sleepq_timeout+0xcc > softclock_call_cc+0x1f4 > callout_process+0x280 > handleevents+0x2ac > timercb+0x4c4 > decr_intr+0xf4 > powerpc_dispatch_intr+0xf8 > trapexit+0x0 (after trapagain+0x4) for 0x900 trap (vmcore.5: 0x500) >=20 > cpu_idle_60x+0x88 > . . . (not shown) >=20 >=20 >=20 > =46rom the vmcore.5: > (The formatting depends on mono-spaced text) >=20 > [ ]: trapexit+0x0 (after trapagain+0x4) > 013ed680 df 5e a7 40 00 10 08 f8 00 00 00 04 df 5e a7 40 = |.^.@.........^.@| > 013ed690 01 47 d3 60 00 00 00 14 01 47 e3 60 00 00 00 04 = |.G.`.....G.`....| > 013ed6a0 00 00 00 04 00 fd 98 7f 00 00 00 00 00 d4 c0 50 = |...............P| > 013ed6b0 01 47 d3 60 df 5e a7 80 df 5d 0d 00 00 00 00 00 = |.G.`.^...]......| > 013ed6c0 00 d4 be 00 00 cb 98 98 00 c9 66 bc 00 c4 5e a8 = |..........f...^.| > 013ed6d0 00 c9 66 bc 00 d4 c5 4c df 5e a9 e0 00 eb a8 00 = |..f....L.^......| > 013ed6e0 00 c9 66 bc 01 47 d3 60 00 00 00 00 df 5e a8 78 = |..f..G.`.....^.x| > 013ed6f0 01 44 0e 00 01 47 d3 60 00 eb af 00 01 47 d3 60 = |.D...G.`.....G.`| > 013ed700 00 d1 ca ac df 5e a7 40 00 53 5a d0 20 00 90 34 = |.....^.@.SZ. ..4| > [ ]: sched_affinity+0x18 >=20 > [ ]: =46rom .hash section > 013ed710 00 00 00 00 00 8d ef b4 00 90 a0 f0 10 00 10 32 = |...............2| > [0x400 trap] > 013ed720 00 00 04 00 41 a1 e5 68 0a 00 00 00 01 47 e3 60 = |....A..h.....G.`| > 013ed730 00 eb af 00 01 47 d3 60 00 d1 ca ac df 5e a7 40 = |.....G.`.....^.@| >=20 > [ ]: sched_add+0x1a0 > 013ed740 df 5e a7 80 00 53 59 dc 00 c9 66 bc 00 d4 c5 4c = |.^...SY...f....L| > 013ed750 df 5e a9 e0 00 eb a8 00 00 c9 66 bc 00 00 00 04 = |.^........f.....| > 013ed760 00 00 00 00 df 5e a8 78 01 44 0e 00 01 47 d3 60 = |.....^.x.D...G.`| > 013ed770 01 47 e3 60 01 51 ff 80 00 d1 b4 30 df 5e a7 80 = |.G.`.Q.....0.^..| >=20 > [ ]: intr_event_schedule_thread+0xd0 > 013ed780 df 5e a7 b0 00 4a 87 8c 6d 0c 21 5c df 5e 00 00 = |.^...J..m.!\.^..| > 013ed790 df 5e a7 b0 00 00 00 7c 00 00 00 00 01 47 d3 60 = |.^.....|.....G.`| > 013ed7a0 00 00 00 01 00 00 00 00 00 d2 6e 70 df 5e a7 b0 = |..........np.^..| >=20 > [ ]: intr_event_handle+0x114 > 013ed7b0 df 5e a7 e0 00 4a 95 fc 00 c9 66 bc 00 00 00 00 = |.^...J....f.....| > 013ed7c0 df 5e a9 8c df 5e a8 78 df 5e a8 78 01 44 0e 00 = |.^...^.x.^.x.D..| > 013ed7d0 00 02 10 a0 01 48 b2 80 00 d2 6e 70 df 5e a7 e0 = |.....H....np.^..| >=20 > [ ]: powerpc_dispatch_intr+0xcc > 013ed7e0 df 5e a8 10 00 8e 91 8c df 5e a7 f0 00 cf 48 a8 = |.^.......^....H.| > 013ed7f0 df 5e a8 10 df 5e a8 78 01 47 d3 60 df 5e a8 78 = |.^...^.x.G.`.^.x| > 013ed800 00 02 10 a0 01 4c d4 00 00 d2 70 2c df 5e a8 10 = |.....L....p,.^..| >=20 > [ ]: openpic_dispatch+0x94 > 013ed810 df 5e a8 40 00 8e c9 48 ec 94 8e 64 e6 38 8f 72 = |.^.@...H...d.8.r| > 013ed820 df 5e a8 40 00 00 00 02 00 00 00 00 00 eb af 00 = |.^.@............| > 013ed830 41 a1 e5 68 01 48 b1 00 00 d2 6e 60 df 5e a8 40 = |A..h.H....n`.^.@| >=20 > [ ]: powerpc_interrupt+0xc4 > 013ed840 df 5e a8 70 00 8e 7d 28 8b 00 00 00 00 00 55 c4 = |.^.p..}(......U.| > 013ed850 00 cd f0 74 00 00 00 03 00 00 00 03 00 eb af 00 = |...t............| > 013ed860 41 a1 e5 68 0a 00 00 00 00 00 00 00 00 00 90 32 = |A..h...........2| >=20 > [ ]: trapexit+0x0 (after trapagain+0x4) > 013ed870 df 5e a9 30 00 10 08 f8 00 04 90 32 df 5e a9 30 = |.^.0.......2.^.0| > 013ed880 01 47 d3 60 00 00 00 00 7f a3 8e 84 00 00 00 00 = |.G.`............| > 013ed890 7f a3 8e 84 00 fd 98 7f 00 00 00 00 00 00 00 44 = |...............D| > 013ed8a0 01 fc a0 55 00 00 90 32 df 5d 0d 00 00 00 00 00 = |...U...2.]......| > 013ed8b0 00 d4 be 00 00 cb 98 98 00 c9 66 bc 00 c4 5e a8 = |..........f...^.| > 013ed8c0 00 c9 66 bc 00 d4 c5 4c df 5e a9 e0 00 eb a8 00 = |..f....L.^......| > 013ed8d0 00 c9 66 bc 01 47 d3 60 df 5e a9 8c 00 00 00 03 = |..f..G.`.^......| > 013ed8e0 00 00 00 03 00 eb af 00 00 00 00 00 00 8e 3c b8 = |..............<.| > 013ed8f0 00 d2 6c 04 df 5e a9 30 00 8e 3c d4 40 00 00 42 = |..l..^.0..<.@..B| >=20 > [ ]: cpu_idle_60x+0x88 > 013ed900 20 00 00 00 00 8e 3c b8 00 8e 3d 40 00 00 90 32 | = .....<...=3D@...2| > [0x500 trap] > 013ed910 00 00 05 00 41 a1 e5 68 0a 00 00 00 00 00 00 00 = |....A..h........| > 013ed920 0b 5c 71 7c 79 c0 d7 fc 00 00 00 00 00 00 00 04 = |.\q|y...........| >=20 > [ignore? ] (see above trap frame) > 013ed930 df 5e a9 50 00 00 00 03 00 00 00 03 00 eb af 00 = |.^.P............| > 013ed940 00 00 00 00 00 d4 ca 44 00 d2 6c 04 df 5e a9 50 = |.......D..l..^.P| >=20 > [ ]: cpu_idle+0x58 > 013ed950 df 5e a9 70 00 8e 32 5c 00 00 00 02 00 eb af 00 = |.^.p..2\........| > 013ed960 00 f2 d6 7c 00 00 00 03 00 d1 ca ac df 5e a9 70 = |...|.........^.p| >=20 > [ ]: sched_idletd+0x4d4 > 013ed970 df 5e aa 50 00 53 6e 7c df 5e a9 80 00 00 00 00 = |.^.P.Sn|.^......| > 013ed980 df 5e a9 b0 01 47 d3 60 df 5e a9 90 ff ff ff fd = |.^...G.`.^......| > 013ed990 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| > 013ed9a0 ff ff ff ff ff ff ff ff ff ff ff ff df 5e a9 b0 = |.............^..| > 013ed9b0 df 5e a9 d0 00 00 00 02 ff ff ff ff 00 00 01 e5 = |.^..............| > 013ed9c0 ff ff ff fd ff ff ff ff ff ff ff ff ff ff ff ff = |................| > 013ed9d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| > 013ed9e0 ff ff ff fd ff ff ff ff ff ff ff ff ff ff ff ff = |................| > 013ed9f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| > 013eda00 df 5e aa 20 00 f6 4a 00 00 00 00 00 00 00 00 00 |.^. = ..J.........| > 013eda10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| > * > 013eda30 00 00 00 00 00 53 69 a8 df 5e aa 98 00 00 00 00 = |.....Si..^......| > 013eda40 01 47 96 e0 01 47 d3 60 00 d1 b3 70 df 5e aa 50 = |.G...G.`...p.^.P| >=20 > [ ]: fork_exit+0xb4 > 013eda50 df 5e aa 80 00 4a 3c b4 df 5e aa 60 df 5e aa 60 = |.^...J<..^.`.^.`| > 013eda60 df 5e aa 80 00 00 00 00 00 00 00 00 00 00 00 00 = |.^..............| > 013eda70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >=20 > [ ]: fork_tramoline+0x10 > 013eda80 00 00 00 00 00 8f 19 90 00 53 69 a8 00 00 00 00 = |.........Si.....| > 013eda90 df 5e aa 98 00 00 00 00 00 00 00 00 00 00 00 00 = |.^..............| > 013edaa0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >=20 >=20 >=20 > =46rom the vmcore.6: >=20 > [ ]: trapexit+0x0 (after trapagain+0x4) > 013ed4d0 df 5e a5 90 00 10 08 f8 00 00 00 04 df 5e a5 90 = |.^...........^..| > 013ed4e0 01 47 d3 60 00 00 00 54 05 91 b0 00 00 00 00 00 = |.G.`...T........| > 013ed4f0 00 00 00 00 00 00 00 0f 00 00 00 00 00 d4 c0 50 = |...............P| > 013ed500 01 47 d3 60 df 5e a5 d0 00 00 00 00 00 00 00 00 = |.G.`.^..........| > 013ed510 00 d4 be 00 00 cb 98 98 00 d4 c4 6c 00 d4 c4 6c = |...........l...l| > 013ed520 00 11 11 97 00 11 12 16 00 00 11 11 05 91 b0 00 = |................| > 013ed530 00 56 64 30 00 00 01 14 00 00 00 00 00 00 00 00 = |.Vd0............| > 013ed540 00 00 00 01 00 00 00 00 00 eb af 00 01 47 d3 60 = |.............G.`| > 013ed550 00 d1 ca ac df 5e a5 90 00 53 5a d0 20 00 90 34 = |.....^...SZ. ..4| > [ ]: sched_affinity+0x18 >=20 > [ ]: =46rom .hash section > 013ed560 00 00 00 00 00 00 00 00 00 90 a0 f0 10 00 10 32 = |...............2| > [0x400 trap] > 013ed570 00 00 04 00 01 81 a4 7c 0a 00 00 00 05 91 b0 00 = |.......|........| > 013ed580 00 eb af 00 01 47 d3 60 00 d1 ca ac df 5e a5 90 = |.....G.`.....^..| >=20 > [ ]: sched_add+0x1a0 > 013ed590 df 5e a5 d0 00 53 59 dc 00 00 00 01 00 d4 c5 4c = |.^...SY........L| > 013ed5a0 df 5e 00 00 00 00 00 40 df 5e a5 b0 00 00 00 04 = |.^.....@.^......| > 013ed5b0 df 5e a5 d0 00 00 00 00 00 00 00 01 00 00 00 00 = |.^..............| > 013ed5c0 05 91 b3 28 05 91 b0 00 00 d1 ca ac df 5e a5 d0 = |...(.........^..| >=20 > [ ]: sched_wakeup+0xa8 > 013ed5d0 df 5e a5 f0 00 53 5c 18 00 00 00 00 00 00 00 00 = |.^...S\.........| > 013ed5e0 01 42 b0 80 05 91 b0 00 00 d1 c4 c4 df 5e a5 f0 = |.B...........^..| >=20 > [ ]: setrunnable+0xa0 > 013ed5f0 df 5e a6 10 00 50 26 08 df 5e a6 00 00 cb 98 98 = |.^...P&..^......| > 013ed600 df 5e a6 40 00 d4 c4 6c 00 d1 d5 34 df 5e a6 10 = |.^.@...l...4.^..| >=20 > [ ]: sleepq_resume_thread+0x180 > 013ed610 df 5e a6 40 00 56 43 2c 00 56 64 30 00 00 01 14 = |.^.@.VC,.Vd0....| > 013ed620 df 5e a6 40 00 00 00 00 00 00 00 01 00 00 11 11 = |.^.@............| > 013ed630 8a d3 94 2a 05 91 b0 00 00 d1 d5 34 df 5e a6 40 = |...*.......4.^.@| >=20 > [ ]: sleepq_timeout+0xcc > 013ed640 df 5e a6 80 00 56 64 fc 00 c9 66 bc 00 00 00 00 = |.^...Vd...f.....| > 013ed650 00 00 11 11 00 00 00 00 97 a0 fc 3d 80 96 c0 38 = |...........=3D...8| > 013ed660 df 5e a6 80 00 8e a5 04 00 d2 5b 10 05 91 b2 a0 = |.^........[.....| > 013ed670 00 e9 58 00 00 00 00 00 00 d1 c8 20 df 5e a6 80 = |..X........ .^..| >=20 > [ ]: softclock_call_cc+0x1f4 > 013ed680 df 5e a6 f0 00 51 63 84 00 d2 5b 10 df 5e a6 90 = |.^...Qc...[..^..| > 013ed690 df 5e a6 f0 00 8a ca a8 df 5e a6 a0 00 00 00 0f = |.^.......^......| > 013ed6a0 df 5e a7 10 00 4c e2 f4 68 fc 88 02 00 00 00 04 = |.^...L..h.......| > 013ed6b0 df 5e a6 d0 00 00 00 02 00 11 11 97 00 11 12 16 = |.^..............| > 013ed6c0 00 00 11 11 d7 a0 9d 9d 00 11 11 8a 00 00 11 11 = |................| > 013ed6d0 97 a0 9d 9d 00 00 11 12 17 00 00 00 00 00 11 12 = |................| > 013ed6e0 17 00 00 00 00 e9 58 00 00 d1 c8 20 df 5e a6 f0 = |......X.... .^..| >=20 > [ ]: callout_process+0x280 > 013ed6f0 df 5e a7 50 00 51 77 c0 df 5e a8 78 01 47 d3 60 = |.^.P.Qw..^.x.G.`| > 013ed700 01 47 d4 58 00 00 00 00 00 d1 ab 24 00 00 00 04 = |.G.X.......$....| > 013ed710 00 c9 66 bc 00 c4 5e a8 00 c9 66 bc 00 d4 c5 4c = |..f...^...f....L| > 013ed720 00 d0 53 00 00 eb a8 00 00 00 00 01 00 00 00 00 = |..S.............| > 013ed730 df 5e a9 8c 00 00 00 00 df 5e a8 78 00 00 11 11 = |.^.......^.x....| > 013ed740 97 a0 9d 9d df 5d 0d 00 00 d2 5b 10 df 5e a7 50 = |.....]....[..^.P| >=20 > [ ]: handleevents+0x2ac > 013ed750 df 5e a7 a0 00 8a b2 70 df 5e a7 60 df 5e a7 60 = |.^.....p.^.`.^.`| > 013ed760 df 5e a7 a0 00 53 49 dc 00 d2 5b 10 00 00 00 04 = |.^...SI...[.....| > 013ed770 df 5e a7 c0 05 9b d2 00 00 c9 66 bc 01 47 d3 60 = |.^........f..G.`| > 013ed780 df 5e a9 8c 00 f6 1d 90 00 00 11 11 97 a0 9d 9d = |.^..............| > 013ed790 df 5d 0d 00 df 5d 0d 30 00 d2 5b 10 df 5e a7 a0 = |.]...].0..[..^..| >=20 > [ ]: timercb+0x4c4 > 013ed7a0 df 5e a8 20 00 8a d1 10 00 d2 6e 70 df 5e a7 b0 |.^. = ......np.^..| > 013ed7b0 df 5e a7 e0 00 4a 96 00 00 00 11 11 00 00 00 00 = |.^...J..........| > 013ed7c0 97 a0 9d 9d 53 27 aa d0 df 5e a8 78 05 86 37 00 = |....S'...^.x..7.| > 013ed7d0 df 5e a7 f0 05 86 37 80 00 d4 be 00 00 cb 98 98 = |.^....7.........| > 013ed7e0 00 c9 66 bc 00 c4 5e a8 00 c9 66 bc 00 d4 c5 4c = |..f...^...f....L| > 013ed7f0 df 5e a9 e0 00 eb a8 00 00 c9 66 bc 01 47 d3 60 = |.^........f..G.`| > 013ed800 df 5e a9 8c df 5e a8 78 01 47 d3 60 00 00 00 00 = |.^...^.x.G.`....| > 013ed810 00 f6 1d 90 00 00 00 01 00 d2 6b dc df 5e a8 20 = |..........k..^. | >=20 > [ ]: decr_intr+0xf4 > 013ed820 df 5e a8 40 00 8e 1f 08 00 00 00 00 00 00 00 04 = |.^.@............| > 013ed830 01 47 d4 34 00 00 00 01 00 d2 6e 60 df 5e a8 40 = |.G.4......n`.^.@| >=20 > [ ]: powerpc_dispatch_intr+0xf8 > 013ed840 df 5e a8 70 00 8e 7d 5c 00 d1 ca ac df 5e a8 50 = |.^.p..}\.....^.P| > 013ed850 00 cd f0 74 00 00 00 03 00 00 00 03 00 eb af 00 = |...t............| > 013ed860 01 81 a4 7c 0a 00 00 00 00 00 00 00 00 00 90 32 = |...|...........2| >=20 > [ ]: trapexit+0x0 (after trapagain+0x4) > 013ed870 df 5e a9 30 00 10 08 f8 00 04 90 32 df 5e a9 30 = |.^.0.......2.^.0| > 013ed880 01 47 d3 60 00 00 00 00 0d 0a d2 89 00 00 00 00 = |.G.`............| > 013ed890 0d 0a d2 89 00 19 e9 a4 00 00 00 00 00 00 00 44 = |...............D| > 013ed8a0 01 fc a0 55 00 00 90 32 df 5d 0d 00 00 00 00 00 = |...U...2.]......| > 013ed8b0 00 d4 be 00 00 cb 98 98 00 c9 66 bc 00 c4 5e a8 = |..........f...^.| > 013ed8c0 00 c9 66 bc 00 d4 c5 4c df 5e a9 e0 00 eb a8 00 = |..f....L.^......| > 013ed8d0 00 c9 66 bc 01 47 d3 60 df 5e a9 8c 00 00 00 03 = |..f..G.`.^......| > 013ed8e0 00 00 00 03 00 eb af 00 00 00 00 00 00 8e 3c b8 = |..............<.| > 013ed8f0 00 d2 6c 04 df 5e a9 30 00 8e 3c d4 40 00 00 42 = |..l..^.0..<.@..B| >=20 > [ ]: cpu_idle_60x+0x88 > 013ed900 20 00 00 00 00 8e 3c b8 00 8e 3d 40 00 00 90 32 | = .....<...=3D@...2| > [0x900 trap] > 013ed910 00 00 09 00 01 81 a4 7c 0a 00 00 00 00 00 00 00 = |.......|........| > 013ed920 8a 95 8e 6d 80 4a 8c 8c 00 00 00 00 00 00 00 04 = |...m.J..........| >=20 > [ignore? ] (see above trap frame) > 013ed930 df 5e a9 50 00 00 00 03 00 00 00 03 00 eb af 00 = |.^.P............| > 013ed940 00 00 00 00 00 d4 ca 44 00 d2 6c 04 df 5e a9 50 = |.......D..l..^.P| >=20 > [ ]: cpu_idle+0x58 > 013ed950 df 5e a9 70 00 8e 32 5c 00 00 00 02 00 eb af 00 = |.^.p..2\........| > 013ed960 00 f2 d6 7c 00 00 00 03 00 d1 ca ac df 5e a9 70 = |...|.........^.p| >=20 > [ ]: sched_idletd+0x4d4 > 013ed970 df 5e aa 50 00 53 6e 7c df 5e a9 80 00 00 00 00 = |.^.P.Sn|.^......| > 013ed980 df 5e a9 b0 01 47 d3 60 00 d2 5b 10 ff ff ff fd = |.^...G.`..[.....| > 013ed990 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| > 013ed9a0 ff ff ff ff ff ff ff ff ff ff ff ff df 5e a9 b0 = |.............^..| > 013ed9b0 df 5e a9 d0 00 00 00 02 ff ff ff ff 00 00 01 e5 = |.^..............| > 013ed9c0 ff ff ff fd ff ff ff ff ff ff ff ff ff ff ff ff = |................| > 013ed9d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| > 013ed9e0 ff ff ff fd ff ff ff ff ff ff ff ff ff ff ff ff = |................| > 013ed9f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff = |................| > 013eda00 df 5e aa 50 00 f6 4a 00 00 00 00 00 00 00 00 00 = |.^.P..J.........| > 013eda10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| > * > 013eda30 00 00 00 00 00 53 69 a8 df 5e aa 98 00 00 00 00 = |.....Si..^......| > 013eda40 01 47 96 e0 01 47 d3 60 00 d1 b3 70 df 5e aa 50 = |.G...G.`...p.^.P| >=20 > [ ]: fork_exit+0xb4 > 013eda50 df 5e aa 80 00 4a 3c b4 df 5e aa 60 fa 50 05 af = |.^...J<..^.`.P..| > 013eda60 df 5e aa 80 00 00 00 00 00 00 00 00 00 00 00 00 = |.^..............| > 013eda70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >=20 > [ ]: fork_tramoline+0x10 > 013eda80 00 00 00 00 00 8f 19 90 00 53 69 a8 00 00 00 00 = |.........Si.....| > 013eda90 df 5e aa 98 00 00 00 00 00 00 00 00 00 00 00 00 = |.^..............| > 013edaa0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >=20 >=20 > FYI: The memory protection debugging hack in (and some > before): >=20 > void > moea64_kenter_attr(mmu_t mmu, vm_offset_t va, vm_paddr_t pa, = vm_memattr_t ma) >=20 > is currently: >=20 > # svnlite diff /usr/src/sys/powerpc/aim/mmu_oea64.c = = Index: = /usr/src/sys/powerpc/aim/mmu_oea64.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/powerpc/aim/mmu_oea64.c (revision 317820) > +++ /usr/src/sys/powerpc/aim/mmu_oea64.c (working copy) > @@ -1752,6 +1752,18 @@ > PV_PAGE_UNLOCK(m); > } >=20 > +#if defined(AIM) && !defined(__powerpc64__) > +// > +// Part of PowerMac G5 HACK FOR PROBLEM FINDING. . . > +// (G5 used via 32-bit FreeBSD.) > +// > + > +extern char _GOT_START_[]; // beginning of .got/.got.plt > +extern char _GOT_END_[]; // ending of .got/.got.plt > + > +extern vm_offset_t __startkernel, __endkernel; > +#endif > + > /* > * Map a wired page into kernel virtual address space. > */ > @@ -1762,6 +1774,52 @@ > struct pvo_entry *pvo, *oldpvo; >=20 > pvo =3D alloc_pvo_entry(0); > +#if defined(AIM) && !defined(__powerpc64__) > + // > + // PowerMac G5 HACK FOR PROBLEM FINDING. . . > + // (G5 used via 32-bit FreeBSD.) > + // > + // As a problem-finding-aid try to catch some examples of > + // jumping to non-code in the kernel before it tries to > + // execute that that code. Hopefully this will show where > + // the bad jump into the likes of the .hash section is > + // happening. (dbb bt and vmcore.*'s have not lead to > + // that information so far.) > + // > + if (cpu_features & PPC_FEATURE_64) > + { > + // First deal with pages that should have the original > + // VM_PROT_EXECUTE status for something on the page > + // (most pages in the kernel area). So pages with some > + // byte(s) from .text, .got, or .got.plt, along with > + // any requested from before where __startkernel > + // indicates. Also any va requested from a page > + // containing where __endkernel indicates or later > + // gets VM_PROT_EXECUTE if such a va is requested. > + // > + // So: have just the rest of the kernel area not have > + // VM_PROT_EXECUTE status in hopes that it will report > + // where the code is that is making bad jumps to > + // non-code, such as jumping into the .hash section > + // instead of reporting on illegal instructions > + // from the incorrect traget area. > + // > + if ( va < ((vm_offset_t)(etext+(PAGE_SIZE-1)) & = ~PAGE_MASK) ) > + pvo->pvo_pte.prot =3D VM_PROT_READ | = VM_PROT_WRITE | VM_PROT_EXECUTE; > + > + else if ( ((vm_offset_t)_GOT_START_ & ~PAGE_MASK) <=3D = va > + && va < ((vm_offset_t)(_GOT_END_+(PAGE_SIZE-1)) = & ~PAGE_MASK) > + ) > + pvo->pvo_pte.prot =3D VM_PROT_READ | = VM_PROT_WRITE | VM_PROT_EXECUTE; > + > + else if ( va < (__endkernel & ~PAGE_MASK) ) > + pvo->pvo_pte.prot =3D VM_PROT_READ | = VM_PROT_WRITE; > + > + else // Otherwise do as before the HACK: > + pvo->pvo_pte.prot =3D VM_PROT_READ | = VM_PROT_WRITE | VM_PROT_EXECUTE; > + } > + else > +#endif > pvo->pvo_pte.prot =3D VM_PROT_READ | VM_PROT_WRITE | = VM_PROT_EXECUTE; > pvo->pvo_pte.pa =3D (pa & ~ADDR_POFF) | moea64_calc_wimg(pa, = ma); > pvo->pvo_vaddr |=3D PVO_WIRED; >=20 > Being va based for when to avoid VM_PROT_EXECUTE > this way means that the openfirmware related > virtual addresses that go through this code still > get VM_PROT_EXECUTE --even if some had pa's in the > loaded kernel's address range (if such were > possible). >=20 >=20 >=20 > Note: While 32-bit powerpc FreeBSD uses a relocatable > kernel format it seems to not actually change the > code addresses on the G5 from what objdump reports > when looking at /boot/kernel/kernel . Below I compare and contrast the vmcore.5 and vmcore.6 register values that were reported by ddb at the time (via show reg). r0, r2, r9, r10, r14, r15, r24, r28, r29, r30, srr0, srr1, lr, cr, xer, and dsisr have the same values and the others do not. The pointers into the stacks are different in specific value when both vmcore.*'s have a stack address in the same register. But both point into the same stack area in such cases. (But vmcore.*'s happened to get the problem on cpu 1's idle thread so this is expected.) reg: vmcore.5's value, vmcore.6's value r0: 0x4, 0x4 r1: 0xdf5ea740, 0xdf5ea590 r2: 0x147d360, 0x147d360 r3: 0x14, 0x54 r4: 0x147de60, 0x591b000 r5: 0x4, 0 r6: 0x4, 0 r7: 0xfd987f end+0x50cf, 0xf r8: 0, 0 r9: 0xd4c050 cold, 0xd4c050 cold r10: 0x147d360, 0x147d360 r11: 0xdf5ea780, 0xdf5ea5d0 r12: 0xdf5d0d00, 0 r13: 0, 0 r14: 0xd4be00 sdt_probe_func, 0xd4be00 sdt_probe_func r15: 0xcb9898 sdt_lockstat__spin__release, 0xcb9898 sdt_lockstat__spin__release r16: 0xc966bc sched_interact, 0xd4c46c callsheelmask r17: 0xc45ea8, 0xd4c46c callsheelmask r18: 0xc966bc sched_interact, 0x111197 xpt_done_process+0x617 r19: 0xd4c54c smp_started, 0x111216 xpt_done_process+0x696 r20: 0xdfea9e0, 0x1111 dsmmisssize+0x1021 r21: 0xeb800 tdq_cpu, 0x591b000 r22: 0xc966bc sched_interact, 0x566430 sleepq_timeout r23: 0x147d360, 0x114 dsmisssize+0x24 r24: 0, 0 r25: 0xdf5ea878, 0 r26: 0x1440e00, 0x1 r27: 0x147d360, 0 r28: 0xebaf00 tdq_cpu+0x700, 0xebaf00 tdq_cpu+0x700 r29: 0x147d360, 0x147d360 r30: 0xd1caac, 0xd1caac r31: 0xdf5ea740, 0xdf5ea590 srr0: 0x90a0f0 etext+0xb8fc, 0x90a0f0 etext+0xb8fc srr1: 0x10001032, 0x10001032 lr: 0x535ad0 sched_affinity+0x18, 0x535ad0 sched_affinity+0x18 ctr: 0x8defb4 bs_be_ws_4, 0 cr: 0x20009034, 0x20009034 xer: 0, 0 dar: 0x41a1e568, 0x181a47c dsisr: 0xa000000, 0xa000000 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Sat Jun 3 14:20:47 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C0604BF25E5 for ; Sat, 3 Jun 2017 14:20:47 +0000 (UTC) (envelope-from mason@blisses.org) Received: from phlegethon.blisses.org (phlegethon.blisses.org [50.56.97.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A4AAB712A4 for ; Sat, 3 Jun 2017 14:20:47 +0000 (UTC) (envelope-from mason@blisses.org) Received: from blisses.org (cocytus.blisses.org [64.223.129.151]) by phlegethon.blisses.org (Postfix) with ESMTPSA id BC06D194D1B for ; Sat, 3 Jun 2017 10:20:45 -0400 (EDT) Date: Sat, 3 Jun 2017 10:20:43 -0400 From: Mason Loring Bliss To: freebsd-hackers@freebsd.org Subject: Linuxulator / Chrome Message-ID: <20170603142043.GB8701@blisses.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="24zk1gE8NUlDmwG9" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 14:20:47 -0000 --24zk1gE8NUlDmwG9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [Posted to freebsd-questions last night, but there's probably a better chance of someone having done this here.] Hi all. Will Chrome work on Linuxulator if I chase down enough dependencies= ? =20 I'm trying to get BlueJeans running, and it's balking in both Firefox and = =20 Chromium on FreeBSD (11-STABLE) so I figured I'd give Chrome under the = =20 Linuxulator a try. I hit several missing libraries until I realized I neede= d =20 to install the whole linux-c6 (also tried linux-c7) suite. = =20 = =20 Once that was done, I hit this: = =20 = =20 ./chrome: error while loading shared libraries: libgconf-2.so.4: cannot= =20 open shared object file: No such file or directory = =20 = =20 We don't seem to have a package for it. = =20 = =20 I tried running ldd to see what other libraries I'd need, but the ldd in = =20 /compat bailed out, saying "missing file". I suspect it's not intended to b= e =20 used, as it has /bin/bash in the shebang line. The native LDD was unhappy = =20 with the Chrome binary. = =20 = =20 I've now pulled out a list of libraries from a Linux machine where I could = =20 run ldd, and I can collect the libraries by hand from Linux to populate = =20 /compat, but I'm really interested in knowing if anyone's gotten Chrome = =20 working this way, or if I'll run into known obstacles once I have all the = =20 libraries in place. = =20 = =20 Thanks! = =20 --=20 Mason Loring Bliss mason@blisses.org http://blisses.o= rg/ =20 The sand bats of Manark IV look like inanimate rock crystals until they att= ack. --24zk1gE8NUlDmwG9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJZMsW7AAoJEJ6yV3B27yVVjBsP/jQK2HQOlKUVAIxqkS3PwxY9 7WSnXW4KhT9m6fqpG8zbBUhYxEspcRSrspo6HtiAsxAcUbfBfNO7GjS7RxUZMahD CQZmqEtAIhGY9SVcgC5sN1qXgiGGB5SgJRash7NzAspN0wqG8G9Sk1T4s9Czp23b Kkxm6pDjHM0lUpvIcc0R5nTmrDF2yi/M+tmT0+PtqD/pKwrPqwNuhALfTE0I6iGJ h5fIA4afdY+twHX3NSY6GLDhC1J00IhzF5fJJWaTsHXgsT7hoKBwNms9Uc1fKtWM MNzMD1h8xQtuYI2GmcPUWiKiOEkB6ZR4EMk3EFWbMFRTFJsyG14LEliYU/UTDv1w u5TOM6X52OtWl6v7KN5hDk97CHDA5rqixbg9xSis2StzzcCNaGXMb9lEjJFvXZ+1 a4QqH1yuLoYkHnPSaue9dqQY3djDPAbE9dX6mqEG2gSWS9kKnfdOKHSWYRFJJatL EMOvFxWTvhvpg3U3kbrm8gzJ52L97+QRmEE3OC5YdEJuz84BDZtUkWtjsldCX1x6 Lgap/hmj90EcKRizbTpGZiidhtNcPw2344twq1S8xWkJKMCGiMDF+gpBoqhyYZRP hsDV4WhqX7kvjU0uBPOIiru1MiQ7e1ilDJHs+8Y55aYHppw+hJtYemMTX8T/85sX eT3ScT3WgIHu1rTc/MG8 =baCD -----END PGP SIGNATURE----- --24zk1gE8NUlDmwG9-- From owner-freebsd-hackers@freebsd.org Sat Jun 3 20:07:23 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 20390BF8547 for ; Sat, 3 Jun 2017 20:07:23 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CAD277CA06 for ; Sat, 3 Jun 2017 20:07:22 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-qk0-x234.google.com with SMTP id d14so79999648qkb.1 for ; Sat, 03 Jun 2017 13:07:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=X/kEkaXMGRZbepMqmPuf4nH/b6lf43XPJwLEnGxhy+Q=; b=ZIEVesKSnLl/AdDSyDzQyHk3T79hmqdf9Z/4QXTAztiULOzlfmpiBdGROnwsOp7pKH 2/WqfgK+ypj4QIDxo2alqbXRzeaI0sgVRYt8nHDMVU9Tt0+SFf2ZPNr5PTB3ht2epklf ndVEsdwBAQkmdJtzJtkGBJApPX9Aw80TTmZE0RD/D479x+R0xtmQtfD2MwG4GR2dryBp Q3TWuBx1ZmJqXsnPeRyRajkxL72amVsoWgHV/HoMzjLJWXUNn3vjQl7nRFOs2mBuqn1c TO1H8AL+5QdoBYeBchgIlQuPWMADh96LKht9spQlFDscLwoVjuaaswjTrutRaIunEKp0 Ks4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=X/kEkaXMGRZbepMqmPuf4nH/b6lf43XPJwLEnGxhy+Q=; b=dfSFkda+yKnA9BOrJ8UtCqLI6l1hE02rg2UkiGxuK/zNIDNHdJfZ6hSi/k5PK9EaAX GqqhNnBgKX7/deEjXoeNiZzQz7dGTxDT6VQqoSQ2nxOIcbycm7TsYLYBH9n8NOczn1Su f/gXmLWSKkd3c5nEA75mEJWuaM9YkGgZjObOCkfZ+H8heyDGVAT6d7ndtw+4MwuKzC+Z o45qBWFelbh2slEutDZSbun6k/jA1k9g9D/+nBMr9yLHif5CVEKXo0FTArJ0gMrQSoRv ltiQAiUP/IK3RhpftJroKZSDtgxdCVe7R7oaJAFK/lxyUP5hAyUY6s0FAB3HI9xQcJ+E JC9Q== X-Gm-Message-State: AODbwcBVwUXrVRRvnpEY7QiaYfm7lSKKRKQQKLr/8hsNaZXSjIOwvrcr MSCs93jppLfN3bqs4/c0HA== X-Received: by 10.55.97.212 with SMTP id v203mr16133567qkb.129.1496520441140; Sat, 03 Jun 2017 13:07:21 -0700 (PDT) Received: from ?IPv6:2600:1017:b429:cc40:1d3e:ed7a:831d:4601? ([2600:1017:b429:cc40:1d3e:ed7a:831d:4601]) by smtp.gmail.com with ESMTPSA id w12sm18081444qtc.20.2017.06.03.13.07.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 03 Jun 2017 13:07:19 -0700 (PDT) Mime-Version: 1.0 (1.0) Subject: Re: Linuxulator / Chrome From: Mark Saad X-Mailer: iPhone Mail (14F89) In-Reply-To: <20170603142043.GB8701@blisses.org> Date: Sat, 3 Jun 2017 16:07:18 -0400 Cc: freebsd-hackers@freebsd.org Message-Id: <52995F1D-D4C2-49E4-9B6F-38DF99A0FDE6@longcount.org> References: <20170603142043.GB8701@blisses.org> To: Mason Loring Bliss Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 20:07:23 -0000 --- Mark Saad | nonesuch@longcount.org > On Jun 3, 2017, at 10:20 AM, Mason Loring Bliss wrote:= >=20 > [Posted to freebsd-questions last night, but there's probably a better > chance of someone having done this here.] >=20 >=20 > Hi all. Will Chrome work on Linuxulator if I chase down enough dependencie= s? =20 I don't see why not . But you will need to get the alsa/oss parts working . I= would check out cooltrainer=20 https://cooltrainer.org/a-freebsd-desktop-howto/ Th sections on Skype audio are going to come in handy . > I'm trying to get BlueJeans running, and it's balking in both Firefox and = =20 > Chromium on FreeBSD (11-STABLE) so I figured I'd give Chrome under the = =20 > Linuxulator a try. I hit several missing libraries until I realized I need= ed =20 > to install the whole linux-c6 (also tried linux-c7) suite. = =20 >=20 If you have qemu you can try this . Create a new vm with a raw disk , boot u= p qemu with the centos 6 DVD do a ext4 disk setup with out lvm and a full de= sktop install . Then from qemu and that install try to get chrome working .P= ower off the vm .Then once done using mdconfig attach the raw disk and mount= it and copy that into a local dir for use as your Linux base . The. Give ch= rome a try . While involved it worked int the past for some app I had to dea= l with .=20 > Once that was done, I hit this: = =20 >=20 > ./chrome: error while loading shared libraries: libgconf-2.so.4: cannot= =20 > open shared object file: No such file or directory = =20 >=20 > We don't seem to have a package for it. = =20 >=20 > I tried running ldd to see what other libraries I'd need, but the ldd in = =20 > /compat bailed out, saying "missing file". I suspect it's not intended to b= e =20 > used, as it has /bin/bash in the shebang line. The native LDD was unhappy = =20 > with the Chrome binary. = =20 >=20 > I've now pulled out a list of libraries from a Linux machine where I could= =20 > run ldd, and I can collect the libraries by hand from Linux to populate = =20 > /compat, but I'm really interested in knowing if anyone's gotten Chrome = =20 > working this way, or if I'll run into known obstacles once I have all the = =20 > libraries in place. = =20 >=20 > Thanks! = =20 >=20 > --=20 > Mason Loring Bliss mason@blisses.org http://blisses.= org/ =20 > The sand bats of Manark IV look like inanimate rock crystals until they at= tack. --- Mark Saad | nonesuch@longcount.org=