From owner-freebsd-sparc64@FreeBSD.ORG Sun Apr 22 20:40:13 2012 Return-Path: Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C2041065670 for ; Sun, 22 Apr 2012 20:40:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 46FA38FC16 for ; Sun, 22 Apr 2012 20:40:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q3MKeDVs098089 for ; Sun, 22 Apr 2012 20:40:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3MKeDtu098088; Sun, 22 Apr 2012 20:40:13 GMT (envelope-from gnats) Date: Sun, 22 Apr 2012 20:40:13 GMT Message-Id: <201204222040.q3MKeDtu098088@freefall.freebsd.org> To: freebsd-sparc64@FreeBSD.org From: Marius Strobl Cc: Subject: Re: sparc64/165025: [PATCH] zfsboot support for sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marius Strobl List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 20:40:13 -0000 The following reply was made to PR sparc64/165025; it has been noted by GNATS. From: Marius Strobl To: Gavin Mu Cc: bug-followup@freebsd.org, Kurt Lidl Subject: Re: sparc64/165025: [PATCH] zfsboot support for sparc64 Date: Sun, 22 Apr 2012 22:32:11 +0200 On Thu, Apr 12, 2012 at 10:27:31PM +0800, Gavin Mu wrote: > On Mon, Mar 5, 2012 at 2:06 AM, Marius Strobl wrote: > > Typically, opening and closing devices via OFW causes quite a delay, > > the exact impact depends on the firmware version and the devices > > involved though. Therefore, it would be advisable to keep using the > > current approach of caching opened packages. In what way does this > > fail with ZFS? > The error message on Fire V100 is: Fast Data Access MMU Miss > > > Basically, IEEE 1275 just says that support for > > opening a package more than once depends on the particular package > > but nothing about concurrently opening different packages. Not > > being able to concurrently open different packages also doesn't > > make all that much of a sense as opening one package also means > > to subsequentially open all the parents up to the root if not > > already opened and I think to actually have tested opening disks > > concurrently when writing the current code. Could this fail due > > to one device actually being opened twice, once via the full path > > and once via its alias? > There is no such scene though the code lacks the checking for full > path/devalias. > I have tried many times to find the root cause but I think it is > difficult without open firmware knowledge. > currently I found that following scenes will cause this issue with my test code: > 1. do OF_seek(ihandle_t a) just after OF_close(ihandle_t b). in real > world, OF_seek(a) is the step to read ZFS data just after OF_close() > another disk during zfs init/probe. > 2. do OF_seek(ihandle_t a) just after OF_open("available controller > without disk"). For example there is no disk3 on my machine though > there is disk controller. OF_open("disk3:") will report: > Can't read disk label. > Can't open disk label package > > in ofw_disk.c, OF_close() has been commented out for powerpc > architecture, and can not find detail reason from code history, so I > am thinking if we need also disable OF_close() for sparc64. Hrm, some OFW implementations might have reference counting bugs, causing OF_close() to also close some parent(s) when these in fact are still used by another opened child device. Have you tried how it works when just commenting out the OF_close() in ofwd_close() but leaving the rest of ofw_disk.c as is? If that works, we probably can add a cleanup handler which closes all opened disk devices before leaving the loader, still taking advantage of caching opened disks. > > for OF_open("normal disk controller without disk") issue, I did not > find how to work around or fix yet. Currently, I can't think of a way to solve this with the available OFW interfaces. Have you checked whether OpenSolaris includes the source of the OFW ZFS loader bits and how it's done there or generally how a Solaris instalaltion handles this (f.e. does it create any additional aliases for ZFS providers and uses these instead etc)? > > Is there any documents about how this open firmware work? I googled > but can not find anything useful. > For the most part, there's just IEEE 1275. There once was a bit of related information on http://playground.sun.com/1275/, which unfortunately disappeared some time after Oracle took over. Marius From owner-freebsd-sparc64@FreeBSD.ORG Mon Apr 23 11:07:25 2012 Return-Path: Delivered-To: freebsd-sparc64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A3762106566B for ; Mon, 23 Apr 2012 11:07:25 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8CF468FC23 for ; Mon, 23 Apr 2012 11:07:25 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q3NB7P4W047708 for ; Mon, 23 Apr 2012 11:07:25 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3NB7On0047706 for freebsd-sparc64@FreeBSD.org; Mon, 23 Apr 2012 11:07:24 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 23 Apr 2012 11:07:24 GMT Message-Id: <201204231107.q3NB7On0047706@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-sparc64@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-sparc64@FreeBSD.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 11:07:25 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o sparc/165025 sparc64 [PATCH] zfsboot support for sparc64 o sparc/164227 sparc64 [boot] Can't boot 9.0-RELEASE/sparc64 on Blade 1500 o sparc/164226 sparc64 [cd] Data corruption on 9.0-RELEASE when reading from o sparc/162513 sparc64 mpt(4), mptutil(8) reports variable, erroneous drive i o sparc/141918 sparc64 [ehci] ehci_interrupt: unrecoverable error, controller s sparc/139134 sparc64 kernel output corruption s sparc/107087 sparc64 [hang] system is hung during boot from CD o sparc/105048 sparc64 [trm] trm(4) panics on sparc64 o sparc/104428 sparc64 [nullfs] nullfs panics on E4500 (but not E420) o sparc/71729 sparc64 printf in kernel thread causes panic on SPARC 10 problems total. From owner-freebsd-sparc64@FreeBSD.ORG Mon Apr 23 14:26:22 2012 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 382341065674 for ; Mon, 23 Apr 2012 14:26:22 +0000 (UTC) (envelope-from thogard@abnormal.com) Received: from v.abnormal.com (v.abnormal.com [64.27.26.128]) by mx1.freebsd.org (Postfix) with ESMTP id 1EC218FC19 for ; Mon, 23 Apr 2012 14:26:22 +0000 (UTC) Received: (from thogard@localhost) by v.abnormal.com (8.14.4/8.14.1) id q3NEQFSm066866 for freebsd-sparc64@freebsd.org; Mon, 23 Apr 2012 14:26:15 GMT (envelope-from thogard) From: Tim Hogard Message-Id: <201204231426.q3NEQFSm066866@v.abnormal.com> To: freebsd-sparc64@freebsd.org Date: Mon, 23 Apr 2012 14:26:15 +0000 (UTC) In-Reply-To: <20120423120040.01C8C106582A@hub.freebsd.org> X-Foo: Mon Apr 23 14:26:15 UTC 2012 X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Slow on v210? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 14:26:22 -0000 I'm at the inital stages of looking into the problems here. I just put Release 9.0 on a single CPU v210 and it is much slower than I expected. A simple perl program runs at 1/6th the speed of the Solaris 9 machine I'm testing aginst. Other things involing basic utils also seem to run about that ratio. Compiles are also very slow. For testing I've got a Sol 9 dual 1.33 Ghz netra 210 with 4 gig of ram and a single 1.33 ghz v210 with 2 gig of ram. My tests show both system have about 1 gig free and I run 4 processes per core: #!/usr/bin/perl foreach $i (1..1000000) { $i{$i}=$i; } The FreeBSD 9.0 and perl 5.12 (from ports) with no load is running much slower than the Sol 9 with perl 5.10 a few other things running. sol$ time ./p real 0m4.110s user 0m3.430s sys 0m0.610s f9$ time ./p 27.24 real 6.10 user 21.00 sys 2 on f9 take 55 or so seconds, 4 on the dual cpu take about 8 seconds. Other things also seem slower but I haven't benchmarked them but they should in the are ballpark. The disks on the n210 are 2.5 and 3.5 on the v210. Both are 7200 rpm but everything is in cache. The ram seems identical. The freeBSD machine should not be 7 times slower. Other issues: 1) The machine needed the vm.kmem_size="1024" in /etc/loader.conf or it wouldn't boot. (http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2012-01/msg00414.html) fixed by stopping boot and typing something like set vm.kmem_size="1024m" at the laoder prompt. 2) base.txz just wouldn't end up with the right sha-256 hash even when checked on other machines. Fixed by using net install. Any hints? Thanks, -tim http://web.abnormal.com > > Send freebsd-sparc64 mailing list submissions to > freebsd-sparc64@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 > or, via email, send a message with subject or body 'help' to > freebsd-sparc64-request@freebsd.org > > You can reach the person managing the list at > freebsd-sparc64-owner@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-sparc64 digest..." > > > Today's Topics: > > 1. Re: sparc64/165025: [PATCH] zfsboot support for sparc64 > (Marius Strobl) > 2. Current problem reports assigned to > freebsd-sparc64@FreeBSD.org (FreeBSD bugmaster) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 22 Apr 2012 20:40:13 GMT > From: Marius Strobl > Subject: Re: sparc64/165025: [PATCH] zfsboot support for sparc64 > To: freebsd-sparc64@FreeBSD.org > Message-ID: <201204222040.q3MKeDtu098088@freefall.freebsd.org> > > The following reply was made to PR sparc64/165025; it has been noted by GNATS. > > From: Marius Strobl > To: Gavin Mu > Cc: bug-followup@freebsd.org, Kurt Lidl > Subject: Re: sparc64/165025: [PATCH] zfsboot support for sparc64 > Date: Sun, 22 Apr 2012 22:32:11 +0200 > > On Thu, Apr 12, 2012 at 10:27:31PM +0800, Gavin Mu wrote: > > On Mon, Mar 5, 2012 at 2:06 AM, Marius Strobl wrote: > > > Typically, opening and closing devices via OFW causes quite a delay, > > > the exact impact depends on the firmware version and the devices > > > involved though. Therefore, it would be advisable to keep using the > > > current approach of caching opened packages. In what way does this > > > fail with ZFS? > > The error message on Fire V100 is: Fast Data Access MMU Miss > > > > > Basically, IEEE 1275 just says that support for > > > opening a package more than once depends on the particular package > > > but nothing about concurrently opening different packages. Not > > > being able to concurrently open different packages also doesn't > > > make all that much of a sense as opening one package also means > > > to subsequentially open all the parents up to the root if not > > > already opened and I think to actually have tested opening disks > > > concurrently when writing the current code. Could this fail due > > > to one device actually being opened twice, once via the full path > > > and once via its alias? > > There is no such scene though the code lacks the checking for full > > path/devalias. > > I have tried many times to find the root cause but I think it is > > difficult without open firmware knowledge. > > currently I found that following scenes will cause this issue with my test code: > > 1. do OF_seek(ihandle_t a) just after OF_close(ihandle_t b). in real > > world, OF_seek(a) is the step to read ZFS data just after OF_close() > > another disk during zfs init/probe. > > 2. do OF_seek(ihandle_t a) just after OF_open("available controller > > without disk"). For example there is no disk3 on my machine though > > there is disk controller. OF_open("disk3:") will report: > > Can't read disk label. > > Can't open disk label package > > > > in ofw_disk.c, OF_close() has been commented out for powerpc > > architecture, and can not find detail reason from code history, so I > > am thinking if we need also disable OF_close() for sparc64. > > Hrm, some OFW implementations might have reference counting bugs, > causing OF_close() to also close some parent(s) when these in fact > are still used by another opened child device. Have you tried how > it works when just commenting out the OF_close() in ofwd_close() but > leaving the rest of ofw_disk.c as is? If that works, we probably > can add a cleanup handler which closes all opened disk devices > before leaving the loader, still taking advantage of caching opened > disks. > > > > > for OF_open("normal disk controller without disk") issue, I did not > > find how to work around or fix yet. > > Currently, I can't think of a way to solve this with the available > OFW interfaces. Have you checked whether OpenSolaris includes the > source of the OFW ZFS loader bits and how it's done there or > generally how a Solaris instalaltion handles this (f.e. does it > create any additional aliases for ZFS providers and uses these > instead etc)? > > > > > Is there any documents about how this open firmware work? I googled > > but can not find anything useful. > > > > For the most part, there's just IEEE 1275. There once was a bit of > related information on http://playground.sun.com/1275/, which > unfortunately disappeared some time after Oracle took over. > > Marius > > > > ------------------------------ > > Message: 2 > Date: Mon, 23 Apr 2012 11:07:24 GMT > From: FreeBSD bugmaster > Subject: Current problem reports assigned to > freebsd-sparc64@FreeBSD.org > To: freebsd-sparc64@FreeBSD.org > Message-ID: <201204231107.q3NB7On0047706@freefall.freebsd.org> > > Note: to view an individual PR, use: > http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). > > The following is a listing of current problems submitted by FreeBSD users. > These represent problem reports covering all versions including > experimental development code and obsolete releases. > > > S Tracker Resp. Description > -------------------------------------------------------------------------------- > o sparc/165025 sparc64 [PATCH] zfsboot support for sparc64 > o sparc/164227 sparc64 [boot] Can't boot 9.0-RELEASE/sparc64 on Blade 1500 > o sparc/164226 sparc64 [cd] Data corruption on 9.0-RELEASE when reading from > o sparc/162513 sparc64 mpt(4), mptutil(8) reports variable, erroneous drive i > o sparc/141918 sparc64 [ehci] ehci_interrupt: unrecoverable error, controller > s sparc/139134 sparc64 kernel output corruption > s sparc/107087 sparc64 [hang] system is hung during boot from CD > o sparc/105048 sparc64 [trm] trm(4) panics on sparc64 > o sparc/104428 sparc64 [nullfs] nullfs panics on E4500 (but not E420) > o sparc/71729 sparc64 printf in kernel thread causes panic on SPARC > > 10 problems total. > > > > ------------------------------ > > _______________________________________________ > freebsd-sparc64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 > To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@freebsd.org" > > > End of freebsd-sparc64 Digest, Vol 472, Issue 1 > *********************************************** > From owner-freebsd-sparc64@FreeBSD.ORG Tue Apr 24 12:10:15 2012 Return-Path: Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 75C1E1065686 for ; Tue, 24 Apr 2012 12:10:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 607478FC0C for ; Tue, 24 Apr 2012 12:10:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q3OCAFkC081348 for ; Tue, 24 Apr 2012 12:10:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3OCAF4u081347; Tue, 24 Apr 2012 12:10:15 GMT (envelope-from gnats) Date: Tue, 24 Apr 2012 12:10:15 GMT Message-Id: <201204241210.q3OCAF4u081347@freefall.freebsd.org> To: freebsd-sparc64@FreeBSD.org From: Manuel Tobias Schiller Cc: Subject: Re: sparc64/141918: [ehci] ehci_interrupt: unrecoverable error, controller halted (sparc64) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Manuel Tobias Schiller List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 12:10:15 -0000 The following reply was made to PR sparc64/141918; it has been noted by GNATS. From: Manuel Tobias Schiller To: Marius Strobl Cc: bug-followup@FreeBSD.org Subject: Re: sparc64/141918: [ehci] ehci_interrupt: unrecoverable error, controller halted (sparc64) Date: Tue, 24 Apr 2012 14:05:47 +0200 --Sig_/9VY0Wp.oK7i1jICn3i=InqH Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Marius, I'm rather busy with work at the moment, so I'm not working quite as much on troubleshooting this issue right now... (See below for answers to your questions...) On Sun, 15 Apr 2012 14:51:05 +0200 Marius Strobl wrote: > [...] > > > >=20 > > > > Hi, > > > >=20 > > > > the "VIA quirk fix" on its own gives the familiar message in dmesg > > > > (unrecoverable error, controller halted), so I'm compiling a > > > > kernel which > > >=20 > > > Oof, this likely means there's a more basic problem with this > > > device. Have you already tried to re-seat the card in case there's > > > an electrical problem? > > > Please also provide the output of `pciconf -rb ehci0@pci0:2:5:2 > > > 0:255' from a booting kernel. > > > FYI, after some digging I've found the following card > > > ehci0@pci0:2:5:2: class=3D0x0c0320 card=3D0x31041106 chip=3D0x31041106 > > > rev=3D0x6h0 which is a newer revision of your device and works just > > > fine in a T1-200 including with the usb(4) fixes. The publicly > > > available datasheets for the VIA USB controllers are minimal and > > > exclude errata and Linux also doesn't seem to use any additional > > > work arounds, so I'm starting to run out of ideas what could be > > > wrong with your revision. The only remaining thing to give a try I > > > currently can think of is to test whether it chokes on the generic > > > initialization done by the sparc64 PCI code using the attached > > > patch. > > >=20 > > > > combines this fix with your latest busdma fix to try them both > > > > together; > > >=20 > > > This combination is unlikely to make a difference. > > >=20 > > > Marius > > >=20 > >=20 > > Hi Marius, > >=20 > > I've tried your new patch, both on its own and in conjunction with > > the latest busdma and Via quirk fixes, and I still get the same error > > message... > >=20 > > Here's the output of pciconf you requested: > >=20 > > mala@router:~> sudo pciconf -rb ehci0@pci0:2:5:2 0:255 > > Password: > > 06 11 04 31 06 00 10 22 65 20 03 0c 00 16 80 00=20 > > 00 a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00=20 > > 00 00 00 00 00 00 00 00 00 00 00 00 06 11 04 31=20 > > 00 00 00 00 80 00 00 00 00 00 00 00 14 03 00 00=20 > > 00 00 0b 00 00 00 00 00 a0 20 00 29 00 00 ff ff=20 >=20 > This is rather confusing; the 0x29 in the above line means that the > VIA workaround is applied. Didn't you say that with the fix to > actually apply it, the kernel panics as soon as attaching the > device? > Apart from this, the configuration space differs in 3 undocumented > bytes from mine. I'm not sure whether it's worth trying whether > these make a difference ... Yes, this was from a kernel with your patch and the VIA workaround applied; the kernel usually stops when I start using these devices heavily (i.e. the automatic checks done during a ZFS mount operation). > > 00 5a 04 80 00 00 00 00 04 0b 88 88 33 00 00 00=20 > > 20 20 01 00 00 00 00 00 01 00 00 00 00 00 00 c0=20 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00=20 > > 01 00 0a 7e 00 00 00 00 00 00 00 00 00 00 00 00=20 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00=20 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00=20 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00=20 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00=20 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00=20 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00=20 > > 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 00 > >=20 > > This was taken after the controller stopped, on a kernel with your > > latest patch, but I'd guess that doesn't matter - the EHCI driver > > should not be playing with the PCI settings after initialisation... > >=20 > > I've also opened the machine, and the PCI card is seated properly. I > > even removed it and tried an even older VIA EHCI controller and one > > of the first USB 2.0 controllers by NEC - no luck, the VIA one had > > trouble recognizing devices, the NEC one did not recognize a single > > one I plugged in. > >=20 >=20 > This also is rather strange. Have you ever used any other type of > card in the slot, f.e. an NIC, so you can rule out it's broken > somehow? Some four or five years ago, the slot held a quad fast ethernet NIC, and that seemed to work fine... But: a lot can happen during this time, so I ordered a new USB controller to test with, just in case... > How does using the on-board USB controller work out? As far as I know, the on-board controller is USB1.1, so I have not really tried it because it's going to be a no-go option for disks (I'd get similar speed getting data from some server here at CERN over my DSL connection, and I probably wouldn't even have to administer the server myself - if I could get them to host my data ;)... I can give the onboard USB 1.1 controller a try, though... I noticed something else when reconnecting everything to the server: The USB ground seems to have a quite high (voltage) potential with respect to the chassis of the server (and the protective ground of the wall outlet), about 80 Volts. I've tried to locate a single faulty power supply of the hard disks (since the server chassis is at ground levels), but when tested individually, none of them shows this behaviour. It only happens when I connect all eight USB disks to the USB hub which in turn connects to the server. Apparently, this is some collective effect. Obviously, when the USB cable from the hub is plugged into the server, this potential difference is no longer there, and the disks are recognised. I'm not sure what this observation means (except that I'd really prefer linear over switching mode power supplies because of the galvanic separation between primary and secondary sides), but I thought I mention it anyway. Manuel > Marius >=20 >=20 --=20 Homepage: http://www.hinterbergen.de/mala OpenPGP: 0xA330353E (DSA) or 0xD87D188C (RSA) --Sig_/9VY0Wp.oK7i1jICn3i=InqH Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQGcBAEBAgAGBQJPlpcbAAoJEEPbVOqHHK4gOYcL/1RX9RFO/1igVUFYkXiZJJg/ ctFL8SmAWDPofWO4xCoHzCeLVG1nj5dkn0QdMB93t+JRq8mhH+Dyv+VPgbv94dea uYdRr2fjQktRJptkLFtMTvK7NyxItQ6PNSBEVkIYJrbo7/cqumeF1hJ7ZB255Iub gHdR4zQQv/0PiwFeBSdjFK1RHMAcp/0LnzWiBW/xKeKEE4U7YzNt+5Xo1c0ym5me 1FNl403xtgttlUzAK3pQqh54dWJbtyFpz489eRY92+ZydGuT3XtDf6svqoyUGx2K 2q5Kq72MaTmSittwPeV5UxfqI45Iz6PUha2R3P9GHc75CVY7vN9wF+M3/qIwAToB H75vI7KF1ZUM8HR2OX9MnWCsaJiNsHKqyDgitjI7O1IRDeXVcgVnzQVtez3ZKTHN aoid3ItzMK0Sh6HBSktNl5CvTCwH7sPcdfpCp4OybANFb6UDeZhrW8XBrAoV8mx3 9nOfiAVjsLsPpDq423BvanI9s8xd72OhbcgxKAoYAQ== =Hc4a -----END PGP SIGNATURE----- --Sig_/9VY0Wp.oK7i1jICn3i=InqH-- From owner-freebsd-sparc64@FreeBSD.ORG Wed Apr 25 12:31:32 2012 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6EEE0106566B; Wed, 25 Apr 2012 12:31:32 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id B96E68FC08; Wed, 25 Apr 2012 12:31:31 +0000 (UTC) Received: from ncsc.bris.ac.uk ([137.222.10.41]) by dirj.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1SN1Na-00034P-PE; Wed, 25 Apr 2012 13:31:30 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncsc.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SN1Na-0007WY-Hp; Wed, 25 Apr 2012 13:31:30 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5) with ESMTP id q3PCVUH3074482; Wed, 25 Apr 2012 13:31:30 +0100 (BST) (envelope-from mexas@bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5/Submit) id q3PCVUuF074481; Wed, 25 Apr 2012 13:31:30 +0100 (BST) (envelope-from mexas@bris.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bris.ac.uk using -f Date: Wed, 25 Apr 2012 13:31:30 +0100 From: Anton Shterenlikht To: Baptiste Daroussin Message-ID: <20120425123130.GA74468@mech-cluster241.men.bris.ac.uk> References: <20120416142124.GA17906@mech-cluster241.men.bris.ac.uk> <4F8C3393.6020703@freebsd.org> <20120416151306.GA24208@mech-cluster241.men.bris.ac.uk> <20120418124430.GA34779@mech-cluster241.men.bris.ac.uk> <20120418180554.GB47452@gahrfit.gahr.ch> <20120421213423.GA30575@azathoth.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120421213423.GA30575@azathoth.lan> User-Agent: Mutt/1.4.2.3i Cc: Julien Laffaye , freebsd-sparc64@freebsd.org, freebsd-ports@freebsd.org Subject: Re: pkg audit -F segfault on sparc64 and ia64 [WAS: Re: pkg audit segfault] X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 12:31:32 -0000 On Sat, Apr 21, 2012 at 11:34:24PM +0200, Baptiste Daroussin wrote: > Fixed in git thank you for reporting > > On Wed, Apr 18, 2012 at 08:05:54PM +0200, Pietro Cerutti wrote: > > On 2012-Apr-18, 13:44, Anton Shterenlikht wrote: > > > On Mon, Apr 16, 2012 at 04:13:06PM +0100, Anton Shterenlikht wrote: > > > > On Mon, Apr 16, 2012 at 04:58:27PM +0200, Julien Laffaye wrote: > > > > > On 04/16/2012 04:21 PM, Anton Shterenlikht wrote: > > > > > >pkg audit -F > > > > > On my 9.0-RELEASE amd64, it works fine. > > > > > > segfault also on sparc64 r230787M > > > > I have a couple of sparc64 machines on which I can test, but that won't > > be before next week.. I'll follow-up. > > > > > > > > # pkg -vvv > > > version: 1.0-beta11 > > > abi: freebsd:10:sparc64:64 > > > db dir: /var/db/pkg > > > cache dir: /var/cache/pkg > > > ports dir: /usr/ports > > > Log into syslog: yes > > > Assume always yes: no > > > Handle rc scripts: no > > > Track shlibs: no > > > Automatic depdency tracking: no > > > Custom keywords directory: none > > > Repository: none > > > # > > > > > > # pkg audit -F > > > http://portaudit.FreeBSD.org/auditfile.tbz 100% 76KB 75.7KB/s 75.7KB/s 00:00 > > > 0 problem(s) in your installed packages found. > > > Segmentation fault (core dumped) > > > > > > # gdb /usr/local/sbin/pkg pkg.core > > > GNU gdb 6.1.1 [FreeBSD] > > > Copyright 2004 Free Software Foundation, Inc. > > > GDB is free software, covered by the GNU General Public License, and you are > > > welcome to change it and/or distribute copies of it under certain conditions. > > > Type "show copying" to see the conditions. > > > There is absolutely no warranty for GDB. Type "show warranty" for details. > > > This GDB was configured as "sparc64-marcel-freebsd"... > > > Core was generated by `pkg'. > > > Program terminated with signal 11, Segmentation fault. > > > Reading symbols from /usr/local/lib/libpkg.so.0...done. > > > Loaded symbols for /usr/local/lib/libpkg.so.0 > > > Reading symbols from /lib/libutil.so.9...done. > > > Loaded symbols for /lib/libutil.so.9 > > > Reading symbols from /lib/libjail.so.1...done. > > > Loaded symbols for /lib/libjail.so.1 > > > Reading symbols from /lib/libc.so.7...done. > > > Loaded symbols for /lib/libc.so.7 > > > Reading symbols from /usr/lib/libarchive.so.5...done. > > > Loaded symbols for /usr/lib/libarchive.so.5 > > > Reading symbols from /lib/libsbuf.so.6...done. > > > Loaded symbols for /lib/libsbuf.so.6 > > > Reading symbols from /usr/lib/libfetch.so.6...done. > > > Loaded symbols for /usr/lib/libfetch.so.6 > > > Reading symbols from /usr/lib/libelf.so.1...done. > > > Loaded symbols for /usr/lib/libelf.so.1 > > > Reading symbols from /lib/libthr.so.3...done. > > > Loaded symbols for /lib/libthr.so.3 > > > Reading symbols from /lib/libedit.so.7...done. > > > Loaded symbols for /lib/libedit.so.7 > > > Reading symbols from /lib/libz.so.6...done. > > > Loaded symbols for /lib/libz.so.6 > > > Reading symbols from /usr/lib/libbz2.so.4...done. > > > Loaded symbols for /usr/lib/libbz2.so.4 > > > Reading symbols from /usr/lib/liblzma.so.5...done. > > > Loaded symbols for /usr/lib/liblzma.so.5 > > > Reading symbols from /lib/libbsdxml.so.4...done. > > > Loaded symbols for /lib/libbsdxml.so.4 > > > Reading symbols from /lib/libcrypto.so.6...done. > > > Loaded symbols for /lib/libcrypto.so.6 > > > Reading symbols from /usr/lib/libssl.so.6...done. > > > Loaded symbols for /usr/lib/libssl.so.6 > > > Reading symbols from /lib/libmd.so.5...done. > > > Loaded symbols for /lib/libmd.so.5 > > > Reading symbols from /lib/libncurses.so.8...done. > > > Loaded symbols for /lib/libncurses.so.8 > > > Reading symbols from /libexec/ld-elf.so.1...done. > > > Loaded symbols for /libexec/ld-elf.so.1 > > > #0 0x00000000407f31a8 in __sparc_utrap_install () from /lib/libc.so.7 > > > [New Thread 41c04400 (LWP 100130/pkg)] > > > (gdb) bt > > > #0 0x00000000407f31a8 in __sparc_utrap_install () from /lib/libc.so.7 > > > #1 0x00000000407f32cc in __sparc_utrap_install () from /lib/libc.so.7 > > > #2 0x00000000407f3570 in __sparc_utrap_install () from /lib/libc.so.7 > > > #3 0x00000000407f2dac in __sparc_utrap_install () from /lib/libc.so.7 > > > #4 0x0000000040225b74 in dlsym () from /libexec/ld-elf.so.1 > > > #5 0x0000000040225b74 in dlsym () from /libexec/ld-elf.so.1 > > > Previous frame identical to this frame (corrupt stack?) > > > (gdb) > > > > > > -- > > > Anton Shterenlikht > > > Room 2.6, Queen's Building > > > Mech Eng Dept > > > Bristol University > > > University Walk, Bristol BS8 1TR, UK > > > Tel: +44 (0)117 331 5944 > > > Fax: +44 (0)117 929 4423 > > > _______________________________________________ > > > freebsd-ports@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > > > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > > > > -- > > Pietro Cerutti > > The FreeBSD Project > > gahr@FreeBSD.org > > > > PGP Public Key: > > http://gahr.ch/pgp > > I confirm that in v 1.0-beta12 pkg audit works fine on both sparc64 and ia64. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-sparc64@FreeBSD.ORG Sat Apr 28 13:51:40 2012 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DF891106566B; Sat, 28 Apr 2012 13:51:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id AF60B8FC08; Sat, 28 Apr 2012 13:51:40 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3SDpep2098746; Sat, 28 Apr 2012 09:51:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3SDpePH098745; Sat, 28 Apr 2012 13:51:40 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 28 Apr 2012 13:51:40 GMT Message-Id: <201204281351.q3SDpePH098745@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 13:51:41 -0000 TB --- 2012-04-28 12:43:56 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-28 12:43:56 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-28 12:43:56 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-04-28 12:43:57 - cleaning the object tree TB --- 2012-04-28 12:43:57 - cvsupping the source tree TB --- 2012-04-28 12:43:57 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-04-28 12:45:01 - building world TB --- 2012-04-28 12:45:01 - CROSS_BUILD_TESTING=YES TB --- 2012-04-28 12:45:01 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-28 12:45:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-28 12:45:01 - SRCCONF=/dev/null TB --- 2012-04-28 12:45:01 - TARGET=sparc64 TB --- 2012-04-28 12:45:01 - TARGET_ARCH=sparc64 TB --- 2012-04-28 12:45:01 - TZ=UTC TB --- 2012-04-28 12:45:01 - __MAKE_CONF=/dev/null TB --- 2012-04-28 12:45:01 - cd /src TB --- 2012-04-28 12:45:01 - /usr/bin/make -B buildworld >>> World build started on Sat Apr 28 12:45:02 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Apr 28 13:47:46 UTC 2012 TB --- 2012-04-28 13:47:46 - generating LINT kernel config TB --- 2012-04-28 13:47:46 - cd /src/sys/sparc64/conf TB --- 2012-04-28 13:47:46 - /usr/bin/make -B LINT TB --- 2012-04-28 13:47:46 - cd /src/sys/sparc64/conf TB --- 2012-04-28 13:47:46 - /usr/sbin/config -m LINT TB --- 2012-04-28 13:47:47 - building LINT kernel TB --- 2012-04-28 13:47:47 - CROSS_BUILD_TESTING=YES TB --- 2012-04-28 13:47:47 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-28 13:47:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-28 13:47:47 - SRCCONF=/dev/null TB --- 2012-04-28 13:47:47 - TARGET=sparc64 TB --- 2012-04-28 13:47:47 - TARGET_ARCH=sparc64 TB --- 2012-04-28 13:47:47 - TZ=UTC TB --- 2012-04-28 13:47:47 - __MAKE_CONF=/dev/null TB --- 2012-04-28 13:47:47 - cd /src TB --- 2012-04-28 13:47:47 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 28 13:47:47 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ath_hal/ar5212/ar5212_reset.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ath_hal/ar5212/ar5212_rfgain.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ath_hal/ar5212/ar5212_xmit.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ath_hal/ar5416/ar5416_ani.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc1: warnings being treated as errors /src/sys/dev/ath/ath_hal/ar5416/ar5416_ani.c: In function 'ar5416AniPoll': /src/sys/dev/ath/ath_hal/ar5416/ar5416_ani.c:818: warning: 'listenTime' may be used uninitialized in this function /src/sys/dev/ath/ath_hal/ar5416/ar5416_ani.c:818: note: 'listenTime' was declared here *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-28 13:51:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-28 13:51:40 - ERROR: failed to build LINT kernel TB --- 2012-04-28 13:51:40 - 3133.87 user 557.91 system 4063.21 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-sparc64@FreeBSD.ORG Sat Apr 28 19:29:37 2012 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55921106564A; Sat, 28 Apr 2012 19:29:37 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 237C18FC14; Sat, 28 Apr 2012 19:29:37 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3SJTafY004244; Sat, 28 Apr 2012 15:29:36 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3SJTagd004243; Sat, 28 Apr 2012 19:29:36 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 28 Apr 2012 19:29:36 GMT Message-Id: <201204281929.q3SJTagd004243@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 19:29:37 -0000 TB --- 2012-04-28 18:19:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-28 18:19:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-28 18:19:00 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-04-28 18:19:00 - cleaning the object tree TB --- 2012-04-28 18:20:41 - cvsupping the source tree TB --- 2012-04-28 18:20:41 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-04-28 18:21:57 - building world TB --- 2012-04-28 18:21:57 - CROSS_BUILD_TESTING=YES TB --- 2012-04-28 18:21:57 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-28 18:21:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-28 18:21:57 - SRCCONF=/dev/null TB --- 2012-04-28 18:21:57 - TARGET=sparc64 TB --- 2012-04-28 18:21:57 - TARGET_ARCH=sparc64 TB --- 2012-04-28 18:21:57 - TZ=UTC TB --- 2012-04-28 18:21:57 - __MAKE_CONF=/dev/null TB --- 2012-04-28 18:21:57 - cd /src TB --- 2012-04-28 18:21:57 - /usr/bin/make -B buildworld >>> World build started on Sat Apr 28 18:21:58 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Apr 28 19:25:45 UTC 2012 TB --- 2012-04-28 19:25:45 - generating LINT kernel config TB --- 2012-04-28 19:25:45 - cd /src/sys/sparc64/conf TB --- 2012-04-28 19:25:45 - /usr/bin/make -B LINT TB --- 2012-04-28 19:25:45 - cd /src/sys/sparc64/conf TB --- 2012-04-28 19:25:45 - /usr/sbin/config -m LINT TB --- 2012-04-28 19:25:45 - building LINT kernel TB --- 2012-04-28 19:25:45 - CROSS_BUILD_TESTING=YES TB --- 2012-04-28 19:25:45 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-28 19:25:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-28 19:25:45 - SRCCONF=/dev/null TB --- 2012-04-28 19:25:45 - TARGET=sparc64 TB --- 2012-04-28 19:25:45 - TARGET_ARCH=sparc64 TB --- 2012-04-28 19:25:45 - TZ=UTC TB --- 2012-04-28 19:25:45 - __MAKE_CONF=/dev/null TB --- 2012-04-28 19:25:45 - cd /src TB --- 2012-04-28 19:25:45 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 28 19:25:45 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ath_hal/ar5212/ar5212_reset.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ath_hal/ar5212/ar5212_rfgain.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ath_hal/ar5212/ar5212_xmit.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ath_hal/ar5416/ar5416_ani.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc1: warnings being treated as errors /src/sys/dev/ath/ath_hal/ar5416/ar5416_ani.c: In function 'ar5416AniPoll': /src/sys/dev/ath/ath_hal/ar5416/ar5416_ani.c:818: warning: 'listenTime' may be used uninitialized in this function /src/sys/dev/ath/ath_hal/ar5416/ar5416_ani.c:818: note: 'listenTime' was declared here *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-28 19:29:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-28 19:29:36 - ERROR: failed to build LINT kernel TB --- 2012-04-28 19:29:36 - 3109.49 user 560.59 system 4236.01 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-sparc64@FreeBSD.ORG Sat Apr 28 21:38:46 2012 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E81D7106566B for ; Sat, 28 Apr 2012 21:38:46 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 8105B8FC15 for ; Sat, 28 Apr 2012 21:38:46 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q3SLcbpW012783; Sat, 28 Apr 2012 23:38:37 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q3SLcaWf012782; Sat, 28 Apr 2012 23:38:36 +0200 (CEST) (envelope-from marius) Date: Sat, 28 Apr 2012 23:38:36 +0200 From: Marius Strobl To: Tim Hogard Message-ID: <20120428213836.GA12730@alchemy.franken.de> References: <20120423120040.01C8C106582A@hub.freebsd.org> <201204231426.q3NEQFSm066866@v.abnormal.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201204231426.q3NEQFSm066866@v.abnormal.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-sparc64@freebsd.org Subject: Re: Slow on v210? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 21:38:47 -0000 On Mon, Apr 23, 2012 at 02:26:15PM +0000, Tim Hogard wrote: > > I'm at the inital stages of looking into the problems here. > > I just put Release 9.0 on a single CPU v210 and it is much slower > than I expected. A simple perl program runs at 1/6th the speed of > the Solaris 9 machine I'm testing aginst. Other things involing > basic utils also seem to run about that ratio. Compiles are also > very slow. > > For testing I've got a Sol 9 dual 1.33 Ghz netra 210 with > 4 gig of ram and a single 1.33 ghz v210 with 2 gig of ram. > My tests show both system have about 1 gig free and I run > 4 processes per core: > > #!/usr/bin/perl > foreach $i (1..1000000) { > $i{$i}=$i; > } > > The FreeBSD 9.0 and perl 5.12 (from ports) with no load is running > much slower than the Sol 9 with perl 5.10 a few other things running. > > sol$ time ./p > > real 0m4.110s > user 0m3.430s > sys 0m0.610s > > f9$ time ./p > 27.24 real 6.10 user 21.00 sys > > 2 on f9 take 55 or so seconds, 4 on the dual cpu take about 8 seconds. > > Other things also seem slower but I haven't benchmarked them but they should in the are ballpark. > The disks on the n210 are 2.5 and 3.5 on the v210. Both are 7200 rpm but everything is in cache. > The ram seems identical. > > The freeBSD machine should not be 7 times slower. Could you please do some profiling in order to determine where (i.e. which syscall etc) the time is spent? > > Other issues: > 1) The machine needed the vm.kmem_size="1024" in /etc/loader.conf or it wouldn't boot. > (http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2012-01/msg00414.html) > fixed by stopping boot and typing something like set vm.kmem_size="1024m" at > the laoder prompt. Apparently, this is a bug in the machine independent parts of the VM triggered by extra sparse physical memory layouts as seen with USIIIi- based machines with 2 GB of RAM. You can work around this without sacrificing physical memory by setting the vm.kmem_size_scale loader tunable to 2. Until the underlying problem is fixed, stable/9 defaults to the same scaling. > > 2) base.txz just wouldn't end up with the right sha-256 hash even when checked > on other machines. Fixed by using net install. > ATA_CAM broke ATAPI DMA for some chipsets causing data corruption. You can work around it by manually reverting to PIO mode. For a v210, setting the loader tunable hint.ata.2.mode to PIO4 should do this. Until the underlying problem is fixed, stable/9 defaults to not using ATAPI DMA along with ATA_CAM for the chipsets identified so far. Marius