From owner-freebsd-sparc64@freebsd.org Sun Oct 11 21:35:03 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 62B549B1B72 for ; Sun, 11 Oct 2015 21:35:03 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0EE1F1594; Sun, 11 Oct 2015 21:35:02 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.15.2/8.15.2/ALCHEMY.FRANKEN.DE) with ESMTPS id t9BL9CUQ043960 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 11 Oct 2015 23:09:12 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id t9BL9C9k043959; Sun, 11 Oct 2015 23:09:12 +0200 (CEST) (envelope-from marius) Date: Sun, 11 Oct 2015 23:09:12 +0200 From: Marius Strobl To: Mark Cave-Ayland Cc: Alexey Dokuchaev , "freebsd-sparc64@freebsd.org" Subject: Re: PCI range checking under qemu-system-sparc64 Message-ID: <20151011210912.GA43837@alchemy.franken.de> References: <55FBB662.4080708@ilande.co.uk> <20150919211420.GK18789@alchemy.franken.de> <55FDEA3C.1010804@ilande.co.uk> <20150920043630.GA36162@FreeBSD.org> <20150922221404.GA81100@alchemy.franken.de> <560260A9.9010505@ilande.co.uk> <20150923204336.GO18789@alchemy.franken.de> <56044B9C.8030105@ilande.co.uk> <20150924195603.GT18789@alchemy.franken.de> <56087660.6070408@ilande.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56087660.6070408@ilande.co.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (alchemy.franken.de [0.0.0.0]); Sun, 11 Oct 2015 23:09:12 +0200 (CEST) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2015 21:35:03 -0000 On Mon, Sep 28, 2015 at 12:06:08AM +0100, Mark Cave-Ayland wrote: > On 24/09/15 20:56, Marius Strobl wrote: > > > On Thu, Sep 24, 2015 at 08:14:36PM +0100, Mark Cave-Ayland wrote: > >> On 23/09/15 21:43, Marius Strobl wrote: > >> > >>> On Wed, Sep 23, 2015 at 09:19:53AM +0100, Mark Cave-Ayland wrote: > >>>> > >>>> I've had a quick look through the relevant PDFs and the definitions I > >>>> have for tick/stick are this: > >>>> > >>>> tick: > >>>> bit 63: NPT (Non-Privileged Trap enable - defaults to 1) > >>>> bits 62 - 0: CPU cycle counter > >>>> > >>>> tick_cmpr: > >>>> bit 63: Interrupt disable (1 = no interrupt) > >>>> bits 62 - 0: counter compare value > >>>> > >>>> stick: > >>>> bit 63: Reserved (reads 0, no write) > >>>> bits 62 - 0: stick register count value > >>> > >>> I cannot confirm that, the specification for the first sun4u CPU > >>> having a %stick register (UltraSPARC III, see 1, p. 6-105) up to > >>> the latest architecture specification (see 2, p. 60) say that bit > >>> 32 of %stick is NPT, just as with %tick. Same for the specification > >>> the Fujitsu SPARC64 processors follow (3, p. 90). > >> > >> Interesting. The document I'm referring to in my local collection is the > >> UltraSPARC IIe specification which you can find a copy at > >> http://www.coris.org.uk/misc/Sundocs/USIIe_ext_1.1.pdf (see page 29). I > >> don't see this as necessarily being a conflict, it just seems that the > >> IIe allows unprivileged access to %stick. > > > > Err, we are taking about different STICK registers. The one I was > > referring to is the ASR24 CPU register, i. e. the thing QEMU tries > > to emulate. It works akin to TICK (%tick in GCC assembly) but is > > driven by a different clock in real machines. The STICK frequency > > is guaranteed to be the same across all CPUs (which unfortunately > > doesn't imply that the STICK registers are synchronized). ASR24 > > and the accompanying compare register (ASR25) were introduced with > > the UltraSPARC III as systems built on these were the first sun4u > > machines allowing to mix different CPU speeds (which results in > > different TICK clocks). > > > > UltraSPARC IIe had sort of a predecessor to that STICK register. > > The main difference is that the UltraSPARC IIe version has been > > implemented in I/O space (see page 42 of the PDF file you are > > citing), IIRC as part of the Hummingbird host-PCI-bridge built > > into the actual UltraSPARC IIe chips. That also explains why it > > has no NPT functionality (and why the UltraSPARC IIe user manual > > may be confusing as it doesn't solely document the CPU core; I > > think this isn't that different with UltraSPARC IIi, though). > > The UltraSPARC IIe STICK register was introduced to ease time > > keeping when the CPU clock is throttled (referred to as E-Star > > operation here; STICK frequency is unaffected by it). > > In short: You can ignore the UltraSPARC IIe documentation for > > the STICK CPU register QEMU tries to emulate. > > Now I see - I didn't quite appreciate the difference between IIe and II > %stick registers. Given that the default processor for QEMU is the TI > UltraSPARC IIi, does that mean that %stick should even be implemented in > the default configuration? Like I wrote above, the CPU-register-based STICK counter - which QEMU tries to emulate - was introduced with USIII. It also was brought over to sun4v, though, which additionally grew a HSTICK (Hyperprivileged System Tick, i. e. for use by the hypervisor). My understanding is target-sparc/translate.c is shared between the sun4u and sun4v emulation of QEMU, which explains why that source file implements all of TICK, STICK and HSTICK code. The I/O-space-based STICK counter in turn is specific to USIIe. So, no, as long as the sun4u support of QEMU consists of USIIi emulation only - which still is the case AFAICT -, there's no need to implement the I/O-space-based STICK counter in the default configuration. In fact, due to the limitation to USIIi, the sun4u emulation of QEMU currently would solely need to implement TICK support. I just wanted to point out the obvious bugs present in all of TICK, STICK and HSTICK CPU register code of QEMU but also the erroneous inconsistencies between these implementations. I still don't have an explanation for the incorrect behavior, i. e. the TICK compare interrupt not firing due to the disable bit somehow being stuck in QEMU, when trying to run FreeBSD, however. > In other news, as of this weekend I've finally got my FreeBSD VM set up > with -CURRENT and generating a SPARC64 .iso for test. I've got a basic > patchset for kb_ps2 and kdmouse that attaches under all of the BSDs but > causes my test Linux kernel to reference a NULL pointer. I'll post the > patchset onto the OpenBIOS list and a test binary as soon as I have > something that passes all of my local tests. > That's nice; modulo the NULL pointer dereference that is, of course :) Marius From owner-freebsd-sparc64@freebsd.org Mon Oct 12 15:25:41 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5DCCEA11BFA for ; Mon, 12 Oct 2015 15:25:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49D16A18 for ; Mon, 12 Oct 2015 15:25:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t9CFPfq7095272 for ; Mon, 12 Oct 2015 15:25:41 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-sparc64@FreeBSD.org Subject: [Bug 203381] [patch] mark mail/thunderbird BROKEN on sparc64 Date: Mon, 12 Oct 2015 15:25:41 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: swills@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gecko@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 15:25:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203381 Steve Wills changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |swills@FreeBSD.org --- Comment #3 from Steve Wills --- Permission granted, though I would think this type of change would be covered under blanket approvals (or should be if it's not). -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-sparc64@freebsd.org Sat Oct 17 18:01:09 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6513A1740F for ; Sat, 17 Oct 2015 18:01:09 +0000 (UTC) (envelope-from bvasea@gmail.com) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A8AD6F12 for ; Sat, 17 Oct 2015 18:01:09 +0000 (UTC) (envelope-from bvasea@gmail.com) Received: by qgad10 with SMTP id d10so33072674qga.3 for ; Sat, 17 Oct 2015 11:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=uMeOuVKTsI+GiVPgN242Wm2FvUzkGPsJJsN/Hml9XSOlqqS2zGvqOoNuLftjz4QZ4W mbuc7uFImZpXPthdf/HoWSM7JaYadGWOp4MoKaxcY5AsmFeB5wUWM6Xoosrr07OKrYlg s/IA7D7CgoZg8UGx1jUIcvcNtk7WisoytmyVFMblvndkzo2t89qDU+IYMNpDf/bpGWs8 /OgGJmrzBK10imeyMazGPLBQSpAJk8VvaeAiLQiaXWLBuPJPtzi3mUEottrAwgg4wg3k KPHa5xOEv9iK4nBjG+LY09ujUFSdX74qcIyTktuf2GD6QALDyAeHvLFdBIfv7J7jNsHa t1NA== MIME-Version: 1.0 X-Received: by 10.140.233.130 with SMTP id e124mr27932195qhc.79.1445104868813; Sat, 17 Oct 2015 11:01:08 -0700 (PDT) Received: by 10.55.181.67 with HTTP; Sat, 17 Oct 2015 11:01:08 -0700 (PDT) Date: Sat, 17 Oct 2015 21:01:08 +0300 Message-ID: Subject: FreeBSD 10.2-RELEASE UFS mount failu From: Vasile Buruiana To: freebsd-sparc64@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2015 18:01:10 -0000 From owner-freebsd-sparc64@freebsd.org Sat Oct 17 18:32:02 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 29807A1745E for ; Sat, 17 Oct 2015 18:32:02 +0000 (UTC) (envelope-from bvasea@gmail.com) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DDCC8137F for ; Sat, 17 Oct 2015 18:32:01 +0000 (UTC) (envelope-from bvasea@gmail.com) Received: by qgez77 with SMTP id z77so126467994qge.1 for ; Sat, 17 Oct 2015 11:32:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=tZIPW0TV6ERMrniCXpdC3ktI0lWLa9Q3UlgaPbvHYLc=; b=o4rsJypK9d277MZiuKbzSlE2OrgCYxuwW6pYZlT0/St3D80jK1Mj7O6Ic0inVjQ3aU Dpbh1YRGD7CMXH65qT4e1kLlSTSJzy/kSMdcu4+ozeUwQfORq5eusV4MSHGxEBBNi77W nfSgePBCgqVfVLI7w2ebanxxWqSS9LqemKaAGiLzHx6IiFhXQwA+zeYAgG6/JCXDaG3y J1ldMNb9pbyUzttRNj9gIsfMKSJZHlE3d3/k62GQj8zH/eJZUgovekkIYPMeE0M00XIm 5OwaUtg435vV2HdSCZjM0sJFL4qVvWcAmLPs6QPmcwSMTfM8oc9Gg1w5+u7aS6Xja7vQ 8SOA== MIME-Version: 1.0 X-Received: by 10.140.94.148 with SMTP id g20mr26861866qge.43.1445106720817; Sat, 17 Oct 2015 11:32:00 -0700 (PDT) Received: by 10.55.181.67 with HTTP; Sat, 17 Oct 2015 11:32:00 -0700 (PDT) Date: Sat, 17 Oct 2015 21:32:00 +0300 Message-ID: Subject: UFS mount failure - disk slice created on and64, unable to mount on sparc64 From: Vasile Buruiana To: freebsd-sparc64@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2015 18:32:02 -0000 Hello Found a bug in FreeBSD 10.2. An UFS disk slice created under sparc64 cannot be mounted under amd64. And reverse: UFS disk slice created under amd64 cannot be mounted under sparc64. This also happens with hard disks on both MBR and VTOC8 partition schemes, on both UFS and ZFS filesystems. uname -a ________ sparc64: root@sun:/usr/home/skaarj # uname -a FreeBSD sun.home.com 10.2-RELEASE FreeBSD 10.2-RELEASE #0 r286666: Thu Aug 13 01:16:49 UTC 2015 root@releng1.nyi.freebsd.org:/usr/obj/sparc64.sparc64/usr/src/sys/GENERIC sparc64 root@sun:/usr/home/skaarj # and amd64: root@supercow:/usr/home/skaarj # uname -a FreeBSD supercow.rompetrol.ro 10.2-RELEASE FreeBSD 10.2-RELEASE #0 r286666: Wed Aug 12 15:26:37 UTC 2015 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 root@supercow:/usr/home/skaarj # As we can see, both kernels are the generic. This is how you can simply reproduce the bug: _____________________________________ amd64: -> create 400MB disk image with dd, attach to md and format with newfs -> mount, copy some stuff(/bin), unmount, detach from md; -> md5+sh256 check of the image to see if they match when sent to the other side; -> send it with ftp to the sparc64 machine root@supercow:/usr/home/skaarj # dd if=/dev/zero of=/disk.img bs=8M count=50 50+0 records in 50+0 records out 419430400 bytes transferred in 6.336222 secs (66195661 bytes/sec) root@supercow:/usr/home/skaarj # mdconfig -a -u 0 /disk.img root@supercow:/usr/home/skaarj # newfs -U /dev/md0 /dev/md0: 400.0MB (819200 sectors) block size 32768, fragment size 4096 using 4 cylinder groups of 100.03MB, 3201 blks, 12928 inodes. with soft updates super-block backups (for fsck_ffs -b #) at: 192, 205056, 409920, 614784 root@supercow:/usr/home/skaarj # mount /dev/md0 /mnt root@supercow:/usr/home/skaarj # cp -R /bin /mnt root@supercow:/usr/home/skaarj # ls -l /mnt total 8 drwxrwxr-x 2 root operator 512 Oct 18 00:09 .snap drwxr-xr-x 2 root wheel 1024 Oct 18 00:10 bin root@supercow:/usr/home/skaarj # umount /mnt root@supercow:/usr/home/skaarj # md5 /disk.img MD5 (/disk.img) = ba7c649f74ddfce95e312a6f637e4a09 root@supercow:/usr/home/skaarj # sha256 /disk.img SHA256 (/disk.img) = 18d5d318e662cad6c7b20fd15faed33891300d6294835dc822d8099421747c52 root@supercow:/usr/home/skaarj # ftp 1.1.1.19 Connected to 1.1.1.19. 220 sun.home.com FTP server (Version 6.00LS) ready. Name (1.1.1.19:skaarj): skaarj Password: ftp> mput /disk.img 100% |************************************************| 400 MiB 5.08 MiB/s 00:00 ETA 226 Transfer complete. _______________________________________________________________________________ sparc64: -> md5+sha256 of image to compare; -> attach + md and mount root@sun:/usr/home/skaarj # md5 disk.img MD5 (disk.img) = ba7c649f74ddfce95e312a6f637e4a09 root@sun:/usr/home/skaarj # sha256 disk.img SHA256 (disk.img) = 18d5d318e662cad6c7b20fd15faed33891300d6294835dc822d8099421747c52 root@sun:/usr/home/skaarj # mdconfig -a -u 0 disk.img root@sun:/usr/home/skaarj # mount /dev/md0 /mnt mount: /dev/md0: Invalid argument root@sun:/usr/home/skaarj # _____________________________ no error output on /var/log/messages, no error output on dmesg when mount fails on both systems. Dmesgs after mount failure _______________________________________________________________________________ dmesg on sparc64: Copyright (c) 1992-2015 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.2-RELEASE #0 r286666: Thu Aug 13 01:16:49 UTC 2015 root@releng1.nyi.freebsd.org:/usr/obj/sparc64.sparc64/usr/src/sys/GENERIC sparc64 gcc version 4.2.1 20070831 patched [FreeBSD] real memory = 268435456 (256 MB) avail memory = 234143744 (223 MB) cpu0: Sun Microsystems UltraSparc-IIi Processor (400.00 MHz CPU) random: initialized kbd1 at kbdmux0 nexus0: pcib0: mem 0x1fe00000000-0x1fe0000ffff,0x1fe01000000-0x1fe0 10000ff irq 2032,2030,2031,2021 on nexus0 pcib0: Sabre, impl 0, version 0, IGN 0x1f, bus A, 66MHz pcib0: DVMA map: 0xc0000000 to 0xc3ffffff 8192 entries pcib0: [GIANT-LOCKED] pci0: on pcib0 pcib1: at device 1.1 on pci0 pci1: on pcib1 pcib1: device (null) requested unsupported I/O range 0x0-0xff ebus0: mem 0xf0000000-0xf0ffffff,0xf1000000-0xf17fffff at dev ice 1.0 on pci1 pcib2: at device 1.0 on pci0 pci2: on pcib2 auxio0: addr 0x1400726000-0x1400726003,0x1400728000-0x140072 8003,0x140072a000-0x140072a003,0x140072c000-0x140072c003,0x140072f000-0x140072f0 03 on ebus0 ebus0: addr 0x1400724000-0x1400724003 irq 37 (no driver attached) ebus0: addr 0x1400504000-0x1400504002 (no driver attached) scc0: addr 0x1400400000-0x140040007f irq 43 on ebus0 uart0: on scc0 uart0: CTS oflow uart1: on scc0 uart1: CTS oflow uart2: <16550 or compatible> addr 0x14003083f8-0x14003083ff irq 41 on ebus0 uart2: keyboard (1200,n,8,1) kbd0 at sunkbd0 uart3: <16550 or compatible> addr 0x14003062f8-0x14003062ff irq 42 on ebus0 ebus0: addr 0x14003043bc-0x14003043cb,0x140030015c-0x140030015d,0x1400700 000-0x140070000f irq 34 (no driver attached) ebus0: addr 0x14003023f0-0x14003023f7,0x1400706000-0x140070600f,0x1400 720000-0x1400720003 irq 39 (no driver attached) eeprom0: addr 0x1400000000-0x1400001fff on ebus0 eeprom0: model mk48t59 ebus0: addr 0x1000000000-0x10000fffff (no driver attached) pcm0: addr 0x1400200000-0x14002000ff,0x1400702000-0x140070200f,0x1 400704000-0x140070400f,0x1400722000-0x1400722003 irq 35,36 on ebus0 pcm0: hme0: mem 0xe0000000-0xe0007fff at device 1.1 on pci1 miibus0: on hme0 nsphy0: PHY 1 on miibus0 nsphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto hme0: Ethernet address: 08:00:20:ff:6e:88 machfb0: mem 0xe1000000-0xe1ffffff,0xe2000000-0xe2000fff at de vice 2.0 on pci1 machfb0: console machfb0: 16 MB aperture at 0xfe000000 not swapped machfb0: 4096 KB SGRAM 98.924 MHz, maximum RAMDAC clock 230 MHz, DSP machfb0: resolution 1152x900 at 8 bpp atapci0: port 0xc00000-0xc00007,0xc00008-0xc000 0b,0xc00010-0xc00017,0xc00018-0xc0001b,0xc00020-0xc0002f at device 3.0 on pci1 ata2: at channel 0 on atapci0 ata3: at channel 1 on atapci0 syscons0: on nexus0 syscons0: Unknown <16 virtual consoles, flags=0x300> Timecounter "tick" frequency 400000000 Hz quality 1000 Event timer "tick" frequency 400000000 Hz quality 1000 Timecounters tick every 1.000 msec interrupt storm detected on "vec2016:"; throttling interrupt source ada0 at ata2 bus 0 scbus0 target 0 lun 0 ada0: ATA-6 device ada0: Serial Number WD-WCAM9N419109 ada0: 16.700MB/s transferscd0 at ata3 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI device cd0: Serial Number 6AD0AA149275 cd0: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present (WDMA2, PIO 8192bytes) random: unblocking device. ada0: 76319MB (156301488 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 ada1 at ata2 bus 0 scbus0 target 1 lun 0 ada1: ATA-6 device ada1: Serial Number WD-WCAM9V150577 ada1: 16.700MB/s transfers (WDMA2, PIO 8192bytes) ada1: 76319MB (156301488 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad1 Trying to mount root from ufs:/dev/ada0a [rw]... _______________________________________________________________________ dmesg on amd64: _______________________________________________________________________ Copyright (c) 1992-2015 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.2-RELEASE #0 r286666: Wed Aug 12 15:26:37 UTC 2015 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 CPU: Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz (2594.16-MHz K8-class CPU) Origin="GenuineIntel" Id=0x306a9 Family=0x6 Model=0x3a Stepping=9 Features=0xbfebfbff Features2=0x7fbae3bf AMD Features=0x28100800 AMD Features2=0x1 Structured Extended Features=0x281 XSAVE Features=0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 3777761280 (3602 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 irqs 0-23 on motherboard random: initialized kbd1 at kbdmux0 acpi0: on motherboard acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x6000-0x603f mem 0xf0000000-0xf03fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: aperture size is 256M, detected 65532k stolen memory vgapci0: Boot video device xhci0: mem 0xf2520000-0xf252ffff irq 16 at device 20.0 on pci0 xhci0: 32 bytes context size, 64-bit DMA xhci0: Port routing mask set to 0xffffffff usbus0 on xhci0 pci0: at device 22.0 (no driver attached) em0: port 0x6080-0x609f mem 0xf2500000-0xf251ffff,0xf253b000-0xf253bfff irq 20 at device 25.0 on pci0 em0: Using an MSI interrupt em0: Ethernet address: 28:d2:44:10:3f:ae ehci0: mem 0xf253a000-0xf253a3ff irq 16 at device 26.0 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci0 hdac0: mem 0xf2530000-0xf2533fff irq 22 at device 27.0 on pci0 pcib1: irq 16 at device 28.0 on pci0 pci2: on pcib1 sdhci_pci0: mem 0xf1d00000-0xf1d000ff irq 16 at device 0.0 on pci2 sdhci_pci0: 1 slot(s) allocated pcib2: irq 17 at device 28.1 on pci0 pci3: on pcib2 pci3: at device 0.0 (no driver attached) pcib3: irq 18 at device 28.2 on pci0 pci4: on pcib3 ehci1: mem 0xf2539000-0xf25393ff irq 23 at device 29.0 on pci0 usbus2: EHCI version 1.0 usbus2 on ehci1 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x60a8-0x60af,0x60b4-0x60b7,0x60a0-0x60a7,0x60b0-0x60b3,0x6060-0x607f mem 0xf2538000-0xf25387ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich4: at channel 4 on ahci0 ahciem0: on ahci0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 battery0: on acpi0 acpi_acad0: on acpi0 orm0: at iomem 0xc0000-0xcffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range est0: on cpu0 est1: on cpu1 est2: on cpu2 est3: on cpu3 Timecounters tick every 1.000 msec hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 20,21 and 24 on hdaa0 pcm1: at nid 18 on hdaa0 hdacc1: at cad 3 on hdac0 hdaa1: at nid 1 on hdacc1 pcm2: at nid 5 on hdaa1 pcm3: at nid 6 on hdaa1 pcm4: at nid 7 on hdaa1 random: unblocking device. usbus0: 5.0Gbps Super Speed USB v3.0 usbus1: 480Mbps High Speed USB v2.0 usbus2: 480Mbps High Speed USB v2.0 ugen1.1: at usbus1 uhub0: on usbus1 ugen0.1: <0x8086> at usbus0 uhub1: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 ugen2.1: at usbus2 uhub2: on usbus2 ses0 at ahciem0 bus 0 scbus3 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA8-ACS SATA 2.x device ada0: Serial Number W0Q9KW2S ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 305245MB (625142448 512 byte sectors: 1H 63S/T 16383C) ada0: quirks=0x1<4K> ada0: Previously was known as ad4 cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI device cd0: Serial Number S45N7602Z1ZM1R00KBEN cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! Timecounter "TSC-low" frequency 1297082444 Hz quality 1000 uhub1: 8 ports with 8 removable, self powered Root mount waiting for: usbus2 usbus1 uhub0: 3 ports with 3 removable, self powered uhub2: 3 ports with 3 removable, self powered Root mount waiting for: usbus2 usbus1 ugen1.2: at usbus1 uhub3: on usbus1 ugen2.2: at usbus2 uhub4: on usbus2 Root mount waiting for: usbus2 usbus1 uhub3: 6 ports with 6 removable, self powered uhub4: 8 ports with 8 removable, self powered ugen1.3: at usbus1 Root mount waiting for: usbus1 ugen1.4: at usbus1 ugen1.5: at usbus1 Trying to mount root from ufs:/dev/ada0s4a [rw]... ____________________________________________________ Please advise Best wishes, Vasile From owner-freebsd-sparc64@freebsd.org Sat Oct 17 18:44:33 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04528A1773B for ; Sat, 17 Oct 2015 18:44:33 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D897E1B88 for ; Sat, 17 Oct 2015 18:44:32 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t9HIiPgQ065256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Oct 2015 11:44:25 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t9HIiPs5065255; Sat, 17 Oct 2015 11:44:25 -0700 (PDT) (envelope-from jmg) Date: Sat, 17 Oct 2015 11:44:25 -0700 From: John-Mark Gurney To: Vasile Buruiana Cc: freebsd-sparc64@freebsd.org Subject: Re: UFS mount failure - disk slice created on and64, unable to mount on sparc64 Message-ID: <20151017184425.GR67524@funkthat.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Sat, 17 Oct 2015 11:44:25 -0700 (PDT) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2015 18:44:33 -0000 Vasile Buruiana wrote this message on Sat, Oct 17, 2015 at 21:32 +0300: > Found a bug in FreeBSD 10.2. > An UFS disk slice created under sparc64 cannot be mounted under amd64. > And reverse: UFS disk slice created under amd64 cannot be mounted > under sparc64. This also happens with hard disks on both MBR and VTOC8 > partition schemes, on both UFS and ZFS filesystems. Sadly, this is due to the fact that sparc64 is big endian, and our UFS implementation isn't bi-endian... If you need to make a UFS file system on amd64 for use on sparc64, use the makefs utility w/ the option -B big to create it... Just ran into the same issue on an EdgeRouter Lite, which is a big endian MIPS64 machine... Though I'm a bit surprized that it happens w/ ZFS as ZFS is suppose to support either endianness automaticly.. Did you try this on raw disks? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-sparc64@freebsd.org Sat Oct 17 19:38:24 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DC440A172DF for ; Sat, 17 Oct 2015 19:38:23 +0000 (UTC) (envelope-from bvasea@gmail.com) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9AF48CEB for ; Sat, 17 Oct 2015 19:38:23 +0000 (UTC) (envelope-from bvasea@gmail.com) Received: by qgbb65 with SMTP id b65so22313765qgb.2 for ; Sat, 17 Oct 2015 12:38:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cyVOJfoKAsnlVULrn5r/DQFjEYZYtiKhjcBmCYzmXhw=; b=QB7KLNTQUoVARhRLXGblDcr4fWd6/ZvflNzCQPui1fqrKo537zk+TB3AE0xdTSRToU KMcXg8zRf60xC+eoJ9Z+LSYdLTBJT1AingKHwcGZtweUMTlro4OPOFtzypInPjYQ7TC0 9pcQEzRafGhveB5rD8b89dbelqUC+f+4/dva0AVoeDMNOeZlouaK8+DItcTDyVsZElIW ZwseiGRuyb8ANgtyYiN/pNkNzlk5hYnEifj6xG3E3Z2YdgBrG6N0zWXufM6CGnRrSLub kaPKnoPTySWfU5ph2KQ9kFDQjOKgS4/Wv3QWCyYTQn6g3gclIKOeP1JiFEvh/xSwl+sE eYKg== MIME-Version: 1.0 X-Received: by 10.140.34.208 with SMTP id l74mr26514116qgl.61.1445110702578; Sat, 17 Oct 2015 12:38:22 -0700 (PDT) Received: by 10.55.181.67 with HTTP; Sat, 17 Oct 2015 12:38:22 -0700 (PDT) In-Reply-To: <20151017184425.GR67524@funkthat.com> References: <20151017184425.GR67524@funkthat.com> Date: Sat, 17 Oct 2015 22:38:22 +0300 Message-ID: Subject: Re: UFS mount failure - disk slice created on and64, unable to mount on sparc64 From: Vasile Buruiana To: John-Mark Gurney Cc: freebsd-sparc64@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2015 19:38:24 -0000 Yesm I played with a harddisk connected via IDE to the sun and later to the laptop via USB-to-IDE adapter. Currently I'm trying to buildworkd+buildkernel on the sun using some contents of the /usr/obj cross-compiled on the amd-64 laptop to speed up the process (that's how I found the problem), so I'm writing these from my memory: This happened on the SUN: gpart create -s mbr ada0 gpart add -t freebsd ada0 gpart create -s bsd ada0s1 gpart add -s 1G -t freebsd-zfs ada0s1 newfs -U /dev/ada0s1 copy stuff, umount, invalid argument while attempting to mount on the laptop. gpart create -s vtoc8 ada0 gpart add -t freebsd ada0 gpart create -s bsd da0s1 gpart add -s 1G -t freebsd-zfs ada0s1 newfs -U /dev/ada0s1 copy suff, unmount, again invalid argument while attempting to mount on the laptop. Same when creating on the laptop and mounting on the sun. When moving the harddisk from one unit to the other, at boot (or at usb insert) the kernel reports: g_dev_taste: make_dev_p() failed (gp->name=da0a, error=17) or ada0a and many slices appear in /dev: da0a da0aa da0ab da0b da0c da0ca da0cb (or ada0s1a, ada0s1aa, ada0s1ab, ada0s1b, ada0s1bb, ada0s1c, ada0s1ca on the sparc64....) and so on, same for mbr/vtoc8, same for bsd/zfs. These are some geom-relaed errors as I read on some other mailing lists, so I tried to identify the problem by simplifying things until I reduced everything to image file attached to md. The Sparc also ran a FreeBSD 6.1-release perfectly, the ufs mbr partition could be mounted on a x86 for fsck or other maintenance with absolutely no problems. Seems that the advances in technology are still causing headaches in keeping the things simple. I will try to makefs -B big on the amd64 but I doubt i will also be able to mount it on the same machine. Best wishes Vasile On 10/17/15, John-Mark Gurney wrote: > Vasile Buruiana wrote this message on Sat, Oct 17, 2015 at 21:32 +0300: >> Found a bug in FreeBSD 10.2. >> An UFS disk slice created under sparc64 cannot be mounted under amd64. >> And reverse: UFS disk slice created under amd64 cannot be mounted >> under sparc64. This also happens with hard disks on both MBR and VTOC8 >> partition schemes, on both UFS and ZFS filesystems. > > Sadly, this is due to the fact that sparc64 is big endian, and our UFS > implementation isn't bi-endian... If you need to make a UFS file system > on amd64 for use on sparc64, use the makefs utility w/ the option -B big > to create it... > > Just ran into the same issue on an EdgeRouter Lite, which is a big > endian MIPS64 machine... > > Though I'm a bit surprized that it happens w/ ZFS as ZFS is suppose > to support either endianness automaticly.. Did you try this on raw > disks? > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > From owner-freebsd-sparc64@freebsd.org Sat Oct 17 19:46:41 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B0565A17529 for ; Sat, 17 Oct 2015 19:46:41 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 948EAEB for ; Sat, 17 Oct 2015 19:46:41 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t9HJkeQH066176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Oct 2015 12:46:40 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t9HJkeuD066175; Sat, 17 Oct 2015 12:46:40 -0700 (PDT) (envelope-from jmg) Date: Sat, 17 Oct 2015 12:46:40 -0700 From: John-Mark Gurney To: Vasile Buruiana Cc: freebsd-sparc64@freebsd.org Subject: Re: UFS mount failure - disk slice created on and64, unable to mount on sparc64 Message-ID: <20151017194640.GA65715@funkthat.com> References: <20151017184425.GR67524@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Sat, 17 Oct 2015 12:46:40 -0700 (PDT) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2015 19:46:41 -0000 Vasile Buruiana wrote this message on Sat, Oct 17, 2015 at 22:38 +0300: > Yesm I played with a harddisk connected via IDE to the sun and later > to the laptop via USB-to-IDE adapter. Currently I'm trying to > buildworkd+buildkernel on the sun using some contents of the /usr/obj > cross-compiled on the amd-64 laptop to speed up the process (that's > how I found the problem), so I'm writing these from my memory: > > This happened on the SUN: > > gpart create -s mbr ada0 > gpart add -t freebsd ada0 > gpart create -s bsd ada0s1 > gpart add -s 1G -t freebsd-zfs ada0s1 > > newfs -U /dev/ada0s1 > > copy stuff, umount, invalid argument while attempting to mount on the laptop. Expected as the UFS file system is big endian, and tried to mount on a little endian machine.. > gpart create -s vtoc8 ada0 > gpart add -t freebsd ada0 > gpart create -s bsd da0s1 > gpart add -s 1G -t freebsd-zfs ada0s1 > newfs -U /dev/ada0s1 > > copy suff, unmount, again invalid argument while attempting to mount > on the laptop. same... > Same when creating on the laptop and mounting on the sun. > > When moving the harddisk from one unit to the other, at boot (or at > usb insert) the kernel reports: > g_dev_taste: make_dev_p() failed (gp->name=da0a, error=17) or ada0a Not sure about this.. asking on -current or -stable and -geom might get you more info on this.. > and many slices appear in /dev: > da0a > da0aa > da0ab > da0b > da0c > da0ca > da0cb > (or ada0s1a, ada0s1aa, ada0s1ab, ada0s1b, ada0s1bb, ada0s1c, ada0s1ca > on the sparc64....) > > and so on, same for mbr/vtoc8, same for bsd/zfs. > > These are some geom-relaed errors as I read on some other mailing > lists, so I tried to identify the problem by simplifying things until > I reduced everything to image file attached to md. > > The Sparc also ran a FreeBSD 6.1-release perfectly, the ufs mbr > partition could be mounted on a x86 for fsck or other maintenance with > absolutely no problems. Seems that the advances in technology are > still causing headaches in keeping the things simple. Hmm... Are you sure about this? iirc, there was a utility that you could run to switch the endianness of a UFS FS, could you have been using this utility? > I will try to makefs -B big on the amd64 but I doubt i will also be > able to mount it on the same machine. Correct, you will not be able to mount an FS created w/ -B big on the laptop as it will be the wrong endianness, but it will mount fine on the sparc64 system... > On 10/17/15, John-Mark Gurney wrote: > > Vasile Buruiana wrote this message on Sat, Oct 17, 2015 at 21:32 +0300: > >> Found a bug in FreeBSD 10.2. > >> An UFS disk slice created under sparc64 cannot be mounted under amd64. > >> And reverse: UFS disk slice created under amd64 cannot be mounted > >> under sparc64. This also happens with hard disks on both MBR and VTOC8 > >> partition schemes, on both UFS and ZFS filesystems. > > > > Sadly, this is due to the fact that sparc64 is big endian, and our UFS > > implementation isn't bi-endian... If you need to make a UFS file system > > on amd64 for use on sparc64, use the makefs utility w/ the option -B big > > to create it... > > > > Just ran into the same issue on an EdgeRouter Lite, which is a big > > endian MIPS64 machine... > > > > Though I'm a bit surprized that it happens w/ ZFS as ZFS is suppose > > to support either endianness automaticly.. Did you try this on raw > > disks? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."