From owner-freebsd-hackers@FreeBSD.ORG Sun May 10 02:00:08 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 DD7862EF for ; Sun, 10 May 2015 02:00:08 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BEBF61DFA for ; Sun, 10 May 2015 02:00:07 +0000 (UTC) Received: from [192.168.200.208] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 52157192906 for ; Sun, 10 May 2015 02:00:06 +0000 (UTC) Message-ID: <554EBBA5.9000303@ignoranthack.me> Date: Sat, 09 May 2015 19:00:05 -0700 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: How to get anything useful out of kgdb? References: <554E41EE.2010202@ignoranthack.me> <554E4BD1.1030802@ignoranthack.me> <406EAA27-D825-408B-985E-DC3FFE746473@frob.org> <554E5263.8010205@ignoranthack.me> <20150509190347.10e1e2c2@kan> In-Reply-To: <20150509190347.10e1e2c2@kan> Content-Type: text/plain; charset=koi8-r 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, 10 May 2015 02:00:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >> >> I'm guessing that the place to change -O2 -> -O0 is in >> kern.pre.mk ? >> >> sean > > No, it means you need to iescover DEBUG and how it affects > optimization level :) > > .if defined(DEBUG) _MINUS_O= -O CTFFLAGS+= -g .else ... > > Say, I have 'makeoptions DEBUG="-g -gdwarf-2"' in my kernel > config file. -gdwarf-2 is probably not required anymore. Indeed! :-) I was directed to go a slightly different way: make.conf: COPTFLAGS=-O0 CFLAGS=-O0 This makes unbootable kernels and they panic unless you defined the following in your kernel config: options KSTACK_PAGES=6 sean -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJVTruiXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kPtwIAIBLJNM3c8ml1+31ZAg7Z/tM xTLPBroxdO12GIAMniacX1A1YGDWbt+jGt9097Yzm7SWKFLa4cR/C62QqgwdwM6N XJDoh4Vyd+oaOou3zaLo2FSfMX9tS2TsVZOdl+aOU2D0qkgMZP/y2tt9j9tcLlUn rMg6uKI6JrUh4dHHuM2V5T8FC2t99JnJqPPPTrEdXoNrjMBU+5eAUiufvorQhAHF JkknzZ0BFOSfn+4M9YDyNVmlYX2qtX+6NudbxNAwrRCsgIAzVxWgQ875VqT1Pjov TggjbtnHF6d9CNHlQK0AKckXHDhSdECjQ4vcCtIKiniHtX46YxA8w2x9Id7dXM0= =wWUX -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Sun May 10 18:04: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 AB3DE920 for ; Sun, 10 May 2015 18:04: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 4689A18D6 for ; Sun, 10 May 2015 18:04:47 +0000 (UTC) Received: from [IPv6:2001:470:1f11:617:5ef7:830:9e60:2038] (unknown [IPv6:2001:470:1f11:617:5ef7:830:9e60:2038]) (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 71E4E29AD2 for ; Sun, 10 May 2015 18:04:46 +0000 (UTC) Message-ID: <554F9DBB.6020202@metricspace.net> Date: Sun, 10 May 2015 14:04:43 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: EFI boot loader regression? References: <553A8CE4.9030204@metricspace.net> In-Reply-To: <553A8CE4.9030204@metricspace.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BdNR2hc2JDrfgguIWCHHMsfb9beOihcgH" 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, 10 May 2015 18:04:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BdNR2hc2JDrfgguIWCHHMsfb9beOihcgH Content-Type: multipart/mixed; boundary="------------040709080406050600000600" This is a multi-part message in MIME format. --------------040709080406050600000600 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sorry for the delay in posting this. Attached is my latest work on the boot block. It includes numerous debugging messages. You should be able to tell if it gets all the way through the first stage, or where it stops if it doesn't. For everyone else, these are the outstanding issues I still need to addre= ss: * I'm currently (ab)using the UEFI pool allocator as a malloc-like mechanism. * The partition scan completely ignores the GPT labels, and tries to probe every single partition for every single filesystem. * Need to work out argv-style options for the UEFI loader, and have the boot block construct and pass in an argv array. Any other comments are welcome. On 04/24/2015 02:35 PM, Eric McCorkle wrote: > What kind of laptop are you using, and did you update your BIOS in ther= e > anywhere? >=20 > 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 th= e > problem. >=20 > 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 f= irst. >> >> http://bsdnir.info/files/efi/ screenshots and working version boot loa= der >> >> 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" >> > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 --------------040709080406050600000600 Content-Type: text/x-patch; name="zfsefi_curr.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="zfsefi_curr.diff" Index: sys/boot/efi/boot1/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/efi/boot1/Makefile (revision 281381) +++ sys/boot/efi/boot1/Makefile (working copy) @@ -13,7 +13,7 @@ INTERNALPROG=3D =20 # architecture-specific loader code -SRCS=3D boot1.c reloc.c start.S +SRCS=3D boot1.c reloc.c start.S ufs_module.c zfs_module.c =20 CFLAGS+=3D -I. CFLAGS+=3D -I${.CURDIR}/../include @@ -20,6 +20,8 @@ CFLAGS+=3D -I${.CURDIR}/../include/${MACHINE_CPUARCH} CFLAGS+=3D -I${.CURDIR}/../../../contrib/dev/acpica/include CFLAGS+=3D -I${.CURDIR}/../../.. +CFLAGS+=3D -I${.CURDIR}/../../zfs/ +CFLAGS+=3D -I${.CURDIR}/../../../cddl/boot/zfs/ =20 # Always add MI sources and REGULAR efi loader bits .PATH: ${.CURDIR}/../loader/arch/${MACHINE_CPUARCH} Index: sys/boot/efi/boot1/boot1.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- 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$"); =20 #include -#include #include #include =20 @@ -28,6 +29,8 @@ #include #include =20 +#include "boot_module.h" + #define _PATH_LOADER "/boot/loader.efi" #define _PATH_KERNEL "/boot/kernel/kernel" =20 @@ -41,14 +44,20 @@ u_int sp_size; }; =20 +static const boot_module_t* const boot_modules[] =3D +{ +#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[] =3D "0123456789abcdef"; =20 -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_li= st 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; =20 -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) !=3D + EFI_SUCCESS) { + printf("Can't allocate memory pool\n"); + return NULL; + } + return out; +} + +char* strcpy(char* dst, const char* src) { + for(int i =3D 0; src[i]; i++) + dst[i] =3D src[i]; + + return dst; +} + +char* strchr(const char* s, int c) { + for(int i =3D 0; s[i]; i++) + if (s[i] =3D=3D c) + return (char*)(s + i); + + return NULL; +} + +int strncmp(const char *a, const char *b, size_t len) +{ + for (int i =3D 0; i < len; i++) + if(a[i] =3D=3D '\0' && b[i] =3D=3D '\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 =3D 1; s[len]; len++); + + char* out =3D malloc(len); + + for(int i =3D 0; i < len; i++) + out[i] =3D s[i]; + + return out; +} + +int bcmp(const void *a, const void *b, size_t len) +{ + const char *sa =3D a; + const char *sb =3D b; + + for (int i =3D 0; i < len; i++) + if(sa[i] !=3D 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 =3D src; char *d =3D dst; =20 @@ -72,23 +152,24 @@ *d++ =3D *s++; } =20 -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; } =20 -static void -bzero(void *b, size_t len) + +void* memset(void *b, int val, size_t len) { char *p =3D b; =20 while (len-- !=3D 0) - *p++ =3D 0; + *p++ =3D val; + + return b; } =20 -static int -strcmp(const char *s1, const char *s2) +int strcmp(const char *s1, const char *s2) { for (; *s1 =3D=3D *s2 && *s1; s1++, s2++) ; @@ -95,30 +176,99 @@ return ((u_char)*s1 - (u_char)*s2); } =20 +int putchr(char c, void *arg) +{ + CHAR16 buf[2]; + + if (c =3D=3D '\n') { + buf[0] =3D '\r'; + buf[1] =3D 0; + systab->ConOut->OutputString(systab->ConOut, buf); + } + buf[0] =3D c; + buf[1] =3D 0; + systab->ConOut->OutputString(systab->ConOut, buf); + return (1); +} + static EFI_GUID BlockIoProtocolGUID =3D BLOCK_IO_PROTOCOL; static EFI_GUID DevicePathGUID =3D DEVICE_PATH_PROTOCOL; +static EFI_GUID ConsoleControlGUID =3D EFI_CONSOLE_CONTROL_PROTOCOL_GUID= ; static EFI_GUID LoadedImageGUID =3D LOADED_IMAGE_PROTOCOL; -static EFI_GUID ConsoleControlGUID =3D EFI_CONSOLE_CONTROL_PROTOCOL_GUID= ; =20 -static EFI_BLOCK_IO *bootdev; -static EFI_DEVICE_PATH *bootdevpath; -static EFI_HANDLE *bootdevhandle; +#define MAX_DEVS 128 =20 -EFI_STATUS efi_main(EFI_HANDLE Ximage, EFI_SYSTEM_TABLE* Xsystab) +void try_load(const boot_module_t* const mod, + const dev_info_t devs[], + size_t ndevs) { - EFI_HANDLE handles[128]; + int idx; + size_t bufsize; + void* const buffer =3D mod->load(devs, ndevs, _PATH_LOADER, &idx= , &bufsize); + EFI_HANDLE loaderhandle; + EFI_LOADED_IMAGE *loaded_image; + + if (NULL =3D=3D buffer) { + printf("Could not load file\n"); + return; + } + printf("Loaded file %s, image at %p\n" + "Attempting to load as bootable image...", + _PATH_LOADER, image); + if (systab->BootServices->LoadImage(TRUE, image, devs[idx].devpa= th, + buffer, bufsize, &loaderhand= le) !=3D + EFI_SUCCESS) { + printf("failed\n"); + return; + } + printf("success\n" + "Preparing to execute image..."); + + if (systab->BootServices->HandleProtocol(loaderhandle, + &LoadedImageGUID, + (VOID**)&loaded_image) = !=3D + EFI_SUCCESS) { + printf("failed\n"); + return; + } + + printf("success\n"); + + loaded_image->DeviceHandle =3D devs[idx].devhandle; + + printf("Image prepared, attempting to execute\n"); + // XXX Set up command args first + if (systab->BootServices->StartImage(loaderhandle, NULL, NULL) != =3D + EFI_SUCCESS) { + printf("Failed to execute loader\n"); + return; + } + printf("Shouldn't be here!\n"); +} + +void efi_main(EFI_HANDLE Ximage, EFI_SYSTEM_TABLE* Xsystab) +{ + 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 =3D sizeof(handles), cols, rows, max_dim, best_mode; + UINTN nparts =3D sizeof(handles); EFI_STATUS status; EFI_DEVICE_PATH *devpath; EFI_BOOT_SERVICES *BS; EFI_CONSOLE_CONTROL_PROTOCOL *ConsoleControl =3D NULL; SIMPLE_TEXT_OUTPUT_INTERFACE *conout =3D NULL; - char *path =3D _PATH_LOADER; =20 + // Basic initialization systab =3D Xsystab; image =3D Ximage; =20 + for(int i =3D 0; i < NUM_BOOT_MODULES; i++) + { + dev_offsets[i] =3D 0; + } + + // Set up the console, so printf works. BS =3D systab->BootServices; status =3D BS->LocateProtocol(&ConsoleControlGUID, NULL, (VOID **)&ConsoleControl); @@ -128,10 +278,14 @@ /* * Reset the console and find the best text mode. */ + UINTN max_dim; + UINTN best_mode; + UINTN cols; + UINTN rows; conout =3D systab->ConOut; conout->Reset(conout, TRUE); max_dim =3D best_mode =3D 0; - for (i =3D 0; ; i++) { + for (int i =3D 0; ; i++) { status =3D conout->QueryMode(conout, i, &cols, &rows); if (EFI_ERROR(status)) @@ -141,6 +295,7 @@ best_mode =3D i; } } + if (max_dim > 0) conout->SetMode(conout, best_mode); conout->EnableCursor(conout, TRUE); @@ -147,206 +302,94 @@ conout->ClearScreen(conout); =20 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); =20 + printf(" Initializing modules:"); + for(int i =3D 0; i < NUM_BOOT_MODULES; i++) + { + if (NULL !=3D 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 =3D systab->BootServices->LocateHandle(ByProtocol, &BlockIoProtocolGUID, NULL, &nparts, handles); nparts /=3D sizeof(handles[0]); + printf(" Scanning %lu device handles\n", nparts); =20 - for (i =3D 0; i < nparts; i++) { + // Scan all partitions, probing with all modules. + for (int i =3D 0; i < nparts; i++) { + dev_info_t devinfo; + + // Figure out if we're dealing with an actual partition status =3D systab->BootServices->HandleProtocol(handles[i], &DevicePathGUID, (void **)&devpath); - if (EFI_ERROR(status)) + if (EFI_ERROR(status)) { + printf(" Not a device path protocol\n"); continue; + } =20 - while (!IsDevicePathEnd(NextDevicePathNode(devpath))) + while (!IsDevicePathEnd(NextDevicePathNode(devpath))) { + printf(" Advancing to next device\n"); devpath =3D NextDevicePathNode(devpath); + } =20 status =3D systab->BootServices->HandleProtocol(handles[i], &BlockIoProtocolGUID, (void **)&blkio); - if (EFI_ERROR(status)) + if (EFI_ERROR(status)) { + printf(" Not a block device\n"); continue; + } =20 - if (!blkio->Media->LogicalPartition) + if (!blkio->Media->LogicalPartition) { + printf(" Logical partition\n"); continue; + } =20 - if (domount(devpath, blkio, 1) >=3D 0) - break; - } + // Setup devinfo + devinfo.dev =3D blkio; + devinfo.devpath =3D devpath; + devinfo.devhandle =3D handles[i]; + devinfo.devdata =3D NULL; =20 - if (i =3D=3D nparts) - panic("No bootable partition found"); - - bootdevhandle =3D 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 =3D lba / (bootdev->Media->BlockSize / DEV_BSIZE); - size =3D nblk * DEV_BSIZE; - status =3D 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 =3D dmadat->blkbuf; - indbuf =3D dmadat->indbuf; - if (!dsk_meta) { - inomap =3D 0; - for (n =3D 0; sblock_try[n] !=3D -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 =3D=3D FS_UFS1_MAGIC -#elif defined(UFS2_ONLY) - (fs.fs_magic =3D=3D FS_UFS2_MAGIC && - fs.fs_sblockloc =3D=3D sblock_try[n]) -#else - fs.fs_magic =3D=3D FS_UFS1_MAGIC || - (fs.fs_magic =3D=3D FS_UFS2_MAGIC && - fs.fs_sblockloc =3D=3D sblock_try[n]) -#endif - ) && - fs.fs_bsize <=3D MAXBSIZE && - fs.fs_bsize >=3D sizeof(struct fs)) - break; - } - if (sblock_try[n] =3D=3D -1) { - printf("Not ufs\n"); - return -1; - } - dsk_meta++; - } else - memcpy(&fs, dmadat->sbbuf, sizeof(struct fs)); - if (!inode) - return 0; - if (inomap !=3D inode) { - n =3D IPERVBLK(&fs); - if (dskread(blkbuf, INO_TO_VBA(&fs, n, inode), DBPERVBLK)) - return -1; - n =3D 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 =3D=3D 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 =3D inode; - fs_off =3D 0; - blkmap =3D indmap =3D 0; + // Run through each module, see if it can load this part= ition + for (int j =3D 0; j < NUM_BOOT_MODULES; j++ ) + { + if (NULL !=3D 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]++] =3D dev= info; + } + } } - size =3D DIP(di_size); - n =3D size - fs_off; - return (n); -} =20 -static struct dmadat __dmadat; + // Select a partition to boot. We do this by trying each + // module in order. + for (int i =3D 0; i < NUM_BOOT_MODULES; i++) + { + if (NULL !=3D boot_modules[i]) + { + printf(" Trying to load from %lu %s partitions= \n", + dev_offsets[i], boot_modules[i]->name); + try_load(boot_modules[i], module_devs[i], + dev_offsets[i]); + printf(" Failed\n"); + } + } =20 -static int -domount(EFI_DEVICE_PATH *device, EFI_BLOCK_IO *blkio, int quiet) -{ - - dmadat =3D &__dmadat; - bootdev =3D blkio; - bootdevpath =3D 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!"); } =20 -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 =3D lookup(fname)) =3D=3D 0) { - printf("File %s not found\n", fname); - return; - } - - bufsize =3D fsstat(ino); - status =3D systab->BootServices->AllocatePool(EfiLoaderData, - bufsize, &buffer); - fsread(ino, buffer, bufsize); - - /* XXX: For secure boot, we need our own loader here */ - status =3D systab->BootServices->LoadImage(TRUE, image, bootdevpath, - buffer, bufsize, &loaderhandle); - if (EFI_ERROR(status)) - printf("LoadImage failed with error %lx\n", status); - - status =3D systab->BootServices->HandleProtocol(loaderhandle, - &LoadedImageGUID, (VOID**)&loaded_image); - if (EFI_ERROR(status)) - printf("HandleProtocol failed with error %lx\n", status); - - loaded_image->DeviceHandle =3D bootdevhandle; - - status =3D 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 +401,25 @@ while (1) {} } =20 -static int -printf(const char *fmt, ...) +int printf(const char *fmt, ...) { va_list ap; int ret; =20 - /* Don't annoy the user as we probe for partitions */ - if (strcmp(fmt,"Not ufs\n") =3D=3D 0) - return 0; =20 va_start(ap, fmt); - ret =3D vprintf(fmt, ap); + ret =3D __printf(fmt, putchr, 0, ap); va_end(ap); return (ret); } =20 -static int -putchar(char c, void *arg) +void vprintf(const char *fmt, va_list ap) { - CHAR16 buf[2]; - - if (c =3D=3D '\n') { - buf[0] =3D '\r'; - buf[1] =3D 0; - systab->ConOut->OutputString(systab->ConOut, buf); - } - buf[0] =3D c; - buf[1] =3D 0; - systab->ConOut->OutputString(systab->ConOut, buf); - return (1); + __printf(fmt, putchr, 0, ap); } =20 -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 =3D __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; =20 Index: sys/boot/efi/boot1/boot_module.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/efi/boot1/boot_module.h (revision 0) +++ sys/boot/efi/boot1/boot_module.h (working copy) @@ -0,0 +1,60 @@ +#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 han= dle. + 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, + int* idxref, + size_t* bufsizeref); +} 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=3D%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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- 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 =3D LOADED_IMAGE_PROTOCOL; + +static int +dskread(void *buf, u_int64_t lba, int nblk) +{ + EFI_STATUS status; + int size; + + lba =3D lba / (devinfo.dev->Media->BlockSize / DEV_BSIZE); + size =3D nblk * DEV_BSIZE; + status =3D devinfo.dev->ReadBlocks(devinfo.dev, + devinfo.dev->Media->MediaId, lb= a, + 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 =3D dmadat->blkbuf; + indbuf =3D dmadat->indbuf; + if (!dsk_meta) { + inomap =3D 0; + for (n =3D 0; sblock_try[n] !=3D -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 =3D=3D FS_UFS1_MAGIC +#elif defined(UFS2_ONLY) + (fs.fs_magic =3D=3D FS_UFS2_MAGIC && + fs.fs_sblockloc =3D=3D sblock_try[n]) +#else + fs.fs_magic =3D=3D FS_UFS1_MAGIC || + (fs.fs_magic =3D=3D FS_UFS2_MAGIC && + fs.fs_sblockloc =3D=3D sblock_try[n]) +#endif + ) && + fs.fs_bsize <=3D MAXBSIZE && + fs.fs_bsize >=3D sizeof(struct fs)) + break; + } + if (sblock_try[n] =3D=3D -1) { + return -1; + } + dsk_meta++; + } else + memcpy(&fs, dmadat->sbbuf, sizeof(struct fs)); + if (!inode) + return 0; + if (inomap !=3D inode) { + n =3D IPERVBLK(&fs); + if (dskread(blkbuf, INO_TO_VBA(&fs, n, inode), DBPERVBLK)) + return -1; + n =3D 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 =3D=3D 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 =3D inode; + fs_off =3D 0; + blkmap =3D indmap =3D 0; + } + size =3D DIP(di_size); + n =3D size - fs_off; + return (n); +} + +static struct dmadat __dmadat; + +static bool +probe(dev_info_t* const dev) +{ + devinfo =3D *dev; + dmadat =3D &__dmadat; + if (fsread(0, NULL, 0)) { + return 0; + } + return 1; +} + +static void* +try_load(const dev_info_t dev, + const char* const loader_path, + size_t* const bufsizeref) +{ + ufs_ino_t ino; + EFI_STATUS status; + void *buffer; + size_t bufsize; + + devinfo =3D dev; + if ((ino =3D lookup(loader_path)) =3D=3D 0) { + printf("File %s not found\n", loader_path); + return NULL; + } + + bufsize =3D fsstat(ino); + *bufsizeref =3D bufsize; + status =3D systab->BootServices->AllocatePool(EfiLoaderData, + bufsize, &buffer); + fsread(ino, buffer, bufsize); + return buffer; +} + +static void* +load(const dev_info_t devs[], + const size_t ndevs, + const char* const loader_path, + int* const idxref, + size_t* const bufsizeref) +{ + for(int i =3D 0; i < ndevs; i++) + { + void* const out =3D try_load(devs[i], loader_path, bufsiz= eref); + if (out !=3D NULL) + { + *idxref =3D i; + return out; + } + } + return NULL; +} + + +static void init(EFI_HANDLE xImage, + EFI_SYSTEM_TABLE* xSystab, + EFI_BOOT_SERVICES * xBootsrv) +{ + image =3D xImage; + systab =3D xSystab; + bootsrv =3D xBootsrv; +} + +const boot_module_t ufs_module =3D +{ + .name =3D "UFS", + .init =3D init, + .probe =3D probe, + .load =3D 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=3D%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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/efi/boot1/zfs_module.c (revision 0) +++ sys/boot/efi/boot1/zfs_module.c (working copy) @@ -0,0 +1,201 @@ +/* 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 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 =3D (const dev_info_t*) priv; + const off_t lba =3D off / devinfo->dev->Media->BlockSize; + const EFI_STATUS status =3D + 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 =3D vdev_probe(vdev_read, dev, &spa); + dev->devdata =3D spa; + + return result =3D=3D 0; +} + +static void* try_load(const dev_info_t devinfo, + const char* const loader_path, + size_t* const bufsizeref) +{ + spa_t *spa =3D devinfo.devdata; + struct zfsmount zfsmount; + dnode_phys_t dn; + bool autoboot =3D true; + + if (zfs_spa_init(spa) !=3D 0) { + // Mount failed. Don't report this loudly + return NULL; + } + + // First, try mounting the ZFS volume + if (zfs_mount(spa, 0, &zfsmount) !=3D 0) { + // Mount failed. Don't report this loudly + return NULL; + } + + //vdev_t * const primary_vdev =3D spa_get_primary_vdev(spa); + + if (zfs_lookup(&zfsmount, loader_path, &dn) !=3D 0) { + return NULL; + } + + struct stat st; + if (zfs_dnode_stat(spa, &dn, &st)) { + return NULL; + } + + const size_t bufsize =3D st.st_size; + void* buffer; + EFI_STATUS status; + + *bufsizeref =3D bufsize; + + if (systab->BootServices->AllocatePool(EfiLoaderData, + bufsize, &buffer) !=3D + EFI_SUCCESS) { + return NULL; + } + + if (dnode_read(spa, &dn, 0, buffer, bufsize) < 0) { + return NULL; + } + + return buffer; +} + +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 =3D strchr(dsname, '/'); + if (q) + *q++ =3D '\0'; + newspa =3D spa_find_by_name(dsname); + if (newspa =3D=3D NULL) { + printf("\nCan't find ZFS pool %s\n", dsname); + return -1; + } + + if (zfs_spa_init(newspa)) + return -1; + + newroot =3D 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 =3D newspa; + return (0); +} + +static void* load(const dev_info_t devs[], + const size_t ndevs, + const char* const loader_path, + int* const idxref, + size_t* const bufsizeref) +{ + for(int i =3D 0; i < ndevs; i++) { + void* const out =3D try_load(devs[i], loader_path, bufsi= zeref); + if (out !=3D NULL) + { + *idxref =3D i; + return out; + } + } + return NULL; +} + +static void init(EFI_HANDLE xImage, + EFI_SYSTEM_TABLE* xSystab, + EFI_BOOT_SERVICES * xBootsrv) +{ + image =3D xImage; + systab =3D xSystab; + bootsrv =3D xBootsrv; + zfs_init(); +} + +const boot_module_t zfs_module =3D +{ + .name =3D "ZFS", + .init =3D init, + .probe =3D probe, + .load =3D 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=3D%H \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property --------------040709080406050600000600-- --BdNR2hc2JDrfgguIWCHHMsfb9beOihcgH 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 iQIcBAEBAgAGBQJVT53DAAoJEEGB2s+NNG0FfAQP/1LiivskAgDIPNiXjq6ZhapJ FgPtFWzpkOHIe7WXfXgqwCwziFlvwmmyVTcX/JfbXtLO9UK/Y+aUEw0bnwbMEy2f bsWbsfauTL2X6Q7zeabTG/JV/G9tOe/IQKYYQFaYeMY7pweX0g9Dqv1eGWgOG6Is t+4xaSxv1I+L9HjcuRnoJ1sWnvTEx7oPi7Gwm0XtTmNeRB4tB7IJS4GFe4kQjR9t WinWfO+pQMxFJaTKYpG9GZ4x2Syt92xC+z4qVETKEydG54eoFfOu9GNmju6p1irX IcYxQBH6Fm5quR+CkrR66xVNVJfZjgSa11zU1HI0OgHFT9T+tsL1sDWnDPuIBgKH YjB/vsb1jnqIF+l31y9Y50rTWOelPugGQcpdXhHTbsxIZTgpPh+N1LegpcS40Ny9 Q52j39igaSR2Z9IjlLAMsNyk2BcS3Wfv/gMFeg/QB6w5N1r5ucMkQHLQn7FQ41n1 MDu2f+4aW4zx1NfY7U69VVmQHy0fcR61p0CnIIcx2FavRemjQquHvmC7TehBh5ab PHpg3qW1dt60vVEmW4O9wbGx1zMhkCvB+UTSQPjaYwkMS2Zul94Y+e1HVp6qUoou QJ61p+JbpYNfndJfm6NNtvvmhbZTjQCiQ8L3wyAhNXL9hxF51GXdV9Ocd911NsRU u+bqVCyj7xgCe+9nXuxk =ljNX -----END PGP SIGNATURE----- --BdNR2hc2JDrfgguIWCHHMsfb9beOihcgH-- From owner-freebsd-hackers@FreeBSD.ORG Mon May 11 11:43: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 5A1F0810 for ; Mon, 11 May 2015 11:43:59 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (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 E1EBF15EF for ; Mon, 11 May 2015 11:43:58 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id F04E86ABEC6; Mon, 11 May 2015 13:43:54 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id t4BBhsXG087677; Mon, 11 May 2015 13:43:54 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id t4BBhs0A084071; Mon, 11 May 2015 13:43:54 +0200 (CEST) (envelope-from lars) Date: Mon, 11 May 2015 13:43:54 +0200 From: Lars Engels To: Jonathan de Boyne Pollard Cc: FreeBSD Hackers Subject: Re: nosh version 1.14 Message-ID: <20150511114354.GK53149@e-new.0x20.net> References: <54430B41.3010301@NTLWorld.com> <54B86FD5.3090203@NTLWorld.com> <554E53EF.4080600@NTLWorld.com> <554E5EEA.7020901@NTLWorld.com> <554E7EB6.3000200@NTLWorld.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ogUXNSQj4OI1q3LQ" Content-Disposition: inline In-Reply-To: <554E7EB6.3000200@NTLWorld.com> X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p23 User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Mon, 11 May 2015 12:01:42 +0000 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, 11 May 2015 11:43:59 -0000 --ogUXNSQj4OI1q3LQ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 09, 2015 at 10:40:06PM +0100, Jonathan de Boyne Pollard wrote: > nosh is now up to version 1.14 >=20 > * http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.ht= ml >=20 > The largest part of the recent changes is a list of new service bundles,= =20 > most of which are cross-platform, but a few of which are BSD-specific. = =20 > The bundles list now comes to some 230 services, not counting logging=20 > services. The list ranges from vixiecron to OpenStack Swift, passing=20 > through such things as RabbitMQ, CUPS, and MongoDB along the way. >=20 > As I said, I have been running FreeBSD with the nosh system and service= =20 > management for some time. And the service bundles, that I already have,= =20 > have for some time been enough to fully bootstrap and run my machine. =20 > But I haven't yet finished that list of 157 rc.d scripts that I=20 > mentioned back in the announcement of nosh version 1.9. There are just= =20 > over 80 left: >=20 > abi, adjkerntz, archdep, atm1, atm2, atm3, bluetooth, bridge, cleanvar,= =20 > cleartmp, ddb, defaultroute, devfs, dhclient, dumpon, faith, gbde, geli,= =20 > geli2, gptboot, initrandom, ip6addrctl, ipfilter, ipfs, ipfw, ipmon,=20 > ipnat, ipsec, jail, kld, kldxref, local, local_unbound, localpkg,=20 > mdconfig, mdconfig2, motd, mountcritlocal, mountcritremote, mountd,=20 > natd, netif, netoptions, netwait, nfsclient, nfsd, nsswitch, ntpdate,=20 > pflog, pfsync, postrandom, power_profile, ppp, random, rctl, resolv,=20 > rfcomm_pppd_server, root, routing, rtadvd, savecore, sendmail, serial,=20 > sppp, static_arp, static_ndp, stf, syscons, tmp, ubthidhci, ugidfw, var,= =20 > virecover, zvol, fusefs, gdm, hald, netatalk, ossec-hids, pcbsdinit,=20 > pefs, wardenrc, webcamd >=20 > These fall into seven main categories: > * Things which I don't have in use anywhere and so have difficulty in= =20 > testing: ZFS, pf, faith, ATM, AppleTalk, and GELI. > * I haven't encountered a machine with diskless bootstrap since=20 > 1990. So things like root, var, and tmp are fairly tricky to test, too. > * Things which have astoundingly complex ways for saying enable=3D"YES= "=20 > flags=3D"wibble". These are going to need some heavyweight conversion=20 > procedures. > * Things which never really belonged in /etc/rc.d as part of a=20 > start-stop model at all. power_profile and serial are prime examples. > * Things which probably should be done a different way, such as=20 > pcbsdinit, cleartmp, and cleanvar. > * Things which definitely should be done a different way under nosh=20 > service management, such as mountcritlocal, kld, abi, ibcs2, and syscons. > * Things which even the BSD world is saying goodbye to, such as=20 > sendmail (now gone entirely from OpenBSD and DragonFly BSD). It sound very useful. Do you provide virtual machine images or ISOs so interested people can give it a try easily? --ogUXNSQj4OI1q3LQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQF8BAEBCgBmBQJVUJX5XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1tWE0IAL6x0tvTgW322eFpBmqnRRlN m/OWTR4P5+5GtzBxEFemwvPXJeId0MWP03NCPPpK3Nn/Mr29FOiHYpHBi0qJy8mg uJBzd4hqIY0DhSxTaw54+1pScDbl1fJ4bGfhPYKkwxvGq7t75BfKy1HtMfvWtxHr UbmGpyL4hAh9VMMZhTp5GGy49F0g9PMbNSnyG+tPKclpXT/bn/jhlYTgjz4utSwu p5S5WJV7sILaDEU+Lxiop7vBAnhqh2FmGeTVG57UHaW9deBuCScAGESpRy5EY21A weHTghhBv9ri4Tn3nmGz0y3zSGgSYpR+eM5IOfKD4TOrVqVkvOjR55l3bH3qQTs= =UZJi -----END PGP SIGNATURE----- --ogUXNSQj4OI1q3LQ-- From owner-freebsd-hackers@FreeBSD.ORG Mon May 11 12:46:06 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 AE5C78CD for ; Mon, 11 May 2015 12:46:06 +0000 (UTC) Received: from nimrev.com (nimrev.com [188.226.203.191]) (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 1C00C1CCA for ; Mon, 11 May 2015 12:46:05 +0000 (UTC) Received: from nimrev.com (localhost [127.0.0.1]); by nimrev.com (OpenSMTPD) with ESMTP id fa17ce1d; for ; Mon, 11 May 2015 14:39:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=nimrev.com; h=from :content-type:subject:message-id:date:to:mime-version; s=mail; bh=P5uSmVGQj9nvDOh6PNZjSrVs/cs=; b=kraEaCqb5sm1Mqj4seq4FlXRtB9A kxZ+KEzFqfELDJjuzuMrqJkC8gWViQ0m6x4O4aTTYAzPG1/LfsK+BV1LdxnO+Gjd eugEyCUufC4bOup5S/+FwIR8st39pxuwnZloIz8EYpu+HtiPuZ1N0JW4guG/Csep vU0MQntY7fdZsFE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=nimrev.com; h=from :content-type:subject:message-id:date:to:mime-version; q=dns; s= mail; b=DhgNWrjTMXD4aDIHlH7yME/7m1IpKUFDVwuJ+W8W4dbitAKxtQK7FUHb rjppC5ebvlNceBd3M2cNJ03W6RHBJzWsKZXNfz6XXXL7WD9TOP6vmMM550t82JtZ ws0IoxFBlOJqm+YQUaO/nsqZZNDs/IjbMI8b/i24QkMX+m1iELk= Received: by mail.nimrev.com (OpenSMTPD) with ESMTPSA id 55a6c245; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; for ; Mon, 11 May 2015 14:39:22 +0200 (CEST) From: Bas Vermin Subject: Re: EFI boot loader regression? Message-Id: Date: Mon, 11 May 2015 14:39:22 +0200 To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) X-Mailman-Approved-At: Mon, 11 May 2015 12:54:07 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Mon, 11 May 2015 12:46:06 -0000 Hi Eric, I=E2=80=99ll try you=E2=80=99re patch sometime this week, a had a quick = look at the patch and it seems it=E2=80=99ll also fix a bug I reported a = while ago: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D199729 = I=E2=80=99ll report any issues I find, Bas= From owner-freebsd-hackers@FreeBSD.ORG Mon May 11 19:56:36 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 4AADA320 for ; Mon, 11 May 2015 19:56:36 +0000 (UTC) Received: from manchester-1.man.uk.cluster.ok24.net (unknown [IPv6:2001:41c8:51:40::1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F1DF413AD for ; Mon, 11 May 2015 19:56:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=pyro.eu.org; s=05.2015; h=Content-Type:MIME-Version:Reply-To:Message-ID:Subject:Cc:To:From:Date:Resent-To:Resent-Message-ID:Resent-Date:Resent-From; bh=6AH0R4UlKtrgks6J2iLBvDajdjOkrvRpJ1TlAx0Q+Og=; b=IwksI4BPJEqPyMpFzZKutMjwsU32FuM+6Yzs3IN2oAXAFsBDeCX007qTKs4PmDK0asFoNBkjYpqPvvyAjiI5838sCvEJXp26+/Kj3D208VSDfau0y2u7jjXmShLMZ+2UBAtnl5y0MjT+NdJsNfI24fUNgzlB2jx/duhoZQ4FOiI=; X-Spam-Status: No, score=0.4 required=2.0 tests=ALL_TRUSTED, BAYES_00, DKIM_ADSP_DISCARD, FAKE_REPLY_C Received: from guisborough-1.rcc.uk.cluster.ok24.net ([217.155.40.118] helo=smtp.ok24.net) by manchester-1.man.uk.cluster.ok24.net with esmtp (Exim 4.80) (envelope-from ) id 1YrtoU-0008Fc-Il for freebsd-hackers@freebsd.org; Mon, 11 May 2015 20:56:32 +0100 Received: from kfreebsd-amd64.pyro.eu.org (smtp.ok24.net [10.1.1.1]) by smtp.ok24.net (Postfix) with ESMTPS id 7AA8310A5DB for ; Mon, 11 May 2015 20:56:30 +0100 (BST) Received: by kfreebsd-amd64.pyro.eu.org (Postfix, from userid 1000) id 6000267EC; Mon, 11 May 2015 20:56:30 +0100 (BST) Resent-From: Steven Chamberlain Resent-Date: Mon, 11 May 2015 20:56:30 +0100 Resent-Message-ID: <20150511195630.GD20721@pyro.eu.org> Resent-To: freebsd-hackers@freebsd.org Date: Mon, 11 May 2015 19:37:40 +0100 From: Steven Chamberlain To: freebsd-hackers@freebsd.org, debian-bsd@lists.debian.org Cc: Holger Levsen Subject: Re: reproducible builds of FreeBSD in a chroot on Linux Message-ID: <20150511183740.GA20721@pyro.eu.org> Reply-To: freebsd-hackers@freebsd.org, debian-bsd@lists.debian.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline 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: Mon, 11 May 2015 19:56:36 -0000 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > On 5/7/15 5:22 PM, Holger Levsen wrote: >> So now I would like to build freebsd myself, twice, and compare the resu= lts >> and show these results as in >> https://reproducible.debian.net/rb-pkg/unstable/amd64/gcc-4.9.html - and= then >> quite probably set up a jenkins job on jenkins.debian.net and do this ev= ery >> week. Julian Elischer wrote: > Cross compiling FreeBSD from another platform has been a "gee the=20 > might be nice" goal for some years > [...] > If you really wanted to you could look at he kFreeBSD project and=20 > maybe they have a way to do stuff.. That we do! We package various FreeBSD stuff for Debian GNU/kFreeBSD and then build some of it reproducibly already. We already have in Debian - on kfreebsd and linux - the necessary toolchain packages such as clang-3.4, bmake, freebsd-mk, freebsd-buildutils and particular versions of byacc and flex. We prepend "/usr/lib/freebsd:" to $PATH in order to use these: https://anonscm.debian.org/viewvc/glibc-bsd/trunk/kfreebsd-10/debian/rules?= view=3Dmarkup#l46 We were actually able to build our package of the FreeBSD kernel on GNU/Linux, and the binary would match what we built on GNU/kFreeBSD. (Which I think is the ultimate in securing against attacks on the build/development systems). I haven't tried building much else from FreeBSD - on Linux, or on GNU/kFreeBSD - using only FreeBSD's original build system. In our packaging we tend to make changes as necessary to get individual bits to build. I understand wanting to do this on GNU/Linux, but if that's too difficult, it may be easier trying this in a chroot on GNU/kFreeBSD first. You can even run a Debian GNU/kFreeBSD host system with native FreeBSD binaries inside a chroot or jail, potentially a whole native build system inside of it. In any case, I'd like to someday see a GNU/kFreeBSD machine set up as a http://jenkins.debian.net slave, doing rebuilds and alerting us if any packages in sid are FTBFS, as well as other tests. > There may also be a better mailing list for this... Discussions are very welcome on debian-bsd@lists.debian.org, although we are rather busy this week finalising a jessie-kfreebsd release. Regards, --=20 Steven Chamberlain steven@pyro.eu.org --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/kFreeBSD) iQEcBAEBCAAGBQJVUPbzAAoJELrpzbaMAu5TJXMIAMVSYY9RrtrNQCedVrWMO5Ml vDRHjTSUncZutVSnLaYiO/oWAQrGjf1aMN7e2XFQwdITCa2TvBrFJN2JHJyXDt1D XBKziJVLqrk4x1Ds9/piRYxaXZezk2lNU4LOGvppjwURd4LV1EC2lClAJu7IzGEK lNgknCPc0Oq/uedzpbybggo6nZKO6PrdtF6iSsQ9zSEbTVGVPg6emgUKIbe+qxW1 fVMSZgd6SfYDpsVyTFotOmil3UwbrcFTfKl+OL5VRLrKndmhfROZp+ohx5A+hyqe shthpNRAH6cct2Jt9xiwNuHbOmzrSgEZ7RobyFOOxZIXxMd8JRffd6xjQDZ8Nl0= =pbtR -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- From owner-freebsd-hackers@FreeBSD.ORG Mon May 11 21:08:00 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 66403CA7 for ; Mon, 11 May 2015 21:08:00 +0000 (UTC) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (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 30CD11C5E for ; Mon, 11 May 2015 21:08:00 +0000 (UTC) Received: by igbpi8 with SMTP id pi8so82823756igb.1 for ; Mon, 11 May 2015 14:07:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=bHFUx564oZf+n+bT8ZyCz+0HOVjdHAycfjBI9GYdemg=; b=bHz4SKlkHZEGCw6I8zT4B/AIArYpxA3plxl9ZvDbEMKK9Hr+4E1TI4P2387DnYmyfq nydO3C7THSPThQWzrGJEHwK0kvnhohaoHBFbhPWEZbLvWvCWn/csDdssS6FFZHa+bCpC nweccG7ILpS8ChD7NX56OgkWkp9FtOTgUsdmeef0TxWNYbyB9NSakmOkilhhHMj6Z4Ip aNplmsoJsZs9tx7PTELdrLXAZ6uOtLqfTm+36I57MjYrdHJSBfKD6mrA5CvJrpoN3un8 syz4Kt+lZnRdTnKqhRx9RzbNOa0OgRCXRArsa/iqkvGyv9OTfs9F+D8dxAdPOrotDADE p4nA== X-Received: by 10.50.143.33 with SMTP id sb1mr15563863igb.33.1431378479643; Mon, 11 May 2015 14:07:59 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.48.3 with HTTP; Mon, 11 May 2015 14:07:38 -0700 (PDT) In-Reply-To: <20150511183740.GA20721@pyro.eu.org> References: <20150511183740.GA20721@pyro.eu.org> From: Ed Maste Date: Mon, 11 May 2015 17:07:38 -0400 X-Google-Sender-Auth: RgTPc7KYMeqNGRFSVBZ2v0c65fk Message-ID: Subject: Re: reproducible builds of FreeBSD in a chroot on Linux To: "freebsd-hackers@freebsd.org" , "debian-bsd@lists.debian.org" Cc: Holger Levsen 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: Mon, 11 May 2015 21:08:00 -0000 On 11 May 2015 at 14:37, Steven Chamberlain wrote: > > We were actually able to build our package of the FreeBSD kernel on > GNU/Linux, and the binary would match what we built on GNU/kFreeBSD. > (Which I think is the ultimate in securing against attacks on the > build/development systems). Ideally we'd be able to produce binary identical kernel on FreeBSD as well, although that might be more difficult depending on how you've set up the kFreeBSD build infrastructure. In any case, it's still a good diversity story. > I understand wanting to do this on GNU/Linux, but if that's too > difficult, it may be easier trying this in a chroot on GNU/kFreeBSD > first. You can even run a Debian GNU/kFreeBSD host system with > native FreeBSD binaries inside a chroot or jail, potentially a whole > native build system inside of it. A lot of this depends on the motivation for pursuing reproducible FreeBSD builds. If it's to help FreeBSD overall with reproducible builds, then using the FreeBSD build infrastructure on a FreeBSD kernel (e.g., a FreeBSD jail on Debian kFreeBSD) is an important part of the story. If it's specifically for reproducible kernel builds for kFreeBSD then the FreeBSD build infrastructure isn't relevant. From owner-freebsd-hackers@FreeBSD.ORG Tue May 12 18:29:38 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 44848252 for ; Tue, 12 May 2015 18:29:38 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (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 D25411389 for ; Tue, 12 May 2015 18:29:37 +0000 (UTC) Received: by wicmc15 with SMTP id mc15so60705400wic.1 for ; Tue, 12 May 2015 11:29:36 -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=nDyNlUyLwxOF9wo7bmYKlPYMgmwzJ0BW0e/2of/NKy8=; b=CZv9W2GqyXfEzm9sX+m+3PqIwzIFIQnRQDA5HJAUCsSeYB7/fggGBWwTsO0hBiatyy LSrU2ZoQc6z8oxWUw3InCw7XJ/U5b/P3bXF4ijLsCLZ1L3V9tlZlZPar5Tx0ctVM1aWC kvv6vZhgPBfjekTDO3bISmTTkbz7JTl9OGOx5BvHsEbeUtem6fO4sCc9ogvLYcaITuis SGmy52Gp2zoBwSzHKwi0Y+UoM/4k5T01sb+ksoeSEaK3NUHb21RFig7xBFJee03iVG71 o8OsPjOqcnVQg3aR9Gc92BYvweRq1+2gCz0Gir5cYhNNA9qB0w10iAQdHzMWIerLmyHb jEqg== MIME-Version: 1.0 X-Received: by 10.180.186.5 with SMTP id fg5mr7534030wic.60.1431455376412; Tue, 12 May 2015 11:29:36 -0700 (PDT) Received: by 10.194.38.104 with HTTP; Tue, 12 May 2015 11:29:36 -0700 (PDT) In-Reply-To: <554F9DBB.6020202@metricspace.net> References: <553A8CE4.9030204@metricspace.net> <554F9DBB.6020202@metricspace.net> Date: Tue, 12 May 2015 21:29:36 +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: Tue, 12 May 2015 18:29:38 -0000 On Sun, May 10, 2015 at 9:04 PM, Eric McCorkle wrote: > Sorry for the delay in posting this. Attached is my latest work on the > boot block. It includes numerous debugging messages. You should be > able to tell if it gets all the way through the first stage, or where it > stops if it doesn't. > > > > For everyone else, these are the outstanding issues I still need to address: > > * I'm currently (ab)using the UEFI pool allocator as a malloc-like > mechanism. > > * The partition scan completely ignores the GPT labels, and tries to > probe every single partition for every single filesystem. > > * Need to work out argv-style options for the UEFI loader, and have the > boot block construct and pass in an argv array. > > Any other comments are welcome. > > On 04/24/2015 02: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. >> >> 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 Hello, I'm test this patch with r281381 build sucess. Now work boot priority Legacy first, with UEFI first loader not found. There diagnostic messages, but unfortunately, they take more than two screens and almost unreal to see even at 50fps video recording After https://svnweb.freebsd.org/base/head/sys/boot/efi/boot1/Makefile?r1=282474&r2=282727 seems to need additional changes, I corrected reloc.c to self_reloc.c but the image obtained is not loaded, though and with diagnostic messages. From owner-freebsd-hackers@FreeBSD.ORG Wed May 13 07:03:31 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 14CFAC0; Wed, 13 May 2015 07:03:31 +0000 (UTC) Received: from vps.markoturk.info (vps.markoturk.info [95.154.208.14]) by mx1.freebsd.org (Postfix) with ESMTP id D6D82178B; Wed, 13 May 2015 07:03:30 +0000 (UTC) Received: by vps.markoturk.info (Postfix, from userid 1001) id D21C927368; Wed, 13 May 2015 09:02:59 +0200 (CEST) Date: Wed, 13 May 2015 09:02:59 +0200 From: Marko Turk To: freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org Subject: vt_core.c vt_is_cursor_in_area different behavior after r282823 Message-ID: <20150513070259.GA27935@vps.markoturk.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Wed, 13 May 2015 11:34:01 +0000 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, 13 May 2015 07:03:31 -0000 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, after r282823, new vt_is_cursor_in_area is, in some cases, returning different values than the old function. For example: If (my + vd->vd_mcursor->height) is equal to (area->tr_begin.tp_row), old function will return 1 and new function will return 0. Is this intended behavior or is it a bug? BR, Marko --W/nzBZO5zC0uMSeA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVUvcjAAoJEDcRe7P/w1sjqFIQALhiNM4t32+j7wNKYFU4D33N liVrPTghCp9ZJI/fnoNeg6SkIv/5BatQY1ZlPpaZlwRmix/a6+qYablFuTt7+ibR LE0m9xmN9YA0oTRJZ4N1aE0S2R27HseBB1s57v6FgM8l3Tr3AuxHCoIJ/uSev1vW elwPY1Nh1VSkF6G4GilKRL50xxWait6wyV94siuP1181mvXon8weWwZGDF2l1l8W n7kJfxuQOPx4K5prbMJA8CtlKpZhFXwNL+F5Nvn5DIkfpOFNuc5kwBCuNDdCiPHF cMUBFMJN++6Ie1F+26+wTOL6oUEH00Yj4szL4s112NSCFERoaWYXbP8coY3lnZi3 92OimkPfCUxKNFPBQe+nZBdfpPUcpcsJ76yN1S5YmKbg/vsdmVq7y6EyKdb5W0tL j/Sk1jWfuLequiNRgYmJOw3b52w0REYacpISKshbv+FJCQBjFOZiNgGhuxaAXDXu clmlD7/vikLqWKSiQvIB1ptT8jlzpNGkpazjq1fp7wmfVkEZRKZM5O2YWeLojKEx Vih5pltvR7IFwThhxSD+K+8YvXjvWNKHdOv9myWjrMHoTKXAr/GBdvsUD6zTTKuC CpxKrH870dRzthH3vPkMqyxRa+YmyLhDRinygYHZCoMrVplVXFmfTAOqSaEQlx+Y TKtbBbNEII8JOvxXTLbF =fdow -----END PGP SIGNATURE----- --W/nzBZO5zC0uMSeA-- From owner-freebsd-hackers@FreeBSD.ORG Wed May 13 15:00:29 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 048B8BB2; Wed, 13 May 2015 15:00:29 +0000 (UTC) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::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 C3F8D162E; Wed, 13 May 2015 15:00:28 +0000 (UTC) Received: by igbsb11 with SMTP id sb11so47263072igb.0; Wed, 13 May 2015 08:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=1w7up1k5fXpJDHhqYuIG4cq6l26gTy4t2wCvP/Nb0h4=; b=uh02GinXcflYh6wIbRMoYIA5fZQjoOWTam8l+CF6Y0XF4/jSU4urIwvLC9sNSF+K+X M37E0lFIiAE+aWkYnR/4PbXYsirscQbv8h7IpiK1Kq4W+bVXXu6gp1xQe1ccNPLc5EMC k5n63QnJoO46rm0yj2mlG+JU+wDGnzsrm8dA1U4m2+GZvJnGNU1E78UEyQOtndzRiVLK yLAo7oG1yM4CTduqTsHgMnCCaQNG1rBDEA3DfkuBmDSJOI4FWjNM5sFnmBfMerNtqBA6 kdBY59QNgFAj/hIXxEI6Ny7Ax9kgB1AbkFO1GrPuYzKgHrERlyfXJCYFA3eQaUvXDdhC uktg== X-Received: by 10.42.20.197 with SMTP id h5mr9456566icb.22.1431529227992; Wed, 13 May 2015 08:00:27 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.48.3 with HTTP; Wed, 13 May 2015 08:00:07 -0700 (PDT) In-Reply-To: <20150513070259.GA27935@vps.markoturk.info> References: <20150513070259.GA27935@vps.markoturk.info> From: Ed Maste Date: Wed, 13 May 2015 11:00:07 -0400 X-Google-Sender-Auth: 38bah26lu6Q_5DPZPT1V6rF_cmQ Message-ID: Subject: Re: vt_core.c vt_is_cursor_in_area different behavior after r282823 To: Marko Turk Cc: freebsd-stable stable , "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: Wed, 13 May 2015 15:00:29 -0000 On 13 May 2015 at 03:02, Marko Turk wrote: > Hi, > > after r282823, new vt_is_cursor_in_area is, in some cases, returning > different values than the old function. > > For example: > If (my + vd->vd_mcursor->height) is equal to (area->tr_begin.tp_row), > old function will return 1 and new function will return 0. > > Is this intended behavior or is it a bug? Thanks for the detailed look at the change! It's intentional -- when they're equal the cursor rectangle and display area rectangle border each other, but do not actually overlap. It doesn't hurt to return 1 in this case, it just results in some unnecessary drawing. From owner-freebsd-hackers@FreeBSD.ORG Thu May 14 10:23:09 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 59B3581C for ; Thu, 14 May 2015 10:23:09 +0000 (UTC) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::103]) by mx1.freebsd.org (Postfix) with ESMTP id 310731E63 for ; Thu, 14 May 2015 10:23:09 +0000 (UTC) Received: from [172.16.1.130] (unknown [172.16.1.130]) (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 9D2CB2FBBE for ; Thu, 14 May 2015 10:23:02 +0000 (UTC) Message-ID: <55547786.40000@metricspace.net> Date: Thu, 14 May 2015 06:23:02 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: EFI boot loader regression? References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SuRS3MEiwGmQS9P8IlNjcR8lW9SK9wiNu" 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, 14 May 2015 10:23:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SuRS3MEiwGmQS9P8IlNjcR8lW9SK9wiNu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Note that I still want to have it look at the partition type UUIDs. Right now, it basically probes every partition directly. On 05/11/2015 08:39 AM, Bas Vermin wrote: > Hi Eric, >=20 > I=E2=80=99ll try you=E2=80=99re patch sometime this week, a had a quick= look at the patch and it seems it=E2=80=99ll also fix a bug I reported a= while ago: >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D199729 >=20 > I=E2=80=99ll report any issues I find, >=20 > Bas > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 --SuRS3MEiwGmQS9P8IlNjcR8lW9SK9wiNu 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 iQIcBAEBAgAGBQJVVHeMAAoJEEGB2s+NNG0FcxwP/3PQ6cynA421UVvQjRcNrgfO oDR+ZY0Tzn7BoRljQfft5Ak8wGnVkcxkSNOkyKMuvGanLasKY0fHGTAx94TwpKRZ J9aCbJ9aO+a9PvwMpWxHgRmvMqdmMYC4+ntxZFYw1K/78QRdPrSW1aFYMcRhF8Xm cEnE3AbuF9rd0apbHR2jcIMAMrdr4U0yNJ0gYSsgg9RV1riFY7edje5w8cgYLHmK hIj+aH6T2KSB255QS4R3QXGp68QGwv5WFwCTcbOxIJSqJlSwfQTWsF2VZYWE1uO/ yeDkJBNE4Dg3atzguC3F3CDLe6yQ1Mud6VnDPp0ql/dP7leHoe797qw4Uy4spRJF nlJ++njA+Yr+wZ0/w35XyEWKQcGi6zLVP3uVq8MHpdxGpMaOe8qMIxzAmUxR8VpK F3TZn/I2y9iWMlM496XaaIrJTP9JgG9/e3w7omrUST/HnkthDOgn1tOJlQfeGgB3 xxtFgC2N1XZDb63787+JpSmNxvh/r96DwM0BYnCKajjhjCOGLxTqbS+zDPnUdICa WG2vDaFphNhBJ3yhAlZNzg5lAw8JkZ1BnztEbP362BcKU+Vvj5FkaXAPcOALU/BZ kl0RWW6/pqKiiSuEpGSh8XzbkOXOjSqkRlQOWcaIJ+JLRkIePzYpQnZSiELblG1V L8Pk5jt8lhb3DEsOgNjI =a1MU -----END PGP SIGNATURE----- --SuRS3MEiwGmQS9P8IlNjcR8lW9SK9wiNu-- From owner-freebsd-hackers@FreeBSD.ORG Thu May 14 15:48:08 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 7CDA5801 for ; Thu, 14 May 2015 15:48:08 +0000 (UTC) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::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 45C391C4B for ; Thu, 14 May 2015 15:48:08 +0000 (UTC) Received: by igblo3 with SMTP id lo3so14333569igb.1 for ; Thu, 14 May 2015 08:48:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=NVVOlrIZWIIf5KesP2hwnX2HRwkPjXMneiaJEkKFAgM=; b=hNap5UwJBmiR4wIJbUy8bRuTSxEPKxhVtK/oARrkhnQ114SQIZjK9X5QdxCFzWH3yT wXxNPBPShgmzigBwVa/D2biLabDtmBiMEb+uDOPhtl6kNRizI6Qh/O5Q8R9Jou5/vdjF jl/c7wrnFtSl8yzslY7/QrzPYvxghPAME+hWRNB0iYzVuzC/rPgrUO/+eH128AtT6Gss 7nRAGP+UB3+20p/LUM/kNEzBjXR7QbFY4E9vApxe9DEgzWVgvAxpLu8qFmjaIzpAnU9x HLJWa/d49jSnQk5WFJOcAttZ1Jj2DQSu/6FqFzaimvkCHEV1sA+IUdntwVA1yCy+bwMj DF/g== X-Received: by 10.43.96.10 with SMTP id ce10mr9093539icc.59.1431618487624; Thu, 14 May 2015 08:48:07 -0700 (PDT) Received: from [10.10.1.5] ([192.252.130.194]) by mx.google.com with ESMTPSA id r39sm16728737ioe.25.2015.05.14.08.48.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 May 2015 08:48:07 -0700 (PDT) Message-ID: <5554C3B0.4030102@gmail.com> Date: Thu, 14 May 2015 11:48:00 -0400 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Intel System-on-Chip (SoC) E3800 Atom UART support Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 14 May 2015 16:49:19 +0000 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, 14 May 2015 15:48:08 -0000 Hi Hackers, Anyone got a uart driver going for one of those in his back pocket? Here is the back story: As Intel turns the wheel of technological evolution, embedded customers are dragged along, often kicking and screaming. The ADLE3800PC incorporates the Intel Atom® E3800 Series SoC. This is the smallest Atom package that Intel has released. It allows for better use of space on a PCB since the chipset features, CPU and GPU all reside within a single BGA. It boasts impressive performance numbers comparable to Intel First Generation Core® products. With this massive integration of functions into a single chip, some features are scaled back or eliminated in the name of forward-thinking high speed interface technologies. The E3800 Series does away with LPT, Keyboard/ Mouse, but retains features like GPIO and RS232 COM ports. The RS232 COM ports are supported with a reduced signal and instruction set designed to leave just the basics in place. The reduced signal set is as follows: Supported Interface Signals: Tx Rx CTS RTS The command instruction set is also reduced. The following commands are not supported by the Windows 7/8 HS-UART Driver: IOCTL_SERIAL_SET_WAIT_MASK IOCTL_SERIAL_GET_WAIT_MASK IOCTL_SERIAL_WAIT_ON_MASK IOCTL_SERIAL_XOFF_COUNTER IOCTL_SERIAL_LSRMST_INSERT IOCTL_SERIAL_SET_BREAK_ON IOCTL_SERIAL_SET_BREAK_OFF Provided that an application does not require a full set of modem control signals, and none of the commands above commands are used in existing applications. The COM ports will work successfully. Please consult the “ISG_BYT-I_HSUART_Driver_Release_Note” included with the driver download for detailed information about the HSUART driver. Thanks! Karim. From owner-freebsd-hackers@FreeBSD.ORG Thu May 14 21:11:35 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 7D15F831 for ; Thu, 14 May 2015 21:11:35 +0000 (UTC) Received: from know-smtprelay-omc-10.server.virginmedia.net (know-smtprelay-omc-10.server.virginmedia.net [80.0.253.74]) by mx1.freebsd.org (Postfix) with ESMTP id F07A91369 for ; Thu, 14 May 2015 21:11:34 +0000 (UTC) Received: from [192.168.1.100] ([86.20.122.200]) by know-smtprelay-10-imp with bizsmtp id TxAQ1q0034KXVwe01xAQwA; Thu, 14 May 2015 22:10:24 +0100 X-Originating-IP: [86.20.122.200] X-Spam: 0 X-Authority: v=2.1 cv=AYg/HhnG c=1 sm=1 tr=0 a=WByauD8lJrWvBFCNrxRoEQ==:117 a=WByauD8lJrWvBFCNrxRoEQ==:17 a=9cW_t1CCXrUA:10 a=LdKPt8bmWjYA:10 a=IkcTkHD0fZMA:10 a=NLZqzBF-AAAA:8 a=KlpANiOQP4cm9LJGYPoA:9 a=QEXdDO2ut3YA:10 a=42TJWvc3JAEA:10 a=NJfp1ZnvUGcA:10 Message-ID: <55550F38.1070203@NTLWorld.com> Date: Thu, 14 May 2015 22:10:16 +0100 From: Jonathan de Boyne Pollard User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 CC: FreeBSD Hackers Subject: Re: nosh version 1.14 References: <54430B41.3010301@NTLWorld.com> <54B86FD5.3090203@NTLWorld.com> <554E53EF.4080600@NTLWorld.com> <554E5EEA.7020901@NTLWorld.com> <554E7EB6.3000200@NTLWorld.com> <20150511114354.GK53149@e-new.0x20.net> In-Reply-To: <20150511114354.GK53149@e-new.0x20.net> 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: Thu, 14 May 2015 21:11:35 -0000 Lars Engels: > It sound very useful. Do you provide virtual machine images or ISOs so > interested people can give it a try easily? I'm not sure that I agree with that use of the adverb "easily". (-: nosh isn't a whole operating system. It's a toolset, to form part of, or to use on, an operating system. At the moment, you install it in the fashion that the FreeBSD Handbook calls "typical". There's a .tar.bz2 source archive. It unpacks into a self-contained build tree, where the binaries are built. * http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/source-package.html Installing is a little hairy, still. "package/export /usr/local" does most of it on my system, but there are still some manual steps that follow that, especially in the separate-/usr-volume case. The Debian Linux side of things is a little ahead in this regard. One of the reasons that I mentioned that the packaging was a "big deal" on the Linux side in an earlier message was that in this version (and even more so in version 1.15 that I have under development) I've finally got maintainer scripts doing the automatic native nosh preset/disable of service bundles to such an extent that an entire system almost installs from packages. * http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/debian-binary-packages.html I hope to catch up with that on the BSD side. But I need to learn BSD packaging first. (-: And as I said, there's that little matter of 80-some things that need dealing with. That said, if you need pointers on what to do after "package/compile && sudo package/export /usr/local" here is a good place to ask. You can stop after "package/compile" and view "guide/index.html" in your favourite WWW browser and read the man pages located under "manual/". From owner-freebsd-hackers@FreeBSD.ORG Fri May 15 15:27:20 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 2066B847 for ; Fri, 15 May 2015 15:27:20 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 02A531A7C for ; Fri, 15 May 2015 15:27:19 +0000 (UTC) Received: from [192.168.200.214] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 648AB193656 for ; Fri, 15 May 2015 15:27:18 +0000 (UTC) Message-ID: <55561055.9020902@ignoranthack.me> Date: Fri, 15 May 2015 08:27:17 -0700 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: How to get anything useful out of kgdb? References: <554E41EE.2010202@ignoranthack.me> In-Reply-To: <554E41EE.2010202@ignoranthack.me> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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, 15 May 2015 15:27:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/09/15 10:20, Sean Bruno wrote: > > tl;dr What are the kernel config options to get good output of > kgdb? > > > I'm trying to get the ability to debug and display internal > variables, as one does, with kgdb. I'm *must* be doing this wrong > as I cannot get any useful output from accessing variables that > were JUST accessed in order to invoke a panic() that I have > inserted. This is a GENERIC kernel without INVARIANTS and without > WITNESS: > > https://people.freebsd.org/~sbruno/wtf_kgdb.txt > > I seem to have debug enabled and am able to browse source, but I > obviously haven't compiled correctly as things are optimized out. > > sean > A little bit of progress and learning on my side, so that's good. I'll be patching gdb with a couple of 10-year old upstream commits later today to squash some type missing errors, "#0 doadump (textdump=Unhandled dwarf expression opcode 0x93". Review is here https://reviews.freebsd.org/D2534 sean -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJVVhBTXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5k9MQH/ioTLENq1AZRDsOQaRR8U4lF 5iD6cWYgfqkUrLr5VZv6OyVK6zMbf4Jk/PClN7c7m4rVp7tC2kGeiitbaRVOaGxU nb2zJ7eTs6uufCqd9wS3PWjwZlKhggAE9OplPIckU2oy4vlI7tr8DWuh5Mlr/el0 qJ2Bmnzp0vHPqniyCEsxgd/7xm8KjzN6CJASzIdgEd2bVMXbtAHG1XQ6lry+8NJ/ dpwrs9KqHc4xvR7frQzaek2soDIrdOEKV9f4e+PCBav1MbZKoVzYARR3+8LjHd7W k0oNhl8FqqqUYnwS+iBzc/08K6VbIpkzEJzxGXDUsSp++9e8x9umE7FwMdKY2lo= =4LZI -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Fri May 15 15:50:55 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 E0B10492; Fri, 15 May 2015 15:50:55 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BD4741D87; Fri, 15 May 2015 15:50:55 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CC7BAB939; Fri, 15 May 2015 11:50:54 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org, sbruno@freebsd.org Subject: Re: How to get anything useful out of kgdb? Date: Fri, 15 May 2015 11:50:38 -0400 Message-ID: <2063489.pgabuk9nPJ@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.1-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <554E41EE.2010202@ignoranthack.me> References: <554E41EE.2010202@ignoranthack.me> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 15 May 2015 11:50:54 -0400 (EDT) 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, 15 May 2015 15:50:56 -0000 On Saturday, May 09, 2015 10:20:46 AM Sean Bruno wrote: > tl;dr What are the kernel config options to get good output of kgdb? > > > I'm trying to get the ability to debug and display internal variables, > as one does, with kgdb. I'm *must* be doing this wrong as I cannot get > any useful output from accessing variables that were JUST accessed in > order to invoke a panic() that I have inserted. This is a GENERIC > kernel without INVARIANTS and without WITNESS: > > https://people.freebsd.org/~sbruno/wtf_kgdb.txt > > I seem to have debug enabled and am able to browse source, but I > obviously haven't compiled correctly as things are optimized out. 1) gdb7 does a better job. I hope to get the kgdb patches into the port soon. If you are feeling brave: # add texinfo for HEAD % pkg install gmake bison % git clone https://github.com/bsdjhb/gdb.git % cd gdb % git checkout freebsd-7.9.0-kgdb % fetch http://people.freebsd.org/~jhb/gdb/build % sh ./build % cd obj # or obj.i386 for i386 % gmake Then use /path/to/git/gdb/obj/gdb/kgdb 2) Even with gdb7 it can't figure out variables that it should figure out sometimes. Other options are either to find the variable in a higher frame (e.g. if it is something like 'td' or a driver softc) or to start poking around in the dissassembly to work out which register it is in (or which register points to a structure that contains it) and go from there. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri May 15 16:00:05 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 BF56993F; Fri, 15 May 2015 16:00:05 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A10BE1E25; Fri, 15 May 2015 16:00:05 +0000 (UTC) Received: from [192.168.200.214] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 66419193656; Fri, 15 May 2015 16:00:04 +0000 (UTC) Message-ID: <55561803.9050102@ignoranthack.me> Date: Fri, 15 May 2015 09:00:03 -0700 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: John Baldwin , freebsd-hackers@freebsd.org Subject: Re: How to get anything useful out of kgdb? References: <554E41EE.2010202@ignoranthack.me> <2063489.pgabuk9nPJ@ralph.baldwin.cx> In-Reply-To: <2063489.pgabuk9nPJ@ralph.baldwin.cx> 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, 15 May 2015 16:00:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/15/15 08:50, John Baldwin wrote: > On Saturday, May 09, 2015 10:20:46 AM Sean Bruno wrote: >> tl;dr What are the kernel config options to get good output of >> kgdb? >> >> >> I'm trying to get the ability to debug and display internal >> variables, as one does, with kgdb. I'm *must* be doing this >> wrong as I cannot get any useful output from accessing variables >> that were JUST accessed in order to invoke a panic() that I have >> inserted. This is a GENERIC kernel without INVARIANTS and >> without WITNESS: >> >> https://people.freebsd.org/~sbruno/wtf_kgdb.txt >> >> I seem to have debug enabled and am able to browse source, but I >> obviously haven't compiled correctly as things are optimized >> out. > > 1) gdb7 does a better job. I hope to get the kgdb patches into > the port soon. If you are feeling brave: > > # add texinfo for HEAD % pkg install gmake bison > > % git clone https://github.com/bsdjhb/gdb.git % cd gdb % git > checkout freebsd-7.9.0-kgdb % fetch > http://people.freebsd.org/~jhb/gdb/build % sh ./build % cd obj # > or obj.i386 for i386 % gmake > > Then use /path/to/git/gdb/obj/gdb/kgdb > > 2) Even with gdb7 it can't figure out variables that it should > figure out sometimes. Other options are either to find the > variable in a higher frame (e.g. if it is something like 'td' or a > driver softc) or to start poking around in the dissassembly to work > out which register it is in (or which register points to a > structure that contains it) and go from there. > So one non-obvious thing that I'd like an explanation about: If I manually break to the debbugger and cause a dump (doadump), how do I poke around in the crash dump later on to find a thread that I'm looking for, e.g. I want to poke at various bits inside em(4). sean -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJVVhgAXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kTR0IANHGeY0qH9wj8OKBUcAV/anR 8fpZMd4KxBIxy+2K2/TsAHWbXYDS+q/0LBNLI919ArDmPdR00iJjnMOCmBc4gCJr 53943f1x5+qKgtVVN9rQdKfHl6SilG2EeVI79HJasVNaghiV7o5vseu8p6FtQgai ytJPh5eWwBbNkYr0h9aNlXnODiqaZWLfwzSha/1VIU9nuhb1/zDh6O/MyvmuOF1B zu9kaNRyLSQBSe/YIK3D5pKiAotM4D/AQIkylc+Pan1G2JKIbqiaEqpETnjNQTSM BbVv7ccTEQXb+jow09z4JsAXyphVU7Jn+XdB7xnw0cUNkuUWMPy7x98dOJ10rM0= =jntV -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Fri May 15 16:08:12 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 77C4BC6D; Fri, 15 May 2015 16:08:12 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 524171F38; Fri, 15 May 2015 16:08:12 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 42066B93C; Fri, 15 May 2015 12:08:11 -0400 (EDT) From: John Baldwin To: sbruno@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: Re: How to get anything useful out of kgdb? Date: Fri, 15 May 2015 12:08:09 -0400 Message-ID: <19618854.y3EeXVtCGX@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.1-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <55561803.9050102@ignoranthack.me> References: <554E41EE.2010202@ignoranthack.me> <2063489.pgabuk9nPJ@ralph.baldwin.cx> <55561803.9050102@ignoranthack.me> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 15 May 2015 12:08:11 -0400 (EDT) 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, 15 May 2015 16:08:12 -0000 On Friday, May 15, 2015 09:00:03 AM Sean Bruno wrote: > On 05/15/15 08:50, John Baldwin wrote: > > On Saturday, May 09, 2015 10:20:46 AM Sean Bruno wrote: > >> tl;dr What are the kernel config options to get good output of > >> kgdb? > >> > >> > >> I'm trying to get the ability to debug and display internal > >> variables, as one does, with kgdb. I'm *must* be doing this > >> wrong as I cannot get any useful output from accessing variables > >> that were JUST accessed in order to invoke a panic() that I have > >> inserted. This is a GENERIC kernel without INVARIANTS and > >> without WITNESS: > >> > >> https://people.freebsd.org/~sbruno/wtf_kgdb.txt > >> > >> I seem to have debug enabled and am able to browse source, but I > >> obviously haven't compiled correctly as things are optimized > >> out. > > > > 1) gdb7 does a better job. I hope to get the kgdb patches into > > the port soon. If you are feeling brave: > > > > # add texinfo for HEAD % pkg install gmake bison > > > > % git clone https://github.com/bsdjhb/gdb.git % cd gdb % git > > checkout freebsd-7.9.0-kgdb % fetch > > http://people.freebsd.org/~jhb/gdb/build % sh ./build % cd obj # > > or obj.i386 for i386 % gmake > > > > Then use /path/to/git/gdb/obj/gdb/kgdb > > > > 2) Even with gdb7 it can't figure out variables that it should > > figure out sometimes. Other options are either to find the > > variable in a higher frame (e.g. if it is something like 'td' or a > > driver softc) or to start poking around in the dissassembly to work > > out which register it is in (or which register points to a > > structure that contains it) and go from there. > > > > So one non-obvious thing that I'd like an explanation about: If I > manually break to the debbugger and cause a dump (doadump), how do I > poke around in the crash dump later on to find a thread that I'm > looking for, e.g. I want to poke at various bits inside em(4). The current thread in a crashdump is the one that calls dump or panic. If you want to find a different thread you have a couple of options. First, kgdb exposes each kernel thread as a thread to gdb. You can switch to individual kernel threads by using 'tid N' (where N is td_tid) or 'proc N' (where N is a pid). You can also use 'thread N', but that requires using gdb's internal thread number which has no relation to tids or pids. There are several ways to enumerate the list of threads in a core: 1) You can use 'info threads' in kgdb to get a list of threads. 2) You can run 'ps' against the crashdump using -N and -M to get the tid and pid values (at least until someone like glebius@ goes on more of an anti-libkvm tirade and removes crashdump support from ps). crashinfo runs ps by default, so if you have that enabled you can look in core.txt.N to get the list of tids / pids. 3) You can grab my gdb scripts at ~jhb/gdb/ and source 'gdb6'. That gives you a 'ps' command kind of like DDB's ps. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri May 15 16:23:56 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 8C9A2F1; Fri, 15 May 2015 16:23:56 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6DAFC1181; Fri, 15 May 2015 16:23:55 +0000 (UTC) Received: from [192.168.200.214] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 14C61193656; Fri, 15 May 2015 16:23:55 +0000 (UTC) Message-ID: <55561D9A.30309@ignoranthack.me> Date: Fri, 15 May 2015 09:23:54 -0700 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: John Baldwin CC: freebsd-hackers@freebsd.org Subject: Re: How to get anything useful out of kgdb? References: <554E41EE.2010202@ignoranthack.me> <2063489.pgabuk9nPJ@ralph.baldwin.cx> <55561803.9050102@ignoranthack.me> <19618854.y3EeXVtCGX@ralph.baldwin.cx> In-Reply-To: <19618854.y3EeXVtCGX@ralph.baldwin.cx> 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, 15 May 2015 16:23:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/15/15 09:08, John Baldwin wrote: > On Friday, May 15, 2015 09:00:03 AM Sean Bruno wrote: >> On 05/15/15 08:50, John Baldwin wrote: >>> On Saturday, May 09, 2015 10:20:46 AM Sean Bruno wrote: >>>> tl;dr What are the kernel config options to get good output >>>> of kgdb? >>>> >>>> >>>> I'm trying to get the ability to debug and display internal >>>> variables, as one does, with kgdb. I'm *must* be doing this >>>> wrong as I cannot get any useful output from accessing >>>> variables that were JUST accessed in order to invoke a >>>> panic() that I have inserted. This is a GENERIC kernel >>>> without INVARIANTS and without WITNESS: >>>> >>>> https://people.freebsd.org/~sbruno/wtf_kgdb.txt >>>> >>>> I seem to have debug enabled and am able to browse source, >>>> but I obviously haven't compiled correctly as things are >>>> optimized out. >>> >>> 1) gdb7 does a better job. I hope to get the kgdb patches >>> into the port soon. If you are feeling brave: >>> >>> # add texinfo for HEAD % pkg install gmake bison >>> >>> % git clone https://github.com/bsdjhb/gdb.git % cd gdb % git >>> checkout freebsd-7.9.0-kgdb % fetch >>> http://people.freebsd.org/~jhb/gdb/build % sh ./build % cd obj >>> # or obj.i386 for i386 % gmake >>> >>> Then use /path/to/git/gdb/obj/gdb/kgdb >>> >>> 2) Even with gdb7 it can't figure out variables that it should >>> figure out sometimes. Other options are either to find the >>> variable in a higher frame (e.g. if it is something like 'td' >>> or a driver softc) or to start poking around in the >>> dissassembly to work out which register it is in (or which >>> register points to a structure that contains it) and go from >>> there. >>> >> >> So one non-obvious thing that I'd like an explanation about: If >> I manually break to the debbugger and cause a dump (doadump), how >> do I poke around in the crash dump later on to find a thread that >> I'm looking for, e.g. I want to poke at various bits inside >> em(4). > > The current thread in a crashdump is the one that calls dump or > panic. If you want to find a different thread you have a couple of > options. First, kgdb exposes each kernel thread as a thread to gdb. > You can switch to individual kernel threads by using 'tid N' (where > N is td_tid) or 'proc N' (where N is a pid). You can also use > 'thread N', but that requires using gdb's internal thread number > which has no relation to tids or pids. There are several ways to > enumerate the list of threads in a core: > > 1) You can use 'info threads' in kgdb to get a list of threads. > > 2) You can run 'ps' against the crashdump using -N and -M to get > the tid and pid values (at least until someone like glebius@ goes > on more of an anti-libkvm tirade and removes crashdump support from > ps). crashinfo runs ps by default, so if you have that enabled you > can look in core.txt.N to get the list of tids / pids. > > 3) You can grab my gdb scripts at ~jhb/gdb/ and source 'gdb6'. > That gives you a 'ps' command kind of like DDB's ps. > OMG ... thank you. :-) I'm guessing, that from the list here, no useful information is going to be available. It looks like all my interrupt threads are idle and all taskqueue threads are asleep: 59 Thread 100049 (PID=12: intr/irq257: em0:rx0) sched_switch (td=0xfffff80002c47940, newtd=, flags=) at /home/sbruno/bsd/em_mq/sys/kern/sched_ule.c:1956 58 Thread 100051 (PID=12: intr/irq258: em0:rx1) sched_switch (td=0xfffff80002c47000, newtd=, flags=) at /home/sbruno/bsd/em_mq/sys/kern/sched_ule.c:1956 57 Thread 100053 (PID=12: intr/irq259: em0:tx0) sched_switch (td=0xfffff80002c424a0, newtd=, flags=) at /home/sbruno/bsd/em_mq/sys/kern/sched_ule.c:1956 56 Thread 100055 (PID=12: intr/irq260: em0:tx1) sched_switch (td=0xfffff80002c5e940, newtd=, flags=) at /home/sbruno/bsd/em_mq/sys/kern/sched_ule.c:1956 55 Thread 100057 (PID=12: intr/irq261: em0:link) sched_switch (td=0xfffff80002c5e000, newtd=, flags=) at /home/sbruno/bsd/em_mq/sys/kern/sched_ule.c:1956 54 Thread 100058 (PID=12: intr/irq262: em1:rx0) cpustop_handler () at /home/sbruno/bsd/em_mq/sys/x86/x86/mp_x86.c:987 53 Thread 100060 (PID=12: intr/irq263: em1:rx1) cpustop_handler () at /home/sbruno/bsd/em_mq/sys/x86/x86/mp_x86.c:987 52 Thread 100062 (PID=12: intr/irq264: em1:tx0) cpustop_handler () at /home/sbruno/bsd/em_mq/sys/x86/x86/mp_x86.c:987 51 Thread 100064 (PID=12: intr/irq265: em1:tx1) cpustop_handler () at /home/sbruno/bsd/em_mq/sys/x86/x86/mp_x86.c:987 50 Thread 100066 (PID=12: intr/irq266: em1:link) cpustop_handler () at /home/sbruno/bsd/em_mq/sys/x86/x86/mp_x86.c:987 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJVVh2YXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kUlMH/2ZHs/G/Ql9a+ah3oyyFXosh /KVZ17K6CXywAVPhL2+twXUuzu5zDj4spu4zdlbSIN5BqzpbPyiJgtAc1iT3Elco U7J5KQSaGOopd0ldwkTShormsvUlhDEy3Ed529qN5ppf1YI/yZ6HGYpYQ2gdvRJ1 5148j+q/aLLDpFFbuffT2NXgeMgahW79SEOl/kiI+Qn5KIT+Kp417+1ZriTz2Xx8 TRIayQi2IItU4AmowSToBt5hFqWVywAYLLRur3z12OgAbgodcxLg4IN3muHzfpPY lJh57lb4pSIL2Ic2a7tBcXyaT4lsUKI4uG7Sxa0pq+WUW6zY+XRcc1y+K6k5tCg= =ZIqy -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Fri May 15 16:45:11 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 D9B218A4; Fri, 15 May 2015 16:45:10 +0000 (UTC) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A2AC913DC; Fri, 15 May 2015 16:45:10 +0000 (UTC) Received: by igbpi8 with SMTP id pi8so227980020igb.1; Fri, 15 May 2015 09:45:10 -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=mvULH69on0CoQ6Ax8e+HhAAfG9pOiF9Lfie93zqGRD8=; b=VfAEv6KNfQkj5wN2ZMB9853vr26/0IaKTiOh04g1phYwfLmmUyiY2/BiuoqiMS9YY3 +8eFcwVb7iqnu5okI3r50J+dvP5tZTiWmJqtac+ttf91BOQ8LxjZGtf7DcwQKWGopWTL pkP9QKLPpwJYhJItanumacJnNzQRqMZe0NcYL2KOaqKB2+hVtgNyzG8/Lzjqz/pyHcWb iPlAsGWjUYsip5Ed88FiNIDxwUW/+BSWXHlRjkVRvOBbiHcSb5Sa57Ozp+HXJ3pdD2m+ pYqJo0Bb3/8R7yxgMhC3EsbQCahN8sBy2qCjw8o9SNzVHlbg4L8ee6GMC1aS4ropjlvf GoCw== MIME-Version: 1.0 X-Received: by 10.50.73.169 with SMTP id m9mr43749878igv.37.1431708310111; Fri, 15 May 2015 09:45:10 -0700 (PDT) Received: by 10.107.40.194 with HTTP; Fri, 15 May 2015 09:45:10 -0700 (PDT) In-Reply-To: <55561D9A.30309@ignoranthack.me> References: <554E41EE.2010202@ignoranthack.me> <2063489.pgabuk9nPJ@ralph.baldwin.cx> <55561803.9050102@ignoranthack.me> <19618854.y3EeXVtCGX@ralph.baldwin.cx> <55561D9A.30309@ignoranthack.me> Date: Fri, 15 May 2015 12:45:10 -0400 Message-ID: Subject: Re: How to get anything useful out of kgdb? From: Ryan Stone To: Sean Bruno Cc: John Baldwin , "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: Fri, 15 May 2015 16:45:11 -0000 On Fri, May 15, 2015 at 12:23 PM, Sean Bruno wrote: > 54 Thread 100058 (PID=12: intr/irq262: em1:rx0) cpustop_handler () > at /home/sbruno/bsd/em_mq/sys/x86/x86/mp_x86.c:987 > 53 Thread 100060 (PID=12: intr/irq263: em1:rx1) cpustop_handler () > at /home/sbruno/bsd/em_mq/sys/x86/x86/mp_x86.c:987 > 52 Thread 100062 (PID=12: intr/irq264: em1:tx0) cpustop_handler () > at /home/sbruno/bsd/em_mq/sys/x86/x86/mp_x86.c:987 > 51 Thread 100064 (PID=12: intr/irq265: em1:tx1) cpustop_handler () > at /home/sbruno/bsd/em_mq/sys/x86/x86/mp_x86.c:987 > 50 Thread 100066 (PID=12: intr/irq266: em1:link) cpustop_handler () > at /home/sbruno/bsd/em_mq/sys/x86/x86/mp_x86.c:987 > These ones were all running at the time. From owner-freebsd-hackers@FreeBSD.ORG Fri May 15 17:07:58 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 B58A484D for ; Fri, 15 May 2015 17:07:58 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9595D1714 for ; Fri, 15 May 2015 17:07:58 +0000 (UTC) Received: from [192.168.200.214] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 5DF02193656; Fri, 15 May 2015 17:07:57 +0000 (UTC) Message-ID: <555627EC.2020007@ignoranthack.me> Date: Fri, 15 May 2015 10:07:56 -0700 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ryan Stone CC: "freebsd-hackers@freebsd.org" Subject: Re: How to get anything useful out of kgdb? References: <554E41EE.2010202@ignoranthack.me> <2063489.pgabuk9nPJ@ralph.baldwin.cx> <55561803.9050102@ignoranthack.me> <19618854.y3EeXVtCGX@ralph.baldwin.cx> <55561D9A.30309@ignoranthack.me> In-Reply-To: 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: Fri, 15 May 2015 17:07:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/15/15 09:45, Ryan Stone wrote: > On Fri, May 15, 2015 at 12:23 PM, Sean Bruno > wrote: > >> 54 Thread 100058 (PID=12: intr/irq262: em1:rx0) cpustop_handler >> () at /home/sbruno/bsd/em_mq/sys/x86/x86/mp_x86.c:987 53 Thread >> 100060 (PID=12: intr/irq263: em1:rx1) cpustop_handler () at >> /home/sbruno/bsd/em_mq/sys/x86/x86/mp_x86.c:987 52 Thread 100062 >> (PID=12: intr/irq264: em1:tx0) cpustop_handler () at >> /home/sbruno/bsd/em_mq/sys/x86/x86/mp_x86.c:987 51 Thread 100064 >> (PID=12: intr/irq265: em1:tx1) cpustop_handler () at >> /home/sbruno/bsd/em_mq/sys/x86/x86/mp_x86.c:987 50 Thread 100066 >> (PID=12: intr/irq266: em1:link) cpustop_handler () at >> /home/sbruno/bsd/em_mq/sys/x86/x86/mp_x86.c:987 >> > > These ones were all running at the time. > Hrm, when I look at them directly in the crashdump, I don't see anything useful. (kgdb) tid 100058 [Switching to thread 54 (Thread 100058)]#0 cpustop_handler () at /home/sbruno/bsd/em_mq/sys/x86/x86/mp_x86.c:987 987 CPU_SET_ATOMIC(cpu, &stopped_cpus); Current language: auto; currently minimal (kgdb) whe #0 cpustop_handler () at /home/sbruno/bsd/em_mq/sys/x86/x86/mp_x86.c:98 7 #1 0xffffffff80f76f7a in ipi_nmi_handler () at /home/sbruno/bsd/em_mq/sys/x86/x86/mp_x86.c:969 #2 0xffffffff80e3657a in trap (frame=0xffffffff817eb910) at /home/sbruno/bsd/em_mq/sys/amd64/amd64/trap.c:188 #3 0xffffffff80e1b273 in nmi_calltrap () at /home/sbruno/bsd/em_mq/sys/amd64/amd64/exception.S:509 #4 0x0000000800841841 in ?? () Previous frame inner to this frame (corrupt stack?) Is "what I want to do" not really possible? sean -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJVVifqXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kXt8IANIkerdy0eZgjxfCbC+3Re6g 7HxS18p7d+sHzMO9YBtigYqs4apNnPjglCUWlBDQBgpjeyFPvVA20siIGKXSwHqI ogjY/93n3hr9ZAa+nMxNMBDloghUJJrItV42FWHs1x/sFYiCxojp53zmZDe1lmfU 2ZKotyFdo10Kq+1LNN8TLzK1KjBT581R94mTNlozTAJM+hFiBuSB7xv3tvITOUIa QQ8gXmLB70vfWpfHnUsW5xlBhjJaR9oBFM4HvhbWVDtVFXpQQvIUgAYboSRjQZZd 90N8Qo/GygK7XNfiiwykLqhLUlr008xgcEQa7ZIryKP8D2dwwAU9XAqGzbkuGjA= =fGWH -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Fri May 15 17:57:04 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 09EFB6D8; Fri, 15 May 2015 17:57:04 +0000 (UTC) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C705C1D1E; Fri, 15 May 2015 17:57:03 +0000 (UTC) Received: by iepk2 with SMTP id k2so121840282iep.3; Fri, 15 May 2015 10:57:03 -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=ZEmUa9qmneavETpMzaJW/Rk4gV5007ielMO66E0yknk=; b=R1wE0bUKZKbh910QqasJWIJX03fQwzpbf6AIpwbfpT+fn4ejhmloiIllnDCuKxw7rE mNruRvvP3/5ny/ZUo5lP04OnfzN6CrEOuNqtXgRvdo2IPjinxaDg/BPMInVSvbSvKAsj vY1HJzIlfYGvBY733rGoBl//x3i89sOmWf1zRR3cZJFGAQAEVnLaVEkkP1GEYnK+xiGA D0usMRFXbI9CTx/H6YqFqjM4z9dM/9WxKHgVAY8i5q3HFJcAka1eu1tJW9UxTNM95PpL P3mIQ6DJBxBH8bk/rd2zsYlmWZQ1endzw2rm6ZHqM0txxfuvkZggfAjgVg6Mn3nllum1 +bFg== MIME-Version: 1.0 X-Received: by 10.42.146.202 with SMTP id k10mr22579446icv.34.1431712623197; Fri, 15 May 2015 10:57:03 -0700 (PDT) Received: by 10.107.40.194 with HTTP; Fri, 15 May 2015 10:57:03 -0700 (PDT) In-Reply-To: <555627EC.2020007@ignoranthack.me> References: <554E41EE.2010202@ignoranthack.me> <2063489.pgabuk9nPJ@ralph.baldwin.cx> <55561803.9050102@ignoranthack.me> <19618854.y3EeXVtCGX@ralph.baldwin.cx> <55561D9A.30309@ignoranthack.me> <555627EC.2020007@ignoranthack.me> Date: Fri, 15 May 2015 13:57:03 -0400 Message-ID: Subject: Re: How to get anything useful out of kgdb? From: Ryan Stone To: Sean Bruno Cc: "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: Fri, 15 May 2015 17:57:04 -0000 On Fri, May 15, 2015 at 1:07 PM, Sean Bruno wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hrm, when I look at them directly in the crashdump, I don't see > anything useful. > > (kgdb) tid 100058 > [Switching to thread 54 (Thread 100058)]#0 cpustop_handler () at > /home/sbruno/bsd/em_mq/sys/x86/x86/mp_x86.c:987 > 987 CPU_SET_ATOMIC(cpu, &stopped_cpus); > Current language: auto; currently minimal > (kgdb) whe > #0 cpustop_handler () at /home/sbruno/bsd/em_mq/sys/x86/x86/mp_x86.c:98 > 7 > #1 0xffffffff80f76f7a in ipi_nmi_handler () at > /home/sbruno/bsd/em_mq/sys/x86/x86/mp_x86.c:969 > #2 0xffffffff80e3657a in trap (frame=0xffffffff817eb910) at > /home/sbruno/bsd/em_mq/sys/amd64/amd64/trap.c:188 > #3 0xffffffff80e1b273 in nmi_calltrap () at > /home/sbruno/bsd/em_mq/sys/amd64/amd64/exception.S:509 > #4 0x0000000800841841 in ?? () > Previous frame inner to this frame (corrupt stack?) > *Sigh*, kgdb isn't unwinding the trap frame properly. You can try this to figure out where it was running: frame 2 info line *frame->tf_rip That gives you the top of the callstack at the time that the core was taken. To get the rest of it, try: define trace_stack set $frame_ptr=$arg0 set $iters=0 while $frame_ptr != 0 && $iters < $arg1 set $ret_addr=((char*)$frame_ptr) + sizeof(void*) printf "frameptr=%p, ret_addr=%p\n", (void*)$frame_ptr, *(void**)$ret_addr printf " " info line **(void***)$ret_addr set $frame_ptr=*(void**)$frame_ptr set $iters=$iters+1 end end trace_stack frame->tf_rbp 20 From owner-freebsd-hackers@FreeBSD.ORG Fri May 15 19:20:21 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 181AE6D3 for ; Fri, 15 May 2015 19:20:21 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D90E1177F for ; Fri, 15 May 2015 19:20:20 +0000 (UTC) Received: from [192.168.200.214] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id EA670193656; Fri, 15 May 2015 19:20:18 +0000 (UTC) Message-ID: <555646F1.4000405@ignoranthack.me> Date: Fri, 15 May 2015 12:20:17 -0700 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ryan Stone CC: "freebsd-hackers@freebsd.org" Subject: Re: How to get anything useful out of kgdb? References: <554E41EE.2010202@ignoranthack.me> <2063489.pgabuk9nPJ@ralph.baldwin.cx> <55561803.9050102@ignoranthack.me> <19618854.y3EeXVtCGX@ralph.baldwin.cx> <55561D9A.30309@ignoranthack.me> <555627EC.2020007@ignoranthack.me> In-Reply-To: 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: Fri, 15 May 2015 19:20:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/15/15 10:57, Ryan Stone wrote: > On Fri, May 15, 2015 at 1:07 PM, Sean Bruno > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >> >> Hrm, when I look at them directly in the crashdump, I don't see >> anything useful. >> >> (kgdb) tid 100058 [Switching to thread 54 (Thread 100058)]#0 >> cpustop_handler () at >> /home/sbruno/bsd/em_mq/sys/x86/x86/mp_x86.c:987 987 >> CPU_SET_ATOMIC(cpu, &stopped_cpus); Current language: auto; >> currently minimal (kgdb) whe #0 cpustop_handler () at >> /home/sbruno/bsd/em_mq/sys/x86/x86/mp_x86.c:98 7 #1 >> 0xffffffff80f76f7a in ipi_nmi_handler () at >> /home/sbruno/bsd/em_mq/sys/x86/x86/mp_x86.c:969 #2 >> 0xffffffff80e3657a in trap (frame=0xffffffff817eb910) at >> /home/sbruno/bsd/em_mq/sys/amd64/amd64/trap.c:188 #3 >> 0xffffffff80e1b273 in nmi_calltrap () at >> /home/sbruno/bsd/em_mq/sys/amd64/amd64/exception.S:509 #4 >> 0x0000000800841841 in ?? () Previous frame inner to this frame >> (corrupt stack?) >> > > *Sigh*, kgdb isn't unwinding the trap frame properly. You can try > this to figure out where it was running: > > frame 2 info line *frame->tf_rip I'm guessing that we are just at the limit of what the intree kgdb is capable of doing with out crashdumps. #2 0xffffffff80e3657a in trap (frame=0xffffffff817eb910) at /home/sbruno/bsd/em_mq/sys/amd64/amd64/trap.c:188 188 if (ipi_nmi_handler() == 0) (kgdb) p frame $5 = (struct trapframe *) 0xffffffff817eb910 (kgdb) p *frame $6 = {tf_rdi = 34389196884, tf_rsi = 34389192960, tf_rdx = 0, tf_rcx = 360, tf_r8 = 0, tf_r9 = -8795456263872, tf_rax = 0, tf_rbx = 34393489408, tf_rbp = 140736951475936, tf_r10 = 17232, tf_r11 = 583, tf_r12 = 1882455366, tf_r13 = 34389196880, tf_r14 = 0, tf_r15 = 6358856, tf_trapno = 19, tf_fs = 19, tf_gs = 27, tf_addr = 0, tf_flags = 1, tf_es = 59, tf_ds = 59, tf_err = 0, tf_rip = 34368395329, tf_cs = 67, tf_rflags = 518, tf_rsp = 140736951475912, tf_ss = 59} (kgdb) p *frame->tf_rip Cannot access memory at address 0x800841841 (kgdb) info line *frame->tf_rip No line number information available for address 0x800841841 (kgdb) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJVVkbvXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kDCAH+wZCVF2ZVzIJ3KZaKJK3TZhk P0LKwJDqKPiSf0qJtjD5WOomPWTwBjOS83soGwOUylo5QQezCtdisMDR9E5z5V8Y nWP3MLN/leG8KAbFl5XxLwQ3OlQ8SdXaHLoF8M17C8orJOo5vJfe/qEmqSOQJiU1 ZFES+xvtvoeqjirvzdw1cu55ZDJH6I5hmDL8LLShC3MCgS3R81m6YObIL8BAFOTu FCMZJVxDuZZ/nAQDmVDUKFXFO8GSibEDCmmFMWqwSR/qmKV9KNveJ51PNW1yl8E6 QHa66unZ1Y+oMDHpZYopPuuKks4M4akrRhJzFLdbuMTOdCJ0qnoXYgsoIb8Vsy0= =efn3 -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Sat May 16 11:01:27 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 5482F29C for ; Sat, 16 May 2015 11:01:27 +0000 (UTC) Received: from puchar.net (puchar.net [188.252.31.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D511617C7 for ; Sat, 16 May 2015 11:01:26 +0000 (UTC) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.14.9/8.14.9) with ESMTP id t4GAcYa6006158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 16 May 2015 12:38:34 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from laptop.wojtek.intra (localhost [127.0.0.1]) by laptop.wojtek.intra (8.14.9/8.14.9) with ESMTP id t4GAcahr000814 for ; Sat, 16 May 2015 12:38:36 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by laptop.wojtek.intra (8.14.9/8.14.9/Submit) with ESMTP id t4GAcUsQ000811 for ; Sat, 16 May 2015 12:38:31 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: laptop.wojtek.intra: wojtek owned process doing -bs Date: Sat, 16 May 2015 12:38:30 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: freebsd-hackers@freebsd.org Subject: unionfs/nullfs Help please Message-ID: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Sat, 16 May 2015 12:38:35 +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: Sat, 16 May 2015 11:01:27 -0000 what i need: i have a directory "/home/administration" with files belonging to group say "bosses". I've added say "john" and "bill" to group bosses. Now bosses can read and write in /home/administration. Now i want mark, anne and tom to be able to read data from /home/administration but not write. Others should not be able to do access it at all. So i created group "administration-read" and added mark,anne and tom to it. Now i wanted using nullfs or unionfs to clone /home/administration to say /nullfs/administration-read so it will be read only (no problem) but gid of files would be changed to administration-read. Tried multiple things, to no avail. Seems i don't really understand manuals ;) Any help how to do it this way or other way (but no ACLs please)? From owner-freebsd-hackers@FreeBSD.ORG Sat May 16 14:20:10 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 ABEACAFA for ; Sat, 16 May 2015 14:20:10 +0000 (UTC) Received: from mail.egr.msu.edu (boomhauer.egr.msu.edu [35.9.37.167]) by mx1.freebsd.org (Postfix) with ESMTP id 8611F1BC8 for ; Sat, 16 May 2015 14:20:09 +0000 (UTC) Received: from boomhauer (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id C8E463D0B3 for ; Sat, 16 May 2015 10:13:37 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by boomhauer (boomhauer.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmmYAwHkKI6c for ; Sat, 16 May 2015 10:13:37 -0400 (EDT) Received: from EGR authenticated sender mcdouga9 Message-ID: <55575090.1020609@egr.msu.edu> Date: Sat, 16 May 2015 10:13:36 -0400 From: Adam McDougall User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: unionfs/nullfs Help please 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: Sat, 16 May 2015 14:20:10 -0000 On 05/16/2015 06:38, Wojciech Puchar wrote: > what i need: > > i have a directory "/home/administration" with files belonging to group > say "bosses". I've added say "john" and "bill" to group bosses. Now > bosses can read and write in /home/administration. > > Now i want mark, anne and tom to be able to read data from > /home/administration but not write. Others should not be able to do > access it at all. > > So i created group "administration-read" and added mark,anne and tom to it. > > Now i wanted using nullfs or unionfs to clone /home/administration to > say /nullfs/administration-read so it will be read only (no problem) but > gid of files would be changed to administration-read. > > Tried multiple things, to no avail. Seems i don't really understand > manuals ;) > > Any help how to do it this way or other way (but no ACLs please)? > > Make /home/administration mode 750, group administration-read. Add members of "bosses" to administration-read so all authorized users but nobody else can enter the directory. Make the content inside mode 775 or 664 as appropriate, group bosses, so bosses can write but 'other' can read, which will allow members of administration-read to read. It is up to you or the bosses to make sure content doesn't become world writable or the top level doesn't allow others in, and new files/dirs have group bosses. chgrp g+s on directories may help preserve the proper group on new content.