From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 14 08:50:55 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A7964E5D; Sun, 14 Sep 2014 08:50:55 +0000 (UTC) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5F31B905; Sun, 14 Sep 2014 08:50:55 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id jd19so1765589oac.27 for ; Sun, 14 Sep 2014 01:50:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=PSNr+X4nHItT3ZwxdYrqZS0+47AdFKjkw5mrMOmCwcE=; b=k2yjP/q+8dbzq01rMzaO3Cml9/gnxfG3JPqiIRdeHrdKl2ZTB1hYnAoDBWWbETIUu1 XxnnbNNAi9G4AN+CIaFDrY8toSq6cAtFZjB591KGU6gU9Dl5vnyno2Twql+DXiZt3uzJ A5baf/8ZSZ0/A8hgNj3/1mSeHqZQsxAMlgtuk9diSUIuSkBQGH9cAqLtloFzMHYjNMuu f16hkf64c0oQDmjJVh0mnVy0fCn8CdRvXKFu4SjxzkesZ6W1clmzAmJ0wGsh97biAA+k 4ETfufYh4f4b+Ml+xsKSFljea4NU1nDbgcjwKsFOdYcObc10FxeGh4aPSndfUBr41Tmr IrpQ== MIME-Version: 1.0 X-Received: by 10.60.175.166 with SMTP id cb6mr798656oec.64.1410684654665; Sun, 14 Sep 2014 01:50:54 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.202.58.196 with HTTP; Sun, 14 Sep 2014 01:50:54 -0700 (PDT) In-Reply-To: References: Date: Sun, 14 Sep 2014 10:50:54 +0200 X-Google-Sender-Auth: JpCwGup7TAwpTDwzYLDzSB25DEA Message-ID: Subject: Re: FreeBSD and WiDi / Miracast / WiFi Direct HDMI streaming From: CeDeROM To: Waitman Gobble Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , FreeBSD Questions Mailing List X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 08:50:55 -0000 On Sun, Sep 14, 2014 at 9:12 AM, Waitman Gobble wrote: >> yeah. >> configure: error: Package requirements (libudev libsystemd >= 213) were >> not met: > > ... with some intensive hacking we can maybe make it work :) > it's a start anyway. getting rid of the systemd stuff and switching logging > functions to syslog(3) miracled builds (but seriously no doubt hours more > work involved to do something useful). :) this is just really a simple shell > around the important guts. Cool :-) Maybe some layer could be added to make it OS independent? When I finish patching u3g module to make 3g modem work on my new machine I'll get into it :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 14 13:40:22 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD497A8 for ; Sun, 14 Sep 2014 13:40:22 +0000 (UTC) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::103]) by mx1.freebsd.org (Postfix) with ESMTP id A57BA835 for ; Sun, 14 Sep 2014 13:40:22 +0000 (UTC) Received: from [172.16.1.182] (unknown [172.16.1.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id D18FC2F44C for ; Sun, 14 Sep 2014 13:40:21 +0000 (UTC) Message-ID: <54159AC5.1010800@metricspace.net> Date: Sun, 14 Sep 2014 09:40:21 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "freebsd-hackers@freebsd.org" Subject: Resuming old EFI project Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 13:40:22 -0000 Hello everyone, About two years ago, I was working on a project to try and finish the EFI support for AMD64. Unfortunately, I had to abandon the project due to family illness and a job search. At this point, I'm in a position to pick that project back up as a side project (I also have better hardware now ;) It seems everything in sys/boot/amd64/efi is pretty much unchanged. One thing that's changed things quite a bit, though, is the switch to clang. When I was working on it before, there was a custom linker script that got used to produce loader as a PE binary (EFI uses the PE format and win32 ABI). However, that script seemed to produce bad offsets when using clang. On the other hand, clang can cross-compile to the win32 ABI (by giving it -target x86_64-unknown-win32). This does have some additional advantages; win32 has slightly different conventions, and I remember reading about an issue someone was having because of a stack alignment issue when they were using a linker script solution. So the thing to do might be to cross-compile loader and its dependencies (stand, ficl, if I recall). The issue here is that you'd potentially be producing two sets of libraries: one with the standard ABI and one with the win32 ABI. Worth noting: there's supposedly a way to get clang to produce "object" files that are actually LLVM bitcode; that could potentially avoid generating two sets of object files. I welcome any suggestions or comments. From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 14 17:37:32 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B0E01F08 for ; Sun, 14 Sep 2014 17:37:32 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 902F2FC2 for ; Sun, 14 Sep 2014 17:37:32 +0000 (UTC) Received: from [192.168.200.200] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 4C03F1928A7; Sun, 14 Sep 2014 17:37:31 +0000 (UTC) Subject: Re: Resuming old EFI project From: Sean Bruno Reply-To: sbruno@freebsd.org To: Eric McCorkle In-Reply-To: <54159AC5.1010800@metricspace.net> References: <54159AC5.1010800@metricspace.net> Content-Type: text/plain; charset="us-ascii" Date: Sun, 14 Sep 2014 10:37:30 -0700 Message-ID: <1410716250.4174.3.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 17:37:32 -0000 On Sun, 2014-09-14 at 09:40 -0400, Eric McCorkle wrote: > Hello everyone, > > About two years ago, I was working on a project to try and finish the > EFI support for AMD64. Unfortunately, I had to abandon the project due > to family illness and a job search. At this point, I'm in a position to > pick that project back up as a side project (I also have better hardware > now ;) > > It seems everything in sys/boot/amd64/efi is pretty much unchanged. One > thing that's changed things quite a bit, though, is the switch to clang. > > When I was working on it before, there was a custom linker script that > got used to produce loader as a PE binary (EFI uses the PE format and > win32 ABI). However, that script seemed to produce bad offsets when > using clang. > > On the other hand, clang can cross-compile to the win32 ABI (by giving > it -target x86_64-unknown-win32). This does have some additional > advantages; win32 has slightly different conventions, and I remember > reading about an issue someone was having because of a stack alignment > issue when they were using a linker script solution. So the thing to do > might be to cross-compile loader and its dependencies (stand, ficl, if I > recall). The issue here is that you'd potentially be producing two sets > of libraries: one with the standard ABI and one with the win32 ABI. > Worth noting: there's supposedly a way to get clang to produce "object" > files that are actually LLVM bitcode; that could potentially avoid > generating two sets of object files. There's been quite a bit of work in this space and people are already booting their laptops and such from the UEFI enabled boot loader. What specifically are you looking to work on? sean https://wiki.freebsd.org/UEFI From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 14 20:05:27 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0AA13C18; Sun, 14 Sep 2014 20:05:27 +0000 (UTC) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::103]) by mx1.freebsd.org (Postfix) with ESMTP id D5770FFA; Sun, 14 Sep 2014 20:05:26 +0000 (UTC) Received: from [172.16.1.182] (unknown [172.16.1.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id C1ED82F79E; Sun, 14 Sep 2014 20:05:25 +0000 (UTC) Message-ID: <5415F505.3070206@metricspace.net> Date: Sun, 14 Sep 2014 16:05:25 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: sbruno@freebsd.org Subject: Re: Resuming old EFI project References: <54159AC5.1010800@metricspace.net> <1410716250.4174.3.camel@bruno> In-Reply-To: <1410716250.4174.3.camel@bruno> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 20:05:27 -0000 On 09/14/2014 13:37, Sean Bruno wrote: > There's been quite a bit of work in this space and people are already > booting their laptops and such from the UEFI enabled boot loader. That's excellent. I had assumed nobody had worked on it. > What specifically are you looking to work on? > Well, I had been trying to get it to boot on a mac EFI implementation as well. There's some funny things that have to happen there (notably, an HFS+ image). I know there's also some secure booting features in EFI (my new laptop supports them), not sure if anyone's done anything with them. From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 15 00:16:50 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41D288FF; Mon, 15 Sep 2014 00:16:50 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 27344B5E; Mon, 15 Sep 2014 00:16:50 +0000 (UTC) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s8F0GfGX020032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 14 Sep 2014 17:16:42 -0700 Message-ID: <541604F1.9010402@freebsd.org> Date: Sun, 14 Sep 2014 14:13:21 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Eric McCorkle , sbruno@freebsd.org Subject: Re: Resuming old EFI project References: <54159AC5.1010800@metricspace.net> <1410716250.4174.3.camel@bruno> <5415F505.3070206@metricspace.net> In-Reply-To: <5415F505.3070206@metricspace.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVbSd0KG+goNSrk6VZGvfrFb2crAcMSGAyFn5hKcNaLes8SSlAk6EQTDe/dL11/ebz7tJtFaDw4cqyvdsSBaD0QQb2ujJvKJw54= X-Sonic-ID: C;qJNNkW085BGWFTZXoK8kYw== M;IB7mkW085BGWFTZXoK8kYw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 00:16:50 -0000 On 09/14/14 13:05, Eric McCorkle wrote: > On 09/14/2014 13:37, Sean Bruno wrote: >> There's been quite a bit of work in this space and people are already >> booting their laptops and such from the UEFI enabled boot loader. > > That's excellent. I had assumed nobody had worked on it. This will be part of 10.1, by the way. > >> What specifically are you looking to work on? >> > > Well, I had been trying to get it to boot on a mac EFI implementation > as well. There's some funny things that have to happen there > (notably, an HFS+ image). People seem to have had luck with our FAT32 EFI system partitions on macs so far, but this in general is one of the big missing bits: hunting down weird firmwares, testing them, and fixing them when they don't work. We also need the EFI boot1 both to (a) have a better algorithm for finding the right UFS partition to boot from and (b) learn how to boot from ZFS as well as UFS. > > I know there's also some secure booting features in EFI (my new laptop > supports them), not sure if anyone's done anything with them. > No one has done anything on this front yet, so far as I know. -Nathan From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 15 01:20:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61B4311A; Mon, 15 Sep 2014 01:20:11 +0000 (UTC) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1DA05FD3; Mon, 15 Sep 2014 01:20:11 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id lx4so3797163iec.19 for ; Sun, 14 Sep 2014 18:20:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=kqYgaojHDX9eJ2DRoCplN5fYT0pZ3qB1Ke6x7ttDiD0=; b=XIC3tjok1ga/d6dT8ydtuVI2LmUlZD8iRtXJ08BShtzMpwY1MYOODjwkRCl6+qONCx ISS2Mh5AGhQ1oSyo0w4Upoe5/kWfJQ3tnT8XYcIa0b5gd0PBI22SX+SmjF3mJH4TwPgU XSkYf3o5+ctfyQZvR6S87qwWqOCYa+BEX0ZXZQ/a98W2uPkN3btA5Z+8p1yoOIQc70k9 mX51Ps9i9vGQp60uSK+bVYrryFSjf8qF/QK38+5xcu+YW3jyFqdiNXa/ESVbak9vVyuT cQTvHvcb6xbSgC3CFVz3uSM2bzP6jagAj7KsOWCnGCiKQr6yo6lwJrpJyFf6hZDQRty1 aSuA== X-Received: by 10.42.227.10 with SMTP id iy10mr23061498icb.3.1410744010409; Sun, 14 Sep 2014 18:20:10 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.44.196 with HTTP; Sun, 14 Sep 2014 18:19:50 -0700 (PDT) In-Reply-To: <541604F1.9010402@freebsd.org> References: <54159AC5.1010800@metricspace.net> <1410716250.4174.3.camel@bruno> <5415F505.3070206@metricspace.net> <541604F1.9010402@freebsd.org> From: Ed Maste Date: Sun, 14 Sep 2014 21:19:50 -0400 X-Google-Sender-Auth: 24UeZw0AxIFyrFjLp6hE8Iqmffk Message-ID: Subject: Re: Resuming old EFI project To: Nathan Whitehorn Content-Type: text/plain; charset=UTF-8 Cc: Eric McCorkle , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 01:20:11 -0000 >>> There's been quite a bit of work in this space and people are already >>> booting their laptops and such from the UEFI enabled boot loader. >> >> That's excellent. I had assumed nobody had worked on it. > > This will be part of 10.1, by the way. Yes, the basic support is already in 10.1 and UEFI-capable snapshots will be available throughout the beta and release candidate process. For 10.1 I think we'll provide separate conventional (BIOS-only) and dual-mode USB stick and CD images to avoid unexpected regressions. >> Well, I had been trying to get it to boot on a mac EFI implementation as >> well. There's some funny things that have to happen there (notably, an HFS+ >> image). The current code does work on MacBook Airs, with a caveat that the loader is not displayed (we don't force a switch to text mode). There is a patch in progress to address this which should arrive shortly. There is an additional issue that affects MacBook Pros which remains to be diagnosed: the system appears to hang immediately after the loader transfers control to the new kernel. >> I know there's also some secure booting features in EFI (my new laptop >> supports them), not sure if anyone's done anything with them. We had a plan for a very basic level of Secure Boot support using Matthew Garrett's shim loader. It relied on having Microsoft sign the shim, but that easy plan is no longer viable due to changes in Microsoft's policy for signing third-party UEFI software. It's definitely still on the roadmap, it just will take additional effort. -Ed From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 15 01:26:15 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E98D625C; Mon, 15 Sep 2014 01:26:13 +0000 (UTC) Date: Sun, 14 Sep 2014 21:26:10 -0400 From: Glen Barber To: Ed Maste Subject: Re: Resuming old EFI project Message-ID: <20140915012610.GL1198@hub.FreeBSD.org> References: <54159AC5.1010800@metricspace.net> <1410716250.4174.3.camel@bruno> <5415F505.3070206@metricspace.net> <541604F1.9010402@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pVdNWoWUH9QCMJqq" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Eric McCorkle , "freebsd-hackers@freebsd.org" , Nathan Whitehorn X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 01:26:15 -0000 --pVdNWoWUH9QCMJqq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 14, 2014 at 09:19:50PM -0400, Ed Maste wrote: > >>> There's been quite a bit of work in this space and people are already > >>> booting their laptops and such from the UEFI enabled boot loader. > >> > >> That's excellent. I had assumed nobody had worked on it. > > > > This will be part of 10.1, by the way. >=20 > Yes, the basic support is already in 10.1 and UEFI-capable snapshots > will be available throughout the beta and release candidate process. > For 10.1 I think we'll provide separate conventional (BIOS-only) and > dual-mode USB stick and CD images to avoid unexpected regressions. >=20 The final 10.1-RELEASE will also include dual-mode memstick images, as well as disc1 ISO images for amd64. The dual-mode memstick images are available for the -BETA1, the disc1 and dvd1 ISO images will be available for -BETA2. Glen --pVdNWoWUH9QCMJqq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUFkAyAAoJELls3eqvi17Q7UUP/27KByJ2PK0L/qeFCaCg9iRx UtRvusota99AOJl4Tab2w/yPgd4hI6N3Zff0v7QqGWPzd4OCI+d6IdjwSBEc1kSl CDTBnFhQPiWBzPtXMDrBzEmxTXTSxlTIpR0vo/hsC7Yah+XaWFUFABRwUE8biY00 K1dOXtLYpqEvXAxIBxiFrbrNGe1lz6QqBvpXfhUcxGNQp4ZnuvI34dfC9twJPuXF gorpoBTNpTMxjZJmeTQimOgcFiFoq9KKWFySUyS9p4oeaA4DPPfy9zQVY/59NrsZ IZrIXseDDsEne11f8CEbqDEBB4QWO+/fB7Vyx1bbGtyj9TkaUALPGRxKDbX2SoVz pI2YN2Mvfq6SWZBe7MVly9rp+DxATtlPzwfa5QSmn1TJPm410kzZuE+C6/r+GMHm hRnTmbKNXVoi4tE+wUNnOZEtAwojXdj8govQttgWEWn24Ki86W3gbGrLojOB6GJr yO+ROYGEOpiXQm9/ceCdKQ3ynNEF1/3Xlz6EM3hfWzNZLCKHu143kY15rckaBHCf fmSDF2SvDFVSddnX4U6ssHXKgcbmcMNFflUR5mcUYTzGBXQL7WdyuKDPxyvzomyr lZCD56Y0PhWwn2GVhO7novLynxPP2abtfwvUAbtmemeyAHd0H2UGdp5nBxFJbzu6 CAEa6HpAOFjEfRrTniGG =ST9a -----END PGP SIGNATURE----- --pVdNWoWUH9QCMJqq-- From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 15 10:17:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4B2DA8A5 for ; Mon, 15 Sep 2014 10:17:42 +0000 (UTC) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1EA6CBF8 for ; Mon, 15 Sep 2014 10:17:42 +0000 (UTC) Received: by mail-pd0-f172.google.com with SMTP id v10so6038232pde.3 for ; Mon, 15 Sep 2014 03:17:41 -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:content-transfer-encoding; bh=n3QmchMtVLKRO+ERzbNV0xPt8ekOAmcMF9YxZqmMqbA=; b=gVks4K/ZElM90O44FVr+E3ZsCZflPciqMZjcI6tQTITcNz0L5/uOCRRmHWAIzX/QJ5 8joaAV6IGtEmfFfVG+09WkWt1QBvSA9HP7IN+2TfjREG/0T/EEfuCKlUlTePO5bUCP+u b1mt4GPfPZTOsaCw9sG87XhAnA9AO84fcCHWERqIZDkGGgNv9GN0/eWlg1wSBbPZF9kR fhW0orMJ6HG2V6G+kCejeBD9YvqrYZ4lvb/jYwcVx/hms8TCDrZYehBGo19NDyEX2OfR zDjbT5qBkw+C+ozuY5jxbVxehAlmw2W7eGzbuKXBTaUZpuNo9jGfhq20ZzzdNRef4Wh0 kJJA== MIME-Version: 1.0 X-Received: by 10.70.131.231 with SMTP id op7mr19813962pdb.91.1410776261464; Mon, 15 Sep 2014 03:17:41 -0700 (PDT) Received: by 10.70.132.2 with HTTP; Mon, 15 Sep 2014 03:17:41 -0700 (PDT) In-Reply-To: References: <220565922.34288992.1410298180362.JavaMail.root@uoguelph.ca> Date: Mon, 15 Sep 2014 12:17:41 +0200 Message-ID: Subject: Re: Tool to access ZFS/NFSv4 alternate data streams on FreeBSD? From: Lionel Cons To: Simon Toedt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Freebsd hackers list , Richard Yao , Rick Macklem , Jordan Hubbard , Jan Bramkamp X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 10:17:42 -0000 On 12 September 2014 17:47, Simon Toedt wrote: > On Fri, Sep 12, 2014 at 2:24 AM, Lionel Cons w= rote: >> On 9 September 2014 23:29, Rick Macklem wrote: >>> Simon Toedt wrote: >>>> On Tue, Sep 9, 2014 at 1:47 PM, Rick Macklem >>>> wrote: >>>> > Jordan Hubbard wrote: >>>> >> Yep. I was just describing the experience that OS X went through >>>> >> in >>>> >> implementing extattrs / legacy resource fork support. To recap it >>>> >> very briefly: Having NFSv4 support extattrs (or even named >>>> >> streams, >>>> >> if you want to go that far) is the comparatively easy part. It=E2= =80=99s >>>> >> backing them up / copying them around that gets more involved, and >>>> >> if you can=E2=80=99t back up certain attributes then you=E2=80=99re= not likely to >>>> >> get anyone to want to use them, at which point the whole =E2=80=9Cs= haring=E2=80=9D >>>> >> aspect kind of takes a back seat. >>>> >> >>>> > Yep. I strongly suspect you are correct. >>>> > >>>> > The question then becomes: >>>> > - Do we wait and see if someone chooses to get around to doing all >>>> > the hard userland work. >>>> >>>> Solaris tools already have support for this. Also AT&T AST from David >>>> Korn have support for O_XATTR, too. >>>> >>> Hopefully others will correct me if I have this incorrect, but I though= t >>> CDDL code could only be used for optional components of FreeBSD? >>> I suspect tar and friends are considered core components and that code >>> for this would have to be written by someone (ie. couldn't use CDDL cod= e?). >>> (I'm assuming that these tools are in OpenSolaris.) >> >> I don't think you FreeBSD should *copy* the code. But it can be used >> for reference how the extended tar headers for filesystem forks should >> look like. That's all. >> >>> >>> Be aware that most of FreeBSD's development is done by volunteers in th= eir >>> spare time, so I have no idea if someone is interested in doing this. >> >> If anyone can get the kernel parts I think we can sponsor someone to >> do the userland work. > > How much money would CERN offer? :) > > Simon Depends. First I need to have more support (2nd funding pillar) and then write a proposal. Short: Paperwork. Long: More paperwork. But given the number of projects here which rely on O_XATTR there isn't a way around it so funding should be easy to obtain. Lionel From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 15 12:09:18 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 02F4C78E; Mon, 15 Sep 2014 12:09:18 +0000 (UTC) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::103]) by mx1.freebsd.org (Postfix) with ESMTP id CB82199A; Mon, 15 Sep 2014 12:09:17 +0000 (UTC) Received: from [172.16.1.182] (unknown [172.16.1.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 8DCA22FF10; Mon, 15 Sep 2014 12:09:16 +0000 (UTC) Message-ID: <5416D6EB.7020803@metricspace.net> Date: Mon, 15 Sep 2014 08:09:15 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Nathan Whitehorn , sbruno@freebsd.org Subject: Re: Resuming old EFI project References: <54159AC5.1010800@metricspace.net> <1410716250.4174.3.camel@bruno> <5415F505.3070206@metricspace.net> <541604F1.9010402@freebsd.org> In-Reply-To: <541604F1.9010402@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 12:09:18 -0000 On 09/14/2014 17:13, Nathan Whitehorn wrote: >>> What specifically are you looking to work on? >>> >> >> Well, I had been trying to get it to boot on a mac EFI implementation >> as well. There's some funny things that have to happen there >> (notably, an HFS+ image). > > People seem to have had luck with our FAT32 EFI system partitions on > macs so far, but this in general is one of the big missing bits: hunting > down weird firmwares, testing them, and fixing them when they don't > work. We also need the EFI boot1 both to (a) have a better algorithm for > finding the right UFS partition to boot from and (b) learn how to boot > from ZFS as well as UFS. I have a 100% ZFS system, so the current boot block doesn't work for me (though I can tell it's being loaded and run). GELI should probably be added to that list as well... I assume the best thing would be to link in the ZFS code? Or would it be better to install loader into the system partition as well? From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 15 15:24:09 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4AC8919F; Mon, 15 Sep 2014 15:24:09 +0000 (UTC) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E59B9130; Mon, 15 Sep 2014 15:24:08 +0000 (UTC) Received: by mail-ob0-f170.google.com with SMTP id uy5so2637173obc.1 for ; Mon, 15 Sep 2014 08:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=DlP/13RcYpJk/DQBdbT1nCy2gJKMlkvLy6ah2dvurPw=; b=Nk5b6bmCQ/AiQEgULn0iUcb1viUD4CsCHH93QtUk6sVsDkwhbVtUOSoynP9iYl6ctV 4frSfRgNeveeC7IK//me5jMQfUR6DdDohx9oOoqKlwhGB0Rf3r+97uZ5Mp97uAMNqx/I Ss97SqhKczlfqJv7JyXltRwjOIVJVqfEo5kqRRZHRQxwSflwPk70c/gLRbJaesjWIFe0 RVF9dIx8Rmas0wdQtudszcqI9LVAHAJzSBKfBKFSz1IZn9TUQDCPOdDddda38fgE8T9/ soysDR88/zgZG0rH1/ZQ7tOvKg7wKasBOj/aaQZJjQ5M9XtPeoWemmB+1vH/PR9GsFbZ PPSQ== MIME-Version: 1.0 X-Received: by 10.60.142.165 with SMTP id rx5mr13405140oeb.5.1410794217271; Mon, 15 Sep 2014 08:16:57 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.202.58.196 with HTTP; Mon, 15 Sep 2014 08:16:57 -0700 (PDT) Date: Mon, 15 Sep 2014 17:16:57 +0200 X-Google-Sender-Auth: BvFx9GV_CZdR-X5uX85LvmnQuTI Message-ID: Subject: U3G QDL firmware loader for GOBI2000/HP_UN2420 MiniPCI/USB 3G/GPS From: CeDeROM To: FreeBSD Questions Mailing List , "freebsd-hackers@freebsd.org" , freebsd-net@freebsd.org, "freebsd-usb@FreeBSD.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 15:24:09 -0000 Hello world! :-) I have changed my machine, there is a built-in GOBI2000 / HP UN2420 3G/GPS module installable as MiniPCI card and visible as USB device. I have added its VID/PID to the usbdevs and u3g.c module, so after recompilation it gets recognised by u3g module and apropriate /dev/cuaU* device shows up.. The problem is that device does not store firmware inside non-volatile memory, so user needs to upload it after power-on. I have the firmware files. I can test modem with success after reboot from Win7 which uploads firmware into device. Still, I need to upload the firmware somehow on my FreeBSD. The upload protocol is QDL and /dev/cuaU0 shows up waiting for command. Which utility can I use to upload firmware with QDL? I have seen one post [1] regarding this problem in the past but the QDL utility was not named explicitly. Any hints welcome! :-) Tomek [1] http://lists.freebsd.org/pipermail/freebsd-usb/2010-October/009384.html -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 15 15:53:29 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D24F34E for ; Mon, 15 Sep 2014 15:53:29 +0000 (UTC) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B871A7CE for ; Mon, 15 Sep 2014 15:53:28 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id n3so4527669wiv.7 for ; Mon, 15 Sep 2014 08:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=nnD1QjZJ0ee6u3iDHMpTYLON/WHuFTPsRdN1Vt9MRvQ=; b=PcFYFbuDQQYOj9rC5IVolXbF89MvJhrJUgOz3KMiTJxKpcfmu/zEvgvVaNWcPTnQ1o cfRqlSWvc29hS0vAEZRoKHZJIZ2jOHpRPSbKn6giCaCedPt0CV9ou7CKfP/Go9cfspJw dTvGQDI00nxYMFI8I5JW+X9uOmgmm75rIr1koqI4g1QL+IJCfptfoAE6uJzguVGenD3e eyjiGydvmyeUvLbcOxcnHlLPyPY+lcgaerUFEcc0QDJGR/zKZy1MQwLYO7oybpGqoqFM zOEN2WT7NWsUjofcBldeFl054FoKe4V9qeVMIr/bYG2IQFvEVTE6Xsl6H+yfIh6vjt1c wgcQ== X-Received: by 10.180.231.3 with SMTP id tc3mr13217872wic.18.1410796406890; Mon, 15 Sep 2014 08:53:26 -0700 (PDT) Received: from gumby.homeunix.com ([94.195.197.245]) by mx.google.com with ESMTPSA id lv7sm12105571wic.16.2014.09.15.08.53.25 for (version=SSLv3 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Sep 2014 08:53:26 -0700 (PDT) Date: Mon, 15 Sep 2014 16:53:23 +0100 From: RW To: freebsd-hackers@freebsd.org Subject: Re: openssl with aes-in or padlock Message-ID: <20140915165323.1c951385@gumby.homeunix.com> In-Reply-To: <20140912004541.GQ82175@funkthat.com> References: <20140911180258.GN82175@funkthat.com> <20140912004541.GQ82175@funkthat.com> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 15:53:29 -0000 On Thu, 11 Sep 2014 17:45:41 -0700 John-Mark Gurney wrote: > Wojciech Puchar wrote this message on Thu, Sep 11, 2014 at 23:33 > +0200: > > >GEOM_ELI: Encryption: AES-XTS 256 > > >GEOM_ELI: Crypto: hardware > > > > yes i have this. contrary to what you say - both AES-XTC and > > AES-CBC gets MUCH faster with AES-NI. > > Well, AES-NI CBC may be faster w/ AES-NI, but it's not as fast as > using another mode... AES-XTS should be many times faster than > CBC... GELI was around for a long time before it had AES-XTS, and I presume it uses its kernel threads to process multiple sectors in parallel. In that case XTS and CBC would both get a similar benefit from SMP. From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 15 16:33:38 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC21D3A3; Mon, 15 Sep 2014 16:33:38 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (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 A071EC7E; Mon, 15 Sep 2014 16:33:38 +0000 (UTC) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s8FGXaSn021858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 15 Sep 2014 09:33:36 -0700 Message-ID: <541714E0.90609@freebsd.org> Date: Mon, 15 Sep 2014 09:33:36 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Eric McCorkle , sbruno@freebsd.org Subject: Re: Resuming old EFI project References: <54159AC5.1010800@metricspace.net> <1410716250.4174.3.camel@bruno> <5415F505.3070206@metricspace.net> <541604F1.9010402@freebsd.org> <5416D6EB.7020803@metricspace.net> In-Reply-To: <5416D6EB.7020803@metricspace.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVb/AmNlHxuSn/CWKsM0HN22lw71MnB3TyWVrQK0VexdTLGg+dwSpR2hyj4h0jV8LXi6r8VhwyjpOdpLgKZkXFbuLwoaEV+dagQ= X-Sonic-ID: C;ZEBqCvY85BGqiQDu5Qupew== M;5gC+CvY85BGqiQDu5Qupew== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 16:33:38 -0000 On 09/15/14 05:09, Eric McCorkle wrote: > On 09/14/2014 17:13, Nathan Whitehorn wrote: > >>>> What specifically are you looking to work on? >>>> >>> >>> Well, I had been trying to get it to boot on a mac EFI implementation >>> as well. There's some funny things that have to happen there >>> (notably, an HFS+ image). >> >> People seem to have had luck with our FAT32 EFI system partitions on >> macs so far, but this in general is one of the big missing bits: hunting >> down weird firmwares, testing them, and fixing them when they don't >> work. We also need the EFI boot1 both to (a) have a better algorithm for >> finding the right UFS partition to boot from and (b) learn how to boot >> from ZFS as well as UFS. > > I have a 100% ZFS system, so the current boot block doesn't work for > me (though I can tell it's being loaded and run). GELI should > probably be added to that list as well... > > I assume the best thing would be to link in the ZFS code? Or would it > be better to install loader into the system partition as well? > It's hard to integrate having loader on the ESP with the way loader and installworld work, so better to keep it on UFS/ZFS. The sparc64 boot1, on which the UEFI boot1 is based, has ZFS support already, so that's the place to look I think. -Nathan From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 16 02:03:59 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7ED6A9E; Tue, 16 Sep 2014 02:03:59 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 4425DFDC; Tue, 16 Sep 2014 02:03:58 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id C65B820E7088D; Tue, 16 Sep 2014 02:03:56 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.2 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,RDNS_DYNAMIC,STOX_REPLY_TYPE, STOX_REPLY_TYPE_WITHOUT_QUOTES autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTP id 255E220E70886; Tue, 16 Sep 2014 02:03:55 +0000 (UTC) Message-ID: From: "Steven Hartland" To: Subject: ZFS SET_ERROR dtrace probe possible under FreeBSD? Date: Tue, 16 Sep 2014 03:03:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 02:03:59 -0000 The following commit added SET_ERROR dtrace probes to illumos https://github.com/illumos/illumos-gate/commit/be6fd75 Now we have all the SET_ERROR calls but the FreeBSD's ZFS implementation but our SET_ERROR in sys/cddl/compat/opensolaris/sys/sdt.h is simply: #define SET_ERROR(err) (err) I tried using the illumos version but that resulted being unable to mount ZFS root, so clearly not right. /* * the set-error SDT probe is extra static, in that we declare its fake * function literally, rather than with the DTRACE_PROBE1() macro. This is * necessary so that SET_ERROR() can evaluate to a value, which wouldn't * be possible if it required multiple statements (to declare the function * and then call it). * * SET_ERROR() uses the comma operator so that it can be used without much * additional code. For example, "return (EINVAL);" becomes * "return (SET_ERROR(EINVAL));". Note that the argument will be evaluated * twice, so it should not have side effects (e.g. something like: * "return (SET_ERROR(log_error(EINVAL, info)));" would log the error twice). */ extern void __dtrace_probe_set__error(uintptr_t); #define SET_ERROR(err) (__dtrace_probe_set__error(err), err) For those that know the the ins and outs of our dtrace is it possible for us to add support for this trace point? Regards Steve From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 16 03:13:22 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB6D08B0; Tue, 16 Sep 2014 03:13:22 +0000 (UTC) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A00D08BF; Tue, 16 Sep 2014 03:13:22 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id fp1so7708247pdb.1 for ; Mon, 15 Sep 2014 20:13:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=QMMYsCFVjzcAGS1Fm8gSJdKEH2u7fklKQcul7IXUo2Y=; b=fZ/ElARs9m3gPErSxdzyIGTs1Krv0dTE/+bAgv4zZ5GLnQxK7l7o32EFYUY1AJZQyG Mz4GJBC3k+ugUFTlSdgvn9E2LZ3NN2YjCwk91XlphC3wkNmURbGsfCu38KuOxf+shlAf XzraPHtvtzi87Hl+eQ62k2WyLasF2rScW6mC4YoBqlUQBY2sZxivavRf+Ycy8xIxNVpo gyjPTz4gVjq1mw3bPdwE/H4EIZ7Xy9+M18KxpT1/32sbH3erj7nsaU90pEw6j4jvqYZa +hmb3ACrKCK4OPBi5iv2vmtguhKXifKAWwp4BRIQ44hCtPRb8DwFQC4fH7FZi3xnUCy2 cjcQ== X-Received: by 10.66.182.227 with SMTP id eh3mr45375966pac.68.1410837202191; Mon, 15 Sep 2014 20:13:22 -0700 (PDT) Received: from charmander.picturesperfect.net (c-67-182-131-225.hsd1.wa.comcast.net. [67.182.131.225]) by mx.google.com with ESMTPSA id wc5sm13182102pab.2.2014.09.15.20.13.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Sep 2014 20:13:21 -0700 (PDT) Sender: Mark Johnston Date: Mon, 15 Sep 2014 20:13:19 -0700 From: Mark Johnston To: Matthew Ahrens Subject: Re: ZFS SET_ERROR dtrace probe possible under FreeBSD? Message-ID: <20140916031318.GB26720@charmander.picturesperfect.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Steven Hartland , hackers@freebsd.org, freebsd-dtrace@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 03:13:23 -0000 On Mon, Sep 15, 2014 at 07:59:50PM -0700, Matthew Ahrens wrote: > Disclaimer: I'm not an expert in FreeBSD dtrace. > > It looks like the FreeBSD kernel uses these declaration for kernel SDT > probes, in sdt.h: > > 333 #*define* > DTRACE_PROBE1 (name > , > type0 , > arg0 ) \334 > DTRACE_PROBE_IMPL_START > (name > , arg0 > , 0, > 0, 0, 0) \335 > SDT_PROBE_ARGTYPE > (sdt > , , > , name , > 0, #type0 , > NULL ); \336 > DTRACE_PROBE_IMPL_END > > > > 324 #*define* DTRACE_PROBE_IMPL_START > (name > , arg0 > , arg1 > , arg2 > , arg3 > , arg4 > ) *do* > { \325 *static* > SDT_PROBE_DEFINE > (sdt > , , > , name ); > \326 SDT_PROBE > (sdt > , , > , name , > arg0 , > arg1 , > arg2 , > arg3 , > arg4 );327 > #*define* > DTRACE_PROBE_IMPL_END > } > *while* (0) > > > 163 #*define* > SDT_PROBE (prov > , > mod , > func , > name , > arg0 , > arg1 , > arg2 , > arg3 , > arg4 ) *do* > { \164 *if* > (sdt_ ##prov > ##_##mod > ##_##func > ##_##name > ->id > ) \165 > (*sdt_probe_func > )(sdt_ > ##prov > ##_##mod > ##_##func > ##_##name > ->id > , \166 > > (uintptr_t ) > arg0 , > (uintptr_t ) > arg1 , > (uintptr_t ) > arg2 , \167 > > (uintptr_t ) > arg3 , > (uintptr_t ) > arg4 ); \168 > } > *while* (0) > > > To do the equivalent "extra static" magic, you will need to expand out the > DTRACE_PROBE1 macro. I think it should look something like: > > SDT_PROBE_DEFINE1(sdt, zfs, , set__error, "int"); > > #define SET_ERROR(err) \ > ((sdt_sdt_zfs__set__error->id && \ > (*sdt_probe_func)(sdt_sdt_zfs__set__error->id, (uintptr_t)err, 0, 0, 0, > 0)), \ > err) I think it would need to be SDT_PROBE_DECLARE(sdt, , , set__error); #define SET_ERROR(err) ... in the compat sdt.h, and then kern_dtrace.c or so would contain SDT_PROBE_DEFINE1(sdt, , , set__error, "int"); Note that the module shouldn't be hard-coded - it'll be filled in when the probes are created by the SDT code. -Mark > > Note that SET_ERROR is an expansion of SDT_PROBE, but rewritten to be a > single statement, so that we can do the same trick with the comma operator. > > --matt > > On Mon, Sep 15, 2014 at 7:03 PM, Steven Hartland wrote: > > > The following commit added SET_ERROR dtrace probes to illumos > > https://github.com/illumos/illumos-gate/commit/be6fd75 > > > > Now we have all the SET_ERROR calls but the FreeBSD's ZFS implementation > > but our SET_ERROR in sys/cddl/compat/opensolaris/sys/sdt.h is simply: > > #define SET_ERROR(err) (err) > > > > I tried using the illumos version but that resulted being unable > > to mount ZFS root, so clearly not right. > > > > /* > > * the set-error SDT probe is extra static, in that we declare its fake > > * function literally, rather than with the DTRACE_PROBE1() macro. This is > > * necessary so that SET_ERROR() can evaluate to a value, which wouldn't > > * be possible if it required multiple statements (to declare the function > > * and then call it). > > * > > * SET_ERROR() uses the comma operator so that it can be used without much > > * additional code. For example, "return (EINVAL);" becomes > > * "return (SET_ERROR(EINVAL));". Note that the argument will be evaluated > > * twice, so it should not have side effects (e.g. something like: > > * "return (SET_ERROR(log_error(EINVAL, info)));" would log the error > > twice). > > */ > > extern void __dtrace_probe_set__error(uintptr_t); > > #define SET_ERROR(err) (__dtrace_probe_set__error(err), err) > > > > > > For those that know the the ins and outs of our dtrace is it > > possible for us to add support for this trace point? > > > > Regards > > Steve From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 16 02:59:53 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A9CDD56E for ; Tue, 16 Sep 2014 02:59:53 +0000 (UTC) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1838B641 for ; Tue, 16 Sep 2014 02:59:52 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id s18so5934113lam.14 for ; Mon, 15 Sep 2014 19:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphix.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Acp2PpEfglERLCcGmC6oz3isxgDG/QV38pcx+pONJn8=; b=Tw1NREm+m1M3RJunpxgjWCpBDc1D9gGeyc229FhY0PLkzvJj95JR75FHw8hF+4zwbh YMfaGjhscU2hfoI33413+Ea/S3NmpXZ1Zrn8ZZ5OD5f8gY3yhvFosrIsXENKmnwV6bkC AweEr4EHElE05tztcTqX+koKBQbEXf6ytRqgI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Acp2PpEfglERLCcGmC6oz3isxgDG/QV38pcx+pONJn8=; b=kpspi/micv+ZeOPVSAIaHcNoLuCs/yPDCWYNdUQkACY55nkB0oWq0kd67Rv8sDTwAb uTsR8I/rzQKs6PCBBInZ4/4tjLoZ3+9GSH0RubhcABBrDiVPLx9Cf+N9MWie2Qd44PlB HumfRov9ijJbpB0gyePO4FX2u/cwjr6pbRF7sv7Vf2dge9N2iUvPh09RjILtOpX7Yw5J libV814NywtewFultaHVqULRj8juheawIVvritutxlhSeUhU90qw79A8JjWfFGGk4tXT 9GiaSS+IGbOZv9qeSEi6uEft8Uj7hWQy0sDvPl6i2wKpLW+21BeF0SWklh7/0GySTruz QkIg== X-Gm-Message-State: ALoCoQns6+T0mWH6i/bejlK6g4bLO+iE+eDNAJIUNbvhhf+8oHDthviGztSfHfVz352OnhUpNSaG MIME-Version: 1.0 X-Received: by 10.112.118.141 with SMTP id km13mr31205644lbb.37.1410836390629; Mon, 15 Sep 2014 19:59:50 -0700 (PDT) Received: by 10.25.170.148 with HTTP; Mon, 15 Sep 2014 19:59:50 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Sep 2014 19:59:50 -0700 Message-ID: Subject: Re: ZFS SET_ERROR dtrace probe possible under FreeBSD? From: Matthew Ahrens To: Steven Hartland X-Mailman-Approved-At: Tue, 16 Sep 2014 04:01:41 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: hackers@freebsd.org, freebsd-dtrace@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 02:59:53 -0000 Disclaimer: I'm not an expert in FreeBSD dtrace. It looks like the FreeBSD kernel uses these declaration for kernel SDT probes, in sdt.h: 333 #*define* DTRACE_PROBE1 (name , type0 , arg0 ) \334 DTRACE_PROBE_IMPL_START (name , arg0 , 0, 0, 0, 0) \335 SDT_PROBE_ARGTYPE (sdt , , , name , 0, #type0 , NULL ); \336 DTRACE_PROBE_IMPL_END 324 #*define* DTRACE_PROBE_IMPL_START (name , arg0 , arg1 , arg2 , arg3 , arg4 ) *do* { \325 *static* SDT_PROBE_DEFINE (sdt , , , name ); \326 SDT_PROBE (sdt , , , name , arg0 , arg1 , arg2 , arg3 , arg4 );327 #*define* DTRACE_PROBE_IMPL_END } *while* (0) 163 #*define* SDT_PROBE (prov , mod , func , name , arg0 , arg1 , arg2 , arg3 , arg4 ) *do* { \164 *if* (sdt_ ##prov ##_##mod ##_##func ##_##name ->id ) \165 (*sdt_probe_func )(sdt_ ##prov ##_##mod ##_##func ##_##name ->id , \166 (uintptr_t ) arg0 , (uintptr_t ) arg1 , (uintptr_t ) arg2 , \167 (uintptr_t ) arg3 , (uintptr_t ) arg4 ); \168 } *while* (0) To do the equivalent "extra static" magic, you will need to expand out the DTRACE_PROBE1 macro. I think it should look something like: SDT_PROBE_DEFINE1(sdt, zfs, , set__error, "int"); #define SET_ERROR(err) \ ((sdt_sdt_zfs__set__error->id && \ (*sdt_probe_func)(sdt_sdt_zfs__set__error->id, (uintptr_t)err, 0, 0, 0, 0)), \ err) Note that SET_ERROR is an expansion of SDT_PROBE, but rewritten to be a single statement, so that we can do the same trick with the comma operator. --matt On Mon, Sep 15, 2014 at 7:03 PM, Steven Hartland wrote: > The following commit added SET_ERROR dtrace probes to illumos > https://github.com/illumos/illumos-gate/commit/be6fd75 > > Now we have all the SET_ERROR calls but the FreeBSD's ZFS implementation > but our SET_ERROR in sys/cddl/compat/opensolaris/sys/sdt.h is simply: > #define SET_ERROR(err) (err) > > I tried using the illumos version but that resulted being unable > to mount ZFS root, so clearly not right. > > /* > * the set-error SDT probe is extra static, in that we declare its fake > * function literally, rather than with the DTRACE_PROBE1() macro. This is > * necessary so that SET_ERROR() can evaluate to a value, which wouldn't > * be possible if it required multiple statements (to declare the function > * and then call it). > * > * SET_ERROR() uses the comma operator so that it can be used without much > * additional code. For example, "return (EINVAL);" becomes > * "return (SET_ERROR(EINVAL));". Note that the argument will be evaluated > * twice, so it should not have side effects (e.g. something like: > * "return (SET_ERROR(log_error(EINVAL, info)));" would log the error > twice). > */ > extern void __dtrace_probe_set__error(uintptr_t); > #define SET_ERROR(err) (__dtrace_probe_set__error(err), err) > > > For those that know the the ins and outs of our dtrace is it > possible for us to add support for this trace point? > > Regards > Steve > _______________________________________________ > freebsd-dtrace@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-dtrace > To unsubscribe, send any mail to "freebsd-dtrace-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 16 03:19:06 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 28BB59EE for ; Tue, 16 Sep 2014 03:19:06 +0000 (UTC) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9DF368F3 for ; Tue, 16 Sep 2014 03:19:05 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id b17so5942175lan.4 for ; Mon, 15 Sep 2014 20:19:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphix.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tX5IM6J6fDWgZENsn/sayZndAj6bQxFNLbH52ADUWU4=; b=ZZTKXBckA/kH8djmpKX3czYaMCD1c92IkA9XSqvRdUiolt8nmOYDTxnkV6yEm1w/qE lK3KpGBKDFeB9XnvJZAHIWujNEfpHJYfMx9sM+usc1QxwUsZi0akLiGiyo0z2cb75EOH 3yIA43Ic++6HVxvKmiA4pDImWg7h2Pgafm1SE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tX5IM6J6fDWgZENsn/sayZndAj6bQxFNLbH52ADUWU4=; b=Gjx6Ab0ieFfj0ZD1PUMJNVwGPm1Pen7AYKUaRe2EaJcZN59g9PizWw2qjbi2N0bNiD k5nkwPNylTvtEubZEFUZ9PLntKnz5XAIp1jkWR/x/2QIVQ4zHB45/jbMomZnQJKxMDWH MsQl5nqG5xlSYCI5jFdP2X6xPsy+y18X5DJP8QOi/ZNN59PA5/WBXL1Hfit+WofHk/dB tjAMSIPxGo3xMlZdP0OjTvx1xDv823hdMeMEjowvctUql32POaTkr1frgoII2m4J+j33 DYIh9n1y74ABGo9pD2aGsTc8DIsozJzlJe2aG5WWuV/pXufrMeOjiS3UOjGBj4+ATL47 T2wA== X-Gm-Message-State: ALoCoQkqLFeWta/gRTP8Xj8Q4jB9l9sGF6uH52juhf5TFPozsiYGcQSYoT2RM6fBl5qULsTzG/hl MIME-Version: 1.0 X-Received: by 10.112.4.33 with SMTP id h1mr30519046lbh.67.1410837543411; Mon, 15 Sep 2014 20:19:03 -0700 (PDT) Received: by 10.25.170.148 with HTTP; Mon, 15 Sep 2014 20:19:03 -0700 (PDT) In-Reply-To: <20140916031318.GB26720@charmander.picturesperfect.net> References: <20140916031318.GB26720@charmander.picturesperfect.net> Date: Mon, 15 Sep 2014 20:19:03 -0700 Message-ID: Subject: Re: ZFS SET_ERROR dtrace probe possible under FreeBSD? From: Matthew Ahrens To: Mark Johnston X-Mailman-Approved-At: Tue, 16 Sep 2014 04:02:05 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Steven Hartland , hackers@freebsd.org, freebsd-dtrace@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 03:19:06 -0000 On Mon, Sep 15, 2014 at 8:13 PM, Mark Johnston wrote: > On Mon, Sep 15, 2014 at 07:59:50PM -0700, Matthew Ahrens wrote: > > Disclaimer: I'm not an expert in FreeBSD dtrace. > > > > It looks like the FreeBSD kernel uses these declaration for kernel SDT > > probes, in sdt.h: > ... > > > > To do the equivalent "extra static" magic, you will need to expand out > the > > DTRACE_PROBE1 macro. I think it should look something like: > > > > SDT_PROBE_DEFINE1(sdt, zfs, , set__error, "int"); > > > > #define SET_ERROR(err) \ > > ((sdt_sdt_zfs__set__error->id && \ > > (*sdt_probe_func)(sdt_sdt_zfs__set__error->id, (uintptr_t)err, 0, 0, > 0, > > 0)), \ > > err) > > I think it would need to be > > SDT_PROBE_DECLARE(sdt, , , set__error); > > #define SET_ERROR(err) ... > > in the compat sdt.h, and then kern_dtrace.c or so would contain > > SDT_PROBE_DEFINE1(sdt, , , set__error, "int"); > > Note that the module shouldn't be hard-coded - it'll be filled in when > the probes are created by the SDT code. Ah, yes, that makes sense. --matt From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 16 05:39:24 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B6F5A44; Tue, 16 Sep 2014 05:39:24 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BA730645; Tue, 16 Sep 2014 05:39:22 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 00DD71FE027; Tue, 16 Sep 2014 07:39:13 +0200 (CEST) Message-ID: <5417CCF6.10204@selasky.org> Date: Tue, 16 Sep 2014 07:39:02 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: CeDeROM , FreeBSD Questions Mailing List , "freebsd-hackers@freebsd.org" , freebsd-net@freebsd.org, "freebsd-usb@FreeBSD.org" Subject: Re: U3G QDL firmware loader for GOBI2000/HP_UN2420 MiniPCI/USB 3G/GPS References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 05:39:24 -0000 On 09/15/14 17:16, CeDeROM wrote: > Hello world! :-) > > I have changed my machine, there is a built-in GOBI2000 / HP UN2420 > 3G/GPS module installable as MiniPCI card and visible as USB device. I > have added its VID/PID to the usbdevs and u3g.c module, so after > recompilation it gets recognised by u3g module and apropriate > /dev/cuaU* device shows up.. > > The problem is that device does not store firmware inside non-volatile > memory, so user needs to upload it after power-on. I have the firmware > files. I can test modem with success after reboot from Win7 which > uploads firmware into device. Still, I need to upload the firmware > somehow on my FreeBSD. > > The upload protocol is QDL and /dev/cuaU0 shows up waiting for > command. Which utility can I use to upload firmware with QDL? I have > seen one post [1] regarding this problem in the past but the QDL > utility was not named explicitly. > > Any hints welcome! :-) > > Tomek > > [1] http://lists.freebsd.org/pipermail/freebsd-usb/2010-October/009384.html > Hi, Maybe you can use some tools to sniff the USB protocol under the other operating system. The protocol is probably not too complicated, and just replay the traffic. --HPS From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 16 06:19:07 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E331644 for ; Tue, 16 Sep 2014 06:19:07 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E387A2D for ; Tue, 16 Sep 2014 06:19:06 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s8G6Ix92066054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Sep 2014 23:18:59 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s8G6Iw9c066053; Mon, 15 Sep 2014 23:18:58 -0700 (PDT) (envelope-from jmg) Date: Mon, 15 Sep 2014 23:18:58 -0700 From: John-Mark Gurney To: Wojciech Puchar Subject: Re: openssl with aes-in or padlock Message-ID: <20140916061857.GY82175@funkthat.com> Mail-Followup-To: Wojciech Puchar , Jim Thompson , "hackers@freebsd.org" References: <20140911180258.GN82175@funkthat.com> <62E8AD7E-346F-4F77-9628-6D5121D7AD6D@netgate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 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? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 15 Sep 2014 23:18:59 -0700 (PDT) Cc: Jim Thompson , "hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 06:19:07 -0000 Wojciech Puchar wrote this message on Sat, Sep 13, 2014 at 09:35 +0200: > will it be available on FreeBSD 10 ? It will eventually make it into 10, but it definately won't make it into 10.1-R which is coming up soon. > On Thu, 11 Sep 2014, Jim Thompson wrote: > > >We just fixed IPSEC to use AES-GCM (with support for AES-NI on hardware > >that supports it.) > > > >OpenSSL / OpenVPN is probably next. > > > >-- Jim > > > >On Sep 11, 2014, at 14:33, Wojciech Puchar wrote: > > > >>>>#openssl speed -evp aes-256-cbc > >>> > >>>First off, you won't get much speed up w/ CBC encrypt... Try testing > >>>using aes-256-ctr instead... CBC can't process multiple blocks in > >>>parallel like CTR can... if you measure the cbc _decrypt_ speed, you > >>>should see a big improvement as CBC decrypt can be parallelized... > >>> > >>>>in the same time dd from geli encrypted ramdisk to /dev/null is 66MB/s > >>> > >>>geli uses a different framework for it's crypto processing.. for geli, > >>>make sure you have the aesni kernel module loaded before you attach > >>>to a geli disk... You should get kernel messages like the following: > >>>GEOM_ELI: Device gpt/werner.eli created. > >>>GEOM_ELI: Encryption: AES-XTS 256 > >>>GEOM_ELI: Crypto: hardware > >> > >>yes i have this. contrary to what you say - both AES-XTC and AES-CBC gets > >>MUCH faster with AES-NI. > >> > >>>notice the Crypto: hardware line.. Also, make sure that your geli > >>>sector size is 4k instead of 512... This reduces the loop overhead, > >> > >>as i already said - geli works fast and make use of AES-NI or padlock > >> > >>openssl does not -- 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-hackers@FreeBSD.ORG Tue Sep 16 06:59:19 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C2AF987; Tue, 16 Sep 2014 06:59:19 +0000 (UTC) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F3562D58; Tue, 16 Sep 2014 06:59:18 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id i7so2465120oag.33 for ; Mon, 15 Sep 2014 23:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lp6LCa3ZaznZU93eKYJJovoCzfjfcRjt8eEOaUyrf9U=; b=FQnPSe1AO1a9L2CEvfUVs6LgQ9AFWBsB5smJQINid+DS+XUlAcA5u7n4RGRA8Trcxs AN4GX/AzF6LAaik4mpN9nXzlFxK7MvvIQMJbRAYC52yZUSgzRBwhjhbZWwfqEiY2qT5S pzzlfr/75kdt89ZWCQZzIQlZf85645m0QWx2wccNuX0SMZYq9HSgm1xGYO3IJaeOscW/ sIAD0DMGDTR/CFH3VL9CpEVcsXP/RCMykQZKPUUKuGI9XRsJLoYkE8w69g9x1/1jaZC5 Pl2SsF8EgzCEmDohaFKAsN52GS5AJcRbPdXKIlWIV+fMOT5QxWnOCGR5Nmf7eV0Mb3M6 4v1A== MIME-Version: 1.0 X-Received: by 10.60.175.166 with SMTP id cb6mr9099996oec.64.1410850758091; Mon, 15 Sep 2014 23:59:18 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.202.58.196 with HTTP; Mon, 15 Sep 2014 23:59:18 -0700 (PDT) In-Reply-To: <5417CCF6.10204@selasky.org> References: <5417CCF6.10204@selasky.org> Date: Tue, 16 Sep 2014 08:59:18 +0200 X-Google-Sender-Auth: 5fJ56He3INDiygHWWFUADDPeRN8 Message-ID: Subject: Re: U3G QDL firmware loader for GOBI2000/HP_UN2420 MiniPCI/USB 3G/GPS From: CeDeROM To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , Ruslan Bukin , FreeBSD Questions Mailing List , "freebsd-usb@FreeBSD.org" , freebsd-net@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 06:59:19 -0000 On Tue, Sep 16, 2014 at 7:39 AM, Hans Petter Selasky wrote: > On 09/15/14 17:16, CeDeROM wrote: >> Hello world! :-) >> I have changed my machine, there is a built-in GOBI2000 / HP UN2420 >> 3G/GPS module installable as MiniPCI card and visible as USB device. I >> have added its VID/PID to the usbdevs and u3g.c module, so after >> recompilation it gets recognised by u3g module and apropriate >> /dev/cuaU* device shows up.. >> The problem is that device does not store firmware inside non-volatile >> memory, so user needs to upload it after power-on. I have the firmware >> files. I can test modem with success after reboot from Win7 which >> uploads firmware into device. Still, I need to upload the firmware >> somehow on my FreeBSD. >> The upload protocol is QDL and /dev/cuaU0 shows up waiting for >> command. Which utility can I use to upload firmware with QDL? I have >> seen one post [1] regarding this problem in the past but the QDL >> utility was not named explicitly. >> Any hints welcome! :-) >> Tomek >> [1] >> http://lists.freebsd.org/pipermail/freebsd-usb/2010-October/009384.html>> > Hi, > Maybe you can use some tools to sniff the USB protocol under the other > operating system. The protocol is probably not too complicated, and just > replay the traffic. > --HPS I just got the gobi_loader application sources from Ruslan Bukin! I will try it out and when it works fine I will send patches to the FreeBSD base along with my u3g patches, it may come handy for others as well :-) Thank you!! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 16 10:05:27 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8619BB6C; Tue, 16 Sep 2014 10:05:27 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id EE35918F; Tue, 16 Sep 2014 10:05:26 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id F093320E7088F; Tue, 16 Sep 2014 10:05:18 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: * X-Spam-Status: No, score=1.3 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,RDNS_DYNAMIC,STOX_REPLY_TYPE autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTP id 1A4D720E70886; Tue, 16 Sep 2014 10:05:13 +0000 (UTC) Message-ID: From: "Steven Hartland" To: "Mark Johnston" , "Matthew Ahrens" References: <20140916031318.GB26720@charmander.picturesperfect.net> Subject: Re: ZFS SET_ERROR dtrace probe possible under FreeBSD? Date: Tue, 16 Sep 2014 11:05:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: hackers@freebsd.org, freebsd-dtrace@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 10:05:27 -0000 ----- Original Message ----- From: "Mark Johnston" > On Mon, Sep 15, 2014 at 07:59:50PM -0700, Matthew Ahrens wrote: >> Disclaimer: I'm not an expert in FreeBSD dtrace. >> >> It looks like the FreeBSD kernel uses these declaration for kernel SDT >> probes, in sdt.h: >> >> 333 #*define* >> DTRACE_PROBE1 (name >> , >> type0 , >> arg0 ) \334 >> DTRACE_PROBE_IMPL_START >> (name >> , arg0 >> , 0, >> 0, 0, 0) \335 >> SDT_PROBE_ARGTYPE >> (sdt >> , , >> , name , >> 0, #type0 , >> NULL ); \336 >> DTRACE_PROBE_IMPL_END >> >> >> >> 324 #*define* DTRACE_PROBE_IMPL_START >> (name >> , arg0 >> , arg1 >> , arg2 >> , arg3 >> , arg4 >> ) *do* >> { \325 *static* >> SDT_PROBE_DEFINE >> (sdt >> , , >> , name ); >> \326 SDT_PROBE >> (sdt >> , , >> , name , >> arg0 , >> arg1 , >> arg2 , >> arg3 , >> arg4 );327 >> #*define* >> DTRACE_PROBE_IMPL_END >> } >> *while* (0) >> >> >> 163 #*define* >> SDT_PROBE (prov >> , >> mod , >> func , >> name , >> arg0 , >> arg1 , >> arg2 , >> arg3 , >> arg4 ) *do* >> { \164 *if* >> (sdt_ ##prov >> ##_##mod >> ##_##func >> ##_##name >> ->id >> ) \165 >> (*sdt_probe_func >> )(sdt_ >> ##prov >> ##_##mod >> ##_##func >> ##_##name >> ->id >> , \166 >> >> (uintptr_t ) >> arg0 , >> (uintptr_t ) >> arg1 , >> (uintptr_t ) >> arg2 , \167 >> >> (uintptr_t ) >> arg3 , >> (uintptr_t ) >> arg4 ); \168 >> } >> *while* (0) >> >> >> To do the equivalent "extra static" magic, you will need to expand out the >> DTRACE_PROBE1 macro. I think it should look something like: >> >> SDT_PROBE_DEFINE1(sdt, zfs, , set__error, "int"); >> >> #define SET_ERROR(err) \ >> ((sdt_sdt_zfs__set__error->id && \ >> (*sdt_probe_func)(sdt_sdt_zfs__set__error->id, (uintptr_t)err, 0, 0, 0, >> 0)), \ >> err) > > I think it would need to be > > SDT_PROBE_DECLARE(sdt, , , set__error); > > #define SET_ERROR(err) ... > > in the compat sdt.h, and then kern_dtrace.c or so would contain > > SDT_PROBE_DEFINE1(sdt, , , set__error, "int"); > > Note that the module shouldn't be hard-coded - it'll be filled in when > the probes are created by the SDT code. Thanks guys for the pointers, I tried the following slightly ammended from Matts original due to sdt_probe_func being a void return: Index: sys/cddl/compat/opensolaris/sys/sdt.h =================================================================== --- sys/cddl/compat/opensolaris/sys/sdt.h (revision 271518) +++ sys/cddl/compat/opensolaris/sys/sdt.h (working copy) @@ -34,6 +34,11 @@ #endif #include_next -#define SET_ERROR(err) (err) +SDT_PROBE_DECLARE(sdt, , , set__error); +#define SET_ERROR(err) \ + ((sdt_sdt___set__error->id ? \ + (*sdt_probe_func)(sdt_sdt___set__error->id, \ + (uintptr_t)err, 0, 0, 0, 0) : 0), err) + #endif /* _OPENSOLARIS_SYS_SDT_H_ */ Index: sys/kern/kern_dtrace.c =================================================================== --- sys/kern/kern_dtrace.c (revision 271518) +++ sys/kern/kern_dtrace.c (working copy) @@ -48,6 +48,8 @@ FEATURE(kdtrace_hooks, static MALLOC_DEFINE(M_KDTRACE, "kdtrace", "DTrace hooks"); +SDT_PROBE_DEFINE1(sdt, , , set__error, "int"); + /* Hooks used in the machine-dependent trap handlers. */ dtrace_trap_func_t dtrace_trap_func; dtrace_doubletrap_func_t dtrace_doubletrap_func; But it fails with:- /usr/src/sys/kern/kern_dtrace.c:51:24: error: expected identifier SDT_PROBE_DEFINE1(sdt, , , set__error, "int"); ^ /usr/src/sys/kern/kern_dtrace.c:51:1: error: type specifier missing, defaults to 'int' [-Werror,-Wimplicit-int] SDT_PROBE_DEFINE1(sdt, , , set__error, "int"); All other calls to SDT_PROBE_DEFINE1 seem to define all args e.g. sys/kern/kern_exit.c:SDT_PROBE_DEFINE1(proc, kernel, , exit, "int"); Are you sure they should be ommited? Also is kern_dtrace.c the correct place for the probe define given its zfs specific? Regards Steve From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 16 16:39:50 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 591C2F93; Tue, 16 Sep 2014 16:39:50 +0000 (UTC) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B22D94D; Tue, 16 Sep 2014 16:39:50 +0000 (UTC) Received: by mail-pa0-f45.google.com with SMTP id rd3so130451pab.32 for ; Tue, 16 Sep 2014 09:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=+jQasUqFR6AdLMLCMImEIhRZBrhWURC3D1kiUehdSIw=; b=p1rzfvOyztlyn+xeaTqhWolEd8o+h0ia+F8HnRovtZVok7zKgGZGMDa6Vwwd8/SwRb X+ovhjFeWbrTf47gpoGwz5khj0CftrYxKxI2zbkPl40mYoJMOYGzy8TIWwzr/hT1RH0/ wRQmrgf6eWrTAYKghIDepbiOWwqIuspu/LO6rQ8rqqZpD1RomEQBFmTq6+/uTPxWgcZw yjf94rzTuE06crhJtlLKlN3cGJ48DmyGsM/iUuegz28tCSUNNmkfb81/elK6NG/kvZhv NK8RL5V5qEDmh3d4pEYWbUVnSy3nh2ukzO9FIlja/gu/XCDNyBSDCq7n8ZPWVD+5HffD glRQ== X-Received: by 10.66.139.16 with SMTP id qu16mr17170212pab.153.1410885589467; Tue, 16 Sep 2014 09:39:49 -0700 (PDT) Received: from charmander.picturesperfect.net (c-67-182-131-225.hsd1.wa.comcast.net. [67.182.131.225]) by mx.google.com with ESMTPSA id ca4sm7120449pad.0.2014.09.16.09.39.47 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Sep 2014 09:39:48 -0700 (PDT) Sender: Mark Johnston Date: Tue, 16 Sep 2014 09:39:27 -0700 From: Mark Johnston To: Steven Hartland Subject: Re: ZFS SET_ERROR dtrace probe possible under FreeBSD? Message-ID: <20140916163927.GA36108@charmander.picturesperfect.net> References: <20140916031318.GB26720@charmander.picturesperfect.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Matthew Ahrens , hackers@freebsd.org, freebsd-dtrace@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 16:39:50 -0000 On Tue, Sep 16, 2014 at 11:05:09AM +0100, Steven Hartland wrote: > > ----- Original Message ----- > From: "Mark Johnston" > > > > On Mon, Sep 15, 2014 at 07:59:50PM -0700, Matthew Ahrens wrote: > >> Disclaimer: I'm not an expert in FreeBSD dtrace. > >> > >> It looks like the FreeBSD kernel uses these declaration for kernel SDT > >> probes, in sdt.h: > >> > >> 333 #*define* > >> DTRACE_PROBE1 (name > >> , > >> type0 , > >> arg0 ) \334 > >> DTRACE_PROBE_IMPL_START > >> (name > >> , arg0 > >> , 0, > >> 0, 0, 0) \335 > >> SDT_PROBE_ARGTYPE > >> (sdt > >> , , > >> , name , > >> 0, #type0 , > >> NULL ); \336 > >> DTRACE_PROBE_IMPL_END > >> > >> > >> > >> 324 #*define* DTRACE_PROBE_IMPL_START > >> (name > >> , arg0 > >> , arg1 > >> , arg2 > >> , arg3 > >> , arg4 > >> ) *do* > >> { \325 *static* > >> SDT_PROBE_DEFINE > >> (sdt > >> , , > >> , name ); > >> \326 SDT_PROBE > >> (sdt > >> , , > >> , name , > >> arg0 , > >> arg1 , > >> arg2 , > >> arg3 , > >> arg4 );327 > >> #*define* > >> DTRACE_PROBE_IMPL_END > >> } > >> *while* (0) > >> > >> > >> 163 #*define* > >> SDT_PROBE (prov > >> , > >> mod , > >> func , > >> name , > >> arg0 , > >> arg1 , > >> arg2 , > >> arg3 , > >> arg4 ) *do* > >> { \164 *if* > >> (sdt_ ##prov > >> ##_##mod > >> ##_##func > >> ##_##name > >> ->id > >> ) \165 > >> (*sdt_probe_func > >> )(sdt_ > >> ##prov > >> ##_##mod > >> ##_##func > >> ##_##name > >> ->id > >> , \166 > >> > >> (uintptr_t ) > >> arg0 , > >> (uintptr_t ) > >> arg1 , > >> (uintptr_t ) > >> arg2 , \167 > >> > >> (uintptr_t ) > >> arg3 , > >> (uintptr_t ) > >> arg4 ); \168 > >> } > >> *while* (0) > >> > >> > >> To do the equivalent "extra static" magic, you will need to expand out the > >> DTRACE_PROBE1 macro. I think it should look something like: > >> > >> SDT_PROBE_DEFINE1(sdt, zfs, , set__error, "int"); > >> > >> #define SET_ERROR(err) \ > >> ((sdt_sdt_zfs__set__error->id && \ > >> (*sdt_probe_func)(sdt_sdt_zfs__set__error->id, (uintptr_t)err, 0, 0, 0, > >> 0)), \ > >> err) > > > > I think it would need to be > > > > SDT_PROBE_DECLARE(sdt, , , set__error); > > > > #define SET_ERROR(err) ... > > > > in the compat sdt.h, and then kern_dtrace.c or so would contain > > > > SDT_PROBE_DEFINE1(sdt, , , set__error, "int"); > > > > Note that the module shouldn't be hard-coded - it'll be filled in when > > the probes are created by the SDT code. > > Thanks guys for the pointers, I tried the following slightly ammended > from Matts original due to sdt_probe_func being a void return: > > Index: sys/cddl/compat/opensolaris/sys/sdt.h > =================================================================== > --- sys/cddl/compat/opensolaris/sys/sdt.h (revision 271518) > +++ sys/cddl/compat/opensolaris/sys/sdt.h (working copy) > @@ -34,6 +34,11 @@ > #endif > #include_next > > -#define SET_ERROR(err) (err) > +SDT_PROBE_DECLARE(sdt, , , set__error); > > +#define SET_ERROR(err) \ > + ((sdt_sdt___set__error->id ? \ > + (*sdt_probe_func)(sdt_sdt___set__error->id, \ > + (uintptr_t)err, 0, 0, 0, 0) : 0), err) > + > #endif /* _OPENSOLARIS_SYS_SDT_H_ */ > Index: sys/kern/kern_dtrace.c > =================================================================== > --- sys/kern/kern_dtrace.c (revision 271518) > +++ sys/kern/kern_dtrace.c (working copy) > @@ -48,6 +48,8 @@ FEATURE(kdtrace_hooks, > > static MALLOC_DEFINE(M_KDTRACE, "kdtrace", "DTrace hooks"); > > +SDT_PROBE_DEFINE1(sdt, , , set__error, "int"); > + > /* Hooks used in the machine-dependent trap handlers. */ > dtrace_trap_func_t dtrace_trap_func; > dtrace_doubletrap_func_t dtrace_doubletrap_func; > > But it fails with:- > /usr/src/sys/kern/kern_dtrace.c:51:24: error: expected identifier > SDT_PROBE_DEFINE1(sdt, , , set__error, "int"); > ^ > /usr/src/sys/kern/kern_dtrace.c:51:1: error: type specifier missing, defaults to 'int' [-Werror,-Wimplicit-int] > SDT_PROBE_DEFINE1(sdt, , , set__error, "int"); > > All other calls to SDT_PROBE_DEFINE1 seem to define all args e.g. > sys/kern/kern_exit.c:SDT_PROBE_DEFINE1(proc, kernel, , exit, "int"); > > Are you sure they should be ommited? You'll need to #include in kern_dtrace.c. > > Also is kern_dtrace.c the correct place for the probe define given > its zfs specific? I was just thinking that it might be useful elsewhere too. For now, perhaps the best place is in a new file under sys/cddl/compat/opensolaris/kern. Then it'll be part of opensolaris.ko and SET_ERROR will work for any illumos code in the tree, not just ZFS. -Mark From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 16 19:02:18 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 920C86E0; Tue, 16 Sep 2014 19:02:18 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 5368DCF1; Tue, 16 Sep 2014 19:02:18 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 1B58220E7088D; Tue, 16 Sep 2014 19:02:16 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.2 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,RDNS_DYNAMIC,STOX_REPLY_TYPE autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id A2C9B20E70886; Tue, 16 Sep 2014 19:02:14 +0000 (UTC) Message-ID: <4B404F031430407C98A6A553A5FF1843@multiplay.co.uk> From: "Steven Hartland" To: "Mark Johnston" References: <20140916031318.GB26720@charmander.picturesperfect.net> <20140916163927.GA36108@charmander.picturesperfect.net> Subject: Re: ZFS SET_ERROR dtrace probe possible under FreeBSD? Date: Tue, 16 Sep 2014 20:02:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: hackers@freebsd.org, freebsd-dtrace@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 19:02:18 -0000 ----- Original Message ----- From: "Mark Johnston" > You'll need to #include in kern_dtrace.c. > >> >> Also is kern_dtrace.c the correct place for the probe define given >> its zfs specific? > > I was just thinking that it might be useful elsewhere too. > > For now, perhaps the best place is in a new file under > sys/cddl/compat/opensolaris/kern. Then it'll be part of opensolaris.ko > and SET_ERROR will work for any illumos code in the tree, not just ZFS. Thanks again. I've created a review for this change below if you would be so kind: https://reviews.freebsd.org/D790 Regards Steve From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 16 23:17:22 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00925597; Tue, 16 Sep 2014 23:17:21 +0000 (UTC) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 77A6ABA8; Tue, 16 Sep 2014 23:17:21 +0000 (UTC) Received: by mail-qg0-f53.google.com with SMTP id q108so834915qgd.12 for ; Tue, 16 Sep 2014 16:17:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4l5R6ojs/BoDKkIkv8NRpj9l6nMGrIBi9Ru5NUprgwI=; b=LfuhtDdGXn+s7cObqewgyiC3ERHdGdbcIACX2OAYAHkK1e9BEFXI4Og/IwnEBwUZ3z KfzaVbvkZme8y+VgLYzJTkVlx/lnJdEXCjP25xRf1CN0s+Sikol5+6fe0fJMtLEtVBut A95OSQvFol41dF8+ctGEk0DWluExsDEJRaouz1ur7N3ZZTBYygPVwCm0nxI2Cq46KYrg 93OmVHUpFBqweZo/R+w95lxBq2et2qjPYh4F2HSWJ/HvwbNpBNIyW9KosC/9tK1agsKd t5iTtgYN3m/cnazoQoQvatqBWVyJlvYrirDo7LTQaVxa4aW+My+Ur8WX7TmzspfA4wSP 5wPw== MIME-Version: 1.0 X-Received: by 10.229.249.8 with SMTP id mi8mr28280524qcb.6.1410909440657; Tue, 16 Sep 2014 16:17:20 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.39.139 with HTTP; Tue, 16 Sep 2014 16:17:20 -0700 (PDT) In-Reply-To: <52A731FD.8060307@FreeBSD.org> References: <5295A261.2060403@FreeBSD.org> <529F4409.9080403@FreeBSD.org> <52A1B869.6080407@FreeBSD.org> <52A21AE9.5020803@FreeBSD.org> <52A731FD.8060307@FreeBSD.org> Date: Tue, 16 Sep 2014 16:17:20 -0700 X-Google-Sender-Auth: 08wbhFiKGMktHGHguZyfb9maQDs Message-ID: Subject: Re: 9.1 callout behavior From: Adrian Chadd To: Alexander Motin Content-Type: text/plain; charset=UTF-8 Cc: Bret Ketchum , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 23:17:22 -0000 Hi! I know this is bringing up an old thread, but Dell has shipped us some hardware (thanks Dell!) and I'm helping them take a look at it. On 10 December 2013 07:23, Alexander Motin wrote: > On 10.12.2013 17:12, Bret Ketchum wrote: >> >> Do either of you have a dual socket/package motherboard to play >> with? I've tried a couple single socket motherboards and cannot >> reproduce the issue. I'm wondering if this occurs on only multi-socket >> mobos. > > > My main test system is dual-socket (Supermicro X8DTU). It's reasonably reproducable. The tscdrift tool from jhb (in tools/tools/tscdrift) looks thus: root@appollyon:~/src/tscdrift # ./tscdrift CPU | TSC skew (min/avg/max/stddev) ----+------------------------------ 0 | 0 0 0 0.000 1 | 34 79 380 39.005 2 | 306 476 1326 120.472 3 | 306 485 1426 123.487 4 | 280 473 7500 248.965 5 | 280 462 1320 126.691 6 | 300 461 1934 129.362 7 | 300 470 1354 122.654 8 | 292 420 3640 152.029 9 | 135 190 655 58.601 10 | 112 188 620 56.490 11 | 114 189 660 62.440 12 | 129 204 566 53.731 13 | 129 206 617 56.047 14 | 126 211 620 54.450 15 | 126 213 603 54.808 16 | 440 590 1683 217.649 17 | 440 612 1606 234.295 18 | 468 642 4017 266.768 19 | 463 653 8683 352.624 20 | 480 671 1500 255.395 21 | 480 689 8060 348.384 22 | 468 707 3766 296.721 23 | 466 703 1683 284.625 24 | 480 767 8183 373.741 25 | 486 782 7400 362.069 26 | 480 664 1620 249.125 27 | 477 686 3669 278.144 28 | 469 621 1897 226.673 29 | 469 649 8275 363.575 30 | 457 636 1835 250.005 31 | 451 641 4300 272.322 If I modify their supplied ticktock module to call callout_reset_on(args, 0); to call on CPU #0, then it actually doesn't seem to drift. I'm going to look at mav's recent patch to the scheduler in case it has an effect on things. -a From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 17 00:38:30 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 111DB575; Wed, 17 Sep 2014 00:38:30 +0000 (UTC) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AAE58396; Wed, 17 Sep 2014 00:38:29 +0000 (UTC) Received: by mail-qg0-f54.google.com with SMTP id z60so879614qgd.41 for ; Tue, 16 Sep 2014 17:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=dqgIVhFvQEbPSjHo7hLPy2ZpDWl9Jc6GTsY2fFuMxG8=; b=Mj8M1qytJt+Tdgq+VLskfKI5iQec8MD/rxuwlh/ajJlGaLmStWmnW3D/o6Dnr/98UI GcFzf8h5VeCLvtbVvxcPp6WeA85vTAF5ShCNuaY4rNSkEyJ9SPupHhAlixjryxHqIDvU Cfw0yABVrb4cRkGs/ilHaMBJT6ACqydwCLeQb14YG7oC3DiARIJO+zDBYwiJv02tXcU2 1yZd295yoITonzMW0JO1vqDjDVIAfAV27Agci6TRrT8k26LG0L0zI6m4WoPfw7tu2k9q vM5G69TeGyKbaf7WsP34vdrGDT6NXAx3hc7tiTBJ3jcRK7nMEljxXZvI8dIyBIaroMRL ocbQ== MIME-Version: 1.0 X-Received: by 10.140.42.77 with SMTP id b71mr54216746qga.52.1410914308634; Tue, 16 Sep 2014 17:38:28 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.39.139 with HTTP; Tue, 16 Sep 2014 17:38:28 -0700 (PDT) In-Reply-To: References: <5295A261.2060403@FreeBSD.org> <529F4409.9080403@FreeBSD.org> <52A1B869.6080407@FreeBSD.org> <52A21AE9.5020803@FreeBSD.org> <52A731FD.8060307@FreeBSD.org> Date: Tue, 16 Sep 2014 17:38:28 -0700 X-Google-Sender-Auth: Z1UHp45bi3Jz1saEDb_9JKPIbMM Message-ID: Subject: Re: 9.1 callout behavior From: Adrian Chadd To: Alexander Motin Content-Type: text/plain; charset=UTF-8 Cc: Bret Ketchum , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 00:38:30 -0000 So, it did show up even if I say to run the callout on cpu #0 - any kind of load on that CPU and that callwheel still gets run on another CPU. What I next did was compile up KTR: include GENERIC ident TESTING options KTR options ALQ options KTR_ALQ options KTR_COMPILE=0xffffffff .. then enable KTR_CALLOUT, and I see: 4175 0 884780740167480 precision set for 0xffffffff818194f8: 0.01999997 4174 0 884780667893634 callout lock 0xffffffff818194f8 func 0xffffffff818191d0 arg 0xffffffff818194f8 4149 0 884780455441940 callout 0xffffffff818194f8 finished 4148 0 884780455441414 scheduled 0xffffffff818194f8 func 0xffffffff818191d0 arg 0xffffffff818194f8 in 561.4a5c984a 4147 0 884780455440600 precision set for 0xffffffff818194f8: 0.01999997 4132 0 884780373374060 callout lock 0xffffffff818194f8 func 0xffffffff818191d0 arg 0xffffffff818194f8 4103 0 884780170731868 callout 0xffffffff818194f8 finished 4102 0 884780170731468 scheduled 0xffffffff818194f8 func 0xffffffff818191d0 arg 0xffffffff818194f8 in 561.25c0f291 4101 0 884780170730948 precision set for 0xffffffff818194f8: 0.01999997 4086 0 884780089391348 callout lock 0xffffffff818194f8 func 0xffffffff818191d0 arg 0xffffffff818194f8 4058 0 884779886019688 callout 0xffffffff818194f8 finished .. and those 561.xxxx values are sbintime values. The delta looks like it's ~ 142mS, which is in line with what your callout routine reports. So the math to calculate the "next" event is bumping it along to that value instead of 100mS. I'm going to update one of these boxes to -HEAD and see if it's still a problem there. -a From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 17 00:53:54 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66177880; Wed, 17 Sep 2014 00:53:54 +0000 (UTC) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0A690759; Wed, 17 Sep 2014 00:53:53 +0000 (UTC) Received: by mail-qg0-f48.google.com with SMTP id q108so926600qgd.7 for ; Tue, 16 Sep 2014 17:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=R5PkOEB2IlJh6ht60AQ3hxlghSSKe2jaO1QayBdCbW0=; b=n3nYL4kHyKsmd2qK86ri51Y/b3lQJPANp8qXYjoCqwxx9b9gy435su5h3sVxKm/jH7 hlD+2C4XDcFIlqWB28GqCP7JIt/+tdKtUR7TbnaHKoi5zA8bIQajGHmc8iOJyiX/i+sz 3BpTVMpDNvARbLUzv2HoNnWj3rJyy67e7FICE3yn/MM7smW5OwVUa/nvgAg8tNCrlmF9 CZT3KGFPbFPsjHPsIkIRQ4GjNmjLVWPcVe8R8EbI2j7ZclsMfOR+reQOzdp2Zm8VCM7/ HimFnUTurfPWKg20Ofm2JpSYaXTAhBYSuTuXjM6uekOiHoLy+MSdcVNUXlaXzWJB7BLn cSCA== MIME-Version: 1.0 X-Received: by 10.229.136.133 with SMTP id r5mr18611785qct.31.1410915233141; Tue, 16 Sep 2014 17:53:53 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.39.139 with HTTP; Tue, 16 Sep 2014 17:53:52 -0700 (PDT) In-Reply-To: References: <5295A261.2060403@FreeBSD.org> <529F4409.9080403@FreeBSD.org> <52A1B869.6080407@FreeBSD.org> <52A21AE9.5020803@FreeBSD.org> <52A731FD.8060307@FreeBSD.org> Date: Tue, 16 Sep 2014 17:53:52 -0700 X-Google-Sender-Auth: d3ljxE12s7WXI1MI0HQgJBYKTiU Message-ID: Subject: Re: 9.1 callout behavior From: Adrian Chadd To: Alexander Motin Content-Type: text/plain; charset=UTF-8 Cc: Bret Ketchum , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 00:53:54 -0000 On 16 September 2014 17:38, Adrian Chadd wrote: > So, it did show up even if I say to run the callout on cpu #0 - any > kind of load on that CPU and that callwheel still gets run on another > CPU. > > What I next did was compile up KTR: > > include GENERIC > ident TESTING > options KTR > options ALQ > options KTR_ALQ > options KTR_COMPILE=0xffffffff > > .. then enable KTR_CALLOUT, and I see: > > 4175 0 884780740167480 precision set for 0xffffffff818194f8: 0.01999997 > 4174 0 884780667893634 callout lock 0xffffffff818194f8 func > 0xffffffff818191d0 arg 0xffffffff818194f8 > 4149 0 884780455441940 callout 0xffffffff818194f8 finished > 4148 0 884780455441414 scheduled 0xffffffff818194f8 func > 0xffffffff818191d0 arg 0xffffffff818194f8 in 561.4a5c984a > 4147 0 884780455440600 precision set for 0xffffffff818194f8: 0.01999997 > 4132 0 884780373374060 callout lock 0xffffffff818194f8 func > 0xffffffff818191d0 arg 0xffffffff818194f8 > 4103 0 884780170731868 callout 0xffffffff818194f8 finished > 4102 0 884780170731468 scheduled 0xffffffff818194f8 func > 0xffffffff818191d0 arg 0xffffffff818194f8 in 561.25c0f291 > 4101 0 884780170730948 precision set for 0xffffffff818194f8: 0.01999997 > 4086 0 884780089391348 callout lock 0xffffffff818194f8 func > 0xffffffff818191d0 arg 0xffffffff818194f8 > 4058 0 884779886019688 callout 0xffffffff818194f8 finished > > .. and those 561.xxxx values are sbintime values. > > The delta looks like it's ~ 142mS, which is in line with what your > callout routine reports. So the math to calculate the "next" event is > bumping it along to that value instead of 100mS. > > I'm going to update one of these boxes to -HEAD and see if it's still > a problem there. So the test case uses callout_reset(), which is the "older" way of doing it. What callout_reset() does is: * convert to sbintime_t; * set the callout precision to 0; * set C_HARDCLOCK. Now, C_HARDCLOCK doesn't read the last clock - it reads the last per-cpu clock value. I have no idea if PCPU_GET(hardclocktime) is _actually_ going to be equal across all CPUs - and boy if it isn't I'm not going to fix it - but the point here is it's not going to be updated very often when the system is idle and not receiving many interrupts. When I change the code to use callout_reset_sbt(): callout_reset_sbt(&cp->co, (SBT_1S * 100) / 1000, 0, ticktock_callback, cp, 0); .. and callout_reset_sbt(&c.co, (SBT_1S * 100) / 1000, 0, ticktock_callback, &c, 0); To fire at the same interval that you did (hz / 10; so 100mS) then it worked out perfectly fine. -a From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 17 01:07:19 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88948DAB; Wed, 17 Sep 2014 01:07:19 +0000 (UTC) Received: from mail.westryn.net (mail.westryn.net [199.48.135.251]) (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 65AA1883; Wed, 17 Sep 2014 01:07:19 +0000 (UTC) Received: from sneffels.westryn.net (225x169.ouraynet.com [204.16.225.169]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.westryn.net (Postfix) with ESMTPSA id 948849432D3; Tue, 16 Sep 2014 18:59:31 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Resuming old EFI project From: Kim Shrier In-Reply-To: <541714E0.90609@freebsd.org> Date: Tue, 16 Sep 2014 18:57:39 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54159AC5.1010800@metricspace.net> <1410716250.4174.3.camel@bruno> <5415F505.3070206@metricspace.net> <541604F1.9010402@freebsd.org> <5416D6EB.7020803@metricspace.net> <541714E0.90609@freebsd.org> To: "freebsd-hackers@freebsd.org" X-Mailer: Apple Mail (2.1878.6) Cc: Eric McCorkle , Nathan Whitehorn X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 01:07:19 -0000 On Sep 15, 2014, at 10:33 AM, Nathan Whitehorn = wrote: >=20 > On 09/15/14 05:09, Eric McCorkle wrote: >> On 09/14/2014 17:13, Nathan Whitehorn wrote: >>=20 >>>>> What specifically are you looking to work on? >>>>>=20 >>>>=20 >>>> Well, I had been trying to get it to boot on a mac EFI = implementation >>>> as well. There's some funny things that have to happen there >>>> (notably, an HFS+ image). >>>=20 >>> People seem to have had luck with our FAT32 EFI system partitions on >>> macs so far, but this in general is one of the big missing bits: = hunting >>> down weird firmwares, testing them, and fixing them when they don't >>> work. We also need the EFI boot1 both to (a) have a better algorithm = for >>> finding the right UFS partition to boot from and (b) learn how to = boot >>> from ZFS as well as UFS. >>=20 >> I have a 100% ZFS system, so the current boot block doesn't work for = me (though I can tell it's being loaded and run). GELI should probably = be added to that list as well... >>=20 >> I assume the best thing would be to link in the ZFS code? Or would = it be better to install loader into the system partition as well? >>=20 >=20 > It's hard to integrate having loader on the ESP with the way loader = and installworld work, so better to keep it on UFS/ZFS. The sparc64 = boot1, on which the UEFI boot1 is based, has ZFS support already, so = that's the place to look I think. > -Nathan I have a mac-mini server that I purchased in October 2013. I would like = to use GPT on the internal drives and boot FreeBSD. I currently have = the drives using MBR and booting FreeBSD 10.0. I understand that in = order to use GPT instead, I have to have an Apple_boot partition that = would then boot FreeBSD. Are the UEFI code and disk partitioning tools = able to handle this? I am also interested in switching from UFS to ZFS. = Is that possible? I have looked around in the source some, and it appears that most of the = pieces are there but maybe not tested. I am willing to use this = mac-mini as a test bed and I would be willing to help iron out any = issues. Kim From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 17 06:47:18 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10A2C38F for ; Wed, 17 Sep 2014 06:47:18 +0000 (UTC) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 944A9E60 for ; Wed, 17 Sep 2014 06:47:17 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id m15so877954wgh.31 for ; Tue, 16 Sep 2014 23:47:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=nyPCxMOuUio0q5enaM3kLH4tDNA8pTn2hQRmOTtcMOk=; b=CaLJp3trPNnACYmp1K+HZjlqcDYg/sNfVwDdxGcEWO+zp+b0Ct+2MHY4eS1eohIccd X8J/3WRNhlZsNNtE5tUues2nk8fm3a4VtQNtdWYvEXHYjjpzqPPUsrLGJxK74TeztYZP lFqBao+KF9tXzRhJ+MOQNeYvfjKRt8K2n5KSGpaslS8ezsXpbysL7//sGpCYV+ZNeqkm oQe3he8qWsuRv6ni+GqXcezV3a+fH16n5GZCHMgSzh47Y5fi510/+XhHb832i1ZFePAm qD+cq1Hik3VZIa6D5PNt1iGod29Cy2k8G/8LGKFRbIcePpx8ErXclpQvaSyuviI4h3MO VGPw== X-Gm-Message-State: ALoCoQmKTGhhAfA+JWz23YBB8ydN5zQkhy12rYwcUE/OL2vETZUuuYxLQzdDEKGrjQ/EKWhz/Tvd X-Received: by 10.194.236.102 with SMTP id ut6mr19040815wjc.19.1410936005827; Tue, 16 Sep 2014 23:40:05 -0700 (PDT) Received: from localhost ([94.3.67.218]) by mx.google.com with ESMTPSA id kw2sm20924995wjb.30.2014.09.16.23.40.04 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Sep 2014 23:40:05 -0700 (PDT) Date: Wed, 17 Sep 2014 07:40:03 +0100 From: Matt Fleming To: Ed Maste Subject: Re: Resuming old EFI project Message-ID: <20140917064003.GA18635@console-pimps.org> References: <54159AC5.1010800@metricspace.net> <1410716250.4174.3.camel@bruno> <5415F505.3070206@metricspace.net> <541604F1.9010402@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Eric McCorkle , "freebsd-hackers@freebsd.org" , Nathan Whitehorn X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 06:47:18 -0000 On Sun, 14 Sep, at 09:19:50PM, Ed Maste wrote: > > The current code does work on MacBook Airs, with a caveat that the > loader is not displayed (we don't force a switch to text mode). There > is a patch in progress to address this which should arrive shortly. > > There is an additional issue that affects MacBook Pros which remains > to be diagnosed: the system appears to hang immediately after the > loader transfers control to the new kernel. Hey guys, I'm the EFI maintainer for the Linux kernel. One of the things that we do in the EFI boot stub is to search for GOP devices that also have the EFI Console Out protocol bound to them, since we've seen machines with multiple GOP devices and not all devices are actually backed by hardware. See here for the relevant code, http://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/commit/arch/x86/boot/compressed/eboot.c?id=38cb5ef4473c6f510fae3a00bdac3acd550e3796 This could be related to the problem you're seeing. -- Matt Fleming, Intel Open Source Technology Center From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 17 09:06:37 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94D6617E; Wed, 17 Sep 2014 09:06:37 +0000 (UTC) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FC36FD6; Wed, 17 Sep 2014 09:06:37 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id m8so831517obr.13 for ; Wed, 17 Sep 2014 02:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=C4RLhy3lJ0oCf3Wsy/xoCde7OEDehT06yYo+/TWPzhc=; b=sxg8XTlNWm4IkG8SqH8M23v9G2Izkl8XyAIDByFKh0hrhf2MeNtgDGM/x+BmrUlHhV Vkkc7Ou77goJr3l65xb1RdXDLYgtBpkDwITFNxlEdJ9cYxZA8++dntwuzndktSZ/+0hb uwRBnCNIpjPr80W7JxMGnOl3tJmgipBkkn8NrR+X9KBP91/RgoQv8PVrcNEfGtYM6s+u Me9dXL2OuJ0+Amg4OmLtUT2ECfrx3ARl5/DYaP23YAvNOjgDn9TZogiohgwUaXpMsF4Y pHv4ngolQecExcfYBfZ6xQhiLRRnBDU+YMl2sP/mAktIBNwC2CosC4v18vgNQOj0UfuL 66vg== MIME-Version: 1.0 X-Received: by 10.60.177.161 with SMTP id cr1mr41705825oec.8.1410944796732; Wed, 17 Sep 2014 02:06:36 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.202.58.196 with HTTP; Wed, 17 Sep 2014 02:06:36 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Sep 2014 11:06:36 +0200 X-Google-Sender-Auth: xZAvrxEXj3KcXWnGNh-xTqz4Mf0 Message-ID: Subject: Re: FreeBSD and WiDi / Miracast / WiFi Direct HDMI streaming From: CeDeROM To: Waitman Gobble Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , FreeBSD Questions Mailing List X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 09:06:37 -0000 On Fri, Sep 12, 2014 at 6:25 PM, CeDeROM wrote: > PTV3000 does not seems to work even with the stock Android/Nexus > (Streamcast) nor Windows 7 (Intel WiDi). > > I have ordered a Streamcast dongle from Google, lets give it a try :-) I have just received a Chromecast from Google dongle =) IT WORKS! Amazingly from start, on my old Nexus7, seems to work on OSX as well. Now time for FreeBSD :-) I think Chromecast would be the way to go.. Google must have it already implemented in open-source, it can stream sound so it could be also good alternative for Bluetooth A2DP.. and it cost only $35 :-) Best regards! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 17 11:23:07 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E99E0662 for ; Wed, 17 Sep 2014 11:23:07 +0000 (UTC) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.9]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8CA63F42 for ; Wed, 17 Sep 2014 11:23:07 +0000 (UTC) Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 3hydvq47kXz3hj3N for ; Wed, 17 Sep 2014 13:13:11 +0200 (CEST) Received: from mail.embedded-brains.de (host-82-135-62-35.customer.m-online.net [82.135.62.35]) by mail.mnet-online.de (Postfix) with ESMTP id 3hydvq2yTgzvhRx for ; Wed, 17 Sep 2014 13:13:11 +0200 (CEST) Received: by mail.embedded-brains.de (Postfix, from userid 65534) id E3A24652CFC; Wed, 17 Sep 2014 13:13:10 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on fidibusdmz X-Spam-Level: X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from self.eb.z (unknown [192.168.100.11]) by mail.embedded-brains.de (Postfix) with ESMTP id 1FE3865243D; Wed, 17 Sep 2014 13:13:10 +0200 (CEST) From: Sebastian Huber To: freebsd-hackers@freebsd.org Subject: [PATCH] C++ compatibility for some kernel headers Date: Wed, 17 Sep 2014 13:13:09 +0200 Message-Id: <1410952389-30368-1-git-send-email-sebastian.huber@embedded-brains.de> X-Mailer: git-send-email 1.8.4.5 Cc: Sebastian Huber X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 11:23:08 -0000 We ported the FreeBSD network stack to RTEMS. Some users want to write network interface drivers in C++. It would be nice if we can make some FreeBSD kernel headers C++ compatible. sys/buf_ring.h: Mabye it is better to fix the integer type of br_cons_head to be able to use it in atomic_cmpset_int(). sys/mbuf.h: Maybe it is better to fix the integer type of ext_cnt to be able to use it for uma_find_refcnt(). --- sys/net/ifq.h | 16 ++++++++-------- sys/sys/buf_ring.h | 9 +++++---- sys/sys/mbuf.h | 17 +++++++++-------- 3 files changed, 22 insertions(+), 20 deletions(-) diff --git a/sys/net/ifq.h b/sys/net/ifq.h index cf0c506..c970443 100644 --- a/sys/net/ifq.h +++ b/sys/net/ifq.h @@ -332,7 +332,7 @@ drbr_enqueue(struct ifnet *ifp, struct buf_ring *br, struct mbuf *m) } static __inline void -drbr_putback(struct ifnet *ifp, struct buf_ring *br, struct mbuf *new) +drbr_putback(struct ifnet *ifp, struct buf_ring *br, struct mbuf *new_mbuf) { /* * The top of the list needs to be swapped @@ -344,11 +344,11 @@ drbr_putback(struct ifnet *ifp, struct buf_ring *br, struct mbuf *new) * Peek in altq case dequeued it * so put it back. */ - IFQ_DRV_PREPEND(&ifp->if_snd, new); + IFQ_DRV_PREPEND(&ifp->if_snd, new_mbuf); return; } #endif - buf_ring_putback_sc(br, new); + buf_ring_putback_sc(br, new_mbuf); } static __inline struct mbuf * @@ -367,7 +367,7 @@ drbr_peek(struct ifnet *ifp, struct buf_ring *br) return (m); } #endif - return(buf_ring_peek(br)); + return ((struct mbuf *)buf_ring_peek(br)); } static __inline void @@ -379,7 +379,7 @@ drbr_flush(struct ifnet *ifp, struct buf_ring *br) if (ifp != NULL && ALTQ_IS_ENABLED(&ifp->if_snd)) IFQ_PURGE(&ifp->if_snd); #endif - while ((m = buf_ring_dequeue_sc(br)) != NULL) + while ((m = (struct mbuf *)buf_ring_dequeue_sc(br)) != NULL) m_freem(m); } @@ -402,7 +402,7 @@ drbr_dequeue(struct ifnet *ifp, struct buf_ring *br) return (m); } #endif - return (buf_ring_dequeue_sc(br)); + return ((struct mbuf *)buf_ring_dequeue_sc(br)); } static __inline void @@ -435,11 +435,11 @@ drbr_dequeue_cond(struct ifnet *ifp, struct buf_ring *br, return (m); } #endif - m = buf_ring_peek(br); + m = (struct mbuf *)buf_ring_peek(br); if (m == NULL || func(m, arg) == 0) return (NULL); - return (buf_ring_dequeue_sc(br)); + return ((struct mbuf *)buf_ring_dequeue_sc(br)); } static __inline int diff --git a/sys/sys/buf_ring.h b/sys/sys/buf_ring.h index a46aa2d..934f1a7 100644 --- a/sys/sys/buf_ring.h +++ b/sys/sys/buf_ring.h @@ -86,7 +86,8 @@ buf_ring_enqueue(struct buf_ring *br, void *buf) critical_exit(); return (ENOBUFS); } - } while (!atomic_cmpset_int(&br->br_prod_head, prod_head, prod_next)); + } while (!atomic_cmpset_int((volatile int *)&br->br_prod_head, + prod_head, prod_next)); #ifdef DEBUG_BUFRING if (br->br_ring[prod_head] != NULL) panic("dangling value in enqueue"); @@ -135,7 +136,7 @@ buf_ring_dequeue_mc(struct buf_ring *br) return (NULL); } - success = atomic_cmpset_int(&br->br_cons_head, cons_head, + success = atomic_cmpset_int((volatile int *)&br->br_cons_head, cons_head, cons_next); } while (success == 0); @@ -253,11 +254,11 @@ buf_ring_advance_sc(struct buf_ring *br) * the compare and an atomic. */ static __inline void -buf_ring_putback_sc(struct buf_ring *br, void *new) +buf_ring_putback_sc(struct buf_ring *br, void *new_item) { KASSERT(br->br_cons_head != br->br_prod_tail, ("Buf-Ring has none in putback")) ; - br->br_ring[br->br_cons_head] = new; + br->br_ring[br->br_cons_head] = new_item; } /* diff --git a/sys/sys/mbuf.h b/sys/sys/mbuf.h index d3e6ce0..960636b 100644 --- a/sys/sys/mbuf.h +++ b/sys/sys/mbuf.h @@ -627,7 +627,7 @@ m_get(int how, short type) args.flags = 0; args.type = type; - return (uma_zalloc_arg(zone_mbuf, &args, how)); + return ((struct mbuf *)uma_zalloc_arg(zone_mbuf, &args, how)); } /* @@ -641,7 +641,7 @@ m_getclr(int how, short type) args.flags = 0; args.type = type; - m = uma_zalloc_arg(zone_mbuf, &args, how); + m = (struct mbuf *)uma_zalloc_arg(zone_mbuf, &args, how); if (m != NULL) bzero(m->m_data, MLEN); return (m); @@ -654,7 +654,7 @@ m_gethdr(int how, short type) args.flags = M_PKTHDR; args.type = type; - return (uma_zalloc_arg(zone_mbuf, &args, how)); + return ((struct mbuf *)uma_zalloc_arg(zone_mbuf, &args, how)); } static __inline struct mbuf * @@ -664,7 +664,7 @@ m_getcl(int how, short type, int flags) args.flags = flags; args.type = type; - return (uma_zalloc_arg(zone_pack, &args, how)); + return ((struct mbuf *)uma_zalloc_arg(zone_pack, &args, how)); } static __inline void @@ -703,7 +703,7 @@ m_cljget(struct mbuf *m, int how, int size) m->m_ext.ext_buf = NULL; zone = m_getzone(size); - return (uma_zalloc_arg(zone, m, how)); + return ((struct mbuf *)uma_zalloc_arg(zone, m, how)); } static __inline void @@ -736,12 +736,13 @@ m_cljset(struct mbuf *m, void *cl, int type) break; } - m->m_data = m->m_ext.ext_buf = cl; - m->m_ext.ext_free = m->m_ext.ext_arg1 = m->m_ext.ext_arg2 = NULL; + m->m_data = m->m_ext.ext_buf = (caddr_t)cl; + m->m_ext.ext_free = NULL; + m->m_ext.ext_arg1 = m->m_ext.ext_arg2 = NULL; m->m_ext.ext_size = size; m->m_ext.ext_type = type; m->m_ext.ext_flags = 0; - m->m_ext.ext_cnt = uma_find_refcnt(zone, cl); + m->m_ext.ext_cnt = (u_int *)uma_find_refcnt(zone, cl); m->m_flags |= M_EXT; } -- 1.8.4.5 From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 17 11:27:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C09F86B for ; Wed, 17 Sep 2014 11:27:14 +0000 (UTC) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F15AF78 for ; Wed, 17 Sep 2014 11:27:14 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id fp1so1984063pdb.0 for ; Wed, 17 Sep 2014 04:27:14 -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:content-transfer-encoding; bh=4xbgvA/j23WWguSYrIt0yaTrECe16VrCNOdcUB0gfi8=; b=GaAmZ4QGKVzi3pG1E2RwSwBOrDugCnGJP4SROK+fkbTxhz4eXJrwxPlTF/HiioCIbg Q7xje2MK97Y706Dj+psclz+gwc6GcrA7Y6FSwxxkpopp9ZSVeXBRocZZ0bQj59OTjIQW b4i57JGLptIAlRg6lysv8UE906cYsP/KiyYNrszZzopqXhVaTH8P3LVepkaFSYOxse4U 7ZNmrn//lSM4A4YtO5ADyuCoaU+4N2nBKTkcaIjIjTSQfiLNm13ABjIFtGu6CnBwkLHm Cr22lNf4WbKS0wui646u5oOrcdKLAhKM51qFSzlk6ch4F4oGY9EXKEwLmrayL6dnqphm gclw== MIME-Version: 1.0 X-Received: by 10.68.109.5 with SMTP id ho5mr60758168pbb.13.1410953233936; Wed, 17 Sep 2014 04:27:13 -0700 (PDT) Received: by 10.66.82.37 with HTTP; Wed, 17 Sep 2014 04:27:13 -0700 (PDT) In-Reply-To: References: <220565922.34288992.1410298180362.JavaMail.root@uoguelph.ca> Date: Wed, 17 Sep 2014 13:27:13 +0200 Message-ID: Subject: Re: Tool to access ZFS/NFSv4 alternate data streams on FreeBSD? From: Simon Toedt To: Lionel Cons Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Freebsd hackers list , Richard Yao , Rick Macklem , Jordan Hubbard , Jan Bramkamp X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 11:27:14 -0000 On Mon, Sep 15, 2014 at 12:17 PM, Lionel Cons wr= ote: > On 12 September 2014 17:47, Simon Toedt wrote: >> On Fri, Sep 12, 2014 at 2:24 AM, Lionel Cons = wrote: >>> On 9 September 2014 23:29, Rick Macklem wrote: >>>> Simon Toedt wrote: >>>>> On Tue, Sep 9, 2014 at 1:47 PM, Rick Macklem >>>>> wrote: >>>>> > Jordan Hubbard wrote: >>>>> >> Yep. I was just describing the experience that OS X went through >>>>> >> in >>>>> >> implementing extattrs / legacy resource fork support. To recap it >>>>> >> very briefly: Having NFSv4 support extattrs (or even named >>>>> >> streams, >>>>> >> if you want to go that far) is the comparatively easy part. It=E2= =80=99s >>>>> >> backing them up / copying them around that gets more involved, and >>>>> >> if you can=E2=80=99t back up certain attributes then you=E2=80=99r= e not likely to >>>>> >> get anyone to want to use them, at which point the whole =E2=80=9C= sharing=E2=80=9D >>>>> >> aspect kind of takes a back seat. >>>>> >> >>>>> > Yep. I strongly suspect you are correct. >>>>> > >>>>> > The question then becomes: >>>>> > - Do we wait and see if someone chooses to get around to doing all >>>>> > the hard userland work. >>>>> >>>>> Solaris tools already have support for this. Also AT&T AST from David >>>>> Korn have support for O_XATTR, too. >>>>> >>>> Hopefully others will correct me if I have this incorrect, but I thoug= ht >>>> CDDL code could only be used for optional components of FreeBSD? >>>> I suspect tar and friends are considered core components and that code >>>> for this would have to be written by someone (ie. couldn't use CDDL co= de?). >>>> (I'm assuming that these tools are in OpenSolaris.) >>> >>> I don't think you FreeBSD should *copy* the code. But it can be used >>> for reference how the extended tar headers for filesystem forks should >>> look like. That's all. >>> >>>> >>>> Be aware that most of FreeBSD's development is done by volunteers in t= heir >>>> spare time, so I have no idea if someone is interested in doing this. >>> >>> If anyone can get the kernel parts I think we can sponsor someone to >>> do the userland work. >> >> How much money would CERN offer? :) >> >> Simon > > Depends. First I need to have more support (2nd funding pillar) and > then write a proposal. Short: Paperwork. Long: More paperwork. > But given the number of projects here which rely on O_XATTR there > isn't a way around it so funding should be easy to obtain. Our institute volunteers for testing! is there a task or todo list yet? Simon From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 17 15:41:56 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00DE7F0 for ; Wed, 17 Sep 2014 15:41:55 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 D3457E2A for ; Wed, 17 Sep 2014 15:41:55 +0000 (UTC) Received: from [192.168.200.200] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 722A819413C; Wed, 17 Sep 2014 15:41:53 +0000 (UTC) Subject: Re: [PATCH] C++ compatibility for some kernel headers From: Sean Bruno Reply-To: sbruno@freebsd.org To: Sebastian Huber In-Reply-To: <1410952389-30368-1-git-send-email-sebastian.huber@embedded-brains.de> References: <1410952389-30368-1-git-send-email-sebastian.huber@embedded-brains.de> Content-Type: text/plain; charset="us-ascii" Date: Wed, 17 Sep 2014 08:41:51 -0700 Message-ID: <1410968511.1166.30.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 15:41:56 -0000 On Wed, 2014-09-17 at 13:13 +0200, Sebastian Huber wrote: > We ported the FreeBSD network stack to RTEMS. Some users want to write > network interface drivers in C++. It would be nice if we can make some > FreeBSD kernel headers C++ compatible. > Want to post this over to freebsd-arch@ so you can experience a full "bikeshed" over this? :-) But seriously, freebsd-arch@ is a good place to discuss things that change behavior and capabilites (not bug fixes) and this patch definitely seems to need a good once over. sean > sys/buf_ring.h: > > Mabye it is better to fix the integer type of br_cons_head to be able to > use it in atomic_cmpset_int(). > > sys/mbuf.h: > > Maybe it is better to fix the integer type of ext_cnt to be able to use > it for uma_find_refcnt(). > --- > sys/net/ifq.h | 16 ++++++++-------- > sys/sys/buf_ring.h | 9 +++++---- > sys/sys/mbuf.h | 17 +++++++++-------- > 3 files changed, 22 insertions(+), 20 deletions(-) > > diff --git a/sys/net/ifq.h b/sys/net/ifq.h > index cf0c506..c970443 100644 > --- a/sys/net/ifq.h > +++ b/sys/net/ifq.h > @@ -332,7 +332,7 @@ drbr_enqueue(struct ifnet *ifp, struct buf_ring *br, struct mbuf *m) > } > > static __inline void > -drbr_putback(struct ifnet *ifp, struct buf_ring *br, struct mbuf *new) > +drbr_putback(struct ifnet *ifp, struct buf_ring *br, struct mbuf *new_mbuf) > { > /* > * The top of the list needs to be swapped > @@ -344,11 +344,11 @@ drbr_putback(struct ifnet *ifp, struct buf_ring *br, struct mbuf *new) > * Peek in altq case dequeued it > * so put it back. > */ > - IFQ_DRV_PREPEND(&ifp->if_snd, new); > + IFQ_DRV_PREPEND(&ifp->if_snd, new_mbuf); > return; > } > #endif > - buf_ring_putback_sc(br, new); > + buf_ring_putback_sc(br, new_mbuf); > } > > static __inline struct mbuf * > @@ -367,7 +367,7 @@ drbr_peek(struct ifnet *ifp, struct buf_ring *br) > return (m); > } > #endif > - return(buf_ring_peek(br)); > + return ((struct mbuf *)buf_ring_peek(br)); > } > > static __inline void > @@ -379,7 +379,7 @@ drbr_flush(struct ifnet *ifp, struct buf_ring *br) > if (ifp != NULL && ALTQ_IS_ENABLED(&ifp->if_snd)) > IFQ_PURGE(&ifp->if_snd); > #endif > - while ((m = buf_ring_dequeue_sc(br)) != NULL) > + while ((m = (struct mbuf *)buf_ring_dequeue_sc(br)) != NULL) > m_freem(m); > } > > @@ -402,7 +402,7 @@ drbr_dequeue(struct ifnet *ifp, struct buf_ring *br) > return (m); > } > #endif > - return (buf_ring_dequeue_sc(br)); > + return ((struct mbuf *)buf_ring_dequeue_sc(br)); > } > > static __inline void > @@ -435,11 +435,11 @@ drbr_dequeue_cond(struct ifnet *ifp, struct buf_ring *br, > return (m); > } > #endif > - m = buf_ring_peek(br); > + m = (struct mbuf *)buf_ring_peek(br); > if (m == NULL || func(m, arg) == 0) > return (NULL); > > - return (buf_ring_dequeue_sc(br)); > + return ((struct mbuf *)buf_ring_dequeue_sc(br)); > } > > static __inline int > diff --git a/sys/sys/buf_ring.h b/sys/sys/buf_ring.h > index a46aa2d..934f1a7 100644 > --- a/sys/sys/buf_ring.h > +++ b/sys/sys/buf_ring.h > @@ -86,7 +86,8 @@ buf_ring_enqueue(struct buf_ring *br, void *buf) > critical_exit(); > return (ENOBUFS); > } > - } while (!atomic_cmpset_int(&br->br_prod_head, prod_head, prod_next)); > + } while (!atomic_cmpset_int((volatile int *)&br->br_prod_head, > + prod_head, prod_next)); > #ifdef DEBUG_BUFRING > if (br->br_ring[prod_head] != NULL) > panic("dangling value in enqueue"); > @@ -135,7 +136,7 @@ buf_ring_dequeue_mc(struct buf_ring *br) > return (NULL); > } > > - success = atomic_cmpset_int(&br->br_cons_head, cons_head, > + success = atomic_cmpset_int((volatile int *)&br->br_cons_head, cons_head, > cons_next); > } while (success == 0); > > @@ -253,11 +254,11 @@ buf_ring_advance_sc(struct buf_ring *br) > * the compare and an atomic. > */ > static __inline void > -buf_ring_putback_sc(struct buf_ring *br, void *new) > +buf_ring_putback_sc(struct buf_ring *br, void *new_item) > { > KASSERT(br->br_cons_head != br->br_prod_tail, > ("Buf-Ring has none in putback")) ; > - br->br_ring[br->br_cons_head] = new; > + br->br_ring[br->br_cons_head] = new_item; > } > > /* > diff --git a/sys/sys/mbuf.h b/sys/sys/mbuf.h > index d3e6ce0..960636b 100644 > --- a/sys/sys/mbuf.h > +++ b/sys/sys/mbuf.h > @@ -627,7 +627,7 @@ m_get(int how, short type) > > args.flags = 0; > args.type = type; > - return (uma_zalloc_arg(zone_mbuf, &args, how)); > + return ((struct mbuf *)uma_zalloc_arg(zone_mbuf, &args, how)); > } > > /* > @@ -641,7 +641,7 @@ m_getclr(int how, short type) > > args.flags = 0; > args.type = type; > - m = uma_zalloc_arg(zone_mbuf, &args, how); > + m = (struct mbuf *)uma_zalloc_arg(zone_mbuf, &args, how); > if (m != NULL) > bzero(m->m_data, MLEN); > return (m); > @@ -654,7 +654,7 @@ m_gethdr(int how, short type) > > args.flags = M_PKTHDR; > args.type = type; > - return (uma_zalloc_arg(zone_mbuf, &args, how)); > + return ((struct mbuf *)uma_zalloc_arg(zone_mbuf, &args, how)); > } > > static __inline struct mbuf * > @@ -664,7 +664,7 @@ m_getcl(int how, short type, int flags) > > args.flags = flags; > args.type = type; > - return (uma_zalloc_arg(zone_pack, &args, how)); > + return ((struct mbuf *)uma_zalloc_arg(zone_pack, &args, how)); > } > > static __inline void > @@ -703,7 +703,7 @@ m_cljget(struct mbuf *m, int how, int size) > m->m_ext.ext_buf = NULL; > > zone = m_getzone(size); > - return (uma_zalloc_arg(zone, m, how)); > + return ((struct mbuf *)uma_zalloc_arg(zone, m, how)); > } > > static __inline void > @@ -736,12 +736,13 @@ m_cljset(struct mbuf *m, void *cl, int type) > break; > } > > - m->m_data = m->m_ext.ext_buf = cl; > - m->m_ext.ext_free = m->m_ext.ext_arg1 = m->m_ext.ext_arg2 = NULL; > + m->m_data = m->m_ext.ext_buf = (caddr_t)cl; > + m->m_ext.ext_free = NULL; > + m->m_ext.ext_arg1 = m->m_ext.ext_arg2 = NULL; > m->m_ext.ext_size = size; > m->m_ext.ext_type = type; > m->m_ext.ext_flags = 0; > - m->m_ext.ext_cnt = uma_find_refcnt(zone, cl); > + m->m_ext.ext_cnt = (u_int *)uma_find_refcnt(zone, cl); > m->m_flags |= M_EXT; > > } From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 17 17:37:26 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 455B6815 for ; Wed, 17 Sep 2014 17:37:26 +0000 (UTC) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C7D0DD76 for ; Wed, 17 Sep 2014 17:37:25 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id m15so1759236wgh.8 for ; Wed, 17 Sep 2014 10:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=hjbAXen3BqFPlbNKaHysvdMV3Xbf6FbxFEjnsTAYJJQ=; b=drDx/vHzXfJx06AJMRvGe58hBAvfJZYD9MZU+z6bqFIt3UHMmRtkS853NwCtVwrE++ GwJ9Vi0qkLAHhWu9ijknuGHAnSsKcCoy+7pXCppA4eRtufqDPWN35io7Y41RgqJzbZy4 uPg9v48gtr0IQKOosoGu9ifNcYy7p8xyNRdPNvMemPbZ6x30Dc7JoPgcoI0TS1zUKXxL RhcsFXAvheQaFZ+fnTACHSmDYSLK8LI01lRI1hnjfbm3ircrD3DPuLhvNz4EJ1G8cEwi rkBTDX3ISv1LtecUBcvEPu9gkT8+n1RTTQgJsZup4TWKB+SFryBBlJZQjj9wWrRiFNWz k3xA== MIME-Version: 1.0 X-Received: by 10.194.58.41 with SMTP id n9mr4301057wjq.20.1410975444033; Wed, 17 Sep 2014 10:37:24 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.199 with HTTP; Wed, 17 Sep 2014 10:37:23 -0700 (PDT) In-Reply-To: <1410952389-30368-1-git-send-email-sebastian.huber@embedded-brains.de> References: <1410952389-30368-1-git-send-email-sebastian.huber@embedded-brains.de> Date: Wed, 17 Sep 2014 10:37:23 -0700 X-Google-Sender-Auth: e0MraDof6qw9DsPj_r-UxLS9188 Message-ID: Subject: Re: [PATCH] C++ compatibility for some kernel headers From: Adrian Chadd To: Sebastian Huber Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 17:37:26 -0000 Hi! This is of interest to me at ${WORK}. So please do file a PR (https://bugs.freebsd.org/submit/) and I'll make sure we fix -HEAD up to do this. Thanks! -a On 17 September 2014 04:13, Sebastian Huber wrote: > We ported the FreeBSD network stack to RTEMS. Some users want to write > network interface drivers in C++. It would be nice if we can make some > FreeBSD kernel headers C++ compatible. > > sys/buf_ring.h: > > Mabye it is better to fix the integer type of br_cons_head to be able to > use it in atomic_cmpset_int(). > > sys/mbuf.h: > > Maybe it is better to fix the integer type of ext_cnt to be able to use > it for uma_find_refcnt(). > --- > sys/net/ifq.h | 16 ++++++++-------- > sys/sys/buf_ring.h | 9 +++++---- > sys/sys/mbuf.h | 17 +++++++++-------- > 3 files changed, 22 insertions(+), 20 deletions(-) > > diff --git a/sys/net/ifq.h b/sys/net/ifq.h > index cf0c506..c970443 100644 > --- a/sys/net/ifq.h > +++ b/sys/net/ifq.h > @@ -332,7 +332,7 @@ drbr_enqueue(struct ifnet *ifp, struct buf_ring *br, struct mbuf *m) > } > > static __inline void > -drbr_putback(struct ifnet *ifp, struct buf_ring *br, struct mbuf *new) > +drbr_putback(struct ifnet *ifp, struct buf_ring *br, struct mbuf *new_mbuf) > { > /* > * The top of the list needs to be swapped > @@ -344,11 +344,11 @@ drbr_putback(struct ifnet *ifp, struct buf_ring *br, struct mbuf *new) > * Peek in altq case dequeued it > * so put it back. > */ > - IFQ_DRV_PREPEND(&ifp->if_snd, new); > + IFQ_DRV_PREPEND(&ifp->if_snd, new_mbuf); > return; > } > #endif > - buf_ring_putback_sc(br, new); > + buf_ring_putback_sc(br, new_mbuf); > } > > static __inline struct mbuf * > @@ -367,7 +367,7 @@ drbr_peek(struct ifnet *ifp, struct buf_ring *br) > return (m); > } > #endif > - return(buf_ring_peek(br)); > + return ((struct mbuf *)buf_ring_peek(br)); > } > > static __inline void > @@ -379,7 +379,7 @@ drbr_flush(struct ifnet *ifp, struct buf_ring *br) > if (ifp != NULL && ALTQ_IS_ENABLED(&ifp->if_snd)) > IFQ_PURGE(&ifp->if_snd); > #endif > - while ((m = buf_ring_dequeue_sc(br)) != NULL) > + while ((m = (struct mbuf *)buf_ring_dequeue_sc(br)) != NULL) > m_freem(m); > } > > @@ -402,7 +402,7 @@ drbr_dequeue(struct ifnet *ifp, struct buf_ring *br) > return (m); > } > #endif > - return (buf_ring_dequeue_sc(br)); > + return ((struct mbuf *)buf_ring_dequeue_sc(br)); > } > > static __inline void > @@ -435,11 +435,11 @@ drbr_dequeue_cond(struct ifnet *ifp, struct buf_ring *br, > return (m); > } > #endif > - m = buf_ring_peek(br); > + m = (struct mbuf *)buf_ring_peek(br); > if (m == NULL || func(m, arg) == 0) > return (NULL); > > - return (buf_ring_dequeue_sc(br)); > + return ((struct mbuf *)buf_ring_dequeue_sc(br)); > } > > static __inline int > diff --git a/sys/sys/buf_ring.h b/sys/sys/buf_ring.h > index a46aa2d..934f1a7 100644 > --- a/sys/sys/buf_ring.h > +++ b/sys/sys/buf_ring.h > @@ -86,7 +86,8 @@ buf_ring_enqueue(struct buf_ring *br, void *buf) > critical_exit(); > return (ENOBUFS); > } > - } while (!atomic_cmpset_int(&br->br_prod_head, prod_head, prod_next)); > + } while (!atomic_cmpset_int((volatile int *)&br->br_prod_head, > + prod_head, prod_next)); > #ifdef DEBUG_BUFRING > if (br->br_ring[prod_head] != NULL) > panic("dangling value in enqueue"); > @@ -135,7 +136,7 @@ buf_ring_dequeue_mc(struct buf_ring *br) > return (NULL); > } > > - success = atomic_cmpset_int(&br->br_cons_head, cons_head, > + success = atomic_cmpset_int((volatile int *)&br->br_cons_head, cons_head, > cons_next); > } while (success == 0); > > @@ -253,11 +254,11 @@ buf_ring_advance_sc(struct buf_ring *br) > * the compare and an atomic. > */ > static __inline void > -buf_ring_putback_sc(struct buf_ring *br, void *new) > +buf_ring_putback_sc(struct buf_ring *br, void *new_item) > { > KASSERT(br->br_cons_head != br->br_prod_tail, > ("Buf-Ring has none in putback")) ; > - br->br_ring[br->br_cons_head] = new; > + br->br_ring[br->br_cons_head] = new_item; > } > > /* > diff --git a/sys/sys/mbuf.h b/sys/sys/mbuf.h > index d3e6ce0..960636b 100644 > --- a/sys/sys/mbuf.h > +++ b/sys/sys/mbuf.h > @@ -627,7 +627,7 @@ m_get(int how, short type) > > args.flags = 0; > args.type = type; > - return (uma_zalloc_arg(zone_mbuf, &args, how)); > + return ((struct mbuf *)uma_zalloc_arg(zone_mbuf, &args, how)); > } > > /* > @@ -641,7 +641,7 @@ m_getclr(int how, short type) > > args.flags = 0; > args.type = type; > - m = uma_zalloc_arg(zone_mbuf, &args, how); > + m = (struct mbuf *)uma_zalloc_arg(zone_mbuf, &args, how); > if (m != NULL) > bzero(m->m_data, MLEN); > return (m); > @@ -654,7 +654,7 @@ m_gethdr(int how, short type) > > args.flags = M_PKTHDR; > args.type = type; > - return (uma_zalloc_arg(zone_mbuf, &args, how)); > + return ((struct mbuf *)uma_zalloc_arg(zone_mbuf, &args, how)); > } > > static __inline struct mbuf * > @@ -664,7 +664,7 @@ m_getcl(int how, short type, int flags) > > args.flags = flags; > args.type = type; > - return (uma_zalloc_arg(zone_pack, &args, how)); > + return ((struct mbuf *)uma_zalloc_arg(zone_pack, &args, how)); > } > > static __inline void > @@ -703,7 +703,7 @@ m_cljget(struct mbuf *m, int how, int size) > m->m_ext.ext_buf = NULL; > > zone = m_getzone(size); > - return (uma_zalloc_arg(zone, m, how)); > + return ((struct mbuf *)uma_zalloc_arg(zone, m, how)); > } > > static __inline void > @@ -736,12 +736,13 @@ m_cljset(struct mbuf *m, void *cl, int type) > break; > } > > - m->m_data = m->m_ext.ext_buf = cl; > - m->m_ext.ext_free = m->m_ext.ext_arg1 = m->m_ext.ext_arg2 = NULL; > + m->m_data = m->m_ext.ext_buf = (caddr_t)cl; > + m->m_ext.ext_free = NULL; > + m->m_ext.ext_arg1 = m->m_ext.ext_arg2 = NULL; > m->m_ext.ext_size = size; > m->m_ext.ext_type = type; > m->m_ext.ext_flags = 0; > - m->m_ext.ext_cnt = uma_find_refcnt(zone, cl); > + m->m_ext.ext_cnt = (u_int *)uma_find_refcnt(zone, cl); > m->m_flags |= M_EXT; > > } > -- > 1.8.4.5 > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 17 18:47:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6C0C569; Wed, 17 Sep 2014 18:47:02 +0000 (UTC) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id 9FBC3840; Wed, 17 Sep 2014 18:47:02 +0000 (UTC) Received: from marvin.lab.vangyzen.net (c-24-125-214-90.hsd1.va.comcast.net [24.125.214.90]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 6666A56449; Wed, 17 Sep 2014 13:47:01 -0500 (CDT) Message-ID: <5419D724.6000601@vangyzen.net> Date: Wed, 17 Sep 2014 14:47:00 -0400 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Adrian Chadd , Sebastian Huber Subject: Re: [PATCH] C++ compatibility for some kernel headers References: <1410952389-30368-1-git-send-email-sebastian.huber@embedded-brains.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 18:47:02 -0000 While we're on the topic, I'd like to see the definition of struct prf_ra moved outside the definition of struct in6_prflags in netinet6/in6_var.h, in order to play nicely with C++ scoping. I'll whip up a patch, if anyone would like. Eric On 09/17/2014 13:37, Adrian Chadd wrote: > Hi! > > This is of interest to me at ${WORK}. > > So please do file a PR (https://bugs.freebsd.org/submit/) and I'll > make sure we fix -HEAD up to do this. > > Thanks! > > -a > > > On 17 September 2014 04:13, Sebastian Huber > wrote: >> We ported the FreeBSD network stack to RTEMS. Some users want to write >> network interface drivers in C++. It would be nice if we can make some >> FreeBSD kernel headers C++ compatible. >> >> sys/buf_ring.h: >> >> Mabye it is better to fix the integer type of br_cons_head to be able to >> use it in atomic_cmpset_int(). >> >> sys/mbuf.h: >> >> Maybe it is better to fix the integer type of ext_cnt to be able to use >> it for uma_find_refcnt(). >> --- >> sys/net/ifq.h | 16 ++++++++-------- >> sys/sys/buf_ring.h | 9 +++++---- >> sys/sys/mbuf.h | 17 +++++++++-------- >> 3 files changed, 22 insertions(+), 20 deletions(-) >> >> diff --git a/sys/net/ifq.h b/sys/net/ifq.h >> index cf0c506..c970443 100644 >> --- a/sys/net/ifq.h >> +++ b/sys/net/ifq.h >> @@ -332,7 +332,7 @@ drbr_enqueue(struct ifnet *ifp, struct buf_ring *br, struct mbuf *m) >> } >> >> static __inline void >> -drbr_putback(struct ifnet *ifp, struct buf_ring *br, struct mbuf *new) >> +drbr_putback(struct ifnet *ifp, struct buf_ring *br, struct mbuf *new_mbuf) >> { >> /* >> * The top of the list needs to be swapped >> @@ -344,11 +344,11 @@ drbr_putback(struct ifnet *ifp, struct buf_ring *br, struct mbuf *new) >> * Peek in altq case dequeued it >> * so put it back. >> */ >> - IFQ_DRV_PREPEND(&ifp->if_snd, new); >> + IFQ_DRV_PREPEND(&ifp->if_snd, new_mbuf); >> return; >> } >> #endif >> - buf_ring_putback_sc(br, new); >> + buf_ring_putback_sc(br, new_mbuf); >> } >> >> static __inline struct mbuf * >> @@ -367,7 +367,7 @@ drbr_peek(struct ifnet *ifp, struct buf_ring *br) >> return (m); >> } >> #endif >> - return(buf_ring_peek(br)); >> + return ((struct mbuf *)buf_ring_peek(br)); >> } >> >> static __inline void >> @@ -379,7 +379,7 @@ drbr_flush(struct ifnet *ifp, struct buf_ring *br) >> if (ifp != NULL && ALTQ_IS_ENABLED(&ifp->if_snd)) >> IFQ_PURGE(&ifp->if_snd); >> #endif >> - while ((m = buf_ring_dequeue_sc(br)) != NULL) >> + while ((m = (struct mbuf *)buf_ring_dequeue_sc(br)) != NULL) >> m_freem(m); >> } >> >> @@ -402,7 +402,7 @@ drbr_dequeue(struct ifnet *ifp, struct buf_ring *br) >> return (m); >> } >> #endif >> - return (buf_ring_dequeue_sc(br)); >> + return ((struct mbuf *)buf_ring_dequeue_sc(br)); >> } >> >> static __inline void >> @@ -435,11 +435,11 @@ drbr_dequeue_cond(struct ifnet *ifp, struct buf_ring *br, >> return (m); >> } >> #endif >> - m = buf_ring_peek(br); >> + m = (struct mbuf *)buf_ring_peek(br); >> if (m == NULL || func(m, arg) == 0) >> return (NULL); >> >> - return (buf_ring_dequeue_sc(br)); >> + return ((struct mbuf *)buf_ring_dequeue_sc(br)); >> } >> >> static __inline int >> diff --git a/sys/sys/buf_ring.h b/sys/sys/buf_ring.h >> index a46aa2d..934f1a7 100644 >> --- a/sys/sys/buf_ring.h >> +++ b/sys/sys/buf_ring.h >> @@ -86,7 +86,8 @@ buf_ring_enqueue(struct buf_ring *br, void *buf) >> critical_exit(); >> return (ENOBUFS); >> } >> - } while (!atomic_cmpset_int(&br->br_prod_head, prod_head, prod_next)); >> + } while (!atomic_cmpset_int((volatile int *)&br->br_prod_head, >> + prod_head, prod_next)); >> #ifdef DEBUG_BUFRING >> if (br->br_ring[prod_head] != NULL) >> panic("dangling value in enqueue"); >> @@ -135,7 +136,7 @@ buf_ring_dequeue_mc(struct buf_ring *br) >> return (NULL); >> } >> >> - success = atomic_cmpset_int(&br->br_cons_head, cons_head, >> + success = atomic_cmpset_int((volatile int *)&br->br_cons_head, cons_head, >> cons_next); >> } while (success == 0); >> >> @@ -253,11 +254,11 @@ buf_ring_advance_sc(struct buf_ring *br) >> * the compare and an atomic. >> */ >> static __inline void >> -buf_ring_putback_sc(struct buf_ring *br, void *new) >> +buf_ring_putback_sc(struct buf_ring *br, void *new_item) >> { >> KASSERT(br->br_cons_head != br->br_prod_tail, >> ("Buf-Ring has none in putback")) ; >> - br->br_ring[br->br_cons_head] = new; >> + br->br_ring[br->br_cons_head] = new_item; >> } >> >> /* >> diff --git a/sys/sys/mbuf.h b/sys/sys/mbuf.h >> index d3e6ce0..960636b 100644 >> --- a/sys/sys/mbuf.h >> +++ b/sys/sys/mbuf.h >> @@ -627,7 +627,7 @@ m_get(int how, short type) >> >> args.flags = 0; >> args.type = type; >> - return (uma_zalloc_arg(zone_mbuf, &args, how)); >> + return ((struct mbuf *)uma_zalloc_arg(zone_mbuf, &args, how)); >> } >> >> /* >> @@ -641,7 +641,7 @@ m_getclr(int how, short type) >> >> args.flags = 0; >> args.type = type; >> - m = uma_zalloc_arg(zone_mbuf, &args, how); >> + m = (struct mbuf *)uma_zalloc_arg(zone_mbuf, &args, how); >> if (m != NULL) >> bzero(m->m_data, MLEN); >> return (m); >> @@ -654,7 +654,7 @@ m_gethdr(int how, short type) >> >> args.flags = M_PKTHDR; >> args.type = type; >> - return (uma_zalloc_arg(zone_mbuf, &args, how)); >> + return ((struct mbuf *)uma_zalloc_arg(zone_mbuf, &args, how)); >> } >> >> static __inline struct mbuf * >> @@ -664,7 +664,7 @@ m_getcl(int how, short type, int flags) >> >> args.flags = flags; >> args.type = type; >> - return (uma_zalloc_arg(zone_pack, &args, how)); >> + return ((struct mbuf *)uma_zalloc_arg(zone_pack, &args, how)); >> } >> >> static __inline void >> @@ -703,7 +703,7 @@ m_cljget(struct mbuf *m, int how, int size) >> m->m_ext.ext_buf = NULL; >> >> zone = m_getzone(size); >> - return (uma_zalloc_arg(zone, m, how)); >> + return ((struct mbuf *)uma_zalloc_arg(zone, m, how)); >> } >> >> static __inline void >> @@ -736,12 +736,13 @@ m_cljset(struct mbuf *m, void *cl, int type) >> break; >> } >> >> - m->m_data = m->m_ext.ext_buf = cl; >> - m->m_ext.ext_free = m->m_ext.ext_arg1 = m->m_ext.ext_arg2 = NULL; >> + m->m_data = m->m_ext.ext_buf = (caddr_t)cl; >> + m->m_ext.ext_free = NULL; >> + m->m_ext.ext_arg1 = m->m_ext.ext_arg2 = NULL; >> m->m_ext.ext_size = size; >> m->m_ext.ext_type = type; >> m->m_ext.ext_flags = 0; >> - m->m_ext.ext_cnt = uma_find_refcnt(zone, cl); >> + m->m_ext.ext_cnt = (u_int *)uma_find_refcnt(zone, cl); >> m->m_flags |= M_EXT; >> >> } >> -- >> 1.8.4.5 >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 17 18:46:28 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E92F355E for ; Wed, 17 Sep 2014 18:46:28 +0000 (UTC) Received: from sender1.zohomail.com (sender1.zohomail.com [74.201.84.155]) by mx1.freebsd.org (Postfix) with ESMTP id CFF48836 for ; Wed, 17 Sep 2014 18:46:28 +0000 (UTC) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by mx.zohomail.com with SMTPS id 1410979586655828.3542318562128; Wed, 17 Sep 2014 11:46:26 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id uy5so60263obc.31 for ; Wed, 17 Sep 2014 11:46:25 -0700 (PDT) Received: by 10.76.9.225 with HTTP; Wed, 17 Sep 2014 11:45:45 -0700 (PDT) X-Received: by 10.182.103.165 with SMTP id fx5mr20907312obb.61.1410979585763; Wed, 17 Sep 2014 11:46:25 -0700 (PDT) MIME-Version: 1.0 From: Mohammad Shokri Date: Wed, 17 Sep 2014 23:15:45 +0430 Message-ID: Subject: Stack Exchange Q&A site proposal: *BSD To: freebsd-hackers@freebsd.org X-ZohoMailClient: External X-Zoho-Virus-Status: 2 X-Mailman-Approved-At: Wed, 17 Sep 2014 20:39:10 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 18:46:29 -0000 Hi! I'm supporting a proposal to create a new Q&A website for users of BSD Variants: FreeBSD, OpenBSD, NetBSD, DragonFly, FreeNAS, PC-BSD, TrueBSD and so on. It's built on the same software as stackoverflow.com, a hugely popular site where over seven million programmers help each other with difficult programming problems. On Stack Overflow the audience votes for the best answer, so the answer you want is usually right at the top, not on page five. I'm hoping that a site for users of BSD Variants: FreeBSD, OpenBSD, NetBSD, DragonFly, FreeNAS, PC-BSD, TrueBSD and so on would have the same kind of network effect and turn into an amazing resource. The proposal process is going on here: http://area51.stackexchange.com/proposals/76823/bsd?referrer=0reUHvY9WBao7tQ8CcbOfA2 If you're interested in participating, go to that URL and click on the orange "Follow It!" button. Thanks! From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 17 23:18:39 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3FBCF5C2 for ; Wed, 17 Sep 2014 23:18:39 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 03253834 for ; Wed, 17 Sep 2014 23:18:38 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoEAH8VGlSDaFve/2dsb2JhbABhg2BXBIJ8xjAKhnlUAYEuAXmEAwEBAQMBAQEBICsgCwUWGAICDRkCIwYBCSYGCAcEARwEiAkDCQgNqVCObA2HJwEXgSyMHoFcAQEbATMHgjdBEoFBBZYFhAN0g3CKToJYhkKDeiEvB4EIOYECAQEB X-IronPort-AV: E=Sophos;i="5.04,542,1406606400"; d="scan'208";a="155887793" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 17 Sep 2014 19:18:32 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id DFB6CB4037; Wed, 17 Sep 2014 19:18:31 -0400 (EDT) Date: Wed, 17 Sep 2014 19:18:31 -0400 (EDT) From: Rick Macklem To: Simon Toedt Message-ID: <102210795.47541414.1410995911907.JavaMail.root@uoguelph.ca> In-Reply-To: Subject: Re: Tool to access ZFS/NFSv4 alternate data streams on FreeBSD? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: Freebsd hackers list , Richard Yao , Lionel Cons , Jordan Hubbard , Jan Bramkamp X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 23:18:39 -0000 Simon Toedt wrote: > On Mon, Sep 15, 2014 at 12:17 PM, Lionel Cons > wrote: > > On 12 September 2014 17:47, Simon Toedt > > wrote: > >> On Fri, Sep 12, 2014 at 2:24 AM, Lionel Cons > >> wrote: > >>> On 9 September 2014 23:29, Rick Macklem > >>> wrote: > >>>> Simon Toedt wrote: > >>>>> On Tue, Sep 9, 2014 at 1:47 PM, Rick Macklem > >>>>> > >>>>> wrote: > >>>>> > Jordan Hubbard wrote: > >>>>> >> Yep. I was just describing the experience that OS X went > >>>>> >> through > >>>>> >> in > >>>>> >> implementing extattrs / legacy resource fork support. To > >>>>> >> recap it > >>>>> >> very briefly: Having NFSv4 support extattrs (or even named > >>>>> >> streams, > >>>>> >> if you want to go that far) is the comparatively easy part. > >>>>> >> It=E2=80=99s > >>>>> >> backing them up / copying them around that gets more > >>>>> >> involved, and > >>>>> >> if you can=E2=80=99t back up certain attributes then you=E2=80= =99re not > >>>>> >> likely to > >>>>> >> get anyone to want to use them, at which point the whole > >>>>> >> =E2=80=9Csharing=E2=80=9D > >>>>> >> aspect kind of takes a back seat. > >>>>> >> > >>>>> > Yep. I strongly suspect you are correct. > >>>>> > > >>>>> > The question then becomes: > >>>>> > - Do we wait and see if someone chooses to get around to > >>>>> > doing all > >>>>> > the hard userland work. > >>>>> > >>>>> Solaris tools already have support for this. Also AT&T AST from > >>>>> David > >>>>> Korn have support for O_XATTR, too. > >>>>> > >>>> Hopefully others will correct me if I have this incorrect, but I > >>>> thought > >>>> CDDL code could only be used for optional components of FreeBSD? > >>>> I suspect tar and friends are considered core components and > >>>> that code > >>>> for this would have to be written by someone (ie. couldn't use > >>>> CDDL code?). > >>>> (I'm assuming that these tools are in OpenSolaris.) > >>> > >>> I don't think you FreeBSD should *copy* the code. But it can be > >>> used > >>> for reference how the extended tar headers for filesystem forks > >>> should > >>> look like. That's all. > >>> > >>>> > >>>> Be aware that most of FreeBSD's development is done by > >>>> volunteers in their > >>>> spare time, so I have no idea if someone is interested in doing > >>>> this. > >>> > >>> If anyone can get the kernel parts I think we can sponsor someone > >>> to > >>> do the userland work. > >> > >> How much money would CERN offer? :) > >> > >> Simon > > > > Depends. First I need to have more support (2nd funding pillar) and > > then write a proposal. Short: Paperwork. Long: More paperwork. > > But given the number of projects here which rely on O_XATTR there > > isn't a way around it so funding should be easy to obtain. >=20 > Our institute volunteers for testing! >=20 > is there a task or todo list yet? >=20 Well, first I believe the FreeBSD project (I refer to it as the "collective" for want of a better word) needs to come to a consensus that this should be done. As I understand it, the first step towards that is a post on freebsd-arch@ proposing this work and why you think it is a good idea. Then, based upon the discussion/comments in response to this post, it will hopefully become fairly clear if the "collective" is in favour of doing this or not. Then, if the consensus is in favour, someone needs to do the coding. (I have volunteered to at least look at the kernel changes, but only the kernel changes.) rick > Simon > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 18 01:30:28 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C61ED8DC; Thu, 18 Sep 2014 01:30:28 +0000 (UTC) Received: from kx.openedu.org (96.247.3.110.ap.yournet.ne.jp [110.3.247.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3F1BD38F; Thu, 18 Sep 2014 01:30:27 +0000 (UTC) Received: from kiri.pis.kx.openedu.org (kiri.pis [192.168.1.1] (may be forged)) by kx.openedu.org (8.14.5/8.14.5) with ESMTP id s8I10J1c041678; Thu, 18 Sep 2014 10:00:19 +0900 (JST) (envelope-from kiri@kx.openedu.org) Message-Id: <201409180100.s8I10J1c041678@kx.openedu.org> Date: Thu, 18 Sep 2014 10:00:19 +0900 From: KIRIYAMA Kazuhiko To: Eitan Adler Subject: Re: Leaving the Desktop Market In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.6 MULE XEmacs/21.4 (patch 22) (Instant Classic) (amd64--freebsd) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Cc: freebsd-advocacy@freebsd.org, hackers@freebsd.org, current@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 01:30:29 -0000 Dear lists, I'm sorry for 2L8 reply though,I have transrated this thread into japanese in [1]. I wonder if every mail transrated correctly so please check it if you understand japanese especially by japanese lists. BTW ML mails should be obeyed by FreeBSD Copyright but it's derivative work would be going to?=20 Regards [1] http://www.openedu.org/dkp/archive/mail/current/20140331-0517/maillist.= html --- Kazuhiko Kiriyama kiri@openedu.org At Mon, 31 Mar 2014 22:46:45 -0700, Eitan Adler wrote: >=20 > Hi all, >=20 > Some of you may have seen my posts entitled "Story of a Laptop User" > and "Story of a Desktop User". For those of you who did not, it can > be a worthwhile read to see what life is like when using FreeBSD as a > desktop. In short, it is an educational experience. While FreeBSD > can be coerced to do the right thing, it is rarely there by default > and often doesn't work as well as we would expect. >=20 > The following are issues I haven't brought up in the past: >=20 > Battery life sucks: it=A2s almost as if powerd wasn't running. Windows > can run for five hours on my laptop while FreeBSD can barely make it > two hours. I wonder what the key differences are? Likely it=A2s that > we focus so much on performance that no one considers power. ChromeOS > can run for 12 hours on some hardware; why can't we make FreeBSD run > for 16? >=20 > Sound configuration lacks key documentation: how can I automatically > change between headphones and external speakers? You can't even do > that in middle of a song at all! Trust me that you never want to be > staring at an HDA pin configuration. I'll bet you couldn't even get > sound streaming to other machines working if you tried. >=20 > FreeBSD lacks vendor credibility: CUDA is unsupported. Dropbox hasn't > released a client for FreeBSD. Nvidia Optimus doesn't function on > FreeBSD. Can you imagine telling someone to purchase a laptop with > the caveat: "but you won't be able to use your graphics card"? >=20 > In any case, half of our desktop support is emulation: flash and opera > only works because of the linuxulator. There really isn't any reason > for vendors to bother supporting FreeBSD if we are just going to ape > Linux anyways. >=20 > That is why on this date I propose that we cease competing on the > desktop market. FreeBSD should declare 2014 to be "year of the Linux > desktop" and start to rip out the pieces of the OS not needed for > server or embedded use. >=20 > Some of you may point to PCBSD and say that we have a chance, but I > must ask you: how does one flavor stand up to the thousands in the > Linux world? >=20 > Eitan Adler > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 18 04:10:18 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 941D428D for ; Thu, 18 Sep 2014 04:10:18 +0000 (UTC) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6BC813E1 for ; Thu, 18 Sep 2014 04:10:18 +0000 (UTC) Received: by mail-pd0-f182.google.com with SMTP id w10so532966pde.27 for ; Wed, 17 Sep 2014 21:10:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:reply-to:to:content-type:date:message-id:mime-version :content-transfer-encoding; bh=fr/2pq/ZU1tn5T9uQczpfl07KEJoCQSsbOVd0Y9J2OM=; b=FJh1uUdTxNZDgCkKj29eiJJ/bNyNEl6CQ6Eso8V7NUIdzWwKGI87vYSHavNSvc89ZZ l5gXrMCec+szR9PqmLXiZeMZ4IjcghPHjLnYmhw0hm8zqUYRQu+mGKjtXaZIsgyRjS+E uZuHFEU3md+o9NPQJqjZgliagaGKtZzOJyS2/KG2XP6KaDI6/Ff07dESAL6x43aFdb5T svZz1/Xz4DqjCcq7K8YYidVFCP/3dEe9rX5l6G57IxjeQ7jjkQOYdqG6p8YSgyM4reiu hxi+PfY0Ckgqou3NLLPghtLY4wOCaHjBQt73eyCuasAHoQLwMGXEIoHIX83TpUS2O5l1 WNoA== X-Received: by 10.70.43.39 with SMTP id t7mr1911884pdl.101.1411013417744; Wed, 17 Sep 2014 21:10:17 -0700 (PDT) Received: from ?IPv6:2001:470:f0fd:0:2e0:81ff:febc:fdcc? ([2001:470:f0fd:0:2e0:81ff:febc:fdcc]) by mx.google.com with ESMTPSA id ki1sm18299626pdb.59.2014.09.17.21.10.15 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Wed, 17 Sep 2014 21:10:16 -0700 (PDT) Subject: "Invalid partition table" on 10-stable. From: Frank Mayhar Reply-To: frank@exit.com To: freebsd-hackers Content-Type: text/plain; charset="ISO-8859-1" Date: Wed, 17 Sep 2014 21:11:10 -0700 Message-ID: <1411013471.25791.52.camel@jill.exit.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 04:10:18 -0000 Someone please give me a hint of what's going on here. I just got a Dell Precision M6800. It's not doing UEFI, it's all legacy. I pulled the installed drive and dropped in a Seagate hybrid 1T drive, then tried (and tried, and tried, and tried) to install 10-stable on it. I'm using a memstick image, btw. No matter what I try and no matter whether I use bsdinstall or do the gpart stuff by hand, everything goes fine until I try to boot the new install when all I get is "Invalid partition table!" And nothing. Am I going to have to use a legacy MBR and disklabel rather than gpt? Can anyone give me any hints as to what I might look for? I've googled to no avail (just some stuff from 2010 that doesn't seem to apply). I really want to follow the setup outlined at https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot . Hmm, is there a way to use, say, grub to do the bootstrap? How would I go about doing that? And most importantly, would it help? My head is about to explode so I'm turning to you guys. Even a hint would help. Thanks. -- Frank Mayhar frank@exit.com From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 18 05:48:44 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0A9F65C6; Thu, 18 Sep 2014 05:48:44 +0000 (UTC) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.9]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B8E15DF5; Thu, 18 Sep 2014 05:48:43 +0000 (UTC) Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 3hz6fw4CnYz3hhyl; Thu, 18 Sep 2014 07:48:40 +0200 (CEST) Received: from mail.embedded-brains.de (host-82-135-62-35.customer.m-online.net [82.135.62.35]) by mail.mnet-online.de (Postfix) with ESMTP id 3hz6fw2cTRzvh1p; Thu, 18 Sep 2014 07:48:40 +0200 (CEST) Received: by mail.embedded-brains.de (Postfix, from userid 65534) id D1376652CFC; Thu, 18 Sep 2014 07:48:39 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on fidibusdmz X-Spam-Level: X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from [192.168.100.11] (unknown [192.168.100.11]) by mail.embedded-brains.de (Postfix) with ESMTP id 4924165243D; Thu, 18 Sep 2014 07:48:39 +0200 (CEST) Message-ID: <541A7237.8030009@embedded-brains.de> Date: Thu, 18 Sep 2014 07:48:39 +0200 From: Sebastian Huber User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [PATCH] C++ compatibility for some kernel headers References: <1410952389-30368-1-git-send-email-sebastian.huber@embedded-brains.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 05:48:44 -0000 Hello, On 17/09/14 19:37, Adrian Chadd wrote: > So please do file a PR (https://bugs.freebsd.org/submit/) and I'll > make sure we fix -HEAD up to do this. I submitted a PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193733 -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 18 09:30:05 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A3C44C8 for ; Thu, 18 Sep 2014 09:30:05 +0000 (UTC) Received: from puchar.net (puchar.net [188.252.31.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A3BEB810 for ; Thu, 18 Sep 2014 09:30:03 +0000 (UTC) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.14.9/8.14.9) with ESMTP id s8I9Tre2019803 for ; Thu, 18 Sep 2014 11:29:53 +0200 (CEST) (envelope-from wojtek@puchar.net) Date: Thu, 18 Sep 2014 11:29:54 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop To: freebsd-hackers@freebsd.org Subject: unbound - what is wrong Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Thu, 18 Sep 2014 11:29:54 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 09:30:05 -0000 i try to make it resolve both global zones and my own intranet zones i added to /var/unbound/conf.d/ file intra.conf private-address: 10.0.0.0/8 local-zone: "10.in-addr.arpa." transparent local-zone: "intra." transparent forward-zone: name: intra. forward-addr: 10.0.1.1 forward-zone: name: 10.in-addr.arpa. forward-addr: 10.0.1.1 reverse lookups on 10/8 works fine [root@laptop /var/unbound]# host 10.0.1.1 1.1.0.10.in-addr.arpa domain name pointer intra. but forward: [root@laptop /var/unbound]# host intra. Host intra not found: 2(SERVFAIL) what is wrong? From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 18 10:18:22 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF6863E5 for ; Thu, 18 Sep 2014 10:18:22 +0000 (UTC) Received: from mail.beastielabs.net (unknown [IPv6:2001:888:1227:0:200:24ff:fec9:5934]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 98257C71 for ; Thu, 18 Sep 2014 10:18:22 +0000 (UTC) Received: from beastie.hotsoft.nl (beastie.hotsoft.nl [IPv6:2001:888:1227:0:219:d1ff:fee8:91eb]) by mail.beastielabs.net (8.14.7/8.14.7) with ESMTP id s8IAICV2007835; Thu, 18 Sep 2014 12:18:12 +0200 (CEST) (envelope-from hans@beastielabs.net) Message-ID: <541AB164.80707@beastielabs.net> Date: Thu, 18 Sep 2014 12:18:12 +0200 From: Hans Ottevanger User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: frank@exit.com Subject: Re: "Invalid partition table" on 10-stable. References: <1411013471.25791.52.camel@jill.exit.com> In-Reply-To: <1411013471.25791.52.camel@jill.exit.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 10:18:23 -0000 On 09/18/14 06:11, Frank Mayhar wrote: > Someone please give me a hint of what's going on here. I just got a > Dell Precision M6800. It's not doing UEFI, it's all legacy. I pulled > the installed drive and dropped in a Seagate hybrid 1T drive, then tried > (and tried, and tried, and tried) to install 10-stable on it. I'm using > a memstick image, btw. > > No matter what I try and no matter whether I use bsdinstall or do the > gpart stuff by hand, everything goes fine until I try to boot the new > install when all I get is "Invalid partition table!" And nothing. > > Am I going to have to use a legacy MBR and disklabel rather than gpt? > Can anyone give me any hints as to what I might look for? I've googled > to no avail (just some stuff from 2010 that doesn't seem to apply). > > I really want to follow the setup outlined at > https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot . > > Hmm, is there a way to use, say, grub to do the bootstrap? How would I > go about doing that? And most importantly, would it help? > > My head is about to explode so I'm turning to you guys. Even a hint > would help. Thanks. > Hi, I have a similar situation with my oldish Q6600 based systems using an INTEL DP965LT main-board. After a fresh installation of FreeBSD 10 or higher (using a GPT scheme) I consistently get the message: No bootable device -- insert boot disk and press any key when rebooting the new installation for the first time. In my situation I can get the installation working by booting single user from an older FreeBSD install CD (9.2R in my case) and reinstall the MBR as follows: /sbin/gpart bootcode -b /boot/pmbr ada0 Probably gpart changed the way it installs the MBR, but I think it is very board (or maybe BIOS) specific: other systems do not have the issue. Please let me know if this "trick" helps for you. Kind regards, Hans From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 18 11:51:36 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8361FA7E for ; Thu, 18 Sep 2014 11:51:36 +0000 (UTC) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (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 55C1882A for ; Thu, 18 Sep 2014 11:51:36 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by gateway2.nyi.internal (Postfix) with ESMTP id 88BA316A7 for ; Thu, 18 Sep 2014 07:51:34 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute3.internal (MEProxy); Thu, 18 Sep 2014 07:51:34 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date:in-reply-to :references; s=smtpout; bh=TEYNm/uTCsjJFBRFEW5oQhw0zx0=; b=FCcVU 4BBAX9gh/h+a1pxQ9tHkWbnGn9AOKZE7TgKKIPKvXHKnvnqT7T3gcSi75q4nUd6e aRwvKixlji/zCNhKN+M8aROTO8mTDzmVyzQrFRR9Z2XMMfWVjPkKbzFhab5P+vtU 9YmaA79896TQfyr5nwcMPIajo8OlS1fe426Nr4= Received: by web3.nyi.internal (Postfix, from userid 99) id 16D3710ED4A; Thu, 18 Sep 2014 07:51:34 -0400 (EDT) Message-Id: <1411041094.640133.168972769.6D823A59@webmail.messagingengine.com> X-Sasl-Enc: 5vmAFSg/ebMzKFyUxgP69OqupjT/VXpyAq/oPNVpeMgV 1411041094 From: Mark Felder To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-68d12f42 Subject: Re: unbound - what is wrong Date: Thu, 18 Sep 2014 06:51:34 -0500 In-Reply-To: References: X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 11:51:36 -0000 On Thu, Sep 18, 2014, at 04:29, Wojciech Puchar wrote: > i try to make it resolve both global zones and my own intranet zones > > i added to /var/unbound/conf.d/ file intra.conf > > private-address: 10.0.0.0/8 > local-zone: "10.in-addr.arpa." transparent > local-zone: "intra." transparent > forward-zone: > name: intra. > forward-addr: 10.0.1.1 > forward-zone: > name: 10.in-addr.arpa. > forward-addr: 10.0.1.1 > > > reverse lookups on 10/8 works fine > > [root@laptop /var/unbound]# host 10.0.1.1 > 1.1.0.10.in-addr.arpa domain name pointer intra. > > but forward: > > [root@laptop /var/unbound]# host intra. > Host intra not found: 2(SERVFAIL) > > > what is wrong? > Can you confirm that a dig or drill @10.0.1.1 for intra hostnames works correctly? I previously had a setup that required two additional lines. See below: private-domain: localdomain domain-insecure: localdomain forward-zone: name: "localdomain" forward-addr: 192.168.1.1 From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 18 11:53:31 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2643DCAA for ; Thu, 18 Sep 2014 11:53:31 +0000 (UTC) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (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 ECC79847 for ; Thu, 18 Sep 2014 11:53:30 +0000 (UTC) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by gateway2.nyi.internal (Postfix) with ESMTP id 0C55472D for ; Thu, 18 Sep 2014 07:53:30 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute5.internal (MEProxy); Thu, 18 Sep 2014 07:53:30 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=QBtJDkJllx2dw9qJi6RwSktRaUo=; b=c0V 3rzqrztwEbwkyaFZj1bMY/XM0RTUAhiMlJ4y5jwCnZm+ewK5XTW0uQIPNpNR7gbK vUCVS2gl4s2UQgixBpqHUiP9rgZgGsVaQrZYemI3tAKeryy3DdHhXmgv9PvRQOZh 4Y5AsxE/RJGO3xk3Rfrk+Oo1eZStPXRTt/ysuoWw= Received: by web3.nyi.internal (Postfix, from userid 99) id CC49910ED54; Thu, 18 Sep 2014 07:53:29 -0400 (EDT) Message-Id: <1411041209.640367.168973281.5BC3D2D2@webmail.messagingengine.com> X-Sasl-Enc: ATnAiJweFVUWiQu8+ykTMRyvwEsm0qmSWS9Ag/hNIpZS 1411041209 From: Mark Felder To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-68d12f42 In-Reply-To: References: Subject: Re: unbound - what is wrong Date: Thu, 18 Sep 2014 06:53:29 -0500 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 11:53:31 -0000 On Thu, Sep 18, 2014, at 04:29, Wojciech Puchar wrote: > > local-zone: "10.in-addr.arpa." transparent > local-zone: "intra." transparent > I also just realized you have local-zone defined. That's for when you want to hardcode entries into unbound's configuration. I don't believe you can have a local-zone that is also forwarded. You should probably remove those two lines. From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 18 14:23:58 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7A1DA667 for ; Thu, 18 Sep 2014 14:23:58 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 288E0C97 for ; Thu, 18 Sep 2014 14:23:57 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id s8IENqer012527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 18 Sep 2014 08:23:53 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id s8IENj1k012516; Thu, 18 Sep 2014 08:23:52 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Thu, 18 Sep 2014 08:23:45 -0600 (MDT) From: Warren Block To: frank@exit.com Subject: Re: "Invalid partition table" on 10-stable. In-Reply-To: <1411013471.25791.52.camel@jill.exit.com> Message-ID: References: <1411013471.25791.52.camel@jill.exit.com> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Thu, 18 Sep 2014 08:23:53 -0600 (MDT) Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 14:23:58 -0000 On Wed, 17 Sep 2014, Frank Mayhar wrote: > Someone please give me a hint of what's going on here. I just got a > Dell Precision M6800. It's not doing UEFI, it's all legacy. I pulled > the installed drive and dropped in a Seagate hybrid 1T drive, then tried > (and tried, and tried, and tried) to install 10-stable on it. I'm using > a memstick image, btw. > > No matter what I try and no matter whether I use bsdinstall or do the > gpart stuff by hand, everything goes fine until I try to boot the new > install when all I get is "Invalid partition table!" And nothing. If that is the only thing displayed, it's from the BIOS. It would indicate Dell has done something in the BIOS that expects certain partition types in an MBR, and chokes on the PMBR. Sometimes a BIOS update helps. It's not clear whether this system is UEFI capable. If it is, there are strict rules for GPT or MBR layout. See https://forums.freebsd.org/viewtopic.php?&t=42781 If the message appears after FreeBSD starts to boot, it's from FreeBSD. The RootOnZFS process looks like it could use an update for partition alignment and size, but otherwise should work. From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 18 15:25:12 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 98E95EC5; Thu, 18 Sep 2014 15:25:12 +0000 (UTC) Received: from puchar.net (puchar.net [188.252.31.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 254777B4; Thu, 18 Sep 2014 15:25:11 +0000 (UTC) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.14.9/8.14.9) with ESMTP id s8IFP7qo011607; Thu, 18 Sep 2014 17:25:07 +0200 (CEST) (envelope-from wojtek@puchar.net) Date: Thu, 18 Sep 2014 17:25:08 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop To: Mark Felder Subject: Re: unbound - what is wrong In-Reply-To: <1411041094.640133.168972769.6D823A59@webmail.messagingengine.com> Message-ID: References: <1411041094.640133.168972769.6D823A59@webmail.messagingengine.com> 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.4.3 (puchar.net [10.0.1.1]); Thu, 18 Sep 2014 17:25:07 +0200 (CEST) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 15:25:12 -0000 >> Host intra not found: 2(SERVFAIL) >> >> >> what is wrong? >> > > Can you confirm that a dig or drill @10.0.1.1 for intra hostnames works > correctly? yes i can [wojtek@laptop ~]$ drill intra @10.0.1.1 ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 19090 ;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;; intra. IN A ;; ANSWER SECTION: intra. 10800 IN A 10.0.1.1 ;; AUTHORITY SECTION: intra. 10800 IN NS dns.intra. ;; ADDITIONAL SECTION: dns.intra. 10800 IN A 10.0.1.1 ;; Query time: 21 msec ;; SERVER: 10.0.1.1 ;; WHEN: Thu Sep 18 17:22:27 2014 ;; MSG SIZE rcvd: 73 > > I previously had a setup that required two additional lines. See below: > > private-domain: localdomain > domain-insecure: localdomain > forward-zone: > name: "localdomain" > forward-addr: 192.168.1.1 now i have private-address: 10.0.0.0/8 domain-insecure: intra. local-zone: "10.in-addr.arpa." transparent local-zone: "intra." transparent forward-zone: name: intra. forward-addr: 10.0.1.1 forward-zone: name: 10.in-addr.arpa. forward-addr: 10.0.1.1 things changed: [root@laptop ~]# host intra YES - no output, no error. [root@laptop ~]# host -a intra Trying "intra" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20302 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;intra. IN TYPE255 ;; ANSWER SECTION: intra. 10800 IN SOA dns.intra. root.puchar.net. 1409050208 3600 3600 604800 10800 intra. 10800 IN NS dns.intra. Received 92 bytes from 127.0.0.1#53 in 20 ms From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 18 15:25:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6779BFA5; Thu, 18 Sep 2014 15:25:42 +0000 (UTC) Received: from puchar.net (puchar.net [188.252.31.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E6FA37BE; Thu, 18 Sep 2014 15:25:41 +0000 (UTC) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.14.9/8.14.9) with ESMTP id s8IFPdE0011841; Thu, 18 Sep 2014 17:25:39 +0200 (CEST) (envelope-from wojtek@puchar.net) Date: Thu, 18 Sep 2014 17:25:40 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop To: Mark Felder Subject: Re: unbound - what is wrong In-Reply-To: <1411041209.640367.168973281.5BC3D2D2@webmail.messagingengine.com> Message-ID: References: <1411041209.640367.168973281.5BC3D2D2@webmail.messagingengine.com> 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.4.3 (puchar.net [10.0.1.1]); Thu, 18 Sep 2014 17:25:40 +0200 (CEST) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 15:25:42 -0000 done. changed nothing On Thu, 18 Sep 2014, Mark Felder wrote: > > > On Thu, Sep 18, 2014, at 04:29, Wojciech Puchar wrote: >> >> local-zone: "10.in-addr.arpa." transparent >> local-zone: "intra." transparent >> > > I also just realized you have local-zone defined. That's for when you > want to hardcode entries into unbound's configuration. I don't believe > you can have a local-zone that is also forwarded. You should probably > remove those two lines. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 18 20:30:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1AFE4411 for ; Thu, 18 Sep 2014 20:30:10 +0000 (UTC) Received: from ln.servalan.com (ln.servalan.com [IPv6:2600:3c00::f03c:91ff:fe96:62f5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E7951F09 for ; Thu, 18 Sep 2014 20:30:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=servalan.com; s=rsadkim; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:To:From; bh=wUEpn21eEfzszB0hB3uIgaWa4P9eTM9JtVktmNiJ9IM=; b=GgQFdmPSycgxhwwUY9v7da49Cx29Lxdpmgyenmm/NrJpi5jx7wcMuRB1g5RtYbsmjBD/UiaoduBHqPHLFl40cqkCamEZwCj8seBvx+E4qD3zDeSZjlRyG5btWL46JJhYaYhKwwSLlhZD9p6eU524cmvw+ji08TKltQ3UjXMl2Vk=; Received: from uucp by ln.servalan.com with local-rmail (Exim 4.76) (envelope-from ) id 1XUiLA-0002zq-TT for freebsd-hackers@freebsd.org; Thu, 18 Sep 2014 15:30:08 -0500 Received: from rmtodd by servalan.servalan.com with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XUiBW-0000oh-NP; Thu, 18 Sep 2014 15:20:10 -0500 From: Richard Todd To: freebsd-hackers@freebsd.org Subject: Re: "Invalid partition table" on 10-stable. References: <1411013471.25791.52.camel@jill.exit.com> <541AB164.80707@beastielabs.net> Date: Thu, 18 Sep 2014 15:19:57 -0500 In-Reply-To: <541AB164.80707@beastielabs.net> (Hans Ottevanger's message of "Thu, 18 Sep 2014 12:18:12 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain X-Mailman-Approved-At: Thu, 18 Sep 2014 20:37:57 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 20:30:10 -0000 Hans Ottevanger writes: > Hi, > > I have a similar situation with my oldish Q6600 based systems using an > INTEL DP965LT main-board. After a fresh installation of FreeBSD 10 or > higher (using a GPT scheme) I consistently get the message: > > No bootable device -- insert boot disk and press any key > > when rebooting the new installation for the first time. > > In my situation I can get the installation working by booting single > user from an older FreeBSD install CD (9.2R in my case) and reinstall > the MBR as follows: > > /sbin/gpart bootcode -b /boot/pmbr ada0 > > Probably gpart changed the way it installs the MBR, but I think it is > very board (or maybe BIOS) specific: other systems do not have the > issue. I have a DP965LT system, and yes the BIOS is a bit finicky about the contents of the MBR; I had issues before (pre-GPT days in FreeBSD) with it not wanting to boot which turned out to be it insisting there had to be one and only one "active" partition in the MBR. It's currently running with a GPT PMBR boot record, set up sometime when it was running 9.x I think. This is what fdisk shows for the MBR on that machine: 3 blo-rakane /usr/home/rmtodd[ 3:15PM] Z# fdisk /dev/ada0 ******* Working on device /dev/ada0 ******* parameters extracted from in-core disklabel are: cylinders=484521 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=484521 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 238 (0xee),(EFI GPT) start 1, size 488397167 (238475 Meg), flag 80 (active) beg: cyl 0/ head 0/ sector 2; end: cyl 1023/ head 255/ sector 63 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: Note the "active" flag present on the GPT fake-MBR-partition. From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 18 21:10:13 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5092A3DE for ; Thu, 18 Sep 2014 21:10:13 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0A806622 for ; Thu, 18 Sep 2014 21:10:12 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XUixn-0001u6-K4 for freebsd-hackers@freebsd.org; Thu, 18 Sep 2014 23:10:03 +0200 Received: from 74.125.59.185 ([74.125.59.185]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 18 Sep 2014 23:10:03 +0200 Received: from fmayhar by 74.125.59.185 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 18 Sep 2014 23:10:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Frank Mayhar Subject: Re: "Invalid partition table" on 10-stable. Date: Thu, 18 Sep 2014 21:01:31 +0000 (UTC) Lines: 18 Message-ID: References: <1411013471.25791.52.camel@jill.exit.com> <541AB164.80707@beastielabs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 74.125.59.185 (Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 21:10:13 -0000 Hans Ottevanger beastielabs.net> writes: > In my situation I can get the installation working by booting single > user from an older FreeBSD install CD (9.2R in my case) and reinstall > the MBR as follows: > > /sbin/gpart bootcode -b /boot/pmbr ada0 > > Probably gpart changed the way it installs the MBR, but I think it is > very board (or maybe BIOS) specific: other systems do not have the issue. > > Please let me know if this "trick" helps for you. I did install the pmbr during the initial setup, as well as the bootstrap itself. I do plan to try the "set active partition" trick suggested elsewhere. -- Frank Mayhar fmayhar@gmail.com From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 18 22:03:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 62CA9AA0 for ; Thu, 18 Sep 2014 22:03:14 +0000 (UTC) Received: from puchar.net (puchar.net [188.252.31.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E2025BDF for ; Thu, 18 Sep 2014 22:03:13 +0000 (UTC) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.14.9/8.14.9) with ESMTP id s8IM399O011400; Fri, 19 Sep 2014 00:03:09 +0200 (CEST) (envelope-from wojtek@puchar.net) Date: Fri, 19 Sep 2014 00:03:09 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop To: Frank Mayhar Subject: Re: "Invalid partition table" on 10-stable. In-Reply-To: Message-ID: References: <1411013471.25791.52.camel@jill.exit.com> <541AB164.80707@beastielabs.net> 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.4.3 (puchar.net [10.0.1.1]); Fri, 19 Sep 2014 00:03:09 +0200 (CEST) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 22:03:14 -0000 >> >> /sbin/gpart bootcode -b /boot/pmbr ada0 >> >> Probably gpart changed the way it installs the MBR, but I think it is >> very board (or maybe BIOS) specific: other systems do not have the issue. >> >> Please let me know if this "trick" helps for you. > > I did install the pmbr during the initial setup, as well as the bootstrap > itself. I do plan to try the "set active partition" trick suggested > elsewhere. while it may not solve your problems i prefer to NEVER make MBR partitions at all, only bsdlabel. example: [root@laptop ~]# bsdlabel ada0 # /dev/ada0: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 249984 16 4.2BSD 0 0 0 b: 4750000 250000 swap c: 117210240 0 unused 0 0 # "raw" part, don't edit d: 63332672 5000000 4.2BSD 0 0 0 h: 48877568 68332672 4.2BSD 0 0 0 simply do bsdlabel -B disk to make it bootable. From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 18 22:21:58 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18E77484 for ; Thu, 18 Sep 2014 22:21:58 +0000 (UTC) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DF9AED9A for ; Thu, 18 Sep 2014 22:21:57 +0000 (UTC) Received: by mail-pd0-f178.google.com with SMTP id y10so80359pdj.37 for ; Thu, 18 Sep 2014 15:21:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:reply-to:to:cc:in-reply-to:references:content-type :date:message-id:mime-version:content-transfer-encoding; bh=UYyKwxb9gBt2TLnsj2Ru0OxCY1tWlzyDJh8L3u9J6RE=; b=oA04+XVM17sweSBO8k2t48PyJEonWKaWlEHN4iXaitfsakjZ+sK2G+5D40PyPh2Mw0 P6OCYjy5tbuWQKl23rA8Q/XDpHvYjkOQEex72xi2I1WC5K90wGPn7CDTM/+yEGjRes3n 3ikw1h/h/MdZ4m/bAScoZckQ/f7xiYdHx9KbPCJQribk6COWN53gs/H0EZ41OBqRW3qz m5/XYAYcivBGmMEqU/v1xq3PyZS4gYVFoNzUw83+K3eceTQyKSQKhN1Jds0+Hl1Ed6wW QMRMfwod5m+hM65rfbft2hFQLvxWD5wfLvmFpo9JZnLvAsIEQQi/w7182gqDJvxmD57m Fp6Q== X-Received: by 10.70.88.237 with SMTP id bj13mr11336984pdb.57.1411078917080; Thu, 18 Sep 2014 15:21:57 -0700 (PDT) Received: from ?IPv6:2001:470:f0fd:0:2e0:81ff:febc:fdcc? ([2001:470:f0fd:0:2e0:81ff:febc:fdcc]) by mx.google.com with ESMTPSA id qy1sm52526pbc.27.2014.09.18.15.21.55 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Thu, 18 Sep 2014 15:21:56 -0700 (PDT) Subject: Re: "Invalid partition table" on 10-stable. From: Frank Mayhar Reply-To: fmayhar@gmail.com To: Wojciech Puchar In-Reply-To: References: <1411013471.25791.52.camel@jill.exit.com> <541AB164.80707@beastielabs.net> Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 18 Sep 2014 15:22:58 -0700 Message-ID: <1411078978.90616.21.camel@jill.exit.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 22:21:58 -0000 On Fri, 2014-09-19 at 00:03 +0200, Wojciech Puchar wrote: > >> > >> /sbin/gpart bootcode -b /boot/pmbr ada0 > >> > >> Probably gpart changed the way it installs the MBR, but I think it is > >> very board (or maybe BIOS) specific: other systems do not have the issue. > >> > >> Please let me know if this "trick" helps for you. > > > > I did install the pmbr during the initial setup, as well as the bootstrap > > itself. I do plan to try the "set active partition" trick suggested > > elsewhere. > while it may not solve your problems i prefer to NEVER make MBR partitions > at all, only bsdlabel. > > example: > > [root@laptop ~]# bsdlabel ada0 > # /dev/ada0: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > a: 249984 16 4.2BSD 0 0 0 > b: 4750000 250000 swap > c: 117210240 0 unused 0 0 # "raw" part, don't edit > d: 63332672 5000000 4.2BSD 0 0 0 > h: 48877568 68332672 4.2BSD 0 0 0 > > simply do > > bsdlabel -B disk > > to make it bootable. Well, my pmbr isn't really an MBR, it's just the fake one to make things "work right" as I understand it. In fact, I don't really understand it, or why it's necessary, but it's pretty clear that something's funky here. I'm planning to avoid disk/bsdlabel entirely in favor of gpart, GPT and zfs. (I'm dead set on using ZFS; I don't trust UFS nearly as much as I used to.) -- Frank Mayhar frank@exit.com From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 19 00:51:15 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 50C11658 for ; Fri, 19 Sep 2014 00:51:15 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 10265D77 for ; Fri, 19 Sep 2014 00:51:14 +0000 (UTC) Received: from [192.168.1.2] (senat1-01.HML3.ScaleEngine.net [209.51.186.5]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 09A1050A32 for ; Fri, 19 Sep 2014 00:51:12 +0000 (UTC) Message-ID: <541B7E15.1010201@freebsd.org> Date: Thu, 18 Sep 2014 20:51:33 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: "Invalid partition table" on 10-stable. References: <1411013471.25791.52.camel@jill.exit.com> <541AB164.80707@beastielabs.net> <1411078978.90616.21.camel@jill.exit.com> In-Reply-To: <1411078978.90616.21.camel@jill.exit.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2Xgnprejc7IoqGUNUQshQaElXw3kkX3Re" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 00:51:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2Xgnprejc7IoqGUNUQshQaElXw3kkX3Re Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2014-09-18 18:22, Frank Mayhar wrote: > On Fri, 2014-09-19 at 00:03 +0200, Wojciech Puchar wrote: >>>> >>>> /sbin/gpart bootcode -b /boot/pmbr ada0 >>>> >>>> Probably gpart changed the way it installs the MBR, but I think it i= s >>>> very board (or maybe BIOS) specific: other systems do not have the i= ssue. >>>> >>>> Please let me know if this "trick" helps for you. >>> >>> I did install the pmbr during the initial setup, as well as the boots= trap >>> itself. I do plan to try the "set active partition" trick suggested >>> elsewhere. >> while it may not solve your problems i prefer to NEVER make MBR partit= ions=20 >> at all, only bsdlabel. >> >> example: >> >> [root@laptop ~]# bsdlabel ada0 >> # /dev/ada0: >> 8 partitions: >> # size offset fstype [fsize bsize bps/cpg] >> a: 249984 16 4.2BSD 0 0 0 >> b: 4750000 250000 swap >> c: 117210240 0 unused 0 0 # "raw" part,= don't edit >> d: 63332672 5000000 4.2BSD 0 0 0 >> h: 48877568 68332672 4.2BSD 0 0 0 >> >> simply do >> >> bsdlabel -B disk >> >> to make it bootable. >=20 > Well, my pmbr isn't really an MBR, it's just the fake one to make thing= s > "work right" as I understand it. In fact, I don't really understand it= , > or why it's necessary, but it's pretty clear that something's funky > here. >=20 > I'm planning to avoid disk/bsdlabel entirely in favor of gpart, GPT and= > zfs. (I'm dead set on using ZFS; I don't trust UFS nearly as much as I= > used to.) >=20 I think the reason it is necessary, and called a 'protective' MBR, is that when Windows sees a disk without a valid-looking MBR, it immediately offers to format it for you. Thus the pMBR prevents you from accidentally erasing all of your data if you boot windows of another drive or something. --=20 Allan Jude --2Xgnprejc7IoqGUNUQshQaElXw3kkX3Re Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUG34YAAoJEJrBFpNRJZKfy4QP/1Dqesrk45H+thCZflW+kkBc MkaeWXBwvVDY5gN1qQ1sNyBXwosVKdpsSZpJJJEV34955tOkfgd54WK4g8pVKkrU iLR/3yvigm/WeoG7D8ogiizIZMG3QxHUTK83LuWp+bmj3koamgo+FnxsK4jh2dC3 1dxWugzRHaDNkqnTYfyGscIZhJ9GpD0GI+wIba7ydPs7RwZHgB4woV9Q3b+G8ebL K+Cbi269QURMuWuL6g2/h0pF3gaFiOlzx2cVoNPYoOtBf3EziStIXsk3xpTSdP+5 +UICaBSQKiOvHsge2jHbEdhEThjY45JmlMFABKBvviYQzH8pWWH0USYHnK2bEkWS Kxg+Xhw6F/WM+7bnFZrkfNYyjgxm7zSwNi1fOjXPx20caet1m37GDE/qEHSVJ0tz gagIH51TKE3xrgECT/Iv3JXQj1N9/R9/2OKZme7WU/XJpIyph8Jid8WHMcRrorwY H0dJmAMWsRQ1yiX/n3YK6xOSKGTAZkw5FkionO9HSfRf9IwcNg+Ob2EKowCICHRS a60rXccuwIcEW+pNQzFppj+12LGYg5F4+0l3JdMMoJ0qdtrIjf7n/LH9HW2OlWb3 F1mmwQFr550BKz46yHLEEJirJeJcGplPI55gpMtXvT3W1wqRBDBO6ZmY96THLxTX 8+ag+7p+pIFQaiEt2p36 =2XdH -----END PGP SIGNATURE----- --2Xgnprejc7IoqGUNUQshQaElXw3kkX3Re-- From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 19 11:48:40 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EEE87EF3 for ; Fri, 19 Sep 2014 11:48:40 +0000 (UTC) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C3809870 for ; Fri, 19 Sep 2014 11:48:40 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id v10so3480573pde.33 for ; Fri, 19 Sep 2014 04:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:reply-to:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; bh=Wkh+WBKwaS0REsEnqQJDMkaxpJd0Iy9Ra507s/r8KOk=; b=elsrGDc2wv1Q42iBsPTagU0f15s6UHHtlPs9wMp4nr/OYBeNJ3T31k8kufZsVZmz4i fulMHE8NgULXmPc9otO3BBzuOKpv+eap9yS7BlGx9uU0aBGJUbBpyzyoh0uKMwpIW63r dBa8QzIsprU9Fu5TvzDJWgqUNVjVL62ecpYJSrH7v30mY+rC0Uqe3Nu6fQrR/iz8X90N 98ebNMgIOmOftYkFfBu81xDv+TA3l3Etn0gyYdxQoDLC00I9g8vaWKfRX6nqDPCXkZjm FkV3HIUjWei+TNj1EVIiUlbCoAdblkzIhoZejoRrjsArQk5G/3PPywKLcoHF5Hep8iA8 BSig== X-Received: by 10.70.38.161 with SMTP id h1mr133593pdk.105.1411127319947; Fri, 19 Sep 2014 04:48:39 -0700 (PDT) Received: from ?IPv6:2001:470:f0fd:0:2e0:81ff:febc:fdcc? ([2001:470:f0fd:0:2e0:81ff:febc:fdcc]) by mx.google.com with ESMTPSA id f2sm1689792pdo.29.2014.09.19.04.48.38 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Fri, 19 Sep 2014 04:48:38 -0700 (PDT) Subject: Re: "Invalid partition table" on 10-stable. Solved. Ish. From: Frank Mayhar Reply-To: fmayhar@gmail.com To: freebsd-hackers In-Reply-To: <1411013471.25791.52.camel@jill.exit.com> References: <1411013471.25791.52.camel@jill.exit.com> Content-Type: text/plain; charset="ISO-8859-1" Date: Fri, 19 Sep 2014 04:49:44 -0700 Message-ID: <1411127384.92654.9.camel@jill.exit.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 11:48:41 -0000 On Wed, 2014-09-17 at 21:11 -0700, Frank Mayhar wrote: > Someone please give me a hint of what's going on here. I just got a > Dell Precision M6800. It's not doing UEFI, it's all legacy. I pulled > the installed drive and dropped in a Seagate hybrid 1T drive, then tried > (and tried, and tried, and tried) to install 10-stable on it. I'm using > a memstick image, btw. > > No matter what I try and no matter whether I use bsdinstall or do the > gpart stuff by hand, everything goes fine until I try to boot the new > install when all I get is "Invalid partition table!" And nothing. > > Am I going to have to use a legacy MBR and disklabel rather than gpt? > Can anyone give me any hints as to what I might look for? I've googled > to no avail (just some stuff from 2010 that doesn't seem to apply). > > I really want to follow the setup outlined at > https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot . Well, I got it going. In fact, when I got home last night I found that it was sitting there running FreeBSD off the disk. After some experimentation, I found that I had left it in legacy boot mode after strictly following the instructions in the above web page. And I think I had set the MBR to active, although I can't really remember. Even with that hack, however, UEFI just plain didn't work. It didn't find the bootable partition; when I tried to get it to look for it it claimed "Operating System not found" or something along those lines. It may well be looking for Windows only, I guess. Fortunately I can live with legacy boot. I reinstalled that way, following a slightly-modified version of the ZFS-root instructions above, and I'm installing ports as I write this. So, notwithstanding the lack of UEFI support, success! -- Frank Mayhar frank@exit.com From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 19 16:57:39 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A9C35B52 for ; Fri, 19 Sep 2014 16:57:39 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (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 75660DBC for ; Fri, 19 Sep 2014 16:57:39 +0000 (UTC) Received: from aurora.physics.berkeley.edu (aurora.Physics.Berkeley.EDU [128.32.117.67]) (authenticated bits=0) by d.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s8JGvUBL027280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 19 Sep 2014 09:57:31 -0700 Message-ID: <541C607A.5000407@freebsd.org> Date: Fri, 19 Sep 2014 09:57:30 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: "Invalid partition table" on 10-stable. Solved. Ish. References: <1411013471.25791.52.camel@jill.exit.com> <1411127384.92654.9.camel@jill.exit.com> In-Reply-To: <1411127384.92654.9.camel@jill.exit.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVYFI9NXRpFWnI3AAn4MM7Jhtdz6aZYobMOhor2/wR7ug2EFLUmSlLUntsOHVlVtCcT3Gl+XRWD0rpg/F9qjQ0Jqygc3LqAVBnQ= X-Sonic-ID: C;urQeCx5A5BGflwDu5Qupew== M;qAtSCx5A5BGflwDu5Qupew== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 16:57:39 -0000 On 09/19/14 04:49, Frank Mayhar wrote: > On Wed, 2014-09-17 at 21:11 -0700, Frank Mayhar wrote: >> Someone please give me a hint of what's going on here. I just got a >> Dell Precision M6800. It's not doing UEFI, it's all legacy. I pulled >> the installed drive and dropped in a Seagate hybrid 1T drive, then tried >> (and tried, and tried, and tried) to install 10-stable on it. I'm using >> a memstick image, btw. >> >> No matter what I try and no matter whether I use bsdinstall or do the >> gpart stuff by hand, everything goes fine until I try to boot the new >> install when all I get is "Invalid partition table!" And nothing. >> >> Am I going to have to use a legacy MBR and disklabel rather than gpt? >> Can anyone give me any hints as to what I might look for? I've googled >> to no avail (just some stuff from 2010 that doesn't seem to apply). >> >> I really want to follow the setup outlined at >> https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot . > Well, I got it going. In fact, when I got home last night I found that > it was sitting there running FreeBSD off the disk. After some > experimentation, I found that I had left it in legacy boot mode after > strictly following the instructions in the above web page. And I think > I had set the MBR to active, although I can't really remember. > > Even with that hack, however, UEFI just plain didn't work. It didn't > find the bootable partition; when I tried to get it to look for it it > claimed "Operating System not found" or something along those lines. It > may well be looking for Windows only, I guess. > > Fortunately I can live with legacy boot. I reinstalled that way, > following a slightly-modified version of the ZFS-root instructions > above, and I'm installing ports as I write this. > > So, notwithstanding the lack of UEFI support, success! Did you have secure boot enabled? -Nathan From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 19 17:50:53 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1DB2EAAE; Fri, 19 Sep 2014 17:50:53 +0000 (UTC) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E0F253B1; Fri, 19 Sep 2014 17:50:52 +0000 (UTC) Received: by mail-pd0-f172.google.com with SMTP id y10so374052pdj.31 for ; Fri, 19 Sep 2014 10:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:reply-to:to:cc:in-reply-to:references:content-type :date:message-id:mime-version:content-transfer-encoding; bh=BevlwR4HGrnNTz7ouTkhm9vX0e7TYsolErqQ3e2OW3w=; b=VdL0fwqmqLnO5ZI1NRLvX6iU6B484xIDRskqoRmrJJCtKjgirw6aYE2icXsfMAnTCl iSDxxhelnrq5ZaYaelF+iy295kxtAW46ESOong0f0CBk2w74aUH5Oe2IzqeO2zL5SxJ0 WnwBQD5AsMU36wtmzIdvo9/CBTezFBA2e6gNZBYOA+ySyqjXkBI5fkgoHs4nsAxevBOI 5GGKJxuNx1NkKyB5tYS5anzRM1MOKubfDhI5Yf5O0T3NIglLJw3wiLBmiVEdBtkFoaUy pzsGN1oCHdsFvWbvWnDWaMuSn+hPrqYQs8rB6TU+7ixnGqzDxvBN5npwcPdwC11Ma5lv jB8A== X-Received: by 10.69.18.74 with SMTP id gk10mr2396920pbd.145.1411149052417; Fri, 19 Sep 2014 10:50:52 -0700 (PDT) Received: from ?IPv6:2001:470:f0fd:0:2e0:81ff:febc:fdcc? ([2001:470:f0fd:0:2e0:81ff:febc:fdcc]) by mx.google.com with ESMTPSA id ca4sm2483013pad.0.2014.09.19.10.50.50 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Fri, 19 Sep 2014 10:50:51 -0700 (PDT) Subject: Re: "Invalid partition table" on 10-stable. Solved. Ish. From: Frank Mayhar Reply-To: fmayhar@gmail.com To: Nathan Whitehorn In-Reply-To: <541C607A.5000407@freebsd.org> References: <1411013471.25791.52.camel@jill.exit.com> <1411127384.92654.9.camel@jill.exit.com> <541C607A.5000407@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" Date: Fri, 19 Sep 2014 10:51:55 -0700 Message-ID: <1411149115.92654.10.camel@jill.exit.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 17:50:53 -0000 On Fri, 2014-09-19 at 09:57 -0700, Nathan Whitehorn wrote: > On 09/19/14 04:49, Frank Mayhar wrote: > > Well, I got it going. In fact, when I got home last night I found that > > it was sitting there running FreeBSD off the disk. After some > > experimentation, I found that I had left it in legacy boot mode after > > strictly following the instructions in the above web page. And I think > > I had set the MBR to active, although I can't really remember. > > > > Even with that hack, however, UEFI just plain didn't work. It didn't > > find the bootable partition; when I tried to get it to look for it it > > claimed "Operating System not found" or something along those lines. It > > may well be looking for Windows only, I guess. > > > > Fortunately I can live with legacy boot. I reinstalled that way, > > following a slightly-modified version of the ZFS-root instructions > > above, and I'm installing ports as I write this. > > > > So, notwithstanding the lack of UEFI support, success! > > Did you have secure boot enabled? No, definitely not. -- Frank Mayhar frank@exit.com From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 19 23:35:09 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96F78A5E for ; Fri, 19 Sep 2014 23:35:09 +0000 (UTC) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 342D9AE5 for ; Fri, 19 Sep 2014 23:35:09 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id em10so329531wid.5 for ; Fri, 19 Sep 2014 16:35:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=CDhY2Rg7TNqIEeK80VjLWcMF3XjDBq33H0A/d6Z58pQ=; b=VhLDEOYEUzlI1TFe6qZn3BRE4vNJj2xalFXuJQ31crXzSPkeWtl6V4NVasBBECcHH3 Tn+M7kVjbF4xfBS9+Oag3UecHUXx3o6G7NaipinEblK+6oya3pdEYcFpSJofFhMSFRwg 4trVtRdDPMrInaKhpylK6lYr+F6O0Z3lfZZWfbezyqeq7QEiXpxcgBfuEp8Szmljfjo9 OlJam6JwPwBYX2l9TuzheqUK6dE0r9bvGVvCVqo9I9+TSlDWex60J/9c8iffD7W/3rI+ UG8qdGbt2f6wBNZXrnUMP6uTgsxhVlVHfvjyq5MnribVi8PBrIsqWSfAvDqSE5A/GEGW SjUA== X-Received: by 10.180.184.40 with SMTP id er8mr59074028wic.31.1411169707359; Fri, 19 Sep 2014 16:35:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.192.66 with HTTP; Fri, 19 Sep 2014 16:34:27 -0700 (PDT) From: Artem Naluzhnyy Date: Sat, 20 Sep 2014 02:34:27 +0300 Message-ID: Subject: Deadline/NOOP-like I/O scheduler for hardware RAID controller To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 23:35:09 -0000 Hi, Will a Linux Deadline/NOOP-like I/O scheduler implementation using GEOM sched in FreeBSD have any performance improvements on hardware RAID controllers [1], SSD drives [2] or virtualization [3] like Linux has? Or there is a FreeBSD way to pass the I/O requests queue management to underlying (RAID/SSD controller or host OS) level? NOOP scheduler implementation in Linux looks quite simple [4]. [1] http://www.fishpool.org/post/2008/03/31/Optimizing-Linux-I/O-on-hardware-RAID [2] https://wiki.debian.org/SSDOptimization#Low-Latency_IO-Scheduler [3] http://www.sigops.org/sosp/sosp09/papers/hotstorage_4_boutcher.pdf [4] https://github.com/torvalds/linux/blob/master/block/noop-iosched.c -- Artem Naluzhnyy From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 20 07:07:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DCBB9A15 for ; Sat, 20 Sep 2014 07:07:34 +0000 (UTC) Received: from ustc.edu.cn (email6.ustc.edu.cn [IPv6:2001:da8:d800::8]) by mx1.freebsd.org (Postfix) with ESMTP id 26C84791 for ; Sat, 20 Sep 2014 07:07:33 +0000 (UTC) Received: from btw ( [58.211.218.74] ) by ajax-webmail-mailweb (Coremail) ; Sat, 20 Sep 2014 15:07:30 +0800 (CST) Date: Sat, 20 Sep 2014 15:07:30 +0800 (CST) From: btw@mail.ustc.edu.cn To: freebsd-hackers@freebsd.org Message-ID: <1473289.768021411196850376.JavaMail.coremail@mailweb> Subject: What's the difference between kmem_arena and kernel_arena? MIME-Version: 1.0 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: 7bit X-Originating-IP: [58.211.218.74] X-Priority: 3 X-Mailer: Coremail Webmail Server Version XT_U3b build 111111(15684.4153.3993) Copyright (c) 2002-2014 www.mailtech.cn ustc-xl X-CM-TRANSID: yia_0ZDLTQayJx1UAJDQAw--.20798W X-CM-SenderInfo: xewzqzxdloh3xvwfhvlgxou0/1tbiAQUNAUqSOCd6rwAAsa X-Coremail-Antispam: 1U50xBIdaVrnn0S07vEb7Iv0xC_Ar1lV2xY67kC6x804xJvcS sGvfC2KfnxnUU== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 07:07:34 -0000 Hi All, There are two similar variables declared in vm/vm_kern.h, they are kernel_arena and kmem_arena. Both of them are used in kmem_malloc(): rv = kmem_back((vmem == kmem_arena) ? kmem_object : kernel_object, I'm wondering what's the difference between them. Why both of them are needed? I have done a lot of searching, but I still can not find an answer. Thanks in advance! - twb From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 20 12:11:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 274BAAAC for ; Sat, 20 Sep 2014 12:11:11 +0000 (UTC) Received: from puchar.net (puchar.net [188.252.31.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8CA4436E for ; Sat, 20 Sep 2014 12:11:10 +0000 (UTC) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.14.9/8.14.9) with ESMTP id s8KCAx4w016183; Sat, 20 Sep 2014 14:11:00 +0200 (CEST) (envelope-from wojtek@puchar.net) Date: Sat, 20 Sep 2014 14:10:59 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop To: Frank Mayhar Subject: Re: "Invalid partition table" on 10-stable. In-Reply-To: <1411078978.90616.21.camel@jill.exit.com> Message-ID: References: <1411013471.25791.52.camel@jill.exit.com> <541AB164.80707@beastielabs.net> <1411078978.90616.21.camel@jill.exit.com> 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.4.3 (puchar.net [10.0.1.1]); Sat, 20 Sep 2014 14:11:01 +0200 (CEST) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 12:11:11 -0000 > > Well, my pmbr isn't really an MBR, it's just the fake one to make things > "work right" as I understand it. In fact, I don't really understand it, > or why it's necessary, but it's pretty clear that something's funky > here. it is only necessary if you use FreeBSD installer. From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 20 16:34:50 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED12197 for ; Sat, 20 Sep 2014 16:34:50 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 D0E45DD4 for ; Sat, 20 Sep 2014 16:34:50 +0000 (UTC) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s8KGYgBr021098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sat, 20 Sep 2014 09:34:43 -0700 Message-ID: <541DACA2.3000900@freebsd.org> Date: Sat, 20 Sep 2014 09:34:42 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: "Invalid partition table" on 10-stable. References: <1411013471.25791.52.camel@jill.exit.com> <541AB164.80707@beastielabs.net> <1411078978.90616.21.camel@jill.exit.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVY97cPIfgwT5i9SHmReq7mpE75ve5NF9sE+Kcul0LJOhdTMqpoDKuDv6S3dh1e6tuxUToTplojk1Oyy+b6XJ6OXtM1qskvnkv8= X-Sonic-ID: C;HOIJBuRA5BGqDDZXoK8kYw== M;ToJzBuRA5BGqDDZXoK8kYw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 16:34:51 -0000 On 09/20/14 05:10, Wojciech Puchar wrote: >> >> Well, my pmbr isn't really an MBR, it's just the fake one to make things >> "work right" as I understand it. In fact, I don't really understand it, >> or why it's necessary, but it's pretty clear that something's funky >> here. > > it is only necessary if you use FreeBSD installer. > Could you describe the exact problem here so that we can fix the installer? If this is the mark one partition active thing, I'm not sure we can change that, since there are also systems *that* breaks. -Nathan