From owner-freebsd-arm@freebsd.org Sun Jun 19 00:36:55 2016 Return-Path: Delivered-To: freebsd-arm@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 C8255A782D3 for ; Sun, 19 Jun 2016 00:36:55 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7D83F2204 for ; Sun, 19 Jun 2016 00:36:55 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id u5J0aqHW042478 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 18 Jun 2016 17:36:53 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id u5J0aqXM042477; Sat, 18 Jun 2016 17:36:52 -0700 (PDT) (envelope-from fbsd) Date: Sat, 18 Jun 2016 17:36:51 -0700 From: bob prohaska To: Hal Murray Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: pl2303 lockups on rpi2 Message-ID: <20160619003651.GB38492@www.zefox.net> References: <20160618025517.GA38492@www.zefox.net> <20160618043430.28E93406057@ip-64-139-1-69.sjc.megapath.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160618043430.28E93406057@ip-64-139-1-69.sjc.megapath.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 00:36:55 -0000 On Fri, Jun 17, 2016 at 09:34:30PM -0700, Hal Murray wrote: > > How solid is your power? > The three RPI2s that I can check easily are all over 5 Volts. The fourth is hard to get at, but it shares the same power supply type and is unlikely to be significantly different. Swapping places between the two adapters that locked up with the two that kept working didn't turn out as planned. The two adapters that were failing still failed, but one that hadn't failed up to then did, in about 48 hours. The one encouragement is that updating to r301978 and rebooting unstuck an adapter that had locked up under r301569. Up to now it's been necessary to expose the adapters to Prolific's driver to unstick them. Unplugging and replugging didn't help. There seem to be nine supported USB-serial adapter types, can you suggest a better bet if I have to go shopping again? I can't find kind words about any of them. Thanks for reading! bob prohaska > I've seen USB screwups on a Pi 3 running Linux talking to a GPS unit with a > PL2303. The symptom was that every day or two, it just stopped working. > Unplugging and replugging fixed it. I didn't find a way to fix it from the > command line. > > Somebody suggested that a Pi-? needs more than 4.8 V. My setup was running > at 4.8 V. Power seemed like a likely problem, but I didn't track down the > source. It could be a handy urban legend. > > You can get USB cables with heavier gauge power wires. I got some Tronsmart > brand. They gave me a bit more than an extra 0.1 V, but I don't have enough > hours on them to know if it solved the problem. > > > -- > These are my opinions. I hate spam. > > > From owner-freebsd-arm@freebsd.org Sun Jun 19 01:23:27 2016 Return-Path: Delivered-To: freebsd-arm@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 35E1CA78BD3 for ; Sun, 19 Jun 2016 01:23:27 +0000 (UTC) (envelope-from hmurray@megapathdsl.net) Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by mx1.freebsd.org (Postfix) with ESMTP id 216691334 for ; Sun, 19 Jun 2016 01:23:26 +0000 (UTC) (envelope-from hmurray@megapathdsl.net) Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 83751406057; Sat, 18 Jun 2016 18:23:23 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: bob prohaska cc: Hal Murray , freebsd-arm@freebsd.org From: Hal Murray Subject: Re: pl2303 lockups on rpi2 In-Reply-To: Message from bob prohaska of "Sat, 18 Jun 2016 17:36:51 PDT." <20160619003651.GB38492@www.zefox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 18 Jun 2016 18:23:23 -0700 Message-Id: <20160619012323.83751406057@ip-64-139-1-69.sjc.megapath.net> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 01:23:27 -0000 fbsd@www.zefox.net said: > There seem to be nine supported USB-serial adapter types, can you suggest a > better bet if I have to go shopping again? I can't find kind words about any > of them. FTDI is the other major vendor in that area. (at least in my collection) -- These are my opinions. I hate spam. From owner-freebsd-arm@freebsd.org Sun Jun 19 01:24:46 2016 Return-Path: Delivered-To: freebsd-arm@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 07438A78C26 for ; Sun, 19 Jun 2016 01:24:46 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-153.reflexion.net [208.70.211.153]) (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 972F713A1 for ; Sun, 19 Jun 2016 01:24:45 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 4326 invoked from network); 19 Jun 2016 01:25:14 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 19 Jun 2016 01:25:14 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Sat, 18 Jun 2016 21:24:43 -0400 (EDT) Received: (qmail 16319 invoked from network); 19 Jun 2016 01:24:43 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 19 Jun 2016 01:24:43 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 5CA2FB1E001; Sat, 18 Jun 2016 18:24:32 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: FreeBSD on the ODroid-C2 (arm64 AMLogic S905) [tc2 vs. c2 branches] Message-Id: <03E8901C-5EDB-44FC-81F3-8041DF2D7760@dsl-only.net> Date: Sat, 18 Jun 2016 18:24:36 -0700 To: Andreas Tobler , tvijlbrief@gmail.com, freebsd-arm Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 01:24:46 -0000 Mixing things that Tom Vijlbrief and Andreas Tobler wrote at various = times: Tom wrote: > This is very much a work in progress, but for those who would like to > compile their own kernel and boot it on an Odroid-C2, get it from: >=20 > https://github.com/tomtor/freebsd/tree/tc2 Andreas wrote: > Ok, I'm not very familiar with git & co. So far I do not see a=20 > change/update on the 'web frontend' of your repo.=20 > (https://github.com/tomtor/freebsd/tree/c2) There appear to be 2 distinct branches under = https://github.com/tomtor/freebsd/tree/ for the ODROID-C2, one newer = (tc2) and one older (c2) as far as content goes: https://github.com/tomtor/freebsd/tree/tc2 is newer (about 19hours ago for its last update as I look at it now) vs. https://github.com/tomtor/freebsd/tree/c2 is older (not updated since 2016-Apr-27) (I've not used either, although I hope to someday use FreeBSD on the = Ordroid-C2.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Jun 19 02:03:16 2016 Return-Path: Delivered-To: freebsd-arm@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 2B676A7A262 for ; Sun, 19 Jun 2016 02:03:16 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DC6E0217A for ; Sun, 19 Jun 2016 02:03:15 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id u5J23C7N042673 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 18 Jun 2016 19:03:14 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id u5J23CGO042672; Sat, 18 Jun 2016 19:03:12 -0700 (PDT) (envelope-from fbsd) Date: Sat, 18 Jun 2016 19:03:12 -0700 From: bob prohaska To: Hal Murray Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: pl2303 lockups on rpi2 Message-ID: <20160619020311.GC38492@www.zefox.net> References: <20160619003651.GB38492@www.zefox.net> <20160619012323.83751406057@ip-64-139-1-69.sjc.megapath.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160619012323.83751406057@ip-64-139-1-69.sjc.megapath.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 02:03:16 -0000 On Sat, Jun 18, 2016 at 06:23:23PM -0700, Hal Murray wrote: > > > FTDI is the other major vendor in that area. (at least in my collection) > Yes, FTDI seems to be the most common alternative. Do you think it an improvement? The man page for uplcom does not list pl2303ta, stopping at pl2303hx. The hx version is now EOL, superseded by the ta version. Prolific's migration guide at http://prolificusa.com/docs/2303/all/PL2303TA-Migration-Guide.pdf advises: "Note: Older driver versions are not compatible with PL2303TA chip for above 115200bps baud rates." I wonder if slowing the RPi2 consoles down would make the problems go away, at least until the driver is updated. It seems unlikely, given that the lockup is on the USB side. Thanks for reading! bob prohaska > > -- > These are my opinions. I hate spam. > > > From owner-freebsd-arm@freebsd.org Sun Jun 19 03:42:52 2016 Return-Path: Delivered-To: freebsd-arm@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 4CE9AA7A477 for ; Sun, 19 Jun 2016 03:42:52 +0000 (UTC) (envelope-from hmurray@megapathdsl.net) Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by mx1.freebsd.org (Postfix) with ESMTP id 307F72F3C for ; Sun, 19 Jun 2016 03:42:51 +0000 (UTC) (envelope-from hmurray@megapathdsl.net) Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 1D097406057; Sat, 18 Jun 2016 20:42:48 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: bob prohaska cc: Hal Murray , freebsd-arm@freebsd.org From: Hal Murray Subject: Re: pl2303 lockups on rpi2 In-Reply-To: Message from bob prohaska of "Sat, 18 Jun 2016 19:03:12 PDT." <20160619020311.GC38492@www.zefox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 18 Jun 2016 20:42:48 -0700 Message-Id: <20160619034248.1D097406057@ip-64-139-1-69.sjc.megapath.net> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 03:42:52 -0000 fbsd@www.zefox.net said: > Yes, FTDI seems to be the most common alternative. Do you think it an > improvement? >From the OS side, I expect they are mostly the same. There is a USB spec for serial interface chips. They don't cost much. If you are going to play with USB on bleeding edge OS software, you should have one or several just for times like this. > The man page for uplcom does not list pl2303ta, stopping at pl2303hx. The hx > version is now EOL, superseded by the ta version. I'd expect the chip designers were careful to make sure that old drivers and new chips would work together as long as you didn't expect support for any new features. You could try plugging your USB gear into a PC running FreeBSD. fbsd@www.zefox.net said: > I wonder if slowing the RPi2 consoles down would make the problems go away, > at least until the driver is updated. It seems unlikely, given that the > lockup is on the USB side. The Linux geeks have figured out how to use the "console" as a serial port. It's used by the GPS HATs. If you are trying to get work done rather than debug USB stuff, that might be an interesting approach. You would need a level shifter if you are talking to a real RS232 device. Google for >RS232 HAT< gets several hits. I didn't look more than that. Some support multiple serial ports. Using the extras probably requires getting the OS to configure the IO pins and setup the appropriate new IO devices. The first one (aka console) probably works without much work. All you get is RX and TX. The modem control signals will require extra work. -- These are my opinions. I hate spam. From owner-freebsd-arm@freebsd.org Sun Jun 19 04:11:23 2016 Return-Path: Delivered-To: freebsd-arm@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 CD06AA7A9EF for ; Sun, 19 Jun 2016 04:11:23 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 8FE8B1E05 for ; Sun, 19 Jun 2016 04:11:23 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-oi0-x234.google.com with SMTP id d132so168816887oig.1 for ; Sat, 18 Jun 2016 21:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QHTNodRfZcCvJD0wabBaMbsFj8qNBkLmfD5R6J3BNp4=; b=PgOqgX+iwL01VhfM8HaynGH9tpDI8zayqxlitBZdgQRijFRO12WJRJNLKpmeY7rFgp NKYklc57iSadzUXwRTgTNopwg/aKflwuHQcIsdPKJ8psq/vP9mtSQ3aIH9+yGa/0cfpj ZNhxdgKPCZlAt42+aJR2LM0IpkbrILslAv0nF09xywaECI1f04+kK//DEMWvBVmPhOM9 qghesx7vRYam8XBWqutBzHhYRZF3QOjTbCkjHTQI6SE5EU4ffIg2kBGfdOeLlhsHxBkC Jd7EWIux3PTfKdMFHvWLv3OMAojXIuTBWPlvYSpHzz4r5yXzG1tlh6QSyP6XfXmnL1JV 6NlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QHTNodRfZcCvJD0wabBaMbsFj8qNBkLmfD5R6J3BNp4=; b=hlYKVqTq36rRVViYdHXbAMhf2AtzQWxEXkVKJ9vCQ+zk8pXLHR97WOynwTyuEUd5tk r8LAJqnj4VZ1b2CBaoXyc1YbGTG/QBDkg5XLmERZfrFmu63tru1UMuZdo6Ll0Mve0O6L beMNxZ/J77kO3C4i4tjRvVew/nKqNaH4aV6kSPbcmebZfdA4jCVf+sm1Qr8Q3iSAkG2t 6DnNwULnCu9WiZ2UPppPtJ/n4TDpI5JyTp+rVrmko1WUmfqoJp/n8IHjgk84Zbxqi7sr 018j5WPtbigiuFgYzIhGbai7z898726uEMSvV2GBCvHduWpsjRJeA78E1uOmqL30+tPO eAKA== X-Gm-Message-State: ALyK8tLH0fHQvmcVZ0KrNaRO3ISSwRn/YcWs0V1OtZzWtjDu20ct60gMqo1TFcgKNIbp3bHzcCztzdqO2tNXGtWC X-Received: by 10.157.29.236 with SMTP id w41mr5304536otw.44.1466309482250; Sat, 18 Jun 2016 21:11:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.41.209 with HTTP; Sat, 18 Jun 2016 21:11:21 -0700 (PDT) In-Reply-To: References: <83A18C0E-FA89-4009-A8D5-3185FB27A688@netgate.com> From: Maxim Sobolev Date: Sat, 18 Jun 2016 21:11:21 -0700 Message-ID: Subject: Re: BBB (cpsw(4)) seems to be broken in the latest 11-current To: Jim Thompson , Luiz Otavio O Souza Cc: Svatopluk Kraus , "freebsd-arm@freebsd.org" , FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 04:11:23 -0000 Jim, some update from here. Running r283287 of the driver, I still see the same "watchdog timeout" messages, but they do not lead to the interface lockout. The traffic resumes momentarily. Which is probably why I never paid much attention to those warnings before. Therefore, I suspect that the new MAC code does not deal with watchdog-triggered interface reset as good as the old code. Does it give you any ideas about what could be wrong there by any chance? 03:54:50 CPSW watchdog cpsw0: watchdog timeout cpsw0: Unable to cleanly shutdown transmitter 03:58:03 CPSW watchdog cpsw0: watchdog timeout cpsw0: Unable to cleanly shutdown transmitter On Sat, Jun 18, 2016 at 2:09 PM, Maxim Sobolev wrote: > Jim, > > Yes, I've seen those. There were just handful of revision into the driver > between my old good kernel and now, most of them are from you guys: > > r299477 | gonzo | 2016-05-11 11:20:02 -0700 (=D1=81=D1=80, 11 =D0=BC=D0= =B0=D0=B9 2016) | 16 lines > r298352 | pfg | 2016-04-20 08:45:55 -0700 (=D1=81=D1=80, 20 =D0=B0=D0=BF= =D1=80 2016) | 6 lines > r297132 | loos | 2016-03-20 20:16:56 -0700 (=D0=B2=D1=81, 20 =D0=BC=D0=B0= =D1=80 2016) | 5 lines > r297043 | loos | 2016-03-18 13:24:31 -0700 (=D0=BF=D1=82, 18 =D0=BC=D0=B0= =D1=80 2016) | 4 lines > r297042 | loos | 2016-03-18 13:09:54 -0700 (=D0=BF=D1=82, 18 =D0=BC=D0=B0= =D1=80 2016) | 4 lines > r297041 | loos | 2016-03-18 13:04:34 -0700 (=D0=BF=D1=82, 18 =D0=BC=D0=B0= =D1=80 2016) | 4 lines > r296993 | loos | 2016-03-17 12:35:08 -0700 (=D1=87=D1=82, 17 =D0=BC=D0=B0= =D1=80 2016) | 24 lines > r296980 | loos | 2016-03-16 23:23:48 -0700 (=D1=81=D1=80, 16 =D0=BC=D0=B0= =D1=80 2016) | 6 lines > r283287 | andrew | 2015-05-22 07:25:23 -0700 (=D0=BF=D1=82, 22 =D0=BC=D0= =B0=D0=B9 2015) | 4 lines > (last known good one) > > I've reverted the driver to the state all way down to r283287, while > keeping the rest of the kernel intact and soon will see if it works bette= r. > If that works fine, I'll try to bi-sect it to a single troublesome revisi= on. > > -Max > > On Sat, Jun 18, 2016 at 12:26 PM, Jim Thompson wrote: > >> There are recent changes to enable the switch and two port MAC mode. >> >> These were lightly tested on BBB prior to being committed. >> >> -- Jim >> >> > On Jun 18, 2016, at 11:49 AM, Maxim Sobolev >> wrote: >> > >> > Well, I am not sure either as I don't have any issue restarting it >> > afterwards. >> > >> > Yes, it seems to be happening fairly reliably here. :( Happened for me >> > again, I left it running overnight. I am 99% positive it was not the >> case >> > before kernel upgrade.. >> > >> > 07:11:52 CPSW watchdog cpswss0: watchdog timeout >> > cpswss0: Unable to cleanly shutdown transmitter >> > >> > >> >> On Sat, Jun 18, 2016 at 1:09 AM, Svatopluk Kraus >> wrote: >> >> >> >> On Sat, Jun 18, 2016 at 8:50 AM, Maxim Sobolev >> >> wrote: >> >>> Updated my BBB to the latest -current, immediately got this while >> trying >> >> to >> >>> make world over ssh console: >> >>> >> >>> 06:02:17 CPSW watchdog cpswss0: watchdog timeout >> >>> cpswss0: Unable to cleanly shutdown transmitter >> >> >> >> My BBB stucks in cpsw0 during boot rarely, and even soft reset (reset >> >> button) does not help. Only hard reset (power-off) helps. I have neve= r >> >> had time to discover where a problem is. I'm not even sure if this is >> >> related to your problem as I did not remember exact dmesg in my case. >> >> >> >> Svata >> >> >> >> >> >>> >> >>> Interface seems to be locked after that, no traffic comes in or out. >> >>> >> >>> This is: >> >>> >> >>> FreeBSD 11.0-ALPHA3 #1 ba7edef(tps65217x)-dirty: Fri Jun 17 16:22:07 >> PDT >> >>> 2016, svn revision 301898 >> >>> >> >>> The previous version that was rock-solid was: >> >>> >> >>> FreeBSD 11.0-CURRENT #0 9d390ee(tps65217x)-dirty: Mon Jul 6 19:31:3= 0 >> PDT >> >>> 2015, svn revision 284878 >> >>> >> >>> I've been running buildworlds for literally days on that board, >> because >> >>> it's how long it takes to build on that hardware. :) >> >>> >> >>> I'll run it again and see if the issue re-appears. >> >>> >> >>> If anyone seen this or if it's known issue please let me know. >> >>> >> >>> Thanks! >> >>> >> >>> -Max >> >>> _______________________________________________ >> >>> freebsd-arm@freebsd.org mailing list >> >>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> >>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.or= g >> " >> > _______________________________________________ >> > freebsd-arm@freebsd.org mailing list >> > https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >> >> > --=20 Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts Tel (Canada): +1-778-783-0474 Tel (Toll-Free): +1-855-747-7779 Fax: +1-866-857-6942 Web: http://www.sippysoft.com MSN: sales@sippysoft.com Skype: SippySoft From owner-freebsd-arm@freebsd.org Sun Jun 19 05:52:35 2016 Return-Path: Delivered-To: freebsd-arm@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 43AA8A78DF8 for ; Sun, 19 Jun 2016 05:52:35 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 B59072698 for ; Sun, 19 Jun 2016 05:52:34 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: by mail-lf0-x22d.google.com with SMTP id q132so19882392lfe.3 for ; Sat, 18 Jun 2016 22:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=+14hBUxuM4y9U/FXvMCh09w2RLXg9+JQhAyaktkIGxo=; b=xlNFqaO1Y1LZep1CPJV+NCb/q0ilE5poLfDhaVtLK2kGkcLTjsJ1b/xVK7BWEW/ReU ej2f+Ug1NuKl1fAtDVMNOzOHm+IUCWq417PGgd3UM2GF7Ikx+IipB7PAgdNyy2L5k9ew yVd7iJhz1thDuNxFsx3bYmbeKU5VrDTJMfHZgqssZaGceathOmwczm2/5HON3Ki3W6QZ sme0wuyRUqCQNo3VZjatIppr5XjXenSgEtLjDfRzqeQiWPFSAHZ0kq0EFMOy2U8sKGtz 8ZCv/T8CvG8+fJ9QvlSN7QLXfPBzRVH1usDbZNsm5I4RgjjYQexmGzfScD8yI80kSI2L j1Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=+14hBUxuM4y9U/FXvMCh09w2RLXg9+JQhAyaktkIGxo=; b=KsXBzry+nK0dKM3i6QcZSEQziEWMG9szKJk5d8KXrJqC8h0LJdKw50DXamtVywOEgT h7Rfo0exBxiuT1s9BqXfu67vmFBiwBpWS9ySh06r85vZFkMmmbeKvWnqUPnnGYiFSIbZ FnPQXG3veKHlLQiSv+6TgaIpe03xnELJv74mbshkkImEU3NZaa/qNv/Qikj4EmdmPKt6 JfG4BnN0VXyKcQgFR0RbUJ+kY5i3JRS2OpsFfpPE60DQsRLWHupNwTSQo9bKm/m+Omct VOMlilP6xDfzkUvk+rUH8FeZC737NCR2/RkW+ZUWJ1cO04abQ7ucpDIWxjftyZBeFKnz rcpQ== X-Gm-Message-State: ALyK8tLdsZLIT6tZwR+5DVGvv5gqNCPY7yRztvCFGEjLuf14YD9iGCcPafZDmOa1BmraGK/WXxWvHsKUfPPbsw== X-Received: by 10.46.0.16 with SMTP id 16mr2521829lja.56.1466315552442; Sat, 18 Jun 2016 22:52:32 -0700 (PDT) MIME-Version: 1.0 References: <03E8901C-5EDB-44FC-81F3-8041DF2D7760@dsl-only.net> In-Reply-To: <03E8901C-5EDB-44FC-81F3-8041DF2D7760@dsl-only.net> From: Tom Vijlbrief Date: Sun, 19 Jun 2016 05:52:22 +0000 Message-ID: Subject: Re: FreeBSD on the ODroid-C2 (arm64 AMLogic S905) [tc2 vs. c2 branches] To: Mark Millard , Andreas Tobler , freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 05:52:35 -0000 I will remove the old c2 branch to avoid confusion... Op 03:24 ZO 19 Jun 2016 schreef Mark Millard : > Mixing things that Tom Vijlbrief and Andreas Tobler wrote at various times: > > Tom wrote: > > > This is very much a work in progress, but for those who would like to > > compile their own kernel and boot it on an Odroid-C2, get it from: > > > > https://github.com/tomtor/freebsd/tree/tc2 > > > Andreas wrote: > > > Ok, I'm not very familiar with git & co. So far I do not see a > > change/update on the 'web frontend' of your repo. > > (https://github.com/tomtor/freebsd/tree/c2) > > > > There appear to be 2 distinct branches under > https://github.com/tomtor/freebsd/tree/ for the ODROID-C2, one newer > (tc2) and one older (c2) as far as content goes: > > https://github.com/tomtor/freebsd/tree/tc2 is newer > (about 19hours ago for its last update as I look at it now) > > vs. > > https://github.com/tomtor/freebsd/tree/c2 is older > (not updated since 2016-Apr-27) > > (I've not used either, although I hope to someday use FreeBSD on the > Ordroid-C2.) > > === > Mark Millard > markmi at dsl-only.net > > From owner-freebsd-arm@freebsd.org Sun Jun 19 15:33:23 2016 Return-Path: Delivered-To: freebsd-arm@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 6911BA795F9 for ; Sun, 19 Jun 2016 15:33:23 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (unknown [IPv6:2001:4060:1:1001::14:52]) (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 311962610 for ; Sun, 19 Jun 2016 15:33:23 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from [192.168.225.14] (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by fgznet.ch (Postfix) with ESMTPS id 75D90C49F9; Sun, 19 Jun 2016 17:33:11 +0200 (CEST) Subject: Re: FreeBSD on the ODroid-C2 (arm64 AMLogic S905) [tc2 vs. c2 branches] To: Tom Vijlbrief , Mark Millard , freebsd-arm References: <03E8901C-5EDB-44FC-81F3-8041DF2D7760@dsl-only.net> From: Andreas Tobler Message-ID: <1f1f8467-2090-8e2e-5ffa-a4f473d9f119@fgznet.ch> Date: Sun, 19 Jun 2016 17:33:11 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 127.0.1.1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 15:33:23 -0000 On 19.06.16 07:52, Tom Vijlbrief wrote: > I will remove the old c2 branch to avoid confusion... Ugh, excellent! Now things look much better. Thanks a lot!!! Btw, what is the issue with if_dwc? Not complete yet? Andreas > > > Op 03:24 ZO 19 Jun 2016 schreef Mark Millard >: > > Mixing things that Tom Vijlbrief and Andreas Tobler wrote at various > times: > > Tom wrote: > > > This is very much a work in progress, but for those who would like to > > compile their own kernel and boot it on an Odroid-C2, get it from: > > > > https://github.com/tomtor/freebsd/tree/tc2 > > > Andreas wrote: > > > Ok, I'm not very familiar with git & co. So far I do not see a > > change/update on the 'web frontend' of your repo. > > (https://github.com/tomtor/freebsd/tree/c2) > > > > There appear to be 2 distinct branches under > https://github.com/tomtor/freebsd/tree/ for the ODROID-C2, one newer > (tc2) and one older (c2) as far as content goes: > > https://github.com/tomtor/freebsd/tree/tc2 is newer > (about 19hours ago for its last update as I look at it now) > > vs. > > https://github.com/tomtor/freebsd/tree/c2 is older > (not updated since 2016-Apr-27) > > (I've not used either, although I hope to someday use FreeBSD on the > Ordroid-C2.) > > === > Mark Millard > markmi at dsl-only.net > From owner-freebsd-arm@freebsd.org Sun Jun 19 16:23:50 2016 Return-Path: Delivered-To: freebsd-arm@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 08187A7A610 for ; Sun, 19 Jun 2016 16:23:50 +0000 (UTC) (envelope-from freebsd-lists-5@thismonkey.com) Received: from mail-01.thismonkey.com (mail-01.thismonkey.com [220.244.217.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mail-01.thismonkey.com", Issuer "Thismonkey IT Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 41E0026A7 for ; Sun, 19 Jun 2016 16:23:48 +0000 (UTC) (envelope-from freebsd-lists-5@thismonkey.com) X-TM-Via-MX: mail-01.thismonkey.com DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=thismonkey.com; s=mail-01; t=1466352418; bh=b7lfYHzhDlM7fk48kMpq2v3R7Dda5MIym8wipRkc+to=; h=Date:From:To:Subject:References:In-Reply-To; b=mDKJhkrs1afH0NGxrVaeCObiLcFOzRtuQ0YEi0hfp52ye0M33H297Hx5K8smxQYEf uTTM8A/d9YDC+k22XUGp9rZJ1zitT0xpmquq8Rgka6rBR3CP4mKqOLUFSnPTw3HkZG FDHSEI0S6PAkc+0bHkYYGL9e+ppvFLrxfEaszbEE= DMARC-Filter: OpenDMARC Filter v1.3.0 mail-01.thismonkey.com u5JG6wle075887 Authentication-Results: mail-01/u5JG6wle075887; dmarc=none header.from=thismonkey.com Authentication-Results: mail-01; spf=pass smtp.mailfrom=freebsd-lists-5@thismonkey.com Received: from utility-01.thismonkey.com (utility-01.thismonkey.com [10.1.1.32]) by mail-01.thismonkey.com (8.14.9/8.14.9) with ESMTP id u5JG6wle075887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 20 Jun 2016 02:06:58 +1000 (EST) (envelope-from freebsd-lists-5@thismonkey.com) Received: from utility-01.thismonkey.com (localhost [127.0.0.1]) by utility-01.thismonkey.com (8.14.9/8.14.9) with ESMTP id u5JG6wP7062130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 20 Jun 2016 02:06:58 +1000 (EST) (envelope-from freebsd-lists-5@thismonkey.com) Received: (from root@localhost) by utility-01.thismonkey.com (8.14.9/8.14.9/Submit) id u5JG6vjK062129 for freebsd-arm@freebsd.org; Mon, 20 Jun 2016 02:06:57 +1000 (EST) (envelope-from freebsd-lists-5@thismonkey.com) Date: Mon, 20 Jun 2016 02:06:57 +1000 From: Scott To: freebsd-arm@freebsd.org Subject: Sleep/power off the HDMI output on an RPi Message-ID: <20160619160656.GA61604@thismonkey.com> Mail-Followup-To: freebsd-arm@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: inspected by milter-greylist-4.5.11 (mail-01.thismonkey.com [10.1.2.50]); Mon, 20 Jun 2016 02:06:58 +1000 (EST) for IP:'10.1.1.32' DOMAIN:'utility-01.thismonkey.com' HELO:'utility-01.thismonkey.com' FROM:'freebsd-lists-5@thismonkey.com' RCPT:'' X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.11 (mail-01.thismonkey.com [10.1.2.50]); Mon, 20 Jun 2016 02:06:58 +1000 (EST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 16:23:50 -0000 Hi, can anyone confirm if the blank screensaver on an RPi sleeps/powers off the HDMI? My RPi keeps my new monitor on and switched to the HDMI input because of the RPi. For bonus points: is it easy to compile just the blank_saver.ko? My 11-CURRENT install didn't include screen savers. Many thanks, Scott From owner-freebsd-arm@freebsd.org Sun Jun 19 21:40:29 2016 Return-Path: Delivered-To: freebsd-arm@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 A3D2CA77D0A for ; Sun, 19 Jun 2016 21:40:29 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::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 58F7421BD for ; Sun, 19 Jun 2016 21:40:29 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qk0-x233.google.com with SMTP id p10so140921889qke.3 for ; Sun, 19 Jun 2016 14:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=aATkkCnlF3HzZQzV4NKz1jPHi4+92Y1nBj5RxtRGnfU=; b=cEjO+lTExyYWzD4QZz6+5RXp4Ace5wnKNASnaNKG0YbHVTX26zZGJDcesaP5ZhyON+ W1IVwdHDhOjT708PvZ1inNdaZsSSIgaxJXJs+BS782nSnmaCgHbRAcYSPUUR7P5/qbO8 pqtmFd6C8sF5p4YcE1k0ban459iSMs4b1hXsM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=aATkkCnlF3HzZQzV4NKz1jPHi4+92Y1nBj5RxtRGnfU=; b=BDKonTY5qyUem9pcfT0dE80zdqecn5TG1XSnLbXPfr/WYe/GZZivqTytrUPIU6FpPx V3HR4w+AbVQ0vVABi+UVADIE3tTDwb9C994C17GLGfoguBw7SaT9duDKFwHGb8zwIr/U +HJfiMREgW1YaAjytGRjXq+hgcCNIeTcpKaRC8zTyFqm646hJ0UL3zeHtAMMlqAF4EVr 7tk1i/jIriNFv0neCUo3AR9gtnxVd8qMkF861SIsXe/tAmgP0Z7Hm7bsfpLVegKTVfYG jTMYYWOcQCXDQyJr/JepDuiIHNs9L3HKsfuGRznf+ov8Cy5qlvVvJw/dRtQyMfG+a91V W73g== X-Gm-Message-State: ALyK8tJ9y71NYa5pphnmbLOM62JxZoq5tCT2Xj8sV2SrGTS/ZMQM614KJo3jx64kHSs3vA== X-Received: by 10.237.53.51 with SMTP id a48mr16913518qte.54.1466372428119; Sun, 19 Jun 2016 14:40:28 -0700 (PDT) Received: from [192.168.0.18] ([187.60.94.34]) by smtp.googlemail.com with ESMTPSA id s13sm14705288qke.6.2016.06.19.14.40.26 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 19 Jun 2016 14:40:27 -0700 (PDT) To: "freebsd-arm@freebsd.org" , freebsd-hackers@freebsd.org From: =?UTF-8?B?T3RhY8OtbGlv?= Subject: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held Message-ID: Date: Sun, 19 Jun 2016 18:40:07 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 21:40:29 -0000 I was installing netperf on a fresh FreeBSD-ALPHA3 FreeBSD beaglebone 11.0-ALPHA3 FreeBSD 11.0-ALPHA3 #0 r301846: Mon Jun 13 19:54:27 BRT 2016 ota@nostromo:/root/crochet/work/obj/arm.armv6/usr/src/sys/BEAGLEBONE-DEBUG arm on BeagleboneBlack using wrtwn when I got this kernel panic: root@beaglebone:/usr/home/ota # pkg install netperf Updating FreeBSD repository catalogue... Fetching meta.txz: 100% 944 B 0.9kB/s 00:01 Fetching packagesite.txz: 100% 4 MiB 46.0kB/s 01:42 Processing entries: 6%lock order reversal: 1st 0xc30b35d4 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2048 2nd 0xc319d6f4 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2498 stack backtrace: Processing entries: 58%Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex tcp_sc_head (tcp_sc_head) r = 0 (0xc2f9d520) locked @ /usr/src/sys/netinet/tcp_syncache.c:494 shared rw tcp (tcp) r = 0 (0xc08ef348) locked @ /usr/src/sys/netinet/tcp_input.c:1034 exclusive rw tcpinp (tcpinp) r = 0 (0xc31ab494) locked @ /usr/src/sys/netinet/in_pcb.c:1964 stack backtrace: Fatal kernel mode data abort: 'Alignment Fault' on read trapframe: 0xdcfe58a8 FSR=00000001, FAR=c2e7187a, spsr=60000013 r0 =c08e7988, r1 =00000004, r2 =c06fa3ad, r3 =000007b6 r4 =dcfe5a10, r5 =dcfe5b28, r6 =c2e71876, r7 =c2f9d520 r8 =c2f9d520, r9 =c2e71876, r10=dcfe5b28, r11=dcfe5970 r12=00000000, ssp=dcfe5938, slr=c2d34370, pc =c053d8e8 [ thread pid 13 tid 100036 ] Stopped at syncookie_lookup+0x38: ldmib r6, {r1-r2} db> []'s -Otacílio From owner-freebsd-arm@freebsd.org Sun Jun 19 21:47:40 2016 Return-Path: Delivered-To: freebsd-arm@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 8B955A7A014 for ; Sun, 19 Jun 2016 21:47:40 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 463ED2749 for ; Sun, 19 Jun 2016 21:47:40 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qk0-x22e.google.com with SMTP id a186so140967434qkf.0 for ; Sun, 19 Jun 2016 14:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=qjmXniEmGtMqz9SS8xuhGquvc4OV6DZqFDyy1720PXU=; b=RnpUYLJIFH64lU4wGldNg8k+rViray17bRDJLJIxKidUrCKVk5Yg9V8bbOwR+os51n M0k8j5IBsa/2LTMHOND0uHbMVy0+SM/qRzvMoEzv165LUi/YjvyleHnSb8pkiOnlO5NE 0+G7G0zOtrEZDdKJTHibW69AMHCKGgWGionuI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=qjmXniEmGtMqz9SS8xuhGquvc4OV6DZqFDyy1720PXU=; b=dVIKoaXNL7gFnzgeutvnZVeCRgF54jSGHQDwsjCRACW9lHfEGcA/Xnhmik14lUA2np wXGJrqnnnAi3OFKDDR9xacYFKAvFlKKm09zyfqUSAkahdAC3BScys3Eg/Gqtr0q0rGTS kt/pRhtnJBaAj+GeL/UJqWcXYH6O6o7HWghRiJ2CsKSgHZe3PkPlP1Y9XkVxxKZFnA9h jMpcTXwtwbRfPDAEC6RgAIHFCr8sDQcc8lo4cBU5vaa7nBE4ESc7OaKQMlPE0Z1bXCuV scM29mLsU26k3xQV+ANihudf7etn0tiqKBEHhHBUmC6R4AlJoIPqgXjuuNVgyg+cZuRE RcbQ== X-Gm-Message-State: ALyK8tLkvZqTy8LCXwrWJCRaJQ/d/x4iKAmIPHlMPTGQ9HCaa5+1Ogwx18KrlwRzQSMMwQ== X-Received: by 10.55.209.83 with SMTP id s80mr17258725qki.87.1466372859352; Sun, 19 Jun 2016 14:47:39 -0700 (PDT) Received: from [192.168.0.18] ([187.60.94.34]) by smtp.googlemail.com with ESMTPSA id f13sm14609915qtc.2.2016.06.19.14.47.37 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 19 Jun 2016 14:47:38 -0700 (PDT) Subject: Re: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held To: "freebsd-arm@freebsd.org" , freebsd-hackers@freebsd.org References: From: =?UTF-8?B?T3RhY8OtbGlv?= Message-ID: <5e322d5a-8c42-8e69-f3c4-e607d40e8724@bsd.com.br> Date: Sun, 19 Jun 2016 18:47:19 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 21:47:40 -0000 Em 19/06/2016 18:40, Otacílio escreveu: > I was installing netperf on a fresh FreeBSD-ALPHA3 > > FreeBSD beaglebone 11.0-ALPHA3 FreeBSD 11.0-ALPHA3 #0 r301846: Mon Jun > 13 19:54:27 BRT 2016 > ota@nostromo:/root/crochet/work/obj/arm.armv6/usr/src/sys/BEAGLEBONE-DEBUG > arm > > on BeagleboneBlack using wrtwn when I got this kernel panic: > > root@beaglebone:/usr/home/ota # pkg install netperf > Updating FreeBSD repository catalogue... > Fetching meta.txz: 100% 944 B 0.9kB/s 00:01 > Fetching packagesite.txz: 100% 4 MiB 46.0kB/s 01:42 > Processing entries: 6%lock order reversal: > 1st 0xc30b35d4 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2048 > 2nd 0xc319d6f4 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2498 > stack backtrace: > Processing entries: 58%Kernel page fault with the following > non-sleepable locks held: > exclusive sleep mutex tcp_sc_head (tcp_sc_head) r = 0 (0xc2f9d520) > locked @ /usr/src/sys/netinet/tcp_syncache.c:494 > shared rw tcp (tcp) r = 0 (0xc08ef348) locked @ > /usr/src/sys/netinet/tcp_input.c:1034 > exclusive rw tcpinp (tcpinp) r = 0 (0xc31ab494) locked @ > /usr/src/sys/netinet/in_pcb.c:1964 > stack backtrace: > Fatal kernel mode data abort: 'Alignment Fault' on read > trapframe: 0xdcfe58a8 > FSR=00000001, FAR=c2e7187a, spsr=60000013 > r0 =c08e7988, r1 =00000004, r2 =c06fa3ad, r3 =000007b6 > r4 =dcfe5a10, r5 =dcfe5b28, r6 =c2e71876, r7 =c2f9d520 > r8 =c2f9d520, r9 =c2e71876, r10=dcfe5b28, r11=dcfe5970 > r12=00000000, ssp=dcfe5938, slr=c2d34370, pc =c053d8e8 > > [ thread pid 13 tid 100036 ] > Stopped at syncookie_lookup+0x38: ldmib r6, {r1-r2} > db> > > > []'s > > -Otacílio > The kernel panic is totally reproducible. I need only do a ssh in the beaglebone using ptty on windows or ssh on freebsd and the kernel panic is raised. FreeBSD/arm (beaglebone) (ttyu0) login: Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex tcp_sc_head (tcp_sc_head) r = 0 (0xc2f95480) locked @ /usr/src/sys/netinet/tcp_syncache.c:494 shared rw tcp (tcp) r = 0 (0xc08ef348) locked @ /usr/src/sys/netinet/tcp_input.c:1034 exclusive rw tcpinp (tcpinp) r = 0 (0xc341e494) locked @ /usr/src/sys/netinet/in_pcb.c:1964 stack backtrace: Fatal kernel mode data abort: 'Alignment Fault' on read trapframe: 0xdcfe58a8 FSR=00000001, FAR=c2e7807a, spsr=60000013 r0 =c08e7988, r1 =00000004, r2 =c06fa3ad, r3 =000007b6 r4 =dcfe5a10, r5 =dcfe5b28, r6 =c2e78076, r7 =c2f95480 r8 =c2f95480, r9 =c2e78076, r10=dcfe5b28, r11=dcfe5970 r12=00000000, ssp=dcfe5938, slr=c2d34370, pc =c053d8e8 [ thread pid 13 tid 100036 ] Stopped at syncookie_lookup+0x38: ldmib r6, {r1-r2} db> From owner-freebsd-arm@freebsd.org Mon Jun 20 01:32:31 2016 Return-Path: Delivered-To: freebsd-arm@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 A4267A79B46 for ; Mon, 20 Jun 2016 01:32:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (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 5EC581EF8 for ; Mon, 20 Jun 2016 01:32:30 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9235 invoked from network); 20 Jun 2016 01:32:18 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 20 Jun 2016 01:32:18 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Sun, 19 Jun 2016 21:32:28 -0400 (EDT) Received: (qmail 20973 invoked from network); 20 Jun 2016 01:32:28 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 20 Jun 2016 01:32:28 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 3CE71B1E001; Sun, 19 Jun 2016 18:32:17 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [lock order reversal then later Alignment Fault] Message-Id: <8994A697-B521-4618-96F5-23539F59F2D6@dsl-only.net> Date: Sun, 19 Jun 2016 18:32:21 -0700 To: otacilio.neto@bsd.com.br, freebsd-arm Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 01:32:31 -0000 Otac=C3=ADlio otacilio.neto at bsd.com.br wrote on Sun Jun 19 21:40:29 = UTC 2016: > Processing entries: 6%lock order reversal: > 1st 0xc30b35d4 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2048 > 2nd 0xc319d6f4 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2498 then later: > Kernel page fault with the following=20 > non-sleepable locks held: > exclusive sleep mutex tcp_sc_head (tcp_sc_head) r =3D 0 (0xc2f9d520)=20= > locked @ /usr/src/sys/netinet/tcp_syncache.c:494 > shared rw tcp (tcp) r =3D 0 (0xc08ef348) locked @=20 > /usr/src/sys/netinet/tcp_input.c:1034 > exclusive rw tcpinp (tcpinp) r =3D 0 (0xc31ab494) locked @=20 > /usr/src/sys/netinet/in_pcb.c:1964 then later: > Fatal kernel mode data abort: 'Alignment Fault' on read > trapframe: 0xdcfe58a8 > FSR=3D00000001, FAR=3Dc2e7187a, spsr=3D60000013 > r0 =3Dc08e7988, r1 =3D00000004, r2 =3Dc06fa3ad, r3 =3D000007b6 > r4 =3Ddcfe5a10, r5 =3Ddcfe5b28, r6 =3Dc2e71876, r7 =3Dc2f9d520 > r8 =3Dc2f9d520, r9 =3Dc2e71876, r10=3Ddcfe5b28, r11=3Ddcfe5970 > r12=3D00000000, ssp=3Ddcfe5938, slr=3Dc2d34370, pc =3Dc053d8e8 >=20 > [ thread pid 13 tid 100036 ] > Stopped at syncookie_lookup+0x38: ldmib r6, {r1-r2} This was based on 11.0 -r301846. The last part may be tied to the later fix in -r301872 for network code = (quoting = https://lists.freebsd.org/pipermail/svn-src-head/2016-June/088339.html = ): > Author: ian > Date: Mon Jun 13 16:48:27 2016 > New Revision: 301872 > URL:=20 > https://svnweb.freebsd.org/changeset/base/301872 >=20 >=20 > Log: > Do not define __NO_STRICT_ALIGNMENT for armv6. While the = requirements > are no longer natural-alignment strict, there are still some = restrictions. > =20 > FreeBSD network code assumes data is naturally-aligned or is running > on a platform with no restrictions; pointers are not annotated to > indicate the data pointed to may be packed or unaligned. The clang > optimizer can sometimes combine the load or store of a pair of = adjacent > 32-bit values into a single doubleword load/store, and that = operation > requires at least 4-byte alignment. __NO_STRICT_ALIGNMENT can lead > to tcp headers being only 2-byte aligned. > =20 > Note that alignment faults remain disabled on armv6, this change = reverts > only the defining of the symbol which leads to some overly-agressive = code > shortcuts when building common/shared drivers and network code for = arm. > =20 > Approved by: re(kib) >=20 > Modified: > head/sys/arm/include/_types.h >=20 > Modified: head/sys/arm/include/_types.h > = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > --- head/sys/arm/include/_types.h Mon Jun 13 11:19:06 2016 = (r301871) > +++ head/sys/arm/include/_types.h Mon Jun 13 16:48:27 2016 = (r301872) > @@ -43,10 +43,6 @@ > #error this file needs sys/cdefs.h as a prerequisite > #endif > =20 > -#if __ARM_ARCH >=3D 6 > -#define __NO_STRICT_ALIGNMENT > -#endif > - > /* > * Basic types upon which most other types are built. > */ The later ssh related report in "Otac=C3=ADlio otacilio.neto at = bsd.com.br Sun Jun 19 21:47:40 UTC 2016" that also includes a matching = Alignment fault that may also fit with the fix above. Quoting: > The kernel panic is totally reproducible. I need only do a ssh in the=20= > beaglebone using ptty on windows or ssh on freebsd and the kernel = panic=20 > is raised. >=20 > FreeBSD/arm (beaglebone) (ttyu0) >=20 > login: Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex tcp_sc_head (tcp_sc_head) r =3D 0 (0xc2f95480)=20= > locked @ /usr/src/sys/netinet/tcp_syncache.c:494 > shared rw tcp (tcp) r =3D 0 (0xc08ef348) locked @=20 > /usr/src/sys/netinet/tcp_input.c:1034 > exclusive rw tcpinp (tcpinp) r =3D 0 (0xc341e494) locked @=20 > /usr/src/sys/netinet/in_pcb.c:1964 > stack backtrace: > Fatal kernel mode data abort: 'Alignment Fault' on read > trapframe: 0xdcfe58a8 > FSR=3D00000001, FAR=3Dc2e7807a, spsr=3D60000013 > r0 =3Dc08e7988, r1 =3D00000004, r2 =3Dc06fa3ad, r3 =3D000007b6 > r4 =3Ddcfe5a10, r5 =3Ddcfe5b28, r6 =3Dc2e78076, r7 =3Dc2f95480 > r8 =3Dc2f95480, r9 =3Dc2e78076, r10=3Ddcfe5b28, r11=3Ddcfe5970 > r12=3D00000000, ssp=3Ddcfe5938, slr=3Dc2d34370, pc =3Dc053d8e8 >=20 > [ thread pid 13 tid 100036 ] > Stopped at syncookie_lookup+0x38: ldmib r6, {r1-r2} The rpi2 that I have access to is busy doing buildworld and buildkernel = under WITH_META_MODE for the first time. So I'll not be independently = checking that context anytime soon. It is at -r301975 (basically = matching ALPHA4's snapshot) but built "no debug" style for the kernel = (with debug symbols). The rpi2 is the only supported armv6 context that = I currently have access to. [I've not experimented with the ODRIOD-C2 = material at https://github.com/tomtor/freebsd/tree/tc2 yet and may not = for some time.] You may want to try -r301872 or later, although only the Alignment fault = might be the only change of status. If -r301872 or later still shows an Alignment fault then Ian Lepore and = others likely would be very interested in learning about it as soon as = possible. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Jun 20 02:41:58 2016 Return-Path: Delivered-To: freebsd-arm@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 AD258A7B63A for ; Mon, 20 Jun 2016 02:41:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (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 6F09F17C9 for ; Mon, 20 Jun 2016 02:41:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12789 invoked from network); 20 Jun 2016 02:42:30 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 20 Jun 2016 02:42:30 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Sun, 19 Jun 2016 22:42:40 -0400 (EDT) Received: (qmail 25473 invoked from network); 20 Jun 2016 02:42:40 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 20 Jun 2016 02:42:40 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 2F4C0B1E001; Sun, 19 Jun 2016 19:41:50 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: Compiling 11 on a Raspberry B+ 2 failes [not in my experience for -r301975] Message-Id: Date: Sun, 19 Jun 2016 19:41:54 -0700 To: erichsfreebsdlist@alogt.com, freebsd-arm , FreeBSD Current Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 02:41:58 -0000 Quoting Erich Dollansky erichsfreebsdlist at alogt.com Sun Jun 19 = 23:38:56 UTC 2016 : > I am trying to compile HEAD on a Raspberry and get always the = following > error. >=20 > Of course, compiling revision 302017 on amd64 works. >=20 > Erich >=20 > Last Changed Rev: 301974 >=20 > /usr/src/lib/csu/arm/crt1.c:(.text+0xb4): relocation truncated to > fit: R_ARM_CALL against symbol `atexit' defined in .text section > in /usr/lib/libc.a(atexit.o) /usr/src/lib/csu/arm/crt1.c:(.text+0xbc): > relocation truncated to fit: R_ARM_CALL against symbol `_init_tls' > defined in .text section > in /usr/lib/libc.a(tls.o) /usr/src/lib/csu/arm/crt1.c:(.text+0xcc): > relocation truncated to fit: R_ARM_CALL against symbol `atexit' = defined > in .text section > in /usr/lib/libc.a(atexit.o) = /usr/src/lib/csu/arm/crt1.c:(.text+0x174): > relocation truncated to fit: R_ARM_CALL against symbol `exit' defined > in .text section in /usr/lib/libc.a(exit.o) /usr/lib/crt1.o: In > function `finalizer': /usr/src/lib/csu/arm/crt1.c:(.text+0x1ec): > relocation truncated to fit: R_ARM_JUMP24 against symbol `_fini' > defined in .fini section in /usr/lib/crti.o c++: error: linker command > failed with exit code 1 (use -v to see invocation) *** Error code 1 >=20 > Stop. > bmake[4]: stopped in /usr/src.head/usr.bin/clang/clang > *** Error code 1 >=20 > Stop. > bmake[3]: stopped in /usr/src.head/usr.bin/clang > *** Error code 1 >=20 > Stop. > bmake[2]: stopped in /usr/src.head > *** Error code 1 >=20 > Stop. > bmake[1]: stopped in /usr/src.head > *** Error code 1 >=20 > Stop. > make: stopped in /usr/src.head > [raspberry2]~/System (root) >=20 I've done buildworld buildkernel for -r301975 on an rpi2 (not using = WITH_META_MODE=3Dyes) with no problem. The rpi2 was already running = -r301975 via a amd64 -> rpi2 cross build. You do not mention what vintage of 11.0 your -r301974 build was started = from. A uname -apKU output would be appropriate to post as one way of indicating that. My WITH_META_MODE=3Dyes buidlworld buildkernel is still in process. Later below list my src.conf showing my slightly odd choices targeting = armv7-a/cortex-a7 explicitly. I'd be surprised if that makes a = difference for this issue. You have not provided your src.conf or = make.conf or other such context. My -r301975 cross builds on amd64 targeting an rpi2 [armv7-a/cortex-a7] = have all worked fine (no matter if WITH_META_MODE_yes was in use or = not). I've only used the system clang 3.8.0 to target armv6 in modern times. My src.conf for rpi2 self hosted builds looks like: > # more ~/src.configs/src.conf.rpi2-clang-bootstrap.rpi2-host=20 > TO_TYPE=3Darmv6 > # > KERNCONF=3DRPI2-NODBG > TARGET=3Darm > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3D${TO_TYPE} > .export TARGET_ARCH > .endif > # > #WITH_CROSS_COMPILER=3D > WITH_SYSTEM_COMPILER=3D > # > #CPUTYPE=3Dsoft > WITH_LIBSOFT=3D > WITH_LIBCPLUSPLUS=3D > WITH_BINUTILS_BOOTSTRAP=3D > #WITHOUT_CLANG_BOOTSTRAP=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_CLANG_EXTRAS=3D > WITH_LLDB=3D > # > WITH_BOOT=3D > WITHOUT_LIB32=3D > # > WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D > WITHOUT_GCC_BOOTSTRAP=3D > WITHOUT_GCC=3D > WITHOUT_GCC_IS_CC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > #WERROR=3D > MALLOC_PRODUCTION=3D > # > WITH_DEBUG_FILES=3D > # > XCFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 > XCXXFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 > # There is no XCPPFLAGS but XCPP ets XCFLAGS content. The ~/src.configs/make.conf is empty. The amd64 -> rpi2 cross builds are only different for src.conf by: > # diff ~/src.configs/src.conf.rpi2-clang-bootstrap.rpi2-host = ~/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host=20 > 10,11c10,11 > < #WITH_CROSS_COMPILER=3D > < WITH_SYSTEM_COMPILER=3D > --- > > WITH_CROSS_COMPILER=3D > > WITHOUT_SYSTEM_COMPILER=3D > 17c17 > < #WITHOUT_CLANG_BOOTSTRAP=3D > --- > > WITH_CLANG_BOOTSTRAP=3D Showing the "on a rpi2" script that runs make for using = WITH_META_MODE=3Dyes : > # more = ~/sys_build_scripts.rpi2-host/make_rpi2_nodebug_clang_bootstrap-rpi2-host.= sh=20 > kldload -n filemon && \ > script = ~/sys_typescripts/typescript_make_rpi2_nodebug_clang_bootstrap-rpi2-host-$= (date +%Y-%m-%d:%H:%M:%S) \ > env __MAKE_CONF=3D"/root/src.configs/make.conf" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.rpi2-clang-bootstrap.rpi2-host"= \ > WITH_META_MODE=3Dyes \ > MAKEOBJDIRPREFIX=3D"/usr/obj/clang/arm.armv6" \ > make $* My /usr/src tree has some changes/additions --but mostly for powerpc64 = and powerpc issues: > # svnlite status /usr/src/ > M = /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp > M /usr/src/lib/csu/powerpc64/Makefile > ? /usr/src/sys/amd64/include/include > ? /usr/src/sys/arm/conf/RPI2-NODBG > ? /usr/src/sys/arm/include/include > M /usr/src/sys/boot/ofw/Makefile.inc > M /usr/src/sys/boot/powerpc/Makefile > M /usr/src/sys/boot/powerpc/Makefile.inc > M /usr/src/sys/boot/uboot/Makefile.inc > M /usr/src/sys/conf/Makefile.powerpc > M /usr/src/sys/conf/kern.mk > M /usr/src/sys/conf/kmod.mk > M /usr/src/sys/dev/cxgb/ulp/tom/cxgb_listen.c > M /usr/src/sys/dev/cxgbe/tom/t4_listen.c > ? /usr/src/sys/powerpc/conf/GENERIC64-NODBG > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG > ? /usr/src/sys/powerpc/conf/GENERICvtsc > ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG > ? /usr/src/sys/powerpc/include/include > M /usr/src/sys/powerpc/ofw/ofw_machdep.c > M /usr/src/sys/powerpc/powerpc/exec_machdep.c > ? /usr/src/sys/x86/include/include (The include/include ones are from something making links pointing back = up to the parent include/ . I did not explicitly create these.) (The cxbg and cxbge ones were from trying to have amd64 target amd64 via = xtoolchain (devel/amd64-gcc). But other places also stopped it and I = quit trying that for now.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Jun 20 05:57:20 2016 Return-Path: Delivered-To: freebsd-arm@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 19620A7AB6F for ; Mon, 20 Jun 2016 05:57:20 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::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 8424C21D8 for ; Mon, 20 Jun 2016 05:57:19 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: by mail-lf0-x235.google.com with SMTP id q132so30628432lfe.3 for ; Sun, 19 Jun 2016 22:57:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ZHB3nvFOtWERqckaWLMfr2U5qe24tQYmAF5Y0GWIlxU=; b=W2JZ3rWAx8tujPrVfUI1wtzNmtzg+Y1VkM3x9um39P7r106tJEmpnLQ50Pc+4cxrur e9jG0IfXJdrHMOVYnJfgeQ/SIUqcLjgX63WvbL6nQEIOqw/YBO23Ausn/E/ksma5pW5O HaPnh9ggo674uOa378J3G1q6xvATxmyNvh9V9OvexZmDhUddNVKwhpgVXZViWRZQJtm+ Q/hoMcuifS8z9vKyb76uVtNNopawTCpie2Ygs/PA9sKum9Expauy4hAl8WBIdMppci9A nDNGjgyHEoZrMdasRoI1NQ2VS6Eo3YIX0nZHYz1UjExaqXpDtTCfLlilpiqBYGIoFTyH BpYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ZHB3nvFOtWERqckaWLMfr2U5qe24tQYmAF5Y0GWIlxU=; b=KCTwufAVTNr7GpGomjNAY6P7a7McTpyKffo1YEmUarRO0rzDuUDWFvPptctjEIUgha hcNYgK2b6smpRI71xYpAp0fVm90M8ZD1buefTZFwONvbdKumjxNIu0KN+vHDf9hbtO6Q nky15/jRMvcORHrP1yvCjw4P4LGF+CQnsF0Rzjn3MHTzxojaH5pQ0DKVstWr6Ch5rR1Q /bSAxmMTuw3djVe7c7oL0vI2hZCSHY82yVm0T81BifcpM96hd9c7SFUsNXYffhN1A3wg 71LsO7P5ybLLHT1oZUUnIgKGo3/W8EawxGlo8JmTpKQm+pfK9g2sFcGuxryAX30Qt14l PTwg== X-Gm-Message-State: ALyK8tLprxMLuS2S2YTpN5YYz/5pnZvpHzRhfDu3ntKsYUS25KR3wdZgDWLkOInamB4ROrxpGERdLn/Ll9ZrRw== X-Received: by 10.25.127.4 with SMTP id a4mr3794913lfd.111.1466402237202; Sun, 19 Jun 2016 22:57:17 -0700 (PDT) MIME-Version: 1.0 References: <20160618072747.6c6d4328@X220.alogt.com> In-Reply-To: <20160618072747.6c6d4328@X220.alogt.com> From: Tom Vijlbrief Date: Mon, 20 Jun 2016 05:57:07 +0000 Message-ID: Subject: Re: Compiling HEAD on a Raspberry Pi B+ 2 failes To: Erich Dollansky , freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 05:57:20 -0000 This is an issue from early this year. See freebsd-toolchain/2016-January/001906.html For a fix Tom Op za 18 jun. 2016 01:28 schreef Erich Dollansky : > Hi, > > I am trying to compile HEAD on a Raspberry and get always the following > error. > > Erich > > Last Changed Rev: 301974 > > /usr/src/lib/csu/arm/crt1.c:(.text+0xb4): relocation truncated to > fit: R_ARM_CALL against symbol `atexit' defined in .text section > in /usr/lib/libc.a(atexit.o) /usr/src/lib/csu/arm/crt1.c:(.text+0xbc): > relocation truncated to fit: R_ARM_CALL against symbol `_init_tls' > defined in .text section > in /usr/lib/libc.a(tls.o) /usr/src/lib/csu/arm/crt1.c:(.text+0xcc): > relocation truncated to fit: R_ARM_CALL against symbol `atexit' defined > in .text section > in /usr/lib/libc.a(atexit.o) /usr/src/lib/csu/arm/crt1.c:(.text+0x174): > relocation truncated to fit: R_ARM_CALL against symbol `exit' defined > in .text section in /usr/lib/libc.a(exit.o) /usr/lib/crt1.o: In > function `finalizer': /usr/src/lib/csu/arm/crt1.c:(.text+0x1ec): > relocation truncated to fit: R_ARM_JUMP24 against symbol `_fini' > defined in .fini section in /usr/lib/crti.o c++: error: linker command > failed with exit code 1 (use -v to see invocation) *** Error code 1 > > Stop. > bmake[4]: stopped in /usr/src.head/usr.bin/clang/clang > *** Error code 1 > > Stop. > bmake[3]: stopped in /usr/src.head/usr.bin/clang > *** Error code 1 > > Stop. > bmake[2]: stopped in /usr/src.head > *** Error code 1 > > Stop. > bmake[1]: stopped in /usr/src.head > *** Error code 1 > > Stop. > make: stopped in /usr/src.head > [raspberry2]~/System (root) > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Mon Jun 20 06:20:37 2016 Return-Path: Delivered-To: freebsd-arm@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 E5E61A7AED3 for ; Mon, 20 Jun 2016 06:20:37 +0000 (UTC) (envelope-from erich@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) (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 C96A2298B for ; Mon, 20 Jun 2016 06:20:37 +0000 (UTC) (envelope-from erich@alogt.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References: In-Reply-To:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=3IHPflAi3V6ApMZNfgo982yzrrhwxxe+CYeAAlX5uHo=; b=EMBy/hM2m6Bv1UiQazb2hi3CXk RbZZZsSEiKYQAa9pTGt71JXguluGho+tlDZF224JcU+orTXCVhE1k4ZIGoep0fi31B8c7sMPLzYbq Ay+Fq8q23xZpeChvi2l2I+n5byvZzVwytc08i2jP3O1GvNxVh86tZnfV6DdbTSFLP1es=; Received: from [114.120.235.68] (port=65494 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1bEsZY-0044d9-HJ; Mon, 20 Jun 2016 00:20:37 -0600 Date: Mon, 20 Jun 2016 14:20:31 +0800 From: Erich Dollansky To: Tom Vijlbrief Cc: freebsd-arm Subject: Re: Compiling HEAD on a Raspberry Pi B+ 2 failes Message-ID: <20160620142031.1d219cc6@X220.alogt.com> In-Reply-To: References: <20160618072747.6c6d4328@X220.alogt.com> Organization: ALO Green Technologies MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erich@alogt.com X-Authenticated-Sender: sl-508-2.slc.westdc.net: erich@alogt.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 06:20:38 -0000 Hi, On Mon, 20 Jun 2016 05:57:07 +0000 Tom Vijlbrief wrote: > This is an issue from early this year. > > See > > freebsd-toolchain/2016-January/001906.html > > For a fix thanks, I did it and the Raspberry is compiling now. As you know, this will take some time. Erich > > Tom > > Op za 18 jun. 2016 01:28 schreef Erich Dollansky : > > > Hi, > > > > I am trying to compile HEAD on a Raspberry and get always the > > following error. > > > > Erich > > > > Last Changed Rev: 301974 > > > > /usr/src/lib/csu/arm/crt1.c:(.text+0xb4): relocation truncated to > > fit: R_ARM_CALL against symbol `atexit' defined in .text section > > in /usr/lib/libc.a(atexit.o) /usr/src/lib/csu/arm/crt1.c:(.text+0xbc): > > relocation truncated to fit: R_ARM_CALL against symbol `_init_tls' > > defined in .text section > > in /usr/lib/libc.a(tls.o) /usr/src/lib/csu/arm/crt1.c:(.text+0xcc): > > relocation truncated to fit: R_ARM_CALL against symbol `atexit' > > defined in .text section > > in /usr/lib/libc.a(atexit.o) /usr/src/lib/csu/arm/crt1.c:(.text+0x174): > > relocation truncated to fit: R_ARM_CALL against symbol `exit' > > defined in .text section > > in /usr/lib/libc.a(exit.o) /usr/lib/crt1.o: In function > > `finalizer': /usr/src/lib/csu/arm/crt1.c:(.text+0x1ec): relocation > > truncated to fit: R_ARM_JUMP24 against symbol `_fini' defined > > in .fini section in /usr/lib/crti.o c++: error: linker command > > failed with exit code 1 (use -v to see invocation) *** Error code 1 > > > > Stop. > > bmake[4]: stopped in /usr/src.head/usr.bin/clang/clang > > *** Error code 1 > > > > Stop. > > bmake[3]: stopped in /usr/src.head/usr.bin/clang > > *** Error code 1 > > > > Stop. > > bmake[2]: stopped in /usr/src.head > > *** Error code 1 > > > > Stop. > > bmake[1]: stopped in /usr/src.head > > *** Error code 1 > > > > Stop. > > make: stopped in /usr/src.head > > [raspberry2]~/System (root) > > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to > > "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Mon Jun 20 06:50:12 2016 Return-Path: Delivered-To: freebsd-arm@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 ECA49A7B62C for ; Mon, 20 Jun 2016 06:50:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (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 AE6AB1BC8 for ; Mon, 20 Jun 2016 06:50:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17184 invoked from network); 20 Jun 2016 06:50:11 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 20 Jun 2016 06:50:11 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Mon, 20 Jun 2016 02:50:15 -0400 (EDT) Received: (qmail 27143 invoked from network); 20 Jun 2016 06:50:15 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 20 Jun 2016 06:50:15 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 383A0B1E001; Sun, 19 Jun 2016 23:50:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Compiling 11 on a Raspberry B+ 2 failes [not in my experience for -r301975] From: Mark Millard In-Reply-To: Date: Sun, 19 Jun 2016 23:50:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <71F9C259-E75C-49F0-B7DC-4719E630BD88@dsl-only.net> References: To: erichsfreebsdlist@alogt.com, freebsd-arm , FreeBSD Current X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 06:50:13 -0000 On 2016-Jun-19, at 7:41 PM, Mark Millard wrote: > Quoting Erich Dollansky erichsfreebsdlist at alogt.com Sun Jun 19 = 23:38:56 UTC 2016 : >=20 >> I am trying to compile HEAD on a Raspberry and get always the = following >> error. >>=20 >> Of course, compiling revision 302017 on amd64 works. >>=20 >> Erich >>=20 >> Last Changed Rev: 301974 >>=20 >> /usr/src/lib/csu/arm/crt1.c:(.text+0xb4): relocation truncated to >> fit: R_ARM_CALL against symbol `atexit' defined in .text section >> in /usr/lib/libc.a(atexit.o) = /usr/src/lib/csu/arm/crt1.c:(.text+0xbc): >> relocation truncated to fit: R_ARM_CALL against symbol `_init_tls' >> defined in .text section >> in /usr/lib/libc.a(tls.o) /usr/src/lib/csu/arm/crt1.c:(.text+0xcc): >> relocation truncated to fit: R_ARM_CALL against symbol `atexit' = defined >> in .text section >> in /usr/lib/libc.a(atexit.o) = /usr/src/lib/csu/arm/crt1.c:(.text+0x174): >> relocation truncated to fit: R_ARM_CALL against symbol `exit' defined >> in .text section in /usr/lib/libc.a(exit.o) /usr/lib/crt1.o: In >> function `finalizer': /usr/src/lib/csu/arm/crt1.c:(.text+0x1ec): >> relocation truncated to fit: R_ARM_JUMP24 against symbol `_fini' >> defined in .fini section in /usr/lib/crti.o c++: error: linker = command >> failed with exit code 1 (use -v to see invocation) *** Error code 1 >>=20 >> Stop. >> bmake[4]: stopped in /usr/src.head/usr.bin/clang/clang >> *** Error code 1 >>=20 >> Stop. >> bmake[3]: stopped in /usr/src.head/usr.bin/clang >> *** Error code 1 >>=20 >> Stop. >> bmake[2]: stopped in /usr/src.head >> *** Error code 1 >>=20 >> Stop. >> bmake[1]: stopped in /usr/src.head >> *** Error code 1 >>=20 >> Stop. >> make: stopped in /usr/src.head >> [raspberry2]~/System (root) >=20 >=20 >=20 > I've done buildworld buildkernel for -r301975 on an rpi2 (not using = WITH_META_MODE=3Dyes) with no problem. The rpi2 was already running = -r301975 via a amd64 -> rpi2 cross build. >=20 > You do not mention what vintage of 11.0 your -r301974 build was = started from. A >=20 > uname -apKU >=20 > output would be appropriate to post as one way of indicating that. I went back and looked up my old notes from 2016-Jan-18 ( = https://lists.freebsd.org/pipermail/freebsd-arm/2016-January/013053.html = ) and it indicates that one must use 11.0 -r294031 or later to build = clang 3.8.0. The issue is clang 3.8.0 being bigger and needing -mlong-calls compiler = options in more places than the older clang 3.7.1 did. Quoting from the 2016-Jan-18 message. . . > The clang 3.8.0 investigation ran into this for building clang and = lldb. A quick scan of materials checked out from that branch (my = /usr/src is bound to that branch) shows the following as far as what 4 = Makefile* or 2 *.mk files list the option someplace: >=20 > > # find /usr/src/ -name .svn -prune -o -name 'Makefile*' -exec grep = mlong-calls {} \; -print > > STATIC_CXXFLAGS+=3D -mlong-calls > > /usr/src/lib/libc++/Makefile > > STATIC_CFLAGS+=3D -mlong-calls > > /usr/src/lib/csu/arm/Makefile > > CFLAGS+=3D -mlong-calls > > /usr/src/usr.bin/clang/lldb/Makefile > > CFLAGS+=3D -mlong-calls > > /usr/src/usr.bin/clang/clang/Makefile >=20 >=20 > > # find /usr/src/ -name .svn -prune -o -name '*.mk' -exec grep = mlong-calls {} \; -print > > STATIC_CXXFLAGS+=3D -mlong-calls > > /usr/src/lib/clang/clang.lib.mk > > CFLAGS+=3D -G0 -fno-pic -mno-abicalls -mlong-calls > > /usr/src/sys/conf/kmod.mk >=20 >=20 > (That last one is for mips instead of arm and has been around a long = time.) [Back to quoting the recent message. . .] > My WITH_META_MODE=3Dyes buidlworld buildkernel is still in process. The WITH_META_MODE=3Dyes build also completed fine. [WITH_META_MODE=3Dyes = is a recent addition to the build environment.] > Later below list my src.conf showing my slightly odd choices targeting = armv7-a/cortex-a7 explicitly. I'd be surprised if that makes a = difference for this issue. You have not provided your src.conf or = make.conf or other such context. >=20 > My -r301975 cross builds on amd64 targeting an rpi2 = [armv7-a/cortex-a7] have all worked fine (no matter if = WITH_META_MODE_yes was in use or not). >=20 > I've only used the system clang 3.8.0 to target armv6 in modern times. >=20 > My src.conf for rpi2 self hosted builds looks like: >=20 >> # more ~/src.configs/src.conf.rpi2-clang-bootstrap.rpi2-host=20 >> TO_TYPE=3Darmv6 >> # >> KERNCONF=3DRPI2-NODBG >> TARGET=3Darm >> .if ${.MAKE.LEVEL} =3D=3D 0 >> TARGET_ARCH=3D${TO_TYPE} >> .export TARGET_ARCH >> .endif >> # >> #WITH_CROSS_COMPILER=3D >> WITH_SYSTEM_COMPILER=3D >> # >> #CPUTYPE=3Dsoft >> WITH_LIBSOFT=3D >> WITH_LIBCPLUSPLUS=3D >> WITH_BINUTILS_BOOTSTRAP=3D >> #WITHOUT_CLANG_BOOTSTRAP=3D >> WITH_CLANG=3D >> WITH_CLANG_IS_CC=3D >> WITH_CLANG_FULL=3D >> WITH_CLANG_EXTRAS=3D >> WITH_LLDB=3D >> # >> WITH_BOOT=3D >> WITHOUT_LIB32=3D >> # >> WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D >> WITHOUT_GCC_BOOTSTRAP=3D >> WITHOUT_GCC=3D >> WITHOUT_GCC_IS_CC=3D >> WITHOUT_GNUCXX=3D >> # >> NO_WERROR=3D >> #WERROR=3D >> MALLOC_PRODUCTION=3D >> # >> WITH_DEBUG_FILES=3D >> # >> XCFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 >> XCXXFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 >> # There is no XCPPFLAGS but XCPP ets XCFLAGS content. >=20 > The ~/src.configs/make.conf is empty. >=20 > The amd64 -> rpi2 cross builds are only different for src.conf by: >=20 >> # diff ~/src.configs/src.conf.rpi2-clang-bootstrap.rpi2-host = ~/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host=20 >> 10,11c10,11 >> < #WITH_CROSS_COMPILER=3D >> < WITH_SYSTEM_COMPILER=3D >> --- >>> WITH_CROSS_COMPILER=3D >>> WITHOUT_SYSTEM_COMPILER=3D >> 17c17 >> < #WITHOUT_CLANG_BOOTSTRAP=3D >> --- >>> WITH_CLANG_BOOTSTRAP=3D >=20 >=20 > Showing the "on a rpi2" script that runs make for using = WITH_META_MODE=3Dyes : >=20 >> # more = ~/sys_build_scripts.rpi2-host/make_rpi2_nodebug_clang_bootstrap-rpi2-host.= sh=20 >> kldload -n filemon && \ >> script = ~/sys_typescripts/typescript_make_rpi2_nodebug_clang_bootstrap-rpi2-host-$= (date +%Y-%m-%d:%H:%M:%S) \ >> env __MAKE_CONF=3D"/root/src.configs/make.conf" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.rpi2-clang-bootstrap.rpi2-host"= \ >> WITH_META_MODE=3Dyes \ >> MAKEOBJDIRPREFIX=3D"/usr/obj/clang/arm.armv6" \ >> make $* >=20 > My /usr/src tree has some changes/additions --but mostly for powerpc64 = and powerpc issues: >=20 >> # svnlite status /usr/src/ >> M = /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp >> M /usr/src/lib/csu/powerpc64/Makefile >> ? /usr/src/sys/amd64/include/include >> ? /usr/src/sys/arm/conf/RPI2-NODBG >> ? /usr/src/sys/arm/include/include >> M /usr/src/sys/boot/ofw/Makefile.inc >> M /usr/src/sys/boot/powerpc/Makefile >> M /usr/src/sys/boot/powerpc/Makefile.inc >> M /usr/src/sys/boot/uboot/Makefile.inc >> M /usr/src/sys/conf/Makefile.powerpc >> M /usr/src/sys/conf/kern.mk >> M /usr/src/sys/conf/kmod.mk >> M /usr/src/sys/dev/cxgb/ulp/tom/cxgb_listen.c >> M /usr/src/sys/dev/cxgbe/tom/t4_listen.c >> ? /usr/src/sys/powerpc/conf/GENERIC64-NODBG >> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc >> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG >> ? /usr/src/sys/powerpc/conf/GENERICvtsc >> ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG >> ? /usr/src/sys/powerpc/include/include >> M /usr/src/sys/powerpc/ofw/ofw_machdep.c >> M /usr/src/sys/powerpc/powerpc/exec_machdep.c >> ? /usr/src/sys/x86/include/include >=20 > (The include/include ones are from something making links pointing = back up to the parent include/ . I did not explicitly create these.) >=20 > (The cxbg and cxbge ones were from trying to have amd64 target amd64 = via xtoolchain (devel/amd64-gcc). But other places also stopped it and I = quit trying that for now.) >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Jun 20 08:15:38 2016 Return-Path: Delivered-To: freebsd-arm@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 57000A7B6D7 for ; Mon, 20 Jun 2016 08:15:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-153.reflexion.net [208.70.211.153]) (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 075222C0D for ; Mon, 20 Jun 2016 08:15:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 3059 invoked from network); 20 Jun 2016 08:16:03 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 20 Jun 2016 08:16:03 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Mon, 20 Jun 2016 04:15:26 -0400 (EDT) Received: (qmail 32751 invoked from network); 20 Jun 2016 08:15:25 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 20 Jun 2016 08:15:25 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id E2A1CB1E001; Mon, 20 Jun 2016 01:15:27 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: FYI: how long for a "nothing new" 11.0 -r301975 WITH_META_MODE=yes build on an rpi2? Message-Id: Date: Mon, 20 Jun 2016 01:15:27 -0700 To: freebsd-arm , FreeBSD Current Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 08:15:38 -0000 [One oddity of the rpi2 context for the below is that the root file = system is on a fast USB SSD drive: it is really a fast USB 3.0 SSD drive = just used on the USB 2 bus via a USB 3.0 capable hub.] I just did the following sort of sequence on an rpi2 for 11.0 -r301975 = rebuilding itself where the .sh script used indicates to use = WITH_META_MODE=3Dyes for the make command : > # = ~/sys_build_scripts.rpi2-host/make_rpi2_nodebug_clang_bootstrap-rpi2-host.= sh -j 5 buildworld buildkernel > # = ~/sys_build_scripts.rpi2-host/make_rpi2_nodebug_clang_bootstrap-rpi2-host.= sh -j 5 buildworld buildkernel (Also the .sh runs script to log all the make output. The first build = was actually more involved than shown above, see later notes.) The 2nd one took about 15 or 16 minutes to go through everything and, in = essence, discover that nothing needed to be rebuilt. This was (still) = using WITH_LIBSOFT=3D in the src.conf file. Also: WITH_CLANG_FULL=3D = WITH_CLANG_EXTRAS=3D WITH_LLDB=3D were in use. . . > # more ~/src.configs/src.conf.rpi2-clang-bootstrap.rpi2-host=20 > TO_TYPE=3Darmv6 > # > KERNCONF=3DRPI2-NODBG > TARGET=3Darm > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3D${TO_TYPE} > .export TARGET_ARCH > .endif > # > #WITH_CROSS_COMPILER=3D > WITH_SYSTEM_COMPILER=3D > # > #CPUTYPE=3Dsoft > WITH_LIBSOFT=3D > WITH_LIBCPLUSPLUS=3D > WITH_BINUTILS_BOOTSTRAP=3D > #WITHOUT_CLANG_BOOTSTRAP=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_CLANG_EXTRAS=3D > WITH_LLDB=3D > # > WITH_BOOT=3D > WITHOUT_LIB32=3D > # > WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D > WITHOUT_GCC_BOOTSTRAP=3D > WITHOUT_GCC=3D > WITHOUT_GCC_IS_CC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > #WERROR=3D > MALLOC_PRODUCTION=3D > # > WITH_DEBUG_FILES=3D > # > XCFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 > XCXXFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 > # There is no XCPPFLAGS but XCPP ets XCFLAGS content. ~/src.configs/make.conf was empty. Other notes: I've not had any problems with WITH_META_MODE=3Dyes use for the self = hosting 11.0 -r301975 rpi2 builds. Going from not using WITH_META_MODE=3Dyes to using WITH_META_MODE=3Dyes = in the self-hosting context did not require a cleanworld between the = builds. (Cross build transitions in that direction do require such = still.) I do not report the WITH_META_MODE=3Dyes build time for the first time = because I actually did more. I: A) forced a root file system I/O failure/panic (during what happened to be libxo building) B) then started WITH_META_MODE=3Dyes again (after booting) C) let it run until the incomplete file(s) from the failure caused it to = stop D) did a make clean for libxo E) then started WITH_META_MODE=3Dyes yet again F) let it run to completion The WITH_META_MODE=3Dyes use appears to have worked just fine despite = the abusive nature of the test. I will report that not using WITH_META_MODE=3Dyes took between 15 hr and = 16 hr (no such odd testing sequence involved). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Jun 20 15:57:04 2016 Return-Path: Delivered-To: freebsd-arm@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 B5CECA7B507; Mon, 20 Jun 2016 15:57:04 +0000 (UTC) (envelope-from loos.br@gmail.com) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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 863DA121E; Mon, 20 Jun 2016 15:57:04 +0000 (UTC) (envelope-from loos.br@gmail.com) Received: by mail-it0-x231.google.com with SMTP id h190so41450371ith.1; Mon, 20 Jun 2016 08:57:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yhQbL9e6GqDcLLJEh98cqZ467Z+1DtO0B3UmKNgjHrs=; b=h7cRF+kHhyU45Lf7MLcrza1yxSkE7uHa/sSnt1oRnjsInNydxxIB6TnWzJJVUJcb1w 33kdDVkuBagigpa6c9QpjwlkCVRlh231IP2L9RH/ASc8+Yo0DuUPQdVkCyIuglRVIOeq 1GwzzvUZcDaGJwYTzQAxcupp7OF28mU4XsxwB4SX5Rxwb3KZK5cJB/IlyUut+3OAQVzT 3+ZZA+vWDx715pikTvW99idIkBanWLBD80uwX6zUAS9f2M+wB1P08k3dmt1w/3lwrYM9 vvLwaVQerX7fnVRmxuashyc2T16VLB8Pdt5AX00BruPru0FGSP9Qj7MpYhPD0cahLu4Y ra2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yhQbL9e6GqDcLLJEh98cqZ467Z+1DtO0B3UmKNgjHrs=; b=Zxk7pnh6g4aZ4RUCoJBXpUUTbRZdJ1duKiZz5n/Nh2wHd+k1ZvscMomxzWULZ0w2+e r8sGnUQUGTGOSEKjwao0CLAPDSW2kS/HqBPYjS5hmJyeylvKW9wztlBuUHlbC9UNTRlZ Fo5XNA1hQyulLa6BZLfkq4lohtSGLWuQi9P05dNUjyTkD+kyHPEmHvKtBwOs7ywTD8UM VBzWyQ9B2jMygIwZu9EcvGxE2O6EDq49yy8xObon0Uq8PLCb1mzEkUIAnWUQRqOP1hhv lBhqBOZmCYq6eorda7lKvrfHs6UudP0XR59ns0dLt8yJSfE8Z3sVQ32u3dPKLl2UN5Y/ +Vvg== X-Gm-Message-State: ALyK8tK0F4mamNZRQjqRa7MIJr7GWdR4Oij1bwSZPGisFGWfX13aKlwbONo4N3OKEHuvcu39DqEqvj/eoK3eQQ== X-Received: by 10.36.17.131 with SMTP id 125mr8799372itf.81.1466438223884; Mon, 20 Jun 2016 08:57:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.33.132 with HTTP; Mon, 20 Jun 2016 08:57:03 -0700 (PDT) In-Reply-To: References: <83A18C0E-FA89-4009-A8D5-3185FB27A688@netgate.com> From: Luiz Otavio O Souza Date: Mon, 20 Jun 2016 12:57:03 -0300 Message-ID: Subject: Re: BBB (cpsw(4)) seems to be broken in the latest 11-current To: Maxim Sobolev Cc: Jim Thompson , Svatopluk Kraus , "freebsd-arm@freebsd.org" , FreeBSD Current Content-Type: multipart/mixed; boundary=001a114452e26b900a0535b7c1e7 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 15:57:04 -0000 --001a114452e26b900a0535b7c1e7 Content-Type: text/plain; charset=UTF-8 On Sun, Jun 19, 2016 at 1:11 AM, Maxim Sobolev wrote: > Jim, some update from here. Running r283287 of the driver, I still see the > same "watchdog timeout" messages, but they do not lead to the interface > lockout. The traffic resumes momentarily. Which is probably why I never paid > much attention to those warnings before. Therefore, I suspect that the new > MAC code does not deal with watchdog-triggered interface reset as good as > the old code. Does it give you any ideas about what could be wrong there by > any chance? Hi Maxim, My recent changes contributed somehow to expose the bug more frequently. There was a condition in tx packet reclamation where we aren't restarting the tx queue in one of the possible stall conditions. Please try the attached patch and let me know if it works for you. Luiz --001a114452e26b900a0535b7c1e7 Content-Type: text/plain; charset=US-ASCII; name="cpsw-eoq-restart.diff" Content-Disposition: attachment; filename="cpsw-eoq-restart.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ipo6vinw0 SW5kZXg6IHN5cy9hcm0vdGkvY3Bzdy9pZl9jcHN3LmMKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2FybS90 aS9jcHN3L2lmX2Nwc3cuYwkocmV2aXNpb24gMzAxOTc1KQorKysgc3lzL2FybS90aS9jcHN3L2lm X2Nwc3cuYwkod29ya2luZyBjb3B5KQpAQCAtMTg3NCw2ICsxODc0LDcgQEAKIAkJcmV0dXJuOwog CX0gZWxzZSBpZiAobGFzdF9vbGRfc2xvdCA9PSBOVUxMKSB7CiAJCS8qIFN0YXJ0IGEgZnJlc2gg cXVldWUuICovCisJCXNjLT5zd3NjLT5sYXN0X2hkcCA9IGNwc3dfY3BkbWFfYmRfcGFkZHIoc2Mt PnN3c2MsIGZpcnN0X25ld19zbG90KTsKIAkJY3Bzd193cml0ZV9oZHBfc2xvdChzYy0+c3dzYywg JnNjLT5zd3NjLT50eCwgZmlyc3RfbmV3X3Nsb3QpOwogCX0gZWxzZSB7CiAJCS8qIEFkZCBidWZm ZXJzIHRvIGVuZCBvZiBjdXJyZW50IHF1ZXVlLiAqLwpAQCAtMTg4Miw2ICsxODgzLDcgQEAKIAkJ LyogSWYgdW5kZXJydW4sIHJlc3RhcnQgcXVldWUuICovCiAJCWlmIChjcHN3X2NwZG1hX3JlYWRf YmRfZmxhZ3Moc2MtPnN3c2MsIGxhc3Rfb2xkX3Nsb3QpICYKIAkJICAgIENQRE1BX0JEX0VPUSkg eworCQkJc2MtPnN3c2MtPmxhc3RfaGRwID0gY3Bzd19jcGRtYV9iZF9wYWRkcihzYy0+c3dzYywg Zmlyc3RfbmV3X3Nsb3QpOwogCQkJY3Bzd193cml0ZV9oZHBfc2xvdChzYy0+c3dzYywgJnNjLT5z d3NjLT50eCwKIAkJCSAgICBmaXJzdF9uZXdfc2xvdCk7CiAJCX0KQEAgLTE4OTcsNiArMTg5OSw3 IEBACiBjcHN3X3R4X2RlcXVldWUoc3RydWN0IGNwc3dfc29mdGMgKnNjKQogewogCXN0cnVjdCBj cHN3X3Nsb3QgKnNsb3QsICpsYXN0X3JlbW92ZWRfc2xvdCA9IE5VTEw7CisJc3RydWN0IGNwc3df Y3BkbWFfYmQgYmQ7CiAJdWludDMyX3QgZmxhZ3MsIHJlbW92ZWQgPSAwOwogCiAJc2xvdCA9IFNU QUlMUV9GSVJTVCgmc2MtPnR4LmFjdGl2ZSk7CkBAIC0xOTMxLDcgKzE5MzQsOCBAQAogCQl9CiAK IAkJLyogVGVhckRvd24gY29tcGxldGUgaXMgb25seSBtYXJrZWQgb24gdGhlIFNPUCBmb3IgdGhl IHBhY2tldC4gKi8KLQkJaWYgKGZsYWdzICYgQ1BETUFfQkRfVERPV05DTVBMVCkgeworCQlpZiAo KGZsYWdzICYgKENQRE1BX0JEX1NPUCB8IENQRE1BX0JEX1RET1dOQ01QTFQpKSA9PQorCQkgICAg KENQRE1BX0JEX0VPUCB8IENQRE1BX0JEX1RET1dOQ01QTFQpKSB7CiAJCQlDUFNXX0RFQlVHRihz YywgKCJUWCB0ZWFyZG93biBpbiBwcm9ncmVzcyIpKTsKIAkJCWNwc3dfd3JpdGVfY3Aoc2MsICZz Yy0+dHgsIDB4ZmZmZmZmZmMpOwogCQkJLy8gVE9ETzogSW5jcmVtZW50IGEgY291bnQgb2YgZHJv cHBlZCBUWCBwYWNrZXRzCkBAIC0xOTM4LDYgKzE5NDIsMTYgQEAKIAkJCXNjLT50eC5ydW5uaW5n ID0gMDsKIAkJCWJyZWFrOwogCQl9CisKKwkJaWYgKChmbGFncyAmIENQRE1BX0JEX0VPUCkgPT0g MCkKKwkJCWZsYWdzID0gY3Bzd19jcGRtYV9yZWFkX2JkX2ZsYWdzKHNjLCBsYXN0X3JlbW92ZWRf c2xvdCk7CisJCWlmICgoZmxhZ3MgJiAoQ1BETUFfQkRfRU9QIHwgQ1BETUFfQkRfRU9RKSkgPT0K KwkJICAgIChDUERNQV9CRF9FT1AgfCBDUERNQV9CRF9FT1EpKSB7CisJCQljcHN3X2NwZG1hX3Jl YWRfYmQoc2MsIGxhc3RfcmVtb3ZlZF9zbG90LCAmYmQpOworCQkJaWYgKGJkLm5leHQgIT0gMCAm JiBiZC5uZXh0ICE9IHNjLT5sYXN0X2hkcCkKKwkJCQkvKiBSZXN0YXJ0IHRoZSBxdWV1ZS4gKi8K KwkJCQljcHN3X3dyaXRlXzQoc2MsIHNjLT50eC5oZHBfb2Zmc2V0LCBiZC5uZXh0KTsKKwkJfQog CX0KIAogCWlmIChyZW1vdmVkICE9IDApIHsKSW5kZXg6IHN5cy9hcm0vdGkvY3Bzdy9pZl9jcHN3 dmFyLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQotLS0gc3lzL2FybS90aS9jcHN3L2lmX2Nwc3d2YXIuaAkocmV2aXNp b24gMzAxOTc1KQorKysgc3lzL2FybS90aS9jcHN3L2lmX2Nwc3d2YXIuaAkod29ya2luZyBjb3B5 KQpAQCAtODMsNiArODMsNyBAQAogCiAJLyogUlggYW5kIFRYIGJ1ZmZlciB0cmFja2luZyAqLwog CXN0cnVjdCBjcHN3X3F1ZXVlIHJ4LCB0eDsKKwl1aW50MzJfdAlsYXN0X2hkcDsKIAogCS8qIFdl IGV4cGVjdCAxIG1lbW9yeSByZXNvdXJjZSBhbmQgNCBpbnRlcnJ1cHRzIGZyb20gdGhlIGRldmlj ZSB0cmVlLiAqLwogCWludAkJbWVtX3JpZDsK --001a114452e26b900a0535b7c1e7-- From owner-freebsd-arm@freebsd.org Mon Jun 20 17:00:04 2016 Return-Path: Delivered-To: freebsd-arm@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 BF573AC436A for ; Mon, 20 Jun 2016 17:00:04 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 867A31AB2 for ; Mon, 20 Jun 2016 17:00:04 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 7bd55043-3708-11e6-8929-8ded99d5e9d7 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Mon, 20 Jun 2016 17:00:25 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u5KGxtMm003754; Mon, 20 Jun 2016 10:59:56 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1466441995.34556.44.camel@freebsd.org> Subject: Re: pl2303 lockups on rpi2 From: Ian Lepore To: bob prohaska , Hal Murray Cc: freebsd-arm@freebsd.org Date: Mon, 20 Jun 2016 10:59:55 -0600 In-Reply-To: <20160619003651.GB38492@www.zefox.net> References: <20160618025517.GA38492@www.zefox.net> <20160618043430.28E93406057@ip-64-139-1-69.sjc.megapath.net> <20160619003651.GB38492@www.zefox.net> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 17:00:04 -0000 On Sat, 2016-06-18 at 17:36 -0700, bob prohaska wrote: > On Fri, Jun 17, 2016 at 09:34:30PM -0700, Hal Murray wrote: > > > > How solid is your power? > > > > The three RPI2s that I can check easily are all over 5 Volts. The > fourth is hard to get at, but it shares the same power supply type > and is unlikely to be significantly different. > > Swapping places between the two adapters that locked up with the > two that kept working didn't turn out as planned. The two adapters > that were failing still failed, but one that hadn't failed up to > then did, in about 48 hours. > > The one encouragement is that updating to r301978 and rebooting > unstuck an adapter that had locked up under r301569. Up to now > it's been necessary to expose the adapters to Prolific's driver > to unstick them. Unplugging and replugging didn't help. > > There seem to be nine supported USB-serial adapter types, can you > suggest a better bet if I have to go shopping again? I can't find > kind words about any of them. > > Thanks for reading! > > bob prohaska While I've heard more good things than bad about freebsd's support of pl2303, the one I can personally vouch for is FTDI. We use them extensively at $work, which means basically I get paid to maintain the freebsd driver for them. While FTDI adapters are great, there have been problems with counterfeit hardware. Buy from a reputable source, and if somebody is offerring a crazy-low price on them, it's probably not genuine FTDI. -- Ian From owner-freebsd-arm@freebsd.org Mon Jun 20 18:37:43 2016 Return-Path: Delivered-To: freebsd-arm@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 2D004AC41E1; Mon, 20 Jun 2016 18:37:43 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 076A0172F; Mon, 20 Jun 2016 18:37:42 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from [172.27.2.35] (unknown [172.27.2.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 273C2541; Mon, 20 Jun 2016 14:31:40 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: BBB (cpsw(4)) seems to be broken in the latest 11-current From: Paul Mather In-Reply-To: Date: Mon, 20 Jun 2016 14:31:39 -0400 Cc: FreeBSD Current , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <71DC2BCB-C486-4772-AE32-CC0816B4E93F@gromit.dlib.vt.edu> References: To: Maxim Sobolev X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 18:37:43 -0000 On Jun 18, 2016, at 2:50 AM, Maxim Sobolev wrote: > Updated my BBB to the latest -current, immediately got this while = trying to > make world over ssh console: >=20 > 06:02:17 CPSW watchdog cpswss0: watchdog timeout > cpswss0: Unable to cleanly shutdown transmitter >=20 > Interface seems to be locked after that, no traffic comes in or out. >=20 > This is: >=20 > FreeBSD 11.0-ALPHA3 #1 ba7edef(tps65217x)-dirty: Fri Jun 17 16:22:07 = PDT > 2016, svn revision 301898 >=20 > The previous version that was rock-solid was: >=20 > FreeBSD 11.0-CURRENT #0 9d390ee(tps65217x)-dirty: Mon Jul 6 19:31:30 = PDT > 2015, svn revision 284878 >=20 > I've been running buildworlds for literally days on that board, = because > it's how long it takes to build on that hardware. :) >=20 > I'll run it again and see if the issue re-appears. >=20 > If anyone seen this or if it's known issue please let me know. I have experienced this problem recently, too, after updating to = 11.0-ALPHA3. I get the watchdog timeout messages you give above when = trying to buildworld with /usr/src and /usr/obj mounted via NFS. My last successful build that did not have this problem is this one: = FreeBSD beaglebone 11.0-ALPHA2 FreeBSD 11.0-ALPHA2 #0 r301779: Mon Jun = 13 01:30:05 EDT 2016 = pmather@beaglebone:/usr/obj/usr/src/sys/BEAGLEBONE-NO_WITNESS arm The build where this started happening for me is this one: FreeBSD = 11.0-ALPHA3 #0 r301876: Wed Jun 15 14:23:28 EDT 2016 That's just two days apart. Maybe that might help track down the = potential revision that caused the problem. I've not been able to = buildworld via NFS since the problem began, so I've reverted back to the = r301779 kernel for now. Cheers, Paul. From owner-freebsd-arm@freebsd.org Mon Jun 20 22:33:32 2016 Return-Path: Delivered-To: freebsd-arm@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 CE454AC4EC2; Mon, 20 Jun 2016 22:33:32 +0000 (UTC) (envelope-from kwhite@site.uottawa.ca) Received: from courriel.site.uottawa.ca (eecsmail.engineering.uottawa.ca [137.122.24.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "courriel.site.uottawa.ca", Issuer "DigiCert SHA2 Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 93BB21973; Mon, 20 Jun 2016 22:33:31 +0000 (UTC) (envelope-from kwhite@site.uottawa.ca) Received: from [10.0.2.15] (ppp-66-186-88-176.vianet.ca [66.186.88.176]) (authenticated bits=0) by courriel.site.uottawa.ca (8.14.5/8.14.5) with ESMTP id u5KMXMGs006384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 Jun 2016 18:33:23 -0400 (EDT) (envelope-from kwhite@site.uottawa.ca) Date: Mon, 20 Jun 2016 18:33:22 -0400 (EDT) From: Keith White X-X-Sender: kwhite@localhost.my.domain To: Luiz Otavio O Souza cc: Maxim Sobolev , FreeBSD Current , "freebsd-arm@freebsd.org" Subject: Re: BBB (cpsw(4)) seems to be broken in the latest 11-current In-Reply-To: Message-ID: References: <83A18C0E-FA89-4009-A8D5-3185FB27A688@netgate.com> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 22:33:32 -0000 On Mon, 20 Jun 2016, Luiz Otavio O Souza wrote: > On Sun, Jun 19, 2016 at 1:11 AM, Maxim Sobolev wrote: >> Jim, some update from here. Running r283287 of the driver, I still see the >> same "watchdog timeout" messages, but they do not lead to the interface >> lockout. The traffic resumes momentarily. Which is probably why I never paid >> much attention to those warnings before. Therefore, I suspect that the new >> MAC code does not deal with watchdog-triggered interface reset as good as >> the old code. Does it give you any ideas about what could be wrong there by >> any chance? > > > Hi Maxim, > > My recent changes contributed somehow to expose the bug more frequently. > > There was a condition in tx packet reclamation where we aren't > restarting the tx queue in one of the possible stall conditions. > > Please try the attached patch and let me know if it works for you. > > Luiz Your patch fixes the problem for me. Thanks! FreeBSD beaglebone 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #0 r302028M: Mon Jun 20 18:19:55 EDT 2016 kwhite@freebsd11:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE-LOCAL arm armv6 ...keith From owner-freebsd-arm@freebsd.org Mon Jun 20 22:49:50 2016 Return-Path: Delivered-To: freebsd-arm@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 EE2BFAC433E for ; Mon, 20 Jun 2016 22:49:50 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::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 B212D23E2 for ; Mon, 20 Jun 2016 22:49:50 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-ob0-x235.google.com with SMTP id mu6so2235703obc.3 for ; Mon, 20 Jun 2016 15:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=54ofdZEFdIBKlqGqvy9pSO2qSJNY19Ajp6prF51P4f4=; b=z65MKsv7xzW2zdAaZqo4j6JcplgRvLj43+NBltAC7lkPlZXQBaFQHIGs54CdznqWC9 kZ3/kVvyMBBo0SAoTJrrUcFYmO/TFow+MxiHHmviJ7fuTObNjU1IymjCBdG2b7ddOQRI b4jutsj0AlK6ezEiJSor3OeTXwnf8id1b1Rxb3q8K0Ycrbv91Aa7PhWyFZHw0BpyrgkJ uRHKYKR3eVKv92egXfdPmAO23zlsnAsVPR/KsacV7++9eZAhx1oCgzU08AcuRvTULV0D gwAyhBgNM32CR6M/lwY/jrYjS/LseHZb7IHxogDtjX7hYtuYy6wQ0m3iPGFNiHt6fdQ0 P6wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=54ofdZEFdIBKlqGqvy9pSO2qSJNY19Ajp6prF51P4f4=; b=mltTe4u2EqruPerQJr0xE3DBtftjbEC3Uh5euB9StaDm6tdpkHWAjf3B54CoS1UPbS oXjQMSEOpmMuJI/rkDZeHut6QHIsr2wOEJnBT2K+esM8RFLNlgKqWNNaSOjCn/YKOJjx UCewUJO25w7nnb3AKC56z8hZ2QtezeZ/awUBDpv47FL0Ro7qsCMImkdDbZObwpNtatMu c3hgauEcRCJeFPF8ZBUkQ6Cr0wxlB9bAYbnI15QFQFh4vIQBYYU3842Gbi7QSgpfZQzR 0QA3PlMyE7NSZM12CbuYyO8+RLrSL6WVBQ0E7Jss1WuWj9jPClhSQJhkSXc15oSWbT1F UJqQ== X-Gm-Message-State: ALyK8tKFiPTwkcrb8X6pCbWdxLNToo0+mQDGYXkPOMY3M+9bP13nzw1ItVYYj0Q3Mekw50BfEQ5p01kybRUcEumT X-Received: by 10.157.1.241 with SMTP id e104mr12578205ote.180.1466462990041; Mon, 20 Jun 2016 15:49:50 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.157.41.209 with HTTP; Mon, 20 Jun 2016 15:49:49 -0700 (PDT) In-Reply-To: References: <83A18C0E-FA89-4009-A8D5-3185FB27A688@netgate.com> From: Maxim Sobolev Date: Mon, 20 Jun 2016 15:49:49 -0700 X-Google-Sender-Auth: gEWYWo7EFwQCgW6_SaSWTR8nC8I Message-ID: Subject: Re: BBB (cpsw(4)) seems to be broken in the latest 11-current To: Keith White Cc: Luiz Otavio O Souza , FreeBSD Current , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 22:49:51 -0000 Nice to hear. I am building it right now. Gotta get you some results in the next few hours. Thanks! -Max On Mon, Jun 20, 2016 at 3:33 PM, Keith White wrote: > On Mon, 20 Jun 2016, Luiz Otavio O Souza wrote: > > On Sun, Jun 19, 2016 at 1:11 AM, Maxim Sobolev wrote: >> >>> Jim, some update from here. Running r283287 of the driver, I still see >>> the >>> same "watchdog timeout" messages, but they do not lead to the interface >>> lockout. The traffic resumes momentarily. Which is probably why I never >>> paid >>> much attention to those warnings before. Therefore, I suspect that the >>> new >>> MAC code does not deal with watchdog-triggered interface reset as good as >>> the old code. Does it give you any ideas about what could be wrong there >>> by >>> any chance? >>> >> >> >> Hi Maxim, >> >> My recent changes contributed somehow to expose the bug more frequently. >> >> There was a condition in tx packet reclamation where we aren't >> restarting the tx queue in one of the possible stall conditions. >> >> Please try the attached patch and let me know if it works for you. >> >> Luiz >> > > Your patch fixes the problem for me. Thanks! > > FreeBSD beaglebone 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #0 r302028M: Mon Jun 20 > 18:19:55 EDT 2016 kwhite@freebsd11:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE-LOCAL > arm armv6 > > ...keith > From owner-freebsd-arm@freebsd.org Tue Jun 21 00:06:39 2016 Return-Path: Delivered-To: freebsd-arm@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 BF250AC49EF for ; Tue, 21 Jun 2016 00:06:39 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 81F8D2B59 for ; Tue, 21 Jun 2016 00:06:39 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qk0-x22d.google.com with SMTP id c73so384429qkg.2 for ; Mon, 20 Jun 2016 17:06:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=yQVzk2+4SBJqxNiYq6hpp98vl6/qiW7HBAod0OcyPn4=; b=gDpB0qagYy5cvIQbY3extb7OfCIVjpeXQoqK/XCAtz8xX3hiC7JjOLLs68A/1tTZ50 dOlW2TaFEn4Ra/aMgpw/d/FWya65j+/qIm4Mri/3XE5HwjMQYOyeYRCChR0I+gvAJlqq E1lhvizq2VGUXvwUrBYiNl/ZbIXK2RgLTuWGk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=yQVzk2+4SBJqxNiYq6hpp98vl6/qiW7HBAod0OcyPn4=; b=jgA+jJrmviWrR7/uptpkhgZKBQasoSFvLPbsrqa4sUjBHvkpdlO/DAsHri4SKv5eUY 4913rMzFWB+PVuNMXLKtpymAuYNk3O0zua0sH3Q1ju7NgP3Pb4jhJodzPfb8tqG/pYy7 DGUX4XZMozXuy0JXIwVsSHbzdtFMWQm90PgU8EnXVNn6CVMly/Ay110A+QgL2IAa0BIi 4w3U+wYrEojcfDtNLFJc83N5cc0H9RL+I0cKwWzz7Zr8ALWs2aG6XCsLsAWDjgN1QHDa fr0XW82Xeq7iz8cQByAGWn1m7WlMVoe4JCsgGkQtA1rr+pwo+RX8N66mAsgGB4t0iYDC OP8Q== X-Gm-Message-State: ALyK8tK9MqJN19vgge6I02Q8thlWxkiWUKQJ+tvtASEtO0Qo7fFup54yNlFKSAVWHg33Yw== X-Received: by 10.55.203.202 with SMTP id u71mr24913601qkl.12.1466467598271; Mon, 20 Jun 2016 17:06:38 -0700 (PDT) Received: from [192.168.0.18] ([187.60.94.34]) by smtp.googlemail.com with ESMTPSA id a198sm21990458qkc.24.2016.06.20.17.06.36 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Jun 2016 17:06:37 -0700 (PDT) Subject: Re: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held To: "freebsd-arm@freebsd.org" , freebsd-hackers@freebsd.org References: <5e322d5a-8c42-8e69-f3c4-e607d40e8724@bsd.com.br> From: =?UTF-8?B?T3RhY8OtbGlv?= Message-ID: <1a55f000-eff9-31db-f420-e00278c4c054@bsd.com.br> Date: Mon, 20 Jun 2016 21:06:15 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <5e322d5a-8c42-8e69-f3c4-e607d40e8724@bsd.com.br> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 00:06:39 -0000 Em 19/06/2016 18:47, Otacílio escreveu: > Em 19/06/2016 18:40, Otacílio escreveu: >> I was installing netperf on a fresh FreeBSD-ALPHA3 >> >> FreeBSD beaglebone 11.0-ALPHA3 FreeBSD 11.0-ALPHA3 #0 r301846: Mon >> Jun 13 19:54:27 BRT 2016 >> ota@nostromo:/root/crochet/work/obj/arm.armv6/usr/src/sys/BEAGLEBONE-DEBUG >> arm >> >> on BeagleboneBlack using wrtwn when I got this kernel panic: >> >> root@beaglebone:/usr/home/ota # pkg install netperf >> Updating FreeBSD repository catalogue... >> Fetching meta.txz: 100% 944 B 0.9kB/s 00:01 >> Fetching packagesite.txz: 100% 4 MiB 46.0kB/s 01:42 >> Processing entries: 6%lock order reversal: >> 1st 0xc30b35d4 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2048 >> 2nd 0xc319d6f4 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2498 >> stack backtrace: >> Processing entries: 58%Kernel page fault with the following >> non-sleepable locks held: >> exclusive sleep mutex tcp_sc_head (tcp_sc_head) r = 0 (0xc2f9d520) >> locked @ /usr/src/sys/netinet/tcp_syncache.c:494 >> shared rw tcp (tcp) r = 0 (0xc08ef348) locked @ >> /usr/src/sys/netinet/tcp_input.c:1034 >> exclusive rw tcpinp (tcpinp) r = 0 (0xc31ab494) locked @ >> /usr/src/sys/netinet/in_pcb.c:1964 >> stack backtrace: >> Fatal kernel mode data abort: 'Alignment Fault' on read >> trapframe: 0xdcfe58a8 >> FSR=00000001, FAR=c2e7187a, spsr=60000013 >> r0 =c08e7988, r1 =00000004, r2 =c06fa3ad, r3 =000007b6 >> r4 =dcfe5a10, r5 =dcfe5b28, r6 =c2e71876, r7 =c2f9d520 >> r8 =c2f9d520, r9 =c2e71876, r10=dcfe5b28, r11=dcfe5970 >> r12=00000000, ssp=dcfe5938, slr=c2d34370, pc =c053d8e8 >> >> [ thread pid 13 tid 100036 ] >> Stopped at syncookie_lookup+0x38: ldmib r6, {r1-r2} >> db> >> >> >> []'s >> >> -Otacílio >> > The kernel panic is totally reproducible. I need only do a ssh in the > beaglebone using ptty on windows or ssh on freebsd and the kernel > panic is raised. > > FreeBSD/arm (beaglebone) (ttyu0) > > login: Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex tcp_sc_head (tcp_sc_head) r = 0 (0xc2f95480) > locked @ /usr/src/sys/netinet/tcp_syncache.c:494 > shared rw tcp (tcp) r = 0 (0xc08ef348) locked @ > /usr/src/sys/netinet/tcp_input.c:1034 > exclusive rw tcpinp (tcpinp) r = 0 (0xc341e494) locked @ > /usr/src/sys/netinet/in_pcb.c:1964 > stack backtrace: > Fatal kernel mode data abort: 'Alignment Fault' on read > trapframe: 0xdcfe58a8 > FSR=00000001, FAR=c2e7807a, spsr=60000013 > r0 =c08e7988, r1 =00000004, r2 =c06fa3ad, r3 =000007b6 > r4 =dcfe5a10, r5 =dcfe5b28, r6 =c2e78076, r7 =c2f95480 > r8 =c2f95480, r9 =c2e78076, r10=dcfe5b28, r11=dcfe5970 > r12=00000000, ssp=dcfe5938, slr=c2d34370, pc =c053d8e8 > > [ thread pid 13 tid 100036 ] > Stopped at syncookie_lookup+0x38: ldmib r6, {r1-r2} > db> > FreeBSD11-ALPHA4 shows the same behavior. The only thing that I need to raise the fault is ssh in the beaglebone. root@beaglebone:~ # uname -a FreeBSD beaglebone 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #0 r301975: Fri Jun 17 13:32:55 UTC 2016 root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE arm root@beaglebone:~ # Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex tcp_sc_head (tcp_sc_head) r = 0 (0xc2f98740) locked @ /usr/src/sys/netinet/tcp_syncache.c:494 shared rw tcp (tcp) r = 0 (0xc08ef348) locked @ /usr/src/sys/netinet/tcp_input.c:1034 exclusive rw tcpinp (tcpinp) r = 0 (0xc33e4494) locked @ /usr/src/sys/netinet/in_pcb.c:1964 stack backtrace: Fatal kernel mode data abort: 'Alignment Fault' on read trapframe: 0xdcfe58c0 FSR=00000001, FAR=c2e7a07a, spsr=60000013 r0 =c08e7988, r1 =00000004, r2 =c06fabe6, r3 =000007b6 r4 =dcfe5a28, r5 =dcfe5b40, r6 =c2e7a076, r7 =c2f98740 r8 =c2f98740, r9 =c2e7a076, r10=dcfe5b40, r11=dcfe5988 r12=00000000, ssp=dcfe5950, slr=c2d33370, pc =c053df7c [ thread pid 13 tid 100036 ] Stopped at syncookie_lookup+0x38: ldmib r6, {r1-r2} db> From owner-freebsd-arm@freebsd.org Tue Jun 21 04:14:49 2016 Return-Path: Delivered-To: freebsd-arm@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 C5368A7A8A7 for ; Tue, 21 Jun 2016 04:14:49 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 90570216B for ; Tue, 21 Jun 2016 04:14:49 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id u5L4Eegq002573 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Jun 2016 21:14:41 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id u5L4EeMV002572; Mon, 20 Jun 2016 21:14:40 -0700 (PDT) (envelope-from fbsd) Date: Mon, 20 Jun 2016 21:14:39 -0700 From: bob prohaska To: Hal Murray Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: pl2303 lockups on rpi2 Message-ID: <20160621041439.GA2449@www.zefox.net> References: <20160619020311.GC38492@www.zefox.net> <20160619034248.1D097406057@ip-64-139-1-69.sjc.megapath.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160619034248.1D097406057@ip-64-139-1-69.sjc.megapath.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 04:14:49 -0000 On Sat, Jun 18, 2016 at 08:42:48PM -0700, Hal Murray wrote: > > > The Linux geeks have figured out how to use the "console" as a serial port. > It's used by the GPS HATs. If you are trying to get work done rather than > debug USB stuff, that might be an interesting approach. You would need a > level shifter if you are talking to a real RS232 device. > The goal is simply to let one Pi monitor the console of another, thus making single user mode accessible over a network. After a recent lockup on the usb-serial adapter, I was very surprised to find the pl2303ta "came unstuck" when the serial cable connecting to the console port on the next Pi in the chain was disconnected. No need to unplug the USB side. Thanks for reading, bob prohaska > > From owner-freebsd-arm@freebsd.org Tue Jun 21 08:55:21 2016 Return-Path: Delivered-To: freebsd-arm@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 1D0E5AC520E for ; Tue, 21 Jun 2016 08:55:21 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-153.reflexion.net [208.70.211.153]) (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 D71EC13BF for ; Tue, 21 Jun 2016 08:55:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9369 invoked from network); 21 Jun 2016 08:55:49 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 21 Jun 2016 08:55:49 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Tue, 21 Jun 2016 04:55:09 -0400 (EDT) Received: (qmail 24229 invoked from network); 21 Jun 2016 08:55:09 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 21 Jun 2016 08:55:09 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id A9FED1C407A; Tue, 21 Jun 2016 01:55:11 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison] Message-Id: <99277FB6-77EB-4D8B-8A55-FBD622D29AC3@dsl-only.net> Date: Tue, 21 Jun 2016 01:55:11 -0700 To: otacilio.neto@bsd.com.br, freebsd-arm , FreeBSD Current Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 08:55:21 -0000 Otac=C3=ADlio otacilio.neto at bsd.com.br wrote on Tue Jun 21 00:06:39 = UTC 2016 : > > The kernel panic is totally reproducible. I need only do a ssh in = the > > beaglebone using ptty on windows or ssh on freebsd and the kernel=20 > > panic is raised. . . . > FreeBSD11-ALPHA4 shows the same behavior. The only thing that I need = to=20 > raise the fault is ssh in the beaglebone. (After this quotes are command input/output from my test activity.) Under 11.0 -r310975 on a rpi2 I can ssh out of the rpi2 just fine. . . > # uname -apKU > FreeBSD rpi2 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #1 r301975M: Thu Jun 16 = 18:12:02 PDT 2016 = markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG arm = armv6 1100117 1100117 This is a no-debug kernel build (but with symbols). Details are given = later below. > # ssh markmi@192.168.0.105 > Password: > Last login: Tue Jun 21 01:04:46 2016 > markmi$=20 Similarly I can ssh into the rpi2 from outside, here using new remote = connection in Mac OS X terminal: ssh 192.168.0.119 resulted in. . . > Password for markmi@rpi2: > Last login: Mon May 9 19:27:33 2016 from 192.168.2.1 > FreeBSD 11.0-ALPHA4 (RPI2-NODBG) #1 r301975M: Thu Jun 16 18:12:02 PDT = 2016 >=20 > Welcome to FreeBSD! >=20 > Release Notes, Errata: https://www.FreeBSD.org/releases/ > Security Advisories: https://www.FreeBSD.org/security/ > FreeBSD Handbook: https://www.FreeBSD.org/handbook/ > FreeBSD FAQ: https://www.FreeBSD.org/faq/ > Questions List: = https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/ > FreeBSD Forums: https://forums.FreeBSD.org/ >=20 > Documents installed with the system are in the = /usr/local/share/doc/freebsd/ > directory, or can be installed later with: pkg install en-freebsd-doc > For other languages, replace "en" with a language code like de or fr. >=20 > Show the version of FreeBSD installed: freebsd-version ; uname -a > Please include that output and any error messages when posting = questions. > Introduction to manual pages: man man > FreeBSD directory layout: man hier >=20 > Edit /etc/motd to change this login announcement. > To determine whether a file is a text file, executable, or some other = type > of file, use >=20 > file filename > -- Dru > $=20 No panics or other odd notices. The problem is apparently not general to all armv6 contexts. Various context details follow. . . > # more ~/src.configs/src.conf.rpi2-clang-bootstrap.rpi2-host=20 > TO_TYPE=3Darmv6 > # > KERNCONF=3DRPI2-NODBG > TARGET=3Darm > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3D${TO_TYPE} > .export TARGET_ARCH > .endif > # > #WITH_CROSS_COMPILER=3D > WITH_SYSTEM_COMPILER=3D > # > #CPUTYPE=3Dsoft > WITH_LIBSOFT=3D > WITH_LIBCPLUSPLUS=3D > WITH_BINUTILS_BOOTSTRAP=3D > #WITHOUT_CLANG_BOOTSTRAP=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_CLANG_EXTRAS=3D > WITH_LLDB=3D > # > WITH_BOOT=3D > WITHOUT_LIB32=3D > # > WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D > WITHOUT_GCC_BOOTSTRAP=3D > WITHOUT_GCC=3D > WITHOUT_GCC_IS_CC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > #WERROR=3D > MALLOC_PRODUCTION=3D > # > WITH_DEBUG_FILES=3D > # > XCFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 > XCXXFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 > # There is no XCPPFLAGS but XCPP ets XCFLAGS content. ~/src.configs/make.conf was empty. > # more /usr/src/sys/arm/conf/RPI2-NODBG > # > # RPI2 -- Custom configuration for the Raspberry Pi 2 > # > # For more information on this file, please read the config(5) manual = page, > # and/or the handbook section on Kernel Configuration Files: > # > # = http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-con= fig.html > # > # The handbook is also available locally in /usr/share/doc/handbook > # if you've installed the doc distribution, otherwise always see the > # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the > # latest information. > # > # An exhaustive list of options and more detailed explanations of the > # device lines is also present in the ../../conf/NOTES and NOTES = files. > # If you are in doubt as to the purpose or necessity of a line, check = first > # in NOTES. > # > =20 > ident RPI2-NODBG > =20 > include "RPI2" > =20 > makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols > options ALT_BREAK_TO_DEBUGGER > #options VERBOSE_SYSINIT # Enable verbose sysinit = messages > =20 > options KDB # Enable kernel debugger = support > =20 > # For minimum debugger support (stable branch) use: > #options KDB_TRACE # Print a stack trace for a = panic > options DDB # Enable the kernel debugger > =20 > nooptions INVARIANTS # Enable calls of extra sanity = checking > nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS > nooptions WITNESS # Enable checks to detect = deadlocks and cycles > nooptions WITNESS_SKIPSPIN # Don't run witness on = spinlocks for speed > nooptions DIAGNOSTIC My /usr/src tree has some changes/additions --but mostly for powerpc64 = and powerpc issues: > # svnlite status /usr/src/ > M = /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp > M /usr/src/lib/csu/powerpc64/Makefile > ? /usr/src/sys/amd64/include/include > ? /usr/src/sys/arm/conf/RPI2-NODBG > ? /usr/src/sys/arm/include/include > M /usr/src/sys/boot/ofw/Makefile.inc > M /usr/src/sys/boot/powerpc/Makefile > M /usr/src/sys/boot/powerpc/Makefile.inc > M /usr/src/sys/boot/uboot/Makefile.inc > M /usr/src/sys/conf/Makefile.powerpc > M /usr/src/sys/conf/kern.mk > M /usr/src/sys/conf/kmod.mk > M /usr/src/sys/dev/cxgb/ulp/tom/cxgb_listen.c > M /usr/src/sys/dev/cxgbe/tom/t4_listen.c > ? /usr/src/sys/powerpc/conf/GENERIC64-NODBG > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG > ? /usr/src/sys/powerpc/conf/GENERICvtsc > ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG > ? /usr/src/sys/powerpc/include/include > M /usr/src/sys/powerpc/ofw/ofw_machdep.c > M /usr/src/sys/powerpc/powerpc/exec_machdep.c > ? /usr/src/sys/x86/include/include (The include/include ones are from something making links pointing back = up to the parent include/ . I did not explicitly create these.) (The cxbg and cxbge ones were from trying to have amd64 target amd64 via = xtoolchain (devel/amd64-gcc). But other places also stopped it and I = quit trying that for now.) > # more /etc/rc.conf > hostname=3D"rpi2" > ifconfig_ue0=3D"DHCP" > sshd_enable=3D"YES" > =20 > powerd_enable=3D"YES" > =20 > # Nice if you have a network, else annoying. > ntpd_enable=3D"YES" > ntpd_sync_on_start=3D"YES" > =20 > # Uncomment to disable common services (more memory) > #cron_enable=3D"NO" > #syslogd_enable=3D"NO" > sendmail_enable=3D"NONE" > sendmail_submit_enable=3D"NO" > sendmail_outbound_enable=3D"NO" > sendmail_msp_queue_enable=3D"NO" > # > # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable > dumpdev=3D"AUTO" > # > dbus_enable=3D"YES" > hald_enable=3D"YES" > # > rpcbind_enable=3D"YES" > nfs_server_enable=3D"YES" > mountd_flags=3D"-r" > # > nfs_client_enable=3D"YES" > # more /etc/sysctl.conf=20 > # $FreeBSD: head/etc/sysctl.conf 112200 2003-03-13 18:43:50Z mux $ > # > # This file is read when going to multi-user and its contents piped = thru > # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for = details. > # > =20 > # Uncomment this to prevent users from seeing information about = processes that > # are being run under another UID. > #security.bsd.see_other_uids=3D0 > =20 > kern.nodump_coredump=3D1 > kern.capmode_coredump=3D1 > kern.sugid_coredump=3D1 > kern.corefile=3D/var/crash/%N.%P.core /etc/fstab , /etc/exports , /etc/resolv.conf are very simple but = non-default. Other than password files and the like the rest of /etc/. . = . is just defaults. > # more /boot/loader.conf=20 > kern.cam.boot_delay=3D"10000" =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Jun 21 10:34:06 2016 Return-Path: Delivered-To: freebsd-arm@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 A0D11A7ADC6; Tue, 21 Jun 2016 10:34:06 +0000 (UTC) (envelope-from kwhite@site.uottawa.ca) Received: from courriel.site.uottawa.ca (eecsmail.engineering.uottawa.ca [137.122.24.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "courriel.site.uottawa.ca", Issuer "DigiCert SHA2 Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2DA9F2701; Tue, 21 Jun 2016 10:34:05 +0000 (UTC) (envelope-from kwhite@site.uottawa.ca) Received: from [10.0.2.15] (ppp-66-186-88-176.vianet.ca [66.186.88.176]) (authenticated bits=0) by courriel.site.uottawa.ca (8.14.5/8.14.5) with ESMTP id u5LAXxOv038927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Jun 2016 06:34:00 -0400 (EDT) (envelope-from kwhite@site.uottawa.ca) Date: Tue, 21 Jun 2016 06:33:58 -0400 (EDT) From: Keith White X-X-Sender: kwhite@localhost.my.domain To: Mark Millard cc: otacilio.neto@bsd.com.br, freebsd-arm , FreeBSD Current Subject: Re: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison] In-Reply-To: <99277FB6-77EB-4D8B-8A55-FBD622D29AC3@dsl-only.net> Message-ID: References: <99277FB6-77EB-4D8B-8A55-FBD622D29AC3@dsl-only.net> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 10:34:06 -0000 On Tue, 21 Jun 2016, Mark Millard wrote: > Otacílio otacilio.neto at bsd.com.br wrote on Tue Jun 21 00:06:39 UTC 2016 : > >> > The kernel panic is totally reproducible. I need only do a ssh in the >> > beaglebone using ptty on windows or ssh on freebsd and the kernel >> > panic is raised. > . . . >> FreeBSD11-ALPHA4 shows the same behavior. The only thing that I need to >> raise the fault is ssh in the beaglebone. > > (After this quotes are command input/output from my test activity.) > > Under 11.0 -r310975 on a rpi2 I can ssh out of the rpi2 just fine. . . > >> # uname -apKU >> FreeBSD rpi2 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #1 r301975M: Thu Jun 16 18:12:02 PDT 2016 markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG arm armv6 1100117 1100117 > > > This is a no-debug kernel build (but with symbols). Details are given later below. > >> # ssh markmi@192.168.0.105 >> Password: >> Last login: Tue Jun 21 01:04:46 2016 >> markmi$ > > Similarly I can ssh into the rpi2 from outside, here using new remote connection in Mac OS X terminal: ssh 192.168.0.119 resulted in. . . > >> Password for markmi@rpi2: >> Last login: Mon May 9 19:27:33 2016 from 192.168.2.1 >> FreeBSD 11.0-ALPHA4 (RPI2-NODBG) #1 r301975M: Thu Jun 16 18:12:02 PDT 2016 >> >> Welcome to FreeBSD! >> >> Release Notes, Errata: https://www.FreeBSD.org/releases/ >> Security Advisories: https://www.FreeBSD.org/security/ >> FreeBSD Handbook: https://www.FreeBSD.org/handbook/ >> FreeBSD FAQ: https://www.FreeBSD.org/faq/ >> Questions List: https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/ >> FreeBSD Forums: https://forums.FreeBSD.org/ >> >> Documents installed with the system are in the /usr/local/share/doc/freebsd/ >> directory, or can be installed later with: pkg install en-freebsd-doc >> For other languages, replace "en" with a language code like de or fr. >> >> Show the version of FreeBSD installed: freebsd-version ; uname -a >> Please include that output and any error messages when posting questions. >> Introduction to manual pages: man man >> FreeBSD directory layout: man hier >> >> Edit /etc/motd to change this login announcement. >> To determine whether a file is a text file, executable, or some other type >> of file, use >> >> file filename >> -- Dru >> $ > > No panics or other odd notices. > > The problem is apparently not general to all armv6 contexts. > > Various context details follow. . . > >> # more ~/src.configs/src.conf.rpi2-clang-bootstrap.rpi2-host >> TO_TYPE=armv6 >> # >> KERNCONF=RPI2-NODBG >> TARGET=arm >> .if ${.MAKE.LEVEL} == 0 >> TARGET_ARCH=${TO_TYPE} >> .export TARGET_ARCH >> .endif >> # >> #WITH_CROSS_COMPILER= >> WITH_SYSTEM_COMPILER= >> # >> #CPUTYPE=soft >> WITH_LIBSOFT= >> WITH_LIBCPLUSPLUS= >> WITH_BINUTILS_BOOTSTRAP= >> #WITHOUT_CLANG_BOOTSTRAP= >> WITH_CLANG= >> WITH_CLANG_IS_CC= >> WITH_CLANG_FULL= >> WITH_CLANG_EXTRAS= >> WITH_LLDB= >> # >> WITH_BOOT= >> WITHOUT_LIB32= >> # >> WITHOUT_ELFTOOLCHAIN_BOOTSTRAP= >> WITHOUT_GCC_BOOTSTRAP= >> WITHOUT_GCC= >> WITHOUT_GCC_IS_CC= >> WITHOUT_GNUCXX= >> # >> NO_WERROR= >> #WERROR= >> MALLOC_PRODUCTION= >> # >> WITH_DEBUG_FILES= >> # >> XCFLAGS+= -march=armv7-a -mcpu=cortex-a7 >> XCXXFLAGS+= -march=armv7-a -mcpu=cortex-a7 >> # There is no XCPPFLAGS but XCPP ets XCFLAGS content. > > ~/src.configs/make.conf was empty. > >> # more /usr/src/sys/arm/conf/RPI2-NODBG >> # >> # RPI2 -- Custom configuration for the Raspberry Pi 2 >> # >> # For more information on this file, please read the config(5) manual page, >> # and/or the handbook section on Kernel Configuration Files: >> # >> # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html >> # >> # The handbook is also available locally in /usr/share/doc/handbook >> # if you've installed the doc distribution, otherwise always see the >> # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the >> # latest information. >> # >> # An exhaustive list of options and more detailed explanations of the >> # device lines is also present in the ../../conf/NOTES and NOTES files. >> # If you are in doubt as to the purpose or necessity of a line, check first >> # in NOTES. >> # >> >> ident RPI2-NODBG >> >> include "RPI2" >> >> makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols >> options ALT_BREAK_TO_DEBUGGER >> #options VERBOSE_SYSINIT # Enable verbose sysinit messages >> >> options KDB # Enable kernel debugger support >> >> # For minimum debugger support (stable branch) use: >> #options KDB_TRACE # Print a stack trace for a panic >> options DDB # Enable the kernel debugger >> >> nooptions INVARIANTS # Enable calls of extra sanity checking >> nooptions INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS >> nooptions WITNESS # Enable checks to detect deadlocks and cycles >> nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed >> nooptions DIAGNOSTIC > > > My /usr/src tree has some changes/additions --but mostly for powerpc64 and powerpc issues: > >> # svnlite status /usr/src/ >> M /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp >> M /usr/src/lib/csu/powerpc64/Makefile >> ? /usr/src/sys/amd64/include/include >> ? /usr/src/sys/arm/conf/RPI2-NODBG >> ? /usr/src/sys/arm/include/include >> M /usr/src/sys/boot/ofw/Makefile.inc >> M /usr/src/sys/boot/powerpc/Makefile >> M /usr/src/sys/boot/powerpc/Makefile.inc >> M /usr/src/sys/boot/uboot/Makefile.inc >> M /usr/src/sys/conf/Makefile.powerpc >> M /usr/src/sys/conf/kern.mk >> M /usr/src/sys/conf/kmod.mk >> M /usr/src/sys/dev/cxgb/ulp/tom/cxgb_listen.c >> M /usr/src/sys/dev/cxgbe/tom/t4_listen.c >> ? /usr/src/sys/powerpc/conf/GENERIC64-NODBG >> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc >> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG >> ? /usr/src/sys/powerpc/conf/GENERICvtsc >> ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG >> ? /usr/src/sys/powerpc/include/include >> M /usr/src/sys/powerpc/ofw/ofw_machdep.c >> M /usr/src/sys/powerpc/powerpc/exec_machdep.c >> ? /usr/src/sys/x86/include/include > > (The include/include ones are from something making links pointing back up to the parent include/ . I did not explicitly create these.) > > (The cxbg and cxbge ones were from trying to have amd64 target amd64 via xtoolchain (devel/amd64-gcc). But other places also stopped it and I quit trying that for now.) > >> # more /etc/rc.conf >> hostname="rpi2" >> ifconfig_ue0="DHCP" >> sshd_enable="YES" >> >> powerd_enable="YES" >> >> # Nice if you have a network, else annoying. >> ntpd_enable="YES" >> ntpd_sync_on_start="YES" >> >> # Uncomment to disable common services (more memory) >> #cron_enable="NO" >> #syslogd_enable="NO" >> sendmail_enable="NONE" >> sendmail_submit_enable="NO" >> sendmail_outbound_enable="NO" >> sendmail_msp_queue_enable="NO" >> # >> # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable >> dumpdev="AUTO" >> # >> dbus_enable="YES" >> hald_enable="YES" >> # >> rpcbind_enable="YES" >> nfs_server_enable="YES" >> mountd_flags="-r" >> # >> nfs_client_enable="YES" > >> # more /etc/sysctl.conf >> # $FreeBSD: head/etc/sysctl.conf 112200 2003-03-13 18:43:50Z mux $ >> # >> # This file is read when going to multi-user and its contents piped thru >> # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. >> # >> >> # Uncomment this to prevent users from seeing information about processes that >> # are being run under another UID. >> #security.bsd.see_other_uids=0 >> >> kern.nodump_coredump=1 >> kern.capmode_coredump=1 >> kern.sugid_coredump=1 >> kern.corefile=/var/crash/%N.%P.core > > > /etc/fstab , /etc/exports , /etc/resolv.conf are very simple but non-default. Other than password files and the like the rest of /etc/. . . is just defaults. > >> # more /boot/loader.conf >> kern.cam.boot_delay="10000" > > > > > === > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" I'm using an RPI-B rather than RPI2, but my symptoms are similar. Did you use the wired or wireless interface on the RPI2? I only get the panic on the RPI-B when using wireless. Wired works fine. In an earlier message Ian said that he thought he knew what the problem was... ...keith From owner-freebsd-arm@freebsd.org Tue Jun 21 11:11:31 2016 Return-Path: Delivered-To: freebsd-arm@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 9A4BCAC4761 for ; Tue, 21 Jun 2016 11:11:31 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 53BC61A3A for ; Tue, 21 Jun 2016 11:11:31 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qk0-x22e.google.com with SMTP id a186so15336777qkf.0 for ; Tue, 21 Jun 2016 04:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=7+yyYS0H/RCGAjBzJ/j/Cwrd6JwfVwpcLdMnm+8zR/I=; b=EXi5mPXVEplIo6Yz28vEYT1sh6mDhtDN73ZT8IQKKnans/HLAlERzin/2j2Qea+POg AgBzO+8YuN5IwzhkO1c+B8VLwLDo/iM04JVhWt1XmPyKwwW20tyGCS930b+/RJBPhc16 wfX52s/b6LKssSGVaDsuhmFp9Udq9/UlZPAXA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=7+yyYS0H/RCGAjBzJ/j/Cwrd6JwfVwpcLdMnm+8zR/I=; b=hQ+XcDxi9BbsRs1duvyPTlZDnHvWps5FTAj2Ct2D5p1AJsxtTNk8eR+BVme+62jngf 1N9EsJ6M3EfgZqAaJs3fx56KScxSVonaMOi/BK7A1LqQXaich3Xy2U3HxFoqBm8iMJEb fv0+9WRnY32hJqaduwjm2bK+Vt901ST7t22GXAQpluY83OhSJmYlMsVe+uaLJrJJhi4z O068NNOL4tstPzS3/ppMuO0T6p7UbCvoauuqtvMuqG76HKdKnGN/mnneAUNuxV1e0f1L V5dpXLjnrGNsXpJUVwuVv9fhiLdCK0awzO+R6hsT6rV21yIqTjhLudq1u/pU8fHSv5NI EsEQ== X-Gm-Message-State: ALyK8tILXSPqUW/xfHE+j47lB2K563iBwHZSC0lNCFCQAGiOLaFOhGlW9Tjcvanu3FkIHA== X-Received: by 10.200.37.150 with SMTP id e22mr28331867qte.37.1466507490246; Tue, 21 Jun 2016 04:11:30 -0700 (PDT) Received: from [192.168.0.18] ([187.60.94.34]) by smtp.googlemail.com with ESMTPSA id j62sm9981934qtb.35.2016.06.21.04.11.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Jun 2016 04:11:29 -0700 (PDT) Subject: Re: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison] To: Keith White , Mark Millard References: <99277FB6-77EB-4D8B-8A55-FBD622D29AC3@dsl-only.net> Cc: freebsd-arm , FreeBSD Current From: =?UTF-8?B?T3RhY8OtbGlv?= Message-ID: <22fe5f7f-6153-e092-c410-eddb1431a78a@bsd.com.br> Date: Tue, 21 Jun 2016 08:11:07 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 11:11:31 -0000 Em 21/06/2016 07:33, Keith White escreveu: > In an earlier message Ian said that he thought he knew what the > problem was... Here the problem occurs when using wifi. I do not have tested wired because I don't have a cable here. []'s -Otacilio From owner-freebsd-arm@freebsd.org Tue Jun 21 11:14:15 2016 Return-Path: Delivered-To: freebsd-arm@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 318CDAC49D8 for ; Tue, 21 Jun 2016 11:14:15 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-153.reflexion.net [208.70.211.153]) (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 EA5A61DAA for ; Tue, 21 Jun 2016 11:14:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24109 invoked from network); 21 Jun 2016 11:14:46 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 21 Jun 2016 11:14:46 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Tue, 21 Jun 2016 07:14:18 -0400 (EDT) Received: (qmail 22047 invoked from network); 21 Jun 2016 11:14:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 21 Jun 2016 11:14:18 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id C906C1C407A; Tue, 21 Jun 2016 04:14:10 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison] From: Mark Millard In-Reply-To: Date: Tue, 21 Jun 2016 04:14:11 -0700 Cc: otacilio.neto@bsd.com.br, freebsd-arm , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <99277FB6-77EB-4D8B-8A55-FBD622D29AC3@dsl-only.net> To: Keith White X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 11:14:15 -0000 On 2016-Jun-21, at 3:33 AM, Keith White = wrote: > On Tue, 21 Jun 2016, Mark Millard wrote: >=20 >> Otac=C3=ADlio otacilio.neto at bsd.com.br wrote on Tue Jun 21 = 00:06:39 UTC 2016 : >>=20 >>> > The kernel panic is totally reproducible. I need only do a ssh in = the >>> > beaglebone using ptty on windows or ssh on freebsd and the kernel = > panic is raised. >> . . . >>> FreeBSD11-ALPHA4 shows the same behavior. The only thing that I need = to raise the fault is ssh in the beaglebone. >>=20 >> (After this quotes are command input/output from my test activity.) >>=20 >> Under 11.0 -r310975 on a rpi2 I can ssh out of the rpi2 just fine. . = . >>=20 >>> # uname -apKU >>> FreeBSD rpi2 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #1 r301975M: Thu Jun 16 = 18:12:02 PDT 2016 = markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG arm = armv6 1100117 1100117 >>=20 >>=20 >> This is a no-debug kernel build (but with symbols). Details are given = later below. >>=20 >>> # ssh markmi@192.168.0.105 >>> Password: >>> Last login: Tue Jun 21 01:04:46 2016 >>> markmi$=20 >>=20 >> Similarly I can ssh into the rpi2 from outside, here using new remote = connection in Mac OS X terminal: ssh 192.168.0.119 resulted in. . . >>=20 >>> Password for markmi@rpi2: >>> Last login: Mon May 9 19:27:33 2016 from 192.168.2.1 >>> FreeBSD 11.0-ALPHA4 (RPI2-NODBG) #1 r301975M: Thu Jun 16 18:12:02 = PDT 2016 >>> Welcome to FreeBSD! >>> Release Notes, Errata: https://www.FreeBSD.org/releases/ >>> Security Advisories: https://www.FreeBSD.org/security/ >>> FreeBSD Handbook: https://www.FreeBSD.org/handbook/ >>> FreeBSD FAQ: https://www.FreeBSD.org/faq/ >>> Questions List: = https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/ >>> FreeBSD Forums: https://forums.FreeBSD.org/ >>> Documents installed with the system are in the = /usr/local/share/doc/freebsd/ >>> directory, or can be installed later with: pkg install = en-freebsd-doc >>> For other languages, replace "en" with a language code like de or = fr. >>> Show the version of FreeBSD installed: freebsd-version ; uname -a >>> Please include that output and any error messages when posting = questions. >>> Introduction to manual pages: man man >>> FreeBSD directory layout: man hier >>> Edit /etc/motd to change this login announcement. >>> To determine whether a file is a text file, executable, or some = other type >>> of file, use >>>=20 >>> file filename >>> -- Dru >>> $=20 >>=20 >> No panics or other odd notices. >>=20 >> The problem is apparently not general to all armv6 contexts. >>=20 >> Various context details follow. . . >>=20 >>> # more ~/src.configs/src.conf.rpi2-clang-bootstrap.rpi2-host = TO_TYPE=3Darmv6 >>> # >>> KERNCONF=3DRPI2-NODBG >>> TARGET=3Darm >>> .if ${.MAKE.LEVEL} =3D=3D 0 >>> TARGET_ARCH=3D${TO_TYPE} >>> .export TARGET_ARCH >>> .endif >>> # >>> #WITH_CROSS_COMPILER=3D >>> WITH_SYSTEM_COMPILER=3D >>> # >>> #CPUTYPE=3Dsoft >>> WITH_LIBSOFT=3D >>> WITH_LIBCPLUSPLUS=3D >>> WITH_BINUTILS_BOOTSTRAP=3D >>> #WITHOUT_CLANG_BOOTSTRAP=3D >>> WITH_CLANG=3D >>> WITH_CLANG_IS_CC=3D >>> WITH_CLANG_FULL=3D >>> WITH_CLANG_EXTRAS=3D >>> WITH_LLDB=3D >>> # >>> WITH_BOOT=3D >>> WITHOUT_LIB32=3D >>> # >>> WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D >>> WITHOUT_GCC_BOOTSTRAP=3D >>> WITHOUT_GCC=3D >>> WITHOUT_GCC_IS_CC=3D >>> WITHOUT_GNUCXX=3D >>> # >>> NO_WERROR=3D >>> #WERROR=3D >>> MALLOC_PRODUCTION=3D >>> # >>> WITH_DEBUG_FILES=3D >>> # >>> XCFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 >>> XCXXFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 >>> # There is no XCPPFLAGS but XCPP ets XCFLAGS content. >>=20 >> ~/src.configs/make.conf was empty. >>=20 >>> # more /usr/src/sys/arm/conf/RPI2-NODBG >>> # >>> # RPI2 -- Custom configuration for the Raspberry Pi 2 >>> # >>> # For more information on this file, please read the config(5) = manual page, >>> # and/or the handbook section on Kernel Configuration Files: >>> # >>> # = http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-con= fig.html >>> # >>> # The handbook is also available locally in /usr/share/doc/handbook >>> # if you've installed the doc distribution, otherwise always see the >>> # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the >>> # latest information. >>> # >>> # An exhaustive list of options and more detailed explanations of = the >>> # device lines is also present in the ../../conf/NOTES and NOTES = files. >>> # If you are in doubt as to the purpose or necessity of a line, = check first >>> # in NOTES. >>> # >>> ident RPI2-NODBG >>> include "RPI2" >>> makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols >>> options ALT_BREAK_TO_DEBUGGER >>> #options VERBOSE_SYSINIT # Enable verbose sysinit = messages >>> options KDB # Enable kernel debugger = support >>> # For minimum debugger support (stable branch) use: >>> #options KDB_TRACE # Print a stack trace for a = panic >>> options DDB # Enable the kernel debugger >>> nooptions INVARIANTS # Enable calls of extra = sanity checking >>> nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS >>> nooptions WITNESS # Enable checks to detect = deadlocks and cycles >>> nooptions WITNESS_SKIPSPIN # Don't run witness on = spinlocks for speed >>> nooptions DIAGNOSTIC >>=20 >>=20 >> My /usr/src tree has some changes/additions --but mostly for = powerpc64 and powerpc issues: >>=20 >>> # svnlite status /usr/src/ >>> M = /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp >>> M /usr/src/lib/csu/powerpc64/Makefile >>> ? /usr/src/sys/amd64/include/include >>> ? /usr/src/sys/arm/conf/RPI2-NODBG >>> ? /usr/src/sys/arm/include/include >>> M /usr/src/sys/boot/ofw/Makefile.inc >>> M /usr/src/sys/boot/powerpc/Makefile >>> M /usr/src/sys/boot/powerpc/Makefile.inc >>> M /usr/src/sys/boot/uboot/Makefile.inc >>> M /usr/src/sys/conf/Makefile.powerpc >>> M /usr/src/sys/conf/kern.mk >>> M /usr/src/sys/conf/kmod.mk >>> M /usr/src/sys/dev/cxgb/ulp/tom/cxgb_listen.c >>> M /usr/src/sys/dev/cxgbe/tom/t4_listen.c >>> ? /usr/src/sys/powerpc/conf/GENERIC64-NODBG >>> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc >>> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG >>> ? /usr/src/sys/powerpc/conf/GENERICvtsc >>> ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG >>> ? /usr/src/sys/powerpc/include/include >>> M /usr/src/sys/powerpc/ofw/ofw_machdep.c >>> M /usr/src/sys/powerpc/powerpc/exec_machdep.c >>> ? /usr/src/sys/x86/include/include >>=20 >> (The include/include ones are from something making links pointing = back up to the parent include/ . I did not explicitly create these.) >>=20 >> (The cxbg and cxbge ones were from trying to have amd64 target amd64 = via xtoolchain (devel/amd64-gcc). But other places also stopped it and I = quit trying that for now.) >>=20 >>> # more /etc/rc.conf >>> hostname=3D"rpi2" >>> ifconfig_ue0=3D"DHCP" >>> sshd_enable=3D"YES" >>> powerd_enable=3D"YES" >>> # Nice if you have a network, else annoying. >>> ntpd_enable=3D"YES" >>> ntpd_sync_on_start=3D"YES" >>> # Uncomment to disable common services (more memory) >>> #cron_enable=3D"NO" >>> #syslogd_enable=3D"NO" >>> sendmail_enable=3D"NONE" >>> sendmail_submit_enable=3D"NO" >>> sendmail_outbound_enable=3D"NO" >>> sendmail_msp_queue_enable=3D"NO" >>> # >>> # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable >>> dumpdev=3D"AUTO" >>> # >>> dbus_enable=3D"YES" >>> hald_enable=3D"YES" >>> # >>> rpcbind_enable=3D"YES" >>> nfs_server_enable=3D"YES" >>> mountd_flags=3D"-r" >>> # >>> nfs_client_enable=3D"YES" >>=20 >>> # more /etc/sysctl.conf # $FreeBSD: head/etc/sysctl.conf 112200 = 2003-03-13 18:43:50Z mux $ >>> # >>> # This file is read when going to multi-user and its contents piped = thru >>> # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for = details. >>> # >>> # Uncomment this to prevent users from seeing information about = processes that >>> # are being run under another UID. >>> #security.bsd.see_other_uids=3D0 >>> kern.nodump_coredump=3D1 >>> kern.capmode_coredump=3D1 >>> kern.sugid_coredump=3D1 >>> kern.corefile=3D/var/crash/%N.%P.core >>=20 >>=20 >> /etc/fstab , /etc/exports , /etc/resolv.conf are very simple but = non-default. Other than password files and the like the rest of /etc/. . = . is just defaults. >>=20 >>> # more /boot/loader.conf kern.cam.boot_delay=3D"10000" >>=20 >>=20 >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >=20 > I'm using an RPI-B rather than RPI2, but my symptoms are similar. >=20 > Did you use the wired or wireless interface on the RPI2? I only > get the panic on the RPI-B when using wireless. Wired works fine. My context is/was wired (ue0 --as in ifconfig_ue0=3D"DHCP"), not = wireless. > In an earlier message Ian said that he thought he knew what the > problem was... >=20 > ...keith =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Jun 21 11:59:14 2016 Return-Path: Delivered-To: freebsd-arm@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 8744FA7B4CD for ; Tue, 21 Jun 2016 11:59:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-153.reflexion.net [208.70.211.153]) (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 4B7032F58 for ; Tue, 21 Jun 2016 11:59:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 381 invoked from network); 21 Jun 2016 11:59:48 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 21 Jun 2016 11:59:48 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Tue, 21 Jun 2016 07:59:09 -0400 (EDT) Received: (qmail 23621 invoked from network); 21 Jun 2016 11:59:08 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 21 Jun 2016 11:59:08 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 0CC2F1C408D; Tue, 21 Jun 2016 04:59:09 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison] From: Mark Millard In-Reply-To: Date: Tue, 21 Jun 2016 04:59:10 -0700 Cc: freebsd-arm , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <99277FB6-77EB-4D8B-8A55-FBD622D29AC3@dsl-only.net> To: Keith White , otacilio.neto@bsd.com.br X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 11:59:14 -0000 [A top-post of a new result: WiFI works fine too. Quotes are from = input/output, with some redacting. This is the first time I've set up = WiFi on FreeBSD.] WiFI (urtwn0) also works fine for me with ssh on the rpi2 11.0 -r301975 = context. . . > urtwn0: on usbus0 > urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R > urtwn0: enabling 11n > # ifconfig . . . > wlan0: flags=3D8843 metric 0 = mtu 1500 > ether XXXX > inet 192.168.0.122 netmask 0xffffff00 broadcast 192.168.0.255=20= > groups: wlan=20 > ssid "Millard's AirPort2" channel 11 (2462 MHz 11g ht/20) = bssid XXXX > regdomain FCC country US authmode WPA2/802.11i privacy ON > deftxkey UNDEF TKIP 3:128-bit txpower 30 bmiss 7 scanvalid 60 > protmode CTS ht20 -ampdutx ampdurx ampdulimit 64k ampdudensity = 4 -stbc > wme roaming MANUAL > media: IEEE 802.11 Wireless Ethernet MCS mode 11ng > status: associated > nd6 options=3D29 An ssh markmi@192.168.0.122 into the rpi2 from Mac OS X's terminal = worked fine: > Warning: Permanently added '192.168.0.122' (ECDSA) to the list of = known hosts. > Password for markmi@rpi2: > Last login: Tue Jun 21 01:04:54 2016 from 192.168.0.105 > FreeBSD 11.0-ALPHA4 (RPI2-NODBG) #1 r301975M: Thu Jun 16 18:12:02 PDT = 2016 >=20 > Welcome to FreeBSD! >=20 > Release Notes, Errata: https://www.FreeBSD.org/releases/ > Security Advisories: https://www.FreeBSD.org/security/ > FreeBSD Handbook: https://www.FreeBSD.org/handbook/ > FreeBSD FAQ: https://www.FreeBSD.org/faq/ > Questions List: = https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/ > FreeBSD Forums: https://forums.FreeBSD.org/ >=20 > Documents installed with the system are in the = /usr/local/share/doc/freebsd/ > directory, or can be installed later with: pkg install en-freebsd-doc > For other languages, replace "en" with a language code like de or fr. >=20 > Show the version of FreeBSD installed: freebsd-version ; uname -a > Please include that output and any error messages when posting = questions. > Introduction to manual pages: man man > FreeBSD directory layout: man hier >=20 > Edit /etc/motd to change this login announcement. > You can look through a file in a nice text-based interface by typing >=20 > less filename > $=20 The problem is apparently not general to all armv6 WiFi contexts. I'll note that I did not disable or unplug the wired Ethernet. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jun-21, at 4:14 AM, Mark Millard wrote: > On 2016-Jun-21, at 3:33 AM, Keith White = wrote: >=20 >> On Tue, 21 Jun 2016, Mark Millard wrote: >>=20 >>> Otac=C3=ADlio otacilio.neto at bsd.com.br wrote on Tue Jun 21 = 00:06:39 UTC 2016 : >>>=20 >>>>> The kernel panic is totally reproducible. I need only do a ssh in = the >>>>> beaglebone using ptty on windows or ssh on freebsd and the kernel = > panic is raised. >>> . . . >>>> FreeBSD11-ALPHA4 shows the same behavior. The only thing that I = need to raise the fault is ssh in the beaglebone. >>>=20 >>> (After this quotes are command input/output from my test activity.) >>>=20 >>> Under 11.0 -r310975 on a rpi2 I can ssh out of the rpi2 just fine. . = . >>>=20 >>>> # uname -apKU >>>> FreeBSD rpi2 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #1 r301975M: Thu Jun = 16 18:12:02 PDT 2016 = markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG arm = armv6 1100117 1100117 >>>=20 >>>=20 >>> This is a no-debug kernel build (but with symbols). Details are = given later below. >>>=20 >>>> # ssh markmi@192.168.0.105 >>>> Password: >>>> Last login: Tue Jun 21 01:04:46 2016 >>>> markmi$=20 >>>=20 >>> Similarly I can ssh into the rpi2 from outside, here using new = remote connection in Mac OS X terminal: ssh 192.168.0.119 resulted in. . = . >>>=20 >>>> Password for markmi@rpi2: >>>> Last login: Mon May 9 19:27:33 2016 from 192.168.2.1 >>>> FreeBSD 11.0-ALPHA4 (RPI2-NODBG) #1 r301975M: Thu Jun 16 18:12:02 = PDT 2016 >>>> Welcome to FreeBSD! >>>> Release Notes, Errata: https://www.FreeBSD.org/releases/ >>>> Security Advisories: https://www.FreeBSD.org/security/ >>>> FreeBSD Handbook: https://www.FreeBSD.org/handbook/ >>>> FreeBSD FAQ: https://www.FreeBSD.org/faq/ >>>> Questions List: = https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/ >>>> FreeBSD Forums: https://forums.FreeBSD.org/ >>>> Documents installed with the system are in the = /usr/local/share/doc/freebsd/ >>>> directory, or can be installed later with: pkg install = en-freebsd-doc >>>> For other languages, replace "en" with a language code like de or = fr. >>>> Show the version of FreeBSD installed: freebsd-version ; uname -a >>>> Please include that output and any error messages when posting = questions. >>>> Introduction to manual pages: man man >>>> FreeBSD directory layout: man hier >>>> Edit /etc/motd to change this login announcement. >>>> To determine whether a file is a text file, executable, or some = other type >>>> of file, use >>>>=20 >>>> file filename >>>> -- Dru >>>> $=20 >>>=20 >>> No panics or other odd notices. >>>=20 >>> The problem is apparently not general to all armv6 contexts. >>>=20 >>> Various context details follow. . . >>>=20 >>>> # more ~/src.configs/src.conf.rpi2-clang-bootstrap.rpi2-host = TO_TYPE=3Darmv6 >>>> # >>>> KERNCONF=3DRPI2-NODBG >>>> TARGET=3Darm >>>> .if ${.MAKE.LEVEL} =3D=3D 0 >>>> TARGET_ARCH=3D${TO_TYPE} >>>> .export TARGET_ARCH >>>> .endif >>>> # >>>> #WITH_CROSS_COMPILER=3D >>>> WITH_SYSTEM_COMPILER=3D >>>> # >>>> #CPUTYPE=3Dsoft >>>> WITH_LIBSOFT=3D >>>> WITH_LIBCPLUSPLUS=3D >>>> WITH_BINUTILS_BOOTSTRAP=3D >>>> #WITHOUT_CLANG_BOOTSTRAP=3D >>>> WITH_CLANG=3D >>>> WITH_CLANG_IS_CC=3D >>>> WITH_CLANG_FULL=3D >>>> WITH_CLANG_EXTRAS=3D >>>> WITH_LLDB=3D >>>> # >>>> WITH_BOOT=3D >>>> WITHOUT_LIB32=3D >>>> # >>>> WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D >>>> WITHOUT_GCC_BOOTSTRAP=3D >>>> WITHOUT_GCC=3D >>>> WITHOUT_GCC_IS_CC=3D >>>> WITHOUT_GNUCXX=3D >>>> # >>>> NO_WERROR=3D >>>> #WERROR=3D >>>> MALLOC_PRODUCTION=3D >>>> # >>>> WITH_DEBUG_FILES=3D >>>> # >>>> XCFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 >>>> XCXXFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 >>>> # There is no XCPPFLAGS but XCPP ets XCFLAGS content. >>>=20 >>> ~/src.configs/make.conf was empty. >>>=20 >>>> # more /usr/src/sys/arm/conf/RPI2-NODBG >>>> # >>>> # RPI2 -- Custom configuration for the Raspberry Pi 2 >>>> # >>>> # For more information on this file, please read the config(5) = manual page, >>>> # and/or the handbook section on Kernel Configuration Files: >>>> # >>>> # = http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-con= fig.html >>>> # >>>> # The handbook is also available locally in /usr/share/doc/handbook >>>> # if you've installed the doc distribution, otherwise always see = the >>>> # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the >>>> # latest information. >>>> # >>>> # An exhaustive list of options and more detailed explanations of = the >>>> # device lines is also present in the ../../conf/NOTES and NOTES = files. >>>> # If you are in doubt as to the purpose or necessity of a line, = check first >>>> # in NOTES. >>>> # >>>> ident RPI2-NODBG >>>> include "RPI2" >>>> makeoptions DEBUG=3D-g # Build kernel with = gdb(1) debug symbols >>>> options ALT_BREAK_TO_DEBUGGER >>>> #options VERBOSE_SYSINIT # Enable verbose sysinit = messages >>>> options KDB # Enable kernel debugger = support >>>> # For minimum debugger support (stable branch) use: >>>> #options KDB_TRACE # Print a stack trace for a = panic >>>> options DDB # Enable the kernel = debugger >>>> nooptions INVARIANTS # Enable calls of extra = sanity checking >>>> nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS >>>> nooptions WITNESS # Enable checks to detect = deadlocks and cycles >>>> nooptions WITNESS_SKIPSPIN # Don't run witness on = spinlocks for speed >>>> nooptions DIAGNOSTIC >>>=20 >>>=20 >>> My /usr/src tree has some changes/additions --but mostly for = powerpc64 and powerpc issues: >>>=20 >>>> # svnlite status /usr/src/ >>>> M = /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp >>>> M /usr/src/lib/csu/powerpc64/Makefile >>>> ? /usr/src/sys/amd64/include/include >>>> ? /usr/src/sys/arm/conf/RPI2-NODBG >>>> ? /usr/src/sys/arm/include/include >>>> M /usr/src/sys/boot/ofw/Makefile.inc >>>> M /usr/src/sys/boot/powerpc/Makefile >>>> M /usr/src/sys/boot/powerpc/Makefile.inc >>>> M /usr/src/sys/boot/uboot/Makefile.inc >>>> M /usr/src/sys/conf/Makefile.powerpc >>>> M /usr/src/sys/conf/kern.mk >>>> M /usr/src/sys/conf/kmod.mk >>>> M /usr/src/sys/dev/cxgb/ulp/tom/cxgb_listen.c >>>> M /usr/src/sys/dev/cxgbe/tom/t4_listen.c >>>> ? /usr/src/sys/powerpc/conf/GENERIC64-NODBG >>>> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc >>>> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG >>>> ? /usr/src/sys/powerpc/conf/GENERICvtsc >>>> ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG >>>> ? /usr/src/sys/powerpc/include/include >>>> M /usr/src/sys/powerpc/ofw/ofw_machdep.c >>>> M /usr/src/sys/powerpc/powerpc/exec_machdep.c >>>> ? /usr/src/sys/x86/include/include >>>=20 >>> (The include/include ones are from something making links pointing = back up to the parent include/ . I did not explicitly create these.) >>>=20 >>> (The cxbg and cxbge ones were from trying to have amd64 target amd64 = via xtoolchain (devel/amd64-gcc). But other places also stopped it and I = quit trying that for now.) >>>=20 >>>> # more /etc/rc.conf >>>> hostname=3D"rpi2" >>>> ifconfig_ue0=3D"DHCP" >>>> sshd_enable=3D"YES" >>>> powerd_enable=3D"YES" >>>> # Nice if you have a network, else annoying. >>>> ntpd_enable=3D"YES" >>>> ntpd_sync_on_start=3D"YES" >>>> # Uncomment to disable common services (more memory) >>>> #cron_enable=3D"NO" >>>> #syslogd_enable=3D"NO" >>>> sendmail_enable=3D"NONE" >>>> sendmail_submit_enable=3D"NO" >>>> sendmail_outbound_enable=3D"NO" >>>> sendmail_msp_queue_enable=3D"NO" >>>> # >>>> # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable >>>> dumpdev=3D"AUTO" >>>> # >>>> dbus_enable=3D"YES" >>>> hald_enable=3D"YES" >>>> # >>>> rpcbind_enable=3D"YES" >>>> nfs_server_enable=3D"YES" >>>> mountd_flags=3D"-r" >>>> # >>>> nfs_client_enable=3D"YES" >>>=20 >>>> # more /etc/sysctl.conf # $FreeBSD: head/etc/sysctl.conf 112200 = 2003-03-13 18:43:50Z mux $ >>>> # >>>> # This file is read when going to multi-user and its contents = piped thru >>>> # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for = details. >>>> # >>>> # Uncomment this to prevent users from seeing information about = processes that >>>> # are being run under another UID. >>>> #security.bsd.see_other_uids=3D0 >>>> kern.nodump_coredump=3D1 >>>> kern.capmode_coredump=3D1 >>>> kern.sugid_coredump=3D1 >>>> kern.corefile=3D/var/crash/%N.%P.core >>>=20 >>>=20 >>> /etc/fstab , /etc/exports , /etc/resolv.conf are very simple but = non-default. Other than password files and the like the rest of /etc/. . = . is just defaults. >>>=20 >>>> # more /boot/loader.conf kern.cam.boot_delay=3D"10000" >>>=20 >>>=20 >>>=20 >>>=20 >>> =3D=3D=3D >>> Mark Millard >>> markmi at dsl-only.net >>>=20 >>> _______________________________________________ >>> freebsd-arm@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >>> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >>=20 >> I'm using an RPI-B rather than RPI2, but my symptoms are similar. >>=20 >> Did you use the wired or wireless interface on the RPI2? I only >> get the panic on the RPI-B when using wireless. Wired works fine. >=20 > My context is/was wired (ue0 --as in ifconfig_ue0=3D"DHCP"), not = wireless. >=20 >> In an earlier message Ian said that he thought he knew what the >> problem was... >>=20 >> ...keith >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Jun 21 15:47:22 2016 Return-Path: Delivered-To: freebsd-arm@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 87A6FAC53C4 for ; Tue, 21 Jun 2016 15:47:22 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3FD722DEE; Tue, 21 Jun 2016 15:47:21 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id u5LFlIpH004430 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Jun 2016 08:47:19 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id u5LFlIlm004429; Tue, 21 Jun 2016 08:47:18 -0700 (PDT) (envelope-from fbsd) Date: Tue, 21 Jun 2016 08:47:17 -0700 From: bob prohaska To: Ian Lepore Cc: Hal Murray , freebsd-arm@freebsd.org Subject: Re: pl2303 lockups on rpi2 Message-ID: <20160621154717.GB2449@www.zefox.net> References: <20160618025517.GA38492@www.zefox.net> <20160618043430.28E93406057@ip-64-139-1-69.sjc.megapath.net> <20160619003651.GB38492@www.zefox.net> <1466441995.34556.44.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1466441995.34556.44.camel@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 15:47:22 -0000 On Mon, Jun 20, 2016 at 10:59:55AM -0600, Ian Lepore wrote: > > While I've heard more good things than bad about freebsd's support of > pl2303, the one I can personally vouch for is FTDI. We use them > extensively at $work, which means basically I get paid to maintain the > freebsd driver for them. > Occasionally connection attempts produce a flood of question marks which does not seem to end (I've let it run several minutes). Makes me wonder if there's some sort of wiring issue: root@ns2:/home/bob # stty -f /dev/cuaU0 speed 9600 baud; lflags: echoe echoke echoctl oflags: tab0 cflags: cs8 -parenb clocal root@ns2:/home/bob # stty -f /dev/cuaU0 sane root@ns2:/home/bob # cu -l cuaU0 -s 115200 Connected ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? In this case simply trying again brought up a login prompt. Trouble is, there has been no sign of garbled characters, which I always took to be the signature of something wrong on the serial side of things. Each Pi in the quartet has its own isolated power supply, but all Pis share ground through the network wiring. There's never been a hiccup on the network, however. Next time one of the pl2303s locks up I'll repeat the serial disconnect to see if that unsticks it without intervention on the USB side. If it does maybe this is a wiring or other hardware issue, not software. Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Tue Jun 21 17:33:23 2016 Return-Path: Delivered-To: freebsd-arm@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 D3B45AC5236; Tue, 21 Jun 2016 17:33:23 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AB2F62EF9; Tue, 21 Jun 2016 17:33:23 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from mather.chumby.lan (c-71-63-91-41.hsd1.va.comcast.net [71.63.91.41]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 7DA625C0; Tue, 21 Jun 2016 13:33:21 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: BBB (cpsw(4)) seems to be broken in the latest 11-current From: Paul Mather In-Reply-To: Date: Tue, 21 Jun 2016 13:33:20 -0400 Cc: Luiz Otavio O Souza , "freebsd-arm@freebsd.org" , FreeBSD Current , Maxim Sobolev Content-Transfer-Encoding: quoted-printable Message-Id: References: <83A18C0E-FA89-4009-A8D5-3185FB27A688@netgate.com> To: Keith White X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 17:33:23 -0000 On Jun 20, 2016, at 6:33 PM, Keith White wrote: > On Mon, 20 Jun 2016, Luiz Otavio O Souza wrote: >=20 >> On Sun, Jun 19, 2016 at 1:11 AM, Maxim Sobolev wrote: >>> Jim, some update from here. Running r283287 of the driver, I still = see the >>> same "watchdog timeout" messages, but they do not lead to the = interface >>> lockout. The traffic resumes momentarily. Which is probably why I = never paid >>> much attention to those warnings before. Therefore, I suspect that = the new >>> MAC code does not deal with watchdog-triggered interface reset as = good as >>> the old code. Does it give you any ideas about what could be wrong = there by >>> any chance? >>=20 >>=20 >> Hi Maxim, >>=20 >> My recent changes contributed somehow to expose the bug more = frequently. >>=20 >> There was a condition in tx packet reclamation where we aren't >> restarting the tx queue in one of the possible stall conditions. >>=20 >> Please try the attached patch and let me know if it works for you. >>=20 >> Luiz >=20 > Your patch fixes the problem for me. Thanks! >=20 > FreeBSD beaglebone 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #0 r302028M: Mon = Jun 20 18:19:55 EDT 2016 = kwhite@freebsd11:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE-LOCAL arm = armv6 >=20 > ...keith The patch also fixes the problem for me. FreeBSD beaglebone 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #2 r302030M: Tue Jun = 21 10:20:59 EDT 2016 = pmather@beaglebone:/usr/obj/usr/src/sys/BEAGLEBONE-NO_WITNESS arm Cheers, Paul. From owner-freebsd-arm@freebsd.org Tue Jun 21 17:55:28 2016 Return-Path: Delivered-To: freebsd-arm@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 BB070AC586F for ; Tue, 21 Jun 2016 17:55:28 +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 28E061D80 for ; Tue, 21 Jun 2016 17:55:27 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 57a4a319-37d9-11e6-ac92-3142cfe117f2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.eu.mailhop.org (Halon Mail Gateway) with ESMTPSA; Tue, 21 Jun 2016 17:55:29 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u5LHtJCB006416; Tue, 21 Jun 2016 11:55:19 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1466531719.34556.72.camel@freebsd.org> Subject: Re: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison] From: Ian Lepore To: =?ISO-8859-1?Q?Otac=EDlio?= , Keith White , Mark Millard Cc: freebsd-arm , FreeBSD Current Date: Tue, 21 Jun 2016 11:55:19 -0600 In-Reply-To: <22fe5f7f-6153-e092-c410-eddb1431a78a@bsd.com.br> References: <99277FB6-77EB-4D8B-8A55-FBD622D29AC3@dsl-only.net> <22fe5f7f-6153-e092-c410-eddb1431a78a@bsd.com.br> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 17:55:28 -0000 On Tue, 2016-06-21 at 08:11 -0300, Otacílio wrote: > Em 21/06/2016 07:33, Keith White escreveu: > > In an earlier message Ian said that he thought he knew what the > > problem was... > > Here the problem occurs when using wifi. I do not have tested wired > because I don't have a cable here. > > > []'s > > -Otacilio The wifi alignment fault should be fixed as of r302064. Sorry it took so long. -- Ian From owner-freebsd-arm@freebsd.org Tue Jun 21 19:40:22 2016 Return-Path: Delivered-To: freebsd-arm@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 961F0AC510A; Tue, 21 Jun 2016 19:40:22 +0000 (UTC) (envelope-from s3erios@gmail.com) Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::244]) (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 257701B0F; Tue, 21 Jun 2016 19:40:22 +0000 (UTC) (envelope-from s3erios@gmail.com) Received: by mail-lf0-x244.google.com with SMTP id l188so6393624lfe.0; Tue, 21 Jun 2016 12:40:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:subject:references:date:cc:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; bh=cVULiHQELlYe2FDJgKE9j4/FK8sugD/AgNvOwh3Ktm0=; b=KKXxSBee2nMCiSiF5TLWvW9bv+vzNzO9m9zRFiHvXHqZn9pD72LdHqlL1x0ktyVn4V y8xrY/mJJ4pb5tXYEckBoK79HthhYt3CeY+aQ1b3SPuWIQU0tUE2F5rxJISSjq7Js0Q2 +tejR1/XVgP9Dvh3NX/WTt7pbZ40wqlxRy3E624BPzNwytG495xUSOp50eOzMUntTwXJ hBB0yddYF6DD4j8DwjRziDYamcbAmbqDU9fhkkQOclOz16f3kTZeudadKD7I6eTPxyCW VGF2HKEAaTE/gd+dV8RbN8vaUrweM6Riigo0DHrQ3qH4/LM3FGB6j2iwCEBvYEb/aC7a h4BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:subject:references:date:cc:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; bh=cVULiHQELlYe2FDJgKE9j4/FK8sugD/AgNvOwh3Ktm0=; b=XWdHR2h+PHSRF6can+S3hbTS9ItReNmv/rK45xdMMRGkaGEH9loe2NORKwgjOkZ+9q X49tps+JU+FtCS/cH49CgMB22U4BSJOpCL6QJ7PSgGERYqvKp2ujluavraLCxozDAm0z qHLZkswa8xK25i402TeLYZN4npnQ6ItL9v/LknWHJPf8+ePwflkFk9I7tAuuk3szOQD9 Bbe9cExNzs0JogZT6jm01P7YVmr9OgiIaegIjLo3g/l8fumfNWo89Cg1cAQ5jTKnNpSu cT9Yp/0jroC6Ee/+bIySkykwci5/7/CnEnVP0cbF7L8LHYOeQkcJSlpf4GJed37JM10V DSFQ== X-Gm-Message-State: ALyK8tL32jqK9wlcwvsPE4uun/Pbcw8bCgjlK/uf6KLnXGmmPGlA5SB3faMA+UPpo0uuug== X-Received: by 10.25.149.13 with SMTP id x13mr7639126lfd.199.1466538020238; Tue, 21 Jun 2016 12:40:20 -0700 (PDT) Received: from localhost (host-176-37-109-22.la.net.ua. [176.37.109.22]) by smtp.gmail.com with ESMTPSA id 42sm2997952lfw.42.2016.06.21.12.40.18 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 21 Jun 2016 12:40:19 -0700 (PDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: =?utf-8?Q?Otac=C3=ADlio?= Subject: Re: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held References: <5e322d5a-8c42-8e69-f3c4-e607d40e8724@bsd.com.br> <1a55f000-eff9-31db-f420-e00278c4c054@bsd.com.br> Date: Tue, 21 Jun 2016 22:40:16 +0300 Cc: "freebsd-arm@freebsd.org" , freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Andriy Voskoboinyk" Message-ID: In-Reply-To: <1a55f000-eff9-31db-f420-e00278c4c054@bsd.com.br> User-Agent: Opera Mail/12.16 (FreeBSD) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 19:40:22 -0000 Tue, 21 Jun 2016 03:06:15 +0300 =D0=B1=D1=83=D0=BB=D0=BE =D0=BD=D0=B0=D0= =BF=D0=B8=D1=81=D0=B0=D0=BD=D0=BE Otac=C3=ADlio = : Should be fixed in r302064. > Em 19/06/2016 18:47, Otac=C3=ADlio escreveu: >> Em 19/06/2016 18:40, Otac=C3=ADlio escreveu: >>> I was installing netperf on a fresh FreeBSD-ALPHA3 >>> >>> FreeBSD beaglebone 11.0-ALPHA3 FreeBSD 11.0-ALPHA3 #0 r301846: Mon J= un = >>> 13 19:54:27 BRT 2016 = >>> ota@nostromo:/root/crochet/work/obj/arm.armv6/usr/src/sys/BEAGLEBONE= -DEBUG = >>> arm >>> >>> on BeagleboneBlack using wrtwn when I got this kernel panic: >>> >>> root@beaglebone:/usr/home/ota # pkg install netperf >>> Updating FreeBSD repository catalogue... >>> Fetching meta.txz: 100% 944 B 0.9kB/s 00:01 >>> Fetching packagesite.txz: 100% 4 MiB 46.0kB/s 01:42 >>> Processing entries: 6%lock order reversal: >>> 1st 0xc30b35d4 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2048 >>> 2nd 0xc319d6f4 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2498 >>> stack backtrace: >>> Processing entries: 58%Kernel page fault with the following = >>> non-sleepable locks held: >>> exclusive sleep mutex tcp_sc_head (tcp_sc_head) r =3D 0 (0xc2f9d520)= = >>> locked @ /usr/src/sys/netinet/tcp_syncache.c:494 >>> shared rw tcp (tcp) r =3D 0 (0xc08ef348) locked @ = >>> /usr/src/sys/netinet/tcp_input.c:1034 >>> exclusive rw tcpinp (tcpinp) r =3D 0 (0xc31ab494) locked @ = >>> /usr/src/sys/netinet/in_pcb.c:1964 >>> stack backtrace: >>> Fatal kernel mode data abort: 'Alignment Fault' on read >>> trapframe: 0xdcfe58a8 >>> FSR=3D00000001, FAR=3Dc2e7187a, spsr=3D60000013 >>> r0 =3Dc08e7988, r1 =3D00000004, r2 =3Dc06fa3ad, r3 =3D000007b6 >>> r4 =3Ddcfe5a10, r5 =3Ddcfe5b28, r6 =3Dc2e71876, r7 =3Dc2f9d520 >>> r8 =3Dc2f9d520, r9 =3Dc2e71876, r10=3Ddcfe5b28, r11=3Ddcfe5970 >>> r12=3D00000000, ssp=3Ddcfe5938, slr=3Dc2d34370, pc =3Dc053d8e8 >>> >>> [ thread pid 13 tid 100036 ] >>> Stopped at syncookie_lookup+0x38: ldmib r6, {r1-r2} >>> db> >>> >>> >>> []'s >>> >>> -Otac=C3=ADlio >>> >> The kernel panic is totally reproducible. I need only do a ssh in the= = >> beaglebone using ptty on windows or ssh on freebsd and the kernel pan= ic = >> is raised. >> >> FreeBSD/arm (beaglebone) (ttyu0) >> >> login: Kernel page fault with the following non-sleepable locks held:= >> exclusive sleep mutex tcp_sc_head (tcp_sc_head) r =3D 0 (0xc2f95480) = = >> locked @ /usr/src/sys/netinet/tcp_syncache.c:494 >> shared rw tcp (tcp) r =3D 0 (0xc08ef348) locked @ = >> /usr/src/sys/netinet/tcp_input.c:1034 >> exclusive rw tcpinp (tcpinp) r =3D 0 (0xc341e494) locked @ = >> /usr/src/sys/netinet/in_pcb.c:1964 >> stack backtrace: >> Fatal kernel mode data abort: 'Alignment Fault' on read >> trapframe: 0xdcfe58a8 >> FSR=3D00000001, FAR=3Dc2e7807a, spsr=3D60000013 >> r0 =3Dc08e7988, r1 =3D00000004, r2 =3Dc06fa3ad, r3 =3D000007b6 >> r4 =3Ddcfe5a10, r5 =3Ddcfe5b28, r6 =3Dc2e78076, r7 =3Dc2f95480 >> r8 =3Dc2f95480, r9 =3Dc2e78076, r10=3Ddcfe5b28, r11=3Ddcfe5970 >> r12=3D00000000, ssp=3Ddcfe5938, slr=3Dc2d34370, pc =3Dc053d8e8 >> >> [ thread pid 13 tid 100036 ] >> Stopped at syncookie_lookup+0x38: ldmib r6, {r1-r2} >> db> >> > FreeBSD11-ALPHA4 shows the same behavior. The only thing that I need t= o = > raise the fault is ssh in the beaglebone. > > > root@beaglebone:~ # uname -a > FreeBSD beaglebone 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #0 r301975: Fri Jun= = > 17 13:32:55 UTC 2016 = > root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE= = > arm > root@beaglebone:~ # Kernel page fault with the following non-sleepable= = > locks held: > exclusive sleep mutex tcp_sc_head (tcp_sc_head) r =3D 0 (0xc2f98740) = > locked @ /usr/src/sys/netinet/tcp_syncache.c:494 > shared rw tcp (tcp) r =3D 0 (0xc08ef348) locked @ = > /usr/src/sys/netinet/tcp_input.c:1034 > exclusive rw tcpinp (tcpinp) r =3D 0 (0xc33e4494) locked @ = > /usr/src/sys/netinet/in_pcb.c:1964 > stack backtrace: > Fatal kernel mode data abort: 'Alignment Fault' on read > trapframe: 0xdcfe58c0 > FSR=3D00000001, FAR=3Dc2e7a07a, spsr=3D60000013 > r0 =3Dc08e7988, r1 =3D00000004, r2 =3Dc06fabe6, r3 =3D000007b6 > r4 =3Ddcfe5a28, r5 =3Ddcfe5b40, r6 =3Dc2e7a076, r7 =3Dc2f98740 > r8 =3Dc2f98740, r9 =3Dc2e7a076, r10=3Ddcfe5b40, r11=3Ddcfe5988 > r12=3D00000000, ssp=3Ddcfe5950, slr=3Dc2d33370, pc =3Dc053df7c > > [ thread pid 13 tid 100036 ] > Stopped at syncookie_lookup+0x38: ldmib r6, {r1-r2} > db> > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = > "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Tue Jun 21 22:11:23 2016 Return-Path: Delivered-To: freebsd-arm@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 54413AC571C for ; Tue, 21 Jun 2016 22:11:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (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 EB5DD2B29 for ; Tue, 21 Jun 2016 22:11:22 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 16239 invoked from network); 21 Jun 2016 22:11:56 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 21 Jun 2016 22:11:56 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Tue, 21 Jun 2016 18:11:25 -0400 (EDT) Received: (qmail 3426 invoked from network); 21 Jun 2016 22:11:25 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 21 Jun 2016 22:11:25 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 904D51C4079; Tue, 21 Jun 2016 15:11:15 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: WITH_SYSTEM_COMPILER default on Date: Tue, 21 Jun 2016 15:11:18 -0700 Message-Id: <39C98FFD-B0BB-4F25-A1D1-2447A2FDDFBD@dsl-only.net> Cc: freebsd-arm , FreeBSD PowerPC ML To: Bryan Drewery , FreeBSD Current Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 22:11:23 -0000 Bryan Drewery bdrewery at FreeBSD.org wrote on Tue Jun 21 19:03:46 UTC = 2016 : > This feature is where the bootstrap compiler in buildworld is not = built > if the one in /usr/bin/cc matches what would be built. It is very > conservative and requires a complete match of major/minor version and > the compiler revision (__FreeBSD_cc_version). >=20 > The only complaint so far about this feature was that when we bumped = the > compiler revision, too much of clang would rebuild. That was = addressed > in r301277. >=20 > I would like to enable this feature by default in head for 11.0. >=20 > Unless there are any objections I will do so in a few days. >=20 > --=20 > Regards, > Bryan Drewery I've only been using WITH_SYSTEM_COMPILER=3D for system-clang based = builds with the host matching TARGET_ARCH ("self hosted"). For xtoolchain use (self-hosted or not) I've been using in my src.conf = files for such contexts:=20 WITHOUT_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITHOUT_CLANG_BOOTSTRAP=3D For cross builds (all being amd64 -> something else, such as armv6, = powerpc64, or powerpc) based on using some build of the system clang = 3.8.0 I've been using: WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D As I understand the history the paths for finding tools, headers, etc. = built into the clang cross compiler were not necessarily the same as for = the live the system compiler that has paths appropriate specifically to = self-hosting. This helped avoid getting the wrong versions of files = involved. This was true despite the normal clang code generation being able to = target other architectures. As for self-hosted system-clang based builds I've been using: #WITH_CROSS_COMPILER=3D WITH_SYSTEM_COMPILER=3D WITH_BINUTILS_BOOTSTRAP=3D #WITH_CLANG_BOOTSTRAP=3D (So in this case I've left some things implicit in operation.) As stands I'll not notice the SYSTEM_COMPILER default's consequences = because I'm always explicit about WITH vs. WITHOUT for SYSTM_COMPILER. = If you want some sort of experiment(s), let me know. But I only currently have an amd64 context and a rpi2 armv6 context. The = dual-proessor, each dual-core powerpc64 was much faster at self-hosted = xtoolchain builds compared to any self-hosted rpi2 build but I do not = have access to the powerpc family for now. Self-hosted amd64 xtoolchain = builds do not work yet for normal settings: duplicate declarations tend = to stop the builds if one leaves on the warnings-as-errors status for = buildkernel. (At least last that I tried such.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Jun 21 22:30:52 2016 Return-Path: Delivered-To: freebsd-arm@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 59E4BAC5C0D for ; Tue, 21 Jun 2016 22:30:52 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-153.reflexion.net [208.70.211.153]) (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 0DD711733 for ; Tue, 21 Jun 2016 22:30:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1768 invoked from network); 21 Jun 2016 22:30:45 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 21 Jun 2016 22:30:45 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Tue, 21 Jun 2016 18:31:34 -0400 (EDT) Received: (qmail 14603 invoked from network); 21 Jun 2016 22:31:34 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 21 Jun 2016 22:31:34 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 0FE761C408D; Tue, 21 Jun 2016 15:30:45 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison] Date: Tue, 21 Jun 2016 15:30:47 -0700 Message-Id: Cc: FreeBSD Toolchain To: Ian Lepore , freebsd-arm , FreeBSD Current Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 22:30:52 -0000 Ian Lepore ian at freebsd.org wrote on Tue Jun 21 17:55:28 UTC 2016 : > On Tue, 2016-06-21 at 08:11 -0300, Otac=C3=ADlio wrote: > > Em 21/06/2016 07:33, Keith White escreveu: > > > In an earlier message Ian said that he thought he knew what the > > > problem was...=20 > >=20 > > Here the problem occurs when using wifi. I do not have tested wired=20= > > because I don't have a cable here. > >=20 > >=20 > > []'s > >=20 > > -Otacilio >=20 > The wifi alignment fault should be fixed as of r302064. Sorry it took > so long. >=20 > -- Ian >=20 FYI: I've not had any -r301975 problems with WiFi on my rpi2. But I cross build for TARGET_ARCH=3Darmv6 with: > XCFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 > XCXXFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 (And similarly for self-hosted.) It may be that the -march and/or -mcpu = matter to the code generation and explain my lack of problems. The builds also have INVARIANTS and WITNESS off. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Jun 21 22:35:35 2016 Return-Path: Delivered-To: freebsd-arm@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 AA653AC5E08 for ; Tue, 21 Jun 2016 22:35:35 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 59FD71B66 for ; Tue, 21 Jun 2016 22:35:35 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id u5LMZWi1005265 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Jun 2016 15:35:33 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id u5LMZVNb005264; Tue, 21 Jun 2016 15:35:31 -0700 (PDT) (envelope-from fbsd) Date: Tue, 21 Jun 2016 15:35:31 -0700 From: bob prohaska To: James Elstone Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: pl2303 lockups on rpi2 Message-ID: <20160621223531.GC2449@www.zefox.net> References: <20160619020311.GC38492@www.zefox.net> <20160619034248.1D097406057@ip-64-139-1-69.sjc.megapath.net> <20160621041439.GA2449@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 22:35:35 -0000 On Tue, Jun 21, 2016 at 10:34:41PM +0100, James Elstone wrote: > Hi Bob, > > What sort of flow control (rts/cts, xon/xoff, or none)? > > I suspect you cleared the control signals rather than unfreeze?? There are none to clear: The serial end is on an RPI2, with only TX, RX and ground. The USB end is on a second RPI2. In that particular case, I tried unplugging and replugging the USB end, to no avail. Then I dragged over an iMac with Prolific's drivers installed and plugged the USB end into the iMac. The PL2303 still wasn't recognized. While it was still plugged into the iMac, I lifted the TX, RX and ground connections on the PL2303 cable. The PL2303 recognition message immediately showed up on the iMac's console. As it happens, the two RPI2s in question share a ground through the wired Ethernet. They're connected to two different switches, which are in turn connected by a length of cable. The ground cable on the PL2303 forms a second, parallel ground, amounting to a loop. This is universally considered bad practice but is often gotten away with. Perhaps I'm not so lucky. The Prolific driver installation instructions specify installing the software, connecting the USB end next and connecting the serial end last. I thought they were just pacifying the pedantic among us, but maybe there's a physical reason behind the advice. Next time a PL2303 locks up I'll begin by lifting the serial cable connections, ground first, to see what the uplcom driver does. If it subsequently recognizes the PL2303 I _think_ that supports the notion of a wiring problem. Thanks for reading and special thanks to Hal Murray for introducing the idea of serial devices being "held" by signaling voltages, bob prohaska > Kr, > > James > > P.s. Would you know the state of support with a RP3? > On 21 Jun 2016 05:14, "bob prohaska" wrote: > > > On Sat, Jun 18, 2016 at 08:42:48PM -0700, Hal Murray wrote: > > > > > > > > > The Linux geeks have figured out how to use the "console" as a serial > > port. > > > It's used by the GPS HATs. If you are trying to get work done rather > > than > > > debug USB stuff, that might be an interesting approach. You would need a > > > level shifter if you are talking to a real RS232 device. > > > > > The goal is simply to let one Pi monitor the console of another, thus > > making > > single user mode accessible over a network. > > > > After a recent lockup on the usb-serial adapter, I was very surprised to > > find > > the pl2303ta "came unstuck" when the serial cable connecting to the > > console port on the > > next Pi in the chain was disconnected. No need to unplug the USB side. > > > > Thanks for reading, > > > > bob prohaska > > > > > > > > > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > From owner-freebsd-arm@freebsd.org Tue Jun 21 22:45:20 2016 Return-Path: Delivered-To: freebsd-arm@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 1A5E9AC4033; Tue, 21 Jun 2016 22:45:20 +0000 (UTC) (envelope-from kwhite@site.uottawa.ca) Received: from courriel.site.uottawa.ca (eecsmail.engineering.uottawa.ca [137.122.24.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "courriel.site.uottawa.ca", Issuer "DigiCert SHA2 Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CD0051EA6; Tue, 21 Jun 2016 22:45:18 +0000 (UTC) (envelope-from kwhite@site.uottawa.ca) Received: from [10.0.2.15] (ppp-66-186-88-176.vianet.ca [66.186.88.176]) (authenticated bits=0) by courriel.site.uottawa.ca (8.14.5/8.14.5) with ESMTP id u5LMj8fj081847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Jun 2016 18:45:09 -0400 (EDT) (envelope-from kwhite@site.uottawa.ca) Date: Tue, 21 Jun 2016 18:45:07 -0400 (EDT) From: Keith White X-X-Sender: kwhite@localhost.my.domain To: Ian Lepore cc: =?ISO-8859-15?Q?Otac=EDlio?= , Mark Millard , freebsd-arm , FreeBSD Current Subject: Re: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison] In-Reply-To: <1466531719.34556.72.camel@freebsd.org> Message-ID: References: <99277FB6-77EB-4D8B-8A55-FBD622D29AC3@dsl-only.net> <22fe5f7f-6153-e092-c410-eddb1431a78a@bsd.com.br> <1466531719.34556.72.camel@freebsd.org> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 22:45:20 -0000 On Tue, 21 Jun 2016, Ian Lepore wrote: > On Tue, 2016-06-21 at 08:11 -0300, Otacílio wrote: >> Em 21/06/2016 07:33, Keith White escreveu: >>> In an earlier message Ian said that he thought he knew what the >>> problem was... >> >> Here the problem occurs when using wifi. I do not have tested wired >> because I don't have a cable here. >> >> >> []'s >> >> -Otacilio > > The wifi alignment fault should be fixed as of r302064. Sorry it took > so long. > > -- Ian Many thanks Ian! Yes, this has fixed the problem. No more panics on ssh to rpi-b. ...keith From owner-freebsd-arm@freebsd.org Tue Jun 21 23:13:59 2016 Return-Path: Delivered-To: freebsd-arm@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 4951BAC4752 for ; Tue, 21 Jun 2016 23:13:59 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 0FBB42C2E for ; Tue, 21 Jun 2016 23:13:58 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: e0ae30ae-3805-11e6-a0ff-e511cd071b9b X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Tue, 21 Jun 2016 23:14:17 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u5LNDoxg006862; Tue, 21 Jun 2016 17:13:50 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1466550830.34556.73.camel@freebsd.org> Subject: Re: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison] From: Ian Lepore To: Mark Millard , freebsd-arm , FreeBSD Current Cc: FreeBSD Toolchain Date: Tue, 21 Jun 2016 17:13:50 -0600 In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 23:13:59 -0000 On Tue, 2016-06-21 at 15:30 -0700, Mark Millard wrote: > Ian Lepore ian at freebsd.org wrote on Tue Jun 21 17:55:28 UTC 2016 > : > > > On Tue, 2016-06-21 at 08:11 -0300, Otacílio wrote: > > > Em 21/06/2016 07:33, Keith White escreveu: > > > > In an earlier message Ian said that he thought he knew what the > > > > problem was... > > > > > > Here the problem occurs when using wifi. I do not have tested > > > wired > > > because I don't have a cable here. > > > > > > > > > []'s > > > > > > -Otacilio > > > > The wifi alignment fault should be fixed as of r302064. Sorry it > > took > > so long. > > > > -- Ian > > > > FYI: I've not had any -r301975 problems with WiFi on my rpi2. > > But I cross build for TARGET_ARCH=armv6 with: > > > XCFLAGS+= -march=armv7-a -mcpu=cortex-a7 > > XCXXFLAGS+= -march=armv7-a -mcpu=cortex-a7 > > (And similarly for self-hosted.) It may be that the -march and/or > -mcpu matter to the code generation and explain my lack of problems. > > The builds also have INVARIANTS and WITNESS off. > > === > Mark Millard > markmi at dsl-only.net INVARIANTS being on was one of the things required to trigger the alignment fault. -- Ian From owner-freebsd-arm@freebsd.org Tue Jun 21 23:20:01 2016 Return-Path: Delivered-To: freebsd-arm@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 CDB30AC48D2 for ; Tue, 21 Jun 2016 23:20:01 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 A35002E56 for ; Tue, 21 Jun 2016 23:20:01 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: bb0202f3-3806-11e6-8929-8ded99d5e9d7 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Tue, 21 Jun 2016 23:20:23 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u5LNJrX1006873; Tue, 21 Jun 2016 17:19:53 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1466551193.34556.76.camel@freebsd.org> Subject: Re: pl2303 lockups on rpi2 From: Ian Lepore To: bob prohaska , James Elstone Cc: freebsd-arm@freebsd.org Date: Tue, 21 Jun 2016 17:19:53 -0600 In-Reply-To: <20160621223531.GC2449@www.zefox.net> References: <20160619020311.GC38492@www.zefox.net> <20160619034248.1D097406057@ip-64-139-1-69.sjc.megapath.net> <20160621041439.GA2449@www.zefox.net> <20160621223531.GC2449@www.zefox.net> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 23:20:01 -0000 On Tue, 2016-06-21 at 15:35 -0700, bob prohaska wrote: > On Tue, Jun 21, 2016 at 10:34:41PM +0100, James Elstone wrote: > > Hi Bob, > > > > What sort of flow control (rts/cts, xon/xoff, or none)? > > > > I suspect you cleared the control signals rather than unfreeze?? > > There are none to clear: The serial end is on an RPI2, with only > TX, RX and ground. The USB end is on a second RPI2. > > In that particular case, I tried unplugging and replugging the > USB end, to no avail. Then I dragged over an iMac with Prolific's > drivers installed and plugged the USB end into the iMac. The > PL2303 still wasn't recognized. While it was still plugged into > the iMac, I lifted the TX, RX and ground connections on the PL2303 > cable. The PL2303 recognition message immediately showed up on the > iMac's console. > > As it happens, the two RPI2s in question share a ground through > the wired Ethernet. They're connected to two different switches, > which are in turn connected by a length of cable. > > The ground cable on the PL2303 forms a second, parallel ground, > amounting to a loop. This is universally considered bad practice > but is often gotten away with. Perhaps I'm not so lucky. > > The Prolific driver installation instructions specify installing the > software, connecting the USB end next and connecting the serial end > last. I thought they were just pacifying the pedantic among us, > but maybe there's a physical reason behind the advice. > > Next time a PL2303 locks up I'll begin by lifting the serial cable > connections, ground first, to see what the uplcom driver does. If > it subsequently recognizes the PL2303 I _think_ that supports the > notion of a wiring problem. > > Thanks for reading and special thanks to Hal Murray for introducing > the > idea of serial devices being "held" by signaling voltages, > > bob prohaska > If the serial side has active signals and the usb side is unconnected then you are essentially applying power to some of the IO pins of an otherwise unpowered chip. Sometimes you end up accidentally powering the chip that way and it kinda-sorta works. Other times it just fries the chip. And sometimes it's harmless (usually only because the active signal line(s) can't source enough current to cause any harm). -- Ian From owner-freebsd-arm@freebsd.org Wed Jun 22 00:46:36 2016 Return-Path: Delivered-To: freebsd-arm@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 0BAA1AC5233 for ; Wed, 22 Jun 2016 00:46:36 +0000 (UTC) (envelope-from james.c.elstone@ntlworld.com) Received: from know-smtprelay-omc-11.server.virginmedia.net (know-smtprelay-omc-11.server.virginmedia.net [80.0.253.75]) by mx1.freebsd.org (Postfix) with ESMTP id 52D6016DD for ; Wed, 22 Jun 2016 00:46:34 +0000 (UTC) (envelope-from james.c.elstone@ntlworld.com) Received: from THORIUM ([82.2.189.134]) by know-smtprelay-11-imp with bizsmtp id 9clQ1t00H2uRS4201clQiE; Wed, 22 Jun 2016 01:45:24 +0100 X-Originating-IP: [82.2.189.134] X-Spam: 0 X-Authority: v=2.1 cv=OJTapnuB c=1 sm=1 tr=0 a=veQ/QFbREZPQBKeuBCmuXw==:117 a=veQ/QFbREZPQBKeuBCmuXw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=7QypooQz5QXDWeewLhEA:9 a=lUVFcQCXJ7cUTMjV:21 a=KXZs7l5hMYCt3NOH:21 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 From: "James C Elstone" To: References: <20160619020311.GC38492@www.zefox.net> <20160619034248.1D097406057@ip-64-139-1-69.sjc.megapath.net> <20160621041439.GA2449@www.zefox.net> <20160621223531.GC2449@www.zefox.net> <1466551193.34556.76.camel@freebsd.org> In-Reply-To: <1466551193.34556.76.camel@freebsd.org> Subject: RE: pl2303 lockups on rpi2 Date: Wed, 22 Jun 2016 01:45:38 +0100 Message-ID: <000001d1cc1f$656511b0$302f3510$@c.elstone@ntlworld.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdHMFVfOC3QjkuqQRVCK2VtOVdB9XAAB6UpQ Content-Language: en-gb X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 00:46:36 -0000 Hi Bob, Just a few more thoughts to ponder: It may be an idea to check the status / strength (voltage) of the TX>RX / RX On Tue, Jun 21, 2016 at 10:34:41PM +0100, James Elstone wrote: > > Hi Bob, > > > > What sort of flow control (rts/cts, xon/xoff, or none)? > > > > I suspect you cleared the control signals rather than unfreeze?? > > There are none to clear: The serial end is on an RPI2, with only TX, > RX and ground. The USB end is on a second RPI2. > > In that particular case, I tried unplugging and replugging the USB > end, to no avail. Then I dragged over an iMac with Prolific's drivers > installed and plugged the USB end into the iMac. The > PL2303 still wasn't recognized. While it was still plugged into the > iMac, I lifted the TX, RX and ground connections on the PL2303 cable. > The PL2303 recognition message immediately showed up on the iMac's > console. > > As it happens, the two RPI2s in question share a ground through the > wired Ethernet. They're connected to two different switches, which are > in turn connected by a length of cable. > > The ground cable on the PL2303 forms a second, parallel ground, > amounting to a loop. This is universally considered bad practice but > is often gotten away with. Perhaps I'm not so lucky. > > The Prolific driver installation instructions specify installing the > software, connecting the USB end next and connecting the serial end > last. I thought they were just pacifying the pedantic among us, but > maybe there's a physical reason behind the advice. > > Next time a PL2303 locks up I'll begin by lifting the serial cable > connections, ground first, to see what the uplcom driver does. If it > subsequently recognizes the PL2303 I _think_ that supports the notion > of a wiring problem. > > Thanks for reading and special thanks to Hal Murray for introducing > the idea of serial devices being "held" by signaling voltages, > > bob prohaska > If the serial side has active signals and the usb side is unconnected then you are essentially applying power to some of the IO pins of an otherwise unpowered chip. Sometimes you end up accidentally powering the chip that way and it kinda-sorta works. Other times it just fries the chip. And sometimes it's harmless (usually only because the active signal line(s) can't source enough current to cause any harm). -- Ian _______________________________________________ freebsd-arm@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Wed Jun 22 12:33:44 2016 Return-Path: Delivered-To: freebsd-arm@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 25F04AC56C9 for ; Wed, 22 Jun 2016 12:33:44 +0000 (UTC) (envelope-from usenet@ulrich-grey.de) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BF4201AFD for ; Wed, 22 Jun 2016 12:33:42 +0000 (UTC) (envelope-from usenet@ulrich-grey.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1466598819; l=1486; s=domk; d=ulrich-grey.de; h=Content-Transfer-Encoding:Content-Type:Mime-Version:Subject:To:From: Date; bh=kkDRCBta1mnUBFHTZMCdnl7ZqADnCH9Ez8gYFMC4pvA=; b=Ft6V/yKHGmiKQIYYPC5yCQFhCWM8dEpomLF9PRxOGRQqFeriGGJmQkLlCoDBnKtMbmk B0JfcPxlUUgiKlJN93h2aVMPg8lUekOk3++GSw0i5MHSAJcKOB2LobS74/FpzYhVV50kf Wr2diN1xaNnBvto6NcVZ94/9nBUa17Lk+cc= X-RZG-AUTH: :OX8Be0W8W+pMC3rDLL/lo2xV/LZTbZkYhOcjg8suic3iYr/B8J9Lzp3TJg49sMv7uA== X-RZG-CLASS-ID: mo00 Received: from work (p54869E05.dip0.t-ipconnect.de [84.134.158.5]) by smtp.strato.de (RZmta 38.6 DYNA|AUTH) with ESMTPSA id j06d4es5MCXcMAe (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Wed, 22 Jun 2016 14:33:38 +0200 (CEST) Date: Wed, 22 Jun 2016 14:33:37 +0200 From: Ulrich Grey To: freebsd-arm@freebsd.org Subject: FreeBSD CURRENT on CUBOX-i 4x4-300-D using 4GB RAM Message-Id: <20160622143337.367658276477078d6dff779f@ulrich-grey.de> Organization: - X-Mailer: Sylpheed 3.4.3 (GTK+ 2.24.28; armv6-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 12:33:44 -0000 I have built a new u-boot using sysutils/u-boot-cubox-hummingboard, but substituting the u-boot source tree from ports with a freshly cloned one: git clone https://github.com/SolidRun/u-boot-imx6.git Applying the patches from the port delivered a rejected chunk whom I have applied "manually". After building I have copied the u-boot.imx file to the image file as described in the README file. Booting the system, ca. 4GB (instead of 2GB) of RAM was recognized: FreeBSD 11.0-ALPHA3 #2 r301815M: Sat Jun 11 05:11:51 UTC 2016 root@wqtest.intranet:/usr/obj/usr/src/sys/IMX6 arm FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0) VT: init without driver. CPU: Cortex A9-r2 rev 10 (Cortex-A core) Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext WB enabled LABT branch prediction disabled LoUU:2 LoC:2 LoUIS:2 Cache level 1: 32KB/32B 4-way data cache WB Read-Alloc Write-Alloc 32KB/32B 4-way instruction cache Read-Alloc real memory = 4025483264 (3839 MB) avail memory = 3933708288 (3751 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs But I was not able to use the external USB harddisks. I got error messages like: usb_err_nomem kstack allocation failed. After I added kern.nbuf="8000" to /boot/loader.conf, the error messages disappeared. The value "8000" is a guess, the old value was around 7100. As a test I have successfully build a new kernel. Only USB1 port is working. From owner-freebsd-arm@freebsd.org Wed Jun 22 17:31:47 2016 Return-Path: Delivered-To: freebsd-arm@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 10202B72C0A for ; Wed, 22 Jun 2016 17:31:47 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 CA0A31395; Wed, 22 Jun 2016 17:31:46 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x232.google.com with SMTP id f6so44250314ith.0; Wed, 22 Jun 2016 10:31:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=H98IhJu2Yyc/8wnyHdPV2YIn2BGGAXD7Can+lSr/dBw=; b=Vi9tf2cTIE2YeKIVY8XXmCbSW1c9lLN+AlvHjigAwhXBeRIIprzhSUaD33omq1xchw wtjNVWy8eDHM8lBEk6W8HXETOa2cM80Kw918VRSaUzQ+R6tR/RbeZbqjBy4NIUO7UeeL mj/sLJNwaEf/HLQdzwy0EBdqEPvQgtSa+rr3W/P0fW8EbTmYX4RzcibhmPtRrLtWRNc0 bd37VxfctG85tWP0Y/2g28umeBVRL8qJC025CLIrmaiqX/a7yRXjreCFJFkAzwPEYdfO ccGHF98pGyvzobVlgy1a23EoHGStt2hl4GgXEEBX87iPTUVnBqODrRVJUYRxqIGhfCt6 /1Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=H98IhJu2Yyc/8wnyHdPV2YIn2BGGAXD7Can+lSr/dBw=; b=C5tBS5FLrjaw6q/V5qxaL6gFOBXmkakBt+FuO2oNYKIEyLmtlmebxhxtBN1D7XkBAG 6UBZXqQHt/oIADxST/hhNCQKcbPAnHqGHhOdTd7PsXkRhhawy4f3H7c5NZFre6zehQNz Qcj3AiL8v6/qIHQ4ZFmSdn9Pi3TJiMyCl1wWnOlT8Egj+RR29Q99Z7IzrWoNo7aUV8+H 9ofBOTZJ4ECgjfTr8UlyKf9nwmWAg0MbDCQCCdzKUouKSeqJFSIo2VS9onflz935qeI8 b7B1WlhIlEgGwmT1W0J4IWL6/fjw2hDlQWtRWUEoS84TfTeTdj32UGzumF1qGCeAmaY2 oKTw== X-Gm-Message-State: ALyK8tKKeF+x7kRRnisv1RG/lPz/KuMx++b+VEz7Fh33c8w5GVI1kXYsOEuR/4dIU8YIkq89VXmTLLCnksKSmg== X-Received: by 10.36.57.199 with SMTP id l190mr16691418ita.5.1466616706063; Wed, 22 Jun 2016 10:31:46 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.6.213 with HTTP; Wed, 22 Jun 2016 10:31:26 -0700 (PDT) In-Reply-To: <20160603223153.GA70896@FreeBSD.org> References: <20160603223153.GA70896@FreeBSD.org> From: Ed Maste Date: Wed, 22 Jun 2016 13:31:26 -0400 X-Google-Sender-Auth: mDftpGFKrNmq6Ir1_JuPRpD1EAQ Message-ID: Subject: Re: New FreeBSD snapshots available: head (20160528 r301230) To: Glen Barber , Andrew Turner , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 17:31:47 -0000 On 3 June 2016 at 18:31, Glen Barber wrote: > > Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI > loader file is needed for qemu-system-aarch64 to be able to boot the > virtual machine images. The file can be found here, for now, until > various patches are available upstream: > > http://people.FreeBSD.org/~gjb/QEMU_EFI.fd Linaro has newer UEFI firmware builds for AArch64 QEMU at https://wiki.linaro.org/LEG/UEFIforQEMU and I've just now checked and found that it boots the most recent FreeBSD arm64 memstick snapshot. The specific one I tested was: http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upstream/1036/QEMU-AARCH64/RELEASE_CLANG35/QEMU_EFI.fd From owner-freebsd-arm@freebsd.org Wed Jun 22 17:44:32 2016 Return-Path: Delivered-To: freebsd-arm@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 AECE7B72017 for ; Wed, 22 Jun 2016 17:44:32 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::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 6386B1C18 for ; Wed, 22 Jun 2016 17:44:32 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qk0-x235.google.com with SMTP id a186so75155171qkf.0 for ; Wed, 22 Jun 2016 10:44:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=5sfajsxviTIQFwmtBO4vSEwmdk0Ak6q9r2iAnq2WLv8=; b=Xgb07g6aTChdKNn4tGhE4aeQ6mY4hn/Zc1C+KXIR04Y952qIvVC6MLiTSJcTKseWH0 MAGCGdROWkpiJxQ1wjtRIlWXDMXnmQNnigibtR4aChUngU8NNsZIPkZnvcLqTYus5KY3 kiCTgwwMffCWwzUcMNo53tcjKbMHDis4h68jo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=5sfajsxviTIQFwmtBO4vSEwmdk0Ak6q9r2iAnq2WLv8=; b=ExYg6WocW5BNH5petLdVAgzo4NXOexyM3guS1MeBOZxN5C0LBsnMjdIhdowfn7x7CH O1tP//0pxf+f1Lsz+p6pVfPcifxc742JEk7I8CvllGzrFwcbcWd4LvD6lIB800/miFcv xTm44dTUn8RryooHhDhvPNfOrnO+TQgs5UnQmqCJYxuKN9oZp0gy3tXzbs01wjk8Fu5U 98xVrwv5CBmXaJ3Rj7l2Wz5nZbzffgWabWdE3qNkx+GUL+bNqS6wr2KIyF0mAcN0f85j 1KYxr7+qgNXGYCI8meKrVWsQbJVVJ4Q+veOv5hWUFqYy7nUOKEbghTMVoXJT/5nyiW8c i7rA== X-Gm-Message-State: ALyK8tIMbqzCiS92FmcxjJeCfEaZgIFlxz6jfH3sE2Ryq1sCjFIqm1rvT30xDhwFZX+dyA== X-Received: by 10.55.165.67 with SMTP id o64mr40246172qke.51.1466617471608; Wed, 22 Jun 2016 10:44:31 -0700 (PDT) Received: from [192.168.0.18] ([187.60.94.34]) by smtp.googlemail.com with ESMTPSA id j62sm396074qtb.35.2016.06.22.10.44.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jun 2016 10:44:30 -0700 (PDT) Subject: Re: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison] To: Keith White , Ian Lepore References: <99277FB6-77EB-4D8B-8A55-FBD622D29AC3@dsl-only.net> <22fe5f7f-6153-e092-c410-eddb1431a78a@bsd.com.br> <1466531719.34556.72.camel@freebsd.org> Cc: Mark Millard , freebsd-arm , FreeBSD Current From: =?UTF-8?B?T3RhY8OtbGlv?= Message-ID: <3c4cc02c-f6be-b6de-3d9b-da1302aac85d@bsd.com.br> Date: Wed, 22 Jun 2016 14:44:06 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 17:44:32 -0000 Em 21/06/2016 19:45, Keith White escreveu: > On Tue, 21 Jun 2016, Ian Lepore wrote: > >> On Tue, 2016-06-21 at 08:11 -0300, Otacílio wrote: >>> Em 21/06/2016 07:33, Keith White escreveu: >>>> In an earlier message Ian said that he thought he knew what the >>>> problem was... >>> >>> Here the problem occurs when using wifi. I do not have tested wired >>> because I don't have a cable here. >>> >>> >>> []'s >>> >>> -Otacilio >> >> The wifi alignment fault should be fixed as of r302064. Sorry it took >> so long. >> >> -- Ian > > Many thanks Ian! Yes, this has fixed the problem. No more panics > on ssh to rpi-b. > > ...keith This fix on beaglebone black also. Thanks a lot! []'s -Otacílio From owner-freebsd-arm@freebsd.org Wed Jun 22 17:52:52 2016 Return-Path: Delivered-To: freebsd-arm@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 89F5AB722BC for ; Wed, 22 Jun 2016 17:52:52 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 46C3F21F2 for ; Wed, 22 Jun 2016 17:52:52 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qk0-x22e.google.com with SMTP id t127so75501396qkf.1 for ; Wed, 22 Jun 2016 10:52:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=bdKi4JpVkfDQi2iN8+aHud8d65YNlTea+02z5Rnamco=; b=D0mmzny8D2lUDeuqXQw7qjhxIy0ODsSzXBhuLfHttyYHEUR0tu3AToZ3idRt7e9tIy 9i+Fd4GoYmIZUhY6uiARhTLBUOKVQyH+iZbblnvz1eqp99oQXi/ZW3/3zWV753Nx7QI+ v1G8FI0KdpsYwVnYjBwEz0rxB2K1qKk9aVNbY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=bdKi4JpVkfDQi2iN8+aHud8d65YNlTea+02z5Rnamco=; b=CnjbzEOvNuOEm3JnBraFiBErtdm4RiTvfE40N5snD1aB4gIBRZO3AWtVYpS9DEbfkD jXhfS8TsRgFxuFfaD8E/dSWZ9prfTYgLBhtC7BIDXEv4b5NzNdeBob6q47sNvdQqzFYq GEzXAp5onSgYxVKcCLci8Ba35bdmjHc7OKb6okTAv3ciww1FS+frGLSfXd/t40csUZfr y9OuKJVdHhuFV4CetoVqTD3DPUsc2evoxDb+EFTOrdsj7Jd1d34VjL8xJDEhgTyKbZvC UVd1QSTG9MoDMo+zPN8RZlSZRgjdvutK5mObjTj1Dm2JPrq6fTLexjmQo9nq0rvakV2J S7WQ== X-Gm-Message-State: ALyK8tLopq++7CVZ9/97sohClE6hP7vooeZak4wNuaZjAydff3LrGiJ5n1R42OZcHMDMYw== X-Received: by 10.237.53.233 with SMTP id d38mr37236158qte.104.1466617971354; Wed, 22 Jun 2016 10:52:51 -0700 (PDT) Received: from [192.168.0.18] ([187.60.94.34]) by smtp.googlemail.com with ESMTPSA id m92sm423591qtd.27.2016.06.22.10.52.49 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jun 2016 10:52:50 -0700 (PDT) To: "freebsd-arm@freebsd.org" , freebsd-hackers@freebsd.org From: =?UTF-8?B?T3RhY8OtbGlv?= Subject: Poor performance when using urtwn on beaglebone black Message-ID: <8751579c-68ae-7330-eb9b-c67d84ae18db@bsd.com.br> Date: Wed, 22 Jun 2016 14:52:26 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 17:52:52 -0000 Dears I'm getting poor performance when using wifi by urtwn on beaglebone black. I'm using netperf to do benchmarks and I'm getting less than 1Mbps normally and between 3Mbps and 7.5Mbps when creating the interface with -ht option. I think that previous versions has better performance. FreeBSD beaglebone 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #0 r302064: Wed Jun 22 00:25:52 BRT 2016 ota@squitch:/root/workdir/crochet/work/obj/arm.armv6/usr/src/sys/BEAGLEBONE arm []'s -Otacílio From owner-freebsd-arm@freebsd.org Wed Jun 22 17:57:52 2016 Return-Path: Delivered-To: freebsd-arm@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 955AFB724E4 for ; Wed, 22 Jun 2016 17:57:52 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 51E4925B4 for ; Wed, 22 Jun 2016 17:57:52 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qk0-x229.google.com with SMTP id c73so75816966qkg.2 for ; Wed, 22 Jun 2016 10:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=fq8Fe9tRu/SW4x64NPI7jfR4o7Ehjw3X0dYtqtfigkE=; b=Oo2n+uECVBLvOxZOoaMg52ksj73l1e2fzhY0HZipfyYrX23I1un5PlOkxYNwqbHkCN qXUXdajZmhpbJ4MVOntFAeJwBNe9vcZZeeFMEvR9aChLZg0ITUAqeherNv8ESaoh/zxr VXpYK67vsSK6uk4Yw3O4aylwQavfnsznrTLxU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=fq8Fe9tRu/SW4x64NPI7jfR4o7Ehjw3X0dYtqtfigkE=; b=PxMQ42F/BWCinjbf10ELZ3IhKHGAi0ppE9eAjYqp/W9OoOVBd5We1QYG1/fMuP4rWm zsshSaMU8FEBCWBdAzKjkwVDjBxrY0rcGZTZY1z/Z0kCu+/+Qwchynf9/qiGxo7AzrgE GHoOF7HJkX3kY/9xbo53DYL44qtGlBFthVsQRPsx1ETbYzx2DPiQnlsNKU0LKukoKGDd eJRbKMcXyMeklN43RWVDvfCs3tadnK7eSulk3b5u7uADKG8Ia9KQaWWMjtZMpXOzZqT/ mAW6t2EXUU9bEreiO48f4BLpn+uGDGpY42fQqe+jU4o+R2adlKeWtVMcWtrbEWQTXFiL 2okg== X-Gm-Message-State: ALyK8tIPi+6a8CaCivOjKebZlFkbUNgHy654k//ySRW38Y7XpIuekjz7N9csPGokM2ql2Q== X-Received: by 10.55.31.140 with SMTP id n12mr40483089qkh.4.1466618271253; Wed, 22 Jun 2016 10:57:51 -0700 (PDT) Received: from [192.168.0.18] ([187.60.94.34]) by smtp.googlemail.com with ESMTPSA id c192sm506966qke.2.2016.06.22.10.57.49 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jun 2016 10:57:50 -0700 (PDT) To: "freebsd-arm@freebsd.org" , freebsd-hackers@freebsd.org From: =?UTF-8?B?T3RhY8OtbGlv?= Subject: Kernel panic all times when running service netif restart Message-ID: <8e22a408-3d61-d0e4-2285-83448bf48a3e@bsd.com.br> Date: Wed, 22 Jun 2016 14:57:26 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 17:57:52 -0000 Dears I'm getting a kernel panic all times on FreeBSD beaglebone 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #0 r302064: Wed Jun 22 00:25:52 BRT 2016 ota@squitch:/root/workdir/crochet/work/obj/arm.armv6/usr/src/sys/BEAGLEBONE arm when I run 'service netif restart' on a beaglebone black using urtwn driver. Look bellow: root@beaglebone:/usr/home/ota # service netif restart dhclient not running? (check /var/run/dhclient.cpsw0.pid). Jun 22 17:53:18 beaglebone dhclient[782]: My address (192.168.0.11) was deleted, dhclient exiting Jun 22 17:53:18 beaglebone dhclient[730]: connection closed Jun 22 17:53:18 beaglebone dhclient[730]: exiting. Stopping wpa_supplicant. Jun 22 17:53:19 beaglebone wpa_supplicant[350]: ioctl[SIOCS80211, op=20, val=0, arg_len=7]: Can't assign requested address dhclient not running? (check /var/run/dhclient.wlan0.pid). Stopping Network: lo0 cpsw0 wlan0. lo0: flags=8048 metric 0 mtu 16384 options=600003 groups: lo nd6 options=21 cpsw0: flags=8c02 metric 0 mtu 1500 options=8000b ether 90:59:af:4c:20:9a media: Ethernet autoselect (none) status: no carrier nd6 options=29 wlan0: flags=8802 metric 0 mtu 1500 ether 14:cc:20:12:ee:55 groups: wlan ssid "" channel 11 (2462 MHz 11g) regdomain FCC country US authmode OPEN privacy OFF txpower 30 bmiss 7 scanvalid 60 protmode CTS wme media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier nd6 options=29 Fatal kernel mode data abort: 'Translation Fault (L2)' on read trapframe: 0xde3abba0 FSR=00000007, FAR=00000014, spsr=20000013 r0 =00000000, r1 =00000000, r2 =c06f1fa6, r3 =000003aa r4 =c31fc000, r5 =c06f1fa6, r6 =c2fe84b8, r7 =c2fe6000 r8 =c2fec000, r9 =00000016, r10=c2fec008, r11=de3abc70 r12=c08b6ca0, ssp=de3abc30, slr=c31941e4, pc =c0484744 [ thread pid 1273 tid 100074 ] Stopped at if_detach+0x28: ldr r4, [r0, #0x014] db> []'s -Otacílio From owner-freebsd-arm@freebsd.org Wed Jun 22 18:01:35 2016 Return-Path: Delivered-To: freebsd-arm@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 5D49DB726B6; Wed, 22 Jun 2016 18:01:35 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 2E3BE28DC; Wed, 22 Jun 2016 18:01:35 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: by mail-pf0-x230.google.com with SMTP id i123so19859780pfg.0; Wed, 22 Jun 2016 11:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=vN6NO+04DfUV66tQxcsHklfqneGvDcPcMNyy94EXFgQ=; b=TqpcVc7LLBYREEcy5fiKEDG8wkIMzZhjPMuv8Exi/hoTYq5QTy/EG0KnUNi/BSsKqS FQ4wPSvty/4zV+JNHIpxZtZXIlYBZmX9XKG49QRorsepx2VnfeK0GTTa5R4Yis8jvLem sSiXXYxXdQQAnqJfTEJHmGXJEqS7txdLOb4k9b3UmW4AiFtxA0wjFnwJkPxrg7ObJ7lT OJm3W/9FTEFsgIrE5o6EPDdVDwdmQ6aPaXJ522fp750WQcc7FxrLB1lL+wp6i2HM/+kf X6qm1ZnvU0fflKAU87EfzhedaJPm+df/qjRyNw/CQdFtDs0fQvxozwEpei0F8si+20ng dXWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=vN6NO+04DfUV66tQxcsHklfqneGvDcPcMNyy94EXFgQ=; b=Hw8HvZqhyEfSreWOmYIxdUqUT8djNX+hfVLx78yjbjM7eOFstlXqHBXap1yxr2U88s 5kbqOs1SdsQGe8RwNvH7XxkPlCKrcFHSHhZUP4lt6IzeG+siaeQdoKaHZVdsExeOeqIt QfQw2jdPNPmWV82OTjFKkp//K+UvhvuZEQNrPTo0ivHVZCJAOcH2AzsD63X5MtS9Qiyv S8n/YuVvYlsEF+xmLXgioCFsa6PgV9jHp33kMIjhWtPivULI6KVYSikzvp1kZsBe8Tjd DQgYFCOtcS7T/6RNz8a90DAKl0UeBco+k3xpJko87zJE7E9pMWS44UPWKq5IAwVEjFzx vUYQ== X-Gm-Message-State: ALyK8tLUtorfYdYuR7lFaV2dRRdZU4Ir9g11UAb8epnaoBHDuWcjmuulBh72MicxaU6xEQ== X-Received: by 10.98.210.66 with SMTP id c63mr36234955pfg.25.1466618494437; Wed, 22 Jun 2016 11:01:34 -0700 (PDT) Received: from [10.192.166.0] ([12.32.117.8]) by smtp.googlemail.com with ESMTPSA id fj13sm1471016pab.0.2016.06.22.11.01.33 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jun 2016 11:01:33 -0700 (PDT) Subject: Re: Kernel panic all times when running service netif restart To: =?UTF-8?B?T3RhY8OtbGlv?= , "freebsd-arm@freebsd.org" , freebsd-hackers@freebsd.org References: <8e22a408-3d61-d0e4-2285-83448bf48a3e@bsd.com.br> From: Navdeep Parhar Message-ID: <78521866-f22f-5d75-7925-a48996352590@gmail.com> Date: Wed, 22 Jun 2016 11:01:32 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <8e22a408-3d61-d0e4-2285-83448bf48a3e@bsd.com.br> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 18:01:35 -0000 Try r302083, it fixed a panic in if_detach. Regards, Navdeep On 06/22/2016 10:57, Otac=C3=ADlio wrote: > Dears >=20 > I'm getting a kernel panic all times on >=20 > FreeBSD beaglebone 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #0 r302064: Wed Jun > 22 00:25:52 BRT 2016 > ota@squitch:/root/workdir/crochet/work/obj/arm.armv6/usr/src/sys/BEAGLE= BONE > arm >=20 > when I run 'service netif restart' on a beaglebone black using urtwn > driver. Look bellow: >=20 > root@beaglebone:/usr/home/ota # service netif restart > dhclient not running? (check /var/run/dhclient.cpsw0.pid). > Jun 22 17:53:18 beaglebone dhclient[782]: My address (192.168.0.11) was= > deleted, dhclient exiting > Jun 22 17:53:18 beaglebone dhclient[730]: connection closed > Jun 22 17:53:18 beaglebone dhclient[730]: exiting. > Stopping wpa_supplicant. > Jun 22 17:53:19 beaglebone wpa_supplicant[350]: ioctl[SIOCS80211, op=3D= 20, > val=3D0, arg_len=3D7]: Can't assign requested address > dhclient not running? (check /var/run/dhclient.wlan0.pid). > Stopping Network: lo0 cpsw0 wlan0. > lo0: flags=3D8048 metric 0 mtu 16384 > options=3D600003 > groups: lo > nd6 options=3D21 > cpsw0: flags=3D8c02 metric 0 mtu 1= 500 > options=3D8000b > ether 90:59:af:4c:20:9a > media: Ethernet autoselect (none) > status: no carrier > nd6 options=3D29 > wlan0: flags=3D8802 metric 0 mtu 1500 > ether 14:cc:20:12:ee:55 > groups: wlan > ssid "" channel 11 (2462 MHz 11g) > regdomain FCC country US authmode OPEN privacy OFF txpower 30 > bmiss 7 > scanvalid 60 protmode CTS wme > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) > status: no carrier > nd6 options=3D29 > Fatal kernel mode data abort: 'Translation Fault (L2)' on read > trapframe: 0xde3abba0 > FSR=3D00000007, FAR=3D00000014, spsr=3D20000013 > r0 =3D00000000, r1 =3D00000000, r2 =3Dc06f1fa6, r3 =3D000003aa > r4 =3Dc31fc000, r5 =3Dc06f1fa6, r6 =3Dc2fe84b8, r7 =3Dc2fe6000 > r8 =3Dc2fec000, r9 =3D00000016, r10=3Dc2fec008, r11=3Dde3abc70 > r12=3Dc08b6ca0, ssp=3Dde3abc30, slr=3Dc31941e4, pc =3Dc0484744 >=20 > [ thread pid 1273 tid 100074 ] > Stopped at if_detach+0x28: ldr r4, [r0, #0x014] > db> >=20 >=20 > []'s >=20 > -Otac=C3=ADlio >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" From owner-freebsd-arm@freebsd.org Thu Jun 23 08:21:59 2016 Return-Path: Delivered-To: freebsd-arm@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 CD82DAC6541 for ; Thu, 23 Jun 2016 08:21:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (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 8D3FC1ACC for ; Thu, 23 Jun 2016 08:21:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21185 invoked from network); 23 Jun 2016 08:22:28 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 23 Jun 2016 08:22:28 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Thu, 23 Jun 2016 04:22:36 -0400 (EDT) Received: (qmail 24946 invoked from network); 23 Jun 2016 08:22:36 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 23 Jun 2016 08:22:36 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 4182C1C407A; Thu, 23 Jun 2016 01:21:37 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: WITH_SYSTEM_COMPILER default on From: Mark Millard In-Reply-To: <39C98FFD-B0BB-4F25-A1D1-2447A2FDDFBD@dsl-only.net> Date: Thu, 23 Jun 2016 01:21:49 -0700 Cc: freebsd-arm , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <6C3A4F2A-9583-49FB-B1E7-69A0044B3887@dsl-only.net> References: <39C98FFD-B0BB-4F25-A1D1-2447A2FDDFBD@dsl-only.net> To: Bryan Drewery , FreeBSD Current , FreeBSD Toolchain X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 08:21:59 -0000 On 2016-Jun-21, at 3:11 PM, Mark Millard wrote: > Bryan Drewery bdrewery at FreeBSD.org wrote on Tue Jun 21 19:03:46 UTC = 2016 : >=20 >> This feature is where the bootstrap compiler in buildworld is not = built >> if the one in /usr/bin/cc matches what would be built. It is very >> conservative and requires a complete match of major/minor version and >> the compiler revision (__FreeBSD_cc_version). >>=20 >> The only complaint so far about this feature was that when we bumped = the >> compiler revision, too much of clang would rebuild. That was = addressed >> in r301277. >>=20 >> I would like to enable this feature by default in head for 11.0. >>=20 >> Unless there are any objections I will do so in a few days. >>=20 >> --=20 >> Regards, >> Bryan Drewery >=20 > I've only been using WITH_SYSTEM_COMPILER=3D for system-clang based = builds with the host matching TARGET_ARCH ("self hosted"). >=20 > For xtoolchain use (self-hosted or not) I've been using in my src.conf = files for such contexts:=20 >=20 > WITHOUT_CROSS_COMPILER=3D > WITHOUT_SYSTEM_COMPILER=3D > WITHOUT_BINUTILS_BOOTSTRAP=3D > WITHOUT_CLANG_BOOTSTRAP=3D >=20 > For cross builds (all being amd64 -> something else, such as armv6, = powerpc64, or powerpc) based on using some build of the system clang = 3.8.0 I've been using: >=20 > WITH_CROSS_COMPILER=3D > WITHOUT_SYSTEM_COMPILER=3D > WITH_BINUTILS_BOOTSTRAP=3D > WITH_CLANG_BOOTSTRAP=3D >=20 > As I understand the history the paths for finding tools, headers, etc. = built into the clang cross compiler were not necessarily the same as for = the live the system compiler that has paths appropriate specifically to = self-hosting. This helped avoid getting the wrong versions of files = involved. A historical example was cross builds running the live-system's ld when = the use of ld was implicit in a clang/clang++ command instead of being a = direct use of ${XLD}. In other words: such implicit use of ld by /usr/bin/clang and = /usr/bin/clang++ would not go find the ld built by = WITH_BINUTILS_BOOTSTRAP=3D but would instead use /usr/bin/ld (which was = for the wrong TARGET_ARCH). It looks like testing the current handling of such WITH_SYSTEM_COMPILER=3D= issues in a form that allows WITHOUT_CROSS_COMPILER=3D operation = requires building not using WITH_META_MODE=3D : man src.conf says that = WITH_META_MODE=3D enforces WITHOUT_SYSTEM_COMPILER=3D . My normal build procedures now use WITH_META_MODE=3D so such a test = would be special. Let me know if you want my to make such a test. > This was true despite the normal clang code generation being able to = target other architectures. >=20 > As for self-hosted system-clang based builds I've been using: >=20 > #WITH_CROSS_COMPILER=3D > WITH_SYSTEM_COMPILER=3D > WITH_BINUTILS_BOOTSTRAP=3D > #WITH_CLANG_BOOTSTRAP=3D >=20 > (So in this case I've left some things implicit in operation.) >=20 > As stands I'll not notice the SYSTEM_COMPILER default's consequences = because I'm always explicit about WITH vs. WITHOUT for SYSTM_COMPILER. = If you want some sort of experiment(s), let me know. >=20 > But I only currently have an amd64 context and a rpi2 armv6 context. = The dual-proessor, each dual-core powerpc64 was much faster at = self-hosted xtoolchain builds compared to any self-hosted rpi2 build but = I do not have access to the powerpc family for now. Self-hosted amd64 = xtoolchain builds do not work yet for normal settings: duplicate = declarations tend to stop the builds if one leaves on the = warnings-as-errors status for buildkernel. (At least last that I tried = such.) >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Jun 23 10:00:54 2016 Return-Path: Delivered-To: freebsd-arm@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 4D3CDA7999F for ; Thu, 23 Jun 2016 10:00:54 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::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 0F83E21A3 for ; Thu, 23 Jun 2016 10:00:53 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-vk0-x22c.google.com with SMTP id c2so68253553vkg.1 for ; Thu, 23 Jun 2016 03:00:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=pj980TBrBEmSQ+WBNHJWQ1b98xyhJ5S932Uwg8+eBHg=; b=LRQGNOphNUZ8lLAzPcHj8gYRif9MGAVducxtZLC7HnZLZ4+Sgy7k0xQsYyFpR86p5D 6Dg2RFVKCHnKjVZ7BM4o/RgpEUQhIvprvwXy1QWqHNg5dvuIkyLAOTnPwof41cZviqfr VN1Geh0UzxK9VAdT+G9TiXoDrspCHK9KaSLKQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=pj980TBrBEmSQ+WBNHJWQ1b98xyhJ5S932Uwg8+eBHg=; b=MyptF9FdW8ZlYSIRI+I3+eTjd08XqoiYj2IAn81sKL1no9hkD3k9SsNB1zDwZpQw/A rE2sLRBTfxd5QszxyN78QOkyQGGXL0lvkY5CR0UE8Mg1zPefzEke2HvU6NPwx9AJvtek cbWoyGOJMNjy6MZCTyaH+Bh+rD9YK+g+pvpCXD47DDKHD+OtR+RUS83SJgErSAnn+knd +xuuBqg/t+1doepBjMTv8OLBJtO7b0Z/ftKdzMpHqR3nufSY+iBjKxurA2bvUMGa5Dfe cjtnBZPb2KtLcIlgKSmn7tmIA+pRnwQ+g0f8P3//HgZCDviL1pzsOShsdaqOVhTOKlwq TzCQ== X-Gm-Message-State: ALyK8tL4QjZEiAHR8987gP2acZmu/eTw43jgUQz8KAikAyEExnnKxMin+Vn8/dXtOgI/7g== X-Received: by 10.176.4.48 with SMTP id 45mr14602925uav.127.1466676052810; Thu, 23 Jun 2016 03:00:52 -0700 (PDT) Received: from [192.168.0.18] ([187.60.94.34]) by smtp.googlemail.com with ESMTPSA id n16sm1089166vkd.2.2016.06.23.03.00.50 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Jun 2016 03:00:51 -0700 (PDT) Subject: Re: Kernel panic all times when running service netif restart To: Navdeep Parhar , "freebsd-arm@freebsd.org" , freebsd-hackers@freebsd.org References: <8e22a408-3d61-d0e4-2285-83448bf48a3e@bsd.com.br> <78521866-f22f-5d75-7925-a48996352590@gmail.com> From: =?UTF-8?B?T3RhY8OtbGlv?= Message-ID: <1608d561-2109-fbb9-39fe-226c43f6120d@bsd.com.br> Date: Thu, 23 Jun 2016 07:00:27 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <78521866-f22f-5d75-7925-a48996352590@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 10:00:54 -0000 Yes. Works here. Thanks a lot! []'s -Otacilio Em 22/06/2016 15:01, Navdeep Parhar escreveu: > Try r302083, it fixed a panic in if_detach. > > Regards, > Navdeep > > On 06/22/2016 10:57, Otacílio wrote: >> Dears >> >> I'm getting a kernel panic all times on >> >> FreeBSD beaglebone 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #0 r302064: Wed Jun >> 22 00:25:52 BRT 2016 >> ota@squitch:/root/workdir/crochet/work/obj/arm.armv6/usr/src/sys/BEAGLEBONE >> arm >> >> when I run 'service netif restart' on a beaglebone black using urtwn >> driver. Look bellow: >> >> root@beaglebone:/usr/home/ota # service netif restart >> dhclient not running? (check /var/run/dhclient.cpsw0.pid). >> Jun 22 17:53:18 beaglebone dhclient[782]: My address (192.168.0.11) was >> deleted, dhclient exiting >> Jun 22 17:53:18 beaglebone dhclient[730]: connection closed >> Jun 22 17:53:18 beaglebone dhclient[730]: exiting. >> Stopping wpa_supplicant. >> Jun 22 17:53:19 beaglebone wpa_supplicant[350]: ioctl[SIOCS80211, op=20, >> val=0, arg_len=7]: Can't assign requested address >> dhclient not running? (check /var/run/dhclient.wlan0.pid). >> Stopping Network: lo0 cpsw0 wlan0. >> lo0: flags=8048 metric 0 mtu 16384 >> options=600003 >> groups: lo >> nd6 options=21 >> cpsw0: flags=8c02 metric 0 mtu 1500 >> options=8000b >> ether 90:59:af:4c:20:9a >> media: Ethernet autoselect (none) >> status: no carrier >> nd6 options=29 >> wlan0: flags=8802 metric 0 mtu 1500 >> ether 14:cc:20:12:ee:55 >> groups: wlan >> ssid "" channel 11 (2462 MHz 11g) >> regdomain FCC country US authmode OPEN privacy OFF txpower 30 >> bmiss 7 >> scanvalid 60 protmode CTS wme >> media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) >> status: no carrier >> nd6 options=29 >> Fatal kernel mode data abort: 'Translation Fault (L2)' on read >> trapframe: 0xde3abba0 >> FSR=00000007, FAR=00000014, spsr=20000013 >> r0 =00000000, r1 =00000000, r2 =c06f1fa6, r3 =000003aa >> r4 =c31fc000, r5 =c06f1fa6, r6 =c2fe84b8, r7 =c2fe6000 >> r8 =c2fec000, r9 =00000016, r10=c2fec008, r11=de3abc70 >> r12=c08b6ca0, ssp=de3abc30, slr=c31941e4, pc =c0484744 >> >> [ thread pid 1273 tid 100074 ] >> Stopped at if_detach+0x28: ldr r4, [r0, #0x014] >> db> >> >> >> []'s >> >> -Otacílio >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Thu Jun 23 16:06:52 2016 Return-Path: Delivered-To: freebsd-arm@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 A27DDAC5D46; Thu, 23 Jun 2016 16:06:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 6D673182F; Thu, 23 Jun 2016 16:06:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x22b.google.com with SMTP id f30so75564083ioj.2; Thu, 23 Jun 2016 09:06:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=u7evnsm2K1fuFJ86z08kS9qTmh2i75N5wPd9kOczwx0=; b=ireE66i5CrvGLQZONAQSAeuIvIR5OabBhC0sByBuPjpQ6puHCY/BvuNFvOe4JHR7B6 5LXW1p6xz0UWxpnQ623C+Ng8oVF2V/SpH4ai03jvj7Hgeakw6p3kqnGbvGw4Zb/3LLwZ tcA6iVlbdgHZsT44zWA89VCnlYvR0WSf2Qlg0XIZFDp6J6g5j2vh1jksxQCgLDECTv+g 7Vg3s5Do4LnRoG++rm8Z88XKz2OmJh3oqLrdTvChAmjHpwG2RO4PfTrb6oX0VEIyiQ75 vDBJyMuv3VqJYymFn+GZNRG8vUBYAljr7WaBd6D0vCgnAvxvHpJNZpoMSgCSylCudBPy tTkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=u7evnsm2K1fuFJ86z08kS9qTmh2i75N5wPd9kOczwx0=; b=JS19CycyduFMdSQckWO2PBoGTD/JLF0I6O4OTHk/kRK8LjTMHTqKA8DGBlnuVTpQuY X6tbt2eHMknWi/ZhO+8z1Ypp6KDlJ40Aeco9lWKtdy0KDfdDo1sCnhmD3W549NVJzY0o EPskB1ypGFGNVf9wfQDwU+REwfW0x9vPNA2Go8Ifk5Inqva3jEbDbh5WpbY1/qsGu8bp Xczq23l6gccTucMR/E/Cg/fyGanPd5a+JQD3KLzaIdHkECDfdN9LjGYfKiR9vLD4GVM1 EtlQVFK6eYpbavksakwiRk06FdOK4oSU7gYzzHQKxurfIy7DL0azDQ8uJh7s2kCEeSHo SMtw== X-Gm-Message-State: ALyK8tKgFRm0sj7JTTHjGic3f01GiQRvTrke3gQbTm68qh7Agu9dhFF9QR9oEFjslaauDbzWm9EKi3w5EjzrWQ== X-Received: by 10.107.144.86 with SMTP id s83mr1532122iod.165.1466698011582; Thu, 23 Jun 2016 09:06:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.210.212 with HTTP; Thu, 23 Jun 2016 09:06:50 -0700 (PDT) In-Reply-To: <8751579c-68ae-7330-eb9b-c67d84ae18db@bsd.com.br> References: <8751579c-68ae-7330-eb9b-c67d84ae18db@bsd.com.br> From: Adrian Chadd Date: Thu, 23 Jun 2016 09:06:50 -0700 Message-ID: Subject: Re: Poor performance when using urtwn on beaglebone black To: =?UTF-8?B?T3RhY8OtbGlv?= Cc: "freebsd-arm@freebsd.org" , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 16:06:52 -0000 which urtwn is it? can you do a dmesg | grep urtwn? I'd like to see which NIC it is and whether firmware rate control is workin= g. Thanks, -adrian On 22 June 2016 at 10:52, Otac=C3=ADlio wrote: > Dears > > I'm getting poor performance when using wifi by urtwn on beaglebone black= . > I'm using netperf to do benchmarks and I'm getting less than 1Mbps normal= ly > and between 3Mbps and 7.5Mbps when creating the interface with -ht option= . I > think that previous versions has better performance. > > FreeBSD beaglebone 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #0 r302064: Wed Jun 22 > 00:25:52 BRT 2016 > ota@squitch:/root/workdir/crochet/work/obj/arm.armv6/usr/src/sys/BEAGLEBO= NE > arm > > []'s > > -Otac=C3=ADlio > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Thu Jun 23 16:23:32 2016 Return-Path: Delivered-To: freebsd-arm@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 5CC00B730AE for ; Thu, 23 Jun 2016 16:23:32 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 021101978 for ; Thu, 23 Jun 2016 16:23:31 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-vk0-x229.google.com with SMTP id d185so113622593vkg.0 for ; Thu, 23 Jun 2016 09:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=MCmFJPm0c/JcXADKYzvW7+m8rbBlOK2JVf3AxJj+Fiw=; b=fkaOklH5a/ZJDD+81abz1OfE/gUk59YKZs18PRWaqVbLP3WID8SL5usWRlTsdb9/q+ GZ3QJ+O/NiJkdHmX3gadPqeDdV++mhScyNWINeZaH4vg+LIPWCIx25p3GJp1kr1bcBIm TW/TFNd9MolPMmBJlkJx9M0twNBmCBNRDx74Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=MCmFJPm0c/JcXADKYzvW7+m8rbBlOK2JVf3AxJj+Fiw=; b=fNHMWSVgFqZADUZQKV7KeaXNs60QfL07XeNLfvR6DwwDXgv0NYojUWdrbgO8m2MZtt RCXkTGKp0LSboJ21z4FzEGjQdI1BgsGG8cnBSxi/pnonB7UiBbflTecsjS3PDqa+hop7 UFWSPb/8D3LVUiKnI458gAA1vW9RyfV9JTpmjKeeKN2uLDUpc6bEB+WkQ1u5LWGJt1g3 1Lqw7obpW3Ix2WDqmqVqTNCV0jGQS8fX7OyLBIRd5eYTxabRcg4jzbNXROeP73ZbC9Ww Izr7TvpHBhkYOQbcYsBATrypIIfSEC6biKPe4eXtCDSKh7zDVWQToINY5N+isANHDGnl Ff+A== X-Gm-Message-State: ALyK8tLAf7YbzdTXnL+5ciVNH/YdeZVHcwLUA01jesLGVWZDHt+nGPG4+WY8NCw1ENospw== X-Received: by 10.176.64.166 with SMTP id i35mr15842168uad.105.1466699010796; Thu, 23 Jun 2016 09:23:30 -0700 (PDT) Received: from [192.168.0.18] ([187.60.94.34]) by smtp.googlemail.com with ESMTPSA id 48sm323725uat.9.2016.06.23.09.23.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jun 2016 09:23:30 -0700 (PDT) Subject: Re: Poor performance when using urtwn on beaglebone black To: Adrian Chadd References: <8751579c-68ae-7330-eb9b-c67d84ae18db@bsd.com.br> Cc: "freebsd-arm@freebsd.org" , "freebsd-hackers@freebsd.org" From: =?UTF-8?B?T3RhY8OtbGlv?= Message-ID: <9688c9e7-3619-82ef-a10e-00ef97d435c4@bsd.com.br> Date: Thu, 23 Jun 2016 13:23:27 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 16:23:32 -0000 I did the tests with two adapters. Bellow RTL8192CU poor performance % dmesg | grep urtwn urtwn0: on usbus1 urtwn0: MAC/BB RTL8192CU, RF 6052 2T2R urtwn0: enabling 11n % netperf -H squitch MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to squitch () port 0 AF_INET : histogram : interval : dirty data : demo Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 65536 32768 32768 10.72 1.06 good performance (after create the interface using -ht) % dmesg | grep urtwn urtwn0: on usbus1 urtwn0: MAC/BB RTL8192CU, RF 6052 2T2R urtwn0: enabling 11n % netperf -H squitch MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to squitch () port 0 AF_INET : histogram : interval : dirty data : demo Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 65536 32768 32768 10.16 7.41 ===================================================================================== poor performance for RTL8188CUS % dmesg | grep urtwn urtwn0: on usbus1 urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R urtwn0: enabling 11n % netperf -H squitch MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to squitch () port 0 AF_INET : histogram : interval : dirty data : demo Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 65536 32768 32768 14.03 0.02 good performance (after create the interface using -ht) urtwn0: on usbus1 urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R urtwn0: enabling 11n % netperf -H squitch MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to squitch () port 0 AF_INET : histogram : interval : dirty data : demo Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 65536 32768 32768 10.15 5.81 Em 23/06/2016 13:06, Adrian Chadd escreveu: > which urtwn is it? can you do a dmesg | grep urtwn? > > I'd like to see which NIC it is and whether firmware rate control is working. > > Thanks, > > > > -adrian > > > On 22 June 2016 at 10:52, Otacílio wrote: >> Dears >> >> I'm getting poor performance when using wifi by urtwn on beaglebone black. >> I'm using netperf to do benchmarks and I'm getting less than 1Mbps normally >> and between 3Mbps and 7.5Mbps when creating the interface with -ht option. I >> think that previous versions has better performance. >> >> FreeBSD beaglebone 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #0 r302064: Wed Jun 22 >> 00:25:52 BRT 2016 >> ota@squitch:/root/workdir/crochet/work/obj/arm.armv6/usr/src/sys/BEAGLEBONE >> arm >> >> []'s >> >> -Otacílio >> >> >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Thu Jun 23 16:28:09 2016 Return-Path: Delivered-To: freebsd-arm@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 479EFB73429; Thu, 23 Jun 2016 16:28:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 1183527B1; Thu, 23 Jun 2016 16:28:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-it0-x230.google.com with SMTP id g127so3550055ith.1; Thu, 23 Jun 2016 09:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=6smSpgiO0a+prCsH1gSTgnBcHU5IhwQsj2/uTRkqWSk=; b=O4a6hwSQY1UeyksOmOXOjedUWWdu//zBgP08GktX0FuZAkS1wLxEq8Bv5oCqOzuHET dei8KCgqQZVqduUInNyAR4kBuWu6R00MCt4rokgsoi+Glw/ZIHGPzD6XQ3w4Ikk5U7Po B/6LDLX/Xb3rSkHl820TMdPyJPxHrekmiqmvXyIJPXfaTb/aqzQwKJSmONKcEEjXGg2+ asXehCJ+XAzRixE0LvtVKjSkiHKoixal1+99OfvLpuEnobEexJDw95pmquon2b+wZ/X0 Mn0bdtFq5AufghvpZV5YhMoOjloXpcUH25fd5kZ2ogLLCxpRQrHXJ2Boudg9ODTlCUBm S0jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=6smSpgiO0a+prCsH1gSTgnBcHU5IhwQsj2/uTRkqWSk=; b=OtQ4xcxNUnmFvokedslIO3rrlGEKpaPw7XEhV9uau04bBlOKRmzMWcP1ZrU3eb0r5d CjvCncbbJwje5Cd+362KFbsM2uj9pypRmPrzFrPLPZKnqKJQH/ByJtGJvdTKl+U/AjS8 nfropjSexe02oS2d/IOCvdsbO1960cytOuRlC2OgJjRAugstwTS11BHyKNnZg+0s59q7 2M0U3T/mdECer+1WV78QrSozl2DTmi5Spa4/Kbyzh7fKNywi0q3p7c9ub3RietXCiTg3 Eit4lZRIHOYJpa8nzxYGZtvEFBQYveGdbvWNW9P6L3Z3wR2FyUGYA1MUkoeNk3O/A8ai eSzA== X-Gm-Message-State: ALyK8tIcCQPjLwlMYZiCuKNekLzplfaFIBAddll/ZShPl3vWieqiA9qYeEVkJN63RhvCOg7F2OrvBrPUDSoAYw== X-Received: by 10.36.200.131 with SMTP id w125mr1662838itf.80.1466699288138; Thu, 23 Jun 2016 09:28:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.210.212 with HTTP; Thu, 23 Jun 2016 09:28:07 -0700 (PDT) In-Reply-To: <9688c9e7-3619-82ef-a10e-00ef97d435c4@bsd.com.br> References: <8751579c-68ae-7330-eb9b-c67d84ae18db@bsd.com.br> <9688c9e7-3619-82ef-a10e-00ef97d435c4@bsd.com.br> From: Adrian Chadd Date: Thu, 23 Jun 2016 09:28:07 -0700 Message-ID: Subject: Re: Poor performance when using urtwn on beaglebone black To: =?UTF-8?B?T3RhY8OtbGlv?= Cc: "freebsd-arm@freebsd.org" , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 16:28:09 -0000 Hm, okay. I'll go try and reproduce this locally. can you do an 'ifconfig -v wlan0 list scan' and 'ifconfig -v wlan0 list sta' and privately email it to me? That way I can try to see what environment you have. the 2x2 NICs don't do rate control at the moment, so I bet part of the problem there is the default fixed value is terrible :( -adrian On 23 June 2016 at 09:23, Otac=C3=ADlio wrote: > I did the tests with two adapters. Bellow RTL8192CU > > poor performance > % dmesg | grep urtwn > urtwn0: = on > usbus1 > urtwn0: MAC/BB RTL8192CU, RF 6052 2T2R > urtwn0: enabling 11n > % netperf -H squitch > MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to squitch () por= t 0 > AF_INET : histogram : interval : dirty data : demo > Recv Send Send > Socket Socket Message Elapsed > Size Size Size Time Throughput > bytes bytes bytes secs. 10^6bits/sec > > 65536 32768 32768 10.72 1.06 > > good performance (after create the interface using -ht) > % dmesg | grep urtwn > urtwn0: = on > usbus1 > urtwn0: MAC/BB RTL8192CU, RF 6052 2T2R > urtwn0: enabling 11n > % netperf -H squitch > MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to squitch () por= t 0 > AF_INET : histogram : interval : dirty data : demo > Recv Send Send > Socket Socket Message Elapsed > Size Size Size Time Throughput > bytes bytes bytes secs. 10^6bits/sec > > 65536 32768 32768 10.16 7.41 > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > poor performance for RTL8188CUS > > % dmesg | grep urtwn > urtwn0: = on > usbus1 > urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R > urtwn0: enabling 11n > % netperf -H squitch > MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to squitch () por= t 0 > AF_INET : histogram : interval : dirty data : demo > Recv Send Send > Socket Socket Message Elapsed > Size Size Size Time Throughput > bytes bytes bytes secs. 10^6bits/sec > > 65536 32768 32768 14.03 0.02 > > > good performance (after create the interface using -ht) > urtwn0: = on > usbus1 > urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R > urtwn0: enabling 11n > % netperf -H squitch > MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to squitch () por= t 0 > AF_INET : histogram : interval : dirty data : demo > Recv Send Send > Socket Socket Message Elapsed > Size Size Size Time Throughput > bytes bytes bytes secs. 10^6bits/sec > > 65536 32768 32768 10.15 5.81 > > > Em 23/06/2016 13:06, Adrian Chadd escreveu: >> >> which urtwn is it? can you do a dmesg | grep urtwn? >> >> I'd like to see which NIC it is and whether firmware rate control is >> working. >> >> Thanks, >> >> >> >> -adrian >> >> >> On 22 June 2016 at 10:52, Otac=C3=ADlio wrote= : >>> >>> Dears >>> >>> I'm getting poor performance when using wifi by urtwn on beaglebone >>> black. >>> I'm using netperf to do benchmarks and I'm getting less than 1Mbps >>> normally >>> and between 3Mbps and 7.5Mbps when creating the interface with -ht >>> option. I >>> think that previous versions has better performance. >>> >>> FreeBSD beaglebone 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #0 r302064: Wed Jun = 22 >>> 00:25:52 BRT 2016 >>> >>> ota@squitch:/root/workdir/crochet/work/obj/arm.armv6/usr/src/sys/BEAGLE= BONE >>> arm >>> >>> []'s >>> >>> -Otac=C3=ADlio >>> >>> >>> _______________________________________________ >>> freebsd-arm@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > > From owner-freebsd-arm@freebsd.org Thu Jun 23 22:15:42 2016 Return-Path: Delivered-To: freebsd-arm@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 023B7B74A41 for ; Thu, 23 Jun 2016 22:15:41 +0000 (UTC) (envelope-from lausts@laus.org) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.228]) by mx1.freebsd.org (Postfix) with ESMTP id B7D67221B for ; Thu, 23 Jun 2016 22:15:41 +0000 (UTC) (envelope-from lausts@laus.org) Received: from [173.88.10.122] ([173.88.10.122:47148] helo=mail.laus.org) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id AC/67-30907-FEB5C675; Thu, 23 Jun 2016 22:00:16 +0000 Received: from mail.laus.org (localhost [127.0.0.1]) by mail.laus.org (8.15.2/8.15.2) with ESMTPS id u5NM0FuW073788 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 23 Jun 2016 18:00:15 -0400 (EDT) (envelope-from lausts@laus.org) Received: (from lausts@localhost) by mail.laus.org (8.15.2/8.15.2/Submit) id u5NM0EtD073787 for freebsd-arm@freebsd.org; Thu, 23 Jun 2016 18:00:14 -0400 (EDT) (envelope-from lausts) Date: Thu, 23 Jun 2016 18:00:14 -0400 From: Thomas Laus To: freebsd-arm@freebsd.org Subject: 'urtwn' & 'urtwnfw' Devices Unknown in r302145 Message-ID: <20160623220014.GA73746@mail.laus.org> Reply-To: lausts@acm.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 10.3-RELEASE-p5 on an amd64 User-Agent: Mutt/1.6.1 (2016-04-27) X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 22:15:42 -0000 Group: I have seen recent activity in using the urtwn USB WiFi device and thought that I would try using it again. Both of these devices are unknown when including them in a custom kernel for both the amd64 and arm arch, though the man page for urtwn says they should be. This device seems to work on my FreeBSD 10.3 Release machine. I only have a problem with building a BBB-WiFi kernel on FreeBSD Current and also building one for the amd64 arch using the same rev. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From owner-freebsd-arm@freebsd.org Thu Jun 23 22:53:03 2016 Return-Path: Delivered-To: freebsd-arm@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 24F89B7366C for ; Thu, 23 Jun 2016 22:53:03 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (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 ED9541E1A for ; Thu, 23 Jun 2016 22:53:02 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 5DACD21EA72 for ; Thu, 23 Jun 2016 17:45:45 -0500 (CDT) Subject: Re: 'urtwn' & 'urtwnfw' Devices Unknown in r302145 To: freebsd-arm@freebsd.org References: <20160623220014.GA73746@mail.laus.org> From: Karl Denninger Message-ID: Date: Thu, 23 Jun 2016 17:45:45 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160623220014.GA73746@mail.laus.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms080106080105010807000302" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 22:53:03 -0000 This is a cryptographically signed message in MIME format. --------------ms080106080105010807000302 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 6/23/2016 17:00, Thomas Laus wrote: > Group: > > I have seen recent activity in using the urtwn USB WiFi device and > thought that I would try using it again. Both of these devices are > unknown when including them in a custom kernel for both the amd64 > and arm arch, though the man page for urtwn says they should > be. This device seems to work on my FreeBSD 10.3 Release machine. > I only have a problem with building a BBB-WiFi kernel on FreeBSD > Current and also building one for the amd64 arch using the same rev. > > Tom > No problems here.... % uname -v FreeBSD 11.0-ALPHA4 #0 r302111M: Thu Jun 23 00:43:44 CDT 2016 =20 karl@NewFS.denninger.net:/pics/CrossBuild/obj/arm.armv6/pics/CrossBuild/s= rc/sys/RPI2 =2E... random: unblocking device. smsc0: chip 0xec00, rev. 0002 ue0: link state changed to DOWN ue0: link state changed to UP urtwn0: on usbus0 urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R urtwn0: enabling 11n wlan0: Ethernet address: 74:da:38:59:ec:93 wlan0: ieee80211_new_state_locked: pending INIT -> SCAN transition lost wlan0: link state changed to UP --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms080106080105010807000302 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA2MjMyMjQ1NDVaME8GCSqGSIb3DQEJBDFCBEAI UiivIS3Qo/69gNMg+a54qT3AoWAEob9UrwOf9Dchg73m/26zxbkHKY6QFvRHiCw98qiX+Pcx f3RGm4Nkewg7MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAqCJ7W15v H3lnXMKNCcavbQt8IgTMMYo2gg8Ti4nEKii3QrvI04gx2AqZiSUcOfhmi7rNHY0ek88EllPx g+EPYfFTibSeOVy39o0T1+dJNn4zdmRhWdGGVrVe9DhllFFsbOZJjTDOkM7I/Zl3jE9SYJJ5 8I9Z0GbII02QyIF2dBbHxMJY+eOBXtEVu23IvzIl370O+SUspWehRw/NAXDbQFMYtcQKe+Zo 0dfnmFkaIHB+v7KJ1UziIv8Q+hegCSMaWgrsrafFrppWc1lJQR6F6Bi7mFx0veq1RZqcKcUo nehc3vR0OGb3qq7t5nfIQpritaDPirruCnEyDGCBS8hdjSNommEOUw4dEA6iXrpXImxbcOpV VT6X+Ao4juSm477NxBuHmWzYqIutWFIm/nzRz7c6XbfFbt4zF9Byg6fc52oVUyE1Eq6P42+5 Y4sOAN6XJ4gHMIo5X0HkGEtAxB+m2o8RhJuCGqq9PbjvE0NW//mpteqWmj8fItRZfG1bREP2 sg1Lj5jkdbsbEi3usqgmeH9lKrISGYsjtbmgQ3n/1m2O6B5pMwilB+GRFxYzW/QDljZOuNZa rOYnzoXbWO3OLwiM9VrEm2CsUZ28IqNY0rJ3k5JEXRrMXP1zxAqvbCsPFFJjCP3ZLm0ca2Us K3ejIUle88d7jlbRiSFDjS0zyjMAAAAAAAA= --------------ms080106080105010807000302-- From owner-freebsd-arm@freebsd.org Fri Jun 24 09:49:20 2016 Return-Path: Delivered-To: freebsd-arm@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 00779B8052E for ; Fri, 24 Jun 2016 09:49:20 +0000 (UTC) (envelope-from erich@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) (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 D7FA524B4 for ; Fri, 24 Jun 2016 09:49:19 +0000 (UTC) (envelope-from erich@alogt.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References: In-Reply-To:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=GjN31bnkuh7EkqTUMf3ZrgmjNPm2IEgxG5NVIfmhumo=; b=TfH12S36HLNRGb8G1cyd1dyXPj j/VZ1tczK9QMavND7TPANa+qnm+26pUZfnRejGaDaQu35hkNcKMlCF4LEPdl6V3pO+3vglB9+ceuy rSKbLg6quboErshQCPvbs6tIP9lse4Xr/8lGpdr61za6tkC5bcflFIsMu4gBJ5vn/zRQ=; Received: from [114.120.239.138] (port=47514 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1bGNjc-000hjT-KF; Fri, 24 Jun 2016 03:49:13 -0600 Date: Fri, 24 Jun 2016 17:49:06 +0800 From: Erich Dollansky To: Tom Vijlbrief Cc: freebsd-arm Subject: Re: Compiling HEAD on a Raspberry Pi B+ 2 failes Message-ID: <20160624174906.6037a05e@X220.alogt.com> In-Reply-To: References: <20160618072747.6c6d4328@X220.alogt.com> Organization: ALO Green Technologies MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erich@alogt.com X-Authenticated-Sender: sl-508-2.slc.westdc.net: erich@alogt.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 09:49:20 -0000 Hi, it compiled meanwhile. It took so long as there was another minor problem outside the Raspberry here. Thanks! Erich On Mon, 20 Jun 2016 05:57:07 +0000 Tom Vijlbrief wrote: > This is an issue from early this year. > > See > > freebsd-toolchain/2016-January/001906.html > > For a fix > > Tom > > Op za 18 jun. 2016 01:28 schreef Erich Dollansky : > > > Hi, > > > > I am trying to compile HEAD on a Raspberry and get always the > > following error. > > > > Erich > > > > Last Changed Rev: 301974 > > > > /usr/src/lib/csu/arm/crt1.c:(.text+0xb4): relocation truncated to > > fit: R_ARM_CALL against symbol `atexit' defined in .text section > > in /usr/lib/libc.a(atexit.o) /usr/src/lib/csu/arm/crt1.c:(.text+0xbc): > > relocation truncated to fit: R_ARM_CALL against symbol `_init_tls' > > defined in .text section > > in /usr/lib/libc.a(tls.o) /usr/src/lib/csu/arm/crt1.c:(.text+0xcc): > > relocation truncated to fit: R_ARM_CALL against symbol `atexit' > > defined in .text section > > in /usr/lib/libc.a(atexit.o) /usr/src/lib/csu/arm/crt1.c:(.text+0x174): > > relocation truncated to fit: R_ARM_CALL against symbol `exit' > > defined in .text section > > in /usr/lib/libc.a(exit.o) /usr/lib/crt1.o: In function > > `finalizer': /usr/src/lib/csu/arm/crt1.c:(.text+0x1ec): relocation > > truncated to fit: R_ARM_JUMP24 against symbol `_fini' defined > > in .fini section in /usr/lib/crti.o c++: error: linker command > > failed with exit code 1 (use -v to see invocation) *** Error code 1 > > > > Stop. > > bmake[4]: stopped in /usr/src.head/usr.bin/clang/clang > > *** Error code 1 > > > > Stop. > > bmake[3]: stopped in /usr/src.head/usr.bin/clang > > *** Error code 1 > > > > Stop. > > bmake[2]: stopped in /usr/src.head > > *** Error code 1 > > > > Stop. > > bmake[1]: stopped in /usr/src.head > > *** Error code 1 > > > > Stop. > > make: stopped in /usr/src.head > > [raspberry2]~/System (root) > > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to > > "freebsd-arm-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Fri Jun 24 09:56:02 2016 Return-Path: Delivered-To: freebsd-arm@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 56AE8B8065F for ; Fri, 24 Jun 2016 09:56:02 +0000 (UTC) (envelope-from iz-rpi03@hs-karlsruhe.de) Received: from smtp.hs-karlsruhe.de (smtp.HS-Karlsruhe.DE [193.196.64.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 106BE2789 for ; Fri, 24 Jun 2016 09:56:01 +0000 (UTC) (envelope-from iz-rpi03@hs-karlsruhe.de) Received: from iz-wera01.hs-karlsruhe.de ([193.196.65.46]) by smtp.hs-karlsruhe.de with esmtp (Exim 4.80.1) (envelope-from ) id 1bGNqB-0096kk-EF; Fri, 24 Jun 2016 11:55:59 +0200 X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 From: Ralf Wenk To: lausts@acm.org cc: FreeBSD ARM Subject: Re: 'urtwn' & 'urtwnfw' Devices Unknown in r302145 In-reply-to: <20160623220014.GA73746@mail.laus.org> References: <20160623220014.GA73746@mail.laus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Jun 2016 11:55:59 +0200 Message-Id: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 09:56:02 -0000 At Thu, 23 Jun 2016 18:00:14 -0400, Thomas Laus wrote: > Group: > > I have seen recent activity in using the urtwn USB WiFi device and > thought that I would try using it again. Both of these devices are > unknown when including them in a custom kernel for both the amd64 > and arm arch, though the man page for urtwn says they should > be. This device seems to work on my FreeBSD 10.3 Release machine. > I only have a problem with building a BBB-WiFi kernel on FreeBSD > Current and also building one for the amd64 arch using the same rev. > > Tom All examples are from an "old" RaspberryPi. Are the needed kernel modules missing? $ ls /boot/kernel/wlan* /boot/kernel/urtwn* /boot/kernel/urtwn-rtl8188eufw.ko /boot/kernel/wlan_ccmp.ko /boot/kernel/urtwn-rtl8192cfwT.ko /boot/kernel/wlan_rssadapt.ko /boot/kernel/urtwn-rtl8192cfwU.ko /boot/kernel/wlan_tkip.ko /boot/kernel/wlan.ko /boot/kernel/wlan_wep.ko /boot/kernel/wlan_acl.ko /boot/kernel/wlan_xauth.ko /boot/kernel/wlan_amrr.ko $ Or are they not loaded? $ kldstat Id Refs Address Size Name 1 19 0xc0100000 87ede8 kernel 2 1 0xc097f000 22620 if_urtwn.ko 3 2 0xc09a2000 b234 firmware.ko 4 6 0xc09ae000 6067c wlan.ko 5 1 0xc0a0f000 a1c8 wlan_amrr.ko 6 1 0xc2c1a000 a000 wlan_wep.ko 7 1 0xc2c4d000 b000 wlan_tkip.ko 8 1 0xc2c5d000 e000 wlan_ccmp.ko $ If they are missing you have to build and install a new kernel with a extended configuration. In my old RPi kernel configuration I use in one line: makeoptions MODULES_OVERRIDE="wlan wlan_ccmp wlan_tkip wlan_wep wlan_amrr wlan_rssadapt wlan_xauth wlan_acl urtwn urtwnfw firmware" I am unsure about the "MODULES_EXTRA" line. May be you should just add the missing drivers there. Ralf From owner-freebsd-arm@freebsd.org Fri Jun 24 13:21:06 2016 Return-Path: Delivered-To: freebsd-arm@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 5AF91B72A73 for ; Fri, 24 Jun 2016 13:21:06 +0000 (UTC) (envelope-from lausts@acm.org) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.226]) by mx1.freebsd.org (Postfix) with ESMTP id 239861163 for ; Fri, 24 Jun 2016 13:21:05 +0000 (UTC) (envelope-from lausts@acm.org) Received: from [173.88.10.122] ([173.88.10.122:21986] helo=mail.laus.org) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 64/E1-30907-0C33D675; Fri, 24 Jun 2016 13:21:04 +0000 Received: from [192.168.1.100] (thinkpad [192.168.1.100]) by mail.laus.org (8.15.2/8.15.2) with ESMTPS id u5ODL2pA077243 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 24 Jun 2016 09:21:04 -0400 (EDT) (envelope-from lausts@acm.org) X-Authentication-Warning: mail.laus.org: Host thinkpad [192.168.1.100] claimed to be [192.168.1.100] From: "Thomas Laus" Organization: ABB To: Ralf Wenk , FreeBSD ARM Date: Fri, 24 Jun 2016 09:20:57 -0400 Subject: Re: 'urtwn' & 'urtwnfw' Devices Unknown in r302145 Reply-to: lausts@acm.org Message-ID: <576D33B9.19054.E2ECD@lausts.acm.org> Priority: normal In-reply-to: References: <20160623220014.GA73746@mail.laus.org>, X-mailer: Pegasus Mail for Windows (4.70) X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 13:21:06 -0000 Ralf Wenk > > All examples are from an "old" RaspberryPi. > Are the needed kernel modules missing? > > $ ls /boot/kernel/wlan* /boot/kernel/urtwn* > > > /boot/kernel/urtwn-rtl8188eufw.ko /boot/kernel/wlan_ccmp.ko > /boot/kernel/urtwn-rtl8192cfwT.ko /boot/kernel/wlan_rssadapt.ko > /boot/kernel/urtwn-rtl8192cfwU.ko /boot/kernel/wlan_tkip.ko > /boot/kernel/wlan.ko /boot/kernel/wlan_wep.ko > /boot/kernel/wlan_acl.ko /boot/kernel/wlan_xauth.ko > /boot/kernel/wlan_amrr.ko > $ > > Or are they not loaded? > > $ kldstat > Id Refs Address Size Name > 1 19 0xc0100000 87ede8 kernel > 2 1 0xc097f000 22620 if_urtwn.ko > 3 2 0xc09a2000 b234 firmware.ko > 4 6 0xc09ae000 6067c wlan.ko > 5 1 0xc0a0f000 a1c8 wlan_amrr.ko > 6 1 0xc2c1a000 a000 wlan_wep.ko > 7 1 0xc2c4d000 b000 wlan_tkip.ko > 8 1 0xc2c5d000 e000 wlan_ccmp.ko > $ > > If they are missing you have to build and install a new kernel with > a extended configuration. > > In my old RPi kernel configuration I use in one line: > > makeoptions MODULES_OVERRIDE="wlan wlan_ccmp wlan_tkip wlan_wep > wlan_amrr wlan_rssadapt wlan_xauth wlan_acl urtwn urtwnfw firmware" > > I am unsure about the "MODULES_EXTRA" line. May be you should just add > the missing drivers there. > The modules are not being built at all with a kernel build because they are not being found by the build script. I have this problem on both my amd64 and arm computers. I just performed a fresh checkout of my source tree and compared the location of the urtwn and urtwnfw files on my FreeBSD 10 Release and FreeBSD 11 computers. I am including the logs from the run on the amd4 computer because it builds faster than my BeagleBone. The results are the same. -------------------------------------------------------------- >>> Kernel build for FBSD11 started on Fri Jun 24 09:00:23 EDT 2016 -------------------------------------------------------------- ===> FBSD11 mkdir -p /usr/obj/usr/src/sys -------------------------------------------------------------- >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /usr/src/sys/amd64/conf; PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin: /usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src /tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin config -d /usr/obj/usr/src/sys/FBSD11 -I '/usr/src/sys/amd64/conf' ' /usr/src/sys/amd64/conf/FBSD11' config: Error: device "urtwn" is unknown config: Error: device "urtwnfw" is unknown config: 2 errors *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src root@zfs:/usr/src # ---- FreeBSD 10.3-RELEASE-p5 (FBSD10) #12: Sat Jun 4 11:35:09 EDT 2016 FBSD10 >find /usr/src -name "*urtwn*" /usr/src/sys/contrib/dev/urtwn /usr/src/sys/contrib/dev/urtwn/urtwn-rtl8192cfwU.fw.uu /usr/src/sys/contrib/dev/urtwn/urtwn-rtl8192cfwT.fw.uu /usr/src/sys/contrib/dev/urtwn/urtwn-rtl8188eufw.fw.uu /usr/src/sys/modules/usb/urtwn /usr/src/sys/modules/usb/urtwnfw /usr/src/sys/modules/usb/urtwnfw/urtwnrtl8192cT /usr/src/sys/modules/usb/urtwnfw/urtwnrtl8192cU /usr/src/sys/modules/usb/urtwnfw/urtwnrtl8188eu /usr/src/sys/dev/usb/wlan/if_urtwnreg.h /usr/src/sys/dev/usb/wlan/if_urtwn.c /usr/src/share/man/man4/urtwnfw.4 /usr/src/share/man/man4/urtwn.4 --- FreeBSD 11.0-ALPHA4 (FBSD11) #0 r302145: Thu Jun 23 16:18:41 EDT 2016 FBSD11 >find /usr/src -name "*urtwn*" /usr/src/sys/modules/urtwn /usr/src/sys/modules/urtwnfw /usr/src/sys/modules/urtwnfw/urtwnrtl8188eu /usr/src/sys/modules/urtwnfw/urtwnrtl8192cT /usr/src/sys/modules/urtwnfw/urtwnrtl8192cU /usr/src/sys/dev/urtwn /usr/src/sys/dev/urtwn/if_urtwn.c /usr/src/sys/dev/urtwn/if_urtwnvar.h /usr/src/sys/dev/urtwn/if_urtwnreg.h /usr/src/sys/contrib/dev/urtwn /usr/src/sys/contrib/dev/urtwn/urtwn-rtl8188eufw.fw.uu /usr/src/sys/contrib/dev/urtwn/urtwn-rtl8192cfwT.fw.uu /usr/src/sys/contrib/dev/urtwn/urtwn-rtl8192cfwU.fw.uu /usr/src/share/man/man4/urtwnfw.4 /usr/src/share/man/man4/urtwn.4 -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From owner-freebsd-arm@freebsd.org Fri Jun 24 18:49:49 2016 Return-Path: Delivered-To: freebsd-arm@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 8E99EAC404C for ; Fri, 24 Jun 2016 18:49:49 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6DBD520FF for ; Fri, 24 Jun 2016 18:49:49 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from [172.27.1.97] (unknown [172.27.1.97]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 3C7321BC for ; Fri, 24 Jun 2016 14:49:42 -0400 (EDT) From: Paul Mather Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Poudriere failing on some 10-STABLE ports --- "uses VFP register arguments" Message-Id: Date: Fri, 24 Jun 2016 14:49:41 -0400 To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 18:49:49 -0000 For a while I've been having trouble building ARM packages via = Poudriere. My setup running under a 10-STABLE host quit working = altogether, so I switched to an 11-CURRENT host. That works to build = both 11.x and 10.x FreeBSD/arm packages, however, in the case of the = 10.x packages I am having a couple of persistent failures: = lang/perl5.20; security/libgpg-error; and mail/postfix. All three are = flagged in the Poudriere build page as having "linker_error". The = linker error is always a complaint related to using "VFP register = arguments". E.g., the mail/postfix port complains thus: /nxb-bin/usr/bin/make -f Makefile.in MAKELEVEL=3D Makefiles (echo "# Do not edit -- this file documents how Postfix was built for = your machine."; /bin/sh makedefs) >makedefs.tmp /nxb-bin/usr/bin/ld: ERROR: /tmp/makedefs-9bae49.o uses VFP register = arguments, makedefs.test does not /nxb-bin/usr/bin/ld: failed to merge target specific data of file = /tmp/makedefs-9bae49.o cc: error: linker command failed with exit code 1 (use -v to see = invocation) *** Error code 1 As I understand it, VFP relates to the "Vector Floating Point" = instructions of the ARM processor, so I presume this error is somehow = related to the switchover to hard float. Is anyone else experiencing a problem like this trying to build 10.x = FreeBSD/arm packages? If so, is there a fix? I have rebuilt the = Poudriere jail recently already. Cheers, Paul.= From owner-freebsd-arm@freebsd.org Fri Jun 24 18:56:25 2016 Return-Path: Delivered-To: freebsd-arm@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 B782AAC41C8 for ; Fri, 24 Jun 2016 18:56:25 +0000 (UTC) (envelope-from mikael.urankar@gmail.com) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 7270825B7 for ; Fri, 24 Jun 2016 18:56:25 +0000 (UTC) (envelope-from mikael.urankar@gmail.com) Received: by mail-qk0-x22a.google.com with SMTP id c73so156967727qkg.2 for ; Fri, 24 Jun 2016 11:56:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=jxPN6bzK4WswihnWZEcvtqPLbVPB9zJliQOx7OV4Lw0=; b=zH+z0JVE19qircYcSJbNOVHw2w4VzUTEWzSLCBDJAiVtFwZKOS/SXAWhUkjgs9LZD0 i7cD0/MOvpICWcoTjag3sOEYYHi2LCJc3rYj3cgaJ/PXbbInX2c7DX8BKHNd1Vq3v36s CwtxNVf3+ncinsdAf9FAx546haPfENoGfsvU4QNWWH3ghr7sHHRTZ3HoBserErwcP2tZ geI5LZrhZ9DOGdylk2xwBOdPfnVyQ/DCKhntwUD9icqJIjoPY+6M31+nwqSwcX56LDbR keEJo7IZnMYAVShmAkODbcy2z76Sju3n74nqqu4eqkB2f+UodeOMMHaAM5OUuAdz5eaS qR3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=jxPN6bzK4WswihnWZEcvtqPLbVPB9zJliQOx7OV4Lw0=; b=NddK61eLOXxN0uK6Iq3I61P5z9sHBHX34Aj/4Q0bYlTd/2tlwT0aL1A+sWNKYh5DQN rni1XddfqbEKRwoIIo9ps+yUGo6oUd534DYiuCsl4WeFLwx9bLZwu1Z3mdAVITXpu0BI WwB9xJuOK4B/Vm+n+ax1oGsrkCK8N6ZME9HCV0DfT6AmrEr+VseLmhqXD3r9ZlAghG/n qiHcobWnQiLeNCmergDoYb9nh1NJtmIj40OCeyCyaJ7aAhq+1hhjfmhuvMjGMrGBuy3L pAPhoX5xMvJ8S/NuxjXYR0VLC+7iNM8KjpHr2Gta1XjCZS0h3Z4ogXNCxAuyNIvq6ekn 3kvQ== X-Gm-Message-State: ALyK8tKfJlXtqI656Mu8AL0n3k8vpsf65iOxO4608CNraZA0juZgqmEG+3zx7gMOR+5hZ9acehZWs0OSFwS6cQ== X-Received: by 10.200.55.115 with SMTP id p48mr6603045qtb.15.1466794584316; Fri, 24 Jun 2016 11:56:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.35.148 with HTTP; Fri, 24 Jun 2016 11:55:43 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Mika=C3=ABl_Urankar?= Date: Fri, 24 Jun 2016 20:55:43 +0200 Message-ID: Subject: Re: Poudriere failing on some 10-STABLE ports --- "uses VFP register arguments" To: Paul Mather Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 18:56:25 -0000 2016-06-24 20:49 GMT+02:00 Paul Mather : > For a while I've been having trouble building ARM packages via Poudriere.= My setup running under a 10-STABLE host quit working altogether, so I swi= tched to an 11-CURRENT host. That works to build both 11.x and 10.x FreeBS= D/arm packages, however, in the case of the 10.x packages I am having a cou= ple of persistent failures: lang/perl5.20; security/libgpg-error; and mail/= postfix. All three are flagged in the Poudriere build page as having "link= er_error". The linker error is always a complaint related to using "VFP re= gister arguments". Hi, See https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013952.html From owner-freebsd-arm@freebsd.org Fri Jun 24 19:52:02 2016 Return-Path: Delivered-To: freebsd-arm@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 6A921B8023D for ; Fri, 24 Jun 2016 19:52:02 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 493B92235 for ; Fri, 24 Jun 2016 19:52:02 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from [172.27.1.97] (unknown [172.27.1.97]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id F3A0F1DE; Fri, 24 Jun 2016 15:52:00 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Poudriere failing on some 10-STABLE ports --- "uses VFP register arguments" From: Paul Mather In-Reply-To: Date: Fri, 24 Jun 2016 15:52:00 -0400 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <854D8FF8-CE45-44C1-B371-79AA6DD782FB@gromit.dlib.vt.edu> References: To: =?utf-8?Q?Mika=C3=ABl_Urankar?= X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 19:52:02 -0000 On Jun 24, 2016, at 2:55 PM, Mika=C3=ABl Urankar = wrote: > 2016-06-24 20:49 GMT+02:00 Paul Mather : >> For a while I've been having trouble building ARM packages via = Poudriere. My setup running under a 10-STABLE host quit working = altogether, so I switched to an 11-CURRENT host. That works to build = both 11.x and 10.x FreeBSD/arm packages, however, in the case of the = 10.x packages I am having a couple of persistent failures: = lang/perl5.20; security/libgpg-error; and mail/postfix. All three are = flagged in the Poudriere build page as having "linker_error". The = linker error is always a complaint related to using "VFP register = arguments". >=20 > Hi, > See = https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013952.html I had seen that thread but the fixes suggested (update the jail; update = QEMU) do not appear to work for my problem. I have: Poudriere host: FreeBSD/amd64 11.0-ALPHA4 r302140 Poudriere jail: 10.3-STABLE r302137 arm.armv6 QEMU package: qemu-user-static-2.6.50.g20160621 Note, I have no problems building FreeBSD/arm 11-CURRENT packages on = this Poudriere host, only 10-STABLE packages. Cheers, Paul.= From owner-freebsd-arm@freebsd.org Fri Jun 24 20:11:09 2016 Return-Path: Delivered-To: freebsd-arm@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 D5FBAB807E2 for ; Fri, 24 Jun 2016 20:11:09 +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 450152DE4 for ; Fri, 24 Jun 2016 20:11:08 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: c860f3de-3a47-11e6-ac92-3142cfe117f2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.eu.mailhop.org (Halon Mail Gateway) with ESMTPSA; Fri, 24 Jun 2016 20:11:05 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u5OKAtGs013921; Fri, 24 Jun 2016 14:10:55 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1466799055.72182.50.camel@freebsd.org> Subject: Re: Poudriere failing on some 10-STABLE ports --- "uses VFP register arguments" From: Ian Lepore To: Paul Mather , =?ISO-8859-1?Q?Mika=EBl?= Urankar Cc: "freebsd-arm@freebsd.org" Date: Fri, 24 Jun 2016 14:10:55 -0600 In-Reply-To: <854D8FF8-CE45-44C1-B371-79AA6DD782FB@gromit.dlib.vt.edu> References: <854D8FF8-CE45-44C1-B371-79AA6DD782FB@gromit.dlib.vt.edu> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 20:11:09 -0000 On Fri, 2016-06-24 at 15:52 -0400, Paul Mather wrote: > On Jun 24, 2016, at 2:55 PM, Mikaël Urankar > wrote: > > > 2016-06-24 20:49 GMT+02:00 Paul Mather : > > > For a while I've been having trouble building ARM packages via > > > Poudriere. My setup running under a 10-STABLE host quit working > > > altogether, so I switched to an 11-CURRENT host. That works to > > > build both 11.x and 10.x FreeBSD/arm packages, however, in the > > > case of the 10.x packages I am having a couple of persistent > > > failures: lang/perl5.20; security/libgpg-error; and mail/postfix. > > > All three are flagged in the Poudriere build page as having > > > "linker_error". The linker error is always a complaint related > > > to using "VFP register arguments". > > > > Hi, > > See https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013952 > > .html > > > I had seen that thread but the fixes suggested (update the jail; > update QEMU) do not appear to work for my problem. > > I have: > > Poudriere host: FreeBSD/amd64 11.0-ALPHA4 r302140 > Poudriere jail: 10.3-STABLE r302137 arm.armv6 > QEMU package: qemu-user-static-2.6.50.g20160621 > > > Note, I have no problems building FreeBSD/arm 11-CURRENT packages on > this Poudriere host, only 10-STABLE packages. > > Cheers, When you update the nxb-bin native crosstools (-x command in poudriere jail create) in the 10-stable jail, they are actually being built from /usr/src on your host, not the sources in the jail. This means you're getting hardfloat-abi tools from the 11-alpha host, not the softfp-abi tools from the 10-stable jail sources. I don't know of any way to fix it other than to create a 10-stable amd64 jail to host the 10-stable poudriere crossbuilds, so that the -x option in poudriere picks up the 10-stable copy of /usr/src from the jail it's running in. This doesn't sound like something that would be hard to fix, but I've never looked into it to see why it's hardwired to /usr/src on the host (in fact, I'm just taking someone's word for that, I've never looked into it at all). It might just get neglected because it has never really made much difference before, but now all of a sudden it does. -- Ian From owner-freebsd-arm@freebsd.org Fri Jun 24 20:17:21 2016 Return-Path: Delivered-To: freebsd-arm@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 64691B80945 for ; Fri, 24 Jun 2016 20:17:21 +0000 (UTC) (envelope-from iz-rpi03@hs-karlsruhe.de) Received: from smtp.hs-karlsruhe.de (smtp.HS-Karlsruhe.DE [193.196.64.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2C6EE2FD6 for ; Fri, 24 Jun 2016 20:17:20 +0000 (UTC) (envelope-from iz-rpi03@hs-karlsruhe.de) Received: from iz-wera01.hs-karlsruhe.de ([193.196.65.46]) by smtp.hs-karlsruhe.de with esmtp (Exim 4.80.1) (envelope-from ) id 1bGXXR-00HZ00-K3; Fri, 24 Jun 2016 22:17:17 +0200 X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 From: Ralf Wenk To: "Thomas Laus" cc: FreeBSD ARM Subject: Re: 'urtwn' & 'urtwnfw' Devices Unknown in r302145 In-reply-to: <576D33B9.19054.E2ECD@lausts.acm.org> References: <20160623220014.GA73746@mail.laus.org>, <576D33B9.19054.E2ECD@lausts.acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Jun 2016 22:17:17 +0200 Message-Id: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 20:17:21 -0000 Thomas Laus wrote: > Ralf Wenk > > =5B...=5D > > In my old RPi kernel configuration I use in one line: > >=20 > > makeoptions MODULES_OVERRIDE=3D=22wlan wlan_ccmp wlan_tkip wlan_w= ep > > wlan_amrr wlan_rssadapt wlan_xauth wlan_acl urtwn urtwnfw firmware= =22 > >=20 > > I am unsure about the =22MODULES_EXTRA=22 line. May be you should jus= t add > > the missing drivers there. > >=20 > The modules are not being built at all with a kernel build because they= are=20 > not being found by the build script. I have this problem on both my am= d64=20 > and arm computers. I just performed a fresh checkout of my source tree= and=20 > compared the location of the urtwn and urtwnfw files on my FreeBSD 10 R= elease=20 > and FreeBSD 11 computers. I am including the logs from the run on the = amd4=20 > computer because it builds faster than my BeagleBone. The results are = the=20 > same. Hm, > config: Error: device =22urtwn=22 is unknown > config: Error: device =22urtwnfw=22 is unknown reminds me, that the urtwn device was moved to a new location=5B1=5D whil= e I was following CURRENT. I do think that caused such error messages before I used the new location in my kernel configuration. Ralf =5B1=5D: 11.0-ALPHA4: sys/dev/urtwn/ 10.3-STABLE: sys/dev/usb/wlan/ From owner-freebsd-arm@freebsd.org Fri Jun 24 20:59:55 2016 Return-Path: Delivered-To: freebsd-arm@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 BF97EB74401 for ; Fri, 24 Jun 2016 20:59:55 +0000 (UTC) (envelope-from lausts@laus.org) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.226]) by mx1.freebsd.org (Postfix) with ESMTP id 8680A2A1D for ; Fri, 24 Jun 2016 20:59:54 +0000 (UTC) (envelope-from lausts@laus.org) Received: from [173.88.10.122] ([173.88.10.122:60447] helo=mail.laus.org) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id C5/D8-30907-94F9D675; Fri, 24 Jun 2016 20:59:54 +0000 Received: from mail.laus.org (localhost [127.0.0.1]) by mail.laus.org (8.15.2/8.15.2) with ESMTPS id u5OKxrNT078103 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 24 Jun 2016 16:59:53 -0400 (EDT) (envelope-from lausts@laus.org) Received: (from lausts@localhost) by mail.laus.org (8.15.2/8.15.2/Submit) id u5OKxqYO078102; Fri, 24 Jun 2016 16:59:52 -0400 (EDT) (envelope-from lausts) Date: Fri, 24 Jun 2016 16:59:52 -0400 From: Thomas Laus To: Ralf Wenk Cc: freebsd-arm@freebsd.org Subject: Re: 'urtwn' & 'urtwnfw' Devices Unknown in r302145 Message-ID: <20160624205952.GA78039@mail.laus.org> Reply-To: lausts@acm.org References: <20160623220014.GA73746@mail.laus.org> <576D33B9.19054.E2ECD@lausts.acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.3-RELEASE-p5 on an amd64 User-Agent: Mutt/1.6.1 (2016-04-27) X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 20:59:55 -0000 Ralf Wenk [iz-rpi03@hs-karlsruhe.de] wrote: > Thomas Laus wrote: > > Ralf Wenk > > > [...] > Hm, > > > config: Error: device "urtwn" is unknown > > config: Error: device "urtwnfw" is unknown > > reminds me, that the urtwn device was moved to a new location[1] while > I was following CURRENT. I do think that caused such error messages > before I used the new location in my kernel configuration. > > [1]: 11.0-ALPHA4: sys/dev/urtwn/ > 10.3-STABLE: sys/dev/usb/wlan/ > That is probably the root cause of my problem. The 'make kernel' script in 11.0 has not been updated for the new location of 'urtwn' and 'urtwnfw'. Changing that is out of my area of knowledge and will require some attention of a Developer in order for it to be committed to the source repository. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From owner-freebsd-arm@freebsd.org Fri Jun 24 21:50:17 2016 Return-Path: Delivered-To: freebsd-arm@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 5E7E6B74FD5; Fri, 24 Jun 2016 21:50:17 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 2B6CB29A4; Fri, 24 Jun 2016 21:50:17 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi0-x22b.google.com with SMTP id u201so132794375oie.0; Fri, 24 Jun 2016 14:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=R+Db2jnteBDchBtPpumnS4RxaLoIddNRKhfR8AxOIUQ=; b=XKfgpz/fHdepqGVvxaEDakHI/tJtnMxN0ICzj/vlMi6cBLPDO3AI2LbaCL7B+hYa8K CYYOSfEMgbqmBcr1pm8pYonx0Ci/41QTic0LaIl2XsT1AKohnu2GekumkjOTzBIwY/5q qVpMjwNCT0HgfhnuVE2J1RrFhVJirJsk9w9uCvM8Rj7V+j9kPTiDVcvvxoHhLtdmuQ6Z X4SnvPtVO2/kKCL8CR4z6jNNpLVrNqq2PeQFo2+32Efr+hPoikY4EROnHzZCVc0Ptoff wlgFvXk4YMGXg9yRp6TJxNSQLjNKyWgEKnng0iq4s0IO4dhpZ6gqVTWExJZNHvVybRWS roCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=R+Db2jnteBDchBtPpumnS4RxaLoIddNRKhfR8AxOIUQ=; b=h8lcXRB2myo6xkUoZSlXw6RUhsh1j+GXdFQXc9Q9l+uf2F20nFHC89yJvyMiSYTEU9 ToX8eEG8NIT2o7+tEMGw3C379nNeXUcEpu0vkTKXD3b/Hfa/v9zOaiYPz0HjTDGgCjmj SxbhSCqroQM3KpbgOldx+vdzy1BkGIXZzU9ASzF4u3UcfOrzSdKvePMaCIvRo15+8uz3 AR6GZGbK++pXkvzTwl2ni/pQoSMNCEsthUrc2M0OpiG7fbjDsqQLxfZKD47xRL7Hmogq edJpkvIdyA7j4M9TgjFU6ZbLgrU02mAq8kNX7YSvuakwIpGNxczjLKbNVPwm3tkjywcn ER9w== X-Gm-Message-State: ALyK8tJGyZQzIx1AArBDV6ZG0ucRcJxV7JRs6xI2EEAxs4AS+luAsZ9q6vG+4ndDREoa6IGuRmzvfCBCRNiy9w== X-Received: by 10.157.29.106 with SMTP id m97mr4365447otm.164.1466805016220; Fri, 24 Jun 2016 14:50:16 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.202.168.149 with HTTP; Fri, 24 Jun 2016 14:50:15 -0700 (PDT) In-Reply-To: <1465862808.1188.129.camel@freebsd.org> References: <1465862808.1188.129.camel@freebsd.org> From: Alan Somers Date: Fri, 24 Jun 2016 15:50:15 -0600 X-Google-Sender-Auth: WrAnhoFxie9sUqBc5jnL9f8p0uA Message-ID: Subject: Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists To: Ian Lepore Cc: "Conrad E. Meyer" , Mark Millard , freebsd-arm , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 21:50:17 -0000 >> > On Mon, Jun 13, 2016 at 11:29 AM, Mark Millard > > > wrote: >> > > With the newly less strict alignment requirements "kyua test -k >> > > /usr/tests/Kyuafile" runs to completion, unlike before. >> > > >> > > > ===> Summary >> > > > Results read from /root/.kyua/store/results.usr_tests.20160613 >> > > > -080302-120731.db >> > > > Test cases: 5694 total, 54 skipped, 21 expected failures, 24 >> > > > broken, 59 failed >> > > > Total time: 8723.243s >> > > >> > > >> > > I only list the one line summaries below. Then I list various >> > > context details. >> > > >> > > > ===> Broken tests >> > > > lib/msun/cexp_test:main -> broken: Received signal 6 >> > > > [1.054s] >> > > > lib/msun/ctrig_test:main -> broken: Received signal 6 >> > > > [1.074s] >> > > > lib/msun/exponential_test:main -> broken: Received signal 6 >> > > > [1.045s] >> > > > lib/msun/fenv_test:main -> broken: Received signal 6 >> > > > [1.048s] >> > > > lib/msun/fma_test:main -> broken: Received signal 6 [1.080s] >> > > > lib/msun/invctrig_test:main -> broken: Received signal 6 >> > > > [1.091s] >> > > > lib/msun/invtrig_test:main -> broken: Received signal 6 >> > > > [1.086s] >> > > > lib/msun/logarithm_test:main -> broken: Received signal 6 >> > > > [1.054s] >> > > > lib/msun/lrint_test:main -> broken: Received signal 6 >> > > > [1.069s] >> > > > lib/msun/nearbyint_test:main -> broken: Received signal 6 >> > > > [1.066s] >> > > > lib/msun/rem_test:main -> broken: Received signal 6 [1.069s] >> > > > lib/msun/trig_test:main -> broken: Received signal 6 >> > > > [1.070s] >> > > > sbin/growfs/legacy_test:main -> broken: Reported plan differs >> > > > from actual executed tests [0.459s] >> > > > sys/geom/class/eli/integrity_copy_test:main -> broken: Test >> > > > case timed out [1200.082s] >> > > > sys/geom/class/eli/integrity_hmac_test:main -> broken: Test >> > > > case timed out [600.138s] >> > > > sys/geom/class/eli/onetime_a_test:main -> broken: Test case >> > > > timed out [600.044s] >> > > > sys/sys/bitstring_test:bit_clear -> broken: Test case body >> > > > timed out [300.032s] >> > > > sys/sys/bitstring_test:bit_count -> broken: Premature exit; >> > > > test case received signal 11 (core dumped) [1.080s] >> > > > sys/sys/bitstring_test:bit_ffc -> broken: Premature exit; >> > > > test case received signal 11 (core dumped) [1.077s] >> > > > sys/sys/bitstring_test:bit_ffc_at -> broken: Premature exit; >> > > > test case received signal 11 (core dumped) [1.081s] >> > > > sys/sys/bitstring_test:bit_ffs -> broken: Premature exit; >> > > > test case received signal 11 (core dumped) [1.082s] >> > > > sys/sys/bitstring_test:bit_ffs_at -> broken: Premature exit; >> > > > test case received signal 11 (core dumped) [1.077s] >> > > > sys/sys/bitstring_test:bit_nclear -> broken: Premature exit; >> > > > test case received signal 11 (core dumped) [1.083s] >> > > > sys/sys/bitstring_test:bit_nset -> broken: Premature exit; >> > > > test case received signal 11 (core dumped) [1.079s] >> > > >> > > >> > > > ===> Failed tests >> > > > lib/libc/c063/fstatat_test:fstatat_fd -> failed: >> > > > /usr/src/contrib/netbsd-tests/lib/libc/c063/t_fstatat.c:74: >> > > > memcmp(&st1, &st2, sizeof(st1)) == 0 not met [0. >> > > > 027s] >> > > > lib/libc/nss/gethostby_test:getipnodebyname_getaddrinfo_ipv4 >> > > > -> failed: /usr/src/lib/libc/tests/nss/gethostby_test.c:1335: >> > > > run_tests(_hostlist_file, _snapshot >> > > > _file, 2, TEST_GETHOSTBYNAME2_GETADDRINFO, 0) == 0 not met >> > > > [15.315s] >> > > > lib/libc/ssp/ssp_test:fgets -> failed: Test case body >> > > > returned a non-ok exit code, but this is not allowed [0.153s] >> > > > lib/libc/ssp/ssp_test:gets -> failed: Test case body returned >> > > > a non-ok exit code, but this is not allowed [0.158s] >> > > > lib/libc/ssp/ssp_test:memcpy -> failed: atf-check failed; see >> > > > the output of the test for details [0.148s] >> > > > lib/libc/ssp/ssp_test:memmove -> failed: atf-check failed; >> > > > see the output of the test for details [0.147s] >> > > > lib/libc/ssp/ssp_test:memset -> failed: atf-check failed; see >> > > > the output of the test for details [0.147s] >> > > > lib/libc/ssp/ssp_test:read -> failed: Test case body returned >> > > > a non-ok exit code, but this is not allowed [0.154s] >> > > > lib/libc/ssp/ssp_test:readlink -> failed: atf-check failed; >> > > > see the output of the test for details [0.155s] >> > > > lib/libc/ssp/ssp_test:snprintf -> failed: atf-check failed; >> > > > see the output of the test for details [0.149s] >> > > > lib/libc/ssp/ssp_test:sprintf -> failed: atf-check failed; >> > > > see the output of the test for details [0.149s] >> > > > lib/libc/ssp/ssp_test:stpcpy -> failed: atf-check failed; see >> > > > the output of the test for details [0.149s] >> > > > lib/libc/ssp/ssp_test:stpncpy -> failed: atf-check failed; >> > > > see the output of the test for details [0.147s] >> > > > lib/libc/ssp/ssp_test:strcat -> failed: atf-check failed; see >> > > > the output of the test for details [0.147s] >> > > > lib/libc/ssp/ssp_test:strcpy -> failed: atf-check failed; see >> > > > the output of the test for details [0.147s] >> > > > lib/libc/ssp/ssp_test:strncat -> failed: atf-check failed; >> > > > see the output of the test for details [0.147s] >> > > > lib/libc/ssp/ssp_test:strncpy -> failed: atf-check failed; >> > > > see the output of the test for details [0.146s] >> > > > lib/libc/ssp/ssp_test:vsnprintf -> failed: atf-check failed; >> > > > see the output of the test for details [0.150s] >> > > > lib/libc/ssp/ssp_test:vsprintf -> failed: atf-check failed; >> > > > see the output of the test for details [0.148s] >> > > > lib/libc/stdio/printbasic_test:int_within_limits -> failed: >> > > > printf("%tu", (size_t)-1) ==> [18446744073709551615], expected >> > > > [4294967295]<> [0.030s] >> > > > lib/libc/stdio/scanfloat_test:infinities_and_nans -> failed: >> > > > /usr/src/lib/libc/tests/stdio/scanfloat_test.c:191: >> > > > fetestexcept(FE_INVALID) == 0 not met [0.031 >> > > > s] >> > > > lib/libc/sys/mincore_test:mincore_resid -> failed: >> > > > /usr/src/contrib/netbsd-tests/lib/libc/sys/t_mincore.c:225: >> > > > check_residency(addr, npgs) == 0 not met [0.04 >> > > > 0s] >> > > > lib/libc/sys/mincore_test:mincore_shmseg -> failed: >> > > > /usr/src/contrib/netbsd-tests/lib/libc/sys/t_mincore.c:298: >> > > > check_residency(addr, npgs) == 0 not met [0.0 >> > > > 29s] >> > > > lib/libc/tls/tls_dynamic_test:t_tls_dynamic -> failed: 15 >> > > > checks failed; see output for more details [0.035s] >> > > > lib/libproc/proc_test:symbol_lookup -> failed: >> > > > /usr/src/lib/libproc/tests/proc_test.c:116: state != PS_STOP: >> > > > process has state 4 [0.177s] >> > > > lib/libxo/functional_test:test_02__E -> failed: atf-check >> > > > failed; see the output of the test for details [0.166s] >> > > > lib/libxo/functional_test:test_02__H -> failed: atf-check >> > > > failed; see the output of the test for details [0.168s] >> > > > lib/libxo/functional_test:test_02__HIPx -> failed: atf-check >> > > > failed; see the output of the test for details [0.170s] >> > > > lib/libxo/functional_test:test_02__HP -> failed: atf-check >> > > > failed; see the output of the test for details [0.164s] >> > > > lib/libxo/functional_test:test_02__J -> failed: atf-check >> > > > failed; see the output of the test for details [0.169s] >> > > > lib/libxo/functional_test:test_02__JP -> failed: atf-check >> > > > failed; see the output of the test for details [0.166s] >> > > > lib/libxo/functional_test:test_02__T -> failed: atf-check >> > > > failed; see the output of the test for details [0.168s] >> > > > lib/libxo/functional_test:test_02__X -> failed: atf-check >> > > > failed; see the output of the test for details [0.169s] >> > > > lib/libxo/functional_test:test_02__XP -> failed: atf-check >> > > > failed; see the output of the test for details [0.168s] >> > > > lib/msun/conj_test:main -> failed: 9 tests of 42 failed >> > > > [0.034s] >> > > > lib/msun/ldexp_test:ldexp_denormal -> failed: 4 checks >> > > > failed; see output for more details [0.034s] >> > > > local/kyua/model/metadata_test:override_all_with_set_string -> >> > > > failed: Line 253: disk_space != md.required_disk_space() >> > > > (16777216.00T != 2.00G) [0.047s] >> > > > local/kyua/testers/stacktrace_test:dump__cannot_find_gdb -> >> > > > failed: testers/stacktrace_test.c:281: >> > > > atf_utils_grep_file("execvp failed", "stacktrace") not met >> > > > [0.611s] >> > > > local/kyua/testers/stacktrace_test:dump__gdb_fail -> failed: >> > > > testers/stacktrace_test.c:294: atf_utils_grep_file("foo", >> > > > "stacktrace") not met [0.610s] >> > > > local/kyua/testers/stacktrace_test:dump__gdb_times_out -> >> > > > failed: testers/stacktrace_test.c:311: >> > > > atf_utils_grep_file("foo", "stacktrace") not met [0.614s] >> > > > local/kyua/testers/stacktrace_test:dump__integration -> >> > > > failed: testers/stacktrace_test.c:233: >> > > > atf_utils_grep_file("#0", "stacktrace") not met [0.613s] >> > > > local/kyua/testers/stacktrace_test:dump__ok -> failed: >> > > > testers/stacktrace_test.c:249: atf_utils_grep_file("frame 1", >> > > > "stacktrace") not met [0.614s] >> > > > local/kyua/testers/stacktrace_test:find_core__found__long -> >> > > > failed: Core dumped, but no candidates found [0.606s] >> > > > local/kyua/testers/stacktrace_test:find_core__found__short -> >> > > > failed: Core dumped, but no candidates found [0.603s] >> > > > local/kyua/testers/tap_parser_test:try_parse_plan__insane -> >> > > > failed: testers/tap_parser_test.c:135: 'too long' not matched >> > > > in 'Plan line includes out of range >> > > > numbers' [0.032s] >> > > > sys/geom/class/eli/resize_test:main -> failed: 15 tests of 27 >> > > > failed [1.292s] >> > > > sys/kern/pipe/pipe_fstat_bug_test:main -> failed: Returned >> > > > non-success exit status 1 [0.044s] >> > > > usr.bin/lastcomm/legacy_test:main -> failed: 4 tests of 6 >> > > > failed [0.151s] >> > > > usr.sbin/rpcbind/addrmerge_test:addrmerge_bindip -> failed: 1 >> > > > checks failed; see output for more details [0.035s] >> > > > usr.sbin/rpcbind/addrmerge_test:addrmerge_bindip_rev -> >> > > > failed: 1 checks failed; see output for more details [0.035s] >> > > > usr.sbin/rpcbind/addrmerge_test:addrmerge_localhost_only -> >> > > > failed: 1 checks failed; see output for more details [0.034s] >> > > > usr.sbin/rpcbind/addrmerge_test:addrmerge_one_addr_on_each_subn >> > > > et -> failed: 1 checks failed; see output for more details >> > > > [0.035s] >> > > > usr.sbin/rpcbind/addrmerge_test:addrmerge_one_addr_on_each_subn >> > > > et_rev -> failed: 1 checks failed; see output for more >> > > > details [0.035s] >> > > > usr.sbin/rpcbind/addrmerge_test:addrmerge_point2point -> >> > > > failed: 1 checks failed; see output for more details [0.035s] >> > > > usr.sbin/rpcbind/addrmerge_test:addrmerge_point2point_rev -> >> > > > failed: 1 checks failed; see output for more details [0.033s] >> > > > usr.sbin/rpcbind/addrmerge_test:addrmerge_recvdstaddr -> >> > > > failed: 1 checks failed; see output for more details [0.035s] >> > > > usr.sbin/rpcbind/addrmerge_test:addrmerge_recvdstaddr_rev -> >> > > > failed: 1 checks failed; see output for more details [0.035s] >> > > > usr.sbin/rpcbind/addrmerge_test:addrmerge_singlehomed -> >> > > > failed: 1 checks failed; see output for more details [0.032s] >> > > > usr.sbin/sa/legacy_test:main -> failed: 12 tests of 13 failed >> > > > [0.340s] >> > > >> > > >> > > As of r302180., the usr.sbin/rpcbind, sys/acl, and sys/sys/bitstring tests should all be fixed. I opened PR 210329 for the usr.bin/lastcomm test. I haven't investigated the others. -Alan From owner-freebsd-arm@freebsd.org Sat Jun 25 01:31:13 2016 Return-Path: Delivered-To: freebsd-arm@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 417BAB73149 for ; Sat, 25 Jun 2016 01:31:13 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 0B8E71E0E for ; Sat, 25 Jun 2016 01:31:11 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: by mail-io0-x229.google.com with SMTP id t74so113148274ioi.0 for ; Fri, 24 Jun 2016 18:31:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chen-org-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=d9sqiSb51i47b5vosq7VfXEuC8Csyr+PBvxW7qBXfSk=; b=FGqJBAFGlGr9wExw759TdmuOmj8BqF4m0tdEdKwZZNeDnAdRJ47ntJpwcxKn8WzzE4 pUUyrIRVGMhjx1efNNF7o1t0YKqT9hSOh/KJgRB8xcjGIdZQCogXsdnd4qjShvGoiEtB LeW0MgeXu/uN5bwU27xZ9lyRaUOnz3wFruol1RYWX5NiK0a47J1tQRx2AzAdRaZuUDqA Ki1BMhEdy8vZLBDuqcaYAbEGbyLJbfYD/9EGCOX7f9hrfuLzogIdgBQtSv3aOir04scY MyBSIzmbeB1zntIz9mVrvsGvFw3F48cTUxREeU7ieUHk5JEZQQroXcmBRCudkkoJRuE9 jphA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=d9sqiSb51i47b5vosq7VfXEuC8Csyr+PBvxW7qBXfSk=; b=TzX6pIHq+ZZrRNvZDPwO/8FnuuWjMJlph4LiBtNJfw8p6wQYHeCbGZQDE3b0YgScly Dc6dR1o3LgZ/cum5deFpNzhUlu17IMmZLw6JCRJi+quZ3M07aDstM/zAmviJucb9CJDl aDWq7HqqS2di9QgOCpN43A+D9q1OISy7Iw9+/3EdkL3GUMAfSQI9UCjwCFeXjqoaJgQb CctBMleKnqnCg2mvvg4lTA2MlNr99BhQaIarkr780pF8iDhKLwb/KVGl4gASWtA0ldN7 8fO4tYk+Ga+srALR1Vr94vEASxZOke+b4T2sF5BDjNDbUgRAlVUXc2gXWXBfp75GMTZ9 3Twg== X-Gm-Message-State: ALyK8tJG5nFnGdd/vrvcO76q0rViF1WBoXq8N6No4Ak63aePT5IFMkBZYOiafXRjH6/bKMcJAm9ALRj+2ycRuA== X-Received: by 10.107.6.89 with SMTP id 86mr9061410iog.77.1466818270664; Fri, 24 Jun 2016 18:31:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.134.4 with HTTP; Fri, 24 Jun 2016 18:31:10 -0700 (PDT) X-Originating-IP: [101.53.221.52] From: Jonathan Chen Date: Sat, 25 Jun 2016 13:31:10 +1200 Message-ID: Subject: FreeBSD 10.3/arm on Raspberry Pi 2 To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 01:31:13 -0000 Hi, I recently downloaded FreeBSD-10.3-RELEASE-arm-armv6-RPI-B.img to try on my Raspberry Pi 2B, and am having problems booting it up. I've dd'ed the image onto a 16Gb SD card, but on boot, my HDMI connected TV just shows the rainbow coloured display. The familiar FreeBSD boot output does not appear. I've re-tried with 10.2-RELEASE and the same problem occurs. I've made sure that the SD card and the Pi is functional - I resused the SD card to boot up OSMC. Did I miss something obvious? Thanks. -- Jonathan Chen From owner-freebsd-arm@freebsd.org Sat Jun 25 01:59:25 2016 Return-Path: Delivered-To: freebsd-arm@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 F229FB738CA for ; Sat, 25 Jun 2016 01:59:25 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id E3D3A2998; Sat, 25 Jun 2016 01:59:25 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id A20801685; Sat, 25 Jun 2016 01:59:25 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Sat, 25 Jun 2016 01:59:23 +0000 From: Glen Barber To: Jonathan Chen Cc: freebsd-arm@freebsd.org Subject: Re: FreeBSD 10.3/arm on Raspberry Pi 2 Message-ID: <20160625015923.GA18229@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 01:59:26 -0000 --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 25, 2016 at 01:31:10PM +1200, Jonathan Chen wrote: > Hi, >=20 > I recently downloaded FreeBSD-10.3-RELEASE-arm-armv6-RPI-B.img to try > on my Raspberry Pi 2B, and am having problems booting it up. I've > dd'ed the image onto a 16Gb SD card, but on boot, my HDMI connected TV > just shows the rainbow coloured display. The familiar FreeBSD boot > output does not appear. I've re-tried with 10.2-RELEASE and the same > problem occurs. >=20 > I've made sure that the SD card and the Pi is functional - I resused > the SD card to boot up OSMC. >=20 > Did I miss something obvious? >=20 RPI2 isn't supported for 10.3. You need 11.0. Glen --Nq2Wo0NMKNjxTN9z Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXbeV2AAoJEAMUWKVHj+KT1HEP/1YPgPBiQLjzykB8mIMyobJf P7MT2slpIB0Zkv1t6pQeZSstqdTlJ+a2GTlk57beNM6uXYDZO102rS3HUv+Dm1IY kOKxbkkHkFg3n7vH+iMOTW2JIQiFZL0ISfB5v9nVSMKuTx6jJatibknl5PquHSvn jtlVavJKFSnEaTcb/5MoF2FbPA/Ci0HiO3Lsc79UisPe1iGXd9YoXsU3mDTQOrLz kiEemUG59wBmhwCwDXnMp1Y888W9Y5kaSNqnxKxRUDTI9FULyEFHR55XouDk4VZA ZN5kO7pAhCdbylNu9IRn8TXQFIFqh/NgJ7Wpw1qayZCzk0fGCYSzn5DF+U3oum4F vjSCCogCQnqKhleXX9yE/ATR8lPrTGP8F0ajRloJrWDx/ND8eTjwPK5xp0MSTX8O XHAMPrfPh5L15lCYP4GRGYEG1hKtUUtx92Hc62fjiqSVV2662buRjg3SQp9lHUop KvlT90HouzqSJyQD2+KOISnffvW809IKZ36m30j9L9Aahing1fzjHOE5+hukSdi2 AL240hHKt6gVs693mOAcqnMmijaTxVB8skVtqy6JvTscfmZD4Gp6ROj9yMK/i6+7 rULhnBP3KTMObkN5poEg3X7/1Kvl9buL0cHMpLhdj0BPwXyuy4i+NyKqT8O8Nw5h HD9RkQL7WPkZXHash9fe =vxIY -----END PGP SIGNATURE----- --Nq2Wo0NMKNjxTN9z-- From owner-freebsd-arm@freebsd.org Sat Jun 25 02:03:32 2016 Return-Path: Delivered-To: freebsd-arm@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 A5FFDB73A2D for ; Sat, 25 Jun 2016 02:03:32 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 71B3D2C8C for ; Sat, 25 Jun 2016 02:03:32 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: by mail-it0-x236.google.com with SMTP id a5so28788836ita.1 for ; Fri, 24 Jun 2016 19:03:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chen-org-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=voaYqg79ohalUzQzKi1qhysCPpMlDdd4XXEuBEADMMc=; b=QzrjbNCJF3IEWsipclNDB6YWqB77I/RN5WjDULzDjNe2nnNavphVkBYSRFo1ufH96z F/5R9dYwWMu5g9bb4qjd4l85L6bbPCk79WyppdG+8d3kVB7szVG5PpBD4UvRgHbbzBGJ BZcLGJU2F3kXRr/VHgOwYRBL1lFUfvrpMl5FTezDpJXl62H2AM1eTu1eTp7XyimAtgAs K0yyeFWfv/AkmAka6s1BFOQnKLIW590QtFJbdmfir3JiJJPd7Qp7f2lKI2usJ1/A5ib9 JMBAnzGYgxYboW+mwevbRVl+tJ4n3HDrV721PZ8S9cPh/hIT+pjNrh/xaY47dSjvVqh7 vdMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=voaYqg79ohalUzQzKi1qhysCPpMlDdd4XXEuBEADMMc=; b=hJkR9kFDKhseQlEAPDv/atmwRyBKg+JkWy1RX3abrP32xcKubUUo/FIo+Sm95BOAya 8bUDZGRnH1eUkxWB5LY+FFyfHHtc5BTbJwS85/ZDG1TsWm7Ux0N5UUIHuOllc8JDrQiV Hay9SztLWynShs0EY0zX/jBI2AD/mqmTYoFeOW1xoIgGaPchpo+h1Y+TuRyKyBjQEdAJ zoPj+D2UHsUoeYlFRSKdC7rGHzQXDVQaOa4hjyK1XtA7lvpPOkcu1h6+pgSbuu2bz0u+ czJmpeBkjOf7rU1X6lAjlrrF7KGIaHRHTA7JZGt06oE60q9E02N/FUbOd8mU51wLCUSh Aiug== X-Gm-Message-State: ALyK8tKbOEJ1iwo24iicgkacZ9hDbcIFZ5SRpdrs/q7NhUDdmhz4YOj9gVg0wmkzZuv0SKXB9NuVe+Flsb2daA== X-Received: by 10.36.36.4 with SMTP id f4mr763660ita.29.1466820211652; Fri, 24 Jun 2016 19:03:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.134.4 with HTTP; Fri, 24 Jun 2016 19:03:31 -0700 (PDT) X-Originating-IP: [101.53.221.52] In-Reply-To: <20160625015923.GA18229@FreeBSD.org> References: <20160625015923.GA18229@FreeBSD.org> From: Jonathan Chen Date: Sat, 25 Jun 2016 14:03:31 +1200 Message-ID: Subject: Re: FreeBSD 10.3/arm on Raspberry Pi 2 To: Glen Barber Cc: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 02:03:32 -0000 On 25 June 2016 at 13:59, Glen Barber wrote: > On Sat, Jun 25, 2016 at 01:31:10PM +1200, Jonathan Chen wrote: >> Hi, >> >> I recently downloaded FreeBSD-10.3-RELEASE-arm-armv6-RPI-B.img to try >> on my Raspberry Pi 2B, and am having problems booting it up. I've >> dd'ed the image onto a 16Gb SD card, but on boot, my HDMI connected TV >> just shows the rainbow coloured display. The familiar FreeBSD boot >> output does not appear. I've re-tried with 10.2-RELEASE and the same >> problem occurs. >> >> I've made sure that the SD card and the Pi is functional - I resused >> the SD card to boot up OSMC. >> >> Did I miss something obvious? >> > > RPI2 isn't supported for 10.3. You need 11.0. > Ah. Thanks for that. I didn't realise that as it wasn't obvious on the 10.3 Release page. Cheers. -- Jonathan Chen From owner-freebsd-arm@freebsd.org Sat Jun 25 04:50:41 2016 Return-Path: Delivered-To: freebsd-arm@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 C4A86B73F9E for ; Sat, 25 Jun 2016 04:50:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (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 879CE21F1 for ; Sat, 25 Jun 2016 04:50:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15511 invoked from network); 25 Jun 2016 04:51:08 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 25 Jun 2016 04:51:08 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Sat, 25 Jun 2016 00:50:30 -0400 (EDT) Received: (qmail 15732 invoked from network); 25 Jun 2016 04:50:30 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Jun 2016 04:50:30 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id CC8DF1C4079; Fri, 24 Jun 2016 21:50:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists From: Mark Millard In-Reply-To: Date: Fri, 24 Jun 2016 21:50:31 -0700 Cc: Ian Lepore , "Conrad E. Meyer" , freebsd-arm , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <6727481C-8BD2-4F00-A6F6-3BEE3CC7F2FA@dsl-only.net> References: <1465862808.1188.129.camel@freebsd.org> To: Alan Somers X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 04:50:41 -0000 On 2016-Jun-24, at 2:50 PM, Alan Somers wrote: > As of r302180., the usr.sbin/rpcbind, sys/acl, and sys/sys/bitstring > tests should all be fixed. I opened PR 210329 for the > usr.bin/lastcomm test. I haven't investigated the others. >=20 > -Alan I updated to -r302180 and ran kyua again. It confirms the rpcbind, acl, and bitstring items are gone from the broken and failed lists. This time the totals were 15 broken (down from 24) and 41 failed (down from 59). My results this time were. . . # kyua report --results-filter broken --results-file /usr/tests | more =3D=3D=3D> Broken tests lib/msun/cexp_test:main -> broken: Received signal 6 [1.094s] lib/msun/ctrig_test:main -> broken: Received signal 6 [1.097s] lib/msun/exponential_test:main -> broken: Received signal 6 [1.097s] lib/msun/fenv_test:main -> broken: Received signal 6 [1.099s] lib/msun/fma_test:main -> broken: Received signal 6 [1.114s] lib/msun/invctrig_test:main -> broken: Received signal 6 [1.118s] lib/msun/invtrig_test:main -> broken: Received signal 6 [1.114s] lib/msun/logarithm_test:main -> broken: Received signal 6 [1.096s] lib/msun/lrint_test:main -> broken: Received signal 6 [1.096s] lib/msun/nearbyint_test:main -> broken: Received signal 6 [1.096s] lib/msun/rem_test:main -> broken: Received signal 6 [1.091s] lib/msun/trig_test:main -> broken: Received signal 6 [1.094s] sbin/growfs/legacy_test:main -> broken: Reported plan differs from = actual executed tests [0.479s] sys/geom/class/eli/integrity_copy_test:main -> broken: Test case timed = out [1200.089s] sys/geom/class/eli/onetime_a_test:main -> broken: Test case timed out = [600.041s] =3D=3D=3D> Summary Results read from = /root/.kyua/store/results.usr_tests.20160625-012941-048472.db Test cases: 5700 total, 54 skipped, 20 expected failures, 15 broken, 41 = failed Total time: 9093.092s # kyua report --results-filter failed --results-file /usr/tests | more =3D=3D=3D> Failed tests lib/libc/c063/fstatat_test:fstatat_fd -> failed: = /usr/src/contrib/netbsd-tests/lib/libc/c063/t_fstatat.c:74: memcmp(&st1, = &st2, sizeof(st1)) =3D=3D 0 not met [0.028s] lib/libc/ssp/ssp_test:fgets -> failed: Test case body returned a = non-ok exit code, but this is not allowed [0.159s] lib/libc/ssp/ssp_test:gets -> failed: Test case body returned a non-ok = exit code, but this is not allowed [0.152s] lib/libc/ssp/ssp_test:memcpy -> failed: atf-check failed; see the = output of the test for details [0.150s] lib/libc/ssp/ssp_test:memmove -> failed: atf-check failed; see the = output of the test for details [0.149s] lib/libc/ssp/ssp_test:memset -> failed: atf-check failed; see the = output of the test for details [0.152s] lib/libc/ssp/ssp_test:read -> failed: Test case body returned a non-ok = exit code, but this is not allowed [0.159s] lib/libc/ssp/ssp_test:readlink -> failed: atf-check failed; see the = output of the test for details [0.161s] lib/libc/ssp/ssp_test:snprintf -> failed: atf-check failed; see the = output of the test for details [0.143s] lib/libc/ssp/ssp_test:sprintf -> failed: atf-check failed; see the = output of the test for details [0.143s] lib/libc/ssp/ssp_test:stpcpy -> failed: atf-check failed; see the = output of the test for details [0.146s] lib/libc/ssp/ssp_test:stpncpy -> failed: atf-check failed; see the = output of the test for details [0.149s] lib/libc/ssp/ssp_test:strcat -> failed: atf-check failed; see the = output of the test for details [0.148s] lib/libc/ssp/ssp_test:strcpy -> failed: atf-check failed; see the = output of the test for details [0.152s] lib/libc/ssp/ssp_test:strncat -> failed: atf-check failed; see the = output of the test for details [0.143s] lib/libc/ssp/ssp_test:strncpy -> failed: atf-check failed; see the = output of the test for details [0.147s] lib/libc/ssp/ssp_test:vsnprintf -> failed: atf-check failed; see the = output of the test for details [0.145s] lib/libc/ssp/ssp_test:vsprintf -> failed: atf-check failed; see the = output of the test for details [0.146s] lib/libc/stdio/printbasic_test:int_within_limits -> failed: = printf("%tu", (size_t)-1) =3D=3D> [18446744073709551615], expected = [4294967295]<> [0.029s] lib/libc/stdio/scanfloat_test:infinities_and_nans -> failed: = /usr/src/lib/libc/tests/stdio/scanfloat_test.c:191: = fetestexcept(FE_INVALID) =3D=3D 0 not met [0.032 s] lib/libc/sys/mincore_test:mincore_resid -> failed: = /usr/src/contrib/netbsd-tests/lib/libc/sys/t_mincore.c:225: = check_residency(addr, npgs) =3D=3D 0 not met [0.04 1s] lib/libc/sys/mincore_test:mincore_shmseg -> failed: = /usr/src/contrib/netbsd-tests/lib/libc/sys/t_mincore.c:298: = check_residency(addr, npgs) =3D=3D 0 not met [0.0 32s] lib/libc/tls/tls_dynamic_test:t_tls_dynamic -> failed: 15 checks = failed; see output for more details [0.037s] lib/libproc/proc_test:symbol_lookup -> failed: = /usr/src/lib/libproc/tests/proc_test.c:116: state !=3D PS_STOP: process = has state 4 [0.180s] lib/libxo/functional_test:test_02__E -> failed: atf-check failed; see = the output of the test for details [0.165s] lib/libxo/functional_test:test_02__H -> failed: atf-check failed; see = the output of the test for details [0.169s] lib/libxo/functional_test:test_02__HIPx -> failed: atf-check failed; = see the output of the test for details [0.174s] lib/libxo/functional_test:test_02__HP -> failed: atf-check failed; see = the output of the test for details [0.168s] lib/libxo/functional_test:test_02__J -> failed: atf-check failed; see = the output of the test for details [0.168s] lib/libxo/functional_test:test_02__JP -> failed: atf-check failed; see = the output of the test for details [0.165s] lib/libxo/functional_test:test_02__T -> failed: atf-check failed; see = the output of the test for details [0.169s] lib/libxo/functional_test:test_02__X -> failed: atf-check failed; see = the output of the test for details [0.165s] lib/libxo/functional_test:test_02__XP -> failed: atf-check failed; see = the output of the test for details [0.170s] lib/msun/conj_test:main -> failed: 9 tests of 42 failed [0.034s] lib/msun/ldexp_test:ldexp_denormal -> failed: 4 checks failed; see = output for more details [0.032s] local/kyua/model/metadata_test:override_all_with_set_string -> failed: = Line 253: disk_space !=3D md.required_disk_space() (16777216.00T !=3D = 2.00G) [0.045s] local/kyua/testers/tap_parser_test:try_parse_plan__insane -> failed: = testers/tap_parser_test.c:135: 'too long' not matched in 'Plan line = includes out of range numbers' [0.034s] sys/geom/class/eli/resize_test:main -> failed: 15 tests of 27 failed = [1.094s] sys/kern/pipe/pipe_fstat_bug_test:main -> failed: Returned non-success = exit status 1 [0.038s] usr.bin/lastcomm/legacy_test:main -> failed: 4 tests of 6 failed = [0.139s] usr.sbin/sa/legacy_test:main -> failed: 12 tests of 13 failed = [0.330s] =3D=3D=3D> Summary Results read from = /root/.kyua/store/results.usr_tests.20160625-012941-048472.db Test cases: 5700 total, 54 skipped, 20 expected failures, 15 broken, 41 = failed Total time: 9093.092s =3D=3D=3D Mark Millard markmi@dsl-only.net From owner-freebsd-arm@freebsd.org Sat Jun 25 07:44:59 2016 Return-Path: Delivered-To: freebsd-arm@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 BF74EB80F4B; Sat, 25 Jun 2016 07:44:59 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) 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 70D5B222F; Sat, 25 Jun 2016 07:44:59 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-qk0-x234.google.com with SMTP id p10so168278205qke.3; Sat, 25 Jun 2016 00:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dOUOyXiko7OKNRpyzXMf1z60ejWwD1G+CyA+ouvZ2+A=; b=WqSfxsybTHzNYe0L5V48VEZkwrRM09ppVMBuAgSCZL6UJZgbitXVrrr8w3jp3VPZN3 L2Wc4cEl6s06V6AHogczGB5Hb8SqUh+XLhShtog/ol3zkaXQuifpgBNbiFjN5Oh1pUFN cyf6UYuSfID7P98a5BvI9F0IjuTzP31SNbmTRAKytSEhEr4N6Mh39XTYeIwiDtKxN/MG ok9Voq7eGCCJBUpiOTA4RrYWEPTpzn9UdtNtIBPjqqGQlsfCxRZzG89XqrnqCZ5I5Jf7 wGqm/pz3xKdt8S5zPjFBm9YojqEnT+8lQ9ozm30fEQgGQm39uRdbMFOv8lVwseQsFZPE tfSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dOUOyXiko7OKNRpyzXMf1z60ejWwD1G+CyA+ouvZ2+A=; b=ehp0TdqUm4Cd2lX8aMqyDhrAvKDuOJb2edAkEXS+U/V0K60W33SbPWyaExPo63gZY1 j+jaLGI7WvQh4EuQZXXS5+WvMU8CM/IyD+F1ypuYYC58d4eBFVWhkStmQt4hRDOwQ1g/ 8GJU7+kE0OI2pG5mSjJ37T5UyMn4LJYdUXQqa5ArVspmiq8Q8/kdaX+Gh2rPBbKzk/ld Yoa1/04ygymdW5X5vHHOz6NT9EQFVQ/1mu0dmuIUW+ArQenw8izDEaGtZgBfYAUHowh1 V2/oqkyg94tR1IonV6cifT59CK9cYo6VD8Fh+IUPj2/9rA8xmwVz7dzHRVIZCw5aCF7f Sumw== X-Gm-Message-State: ALyK8tIoPEpjjdXSH4J4amwwJzO4Oou2ine5N/+34V6qr9+CKh33IRegb7uIiefB4wWm9h44LHuqLKBUKijNwg== X-Received: by 10.55.87.194 with SMTP id l185mr8698769qkb.204.1466840698642; Sat, 25 Jun 2016 00:44:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.148.131 with HTTP; Sat, 25 Jun 2016 00:44:58 -0700 (PDT) In-Reply-To: <6727481C-8BD2-4F00-A6F6-3BEE3CC7F2FA@dsl-only.net> References: <1465862808.1188.129.camel@freebsd.org> <6727481C-8BD2-4F00-A6F6-3BEE3CC7F2FA@dsl-only.net> From: Ngie Cooper Date: Sat, 25 Jun 2016 00:44:58 -0700 Message-ID: Subject: Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists To: Mark Millard Cc: Alan Somers , Ian Lepore , "Conrad E. Meyer" , freebsd-arm , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 07:44:59 -0000 On Fri, Jun 24, 2016 at 9:50 PM, Mark Millard wrote: > On 2016-Jun-24, at 2:50 PM, Alan Somers wrote: > >> As of r302180., the usr.sbin/rpcbind, sys/acl, and sys/sys/bitstring >> tests should all be fixed. I opened PR 210329 for the >> usr.bin/lastcomm test. I haven't investigated the others. ... > This time the totals were 15 broken (down from 24) and 41 failed (down > from 59). > > My results this time were. . . Hi Mark, Please file bugs for all of the individual component failures, e.g. lib/msun, and CC me on the bugs. Thanks, -Ngie From owner-freebsd-arm@freebsd.org Sat Jun 25 08:45:57 2016 Return-Path: Delivered-To: freebsd-arm@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 6AF06B731F2 for ; Sat, 25 Jun 2016 08:45:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 5A8AC1CEB for ; Sat, 25 Jun 2016 08:45:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u5P8jv6o010000 for ; Sat, 25 Jun 2016 08:45:57 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 210554] lib/msun broken kyua status for 11.0 -r302180 (only tested on rpi2 with -mcpu=cortex-a7 in use) Date: Sat, 25 Jun 2016 08:45:57 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 08:45:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210554 Bug ID: 210554 Summary: lib/msun broken kyua status for 11.0 -r302180 (only tested on rpi2 with -mcpu=3Dcortex-a7 in use) Product: Base System Version: 11.0-CURRENT Hardware: arm OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: markmi@dsl-only.net [The ". . ."s are omitted Metadata lines.] (only tested on rpi2 with -mcpu=3Dcortex-a7 in use) kyua report --results-filter broken --results-file /usr/tests --verbose reports for lib/msun: =3D=3D=3D> lib/msun/cexp_test:main Result: broken: Received signal 6 Duration: 1.094s . . . Standard output: 1..7 ok 1 - cexp zero # Run 0.. # Run 1.. # Run 2.. # Run 3.. # Run 4.. # Run 5.. # Run 6.. # Run 7.. Standard error: Assertion failed: (((void)(cexp), fetestexcept((0x0002 | 0x0010 | 0x0001 | 0x0004 | 0x0008)) =3D=3D (0))), function test_nan, file /usr/src/lib/msun/tests/cexp_test .c, line 131. Process with PID 60903 dumped core; attempting to gather stack trace Cannot find any core file =3D=3D=3D> lib/msun/ctrig_test:main Result: broken: Received signal 6 Duration: 1.097s . . . Standard output: 1..6 ok 1 - ctrig zero Standard error: Assertion failed: (((void)(csinh), fetestexcept((0x0002 | 0x0010 | 0x0001 | 0x0004 | 0x0008)) =3D=3D (0))), function test_nan, file /usr/src/lib/msun/tests/ctrig_te st.c, line 165. Process with PID 60912 dumped core; attempting to gather stack trace Cannot find any core file =3D=3D=3D> lib/msun/exponential_test:main Result: broken: Received signal 6 Duration: 1.097s . . . Standard output: 1..3 Standard error: Assertion failed: (((void)(exp), fetestexcept((0x0002 | 0x0010 | 0x0001 | 0x0004 | 0x0008)) =3D=3D (0))), function run_generic_tests, file /usr/src/lib/msun/tests/e xponential_test.c, line 103. Process with PID 60915 dumped core; attempting to gather stack trace Cannot find any core file =3D=3D=3D> lib/msun/fenv_test:main Result: broken: Received signal 6 Duration: 1.099s . . . Standard output: 1..8 Standard error: Assertion failed: (memcmp(&env, FE_DFL_ENV, sizeof(env)) =3D=3D 0), function test_dfl_env, file /usr/src/lib/msun/tests/fenv_test.c, line 161. Process with PID 60918 dumped core; attempting to gather stack trace Cannot find any core file =3D=3D=3D> lib/msun/fma_test:main Result: broken: Received signal 6 Duration: 1.114s . . . Standard output: 1..19 rmode =3D 0 ok 1 - fma zeroes rmode =3D 4194304 ok 2 - fma zeroes rmode =3D 8388608 ok 3 - fma zeroes rmode =3D 12582912 ok 4 - fma zeroes rmode =3D 0 ok 5 - fma infinities rmode =3D 4194304 ok 6 - fma infinities rmode =3D 8388608 ok 7 - fma infinities rmode =3D 12582912 ok 8 - fma infinities Standard error: Assertion failed: (((void)(fma), fetestexcept(((0x0002 | 0x0010 | 0x0001 | 0x0004 | 0x0008))) =3D=3D ((0)))), function test_nans, file /usr/src/lib/msun/tests/fma_t est.c, line 165. Process with PID 60921 dumped core; attempting to gather stack trace Cannot find any core file =3D=3D=3D> lib/msun/invctrig_test:main Result: broken: Received signal 6 Duration: 1.118s . . . Standard output: 1..6 ok 1 - invctrig zero Standard error: Assertion failed: (((void)(cacosh), fetestexcept((0x0002 | 0x0010 | 0x0001 | 0x0004 | 0x0008)) =3D=3D (0))), function test_nan, file /usr/src/lib/msun/tests/invctri g_test.c, line 165. Process with PID 60930 dumped core; attempting to gather stack trace Cannot find any core file =3D=3D=3D> lib/msun/invtrig_test:main Result: broken: Received signal 6 Duration: 1.114s . . . Standard output: 1..7 Standard error: Assertion failed: (((void)asin, fetestexcept(ALL_STD_EXCEPT) =3D=3D (((0)))= )), function test_special, file /usr/src/lib/msun/tests/invtrig_test.c, line 14= 5. Process with PID 60927 dumped core; attempting to gather stack trace Cannot find any core file =3D=3D=3D> lib/msun/logarithm_test:main Result: broken: Received signal 6 Duration: 1.096s . . . Standard output: 1..5 Standard error: Assertion failed: (((void)(log), fetestexcept((0x0002 | 0x0010 | 0x0001 | 0x0004 | 0x0008)) =3D=3D (0))), function run_generic_tests, file /usr/src/lib/msun/tests/l ogarithm_test.c, line 111. Process with PID 60933 dumped core; attempting to gather stack trace Cannot find any core file =3D=3D=3D> lib/msun/lrint_test:main Result: broken: Received signal 6 Duration: 1.096s . . . Standard output: 1..1 Standard error: Assertion failed: (fetestexcept(FE_ALL_EXCEPT) =3D=3D (0x0010)), function run_tests, file /usr/src/lib/msun/tests/lrint_test.c, line 73. Process with PID 60936 dumped core; attempting to gather stack trace Cannot find any core file =3D=3D=3D> lib/msun/nearbyint_test:main Result: broken: Received signal 6 Duration: 1.096s . . . Standard output: 1..12 ok 1 # nearbyint(+-0) ok 2 # modf(+-0) Standard error: Assertion failed: (fetestexcept(ALL_STD_EXCEPT) =3D=3D 0), function test_ne= arby, file /usr/src/lib/msun/tests/nearbyint_test.c, line 107. Process with PID 60942 dumped core; attempting to gather stack trace Cannot find any core file =3D=3D=3D> lib/msun/rem_test:main Result: broken: Received signal 6 Duration: 1.091s . . . Standard output: 1..3 ok 1 - rem ok 2 - rem Standard error: Assertion failed: (rem =3D=3D expected_rem), function testd, file /usr/src/lib/msun/tests/rem_test.c, line 173. Process with PID 60948 dumped core; attempting to gather stack trace Cannot find any core file =3D=3D=3D> lib/msun/trig_test:main Result: broken: Received signal 6 Duration: 1.094s . . . Standard output: 1..3 Standard error: Assertion failed: (((void)(tan), fetestexcept((0x0002 | 0x0010 | 0x0001 | 0x0004 | 0x0008)) =3D=3D (0))), function run_special_tests, file /usr/src/lib/msun/tests/t rig_test.c, line 106. Process with PID 60951 dumped core; attempting to gather stack trace Cannot find any core file --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sat Jun 25 08:53:13 2016 Return-Path: Delivered-To: freebsd-arm@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 CBE09B73747 for ; Sat, 25 Jun 2016 08:53:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 A1B9423F9 for ; Sat, 25 Jun 2016 08:53:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u5P8rDmT028265 for ; Sat, 25 Jun 2016 08:53:13 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 210556] sbin/growfs broken kyua status for 11.0 -r302180 (only tested on rpi2 with -mcpu=cortex-a7 in use) Date: Sat, 25 Jun 2016 08:53:13 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 08:53:13 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210556 Bug ID: 210556 Summary: sbin/growfs broken kyua status for 11.0 -r302180 (only tested on rpi2 with -mcpu=3Dcortex-a7 in use) Product: Base System Version: 11.0-CURRENT Hardware: arm OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: markmi@dsl-only.net [The ". . ."s are omitted Metadata lines.] (only tested on rpi2 with -mcpu=3Dcortex-a7 in use) kyua report --results-filter broken --results-file /usr/tests --verbose reports for sbin/growfs: =3D=3D=3D> sbin/growfs/legacy_test:main Result: broken: Reported plan differs from actual executed tests Duration: 0.479s Metadata: allowed_architectures is empty allowed_platforms is empty description is empty has_cleanup =3D false required_configs is empty required_disk_space =3D 0 required_files is empty required_memory =3D 0 required_programs =3D /usr/local/bin/perl required_user is empty timeout =3D 300 Standard output: 1..19 ok 1 - Created md0 with size 40m Standard error: Can't exec "disklabel": No such file or directory at /usr/tests/sbin/growfs/legacy_test line 18. Died at /usr/tests/sbin/growfs/legacy_test line 18. # Looks like you planned 19 tests but ran 1. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sat Jun 25 08:59:49 2016 Return-Path: Delivered-To: freebsd-arm@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 40E3CB73866 for ; Sat, 25 Jun 2016 08:59:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 063772494 for ; Sat, 25 Jun 2016 08:59:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u5P8xm23036452 for ; Sat, 25 Jun 2016 08:59:48 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 210557] sys/geom broken kyua status for 11.0 -r302180 (only tested on rpi2 with -mcpu=cortex-a7 in use) Date: Sat, 25 Jun 2016 08:59:49 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 08:59:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210557 Bug ID: 210557 Summary: sys/geom broken kyua status for 11.0 -r302180 (only tested on rpi2 with -mcpu=3Dcortex-a7 in use) Product: Base System Version: 11.0-CURRENT Hardware: arm OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: markmi@dsl-only.net [The ". . ."s are omitted lines.] (only tested on rpi2 with -mcpu=3Dcortex-a7 in use) kyua report --results-filter broken --results-file /usr/tests --verbose reports for sys/geom: =3D=3D=3D> sys/geom/class/eli/integrity_copy_test:main Result: broken: Test case timed out Duration: 1200.089s Metadata: allowed_architectures is empty allowed_platforms is empty description is empty has_cleanup =3D false required_configs is empty required_disk_space =3D 0 required_files is empty required_memory =3D 0 required_programs is empty required_user =3D root timeout =3D 1200 Standard output: 1..5520 ok 1 - small 1 aalgo=3Dhmac/md5 ealgo=3Daes keylen=3D0 sec=3D512 . . . ok 4442 - small 2 aalgo=3Dhmac/md5 ealgo=3Dblowfish-cbc keylen=3D448 sec=3D= 512 ok 4443 - big 1 aalgo=3Dhmac/md5 ealgo=3Dblowfish-cbc keylen=3D448 sec=3D512 ok 4444 - big 2 aalgo=3Dhmac/md5 ealgo=3Dblowfish-cbc keylen=3D448 sec=3D512 Standard error: Subprocess timed out; sending KILL signal... =3D=3D=3D> sys/geom/class/eli/onetime_a_test:main Result: broken: Test case timed out Duration: 600.041s Metadata: allowed_architectures is empty allowed_platforms is empty description is empty has_cleanup =3D false required_configs is empty required_disk_space =3D 0 required_files is empty required_memory =3D 0 required_programs is empty required_user =3D root timeout =3D 600 Standard output: 1..1380 ok 1 - aalgo=3Dhmac/md5 ealgo=3Daes keylen=3D0 sec=3D512 . . . ok 794 - aalgo=3Dhmac/ripemd160 ealgo=3Dblowfish-cbc keylen=3D0 sec=3D4096 Standard error: Subprocess timed out; sending KILL signal... --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sat Jun 25 09:16:05 2016 Return-Path: Delivered-To: freebsd-arm@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 119A0B73F34 for ; Sat, 25 Jun 2016 09:16:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 00FE62C41 for ; Sat, 25 Jun 2016 09:16:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u5P9G4Wf073641 for ; Sat, 25 Jun 2016 09:16:04 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 210558] lib/libc failed kyua status for 11.0 -r302180 (only tested on rpi2 with -mcpu=cortex-a7 in use) Date: Sat, 25 Jun 2016 09:16:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 09:16:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210558 Bug ID: 210558 Summary: lib/libc failed kyua status for 11.0 -r302180 (only tested on rpi2 with -mcpu=3Dcortex-a7 in use) Product: Base System Version: 11.0-CURRENT Hardware: arm OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: markmi@dsl-only.net [The ". . ."s are omitted Metadata lines or other omitted blocks of text.] (only tested on rpi2 with -mcpu=3Dcortex-a7 in use) kyua report --results-filter failed --results-file /usr/tests --verbose reports for lib/libc: =3D=3D=3D> lib/libc/ssp/ssp_test:fgets Result: failed: Test case body returned a non-ok exit code, but this is not allowed Duration: 0.159s . . . Standard output: Executing command [ echo ok |/usr/tests/lib/libc/ssp/h_fgets 10 ] Executing command [ /usr/tests/lib/libc/ssp/h_fgets 10 ] Executing command [ echo 0123456789abc |/usr/tests/lib/libc/ssp/h_fgets 13 ] Executing command [ /usr/tests/lib/libc/ssp/h_fgets 13 ] Standard error: Fail: program did not receive a signal stdout: 0123456789ab stderr: =3D=3D=3D> lib/libc/ssp/ssp_test:gets Result: failed: Test case body returned a non-ok exit code, but this is not allowed Duration: 0.152s . . . Standard output: Executing command [ echo ok |/usr/tests/lib/libc/ssp/h_gets ] Executing command [ /usr/tests/lib/libc/ssp/h_gets ] Executing command [ echo 0123456789ab |/usr/tests/lib/libc/ssp/h_gets ] Executing command [ /usr/tests/lib/libc/ssp/h_gets ] Standard error: Fail: program did not receive a signal stdout: 0123456789ab stderr: warning: this program uses gets(), which is unsafe. =3D=3D=3D> lib/libc/ssp/ssp_test:memcpy Result: failed: atf-check failed; see the output of the test for details Duration: 0.150s . . . Standard output: Executing command [ /usr/tests/lib/libc/ssp/h_memcpy 10 ] Executing command [ /usr/tests/lib/libc/ssp/h_memcpy 10 ] Executing command [ /usr/tests/lib/libc/ssp/h_memcpy 13 ] Executing command [ /usr/tests/lib/libc/ssp/h_memcpy 13 ] Standard error: Fail: program did not receive a signal stdout: 1020202020202 stderr: =3D=3D=3D> lib/libc/ssp/ssp_test:memmove Result: failed: atf-check failed; see the output of the test for details Duration: 0.149s . . . Standard output: Executing command [ /usr/tests/lib/libc/ssp/h_memmove 10 ] Executing command [ /usr/tests/lib/libc/ssp/h_memmove 10 ] Executing command [ /usr/tests/lib/libc/ssp/h_memmove 13 ] Executing command [ /usr/tests/lib/libc/ssp/h_memmove 13 ] Standard error: Fail: program did not receive a signal stdout: 1020202020202 stderr: =3D=3D=3D> lib/libc/ssp/ssp_test:memset Result: failed: atf-check failed; see the output of the test for details Duration: 0.152s . . . Standard output: Executing command [ /usr/tests/lib/libc/ssp/h_memset 10 ] Executing command [ /usr/tests/lib/libc/ssp/h_memset 10 ] Executing command [ /usr/tests/lib/libc/ssp/h_memset 13 ] Executing command [ /usr/tests/lib/libc/ssp/h_memset 13 ] Standard error: Fail: program did not receive a signal stdout: stderr: =3D=3D=3D> lib/libc/ssp/ssp_test:read Result: failed: Test case body returned a non-ok exit code, but this is not allowed Duration: 0.159s . . . Standard output: Executing command [ echo foo |/usr/tests/lib/libc/ssp/h_read 1024 ] Executing command [ /usr/tests/lib/libc/ssp/h_read 1024 ] Executing command [ echo bar |/usr/tests/lib/libc/ssp/h_read 1027 ] Executing command [ /usr/tests/lib/libc/ssp/h_read 1027 ] Standard error: Fail: program did not receive a signal stdout: stderr: =3D=3D=3D> lib/libc/ssp/ssp_test:readlink Result: failed: atf-check failed; see the output of the test for details Duration: 0.161s . . . =3D=3D=3D> lib/libc/ssp/ssp_test:readlink Result: failed: atf-check failed; see the output of the test for details Duration: 0.161s Metadata: allowed_architectures is empty allowed_platforms is empty description =3D Checks readlink(2) has_cleanup =3D false required_configs is empty required_disk_space =3D 0 required_files is empty required_memory =3D 0 required_programs is empty required_user is empty timeout =3D 300 Standard output: Executing command [ /usr/tests/lib/libc/ssp/h_readlink 512 ] Executing command [ /usr/tests/lib/libc/ssp/h_readlink 512 ] Executing command [ /usr/tests/lib/libc/ssp/h_readlink 523 ] Executing command [ /usr/tests/lib/libc/ssp/h_readlink 523 ] Standard error: Fail: program did not receive a signal stdout: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa= aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa= aaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa= aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa= aaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa= aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa stderr: =3D=3D=3D> lib/libc/ssp/ssp_test:snprintf Result: failed: atf-check failed; see the output of the test for details Duration: 0.143s . . . Standard output: Executing command [ /usr/tests/lib/libc/ssp/h_snprintf 10 ] Executing command [ /usr/tests/lib/libc/ssp/h_snprintf 10 ] Executing command [ /usr/tests/lib/libc/ssp/h_snprintf 13 ] Executing command [ /usr/tests/lib/libc/ssp/h_snprintf 13 ] Standard error: Fail: program did not receive a signal stdout: 012345678901 stderr: =3D=3D=3D> lib/libc/ssp/ssp_test:sprintf Result: failed: atf-check failed; see the output of the test for details Duration: 0.143s . . . Standard output: Executing command [ /usr/tests/lib/libc/ssp/h_sprintf ok ] Executing command [ /usr/tests/lib/libc/ssp/h_sprintf ok ] Executing command [ /usr/tests/lib/libc/ssp/h_sprintf 0123456789ab ] Executing command [ /usr/tests/lib/libc/ssp/h_sprintf 0123456789ab ] Standard error: Fail: program did not receive a signal stdout: 0123456789ab stderr: =3D=3D=3D> lib/libc/ssp/ssp_test:stpcpy Result: failed: atf-check failed; see the output of the test for details Duration: 0.146s . . . Standard output: Executing command [ /usr/tests/lib/libc/ssp/h_stpcpy 0123456 ] Executing command [ /usr/tests/lib/libc/ssp/h_stpcpy 0123456 ] Executing command [ /usr/tests/lib/libc/ssp/h_stpcpy 0123456789ab ] Executing command [ /usr/tests/lib/libc/ssp/h_stpcpy 0123456789ab ] Standard error: Fail: program did not receive a signal stdout: 0123456789ab stderr: =3D=3D=3D> lib/libc/ssp/ssp_test:stpncpy Result: failed: atf-check failed; see the output of the test for details Duration: 0.149s . . . Standard output: Executing command [ /usr/tests/lib/libc/ssp/h_stpncpy 10 ] Executing command [ /usr/tests/lib/libc/ssp/h_stpncpy 10 ] Executing command [ /usr/tests/lib/libc/ssp/h_stpncpy 13 ] Executing command [ /usr/tests/lib/libc/ssp/h_stpncpy 13 ] Standard error: Fail: program did not receive a signal stdout: 1020202020202 stderr: =3D=3D=3D> lib/libc/ssp/ssp_test:strcat Result: failed: atf-check failed; see the output of the test for details Duration: 0.148s . . . Standard output: Executing command [ /usr/tests/lib/libc/ssp/h_strcat 0123456 ] Executing command [ /usr/tests/lib/libc/ssp/h_strcat 0123456 ] Executing command [ /usr/tests/lib/libc/ssp/h_strcat 0123456789ABCDEF ] Executing command [ /usr/tests/lib/libc/ssp/h_strcat 0123456789ABCDEF ] Standard error: Fail: program did not receive a signal stdout: 10123456789ABCDEF stderr: =3D=3D=3D> lib/libc/ssp/ssp_test:strcpy Result: failed: atf-check failed; see the output of the test for details Duration: 0.152s . . . Standard output: Executing command [ /usr/tests/lib/libc/ssp/h_strcpy 0123456 ] Executing command [ /usr/tests/lib/libc/ssp/h_strcpy 0123456 ] Executing command [ /usr/tests/lib/libc/ssp/h_strcpy 0123456789ab ] Executing command [ /usr/tests/lib/libc/ssp/h_strcpy 0123456789ab ] Standard error: Fail: program did not receive a signal stdout: 0123456789ab stderr: =3D=3D=3D> lib/libc/ssp/ssp_test:strncat Result: failed: atf-check failed; see the output of the test for details Duration: 0.143s . . . Standard output: Executing command [ /usr/tests/lib/libc/ssp/h_strncat 8 ] Executing command [ /usr/tests/lib/libc/ssp/h_strncat 8 ] Executing command [ /usr/tests/lib/libc/ssp/h_strncat 11 ] Executing command [ /usr/tests/lib/libc/ssp/h_strncat 11 ] Standard error: Fail: program did not receive a signal stdout: 11020202020 stderr: =3D=3D=3D> lib/libc/ssp/ssp_test:strncpy Result: failed: atf-check failed; see the output of the test for details Duration: 0.147s . . . Standard output: Executing command [ /usr/tests/lib/libc/ssp/h_strncpy 10 ] Executing command [ /usr/tests/lib/libc/ssp/h_strncpy 10 ] Executing command [ /usr/tests/lib/libc/ssp/h_strncpy 13 ] Executing command [ /usr/tests/lib/libc/ssp/h_strncpy 13 ] Standard error: Fail: program did not receive a signal stdout: 1020202020202 stderr: =3D=3D=3D> lib/libc/ssp/ssp_test:vsnprintf Result: failed: atf-check failed; see the output of the test for details Duration: 0.145s . . . Standard output: Executing command [ /usr/tests/lib/libc/ssp/h_vsnprintf 10 ] Executing command [ /usr/tests/lib/libc/ssp/h_vsnprintf 10 ] Executing command [ /usr/tests/lib/libc/ssp/h_vsnprintf 13 ] Executing command [ /usr/tests/lib/libc/ssp/h_vsnprintf 13 ] Standard error: Fail: program did not receive a signal stdout: 012345678901 stderr: =3D=3D=3D> lib/libc/ssp/ssp_test:vsprintf Result: failed: atf-check failed; see the output of the test for details Duration: 0.146s . . . Standard output: Executing command [ /usr/tests/lib/libc/ssp/h_vsprintf ok ] Executing command [ /usr/tests/lib/libc/ssp/h_vsprintf ok ] Executing command [ /usr/tests/lib/libc/ssp/h_vsprintf 0123456789ab ] Executing command [ /usr/tests/lib/libc/ssp/h_vsprintf 0123456789ab ] Standard error: Fail: program did not receive a signal stdout: 0123456789ab stderr: =3D=3D=3D> lib/libc/stdio/printbasic_test:int_within_limits Result: failed: printf("%tu", (size_t)-1) =3D=3D> [18446744073709551615], e= xpected [4294967295]<> Duration: 0.029s . . . =3D=3D=3D> lib/libc/stdio/scanfloat_test:infinities_and_nans Result: failed: /usr/src/lib/libc/tests/stdio/scanfloat_test.c:191: fetestexcept(FE_INVALID) =3D=3D 0 not met Duration: 0.032s . . . =3D=3D=3D> lib/libc/sys/mincore_test:mincore_resid Result: failed: /usr/src/contrib/netbsd-tests/lib/libc/sys/t_mincore.c:225: check_residency(addr, npgs) =3D=3D 0 not met Duration: 0.041s . . . =3D=3D=3D> lib/libc/sys/mincore_test:mincore_shmseg Result: failed: /usr/src/contrib/netbsd-tests/lib/libc/sys/t_mincore.c:298: check_residency(addr, npgs) =3D=3D 0 not met Duration: 0.032s . . . =3D=3D=3D> lib/libc/tls/tls_dynamic_test:t_tls_dynamic Result: failed: 15 checks failed; see output for more details Duration: 0.037s . . . Standard error: *** Check failed: /usr/src/contrib/netbsd-tests/lib/libc/tls/t_tls_dynamic.c:70: var1 !=3D 1 *** Check failed: /usr/src/contrib/netbsd-tests/lib/libc/tls/t_tls_dynamic.c:71: var2 !=3D 0 *** Check failed: /usr/src/contrib/netbsd-tests/lib/libc/tls/t_tls_dynamic.c:74: var2 !=3D 2 *** Check failed: /usr/src/contrib/netbsd-tests/lib/libc/tls/t_tls_dynamic.c:77: var2 !=3D 3 *** Check failed: /usr/src/contrib/netbsd-tests/lib/libc/tls/t_tls_dynamic.c:80: dso_var1 !=3D getpid *** Check failed: /usr/src/contrib/netbsd-tests/lib/libc/tls/t_tls_dynamic.c:70: var1 !=3D 1 *** Check failed: /usr/src/contrib/netbsd-tests/lib/libc/tls/t_tls_dynamic.c:71: var2 !=3D 0 *** Check failed: /usr/src/contrib/netbsd-tests/lib/libc/tls/t_tls_dynamic.c:74: var2 !=3D 2 *** Check failed: /usr/src/contrib/netbsd-tests/lib/libc/tls/t_tls_dynamic.c:77: var2 !=3D 3 *** Check failed: /usr/src/contrib/netbsd-tests/lib/libc/tls/t_tls_dynamic.c:80: dso_var1 !=3D getpid *** Check failed: /usr/src/contrib/netbsd-tests/lib/libc/tls/t_tls_dynamic.c:70: var1 !=3D 1 *** Check failed: /usr/src/contrib/netbsd-tests/lib/libc/tls/t_tls_dynamic.c:71: var2 !=3D 0 *** Check failed: /usr/src/contrib/netbsd-tests/lib/libc/tls/t_tls_dynamic.c:74: var2 !=3D 2 *** Check failed: /usr/src/contrib/netbsd-tests/lib/libc/tls/t_tls_dynamic.c:77: var2 !=3D 3 *** Check failed: /usr/src/contrib/netbsd-tests/lib/libc/tls/t_tls_dynamic.c:80: dso_var1 !=3D getpid --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sat Jun 25 09:20:07 2016 Return-Path: Delivered-To: freebsd-arm@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 5089DB73F8D for ; Sat, 25 Jun 2016 09:20:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 2CAA12CC6 for ; Sat, 25 Jun 2016 09:20:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u5P9K7sp078597 for ; Sat, 25 Jun 2016 09:20:07 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 210559] lib/libproc failed kyua status for 11.0 -r302180 (only tested on rpi2 with -mcpu=cortex-a7 in use) Date: Sat, 25 Jun 2016 09:20:07 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 09:20:07 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210559 Bug ID: 210559 Summary: lib/libproc failed kyua status for 11.0 -r302180 (only tested on rpi2 with -mcpu=3Dcortex-a7 in use) Product: Base System Version: 11.0-CURRENT Hardware: arm OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: markmi@dsl-only.net [The ". . ."s are omitted Metadata lines or other omitted blocks of text.] (only tested on rpi2 with -mcpu=3Dcortex-a7 in use) kyua report --results-filter failed --results-file /usr/tests --verbose reports for lib/libproc: =3D=3D=3D> lib/libproc/proc_test:symbol_lookup Result: failed: /usr/src/lib/libproc/tests/proc_test.c:116: state !=3D PS_S= TOP: process has state 4 Duration: 0.180s --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sat Jun 25 09:28:32 2016 Return-Path: Delivered-To: freebsd-arm@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 6C8D6B8022F for ; Sat, 25 Jun 2016 09:28:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 4E47012DB for ; Sat, 25 Jun 2016 09:28:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u5P9SWEF097978 for ; Sat, 25 Jun 2016 09:28:32 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 210560] lib/libxo failed kyua status for 11.0 -r302180 (only tested on rpi2 with -mcpu=cortex-a7 in use) Date: Sat, 25 Jun 2016 09:28:32 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 09:28:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210560 Bug ID: 210560 Summary: lib/libxo failed kyua status for 11.0 -r302180 (only tested on rpi2 with -mcpu=3Dcortex-a7 in use) Product: Base System Version: 11.0-CURRENT Hardware: arm OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: markmi@dsl-only.net [The ". . ."s are omitted Metadata lines or other omitted blocks of text.] (only tested on rpi2 with -mcpu=3Dcortex-a7 in use) kyua report --results-filter failed --results-file /usr/tests --verbose reports for lib/libxo: =3D=3D=3D> lib/libxo/functional_test:test_02__E Result: failed: atf-check failed; see the output of the test for details Duration: 0.165s . . . Standard output: Executing command [ env LC_ALL=3Den_US.UTF-8 LIBXO_OPTIONS=3Dwarn,encoder= =3Dtest TZ=3DEST /usr/tests/lib/libxo/test_02 ] Standard error: Fail: stdout does not match golden output --- /usr/tests/lib/libxo/test_02.E.out 2016-06-24 22:54:24.000000000 +0000 +++ /tmp/kyua.atf-tester.VvG1Uz/check.gDrZV4/stdout 2016-06-25 02:27:03.201762000 +0000 @@ -9,9 +9,9 @@ op content: [fd] [-1] op string: [error] [Bad fi] op string: [test] [good] -op content: [lines] [20] -op content: [words] [30] -op content: [characters] [40] +op content: [lines] [171798691870] +op content: [words] [4295004890] +op content: [characters] [0] op open_leaf_list: [bytes] [] op content: [bytes] [0] op content: [bytes] [1] =3D=3D=3D> lib/libxo/functional_test:test_02__H Result: failed: atf-check failed; see the output of the test for details Duration: 0.169s . . . Standard output: Executing command [ env LC_ALL=3Den_US.UTF-8 LIBXO_OPTIONS=3D:WH TZ=3DEST /usr/tests/lib/libxo/test_02 ] Standard error: Fail: stdout does not match golden output --- /usr/tests/lib/libxo/test_02.H.out 2016-06-24 22:54:24.000000000 +0000 +++ /tmp/kyua.atf-tester.BglLS2/check.yfusvJ/stdout 2016-06-25 02:27:03.371048000 +0000 @@ -2,6 +2,8 @@
abcdef: Bad file de= scriptor
improper use of pro= fanity; ten yard penalty; first down . . .
Shut 'er down, Clance= y!=20 She's a-pumpin' mud! <>!,"!<>
\ No newline at end of file =3D=3D=3D> lib/libxo/functional_test:test_02__HIPx Result: failed: atf-check failed; see the output of the test for details Duration: 0.174s . . . Standard output: Executing command [ env LC_ALL=3Den_US.UTF-8 LIBXO_OPTIONS=3D:WHIPx TZ=3DEST /usr/tests/lib/libxo/test_02 ] Standard error: Fail: stdout does not match golden output --- /usr/tests/lib/libxo/test_02.HIPx.out 2016-06-24 22:54:24.0000000= 00 +0000 +++ /tmp/kyua.atf-tester.vtmT9E/check.gPReWl/stdout 2016-06-25 02:27:03.551594000 +0000 @@ -43,13 +43,13 @@
-
= =20=20=20=20 20
+
171798691870
-
= =20=20=20=20 30
+
4295004890
-
=20=20 40
+
=20=20 0
-
file
+
^M^Z%Oc ^M^W8?Mp<9C>
0<= /div> =3D=3D=3D> lib/libxo/functional_test:test_02__HP Result: failed: atf-check failed; see the output of the test for details Duration: 0.168s . . . Standard output: Executing command [ env LC_ALL=3Den_US.UTF-8 LIBXO_OPTIONS=3D:WHP TZ=3DEST /usr/tests/lib/libxo/test_02 ] Standard error: Fail: stdout does not match golden output --- /usr/tests/lib/libxo/test_02.HP.out 2016-06-24 22:54:24.000000000 +0000 +++ /tmp/kyua.atf-tester.V74ZiQ/check.boGRaz/stdout 2016-06-25 02:27:03.725819000 +0000 @@ -43,13 +43,13 @@
-
20
+
171798691870
-
30
+
4295004890
-
40
+
0
-
file
+
^K^X<= BF>#Ma ^K^U6=3DKn<9A>
0
=3D=3D=3D> lib/libxo/functional_test:test_02__J Result: failed: atf-check failed; see the output of the test for details Duration: 0.168s . . . Standard output: Executing command [ env LC_ALL=3Den_US.UTF-8 LIBXO_OPTIONS=3D:WJ TZ=3DEST /usr/tests/lib/libxo/test_02 ] Standard error: Fail: stdout does not match golden output --- /usr/tests/lib/libxo/test_02.J.out 2016-06-24 22:54:24.000000000 +0000 +++ /tmp/kyua.atf-tester.7GQOqM/check.gUf41f/stdout 2016-06-25 02:27:03.899756000 +0000 @@ -1,2 +1,2 @@ . . . } =3D=3D=3D> lib/libxo/functional_test:test_02__JP Result: failed: atf-check failed; see the output of the test for details Duration: 0.165s . . . Standard output: Executing command [ env LC_ALL=3Den_US.UTF-8 LIBXO_OPTIONS=3D:WJP TZ=3DEST /usr/tests/lib/libxo/test_02 ] Standard error: Fail: stdout does not match golden output --- /usr/tests/lib/libxo/test_02.JP.out 2016-06-24 22:54:24.000000000 +0000 +++ /tmp/kyua.atf-tester.sei1Wx/check.FD8HKC/stdout 2016-06-25 02:27:04.070827000 +0000 @@ -9,9 +9,9 @@ "fd": -1, "error": "Bad fi", "test": "good", - "lines": 20, - "words": 30, - "characters": 40, + "lines": 171798691870, + "words": 4295004890, + "characters": 0, "bytes": [ 0, 1, =3D=3D=3D> lib/libxo/functional_test:test_02__T Result: failed: atf-check failed; see the output of the test for details Duration: 0.169s . . . Standard output: Executing command [ env LC_ALL=3Den_US.UTF-8 LIBXO_OPTIONS=3D:WT TZ=3DEST /usr/tests/lib/libxo/test_02 ] Standard error: Fail: stderr does not match golden output --- /usr/tests/lib/libxo/test_02.T.err 2016-06-24 22:54:24.000000000 +0000 +++ /tmp/kyua.atf-tester.z9j1Uf/check.xlrmOa/stderr 2016-06-25 02:27:04.243815000 +0000 @@ -1 +1,2 @@ +test_02: invalid UTF-8 character: e5/3 Shut 'er down, Clancey! She's a-pumpin' mud! <>!,"!<> =3D=3D=3D> lib/libxo/functional_test:test_02__X Result: failed: atf-check failed; see the output of the test for details Duration: 0.165s . . . Standard output: Executing command [ env LC_ALL=3Den_US.UTF-8 LIBXO_OPTIONS=3D:WX TZ=3DEST /usr/tests/lib/libxo/test_02 ] Standard error: Fail: stdout does not match golden output --- /usr/tests/lib/libxo/test_02.X.out 2016-06-24 22:54:24.000000000 +0000 +++ /tmp/kyua.atf-tester.ndyVwl/check.qGWl5s/stdout 2016-06-25 02:27:04.413108000 +0000 @@ -2,6 +2,6 @@ abcdef: Bad file descriptor improper use of profanity; ten yard penalty; first down . . . Shut 'er down, Clancey! She's a-pumpin' mud!=20 <>!,"!<> \ No newline at end of file =3D=3D=3D> lib/libxo/functional_test:test_02__XP Result: failed: atf-check failed; see the output of the test for details Duration: 0.170s . . . Standard output: Executing command [ env LC_ALL=3Den_US.UTF-8 LIBXO_OPTIONS=3D:WXP TZ=3DEST /usr/tests/lib/libxo/test_02 ] Standard error: Fail: stdout does not match golden output --- /usr/tests/lib/libxo/test_02.XP.out 2016-06-24 22:54:24.000000000 +0000 +++ /tmp/kyua.atf-tester.YC4Lbu/check.iCXJrS/stdout 2016-06-25 02:27:04.588569000 +0000 @@ -16,9 +16,9 @@ good improper use of profanity; ten yard penalty; first down - 20 - 30 - 40 + 171798691870 + 4295004890 + 0 0 1 2 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sat Jun 25 09:31:44 2016 Return-Path: Delivered-To: freebsd-arm@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 14ECBB8027C for ; Sat, 25 Jun 2016 09:31:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 EB1171529 for ; Sat, 25 Jun 2016 09:31:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u5P9Vhoe007324 for ; Sat, 25 Jun 2016 09:31:43 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 210561] lib/msun failed kyua status for 11.0 -r302180 (only tested on rpi2 with -mcpu=cortex-a7 in use) Date: Sat, 25 Jun 2016 09:31:44 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 09:31:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210561 Bug ID: 210561 Summary: lib/msun failed kyua status for 11.0 -r302180 (only tested on rpi2 with -mcpu=3Dcortex-a7 in use) Product: Base System Version: 11.0-CURRENT Hardware: arm OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: markmi@dsl-only.net [The ". . ."s are omitted Metadata lines or other omitted blocks of text.] (only tested on rpi2 with -mcpu=3Dcortex-a7 in use) kyua report --results-filter failed --results-file /usr/tests --verbose reports for lib/msun: =3D=3D=3D> lib/msun/conj_test:main Result: failed: 9 tests of 42 failed Duration: 0.034s . . . Standard output: 1..42 ok 1 # conjf(0.0 + 0.0I) ok 2 # conj(0.0 + 0.0I) ok 3 # conjl(0.0 + 0.0I) ok 4 # conjf(0.0 + 1.0I) ok 5 # conj(0.0 + 1.0I) ok 6 # conjl(0.0 + 1.0I) ok 7 # conjf(1.0 + 0.0I) ok 8 # conj(1.0 + 0.0I) ok 9 # conjl(1.0 + 0.0I) ok 10 # conjf(-1.0 + 0.0I) ok 11 # conj(-1.0 + 0.0I) ok 12 # conjl(-1.0 + 0.0I) ok 13 # conjf(1.0 + -0.0I) ok 14 # conj(1.0 + -0.0I) ok 15 # conjl(1.0 + -0.0I) ok 16 # conjf(0.0 + -1.0I) ok 17 # conj(0.0 + -1.0I) ok 18 # conjl(0.0 + -1.0I) ok 19 # conjf(2.0 + 4.0I) ok 20 # conj(2.0 + 4.0I) ok 21 # conjl(2.0 + 4.0I) ok 22 # conjf(0.0 + infI) ok 23 # conj(0.0 + infI) ok 24 # conjl(0.0 + infI) ok 25 # conjf(0.0 + -infI) ok 26 # conj(0.0 + -infI) ok 27 # conjl(0.0 + -infI) ok 28 # conjf(inf + 0.0I) ok 29 # conj(inf + 0.0I) ok 30 # conjl(inf + 0.0I) not ok 31 # conjf(nan + 1.0I): threw an exception not ok 32 # conj(nan + 1.0I): threw an exception not ok 33 # conjl(nan + 1.0I): threw an exception not ok 34 # conjf(1.0 + nanI): threw an exception not ok 35 # conj(1.0 + nanI): threw an exception not ok 36 # conjl(1.0 + nanI): threw an exception not ok 37 # conjf(nan + nanI): threw an exception not ok 38 # conj(nan + nanI): threw an exception not ok 39 # conjl(nan + nanI): threw an exception ok 40 # conjf(-inf + infI) ok 41 # conj(-inf + infI) ok 42 # conjl(-inf + infI) =3D=3D=3D> lib/msun/ldexp_test:ldexp_denormal Result: failed: 4 checks failed; see output for more details Duration: 0.032s . . . Standard error: *** Check failed: /usr/src/contrib/netbsd-tests/lib/libm/t_ldexp.c:182: table->result !=3D outbuf (1.1125369292536006915451e-308 !=3D 1.6688053938804010373177e-308) : Entry 1: Exp: "1.1125369292536006915451e-308" Act: "1.6688053938804010373177e-308" *** Check failed: /usr/src/contrib/netbsd-tests/lib/libm/t_ldexp.c:182: table->result !=3D outbuf (1.1125369292536006915451e-308 !=3D 1.6688053938804010373177e-308) : Entry 2: Exp: "1.1125369292536006915451e-308" Act: "1.6688053938804010373177e-308" *** Check failed: /usr/src/contrib/netbsd-tests/lib/libm/t_ldexp.c:182: table->result !=3D outbuf (-1.1125369292536006915451e-308 !=3D -1.6688053938804010373177e-30 8): Entry 6: Exp: "-1.1125369292536006915451e-308" Act: "-1.6688053938804010373177e-308" *** Check failed: /usr/src/contrib/netbsd-tests/lib/libm/t_ldexp.c:182: table->result !=3D outbuf (-1.1125369292536006915451e-308 !=3D -1.6688053938804010373177e-30 8): Entry 7: Exp: "-1.1125369292536006915451e-308" Act: "-1.6688053938804010373177e-308" --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sat Jun 25 09:34:42 2016 Return-Path: Delivered-To: freebsd-arm@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 6B57CB80479 for ; Sat, 25 Jun 2016 09:34:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 592A518DD for ; Sat, 25 Jun 2016 09:34:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u5P9YgfU012038 for ; Sat, 25 Jun 2016 09:34:42 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 210562] local/kyua failed kyua status for 11.0 -r302180 (only tested on rpi2 with -mcpu=cortex-a7 in use) Date: Sat, 25 Jun 2016 09:34:42 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 09:34:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210562 Bug ID: 210562 Summary: local/kyua failed kyua status for 11.0 -r302180 (only tested on rpi2 with -mcpu=3Dcortex-a7 in use) Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: markmi@dsl-only.net [The ". . ."s are omitted Metadata lines or other omitted blocks of text.] (only tested on rpi2 with -mcpu=3Dcortex-a7 in use) kyua report --results-filter failed --results-file /usr/tests --verbose reports for local/kyua: =3D=3D=3D> local/kyua/model/metadata_test:override_all_with_set_string Result: failed: Line 253: disk_space !=3D md.required_disk_space() (1677721= 6.00T !=3D 2.00G) Duration: 0.045s . . . =3D=3D=3D> local/kyua/testers/tap_parser_test:try_parse_plan__insane Result: failed: testers/tap_parser_test.c:135: 'too long' not matched in 'P= lan line includes out of range numbers' Duration: 0.034s . . . Standard output: Looking for 'too long' in 'Plan line includes out of range numbers' --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sat Jun 25 09:37:21 2016 Return-Path: Delivered-To: freebsd-arm@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 C8661B8056B for ; Sat, 25 Jun 2016 09:37:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 B81601A26 for ; Sat, 25 Jun 2016 09:37:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u5P9bLaE015125 for ; Sat, 25 Jun 2016 09:37:21 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 210563] sys/geom failed kyua status for 11.0 -r302180 (only tested on rpi2 with -mcpu=cortex-a7 in use) Date: Sat, 25 Jun 2016 09:37:21 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 09:37:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210563 Bug ID: 210563 Summary: sys/geom failed kyua status for 11.0 -r302180 (only tested on rpi2 with -mcpu=3Dcortex-a7 in use) Product: Base System Version: 11.0-CURRENT Hardware: arm OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: markmi@dsl-only.net [The ". . ."s are omitted Metadata lines or other omitted blocks of text.] (only tested on rpi2 with -mcpu=3Dcortex-a7 in use) kyua report --results-filter failed --results-file /usr/tests --verbose reports for sys/geom: =3D=3D=3D> sys/geom/class/eli/resize_test:main Result: failed: 15 tests of 27 failed Duration: 1.094s . . . Standard output: 1..27 not ok 1 - Sized md2a to 10m not ok 2 - Initialised geli on md2a not ok 3 - Attached md2a as md2a.eli not ok 4 - Initialised the filesystem on md2a.eli ok 5 - fsck says md2a.eli is clean, 3 lines of output not ok 6 - Backed up md2a metadata not ok 7 - Detached md2a.eli not ok 8 - Sized md2a to 20m ok 9 - Attaching md2a fails after resizing the consumer ok 10 - Restoring metadata on md2a.eli fails without -f not ok 11 - Restoring metadata on md2a.eli can be forced not ok 12 - Attaching md2a is now possible not ok 13 - Extended the filesystem on md2a.eli ok 14 - fsck says md2a.eli is clean, 3 lines of output not ok 15 - Detached md2a.eli not ok 16 - Sized md2a to 30m not ok 17 - Resizing works ok ok 18 - Resizing doesn't work a 2nd time (no old metadata) not ok 19 - Attaching md2a works ok not ok 20 - Extended the filesystem on md2a.eli ok 21 - fsck says md2a.eli is clean, 3 lines of output md2 created ok 22 - Installed a GPT on md2 md2p1 added ok 23 - Added a 20m partition in slot 1 ok 24 - Initialised geli on md2p1 md2p1 resized ok 25 - Resized partition md2p1 to 30m ok 26 - Resized geli on md2p1 to 30m ok 27 - Attached md2p1.eli Standard error: /usr/tests/sys/geom/class/eli/resize_test: disklabel: not found geli: Cannot get informations about md2a: No such file or directory. geli: Cannot open md2a: No such file or directory. newfs: /dev/md2a.eli: could not find special device geli: Cannot get informations about md2a: No such file or directory. geli: No such device: md2a.eli. /usr/tests/sys/geom/class/eli/resize_test: disklabel: not found geli: Cannot open md2a: No such file or directory. geli: Cannot open tmp.meta: No such file or directory. geli: Cannot open tmp.meta: No such file or directory. geli: Cannot open md2a: No such file or directory. growfs: cannot find special device for md2a.eli geli: No such device: md2a.eli. /usr/tests/sys/geom/class/eli/resize_test: disklabel: not found geli: Cannot open md2a: No such file or directory. geli: Cannot open md2a: No such file or directory. geli: Cannot open md2a: No such file or directory. growfs: cannot find special device for md2a.eli geli: No such device: md2a.eli. gpart: arg0 'md2': Invalid argument --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sat Jun 25 09:40:59 2016 Return-Path: Delivered-To: freebsd-arm@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 C76E0B805E3 for ; Sat, 25 Jun 2016 09:40:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 9D4851BF7 for ; Sat, 25 Jun 2016 09:40:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u5P9ex5N020625 for ; Sat, 25 Jun 2016 09:40:59 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 210564] sys/kern failed kyua status for 11.0 -r302180 (only tested on rpi2 with -mcpu=cortex-a7 in use) Date: Sat, 25 Jun 2016 09:40:59 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 09:40:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210564 Bug ID: 210564 Summary: sys/kern failed kyua status for 11.0 -r302180 (only tested on rpi2 with -mcpu=3Dcortex-a7 in use) Product: Base System Version: 11.0-CURRENT Hardware: arm OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: markmi@dsl-only.net [The ". . ."s are omitted Metadata lines or other omitted blocks of text.] (only tested on rpi2 with -mcpu=3Dcortex-a7 in use) kyua report --results-filter failed --results-file /usr/tests --verbose reports for sys/kern: =3D=3D=3D> sys/kern/pipe/pipe_fstat_bug_test:main Result: failed: Returned non-success exit status 1 Duration: 0.038s . . . Standard output: SUCCESS at stat size 145 read size 145 SUCCESS at stat size 2048 read size 2048 SUCCESS at stat size 4096 read size 4096 SUCCESS at stat size 8191 read size 8191 Standard error: pipe_fstat_bug_test: pipe_fstat_bug_test: 122: sending synchronization94: waiting for synchronization pipe_fstat_bug_test: 123: waiting for synchronization pipe_fstat_bug_test: 96: sending synchronization pipe_fstat_bug_test: 98: waiting for synchronization pipe_fstat_bug_test: 122: sending synchronization pipe_fstat_bug_test: 123: waiting for synchronization pipe_fstat_bug_test: 100: sending synchronization pipe_fstat_bug_test: 102: waiting for synchronization pipe_fstat_bug_test: 122: sending synchronization pipe_fstat_bug_test: pipe_fstat_bug_test: 123: waiting for synchronization 104: sending synchronization pipe_fstat_bug_test: 106: waiting for synchronization pipe_fstat_bug_test: 122: sending synchronization pipe_fstat_bug_test: 123: waiting for synchronization pipe_fstat_bug_test: 108: sending synchronization pipe_fstat_bug_test: 110: waiting for synchronization pipe_fstat_bug_test: 122: sending synchronization pipe_fstat_bug_test: pipe_fstat_bug_test: 123: waiting for synchronization 111: sending synchronization pipe_fstat_bug_test: pipe_fstat_bug_test: 113: sending synchronization FAILURE: stat size 0 read size 8192: No error: 0 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sat Jun 25 09:43:13 2016 Return-Path: Delivered-To: freebsd-arm@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 B7F73B806E5 for ; Sat, 25 Jun 2016 09:43:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 8DC301D66 for ; Sat, 25 Jun 2016 09:43:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u5P9hDHP029048 for ; Sat, 25 Jun 2016 09:43:13 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 210565] usr.bin/lastcomm failed kyua status for 11.0 -r302180 (only tested on rpi2 with -mcpu=cortex-a7 in use) Date: Sat, 25 Jun 2016 09:43:13 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 09:43:13 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210565 Bug ID: 210565 Summary: usr.bin/lastcomm failed kyua status for 11.0 -r302180 (only tested on rpi2 with -mcpu=3Dcortex-a7 in use) Product: Base System Version: 11.0-CURRENT Hardware: arm OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: markmi@dsl-only.net [The ". . ."s are omitted Metadata lines or other omitted blocks of text.] (only tested on rpi2 with -mcpu=3Dcortex-a7 in use) kyua report --results-filter failed --results-file /usr/tests --verbose reports for usr.bin/lastcomm: =3D=3D=3D> usr.bin/lastcomm/legacy_test:main Result: failed: 4 tests of 6 failed Duration: 0.139s . . . Standard output: 1..6 not ok 1 not ok 2 not ok 3 not ok 4 ok 5 ok 6 Standard error: cat: /usr/tests/usr.bin/lastcomm/v1-arm-acct.in: No such file or directory cat: /usr/tests/usr.bin/lastcomm/v2-arm-acct.in: No such file or directory cat: /usr/tests/usr.bin/lastcomm/v2-arm.out: No such file or directory cat: /usr/tests/usr.bin/lastcomm/v1-arm.out: No such file or directory lastcomm: could not open /usr/tests/usr.bin/lastcomm/v1-arm-acct.in: No such file or directory diff: /usr/tests/usr.bin/lastcomm/v1-arm.out: No such file or directory /usr/tests/usr.bin/lastcomm/legacy_test: cannot open /usr/tests/usr.bin/lastcomm/v1-arm-acct.in: No such file or directory diff: /usr/tests/usr.bin/lastcomm/v1-arm.out: No such file or directory lastcomm: could not open /usr/tests/usr.bin/lastcomm/v2-arm-acct.in: No such file or directory diff: /usr/tests/usr.bin/lastcomm/v2-arm.out: No such file or directory /usr/tests/usr.bin/lastcomm/legacy_test: cannot open /usr/tests/usr.bin/lastcomm/v2-arm-acct.in: No such file or directory diff: /usr/tests/usr.bin/lastcomm/v2-arm.out: No such file or directory --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sat Jun 25 09:46:33 2016 Return-Path: Delivered-To: freebsd-arm@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 568A1B8076F for ; Sat, 25 Jun 2016 09:46:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 45E761E08 for ; Sat, 25 Jun 2016 09:46:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u5P9kXYk033074 for ; Sat, 25 Jun 2016 09:46:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 210566] usr.sbin/sa failed kyua status for 11.0 -r302180 (only tested on rpi2 with -mcpu=cortex-a7 in use) Date: Sat, 25 Jun 2016 09:46:33 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 09:46:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210566 Bug ID: 210566 Summary: usr.sbin/sa failed kyua status for 11.0 -r302180 (only tested on rpi2 with -mcpu=3Dcortex-a7 in use) Product: Base System Version: 11.0-CURRENT Hardware: arm OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: markmi@dsl-only.net [The ". . ."s are omitted Metadata lines or other omitted blocks of text.] (only tested on rpi2 with -mcpu=3Dcortex-a7 in use) kyua report --results-filter failed --results-file /usr/tests --verbose reports for usr.sbin/sa: =3D=3D=3D> usr.sbin/sa/legacy_test:main Result: failed: 12 tests of 13 failed Duration: 0.330s . . . Standard output: 1..13 not ok 1 not ok 2 not ok 3 not ok 4 not ok 5 not ok 6 not ok 7 not ok 8 not ok 9 not ok 10 not ok 11 not ok 12 ok 13 Standard error: install: /usr/tests/usr.sbin/sa/../../usr.bin/lastcomm/v1-arm-acct.in: No s= uch file or directory install: /usr/tests/usr.sbin/sa/../../usr.bin/lastcomm/v2-arm-acct.in: No s= uch file or directory sa: open v1-arm-acct.in read-only: No such file or directory diff: /usr/tests/usr.sbin/sa/v1-arm-u.out: No such file or directory sa: open v2-arm-acct.in read-only: No such file or directory diff: /usr/tests/usr.sbin/sa/v2-arm-u.out: No such file or directory sa: open v1-arm-acct.in read-only: No such file or directory diff: /usr/tests/usr.sbin/sa/v1-arm-sav.out: No such file or directory diff: /usr/tests/usr.sbin/sa/v1-arm-usr.out: No such file or directory sa: open v1-arm-acct.in read-only: No such file or directory diff: /usr/tests/usr.sbin/sa/v1-arm-sav.out: No such file or directory diff: /usr/tests/usr.sbin/sa/v1-arm-usr.out: No such file or directory install: /usr/tests/usr.sbin/sa/v1-arm-sav.in: No such file or directory install: /usr/tests/usr.sbin/sa/v1-arm-usr.in: No such file or directory diff: /usr/tests/usr.sbin/sa/v1-arm-sav.out: No such file or directory diff: /usr/tests/usr.sbin/sa/v1-arm-usr.out: No such file or directory diff: /usr/tests/usr.sbin/sa/v1-arm-sav.out: No such file or directory diff: /usr/tests/usr.sbin/sa/v1-arm-usr.out: No such file or directory sa: open v1-arm-acct.in for read/write: No such file or directory diff: /usr/tests/usr.sbin/sa/v1-arm-sav.out: No such file or directory diff: /usr/tests/usr.sbin/sa/v1-arm-usr.out: No such file or directory install: /usr/tests/usr.sbin/sa/../../usr.bin/lastcomm/v1-arm-acct.in: No s= uch file or directory sa: open v1-arm-acct.in for read/write: No such file or directory install: /usr/tests/usr.sbin/sa/../../usr.bin/lastcomm/v1-arm-acct.in: No s= uch file or directory sa: open v1-arm-acct.in for read/write: No such file or directory cp: /usr/tests/usr.sbin/sa/../../usr.bin/lastcomm/v1-arm-acct.in: No such f= ile or directory sa: open v1-arm-acct.in read-only: No such file or directory sa: open v1-arm-acct.in read-only: No such file or directory --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sat Jun 25 10:26:28 2016 Return-Path: Delivered-To: freebsd-arm@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 0C797B80115 for ; Sat, 25 Jun 2016 10:26:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-153.reflexion.net [208.70.211.153]) (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 9CB802F70 for ; Sat, 25 Jun 2016 10:26:26 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15810 invoked from network); 25 Jun 2016 10:27:02 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 25 Jun 2016 10:27:02 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Sat, 25 Jun 2016 06:26:21 -0400 (EDT) Received: (qmail 28810 invoked from network); 25 Jun 2016 10:26:21 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Jun 2016 10:26:21 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 78E431C407C; Sat, 25 Jun 2016 03:26:23 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists From: Mark Millard In-Reply-To: Date: Sat, 25 Jun 2016 03:26:23 -0700 Cc: Alan Somers , Ian Lepore , "Conrad E. Meyer" , freebsd-arm , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <5D3DEF2A-A14F-456B-B2D5-4E95BD273DB7@dsl-only.net> References: <1465862808.1188.129.camel@freebsd.org> <6727481C-8BD2-4F00-A6F6-3BEE3CC7F2FA@dsl-only.net> To: Ngie Cooper X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 10:26:28 -0000 On 2016-Jun-25, at 12:44 AM, Ngie Cooper = wrote: > On Fri, Jun 24, 2016 at 9:50 PM, Mark Millard = wrote: >> On 2016-Jun-24, at 2:50 PM, Alan Somers wrote: >>=20 >>> As of r302180., the usr.sbin/rpcbind, sys/acl, and sys/sys/bitstring >>> tests should all be fixed. I opened PR 210329 for the >>> usr.bin/lastcomm test. I haven't investigated the others. >=20 > ... >=20 >> This time the totals were 15 broken (down from 24) and 41 failed = (down >> from 59). >>=20 >> My results this time were. . . >=20 > Hi Mark, > Please file bugs for all of the individual component failures, > e.g. lib/msun, and CC me on the bugs. > Thanks, > -Ngie Done. I generally omitted the --verbose Metadata output. For a few there = was a large block of Standard output or Standard error text that I = omitted. I was not sure of the intent but I put all the lib/msun "broken" items = in one submittal, for example. Similarly for each of the other "broken" = components. Similarly for lib/msun "failed" items (a separate submittal). Similarly = for each of the other "failed" components. I noted explicitly in each submittal that I'd used -mcpu=3Dcortex-a7 in = my builds. But in more detail: A) buildworld and buildkernel had -march=3Darmv7-a -mcpu=3Dcortex-a7 = both listed B) ports builds (such as kyua itself) had -mcpu=3Dcortex-a7 (but not = -march=3Darmv7-a) This is because for ports I use options that do not complain for either = clang 3.8.0 or for fairly modern gcc and gcc does complain about = specifying both -mcpu=3Darmv7-a and -mcpu=3Dcortex-a7. Even the = "armv7-a" notation is from gcc rejecting armv7a but both clang and gcc = accepting armv7-a notation. (As I remember gcc uses -march=3Darmv7-a where it conflicts with = -mcpu=3Dcortex-a7 when both are listed but gcc does warn about conflict = despite having a resolution rule.) Other than the 11.0 -r302180 being more recent the "context details" in = https://lists.freebsd.org/pipermail/freebsd-current/2016-June/061831.html still apply. I did not repeat that information in the submittals but at = least the src.conf and the like are available for reference. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sat Jun 25 15:25:47 2016 Return-Path: Delivered-To: freebsd-arm@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 C47F7B81539 for ; Sat, 25 Jun 2016 15:25:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 B3D231BF9 for ; Sat, 25 Jun 2016 15:25:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u5PFPlxe038745 for ; Sat, 25 Jun 2016 15:25:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 210565] usr.bin/lastcomm failed kyua status for 11.0 -r302180 (only tested on rpi2 with -mcpu=cortex-a7 in use) Date: Sat, 25 Jun 2016 15:25:47 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: asomers@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: DUPLICATE X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 15:25:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210565 Alan Somers changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|Open |Closed --- Comment #2 from Alan Somers --- *** This bug has been marked as a duplicate of bug 204154 *** --=20 You are receiving this mail because: You are the assignee for the bug.=