DOCSLIB.ORG

Debugging Kernel Problems

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Debugging Kernel Problems by Greg Lehey Edition for EuroBSDCon 2005 Basel, 25 November 2005 Debugging Kernel Problems by Greg Lehey ([email protected], [email protected], [email protected]) Copyright © 1995-2005 Greg Lehey $Id: handout.mm,v 1.14 2005/11/05 02:36:32 grog Exp $ This book is licensed under the Creative Commons Attribution-NonCommer cial-ShareAlike license, Version 2.5. (http://cr eativecommons.org/licenses/by-nc-sa/2.5/). The following is a slightly refor matted version of the license specified there. Any dif ferences arenot intended to change the meaning of the license. Youare free: • to copy, distribute, display, and perfor m the work, and • to make derivative works under the following conditions: • Attribution: You must attribute the work in the manner specified by the author or licensor. • Non-commercial: You may not use this work for commercial purposes. • Shar e Alike: If you alter,transfor m, or build upon this work, you may distribute the resulting work only under a license identical to this one. • For any reuse or distribution, you must make clear to others the license terms of this work. • Any of these conditions can be modified if you get permission from the copyright holder. Your fair use and other rights areinnoway affected by the above. The latest version of this document is available at http://www.lemis.com/gr og/Papers/Debug-tutorial/tutori- al.pdf. The latest version of the accompanying slides is at http://www.lemis.com/gr og/Papers/Debug-tutori- al/slides.pdf. Debugging Kernel Problems 3 Preface Debugging kernel problems is a black art. Not many people do it, and documentation is rare, inaccurate and incomplete. This document is no exception: faced with the choice of accuracy and completeness, I chose to attempt the latter.Asusual, time was the limiting factor,and this draft is still in beta status, as it has been through numerous pr esentations of the tutorial. This is a typical situation for the whole topic of kernel debugging: building debug tools and documentation is expensive, and the people who write them arealso the people who use them, so there's a tendency to build as much of the tool as necessary to do the job at hand. If the tool is well-written, it will be reusable by the next person who looks at a particular area; if not, it might fall into disuse. Consider this book a starting point for your own development of debugging tools, and remember: morethan anywhereelse, this is an area with “some assembly requir ed”. 4Debugging Kernel Problems Debugging Kernel Problems 5 1 Introduction Operating systems fail. All operating systems contain bugs, and they will sometimes cause the system to behave incorrectly. BSD ker nels ar e no exception. Compar ed to most other operating systems, both free and commercial, BSD kernels offer a large number of debugging tools. This tutorial examines the options available both to the experienced end user and also to the developer. This tutorial bases on the FreeBSD kernel, but the differ ences in other BSDs aresmall. We'll look at the following topics: • How and why kernels fail. • Understanding log files: dmesg and the files in /var/log,notably /var/log/messages. • Userland tools for debugging a running system. • Building a kernel with debugging support: the options. • Using a serial console. • Pr eparing for dumps: dumpon, savecor e. • The assembler-level view of a C program. • Pr eliminary dump analysis. • Reading code. • Intr oduction to the kernel source tree. • Analysing panic dumps with gdb. • On-line kernel debuggers: ddb,remote serial gdb. • Debugging a running system with ddb. • Debugging a running system with gdb. 6Debugging Kernel Problems • Debug options in the kernel: INVARIANTS and friends. • Debug options in the kernel: WITNESS. • Code-based assistance: KTR. Howand whyker nels fail Good kernels should not fail. They must protect themselves against a number of ex- ter nal influences, including hardwarefailur e, both deliberately and accidentally badly written user programs, and kernel programming errors. In some cases, of course, ther e is no way a kernel can recover,for example if the only processor fails. On the other hand, a good kernel should be able to protect itself from badly written user pro- grams. Aker nel can fail in a number of ways: • It can stop reacting to the outside world. This is called a hang. • It can destroy itself (overwriting code). It's almost impossible to distinguish this state from a hang unless you have tools which can examine the machine state inde- pendently of the kernel. • It can detect an inconsistency, report it and stop. In UNIX terminology, this is a panic . • It can continue running incorrectly. For example, it might corrupt data on disk or br each network protocols. By far the easiest kind of failuretodiagnose is a panic. Ther e ar e two basic types: • Failed consistency checks result in a specific panic: panic: Free vnode isn't • Exception conditions result in a less specific panic: panic: Page fault in kernel mode The other cases can be very difficult to catch at the right moment. Debugging Kernel Problems 7 2 Userland programs dmesg In normal operation, a kernel will sometimes write messages to the outside world via the “console”, /dev/console.Inter nally it writes via a circular buffer called msgbuf. The dmesg pr ogram can show the current contents of msgbuf.The most important use is at startup time for diagnosing configuration problems: # dmesg Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.5-PRERELEASE #3: Sat Jan 513:25:02 CST 2002 [email protected]:/src/FreeBSD/4-STABLE-ECHUNGA/src/sys/compile/ECHUNGA Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 751708714 Hz CPU: AMD Athlon(tm) Processor (751.71-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x621 Stepping = 1 Features=0x183f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE3 6,MMX,FXSR> AMD Features=0xc0400000<AMIE,DSP,3DNow!> ... pci0: <unknown card> (vendor=0x1039, dev=0x0009) at 1.1 ... cd1 at ahc0 bus 0 target 1 lun 0 cd1: <TEAC CD-ROM CD-532S 1.0A> Removable CD-ROM SCSI-2 device cd1: 20.000MB/s transfers (20.000MHz, offset 15) cd1: Attempt to query device size failed: NOT READY, Medium not present ... WARNING: / was not properly unmounted Much of this information is informative, but occasionally you get messages indicating some problem. The last line in the previous example shows that the system did not shut down properly: either it crashed, or the power failed. During normal operation you might see messages like the following: sio1: 1 more silo overflow (total 1607) 8Debugging Kernel Problems sio1: 1 more silo overflow (total 1608) nfsd send error 64 ... nfs server wantadilla:/src: not responding nfs server wantadilla:/: not responding nfs server wantadilla:/src: is alive again nfs server wantadilla:/: is alive again arp info overwritten for 192.109.197.82 by 00:00:21:ca:6e:f1 In the course of time, the message buffer wraps around and the old contents arelost. For this reason, FreeBSD and NetBSD print the dmesg contents after boot to the file /var/run/dmesg.boot for later refer ence. In addition, the output is piped to syslogd, the system log daemon, which by default writes it to /var/log/messages. During kernel debugging you can print msgbuf.For FreeBSD, enter: (gdb) printf "%s", (char *)msgbufp->msg_ptr For NetBSD or OpenBSD, enter: (gdb) printf "%s", (char *) msgbufp->msg_bufc Log files BSD systems keep track of significant events in log files.They can be of great use for debugging. Most of them arekept in /var/log,though this is not a requir ement. Many of them aremaintained by syslogd,but thereisnorequir ement for a special program. The only requir ement is to avoid having two programs maintaining the same file. syslogd syslogd is a standard daemon which maintains a number of the files in /var/log.You should always run syslogd unless you have a very good reason not to. Pr ocesses nor mally write to syslogd with the library function syslog: #include <syslog.h> #include <stdarg.h> void syslog (int priority, const char *message, ...); syslog is used in a similar manner to printf;only the first parameter is differ ent. Although it's called priority in the man page, it's divided into two parts: • The level field describes how serious the message is. It ranges from LOG_DEBUG (infor mation nor mally suppr essed and only produced for debug purposes) to LOG_EMERG (“machine about to self-destruct”). • The facility field describes what part of the system generated the message. The priority field can be repr esented in text formasfacility.level.For example, error messages from the mail subsystem arecalled mail.err. Debugging Kernel Problems 9 In FreeBSD, as the result of security concerns, syslogd is started with the -s flag by default. This stops syslogd fr om accepting remote messages. If you specify the -ss flag, as suggested in the comment, you will also not be able to log to remote systems. Depending on your configuration, it’s worth changing this default. For example, you might want all systems in example.or g to log to gw.That way you get one set of log files for the entirenetwork. /etc/syslog.conf syslogd reads the file /etc/syslog.conf,which specifies wheretolog messages based on their message priority. Her e's aslightly modified example: #$FreeBSD: src/etc/syslog.conf,v 1.13 2000/02/08 21:57:28 rwatson Exp $ # #Spaces are NOT valid field separators in this file.
Recommended publications
  • Debugging Kernel Problems

    Debugging Kernel Problems

    Debugging Kernel Problems by GregLehey Edition for AsiaBSDCon 2004 Taipei, 13 March 2004 Debugging Kernel Problems by GregLehey([email protected]) Copyright © 1995-2004 GregLehey 3Debugging Kernel Problems Preface Debugging kernel problems is a black art. Not manypeople do it, and documentation is rare, in- accurate and incomplete. This document is no exception: faced with the choice of accuracyand completeness, I chose to attempt the latter.Asusual, time was the limiting factor,and this draft is still in beta status. This is a typical situation for the whole topic of kernel debugging: building debug tools and documentation is expensive,and the people who write them are also the people who use them, so there'satendencytobuild as much of the tool as necessary to do the job at hand. If the tool is well-written, it will be reusable by the next person who looks at a particular area; if not, it might fall into disuse. Consider this book a starting point for your own develop- ment of debugging tools, and remember: more than anywhere else, this is an area with ``some as- sembly required''. Debugging Kernel Problems 4 1 Introduction Operating systems fail. All operating systems contain bugs, and theywill sometimes cause the system to behave incorrectly.The BSD kernels are no exception. Compared to most other oper- ating systems, both free and commercial, the BSD kernels offer a large number of debugging tools. This tutorial examines the options available both to the experienced end user and also to the developer. In this tutorial, we’ll look at the following topics: • Howand whykernels fail.
  • Some Results Recall: FAT Properties FAT Assessment – Issues

    Some Results Recall: FAT Properties FAT Assessment – Issues

    Recall: A Little Queuing Theory: Some Results • Assumptions: CS162 – System in equilibrium; No limit to the queue Operating Systems and – Time between successive arrivals is random and memoryless Systems Programming Queue Server Lecture 19 Arrival Rate Service Rate μ=1/Tser File Systems (Con’t), • Parameters that describe our system: MMAP, Buffer Cache – : mean number of arriving customers/second –Tser: mean time to service a customer (“m1”) –C: squared coefficient of variance = 2/m12 –μ: service rate = 1/Tser th April 11 , 2019 –u: server utilization (0u1): u = /μ = Tser • Parameters we wish to compute: Prof. Ion Stoica –Tq: Time spent in queue http://cs162.eecs.Berkeley.edu –Lq: Length of queue = Tq (by Little’s law) • Results: –Memoryless service distribution (C = 1): » Called M/M/1 queue: Tq = Tser x u/(1 – u) –General service distribution (no restrictions), 1 server: » Called M/G/1 queue: Tq = Tser x ½(1+C) x u/(1 – u)) 4/11/19 Kubiatowicz CS162 © UCB Spring 2019 Lec 19.2 Recall: FAT Properties FAT Assessment – Issues • File is collection of disk blocks • Time to find block (large files) ?? (Microsoft calls them “clusters”) FAT Disk Blocks FAT Disk Blocks • FAT is array of integers mapped • Block layout for file ??? 1-1 with disk blocks 0: 0: 0: 0: File #1 File #1 – Each integer is either: • Sequential Access ??? » Pointer to next block in file; or 31: File 31, Block 0 31: File 31, Block 0 » End of file flag; or File 31, Block 1 File 31, Block 1 » Free block flag File 63, Block 1 • Random Access ??? File 63, Block 1 • File Number
  • Development Tools for the Kernel Release 4.13.0-Rc4+

    Development Tools for the Kernel Release 4.13.0-Rc4+

    Development tools for the Kernel Release 4.13.0-rc4+ The kernel development community Sep 05, 2017 CONTENTS 1 Coccinelle 3 1.1 Getting Coccinelle ............................................. 3 1.2 Supplemental documentation ...................................... 3 1.3 Using Coccinelle on the Linux kernel .................................. 4 1.4 Coccinelle parallelization ......................................... 4 1.5 Using Coccinelle with a single semantic patch ............................ 5 1.6 Controlling Which Files are Processed by Coccinelle ......................... 5 1.7 Debugging Coccinelle SmPL patches .................................. 5 1.8 .cocciconfig support ............................................ 6 1.9 Additional flags ............................................... 7 1.10 SmPL patch specific options ....................................... 7 1.11 SmPL patch Coccinelle requirements .................................. 7 1.12 Proposing new semantic patches .................................... 7 1.13 Detailed description of the report mode ................................ 7 1.14 Detailed description of the patch mode ................................ 8 1.15 Detailed description of the context mode ............................... 9 1.16 Detailed description of the org mode .................................. 9 2 Sparse 11 2.1 Using sparse for typechecking ...................................... 11 2.2 Using sparse for lock checking ...................................... 11 2.3 Getting sparse ..............................................
  • BSD Professional Certification Job Task Analysis Survey Results

    BSD Professional Certification Job Task Analysis Survey Results

    BSD Professional Certification Job Task Analysis Survey Results March 21, 2010 BSD Professional Job Task Analysis Survey Results 2 Copyright © 2010 BSD Certification Group All Rights Reserved All trademarks are owned by their respective companies. This work is protected by a Creative Commons License which requires attribution and prevents commercial and derivative works. The human friendly version of the license can be viewed at http://creativecommons.org/licenses/by-nc-nd/3.0/ which also provides a hyperlink to the legal code. These conditions can only be waived by written permission from the BSD Certification Group. See the website for contact details. BSD Daemon Copyright 1988 by Marshall Kirk McKusick. All Rights Reserved. Puffy Artwork Copyright© 2004 by OpenBSD. FreeBSD® is a registered trademark of The FreeBSD Foundation, Inc. NetBSD® is a registered trademark of The NetBSD Foundation, Inc. The NetBSD Logo Copyright© 2004 by The NetBSD Foundation, Inc. Fred Artwork Copyright© 2005 by DragonFly BSD. Use of the above names, trademarks, logos, and artwork does not imply endorsement of this certification program by their respective owners. www.bsdcertification.org BSD Professional Job Task Analysis Survey Results 3 Table of Contents Executive Summary ................................................................................................................................... 9 Introduction .............................................................................................................................................
  • Recent Filesystem Optimisations in Freebsd

    Recent Filesystem Optimisations in Freebsd

    Recent Filesystem Optimisations in FreeBSD Ian Dowse <[email protected]> Corvil Networks. David Malone <[email protected]> CNRI, Dublin Institute of Technology. Abstract 2.1 Soft Updates In this paper we summarise four recent optimisations Soft updates is one solution to the problem of keeping to the FFS implementation in FreeBSD: soft updates, on-disk filesystem metadata recoverably consistent. Tra- dirpref, vmiodir and dirhash. We then give a detailed ex- ditionally, this has been achieved by using synchronous position of dirhash’s implementation. Finally we study writes to order metadata updates. However, the perfor- these optimisations under a variety of benchmarks and mance penalty of synchronous writes is high. Various look at their interactions. Under micro-benchmarks, schemes, such as journaling or the use of NVRAM, have combinations of these optimisations can offer improve- been devised to avoid them [14]. ments of over two orders of magnitude. Even real-world workloads see improvements by a factor of 2–10. Soft updates, proposed by Ganger and Patt [4], allows the reordering and coalescing of writes while maintain- ing consistency. Consequently, some operations which have traditionally been durable on system call return are 1 Introduction no longer so. However, any applications requiring syn- chronous updates can still use fsync(2) to force specific changes to be fully committed to disk. The implementa- Over the last few years a number of interesting tion of soft updates is relatively complicated, involving filesystem optimisations have become available under tracking of dependencies and the roll forward/back of FreeBSD. In this paper we have three goals.
  • A Guide to Kernel Exploitation Attacking the Core (2011

    A Guide to Kernel Exploitation Attacking the Core (2011

    A Guide to Kernel Exploitation This page intentionally left blank A Guide to Kernel Exploitation Attacking the Core Enrico Perla Massimiliano Oldani Technical Editor Graham Speake AMSTERDAM • BOSTON • HEIDELBERG • LONDON • • • NEW YORK OXFORD PARIS SAN DIEGO SYNGRESS SAN FRANCISCO • SINGAPORE • SYDNEY • TOKYO ® Syngress is an imprint of Elsevier Acquiring Editor: Rachel Roumeliotis Development Editor: Matthew Cater Project Manager: Julie Ochs Designer: Alisa Andreola Syngress is an imprint of Elsevier 30 Corporate Drive, Suite 400, Burlington, MA 01803, USA © 2011 Elsevier Inc. All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or any information storage and retrieval system, without permission in writing from the publisher. Details on how to seek permission, further information about the Publisher’s permissions policies and our arrangements with organizations such as the Copyright Clearance Center and the Copyright Licensing Agency, can be found at our website: www.elsevier.com/permissions. This book and the individual contributions contained in it are protected under copyright by the Publisher (other than as may be noted herein). Notices Knowledge and best practice in this field are constantly changing. As new research and experience broaden our understanding, changes in research methods or professional practices, may become necessary. Practitioners and researchers must always rely on their own experience and knowledge in evaluating and using any information or methods described herein. In using such information or methods they should be mindful of their own safety and the safety of others, including parties for whom they have a professional responsibility.
  • Sys/Sys/Bio.H 1 1 /* 65 Void *Bio Caller2; /* Private Use by the Caller

    Sys/Sys/Bio.H 1 1 /* 65 Void *Bio Caller2; /* Private Use by the Caller

    04/21/04 16:54:59 sys/sys/bio.h 1 1 /* 65 void *bio_caller2; /* Private use by the caller. */ 2 * Copyright (c) 1982, 1986, 1989, 1993 66 TAILQ_ENTRY(bio) bio_queue; /* Disksort queue. */ 3 * The Regents of the University of California. All rights reserved. 67 const char *bio_attribute; /* Attribute for BIO_[GS]ETATTR */ 4 * (c) UNIX System Laboratories, Inc. 68 struct g_consumer *bio_from; /* GEOM linkage */ 5 * All or some portions of this file are derived from material licensed 69 struct g_provider *bio_to; /* GEOM linkage */ 6 * to the University of California by American Telephone and Telegraph 70 off_t bio_length; /* Like bio_bcount */ 7 * Co. or Unix System Laboratories, Inc. and are reproduced herein with 71 off_t bio_completed; /* Inverse of bio_resid */ 8 * the permission of UNIX System Laboratories, Inc. 72 u_int bio_children; /* Number of spawned bios */ 9 * 73 u_int bio_inbed; /* Children safely home by now */ 10 * Redistribution and use in source and binary forms, with or without 74 struct bio *bio_parent; /* Pointer to parent */ 11 * modification, are permitted provided that the following conditions 75 struct bintime bio_t0; /* Time request started */ 12 * are met: 76 13 * 1. Redistributions of source code must retain the above copyright 77 bio_task_t *bio_task; /* Task_queue handler */ 14 * notice, this list of conditions and the following disclaimer. 78 void *bio_task_arg; /* Argument to above */ 15 * 2. Redistributions in binary form must reproduce the above copyright 79 16 * notice, this list of conditions and the following disclaimer in the 80 /* XXX: these go away when bio chaining is introduced */ 17 * documentation and/or other materials provided with the distribution. 81 daddr_t bio_pblkno; /* physical block number */ 18 * 3.
  • Operating Systems in Depth This Page Intentionally Left Blank OPERATING SYSTEMS in DEPTH

    Operating Systems in Depth This Page Intentionally Left Blank OPERATING SYSTEMS in DEPTH

    This page intentionally left blank Operating Systems in Depth This page intentionally left blank OPERATING SYSTEMS IN DEPTH Thomas W. Doeppner Brown University JOHN WILEY & SONS, INC. vice-president & executive publisher Donald Fowley executive editor Beth Lang Golub executive marketing manager Christopher Ruel production editor Barbara Russiello editorial program assistant Mike Berlin senior marketing assistant Diana Smith executive media editor Thomas Kulesa cover design Wendy Lai cover photo Thomas W. Doeppner Cover photo is of Banggai Cardinalfi sh (Pterapogon kauderni), taken in the Lembeh Strait, North Sulawesi, Indonesia. This book was set in 10/12 Times Roman. The book was composed by MPS Limited, A Macmillan Company and printed and bound by Hamilton Printing Company. This book is printed on acid free paper. ϱ Founded in 1807, John Wiley & Sons, Inc. has been a valued source of knowledge and understanding for more than 200 years, helping people around the world meet their needs and fulfi ll their aspirations. Our company is built on a foundation of principles that include responsibility to the communities we serve and where we live and work. In 2008, we launched a Corporate Citizenship Initiative, a global effort to address the environmental, social, economic, and ethical challenges we face in our business. Among the issues we are addressing are carbon impact, paper specifi cations and procurement, ethical conduct within our business and among our vendors, and community and charitable support. For more information, please visit our
  • Basics of Powerpc Exception Handling in Mac OS X's Darwin Kernel One Find out What Caused the Crash?

    Basics of Powerpc Exception Handling in Mac OS X's Darwin Kernel One Find out What Caused the Crash?

    TN 2063: Understanding and Debugging Kernel Panics 11/11/02 3:19 PM CONTENTS When the kernel crashes on Mac OS X, the system displays a panic message. At this What is a Kernel Panic? point the system will have to be restarted. But before hitting the reset button, how can Basics of PowerPC Exception Handling in Mac OS X's Darwin Kernel one find out what caused the crash? What Does a Panic Look Like? This technote addresses kernel panics: what they are and how to debug the code that How to Read the Panic Display caused the panic. Isolating the Crash The foundation of Mac OS X is a core Summary operating system commonly known as References Darwin. Although the Darwin kernel runs on both PowerPC and Intel x86 architectures, Downloadables this technote discusses PowerPC exception handling only. This technote contains links to source files available from the Darwin repository. Access to these files requires a username and password obtained by agreeing to the Apple Public Source License. [Nov 11 2002] What is a Kernel Panic? In UNIX, a panic is an unrecoverable system error detected by the kernel 1 as opposed to similar errors detected by user space code. It is possible for kernel code to indicate such a condition by calling the panic function located in the header file sys/systm.h. However, most panics are the result of unhandled processor exceptions in kernel code, such as references to invalid memory addresses. These are typically indicative of a bug somewhere in the call chain leading up to the panic.
  • Kernel Programming

    Kernel Programming

    Inside Mac OS X Kernel Programming November 2002 Apple Computer, Inc. NeXT and OpenStep are trademarks © 2001–2002 Apple Computer, Inc. of NeXT Software, Inc., registered in All rights reserved. the United States and other countries. No part of this publication may be Java and all Java-based trademarks reproduced, stored in a retrieval are trademarks or registered system, or transmitted, in any form or trademarks of Sun Microsystems, by any means, mechanical, electronic, Inc., registsered in the United States photocopying, recording, or and other countries. otherwise, without prior written OpenGL is a registered trademark of permission of Apple Computer, Inc., Silicon Graphics, Inc. with the following exceptions: Any Simultaneously published in the person is hereby authorized to store United States and Canada. documentation on a single computer Even though Apple has reviewed this for personal use only and to print manual, APPLE MAKES NO copies of documentation for personal WARRANTY OR REPRESENTATION, use provided that the documentation EITHER EXPRESS OR IMPLIED, WITH contains Apple’s copyright notice. RESPECT TO THIS MANUAL, ITS The Apple logo is a trademark of QUALITY, ACCURACY, Apple Computer, Inc. MERCHANTABILITY, OR FITNESS Use of the “keyboard” Apple logo FOR A PARTICULAR PURPOSE. AS A (Option-Shift-K) for commercial RESULT, THIS MANUAL IS SOLD “AS purposes without the prior written IS,” AND YOU, THE PURCHASER, ARE consent of Apple may constitute ASSUMING THE ENTIRE RISK AS TO trademark infringement and unfair ITS QUALITY AND ACCURACY. competition in violation of federal and state laws. IN NO EVENT WILL APPLE BE LIABLE FOR DIRECT, INDIRECT, SPECIAL, No licenses, express or implied, are INCIDENTAL, OR CONSEQUENTIAL granted with respect to any of the DAMAGES RESULTING FROM ANY technology described in this book.
  • Conference Reports From

    Conference Reports From

    THE MAGAZINE OF USENIX & SAGE August 2002 volume 27 • number 5 inside: CONFERENCE REPORTS USENIX 2002 & The Advanced Computing Systems Association & The System Administrators Guild conference reports 2002 USENIX Annual KEYNOTE ADDRESS Technical Conference THE INTERNET’S COMING SILENT SPRING Lawrence Lessig, Stanford University MONTEREY, CALIFORNIA, USA OUR THANKS TO THE SUMMARIZERS: Summarized by David E. Ott JUNE 10-15, 2002 For the USENIX Annual Technical Conference: In a talk that received a standing ova- Josh Simon, who organized the collecting of ANNOUNCEMENTS tion, Lawrence Lessig pointed out the the summaries in his usual flawless fashion Summarized by Josh Simon recent legal crisis that is stifling innova- Steve Bauer tion by extending notions of private Florian Buchholz The 2002 USENIX Annual Technical Matt Butner Conference was very exciting. The gen- ownership of technology beyond rea- Pradipta De eral track had 105 papers submitted (up sonable limits. Xiaobo Fan 28% from 82 in 2001) and accepted 25 Hai Huang Several lessons from history are instruc- Scott Kilroy (19 from students); the FREENIX track tive: (1) Edwin Armstrong, the creator Teri Lampoudi had 53 submitted (up from 52 in 2001) of FM radio technology, became an Josh Lothian and accepted 26 (7 from students). enemy to RCA, which launched a legal Bosko Milekic campaign to suppress the technology; Juan Navarro The two annual USENIX-given awards David E. Ott were presented by outgoing USENIX (2) packet switching networks, proposed Amit Purohit Board President Dan Geer. The USENIX by Paul Baron, were seen by AT&T as a Brennan Reynolds Lifetime Achievement Award (also new, competing technology that had to Matt Selsky known as the be suppressed; (3) Disney took Grimm J.D.
  • Release Notes – September 2016

    Release Notes – September 2016

    OpenServer 10.3 (R3M0) Release Notes – September 2016 OpenServer 10.3 RELEASE NOTES About this release OpenServer 10 (R3M0) is a new release of the OpenServer 10 operating system, which adds new features and includes security updates as well as enhancements in both OpenSetup and OpenCommander. These release notes accompany this document: OpenServer 10 GETTING STARTED GUIDE (January 2016) available for free download at the Xinuos web site portal. Contents of these Release Notes What's New in this Release ................................................................................................................ 2 General Enhancements ................................................................................................................... 2 OpenServer 10.3: Fixes and Enhancements ............................................................................... 3 OpenSetup: Fixes and Enhancements ......................................................................................... 3 OpenCommander: Fixes and Enhancements ............................................................................ 5 OpenCommander and ‘Definitive’ Virtual Machines (“VM”) ........................................................... 6 Creation of VM in OpenCommander ............................................................................................ 6 Installation of ‘Definitive’ Operating System ................................................................................ 8 Page 1 of 65 Xinuos, Inc. – All Rights Reserved – Copyright