From owner-freebsd-sparc64@FreeBSD.ORG Sun Feb 3 15:57:21 2013 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BB57B35D; Sun, 3 Feb 2013 15:57:21 +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 4704ED9A; Sun, 3 Feb 2013 15:57:20 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.5/8.14.5/ALCHEMY.FRANKEN.DE) with ESMTP id r13FvIAr006234; Sun, 3 Feb 2013 16:57:18 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.5/8.14.5/Submit) id r13FvIvL006233; Sun, 3 Feb 2013 16:57:18 +0100 (CET) (envelope-from marius) Date: Sun, 3 Feb 2013 16:57:18 +0100 From: Marius Strobl To: Konstantin Belousov Subject: Re: Physbio changes final call for tests and reviews Message-ID: <20130203155718.GA6204@alchemy.franken.de> References: <20130202163322.GA2522@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130202163322.GA2522@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: powerpc@freebsd.org, mips@freebsd.org, current@freebsd.org, jeff@freebsd.org, ia64@freebsd.org, arch@freebsd.org, sparc64@freebsd.org, arm@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 15:57:21 -0000 On Sat, Feb 02, 2013 at 06:33:22PM +0200, Konstantin Belousov wrote: > Hi, > I finished the last (insignificant) missed bits in the Jeff' physbio > work. Now I am asking for the last round of testing and review, esp. for > the !x86 architectures. Another testing focus are the SCSI HBAs and RAID > controllers which drivers are changed by the patchset. Please do test > this before the patchset is committed into HEAD ! > > The plan is to commit the patch somewhere in two weeks from this moment. > The patch is required for the finalizing of the unmapped I/O work for UFS > I did in parallel, which I hope to finish shortly after the commit. > > Patch is available at http://people.freebsd.org/~kib/misc/physbio.5.diff > Once you bring in said UFS changes, will the use of bus_dmamap_load_ccb(9) be a requirement for disk controller drivers? Marius From owner-freebsd-sparc64@FreeBSD.ORG Mon Feb 4 11:06:51 2013 Return-Path: Delivered-To: freebsd-sparc64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C3CED9A9 for ; Mon, 4 Feb 2013 11:06:51 +0000 (UTC) (envelope-from owner-bugmaster@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 B592BD1E for ; Mon, 4 Feb 2013 11:06:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r14B6pbL028916 for ; Mon, 4 Feb 2013 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r14B6pei028906 for freebsd-sparc64@FreeBSD.org; Mon, 4 Feb 2013 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 4 Feb 2013 11:06:51 GMT Message-Id: <201302041106.r14B6pei028906@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 Subject: Current problem reports assigned to freebsd-sparc64@FreeBSD.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 11:06:51 -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/170663 sparc64 panics with VIA 6421 SATA150 controller on Blade 1500 o sparc/169669 sparc64 Something seems broken in sparc64 TLS or lang/lua o sparc/164227 sparc64 [boot] Can't boot 9.0-RELEASE/sparc64 on Blade 1500 s 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 11 problems total. From owner-freebsd-sparc64@FreeBSD.ORG Tue Feb 5 06:06:56 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C246FB6A; Tue, 5 Feb 2013 06:06:56 +0000 (UTC) (envelope-from lidl@hydra.pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::3c]) by mx1.freebsd.org (Postfix) with ESMTP id 46D538AF; Tue, 5 Feb 2013 06:06:56 +0000 (UTC) Received: from hydra.pix.net (localhost [127.0.0.1]) by hydra.pix.net (8.14.5/8.14.5) with ESMTP id r1566q5b040960; Tue, 5 Feb 2013 01:06:52 -0500 (EST) (envelope-from lidl@hydra.pix.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.6 at mail.pix.net Received: (from lidl@localhost) by hydra.pix.net (8.14.5/8.14.5/Submit) id r1566p41040959; Tue, 5 Feb 2013 01:06:51 -0500 (EST) (envelope-from lidl) Date: Tue, 5 Feb 2013 01:06:51 -0500 From: Kurt Lidl To: Marius Strobl Subject: Re: smartmontools panics 9.1-RELEASE on sunfire 240 Message-ID: <20130205060651.GA40942@pix.net> References: <20130104051914.GA22613@pix.net> <20130104235336.GB37999@alchemy.franken.de> <20130105013224.GA31361@pix.net> <20130105015242.GB26039@alchemy.franken.de> <20130106021923.GE1410@funkthat.com> <20130106031245.GC26039@alchemy.franken.de> <20130107090200.GA53424@pix.net> <20130123221024.GP85306@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130123221024.GP85306@alchemy.franken.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: mav@freebsd.org, freebsd-sparc64@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 06:06:56 -0000 On Wed, Jan 23, 2013 at 11:10:24PM +0100, Marius Strobl wrote: > Could you please revert the patches to sys/cam/cam_periph.c and smartd.cpp > of smartmontools and try with the following kernel patch instead? > http://people.freebsd.org/~marius/ata_pio_odd_buf.diff OK - I was finally able to test this out. I completely reverted a machine (sunfire V120) to a stock 9.1-RELEASE kernel. I completely reverted the smartmontools. I double-checked that the combination of that kernel, and that binary still caused the problem. Check. Then I applied your patch to the kernel and tried the smartd program again. No panic. It appears your patch fixes the problem. Thanks! -Kurt From owner-freebsd-sparc64@FreeBSD.ORG Tue Feb 5 06:19:58 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 432B8DC3 for ; Tue, 5 Feb 2013 06:19:58 +0000 (UTC) (envelope-from lidl@hydra.pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::3c]) by mx1.freebsd.org (Postfix) with ESMTP id D87F48FA for ; Tue, 5 Feb 2013 06:19:57 +0000 (UTC) Received: from hydra.pix.net (localhost [127.0.0.1]) by hydra.pix.net (8.14.5/8.14.5) with ESMTP id r156Ju25041060; Tue, 5 Feb 2013 01:19:56 -0500 (EST) (envelope-from lidl@hydra.pix.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.6 at mail.pix.net Received: (from lidl@localhost) by hydra.pix.net (8.14.5/8.14.5/Submit) id r156JuN1041059; Tue, 5 Feb 2013 01:19:56 -0500 (EST) (envelope-from lidl) Date: Tue, 5 Feb 2013 01:19:56 -0500 From: Kurt Lidl To: Marius Strobl Subject: Re: console stops with 9.1-RELEASE when under forwarding load Message-ID: <20130205061956.GB40942@pix.net> References: <20130122043541.GA67894@pix.net> <20130123223009.GA22474@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130123223009.GA22474@alchemy.franken.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-sparc64@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 06:19:58 -0000 On Wed, Jan 23, 2013 at 11:30:09PM +0100, Marius Strobl wrote: > On Mon, Jan 21, 2013 at 11:35:41PM -0500, Kurt Lidl wrote: > > I'm not sure if this is better directed at freebsd-sparc64@ > > or freebsd-net@ but I'm going to guess here... > > > > Anyways. In all cases, I'm using an absolutely stock > > FreeBSD 9.1-release installation. > > > > I got several SunFire V120 machines recently, and have been testing > > them out to verify their operation. They all started out identically > > configured -- 1 GB of memory, 2x36GB disks, DVD-rom, 650Mhz processor. > > The V120 has two on-board "gem" network interfaces. And the machine > > can take a single, 32-bit PCI card. > > > > I've benchmarked the gem interfaces being able to source or sink > > about 90mbit/sec of TCP traffic. This is comparable to the speed > > of "hme" interfaces that I've tested in my slower Netra-T1-105 > > machines. > > > > So. I put a Intel 32bit gig-e interface (a "GT" desktop > > Gig-E interface) into the machine, and it comes up like this: > > > > em0: port 0xc00200-0xc0023f mem 0x20000-0x3ffff,0x40000-0x5ffff at device 5.0 on pci2 > > em0: Memory Access and/or Bus Master bits were not set! > > em0: Ethernet address: 00:1b:21: > > > > That interface can source or sink TCP traffic at about > > 248 mbit/sec. > > > > Since I really want to make one of these machines my firewall/router, > > I took a different, dual-port Intel Gig-E server adaptor (a 64bit > > PCI card) and put it into one of the machines so I could look at > > the fowarding performance. It probes like this: > > > > em0: port 0xc00200-0xc0023f mem 0x20000-0x3ffff,0x40000-0x7ffff at device 5.0 on pci2 > > em0: Memory Access and/or Bus Master bits were not set! > > em0: Ethernet address: 00:04:23: > > em1: port 0xc00240-0xc0027f mem 0xc0000-0xdffff,0x100000-0x13ffff at device 5.1 on pci2 > > em1: Memory Access and/or Bus Master bits were not set! > > em1: Ethernet address: 00:04:23: > > > > Now this card can source traffic at about 250 mbit/sec and can sink > > traffic around 204 mbit/sec. > > > > But the real question is - how is the forwarding performance? > > > > So I setup a test between some machines: > > > > A --tcp data--> em0-sparc64-em1 --tcp data--> B > > | | > > \---------<--------tcp acks-------<-----------/ > > > > So, A sends to interface em0 on the sparc64, the sparc64 > > forward out em1 to host B, and the ack traffic flows out > > a different interface from B to A. (A and B are amd64 > > machines, with Gig-E interfaces that are considerably > > faster than the sparc64 machines.) > > > > This test works surprisingly well -- 270 mbit/sec of forwarding > > traffic, at around 29500 packets/second. > > > > The problem is when I change the test to send the tcp ack traffic > > back through the sparc64 (so, ack traffic goes from B into em1, > > then forwarded out em0 to A), while doing the data in the same way. > > > > The console of the sparc64 becomes completely unresponsive during > > the running of this test. The 'netstat 1' that I been running just > > stops. When the data finishes transmitting, the netstat output > > gives one giant jump, counting all the packets that were sent during > > the test as if they happened in a single second. > > > > It's pretty clear that the process I'm running on the console isn't > > receiving any cycles at all. This is true for whatever I have > > running on the console of machine -- a shell, vmstat, iostat, > > whatever. It just hangs until the forwarding test is over. > > Then the console input/output resumes normally. > > > > Has anybody else seen this type of problem? > > > > I don't see what could be a sparc64-specific problem in this case. > You are certainly pushing the hardware beyond its limits though and > it would be interesting to know how a similarly "powerful" i386 > machine behaves in this case. > In any case, in order to not burn any CPU cycles needlessly, you > should use a kernel built from a config stripped down to your > requirements and with options SMP removed to get the maximum out > of a UP machine. It could also be that SCHED_ULE actually helps > in this case (there's a bug in 9.1-RELEASE causing problems with > SCHED_ULE and SMP on sparc64, but for UP it should be fine). I updated the kernel tree on one of my sparc64 machines to the latest version of 9-STABLE, and gave the following combinations a try: SMP+ULE SMP+4BSD non-SMP+ULE non-SMP+4BSD They all performed about the same, in terms of throughput, and about the same in terms of user-responsiveness when under load. None were responsive when forwarding ~214mbit/sec of traffic. I played around a bit with tuning of the rx/tx queue depths for the em0/em1 devices, but none of that had any perceptable difference in the level of throughput or responsiveness of the machine. -Kurt From owner-freebsd-sparc64@FreeBSD.ORG Tue Feb 5 07:26:08 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8C6057BD for ; Tue, 5 Feb 2013 07:26:08 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-da0-f50.google.com (mail-da0-f50.google.com [209.85.210.50]) by mx1.freebsd.org (Postfix) with ESMTP id 519AFAE8 for ; Tue, 5 Feb 2013 07:26:08 +0000 (UTC) Received: by mail-da0-f50.google.com with SMTP id h15so3016436dan.9 for ; Mon, 04 Feb 2013 23:26:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=7rxU6V65KxfAVGndr/FFVlHpF+k07S38tPImLVn7FHY=; b=L2x7G8cs/ygBIDp+Qht8qAHae1YBVDcSYNEflAb1KMzLf8x8VdhkP66drzaMXUpQvX MJmnQ8ZsMY1Bb7twhWkfxPDGFZOf1i5UIishYA8s9BNM+zP8Gux7qFSg2OfcoFeRQykg od63A8y4GYMtvggH6kIeLzjdptFmFsOLVGYV80i61hxkLHTwpFv7OJGUW/1C2BsEkVFR Lkj5OiTw3aJ9ZNc/Cr4bEtw2V8OZ1E+52yATZYnIgEz2nT65RxnyhDjZ1D+qdcROjFm8 sLj5J4FFin23weta9F3YBc174Do8tPusDC64fS0Q9Fn8rcqk/WedoULrEpiCmnp93fxT AOBQ== X-Received: by 10.66.88.198 with SMTP id bi6mr61305513pab.54.1360049162264; Mon, 04 Feb 2013 23:26:02 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id t7sm23647662pax.17.2013.02.04.23.25.58 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 04 Feb 2013 23:26:01 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 05 Feb 2013 16:25:53 +0900 From: YongHyeon PYUN Date: Tue, 5 Feb 2013 16:25:53 +0900 To: Kurt Lidl Subject: Re: console stops with 9.1-RELEASE when under forwarding load Message-ID: <20130205072553.GB1439@michelle.cdnetworks.com> References: <20130122043541.GA67894@pix.net> <20130123223009.GA22474@alchemy.franken.de> <20130205061956.GB40942@pix.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130205061956.GB40942@pix.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-sparc64@freebsd.org, Marius Strobl X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 07:26:08 -0000 On Tue, Feb 05, 2013 at 01:19:56AM -0500, Kurt Lidl wrote: > On Wed, Jan 23, 2013 at 11:30:09PM +0100, Marius Strobl wrote: > > On Mon, Jan 21, 2013 at 11:35:41PM -0500, Kurt Lidl wrote: > > > I'm not sure if this is better directed at freebsd-sparc64@ > > > or freebsd-net@ but I'm going to guess here... > > > > > > Anyways. In all cases, I'm using an absolutely stock > > > FreeBSD 9.1-release installation. > > > > > > I got several SunFire V120 machines recently, and have been testing > > > them out to verify their operation. They all started out identically > > > configured -- 1 GB of memory, 2x36GB disks, DVD-rom, 650Mhz processor. > > > The V120 has two on-board "gem" network interfaces. And the machine > > > can take a single, 32-bit PCI card. > > > > > > I've benchmarked the gem interfaces being able to source or sink > > > about 90mbit/sec of TCP traffic. This is comparable to the speed > > > of "hme" interfaces that I've tested in my slower Netra-T1-105 > > > machines. > > > > > > So. I put a Intel 32bit gig-e interface (a "GT" desktop > > > Gig-E interface) into the machine, and it comes up like this: > > > > > > em0: port 0xc00200-0xc0023f mem 0x20000-0x3ffff,0x40000-0x5ffff at device 5.0 on pci2 > > > em0: Memory Access and/or Bus Master bits were not set! > > > em0: Ethernet address: 00:1b:21: > > > > > > That interface can source or sink TCP traffic at about > > > 248 mbit/sec. > > > > > > Since I really want to make one of these machines my firewall/router, > > > I took a different, dual-port Intel Gig-E server adaptor (a 64bit > > > PCI card) and put it into one of the machines so I could look at > > > the fowarding performance. It probes like this: > > > > > > em0: port 0xc00200-0xc0023f mem 0x20000-0x3ffff,0x40000-0x7ffff at device 5.0 on pci2 > > > em0: Memory Access and/or Bus Master bits were not set! > > > em0: Ethernet address: 00:04:23: > > > em1: port 0xc00240-0xc0027f mem 0xc0000-0xdffff,0x100000-0x13ffff at device 5.1 on pci2 > > > em1: Memory Access and/or Bus Master bits were not set! > > > em1: Ethernet address: 00:04:23: > > > > > > Now this card can source traffic at about 250 mbit/sec and can sink > > > traffic around 204 mbit/sec. > > > > > > But the real question is - how is the forwarding performance? > > > > > > So I setup a test between some machines: > > > > > > A --tcp data--> em0-sparc64-em1 --tcp data--> B > > > | | > > > \---------<--------tcp acks-------<-----------/ > > > > > > So, A sends to interface em0 on the sparc64, the sparc64 > > > forward out em1 to host B, and the ack traffic flows out > > > a different interface from B to A. (A and B are amd64 > > > machines, with Gig-E interfaces that are considerably > > > faster than the sparc64 machines.) > > > > > > This test works surprisingly well -- 270 mbit/sec of forwarding > > > traffic, at around 29500 packets/second. > > > > > > The problem is when I change the test to send the tcp ack traffic > > > back through the sparc64 (so, ack traffic goes from B into em1, > > > then forwarded out em0 to A), while doing the data in the same way. > > > > > > The console of the sparc64 becomes completely unresponsive during > > > the running of this test. The 'netstat 1' that I been running just > > > stops. When the data finishes transmitting, the netstat output > > > gives one giant jump, counting all the packets that were sent during > > > the test as if they happened in a single second. > > > > > > It's pretty clear that the process I'm running on the console isn't > > > receiving any cycles at all. This is true for whatever I have > > > running on the console of machine -- a shell, vmstat, iostat, > > > whatever. It just hangs until the forwarding test is over. > > > Then the console input/output resumes normally. > > > > > > Has anybody else seen this type of problem? > > > > > > > I don't see what could be a sparc64-specific problem in this case. > > You are certainly pushing the hardware beyond its limits though and > > it would be interesting to know how a similarly "powerful" i386 > > machine behaves in this case. > > In any case, in order to not burn any CPU cycles needlessly, you > > should use a kernel built from a config stripped down to your > > requirements and with options SMP removed to get the maximum out > > of a UP machine. It could also be that SCHED_ULE actually helps > > in this case (there's a bug in 9.1-RELEASE causing problems with > > SCHED_ULE and SMP on sparc64, but for UP it should be fine). > > I updated the kernel tree on one of my sparc64 machines to the > latest version of 9-STABLE, and gave the following combinations a > try: > SMP+ULE > SMP+4BSD > non-SMP+ULE > non-SMP+4BSD > They all performed about the same, in terms of throughput, > and about the same in terms of user-responsiveness when under load. > None were responsive when forwarding ~214mbit/sec of traffic. > > I played around a bit with tuning of the rx/tx queue depths for the > em0/em1 devices, but none of that had any perceptable difference in > the level of throughput or responsiveness of the machine. If my memory serve me right, em(4) requires considerably fast machine to offset the overhead of taskqueue(9). Because the taskqueue handler is enqueued again and again under heavy RX network load, most system cycles would be consumed in the taskqueue handler. Try polling(4) and see whether it makes any difference. I'm not sure whether polling(4) works on sparc64 though. > > -Kurt From owner-freebsd-sparc64@FreeBSD.ORG Tue Feb 5 20:16:37 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BD82AEB7; Tue, 5 Feb 2013 20:16:37 +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 0F7443FA; Tue, 5 Feb 2013 20:16:36 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.5/8.14.5/ALCHEMY.FRANKEN.DE) with ESMTP id r15KGTsY030981; Tue, 5 Feb 2013 21:16:29 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.5/8.14.5/Submit) id r15KGTws030980; Tue, 5 Feb 2013 21:16:29 +0100 (CET) (envelope-from marius) Date: Tue, 5 Feb 2013 21:16:29 +0100 From: Marius Strobl To: Kurt Lidl Subject: Re: smartmontools panics 9.1-RELEASE on sunfire 240 Message-ID: <20130205201629.GQ80850@alchemy.franken.de> References: <20130104051914.GA22613@pix.net> <20130104235336.GB37999@alchemy.franken.de> <20130105013224.GA31361@pix.net> <20130105015242.GB26039@alchemy.franken.de> <20130106021923.GE1410@funkthat.com> <20130106031245.GC26039@alchemy.franken.de> <20130107090200.GA53424@pix.net> <20130123221024.GP85306@alchemy.franken.de> <20130205060651.GA40942@pix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130205060651.GA40942@pix.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: mav@freebsd.org, freebsd-sparc64@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 20:16:37 -0000 On Tue, Feb 05, 2013 at 01:06:51AM -0500, Kurt Lidl wrote: > On Wed, Jan 23, 2013 at 11:10:24PM +0100, Marius Strobl wrote: > > Could you please revert the patches to sys/cam/cam_periph.c and smartd.cpp > > of smartmontools and try with the following kernel patch instead? > > http://people.freebsd.org/~marius/ata_pio_odd_buf.diff > > OK - I was finally able to test this out. > > I completely reverted a machine (sunfire V120) to a stock 9.1-RELEASE > kernel. I completely reverted the smartmontools. > > I double-checked that the combination of that kernel, and that binary > still caused the problem. Check. > > Then I applied your patch to the kernel and tried the smartd program > again. No panic. > > It appears your patch fixes the problem. Thanks, I've committed it in r246257 and will MFC it to stable/{8,9}. Marius From owner-freebsd-sparc64@FreeBSD.ORG Tue Feb 5 20:35:05 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8E05546A for ; Tue, 5 Feb 2013 20:35:05 +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 325C06EB for ; Tue, 5 Feb 2013 20:35:04 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.5/8.14.5/ALCHEMY.FRANKEN.DE) with ESMTP id r15KZ3B8031047; Tue, 5 Feb 2013 21:35:04 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.5/8.14.5/Submit) id r15KZ363031046; Tue, 5 Feb 2013 21:35:03 +0100 (CET) (envelope-from marius) Date: Tue, 5 Feb 2013 21:35:03 +0100 From: Marius Strobl To: YongHyeon PYUN Subject: Re: console stops with 9.1-RELEASE when under forwarding load Message-ID: <20130205203503.GR80850@alchemy.franken.de> References: <20130122043541.GA67894@pix.net> <20130123223009.GA22474@alchemy.franken.de> <20130205061956.GB40942@pix.net> <20130205072553.GB1439@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130205072553.GB1439@michelle.cdnetworks.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Kurt Lidl , freebsd-sparc64@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 20:35:05 -0000 On Tue, Feb 05, 2013 at 04:25:53PM +0900, YongHyeon PYUN wrote: > On Tue, Feb 05, 2013 at 01:19:56AM -0500, Kurt Lidl wrote: > > On Wed, Jan 23, 2013 at 11:30:09PM +0100, Marius Strobl wrote: > > > On Mon, Jan 21, 2013 at 11:35:41PM -0500, Kurt Lidl wrote: > > > > I'm not sure if this is better directed at freebsd-sparc64@ > > > > or freebsd-net@ but I'm going to guess here... > > > > > > > > Anyways. In all cases, I'm using an absolutely stock > > > > FreeBSD 9.1-release installation. > > > > > > > > I got several SunFire V120 machines recently, and have been testing > > > > them out to verify their operation. They all started out identically > > > > configured -- 1 GB of memory, 2x36GB disks, DVD-rom, 650Mhz processor. > > > > The V120 has two on-board "gem" network interfaces. And the machine > > > > can take a single, 32-bit PCI card. > > > > > > > > I've benchmarked the gem interfaces being able to source or sink > > > > about 90mbit/sec of TCP traffic. This is comparable to the speed > > > > of "hme" interfaces that I've tested in my slower Netra-T1-105 > > > > machines. > > > > > > > > So. I put a Intel 32bit gig-e interface (a "GT" desktop > > > > Gig-E interface) into the machine, and it comes up like this: > > > > > > > > em0: port 0xc00200-0xc0023f mem 0x20000-0x3ffff,0x40000-0x5ffff at device 5.0 on pci2 > > > > em0: Memory Access and/or Bus Master bits were not set! > > > > em0: Ethernet address: 00:1b:21: > > > > > > > > That interface can source or sink TCP traffic at about > > > > 248 mbit/sec. > > > > > > > > Since I really want to make one of these machines my firewall/router, > > > > I took a different, dual-port Intel Gig-E server adaptor (a 64bit > > > > PCI card) and put it into one of the machines so I could look at > > > > the fowarding performance. It probes like this: > > > > > > > > em0: port 0xc00200-0xc0023f mem 0x20000-0x3ffff,0x40000-0x7ffff at device 5.0 on pci2 > > > > em0: Memory Access and/or Bus Master bits were not set! > > > > em0: Ethernet address: 00:04:23: > > > > em1: port 0xc00240-0xc0027f mem 0xc0000-0xdffff,0x100000-0x13ffff at device 5.1 on pci2 > > > > em1: Memory Access and/or Bus Master bits were not set! > > > > em1: Ethernet address: 00:04:23: > > > > > > > > Now this card can source traffic at about 250 mbit/sec and can sink > > > > traffic around 204 mbit/sec. > > > > > > > > But the real question is - how is the forwarding performance? > > > > > > > > So I setup a test between some machines: > > > > > > > > A --tcp data--> em0-sparc64-em1 --tcp data--> B > > > > | | > > > > \---------<--------tcp acks-------<-----------/ > > > > > > > > So, A sends to interface em0 on the sparc64, the sparc64 > > > > forward out em1 to host B, and the ack traffic flows out > > > > a different interface from B to A. (A and B are amd64 > > > > machines, with Gig-E interfaces that are considerably > > > > faster than the sparc64 machines.) > > > > > > > > This test works surprisingly well -- 270 mbit/sec of forwarding > > > > traffic, at around 29500 packets/second. > > > > > > > > The problem is when I change the test to send the tcp ack traffic > > > > back through the sparc64 (so, ack traffic goes from B into em1, > > > > then forwarded out em0 to A), while doing the data in the same way. > > > > > > > > The console of the sparc64 becomes completely unresponsive during > > > > the running of this test. The 'netstat 1' that I been running just > > > > stops. When the data finishes transmitting, the netstat output > > > > gives one giant jump, counting all the packets that were sent during > > > > the test as if they happened in a single second. > > > > > > > > It's pretty clear that the process I'm running on the console isn't > > > > receiving any cycles at all. This is true for whatever I have > > > > running on the console of machine -- a shell, vmstat, iostat, > > > > whatever. It just hangs until the forwarding test is over. > > > > Then the console input/output resumes normally. > > > > > > > > Has anybody else seen this type of problem? > > > > > > > > > > I don't see what could be a sparc64-specific problem in this case. > > > You are certainly pushing the hardware beyond its limits though and > > > it would be interesting to know how a similarly "powerful" i386 > > > machine behaves in this case. > > > In any case, in order to not burn any CPU cycles needlessly, you > > > should use a kernel built from a config stripped down to your > > > requirements and with options SMP removed to get the maximum out > > > of a UP machine. It could also be that SCHED_ULE actually helps > > > in this case (there's a bug in 9.1-RELEASE causing problems with > > > SCHED_ULE and SMP on sparc64, but for UP it should be fine). > > > > I updated the kernel tree on one of my sparc64 machines to the > > latest version of 9-STABLE, and gave the following combinations a > > try: > > SMP+ULE > > SMP+4BSD > > non-SMP+ULE > > non-SMP+4BSD > > They all performed about the same, in terms of throughput, > > and about the same in terms of user-responsiveness when under load. > > None were responsive when forwarding ~214mbit/sec of traffic. > > > > I played around a bit with tuning of the rx/tx queue depths for the > > em0/em1 devices, but none of that had any perceptable difference in > > the level of throughput or responsiveness of the machine. > > If my memory serve me right, em(4) requires considerably fast > machine to offset the overhead of taskqueue(9). Because the > taskqueue handler is enqueued again and again under heavy RX > network load, most system cycles would be consumed in the > taskqueue handler. > Try polling(4) and see whether it makes any difference. I'm not > sure whether polling(4) works on sparc64 though. > This might or might not work or at least cause ill effects. In general, Sun PCI bridges synchronize DMA on interrupts and polling(4) bypasses that mechanism. For the host-PCI-bridges found in v210, psycho(4) additionally synchronizes DMA manually when bus_dmamap_sync(9) is called with BUS_DMASYNC_POSTREAD (as suggested in the datasheet). I'm not sure whether this is also sufficient for polling(4). In any case, sun4u hardware certainly wasn't built with something like polling(4) in mind. Hrm, according to my reading of the lem(4) source, it shouldn't use taskqueue(9) when setting the loader tunable hw.em.use_legacy_irq to 1 for the MACs in question. In any case, the latter certainly is easier to test than rebuilding a kernel with polling(4) support. Marius From owner-freebsd-sparc64@FreeBSD.ORG Fri Feb 8 12:01:59 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9F184F3E; Fri, 8 Feb 2013 12:01:59 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id 66D2A2F; Fri, 8 Feb 2013 12:01:59 +0000 (UTC) Received: from irix.bris.ac.uk ([137.222.10.39] helo=ncs.bris.ac.uk) by dirg.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1U3meF-000674-Gl; Fri, 08 Feb 2013 12:01:52 +0000 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1U3meF-00014X-Bu; Fri, 08 Feb 2013 12:01:43 +0000 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6) with ESMTP id r18C1fjT034687; Fri, 8 Feb 2013 12:01:42 GMT (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6/Submit) id r18C1fuK034685; Fri, 8 Feb 2013 12:01:41 GMT (envelope-from mexas) Date: Fri, 8 Feb 2013 12:01:41 GMT From: Anton Shterenlikht Message-Id: <201302081201.r18C1fuK034685@mech-cluster241.men.bris.ac.uk> To: freebsd-questions@freebsd.org, freebsd-sparc64@freebsd.org Subject: mount: /dev/da0p1: Invalid argument X-Spam-Score: -1.3 X-Spam-Level: - X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bristol.ac.uk List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 12:01:59 -0000 I need to transfer some files from sparc64 -current box onto amd64 9.1-RELEASE laptop. The amd64 laptop has no network connection yet, so I'm trying to achive this with a USB flash drive. The problem is that I always end up with # mount /dev/da0p1 /mnt/ mount: /dev/da0p1: Invalid argument # If I do newfs on the sparc64 box, then I can't mount it on the amd64 box, and vice versa. I tried just "newfs /dev/da0", and using gpart, e.g.: # gpart show /dev/da0 => 34 4029373 da0 GPT (1.9G) 34 2048 1 freebsd-ufs (1.0M) 2082 4027325 - free - (1.9G) # and then "newfs /dev/da0p1", or similar, but no luck. I tried sparc64 VTOC8 partition scheme too - no help. I can mount the device and use it as expected, i.e. copy files to/from it on either box, but the other box doesn't seem to understand the file system. I tried loading various modules in desperation, e.g. on the sparc64 side: # kldstat Id Refs Address Size Name 1 9 0xc0000000 a80e58 kernel 2 1 0x101bca000 104000 geom_part_mbr.ko 3 1 0x101cce000 110000 geom_label.ko 4 1 0x101dde000 108000 geom_part_gpt.ko # but still no use. Am I missing something simple? Thanks Anton From owner-freebsd-sparc64@FreeBSD.ORG Fri Feb 8 12:14:41 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BAA41325; Fri, 8 Feb 2013 12:14:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 5D223125; Fri, 8 Feb 2013 12:14:41 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r18CEWZI046147; Fri, 8 Feb 2013 14:14:32 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r18CEWZI046147 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r18CEWFM046146; Fri, 8 Feb 2013 14:14:32 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 8 Feb 2013 14:14:32 +0200 From: Konstantin Belousov To: Anton Shterenlikht Subject: Re: mount: /dev/da0p1: Invalid argument Message-ID: <20130208121432.GV2522@kib.kiev.ua> References: <201302081201.r18C1fuK034685@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4PjXPRN4SCmYnrHw" Content-Disposition: inline In-Reply-To: <201302081201.r18C1fuK034685@mech-cluster241.men.bris.ac.uk> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-questions@freebsd.org, freebsd-sparc64@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 12:14:41 -0000 --4PjXPRN4SCmYnrHw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 08, 2013 at 12:01:41PM +0000, Anton Shterenlikht wrote: > I need to transfer some files from sparc64 -current > box onto amd64 9.1-RELEASE laptop. > The amd64 laptop has no network connection yet, > so I'm trying to achive this with a USB flash drive.=20 >=20 > The problem is that I always end up with >=20 > # mount /dev/da0p1 /mnt/ > mount: /dev/da0p1: Invalid argument > #=20 >=20 > If I do newfs on the sparc64 box, then I can't > mount it on the amd64 box, and vice versa. >=20 > I tried just "newfs /dev/da0", and using gpart, > e.g.: >=20 > # gpart show /dev/da0 > =3D> 34 4029373 da0 GPT (1.9G) > 34 2048 1 freebsd-ufs (1.0M) > 2082 4027325 - free - (1.9G) >=20 > # >=20 > and then "newfs /dev/da0p1", or similar, > but no luck. >=20 > I tried sparc64 VTOC8 partition scheme too - no help. >=20 > I can mount the device and use it as expected, > i.e. copy files to/from it on either box, but > the other box doesn't seem to understand the file > system. >=20 > I tried loading various modules in desperation, > e.g. on the sparc64 side: >=20 > # kldstat=20 > Id Refs Address Size Name > 1 9 0xc0000000 a80e58 kernel > 2 1 0x101bca000 104000 geom_part_mbr.ko > 3 1 0x101cce000 110000 geom_label.ko > 4 1 0x101dde000 108000 geom_part_gpt.ko > #=20 >=20 > but still no use.=20 >=20 > Am I missing something simple? UFS on FreeBSD is not endian-agnostic. It uses the host byte order for multibyte values. As result, you can share UFS volumes only between hosts with the same endianess, like i386/amd64/ia64 little endian or sparc64/mips big endian. AFAIK, NetBSD has such support. --4PjXPRN4SCmYnrHw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRFOwoAAoJEJDCuSvBvK1BoTAP/ittIZAN06eVRcXoQo7TD9yu R5WU+ihk9/nCNBsAsXWvMBnBpn9C59A4vUeHXDiVluX4Rgk9xtjvNGdn9I4eJ3gw kDxHm+U9Jo+IaAmenN5Z1FTMQJV+jX2FczZXwztXP2RkPPCtK6BxYV5MmVrFDCNE 1W8CJjtcOzC3WB4d5t9M5+G2kpY7DqqjtMkam/6xI3YH7eKkxJAsZCDAv1/Nis7d AjomDVglxiuLzlMwcVfg/D7opt9Lp+kcu0nUOY6xSzlnA3szoflXvYQ2m0xodoqb X95oBCD+F7cFxug6/B6Oaxi+G9gbgQMGA/p7Mxfvm0LKzn7YoiksUxLVM+Pit84q Ka/k+pwv4RjwAtuByOkdZvtX3H+WXvIdoi08oX5pr4MChnxR0U+j+Uw1PfScZx/a pGokWLcWwbYLfyqx96XUz6odpGRHG6KAA4HExYqPIHPbPoXIrxBMEEsMy0M4yFhM bL59W6fDlD5SBx4Tv1gx+Ai0izpJ3PziRAiyItb0YuHGi/KzDkQe/svLq2w36gAL mFxoTbTsLDZfVL55vVzCuuvfActBvQDOQbiBOu2iDOZzqvZZIIVNiWrJFYyre98x r9kBjsxz03OuTqm8CMgF2i93VXqNav09VS2Vlu/TgfRFWVCSYYaCT7pKU6jTPYXR a9W3ki7Qp4+28ajQsV2H =1kUB -----END PGP SIGNATURE----- --4PjXPRN4SCmYnrHw-- From owner-freebsd-sparc64@FreeBSD.ORG Fri Feb 8 12:31:00 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 469786BC; Fri, 8 Feb 2013 12:31:00 +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 F23271EB; Fri, 8 Feb 2013 12:30:59 +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 1U3n6T-0006wi-DO; Fri, 08 Feb 2013 12:30:53 +0000 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 1U3n6S-00075r-Pk; Fri, 08 Feb 2013 12:30:53 +0000 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6) with ESMTP id r18CUpTn034752; Fri, 8 Feb 2013 12:30:51 GMT (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6/Submit) id r18CUpkL034751; Fri, 8 Feb 2013 12:30:51 GMT (envelope-from mexas) Date: Fri, 8 Feb 2013 12:30:51 GMT From: Anton Shterenlikht Message-Id: <201302081230.r18CUpkL034751@mech-cluster241.men.bris.ac.uk> To: kostikbel@gmail.com, mexas@bristol.ac.uk Subject: Re: mount: /dev/da0p1: Invalid argument In-Reply-To: <20130208121432.GV2522@kib.kiev.ua> Cc: freebsd-questions@freebsd.org, freebsd-sparc64@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bristol.ac.uk List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 12:31:00 -0000 From kostikbel@gmail.com Fri Feb 8 12:25:21 2013 On Fri, Feb 08, 2013 at 12:01:41PM +0000, Anton Shterenlikht wrote: > I need to transfer some files from sparc64 -current > box onto amd64 9.1-RELEASE laptop. > The amd64 laptop has no network connection yet, > so I'm trying to achive this with a USB flash drive.=20 >=20 > The problem is that I always end up with >=20 > # mount /dev/da0p1 /mnt/ > mount: /dev/da0p1: Invalid argument > #=20 >=20 > If I do newfs on the sparc64 box, then I can't > mount it on the amd64 box, and vice versa. >=20 > I tried just "newfs /dev/da0", and using gpart, > e.g.: >=20 > # gpart show /dev/da0 > =3D> 34 4029373 da0 GPT (1.9G) > 34 2048 1 freebsd-ufs (1.0M) > 2082 4027325 - free - (1.9G) >=20 > # >=20 > and then "newfs /dev/da0p1", or similar, > but no luck. >=20 > I tried sparc64 VTOC8 partition scheme too - no help. >=20 > I can mount the device and use it as expected, > i.e. copy files to/from it on either box, but > the other box doesn't seem to understand the file > system. >=20 > I tried loading various modules in desperation, > e.g. on the sparc64 side: >=20 > # kldstat=20 > Id Refs Address Size Name > 1 9 0xc0000000 a80e58 kernel > 2 1 0x101bca000 104000 geom_part_mbr.ko > 3 1 0x101cce000 110000 geom_label.ko > 4 1 0x101dde000 108000 geom_part_gpt.ko > #=20 >=20 > but still no use.=20 >=20 > Am I missing something simple? UFS on FreeBSD is not endian-agnostic. It uses the host byte order for multibyte values. As result, you can share UFS volumes only between hosts with the same endianess, like i386/amd64/ia64 little endian or sparc64/mips big endian. AFAIK, NetBSD has such support. Wow... I didn't realise that. I thought UFS (1 or 2) takes all care of endian-ness. Do you mean that even I had say a SCSI internal disk with UFS2, I couldn't move it between a little and a big endian freebsd boxes? So what is the advice for transferring data via USB in such cases? Any other gpart partition I could use? In the end I burned a CD with the files in question, but it's a bit of a waste, as I only need to move over several KB of data (wireless setup). Thanks Anton From owner-freebsd-sparc64@FreeBSD.ORG Fri Feb 8 12:45:20 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3ABB59B3; Fri, 8 Feb 2013 12:45:20 +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 A11BF293; Fri, 8 Feb 2013 12:45:19 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.5/8.14.5/ALCHEMY.FRANKEN.DE) with ESMTP id r18CjAG5075962; Fri, 8 Feb 2013 13:45:10 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.5/8.14.5/Submit) id r18CjA8q075961; Fri, 8 Feb 2013 13:45:10 +0100 (CET) (envelope-from marius) Date: Fri, 8 Feb 2013 13:45:10 +0100 From: Marius Strobl To: Anton Shterenlikht Subject: Re: mount: /dev/da0p1: Invalid argument Message-ID: <20130208124510.GA75868@alchemy.franken.de> References: <20130208121432.GV2522@kib.kiev.ua> <201302081230.r18CUpkL034751@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201302081230.r18CUpkL034751@mech-cluster241.men.bris.ac.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-questions@freebsd.org, freebsd-sparc64@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 12:45:20 -0000 On Fri, Feb 08, 2013 at 12:30:51PM +0000, Anton Shterenlikht wrote: > From kostikbel@gmail.com Fri Feb 8 12:25:21 2013 > > On Fri, Feb 08, 2013 at 12:01:41PM +0000, Anton Shterenlikht wrote: > > I need to transfer some files from sparc64 -current > > box onto amd64 9.1-RELEASE laptop. > > The amd64 laptop has no network connection yet, > > so I'm trying to achive this with a USB flash drive.=20 > >=20 > > The problem is that I always end up with > >=20 > > # mount /dev/da0p1 /mnt/ > > mount: /dev/da0p1: Invalid argument > > #=20 > >=20 > > If I do newfs on the sparc64 box, then I can't > > mount it on the amd64 box, and vice versa. > >=20 > > I tried just "newfs /dev/da0", and using gpart, > > e.g.: > >=20 > > # gpart show /dev/da0 > > =3D> 34 4029373 da0 GPT (1.9G) > > 34 2048 1 freebsd-ufs (1.0M) > > 2082 4027325 - free - (1.9G) > >=20 > > # > >=20 > > and then "newfs /dev/da0p1", or similar, > > but no luck. > >=20 > > I tried sparc64 VTOC8 partition scheme too - no help. > >=20 > > I can mount the device and use it as expected, > > i.e. copy files to/from it on either box, but > > the other box doesn't seem to understand the file > > system. > >=20 > > I tried loading various modules in desperation, > > e.g. on the sparc64 side: > >=20 > > # kldstat=20 > > Id Refs Address Size Name > > 1 9 0xc0000000 a80e58 kernel > > 2 1 0x101bca000 104000 geom_part_mbr.ko > > 3 1 0x101cce000 110000 geom_label.ko > > 4 1 0x101dde000 108000 geom_part_gpt.ko > > #=20 > >=20 > > but still no use.=20 > >=20 > > Am I missing something simple? > > UFS on FreeBSD is not endian-agnostic. It uses the host byte order > for multibyte values. > > As result, you can share UFS volumes only between hosts with the same > endianess, like i386/amd64/ia64 little endian or sparc64/mips big endian. > AFAIK, NetBSD has such support. > > Wow... I didn't realise that. > I thought UFS (1 or 2) takes all care > of endian-ness. Do you mean that even > I had say a SCSI internal disk with UFS2, > I couldn't move it between a little and > a big endian freebsd boxes? > > So what is the advice for transferring data > via USB in such cases? Any other gpart partition > I could use? > FAT should work and ZFS is also endian-agnostic. I don't know how well these code paths of the latter are tested though and we seem to have grown bugs in this regard at least in the area of intra- ZFS-version compatibility (which due to lack of understanding of the ZFS internals I'm not able to fix) since the split from (Open) Solaris. Marius From owner-freebsd-sparc64@FreeBSD.ORG Fri Feb 8 13:18:35 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E9DF7436; Fri, 8 Feb 2013 13:18:35 +0000 (UTC) (envelope-from bonomi@mail.r-bonomi.com) Received: from mail.r-bonomi.com (mx-out.r-bonomi.com [204.87.227.120]) by mx1.freebsd.org (Postfix) with ESMTP id 855E8405; Fri, 8 Feb 2013 13:18:35 +0000 (UTC) Received: (from bonomi@localhost) by mail.r-bonomi.com (8.14.4/rdb1) id r18DMgVi060782; Fri, 8 Feb 2013 07:22:42 -0600 (CST) Date: Fri, 8 Feb 2013 07:22:42 -0600 (CST) From: Robert Bonomi Message-Id: <201302081322.r18DMgVi060782@mail.r-bonomi.com> To: freebsd-questions@freebsd.org, freebsd-sparc64@freebsd.org, mexas@bristol.ac.uk Subject: Re: mount: /dev/da0p1: Invalid argument In-Reply-To: <201302081230.r18CUpkL034751@mech-cluster241.men.bris.ac.uk> X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 13:18:36 -0000 > Date: Fri, 8 Feb 2013 12:30:51 GMT > From: Anton Shterenlikht > Subject: Re: mount: /dev/da0p1: Invalid argument > > From kostikbel@gmail.com Fri Feb 8 12:25:21 2013 > > On Fri, Feb 08, 2013 at 12:01:41PM +0000, Anton Shterenlikht wrote: > > I need to transfer some files from sparc64 -current > > box onto amd64 9.1-RELEASE laptop. > > The amd64 laptop has no network connection yet, > > so I'm trying to achive this with a USB flash drive.=20 > >=20 > > The problem is that I always end up with > >=20 > > # mount /dev/da0p1 /mnt/ > > mount: /dev/da0p1: Invalid argument > > #=20 > >=20 > > If I do newfs on the sparc64 box, then I can't > > mount it on the amd64 box, and vice versa. > >=20 > > I tried just "newfs /dev/da0", and using gpart, > > e.g.: > >=20 > > # gpart show /dev/da0 > > =3D> 34 4029373 da0 GPT (1.9G) > > 34 2048 1 freebsd-ufs (1.0M) > > 2082 4027325 - free - (1.9G) > >=20 > > # > >=20 > > and then "newfs /dev/da0p1", or similar, > > but no luck. > >=20 > > I tried sparc64 VTOC8 partition scheme too - no help. > >=20 > > I can mount the device and use it as expected, > > i.e. copy files to/from it on either box, but > > the other box doesn't seem to understand the file > > system. > >=20 > > I tried loading various modules in desperation, > > e.g. on the sparc64 side: > >=20 > > # kldstat=20 > > Id Refs Address Size Name > > 1 9 0xc0000000 a80e58 kernel > > 2 1 0x101bca000 104000 geom_part_mbr.ko > > 3 1 0x101cce000 110000 geom_label.ko > > 4 1 0x101dde000 108000 geom_part_gpt.ko > > #=20 > >=20 > > but still no use.=20 > >=20 > > Am I missing something simple? > > UFS on FreeBSD is not endian-agnostic. It uses the host byte order > for multibyte values. > > As result, you can share UFS volumes only between hosts with the same > endianess, like i386/amd64/ia64 little endian or sparc64/mips big endian. > AFAIK, NetBSD has such support. > > Wow... I didn't realise that. > I thought UFS (1 or 2) takes all care > of endian-ness. Do you mean that even > I had say a SCSI internal disk with UFS2, > I couldn't move it between a little and > a big endian freebsd boxes? > > So what is the advice for transferring data > via USB in such cases? Any other gpart partition > I could use? you could use zfs. easier is to use the media as src/dest for tar/gtar/bsdtar/etc. tar is endian-agnostic, although there may be endian-ness issues with binary data in files inside the tarball. From owner-freebsd-sparc64@FreeBSD.ORG Fri Feb 8 13:31:35 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 449E8A73; Fri, 8 Feb 2013 13:31:35 +0000 (UTC) (envelope-from chris@monochrome.org) Received: from mail.monochrome.org (b4.ebbed1.client.atlantech.net [209.190.235.180]) by mx1.freebsd.org (Postfix) with ESMTP id C6BF56A4; Fri, 8 Feb 2013 13:31:34 +0000 (UTC) Received: from [192.168.1.11] ([192.168.1.11]) by mail.monochrome.org (8.14.3/8.14.3) with ESMTP id r18D7CRJ067578; Fri, 8 Feb 2013 08:07:12 -0500 (EST) (envelope-from chris@monochrome.org) Date: Fri, 8 Feb 2013 08:07:12 -0500 (EST) From: Chris Hill To: Anton Shterenlikht Subject: Re: mount: /dev/da0p1: Invalid argument In-Reply-To: <201302081230.r18CUpkL034751@mech-cluster241.men.bris.ac.uk> Message-ID: References: <201302081230.r18CUpkL034751@mech-cluster241.men.bris.ac.uk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-questions@freebsd.org, freebsd-sparc64@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 13:31:35 -0000 On Fri, 8 Feb 2013, Anton Shterenlikht wrote: [ snip ] > So what is the advice for transferring data > via USB in such cases? Any other gpart partition > I could use? I've always used FAT32 for thumb drives and the like. I don't know if the SPARC would be able to use it, but FAT32 seems like it's most likely to be usable by the largest number of different platforms. -- Chris Hill chris@monochrome.org ** [ Busy Expunging ] From owner-freebsd-sparc64@FreeBSD.ORG Fri Feb 8 13:38:25 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 777F2C43; Fri, 8 Feb 2013 13:38:25 +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 3E8536FB; Fri, 8 Feb 2013 13:38:25 +0000 (UTC) Received: from irix.bris.ac.uk ([137.222.10.39] helo=ncs.bris.ac.uk) by dirj.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1U3o9h-00034V-7M; Fri, 08 Feb 2013 13:38:24 +0000 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1U3o9g-0005Cv-PW; Fri, 08 Feb 2013 13:38:16 +0000 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6) with ESMTP id r18DcGKK034983; Fri, 8 Feb 2013 13:38:16 GMT (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6/Submit) id r18DcGa5034982; Fri, 8 Feb 2013 13:38:16 GMT (envelope-from mexas) Date: Fri, 8 Feb 2013 13:38:16 GMT From: Anton Shterenlikht Message-Id: <201302081338.r18DcGa5034982@mech-cluster241.men.bris.ac.uk> To: chris@monochrome.org, mexas@bristol.ac.uk Subject: Re: mount: /dev/da0p1: Invalid argument In-Reply-To: X-Spam-Score: -3.6 X-Spam-Level: --- Cc: freebsd-questions@freebsd.org, freebsd-sparc64@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bristol.ac.uk List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 13:38:25 -0000 From chris@monochrome.org Fri Feb 8 13:27:48 2013 On Fri, 8 Feb 2013, Anton Shterenlikht wrote: [ snip ] > So what is the advice for transferring data > via USB in such cases? Any other gpart partition > I could use? I've always used FAT32 for thumb drives and the like. I don't know if the SPARC would be able to use it, but FAT32 seems like it's most likely to be usable by the largest number of different platforms. But how do I create FAT32 partitions on FreeBSD? The gpart doesn't seem to support it. Anton From owner-freebsd-sparc64@FreeBSD.ORG Fri Feb 8 13:53:45 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B409B92; Fri, 8 Feb 2013 13:53:45 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id 682DA79E; Fri, 8 Feb 2013 13:53:45 +0000 (UTC) Received: from irix.bris.ac.uk ([137.222.10.39] helo=ncs.bris.ac.uk) by dirg.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1U3oOE-0005bs-8U; Fri, 08 Feb 2013 13:53:44 +0000 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1U3oOD-0005lZ-M9; Fri, 08 Feb 2013 13:53:17 +0000 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6) with ESMTP id r18DrHkB035062; Fri, 8 Feb 2013 13:53:17 GMT (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6/Submit) id r18DrHRW035061; Fri, 8 Feb 2013 13:53:17 GMT (envelope-from mexas) Date: Fri, 8 Feb 2013 13:53:17 GMT From: Anton Shterenlikht Message-Id: <201302081353.r18DrHRW035061@mech-cluster241.men.bris.ac.uk> To: bonomi@mail.r-bonomi.com, freebsd-questions@freebsd.org, freebsd-sparc64@freebsd.org, mexas@bristol.ac.uk Subject: Re: mount: /dev/da0p1: Invalid argument In-Reply-To: <201302081322.r18DMgVi060782@mail.r-bonomi.com> X-Spam-Score: -3.4 X-Spam-Level: --- X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bristol.ac.uk List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 13:53:45 -0000 From bonomi@mail.r-bonomi.com Fri Feb 8 13:27:49 2013 > From: Anton Shterenlikht > Subject: Re: mount: /dev/da0p1: Invalid argument > > From kostikbel@gmail.com Fri Feb 8 12:25:21 2013 > > On Fri, Feb 08, 2013 at 12:01:41PM +0000, Anton Shterenlikht wrote: > > I need to transfer some files from sparc64 -current > > box onto amd64 9.1-RELEASE laptop. > > The amd64 laptop has no network connection yet, > > so I'm trying to achive this with a USB flash drive.=20 > >=20 > > The problem is that I always end up with > >=20 > > # mount /dev/da0p1 /mnt/ > > mount: /dev/da0p1: Invalid argument > > #=20 > >=20 > > If I do newfs on the sparc64 box, then I can't > > mount it on the amd64 box, and vice versa. > >=20 > > I tried just "newfs /dev/da0", and using gpart, > > e.g.: > >=20 > > # gpart show /dev/da0 > > =3D> 34 4029373 da0 GPT (1.9G) > > 34 2048 1 freebsd-ufs (1.0M) > > 2082 4027325 - free - (1.9G) > >=20 > > # > >=20 > > and then "newfs /dev/da0p1", or similar, > > but no luck. > >=20 > > I tried sparc64 VTOC8 partition scheme too - no help. > >=20 > > I can mount the device and use it as expected, > > i.e. copy files to/from it on either box, but > > the other box doesn't seem to understand the file > > system. > >=20 > > I tried loading various modules in desperation, > > e.g. on the sparc64 side: > >=20 > > # kldstat=20 > > Id Refs Address Size Name > > 1 9 0xc0000000 a80e58 kernel > > 2 1 0x101bca000 104000 geom_part_mbr.ko > > 3 1 0x101cce000 110000 geom_label.ko > > 4 1 0x101dde000 108000 geom_part_gpt.ko > > #=20 > >=20 > > but still no use.=20 > >=20 > > Am I missing something simple? > > UFS on FreeBSD is not endian-agnostic. It uses the host byte order > for multibyte values. > > As result, you can share UFS volumes only between hosts with the same > endianess, like i386/amd64/ia64 little endian or sparc64/mips big endian. > AFAIK, NetBSD has such support. > > Wow... I didn't realise that. > I thought UFS (1 or 2) takes all care > of endian-ness. Do you mean that even > I had say a SCSI internal disk with UFS2, > I couldn't move it between a little and > a big endian freebsd boxes? > > So what is the advice for transferring data > via USB in such cases? Any other gpart partition > I could use? you could use zfs. easier is to use the media as src/dest for tar/gtar/bsdtar/etc. tar is endian-agnostic, although there may be endian-ness issues with binary data in files inside the tarball. Yes, tar works, e.g. on sparc64 side: # tar -cf - /home/mexas/ftree.gv | dd of=/dev/da0 tar: Removing leading '/' from member names 20+0 records in 20+0 records out 10240 bytes transferred in 0.214031 secs (47844 bytes/sec) # Then on amd64 side: #dd if=/dev/da0 | tar -xf - I've got my file. The only problem is that the last command never stopped. I had to terminate it with CTRL/C. Is that the right syntax at all? Thanks Anton From owner-freebsd-sparc64@FreeBSD.ORG Fri Feb 8 14:47:20 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E0BB2DAA; Fri, 8 Feb 2013 14:47:20 +0000 (UTC) (envelope-from jnagyjr1978@gmail.com) Received: from mail-gh0-f169.google.com (mail-gh0-f169.google.com [209.85.160.169]) by mx1.freebsd.org (Postfix) with ESMTP id 7C7189DB; Fri, 8 Feb 2013 14:47:20 +0000 (UTC) Received: by mail-gh0-f169.google.com with SMTP id r18so881834ghr.28 for ; Fri, 08 Feb 2013 06:47:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=V5dkVkBovqIV/f2HLG4Lk+su79S3U/oHoi1R49cVo7M=; b=zn99cHVYxsGCDiY7T8iN4PMlVTYsozJd0dQCyKZGuTtReI7deXMgxf+grWYeBgNCBs U9LfRGTX6fG0VKq7BdKIJa89MGVcnW03xFCKNu/YXd6atCpjGemv9ooVQMg9KaFSuUz3 Pk5NJheLu/RBB5IDlnheVSWr0NdRPUa7fWO8vY+wNxp/6UpUHyvYy9tpvjVWpA3kmTyv km9weCXO0w50H/Lbz1RIcvGfLT+D5OHnJZ7KAdEpBJSUSY04xhUfzoyin+qTapF+IUwZ jvnM8uB264si+xsOTjveor4IH6sjL6ODw5JLcMjshhD+y2I32/Fwx1EU8j84h/R6rDAb qABQ== X-Received: by 10.236.124.36 with SMTP id w24mr6288595yhh.19.1360334834139; Fri, 08 Feb 2013 06:47:14 -0800 (PST) Received: from [192.168.1.33] (vid-196.dhcp.grp10.tnmmrl.infoave.net. [204.116.254.196]) by mx.google.com with ESMTPS id h38sm28640647ani.7.2013.02.08.06.47.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Feb 2013 06:47:12 -0800 (PST) Message-ID: <51150FED.1050606@gmail.com> Date: Fri, 08 Feb 2013 08:47:09 -0600 From: "Joseph A. Nagy, Jr" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130206 Thunderbird/17.0.2 MIME-Version: 1.0 To: mexas@bristol.ac.uk Subject: Re: mount: /dev/da0p1: Invalid argument References: <201302081338.r18DcGa5034982@mech-cluster241.men.bris.ac.uk> In-Reply-To: <201302081338.r18DcGa5034982@mech-cluster241.men.bris.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: chris@monochrome.org, freebsd-questions@freebsd.org, freebsd-sparc64@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 14:47:20 -0000 On 02/08/13 07:38, Anton Shterenlikht wrote: > From chris@monochrome.org Fri Feb 8 13:27:48 2013 > > On Fri, 8 Feb 2013, Anton Shterenlikht wrote: > > [ snip ] > > > So what is the advice for transferring data > > via USB in such cases? Any other gpart partition > > I could use? > > I've always used FAT32 for thumb drives and the like. I don't know if > the SPARC would be able to use it, but FAT32 seems like it's most likely > to be usable by the largest number of different platforms. > > But how do I create FAT32 partitions on FreeBSD? > The gpart doesn't seem to support it. > > Anton for a new fat32 fs I used: newfs_msdos -F 32 -L travelsize /dev/da0 (FreeBSD 9.1 amd64 over here, for what it's worth) -- Yours in Christ, Joseph A Nagy Jr "Whoever loves instruction loves knowledge, But he who hates correction is stupid." -- Proverbs 12:1 Emails are not formal business letters, whatever businesses may want. Original content CopyFree (F) under the OWL http://copyfree.org/licenses/owl/license.txt From owner-freebsd-sparc64@FreeBSD.ORG Fri Feb 8 14:51:45 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EA9FC313; Fri, 8 Feb 2013 14:51:45 +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 B1B65A3B; Fri, 8 Feb 2013 14:51:45 +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 1U3pIm-0007lx-NW; Fri, 08 Feb 2013 14:51:44 +0000 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 1U3pIl-00013M-Vz; Fri, 08 Feb 2013 14:51:44 +0000 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6) with ESMTP id r18Ephnq035396; Fri, 8 Feb 2013 14:51:43 GMT (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6/Submit) id r18EphXa035395; Fri, 8 Feb 2013 14:51:43 GMT (envelope-from mexas) Date: Fri, 8 Feb 2013 14:51:43 GMT From: Anton Shterenlikht Message-Id: <201302081451.r18EphXa035395@mech-cluster241.men.bris.ac.uk> To: jnagyjr1978@gmail.com, mexas@bristol.ac.uk Subject: Re: mount: /dev/da0p1: Invalid argument In-Reply-To: <51150FED.1050606@gmail.com> Cc: chris@monochrome.org, freebsd-questions@freebsd.org, freebsd-sparc64@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bristol.ac.uk List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 14:51:46 -0000 From jnagyjr1978@gmail.com Fri Feb 8 14:47:22 2013 On 02/08/13 07:38, Anton Shterenlikht wrote: > From chris@monochrome.org Fri Feb 8 13:27:48 2013 > > On Fri, 8 Feb 2013, Anton Shterenlikht wrote: > > [ snip ] > > > So what is the advice for transferring data > > via USB in such cases? Any other gpart partition > > I could use? > > I've always used FAT32 for thumb drives and the like. I don't know if > the SPARC would be able to use it, but FAT32 seems like it's most likely > to be usable by the largest number of different platforms. > > But how do I create FAT32 partitions on FreeBSD? > The gpart doesn't seem to support it. > > Anton for a new fat32 fs I used: newfs_msdos -F 32 -L travelsize /dev/da0 (FreeBSD 9.1 amd64 over here, for what it's worth) got it, thanks. Seems it works on sparc64 too. Thanks Anton From owner-freebsd-sparc64@FreeBSD.ORG Fri Feb 8 16:16:26 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E01B3883; Fri, 8 Feb 2013 16:16:26 +0000 (UTC) (envelope-from freebsd@qeng-ho.org) Received: from blue.qeng-ho.org (blue.qeng-ho.org [217.155.128.241]) by mx1.freebsd.org (Postfix) with ESMTP id 66EA0EDA; Fri, 8 Feb 2013 16:16:26 +0000 (UTC) Received: from fileserver.home.qeng-ho.org (localhost [127.0.0.1]) by fileserver.home.qeng-ho.org (8.14.5/8.14.5) with ESMTP id r18GGHoi084340; Fri, 8 Feb 2013 16:16:17 GMT (envelope-from freebsd@qeng-ho.org) Message-ID: <511524D1.9010809@qeng-ho.org> Date: Fri, 08 Feb 2013 16:16:17 +0000 From: Arthur Chance User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130112 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Joseph A. Nagy, Jr" Subject: Re: mount: /dev/da0p1: Invalid argument References: <201302081338.r18DcGa5034982@mech-cluster241.men.bris.ac.uk> <51150FED.1050606@gmail.com> In-Reply-To: <51150FED.1050606@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org, freebsd-sparc64@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 16:16:26 -0000 On 02/08/13 14:47, Joseph A. Nagy, Jr wrote: > On 02/08/13 07:38, Anton Shterenlikht wrote: >> From chris@monochrome.org Fri Feb 8 13:27:48 2013 >> >> On Fri, 8 Feb 2013, Anton Shterenlikht wrote: >> >> [ snip ] >> >> > So what is the advice for transferring data >> > via USB in such cases? Any other gpart partition >> > I could use? >> >> I've always used FAT32 for thumb drives and the like. I don't know if >> the SPARC would be able to use it, but FAT32 seems like it's most >> likely >> to be usable by the largest number of different platforms. >> >> But how do I create FAT32 partitions on FreeBSD? >> The gpart doesn't seem to support it. >> >> Anton > > for a new fat32 fs I used: > > newfs_msdos -F 32 -L travelsize /dev/da0 > > (FreeBSD 9.1 amd64 over here, for what it's worth) Joseph is right in saying newfs_msdos -F 32 is how to format a FAT32 file system, but it occurs to me that Anton might be asking what type to specify to the gpart add command. Looking at http://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs and http://en.wikipedia.org/wiki/Basic_data_partition I think you probably want to use the type code for a Windows Basic data partition, which would be gpart add -t !EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 other_gpart_args [depending on your shell you may have to escape that '!']. According to the second Wikipedia page "According to Microsoft, the basic data partition is the equivalent to partition types 0x06, 0x07, and 0x0B (FAT16, NTFS, FAT32) in the traditional MBR partition table." From owner-freebsd-sparc64@FreeBSD.ORG Fri Feb 8 18:40:39 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 107ED746; Fri, 8 Feb 2013 18:40:39 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id C58A7852; Fri, 8 Feb 2013 18:40:38 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.6/8.14.6) with ESMTP id r18IeZV7068290; Fri, 8 Feb 2013 11:40:35 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.6/8.14.6/Submit) with ESMTP id r18IeYLo068287; Fri, 8 Feb 2013 11:40:34 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Fri, 8 Feb 2013 11:40:34 -0700 (MST) From: Warren Block To: Arthur Chance Subject: Re: mount: /dev/da0p1: Invalid argument In-Reply-To: <511524D1.9010809@qeng-ho.org> Message-ID: References: <201302081338.r18DcGa5034982@mech-cluster241.men.bris.ac.uk> <51150FED.1050606@gmail.com> <511524D1.9010809@qeng-ho.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Fri, 08 Feb 2013 11:40:35 -0700 (MST) Cc: "Joseph A. Nagy, Jr" , freebsd-questions@freebsd.org, freebsd-sparc64@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 18:40:39 -0000 On Fri, 8 Feb 2013, Arthur Chance wrote: > http://en.wikipedia.org/wiki/Basic_data_partition > > I think you probably want to use the type code for a Windows Basic data > partition, which would be > > gpart add -t !EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 other_gpart_args > > [depending on your shell you may have to escape that '!']. According to the > second Wikipedia page > > "According to Microsoft, the basic data partition is the equivalent to > partition types 0x06, 0x07, and 0x0B (FAT16, NTFS, FAT32) in the traditional > MBR partition table." I just use type 12: # gpart add -t \!12 ... It would be kind of nice if gpart had some keywords for those types, though. From owner-freebsd-sparc64@FreeBSD.ORG Sat Feb 9 12:08:36 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0BF2E571; Sat, 9 Feb 2013 12:08:36 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx02.qsc.de (mx02.qsc.de [213.148.130.14]) by mx1.freebsd.org (Postfix) with ESMTP id AB0C96E7; Sat, 9 Feb 2013 12:08:35 +0000 (UTC) Received: from r56.edvax.de (port-92-195-74-250.dynamic.qsc.de [92.195.74.250]) by mx02.qsc.de (Postfix) with ESMTP id 7399227620; Sat, 9 Feb 2013 13:08:27 +0100 (CET) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id r19C8UBC001935; Sat, 9 Feb 2013 13:08:30 +0100 (CET) (envelope-from freebsd@edvax.de) Date: Sat, 9 Feb 2013 13:08:30 +0100 From: Polytropon To: mexas@bristol.ac.uk Subject: Re: mount: /dev/da0p1: Invalid argument Message-Id: <20130209130830.762096cb.freebsd@edvax.de> In-Reply-To: <201302081230.r18CUpkL034751@mech-cluster241.men.bris.ac.uk> References: <20130208121432.GV2522@kib.kiev.ua> <201302081230.r18CUpkL034751@mech-cluster241.men.bris.ac.uk> Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org, freebsd-sparc64@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Polytropon List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2013 12:08:36 -0000 On Fri, 8 Feb 2013 12:30:51 GMT, Anton Shterenlikht wrote: > So what is the advice for transferring data > via USB in such cases? Any other gpart partition > I could use? Use "the most universal file system" which isn't even a file system: tar. First, create a tar archive (not a _file_!) to the USB media as if it was a tape. On the sparc machine: # tar cvf /dev/da0 You can add compression flags like z and j if you need. To list what you've got, use "tar t" accordingly. Then uncompress directly from the media on the non-sparc machine: # tar xvf /dev/da0 See "man tar" for other options you might want to add. Also note that in this case, no file system is involved, so you can't mount anything here. > In the end I burned a CD with the files in question, > but it's a bit of a waste, as I only need to > move over several KB of data (wireless setup). That's true. Don't you have any floppies at hand? ;-) (Note: The tar approach also works on floppies, and even across OS borders, e. g. between Solaris and Linux.) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... From owner-freebsd-sparc64@FreeBSD.ORG Sat Feb 9 12:11:54 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 29D6268C; Sat, 9 Feb 2013 12:11:54 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx02.qsc.de (mx02.qsc.de [213.148.130.14]) by mx1.freebsd.org (Postfix) with ESMTP id E643771F; Sat, 9 Feb 2013 12:11:53 +0000 (UTC) Received: from r56.edvax.de (port-92-195-74-250.dynamic.qsc.de [92.195.74.250]) by mx02.qsc.de (Postfix) with ESMTP id C87BC27620; Sat, 9 Feb 2013 13:11:52 +0100 (CET) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id r19CBtdP001952; Sat, 9 Feb 2013 13:11:55 +0100 (CET) (envelope-from freebsd@edvax.de) Date: Sat, 9 Feb 2013 13:11:55 +0100 From: Polytropon To: Chris Hill Subject: Re: mount: /dev/da0p1: Invalid argument Message-Id: <20130209131155.7eea2fa8.freebsd@edvax.de> In-Reply-To: References: <201302081230.r18CUpkL034751@mech-cluster241.men.bris.ac.uk> Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org, freebsd-sparc64@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Polytropon List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2013 12:11:54 -0000 On Fri, 8 Feb 2013 08:07:12 -0500 (EST), Chris Hill wrote: > On Fri, 8 Feb 2013, Anton Shterenlikht wrote: > > [ snip ] > > > So what is the advice for transferring data > > via USB in such cases? Any other gpart partition > > I could use? > > I've always used FAT32 for thumb drives and the like. I don't know if > the SPARC would be able to use it, but FAT32 seems like it's most likely > to be usable by the largest number of different platforms. While this may work for "ordinary purposes", it can cause trouble due to limitations of file name length, possibly also characters in file names, and maximum file sizes. If those factors are not triggered, it seems to be okay. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...