From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 19 12:50:20 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 101FCDC2 for ; Sun, 19 Apr 2015 12:50:20 +0000 (UTC) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::103]) by mx1.freebsd.org (Postfix) with ESMTP id A1158754 for ; Sun, 19 Apr 2015 12:50:19 +0000 (UTC) Received: from [172.16.1.102] (unknown [172.16.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 952002E300 for ; Sun, 19 Apr 2015 12:50:18 +0000 (UTC) Message-ID: <5533A48A.7080708@metricspace.net> Date: Sun, 19 Apr 2015 08:50:18 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: ZFS support for EFI References: <55189CBA.9040107@metricspace.net> <55311DA7.8080209@metricspace.net> In-Reply-To: <55311DA7.8080209@metricspace.net> Content-Type: multipart/mixed; boundary="------------020308030103090406010705" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 12:50:20 -0000 This is a multi-part message in MIME format. --------------020308030103090406010705 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit I've gotten the ZFS loader to the point where it successfully loads and attempts to execute the next stage. I wouldn't say boot1 is in its final state; there's going to have to be some way to get information about zfs from boot1 to loader, but I suspect that will fall into place when I'm working on loader itself. Please try this out on both UFS and ZFS systems, and verify that it does in fact successfully get all the way through the loading process. There's also a couple of issues I want to fix before the end: 1) The Malloc implementation uses the EFI memory pool allocator. This may not be the best way to go. 2) The module interface probably ought to expose a function that tries to load a file, returning its contents, rather than trying to load and execute a file. This would better support new filesystems, as well as things like checking cryptographic signatures. On 04/17/2015 10:50 AM, Eric McCorkle wrote: > I did some work on this last weekend. I've got the zfs-enabled boot1 > loading the ZFS uberblock, but it stops somewhere in the vdev_probe > code, believing the block to be a log. > > I've attached a patch if anyone wants to play around with it. > > Also, if someone with a UFS system could test that the modularization > didn't break UFS functionality, that'd be helpful. > > On 03/29/2015 08:45 PM, Eric McCorkle wrote: >> Hi folks, >> >> I've been messing around off and on for a while with adding ZFS support >> to the EFI boot. It's been mostly exploratory and self-contained up to >> this point, but I've gotten to a point that warrants some discussion. >> >> >> First, I've converted boot1.c (the EFI boot block) to use an FS module >> framework. This facilitates the addition of ZFS, and should also come >> in handy if someone wants to add other functionality later (ie. crypto, >> netboot, etc.) >> >> >> More importantly, the EFI loader doesn't seem to make use of its >> command-line arguments at all. But a ZFS-enabled loader would really >> need the ability to take arguments from boot1 (or grub, or whatever >> else). On the boot1 side, with ZFS you need to load and parse >> /boot/loader.conf (which may cause you to switch pools), then hand off >> the information to loader. In the BIOS loader, that's done through a >> binary data object that gets passed in. Command-line strings seem like >> the most sensible way to do it with EFI. >> >> Would this be the right way to go, and if so, what ought these >> command-line strings look like? >> >> >> Thanks, >> Eric >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> >> >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" --------------020308030103090406010705 Content-Type: text/x-patch; name="zfsefi.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="zfsefi.diff" Index: sys/boot/efi/boot1/Makefile =================================================================== --- sys/boot/efi/boot1/Makefile (revision 281381) +++ sys/boot/efi/boot1/Makefile (working copy) @@ -13,7 +13,7 @@ INTERNALPROG= # architecture-specific loader code -SRCS= boot1.c reloc.c start.S +SRCS= boot1.c reloc.c start.S ufs_module.c zfs_module.c CFLAGS+= -I. CFLAGS+= -I${.CURDIR}/../include @@ -20,6 +20,8 @@ CFLAGS+= -I${.CURDIR}/../include/${MACHINE_CPUARCH} CFLAGS+= -I${.CURDIR}/../../../contrib/dev/acpica/include CFLAGS+= -I${.CURDIR}/../../.. +CFLAGS+= -I${.CURDIR}/../../zfs/ +CFLAGS+= -I${.CURDIR}/../../../cddl/boot/zfs/ # Always add MI sources and REGULAR efi loader bits .PATH: ${.CURDIR}/../loader/arch/${MACHINE_CPUARCH} Index: sys/boot/efi/boot1/boot1.c =================================================================== --- sys/boot/efi/boot1/boot1.c (revision 281381) +++ sys/boot/efi/boot1/boot1.c (working copy) @@ -5,6 +5,8 @@ * All rights reserved. * Copyright (c) 2014 Nathan Whitehorn * All rights reserved. + * Copyright (c) 2014 Eric McCorkle + * All rights reverved. * * Redistribution and use in source and binary forms are freely * permitted provided that the above copyright notice and this @@ -21,7 +23,6 @@ __FBSDID("$FreeBSD$"); #include -#include #include #include @@ -28,6 +29,8 @@ #include #include +#include "boot_module.h" + #define _PATH_LOADER "/boot/loader.efi" #define _PATH_KERNEL "/boot/kernel/kernel" @@ -41,14 +44,20 @@ u_int sp_size; }; +static const boot_module_t* const boot_modules[] = +{ +#ifdef ZFS_EFI_BOOT + &zfs_module, +#endif +#ifdef UFS_EFI_BOOT + &ufs_module +#endif +}; + +#define NUM_BOOT_MODULES (sizeof(boot_modules) / sizeof(boot_module_t*)) + static const char digits[] = "0123456789abcdef"; -static void panic(const char *fmt, ...) __dead2; -static int printf(const char *fmt, ...); -static int putchar(char c, void *arg); -static int vprintf(const char *fmt, va_list ap); -static int vsnprintf(char *str, size_t sz, const char *fmt, va_list ap); - static int __printf(const char *fmt, putc_func_t *putc, void *arg, va_list ap); static int __putc(char c, void *arg); static int __puts(const char *s, putc_func_t *putc, void *arg); @@ -62,9 +71,80 @@ static EFI_SYSTEM_TABLE *systab; static EFI_HANDLE *image; -static void -bcopy(const void *src, void *dst, size_t len) + +void* Malloc(size_t len, const char* file, int line) { + void* out; + if (systab->BootServices->AllocatePool(EfiLoaderData, + len, &out) != + EFI_SUCCESS) { + printf("Can't allocate memory pool\n"); + return NULL; + } + return out; +} + +char* strcpy(char* dst, const char* src) { + for(int i = 0; src[i]; i++) + dst[i] = src[i]; + + return dst; +} + +char* strchr(const char* s, int c) { + for(int i = 0; s[i]; i++) + if (s[i] == c) + return (char*)(s + i); + + return NULL; +} + +int strncmp(const char *a, const char *b, size_t len) +{ + for (int i = 0; i < len; i++) + if(a[i] == '\0' && b[i] == '\0') { + return 0; + } else if(a[i] < b[i]) { + return -1; + } else if(a[i] > b[i]) { + return 1; + } + + return 0; +} + +char* strdup(const char* s) { + int len; + + for(len = 1; s[len]; len++); + + char* out = malloc(len); + + for(int i = 0; i < len; i++) + out[i] = s[i]; + + return out; +} + +int bcmp(const void *a, const void *b, size_t len) +{ + const char *sa = a; + const char *sb = b; + + for (int i = 0; i < len; i++) + if(sa[i] != sb[i]) + return 1; + + return 0; +} + +int memcmp(const void *a, const void *b, size_t len) +{ + return bcmp(a, b, len); +} + +void bcopy(const void *src, void *dst, size_t len) +{ const char *s = src; char *d = dst; @@ -72,23 +152,24 @@ *d++ = *s++; } -static void -memcpy(void *dst, const void *src, size_t len) +void* memcpy(void *dst, const void *src, size_t len) { bcopy(src, dst, len); + return dst; } -static void -bzero(void *b, size_t len) + +void* memset(void *b, int val, size_t len) { char *p = b; while (len-- != 0) - *p++ = 0; + *p++ = val; + + return b; } -static int -strcmp(const char *s1, const char *s2) +int strcmp(const char *s1, const char *s2) { for (; *s1 == *s2 && *s1; s1++, s2++) ; @@ -95,30 +176,50 @@ return ((u_char)*s1 - (u_char)*s2); } +int putchr(char c, void *arg) +{ + CHAR16 buf[2]; + + if (c == '\n') { + buf[0] = '\r'; + buf[1] = 0; + systab->ConOut->OutputString(systab->ConOut, buf); + } + buf[0] = c; + buf[1] = 0; + systab->ConOut->OutputString(systab->ConOut, buf); + return (1); +} + static EFI_GUID BlockIoProtocolGUID = BLOCK_IO_PROTOCOL; static EFI_GUID DevicePathGUID = DEVICE_PATH_PROTOCOL; -static EFI_GUID LoadedImageGUID = LOADED_IMAGE_PROTOCOL; static EFI_GUID ConsoleControlGUID = EFI_CONSOLE_CONTROL_PROTOCOL_GUID; -static EFI_BLOCK_IO *bootdev; -static EFI_DEVICE_PATH *bootdevpath; -static EFI_HANDLE *bootdevhandle; +#define MAX_DEVS 128 -EFI_STATUS efi_main(EFI_HANDLE Ximage, EFI_SYSTEM_TABLE* Xsystab) +void efi_main(EFI_HANDLE Ximage, EFI_SYSTEM_TABLE* Xsystab) { - EFI_HANDLE handles[128]; + EFI_HANDLE handles[MAX_DEVS]; + dev_info_t module_devs[NUM_BOOT_MODULES][MAX_DEVS]; + size_t dev_offsets[NUM_BOOT_MODULES]; EFI_BLOCK_IO *blkio; - UINTN i, nparts = sizeof(handles), cols, rows, max_dim, best_mode; + UINTN nparts = sizeof(handles); EFI_STATUS status; EFI_DEVICE_PATH *devpath; EFI_BOOT_SERVICES *BS; EFI_CONSOLE_CONTROL_PROTOCOL *ConsoleControl = NULL; SIMPLE_TEXT_OUTPUT_INTERFACE *conout = NULL; - char *path = _PATH_LOADER; + // Basic initialization systab = Xsystab; image = Ximage; + for(int i = 0; i < NUM_BOOT_MODULES; i++) + { + dev_offsets[i] = 0; + } + + // Set up the console, so printf works. BS = systab->BootServices; status = BS->LocateProtocol(&ConsoleControlGUID, NULL, (VOID **)&ConsoleControl); @@ -128,10 +229,14 @@ /* * Reset the console and find the best text mode. */ + UINTN max_dim; + UINTN best_mode; + UINTN cols; + UINTN rows; conout = systab->ConOut; conout->Reset(conout, TRUE); max_dim = best_mode = 0; - for (i = 0; ; i++) { + for (int i = 0; ; i++) { status = conout->QueryMode(conout, i, &cols, &rows); if (EFI_ERROR(status)) @@ -141,6 +246,7 @@ best_mode = i; } } + if (max_dim > 0) conout->SetMode(conout, best_mode); conout->EnableCursor(conout, TRUE); @@ -147,206 +253,94 @@ conout->ClearScreen(conout); printf("\n" - ">> FreeBSD EFI boot block\n"); - printf(" Loader path: %s\n", path); + ">> FreeBSD ZFS-enabled EFI boot block\n"); + printf(" Loader path: %s\n\n", _PATH_LOADER); + printf(" Initializing modules:"); + for(int i = 0; i < NUM_BOOT_MODULES; i++) + { + if (NULL != boot_modules[i]) + { + printf(" %s", boot_modules[i]->name); + boot_modules[i]->init(image, systab, BS); + } + } + putchr('\n', NULL); + + // Get all the device handles status = systab->BootServices->LocateHandle(ByProtocol, &BlockIoProtocolGUID, NULL, &nparts, handles); nparts /= sizeof(handles[0]); + //printf(" Scanning %lu device handles\n", nparts); - for (i = 0; i < nparts; i++) { + // Scan all partitions, probing with all modules. + for (int i = 0; i < nparts; i++) { + dev_info_t devinfo; + + // Figure out if we're dealing with an actual partition status = systab->BootServices->HandleProtocol(handles[i], &DevicePathGUID, (void **)&devpath); - if (EFI_ERROR(status)) + if (EFI_ERROR(status)) { + //printf(" Not a device path protocol\n"); continue; + } - while (!IsDevicePathEnd(NextDevicePathNode(devpath))) + while (!IsDevicePathEnd(NextDevicePathNode(devpath))) { + //printf(" Advancing to next device\n"); devpath = NextDevicePathNode(devpath); + } status = systab->BootServices->HandleProtocol(handles[i], &BlockIoProtocolGUID, (void **)&blkio); - if (EFI_ERROR(status)) + if (EFI_ERROR(status)) { + //printf(" Not a block device\n"); continue; + } - if (!blkio->Media->LogicalPartition) + if (!blkio->Media->LogicalPartition) { + //printf(" Logical partition\n"); continue; + } - if (domount(devpath, blkio, 1) >= 0) - break; - } + // Setup devinfo + devinfo.dev = blkio; + devinfo.devpath = devpath; + devinfo.devhandle = handles[i]; + devinfo.devdata = NULL; - if (i == nparts) - panic("No bootable partition found"); - - bootdevhandle = handles[i]; - load(path); - - panic("Load failed"); - - return EFI_SUCCESS; -} - -static int -dskread(void *buf, u_int64_t lba, int nblk) -{ - EFI_STATUS status; - int size; - - lba = lba / (bootdev->Media->BlockSize / DEV_BSIZE); - size = nblk * DEV_BSIZE; - status = bootdev->ReadBlocks(bootdev, bootdev->Media->MediaId, lba, - size, buf); - - if (EFI_ERROR(status)) - return (-1); - - return (0); -} - -#include "ufsread.c" - -static ssize_t -fsstat(ufs_ino_t inode) -{ -#ifndef UFS2_ONLY - static struct ufs1_dinode dp1; - ufs1_daddr_t addr1; -#endif -#ifndef UFS1_ONLY - static struct ufs2_dinode dp2; -#endif - static struct fs fs; - static ufs_ino_t inomap; - char *blkbuf; - void *indbuf; - size_t n, nb, size, off, vboff; - ufs_lbn_t lbn; - ufs2_daddr_t addr2, vbaddr; - static ufs2_daddr_t blkmap, indmap; - u_int u; - - blkbuf = dmadat->blkbuf; - indbuf = dmadat->indbuf; - if (!dsk_meta) { - inomap = 0; - for (n = 0; sblock_try[n] != -1; n++) { - if (dskread(dmadat->sbbuf, sblock_try[n] / DEV_BSIZE, - SBLOCKSIZE / DEV_BSIZE)) - return -1; - memcpy(&fs, dmadat->sbbuf, sizeof(struct fs)); - if (( -#if defined(UFS1_ONLY) - fs.fs_magic == FS_UFS1_MAGIC -#elif defined(UFS2_ONLY) - (fs.fs_magic == FS_UFS2_MAGIC && - fs.fs_sblockloc == sblock_try[n]) -#else - fs.fs_magic == FS_UFS1_MAGIC || - (fs.fs_magic == FS_UFS2_MAGIC && - fs.fs_sblockloc == sblock_try[n]) -#endif - ) && - fs.fs_bsize <= MAXBSIZE && - fs.fs_bsize >= sizeof(struct fs)) - break; - } - if (sblock_try[n] == -1) { - printf("Not ufs\n"); - return -1; - } - dsk_meta++; - } else - memcpy(&fs, dmadat->sbbuf, sizeof(struct fs)); - if (!inode) - return 0; - if (inomap != inode) { - n = IPERVBLK(&fs); - if (dskread(blkbuf, INO_TO_VBA(&fs, n, inode), DBPERVBLK)) - return -1; - n = INO_TO_VBO(n, inode); -#if defined(UFS1_ONLY) - memcpy(&dp1, (struct ufs1_dinode *)blkbuf + n, - sizeof(struct ufs1_dinode)); -#elif defined(UFS2_ONLY) - memcpy(&dp2, (struct ufs2_dinode *)blkbuf + n, - sizeof(struct ufs2_dinode)); -#else - if (fs.fs_magic == FS_UFS1_MAGIC) - memcpy(&dp1, (struct ufs1_dinode *)blkbuf + n, - sizeof(struct ufs1_dinode)); - else - memcpy(&dp2, (struct ufs2_dinode *)blkbuf + n, - sizeof(struct ufs2_dinode)); -#endif - inomap = inode; - fs_off = 0; - blkmap = indmap = 0; + // Run through each module, see if it can load this partition + for (int j = 0; j < NUM_BOOT_MODULES; j++ ) + { + if (NULL != boot_modules[j] && + boot_modules[j]->probe(&devinfo)) + { + // If it can, save it to the device list for + // that module + module_devs[j][dev_offsets[j]++] = devinfo; + } + } } - size = DIP(di_size); - n = size - fs_off; - return (n); -} -static struct dmadat __dmadat; + // Select a partition to boot. We do this by trying each + // module in order. + for (int i = 0; i < NUM_BOOT_MODULES; i++) + { + if (NULL != boot_modules[i]) + { + printf(" Trying to load from %lu %s partitions\n", + dev_offsets[i], boot_modules[i]->name); + boot_modules[i]->load(module_devs[i], dev_offsets[i], + _PATH_LOADER); + printf(" Failed\n"); + } + } -static int -domount(EFI_DEVICE_PATH *device, EFI_BLOCK_IO *blkio, int quiet) -{ - - dmadat = &__dmadat; - bootdev = blkio; - bootdevpath = device; - if (fsread(0, NULL, 0)) { - if (!quiet) - printf("domount: can't read superblock\n"); - return (-1); - } - if (!quiet) - printf("Succesfully mounted UFS filesystem\n"); - return (0); + // If we get here, we're out of luck... + panic("No bootable partitions found!"); } -static void -load(const char *fname) +void panic(const char *fmt, ...) { - ufs_ino_t ino; - EFI_STATUS status; - EFI_HANDLE loaderhandle; - EFI_LOADED_IMAGE *loaded_image; - void *buffer; - size_t bufsize; - - if ((ino = lookup(fname)) == 0) { - printf("File %s not found\n", fname); - return; - } - - bufsize = fsstat(ino); - status = systab->BootServices->AllocatePool(EfiLoaderData, - bufsize, &buffer); - fsread(ino, buffer, bufsize); - - /* XXX: For secure boot, we need our own loader here */ - status = systab->BootServices->LoadImage(TRUE, image, bootdevpath, - buffer, bufsize, &loaderhandle); - if (EFI_ERROR(status)) - printf("LoadImage failed with error %lx\n", status); - - status = systab->BootServices->HandleProtocol(loaderhandle, - &LoadedImageGUID, (VOID**)&loaded_image); - if (EFI_ERROR(status)) - printf("HandleProtocol failed with error %lx\n", status); - - loaded_image->DeviceHandle = bootdevhandle; - - status = systab->BootServices->StartImage(loaderhandle, NULL, NULL); - if (EFI_ERROR(status)) - printf("StartImage failed with error %lx\n", status); -} - -static void -panic(const char *fmt, ...) -{ char buf[128]; va_list ap; @@ -358,50 +352,25 @@ while (1) {} } -static int -printf(const char *fmt, ...) +int printf(const char *fmt, ...) { va_list ap; int ret; - /* Don't annoy the user as we probe for partitions */ - if (strcmp(fmt,"Not ufs\n") == 0) - return 0; va_start(ap, fmt); - ret = vprintf(fmt, ap); + ret = __printf(fmt, putchr, 0, ap); va_end(ap); return (ret); } -static int -putchar(char c, void *arg) +void vprintf(const char *fmt, va_list ap) { - CHAR16 buf[2]; - - if (c == '\n') { - buf[0] = '\r'; - buf[1] = 0; - systab->ConOut->OutputString(systab->ConOut, buf); - } - buf[0] = c; - buf[1] = 0; - systab->ConOut->OutputString(systab->ConOut, buf); - return (1); + __printf(fmt, putchr, 0, ap); } -static int -vprintf(const char *fmt, va_list ap) +int vsnprintf(char *str, size_t sz, const char *fmt, va_list ap) { - int ret; - - ret = __printf(fmt, putchar, 0, ap); - return (ret); -} - -static int -vsnprintf(char *str, size_t sz, const char *fmt, va_list ap) -{ struct sp_data sp; int ret; Index: sys/boot/efi/boot1/boot_module.h =================================================================== --- sys/boot/efi/boot1/boot_module.h (revision 0) +++ sys/boot/efi/boot1/boot_module.h (working copy) @@ -0,0 +1,58 @@ +#ifndef _BOOT_MODULE_H_ +#define _BOOT_MODULE_H_ + +#include + +#include +#include +#include + +#define UFS_EFI_BOOT 1 +#define ZFS_EFI_BOOT 1 + +// EFI device info +typedef struct dev_info_t +{ + EFI_BLOCK_IO *dev; + EFI_DEVICE_PATH *devpath; + EFI_HANDLE *devhandle; + void *devdata; +} dev_info_t; + +// A boot loader module. This is a standard interface for filesystem +// modules in the EFI system. +typedef struct boot_module_t +{ + const char* const name; + + // Initialize the module. + void (* const init)(EFI_HANDLE image, + EFI_SYSTEM_TABLE* systab, + EFI_BOOT_SERVICES *bootsrv); + + // Check to see if curr_dev is a device that this module can handle. + bool (* const probe)(dev_info_t* dev); + + // Select the best out of a set of devices that probe indicated were + // loadable, and load it. + void (* const load)(const dev_info_t devs[], + size_t ndevs, + const char* loader_path); +} boot_module_t; + +// Standard boot modules +#ifdef UFS_EFI_BOOT +extern const boot_module_t ufs_module; +#endif +#ifdef ZFS_EFI_BOOT +extern const boot_module_t zfs_module; +#endif + +// Functions available to modules +extern int strcmp(const char *s1, const char *s2); +extern void bcopy(const void *src, void *dst, size_t len); +extern void panic(const char *fmt, ...) __dead2; +extern int printf(const char *fmt, ...); +extern int vsnprintf(char *str, size_t sz, const char *fmt, va_list ap); + +#endif Property changes on: sys/boot/efi/boot1/boot_module.h ___________________________________________________________________ Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Index: sys/boot/efi/boot1/ufs_module.c =================================================================== --- sys/boot/efi/boot1/ufs_module.c (revision 0) +++ sys/boot/efi/boot1/ufs_module.c (working copy) @@ -0,0 +1,210 @@ +/*- + * Copyright (c) 1998 Robert Nordier + * All rights reserved. + * Copyright (c) 2001 Robert Drehmel + * All rights reserved. + * Copyright (c) 2014 Nathan Whitehorn + * All rights reserved. + * Copyright (c) 2015 Eric McCorkle + * All rights reverved. + * + * Redistribution and use in source and binary forms are freely + * permitted provided that the above copyright notice and this + * paragraph and the following disclaimer are duplicated in all + * such forms. + * + * This software is provided "AS IS" and without any express or + * implied warranties, including, without limitation, the implied + * warranties of merchantability and fitness for a particular + * purpose. + */ +#include +#include + +#include +#include + +#include + +#include "boot_module.h" + +static EFI_HANDLE image; +static EFI_SYSTEM_TABLE* systab; +static EFI_BOOT_SERVICES *bootsrv; +static dev_info_t devinfo; +static EFI_GUID LoadedImageGUID = LOADED_IMAGE_PROTOCOL; + +static int +dskread(void *buf, u_int64_t lba, int nblk) +{ + EFI_STATUS status; + int size; + + lba = lba / (devinfo.dev->Media->BlockSize / DEV_BSIZE); + size = nblk * DEV_BSIZE; + status = devinfo.dev->ReadBlocks(devinfo.dev, + devinfo.dev->Media->MediaId, lba, + size, buf); + + if (EFI_ERROR(status)) + return (-1); + + return (0); +} + +#include "ufsread.c" + +static ssize_t +fsstat(ufs_ino_t inode) +{ +#ifndef UFS2_ONLY + static struct ufs1_dinode dp1; + ufs1_daddr_t addr1; +#endif +#ifndef UFS1_ONLY + static struct ufs2_dinode dp2; +#endif + static struct fs fs; + static ufs_ino_t inomap; + char *blkbuf; + void *indbuf; + size_t n, nb, size, off, vboff; + ufs_lbn_t lbn; + ufs2_daddr_t addr2, vbaddr; + static ufs2_daddr_t blkmap, indmap; + u_int u; + + blkbuf = dmadat->blkbuf; + indbuf = dmadat->indbuf; + if (!dsk_meta) { + inomap = 0; + for (n = 0; sblock_try[n] != -1; n++) { + if (dskread(dmadat->sbbuf, sblock_try[n] / DEV_BSIZE, + SBLOCKSIZE / DEV_BSIZE)) + return -1; + memcpy(&fs, dmadat->sbbuf, sizeof(struct fs)); + if (( +#if defined(UFS1_ONLY) + fs.fs_magic == FS_UFS1_MAGIC +#elif defined(UFS2_ONLY) + (fs.fs_magic == FS_UFS2_MAGIC && + fs.fs_sblockloc == sblock_try[n]) +#else + fs.fs_magic == FS_UFS1_MAGIC || + (fs.fs_magic == FS_UFS2_MAGIC && + fs.fs_sblockloc == sblock_try[n]) +#endif + ) && + fs.fs_bsize <= MAXBSIZE && + fs.fs_bsize >= sizeof(struct fs)) + break; + } + if (sblock_try[n] == -1) { + return -1; + } + dsk_meta++; + } else + memcpy(&fs, dmadat->sbbuf, sizeof(struct fs)); + if (!inode) + return 0; + if (inomap != inode) { + n = IPERVBLK(&fs); + if (dskread(blkbuf, INO_TO_VBA(&fs, n, inode), DBPERVBLK)) + return -1; + n = INO_TO_VBO(n, inode); +#if defined(UFS1_ONLY) + memcpy(&dp1, (struct ufs1_dinode *)blkbuf + n, + sizeof(struct ufs1_dinode)); +#elif defined(UFS2_ONLY) + memcpy(&dp2, (struct ufs2_dinode *)blkbuf + n, + sizeof(struct ufs2_dinode)); +#else + if (fs.fs_magic == FS_UFS1_MAGIC) + memcpy(&dp1, (struct ufs1_dinode *)blkbuf + n, + sizeof(struct ufs1_dinode)); + else + memcpy(&dp2, (struct ufs2_dinode *)blkbuf + n, + sizeof(struct ufs2_dinode)); +#endif + inomap = inode; + fs_off = 0; + blkmap = indmap = 0; + } + size = DIP(di_size); + n = size - fs_off; + return (n); +} + +static struct dmadat __dmadat; + +static bool +probe(dev_info_t* const dev) +{ + devinfo = *dev; + dmadat = &__dmadat; + if (fsread(0, NULL, 0)) { + return 0; + } + return 1; +} + +static void +try_load(const dev_info_t dev, + const char* const loader_path) +{ + ufs_ino_t ino; + EFI_STATUS status; + EFI_HANDLE loaderhandle; + EFI_LOADED_IMAGE *loaded_image; + void *buffer; + size_t bufsize; + + devinfo = dev; + if ((ino = lookup(loader_path)) == 0) { + printf("File %s not found\n", loader_path); + return; + } + + bufsize = fsstat(ino); + status = systab->BootServices->AllocatePool(EfiLoaderData, + bufsize, &buffer); + fsread(ino, buffer, bufsize); + + status = systab->BootServices->LoadImage(TRUE, image, devinfo.devpath, + buffer, bufsize, &loaderhandle); + + status = systab->BootServices->HandleProtocol(loaderhandle, + &LoadedImageGUID, (VOID**)&loaded_image); + loaded_image->DeviceHandle = devinfo.devhandle; + + status = systab->BootServices->StartImage(loaderhandle, NULL, NULL); +} + +static void +load(const dev_info_t devs[], + const size_t ndevs, + const char* const loader_path) +{ + for(int i = 0; i < ndevs; i++) + { + try_load(devs[i], loader_path); + } +} + + +static void init(EFI_HANDLE xImage, + EFI_SYSTEM_TABLE* xSystab, + EFI_BOOT_SERVICES * xBootsrv) +{ + image = xImage; + systab = xSystab; + bootsrv = xBootsrv; +} + +const boot_module_t ufs_module = +{ + .name = "UFS", + .init = init, + .probe = probe, + .load = load +}; Property changes on: sys/boot/efi/boot1/ufs_module.c ___________________________________________________________________ Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Index: sys/boot/efi/boot1/zfs_module.c =================================================================== --- sys/boot/efi/boot1/zfs_module.c (revision 0) +++ sys/boot/efi/boot1/zfs_module.c (working copy) @@ -0,0 +1,215 @@ +/* Copyright (c) 2015 Eric McCorkle. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above + * copyright notice, this list of conditions and the following + * disclaimer in the documentation and/or other materials provided + * with the distribution. + * + * 3. Neither the name of the author nor the names of any contributors + * may be used to endorse or promote products derived from this + * software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED + * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A + * PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR + * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF + * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, + * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT + * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ +#include +#include +#include + +#include +#include +#include + +#include + +#include "boot_module.h" + +#include "libzfs.h" +#include "zfsimpl.c" + +#define PATH_CONFIG "/boot/config" +#define PATH_DOTCONFIG "/boot/.config" + +static EFI_HANDLE image; +static EFI_SYSTEM_TABLE* systab; +static EFI_BOOT_SERVICES *bootsrv; +static EFI_GUID LoadedImageGUID = LOADED_IMAGE_PROTOCOL; + +static int +vdev_read(vdev_t * const vdev, + void * const priv, + const off_t off, + void * const buf, + const size_t bytes) +{ + const dev_info_t* const devinfo = (const dev_info_t*) priv; + const off_t lba = off / devinfo->dev->Media->BlockSize; + const EFI_STATUS status = + devinfo->dev->ReadBlocks(devinfo->dev, + devinfo->dev->Media->MediaId, + lba, bytes, buf); + if (EFI_ERROR(status)) + return (-1); + + return (0); +} + +static bool probe(dev_info_t* const dev) +{ + spa_t* spa; + int result = vdev_probe(vdev_read, dev, &spa); + dev->devdata = spa; + + return result == 0; +} + +static void try_load(const dev_info_t devinfo, + const char* const loader_path) +{ + spa_t *spa = devinfo.devdata; + struct zfsmount zfsmount; + dnode_phys_t dn; + bool autoboot = true; + + if (zfs_spa_init(spa) != 0) { + // Mount failed. Don't report this loudly + return; + } + + // First, try mounting the ZFS volume + if (zfs_mount(spa, 0, &zfsmount) != 0) { + // Mount failed. Don't report this loudly + return; + } + + //vdev_t * const primary_vdev = spa_get_primary_vdev(spa); + + if (zfs_lookup(&zfsmount, loader_path, &dn) != 0) { + return; + } + + struct stat st; + if (zfs_dnode_stat(spa, &dn, &st)) { + return; + } + + const size_t bufsize = st.st_size; + void* buffer; + EFI_STATUS status; + EFI_HANDLE loaderhandle; + EFI_LOADED_IMAGE *loaded_image; + + if (systab->BootServices->AllocatePool(EfiLoaderData, + bufsize, &buffer) != + EFI_SUCCESS) { + return; + } + + if (dnode_read(spa, &dn, 0, buffer, bufsize) < 0) { + return; + } + + if (systab->BootServices->LoadImage(TRUE, image, devinfo.devpath, + buffer, bufsize, &loaderhandle) != + EFI_SUCCESS) { + return; + } + + if (systab->BootServices->HandleProtocol(loaderhandle, + &LoadedImageGUID, + (VOID**)&loaded_image) != + EFI_SUCCESS) { + return; + } + + loaded_image->DeviceHandle = devinfo.devhandle; + + printf("Image loader, attempting to execute\n"); + // XXX Set up command args first + if (systab->BootServices->StartImage(loaderhandle, NULL, NULL) != + EFI_SUCCESS) { + printf("Failed to execute loader\n"); + return; + } + +} + +static int zfs_mount_ds(const char * const dsname, + struct zfsmount * const zfsmount, + spa_t ** const spa) +{ + uint64_t newroot; + spa_t *newspa; + char *q; + + q = strchr(dsname, '/'); + if (q) + *q++ = '\0'; + newspa = spa_find_by_name(dsname); + if (newspa == NULL) { + printf("\nCan't find ZFS pool %s\n", dsname); + return -1; + } + + if (zfs_spa_init(newspa)) + return -1; + + newroot = 0; + if (q) { + if (zfs_lookup_dataset(newspa, q, &newroot)) { + printf("\nCan't find dataset %s in ZFS pool %s\n", + q, newspa->spa_name); + return -1; + } + } + if (zfs_mount(newspa, newroot, zfsmount)) { + printf("\nCan't mount ZFS dataset\n"); + return -1; + } + *spa = newspa; + return (0); +} + +static void load(const dev_info_t devs[], + const size_t ndevs, + const char* const loader_path) +{ + for(int i = 0; i < ndevs; i++) { + try_load(devs[i], loader_path); + } +} + +static void init(EFI_HANDLE xImage, + EFI_SYSTEM_TABLE* xSystab, + EFI_BOOT_SERVICES * xBootsrv) +{ + image = xImage; + systab = xSystab; + bootsrv = xBootsrv; + zfs_init(); +} + +const boot_module_t zfs_module = +{ + .name = "ZFS", + .init = init, + .probe = probe, + .load = load +}; Property changes on: sys/boot/efi/boot1/zfs_module.c ___________________________________________________________________ Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property --------------020308030103090406010705-- From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 19 12:52:47 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D0AA0EFD for ; Sun, 19 Apr 2015 12:52:47 +0000 (UTC) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::103]) by mx1.freebsd.org (Postfix) with ESMTP id AAC95829 for ; Sun, 19 Apr 2015 12:52:47 +0000 (UTC) Received: from [172.16.1.102] (unknown [172.16.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 561DD2E308 for ; Sun, 19 Apr 2015 12:52:41 +0000 (UTC) Message-ID: <5533A519.7030301@metricspace.net> Date: Sun, 19 Apr 2015 08:52:41 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: ZFS support for EFI References: <55189CBA.9040107@metricspace.net> <55311DA7.8080209@metricspace.net> <5533A48A.7080708@metricspace.net> In-Reply-To: <5533A48A.7080708@metricspace.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 12:52:47 -0000 On 04/19/2015 08:50 AM, Eric McCorkle wrote: > I've gotten the ZFS loader to the point where it successfully loads and > attempts to execute the next stage. That was a mistake; I meant "zfs boot block" From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 19 20:52:22 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3281668A for ; Sun, 19 Apr 2015 20:52:22 +0000 (UTC) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B865BCB1 for ; Sun, 19 Apr 2015 20:52:21 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.9/8.14.9/ALCHEMY.FRANKEN.DE) with ESMTP id t3JKqIus005234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 19 Apr 2015 22:52:18 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.9/8.14.9/Submit) id t3JKqHf5005232; Sun, 19 Apr 2015 22:52:17 +0200 (CEST) (envelope-from marius) Date: Sun, 19 Apr 2015 22:52:17 +0200 From: Marius Strobl To: Matthias Apitz , freebsd-hackers@freebsd.org, Jeremy Chadwick Subject: Re: Fwd: kernel: MCA: CPU 0 COR (1) internal parity error Message-ID: <20150419205217.GA3802@alchemy.franken.de> References: <20150118060843.GA1184@c720-r276659> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150118060843.GA1184@c720-r276659> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (alchemy.franken.de [0.0.0.0]); Sun, 19 Apr 2015 22:52:18 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 20:52:22 -0000 On Sun, Jan 18, 2015 at 07:08:43AM +0100, Matthias Apitz wrote: > > Hello, > > I'm running since some days a recent -HEAD r276659 on an Acer C720 Chromebook > which works very nicely and fast (I really have never seen such a fast KDE4 desktop). > > >From time to time (let's say 2-3 times a day) I see messages like this > in /var/log/messages: > > Jan 16 12:04:24 c720-r276659 kernel: MCA: Bank 0, Status 0x90000040000f0005 > Jan 16 12:04:24 c720-r276659 kernel: MCA: Global Cap 0x0000000000000c07, Status 0x0000000000000000 > Jan 16 12:04:24 c720-r276659 kernel: MCA: Vendor "GenuineIntel", ID 0x40651, APIC ID 0 > Jan 16 12:04:24 c720-r276659 kernel: MCA: CPU 0 COR (1) internal parity error > <...> > CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz (1396.80-MHz 686-class CPU) > Origin="GenuineIntel" Id=0x40651 Family=0x6 Model=0x45 Stepping=1 Apparently, this is the HSD131 or - more precisely - the HSM142 silicon bug, although the specification update concerened with HSM142 [1] only enlists CPU IDs 0x3c and 0x46 (actually, it only has identification information for the M- and H-line of processors, but not the Y- and - which Celeron 2955U belongs into - U-lines). Reporting should be gone with r281751. Marius 1: http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/4th-gen-core-family-mobile-specification-update.pdf From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 20 07:34:51 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6872F09 for ; Mon, 20 Apr 2015 07:34:51 +0000 (UTC) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8E984664 for ; Mon, 20 Apr 2015 07:34:51 +0000 (UTC) Received: from [89.204.138.151] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1Yk58o-0000C8-5h; Mon, 20 Apr 2015 08:25:10 +0200 Received: from localhost.my.domain (c720-r276659 [127.0.0.1]) by localhost.unixarea.de (8.14.9/8.14.9) with ESMTP id t3K6P8Pp002665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Apr 2015 08:25:08 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.9/8.14.9/Submit) id t3K6P74o002664; Mon, 20 Apr 2015 08:25:07 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Mon, 20 Apr 2015 08:25:07 +0200 From: Matthias Apitz To: Marius Strobl Cc: freebsd-hackers@freebsd.org, Jeremy Chadwick Subject: Re: Fwd: kernel: MCA: CPU 0 COR (1) internal parity error Message-ID: <20150420062507.GA2640@c720-r276659> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , Marius Strobl , freebsd-hackers@freebsd.org, Jeremy Chadwick References: <20150118060843.GA1184@c720-r276659> <20150419205217.GA3802@alchemy.franken.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150419205217.GA3802@alchemy.franken.de> X-Operating-System: FreeBSD 11.0-CURRENT r269739 (i386) User-Agent: Mutt/1.5.23 (2014-03-12) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.138.151 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 07:34:51 -0000 --0F1p//8PRICkK4MW Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit El día Sunday, April 19, 2015 a las 10:52:17PM +0200, Marius Strobl escribió: > On Sun, Jan 18, 2015 at 07:08:43AM +0100, Matthias Apitz wrote: > > > > Hello, > > > > I'm running since some days a recent -HEAD r276659 on an Acer C720 Chromebook > > which works very nicely and fast (I really have never seen such a fast KDE4 desktop). > > > > >From time to time (let's say 2-3 times a day) I see messages like this > > in /var/log/messages: > > > > Jan 16 12:04:24 c720-r276659 kernel: MCA: Bank 0, Status 0x90000040000f0005 > > Jan 16 12:04:24 c720-r276659 kernel: MCA: Global Cap 0x0000000000000c07, Status 0x0000000000000000 > > Jan 16 12:04:24 c720-r276659 kernel: MCA: Vendor "GenuineIntel", ID 0x40651, APIC ID 0 > > Jan 16 12:04:24 c720-r276659 kernel: MCA: CPU 0 COR (1) internal parity error > > > > <...> > > > CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz (1396.80-MHz 686-class CPU) > > Origin="GenuineIntel" Id=0x40651 Family=0x6 Model=0x45 Stepping=1 > > Apparently, this is the HSD131 or - more precisely - the HSM142 silicon > bug, although the specification update concerened with HSM142 [1] only > enlists CPU IDs 0x3c and 0x46 (actually, it only has identification > information for the M- and H-line of processors, but not the Y- and - > which Celeron 2955U belongs into - U-lines). Reporting should be gone > with r281751. > > Marius > > 1: http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/4th-gen-core-family-mobile-specification-update.pdf > Hello Marius, Thanks for a pointer to this explanation and bug fix. I pulled out mca.c of r281751 and the diff looks like I could simply update mca.c to this revision. Thanks matthias -- Matthias Apitz, guru@unixarea.de, http://www.unixarea.de/ +49-170-4527211 +49-176-38902045 "Wenn der Mensch von den Umständen gebildet wird, so muß man die Umstände menschlich bilden." "Si el hombre es formado por las circunstancias entonces es necesario formar humanamente las circunstancias", Karl Marx in Die heilige Familie / La sagrada familia (MEW 2, 138) --0F1p//8PRICkK4MW Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="mca.c.diff" *** x86/x86/mca.c 2015-01-06 08:21:59.000000000 +0100 --- /tmp/mca.c 2015-04-20 08:03:01.000000000 +0200 *************** *** 30,36 **** */ #include ! __FBSDID("$FreeBSD: head/sys/x86/x86/mca.c 269242 2014-07-29 14:54:23Z marius $"); #ifdef __amd64__ #define DEV_APIC --- 30,36 ---- */ #include ! __FBSDID("$FreeBSD$"); #ifdef __amd64__ #define DEV_APIC *************** *** 251,265 **** { /* ! * Skip spurious corrected parity errors generated by desktop Haswell ! * (see HSD131 erratum) unless reporting is enabled. ! * Note that these errors also have been observed with D0-stepping, ! * while the revision 014 desktop Haswell specification update only ! * talks about C0-stepping. */ ! if (rec->mr_cpu_vendor_id == CPU_VENDOR_INTEL && ! rec->mr_cpu_id == 0x306c3 && rec->mr_bank == 0 && ! rec->mr_status == 0x90000040000f0005 && !intel6h_HSD131) return (1); return (0); --- 251,274 ---- { /* ! * Skip spurious corrected parity errors generated by Intel Haswell- ! * and Broadwell-based CPUs (see HSD131, HSM142, HSW131 and BDM48 ! * erratum respectively), unless reporting is enabled. ! * Note that these errors also have been observed with the D0-stepping ! * of Haswell, while at least initially the CPU specification updates ! * suggested only the C0-stepping to be affected. Similarly, Celeron ! * 2955U with a CPU ID of 0x45 apparently are also concerned with the ! * same problem, with HSM142 only referring to 0x3c and 0x46. */ ! if (cpu_vendor_id == CPU_VENDOR_INTEL && ! CPUID_TO_FAMILY(cpu_id) == 0x6 && ! (CPUID_TO_MODEL(cpu_id) == 0x3c || /* HSD131, HSM142, HSW131 */ ! CPUID_TO_MODEL(cpu_id) == 0x3d || /* BDM48 */ ! CPUID_TO_MODEL(cpu_id) == 0x45 || ! CPUID_TO_MODEL(cpu_id) == 0x46) && /* HSM142 */ ! rec->mr_bank == 0 && ! (rec->mr_status & 0xa0000000ffffffff) == 0x80000000000f0005 && ! !intel6h_HSD131) return (1); return (0); --0F1p//8PRICkK4MW-- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 21 11:03:25 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC263EE6 for ; Tue, 21 Apr 2015 11:03:25 +0000 (UTC) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A40451701 for ; Tue, 21 Apr 2015 11:03:25 +0000 (UTC) Received: by oign205 with SMTP id n205so149634859oig.2 for ; Tue, 21 Apr 2015 04:03:25 -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=EjHZb7Cru1PwbtLKoEtB7g2h9VXd1HVq3c44gdblY60=; b=QgEl9zVzZBpH+TVHZvuiiXFFebkYgXJbHwWkBs3ZMxbKk4WFc43pyFIQN8rfStdmL/ /GazFJPJLbawmCLEmRx94LQ19WZ1Be0QW1HE6gEAbhgGtg8UVtYIgHKlp6ipuWKKZvRr 3F3Z0ESJiG6OcNKvQRioRD9Fr0/oS0jF5O1P+dOaRmzzT0HuKow5MxDN4YZuasT1qfxp dTzHR3aHNRNZlsen10UuZlMkKdCxD9s2O8LRu1gJiTWpk1zUd1rwfIlGDspXz00Om9rJ cYg1Nnff2A5hSA0sRo54oGKleGxhQ35deI4nDVeIYJ8ghK3QGfsiqVKQ38a/EQhODWoP mTmg== MIME-Version: 1.0 X-Received: by 10.182.241.197 with SMTP id wk5mr18686429obc.0.1429614204997; Tue, 21 Apr 2015 04:03:24 -0700 (PDT) Received: by 10.60.24.10 with HTTP; Tue, 21 Apr 2015 04:03:24 -0700 (PDT) Date: Tue, 21 Apr 2015 16:33:24 +0530 Message-ID: Subject: Clarification: Acquiring a mutex when a read/write lock is held From: Dheeraj Kandula To: freebsd-hackers@freebsd.org X-Mailman-Approved-At: Tue, 21 Apr 2015 11:33:55 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 11:03:25 -0000 Hey All, Can you clarify the following I have a read write lock locked. Next I want to acquire a mutex when the read write lock is held. Is this allowed or not. As far as I can understand from the "FreeBSD Kernel Developers Handbook" this operation is allowed in FreeBSD9.0, 10.0 and further. But the read write lock cannot be held while sleeping. Doesn't this contradict the above statement, as a thread will go to sleep if can't acquire the mutex when another thread holds the mutex. Hence what sleep are we referring here. Is this sleep(unbounded sleep) or the bounded sleep. Dheeraj From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 21 11:10:59 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 63464258 for ; Tue, 21 Apr 2015 11:10:59 +0000 (UTC) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A09D1751 for ; Tue, 21 Apr 2015 11:10:59 +0000 (UTC) Received: by oica37 with SMTP id a37so147216490oic.0 for ; Tue, 21 Apr 2015 04:10:58 -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; bh=gvmvoTKvfvigVFDoytXxg0QJSm5+izZFpx2cpCN+MC4=; b=ChuIKl5RQl9OS044OV7znOs23n0LtXV2sc8QGOrzAil01q+9cAFbYxYmrAHsu3b0Sr fL9E6gC7FwmaEkffMTvLrJh57PI9ZtGn6FL09ljKfsOUA4bMycasI/1LBP8ru3Spj3bf POUDhtKxBcpkagQHXjEPF9F/76RccuWcBkkxuewjJm+FkZwZxIxkbNlaP1EwOa0tNJrY HX6IXaTJ2MOSXVkEOB5/kA79LG/IpSBg1Gn+eX8qlJVOi0tKXK1LtkQ1+/B6KBk2mX9R 87PVD6eO6p/P2OgnRFXPTYlS+yp9MGy0iCcviRvE1dprvtPRAm51PNfLpLhG1IY2OQ3T sXdg== MIME-Version: 1.0 X-Received: by 10.182.250.134 with SMTP id zc6mr18718765obc.78.1429614658471; Tue, 21 Apr 2015 04:10:58 -0700 (PDT) Received: by 10.60.24.10 with HTTP; Tue, 21 Apr 2015 04:10:58 -0700 (PDT) In-Reply-To: References: Date: Tue, 21 Apr 2015 16:40:58 +0530 Message-ID: Subject: Fwd: Clarification: Acquiring a mutex when a read/write lock is held From: Dheeraj Kandula To: freebsd-hackers@freebsd.org X-Mailman-Approved-At: Tue, 21 Apr 2015 11:34:07 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 11:10:59 -0000 Hey All, Can you clarify the following I have a read write lock locked. Next I want to acquire a mutex when the read write lock is held. Is this allowed or not. As far as I can understand from the "FreeBSD Kernel Developers Handbook" this operation is allowed in FreeBSD9.0, 10.0 and further. But the read write lock cannot be held while sleeping. Doesn't this contradict the above statement, as a thread will go to sleep if can't acquire the mutex when another thread holds the mutex. Hence what sleep are we referring here. Is this sleep(unbounded sleep) or the bounded sleep. Dheeraj From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 21 11:39:19 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F244AAB6 for ; Tue, 21 Apr 2015 11:39:19 +0000 (UTC) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8ABD91AB6 for ; Tue, 21 Apr 2015 11:39:19 +0000 (UTC) Received: by wgin8 with SMTP id n8so209949683wgi.0 for ; Tue, 21 Apr 2015 04:39:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=zluu9WNoZVOq2zSwVikbIimq0csHeXpOxgMzvdQghAM=; b=K+hdx4BG5jgJ5dNXggiYAM627GbRwOohsuzrvFobyb9q+sxKTDuPs9aDEktOVq4Vbu 98oh3jPM4xl7xRw61LzPznOnfRlnSEbdd3gaJzBlHT2iwu30+uuxEC1BKEoj9+PiQWgm IlODQdzIfUQzAuwFZxHU7j8jKzfctSJiCiQA7cjH6lkB4bZDgTyGgbODEDACnlePpI4A kl3ITJsiMprUPCiWFBFK9TLfXYdeOFMRo+pUs5/aAWPOhiXShMyz4uySEPbJg9v5WwNN ON+VoZwXyUs2KvYD8t+5ukGkiLfJm/4WGhXRlgX8+BhfjISpGU6oDXo2UYCPS7ElgjZj pyGA== X-Received: by 10.194.185.68 with SMTP id fa4mr39331069wjc.111.1429616357845; Tue, 21 Apr 2015 04:39:17 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id pv2sm2235274wjc.33.2015.04.21.04.39.16 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 21 Apr 2015 04:39:17 -0700 (PDT) Date: Tue, 21 Apr 2015 13:39:14 +0200 From: Mateusz Guzik To: Dheeraj Kandula Cc: freebsd-hackers@freebsd.org Subject: Re: Clarification: Acquiring a mutex when a read/write lock is held Message-ID: <20150421113914.GA6312@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Dheeraj Kandula , freebsd-hackers@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 11:39:20 -0000 On Tue, Apr 21, 2015 at 04:33:24PM +0530, Dheeraj Kandula wrote: > Hey All, > Can you clarify the following > > I have a read write lock locked. Next I want to acquire a mutex when the > read write lock is held. Is this allowed or not. As far as I can understand > from the "FreeBSD Kernel Developers Handbook" this operation is allowed in > FreeBSD9.0, 10.0 and further. > > But the read write lock cannot be held while sleeping. Doesn't this > contradict the above statement, as a thread will go to sleep if can't > acquire the mutex when another thread holds the mutex. > > Hence what sleep are we referring here. Is this sleep(unbounded sleep) or > the bounded sleep. > Both lock types allow bound sleep, so there is nothing preventing you from establishing the order either way. Of course then there is the quesiton whether these particular locks you have in mind can be taken in the order you want to take them. -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 21 13:23:28 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F9DB138 for ; Tue, 21 Apr 2015 13:23:28 +0000 (UTC) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D8F20170D for ; Tue, 21 Apr 2015 13:23:27 +0000 (UTC) Received: by oica37 with SMTP id a37so149935851oic.0 for ; Tue, 21 Apr 2015 06:23:27 -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; bh=vrUpBR6KB12Ob+HxM6IsYrxuLdwFbPX+6Zz3OvYmoeI=; b=tCfjgZkfD7VMr2QeJOwBDvvJOlUMBEBE2eV3ashul56EjP6DwHinOn/Z/E5x+PI4me n5oCYKpTgAEEOj5ARjfYsKaCQwkRb5uGON6XtiKXR/zjKm0+2o1xLLMVdR4JEOni3ylD kdhK6raBDaFdPgqC6mCvjtxx8BEJ+7xpWGwQtSMpIqbhy7f/N3EaA2yqFDScJ0EYVWHX ZY9lwfMchKtRtLfxUs7WEB0zQXv6EtWIh5GpoJhEOPDAHz2vRF1vjbp2enkKs0P9wzWF jjnsidBN8rd+eIOtgmWR5MXXh3s4WfOTNd8M/CW9LyU9BRLmuQfYxxurjf2ybxFc5zE5 rTRg== MIME-Version: 1.0 X-Received: by 10.60.157.41 with SMTP id wj9mr19099455oeb.16.1429622607139; Tue, 21 Apr 2015 06:23:27 -0700 (PDT) Received: by 10.60.24.10 with HTTP; Tue, 21 Apr 2015 06:23:27 -0700 (PDT) In-Reply-To: <20150421113914.GA6312@dft-labs.eu> References: <20150421113914.GA6312@dft-labs.eu> Date: Tue, 21 Apr 2015 18:53:27 +0530 Message-ID: Subject: Re: Clarification: Acquiring a mutex when a read/write lock is held From: Dheeraj Kandula To: Mateusz Guzik , Dheeraj Kandula , freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 13:23:28 -0000 Thanks for the response. I want to acquire the read/write lock first either as reader or writer and then acquire the mutex lock. I think the second part of your response deals with ordering of locks to prevent deadlock. That shouldn't be an issue. Thanks again for the quick reply. On Tue, Apr 21, 2015 at 5:09 PM, Mateusz Guzik wrote: > On Tue, Apr 21, 2015 at 04:33:24PM +0530, Dheeraj Kandula wrote: > > Hey All, > > Can you clarify the following > > > > I have a read write lock locked. Next I want to acquire a mutex when the > > read write lock is held. Is this allowed or not. As far as I can > understand > > from the "FreeBSD Kernel Developers Handbook" this operation is allowed > in > > FreeBSD9.0, 10.0 and further. > > > > But the read write lock cannot be held while sleeping. Doesn't this > > contradict the above statement, as a thread will go to sleep if can't > > acquire the mutex when another thread holds the mutex. > > > > Hence what sleep are we referring here. Is this sleep(unbounded sleep) or > > the bounded sleep. > > > > Both lock types allow bound sleep, so there is nothing preventing you > from establishing the order either way. > > Of course then there is the quesiton whether these particular locks you > have in mind can be taken in the order you want to take them. > > -- > Mateusz Guzik > From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 22 15:41:26 2015 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F2E68C5 for ; Wed, 22 Apr 2015 15:41:26 +0000 (UTC) Received: from toco-domains.de (mail.toco-domains.de [176.9.39.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 526F41FEF for ; Wed, 22 Apr 2015 15:41:26 +0000 (UTC) Received: from [0.0.0.0] (mail.toco-domains.de [176.9.39.170]) by toco-domains.de (Postfix) with ESMTPA id 423F51B222C0; Wed, 22 Apr 2015 17:41:24 +0200 (CEST) Message-ID: <5537C123.4040308@toco-domains.de> Date: Wed, 22 Apr 2015 17:41:23 +0200 From: Torsten Zuehlsdorff User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: rank1seeker@gmail.com CC: hackers@freebsd.org Subject: Re: (GSoC 2015) Parallel ports build and installation => paraports References: <20150413151426.00000262@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 15:41:26 -0000 Hello, >> So, >> >> I haven't received a single response to my proposal. >> Is there something missing or totally wrong with it? >> Even negative response would be acceptable. >> >> I've applied for GSoC as a student and am at step where I should choose >> organization to which to submit a proposal (but write it first). >> >> I would really like to do this project. >> > > Did you send this mail to freebsd-ports@? > > Maybe you can find some feedback from porters and committers in that list. You should really follow this advice. :) Also did you have a look at poudriere? It's purpose is not exactly the same like yours, but maybe there are some parts you can use (or some ideas to get). Greetings, Torsten From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 23 05:06:14 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F4CBE44 for ; Thu, 23 Apr 2015 05:06:14 +0000 (UTC) Received: from mail.metricspace.net (207-172-209-89.c3-0.arl-ubr1.sbo-arl.ma.static.cable.rcn.com [207.172.209.89]) by mx1.freebsd.org (Postfix) with ESMTP id 4692716E9 for ; Thu, 23 Apr 2015 05:06:13 +0000 (UTC) Received: from [172.16.1.102] (unknown [172.16.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 8182A2F257 for ; Thu, 23 Apr 2015 05:06:06 +0000 (UTC) Message-ID: <55387DBE.7040706@metricspace.net> Date: Thu, 23 Apr 2015 01:06:06 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: FreeBSD and Gentoo Linux on the same ZFS volume Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 05:06:14 -0000 I had previously posted asking if anyone had ever gotten FreeBSD and a linux distro to share the same ZFS volume. I have since accomplished this setup with FreeBSD and Gentoo linux on a GPT disk with a single ZFS volume. I'll write a quick-and-dirty description of how to do it here; at some point in the future, I'll write a more in-depth wiki page about it. == Setting up the Volume == Assume the pool's name is "data". I have the following datasets: data/freebsd, mountpoint = legacy (root of FreeBSD) data/freebsd/*, all mountpoints = legacy data/home, mountpoint = /home (shared home dirs between linux and BSD) data/linux, mountpoint = legacy (root of linux) data/linux/*, all mountpoints = legacy Note that only the datasets that are shared between the two OSes use the ZFS mounting system. The ZFS code doesn't seem to support a "just mount everything under my root" option (if it does, someone please point it out). Thus, I have fstab entries for all the OS-specific datasets. I also have a /linux directory under the FreeBSD root, and a /freebsd directory under the linux root, at which the corresponding OS's filesystems are mounted. Thus, each OS is accessible from the other. I can see this being particularly useful to folks trying to port device drivers. Lastly, make sure to set data/freebsd as the boot dataset. Linux can specify which dataset to use as root. == Booting == Boot selection can be accomplished using GRUB. You can install GRUB using the FreeBSD port. The MBR/bios solution should work for now; I'm currently working on getting the EFI loader to work with ZFS, but it's still a ways out. Unfortunately, the port doesn't seem to be particularly well-documented. The following procedure will set up an EFI-based GRUB with a linux and a freebsd option (the freebsd option currently won't work with EFI and ZFS) 1) Install the sysutils/grub2-efi port 2) Edit /usr/local/etc/grub.d/40-custom file, add the following: menuentry "Gentoo Linux" { search.fs_label data ZFS_PART linux ($ZFS_PART)/linux@/boot/kernel dozfs=force root=ZFS=data/linux initrd ($ZFS_PART)/linux@/boot/initramfs } You'll also need to add a FreeBSD entry, as the script to detect FreeBSD partitions doesn't seem to recognize ZFS. 3) Do "grub-mkconfig > /boot/grub.cfg" to generate the config file 4) Mount the EFI system partition under /mnt 5) Run "grub-install --efi-directory=/mnt --target=x86_64-efi --modules=part_gpt". This will install the binary at /mnt/efi/grub/grubx64.efi 6) Run "cp /mnt/efi/grub/grubx64.efi /mnt/efi/boot/bootx64.efi" to copy GRUB into position to be run by the EFI loader. It should be possible to rework this for legacy BIOS boot, which will actually allow you to select the FreeBSD option and have it work. == Installing FreeBSD == I currently have a legacy BIOS boot set up with a GPT disk, which boots FreeBSD from the ZFS partition. There are guides for how to do this, and they actually work. You can do a MBR/BSDlabel setup if your BIOS can't do legacy boots with a GPT disk (Apple). Be sure to update /etc/fstab too. == Installing Gentoo Linux == The recent livedvd images have ZFS support, and will support the current pool version. Older livedvds and other distros' installers sometimes only support the older pool versions. Once you get a livedvd with the right ZFS version, you can mount the pool and follow the gentoo install guide for the most part. You'll have to build a new kernel, install the ZFS ports, then build the initramfs, which can be a bit tricky. Try to get the kernel/modules/initramfs setup working enough to boot, then circle back and install the rest of the OS. Also, make sure you update /etc/fstab. == Provisos == * I wouldn't recommend sharing swap space, as at least FreeBSD might have saved a crash dump there (and I'm pretty sure linux swap has to be prepared first) * Sharing a L2ARC or intent log is also probably a bad idea. The disjoint access patterns of the two OSes will mess up the locality properties. == Running == Once you've got everything set up, you should be able to boot either OS, use a common /home, and then access the other OS from the /linux or /freebsd directories. As there isn't ZFS support in the EFI loader (yet!), I currently have to switch to legacy BIOS boot mode to boot FreeBSD, and switch back to EFI to boot gentoo (via GRUB). From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 24 16:50:54 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2BD00D6D; Fri, 24 Apr 2015 16:50:54 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BD29214C8; Fri, 24 Apr 2015 16:50:53 +0000 (UTC) Received: by wiax7 with SMTP id x7so39172526wia.0; Fri, 24 Apr 2015 09:50:52 -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=i2gabPsfiqK3l/ejlwnZktI+OfGWzEDbhnACUPYXjIw=; b=k3NdVRwQQ6AEfk1CgdNxK07sbp1SiQC1lb9UowXOwfpTfKxlaQZy5u6JNsnMgFVaSl H+bXlehCbRe0yiv8CjLQt6AkIK3n4ZLr7YFtRUMPXrmSA+P7IDIs5mvoF6R9NyVCmuk2 RlAHZqvu8iTHpJqEMouKdJ2VIzMcoorE4kuG6Gh/nIZ+E3qoUmeI9wSt4S0+su3gc/r3 Q2LHY8aCcl6YzJn5P1N6x/abUebB8YTCNTUBUjkhmPJs8OMzVLo1WK286tKO1fOdTBMx FEmaiv7n4EafIppXzuszTa+B2LBDXbmcqTPkCPcpHCpVKrbA1sZHAxlV74vbT+FHmEV7 qaMA== MIME-Version: 1.0 X-Received: by 10.180.89.231 with SMTP id br7mr5474375wib.60.1429894252257; Fri, 24 Apr 2015 09:50:52 -0700 (PDT) Received: by 10.194.38.104 with HTTP; Fri, 24 Apr 2015 09:50:52 -0700 (PDT) Date: Fri, 24 Apr 2015 19:50:52 +0300 Message-ID: Subject: EFI boot loader regression? From: Andrey Fesenko To: freebsd-current , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 16:50:54 -0000 Hello, I'm use system with EFI boot loader on Lenovo X220. Old EFI loader work fine if BIOS set any boot priority UEFI or Legacy first. Starting around December last year, system not boot if set UEFI boot first. http://bsdnir.info/files/efi/ screenshots and working version boot loader For the cleanliness of experiment, as a new loader I downloaded and test FreeBSD-11.0-CURRENT-amd64-20150421-r281832-memstick.img From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 24 18:35:19 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A17657D for ; Fri, 24 Apr 2015 18:35:19 +0000 (UTC) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::103]) by mx1.freebsd.org (Postfix) with ESMTP id 01FCF11C6 for ; Fri, 24 Apr 2015 18:35:19 +0000 (UTC) Received: from [10.0.1.68] (70-88-198-115-NewEngland.hfc.comcastbusiness.net [70.88.198.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 4D1082F1E1 for ; Fri, 24 Apr 2015 18:35:17 +0000 (UTC) Message-ID: <553A8CE4.9030204@metricspace.net> Date: Fri, 24 Apr 2015 14:35:16 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: EFI boot loader regression? References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 18:35:19 -0000 What kind of laptop are you using, and did you update your BIOS in there anywhere? I'm actively working on the UEFI boot block. I will post a patch with extra debugging messages added, which will hopefully help track down the problem. On 04/24/2015 12:50 PM, Andrey Fesenko wrote: > Hello, > > I'm use system with EFI boot loader on Lenovo X220. > > Old EFI loader work fine if BIOS set any boot priority UEFI or Legacy first. > > Starting around December last year, system not boot if set UEFI boot first. > > http://bsdnir.info/files/efi/ screenshots and working version boot loader > > For the cleanliness of experiment, as a new loader I downloaded and > test FreeBSD-11.0-CURRENT-amd64-20150421-r281832-memstick.img > _______________________________________________ > 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 Fri Apr 24 20:13:48 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D907292C for ; Fri, 24 Apr 2015 20:13:48 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 729D11D0D for ; Fri, 24 Apr 2015 20:13:48 +0000 (UTC) Received: by widdi4 with SMTP id di4so32009949wid.0 for ; Fri, 24 Apr 2015 13:13:46 -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=0oOUFn6YVQg0MRXVFt6kTaiKKl70xglSKY9dyOs+xok=; b=Ad0T7f8sBwZlLsTtkDSsd05nPwts4KEDLkzcQfd844ssa1+FmxYlLbmzrhSF1YX01a XgI5z6jFTzG1E5DnOR+1U1Fr/Sh0W5ISFb37tka90IetFK+DtzjX99lfqpV8rPs//RwX SM4WlCLVxPcVWX2akdYw8LSojG29c2ZGxrMOTVZ2ZP+mf5i4m6jZFI1n+UjABBRkOwPN 7Gr8iEkIYbdT/EI/Z5HiBOJ3FMdNchPYgR0p+ujTSK3it0R8FQQRmzOtWkYQ6sxIvt7k qU5bfHqgWq5oP2FVZO79S7hcfUcoHLWKFh0xikMrN2p6nhSATBDJTAgq3iEnnGjy/m3M zW0w== MIME-Version: 1.0 X-Received: by 10.194.121.68 with SMTP id li4mr274601wjb.84.1429906426532; Fri, 24 Apr 2015 13:13:46 -0700 (PDT) Received: by 10.194.38.104 with HTTP; Fri, 24 Apr 2015 13:13:46 -0700 (PDT) In-Reply-To: <553A8CE4.9030204@metricspace.net> References: <553A8CE4.9030204@metricspace.net> Date: Fri, 24 Apr 2015 23:13:46 +0300 Message-ID: Subject: Re: EFI boot loader regression? From: Andrey Fesenko To: Eric McCorkle Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 20:13:48 -0000 On Fri, Apr 24, 2015 at 9:35 PM, Eric McCorkle wrote: > What kind of laptop are you using, and did you update your BIOS in there > anywhere? > > I'm actively working on the UEFI boot block. I will post a patch with > extra debugging messages added, which will hopefully help track down the > problem. > Vendor: LENOVO Version: 8DET61WW (1.31 ) Release Date: 04/25/2012 Firmware Revision: 1.20 wit hack remove white list wi-fi. According to the log updates any updates EFI in new versions BIOS do not. I am ready to help in testing, and I can build a system with a higher level debugging if tell how to do it