Date: Tue, 26 May 2015 13:09:53 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= <Trond.Endrestol@fagskolen.gjovik.no> To: rank1seeker@gmail.com Cc: hackers@freebsd.org Subject: Re: dumpfs incorrectly displays ufsid Message-ID: <alpine.BSF.2.20.1505261307580.12925@mail.fig.ol.no> In-Reply-To: <20150526123126.00003bab@gmail.com> References: <20150526123126.00003bab@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 26 May 2015 12:31+0200, rank1seeker@gmail.com wrote: > I've reported this at REL 8.2, long ago at May 2011 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=156908 > > Now at 10.1-RELEASE-p10 #0 r282952 i386 > > This happens, ONLY when first chars are 0 (zeros) in second pair of 8 > chars, in which case dumpfs, ommits them. > I.e; For: > /dev/ufsid/3b9aca0000000001 > > # dumpfs ada0s1h | head -2 > magic 19540119 (UFS2) time Sun Sep 9 03:46:40 2001 > superblock location 65536 id [ 3b9aca00 1 ] > > Problem is in '[ 3b9aca00 1 ]' If you apply this patch, then the case for UFS2 is treated similar to the case for UFS1: Index: sbin/dumpfs/dumpfs.c =================================================================== --- sbin/dumpfs/dumpfs.c (revision 283516) +++ sbin/dumpfs/dumpfs.c (working copy) @@ -165,7 +165,7 @@ fstime = afs.fs_time; printf("magic\t%x (UFS2)\ttime\t%s", afs.fs_magic, ctime(&fstime)); - printf("superblock location\t%jd\tid\t[ %x %x ]\n", + printf("superblock location\t%jd\tid\t[ %08x %08x ]\n", (intmax_t)afs.fs_sblockloc, afs.fs_id[0], afs.fs_id[1]); printf("ncg\t%d\tsize\t%jd\tblocks\t%jd\n", afs.fs_ncg, (intmax_t)fssize, (intmax_t)afs.fs_dsize); -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-hackers@FreeBSD.ORG Tue May 26 12:35:14 2015 Return-Path: <owner-freebsd-hackers@FreeBSD.ORG> Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4E44C829 for <freebsd-hackers@freebsd.org>; Tue, 26 May 2015 12:35:14 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::103]) by mx1.freebsd.org (Postfix) with ESMTP id 0AE8E654 for <freebsd-hackers@freebsd.org>; Tue, 26 May 2015 12:35:14 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [192.168.2.2] (unknown [166.199.173.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id A7FCD2FCC3 for <freebsd-hackers@freebsd.org>; Tue, 26 May 2015 12:35:11 +0000 (UTC) User-Agent: K-9 Mail for blackphone In-Reply-To: <5560F743.9000507@metricspace.net> References: <5560F4FE.4030502@metricspace.net> <5560F743.9000507@metricspace.net> MIME-Version: 1.0 Subject: Re: EFI ZFS loader successful load and boot From: Eric McCorkle <eric@metricspace.net> Date: Tue, 26 May 2015 08:34:48 -0400 To: freebsd-hackers@freebsd.org Message-ID: <7CD9D028-8BCE-4361-966B-140642BAE341@metricspace.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD <freebsd-hackers.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-hackers>, <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers/>; List-Post: <mailto:freebsd-hackers@freebsd.org> List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe> X-List-Received-Date: Tue, 26 May 2015 12:35:14 -0000 Updates: with a new kernel, and the vt terminal, this works fine. Unfortunately, the patch doesn't seem to work with a buildworld build (I was doing make from within the directories). This is related to a hack I do of copying zfs.c into the efi loader directory so it can be built with fPIC. The build system seems to get tripped up in mkdep as a result. Could someone with more knowledge of the build system give me some pointers here? Otherwise, is all set for testing. On May 23, 2015 5:55:15 PM EDT, Eric McCorkle <eric@metricspace.net> wrote: >One thing I forgot to mention here, my kernel is severely out of date, >as around October of last year, the blank screen on resume issue showed >up. > >I'll try updating to the latest and see if that helps. > >On 05/23/2015 05:45 PM, Eric McCorkle wrote: > >> There is also one other issue, which I think is the fault of my >hardware... >> >> When I boot a kernel in EFI mode, it prints info about the EFI >console, >> then the screen freezes. However, I can tell that the kernel and OS >> finish booting, because functions like suspend-on-lid-close and the >> power button work as normal after a while. However, when waking from >> suspend, the screen is just blank. >> >> This resembles an issue I've had with this particular laptop, which >I've >> reported before on the ACPI list. Given this as well as basic common >> sense, I think it's extremely unlikely that this issue arises as a >> result of my modifications to loader. >> >> If anyone out there has a ZFS-based system and can confirm or deny >this, >> that would be extremely useful information. >> >> >> Thanks, >> Eric >> -- Sent from my Blackphone with K-9 Mail. Please excuse my brevity. From owner-freebsd-hackers@FreeBSD.ORG Tue May 26 13:09:00 2015 Return-Path: <owner-freebsd-hackers@FreeBSD.ORG> Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9EFBE306; Tue, 26 May 2015 13:09:00 +0000 (UTC) (envelope-from ps06756@gmail.com) Received: from mail-vn0-x22d.google.com (mail-vn0-x22d.google.com [IPv6:2607:f8b0:400c:c0f::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 710D5E19; Tue, 26 May 2015 13:09:00 +0000 (UTC) (envelope-from ps06756@gmail.com) Received: by vnbf62 with SMTP id f62so7101688vnb.7; Tue, 26 May 2015 06:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+7rD3dusRMefAzKPe6ZtOydN4B6dvaJdSNOnOXd/LAg=; b=OqV1uylC8MjZuLaANvWYxx7qcylnMxjJtM74q9HS/zEv8VAOlX270rKpAqh4lldu0N 6TtpHlfvVy57m2oDOtuvar81Xe/mq1YpFHfhhjKjLepO+OkuvyuubBJ22Z4mH5eo7RTZ ezAeF3NgFzuv9Ynz4Wl5NFidSQA6OpjzGfqy1tBTxkDnoxXkMh9SAtKVs/dz7AzDE/Nf S0TsB96SYfvVZGnSVzs0Mkkf0uknIZHBPWcPa0l/MB8HEInWofAa7l3TGLZU491BQn7h F7AsNLeFMPHQys3Boky/4JNhA6sSX+TDnocSFQvbqjlIH4rqBTD35eqDUtZptH0ISs5z eQfQ== X-Received: by 10.52.77.69 with SMTP id q5mr31242019vdw.29.1432645739448; Tue, 26 May 2015 06:08:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.185.134 with HTTP; Tue, 26 May 2015 06:08:39 -0700 (PDT) In-Reply-To: <1432570038.1200.41.camel@freebsd.org> References: <CAGf2gkNuO6b71pDhenZdyyRQPUtGCDn8UTyVrAwu0_TimKcMFg@mail.gmail.com> <1432570038.1200.41.camel@freebsd.org> From: Pratik Singhal <ps06756@gmail.com> Date: Tue, 26 May 2015 18:38:39 +0530 Message-ID: <CAGf2gkOqXYaWvL_G0Ja8FRhxwF18sF8MO=FvRkbYmBC0SNba_A@mail.gmail.com> Subject: Re: Convert virtual address to physical address To: Ian Lepore <ian@freebsd.org> Cc: freebsd-hackers <freebsd-hackers@freebsd.org> Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD <freebsd-hackers.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-hackers>, <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers/>; List-Post: <mailto:freebsd-hackers@freebsd.org> List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe> X-List-Received-Date: Tue, 26 May 2015 13:09:00 -0000 Sir, Thanks for the help. I was missing the busdma 9 part and was passing physical address directly to the hardware. I'll look into the busdma interface of the kernel and use it instead. On Mon, May 25, 2015 at 9:37 PM, Ian Lepore <ian@freebsd.org> wrote: > On Mon, 2015-05-25 at 19:16 +0530, Pratik Singhal wrote: > > I need to convert a kernel virtual address to physical address. To do > that, > > as far as I know, we have 2 macros :- > > > > vtophys :- In sys/arm/include/pmap.h > > VTOP :- In sys/boot/i386/libi386/amd64_tramp.S > > > > Since, I am working on arm kernel with ARM_NEW_PMAP option, I am using > > vtophys macro by including the pmap.h file. > > > > Now, if I compile the kernel after including the pmap.h file, I am > getting > > the error :- > > > > error: field has incomplete type 'struct pmap_statistics' > > struct pmap_statistics pm_stats; /* pmap statictics */ > > ^ > > ./machine/pmap-v6.h:127:9: note: forward declaration of 'struct > > pmap_statistics' > > struct pmap_statistics pm_stats; /* pmap statictics */ > > > > How, should I resolve this error ? Or is there some other way to convert > > virtual address to physical address for arm kernel ? > > IMO, almost any question that begins with "I need to convert a virtual > address to physical" is the wrong question to be asking. > > The reason you typically need physical addresses is to hand them to some > piece of hardware to act on. You can't do that properly using > vtophys(), you'll have cache coherency problems when the hardware > touches the memory. The busdma family of functions does the right thing. > > If it's memory-mapped registers you're accessing rather than ram, you > probably need bus_space_map() to create a proper device-memory mapping > for it. > > -- Ian > > > -- Regards, Pratik Singhal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.20.1505261307580.12925>