From owner-freebsd-sparc64@FreeBSD.ORG Mon Jul 20 11:07:04 2009 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 818241065678 for ; Mon, 20 Jul 2009 11:07:04 +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 6EF868FC0A for ; Mon, 20 Jul 2009 11:07:04 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n6KB745j002445 for ; Mon, 20 Jul 2009 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n6KB73SO002441 for freebsd-sparc64@FreeBSD.org; Mon, 20 Jul 2009 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 20 Jul 2009 11:07:03 GMT Message-Id: <200907201107.n6KB73SO002441@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, 20 Jul 2009 11:07:04 -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 -------------------------------------------------------------------------------- f sparc/127051 sparc64 [hme] hme interfaces "pause" with the message "device o sparc/119244 sparc64 X11Forwarding to X11 server on sparc crashes Xorg o sparc/119240 sparc64 top has WCPU over 100% on UP system s sparc/119239 sparc64 gdb coredumps on sparc64 o sparc/113556 sparc64 [panic] trap: memory address not aligned; Rebooting... f sparc/108732 sparc64 ping(8) reports 14 digit time on sparc64 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/80890 sparc64 [panic] kmem_malloc(73728): kmem_map too small running o sparc/80410 sparc64 [netgraph] netgraph is causing crash with mpd on sparc o sparc/71729 sparc64 printf in kernel thread causes panic on SPARC 12 problems total. From owner-freebsd-sparc64@FreeBSD.ORG Wed Jul 22 20:32:21 2009 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 5A863106566C for ; Wed, 22 Jul 2009 20:32:21 +0000 (UTC) (envelope-from rjohanne@piper.hamline.edu) Received: from piper.hamline.edu (wnk2.hamline.edu [138.192.246.27]) by mx1.freebsd.org (Postfix) with ESMTP id 25E468FC1A for ; Wed, 22 Jul 2009 20:32:20 +0000 (UTC) (envelope-from rjohanne@piper.hamline.edu) Received: from piper.hamline.edu (localhost.localdomain [127.0.0.1]) by piper.hamline.edu (8.14.2/8.14.2) with ESMTP id n6MJetlw023066 for ; Wed, 22 Jul 2009 14:40:55 -0500 Received: from localhost (rjohanne@localhost) by piper.hamline.edu (8.14.2/8.14.2/Submit) with ESMTP id n6MJetcQ023063 for ; Wed, 22 Jul 2009 14:40:55 -0500 Date: Wed, 22 Jul 2009 14:40:55 -0500 (CDT) From: R J X-X-Sender: rjohanne@wnk To: freebsd-sparc64@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Sata pci cards in ultra 60 or blade 1000 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, 22 Jul 2009 20:32:21 -0000 Hi all, I have both an ultra 60 and a Sun blade 1000. I have freebsd 7.2 running on both seemingly without issue, outside of sata pci. I have had a promise SATA300 TX4, 66MHZ (4 port version) in the ultra 60 and rebuild the kernel to contain the ata driver. When the system boots, it sees the card just fine, but it doesn't see any drives attached to it. I had two disks attached (one 40gig fujitsu, and one is a 1TB hitachi), but none of them were seen. I tried powering the drives with a different power supply, but they would not be seen by the promise controller. The drives work fine in a pc with linux. I switched out the promise card, and put a silicon image Sil 3512 in the ultra 60, and the two drives were seen. I was able to lay ufs file system on them, and even copied files around, but the system was not stable. I.e, I would copy files to the sata hard drives for a few minutes before it would hang and remain that way till I did a hard reset. I then took the Sil 3512 out of the ultra60 and put it in the Sun blade 1000, and attached the drives, and, just like the promise card, the sil card is seen by freebsd, but the drives are not. Remember, the drives are seen with the same card in the ultra60. I currently don't have the promise card with me to test with the blade, but I would imagine the same thing will happen. Has any body had success with sata pci cards in any of the ultrasparc pci systems? If so, what cards/chipsets/workarounds? Other than the 66mhz v 33mhz(with respective 3.3/5 volt) and 32 v 64 bit, is there any other thing quirky about the sparc pci busses that would cause this sort of behaviour? Any help appreciated. Robert From owner-freebsd-sparc64@FreeBSD.ORG Thu Jul 23 18:30:38 2009 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 E17CF1065670 for ; Thu, 23 Jul 2009 18:30:38 +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 5890C8FC1E for ; Thu, 23 Jul 2009 18:30:38 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id n6NIUYoS056201; Thu, 23 Jul 2009 20:30:34 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id n6NIUYFQ056200; Thu, 23 Jul 2009 20:30:34 +0200 (CEST) (envelope-from marius) Date: Thu, 23 Jul 2009 20:30:34 +0200 From: Marius Strobl To: Hans Petter Selasky Message-ID: <20090723183034.GA56079@alchemy.franken.de> References: <4A444374.3090008@apz.fi> <200906301037.40138.hselasky@c2i.net> <4A4A5208.9020307@apz.fi> <200907170959.39640.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200907170959.39640.hselasky@c2i.net> User-Agent: Mutt/1.4.2.3i Cc: Ari =?unknown-8bit?Q?Sovij=E4rvi?= , freebsd-sparc64@freebsd.org Subject: Re: "cg 0: bad magic number" with umass 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: Thu, 23 Jul 2009 18:30:39 -0000 On Fri, Jul 17, 2009 at 09:59:38AM +0200, Hans Petter Selasky wrote: > On Tuesday 30 June 2009 19:57:28 Ari Sovijärvi wrote: > > Hans Petter Selasky wrote: > > > Could you show the dmesg of the USB controller? At which bus is it > > > connected? Nexus? There might be bugs in the actual USB device/host > > > hardware. > > > > Here's all I could find of the USB controller from the dmesg's output. > > > > ohci0: mem 0x1000000-0x1000fff > > at device 10.0 on pci0 > > ohci0: [GIANT-LOCKED] > > ohci0: [ITHREAD] > > usb0: OHCI version 1.0, legacy support > > usb0: on ohci0 > > usb0: USB revision 1.0 > > uhub0: on usb0 > > uhub0: 2 ports with 2 removable, self powered > > > > If you need to see anything else from the dmesg, here's the full output: > > http://pastebin.ca/1479774 > > > > The USB-enclosure I used was LaCie's "design by porsche" with 1 terabyte > > Seagate disk. > > > > > Are you using 8-current ? > > > > No, 7.2. > > Hi, > > If you do a simple test on the disk: > > dd if=/dev/urandom of=test.img bs=65536 count=16 > > cat test.img > /dev/daX > > dd if=/dev/daX of=test_rb.img bs=65536 count=16 > > diff test.img test_rb.img > > The only problem I can see is that there is something wrong with the cache > invalidate/flush instruction wrappers on the sparc. > If you are refering to bus_dmamap_sync(9) that hardly can be the cause as we don't take advantage of the streaming cache of sparc64 IOMMUs so far as traditionally drivers used bus_dmamap_sync(9) incorrectly if they did at all, let alone the fact that this particular machine has no streaming cache. I.e. currently the use of bus_dmamap_sync(9) actually is unnecessary on sparc64, my plan is to enable the used of the streaming caches some time after the freeze for 8.0 is over though. I'd rather suspect this to either be one of the typical !x86 LP64, alignment or endianness problems in usb(4) or the firmware initializing the on-board Ali controller to some non-(x86-)default values. The latter is something that ata(4) is also struggeling with. Marius From owner-freebsd-sparc64@FreeBSD.ORG Thu Jul 23 19:07:27 2009 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 EDEDB106566B for ; Thu, 23 Jul 2009 19:07:27 +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 68B118FC12 for ; Thu, 23 Jul 2009 19:07:27 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id n6NJ7Puh056490; Thu, 23 Jul 2009 21:07:26 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id n6NJ7Oij056489; Thu, 23 Jul 2009 21:07:24 +0200 (CEST) (envelope-from marius) Date: Thu, 23 Jul 2009 21:07:24 +0200 From: Marius Strobl To: R J Message-ID: <20090723190724.GB56079@alchemy.franken.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-sparc64@freebsd.org Subject: Re: Sata pci cards in ultra 60 or blade 1000 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: Thu, 23 Jul 2009 19:07:28 -0000 On Wed, Jul 22, 2009 at 02:40:55PM -0500, R J wrote: > Hi all, > I have both an ultra 60 and a Sun blade 1000. I have freebsd 7.2 running > on both seemingly without issue, outside of sata pci. > > I have had a promise SATA300 TX4, 66MHZ (4 port version) in the ultra 60 > and rebuild the kernel to contain the ata driver. When the system boots, > it sees the card just fine, but it doesn't see any drives attached to it. I > had two disks attached (one 40gig fujitsu, and one is a 1TB hitachi), but > none of them were seen. I tried powering the drives with a different power > supply, but they would not be seen by the promise controller. The drives > work fine in a pc with linux. > > I switched out the promise card, and put a silicon image Sil 3512 in the > ultra 60, and the two drives were seen. I was able to lay ufs file system > on them, and even copied files around, but the system was not stable. I.e, > I would copy files to the sata hard drives for a few minutes before it > would hang and remain that way till I did a hard reset. > > I then took the Sil 3512 out of the ultra60 and put it in the Sun blade > 1000, and attached the drives, and, just like the promise card, the sil > card is seen by freebsd, but the drives are not. Remember, the drives are > seen with the same card in the ultra60. I currently don't have the promise > card with me to test with the blade, but I would imagine the same thing > will happen. > > Has any body had success with sata pci cards in any of the ultrasparc pci > systems? If so, what cards/chipsets/workarounds? > > Other than the 66mhz v 33mhz(with respective 3.3/5 volt) and 32 v 64 bit, > is there any other thing quirky about the sparc pci busses that would cause > this sort of behaviour? > > Any help appreciated. > For several controllers ata(4) depends on the firmware to do at least part of the initialization, even for models without RAID etc functionality, which would be required to be written in FCode in order to work in sparc64 machines. Depending on the system firmware and the PCI class a specific controller reports it might be treated as ordinary IDE controller or not which might explain the different behaviors you have seen between machine models. Generally this is highly controller dependent though, IIRC I had no problems with a Promise FastTrack TX2 in a Sun AXe board and a VIA VT6421A-based controller in a Blade 1500, the latter was only lightly tested though. Another possibility for connecting SATA disks to sparc64 machines is to use a SAS controller driven by mpt(4), which aren't necessarily more expensive than TX4 on Ebay. Marius From owner-freebsd-sparc64@FreeBSD.ORG Thu Jul 23 19:47:00 2009 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 3DFC01065676 for ; Thu, 23 Jul 2009 19:47:00 +0000 (UTC) (envelope-from carton@Ivy.NET) Received: from sakima.Ivy.NET (sakima.Ivy.NET [69.31.131.60]) by mx1.freebsd.org (Postfix) with ESMTP id E7F228FC26 for ; Thu, 23 Jul 2009 19:46:59 +0000 (UTC) (envelope-from carton@Ivy.NET) Received: from castrovalva.Ivy.NET (castrovalva.Ivy.NET [IPv6:2610:1f8:dc:c0::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sakima.Ivy.NET (Postfix) with ESMTP id CEFB6A8069 for ; Thu, 23 Jul 2009 15:24:02 -0400 (EDT) Received: by castrovalva.Ivy.NET (Postfix, from userid 405) id 5AB8C12FD0D; Thu, 23 Jul 2009 15:23:56 -0400 (EDT) To: freebsd-sparc64@freebsd.org References: <20090723190724.GB56079@alchemy.franken.de> From: Miles Nordin MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Thu_Jul_23_15:23:54_2009-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 23 Jul 2009 15:23:55 -0400 In-Reply-To: <20090723190724.GB56079@alchemy.franken.de> (Marius Strobl's message of "Thu, 23 Jul 2009 21:07:24 +0200") Message-ID: User-Agent: T-gnus/6.17.2 (based on No Gnus v0.2) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.4 (alpha--netbsd) MULE/5.0 (SAKAKI) Subject: Re: Sata pci cards in ultra 60 or blade 1000 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: Thu, 23 Jul 2009 19:47:00 -0000 --pgp-sign-Multipart_Thu_Jul_23_15:23:54_2009-1 Content-Type: text/plain; charset=US-ASCII >>>>> "ms" == Marius Strobl writes: ms> which would be required to be written in FCode in order to ms> work in sparc64 machines. why? see video on digital alpha see uvesafb on gentoo see int10 module in Xorg ms> Another possibility for connecting SATA disks to sparc64 ms> machines is to use a SAS controller driven by mpt(4) yeah, like solaris. sounds likely to work. --pgp-sign-Multipart_Thu_Jul_23_15:23:54_2009-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (NetBSD) iQCVAwUASmi4y4nCBbTaW/4dAQJ5XgP6A3U41E85Fl1e745lNGvloFv1Z7Qd03kw en3LGvCDYpxgBl/RXx2fYYX3csvcPGoLRBNazhfPwSrVqYPFtTXbLYs7mx6Mj0tH Rgksq3CGjv7XHz74/LzVF8GEKns2Zh/Q2v/s+vTIrvr5GJlP4/Sg+ayLnG4Y3ooR 7tAWp50naHU= =Xaw+ -----END PGP SIGNATURE----- --pgp-sign-Multipart_Thu_Jul_23_15:23:54_2009-1-- From owner-freebsd-sparc64@FreeBSD.ORG Thu Jul 23 20:38:27 2009 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 E228F106566B for ; Thu, 23 Jul 2009 20:38:27 +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 753F58FC24 for ; Thu, 23 Jul 2009 20:38:27 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id n6NKcQH4057181; Thu, 23 Jul 2009 22:38:26 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id n6NKcQ6I057180; Thu, 23 Jul 2009 22:38:26 +0200 (CEST) (envelope-from marius) Date: Thu, 23 Jul 2009 22:38:26 +0200 From: Marius Strobl To: Miles Nordin Message-ID: <20090723203826.GA57062@alchemy.franken.de> References: <20090723190724.GB56079@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-sparc64@freebsd.org Subject: Re: Sata pci cards in ultra 60 or blade 1000 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: Thu, 23 Jul 2009 20:38:28 -0000 On Thu, Jul 23, 2009 at 03:23:55PM -0400, Miles Nordin wrote: > >>>>> "ms" == Marius Strobl writes: > > ms> which would be required to be written in FCode in order to > ms> work in sparc64 machines. > > why? > I was talking about the capability of the machine, i.e. its firmware, here and not a workaround the OS might be able to do, which f.e. still doesn't allow to boot from such a controller though. If you are willing to go to such lengths to get random SATA controllers working the way cleaner approach would be to teach ata(4) or yet better its successor how to do all of the necessary initialization itself however. Marius