From owner-freebsd-hackers@FreeBSD.ORG Sun May 6 03:19:30 2012 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 4FEE1106566B for ; Sun, 6 May 2012 03:19:30 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 9DDD8152B4F for ; Sun, 6 May 2012 03:19:29 +0000 (UTC) Date: Sat, 5 May 2012 20:19:28 -0700 (PDT) From: Doug Barton To: hackers@FreeBSD.org In-Reply-To: Message-ID: References: <20120504191111.153790@gmx.com> <20120504234220.5ba8141b@bhuda.mired.org> <3FFA8D05-005B-4405-ACD7-E8473F9BDCBE@fisglobal.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-message-flag: Outlook -- Not just for spreading viruses anymore! OpenPGP: id=1A1ABC84 Organization: http://SupersetSolutions.com/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Subject: Re: Ways to promote FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 03:19:30 -0000 As someone pointed out when this thread started, it's off-topic for hackers. Please take it to advocacy. -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-hackers@FreeBSD.ORG Sun May 6 03:58:46 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C55DD106564A for ; Sun, 6 May 2012 03:58:46 +0000 (UTC) (envelope-from alfchung02@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 45E308FC08 for ; Sun, 6 May 2012 03:58:46 +0000 (UTC) Received: by lagv3 with SMTP id v3so3836691lag.13 for ; Sat, 05 May 2012 20:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=DlVx9o7G/VpECeVywNqM0SxYSNFXi2b8+LGSdlNCtoc=; b=Z9oqxvX/cuPUvKGHSo5ymgLZ8Y80cFEz9obZ6luKsREArW6zEWetkSHg6Nm5SHJ20K ZHWH7w+BbdABQS4bJYdoZZcvggkg8vnCJKxpLiLxK1gp93E9N83wbJKde8TV2hedho8o OWD6l7LLp1m4w/Us2GnHPDnnduJj2gKMxEXrLP7L2hLqIfiPEHnNYJ8leNH43dOi+hbh HFtb79/fhMpo4tCzS+GlpSyUIHFeAB26XPEYTvR7UP6PYWo82eJhZfZaIFuqwR2YZ/jU r7vLYBPLXifpYHn2qkV406V8NcaiDFO85PrKvmonOdeFe6Jk9qmtbxj3ZoNDe22MfraJ SlTA== MIME-Version: 1.0 Received: by 10.152.148.101 with SMTP id tr5mr10184523lab.36.1336276724907; Sat, 05 May 2012 20:58:44 -0700 (PDT) Received: by 10.112.1.195 with HTTP; Sat, 5 May 2012 20:58:44 -0700 (PDT) Date: Sat, 5 May 2012 23:58:44 -0400 Message-ID: From: Alfred Zhong To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: FreeBSD on MacBook X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 03:58:46 -0000 Hi Dear Hackers, I tried to install FreeBSD on my MacBook. Bascially I followed this post online. http://www.glenbarber.us/2011/11/12/Dual-Booting-OS-X-and-FreeBSD-9.html And the tragedy happened. I do remember, as the post said, typed gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 3 ada0 By the way, I did installed rEFIT on Mac OS After rebooting, I see neither my Mac boot option nor the FreeBSD boot option. Even after holding Option key... The only stuff can boot is if I insert a CD (say, the FreeBSD live CD)... My installation was successful, but the boot loader was messed up! How can I fix this? Thanks! Alfred From owner-freebsd-hackers@FreeBSD.ORG Mon May 7 14:05:30 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84E46106564A; Mon, 7 May 2012 14:05:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 589578FC0C; Mon, 7 May 2012 14:05:30 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C1E01B95B; Mon, 7 May 2012 10:05:29 -0400 (EDT) From: John Baldwin To: freebsd-fs@freebsd.org Date: Mon, 7 May 2012 09:53:03 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <4F8999D2.1080902@FreeBSD.org> <4FA4F36A.6030903@FreeBSD.org> <4FA4F883.2060008@FreeBSD.org> In-Reply-To: <4FA4F883.2060008@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201205070953.04032.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 07 May 2012 10:05:29 -0400 (EDT) Cc: freebsd-hackers@freebsd.org, Andriy Gapon Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 14:05:30 -0000 On Saturday, May 05, 2012 5:53:07 am Andriy Gapon wrote: > on 05/05/2012 12:31 Andriy Gapon said the following: > > on 04/05/2012 18:25 John Baldwin said the following: > >> On Thursday, May 03, 2012 11:23:51 am Andriy Gapon wrote: > >>> on 03/05/2012 18:02 Andriy Gapon said the following: > >>>> > >>>> Here's the latest version of the patches: > >>>> http://people.freebsd.org/~avg/zfsboot.patches.4.diff > >>> > >>> I've found a couple of problems in the previous version, so here's another one: > >>> http://people.freebsd.org/~avg/zfsboot.patches.5.diff > >>> The important change is in the first patch (__exec args). > >> > >> A few comments/suggestions on the args bits: > > > > John, > > > > these are excellent suggestions! Thank you! > > The new patchset: http://people.freebsd.org/~avg/zfsboot.patches.7.diff Looks great, thanks! A few replies below: > >> - Add a CTASSERT() in loader/main.c that BI_SIZE == sizeof(struct bootinfo) > > > > I have added a definition of CTASSERT to boostrap.h as it was not available for > > sys/boot and there were two local definitions of the macro in individual files. > > > > However the assertion would fail right now. > > The backward-compatible value of BI_SIZE (72 == 0x48) covers only part of the > > fields in struct bootinfo, those up to the following comment: > > /* Items below only from advanced bootloader */ > > > > I am a little bit hesitant: should I increase BI_SIZE to cover the whole struct > > bootinfo or should I compare BI_SIZE to offsetof bi_kernend? Actually, we should probably be reading the 'bi_size' field and not using a BI_SIZE constant at all? Looks like only the non-functional EFI boot loader doesn't set bi_size (and it should just be fixed to do so since it needs to pass new fields in anyway). > > I've decided to define ARGADJ in the new common header, then I've had to rename > > btxcsu.s to .S, so that the preprocessing is executed for it. Ok. Maybe add one comment to the bootargs.h head to explain that the 'bootargs' struct starts at ARGOFF and can grow up, while struct bootinfo is copied such that it's end is at the top of the argument area and grows down. Also, at some point we could use a genassym.c file ala the kernel builds to generate some of the constants in bootargs.h instead (e.g. the offsets of fields within structures, and BA_SIZE, though we probably want to ensure that BA_SIZE never changes). -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon May 7 14:05:31 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 344B41065673; Mon, 7 May 2012 14:05:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0A2B78FC12; Mon, 7 May 2012 14:05:31 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6CD6BB95D; Mon, 7 May 2012 10:05:30 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 7 May 2012 09:57:03 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <3B2A320B-3ADE-4F48-B94E-4F0886178251@freebsd.org> In-Reply-To: <3B2A320B-3ADE-4F48-B94E-4F0886178251@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201205070957.03842.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 07 May 2012 10:05:30 -0400 (EDT) Cc: arm@freebsd.org, Tim Kientzle Subject: Re: How does loader(8) decide where to load the kernel? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 14:05:31 -0000 On Saturday, May 05, 2012 1:06:13 am Tim Kientzle wrote: > I have ubldr loading the ELF kernel on BeagleBone and am now > trying to untangle some of the hacks I used to get this working. > > Unfortunately, there's one area of the common loader(8) code > that I really don't understand: How does sys/boot/common/load_elf.c > determine the physical address at which to load the kernel? > > __elfN(loadfile) has the following comment: > > [The file] will be stored at (dest). > > But that's not really true. For starters, loadfile maps dest > through archsw.arch_loadaddr. (This mechanism seems > to only be used on ia64 and pc98, though the result is > later discarded on those platforms.) > > Loadfile then passes the value to loadimage which does > very strange things: > > On i386, amd64, powerpc, and arm, loadimage subtracts > the dest value from the address declared in the actual ELF > headers so that the kernel always gets loaded into low memory. > (there's some intermediate bit-twiddling I'm glossing over, but > this is the general idea). The bit twiddling is supposed to be the equivalent of subtracting KERNBASE from the load address. On both i386 and amd64, there is a direct mapping of the kernel text such that KERNBASE maps address 0, etc. By default on i386 KERNBASE is 0xc0000000. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon May 7 14:35:56 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 667BF106564A; Mon, 7 May 2012 14:35:56 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0C2B08FC0C; Mon, 7 May 2012 14:35:54 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA06392; Mon, 07 May 2012 17:34:37 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4FA7DD7C.4070703@FreeBSD.org> Date: Mon, 07 May 2012 17:34:36 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: Bruce Evans References: <4F8999D2.1080902@FreeBSD.org> <4FA29E1B.7040005@FreeBSD.org> <4FA2A307.2090108@FreeBSD.org> <201205041125.15155.jhb@freebsd.org> <4FA4F36A.6030903@FreeBSD.org> <20120505194459.D1295@besplex.bde.org> In-Reply-To: <20120505194459.D1295@besplex.bde.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org, John Baldwin Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 14:35:56 -0000 on 05/05/2012 13:49 Bruce Evans said the following: > On Sat, 5 May 2012, Andriy Gapon wrote: > >> on 04/05/2012 18:25 John Baldwin said the following: >>> On Thursday, May 03, 2012 11:23:51 am Andriy Gapon wrote: >>>> on 03/05/2012 18:02 Andriy Gapon said the following: >>>>> >>>>> Here's the latest version of the patches: >>>>> http://people.freebsd.org/~avg/zfsboot.patches.4.diff >>>> >>>> I've found a couple of problems in the previous version, so here's another one: >>>> http://people.freebsd.org/~avg/zfsboot.patches.5.diff >>>> The important change is in the first patch (__exec args). >>> >>> A few comments/suggestions on the args bits: >> >> John, >> >> these are excellent suggestions! Thank you! >> Some comments: >>> - Add #ifndef LOCORE guards to the new header around the structure so >>> it can be used in assembly as well as C. >> >> Done. I have had to go into a few btx makefiles and add a necessary include >> path and -DLOCORE to make the header usable from asm. Bruce, first a note that the change that we discussed affects (should affect) only BTX code and as such only boot1/2 -> loader interface. > Ugh, why not use genassym, as is done for all old uses of this header in > locore.s, at least on i386 (5% of the i386 genassym.c is for this). Can not parse 'this header' in this context. We were talking about a new header file, so there could not be any old uses of it :-) Probably you meant sys/i386/include/bootinfo.h ? But, as you say later, it's probably not easy to use genassym with sys/boot code. Not sure if it would be worth while going this path given the possible alternatives. >>> - Move BI_SIZE and ARGOFF into the header as constants. >> >> Done. >> >>> - Add a CTASSERT() in loader/main.c that BI_SIZE == sizeof(struct bootinfo) > > Ugh, BI_SIZE was already used in locore.s. OK, but this is "the other" BI_SIZE. Maybe the name clash is not nice indeed, though. > It wasn't the size of the struct, > but was the offset of the field that gives the size. No CTASSERT() was > needed -- the size is whatever it is, as given by sizeof() on the struct > at the time of compilation of the utility that initializes the struct. > It was a feature that sizeof() and offsetof() can't be used in asm so they > must be translated in genassym and no macros are needed in the header (the > size was fully dynamic, so the asm code only needs the offsetof() values). > Of course, you could use CTASSERT()s to check that the struct layout didn't > get broken. The old code just assumes that the struct is packed by the > programmer and that the arch's struct packing conventions don't change, > so that for example BI_SIZE = offsetof(struct bootinfo, bi_size) never > changes. It seems that boot1/2 -> kernel interface and boo1/2 -> {btxldr, btx} -> loader interfaces are quite independent and a bit different. > genassym is hard to use in boot programs, but the old design was that > boot programs shouldn't use bootinfo in asm and should just use the > target bootinfo.h at compile time (whatever time the target is compiled). I am not sure if it is worthwhile adapting genassym to sys/boot... BTX code needs to know only "some size" of bootinfo. Although it doesn't look like boot1/2 passes anything really useful to loader via bootinfo except for bi_bios_dev. For that matter it looks like maybe only two fields from the whole (x86) bootinfo are useful to (x86) kernel either... > Anyway, LOCORE means "for use in locore.[sS]", so other uses of it, e.g. > in boot programs, are bogus. That's a good point. Maybe we should use some more generic name. Maybe there is even some macro that is always set for .S files that we can check. Oh, thank google, is __ASSEMBLER__ it? It seems like couple of non-x86 headers already use this macro. >> I have added a definition of CTASSERT to boostrap.h as it was not available for >> sys/boot and there were two local definitions of the macro in individual files. >> >> However the assertion would fail right now. >> The backward-compatible value of BI_SIZE (72 == 0x48) covers only part of the > > This isn't backwards compatible. BI_SIZE was decimal 48 (covers everything > up to the bi_size field). I meant backward compatible with the BTX code that I was changing, of course. >> fields in struct bootinfo, those up to the following comment: >> /* Items below only from advanced bootloader */ >> I am a little bit hesitant: should I increase BI_SIZE to cover the whole struct >> bootinfo or should I compare BI_SIZE to offsetof bi_kernend? > > Neither. BI_SIZE shouldn't exist. It defeats the bi_size field. Using the bi_size field may be the proper solution indeed. Even if no data beyond certain offset is ever used by loader. The planned changes to BTX code should make using bi_size easier. >>> Maybe >>> create a 'struct kargs_ext' that looks like this: >>> >>> struct kargs_ext { >>> uint32_t size; >>> char data[0]; >>> }; >> >> I've decided to skip on this. > > Use KNF indentation and KNF field prefixes (ka_) if you add it :-). Generic > field names like `size' and `data' need prefixes more than mos. > > The old struct was: > > % #define N_BIOS_GEOM 8 > % ... > % /* > % * A zero bootinfo field often means that there is no info available. > % * Flags are used to indicate the validity of fields where zero is a > % * normal value. > % */ > % struct bootinfo { > % u_int32_t bi_version; > % u_int32_t bi_kernelname; /* represents a char * */ > % u_int32_t bi_nfs_diskless; /* struct nfs_diskless * */ > % /* End of fields that are always present. */ > > The original size was apparently 12. > > % #define bi_endcommon bi_n_bios_used > > Another style difference. The magic 12 is essentially given by this macro. > This macro is a pseudo-field, like the ones for the copyable and zeroable > regions in struct proc. Its name is in lower case. > > % u_int32_t bi_n_bios_used; > % u_int32_t bi_bios_geom[N_BIOS_GEOM]; > > The struct was broken in 1994 by adding the above 2 fields without providing > any way to distinguish it from the old struct. > > % u_int32_t bi_size; > % u_int8_t bi_memsizes_valid; > % u_int8_t bi_bios_dev; /* bootdev BIOS unit number */ > % u_int8_t bi_pad[2]; > % u_int32_t bi_basemem; > % u_int32_t bi_extmem; > % u_int32_t bi_symtab; /* struct symtab * */ > % u_int32_t bi_esymtab; /* struct symtab * */ > > The above 8 fields were added in 1995 (together with fixing style bugs > like no prefixes for the old field names). Now the struct is determined > by its size according to the bi_size field, and the bi_version field is > not really used (it's much easier to add stuff to the end than to support > multiple versions). This gives a range of old sizes/versions: > > 12: ~1993 (FreeBSD-1) > 48: ~1994 (FreeBSD-1 and/or 2) > 0x48: FreeBSD-2 post-1995 > > But these old sizes are uninteresting since only boot loaders from before > 1993-1995 support only the above fields, and these loaders can't boot current > kernels. > > % /* Items below only from advanced bootloader */ > % u_int32_t bi_kernend; /* end of kernel space */ > % u_int32_t bi_envp; /* environment */ > % u_int32_t bi_modulep; /* preloaded modules */ > > Added in 1998. Still uninteresting, since boot loaders newer than that > are needed to boot current kernels (mainly for elf). > > % uint64_t bi_hcdp; /* DIG64 HCDP table */ > % uint64_t bi_fpswa; /* FPSWA interface */ > % uint64_t bi_systab; /* pa of EFI system table */ > % uint64_t bi_memmap; /* pa of EFI memory map */ > % uint64_t bi_memmap_size; /* size of EFI memory map */ > % uint64_t bi_memdesc_size; /* sizeof EFI memory desc */ > % uint32_t bi_memdesc_version; /* EFI memory desc version */ > > Added in 2010. Are all of these uint64_t types correct? The padding seems > to be broken, so that these fields would not work for amd64: we're at offset > 0x48 for bi_kernend. The 3 uint32_t's added in 1998 reach 0x54. Then all > the uint64_t fields are misaligned on i386, and on amd64 there is unnamed > padding before the first of them to align them. But and64 doesn't use > bootinfo.h in the kernel, so I think only the i386 version is used on amd64 > (in the boot loader), so the misaligned case isn't used. Interesting observations. It looks like these newest fields were ported from IA64 for EFI support, but it doesn't look like that support is actually in x86 yet. > The struct declaration is also broken at the end. The last field is 32 bits, > so there is unnamed padding after it on amd64 only. This padding should be > explicit, like the padding before the uint64_t fields, or just put the 32-bit > field before the 64-bit fields. > > % }; > > So apart you could hard-code the size to the 1998 value of 0x54 without > losing anything except the buggy 2010 fields. But it shouldn't be > hard-coded. I am inclined to agree. Thank you again. P.S. Actually I feel like arguing if the genassym approach is totally correct/safe for BI_SIZE. One could easily insert a field before bi_size and thus change BI_SIZE and thus break compatibility with binaries compiled before the change. And all that without getting any hint during compilation. OTOH, if BI_SIZE is explicitly defined to constant and there is a CTASSERT to assert that BI_SIZE == offsetof(..., bi_size), then the chances of unwittingly breaking things are smaller. Of course, something like this would never happen in reality. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon May 7 14:47:09 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8898106567A; Mon, 7 May 2012 14:47:09 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C12CE8FC14; Mon, 7 May 2012 14:47:08 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA06503; Mon, 07 May 2012 17:47:07 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4FA7E069.8020208@FreeBSD.org> Date: Mon, 07 May 2012 17:47:05 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: John Baldwin References: <4F8999D2.1080902@FreeBSD.org> <4FA4F36A.6030903@FreeBSD.org> <4FA4F883.2060008@FreeBSD.org> <201205070953.04032.jhb@freebsd.org> In-Reply-To: <201205070953.04032.jhb@freebsd.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org, Bruce Evans Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 14:47:10 -0000 on 07/05/2012 16:53 John Baldwin said the following: > On Saturday, May 05, 2012 5:53:07 am Andriy Gapon wrote: [snip] >> The new patchset: http://people.freebsd.org/~avg/zfsboot.patches.7.diff > > Looks great, thanks! A few replies below: Here's a followup patch for the suggestions: http://people.freebsd.org/~avg/bootargs.followup.diff I will merge it into the main patch. What do you think about the -LOCORE- change that Bruce inspired? >>>> - Add a CTASSERT() in loader/main.c that BI_SIZE == sizeof(struct bootinfo) >>> >>> I have added a definition of CTASSERT to boostrap.h as it was not available for >>> sys/boot and there were two local definitions of the macro in individual files. >>> >>> However the assertion would fail right now. >>> The backward-compatible value of BI_SIZE (72 == 0x48) covers only part of the >>> fields in struct bootinfo, those up to the following comment: >>> /* Items below only from advanced bootloader */ >>> >>> I am a little bit hesitant: should I increase BI_SIZE to cover the whole struct >>> bootinfo or should I compare BI_SIZE to offsetof bi_kernend? > > Actually, we should probably be reading the 'bi_size' field and not using a BI_SIZE > constant at all? Done in the above patch. > Looks like only the non-functional EFI boot loader doesn't set bi_size (and it should > just be fixed to do so since it needs to pass new fields in anyway). > >>> I've decided to define ARGADJ in the new common header, then I've had to rename >>> btxcsu.s to .S, so that the preprocessing is executed for it. > > Ok. Maybe add one comment to the bootargs.h head to explain that the 'bootargs' > struct starts at ARGOFF and can grow up, while struct bootinfo is copied such that > it's end is at the top of the argument area and grows down. Will do. > Also, at some point we could use a genassym.c file ala the kernel builds to generate > some of the constants in bootargs.h instead (e.g. the offsets of fields within > structures, and BA_SIZE, though we probably want to ensure that BA_SIZE never > changes). The genassym approach sounds good, but, indeed - later :) Thank you. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon May 7 15:15:57 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ABA39106566C; Mon, 7 May 2012 15:15:57 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 92CE08FC16; Mon, 7 May 2012 15:15:56 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA06720; Mon, 07 May 2012 18:15:54 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4FA7E729.4000308@FreeBSD.org> Date: Mon, 07 May 2012 18:15:53 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: John Baldwin References: <4F8999D2.1080902@FreeBSD.org> <4FA4F36A.6030903@FreeBSD.org> <4FA4F883.2060008@FreeBSD.org> <201205070953.04032.jhb@freebsd.org> <4FA7E069.8020208@FreeBSD.org> In-Reply-To: <4FA7E069.8020208@FreeBSD.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org, Bruce Evans Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 15:15:57 -0000 on 07/05/2012 17:47 Andriy Gapon said the following: > on 07/05/2012 16:53 John Baldwin said the following: >> Ok. Maybe add one comment to the bootargs.h head to explain that the 'bootargs' >> struct starts at ARGOFF and can grow up, while struct bootinfo is copied such that >> it's end is at the top of the argument area and grows down. > > Will do. Could you please check the wording and correct it or suggest alternatives? Thank you. diff --git a/sys/boot/i386/common/bootargs.h b/sys/boot/i386/common/bootargs.h index 510efdd..8bc1b32 100644 --- a/sys/boot/i386/common/bootargs.h +++ b/sys/boot/i386/common/bootargs.h @@ -29,6 +29,15 @@ #define BF_OFF 8 /* offsetof(struct bootargs, bootflags) */ #define BI_OFF 20 /* offsetof(struct bootargs, bootinfo) */ +/* + * We reserve some space above BTX allocated stack for the arguments + * and certain data that could hang off them. Currently only struct bootinfo + * is supported in that category. The bootinfo is placed at the top + * of the arguments area and the actual arguments are placed at ARGOFF offset + * from the top and grow towards the top. Hopefully we have enough space + * for bootinfo and the arguments to not run into each other. + * Arguments area below ARGOFF is reserved for future use. + */ #define ARGSPACE 0x1000 /* total size of the BTX args area */ #define ARGOFF 0x800 /* actual args offset within the args area */ #define ARGADJ (ARGSPACE - ARGOFF) -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon May 7 17:46:12 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A83D1065670; Mon, 7 May 2012 17:46:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id F217C8FC14; Mon, 7 May 2012 17:46:11 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6F03EB95D; Mon, 7 May 2012 13:46:11 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Mon, 7 May 2012 13:38:12 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <4F8999D2.1080902@FreeBSD.org> <4FA7E069.8020208@FreeBSD.org> <4FA7E729.4000308@FreeBSD.org> In-Reply-To: <4FA7E729.4000308@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201205071338.12807.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 07 May 2012 13:46:11 -0400 (EDT) Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Bruce Evans Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 17:46:12 -0000 On Monday, May 07, 2012 11:15:53 am Andriy Gapon wrote: > on 07/05/2012 17:47 Andriy Gapon said the following: > > on 07/05/2012 16:53 John Baldwin said the following: > >> Ok. Maybe add one comment to the bootargs.h head to explain that the 'bootargs' > >> struct starts at ARGOFF and can grow up, while struct bootinfo is copied such that > >> it's end is at the top of the argument area and grows down. > > > > Will do. > > Could you please check the wording and correct it or suggest alternatives? > Thank you. > > diff --git a/sys/boot/i386/common/bootargs.h b/sys/boot/i386/common/bootargs.h > index 510efdd..8bc1b32 100644 > --- a/sys/boot/i386/common/bootargs.h > +++ b/sys/boot/i386/common/bootargs.h > @@ -29,6 +29,15 @@ > #define BF_OFF 8 /* offsetof(struct bootargs, bootflags) */ > #define BI_OFF 20 /* offsetof(struct bootargs, bootinfo) */ > > +/* > + * We reserve some space above BTX allocated stack for the arguments > + * and certain data that could hang off them. Currently only struct bootinfo > + * is supported in that category. The bootinfo is placed at the top > + * of the arguments area and the actual arguments are placed at ARGOFF offset > + * from the top and grow towards the top. Hopefully we have enough space > + * for bootinfo and the arguments to not run into each other. > + * Arguments area below ARGOFF is reserved for future use. > + */ > #define ARGSPACE 0x1000 /* total size of the BTX args area */ > #define ARGOFF 0x800 /* actual args offset within the args area */ > #define ARGADJ (ARGSPACE - ARGOFF) I think this is good, thanks! -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon May 7 17:46:12 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ED4A5106566B; Mon, 7 May 2012 17:46:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id C18788FC15; Mon, 7 May 2012 17:46:12 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 27BB1B978; Mon, 7 May 2012 13:46:12 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Mon, 7 May 2012 13:43:45 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <4F8999D2.1080902@FreeBSD.org> <201205070953.04032.jhb@freebsd.org> <4FA7E069.8020208@FreeBSD.org> In-Reply-To: <4FA7E069.8020208@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201205071343.45955.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 07 May 2012 13:46:12 -0400 (EDT) Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Bruce Evans Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 17:46:13 -0000 On Monday, May 07, 2012 10:47:05 am Andriy Gapon wrote: > on 07/05/2012 16:53 John Baldwin said the following: > > On Saturday, May 05, 2012 5:53:07 am Andriy Gapon wrote: > [snip] > >> The new patchset: http://people.freebsd.org/~avg/zfsboot.patches.7.diff > > > > Looks great, thanks! A few replies below: > > Here's a followup patch for the suggestions: > http://people.freebsd.org/~avg/bootargs.followup.diff > I will merge it into the main patch. > > What do you think about the -LOCORE- change that Bruce inspired? In general I think this looks good. I have only one suggestion. In other code (e.g. the genassym constants in the kernel) where we define constants for field offsets, we make the constant be the uppercase name of the field itself (e.g. TD_PCB for offsetof(struct thread, td_pcb)). I would rather do that here as well. In this case the field names do not have a prefix, but let's just use a BA_ prefix for members of 'bootargs'. BI_SIZE is already correct, but this would mean renaming HT_OFF to BA_HOWTO, BF_OFF to BA_BOOTFLAGS, and BI_OFF to BA_BOOTINFO. I think you can probably leave BA_SIZE as-is. > > Also, at some point we could use a genassym.c file ala the kernel builds to generate > > some of the constants in bootargs.h instead (e.g. the offsets of fields within > > structures, and BA_SIZE, though we probably want to ensure that BA_SIZE never > > changes). > > The genassym approach sounds good, but, indeed - later :) Yes, that can wait. I think it would not be very hard to do however. All you really need is access to sys/kern/genassym.sh and nm. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon May 7 20:53:25 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 97C89106566B for ; Mon, 7 May 2012 20:53:25 +0000 (UTC) (envelope-from eric@shadowsun.net) Received: from mail.atlantawebhost.com (dns1.atlantawebhost.com [66.223.40.39]) by mx1.freebsd.org (Postfix) with ESMTP id 072048FC17 for ; Mon, 7 May 2012 20:53:24 +0000 (UTC) Received: (qmail 24059 invoked from network); 7 May 2012 16:53:23 -0400 Received: from thingy.cs.umass.edu (HELO ?10.1.40.116?) (128.119.40.196) by mail.atlantawebhost.com with SMTP; 7 May 2012 16:53:23 -0400 Message-ID: <4FA8363D.6050204@shadowsun.net> Date: Mon, 07 May 2012 16:53:17 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.4) Gecko/20120425 Thunderbird/10.0.4 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig09119EF3ECFC7A26B1AA81EA" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: FreeBSD on MacBook X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 20:53:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig09119EF3ECFC7A26B1AA81EA Content-Type: multipart/mixed; boundary="------------010300000801080006040906" This is a multi-part message in MIME format. --------------010300000801080006040906 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 05/05/12 23:58, Alfred Zhong wrote: > Hi Dear Hackers, > > I tried to install FreeBSD on my MacBook. Bascially I followed this pos= t > online. > http://www.glenbarber.us/2011/11/12/Dual-Booting-OS-X-and-FreeBSD-9.htm= l > > And the tragedy happened. I do remember, as the post said, typed > gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 3 ada0 > > By the way, I did installed rEFIT on Mac OS > > After rebooting, I see neither my Mac boot option nor the FreeBSD boot > option. Even after holding Option key... > > The only stuff can boot is if I insert a CD (say, the FreeBSD live CD).= =2E. > > My installation was successful, but the boot loader was messed up! > > How can I fix this? > It is possible to install on a macbook (I've done it), though the process is a bit more intricate than any of the guides available suggest.= Basically, you need to install an MBR and boot in legacy BIOS mode.=20 Apple's EFI implementation does some funny things, and FreeBSD doesn't support EFI on i386 (yet, I'm actually working on adding support). I have a ZFS-only system, laid out as follows: there is an MBR with one partition, containing a BSDlabel. Inside that, there is a swap partition, and a single ZFS instance. When installing, you'll need to use dd to install the first part of zfsboot to the bsdlabel, and the remaining portion to the free space after the ZFS header (there's a guide on how to do that somewhere). --=20 Eric McCorkle Computer Science Ph.D Student eric@shadowsun.net --------------010300000801080006040906-- --------------enig09119EF3ECFC7A26B1AA81EA 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.19 (FreeBSD) iQIcBAEBAgAGBQJPqDZCAAoJENSCzbQ+koZ7sQ4P/AjUG473YYZt0s0P6mph2MU7 WsZM10TCCkPpHotGaijfPrj0gQ7+qyewLw6LlwVR/NElLm62VmOhqu1ZbL6Z+ElB iDOtWEUB2+zQJ8lVn1sCBu55njr4HmbjPpBXbstFgjh2GNrkEmqKXvWgFRw+fNZQ h7v/aqAwhFsIQD1NhIxBnX11mJrltfmRgYJ+2/mgvIaEuHUB297MkCt/fSZjmNeY i0kW1H/w5CCX7t9SyasLWDTz+S7pVzpWiNpAcUkwsSzE7HPCZ7Bt6Ni1WPcqotmI 5YSJnoXhhrL0+i3Ry3CabA8e0+ypoNDIEgdVVvi1GPn3TMIcIF3kVh1S/lpVgJrt aMHMg8x7d4oSMufpcfbFCWVfbCBBTsdBzYva2A1DqpqyXvc3KM8HIVr0+eWg+SA7 TH2H8fnjg/0NW374GPpfecTO02VVILbroy8tyCNul+1TwkAs5pIHa8nbyzi8AScQ Bd4GZqxo/8JfyIiKbo2b5GJ0s3HUhreFuYAFBCBjwdQi415rBL4IFJDNXVL+wQiM 9A6uiw03qMn2aKehpQs7fCuAnMrF2/oXcoBR9/QaEmfxZ43sCdq/t+vfDHBME4gy IFYILJr2ssJbogLf5fNn3vzC58K+c4j9hrmwy9BASfdYE/hwvuQpS3vodc9jcofp cgJr7qjNqLIvIDqcc3Ry =Z0at -----END PGP SIGNATURE----- --------------enig09119EF3ECFC7A26B1AA81EA-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 8 05:32:17 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BAD8106566C for ; Tue, 8 May 2012 05:32:17 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id CC8788FC08 for ; Tue, 8 May 2012 05:32:16 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so8461573pbb.13 for ; Mon, 07 May 2012 22:32:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=MX9zryC2Cu3MwYSe7jN0diR8YVnYnN0lg9vrajHAHhI=; b=htezlPC+4lsD6Z+3cLRvpN1stgB2hn98j0XI51icTqnV7djGW/DYH9uGLfJUYlO8cD dj8kFwfrGQNVHvV9DgBy1J0YrCUtT0LuueAXqItN5Wktj3Jp1b0Zd0ULD+yU+sslJpu9 zL/Gx1PP1RZ+6mHySxeBRhSDqWUuURRZdoEv/+SxeUiJX4GxiCMJbmOf+BD8ODDFnxD2 ARzDu7pHw3cgGH1WOnCR9sbZmPr2ALIyaEfCWRn0oSi8CGa4DD1lY1iFQhQ+L1hxnZzf xGohfbP62UWzBlkYf+I5DXRvAOcBZFauziND8YXwNmO74Ev/z4YAAp93M8YR6mHXu2cy TiXQ== Received: by 10.68.212.197 with SMTP id nm5mr4267947pbc.110.1336455136349; Mon, 07 May 2012 22:32:16 -0700 (PDT) Received: from [192.168.1.69] (99-74-169-43.lightspeed.sntcca.sbcglobal.net. [99.74.169.43]) by mx.google.com with ESMTPS id d6sm1185045pbi.23.2012.05.07.22.32.12 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 May 2012 22:32:13 -0700 (PDT) Sender: Tim Kientzle Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Tim Kientzle In-Reply-To: <201205070957.03842.jhb@freebsd.org> Date: Mon, 7 May 2012 22:32:10 -0700 Content-Transfer-Encoding: 7bit Message-Id: <8B01DF29-747A-449C-A762-E852F57C6380@freebsd.org> References: <3B2A320B-3ADE-4F48-B94E-4F0886178251@freebsd.org> <201205070957.03842.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQl43cA6GPMLefgVwJ7pvjeaniw8lJ5zzdfUodRJV2cBsWNcmEQto33VSkS1W0oS/baoOh32 Cc: arm@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: How does loader(8) decide where to load the kernel? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 05:32:17 -0000 On May 7, 2012, at 6:57 AM, John Baldwin wrote: > On Saturday, May 05, 2012 1:06:13 am Tim Kientzle wrote: >> I have ubldr loading the ELF kernel on BeagleBone and am now >> trying to untangle some of the hacks I used to get this working. >> >> Unfortunately, there's one area of the common loader(8) code >> that I really don't understand: How does sys/boot/common/load_elf.c >> determine the physical address at which to load the kernel? >> >> __elfN(loadfile) has the following comment: >> >> [The file] will be stored at (dest). >> >> But that's not really true. For starters, loadfile maps dest >> through archsw.arch_loadaddr. (This mechanism seems >> to only be used on ia64 and pc98, though the result is >> later discarded on those platforms.) >> >> Loadfile then passes the value to loadimage which does >> very strange things: >> >> On i386, amd64, powerpc, and arm, loadimage subtracts >> the dest value from the address declared in the actual ELF >> headers so that the kernel always gets loaded into low memory. >> (there's some intermediate bit-twiddling I'm glossing over, but >> this is the general idea). > > The bit twiddling is supposed to be the equivalent of subtracting > KERNBASE from the load address. On both i386 and amd64, there is > a direct mapping of the kernel text such that KERNBASE maps address > 0, etc. By default on i386 KERNBASE is 0xc0000000. Exactly my problem. This all assumes that you're loading the kernel into low memory. On the AM3358, the DRAM starts at 0x8000 0000 on boot, so I'm trying to find a clean way to convince the loader's ELF code to put the kernel there. Tim From owner-freebsd-hackers@FreeBSD.ORG Tue May 8 07:14:48 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92C36106564A; Tue, 8 May 2012 07:14:48 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 756D58FC0C; Tue, 8 May 2012 07:14:47 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA12978; Tue, 08 May 2012 10:14:45 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SRedA-000K6X-JS; Tue, 08 May 2012 10:14:44 +0300 Message-ID: <4FA8C7E3.8070006@FreeBSD.org> Date: Tue, 08 May 2012 10:14:43 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: John Baldwin References: <4F8999D2.1080902@FreeBSD.org> <201205070953.04032.jhb@freebsd.org> <4FA7E069.8020208@FreeBSD.org> <201205071343.45955.jhb@freebsd.org> In-Reply-To: <201205071343.45955.jhb@freebsd.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org, Bruce Evans Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 07:14:48 -0000 on 07/05/2012 20:43 John Baldwin said the following: > On Monday, May 07, 2012 10:47:05 am Andriy Gapon wrote: >> on 07/05/2012 16:53 John Baldwin said the following: [snip] >> What do you think about the -LOCORE- change that Bruce inspired? > > In general I think this looks good. I have only one suggestion. In other > code (e.g. the genassym constants in the kernel) where we define constants > for field offsets, we make the constant be the uppercase name of the field > itself (e.g. TD_PCB for offsetof(struct thread, td_pcb)). I would rather > do that here as well. In this case the field names do not have a prefix, > but let's just use a BA_ prefix for members of 'bootargs'. BI_SIZE is > already correct, but this would mean renaming HT_OFF to BA_HOWTO, BF_OFF to > BA_BOOTFLAGS, and BI_OFF to BA_BOOTINFO. OK, doing this. > I think you can probably leave BA_SIZE as-is. I see that i386 genassym has a few different styles for sizeof constants: ABBRSIZE FULL_NAME_SIZE ABBR_SIZEOF FULL_NAME_SIZE looked the most appealing to me (and seems to be the most common), so I decided to change BA_SIZE to BOOTARGS_SIZE. I hope that this makes sense and I am not starting a bikeshed :-) >>> Also, at some point we could use a genassym.c file ala the kernel builds to generate >>> some of the constants in bootargs.h instead (e.g. the offsets of fields within >>> structures, and BA_SIZE, though we probably want to ensure that BA_SIZE never >>> changes). >> >> The genassym approach sounds good, but, indeed - later :) > > Yes, that can wait. I think it would not be very hard to do however. All > you really need is access to sys/kern/genassym.sh and nm. > -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Tue May 8 09:41:25 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0D7D71065679; Tue, 8 May 2012 09:41:25 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from mailfilter12.ihug.co.nz (mailfilter12.ihug.co.nz [203.109.136.12]) by mx1.freebsd.org (Postfix) with ESMTP id 444478FC1C; Tue, 8 May 2012 09:41:24 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=1 a=2LU9hpEdpD8A:10 a=kj9zAlcOel0A:10 a=6ftCXtrV6KU8V8Uh/wkvUw==:17 a=6I5d2MoRAAAA:8 a=RAuyRO8aAAAA:8 a=Z99owlsjL6tQOCPQm5YA:9 a=QGwn88ynb5q_FL5o2zQA:7 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=vyoC9CF5tf3hooPs:21 a=_nHp_P4zyDSC04mO:21 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAF7pqE/LrZVI/2dsb2JhbABEsySBCIIMAQEEATocIxAIAxguOR4GE4gJBAy7KYsDhgkElX0BgRGNVIFdgn4 X-IronPort-AV: E=Sophos;i="4.75,549,1330858800"; d="scan'208";a="104511305" Received: from 203-173-149-72.dsl.dyn.ihug.co.nz (HELO localhost) ([203.173.149.72]) by cust.filter2.content.vf.net.nz with SMTP; 08 May 2012 21:40:14 +1200 Date: Tue, 8 May 2012 21:39:54 +1200 From: Andrew Turner To: Tim Kientzle Message-ID: <20120508213954.3c4a0c0e@fubar.geek.nz> In-Reply-To: <8B01DF29-747A-449C-A762-E852F57C6380@freebsd.org> References: <3B2A320B-3ADE-4F48-B94E-4F0886178251@freebsd.org> <201205070957.03842.jhb@freebsd.org> <8B01DF29-747A-449C-A762-E852F57C6380@freebsd.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; i386-portbld-freebsd8.0) X-Pirate: Arrrr Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org, freebsd-hackers@freebsd.org, John Baldwin Subject: Re: How does loader(8) decide where to load the kernel? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 09:41:25 -0000 On Mon, 7 May 2012 22:32:10 -0700 Tim Kientzle wrote: > > On May 7, 2012, at 6:57 AM, John Baldwin wrote: > > > On Saturday, May 05, 2012 1:06:13 am Tim Kientzle wrote: > >> I have ubldr loading the ELF kernel on BeagleBone and am now > >> trying to untangle some of the hacks I used to get this working. > >> > >> Unfortunately, there's one area of the common loader(8) code > >> that I really don't understand: How does > >> sys/boot/common/load_elf.c determine the physical address at which > >> to load the kernel? > >> > >> __elfN(loadfile) has the following comment: > >> > >> [The file] will be stored at (dest). > >> > >> But that's not really true. For starters, loadfile maps dest > >> through archsw.arch_loadaddr. (This mechanism seems > >> to only be used on ia64 and pc98, though the result is > >> later discarded on those platforms.) > >> > >> Loadfile then passes the value to loadimage which does > >> very strange things: > >> > >> On i386, amd64, powerpc, and arm, loadimage subtracts > >> the dest value from the address declared in the actual ELF > >> headers so that the kernel always gets loaded into low memory. > >> (there's some intermediate bit-twiddling I'm glossing over, but > >> this is the general idea). > > > > The bit twiddling is supposed to be the equivalent of subtracting > > KERNBASE from the load address. On both i386 and amd64, there is > > a direct mapping of the kernel text such that KERNBASE maps address > > 0, etc. By default on i386 KERNBASE is 0xc0000000. > > Exactly my problem. This all assumes that you're loading > the kernel into low memory. > > On the AM3358, the DRAM starts at 0x8000 0000 > on boot, so I'm trying to find a clean way to convince > the loader's ELF code to put the kernel there. I have a script at [1] that builds an image to load the kernel directly from U-Boot. It figures out where to tell U-Boot to load a kernel by using readelf to find the value of physaddr and kernbase to use to calculate what physical addresses to use to load the kernel to and where the first instruction to execute is. Andrew [1] http://fubar.geek.nz/files/freebsd/omap/build_beagle.sh From owner-freebsd-hackers@FreeBSD.ORG Tue May 8 14:15:38 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17371106566B; Tue, 8 May 2012 14:15:38 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id DD9FE8FC08; Tue, 8 May 2012 14:15:37 +0000 (UTC) Received: from John-Baldwins-MacBook-Air.local (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3BE00B93B; Tue, 8 May 2012 10:15:37 -0400 (EDT) Message-ID: <4FA92A88.2030000@FreeBSD.org> Date: Tue, 08 May 2012 10:15:36 -0400 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Andriy Gapon References: <4F8999D2.1080902@FreeBSD.org> <201205070953.04032.jhb@freebsd.org> <4FA7E069.8020208@FreeBSD.org> <201205071343.45955.jhb@freebsd.org> <4FA8C7E3.8070006@FreeBSD.org> In-Reply-To: <4FA8C7E3.8070006@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 08 May 2012 10:15:37 -0400 (EDT) Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 14:15:38 -0000 On 5/8/12 3:14 AM, Andriy Gapon wrote: > on 07/05/2012 20:43 John Baldwin said the following: >> On Monday, May 07, 2012 10:47:05 am Andriy Gapon wrote: >>> on 07/05/2012 16:53 John Baldwin said the following: > [snip] >>> What do you think about the -LOCORE- change that Bruce inspired? >> >> In general I think this looks good. I have only one suggestion. In other >> code (e.g. the genassym constants in the kernel) where we define constants >> for field offsets, we make the constant be the uppercase name of the field >> itself (e.g. TD_PCB for offsetof(struct thread, td_pcb)). I would rather >> do that here as well. In this case the field names do not have a prefix, >> but let's just use a BA_ prefix for members of 'bootargs'. BI_SIZE is >> already correct, but this would mean renaming HT_OFF to BA_HOWTO, BF_OFF to >> BA_BOOTFLAGS, and BI_OFF to BA_BOOTINFO. > > OK, doing this. > >> I think you can probably leave BA_SIZE as-is. > > I see that i386 genassym has a few different styles for sizeof constants: > ABBRSIZE > FULL_NAME_SIZE > ABBR_SIZEOF > > FULL_NAME_SIZE looked the most appealing to me (and seems to be the most > common), so I decided to change BA_SIZE to BOOTARGS_SIZE. > I hope that this makes sense and I am not starting a bikeshed :-) Yeah, given the inconsistency in sizeof() constants in genassym.c, just about anything is fine, which is why I hesitated to suggest any change. BOOTARGS_SIZE is fine. I probably slightly prefer that because it is less ambiguous (in case the structure has a foo_size member such as bi_size in bootinfo). Bruce might even suggest adding a ba_ prefix to all the members of struct bootargs btw. I would not be opposed, but you've already done a fair bit of work on this patch. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue May 8 15:45:59 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E09F51065674 for ; Tue, 8 May 2012 15:45:59 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9B3638FC12 for ; Tue, 8 May 2012 15:45:59 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so9216226pbb.13 for ; Tue, 08 May 2012 08:45:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=PnQau39BPOU03qvZh4c9KpezY7gUldVOJjAlS39vsOY=; b=ibwLCD6qjAfaDWDNc4h/DAK2nH9kEXL+KPHv7wBJT+z+5aBV6CW6ciH8gxgaPYyW9U JleSRb4ngnpvkyCCG7VywEzUDS00mEIwGSxhKDka+S2NlCJsKqrBkvZ3Hyq70ushJafd vipKFwMYwng5aXO9mv8YHW/aLrGqaq2/LZhgesJ6q1SS6N+c9531IZEW0B9bQmMiS8kg Iz+S+mSLMbQxZjh1WDu+3zNpiJUBRftNWO8TeTjjnNsybM4d6TbcbEsfCyhtfhxAc0ut LpRQMCjgP3LbR5CluHAXx3ahnBd+MNeib8bvm1G2RHqVpuFtXOTV0INu+YUC3dIsZGgu S0Mg== Received: by 10.68.213.162 with SMTP id nt2mr1916383pbc.31.1336491959135; Tue, 08 May 2012 08:45:59 -0700 (PDT) Received: from [192.168.1.69] (99-74-169-43.lightspeed.sntcca.sbcglobal.net. [99.74.169.43]) by mx.google.com with ESMTPS id py6sm2761479pbc.13.2012.05.08.08.45.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 May 2012 08:45:57 -0700 (PDT) Sender: Tim Kientzle Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <20120508213954.3c4a0c0e@fubar.geek.nz> Date: Tue, 8 May 2012 08:45:53 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <3B2A320B-3ADE-4F48-B94E-4F0886178251@freebsd.org> <201205070957.03842.jhb@freebsd.org> <8B01DF29-747A-449C-A762-E852F57C6380@freebsd.org> <20120508213954.3c4a0c0e@fubar.geek.nz> To: Andrew Turner X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmU4jflIiCwHTLy7CiOMelkttICoOW30tNG8udxq78ye66e/XBB8a8U5dnfDhsk2Jj1VBFa Cc: arm@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: How does loader(8) decide where to load the kernel? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 15:46:00 -0000 On May 8, 2012, at 2:39 AM, Andrew Turner wrote: > On Mon, 7 May 2012 22:32:10 -0700 > Tim Kientzle wrote: > >> >> On May 7, 2012, at 6:57 AM, John Baldwin wrote: >>> >>> The bit twiddling is supposed to be the equivalent of subtracting >>> KERNBASE from the load address. On both i386 and amd64, there is >>> a direct mapping of the kernel text such that KERNBASE maps address >>> 0, etc. By default on i386 KERNBASE is 0xc0000000. >> >> Exactly my problem. This all assumes that you're loading >> the kernel into low memory. >> >> On the AM3358, the DRAM starts at 0x8000 0000 >> on boot, so I'm trying to find a clean way to convince >> the loader's ELF code to put the kernel there. > > I have a script at [1] that builds an image to load the kernel directly > from U-Boot. It figures out where to tell U-Boot to load a kernel by > using readelf to find the value of physaddr and kernbase to use to > calculate what physical addresses to use to load the kernel to and > where the first instruction to execute is. I have a script at [2] that builds a FreeBSD image for BeagleBone that chain loads U-Boot, then ubldr, then loads the ELF kernel from UFS. Works very well, but it relies on some hacks to the common load_elf code that I'd like to find a clean way to generalize. [2] https://github.com/kientzle/freebsd-beaglebone From owner-freebsd-hackers@FreeBSD.ORG Tue May 8 16:07:21 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C4FC21065673 for ; Tue, 8 May 2012 16:07:21 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by mx1.freebsd.org (Postfix) with ESMTP id A9B2A8FC0C for ; Tue, 8 May 2012 16:07:21 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta02.emeryville.ca.mail.comcast.net with comcast id 7U6f1j0051smiN4A2U7F4G; Tue, 08 May 2012 16:07:15 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta20.emeryville.ca.mail.comcast.net with comcast id 7U7E1j00W4NgCEG8gU7Evs; Tue, 08 May 2012 16:07:15 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q48G7CWF088937 for ; Tue, 8 May 2012 10:07:12 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="us-ascii" Date: Tue, 08 May 2012 10:07:12 -0600 Message-ID: <1336493232.1503.29.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Calling tsleep(9) with interrupts disabled X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 16:07:21 -0000 I just realized that I've accidentally coded a sequence similar to this in a driver: s = intr_disable(); // do stuff here tsleep(sc, 0, "twird", hz / 4); // more stuff intr_restore(s); Much to my surpise this works, including waking up due to wakeup(sc) being called from an interrupt handler. So apparently tsleep() results in interrupts being re-enabled during the sleep, although nothing in the manpage says that will happen. Can I safely rely on this behavior, or is it working by accident? (Please no lectures on the evils of disabling interrupts... This is not a multi-GHz multi-core Xeon, it's a 180mhz embedded SoC with buggy builtin devices that will drop or corrupt data if an interrupt happens during the "do stuff here" part of the code.) -- Ian From owner-freebsd-hackers@FreeBSD.ORG Tue May 8 17:35:30 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B261C106566C for ; Tue, 8 May 2012 17:35:30 +0000 (UTC) (envelope-from eric@shadowsun.net) Received: from mail.atlantawebhost.com (dns1.atlantawebhost.com [66.223.40.39]) by mx1.freebsd.org (Postfix) with ESMTP id 628D58FC12 for ; Tue, 8 May 2012 17:35:30 +0000 (UTC) Received: (qmail 10174 invoked from network); 8 May 2012 13:35:29 -0400 Received: from c-71-192-38-198.hsd1.ma.comcast.net (HELO ?192.168.1.8?) (71.192.38.198) by mail.atlantawebhost.com with SMTP; 8 May 2012 13:35:29 -0400 Message-ID: <4FA95960.7090908@shadowsun.net> Date: Tue, 08 May 2012 13:35:28 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120507 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Enigmail-Version: 1.5pre Content-Type: multipart/mixed; boundary="------------070404040305050203020901" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: GSoC Project: EFI on amd64/i386 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 17:35:30 -0000 This is a multi-part message in MIME format. --------------070404040305050203020901 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everyone, I'm going to be working on EFI boot support on the amd64/i386 platforms as a GSoC project. The idea is to allow booting from EFI (as opposed to legacy BIOS) on these platforms, so that FreeBSD can continue to support a wide range of hardware as EFI begins to replace BIOS. I'd also like to start a discussion on the matter, since it seems there are several ways that this could be done. Also, I know Rui Paulo was working on this a while back. If anyone knows the approach he was taking, that would be helpful. The way IA-64 handles booting might also be helpful. Here are some specific points to be decided: * An EFI boot service could potentially function similarly to [zfs]loader. Alternatively, it could function like gpt[zfs]boot, though this might require modifying loader(8) since EFI boot services run in protected/long mode, and have different system information table formats. * How much of what EFI provides do we want to use? There are advantages and disadvantages both ways. * How much of the kernel needs to be changed to boot/run from an EFI boot? * It seems possible to support booting from legacy BIOS as well as EFI (install a protective MBR, and gpt[zfs]boot on a FreeBSD boot partition, install the EFI boot loader in a way that the EFI firmware will find it and load it, and the system itself on another partition). Is it worth trying to do this? Feel free to chime in with your opinions on these matters. - -- Eric McCorkle Computer Science Ph.D Student eric@shadowsun.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJPqVlgAAoJENSCzbQ+koZ7CpYP/27NtM6Vz1069OLjV/+BRUt0 yxW4t8Tl5QXmMUroNAwhnABMKnFG7HAkYxa0twMLudalQVRxCPhyY3bANHQQt6Od mFWDdeeumNLjsOScT577zkFm7mgAdYzP4hO2C5BaxS6ZfWt5WwFm1WGUbY6GuybA jB3dLDLGWyprlxwTJz2cfhrpbVzRfysXzfbccpSVVkYJp9/UcrCh2bpmh7N0S1HC rRCzj8D1yafbjbyKEjOuVnIZMCoh/KFLbsuA2E0GUk2jfyhZKsX8wfFGKZ+53Dle pP8Hks8pOsaQcxy7vwj9Qf22TKnSrCNvUF/m3oNXi2W1DD4byOiNr6VRD2Zo1Ctw hq4mUAb4pe8P8bySjPrLrZWdk6OQuluvcB7g+8kL12EZEWG0QkVDrj7+noOKicqX ntxPAPEMAFt2imzOcrhmNl88qAb+13WDWFHusU+/pxFYJK9rpwCZN9f9gWh5eiW9 HTUiFapKgPkAW5xqU2Fn+LcT1ViBsBO0XHbuvXTVsJJj331OY+56ZgxnszFPhosV l1At9JBcOGJA5+Yq9BaIMv8kN9S617KW9egLEDL1RyhWzdsvpPzILO5moKARLGXo M+3B1PRUMw7a0zHI6mGa7i6ogP5f85Jp/vKlvYK688H9v68rx8sRQs5k9hMkB1JY YxOb+R6NM6AoEMsQ4loE =80fO -----END PGP SIGNATURE----- --------------070404040305050203020901-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 8 18:34:54 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 18DAD106566B; Tue, 8 May 2012 18:34:54 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 01BA08FC14; Tue, 8 May 2012 18:34:52 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA17715; Tue, 08 May 2012 21:34:50 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SRpFJ-000KeQ-MO; Tue, 08 May 2012 21:34:49 +0300 Message-ID: <4FA96747.3060106@FreeBSD.org> Date: Tue, 08 May 2012 21:34:47 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: John Baldwin References: <4F8999D2.1080902@FreeBSD.org> <201205070953.04032.jhb@freebsd.org> <4FA7E069.8020208@FreeBSD.org> <201205071343.45955.jhb@freebsd.org> <4FA8C7E3.8070006@FreeBSD.org> <4FA92A88.2030000@FreeBSD.org> In-Reply-To: <4FA92A88.2030000@FreeBSD.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 18:34:54 -0000 on 08/05/2012 17:15 John Baldwin said the following: > Bruce might even suggest adding a ba_ prefix to all the members of > struct bootargs btw. I would not be opposed, but you've already done > a fair bit of work on this patch. Thank you for sparing me :-) So I hope to get busy committing this stuff soon. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed May 9 09:32:08 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 30B32106566B; Wed, 9 May 2012 09:32:08 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 10F3C8FC14; Wed, 9 May 2012 09:32:06 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA22436; Wed, 09 May 2012 12:32:05 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SS3Fd-000Nar-AR; Wed, 09 May 2012 12:32:05 +0300 Message-ID: <4FAA3994.2070701@FreeBSD.org> Date: Wed, 09 May 2012 12:32:04 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: John Baldwin , Takahashi Yoshihiro References: <4F8999D2.1080902@FreeBSD.org> <201205070953.04032.jhb@freebsd.org> <4FA7E069.8020208@FreeBSD.org> <201205071343.45955.jhb@freebsd.org> <4FA8C7E3.8070006@FreeBSD.org> <4FA92A88.2030000@FreeBSD.org> <4FA96747.3060106@FreeBSD.org> In-Reply-To: <4FA96747.3060106@FreeBSD.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: bootargs.h [Was: [review request] zfsboot/zfsloader: support accessing filesystems within a pool] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 09:32:08 -0000 Here is a subversion diff to make use of the new bootargs.h header in pc98 cdboot and loader, and i386 cdboot and pxeldr: http://people.freebsd.org/~avg/bootargs.diff Could you please review it? Thank you! MFi386 of BTX changes for support of KARGS_FLAGS_EXTARG is pending. Do you think that it should be done? -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed May 9 11:28:03 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3066A1065673; Wed, 9 May 2012 11:28:03 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0088D8FC08; Wed, 9 May 2012 11:28:02 +0000 (UTC) Received: from John-Baldwins-MacBook-Air.local (unknown [24.114.252.231]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4A21BB93E; Wed, 9 May 2012 07:28:02 -0400 (EDT) Message-ID: <4FAA54C1.20203@FreeBSD.org> Date: Wed, 09 May 2012 07:28:01 -0400 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Andriy Gapon References: <4F8999D2.1080902@FreeBSD.org> <201205070953.04032.jhb@freebsd.org> <4FA7E069.8020208@FreeBSD.org> <201205071343.45955.jhb@freebsd.org> <4FA8C7E3.8070006@FreeBSD.org> <4FA92A88.2030000@FreeBSD.org> <4FA96747.3060106@FreeBSD.org> <4FAA3994.2070701@FreeBSD.org> In-Reply-To: <4FAA3994.2070701@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 09 May 2012 07:28:02 -0400 (EDT) Cc: freebsd-hackers@FreeBSD.org, Takahashi Yoshihiro Subject: Re: bootargs.h [Was: [review request] zfsboot/zfsloader: support accessing filesystems within a pool] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 11:28:03 -0000 On 5/9/12 5:32 AM, Andriy Gapon wrote: > > Here is a subversion diff to make use of the new bootargs.h header in pc98 > cdboot and loader, and i386 cdboot and pxeldr: > http://people.freebsd.org/~avg/bootargs.diff > Could you please review it? > Thank you! Looks good. > MFi386 of BTX changes for support of KARGS_FLAGS_EXTARG is pending. > Do you think that it should be done? You mean to pc98's btxldr? I think so, in general we should keep the pc98 BTX bits as close to i386 as possible. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed May 9 14:46:10 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F3432106564A for ; Wed, 9 May 2012 14:46:10 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id ACC4E8FC0A for ; Wed, 9 May 2012 14:46:10 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1SS89T-000H1R-W1 for freebsd-hackers@FreeBSD.org; Wed, 09 May 2012 17:46:04 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: freebsd-hackers@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 09 May 2012 17:46:03 +0300 From: Daniel Braniss Message-ID: Cc: Subject: PCEngines alix.6 with dual SIM X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 14:46:11 -0000 Hi, after a long time, I finaly got around trying to get the GSM/UMTS working, but so far it thinks it's a mass storage! ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0110 bDeviceClass = 0x0000 bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0040 idVendor = 0x1199 idProduct = 0x0fff bcdDevice = 0x0000 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x0003 bNumConfigurations = 0x0001 I added U3G_DEV(SIERRA, TRUINSTALL, 0), to sys/dev/usb/serial/u3g.c but that did not help so any help? danny From owner-freebsd-hackers@FreeBSD.ORG Wed May 9 15:03:29 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA3C81065702 for ; Wed, 9 May 2012 15:03:29 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 74AC78FC0A for ; Wed, 9 May 2012 15:03:29 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.4) with ESMTP id q49F15Au045750; Wed, 9 May 2012 11:01:05 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4FAA86B0.4070202@sentex.net> Date: Wed, 09 May 2012 11:01:04 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Daniel Braniss References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 64.7.153.18 Cc: freebsd-hackers@freebsd.org Subject: Re: PCEngines alix.6 with dual SIM X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 15:03:29 -0000 On 5/9/2012 10:46 AM, Daniel Braniss wrote: > Hi, > after a long time, I finaly got around trying to get the GSM/UMTS working, > but so far it thinks it's a mass storage! > > ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL > (12Mbps) pwr=ON > > bLength = 0x0012 > bDescriptorType = 0x0001 > bcdUSB = 0x0110 > bDeviceClass = 0x0000 > bDeviceSubClass = 0x0000 > bDeviceProtocol = 0x0000 > bMaxPacketSize0 = 0x0040 > idVendor = 0x1199 > idProduct = 0x0fff > bcdDevice = 0x0000 > iManufacturer = 0x0001 > iProduct = 0x0002 > iSerialNumber = 0x0003 > bNumConfigurations = 0x0001 > > I added > U3G_DEV(SIERRA, TRUINSTALL, 0), > > to sys/dev/usb/serial/u3g.c but that did not help Normally its U3GINIT_SIERRA in the driver I have in stable. If you do a camcontrol eject pass0 does it put the device into modem mode ? If you add hw.usb.u3g.debug=1 to /boot/loader.conf what does the dmesg look like. I have used a number of sierra devices in the past with the Alix boxes and they do work. Not sure about your particular unit. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-hackers@FreeBSD.ORG Wed May 9 16:05:59 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 594F81065670 for ; Wed, 9 May 2012 16:05:59 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2D35B8FC0C for ; Wed, 9 May 2012 16:05:59 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so825452pbb.13 for ; Wed, 09 May 2012 09:05:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:content-type:x-mailer:message-id:date:to :content-transfer-encoding:mime-version; bh=wORIPEOIv+U6E2zzyrfEpiuqDh3pqs1I84m557XU0Ks=; b=Ede0zzo/FZv23lBA6hR9UQVcy/I/FYFvYidP9YJlHaw8R0ONvT/XXZz8ETw8iZBWO+ wU2otA2R/uCuQqn1O9Bq0WXi+/4bDM6Nqm2pjrX9O89pkGUcxImb+shjx2ohnUtu4LfT nmQaVeX7GlgW2MOEgCQF+y0N1HNfZjzTGNgA8DSw8UASWM2n+T4KIHW5BT4niHkKC4Kz 1W3nos6/gvNXwGq4cqoWBdKd27BbsKdmD4iRq2mii5kwjLiZQSwbQ+Bqjnob4/1KoY8G rIdcBlR6EANpnQbMMmgDZ5zVgy2BvkoUZb4+rch2SkISs+yfBY0m2YuS4qYHOS8LFBan G23w== Received: by 10.68.191.230 with SMTP id hb6mr10569747pbc.167.1336579553360; Wed, 09 May 2012 09:05:53 -0700 (PDT) Received: from [10.6.137.181] (mobile-166-147-080-052.mycingular.net. [166.147.80.52]) by mx.google.com with ESMTPS id vc4sm948275pbc.8.2012.05.09.09.05.50 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 May 2012 09:05:52 -0700 (PDT) From: Garrett Cooper Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (9B179) Message-Id: Date: Wed, 9 May 2012 09:05:47 -0700 To: "hackers@FreeBSD.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Cc: Subject: Thoughts about kenv emulating sysctl X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 16:05:59 -0000 Hi Hackers, I've been asked to write up a script to analyze tunables via kenv for ar= chival purposes an to establish a baseline set of static variables. In order to make life easier (and be able to do all the grunt work in a s= hell one-liner instead of introducing a bug prone tunable parser) I have wri= tten up a patch which would make kenv function a bit more like sysctl, wrt t= he fact that sysctl -n suppresses suffixing a value with the variable name w= hen executed like so: # kenv LINES LINES=3D"24" # kenv -n LINES 24 I've also considered keeping the functional defaults and instead do the f= ollowing... # kenv -v LINES LINES=3D"24" # kenv LINES 24 Pro of the first form is that it matches sysctl, pro of the second form i= s that it doesn't break backwards 'compatibility'. I know kenv isn't a widely used utility (albeit, I have seen it used in a= few spots outside of FreeBSD proper), but I was wondering if anyone could s= ee any potential pitfalls or would have a large degree of heartburn over cha= nging the default to match sysctl. Thanks! -Garrett= From owner-freebsd-hackers@FreeBSD.ORG Wed May 9 19:45:15 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB80C106564A for ; Wed, 9 May 2012 19:45:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7F5CF8FC08 for ; Wed, 9 May 2012 19:45:06 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so1111136pbb.13 for ; Wed, 09 May 2012 12:45:06 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Py2RWE26ZzvoISNiS4GYMR7etVfFdjDIy/0VB6jft7A=; b=HWXMUk5ajBYfnPqjbhOHPebT0bRGQoiqSVaFMc0NNoptKqvmn/yQddt4HIt049Ae3F 1qZqN6gyS3iLkLGyGVS8tsP8gGKYmZeGv2NDL9I58bXE1Ub50ocsDvg56koVvkNUPQd7 A6c5B+2l3DP1h8sBnDB8QcZAcsbdOMOgsneXwe1GFUF06J+rVvP7GjbkNEcD6TOO9PiE 9A+1q8ZieTqmdPaCvxGdqvNlJZnFNN+o8dkG8veCw27GU3iqHjKKjnfgVoy5SUcIxUdd a58t8+sha4AAHCpdTUVjY3lizwyuq7Y/XZJkVCgt7aI6dw1aRcFK2EO9094mi9eyVMXu EGFw== MIME-Version: 1.0 Received: by 10.68.234.35 with SMTP id ub3mr12634246pbc.8.1336592703318; Wed, 09 May 2012 12:45:03 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.142.101.9 with HTTP; Wed, 9 May 2012 12:45:03 -0700 (PDT) In-Reply-To: <1336493232.1503.29.camel@revolution.hippie.lan> References: <1336493232.1503.29.camel@revolution.hippie.lan> Date: Wed, 9 May 2012 12:45:03 -0700 X-Google-Sender-Auth: WwnJaBzGWLaIfibfU-3oG5xAcMI Message-ID: From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: Calling tsleep(9) with interrupts disabled X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 19:45:15 -0000 .. re-run with witness? :) Adrian From owner-freebsd-hackers@FreeBSD.ORG Wed May 9 22:03:05 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A1D09106564A for ; Wed, 9 May 2012 22:03:05 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 2E8458FC19 for ; Wed, 9 May 2012 22:03:05 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so802710wgb.31 for ; Wed, 09 May 2012 15:03:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=fEXnHao1fvUxi20ntC5XSdIzejj/FXeq+LGxwP3T4fs=; b=dS/sBsFCeZA4Miyb9D4Evn5bJjJX50lYvnGujjrWDs/+NkOdoGqyzmq6uOLaC2liYO Kn+bln24yqlE0mYKxLtGKixQz5vjohNnOloANT4XEnYObiR+DpTEO1g04WJHqqicTQao 04U32IiJu1pKEJrphupH0Xx9+2Ra75neKx2P+HesRuTLQFd/7jjwVvBAGgAdH7/5HYtu QPHZqBezWKzwq7tUiVdFvHupUTTtn0aeFelzX0q8wB6i3fUwHB0JddQjoiE5wbniJT4X pWdPe30NEHOT5qmUV5lx5UkIQWBq+zjBOf4ohn50KCzyFwqW9nldxS8EUbi02NGKSMdU Rq0g== Received: by 10.216.201.150 with SMTP id b22mr118446weo.103.1336600983993; Wed, 09 May 2012 15:03:03 -0700 (PDT) Received: from rnote.ddteam.net (157-86-133-95.pool.ukrtel.net. [95.133.86.157]) by mx.google.com with ESMTPS id ex2sm13967491wib.8.2012.05.09.15.03.01 (version=SSLv3 cipher=OTHER); Wed, 09 May 2012 15:03:01 -0700 (PDT) Date: Thu, 10 May 2012 01:02:58 +0300 From: Aleksandr Rybalko To: Garrett Cooper Message-Id: <20120510010258.2653aeea.ray@ddteam.net> In-Reply-To: References: X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkMaj5h3WC8y1MbxCj5JozlWndq6q3SELaSSRT79jWmxnzIzLEfi5vDY4AhAPb0YQNbFlAx Cc: "hackers@FreeBSD.org" Subject: Re: Thoughts about kenv emulating sysctl X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 22:03:05 -0000 On Wed, 9 May 2012 09:05:47 -0700 Garrett Cooper wrote: > Hi Hackers, > I've been asked to write up a script to analyze tunables via kenv > for archival purposes an to establish a baseline set of static > variables. In order to make life easier (and be able to do all the > grunt work in a shell one-liner instead of introducing a bug prone > tunable parser) I have written up a patch which would make kenv > function a bit more like sysctl, wrt the fact that sysctl -n > suppresses suffixing a value with the variable name when executed > like so: > > # kenv LINES > LINES="24" > # kenv -n LINES > 24 > > I've also considered keeping the functional defaults and instead > do the following... > > # kenv -v LINES > LINES="24" > # kenv LINES > 24 > > Pro of the first form is that it matches sysctl, pro of the > second form is that it doesn't break backwards 'compatibility'. I > know kenv isn't a widely used utility (albeit, I have seen it used in > a few spots outside of FreeBSD proper), but I was wondering if anyone > could see any potential pitfalls or would have a large degree of > heartburn over changing the default to match sysctl. Thanks! > -Garrett_______________________________________________ > 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" Hi Garret, I use it for embedded, kenv is good transport shared by loader, kernel and userland (since there is no RW storages). IMO, kenv != sysctl, so we not need to match sysctl. But backwards 'compatibility' is good reason to select second way. Thanks. WWW -- Aleksandr Rybalko From owner-freebsd-hackers@FreeBSD.ORG Wed May 9 23:38:50 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3D84F106564A for ; Wed, 9 May 2012 23:38:50 +0000 (UTC) (envelope-from brodbd@uw.edu) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0D7DC8FC0C for ; Wed, 9 May 2012 23:38:50 +0000 (UTC) Received: by dadv36 with SMTP id v36so1126599dad.13 for ; Wed, 09 May 2012 16:38:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=UAVHgDBf7VNSs58vs1kT1Tib03oBn6mVvxwvntM1yA8=; b=jfzaRdntj9G1BG30ysUgEZfKbZmGC3PcqwtjpVSS7WFqaU/r/eAtHc7eWg22ILpw6U RVRNemfgJV5HN+zZqbBmuy1etbP7lpOU8kTu5vVxUHEckMbGeTv/yk6uf5cBcjji+22u qSYV0X46pmxGBXLJ/iCrrPioA6k11sgpqLwhSo+5i1G+YauaFB/rVRHRabTndRIsVVKB LFAgvqIXpsPoIRJJF3+64zcgP0tvK7nqPHdlIZXT8V6pEqQ+l5B3H9UduWd5c39FGUuG ADuhzsc/V2RIj9S8c3npD/oujRjyt3P8RaS0hdbfvZ+tizBLprXA8U3exMuLpsw8ejhY 4iow== MIME-Version: 1.0 Received: by 10.68.212.229 with SMTP id nn5mr10647633pbc.143.1336606728938; Wed, 09 May 2012 16:38:48 -0700 (PDT) Received: by 10.68.1.234 with HTTP; Wed, 9 May 2012 16:38:48 -0700 (PDT) In-Reply-To: References: <20120430085748.GA56921@server.vk2pj.dyndns.org> Date: Wed, 9 May 2012 16:38:48 -0700 Message-ID: From: David Brodbeck To: Wojciech Puchar Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl3qOiMg4xogpTekKZ+9YCT7dlf7kNM9zczLeXNuhxQ7UqLagyFK5KHbsjEfJHbc66za8EF Cc: freebsd-hackers@freebsd.org, Peter Jeremy Subject: Re: NFS - slow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 23:38:50 -0000 On Mon, Apr 30, 2012 at 10:00 PM, Wojciech Puchar wrote: > i tried nfsv4, tested under FreeBSD over localhost and it is roughly the > same. am i doing something wrong? I found NFSv4 to be much *slower* than NFSv3 on FreeBSD, when I benchmarked it a year or so ago. --=20 David Brodbeck System Administrator,=A0Linguistics University of Washington From owner-freebsd-hackers@FreeBSD.ORG Thu May 10 00:27:52 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5886106566C for ; Thu, 10 May 2012 00:27:52 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 55A1E8FC16 for ; Thu, 10 May 2012 00:27:52 +0000 (UTC) Received: by vbmv11 with SMTP id v11so1296041vbm.13 for ; Wed, 09 May 2012 17:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PDu2qZU2glXZeSs/WlBHzMSrO7YNekxKgOG0s7HFy8s=; b=J9wVt3lOeXH+xkBIJTEnpQ4Ha7qpgERIiYxHU6uHwXTxRyIYTeEMcwRtQ4RhDCC3QL 5VFYDztMm9uxEoDhOZj80fJnlkyUAJVPEzENrS9DjX2PDgyRw7x44dwmCB6YQt7w4DJF MVHmRCFvs8C02oqh4HIPZD9GgPYbIi7edsyVr0FtCkxcvU36Qs1/+q3UTdIGFo7GBU4a 2dpqknPfhi5morbzJ9G5gT5ynjcaxNTeEuRZCW55jz3B9zKVHQox4B98KUhF7kb67a3R F6wUjff99rihtC1dpZerJ9J4paxKFZNWemW8bi9KdN+JDOygTomaiq/NE5N9QVVlq+si zwbg== MIME-Version: 1.0 Received: by 10.220.153.8 with SMTP id i8mr1231153vcw.73.1336609671544; Wed, 09 May 2012 17:27:51 -0700 (PDT) Received: by 10.220.7.148 with HTTP; Wed, 9 May 2012 17:27:51 -0700 (PDT) In-Reply-To: <20120510010258.2653aeea.ray@ddteam.net> References: <20120510010258.2653aeea.ray@ddteam.net> Date: Wed, 9 May 2012 17:27:51 -0700 Message-ID: From: Garrett Cooper To: Aleksandr Rybalko Content-Type: text/plain; charset=ISO-8859-1 Cc: "hackers@FreeBSD.org" Subject: Re: Thoughts about kenv emulating sysctl X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 00:27:52 -0000 Hi Aleksandr! On Wed, May 9, 2012 at 3:02 PM, Aleksandr Rybalko wrote: > On Wed, 9 May 2012 09:05:47 -0700 > Garrett Cooper wrote: ... > Hi Garret, > > I use it for embedded, kenv is good transport shared by loader, kernel > and userland (since there is no RW storages). Indeed. > IMO, kenv != sysctl, so we not need to match sysctl. But backwards > 'compatibility' is good reason to select second way. Which is what I figured; I favored the latter course at first and developed my patch based on that mindset, because I know people hate it when backwards compatibility is broken :) (in all fairness I'm generally one of them). Thanks! -Garrett From owner-freebsd-hackers@FreeBSD.ORG Thu May 10 01:34:12 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C6659106564A for ; Thu, 10 May 2012 01:34:12 +0000 (UTC) (envelope-from rsimmons0@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 849F28FC0A for ; Thu, 10 May 2012 01:34:12 +0000 (UTC) Received: by vbmv11 with SMTP id v11so1361648vbm.13 for ; Wed, 09 May 2012 18:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=DLU5h6t3w5+JJGITMTLusWdacM9A2BycjRkwzLjS0NA=; b=TFUDbPgDINFKaRnV7FSRb7ROKqUdt5jDh1XCP/OMIKDMd6X+tURNLB8RWVR1QnlITS Nf1jFpqF0Zafp+mXMWd80FXkbI/T9pSs09RzpmbioXhsvf/4dyWqvj3nBByFH+S2UMJA Jh+dZ8tnCpT8EPjf7MSs+FwIE2/ihVp7FI18rFAOPhJWYbxURKWHM8FFB+vODaE4W6cy IIB2fFx++ooSY9ALiV3zpF+9M2ClRsh/tviHQ6R8/zEia/2O9brWO30PY/W3Gx/NsiE0 WJsXtOiWeC1EyPD/bKcmgttZiDmmYg9ZWGyW03BW7KSAXxK4ZBGYH6t0SrkE7Lp3578R sFCw== MIME-Version: 1.0 Received: by 10.220.39.197 with SMTP id h5mr248175vce.51.1336613651883; Wed, 09 May 2012 18:34:11 -0700 (PDT) Received: by 10.52.112.167 with HTTP; Wed, 9 May 2012 18:34:11 -0700 (PDT) Date: Wed, 9 May 2012 21:34:11 -0400 Message-ID: From: Robert Simmons To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: csh builtin command problems X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 01:34:12 -0000 I'm trying to use sysv style echo in /bin/csh and I've hit a wall as to how to get it to work. The following does not have the outcome that I'm looking for: # echo_style=sysv # echo test\ttest > test # cat test testttest I want this: # echo test\ttest > test # cat test test test Any thoughts? From owner-freebsd-hackers@FreeBSD.ORG Thu May 10 06:00:35 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 88E911065672 for ; Thu, 10 May 2012 06:00:35 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 3D8788FC12 for ; Thu, 10 May 2012 06:00:34 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1SSMQR-0005Lf-LU; Thu, 10 May 2012 09:00:31 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Mike Tancsa In-reply-to: <4FAA86B0.4070202@sentex.net> References: <4FAA86B0.4070202@sentex.net> Comments: In-reply-to Mike Tancsa message dated "Wed, 09 May 2012 11:01:04 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 10 May 2012 09:00:31 +0300 From: Daniel Braniss Message-ID: Cc: freebsd-hackers@freebsd.org, Hans Petter Selasky Subject: Re: PCEngines alix.6 with dual SIM X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 06:00:35 -0000 > On 5/9/2012 10:46 AM, Daniel Braniss wrote: > > Hi, > > after a long time, I finaly got around trying to get the GSM/UMTS working, > > but so far it thinks it's a mass storage! > > > > ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL > > (12Mbps) pwr=ON > > > > bLength = 0x0012 > > bDescriptorType = 0x0001 > > bcdUSB = 0x0110 > > bDeviceClass = 0x0000 > > bDeviceSubClass = 0x0000 > > bDeviceProtocol = 0x0000 > > bMaxPacketSize0 = 0x0040 > > idVendor = 0x1199 > > idProduct = 0x0fff > > bcdDevice = 0x0000 > > iManufacturer = 0x0001 > > iProduct = 0x0002 > > iSerialNumber = 0x0003 > > bNumConfigurations = 0x0001 > > > > I added > > U3G_DEV(SIERRA, TRUINSTALL, 0), > > > > to sys/dev/usb/serial/u3g.c but that did not help > > Normally its U3GINIT_SIERRA in the driver I have in stable. If you do a > camcontrol eject pass0 > does it put the device into modem mode ? If you add > hw.usb.u3g.debug=1 > to /boot/loader.conf > what does the dmesg look like. I have used a number of sierra devices > in the past with the Alix boxes and they do work. Not sure about your > particular unit. > > ---Mike hi all, I removed the line I added to urg.c, then kldloaded u3g, and voila: ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON Mike, which minipci cards do you recomend? thanks all, danny ps: now the fun begins - coding From owner-freebsd-hackers@FreeBSD.ORG Thu May 10 08:04:43 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11065106564A; Thu, 10 May 2012 08:04:43 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from mail.kirov.so-ups.ru (mail.kirov.so-ups.ru [178.74.170.1]) by mx1.freebsd.org (Postfix) with ESMTP id A92A28FC12; Thu, 10 May 2012 08:04:42 +0000 (UTC) Received: from kas30pipe.localhost (localhost.kirov.so-ups.ru [127.0.0.1]) by mail.kirov.so-ups.ru (Postfix) with SMTP id 6A0BEB801B; Thu, 10 May 2012 12:04:39 +0400 (MSK) Received: from kirov.so-ups.ru (unknown [172.21.81.1]) by mail.kirov.so-ups.ru (Postfix) with ESMTP id 5FBE3B8008; Thu, 10 May 2012 12:04:39 +0400 (MSK) Received: by ns.kirov.so-ups.ru (Postfix, from userid 1010) id 55F11BA035; Thu, 10 May 2012 12:04:39 +0400 (MSK) Received: from [127.0.0.1] (unknown [10.118.3.52]) by ns.kirov.so-ups.ru (Postfix) with ESMTP id 1E366BA02C; Thu, 10 May 2012 12:04:39 +0400 (MSK) Message-ID: <4FAB7697.50706@FreeBSD.org> Date: Thu, 10 May 2012 12:04:39 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Eric McCorkle References: <4FA95960.7090908@shadowsun.net> In-Reply-To: <4FA95960.7090908@shadowsun.net> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release X-SpamTest-Info: Not protected Cc: freebsd-hackers@freebsd.org, Marcel Moolenaar , rpaulo@FreeBSD.org Subject: Re: GSoC Project: EFI on amd64/i386 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 08:04:43 -0000 On 08.05.2012 21:35, Eric McCorkle wrote: > I'd also like to start a discussion on the matter, since it seems > there are several ways that this could be done. Also, I know Rui > Paulo was working on this a while back. If anyone knows the approach > he was taking, that would be helpful. The way IA-64 handles booting > might also be helpful. I hope Rui and Marcel can share their experience. > * An EFI boot service could potentially function similarly to > [zfs]loader. Alternatively, it could function like gpt[zfs]boot, > though this might require modifying loader(8) since EFI boot services > run in protected/long mode, and have different system information > table formats. > > * How much of what EFI provides do we want to use? There are > advantages and disadvantages both ways. My thoughts on how this should work: Our EFI loader should be placed to the EFI system partition. UEFI firmware executes it and loader works like non-UEFI loader does. I.e. it searches freebsd partitions via libefi and loads kernel. > * How much of the kernel needs to be changed to boot/run from an EFI boot? I think it is not needed. > * It seems possible to support booting from legacy BIOS as well as EFI > (install a protective MBR, and gpt[zfs]boot on a FreeBSD boot > partition, install the EFI boot loader in a way that the EFI firmware > will find it and load it, and the system itself on another partition). > Is it worth trying to do this? We already can boot via PMBR+gpt[zfs]boot, but EFI loader should not depend on that. -- WBR, Andrey V. Elsukov From owner-freebsd-hackers@FreeBSD.ORG Thu May 10 09:41:11 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1FC101065670; Thu, 10 May 2012 09:41:11 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B4C518FC12; Thu, 10 May 2012 09:41:09 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA04033; Thu, 10 May 2012 12:41:08 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SSPrv-0000pf-Qh; Thu, 10 May 2012 12:41:07 +0300 Message-ID: <4FAB8D31.8050301@FreeBSD.org> Date: Thu, 10 May 2012 12:41:05 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: John Baldwin References: <4F8999D2.1080902@FreeBSD.org> <201205070953.04032.jhb@freebsd.org> <4FA7E069.8020208@FreeBSD.org> <201205071343.45955.jhb@freebsd.org> <4FA8C7E3.8070006@FreeBSD.org> <4FA92A88.2030000@FreeBSD.org> <4FA96747.3060106@FreeBSD.org> <4FAA3994.2070701@FreeBSD.org> <4FAA54C1.20203@FreeBSD.org> In-Reply-To: <4FAA54C1.20203@FreeBSD.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Takahashi Yoshihiro Subject: Re: bootargs.h X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 09:41:11 -0000 on 09/05/2012 14:28 John Baldwin said the following: > On 5/9/12 5:32 AM, Andriy Gapon wrote: >> >> Here is a subversion diff to make use of the new bootargs.h header in pc98 >> cdboot and loader, and i386 cdboot and pxeldr: >> http://people.freebsd.org/~avg/bootargs.diff >> Could you please review it? >> Thank you! > > Looks good. > >> MFi386 of BTX changes for support of KARGS_FLAGS_EXTARG is pending. >> Do you think that it should be done? > > You mean to pc98's btxldr? I think so, in general we should keep the > pc98 BTX bits as close to i386 as possible. > Yes. Here is a complete pc98 patch for bootargs.h and btxldr: http://people.freebsd.org/~avg/pc98-btxldr.diff -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu May 10 10:10:14 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C22B610656D8; Thu, 10 May 2012 10:10:14 +0000 (UTC) (envelope-from colonv57@nobleenergyinc.com) Received: from host82-129-static.199-31-b.business.telecomitalia.it (host82-129-static.199-31-b.business.telecomitalia.it [31.199.129.82]) by mx1.freebsd.org (Postfix) with ESMTP id 01D3B8FC0A; Thu, 10 May 2012 10:10:13 +0000 (UTC) Received: from apache by qbqdierrcqdgqiradsdvb.surewest.com with local (Exim 4.63) (envelope-from <, , >) id GIN0F3-DDYAMN-4Z for , , ; Thu, 10 May 2012 11:10:11 +0100 To: , , Date: Thu, 10 May 2012 11:10:11 +0100 From: , , Message-ID: X-Priority: 3 X-Mailer: PHPMailer 5.1 (phpmailer.sourceforge.net) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-2" Cc: Subject: Work offer inside X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 10:10:14 -0000 Job Category: Customer Support/Client Care Reference Code: HJR/EU/856-738 Job Status: Full Time, Temporary/Contract/Project Great company represented in 32 countries worldwide is seeking a Customer Service Representative. This is a temporary position with the great opportunity of going permanent. The responsibilities are as follows: assist to work with existing clients, arrange and assure preparation, final inspection, timely implementation of orders as well as all related documentation and paperwork. Meet the deadline of orders which require certain time frames. Ensure all orders comply with customer routing guides and regulations. Obtain proofs of delivery from companies and track orders. Interface with our financial department to confirm deliveries and resolve discrepancies. Update corporate offices with order and delivery information, etc. MINIMUM REQUIREMENTS - Some college or equivalent - Previous customer service experience is a plus - Experience working in an office environment - Strong organizational, communication, interpersonal skills, and attention to detail - Advanced knowledge of Microsoft Word, Internet and Email. SALARY AND BENEFITS - Fully paid training - Competitive salary up to 2300 Euro per month - Possibility for promotion - Friendly and professional work environment If you do meet the above preconditions and have a desire to know more about this position, please send us your contact details and our HR specialists will explain you everything in detail over the phone. Our contact: Carmelo@employmenteu.com Have a nice day! From owner-freebsd-hackers@FreeBSD.ORG Thu May 10 11:45:46 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 874E3106566B for ; Thu, 10 May 2012 11:45:46 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 382988FC08 for ; Thu, 10 May 2012 11:45:46 +0000 (UTC) Received: from [192.168.1.157] ([199.119.128.74]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q4ABjZNb075083 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 May 2012 04:45:43 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Marcel Moolenaar In-Reply-To: <4FA95960.7090908@shadowsun.net> Date: Thu, 10 May 2012 07:45:35 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <4FA95960.7090908@shadowsun.net> To: Eric McCorkle X-Mailer: Apple Mail (2.1278) Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC Project: EFI on amd64/i386 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 11:45:46 -0000 On May 8, 2012, at 1:35 PM, Eric McCorkle wrote: > Here are some specific points to be decided: > > * An EFI boot service could potentially function similarly to > [zfs]loader. Alternatively, it could function like gpt[zfs]boot, > though this might require modifying loader(8) since EFI boot services > run in protected/long mode, and have different system information > table formats. Your terminology is a bit confusing. EFI provides boot services and runtime services. These services allow EFI applications (e.g. loaders) to do stuff, like output to a console or read/write file systems, etc. The runtime services are not available to a kernel. Only the boot services can be used by a kernel. Now, as for the FreeBSD boot loader: it's currently an EFI program/image that can be run from within EFI and that uses the boot- and runtime services to load the FreeBSD kernel from a file system it knows about in some GPT partition. The loader is stored in the EFI system partition so that it can be found and run. > * How much of what EFI provides do we want to use? There are > advantages and disadvantages both ways. I don't understand the question. Can you elaborate? > * How much of the kernel needs to be changed to boot/run from an EFI boot? The hand-off will be different. In particular, a proper loader will not load the kernel at some hardcoded address. Instead it will use EFI's memory allocation routines to get available memory chunks and load a kernel there. Since the kernel may not occupy a single contiguous range in physical memory this way, you want the loader to set up page tables as well. Put differently: the current state of affairs is that the EFI loader we have loads a kernel, but can't boot it. > * It seems possible to support booting from legacy BIOS as well as EFI > (install a protective MBR, and gpt[zfs]boot on a FreeBSD boot > partition, install the EFI boot loader in a way that the EFI firmware > will find it and load it, and the system itself on another partition). > Is it worth trying to do this? You need to support both anyways. But not at the same time. The machine either boots BIOS or EFI and depending on that will it use the EFI loader or use the MBR to load boot code. There's nothing to try. Key is to have a single kernel loadable and bootable by either the EFI loader or using the "legacy" loader. -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-hackers@FreeBSD.ORG Thu May 10 12:11:16 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B1B26106564A for ; Thu, 10 May 2012 12:11:16 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 6662B8FC14 for ; Thu, 10 May 2012 12:11:16 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAAevq0+DaFvO/2dsb2JhbABEDoVorxiCFQEBAQQBAQEgKyALGw4KAgINGQIpAQkmBggHBAEcBIdtC6gfkwmBL4ljGYR4gRgEk0+CLoERjy+BeDhVgUM X-IronPort-AV: E=Sophos;i="4.75,565,1330923600"; d="scan'208";a="168680540" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 10 May 2012 08:11:13 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id BF879B3F2B; Thu, 10 May 2012 08:11:13 -0400 (EDT) Date: Thu, 10 May 2012 08:11:13 -0400 (EDT) From: Rick Macklem To: David Brodbeck Message-ID: <628700802.190986.1336651873765.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-hackers@freebsd.org, Peter Jeremy , Wojciech Puchar Subject: Re: NFS - slow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 12:11:16 -0000 David Brodbeck wrote: > On Mon, Apr 30, 2012 at 10:00 PM, Wojciech Puchar > wrote: > > i tried nfsv4, tested under FreeBSD over localhost and it is roughly > > the > > same. am i doing something wrong? > > I found NFSv4 to be much *slower* than NFSv3 on FreeBSD, when I > benchmarked it a year or so ago. > If delegations are not enabled, there is additional overhead doing the Open operations against the server. Delegations are not enabled by default in the server, because there isn't code to handle conflicts with opens done locally on the server. (ie. Delegations work iff the volumes exported over NFSv4 are not accessed locally in the server.) I think there are also some issues w.r.t. name caching in the client that still need to be resolved. NFSv4 should provide better byte range locking, plus NFSv4 ACLs and a few other things. However, it is more complex and will not perform better than NFSv3, at least until delegations are used (or pNFS, which is a part of NFSv4.1). rick > -- > David Brodbeck > System Administrator, Linguistics > University of Washington > _______________________________________________ > 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 May 10 12:32:37 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D332106566C; Thu, 10 May 2012 12:32:37 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id E9A208FC0A; Thu, 10 May 2012 12:32:36 +0000 (UTC) Received: from sa-nc-cs-39.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q4ACWSvP075253 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 May 2012 05:32:35 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Marcel Moolenaar In-Reply-To: <8B01DF29-747A-449C-A762-E852F57C6380@freebsd.org> Date: Thu, 10 May 2012 08:32:23 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <3B2A320B-3ADE-4F48-B94E-4F0886178251@freebsd.org> <201205070957.03842.jhb@freebsd.org> <8B01DF29-747A-449C-A762-E852F57C6380@freebsd.org> To: Tim Kientzle X-Mailer: Apple Mail (2.1278) Cc: arm@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: How does loader(8) decide where to load the kernel? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 12:32:37 -0000 On May 8, 2012, at 1:32 AM, Tim Kientzle wrote: >>> On i386, amd64, powerpc, and arm, loadimage subtracts >>> the dest value from the address declared in the actual ELF >>> headers so that the kernel always gets loaded into low memory. >>> (there's some intermediate bit-twiddling I'm glossing over, but >>> this is the general idea). >> >> The bit twiddling is supposed to be the equivalent of subtracting >> KERNBASE from the load address. On both i386 and amd64, there is >> a direct mapping of the kernel text such that KERNBASE maps address >> 0, etc. By default on i386 KERNBASE is 0xc0000000. > > Exactly my problem. This all assumes that you're loading > the kernel into low memory. > > On the AM3358, the DRAM starts at 0x8000 0000 > on boot, so I'm trying to find a clean way to convince > the loader's ELF code to put the kernel there. Look at what I did for ia64. All that frobbing should be done in the machine specific implementation of arch_copyin, arch_copyout and arch_readin. It's a kluge to do it in elf_loadimage. FYI, -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-hackers@FreeBSD.ORG Thu May 10 14:17:17 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 548DD1065670 for ; Thu, 10 May 2012 14:17:17 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 1514D8FC0C for ; Thu, 10 May 2012 14:17:17 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.4) with ESMTP id q4AEGopo099283; Thu, 10 May 2012 10:16:50 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4FABCDCF.2080203@sentex.net> Date: Thu, 10 May 2012 10:16:47 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Daniel Braniss References: <4FAA86B0.4070202@sentex.net> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 64.7.153.18 Cc: freebsd-hackers@freebsd.org Subject: Re: PCEngines alix.6 with dual SIM X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 14:17:17 -0000 On 5/10/2012 2:00 AM, Daniel Braniss wrote: > hi all, > I removed the line I added to urg.c, then kldloaded u3g, and voila: > ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON > > Mike, which minipci cards do you recomend? > thanks all, > danny > ps: now the fun begins - coding Hi, The Sierra ones seem to work ok, but I have used Ovation units in the past as well. I dont know much behind the technology, but I get the sense that some cards will work better with some carriers than others. So if your local carrier / telco sells Ovation units, get those. If they sell Sierra, get those. Obviously, supported frequency is a big thing, but generally they just work. The nice thing about the Sierra ones is they provide a bit more diagnostic info. Signal strength etc. One small challenge I often run into is that the manufactures will make new versions of the devices and their USB ids will change. Even though the model# is the same, they present differently. Oh, and serial ports too. Some units will be cuaU0.0 others might be cuaU0.3. There doesnt seem to be any rhyme or reason sometimes.... ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-hackers@FreeBSD.ORG Thu May 10 14:27:08 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 187601065676; Thu, 10 May 2012 14:27:08 +0000 (UTC) (envelope-from feld@feld.me) Received: from feld.me (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id D5F8C8FC0A; Thu, 10 May 2012 14:27:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Mime-Version:Date:References:Subject:To:Content-Type; bh=5Ua4XRhn3/NsMP69DwbnLcXqFU9/XHaKfP518z+Z2zo=; b=QP5P2cTqv2Lqt5VrnlRI/iapotpe15Audz+VaCA4w6yp5R9NbYok408fHvMdrIKTGV9WS3WrwU25tGNHLAdijLGF5965h4eqrLUrR3T1wozYmsma57NZMK1ExqfgSJav; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SSUKb-000L6t-Cs; Thu, 10 May 2012 09:27:07 -0500 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpa id 1336660015-1570-1568/5/35; Thu, 10 May 2012 14:26:55 +0000 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org References: Date: Thu, 10 May 2012 09:26:54 -0500 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: User-Agent: Opera Mail/11.62 (FreeBSD) X-SA-Score: -1.5 Cc: Subject: Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 14:27:08 -0000 Quick update: I have received word last night that this crash has been consistently happening to someone on FreeBSD 9 and they're looking for more ideas. I changed the following 41 days ago: - Video memory to "auto" if it wasn't already - SCSI controller changed from LSI Logic Parallel to LSI Logic SAS It uses the same driver (da) but so far has been holding steady for us. As far as the video memory -- many of our servers somehow had video memory set to 1MB which seemed strange; newer builds of FreeBSD on ESXi do not show this option. Perhaps there was a build of ESXi in the past that had a different setting for video memory when you selected FreeBSD? Another change people might want to do as suggested to us by VMWare Support: - Change CPU/MMU Virtualization to the bottom option -- "Use Intel VTx/AMD-V for instruction set virtualization and Intel EPT / AMD RVI for MMU virtualization" Supposedly there are autodetection issues here with some OSes -- they named some BSDs and Netware. I'll provide further updates if anything changes, but this seems to be working well so far. We won't begin to trust it until we can hit at least 100 days of uptime, though. Unfortunately I was hoping to upgrade these servers to 8.3 before then... From owner-freebsd-hackers@FreeBSD.ORG Thu May 10 14:27:45 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0EE61065677; Thu, 10 May 2012 14:27:45 +0000 (UTC) (envelope-from nyan@FreeBSD.org) Received: from sakura.ccs.furiru.org (sakura.ccs.furiru.org [IPv6:2001:2f0:104:8060::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7B6C78FC1C; Thu, 10 May 2012 14:27:45 +0000 (UTC) Received: from localhost (authenticated bits=0) by sakura.ccs.furiru.org (unknown) with ESMTP id q4AERfFN054247; Thu, 10 May 2012 23:27:43 +0900 (JST) (envelope-from nyan@FreeBSD.org) Date: Thu, 10 May 2012 23:27:41 +0900 (JST) Message-Id: <20120510.232741.343708041392026540.nyan@FreeBSD.org> To: avg@freebsd.org From: TAKAHASHI Yoshihiro In-Reply-To: <4FAB8D31.8050301@FreeBSD.org> References: <4FAA3994.2070701@FreeBSD.org> <4FAA54C1.20203@FreeBSD.org> <4FAB8D31.8050301@FreeBSD.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: bootargs.h X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 14:27:46 -0000 In article <4FAB8D31.8050301@FreeBSD.org> Andriy Gapon writes: >>> MFi386 of BTX changes for support of KARGS_FLAGS_EXTARG is pending. >>> Do you think that it should be done? >> >> You mean to pc98's btxldr? I think so, in general we should keep the >> pc98 BTX bits as close to i386 as possible. > > Yes. Here is a complete pc98 patch for bootargs.h and btxldr: > http://people.freebsd.org/~avg/pc98-btxldr.diff Sorry I don't have any time to test your patch now, but it seems fine to me. Please feel free to commit. Thanks. --- TAKAHASHI Yoshihiro From owner-freebsd-hackers@FreeBSD.ORG Thu May 10 15:17:56 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 361C0106564A; Thu, 10 May 2012 15:17:56 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 03AE68FC15; Thu, 10 May 2012 15:17:56 +0000 (UTC) Received: from John-Baldwins-MacBook-Air.local (unknown [192.75.139.252]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5CB85B968; Thu, 10 May 2012 11:17:55 -0400 (EDT) Message-ID: <4FABDC23.2090400@FreeBSD.org> Date: Thu, 10 May 2012 11:17:55 -0400 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Andriy Gapon References: <4F8999D2.1080902@FreeBSD.org> <201205070953.04032.jhb@freebsd.org> <4FA7E069.8020208@FreeBSD.org> <201205071343.45955.jhb@freebsd.org> <4FA8C7E3.8070006@FreeBSD.org> <4FA92A88.2030000@FreeBSD.org> <4FA96747.3060106@FreeBSD.org> <4FAA3994.2070701@FreeBSD.org> <4FAA54C1.20203@FreeBSD.org> <4FAB8D31.8050301@FreeBSD.org> In-Reply-To: <4FAB8D31.8050301@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 10 May 2012 11:17:55 -0400 (EDT) Cc: freebsd-hackers@FreeBSD.org, Takahashi Yoshihiro Subject: Re: bootargs.h X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 15:17:56 -0000 On 5/10/12 5:41 AM, Andriy Gapon wrote: > on 09/05/2012 14:28 John Baldwin said the following: >> On 5/9/12 5:32 AM, Andriy Gapon wrote: >>> >>> Here is a subversion diff to make use of the new bootargs.h header in pc98 >>> cdboot and loader, and i386 cdboot and pxeldr: >>> http://people.freebsd.org/~avg/bootargs.diff >>> Could you please review it? >>> Thank you! >> >> Looks good. >> >>> MFi386 of BTX changes for support of KARGS_FLAGS_EXTARG is pending. >>> Do you think that it should be done? >> >> You mean to pc98's btxldr? I think so, in general we should keep the >> pc98 BTX bits as close to i386 as possible. >> > > Yes. Here is a complete pc98 patch for bootargs.h and btxldr: > http://people.freebsd.org/~avg/pc98-btxldr.diff Looks ok to me. We should really see about letting PC98 share more code here rather than using copies if it's not too ugly. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu May 10 18:02:28 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B880106566C for ; Thu, 10 May 2012 18:02:28 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.gmx.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id CE2D08FC14 for ; Thu, 10 May 2012 18:02:27 +0000 (UTC) Received: (qmail 32284 invoked by uid 0); 10 May 2012 18:02:24 -0000 Received: from 67.206.185.81 by rms-us012.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Thu, 10 May 2012 14:02:22 -0400 From: "Dieter BSD" Message-ID: <20120510180223.153800@gmx.com> MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: +Gfeb3Bd3zOlNR3dAHAhYBZ+IGRvbwAV Subject: Re: csh builtin command problems X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 18:02:28 -0000 Robert writes: > I want this: > > # echo test\ttest > test > # cat test > test    test I have given up on using echo for anything the least bit fancy, in favor of printf(1) which gives much better control. printf "test\ttest\n" From owner-freebsd-hackers@FreeBSD.ORG Thu May 10 23:27:57 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12595106566C for ; Thu, 10 May 2012 23:27:57 +0000 (UTC) (envelope-from rsimmons0@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id B8CB48FC12 for ; Thu, 10 May 2012 23:27:56 +0000 (UTC) Received: by vbmv11 with SMTP id v11so2905966vbm.13 for ; Thu, 10 May 2012 16:27:56 -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 :content-type:content-transfer-encoding; bh=g2RGyx/9b1vkaSNJsoIQScioVgqKDnK14blp3jhso/k=; b=FSBkiwAOgQZWZfYSPQ0OiqYOLPNL1c7WnIQdM7XtzgJtS589mqrPplwoa9QVyjqwAn VbAvkECq05SPdJjLEDqWN7s0/sVzI8jRIHogpIt+LHbwgr5S/UINhvcBVy9jprf6q5uu muNjdi7Mixl6vLRejUNp72tlv/Pm0xLzI8sIO9YHLGT6t6osR2XW+sjpTuSH8cCBgssO QHdle5p6H6o8wDvOnje0vzFnaE+BQ77xmgzG4jsSzDayAdfMRwOetXaoEzORTLB9LUlg iM3ReQDyCL6rtKZnIyvYKTCyaIoa/5H8W3LgBROpGVDooBEB3GucXewz1zNFMKpMSTCo LYoQ== MIME-Version: 1.0 Received: by 10.52.65.234 with SMTP id a10mr3007148vdt.124.1336692475727; Thu, 10 May 2012 16:27:55 -0700 (PDT) Received: by 10.52.112.167 with HTTP; Thu, 10 May 2012 16:27:55 -0700 (PDT) In-Reply-To: <20120510180223.153800@gmx.com> References: <20120510180223.153800@gmx.com> Date: Thu, 10 May 2012 19:27:55 -0400 Message-ID: From: Robert Simmons To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: csh builtin command problems X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 23:27:57 -0000 On Thu, May 10, 2012 at 2:02 PM, Dieter BSD wrote: > Robert writes: >> I want this: >> >> # echo test\ttest > test >> # cat test >> test =A0 =A0test > > I have given up on using echo for anything the least bit fancy, > in favor of printf(1) which gives much better control. > > printf "test\ttest\n" I understand, but can anyone verify that what I was doing is correct as far as the man page, and that it is not working on your 9.0 box as well? From owner-freebsd-hackers@FreeBSD.ORG Fri May 11 02:41:58 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEAA21065670 for ; Fri, 11 May 2012 02:41:57 +0000 (UTC) (envelope-from rsimmons0@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 93E4E8FC08 for ; Fri, 11 May 2012 02:41:57 +0000 (UTC) Received: by vbmv11 with SMTP id v11so3079988vbm.13 for ; Thu, 10 May 2012 19:41:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=T291DhfyO3oGn2oEYaXn2VqH/P1LwopFa9GU+YRFBTU=; b=TMBuuJV2QqkXRbph8ueASCz20xPPnJs0ViB1u3OKXmshc8aT6N8XrADHYuEFtd+5y4 0LTSACnTgkpmkPtdxTjURKtMdyVz7isq4e4fYIOT2lHLhLm3cEQNZdj/5W4Y1sHE06lF CtljeeHazy2kxa4bRWx+gMpNqNwN19O+JqXKen608VH/wVETvSlHTEUNFUG7QWusHZJA hqDXyyfoMA16+nVueVd2k8MfQlboJfwraJ1Y2/DLHXTYmC7T/DEUxayW/YUvnQZt9RzB 6jMT+Z9NgLikKzl4ywB4WJD6PiLnJaLGWVgZnn2dyuGAX63/xQm9p1sXn4sovA3T8okK lBeQ== MIME-Version: 1.0 Received: by 10.52.34.200 with SMTP id b8mr3189973vdj.115.1336704116877; Thu, 10 May 2012 19:41:56 -0700 (PDT) Received: by 10.52.112.167 with HTTP; Thu, 10 May 2012 19:41:56 -0700 (PDT) Date: Thu, 10 May 2012 22:41:56 -0400 Message-ID: From: Robert Simmons To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Heimdal 1.5.2 problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 02:41:58 -0000 I've just installed the new version of Heimdal, 1.5.2 from ports, and I'm having a problem. As in the past, BerkeleyDB needs to be enabled with make config so that there is a backend. However, I'm still getting the error as if BerkeleyDB was not enabled, and there is no backend support. I've followed this process to get to this point: # cd /usr/ports/security/heimdal # make config *at this point, I've just made sure that BDB and cracklib support are compiled. # make install # mkdir /var/db/heimdal # chmod 600 /var/db/heimdal Then the following is added to /etc/rc.conf kerberos5_server_enable="YES" kerberos5_server="/use/local/libexec/kdc" kadmind5_server_enable="YES" kadmind5_server="/usr/local/libexec/kadmind" kpasswdd_server_enable="YES" kpasswdd_server="/usr/local/libexec/kpasswdd" This is my /etc/krb5.conf [libdefaults] default_realm = HOME default_etypes = aes256-cts-hmac-sha1-96 [realms] EXAMPLE.ORG = { kdc = kerberos.home admin_server = kerberos.home kpasswd_server = kerberos.home } [password_quality] policies = builtin:minimum-length builtin:character-class min_length = 20 min_classes = 4 [kdc] enable-kerberos4 = false enable-524 = false require-preauth = true allow-anonymous = false [kadmin] require-preauth = true default_keys = aes256-cts-hmac-sha1-96:pw-salt [domain_realm] .home = HOME I then created a key # kstash --enctype=aes256-cts-hmac-sha1-96 --random-key Then tried to initialize the realm: # /usr/local/sbin/kadmin -l kadmin> init HOME kadmin: hdb_open: hdb_open: failed initialize database /var/db/heimdal/heimdal kadmin> This is the error I get. Also, after performing this failed init, the database is actually created in /var/db/heimdal # ll /var/db/heimdal total 24 -rw------- 1 root wheel 16384 May 10 19:56 heimdal.db -rw------- 1 root wheel 0 May 10 19:18 heimdal.lock -rw------- 1 root wheel 264 May 10 19:17 kdc.log -rw------- 1 root wheel 73 May 10 19:18 m-key According to PR 154711, I've done everything correct, but I'm still getting the error. http://www.freebsd.org/cgi/query-pr.cgi?pr=154711 All of the regular dependencies are satisfied: autoconf-2.68, autoconf-wrapper-20101119, gettext-0.18.1.1, libiconv-1.14, libtool-2.4.2, m4-1.4.16,1, perl-5.12.4_4, pkg-config-0.25_1 And, this is the version of BerkeleyDB that it compiles and installs to satisfy the BDB backend that I enabled during config: db41-4.1.25_4 Has anyone else successfully installed Heimdal 1.5.2 from ports on FreeBSD 9.0? What did you do differently than me? From owner-freebsd-hackers@FreeBSD.ORG Fri May 11 09:54:20 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49AE5106566C; Fri, 11 May 2012 09:54:20 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2EEE28FC12; Fri, 11 May 2012 09:54:18 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA15403; Fri, 11 May 2012 12:54:17 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SSmYD-0004H2-B8; Fri, 11 May 2012 12:54:17 +0300 Message-ID: <4FACE1C8.4080802@FreeBSD.org> Date: Fri, 11 May 2012 12:54:16 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: John Baldwin References: <4F8999D2.1080902@FreeBSD.org> <201205070953.04032.jhb@freebsd.org> <4FA7E069.8020208@FreeBSD.org> <201205071343.45955.jhb@freebsd.org> <4FA8C7E3.8070006@FreeBSD.org> <4FA92A88.2030000@FreeBSD.org> <4FA96747.3060106@FreeBSD.org> <4FAA3994.2070701@FreeBSD.org> <4FAA54C1.20203@FreeBSD.org> <4FAB8D31.8050301@FreeBSD.org> <4FABDC23.2090400@FreeBSD.org> In-Reply-To: <4FABDC23.2090400@FreeBSD.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Takahashi Yoshihiro Subject: Re: bootargs.h X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 09:54:20 -0000 on 10/05/2012 18:17 John Baldwin said the following: > On 5/10/12 5:41 AM, Andriy Gapon wrote: >> on 09/05/2012 14:28 John Baldwin said the following: >>> On 5/9/12 5:32 AM, Andriy Gapon wrote: >>>> >>>> Here is a subversion diff to make use of the new bootargs.h header in pc98 >>>> cdboot and loader, and i386 cdboot and pxeldr: >>>> http://people.freebsd.org/~avg/bootargs.diff >>>> Could you please review it? >>>> Thank you! >>> >>> Looks good. >>> >>>> MFi386 of BTX changes for support of KARGS_FLAGS_EXTARG is pending. >>>> Do you think that it should be done? >>> >>> You mean to pc98's btxldr? I think so, in general we should keep the >>> pc98 BTX bits as close to i386 as possible. >>> >> >> Yes. Here is a complete pc98 patch for bootargs.h and btxldr: >> http://people.freebsd.org/~avg/pc98-btxldr.diff > > Looks ok to me. We should really see about letting PC98 share more code > here rather than using copies if it's not too ugly. > btxcsu.S is the only one that is almost identical between i386 and pc98. I think that it was completely identical and I accidentally broke that. Should fix. btxldr.S and btx.S would require a fair number of ifdefs to be shareable. cdboot.S seems to have too many differences. I am not sure whether and what it would make sense to share. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri May 11 20:49:43 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9B7241065670 for ; Fri, 11 May 2012 20:49:43 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 251698FC17 for ; Fri, 11 May 2012 20:49:42 +0000 (UTC) Received: by werg1 with SMTP id g1so1752728wer.13 for ; Fri, 11 May 2012 13:49:42 -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 :content-type:content-transfer-encoding; bh=X8HN0q4ecg/wYTBTbEmIw7/MXmJUV1xpXVuiWHUGUC8=; b=PyLY7C/JSE6j2gOgoBPH96VCZInmprMo0nmrSOEj0/7xrX4TP466UQaUaDl80X+YwS ApRFPBHCh7q78lX55eIzcTT0ypwbEoeiaf2Fh+PuXcd3OGqB9Fb978RaUvA3XEv4rNLD 0BfdOoqhP5eDNbZHssY6dqJ1InlQFrG0ZxvSvwyom6zGEvl1VXPTRHF3hwjvXrM+3zto r2qhtiresQoT/5PR7ueOVIub7KCwq4KfqSkinmHSfE/v7/eD2JlHEtERyVMtvzi1VIpY tHWngXI2Ipa4gf5HQiOcJxkceQMA3zsnlMFzV0xJBRasOGLrr7Ts8N4oLV/keG3ilMQq Y7pA== MIME-Version: 1.0 Received: by 10.180.86.5 with SMTP id l5mr2423366wiz.6.1336769382254; Fri, 11 May 2012 13:49:42 -0700 (PDT) Received: by 10.216.163.136 with HTTP; Fri, 11 May 2012 13:49:42 -0700 (PDT) In-Reply-To: <20111211130819.GH83814@acme.spoerlein.net> References: <4E712D11.7040202@FreeBSD.org> <4E75B67E.1000802@FreeBSD.org> <20110922190535.GR26743@acme.spoerlein.net> <20110922212602.GS26743@acme.spoerlein.net> <20111007102841.GG26743@acme.spoerlein.net> <20111211130819.GH83814@acme.spoerlein.net> Date: Fri, 11 May 2012 16:49:42 -0400 Message-ID: From: Arnaud Lacombe To: Arnaud Lacombe , hackers@freebsd.org, =?ISO-8859-1?Q?Ulrich_Sp=F6rlein?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Fwd: my git development snapshot(s) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 20:49:43 -0000 Hi, On Sun, Dec 11, 2011 at 8:08 AM, Ulrich Sp=F6rlein wrot= e: > On Sun, 2011-12-04 at 18:42:38 -0500, Arnaud Lacombe wrote: >> On Fri, Oct 7, 2011 at 6:28 AM, Ulrich Sp=F6rlein wr= ote: >> > On Fri, 2011-09-30 at 15:41:41 -0400, Arnaud Lacombe wrote: >> >> On Mon, Sep 26, 2011 at 2:23 PM, Arnaud Lacombe = wrote: >> >> > FWIW, how comes that there is not yet any `stable/9' branch on the = github tree ? >> >> > >> >> Ulrich, ping ? >> > >> > Oops, sorry for the delay! Fixed now, thanks for bringing it to my >> > attention. I missed the push --all flag. :/ >> > >> FWIW, the github mirror[0] of the completed SVN tree has not seen any >> upgrade for a week now. Did some script broke ? >> >> Thanks, >> =A0- Arnaud >> >> [0]: https://github.com/freebsd/freebsd > > Yeah, sorry about that. Monitoring is not that great, so you should > always ping me directly. > > The problem is that people dump files at random places in the Subversion > tree and that cannot easily be translated to branches. This time it was > /vendor/flex/FreeBSD-Xlist > It would seem the full SVN mirror on github is out-of-sync again, at least, the `user/imp/extern_cc' is missing. Thanks, - Arnaud From owner-freebsd-hackers@FreeBSD.ORG Fri May 11 22:32:16 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 10AEF106564A; Fri, 11 May 2012 22:32:16 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 160C48FC0A; Fri, 11 May 2012 22:32:14 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA24015; Sat, 12 May 2012 01:32:12 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SSyNf-00056b-Lu; Sat, 12 May 2012 01:32:11 +0300 Message-ID: <4FAD9368.5010008@FreeBSD.org> Date: Sat, 12 May 2012 01:32:08 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org, freebsd-fs@FreeBSD.org References: <4F8999D2.1080902@FreeBSD.org> <4F8E820B.6080400@FreeBSD.org> In-Reply-To: <4F8E820B.6080400@FreeBSD.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit Cc: Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 22:32:16 -0000 After all the preparatory changes are committed, this is a final[*] notice/warning that I am going to start committing the following patchset really soon now[**[: http://people.freebsd.org/~avg/zfsboot.patches.9.diff [*] unless circumstances change [**] maybe next hour, even -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Sat May 12 07:34:48 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 223211065673 for ; Sat, 12 May 2012 07:34:48 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id A13988FC19 for ; Sat, 12 May 2012 07:34:47 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.5/8.14.5) with ESMTP id q4C7Yk5q032157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 12 May 2012 09:34:46 +0200 (CEST) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1336808086; bh=VgxT8B/MFs9uj9RM/qR1YzXLLTR4EcbMiOJHZ9tLZOw=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=J15jnZ+Yb6D9QtYocMSc7S4dIjllFg9PJMee+Qq8cbjhmyJtW02CZHELqbiteZCQt +3jJTZy+vKIS5ENc42DFFtxqAW8EfXjc2lWn8bu/u7NikDnpfRZy6dnQnCSD0gdOv1 Kxx3iUixpcQBJbxkvfuZxbUG6BP2tOTaBqntnhEM= Date: Sat, 12 May 2012 09:34:46 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Arnaud Lacombe Message-ID: <20120512073446.GM71676@acme.spoerlein.net> Mail-Followup-To: Arnaud Lacombe , hackers@freebsd.org References: <4E75B67E.1000802@FreeBSD.org> <20110922190535.GR26743@acme.spoerlein.net> <20110922212602.GS26743@acme.spoerlein.net> <20111007102841.GG26743@acme.spoerlein.net> <20111211130819.GH83814@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hackers@freebsd.org Subject: Re: Fwd: my git development snapshot(s) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 07:34:48 -0000 On Fri, 2012-05-11 at 16:49:42 -0400, Arnaud Lacombe wrote: > Hi, > > On Sun, Dec 11, 2011 at 8:08 AM, Ulrich Spörlein wrote: > > On Sun, 2011-12-04 at 18:42:38 -0500, Arnaud Lacombe wrote: > >> On Fri, Oct 7, 2011 at 6:28 AM, Ulrich Spörlein wrote: > >> > On Fri, 2011-09-30 at 15:41:41 -0400, Arnaud Lacombe wrote: > >> >> On Mon, Sep 26, 2011 at 2:23 PM, Arnaud Lacombe wrote: > >> >> > FWIW, how comes that there is not yet any `stable/9' branch on the github tree ? > >> >> > > >> >> Ulrich, ping ? > >> > > >> > Oops, sorry for the delay! Fixed now, thanks for bringing it to my > >> > attention. I missed the push --all flag. :/ > >> > > >> FWIW, the github mirror[0] of the completed SVN tree has not seen any > >> upgrade for a week now. Did some script broke ? > >> > >> Thanks, > >>  - Arnaud > >> > >> [0]: https://github.com/freebsd/freebsd > > > > Yeah, sorry about that. Monitoring is not that great, so you should > > always ping me directly. > > > > The problem is that people dump files at random places in the Subversion > > tree and that cannot easily be translated to branches. This time it was > > /vendor/flex/FreeBSD-Xlist > > > It would seem the full SVN mirror on github is out-of-sync again, at > least, the `user/imp/extern_cc' is missing. user/ isn't pushed to github (and I consider also not pushing projects/ into it), as their webfrontend often craps out with too many branches. You can get it from git.freebsd.org directly. Uli From owner-freebsd-hackers@FreeBSD.ORG Sat May 12 13:01:51 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E324106566C for ; Sat, 12 May 2012 13:01:51 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id C52238FC0A for ; Sat, 12 May 2012 13:01:50 +0000 (UTC) Received: by yenl8 with SMTP id l8so4363373yen.13 for ; Sat, 12 May 2012 06:01:50 -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 :content-type:content-transfer-encoding; bh=MmXicQ2/8txWGPGllbCVt3l1fHYSFk3CJ5Tx2p3cYTQ=; b=XyKrtXpFJimK78gIil1axbsncvLfz2IXzFGhUKwf/g/wGgixYJPHetbXqaglRSEWCa Ja2HnNNcFcHdc6/+dfVcqOa/DdTwwlX8ZPMuqhv8fl2Fv1gPh1EbrpsLZTBr4wg9D/5J 5Pcow37RCgdRiRqXF0r2VcZg3QVqMf/zcsDDK2yTlAPSVYiE5yVd6KrevwWTy8lmVFN+ 8sVbtMuWd66IeszhjdiNwcDjsmqY6yPjhgh5P1nmQTyeBuO+1rLYHGjkmZMrwfwxBem6 VD+D7uEtuFYdrnDlwuISfv1rqccBayKyqjgbEtHzr9UrUZd1FOfGJGbsBDr1e7DzH67R W9bw== MIME-Version: 1.0 Received: by 10.236.190.196 with SMTP id e44mr1612198yhn.67.1336827710079; Sat, 12 May 2012 06:01:50 -0700 (PDT) Received: by 10.236.108.12 with HTTP; Sat, 12 May 2012 06:01:49 -0700 (PDT) In-Reply-To: <20120512073446.GM71676@acme.spoerlein.net> References: <4E75B67E.1000802@FreeBSD.org> <20110922190535.GR26743@acme.spoerlein.net> <20110922212602.GS26743@acme.spoerlein.net> <20111007102841.GG26743@acme.spoerlein.net> <20111211130819.GH83814@acme.spoerlein.net> <20120512073446.GM71676@acme.spoerlein.net> Date: Sat, 12 May 2012 15:01:49 +0200 Message-ID: From: Oliver Pinter To: Arnaud Lacombe , hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Fwd: my git development snapshot(s) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 13:01:51 -0000 On 5/12/12, Ulrich Sp=F6rlein wrote: > On Fri, 2012-05-11 at 16:49:42 -0400, Arnaud Lacombe wrote: >> Hi, >> >> On Sun, Dec 11, 2011 at 8:08 AM, Ulrich Sp=F6rlein >> wrote: >> > On Sun, 2011-12-04 at 18:42:38 -0500, Arnaud Lacombe wrote: >> >> On Fri, Oct 7, 2011 at 6:28 AM, Ulrich Sp=F6rlein >> >> wrote: >> >> > On Fri, 2011-09-30 at 15:41:41 -0400, Arnaud Lacombe wrote: >> >> >> On Mon, Sep 26, 2011 at 2:23 PM, Arnaud Lacombe >> >> >> wrote: >> >> >> > FWIW, how comes that there is not yet any `stable/9' branch on t= he >> >> >> > github tree ? >> >> >> > >> >> >> Ulrich, ping ? >> >> > >> >> > Oops, sorry for the delay! Fixed now, thanks for bringing it to my >> >> > attention. I missed the push --all flag. :/ >> >> > >> >> FWIW, the github mirror[0] of the completed SVN tree has not seen any >> >> upgrade for a week now. Did some script broke ? >> >> >> >> Thanks, >> >> - Arnaud >> >> >> >> [0]: https://github.com/freebsd/freebsd >> > >> > Yeah, sorry about that. Monitoring is not that great, so you should >> > always ping me directly. >> > >> > The problem is that people dump files at random places in the >> > Subversion >> > tree and that cannot easily be translated to branches. This time it wa= s >> > /vendor/flex/FreeBSD-Xlist >> > >> It would seem the full SVN mirror on github is out-of-sync again, at >> least, the `user/imp/extern_cc' is missing. > > user/ isn't pushed to github (and I consider also not pushing projects/ > into it), as their webfrontend often craps out with too many branches. > > You can get it from git.freebsd.org directly. git.freebsd.org ? > > Uli > _______________________________________________ > 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 Sat May 12 14:27:28 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1423D1065672 for ; Sat, 12 May 2012 14:27:28 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 93C2A8FC0A for ; Sat, 12 May 2012 14:27:27 +0000 (UTC) Received: by wibhn6 with SMTP id hn6so947829wib.13 for ; Sat, 12 May 2012 07:27:26 -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 :content-type:content-transfer-encoding; bh=MrsIOittMUW41AvCtw+ReGqUHQQ/wlCti1OcfOoftoc=; b=MjYf3C1/4UtYhf4owYm6XX4mj6Cth4EXHy/nIFxtFrBZTgyKLW9hps1EWBeLkptEJD 1aJYRNLX5ej92SMKb6O29NIBAdQ3gF8KMBn8WemETNEX5owCLjHFi0fKdnJ0DKX4sNTc k/Gj+pvbI/rSU6H45PgWOsV0LkZ7Hv7bknV0lzwmbaeNniCDLY3xIeYa5j49Q6/Z/DCj gE6dsqSf/aNzlBQQv9/keDVFklgQrwXhkpG2sQXoLilbtrcoen6T1iX3U/M/TCshB0+F SfB7oEVMIwpwzr/DXcNJd/ajZKwJq6+bkatriAs12TqUyDVoJfodKTzyf7Djjbu2yDIg 3zYw== MIME-Version: 1.0 Received: by 10.216.139.12 with SMTP id b12mr1269146wej.4.1336832846422; Sat, 12 May 2012 07:27:26 -0700 (PDT) Received: by 10.216.163.136 with HTTP; Sat, 12 May 2012 07:27:26 -0700 (PDT) In-Reply-To: <20120512073446.GM71676@acme.spoerlein.net> References: <4E75B67E.1000802@FreeBSD.org> <20110922190535.GR26743@acme.spoerlein.net> <20110922212602.GS26743@acme.spoerlein.net> <20111007102841.GG26743@acme.spoerlein.net> <20111211130819.GH83814@acme.spoerlein.net> <20120512073446.GM71676@acme.spoerlein.net> Date: Sat, 12 May 2012 10:27:26 -0400 Message-ID: From: Arnaud Lacombe To: Arnaud Lacombe , hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Fwd: my git development snapshot(s) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 14:27:28 -0000 Hi, On Sat, May 12, 2012 at 3:34 AM, Ulrich Sp=F6rlein wrot= e: > On Fri, 2012-05-11 at 16:49:42 -0400, Arnaud Lacombe wrote: >> Hi, >> >> On Sun, Dec 11, 2011 at 8:08 AM, Ulrich Sp=F6rlein w= rote: >> > On Sun, 2011-12-04 at 18:42:38 -0500, Arnaud Lacombe wrote: >> >> On Fri, Oct 7, 2011 at 6:28 AM, Ulrich Sp=F6rlein = wrote: >> >> > On Fri, 2011-09-30 at 15:41:41 -0400, Arnaud Lacombe wrote: >> >> >> On Mon, Sep 26, 2011 at 2:23 PM, Arnaud Lacombe wrote: >> >> >> > FWIW, how comes that there is not yet any `stable/9' branch on t= he github tree ? >> >> >> > >> >> >> Ulrich, ping ? >> >> > >> >> > Oops, sorry for the delay! Fixed now, thanks for bringing it to my >> >> > attention. I missed the push --all flag. :/ >> >> > >> >> FWIW, the github mirror[0] of the completed SVN tree has not seen any >> >> upgrade for a week now. Did some script broke ? >> >> >> >> Thanks, >> >> =A0- Arnaud >> >> >> >> [0]: https://github.com/freebsd/freebsd >> > >> > Yeah, sorry about that. Monitoring is not that great, so you should >> > always ping me directly. >> > >> > The problem is that people dump files at random places in the Subversi= on >> > tree and that cannot easily be translated to branches. This time it wa= s >> > /vendor/flex/FreeBSD-Xlist >> > >> It would seem the full SVN mirror on github is out-of-sync again, at >> least, the `user/imp/extern_cc' is missing. > > user/ isn't pushed to github (and I consider also not pushing projects/ > into it), as their webfrontend often craps out with too many branches. > > You can get it from git.freebsd.org directly. > ok, there seem to be a valid repository at `git://git.freebsd.org/freebsd'. It might take some time to clone it from BSDCan, so I'll wait to be back to base to clone. It sounds I'll need to re-export/re-import all my branches.. again Thanks for the pointer. - Arnaud From owner-freebsd-hackers@FreeBSD.ORG Sat May 12 21:38:30 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 57FB21065670; Sat, 12 May 2012 21:38:30 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3F60E8FC17; Sat, 12 May 2012 21:38:30 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q4CLcUH7006019; Sat, 12 May 2012 21:38:30 GMT (envelope-from danger@freefall.freebsd.org) Received: (from danger@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q4CLcUqs006017; Sat, 12 May 2012 21:38:30 GMT (envelope-from danger) Date: Sat, 12 May 2012 21:38:30 +0000 From: Daniel Gerzo To: hackers@freebsd.org Message-ID: <20120512213829.GA5893@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org, current@freebsd.org Subject: FreeBSD Quarterly Status Report January-March, 2012 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: monthly@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 21:38:30 -0000 FreeBSD Quarterly Status Report January-March, 2012 Introduction This report covers FreeBSD-related projects between January and March 2012. It is the first of the four reports planned for 2012. This quarter was highlighted by releasing the next major version of FreeBSD, 9.0, which was finally released in the beginning of January 2012. The FreeBSD Project dedicates the FreeBSD 9.0-RELEASE to the memory of Dennis M. Ritchie, one of the founding fathers of the UNIXŽ operating system. Our release engineering team has been also busy with preparation of the 8.3-RELEASE, which was publicly announced in April. Thanks to all the reporters for the excellent work! This report contains 27 entries and we hope you enjoy reading it. Please note that the deadline for submissions covering the period between April and June 2012 is July 15th, 2012. __________________________________________________________________ Projects * FreeBSD Services Control * GNU-Free C++11 Stack * Growing filesystems online * The FreeNAS Project User-land Programs * Clang Replacing GCC in the Base System * Replacing the Regular Expression Code * The bsdconfig(8) utility FreeBSD Team Reports * Release Engineering Team Status Report * The FreeBSD Foundation Team Report Kernel * DTrace Probes for the linuxulator * HDMI/DisplayPort Audio Support in HDA Sound Driver (snd_hda) * Improved hwpmc(9) Support for MIPS * isci(4) SAS Driver Network Infrastructure * Atheros 802.11n Support * IPv6 Performance Analysis * Multi-FIB: IPv6 Support and Other Enhancements Documentation * The FreeBSD Japanese Documentation Project Architectures * FreeBSD/arm on Various TI Boards * FreeBSD/powerpc on Freescale QorIQ DPAA * NAND File System, NAND Flash Framework, NAND Simulator * Porting DTrace to MIPS and ARM Ports * A New linux_base Port Based Upon CentOS * BSD-licensed sort Utility (GNU sort Replacement) * KDE/FreeBSD * Perl Ports Testing * The FreeBSD Haskell Ports * The FreeBSD Ports Collection __________________________________________________________________ A New linux_base Port Based Upon CentOS Contact: Alexander Leidinger We got a PR with a linux_based port which is based upon CentOS 6. Currently this can only be used as a test environment, as it depends upon a more recent linux kernel version, than the linuxulator provides. As of this writing, I'm in the process of preparing a commit of this port. Open tasks: 1. Repocopy by portmgr. 2. Add conflicts in other linux_base ports. 3. Commit the CentOS based one. 4. Some cleanup. __________________________________________________________________ Atheros 802.11n Support URL: http://wiki.FreeBSD.org/AdrianChadd/AtherosTxAgg URL: http://wiki.FreeBSD.org/dev/ath(4) Contact: Adrian Chadd 802.11n station and hostap support is now fully functional, sans correct hostap side power saving. TX aggregation and TX BAR handling is implemented. Station chip power saving is not implemented at all yet, it's not in the scope of this work. Testers should disable bgscan (-bgscan) as scan/bgscan will simply drop any traffic in the TX/RX queues, causing potential traffic stalls. Open tasks: 1. Fix up hostap side power save handling. 2. Implement filtered frames support in the driver. 3. Fix scan/bgscan to correctly buffer and retransmit frames when going off channel, so frames are not just "dropped" - this causes issues in the aggregation sessions and may cause traffic stalls. 4. Test/fix any issues with adhoc 802.11n support. __________________________________________________________________ BSD-licensed sort Utility (GNU sort Replacement) URL: http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/textproc/bsdsort/ URL: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sort.html Contact: Oleg Moskalenko Contact: Gábor Kövesdán Currently the BSD sort reached usable stable stage. It is stable, it is as fast as the GNU sort, and it supports multi-byte locales (this is something that GNU sort does not do correctly). BSD sort has all features of GNU sort 5.3.0 (version included into FreeBSD) with some extra features and bug fixes. Open tasks: 1. Add BSD sort into HEAD as an alternative, installed as bsdsort. If proven to work as expected, change it to the default sort version and remove GNU sort. 2. Investigate the possibility of a multi-threaded sort implementation and implement it, if it proves more efficient. 3. Upgrade BSD sort features to include some obscure new features in the latest GNU sort version 8.15. __________________________________________________________________ Clang Replacing GCC in the Base System URL: http://wiki.FreeBSD.org/BuildingFreeBSDWithClang Contact: Brooks Davis Contact: David Chisnall Contact: Dimitry Andric Contact: Ed Schouten Contact: Pawel Worach Contact: Roman Divacky Both FreeBSD 10.0-CURRENT and 9.0-STABLE now have Clang 3.0 release installed by default. At least on 10.0-CURRENT, both world and the GENERIC kernel can be completely built without any -Werror warnings. This may not be the case for all custom kernel configurations yet. As of r231057, there is a WITH_CLANG_EXTRAS option for src.conf(5), which will enable a number of additional LLVM and Clang tools, such as 'llc' and 'opt'. These tools are mainly useful for people that want to manipulate LLVM bitcode (.bc) and LLVM assembly language (.ll) files, or want to tinker with LLVM and Clang themselves. Also, as of r232322, there is a WITH_CLANG_IS_CC option for src.conf(5), which will install Clang as /usr/bin/cc, /usr/bin/c++ and /usr/bin/cpp, making it the default system compiler. Unless you also use the WITHOUT_GCC option, gcc will still be available as /usr/bin/gcc, /usr/bin/g++ and /usr/bin/gcpp. The intent is to switch on this option by default rather sooner than later, so we can start preparing for shipping 10.0-RELEASE with Clang as as the default system compiler, and deprecating gcc. In other news, we will import a newer snapshot of Clang soon, since upstream LLVM/Clang has already announced their 3.1 release will be branched April 16, 2012. Most likely, the actual 3.1 release will be follow a few weeks later, after which we will do another import. Last but not least, there are many ports people working on making our ports compile properly with Clang. Fixes are checked in on a very regular basis now, and full exp-runs with Clang are also done fairly regularly. Of course, there are always a few difficult cases, especially with very old software that will not even compile with newer versions of gcc, let alone clang. Open tasks: 1. One of the most important tasks at the moment is to actually build and run your entire FreeBSD system with Clang, as much as possible. Any compile-time or run-time problems should be reported to the appropriate mailing list, or filed as a PR. If you have patches and/or workarounds, that would be even better. 2. Clang should have gotten better support for cross-compiling after 3.0, so as soon as a 3.1 version is imported, we will need to look at ways to get the FreeBSD world and kernels to cross-compile. This is mainly of use for ARM and MIPS, which are architectures you usually do not want to build natively on. 3. Help to make unwilling ports build with Clang is always needed, and greatly appreciated. Please mail the maintainer of your favorite port with patches, or file PRs. __________________________________________________________________ DTrace Probes for the linuxulator Contact: Alexander Leidinger Recently DTrace in the kernel was improved to be able to load kernel modules with static dtrace providers after the dtrace modules. This allows me to commit my linuxulator specific static provider work to -CURRENT. Together with the linuxulator DTrace probes I developed some D scripts to check various code paths in the linuxulator. Those scripts check various error cases which may be interesting to verify userland code, but also linuxulator internals like locks. As of this writing I'm in the process of updating a test machine to a more recent -current to prepare the commit. __________________________________________________________________ FreeBSD Services Control URL: http://people.FreeBSD.org/~trhodes/fsc/ Contact: Tom Rhodes After a while of moving and getting a new job, I finally got back to this project (also thanks to several submissions by Julian Fagir), a new version has been uploaded along with a short description page. The current version supports more options, a configuration file, and updated rc.d script. It also includes manual page updates and an optional debugging mode. __________________________________________________________________ FreeBSD/arm on Various TI Boards URL: http://svnweb.FreeBSD.org/base/projects/armv6/sys/arm/ti/ Contact: Ben Gray Contact: Olivier Houchard Contact: Damjan Marion Contact: Oleksandr Tymoshenko The goal of this project is to get FreeBSD running on various popular boards that use TI-based SoCs like OMAP3, OMAP4, AM335x. Project covers some ARM generic Cortex-A components: GIC (Generic Interrupt Controller), PL310 L2 Cache Controller and SCU. PandaBoard (TI OMAP4430) and PandaBoard ES (OMAP4460) Dual core ARM Cortex-A9 board support includes: USB, onboard Ethernet over USB, GPIO, I2C and MMC/SD card drivers. Board works in multiuser mode over NFS root. BeagleBone (TI AM3358/AM3359) single core ARM Cortex-A8 based board support currently includes: Ethernet, L2 cache, GPIO, I2C. Board works in multiuser mode over NFS root. Open tasks: 1. Completing missing peripherals: DMA, SPI, MMC/SD, Video, Audio. 2. Completing SMP support and testing. 3. Importing BeagleBoard (OMAP3) code to SVN. 4. Improving overall stability and performance. __________________________________________________________________ FreeBSD/powerpc on Freescale QorIQ DPAA URL: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=P2040 URL: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=P3041 URL: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=P5020 URL: http://www.freescale.com/webapp/sps/site/homepage.jsp?code=64BIT&fsrch= 1&sr=1 Contact: Michal Dubiel Contact: Rafal Jaworowski Contact: Piotr Ziecik This work is bringing up the FreeBSD on Freescale QorIQ Data Path Acceleration Architecture (DPAA) system-on-chips along with device drivers for integrated peripherals. Since the last status report, the following support has been added: * Ethernet (full network functionality using Regular Mode of DPAA infrastructure) * QorIQ P5020 SoC (e5500 core in legacy 32-bit mode) * P5020 QorIQ Development System support * Initial support for Enhanced SDHC The next step is: * e5500 core in native 64-bit mode Related publications: * Michal Dubiel, Piotr Ziecik, "FreeBSD on Freescale QorIQ Data Path Acceleration Architecture Devices", AsiaBSDCon, March 2012, Tokyo, Japan. __________________________________________________________________ GNU-Free C++11 Stack Contact: David Chisnall Since the last status report, the combination of libc++ and libcxxrt has received some additional testing and gained some new features including support for ARM EABI. With clang 3.1, we now pass all of the C++11 atomics tests. The xlocale implementation (required for libc++) has been tested with a variety of ports that were originally written for the Darwin implementation, and bugs that this testing uncovered have been fixed. This should be released in 9.1. In -CURRENT, we are now building libsupc++ as a shared library. This provides the ABI layer and building it as a shared library means that we can replace it with libcxxrt easily. If you are running -CURRENT, please try using libmap.conf to enable libcxxrt instead of libsupc++. If libstdc++ is using libcxxrt, you can now link against both libraries that are using libstdc++ and libc++, making the migration slightly easier, although you cannot pass STL objects between libraries using different STL versions. We still need a replacement for some parts of libgcc_s and for the linker, but we're on track for a BSD licensed C++ stack in 10.0. Open tasks: 1. Test ports with libc++. Hopefully most will Just Work, but others may need patches or have a hard dependency on libstdc++. 2. Enable building libc++ by default. This is dependent upon building with clang, because the version of gcc in the base system does not support C++11 and so can not be used to build libc++. 3. Removing libstdc++ from the base system and making it available through ports for backwards compatibility. __________________________________________________________________ Growing filesystems online Contact: Edward Tomasz Napierala The goal of this project is to make it possible to grow a filesystem, both UFS and ZFS, while it's mounted read-write. This includes changes to both filesystems, GEOM infrastructure, and the da(4) driver. For testing purposes, I've also added resizing to mdconfig(8) and implemented LUN resizing in CAM Target Layer. From the system administrator point of view, this makes it possible to resize mounted partition using gpart(8) and then resize the filesystem on it using growfs(8) - all without unmounting it first; especially useful if it's a root filesystem. All the functionality works and is in the process of being refined, reviewed and merged to HEAD. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. The write suspension infrastructure (/dev/ufssuspend) implemented to make resizing possible makes it also possible to implement online tunefs(8) and fsck(8). 2. Right now, there is no way for a GEOM class to veto resizing -- classes are notified about resize and they can either adapt, or wither. Many classes store their metadata in the last sector, though, so resizing a partition containing e.g. gmirror will make it inoperable. It would be nice if geom_mirror(4) could veto resizing, so the administrator attempting to shoot himself in the foot would get a warning. __________________________________________________________________ HDMI/DisplayPort Audio Support in HDA Sound Driver (snd_hda) Contact: Alexander Motin snd_hda(4) driver got number of improvements to better support HDMI/DisplayPort audio, such as: * Added fetching EDID-Like Data from the CODEC and video driver, describing audio capabilities of the display device. * Added setting HDMI/DP-specific CODEC options, such as number of channels, speakers configuration and channels mapping. * Added support for more multichannel formats. For HDMI and DisplayPort device now supported: 2.0, 2.1, 3.0, 3.1, 4.0, 4.1, 5.0, 5.1, 6.0, 6.1, 7.0 and 7.1 channels. * Added support for compressed streams passthrough with data rate 6.144 - 24Mbps, such as DTS-HD Master Audio or Dolby TrueHD. * Added support for HDA bus multiplexing to handle higher data rates (up to 92, 184 or more Mbps, depending on hardware capabilities). It allows to handle several 192/24/8 LPCM playback streams simultaneously. Above functionality was successfully tested on NVIDIA GT210 and GT520 video cards with nvidia-driver-290.10 driver. HDMI audio on older NVIDIA ION and Geforce 8300 boards still does not work for unknown reason. There are also successful reports about Intel video with latest KMS-based drivers. Support for ATI cards is limited to older cards, because video driver supporting newer cards does not support HDMI audio. The code was committed to HEAD and merged to 9-STABLE branch. Project sponsored by iXsystems, Inc. Open tasks: 1. Make better use of received EDID-Like Data. 2. Identify and fix problem with older NVIDIA cards. __________________________________________________________________ Improved hwpmc(9) Support for MIPS Contact: Oleksandr Tymoshenko hwpmc(9) for MIPS has been reworked. The changes include: * msip24k code was split to CPU-specific and arch-specific parts to make adding support for new CPUs easier * Added support for Octeon PMC * Added sampling support for MIPS in general __________________________________________________________________ IPv6 Performance Analysis URL: http://people.FreeBSD.org/~bz/bench/ Contact: Bjoern A. Zeeb IPv6 performance numbers were often seen (significantly) lower on FreeBSD when compared to IPv4. Continuing last years IPv6-only kernel efforts this project looked at various reasons for this and started fixing some. As part of the project a benchmark framework was created that could carry out various tests including reboots in between runs and gather results reproducibly without user intervention. It allows regular benchmarking with minimal configuration and easy future extension for more benchmarks. As a result of the initial analysis, UDP locking and route lookups were improved, and delayed checksumming, TSO6 and LRO support for IPv6 were implemented. Following this checksum "offload" for IPv6 on loopback was enabled and various further individual improvements, both locking and general code changes, as well as a reduction of the cache size footprint were carried out. Some of the changes were equally applied to IPv4. Performance numbers on physical and loopback interfaces are on par with IPv4 when using offload support with TCP/IPv6, which is a huge improvement. UDP and non-offload numbers on IPv6 have generally improved but are still lower than on IPv4 and will need future work to catch up with a decade of IPv4 benchmarking and code path optimizations. UDP IPv6 minimal size send path packets per second (pps) numbers however have increased beating IPv4 when sending to a local discard device. This gets us really close to being able to prefer IPv6 by default without causing loopback performance regressions. For physical interfaces, cxgb(4) in HEAD already supports IPv6 TCP offload and LRO/v6 support was added. To be able to get more test results on different hardware, both ixgbe(4) and cxgbe(4) were also updated to support TSO6 and LRO with IPv6. Some of the insights gained from this work will help upcoming discussions on both the lower/link-layer overhaul as well as for the mbuf changes to prepare our stack for more, future improvements (ahead of time). I once again want to thank the FreeBSD Foundation and iXsystems for their support of the project, as well as George Neville-Neil for providing review. Having set the start to close one of the biggest feature parity gaps left I will continue to improve IPv6 code paths and hope that we will see more contributions and independent results from the community as well soon. Open tasks: 1. Carefully merge code changes to SVN. __________________________________________________________________ isci(4) SAS Driver Contact: Jim Harris An Intel-supported isci(4) driver, for the integrated SAS controller in Intel's C600 chipsets, is now available in head, stable/9, stable/8 and stable/7. The isci(4) driver will also be part of the FreeBSD 8.3 release. __________________________________________________________________ KDE/FreeBSD URL: http://FreeBSD.kde.org URL: http://FreeBSD.kde.org/area51.php Contact: KDE FreeBSD The team has made many releases and upstreamed many fixes and patches. The latest round of releases include: * KDE SC: 4.7.4 (in ports) and 4.8.0, 4.8.1, 4.8.2 (in area51) * Qt: 4.8.0, 4.8.1 (in area51) * PyQt: 4.9.1; SIP: 4.13.2 (in area51) * KDevelop: 2.3.0; KDevPlatform: 1.3.0 (in area51) * Calligra: 2.3.87 (in area51) * Amarok: 2.5.0 * CMake: 2.8.7 Due to the prolonged port freeze the KDE team has not been able to update KDE in Ports as it is considered a intrusive change. The team is always looking for more testers and porters so please contact us at kde@FreeBSD.org and visit our home page at http://FreeBSD.kde.org. Open tasks: 1. Testing KDE SC 4.8.2. 2. Testing KDE PIM 4.8.2. 3. Testing phonon-gstreamer and phonon-vlc as the phonon-xine backend was deprecated (but will remain in the ports for now). 4. Testing the Calligra beta releases (in the area51 repository). __________________________________________________________________ Multi-FIB: IPv6 Support and Other Enhancements URL: http://svnweb.FreeBSD.org/base/projects/multi-fibv6/ Contact: Bjoern A. Zeeb Contact: Alexander V. Chernikov In 2008 the multiple forwarding information base (FIB) feature was introduced for IPv4 allowing up to 16 distinct forwarding ("routing") tables in the kernel. Thanks to the sponsorship from Cisco Systems, Inc. this feature is now also available for IPv6 and one of the bigger IPv6 feature-parity gaps is closed. The changes have been integrated to HEAD, were merged back to stable/9 and stable/8 and will be part of future releases for these branches. A backport to stable/7 is also available in the project branch. If more than one FIB is requested, IPv6 FIBs will be added along the extra IPv4 FIBs without any special configuration needed and programs like netstat and setfib, as well as ipfw, etc. were extended to seamlessly support the multi-FIB feature on both address families. Thanks to the help of Alexander V. Chernikov all usage of the multi-FIB feature is now using the boot-time variable rather than depending on the compile time option. In HEAD this now allows us you to use the multi-FIB feature with GENERIC kernels not needing to recompile your own anymore. The former kernel option can still be used to set a default value if desired. Otherwise the net.fibs loader tunable can be used to request more than one IPv6 and IPv4 FIB at boot time. Last, routing sockets are now aware of FIBs and will only show the routing messages targeted at the FIB attached to. This allows route monitor or routing daemons to get selective updates for just a specific FIB. __________________________________________________________________ NAND File System, NAND Flash Framework, NAND Simulator URL: http://svnweb.FreeBSD.org/base/projects/nand/ Contact: Grzegorz Bernacki Contact: Mateusz Guzik The NAND Flash stack consists of a driver framework for NAND controllers and memory chips, a NAND device simulator and a fault tolerant, log-structured file system, accompanied by tools, utilities and documentation. NAND FS support merged into "nand" project branch: * NAND FS filesystem * NAND FS userland tools NAND Framework and NAND simulator merged into "nand" project branch: * NAND framework: nandbus, generic nand chips drivers * NAND Flash controllers (NFC) drivers for NAND Simulator and Marvell MV-78100 (ARM) * NAND tool (which allows to erase, write/read pages/oob, etc. The next steps include: * Fix bugs * Merge into HEAD Work on this project is supported by the FreeBSD Foundation and Juniper Networks. __________________________________________________________________ Perl Ports Testing URL: http://wiki.FreeBSD.org/Perl#Test_Dependencies Contact: Steve Wills Many Perl modules in ports come with test cases included with their source. This project's goal is to ensure that all these tests pass. Significant progress has been made on this project. The change to build perl with -pthread was committed and no issues have been reported. Many ports have had missing dependencies added and/or other changes and approximately 90% of p5- ports pass tests. Work is being done on bringing testing support out of ports tinderbox. Open tasks: 1. Finish work on patch to bring testing support to ports. 2. Add additional support for testing other types of ports such as python and ruby. __________________________________________________________________ Porting DTrace to MIPS and ARM Contact: Oleksandr Tymoshenko The major part of DTrace has been ported to MIPS platform. Supported ABIs: o32 and n64. n32 has not been tested yet. MIPS implementation passes 853 of 927 tests from DTrace test suite. The fbt provider and userland DTrace are not supported yet. The port to ARM is in progress. Open tasks: 1. Userland DTrace support for MIPS. 2. Investigate amount of effort required for getting fbt provider work at least partially. 3. Find proper solution for cross-platform CTF data generation (required for ARM). __________________________________________________________________ Release Engineering Team Status Report URL: http://www.FreeBSD.org/releng/ Contact: Release Engineering Team On behalf of the FreeBSD Project the Release Engineering Team was are pleased to announce the release of the FreeBSD 8.3-RELEASE on April 18th, 2012. With the FreeBSD 8.3 release cycle completed our focus shifts to preparing for the FreeBSD 9.1-RELEASE. A schedule will be posted shortly, with the release target date set for mid-July 2012. __________________________________________________________________ Replacing the Regular Expression Code URL: http://svnweb.FreeBSD.org/base/user/gabor/tre-integration/ URL: http://laurikari.net/tre/ URL: http://www.tdk.aut.bme.hu/Files/TDK2011/POSIX-regularis-kifejezesek1.pd f Contact: Gábor Kövesdán Since the last status report, there has been a significant progress in optimizing TRE. The multiple pattern heuristic code is mostly finished and it distinguishes several different cases to speed up pattern matching. It extracts literal fragments from the original patterns and uses a multiple pattern matching algorithm to find any occurrence. GNU grep uses the Commentz-Walter algorithm, which is an automaton-based algorithm, while in this project, it has been decided to use a Wu-Manber algorithm, which is more efficient and also easier to implement. In the current state, it does not work entirely yet and some cases, like the REG_ICASE flag are not yet covered. This is the next major step to complete this multiple pattern interface. In the development branch, BSD grep is already modified to use this new interface so it can be used for testing and debugging purposes. Open tasks: 1. Finish multiple pattern heuristic regex matching. 2. Implement GNU-specific regex extensions. 3. Test standard-compliance and correct behavior. __________________________________________________________________ The bsdconfig(8) utility URL: http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdconfig/ URL: http://druidbsd.sf.net/download/bsdconfig/bsdconfig-20120512-1.svg URL: http://druidbsd.sf.net/download/bsdconfig/bsdconfig-20120512-1i.svg Contact: Devin Teske Contact: Ron McDowell Approaching 20,000 lines of sh(1) code, the bsdconfig(8) tool is approximately 70% complete. Upon completion of this project, bsdconfig(8) will represent (in conjunction with already-existing bsdinstall(8)) a complete set of utilities capable of purposefully deprecating sysinstall(8) in FreeBSD 9 and higher. This project has been a labor of love for Ron McDowell and I for over 90 days now and we are approaching the completion of this wonderful tool. Open tasks: 1. The "installer suite" modules for acquiring/installing binary packages and additional distribution sets. Startup services module. __________________________________________________________________ The FreeBSD Foundation Team Report URL: www.FreeBSDFoundation.org Contact: Deb Goodkin The Foundation sponsored AsiaBSDCon 2012 which was held in Tokyo, Japan, March 22-25. We were represented at SCALE on Jan 21 and NELF on March 17. This quarter we plan on being at ILF (Indiana LinuxFest) April 14th, BSDCan May 11-12, and SELF (Southeast LinuxFest) June 9. We are proud to be a gold sponsor of BSDCan 2012, which will be held in Ottawa, Canada, May 11-12. We are sponsoring 14 developers to attend the conference. We kicked off three foundation funded projects -- Growing Filesystems Online by Edward Tomasz Napierala, Implementing auditdistd daemon by Pawel Jakub Dawidek, and NAND Flash Support by Semihalf. We are pleased to announce the addition of George Neville-Neil to our board of directors. Deb Goodkin, our Director of Operations, was interviewed by bsdtalk. We announced a call for project proposals. We will accept proposals until April 30th. Please read Project Proposal Procedures to find out more. FreeBSD 9.0 was released and we are proud to say we funded 7 of the new features! __________________________________________________________________ The FreeBSD Haskell Ports URL: http://wiki.FreeBSD.org/Haskell URL: https://github.com/freebsd-haskell/freebsd-haskell/ URL: https://github.com/freebsd-haskell/hsporter/ URL: https://github.com/freebsd-haskell/hsmtk/ Contact: Gábor PÁLI Contact: Ashish SHUKLA We are proud announce that the FreeBSD Haskell Team has committed the Haskell Platform 2011.4.0.0 update, GHC 7.0.4 update, existing port updates, as well new port additions to FreeBSD ports repository, which were pending due to freeze for 9.0-RELEASE. Some of the new ports which were committed include Yesod, Happstack, wxHaskell, gitit, Threadscope, etc. and the count of Haskell ports in FreeBSD Ports tree is now almost 300. All of these updates will be available as part of upcoming 8.3-RELEASE. We started project hsporter to automate creation of new FreeBSD Haskell ports from .cabal file, as well as update existing ports. We also published scripts which we were using in the FreeBSD Haskell project under the project hsmtk. Open tasks: 1. Test GHC to work with clang/LLVM. 2. Add an option to the lang/ghc port to be able to build it with already installed GHC instead of requiring a separate GHC boostrap tarball. 3. Add more ports to the Ports Collection. __________________________________________________________________ The FreeBSD Japanese Documentation Project URL: http://www.FreeBSD.org/ja/ URL: http://www.jp.FreeBSD.org/doc-jp/ Contact: Hiroki Sato Contact: Ryusuke Suzuki The same as before, the outdated contents in the www/ja subtree were updated to the latest versions in the English counterpart. The updating work of the outdated translations in the www/ja subtree is almost complete. Only the translations of the release documents for old releases may be outdated. During this period, we translated the 9.0-RELEASE announcement and published it in a timely manner. It seems that the Japanese version of the release announcement is important for Japanese people as this page has frequently been referenced. For FreeBSD Handbook, translation work of the "cutting-edge" section is still on-going. Some updates in the "printing" and the "linuxemu" section were done. Open tasks: 1. Further translation work of outdated documents in both doc/ja_JP.eucJP and www/ja. __________________________________________________________________ The FreeBSD Ports Collection URL: http://www.FreeBSD.org/ports/ URL: http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributing-ports/ URL: http://portsmon.FreeBSD.org/index.html URL: http://www.FreeBSD.org/portmgr/index.html URL: http://blogs.FreeBSDish.org/portmgr/ URL: http://www.twitter.com/freebsd_portmgr/ URL: http://www.facebook.com/portmgr Contact: Thomas Abthorpe Contact: Port Management Team The ports tree slowly climbs above 23,000 ports. The PR count still remains at about 1100. In Q1 we added 2 new committers, took in 2 commit bits for safe keeping, and had one committer return to ports work. The Ports Management team have been running -exp runs on an ongoing basis, verifying how base system updates may affect the ports tree, as well as providing QA runs for major ports updates. Of note, -exp runs were done for: * Ports validation in the FreeBSD 10 environment * Updates to bison, libtool and libiconv * Set java/opendjdk6 as default java * Tests with clang set as default * Update to devel/boost and friends * Update of audio/sdl and friends * Tests for changes in the ports licensing infrastructure * Update to devel/ruby1[8|9] * Update to postresql * Update to apr * Checks for new x11/xorg * Security update to security/gnutls * Ongoing validation of infrastructure with pkgng A lot of focus during this period was put into getting the ports tree into a ready state for FreeBSD 8.3, including preparing packages for the release. Beat Gaetzi has been doing ongoing tests with the ports tree to ensure a smooth transition from CVS to Subversion. Open tasks: 1. Looking for help getting ports to build with clang. 2. Looking for help with Tier-2 architectures. 3. ports broken by src changes. 4. ports failing on pointyhat. 5. ports failing on pointyhat-west. 6. ports that are marked as BROKEN. 7. When did that port break? 8. Most ports PRs are assigned, we now need to focus on testing, committing and closing. __________________________________________________________________ The FreeNAS Project URL: http://www.FreeNAS.org Contact: Josh Paetzel Contact: Xin Li FreeNAS 8.0.4 was released last month, which marks the end of the 8.0.x branch in FreeNAS. FreeNAS 8.2.0 is in BETA currently, and will hopefully be released by the end of April. It features a number of improvements over the 8.0.x line, including plugin support, (the ability to run arbitrary software in jails), as well as better integration between command line ZFS and the GUI. Once 8.2.0 is out it will be quickly followed up with 8.3.0, which will include a number of driver updates as well as the long awaited ZFS v28. __________________________________________________________________ (c) 1995-2012 The FreeBSD Project. All rights reserved. From owner-freebsd-hackers@FreeBSD.ORG Sat May 12 23:36:10 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 359BF106566C for ; Sat, 12 May 2012 23:36:10 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id F345A8FC14 for ; Sat, 12 May 2012 23:36:09 +0000 (UTC) Received: by dadv36 with SMTP id v36so5115933dad.13 for ; Sat, 12 May 2012 16:36:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=3BG1cp2NgfU7Z3mjVr4LsHHt72h2Oz7E2VNmQfvNRqM=; b=YPItJ4ObMWl8kX0JetzxtVLDgM1PZdXiTg2zD8fVTKIPMGN9hrtRIDdotzmAoricIg QS9hx3hzJogkITdI+sAeETiBj4Ga7pWZkmkN/jgARPlmphVxPD/isua8a4HkKMDMtsIH BRPokLoSSROpVDBFXkXZHMCzyt6TXoRnH2TWIMKLHlLVomBOO9BjBQl7shNoXFADYHB/ lkQ1uEmmO32tp/TO8qdHzkXcyYvU240DepVQDhlgAxjK7TVLOatS5tIgEyT+SXucrcwn TtfU8OuJlZjnOO1O87PFbMLE0p6MNjGMmpBSl22XCRlqdxFwo7keS3IlN7tXH6/AvVG/ PdxQ== Received: by 10.68.231.164 with SMTP id th4mr8550692pbc.97.1336865769634; Sat, 12 May 2012 16:36:09 -0700 (PDT) Received: from [192.168.1.69] (99-74-169-43.lightspeed.sntcca.sbcglobal.net. [99.74.169.43]) by mx.google.com with ESMTPS id nv2sm17283070pbb.6.2012.05.12.16.36.06 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 12 May 2012 16:36:08 -0700 (PDT) Sender: Tim Kientzle Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: Date: Sat, 12 May 2012 16:36:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B2A320B-3ADE-4F48-B94E-4F0886178251@freebsd.org> <201205070957.03842.jhb@freebsd.org> <8B01DF29-747A-449C-A762-E852F57C6380@freebsd.org> To: Marcel Moolenaar X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmOqKFglpfXLDPYROIggMNdnT6tigp5NGofWQr8J7hQAr/xzxAU+rmgQw8hTMdETgB6UWiw Cc: arm@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: How does loader(8) decide where to load the kernel? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 23:36:10 -0000 On May 10, 2012, at 5:32 AM, Marcel Moolenaar wrote: >=20 > On May 8, 2012, at 1:32 AM, Tim Kientzle wrote: >>>> On i386, amd64, powerpc, and arm, loadimage subtracts >>>> the dest value from the address declared in the actual ELF >>>> headers so that the kernel always gets loaded into low memory. >>>> (there's some intermediate bit-twiddling I'm glossing over, but >>>> this is the general idea). >>>=20 >>> The bit twiddling is supposed to be the equivalent of subtracting >>> KERNBASE from the load address. On both i386 and amd64, there is >>> a direct mapping of the kernel text such that KERNBASE maps address >>> 0, etc. By default on i386 KERNBASE is 0xc0000000. >>=20 >> Exactly my problem. This all assumes that you're loading >> the kernel into low memory. >>=20 >> On the AM3358, the DRAM starts at 0x8000 0000 >> on boot, so I'm trying to find a clean way to convince >> the loader's ELF code to put the kernel there. >=20 > Look at what I did for ia64. All that frobbing should be done > in the machine specific implementation of arch_copyin, arch_copyout > and arch_readin. It's a kluge to do it in elf_loadimage. That sounds like a reasonable approach. I've started working down that path=85 but it looks like I'll have to fix a lot of the FDT code along the way. Tim