From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 14:18:41 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47A5A1065673 for ; Mon, 13 Jun 2011 14:18:41 +0000 (UTC) (envelope-from etempest@juniper.net) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by mx1.freebsd.org (Postfix) with ESMTP id C73198FC1E for ; Mon, 13 Jun 2011 14:18:40 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTfYcQELa5FUE+OHiXUcGlXReAoliHVOJ@postini.com; Mon, 13 Jun 2011 07:18:40 PDT Received: from shoals.jnpr.net (10.227.1.190) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.2.254.0; Mon, 13 Jun 2011 07:04:29 -0700 Message-ID: <4DF6191B.2030407@jnpr.net> Date: Mon, 13 Jun 2011 10:05:15 -0400 From: Ewart Tempest User-Agent: Thunderbird 2.0.0.17pre (X11/20081001) MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 13 Jun 2011 17:29:13 +0000 Cc: Ewart Tempest Subject: dwarf2 reader X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 14:18:41 -0000 I have developed some flight recording capability in the JUNOS FreeBSD based kernel, with the flight recorded data being captured in binary form for performance. All the subsequent formatting and display of this data is performed by a user-space application. I would like to reduce the amount of time that designers spend writing formatters to display their flight recorded data. kgdb is perfectly capable of displaying all kernel resident data structures, and the manner in which it does so is perfectly acceptable for flight recording purposes. The code that kgdb uses to support this framework is difficult to break out - does anyone know of a dwarf2 reader s/w implementation that is more re-usable? Ewart From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 18:22:18 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFF141065673 for ; Mon, 13 Jun 2011 18:22:18 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 95DDF8FC0C for ; Mon, 13 Jun 2011 18:22:18 +0000 (UTC) Received: by vws18 with SMTP id 18so5555956vws.13 for ; Mon, 13 Jun 2011 11:22:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AU56PhomQsEaUZe8zf1Xn0a54RH10wWGPjljqxxTnvU=; b=ampYA4NeXJMLdmb6tDG2bhL/NYUgwJbErUw4P3Olsc/xZyoGsWeMLoi9Hwon4MEY8M OPVOoUmyiKqFiReWQpbJ8Kv4l9xoQ/aD+aQbNbN/4/TScljiLAdAR4VxYDL4GTOqTaJV S17PRIKB+J+ZX9eg3WQ0Fhfrjr6twDysktfwk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=RvlmCOT3UsnKHulmpOKRVqwgezNfZPkPDxZ12dk88vu7zxA7zn0Usl616X1zq+E1mx VZxvRIXH1ggBN0IupfcgwvEBzEJLZVsXL5japuCnowEFczpwXH4uKxJ2PpxG+JLcCNBq mFaT4areO4fHPCZO9n4TcFvp3ZBXVGlnwj4YI= MIME-Version: 1.0 Received: by 10.52.75.129 with SMTP id c1mr245316vdw.202.1307989337778; Mon, 13 Jun 2011 11:22:17 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.52.187.74 with HTTP; Mon, 13 Jun 2011 11:22:17 -0700 (PDT) In-Reply-To: <4DF6191B.2030407@jnpr.net> References: <4DF6191B.2030407@jnpr.net> Date: Mon, 13 Jun 2011 20:22:17 +0200 X-Google-Sender-Auth: 7oqfG2a24VmG6jWCeR5hyBOTans Message-ID: From: "K. Macy" To: Ewart Tempest Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Ewart Tempest Subject: Re: dwarf2 reader X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 18:22:19 -0000 Have you taken a look at lldb? It is designed to be more modular. -Kip On Mon, Jun 13, 2011 at 4:05 PM, Ewart Tempest wrote: > I have developed some flight recording capability in the JUNOS FreeBSD ba= sed > kernel, with the flight recorded data being captured in binary form for > performance. All the subsequent formatting and display of this data is > performed by a user-space application. I would like to reduce the amount = of > time that designers spend writing formatters to display their flight > recorded data. kgdb is perfectly capable of displaying all kernel residen= t > data structures, and =A0the manner in which it does so is perfectly accep= table > for flight recording purposes. The code that kgdb uses to support this > framework is difficult to break out - does anyone know of a dwarf2 reader > s/w implementation that is more re-usable? > > Ewart > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 19:00:26 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2700106564A for ; Mon, 13 Jun 2011 19:00:24 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 609678FC13 for ; Mon, 13 Jun 2011 19:00:24 +0000 (UTC) Received: by vxc34 with SMTP id 34so5610673vxc.13 for ; Mon, 13 Jun 2011 12:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=6/2TJC1FtXlLKAelXGYPPKRputWZ/xollKepW1OICfk=; b=jstjlOID5SMoIO0EZ4U1qLZWNxq9DiN2llH3iK4WhQnX7EhgPb3Vo7dBnoLiLEyAQz dpx8lgm48nuCIqCEjqeokLzhx6Gj3+FQCh2AV9E3HSqToHWo8HALtlvQlTInVF8uJWvE cKWbIv/pe36Ojo5n/rBw3jCjWaq40f/BSu9ZM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=F1ZK9SYFnhhFnGUBnhCaWWIGLi+FT4ErBGQUiZPZsGGYQzS5yvT5vQNNWnaUCjhGL6 JaiymcRbCyIdXdYeWlnZhiGNUGEVxSqWU7P7W4XBAx42rn7XhD7XgJvLsBYemezzXjSw MzR+8vuP3TylZkotmK1eF9Lk7NtwihnXx6CAc= MIME-Version: 1.0 Received: by 10.220.187.76 with SMTP id cv12mr2199756vcb.128.1307991623567; Mon, 13 Jun 2011 12:00:23 -0700 (PDT) Received: by 10.220.189.202 with HTTP; Mon, 13 Jun 2011 12:00:23 -0700 (PDT) Date: Mon, 13 Jun 2011 12:00:23 -0700 Message-ID: From: Garrett Cooper To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Opening a character device from a helper driver? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 19:00:27 -0000 Hi, Just to confirm whether or not this is the best way, say I had a module foo(4) that pokes at /dev/bar0, which is attached to bar(4). Should I setup the foo(4) driver with the same class as bar(4) and use KPIs like device_get_parent(9) to get the device_t structure and pass it along to bar(4)'s helper/ioctl functions, or is there a better way to skin the proverbial cat? I'm basing this observation off what I see in /sys/dev/uart_bus_puc.c . Thanks! -Garrett From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 19:01:43 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8131F1065677 for ; Mon, 13 Jun 2011 19:01:43 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [46.28.110.116]) by mx1.freebsd.org (Postfix) with ESMTP id 42F7F8FC1D for ; Mon, 13 Jun 2011 19:01:42 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id 2FCDB7F3A8C; Mon, 13 Jun 2011 20:24:58 +0200 (CEST) Date: Mon, 13 Jun 2011 20:24:58 +0200 From: Roman Divacky To: Ewart Tempest Message-ID: <20110613182458.GA98506@freebsd.org> References: <4DF6191B.2030407@jnpr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DF6191B.2030407@jnpr.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org, Ewart Tempest Subject: Re: dwarf2 reader X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 19:01:43 -0000 There's our very own http://sourceforge.net/apps/trac/elftoolchain/wiki/libdwarf On Mon, Jun 13, 2011 at 10:05:15AM -0400, Ewart Tempest wrote: > I have developed some flight recording capability in the JUNOS FreeBSD > based kernel, with the flight recorded data being captured in binary > form for performance. All the subsequent formatting and display of this > data is performed by a user-space application. I would like to reduce > the amount of time that designers spend writing formatters to display > their flight recorded data. kgdb is perfectly capable of displaying all > kernel resident data structures, and the manner in which it does so is > perfectly acceptable for flight recording purposes. The code that kgdb > uses to support this framework is difficult to break out - does anyone > know of a dwarf2 reader s/w implementation that is more re-usable? > > Ewart > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 22:52:23 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1296106564A for ; Mon, 13 Jun 2011 22:52:23 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 3CF438FC14 for ; Mon, 13 Jun 2011 22:52:23 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 477F91DD731 for ; Tue, 14 Jun 2011 00:52:10 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id 2F93917349; Tue, 14 Jun 2011 00:52:10 +0200 (CEST) Date: Tue, 14 Jun 2011 00:52:10 +0200 From: Jilles Tjoelker To: freebsd-hackers@freebsd.org Message-ID: <20110613225210.GC65312@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [PATCH] [RFC] sh(1) vfork support X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 22:52:23 -0000 The below patch changes sh to use vfork(2) instead of fork(2) in some simple cases: a foreground simple command, not being a command substitution, without redirections or assignments in a non-interactive shell with job control disabled. By restricting the use of vfork, different from what NetBSD has done, I limit what code is executed in the vforked child process. For example, there is no way opening general redirections in a vforked background process can work, as opening a fifo may block, and any long-term blocking of a vforked-but-not-execed process is bad. Background simple commands are also excluded because our current approach of expanding their arguments in the main shell environment is incorrect (zsh is broken in the same way). The restriction to non-interactive shells with job control disabled also limits the amount of code I have to copy to the vfork code path. Command substitutions containing one simple command could also use vfork but this needs a little extra code. The patch does not depend on the memory sharing semantics of vfork. As a result, however, it calls strerror() (and therefore all sorts of NLS code) and stdio in the child, in the case that exec fails. Even in the normal case, malloc() may be called to allocate space for the full pathname of each executable to be tried. This could be fixed by reserving enough space for the pathname first and passing the errno value back through memory and printing the message in the parent process but this also introduces additional differences with the regular code path. The functions setjmp() and longjmp() are also used but only within a process; no jump is made by the vforked process outside vforkexecshell(). Simple tests on various microbenchmarks (i386, calling /bin/echo 10000 times, possibly from multiple processes at once) show a performance improvement of 20-30%. The gain might be bigger on embedded architectures where less time has been spent to optimize fork(2). Unfortunately, it looks like rc.d may not be helped much by this. It uses many subshells, most of which require a full fork() with the current implementation of sh. Index: bin/sh/jobs.h =================================================================== --- bin/sh/jobs.h (revision 223060) +++ bin/sh/jobs.h (working copy) @@ -91,6 +91,7 @@ void showjobs(int, int); struct job *makejob(union node *, int); pid_t forkshell(struct job *, union node *, int); +pid_t vforkexecshell(struct job *, char **, char **, const char *, int); int waitforjob(struct job *, int *); int stoppedjobs(void); int backgndpidset(void); Index: bin/sh/eval.c =================================================================== --- bin/sh/eval.c (revision 223024) +++ bin/sh/eval.c (working copy) @@ -899,6 +899,15 @@ if (pipe(pip) < 0) error("Pipe call failed: %s", strerror(errno)); } + if (cmdentry.cmdtype == CMDNORMAL && + cmd->ncmd.redirect == NULL && + varlist.list == NULL && + mode == FORK_FG && + !iflag && !mflag) { + vforkexecshell(jp, argv, environment(), path, + cmdentry.u.index); + goto parent; + } if (forkshell(jp, cmd, mode) != 0) goto parent; /* at end of routine */ if (flags & EV_BACKCMD) { Index: bin/sh/jobs.c =================================================================== --- bin/sh/jobs.c (revision 223060) +++ bin/sh/jobs.c (working copy) @@ -57,6 +57,7 @@ #undef CEOF /* syntax.h redefines this */ #endif #include "redir.h" +#include "exec.h" #include "show.h" #include "main.h" #include "parser.h" @@ -884,7 +885,48 @@ } +pid_t +vforkexecshell(struct job *jp, char **argv, char **envp, const char *path, int idx) +{ + pid_t pid; + struct jmploc jmploc; + struct jmploc *savehandler; + TRACE(("vforkexecshell(%%%td, %p, %d) called\n", jp - jobtab, (void *)n, + mode)); + INTOFF; + flushall(); + savehandler = handler; + pid = vfork(); + if (pid == -1) { + TRACE(("Vfork failed, errno=%d\n", errno)); + INTON; + error("Cannot fork: %s", strerror(errno)); + } + if (pid == 0) { + TRACE(("Child shell %d\n", (int)getpid())); + if (setjmp(jmploc.loc)) + _exit(exception == EXEXEC ? exerrno : 2); + handler = &jmploc; + shellexec(argv, envp, path, idx); + } + handler = savehandler; + if (jp) { + struct procstat *ps = &jp->ps[jp->nprocs++]; + ps->pid = pid; + ps->status = -1; + ps->cmd = nullstr; + jp->foreground = 1; +#if JOBS + setcurjob(jp); +#endif + } + INTON; + TRACE(("In parent shell: child = %d\n", (int)pid)); + return pid; +} + + /* * Wait for job to finish. * -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 14 01:39:15 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98BF4106564A for ; Tue, 14 Jun 2011 01:39:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5472F8FC0C for ; Tue, 14 Jun 2011 01:39:15 +0000 (UTC) Received: by ywf7 with SMTP id 7so3378033ywf.13 for ; Mon, 13 Jun 2011 18:39:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qVF6cwtWJOXwVfQxnIHtFIP44tC19Vfj4O6vQTyMPrM=; b=AhiQnQErKLrn7QwOsc0I7t0nseo5U9N+9mynj+f2qXDmOBM7OWFq7n0B97CsVXWKhy zOw5tOqqkKfnagFRqtqtBa6TWNdkXC0KeiJbnHDG0rsLJwDhdd1yOtOokivLMxE3VPVh 8QZlSQ5wFEPFeDKy37W2s9eNgQEz43gqVnca4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=q26rEuV2rpL7h7/FzBmNZuPV7+nJ7r14GBPJLN229FhDxkDg7KZlLqfHzAFbOIltn0 BQaRzWkUOv2PpkazpsRyrHnE7Fop2OCnj4e8zW61YaMjQsGvQiwMIYAz2zjfjon1Wkux P0G2ctTdxPPlwneAXFHgP40tJi5N3FdA9P7os= MIME-Version: 1.0 Received: by 10.150.74.17 with SMTP id w17mr7011437yba.274.1308015554403; Mon, 13 Jun 2011 18:39:14 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.150.216.3 with HTTP; Mon, 13 Jun 2011 18:39:14 -0700 (PDT) In-Reply-To: <20110613225210.GC65312@stack.nl> References: <20110613225210.GC65312@stack.nl> Date: Tue, 14 Jun 2011 09:39:14 +0800 X-Google-Sender-Auth: fVh2LLjOLnRQgMysZxSYYLroWjY Message-ID: From: Adrian Chadd To: Jilles Tjoelker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] [RFC] sh(1) vfork support X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 01:39:15 -0000 If you're going to go down this path, would you mind making it depend upon the contents of an environment variable? Ie, DO_SH_VFORK=3D"yes|no" Then debugging can occur without having to recompile sh. I ask simply because I've been down this path before in other projects, and trying to debug vfork() vs fork() (and getting users to patch source code to test) became extremely tedious and annoying. 2c, Adrian On 14 June 2011 06:52, Jilles Tjoelker wrote: > The below patch changes sh to use vfork(2) instead of fork(2) in some > simple cases: a foreground simple command, not being a command > substitution, without redirections or assignments in a non-interactive > shell with job control disabled. > > By restricting the use of vfork, different from what NetBSD has done, I > limit what code is executed in the vforked child process. For example, > there is no way opening general redirections in a vforked background > process can work, as opening a fifo may block, and any long-term > blocking of a vforked-but-not-execed process is bad. > > Background simple commands are also excluded because our current > approach of expanding their arguments in the main shell environment is > incorrect (zsh is broken in the same way). > > The restriction to non-interactive shells with job control disabled also > limits the amount of code I have to copy to the vfork code path. > > Command substitutions containing one simple command could also use vfork > but this needs a little extra code. > > The patch does not depend on the memory sharing semantics of vfork. As a > result, however, it calls strerror() (and therefore all sorts of NLS > code) and stdio in the child, in the case that exec fails. Even in the > normal case, malloc() may be called to allocate space for the full > pathname of each executable to be tried. This could be fixed by > reserving enough space for the pathname first and passing the errno > value back through memory and printing the message in the parent process > but this also introduces additional differences with the regular code > path. > > The functions setjmp() and longjmp() are also used but only within a > process; no jump is made by the vforked process outside > vforkexecshell(). > > Simple tests on various microbenchmarks (i386, calling /bin/echo 10000 > times, possibly from multiple processes at once) show a performance > improvement of 20-30%. The gain might be bigger on embedded > architectures where less time has been spent to optimize fork(2). > > Unfortunately, it looks like rc.d may not be helped much by this. It > uses many subshells, most of which require a full fork() with the > current implementation of sh. > > Index: bin/sh/jobs.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 > --- bin/sh/jobs.h =A0 =A0 =A0 (revision 223060) > +++ bin/sh/jobs.h =A0 =A0 =A0 (working copy) > @@ -91,6 +91,7 @@ > =A0void showjobs(int, int); > =A0struct job *makejob(union node *, int); > =A0pid_t forkshell(struct job *, union node *, int); > +pid_t vforkexecshell(struct job *, char **, char **, const char *, int); > =A0int waitforjob(struct job *, int *); > =A0int stoppedjobs(void); > =A0int backgndpidset(void); > Index: bin/sh/eval.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 > --- bin/sh/eval.c =A0 =A0 =A0 (revision 223024) > +++ bin/sh/eval.c =A0 =A0 =A0 (working copy) > @@ -899,6 +899,15 @@ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (pipe(pip) < 0) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0error("Pip= e call failed: %s", strerror(errno)); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (cmdentry.cmdtype =3D=3D CMDNORMAL && > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cmd->ncmd.redirect =3D=3D NULL && > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 varlist.list =3D=3D NULL && > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mode =3D=3D FORK_FG && > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 !iflag && !mflag) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vforkexecshell(jp, argv, en= vironment(), path, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cmdentry.u.index); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto parent; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 } > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (forkshell(jp, cmd, mode) !=3D 0) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto parent; =A0 =A0/* at = end of routine */ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (flags & EV_BACKCMD) { > Index: bin/sh/jobs.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 > --- bin/sh/jobs.c =A0 =A0 =A0 (revision 223060) > +++ bin/sh/jobs.c =A0 =A0 =A0 (working copy) > @@ -57,6 +57,7 @@ > =A0#undef CEOF =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* syntax.h redefin= es this */ > =A0#endif > =A0#include "redir.h" > +#include "exec.h" > =A0#include "show.h" > =A0#include "main.h" > =A0#include "parser.h" > @@ -884,7 +885,48 @@ > =A0} > > > +pid_t > +vforkexecshell(struct job *jp, char **argv, char **envp, const char *pat= h, int idx) > +{ > + =A0 =A0 =A0 pid_t pid; > + =A0 =A0 =A0 struct jmploc jmploc; > + =A0 =A0 =A0 struct jmploc *savehandler; > > + =A0 =A0 =A0 TRACE(("vforkexecshell(%%%td, %p, %d) called\n", jp - jobta= b, (void *)n, > + =A0 =A0 =A0 =A0 =A0 mode)); > + =A0 =A0 =A0 INTOFF; > + =A0 =A0 =A0 flushall(); > + =A0 =A0 =A0 savehandler =3D handler; > + =A0 =A0 =A0 pid =3D vfork(); > + =A0 =A0 =A0 if (pid =3D=3D -1) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 TRACE(("Vfork failed, errno=3D%d\n", errno)= ); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTON; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 error("Cannot fork: %s", strerror(errno)); > + =A0 =A0 =A0 } > + =A0 =A0 =A0 if (pid =3D=3D 0) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 TRACE(("Child shell %d\n", (int)getpid())); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (setjmp(jmploc.loc)) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 _exit(exception =3D=3D EXEX= EC ? exerrno : 2); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 handler =3D &jmploc; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 shellexec(argv, envp, path, idx); > + =A0 =A0 =A0 } > + =A0 =A0 =A0 handler =3D savehandler; > + =A0 =A0 =A0 if (jp) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct procstat *ps =3D &jp->ps[jp->nprocs+= +]; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 ps->pid =3D pid; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 ps->status =3D -1; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 ps->cmd =3D nullstr; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 jp->foreground =3D 1; > +#if JOBS > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 setcurjob(jp); > +#endif > + =A0 =A0 =A0 } > + =A0 =A0 =A0 INTON; > + =A0 =A0 =A0 TRACE(("In parent shell: =A0child =3D %d\n", (int)pid)); > + =A0 =A0 =A0 return pid; > +} > + > + > =A0/* > =A0* Wait for job to finish. > =A0* > > -- > Jilles Tjoelker > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 15 02:23:22 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5240A106564A for ; Wed, 15 Jun 2011 02:23:22 +0000 (UTC) (envelope-from rsimmons0@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 15A3E8FC08 for ; Wed, 15 Jun 2011 02:23:21 +0000 (UTC) Received: by ywf7 with SMTP id 7so4259892ywf.13 for ; Tue, 14 Jun 2011 19:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=Z2bwnY5lXN3AujEjmb3wx6TYeW6OQkje5Ocby0JFrKw=; b=r8dBz6FTpfbkpohfVBpx4HnKEw+zdcGNLA9uicyEw5tWJ2Mx1sxCx1hjp80DB+Or6h bHU9l1+TY6ZeLJbc4tHxU0jbmPtqLXWoCL0SAwdB25s6SeGqqw4MB6e9mdYbpncSdM+I 6VQG3/6unoijNEU3kwJrovul841Gjebos6hxA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=FRG467efzxxjty0pxMlyqIJ/2e8mWLb2RVyX4tiCMUx82Q9sHUmnkNQnSxEgfUqzir aQrz0mHkXlbVyWC5LY+gJ9reL/FNTb8LwEx81mX9FcsfS+lVaDbNwNLNM8in9RRoYq1W HL9+mbh1Jc0BhhFZ+4MCi3DNZNgKhAqNuTAGw= MIME-Version: 1.0 Received: by 10.101.205.36 with SMTP id h36mr7143881anq.74.1308102812795; Tue, 14 Jun 2011 18:53:32 -0700 (PDT) Received: by 10.100.11.20 with HTTP; Tue, 14 Jun 2011 18:53:32 -0700 (PDT) Date: Tue, 14 Jun 2011 21:53:32 -0400 Message-ID: From: Robert Simmons To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: posixrules X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 02:23:22 -0000 I am a bit confused about the file /usr/share/zoneinfo/posixrules Looking through the docs, it seems that according to tzset(3) the file is "rules for POSIX-style TZ's" but after examining the file, it is identical to the file /usr/share/zoneinfo/America/New_York and the date stamp on the file is back in Feb (when 8.2-RELEASE was built), so it was not created when I ran tzsetup and selected New_York as my timezone. Can someone explain why these two files are the same? From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 15 04:20:30 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E85A2106564A for ; Wed, 15 Jun 2011 04:20:30 +0000 (UTC) (envelope-from ansarm@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id C00F98FC08 for ; Wed, 15 Jun 2011 04:20:30 +0000 (UTC) Received: by pzk27 with SMTP id 27so3840766pzk.13 for ; Tue, 14 Jun 2011 21:20:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=GNoDlKHidZEbJ/7sjyFu6jnE9DrxHNaH03P2VSwYUCE=; b=mTTr4FS3UdW47HCRvByZTk65SqChngAw7TCvDXEmVia2coCH8pG5KZ9GxyKYOBQpCt 30GtURSWeSVy7RokxKqK6I+WaJKRQmtcq2xQ+BfvSzq6zWqyWdHV1NlICAXo4jb5sFQP VqtiNo7EZM0R9EYk5Ch70Z4vRDhouQ7gzIEJ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=aOIlqjgiwD568DgN4mtqpi9+A5aOtuuJMl+cHfnPFn15GzBBKL8d+WKaLQ5ZvnuzSe o5yTEnWijV/6pZGR3MIMQbDoed/yGeqgQPksNxfYiyBdJ7pPlZzl2U/6G8zzcdhD7zZS tWyoN+VYR4n7IIuvfK9k3ZRSURREGrbiR92MQ= MIME-Version: 1.0 Received: by 10.68.39.133 with SMTP id p5mr4036pbk.243.1308109936422; Tue, 14 Jun 2011 20:52:16 -0700 (PDT) Received: by 10.68.44.72 with HTTP; Tue, 14 Jun 2011 20:52:16 -0700 (PDT) Date: Tue, 14 Jun 2011 23:52:16 -0400 Message-ID: From: Ansar Mohammed To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Shooting trouble on a PCI bus hang X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 04:20:31 -0000 Hello All, I have a system that is intermitently hanging during the initial PCI bus scan during boot. I have turned on verbose logging and I cannot break to debugger as its a hang. Can someone guide me to the relevant code section where PCI bus enumeration occurs so that I may modify the kernel source to output even more debug info. My hang occurs at the end of this partial dmesg output. Thank you! pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x100b, dev=0x0028, revid=0x21 domain=0, bus=0, slot=1, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0220, cachelnsz=8 (dwords) lattimer=0xf8 (7440 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type I/O Port, range 32, base 0xac1c, size 2, enabled found-> vendor=0x100b, dev=0x0030, revid=0x00 domain=0, bus=0, slot=1, func=1 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0220, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type Memory, range 32, base 0x41000000, size 24, enabled map[14]: type Memory, range 32, base 0x40ffc000, size 14, enabled map[18]: type Memory, range 32, base 0x40ff8000, size 14, enabled map[1c]: type Memory, range 32, base 0x40ff4000, size 14, enabled found-> vendor=0x10ec, dev=0x8139, revid=0x10 domain=0, bus=0, slot=14, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xef00, size 8, enabled map[14]: type Memory, range 32, base 0xeff00000, size 8, enabled $PIR: 0:14 INTA routed to irq 11 found-> vendor=0x1022, dev=0x2090, revid=0x03 domain=0, bus=0, slot=15, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0009, statreg=0x02a0, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type I/O Port, range 32, base 0x6000, size 3, enabled map[14]: type I/O Port, range 32, base 0x6100, size 8, enabled map[18]: type I/O Port, range 32, base 0x6200, size 6, enabled map[1c]: type I/O Port, range 32, base 0, size 5, enabled map[20]: type I/O Port, range 32, base 0x9d00, size 7, enabled map[24]: type I/O Port, range 32, base 0x9c00, size 6, enabled From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 15 16:49:26 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB42B106566B for ; Wed, 15 Jun 2011 16:49:25 +0000 (UTC) (envelope-from papowell@astart.com) Received: from astart2.astart.com (99-111-96-109.uvs.sndgca.sbcglobal.net [99.111.96.109]) by mx1.freebsd.org (Postfix) with ESMTP id BBFBF8FC08 for ; Wed, 15 Jun 2011 16:49:25 +0000 (UTC) Received: from laptop_81.private (localhost [127.0.0.1]) by astart2.astart.com (8.14.4/8.14.4) with ESMTP id p5FGME66011135 for ; Wed, 15 Jun 2011 09:22:14 -0700 (PDT) (envelope-from papowell@astart.com) Message-ID: <4DF8DC3A.5050703@astart.com> Date: Wed, 15 Jun 2011 09:22:18 -0700 From: Patrick Powell Organization: Astart Technologies User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110312 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Shooting trouble on a PCI bus hang X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: papowell@astart.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 16:49:26 -0000 On 06/14/11 20:52, Ansar Mohammed wrote: > Hello All, > I have a system that is intermitently hanging during the initial PCI bus > scan during boot. I have turned on verbose logging and I cannot break to > debugger as its a hang. Can someone guide me to the relevant code section > where PCI bus enumeration occurs so that I may modify the kernel source to > output even more debug info. > > My hang occurs at the end of this partial dmesg output. > > Thank you! > > pci0: on pcib0 > pci0: domain=0, physical bus=0 > found-> vendor=0x100b, dev=0x0028, revid=0x21 > > domain=0, bus=0, slot=1, func=0 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0005, statreg=0x0220, cachelnsz=8 (dwords) > lattimer=0xf8 (7440 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > map[10]: type I/O Port, range 32, base 0xac1c, size 2, enabled > > found-> vendor=0x100b, dev=0x0030, revid=0x00 > > domain=0, bus=0, slot=1, func=1 > class=03-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0003, statreg=0x0220, cachelnsz=8 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > map[10]: type Memory, range 32, base 0x41000000, size 24, enabled > map[14]: type Memory, range 32, base 0x40ffc000, size 14, enabled > map[18]: type Memory, range 32, base 0x40ff8000, size 14, enabled > map[1c]: type Memory, range 32, base 0x40ff4000, size 14, enabled > > found-> vendor=0x10ec, dev=0x8139, revid=0x10 > > domain=0, bus=0, slot=14, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) > intpin=a, irq=11 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type I/O Port, range 32, base 0xef00, size 8, enabled > map[14]: type Memory, range 32, base 0xeff00000, size 8, enabled > > $PIR: 0:14 INTA routed to irq 11 > found-> vendor=0x1022, dev=0x2090, revid=0x03 > > domain=0, bus=0, slot=15, func=0 > class=06-01-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0009, statreg=0x02a0, cachelnsz=8 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > map[10]: type I/O Port, range 32, base 0x6000, size 3, enabled map[14]: type > I/O Port, range 32, base 0x6100, size 8, enabled map[18]: type I/O Port, > range 32, base 0x6200, size 6, enabled map[1c]: type I/O Port, range 32, > base 0, size 5, enabled map[20]: type I/O Port, range 32, base 0x9d00, size > 7, enabled map[24]: type I/O Port, range 32, base 0x9c00, size 6, enabled > _______________________________________________ > 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" > Before you do anything else, get another set of hardware and try the same thing on it. I had a similar problem that turned out to be a bad SATA controller. It was only by accident that we had two identical systems, one good and one bad. -- Patrick Powell Astart Technologies papowell@astart.com 1530 Jamacha Road, Suite X, Network and System San Diego, CA 92019 Consulting 858-874-6543 Web Site: www.astart.com From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 15 17:44:27 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DFC4106566C; Wed, 15 Jun 2011 17:44:27 +0000 (UTC) (envelope-from mitchell@wyatt672earp.force9.co.uk) Received: from relay.pcl-ipout02.plus.net (relay.pcl-ipout02.plus.net [212.159.7.100]) by mx1.freebsd.org (Postfix) with ESMTP id 699CC8FC0A; Wed, 15 Jun 2011 17:44:23 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMvn+E3Unw4R/2dsb2JhbABRAaZWd4h1v0ODSAGCXQSWKYsW Received: from outmx02.plus.net ([212.159.14.17]) by relay.pcl-ipout02.plus.net with ESMTP; 15 Jun 2011 18:15:10 +0100 Received: from [81.174.221.217] (helo=localhost.invalid) by outmx02.plus.net with esmtp (Exim) id 1QWtgB-00049i-GC; Wed, 15 Jun 2011 18:15:10 +0100 From: Frank Mitchell To: ukfreebsd@uk.freebsd.org, freebsd-chat@freebsd.org, freebsd-hackers@freebsd.org Date: Wed, 15 Jun 2011 16:41:08 +0100 User-Agent: KMail/1.13.5 (FreeBSD/7.4-RELEASE; KDE/4.5.5; i386; ; ) MIME-Version: 1.0 Message-Id: <201106151641.08993.mitchell@wyatt672earp.force9.co.uk> Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Subject: New Spiegel CD/DVD Burning Utility X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 17:44:27 -0000 I've invented an alternative to cdrecord/wodim and burncd, naming it "spiegel". Here's the Source Code for Linux. I tried a FreeBSD version too, but it has to be said: The Linux version works better. Hope you like the Wildebeest License. ======================================================== /* Copyright 2011 Frank Mitchell - Wildebeest License */ /* README.TXT - Spiegel v2.0 - Linux Kernel 2.6.16+ */ /* Contact: mitchell@wyatt672earp.force9.co.uk */ README Welcome to Spiegel, a simpler way to burn Iso Images on Optical Media. This Readme describes the Linux version, which needs Kernel 2.6.16 minimum to access Device Files (/dev/sr0 etc) using the SG_IO ioctl. Some debugging happened around Kernel 2.6.24, so a later version seems advisable. Spiegel assumes you're using an MMC-2 Compatible CD/DVD Writer. If it writes DVDs, or even if it just has Buffer Underrun Protection, the MMC-2 Standard should apply. Non-compatible devices probably haven't been marketed since the 1990s. This First Release is Spiegel v2.0 for Linux. This writes commonly available CD and DVD media, excluding Double-Layer disks, and DVD+RW which can't be used for Sequential Recording. Other RW media must be blanked before re-use, preferably completely, but not formatted. Spiegel is an interactive Console Utility, which uses Real-Time Priority and thus needs to be run by Root. This First Release deals with problems merely by trying to detect them at an early stage and crashing harmlessly with an Error Message. To facilitate burning multiple copies of Iso Images with complicated names, you can set a Symbolic Link: "IsoLink" to your Iso Image Pathname. Spiegel has some Command Line Options too. Brackets [] indicate Default Values: -b INT: Set Write Buffer Ring Factor 10-20 [11] Spiegel needs a ring of Memory Buffers with a total size larger than the capacity of your CD/DVD Writer Cache. Taking the unit as 1/8 the size of your Hardware Cache, the range 10 - 20 gives a factor 1.25 - 2.5 larger. -c INT: Set CD Speed Limit [Max KB/Sec] [4x=706,8x=1411,10x=1764,16x=2822,24x=4234,32x=5645,40x=7056,48x=8467] When you set the Write Speed, it usually works as a Speed Limit. You can specify a higher number, and your drive will select a lower value based on the Optical Power Calibration of your media. CDs and DVDs use entirely different ranges, so it's clearer to specify the value in Kilobytes/Second. Common CD values are listed above. -d INT: Set DVD Speed Limit [Max KB/Sec] [1x=1385,2x=2770,4x=5540,6x=8310,8x=11080,12x=16620,16x=22160] These are the common values for DVD Speeds. If you need to impose limits, it's useful to keep the Command Line in a tiny Script File, with the CD and DVD Speed Limits set independently. -h : Display Brief Help Reminds you of these options. -p INT: Set Real-Time Priority [Mid-Range] [Probably 1 (Lowest) - 99 (Highest) with Default = 50] Spiegel uses Real-Time Priorities so the Write Process gets precedence over other User Tasks. If you're not the Super-User you can't set Real-Time Priorities, and Spiegel will crash harmlessly. -v : Display Version & Licensing Message Says Spiegel v2.0 is Copyright 2011 by Frank Mitchell, and released under the Wildebeest License, shown below. RUNNING SPIEGEL Example Compile command with output "Make.out", containing details of the Link Stage: "make -kB >& Make.out" For Sequential Recording, CD/DVD RW media must be blanked before re-use, preferably completely, but not formatted: "wodim blank=all dev=/dev/scd0 -v" You may need to limit the Write Speed if you want your disks to be readable in other drives besides your own DVD Re-Writer. For instance: I have an ATAPI UDMA-66 DVD Burner, connected with the required 80-Wire PATA Cable. And I also have an ATAPI UDMA-33 DVD Read-Only Drive, connected with an old 40-Wire PATA Cable. I can record DVD-R at 16x Speed = 22160 KB/Sec, but my DVD Reader will only see DVD-R recorded at 12x Speed = 16620 KB/Sec. DVD+R doesn't seem to have this problem. CD-R can benefit from Test Runs to decide what Write Speed you want. My Write Runs always use Buffer Under-Run Protection, but Constant Angular Velocity implies that the Write Speed keeps increasing. So I prefer the original technique of using Test Runs Without Buffer Under-Run Protection until I don't see the message: "RUN FAILED: WRITE COMMAND ERROR". This happens at 48x Speed = 8467 KB/Sec, but I can solve the problem by increasing the Real-Time Priority from 50 to 75. You'll need an Iso Image File to record, created using mkisofs/genisoimage. I tend to select the sub-trees I want to record using Symbolic Links in a Directory called DBACK, which then corresponds to the root of my DVD-R: "genisoimage -f -D -R -o Rock.iso ./DBACK" If desired, you can set a Symbolic Link to the Iso Image Filepath: "ln -sf /mnt/OS/IMG/Rock.iso IsoLink" Spiegel accepts "IsoLink" as the Default, so you can get your filename just by pressing Return. Here's what an Interactive Run looks like: ./spiegel20 "Spiegel Uses Real-Time Priority: Be Root!" "DISK NEEDED NOW" "Proceed? [Y]" [Ret] "SPECIFY DEVICE IN /dev/ [sr0]" [Ret] "DEVICE FILE OPENED, UNIT STARTED, UNIT TESTED READY" "Current Profile: 000Ah, Re-Writable CD-RW" "Max Read & Write Speeds KB/Sec Now: 1764, 1764" "Capacity Already Used: 239.5 Meg" "Before Run Free Space: 441.1 Meg" "Choose Iso Image Path [IsoLink]" [Ret] "Space Needed: 127.7 Meg, Free Space Fraction: 28.95%" "After Run Free Space < 313.4 Meg" "Allow Further Sessions? [Y]" [Ret] "Set Write Speed KB/Sec [1764]" [Ret] "Max Read & Write Speeds KB/Sec Now: 7056, 1764" "Will This Be A Test Run? [Y]" [Ret] "Use Under-Run Protection? [N]" [Ret] "Last Chance To Abandon Run! Proceed? [Y]" [Ret] "WAIT UNTIL CLOSE SESSION MESSAGE APPEARS" "Skip CLOSE SESSION In Test Mode" "That Was A Test: Repeat Run? [Y]" [Ret] "Set Write Speed KB/Sec [1764]" [Ret] "Max Read & Write Speeds KB/Sec Now: 7056, 1764" "Will This Be A Test Run? [Y]" N "Last Chance To Abandon Run! Proceed? [Y]" [Ret] "WAIT UNTIL CLOSE SESSION MESSAGE APPEARS" "WAIT DURING CLOSE SESSION" "Predicted Time Remaining: 15.1 Sec" "Completed CLOSE SESSION" "Max Read & Write Speeds KB/Sec Now: 7056, 1764" "REMOVE DISK NOW" For Multi-Session you need to supply mkisofs/genisoimage with the Start Address of the Session you want to import, and the Start Address of the Session you want to write next. You can get these numbers from the READ TRACK INFORMATION sections in Spiegel.log, but you need to perform a repeat Dummy Run of Spiegel. After your first Session, you'll discover that READ TRACK INFORMATION lists TWO Sessions and TWO Tracks. This is because the unwritten area of the disk is treated as a Track, called the "Invisible Track". So its Start Address is the Next Writable Address, and its Length corresponds to the Free Space left on your disk. Thus after your Initial Session you get: Track #1, Session #1: Track Start Address = 0 (For Importing) Track #2, Session #2: Track Start Address = Next Writable Address Those two numbers are the ones you need to quote using the -C Option when you Import data from one Session to the next on a Multi-Session Disk. READ TRACK INFORMATION is an MMC Command, and all the Spiegel Source Code revolves around these. For more information about MMC, try to get the T10 Standards "mmc2r11a.pdf" and "spc2r20.pdf", also the later versions, which contain the same information but getting more complicated. CHANGELOG First Release: Spiegel v2.0 for Linux, Copyright 2011 by Frank Mitchell. Contact: mitchell@wyatt672earp.force9.co.uk. This uses Sequential Recording to write a single file to commonly available CD and DVD Media. Spiegel is a recent invention, but I have tested it and started using it for real. Incidentally, "Spiegel" is German for "Mirror". TODO This first release of Spiegel v2.0 dated June 2011, has only been tried by the original author Frank Mitchell. Some unresolved issues can be expected, involving the Documentation if not the Program itself. Spiegel is still untidy, with a mixture of Function Parameters and Global Variables. I left this for now. Maybe this is one type of Application where it makes sense to use Global Variables. And some people won't agree with the many goto Statements, a legacy from years of Fortran Programming. Note how most of these are used to crash out to an Error Message. You'll notice I'm fond of CAPITAL LETTERS too: That's from Fortran again. And the Comment Statements which follow Curly Brackets are actually Footnotes which describe the code above. Spiegel.log is informative, and shows how much data can be collected from your CD/DVD Drive just by asking. But much of the information could be redundant, depending how you want to develop the application further. A FreeBSD version of Spiegel is possible, using ioctl IOCATAREQUEST with struct ata_ioc_request. But I understand this interface will change shortly. And for some reason the Write Speed for CD-R on my drive is limited under FreeBSD. I get Buffer Under-Runs above 24x = 4234 KB/Sec. WILDEBEEST LICENSE PREAMBLE: The Licenses for most Software are designed to repudiate any legal liability if it doesn't work. By contrast, the Wildebeest License tries to ensure that it will work, and that you know about any problems beforehand. No permission is needed to modify your Software to serve its intended purpose, because United States and European Union Law both allow Lawful Users to do this anyway. So when this License speaks of Free Software, we mean that you don't need to pay money for it, not that you can modify it until it stops working and nobody understands why. Open Source Users will be aware of such problems when using Free Software, and check for reliability before depending on it. So instead of including a Warranty Disclaimer which could be invalid, the Wildebeest License seeks to ensure that reliablity issues are documented. Note that Software is not patentable under European Law, though it can be covered by a patent for another invention which is. Also, Multiple Licensing is possible, so you can contact the Original Author if you believe the terms of the Wildebeest License need to be altered. 1: This version of the Wildebeest License is intended to be governed by the Legal System of England, which entitles Lawful Users to modify Software if necessary for their own use. You can correct it or adapt it to serve its intended purpose, study its operation and incorporate any underlying ideas into completely different Software licensed under other terms, and make as many Backup or Development Copies as you wish. 2: For Users this Software is intended as a Free Gift, available free of charge apart from incidental expenses, and free from any other obligation beyond the provisions of Copyright and other legal requirements. 3: If you distribute this Software or a modified version to other people, you must do so under the terms of this License. You must ensure that the relevant Documentation and Source Code are available. If you are aware of problems, you must check the Documentation and ensure they are described. This could mean adding Comment Statements to the Source Code as well as editing plaintext documents. 4: If you distribute an adaptation of this Software or a modified version, you must update the Documentation, identifying yourself and your changes. The Wildebeest License does not contain a Warranty Disclaimer, so this Documentation amounts to a Limited Warranty that within the resources available, you have tested the modified Software and that in your experience it functions as future Users are likely to expect. ======================================================== # Copyright 2011 Frank Mitchell - Wildebeest License # Makefile - Spiegel v2.0 - Linux Kernel 2.6.16+ # Contact: mitchell@wyatt672earp.force9.co.uk QAFLAGS = -Wall -Wextra\ -Wshadow -Wunreachable-code -Wpointer-arith\ -Wstrict-prototypes -Wmissing-prototypes\ -Wmissing-declarations -Wredundant-decls OBJS = driver.o iface.o cddev.o writecyc.o spiegel20 : ${OBJS} cc -Wl,-t ${OBJS} -o spiegel20 driver.o : driver.c spiegel.h cc ${QAFLAGS} -c driver.c iface.o : iface.c spiegel.h cc ${QAFLAGS} -c iface.c cddev.o : cddev.c spiegel.h cc ${QAFLAGS} -c cddev.c writecyc.o : writecyc.c spiegel.h cc ${QAFLAGS} -c writecyc.c ======================================================== /* Copyright 2011 Frank Mitchell - Wildebeest License */ /* spiegel.h - Spiegel v2.0 - Linux Kernel 2.6.16+ */ /* Contact: mitchell@wyatt672earp.force9.co.uk */ #define _FILE_OFFSET_BITS 64 #define _XOPEN_SOURCE 700 #include #include #include #include #include #include #include #include #include #include #include #include #include /* Version & Licensing Messages */ #define SAPPMES "Spiegel v2.0 CD/DVD Iso Image Writer, Kernel 2.6.16+" #define CPRTMES "Copyright 2011 Frank Mitchell - Wildebeest License" #define MINTRACKL 300 /* MMC Minimum Track Length */ #define UFSPATHL 320 /* Max UFS Pathname Bytes & Null */ #define WRITE10MAX 65536 /* Max WRITE(10) Bytes Under FreeBSD v8.0+ */ #define DEFLTDEV "sr0" #define SPIEGELLOG "./Spiegel.log" typedef struct { int XferDirn; /* Data Transfer Direction */ char *XferP; /* Data Transfer Buffer */ int XferLen; /* Data Transfer Length */ uint8_t Cmd[12]; /* MMC Command*/ } MMCREQ; /* Linux ATAPI Request */ typedef char ROOTPATH[UFSPATHL]; /* UFS Root Path */ typedef char SECTOR[2048]; /* CD/DVD Sector Store */ typedef char PARMSTOR[64]; /* Write Page Storage */ #ifndef IFACE extern int GDevFil; /* Device File */ extern int GBufFac; /* Write Buffer Ring Factor */ extern off_t GIsoSize; /* Iso File Size Bytes */ extern uint32_t GDevCache; /* CDRW Hardware Buffer Size */ extern uint32_t GSeekLBA; /* Last Valid Seek Sector */ extern ROOTPATH GIsoFilPath; /* UFS Root Path */ extern SECTOR GTransBuf; /* Global Sector Buffer */ extern PARMSTOR GWritePage; /* Write Page Spec */ extern FILE *SpiegLogF; /* Spiegel Log File */ extern MMCREQ GRequest; /* Linux ATAPI Request */ #endif /* driver.c */ int main(int,char**); /* Driver */ void OPTEVAL(int,char**,uint32_t*,uint32_t*); /* Handle Command Line Options */ void STARTUP(void); /* Unit Startup */ uint8_t CONFIGEVAL(void); /* Hardware Configuration */ const char *PROFILES(uint16_t,uint8_t*); /* Profile Numbers */ /* iface.c */ void SYSEVAL(int,char**); /* Misc System Data */ const char *SCHEDPOLICY(int); /* Scheduling Policies */ int DOPACKET(int,const char*,MMCREQ*); /* PACKET ioctl For SCSI Command */ const char *SENSEDESCS(uint8_t); /* Sense Keys */ void SHOWINQUIRY(void); /* INQUIRY Response */ const char *PERIPHQUALS(uint8_t); /* Peripheral Qualifiers */ const char *DEVTYPES(uint8_t); /* Peripheral Device Types */ const char *ANSIVERSIONS(uint8_t); /* ANSI Versions Implemented */ void DEFLTWRITE(void); /* Reset To Default Write Page */ const char *NOTIFICATIONS(uint8_t); /* Event Status Notification Types */ void BIGEND2(void*,void*); /* Reverse 2 Bytes To Other Endian */ void BIGEND4(void*,void*); /* Reverse 4 Bytes To Other Endian */ void SPLITEND2(void*,void*,void*); /* Assemble 2 Byte Integer */ int GETYN(const char*,char); /* Get Y/N Response To Prompt */ int GETINT(const char*,int); /* Get Integer Response To Prompt */ void GETSTR(const char*,char*,const char*,size_t); /* Get String Response To Prompt */ /* cddev.c */ void DRIVEEVAL(void); /* Hardware Parameter Pages */ void SHOWCAPABILITIES(uint16_t*); /* CD Capabilities & Mechanical Status Page */ void SHOWWRITEPARAMS(const char*); /* Write Parameters Mode Page */ const char *WRITETYPES(uint8_t); /* Write Types */ const char *TRACKMODES(uint8_t); /* Track Modes */ const char *MULTISESSCLOSES(uint8_t); /* Multisession Closures */ const char *DATABLOCKTYPES(uint8_t); /* Data Block Types */ const char *SESSIONFORMATS(uint8_t); /* Session Format Types */ int DISCEVAL(uint16_t*,uint16_t*,uint16_t*); /* Disc Evaluation */ int DISCINFO(uint16_t*,uint16_t*,uint16_t*); /* CDB 0x51, READ DISC INFORMATION */ const char *DISCSTATUSS(uint8_t); /* Disc Statuses */ const char *LASTSESSIONS(uint8_t); /* Last Session States */ const char *DISCTYPES(uint8_t); /* Disc Types */ uint32_t SESSEVAL(uint32_t*,uint16_t,uint16_t); /* Sessions Evaluation */ uint32_t TRACKINFO(uint32_t*); /* CDB 0x52, READ TRACK INFORMATION */ const char *DATAMODES(uint8_t); /* Data Modes */ /* writecyc.c */ uint32_t WRITESPEED(uint32_t,uint32_t,uint32_t,uint8_t,const char*); /* Limit Streaming Speed */ uint8_t WRITEPARMS(uint8_t,uint8_t); /* Set Up Write Parameters Mode Page */ int TESTBURN(uint8_t,uint32_t,uint16_t,uint8_t); /* CDR Writer Driver */ int CLOSEWAIT(uint8_t); /* CLOSE SESSION When Not Test Mode */ ======================================================== /* Copyright 2011 Frank Mitchell - Wildebeest License */ /* driver.c - Spiegel v2.0 - Linux Kernel 2.6.16+ */ /* Contact: mitchell@wyatt672earp.force9.co.uk */ #include "spiegel.h" int main(int argc,char **argv) { const char *Here="@MAIN"; uint8_t WriteMode,NextSess,CloseFunc; int Kyn,DiscStatus,IsoFildes; uint32_t WriteStart,WriteEnd,IsoBlocks, NeedBlocks,FreeBlocks,CdSpeed,DvdSpeed,WritePerf; uint16_t FirstTrackN,LastTrackN,SessTot; float Frac,FreeMeg,NeedMeg; struct stat IsoStat; printf("Spiegel Uses Real-Time Priority: Be Root!\n"); /* Command Line Options & Log Files */ OPTEVAL(argc,argv,&CdSpeed,&DvdSpeed); SYSEVAL(argc,argv); /* Check System Data */ STARTUP(); /* Unit Startup */ DRIVEEVAL(); /* Read Hardware Data Pages */ WriteMode=CONFIGEVAL(); /* Check Profile List For Write Type Needed */ /* Overall Streaming Speeds */ WriteStart=0; /* Negative Values Not Accepted */ WriteEnd=0x7FFFFFFF; WritePerf=(WriteMode&0x01)?CdSpeed:DvdSpeed; /* CD Or DVD ? */ WritePerf=WRITESPEED(WriteStart,WriteEnd,WritePerf,1, "Initial Mixed Read/Write Streaming Speeds"); /* Read Disk Track & Session Data */ DiscStatus=DISCEVAL(&FirstTrackN,&LastTrackN,&SessTot); FreeBlocks=SESSEVAL(&WriteStart,FirstTrackN,LastTrackN); FreeMeg=(float)FreeBlocks/512.0; printf("Before Run Free Space: %3.1f Meg\n",FreeMeg); /* Can Set Symbolic Link Default: "ln -sf ImagePath.iso IsoLink" */ GETSTR("\tChoose Iso Image Path [%s]\n",GIsoFilPath,"IsoLink",UFSPATHL); fprintf(SpiegLogF,"\nChosen Iso Image Path:\n\t%s\n",GIsoFilPath); if((IsoFildes=open(GIsoFilPath,O_RDONLY))==-1)goto BADOPENFIL; if(stat(GIsoFilPath,&IsoStat)==-1)goto COULDNTSTAT; GIsoSize=IsoStat.st_size; close(IsoFildes); /* Check Enough Data Blocks Available */ if(GIsoSize&2047)printf("WARNING: CD Image Ends With Partial Sector\n"); IsoBlocks=(GIsoSize+2047)>>11; if((IsoBlocks>360000)&&(GIsoSize&32767)) printf("NOTE: DVD Image Ends With Partial Superblock\n"); NeedBlocks=(IsoBlocks>MINTRACKL)?IsoBlocks:MINTRACKL; NeedBlocks=(WriteMode&0x01)?NeedBlocks:(((NeedBlocks+15)>>4)<<4); /* DVD Superblocks */ NeedMeg=(float)NeedBlocks/512.0; Frac=NeedMeg*100.0/FreeMeg; printf("Space Needed: %3.1f Meg, Free Space Fraction: %4.2f%%\n",NeedMeg,Frac); FreeMeg=(float)((int)FreeBlocks-(int)NeedBlocks)/512.0; /* Blocks To Megabytes */ printf("After Run Free Space < %3.1f Meg\n",FreeMeg); if(NeedBlocks>FreeBlocks)goto NOROOM; WriteEnd=WriteStart+NeedBlocks; /* Specify Multi Session Mode */ Kyn=GETYN("\tAllow Further Sessions? [%c]\n",'Y'); if(Kyn=='Y') { NextSess=0xC6; /* Multi-Session Field=11b */ CloseFunc=2; /* Normal CLOSE SESSION */ } /* Leaves Disk Open */ else { NextSess=0x06; /* Next Session B0 Pointer Disabled */ CloseFunc=(WriteMode&0x08)?5:2; /* DVD+R CLOSE SESSION */ } /* For Write-Protected Disk */ /* Write Cycle Loop */ do { WritePerf=GETINT("\tSet Write Speed KB/Sec [%d]\n",WritePerf); WritePerf=WRITESPEED(WriteStart,WriteEnd,WritePerf,0, "Independent Write Speed Set For Recorded Region"); WriteMode=WRITEPARMS(WriteMode,NextSess); Kyn=GETYN("\tLast Chance To Abandon Run! Proceed? [%c]\n",'Y'); if(Kyn=='N')break; Kyn=TESTBURN(WriteMode,WriteStart,LastTrackN,CloseFunc); if(Kyn)goto OFFLINE; DEFLTWRITE(); /* Clear Test Track Data */ if((WriteMode&0x10)==0)break; /* Write Run Done */ Kyn=GETYN("\tThat Was A Test: Repeat Run? [%c]\n",'Y'); if(Kyn=='N')break; } while(1); /* Restore Streaming Speed Defaults */ WRITESPEED(0,0x7FFFFFFF,0x7FFFFFFF,4,"Restore Streaming Speed Defaults"); /* Stop Unit */ memset(&GRequest,0,sizeof(GRequest)); GRequest.Cmd[0]=0x1B; /* START STOP UNIT */ GRequest.Cmd[4]=0; /* No-Unload Stop */ GRequest.XferDirn=SG_DXFER_NONE; if(DOPACKET(GDevFil,"START STOP UNIT",&GRequest)!=0)goto BADSTOP; OFFLINE: if(close(GDevFil)!=0)goto BADCLOSEDEV; fprintf(SpiegLogF,"\n%s\n%s\n",SAPPMES,CPRTMES); /* Close Recording Log File */ fclose(SpiegLogF); printf("REMOVE DISK NOW\n"); exit(EXIT_SUCCESS); BADOPENFIL:printf("Couldn't open() Iso File %s\n",Here);goto STOP; COULDNTSTAT:printf("Couldn't stat() Iso File %s\n",Here);goto STOP; NOROOM:printf("Insufficient User Blocks On Empty Track %s\n",Here);goto STOP; BADSTOP:printf("Failed Unit Stop %s\n",Here);goto STOP; BADCLOSEDEV:printf("Failed Device File Close %s\n",Here);goto STOP; STOP:printf("errno Says: %s\n",strerror(errno));exit(EXIT_FAILURE); } /* Driver */ void OPTEVAL(int argc,char **argv,uint32_t *CdSpeedP,uint32_t *DvdSpeedP) { const char *Here="@OPTEVAL"; int Opt,Arg,PrioMin,PrioMax,PrioMid; struct sched_param RtParm; GBufFac=11; /* Default Write Buffer Ring Factor */ *CdSpeedP=0x7FFFFFFF; /* Default CD Speed Limit */ *DvdSpeedP=0x7FFFFFFF; /* Default DVD Speed Limit */ PrioMin=sched_get_priority_min(SCHED_FIFO); PrioMax=sched_get_priority_max(SCHED_FIFO); PrioMid=(PrioMin+PrioMax)>>1; RtParm.sched_priority=PrioMid; /* Default Mid-Range Real-Time Priority */ if(sched_setscheduler(0,SCHED_FIFO,&RtParm)==-1)goto NOREALTIME; while((Opt=getopt(argc,argv,"b:c:d:hp:v"))!=-1) { switch(Opt) { case 'b': /* Set Write Buffer Ring Factor */ sscanf(optarg," %d",&Arg); GBufFac=(Arg<10)?10:((Arg>20)?20:Arg); break; case 'c': /* Set CD Speed Limit, KB/Sec */ /* 4x=706,8x=1411,10x=1764,16x=2822,24x=4234,32x=5645,40x=7056,48x=8467 */ sscanf(optarg," %d",CdSpeedP); break; case 'd': /* Set DVD Speed Limit, KB/Sec */ /* 1x=1385,2x=2770,4x=5540,6x=8310,8x=11080,12x=16620,16x=22160 */ sscanf(optarg," %d",DvdSpeedP); break; default: case 'h': /* Display Brief Help */ printf("Spiegel Uses Real-Time Priority: Be Root!\n"); printf("IsoLink = Default Symbolic Link To Image File\n"); /* Write Buffer Ring Size = Device Buffer * 1.25 [10/8] - 2.5 [20/8] */ printf("-b INT: Set Write Buffer Ring Factor 10-20 [11]\n"); printf("-c INT: Set CD Speed Limit [Max KB/Sec]\n"); printf("-d INT: Set DVD Speed Limit [Max KB/Sec]\n"); printf("-h : Display Brief Help\n"); printf("-p INT: Set Real-Time Priority %d-%d [%d]\n", PrioMin,PrioMax,PrioMid); printf("-v : Display Version & Licensing Message\n"); exit(EXIT_SUCCESS); case 'p': /* Set Real-Time Priority */ sscanf(optarg," %d",&Arg); RtParm.sched_priority=(ArgPrioMax)?PrioMax:Arg); sched_setscheduler(0,SCHED_FIFO,&RtParm); break; case 'v': /* Display Version & Licensing Message */ printf("\n"SAPPMES"\n"CPRTMES"\n"); exit(EXIT_SUCCESS); } /* Process Options */ } /* Scan Command Line */ if((SpiegLogF=fopen(SPIEGELLOG,"w"))==NULL)goto BADOPENFIL; fprintf(SpiegLogF,"\nCOMMAND-LINE OPTIONS\n"); fprintf(SpiegLogF,"-b: Write Buffer Ring Factor: %d\n",GBufFac); fprintf(SpiegLogF,"-c: CD Speed Limit: %d Kb/Sec\n",*CdSpeedP); fprintf(SpiegLogF,"-d: DVD Speed Limit: %d Kb/Sec\n",*DvdSpeedP); fprintf(SpiegLogF,"-p: Real-Time Priority: %d\n",RtParm.sched_priority); return; NOREALTIME:printf("Real-Time FIFO Scheduling Not Set %s\n",Here);goto STOP; BADOPENFIL:printf("Failed Open File %s\n",Here);goto STOP; STOP:printf("errno Says: %s\n",strerror(errno));exit(EXIT_FAILURE); } /* Handle Command Line Options */ void STARTUP(void) { const char *Here="@STARTUP"; int Kyn; char DevAtapi[16]; /* Open Device File */ printf("DISK NEEDED NOW\n"); Kyn=GETYN("\tProceed? [%c]\n",'Y'); if(Kyn=='N')goto QUIT; strncpy(DevAtapi,"/dev/",16); GETSTR("\tSPECIFY DEVICE IN /dev/ [%s]\n",&DevAtapi[5],DEFLTDEV,11); GDevFil=open(DevAtapi,O_RDONLY); if(GDevFil==-1)goto BADDEVOPEN; /* Start Unit */ memset(&GRequest,0,sizeof(GRequest)); GRequest.Cmd[0]=0x1B; /* START STOP UNIT */ GRequest.Cmd[4]=1; /* No-Load Start */ GRequest.XferDirn=SG_DXFER_NONE; if(DOPACKET(GDevFil,"START STOP UNIT",&GRequest)!=0)goto BADSTART; /* Inquiry Data */ memset(&GRequest,0,sizeof(GRequest)); GRequest.Cmd[0]=0x12; /* INQUIRY */ GRequest.Cmd[4]=96; /* Allocation Length */ GRequest.XferP=GTransBuf; GRequest.XferLen=sizeof(GTransBuf); GRequest.XferDirn=SG_DXFER_FROM_DEV; if(DOPACKET(GDevFil,"INQUIRY",&GRequest)!=0)goto BADINQ; SHOWINQUIRY(); /* Test Unit Ready */ memset(&GRequest,0,sizeof(GRequest)); GRequest.Cmd[0]=0x00; /* TEST UNIT READY */ GRequest.XferDirn=SG_DXFER_NONE; if(DOPACKET(GDevFil,"TEST UNIT READY",&GRequest)!=0) goto BADTEST; printf("DEVICE FILE OPENED, UNIT STARTED, UNIT TESTED READY\n"); return; QUIT:printf("Quit To Insert Media %s\n",Here);goto STOP; BADDEVOPEN:printf("Open Device File Failed %s\n",Here);goto STOP; BADSTART:printf("Start Unit Failed %s\n",Here);goto STOP; BADINQ:printf("Failed Inquiry %s\n",Here);goto STOP; BADTEST:printf("Failed Test Unit Ready %s\n",Here);goto STOP; STOP:printf("errno Says: %s\n",strerror(errno));exit(EXIT_FAILURE); } /* Unit Startup */ uint8_t CONFIGEVAL(void) { const char *Here="@CONFIGEVAL"; int i,j,DescN; uint8_t WriteMode,AddLength,Active; uint16_t Jshort,CurProfl,ProflN,FeatrN; /* Display Individual Configuration Features */ memset(&GRequest,0,sizeof(GRequest)); GRequest.Cmd[0]=0x46; /* GET CONFIGURATION */ GRequest.Cmd[1]=2; /* Single Feature Mode */ Jshort=0; BIGEND2(&GRequest.Cmd[2],&Jshort); /* Profile List */ Jshort=sizeof(GTransBuf); BIGEND2(&GRequest.Cmd[7],&Jshort); /* Allocation Length */ GRequest.XferP=GTransBuf; GRequest.XferLen=sizeof(GTransBuf); GRequest.XferDirn=SG_DXFER_FROM_DEV; if(DOPACKET(GDevFil,"GET CONFIGURATION: Profile List",&GRequest)!=0)goto BADCONFIG; fprintf(SpiegLogF,"\nGET CONFIGURATION: Profile List\n"); /* Header Adds Eight Bytes To Profile List */ BIGEND2(&CurProfl,GTransBuf+6); BIGEND2(&FeatrN,GTransBuf+8); if(FeatrN!=0)goto PROFLERR; printf("Current Profile: %04Xh, %s\n",CurProfl,PROFILES(CurProfl,&WriteMode)); AddLength=(uint8_t)GTransBuf[11]; DescN=AddLength>>2; fprintf(SpiegLogF,"Profile List Entries: %d, Active [Y] & Inactive [N]\n",DescN); for(i=0;iXferDirn; SgReq.cmd_len=12; /* Using ATAPI Commands */ SgReq.mx_sb_len=sizeof(SenseBuf); SgReq.dxfer_len=RequestP->XferLen; SgReq.dxferp=RequestP->XferP; SgReq.cmdp=RequestP->Cmd; SgReq.sbp=SenseBuf; if(ioctl(DevFil,SG_IO,&SgReq)<0)return -2; if(SgReq.masked_status==0)return 0; fprintf(SpiegLogF,"\n%s: Masked Status: %d\n",Desc,SgReq.masked_status); fprintf(SpiegLogF,"errno Says: %s\n",strerror(errno)); /* SCSI Sense Codes */ SenseKey=SenseBuf[2]&0x0F; fprintf(SpiegLogF,"SCSI Sense Key: %02Xh, %s\n",SenseKey,SENSEDESCS(SenseKey)); fprintf(SpiegLogF,"Additional Sense Code ASC: %02Xh\n",SenseBuf[12]); fprintf(SpiegLogF,"Sense Code Qualifier ASCQ: %02Xh\n",SenseBuf[13]); fflush(NULL); /* Flush All Buffered Output */ return SgReq.masked_status; } /* PACKET ioctl For SCSI Command */ const char *SENSEDESCS(uint8_t SenseKey) { switch(SenseKey) { case 0x00: return "No Specific Sense Key Information"; case 0x01: return "Last Command Complete, Recovered From Error"; case 0x02: return "Logical Unit Not Ready, Cannot Be Accessed"; case 0x03: return "Non-Recovered Medium Error"; case 0x04: return "Non-Recoverable Hardware Failure"; case 0x05: return "Illegal Request, Illegal Data Parameter"; case 0x06: return "Unit Attention, Medium Changed Or Target Reset"; case 0x07: return "Data Protected, Read or Write Failed"; case 0x08: return "Encountered Blank Medium, End Of Formatted Data"; case 0x09: return "Vendor Specific Sense Key"; case 0x0A: return "Copy Command Aborted"; case 0x0B: return "Target Aborted Command, Should Retry"; case 0x0C: return "Search Found Equal Comparison"; case 0x0D: return "Data Overflowed End Of Partition"; case 0x0E: return "Source Data Miscompared Against Medium"; case 0x0F: return "Reserved Sense Key"; default: return "See SPC Sense Keys"; } } /* Sense Keys */ void SHOWINQUIRY(void) { uint8_t Jbyte; fprintf(SpiegLogF,"\nINQUIRY\n"); Jbyte=((uint8_t)GTransBuf[0]&0xE0)>>5; fprintf(SpiegLogF,"Peripheral Qualifier: %u, %s\n",Jbyte,PERIPHQUALS(Jbyte)); Jbyte=(uint8_t)GTransBuf[0]&31; fprintf(SpiegLogF,"Device Type: %02Xh, %s\n",Jbyte,DEVTYPES(Jbyte)); fprintf(SpiegLogF,"Medium Is Removable: %c\n",(GTransBuf[1]&128)?'Y':'N'); Jbyte=(uint8_t)GTransBuf[2]&7; fprintf(SpiegLogF,"ANSI Version: %s\n",ANSIVERSIONS(Jbyte)); fprintf(SpiegLogF,"Vendor ID String: %1.8s\n",>ransBuf[8]); fprintf(SpiegLogF,"Product ID String: %1.16s\n",>ransBuf[16]); fprintf(SpiegLogF,"Product Revision: %1.4s\n",>ransBuf[32]); return; } /* INQUIRY Response */ const char *PERIPHQUALS(uint8_t Code) { switch(Code) { case 0: return "Peripheral Connected, Connection Undetermined"; case 1: return "Peripheral Not Connected, Though Is Supported"; case 2: return "Reserved Peripheral Qualifier"; case 3: return "Device Server Cannot Support A Peripheral Here"; default: return "Vendor Specific Peripheral Qualifier"; } } /* Peripheral Qualifiers */ const char *DEVTYPES(uint8_t DevType) { switch(DevType) { case 0x00: return "Direct Access Block Device, Magnetic Disc"; case 0x01: return "Sequential Access Device, Magnetic Tape"; case 0x02: return "Printer Device"; case 0x03: return "Processor Device"; case 0x04: return "Write Once Device, Optical Disc"; case 0x05: return "CD/DVD Device"; case 0x06: return "Scanner Device"; case 0x07: return "Optical Memory Device, Optical Disc"; case 0x08: return "Medium Changer Device, Jukebox"; case 0x09: return "Communications Device"; case 0x0A: case 0x0B: return "ASC IT8 Device, Graphic Arts Pre-Press"; case 0x0C: return "Storage Array Controller, RAID"; case 0x0D: return "Enclosure Services Device"; case 0x0E: return "Simplified Direct Access Device"; case 0x0F: return "Optical Card Reader/Writer"; case 0x10: return "Bridge Controller Commands"; case 0x11: return "Object-Based Storage Device"; case 0x12: return "Automation/Drive Interface"; case 0x13: return "Security Manager Device"; case 0x1E: return "Well Known Logical Unit"; case 0x1F: return "Unknown - No Device Type"; default: return "Reserved Device Type"; } } /* Peripheral Device Types */ const char *ANSIVERSIONS(uint8_t Code) { switch(Code) { case 0x00: return "ATAPI Device Not Claiming SCSI Conformance"; case 0x01: return "Device Complies To ANSI X3.131:1986 (SCSI-1)"; case 0x02: return "Device Complies To ANSI X3.131:1994 (SCSI-2)"; case 0x03: return "Device Complies To ANSI INCITS 301-1997 (SPC)"; case 0x04: return "Device Complies To ANSI INCITS 351-2001 (SPC-2)"; case 0x05: return "Device Complies To ANSI INCITS 408-2005 (SPC-3)"; case 0x06: return "Device Complies To SPC-4"; default: return "Future ANSI Standard (?)"; } } /* ANSI Versions Implemented */ void DEFLTWRITE(void) { const char *Here="@DEFLTWRITE"; uint16_t Jshort; /* MODE SENSE Default Write Parameters Mode Page */ memset(&GRequest,0,sizeof(GRequest)); GRequest.Cmd[0]=0x5A; /* MODE SENSE */ GRequest.Cmd[1]=8; /* Disable Block Descriptors */ GRequest.Cmd[2]=0x85; /* Default Write Params */ Jshort=64; /* Global Write Page Size */ BIGEND2(&GRequest.Cmd[7],&Jshort); GRequest.XferP=GWritePage; /* Global Write Page */ GRequest.XferLen=64; /* Global Write Page Size */ GRequest.XferDirn=SG_DXFER_FROM_DEV; if(DOPACKET(GDevFil,"MODE SENSE Default Write Parameters",&GRequest)!=0)goto ERRSENSWR; /* Adjust Write Parameters Page */ memset(GWritePage,0,8); /* Mode Header Reserved Or Obsolete */ GWritePage[8]&=0x3F; /* Write Params Page Code */ GWritePage[10]&=0x6F; /* Ensure Zero Test Write Bit */ /* MODE SELECT Clears Test Track Data */ memset(&GRequest,0,sizeof(GRequest)); GRequest.Cmd[0]=0x55; /* MODE SELECT */ GRequest.Cmd[1]=0x10; /* Standard Page Format */ Jshort=GWritePage[9]+10; /* Header Plus Total Page Bytes */ BIGEND2(&GRequest.Cmd[7],&Jshort); GRequest.XferP=GWritePage; /* Global Write Page */ GRequest.XferLen=64; /* Global Write Page Size */ GRequest.XferDirn=SG_DXFER_TO_DEV; if(DOPACKET(GDevFil,"MODE SELECT Write Parameters",&GRequest)!=0)goto ERRSELWR; return; ERRSENSWR:printf("Error Sensing Write Params %s\n",Here);goto STOP; ERRSELWR:printf("Error Selecting Write Params %s\n",Here);goto STOP; STOP:printf("errno Says: %s\n",strerror(errno));exit(EXIT_FAILURE); } /* Reset To Default Write Page */ const char *NOTIFICATIONS(uint8_t Code) { switch(Code) { case 1: return "Operational State Change"; case 2: return "Power Management Event"; case 3: return "External Request"; case 4: return "Media Status Event"; case 5: return "Multiple Initiator Control"; case 6: return "Device Busy Event"; default: return "Reserved Event/Status Notification"; } } /* Event Status Notification Types */ void BIGEND2(void *Out16,void *In16) { uint8_t *OutByteP,*InByteP; OutByteP=(uint8_t*)Out16; InByteP=(uint8_t*)In16; *OutByteP=*(InByteP+1); *(OutByteP+1)=*InByteP; return; } /* Reverse 2 Bytes To Other Endian */ void BIGEND4(void *Out32,void *In32) { uint8_t *OutByteP,*InByteP; OutByteP=(uint8_t*)Out32; InByteP=(uint8_t*)In32; *OutByteP=*(InByteP+3); *(OutByteP+1)=*(InByteP+2); *(OutByteP+2)=*(InByteP+1); *(OutByteP+3)=*InByteP; return; } /* Reverse 4 Bytes To Other Endian */ void SPLITEND2(void *Out16,void *HiByte,void *LoByte) { uint8_t *OutByteP,*HiByteP,*LoByteP; OutByteP=(uint8_t*)Out16; HiByteP=(uint8_t*)HiByte; LoByteP=(uint8_t*)LoByte; *OutByteP=*LoByteP; *(OutByteP+1)=*HiByteP; return; } /* Assemble 2 Byte Integer */ int GETYN(const char *Prompt,char DefaultVal) { char Buf[80]; int Clen,Ryn; do { printf(Prompt,DefaultVal); memset(Buf,0,80); fgets(Buf,80,stdin); if(strcmp(Buf,"\n")==0)return toupper(DefaultVal); Clen=strlen(Buf); Ryn=toupper(Buf[Clen-2]); } while(Ryn!='Y'&&Ryn!='N'); return Ryn; } /* Get Y/N Response To Prompt */ int GETINT(const char *Prompt,int DefaultVal) { char Buf[80]; int ScanVal,Jret; do { printf(Prompt,DefaultVal); memset(Buf,0,80); fgets(Buf,80,stdin); if(strcmp(Buf,"\n")==0)return DefaultVal; ScanVal=sscanf(Buf," %d",&Jret); } while(ScanVal!=1||ScanVal==EOF); return Jret; } /* Get Integer Response To Prompt */ void GETSTR(const char *Prompt,char *RetStr,const char *Default,size_t ResLen) { char *GetStr; ssize_t GotLen; printf(Prompt,Default); memset(RetStr,0,ResLen); GetStr=calloc(ResLen,1); GotLen=getline(&GetStr,&ResLen,stdin); if(GetStr[GotLen-1]=='\n')GotLen--; GetStr[GotLen]=0; if(GetStr[0]!=0)strncpy(RetStr,GetStr,ResLen); else strncpy(RetStr,Default,ResLen); free(GetStr); return; } /* Get String Response To Prompt */ ======================================================== /* Copyright 2011 Frank Mitchell - Wildebeest License */ /* cddev.c - Spiegel v2.0 - Linux Kernel 2.6.16+ */ /* Contact: mitchell@wyatt672earp.force9.co.uk */ #include "spiegel.h" void DRIVEEVAL(void) { const char *Here="@DRIVEEVAL"; uint8_t Jbyte; uint16_t Jshort,BufCache; Jshort=sizeof(GTransBuf); /* Mode Sense CD Capabilities & Mechanical Status Page */ memset(&GRequest,0,sizeof(GRequest)); GRequest.Cmd[0]=0x5A; /* MODE SENSE */ GRequest.Cmd[1]=8; /* Disable Block Descriptors */ GRequest.Cmd[2]=0x2A; /* Current CD Capabilities Page */ BIGEND2(&GRequest.Cmd[7],&Jshort); GRequest.XferP=GTransBuf; GRequest.XferLen=sizeof(GTransBuf); GRequest.XferDirn=SG_DXFER_FROM_DEV; if(DOPACKET(GDevFil,"MODE SENSE CD Capabilities",&GRequest)!=0)goto HARDERR; SHOWCAPABILITIES(&BufCache); GDevCache=BufCache<<10; /* Device Cache Size Bytes */ fprintf(SpiegLogF,"\nCDRW Hardware Buffer: %u Bytes\n",GDevCache); /* Mode Sense Write Parameters Mode Page */ memset(&GRequest,0,sizeof(GRequest)); GRequest.Cmd[0]=0x5A; /* MODE SENSE */ GRequest.Cmd[1]=8; /* Disable Block Descriptors */ GRequest.Cmd[2]=0x05; /* Current Write Params Mode Page */ BIGEND2(&GRequest.Cmd[7],&Jshort); GRequest.XferP=GTransBuf; GRequest.XferLen=sizeof(GTransBuf); GRequest.XferDirn=SG_DXFER_FROM_DEV; if(DOPACKET(GDevFil,"MODE SENSE Current Write Parameters",&GRequest)!=0)goto HARDERR; SHOWWRITEPARAMS("Initial Drive Settings"); /* Write Page Defaults Clear Firmware Data Using Zero Test Write Bit */ DEFLTWRITE(); /* Get Event/Status Notification */ fprintf(SpiegLogF,"\nGET EVENT/STATUS NOTIFICATION\n"); memset(&GRequest,0,sizeof(GRequest)); GRequest.Cmd[0]=0x4A; /* GET EVENT/STATUS NOTIFICATION */ GRequest.Cmd[1]=1; /* Immed/Polled */ GRequest.Cmd[4]=0x54; /* Busy + Media + Power Classes */ BIGEND2(&GRequest.Cmd[7],&Jshort); GRequest.XferP=GTransBuf; GRequest.XferLen=sizeof(GTransBuf); GRequest.XferDirn=SG_DXFER_FROM_DEV; if(DOPACKET(GDevFil,"GET EVENT/STATUS NOTIFICATION",&GRequest)!=0)goto BADNOTIFGET; Jbyte=GTransBuf[2]&0x07; fprintf(SpiegLogF,"Notification Returned: %u, %s\n",Jbyte,NOTIFICATIONS(Jbyte)); if(!(GTransBuf[3]&0x40))goto NOBUSYPOLL; return; HARDERR:printf("Failed Hardware Request %s\n",Here);goto STOP; BADNOTIFGET:printf("Failed Event/Status Notification Request %s\n",Here);goto STOP; NOBUSYPOLL:printf("Cannot Poll For Device Busy Events %s\n",Here);goto STOP; STOP:printf("errno Says: %s\n",strerror(errno));exit(EXIT_FAILURE); } /* Hardware Parameter Pages */ void SHOWCAPABILITIES(uint16_t *BufCacheP) { const char *Here="@SHOWCAPABILITIES"; uint8_t Jbyte,CapsFound; char *RotCtl; uint16_t Jshort,StartByte,WriteSpeed; int j; fprintf(SpiegLogF,"\nCAPABILITIES & MECHANICAL STATUS\n"); /* Header Adds Eight Bytes To Mode Page Locations */ j=(uint8_t)GTransBuf[9]+10; memset(>ransBuf[j],0,2048-j); fprintf(SpiegLogF,"Reads CD-R: %c\n",(GTransBuf[10]&1)?'Y':'N'); fprintf(SpiegLogF,"Reads CD-RW: %c\n",(GTransBuf[10]&2)?'Y':'N'); fprintf(SpiegLogF,"Reads Method 2 Fixed Packet Addressing: %c\n",(GTransBuf[10]&4)?'Y':'N'); fprintf(SpiegLogF,"Reads DVD-ROM: %c\n",(GTransBuf[10]&8)?'Y':'N'); fprintf(SpiegLogF,"Reads DVD-R: %c\n",(GTransBuf[10]&16)?'Y':'N'); fprintf(SpiegLogF,"Reads DVD-RAM: %c\n",(GTransBuf[10]&32)?'Y':'N'); fprintf(SpiegLogF,"Writes CD-R: %c\n",(GTransBuf[11]&1)?'Y':'N'); fprintf(SpiegLogF,"Writes CD-RW: %c\n",(GTransBuf[11]&2)?'Y':'N'); fprintf(SpiegLogF,"Test Write Function Supported: %c\n",(GTransBuf[11]&4)?'Y':'N'); CapsFound=((uint8_t)GTransBuf[11]&7); /* CD-R/RW Write & Test Capability */ fprintf(SpiegLogF,"Writes DVD-R: %c\n",(GTransBuf[11]&16)?'Y':'N'); fprintf(SpiegLogF,"Writes DVD-RAM: %c\n",(GTransBuf[11]&32)?'Y':'N'); fprintf(SpiegLogF,"Reads Mode 2 Form 1 CD Sectors: %c\n",(GTransBuf[12]&16)?'Y':'N'); fprintf(SpiegLogF,"Reads Mode 2 Form 2 CD Sectors: %c\n",(GTransBuf[12]&32)?'Y':'N'); fprintf(SpiegLogF,"Reads Multi-Session CD Disks: %c\n",(GTransBuf[12]&64)?'Y':'N'); fprintf(SpiegLogF,"Supports Buffer Under-Run Free CDR/RW Recording: %c\n",(GTransBuf[12]&128)?'Y':'N'); CapsFound|=((uint8_t)GTransBuf[12]&0xC0); /* Under-Run Prot & Multi-Session Capability */ fprintf(SpiegLogF,"Reads Raw R-W Sub-Channel From Lead-In: %c\n",(GTransBuf[15]&32)?'Y':'N'); BIGEND2(&Jshort,GTransBuf+16); fprintf(SpiegLogF,"Maximum Read Speed (MMC-1) KB/sec: %hu\n",Jshort); BIGEND2(BufCacheP,GTransBuf+20); fprintf(SpiegLogF,"Buffer Cache Size KB: %hu\n",*BufCacheP); BIGEND2(&Jshort,GTransBuf+22); fprintf(SpiegLogF,"Current Read Speed (MMC-1) KB/sec: %hu\n",Jshort); BIGEND2(&Jshort,GTransBuf+26); fprintf(SpiegLogF,"Maximum Write Speed (MMC-1) KB/sec: %hu\n",Jshort); BIGEND2(&Jshort,GTransBuf+28); fprintf(SpiegLogF,"Current Write Speed (MMC-1) KB/sec: %hu\n",Jshort); fprintf(SpiegLogF,"Pure CAV Rotation Control Selected: %c\n",(GTransBuf[35]&0x03)?'Y':'N'); BIGEND2(&Jshort,GTransBuf+36); fprintf(SpiegLogF,"Current Write Speed (MMC-3) KB/sec: %hu\n",Jshort); BIGEND2(&Jshort,GTransBuf+38); fprintf(SpiegLogF,"Number Of Write Speed Performance Descriptors: %hu\n",Jshort); for(j=1;j<=Jshort;j++) { StartByte=40+((j-1)<<2); Jbyte=(uint8_t)GTransBuf[StartByte+1]&7; switch(Jbyte) { case 0:RotCtl="CLV/Part-CAV/Default";break; case 1:RotCtl="Pure CAV";break; default:RotCtl="Rotation Control Undefined"; } /* Rotation Control Types */ BIGEND2(&WriteSpeed,GTransBuf+StartByte+2); fprintf(SpiegLogF,"Write Speed KB/sec: %hu, %s\n",WriteSpeed,RotCtl); } /* List Write Speed Performance Descriptors */ if(CapsFound<0xC5)goto NOCAP; return; NOCAP:printf("Drive Lacks Essential Capability %s\n",Here);goto STOP; STOP:printf("errno Says: %s\n",strerror(errno));exit(EXIT_FAILURE); } /* CD Capabilities & Mechanical Status Page */ void SHOWWRITEPARAMS(const char *Desc) { uint8_t Jbyte; uint32_t Jlong; int j; fprintf(SpiegLogF,"\nCURRENT WRITE PARAMETERS: %s\n",Desc); /* Header Adds Eight Bytes To Mode Page Locations */ j=(uint8_t)GTransBuf[9]+10; memset(>ransBuf[j],0,2048-j); Jbyte=(uint8_t)GTransBuf[10]&0x0F; fprintf(SpiegLogF,"Write Stream Type: %02Xh, %s\n",Jbyte,WRITETYPES(Jbyte)); fprintf(SpiegLogF,"Test Writing Enabled: %c\n",(GTransBuf[10]&16)?'Y':'N'); fprintf(SpiegLogF,"Link Size Valid: %c\n",(GTransBuf[10]&32)?'Y':'N'); fprintf(SpiegLogF,"Buffer Underrun Protection Enabled: %c\n",(GTransBuf[10]&64)?'Y':'N'); Jbyte=(uint8_t)GTransBuf[11]&0x0F; /* Bit 1 Means Copy Permitted */ fprintf(SpiegLogF,"Track Mode Control Nibble: %02Xh, %s\n",Jbyte,TRACKMODES(Jbyte)); fprintf(SpiegLogF,"Fixed Packet Type: %c\n",(GTransBuf[11]&32)?'Y':'N'); Jbyte=((uint8_t)GTransBuf[11]&0xC0)>>6; fprintf(SpiegLogF,"Multisession Closure: %u, %s\n",Jbyte,MULTISESSCLOSES(Jbyte)); Jbyte=(uint8_t)GTransBuf[12]&0x0F; fprintf(SpiegLogF,"Data Block Type: %u, %s\n",Jbyte,DATABLOCKTYPES(Jbyte)); fprintf(SpiegLogF,"Linking Loss Area Size: %u\n",(uint8_t)GTransBuf[13]); Jbyte=(uint8_t)GTransBuf[16]; fprintf(SpiegLogF,"Session Format: %02Xh, %s\n",Jbyte,SESSIONFORMATS(Jbyte)); BIGEND4(&Jlong,GTransBuf+18); fprintf(SpiegLogF,"Fixed Packet Size, Blocks: %d\n",Jlong); fprintf(SpiegLogF,"Sub-Header Hex:"); for(j=56;j<60;j++)fprintf(SpiegLogF," %02X",(uint8_t)GTransBuf[j]); fprintf(SpiegLogF,"\n"); return; } /* Write Parameters Mode Page */ const char *WRITETYPES(uint8_t Code) { switch(Code) { case 0x00: return "Packet/Incremental"; case 0x01: return "Track-At-Once"; case 0x02: return "Session-At-Once"; case 0x03: return "Raw"; default: return "Reserved Write Type"; } } /* Write Types */ const char *TRACKMODES(uint8_t Code) { switch(Code) { case 0x00: return "Two Audio Channels No Pre-Emphasis"; case 0x01: return "Two Audio Channels With Pre-Emphasis"; case 0x02: return "Two Audio Channels No Pre-Emphasis"; case 0x03: return "Two Audio Channels With Pre-Emphasis"; case 0x04: return "Data Track Uninterrupted"; case 0x05: return "Data Track Incremental"; case 0x06: return "Data Track Uninterrupted"; case 0x07: return "Data Track Incremental"; case 0x08: return "Four Audio Channels No Pre-Emphasis"; case 0x09: return "Four Audio Channels With Pre-Emphasis"; case 0x0A: return "Four Audio Channels No Pre-Emphasis"; case 0x0B: return "Four Audio Channels With Pre-Emphasis"; default: return "Reserved Track Mode"; } } /* Track Modes */ const char *MULTISESSCLOSES(uint8_t Code) { switch(Code) { case 0: return "No B0 Pointer, Next Session Not Allowed"; case 1: return "B0 Pointer = FF:FF:FF, Next Session Not Allowed"; case 3: return "Next Session Allowed, B0 Pointer = Next Program Area"; default: return "Reserved Multisession Field"; } } /* Multisession Closures */ const char *DATABLOCKTYPES(uint8_t Code) { switch(Code) { case 0: return "Raw Data *2352, Not Valid For Packet"; case 1: return "Raw Data *2368 With P&Q Sub-Channel"; case 2: return "Raw Data *2448 With P-W Sub-Channel"; case 3: return "Raw Data *2448 With Raw P-W Sub-Channel"; case 7: return "Vendor Specific Data Block Type"; case 8: return "Mode 1 *2048 ISO/IEC 10149 (Mandatory)"; case 9: return "Mode 2 *2336 ISO/IEC 10149"; case 10: return "Mode 2 *2048 CD-ROM XA, Form 1 (Mandatory)"; case 11: return "Mode 2 *2056 CD-ROM XA, Form 1, With Sub-header"; case 12: return "Mode 2 *2324 CD-ROM XA, Form 2"; case 13: return "Mode 2 *2332 CD-ROM XA, Form 1, Form 2, Mixed (Mandatory)"; case 15: return "Vendor Specific Data Block Type"; default: return "Reserved Data Block Type"; } } /* Data Block Types */ const char *SESSIONFORMATS(uint8_t Code) { switch(Code) { case 0x00: return "CD-DA Or CD-ROM Type Data Disc"; case 0x10: return "CD-I Disc"; case 0x20: return "CD-ROM XA Or DDCD Disc"; default: return "Reserved Session Format Code"; } } /* Session Format Types */ int DISCEVAL(uint16_t *FirstTrackP,uint16_t *LastTrackP,uint16_t *SessTotP) { const char *Here="@DISCEVAL"; int DiscStatus; uint16_t Jshort; uint32_t Capacity,BlockLen; float MegUsed; /* Read CD Recorded Capacity */ memset(&GRequest,0,sizeof(GRequest)); GRequest.Cmd[0]=0x25; /* READ CD RECORDED CAPACITY */ GRequest.XferP=GTransBuf; GRequest.XferLen=sizeof(GTransBuf); GRequest.XferDirn=SG_DXFER_FROM_DEV; if(DOPACKET(GDevFil,"READ CAPACITY",&GRequest)!=0)goto MEDIAERR; fprintf(SpiegLogF,"\nREAD CAPACITY\n"); BIGEND4(&Capacity,>ransBuf[0]); fprintf(SpiegLogF,"Last Valid Seek LBA: %d\n",Capacity); GSeekLBA=Capacity; BIGEND4(&BlockLen,>ransBuf[4]); fprintf(SpiegLogF,"Block Length: %d\n",BlockLen); if(BlockLen!=2048)goto BLOCKWRONG; MegUsed=(float)Capacity/512.0; printf("Capacity Already Used: %3.1f Meg\n",MegUsed); /* Read Disc Information */ memset(&GRequest,0,sizeof(GRequest)); GRequest.Cmd[0]=0x51; /* READ DISC INFORMATION */ Jshort=34; BIGEND2(&GRequest.Cmd[7],&Jshort); GRequest.XferP=GTransBuf; GRequest.XferLen=sizeof(GTransBuf); GRequest.XferDirn=SG_DXFER_FROM_DEV; if(DOPACKET(GDevFil,"READ DISC INFORMATION",&GRequest)!=0)goto MEDIAERR; DiscStatus=DISCINFO(FirstTrackP,LastTrackP,SessTotP); return DiscStatus; BLOCKWRONG:printf("Wrong Block Length: 2048 Needed On Data CDs %s\n",Here);goto STOP; MEDIAERR:printf("Failed Media Request %s\n",Here);goto STOP; STOP:printf("errno Says: %s\n",strerror(errno));exit(EXIT_FAILURE); } /* Disc Evaluation */ int DISCINFO(uint16_t *FirstTrackP,uint16_t *LastTrackP,uint16_t *SessTotP) { const char *Here="@DISCINFO"; uint8_t Jbyte; uint16_t Jshort,SessTrackN; uint32_t Jlong; int DiscType,LastSessState,DiscStatus; fprintf(SpiegLogF,"\nREAD DISC INFORMATION\n"); BIGEND2(&Jshort,GTransBuf); memset(>ransBuf[Jshort+2],0,2046-Jshort); Jbyte=(uint8_t)GTransBuf[2]&0x03; fprintf(SpiegLogF,"Disc Status: %u, %s\n",Jbyte,DISCSTATUSS(Jbyte)); DiscStatus=Jbyte; Jbyte=((uint8_t)GTransBuf[2]&0x0C)>>2; fprintf(SpiegLogF,"Last Session State: %u, %s\n",Jbyte,LASTSESSIONS(Jbyte)); LastSessState=Jbyte; fprintf(SpiegLogF,"Erasable RW Medium: %c\n",(GTransBuf[2]&16)?'Y':'N'); fprintf(SpiegLogF,"First Track Number: %u\n",(uint8_t)GTransBuf[3]); *FirstTrackP=(uint16_t)GTransBuf[3]; SPLITEND2(&Jshort,>ransBuf[9],>ransBuf[4]); fprintf(SpiegLogF,"Number Of Sessions: %hu\n",Jshort); *SessTotP=Jshort; SPLITEND2(&Jshort,>ransBuf[10],>ransBuf[5]); fprintf(SpiegLogF,"First Track In Last Session: %hu\n",Jshort); SessTrackN=Jshort; SPLITEND2(&Jshort,>ransBuf[11],>ransBuf[6]); fprintf(SpiegLogF,"Last Track In Last Session: %hu\n",Jshort); *LastTrackP=Jshort; Jbyte=(uint8_t)(GTransBuf[8]); fprintf(SpiegLogF,"Disc Type: %02Xh, %s\n",Jbyte,DISCTYPES(Jbyte)); DiscType=(uint8_t)GTransBuf[8]; BIGEND4(&Jlong,GTransBuf+12); fprintf(SpiegLogF,"Disc Identification: %d\n",Jlong); fprintf(SpiegLogF,"Number Of Power-Calibrated Speeds: %u\n",(uint8_t)GTransBuf[33]); /* Cannot Continue With Inappropriate Disc */ if(DiscStatus>1)goto NOAPPEND; if(LastSessState!=0)goto NONEMPTYSESS; return DiscStatus; NOAPPEND:printf("Disc Status Not Empty Or Appendable %s\n",Here);goto STOP; NONEMPTYSESS:printf("Last Session On Disc Not Empty %s\n",Here);goto STOP; STOP:printf("errno Says: %s\n",strerror(errno));exit(EXIT_FAILURE); } /* CDB 0x51, READ DISC INFORMATION */ const char *DISCSTATUSS(uint8_t Code) { switch(Code) { case 0: return "Empty Disc"; case 1: return "Incomplete Disc, Appendable Session"; case 2: return "Finalized, Last Session Closed"; case 3: return "Random Access Only, No Sessions"; default: return "Reserved Disc Status Value"; } } /* Disc Statuses */ const char *LASTSESSIONS(uint8_t Code) { switch(Code) { case 0: return "Empty Session"; case 1: return "Incomplete Session"; case 2: return "Damaged Session"; case 3: return "Complete Session"; default: return "Reserved Session State Value"; } } /* Last Session States */ const char *DISCTYPES(uint8_t Code) { switch(Code) { case 0x00: return "CD-DA or CD-ROM Disc"; case 0x10: return "CD-I Disc"; case 0x20: return "CD-ROM XA Disc Or DDCD"; case 0xFF: return "Undefined Disc Type"; default: return "Reserved Disc Type"; } } /* Disc Types */ uint32_t SESSEVAL(uint32_t *WriteStartP,uint16_t FirstTrackN,uint16_t LastTrackN) { const char *Here="@SESSEVAL"; uint16_t Jshort; uint32_t Jlong,FreeBlocks; /* Read Track Information For All Tracks */ for(Jlong=FirstTrackN;Jlong<=LastTrackN;Jlong++) { memset(&GRequest,0,sizeof(GRequest)); GRequest.Cmd[0]=0x52; /* READ TRACK INFORMATION */ GRequest.Cmd[1]=1; /* Specify Track Number */ BIGEND4(&GRequest.Cmd[2],&Jlong); Jshort=40; BIGEND2(&GRequest.Cmd[7],&Jshort); GRequest.XferP=GTransBuf; GRequest.XferLen=sizeof(GTransBuf); GRequest.XferDirn=SG_DXFER_FROM_DEV; if(DOPACKET(GDevFil,"READ TRACK INFORMATION",&GRequest)!=0)goto MEDIAERR; FreeBlocks=TRACKINFO(WriteStartP); } /* Writable Disk Returns Data From Invisible Track */ return FreeBlocks; MEDIAERR:printf("Failed Media Request %s\n",Here);goto STOP; STOP:printf("errno Says: %s\n",strerror(errno));exit(EXIT_FAILURE); } /* Sessions Evaluation */ uint32_t TRACKINFO(uint32_t *WriteStartP) { uint8_t Jbyte; uint16_t Jshort; uint32_t Jlong,FreeBlocks; fprintf(SpiegLogF,"\nREAD TRACK INFORMATION\n"); BIGEND2(&Jshort,GTransBuf); memset(>ransBuf[Jshort+2],0,2046-Jshort); SPLITEND2(&Jshort,>ransBuf[32],>ransBuf[2]); fprintf(SpiegLogF,"Track Number: %hu\n",Jshort); SPLITEND2(&Jshort,>ransBuf[33],>ransBuf[3]); fprintf(SpiegLogF,"Session Number: %hu\n",Jshort); Jbyte=(uint8_t)GTransBuf[5]&0x0F; /* Bit 1 Means Copy Permitted */ fprintf(SpiegLogF,"Track Mode Control Nibble: %02Xh, %s\n",Jbyte,TRACKMODES(Jbyte)); Jbyte=(uint8_t)GTransBuf[6]&0x0F; fprintf(SpiegLogF,"Data Mode: %02Xh, %s\n",Jbyte,DATAMODES(Jbyte)); fprintf(SpiegLogF,"Track Must Be Written With Packets: %c\n",(GTransBuf[6]&32)?'Y':'N'); fprintf(SpiegLogF,"Track Is Blank: %c\n",(GTransBuf[6]&64)?'Y':'N'); fprintf(SpiegLogF,"Track Is Reserved: %c\n",(GTransBuf[6]&128)?'Y':'N'); fprintf(SpiegLogF,"Next Writable Address Valid: %c\n",(GTransBuf[7]&1)?'Y':'N'); fprintf(SpiegLogF,"Last Recorded Address Valid: %c\n",(GTransBuf[7]&2)?'Y':'N'); BIGEND4(&Jlong,GTransBuf+8); fprintf(SpiegLogF,"Track Start Address: %d\n",Jlong); BIGEND4(WriteStartP,GTransBuf+12); fprintf(SpiegLogF,"Next Writable Address: %d\n",*WriteStartP); BIGEND4(&FreeBlocks,GTransBuf+16); fprintf(SpiegLogF,"Free Blocks: %d\n",FreeBlocks); BIGEND4(&Jlong,GTransBuf+20); fprintf(SpiegLogF,"Fixed Packet Size: %d\n",Jlong); BIGEND4(&Jlong,GTransBuf+24); fprintf(SpiegLogF,"Track Size: %d\n",Jlong); BIGEND4(&Jlong,GTransBuf+28); fprintf(SpiegLogF,"Last Recorded Address: %d\n",Jlong); BIGEND4(&Jlong,GTransBuf+36); fprintf(SpiegLogF,"Read Compatibility LBA: %d\n",Jlong); return FreeBlocks; } /* CDB 0x52, READ TRACK INFORMATION */ const char *DATAMODES(uint8_t Code) { switch(Code) { case 0x01: return "Mode 1 ISO/IEC 10149"; case 0x02: return "Mode 2 ISO/IEC 10149, CD-ROM XA, DDCD"; case 0x0F: return "Data Block Type Unknown, No Track Descriptor Block"; default: return "Reserved Data Mode Type"; } } /* Data Modes */ ======================================================== /* Copyright 2011 Frank Mitchell - Wildebeest License */ /* writecyc.c - Spiegel v2.0 - Linux Kernel 2.6.16+ */ /* Contact: mitchell@wyatt672earp.force9.co.uk */ #include "spiegel.h" uint32_t WRITESPEED(uint32_t WriteStart,uint32_t WriteEnd, uint32_t WritePerf,uint8_t StreamCtl,const char *Desc) { const char *Here="@WRITESPEED"; int i,j,k,NumDesc,StartByte; uint32_t StartLBA,EndLBA,ReadPerf,StartPerf,EndPerf,Jlong; uint16_t Jshort; uint8_t TypeField[2]={16,20}; ReadPerf=0x7FFFFFFF; /* Reset Same */ Jlong=1000; /* Time Millisec */ Jshort=28; /* Parameter List Length */ memset(GTransBuf,0,sizeof(GTransBuf)); GTransBuf[0]=StreamCtl; BIGEND4(>ransBuf[4],&WriteStart); BIGEND4(>ransBuf[8],&WriteEnd); BIGEND4(>ransBuf[12],&ReadPerf); BIGEND4(>ransBuf[16],&Jlong); /* Read Time */ BIGEND4(>ransBuf[20],&WritePerf); BIGEND4(>ransBuf[24],&Jlong); /* Write Time */ /* Set Streaming Speed */ memset(&GRequest,0,sizeof(GRequest)); GRequest.Cmd[0]=0xB6; /* SET STREAMING */ BIGEND2(&GRequest.Cmd[9],&Jshort); GRequest.XferP=GTransBuf; GRequest.XferLen=sizeof(GTransBuf); GRequest.XferDirn=SG_DXFER_TO_DEV; if(DOPACKET(GDevFil,"SET STREAMING",&GRequest)!=0)goto ERRSETSPEED; /* MMC-2 Read & Write Performance Descriptors */ fprintf(SpiegLogF,"\nSET STREAMING: %s\n",Desc); Jshort=120; /* Max Number Descriptors */ for(i=0;i<2;i++) { memset(&GRequest,0,sizeof(GRequest)); GRequest.Cmd[0]=0xAC; /* GET PERFORMANCE */ GRequest.Cmd[1]=TypeField[i]; /* Nominal Perfs */ BIGEND2(&GRequest.Cmd[8],&Jshort); GRequest.XferP=GTransBuf; GRequest.XferLen=sizeof(GTransBuf); GRequest.XferDirn=SG_DXFER_FROM_DEV; if(DOPACKET(GDevFil,"GET PERFORMANCE",&GRequest)!=0)goto BADPERFGET; /* Header Adds Eight Bytes To Performance Descriptor Locations */ BIGEND4(&Jlong,GTransBuf+0); j=Jlong+8; memset(>ransBuf[j],0,2048-j); NumDesc=Jlong>>4; fprintf(SpiegLogF,"GET PERFORMANCE: %s - Nominal Descriptors: %d\n", (GTransBuf[4]&2)?"Write":"Read",NumDesc); for(k=0;k>11; /* Total Ring Buffer Bytes = Hardware Cache Size /8 *GBufFac */ RingBufTot=(GDevCache>>3)*GBufFac; BufRingK=RingBufTot/(size_t)WRITE10MAX; fprintf(SpiegLogF,"Ring Buffer Count: %u\n",BufRingK); OffSetP=calloc(BufRingK,sizeof(off_t)); if(OffSetP==NULL)goto BADCALLOC; RingPP=calloc(BufRingK,sizeof(void*)); if(RingPP==NULL)goto BADCALLOC; fflush(NULL); /* Flush All Buffered Output */ if((IsoFildes=open(GIsoFilPath,O_RDONLY))==-1)goto BADOPENFIL; for(BufJ=0;BufJ>11; /* Partial Block? */ WriteK=0; /* Buffer Serial Count */ BufJ=0; /* Burn Cycle Index Mod BufRingK */ /* Move To Last Valid Seek Sector */ memset(&GRequest,0,sizeof(GRequest)); GRequest.Cmd[0]=0x2B; /* SEEK(10) */ BIGEND4(&GRequest.Cmd[2],&GSeekLBA); /* Last Seek LBA */ GRequest.XferDirn=SG_DXFER_NONE; if(DOPACKET(GDevFil,"SEEK(10)",&GRequest)!=0)goto SEEKFAIL; StartSect=WriteStart; while(1) { Jshort=(BlocksToDo Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D6C21065701 for ; Wed, 15 Jun 2011 20:21:46 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 138CF8FC1A for ; Wed, 15 Jun 2011 20:21:45 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id p5FKFEQ4053096 for ; Wed, 15 Jun 2011 13:15:15 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <4DF91458.8010508@rawbw.com> Date: Wed, 15 Jun 2011 13:21:44 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.16) Gecko/20101211 Thunderbird/3.0.11 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Why user time of the process depends on machine load? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 20:21:46 -0000 When I test performance of the code, I always observe dependency of CPU user time on the presence of other CPU intense processes. Same CPU-only deterministic process that on the quiet machine completes in 220 user seconds in the presence of, for example, kde rebuild would complete in 261, 266 or even 379 user seconds. I am talking about times shown by time(1), not actual an execution time. It's the same time as getrusage(2) returns in ru_utime field. Why time that process takes in user seconds depends on what other processes are running? FreeBSD-8.2 STABLE on i7 CPU @ 9200 @ 2.67GHz. Yuri From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 15 22:16:08 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8428106566B for ; Wed, 15 Jun 2011 22:16:08 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email2.allantgroup.com (email2.emsphone.com [199.67.51.116]) by mx1.freebsd.org (Postfix) with ESMTP id 91F528FC0A for ; Wed, 15 Jun 2011 22:16:08 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email2.allantgroup.com (8.14.4/8.14.4) with ESMTP id p5FLtIvX049117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 15 Jun 2011 16:55:18 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.5/8.14.5) with ESMTP id p5FLtInw010123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 15 Jun 2011 16:55:18 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.5/8.14.5/Submit) id p5FLtHJ1010122; Wed, 15 Jun 2011 16:55:17 -0500 (CDT) (envelope-from dan) Date: Wed, 15 Jun 2011 16:55:17 -0500 From: Dan Nelson To: Yuri Message-ID: <20110615215515.GA6889@dan.emsphone.com> References: <4DF91458.8010508@rawbw.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DF91458.8010508@rawbw.com> X-OS: FreeBSD 8.2-STABLE User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97 at email2.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (email2.allantgroup.com [199.67.51.78]); Wed, 15 Jun 2011 16:55:19 -0500 (CDT) X-Scanned-By: MIMEDefang 2.68 on 199.67.51.78 Cc: freebsd-hackers@freebsd.org Subject: Re: Why user time of the process depends on machine load? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 22:16:09 -0000 In the last episode (Jun 15), Yuri said: > When I test performance of the code, I always observe dependency of CPU > user time on the presence of other CPU intense processes. Same CPU-only > deterministic process that on the quiet machine completes in 220 user > seconds in the presence of, for example, kde rebuild would complete in > 261, 266 or even 379 user seconds. I am talking about times shown by > time(1), not actual an execution time. It's the same time as getrusage(2) > returns in ru_utime field. > > Why time that process takes in user seconds depends on what other > processes are running? > > FreeBSD-8.2 STABLE on i7 CPU @ 9200 @ 2.67GHz. Some possible factors: o Intel Turbo Boost, which raises the clock rate of a single core if the other cores are idle. A single process on an idle system will run faster. o i7 chips have a shared L3 cache across all cores, so a single process on an idle system will tend to have more of its data in cache compared to a system with multiple processes, so it spends less time waiting for slower physical memory lookups. o Process accounting isn't exact. I may be wrong, but I don't think timestamps are taken every time a syscall is invoked and returns. Some time marked as "user" may actually be "system" time, in which case you may be seeing the effect of contention in the kernel as more processes are run. You may be able to disable Turbo Boot in your BIOS, which you can use to determine how much of the single-process speedup is due to that. Unrelated but still interesting note on your particular CPU: http://www.passmark.com/forum/showthread.php?t=2256 -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 15 22:48:39 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9769E1065676 for ; Wed, 15 Jun 2011 22:48:39 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 51C9A8FC26 for ; Wed, 15 Jun 2011 22:48:38 +0000 (UTC) Received: by gyg13 with SMTP id 13so131195gyg.13 for ; Wed, 15 Jun 2011 15:48:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0g4aZaLchzU5ZydUB9kMksGm1jVOt3UubKcFLK3n8dA=; b=BMvwTedzuYqHvZfS7wf+p+jZmjWF6Ri2zrS1KbUq9YtjWx41mdhq1EXrSV0+qSYUFk yVLJRg8tnKpTLBfGzNkul8U7Fa/Gpg4CSaWlUE8oj5z/BLBFygNnY4vmra373OIXDnif 3tYwpWTeWgH8brIB30dhYivBLoLbyQHwnKjj0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=UTh8MDJBts5EQLtMy74b9wECojkDUCuGlkUwPUn9U3xjB1jT3kfsrWbeoPY0psaLaK +nQoLx3m0Cn1lyo/++5AEGDEtwgNV2le9wuQC4GIe7BOXCff3OfmttuU+K3x+/VJpQWL krJi6KceY2z2B04lnwCKBXngORqkT278yufSw= MIME-Version: 1.0 Received: by 10.236.186.65 with SMTP id v41mr136580yhm.1.1308178118304; Wed, 15 Jun 2011 15:48:38 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.236.61.73 with HTTP; Wed, 15 Jun 2011 15:48:38 -0700 (PDT) In-Reply-To: <20110615215515.GA6889@dan.emsphone.com> References: <4DF91458.8010508@rawbw.com> <20110615215515.GA6889@dan.emsphone.com> Date: Wed, 15 Jun 2011 15:48:38 -0700 X-Google-Sender-Auth: 9a27QiNIrHqnPw7WXVUOeJV-k2o Message-ID: From: Artem Belevich To: Dan Nelson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Yuri , freebsd-hackers@freebsd.org Subject: Re: Why user time of the process depends on machine load? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 22:48:39 -0000 Hi, On Wed, Jun 15, 2011 at 2:55 PM, Dan Nelson wrote= : > In the last episode (Jun 15), Yuri said: >> When I test performance of the code, I always observe dependency of CPU >> user time on the presence of other CPU intense processes. =A0Same CPU-on= ly >> deterministic process that on the quiet machine completes in 220 user >> seconds in the presence of, for example, kde rebuild would complete in >> 261, 266 or even 379 user seconds. =A0I am talking about times shown by >> time(1), not actual an execution time. =A0It's the same time as getrusag= e(2) >> returns in ru_utime field. >> >> Why time that process takes in user seconds depends on what other >> processes are running? >> >> FreeBSD-8.2 STABLE on i7 CPU @ 9200 @ 2.67GHz. > > Some possible factors: > > o Intel Turbo Boost, which raises the clock rate of a single core if the > =A0other cores are idle. =A0A single process on an idle system will run f= aster. > > o i7 chips have a shared L3 cache across all cores, so a single process o= n > =A0an idle system will tend to have more of its data in cache compared to= a > =A0system with multiple processes, so it spends less time waiting for slo= wer > =A0physical memory lookups. > > o Process accounting isn't exact. =A0I may be wrong, but I don't think > =A0timestamps are taken every time a syscall is invoked and returns. =A0S= ome > =A0time marked as "user" may actually be "system" time, in which case you= may > =A0be seeing the effect of contention in the kernel as more processes are > =A0run. I would add hyper-threading to the list. Once you don't have enough real cores available to do the job, things do tend to slow down, unless your process is heavily i/o bound. The time process spends on a hyper-thread when it's not active still counts towards total time consumed by the process. --Artem > > You may be able to disable Turbo Boot in your BIOS, which you can use to > determine how much of the single-process speedup is due to that. > > Unrelated but still interesting note on your particular CPU: > http://www.passmark.com/forum/showthread.php?t=3D2256 > > -- > =A0 =A0 =A0 =A0Dan Nelson > =A0 =A0 =A0 =A0dnelson@allantgroup.com > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 16 11:13:40 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E5AD106566C for ; Thu, 16 Jun 2011 11:13:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 05A138FC0C for ; Thu, 16 Jun 2011 11:13:40 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id ACD9746B03; Thu, 16 Jun 2011 07:13:39 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4C87D8A02A; Thu, 16 Jun 2011 07:13:39 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 16 Jun 2011 07:12:46 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4DF91458.8010508@rawbw.com> <20110615215515.GA6889@dan.emsphone.com> In-Reply-To: <20110615215515.GA6889@dan.emsphone.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201106160712.46408.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 16 Jun 2011 07:13:39 -0400 (EDT) Cc: Yuri , Dan Nelson Subject: Re: Why user time of the process depends on machine load? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 11:13:40 -0000 On Wednesday, June 15, 2011 5:55:17 pm Dan Nelson wrote: > In the last episode (Jun 15), Yuri said: > > When I test performance of the code, I always observe dependency of CPU > > user time on the presence of other CPU intense processes. Same CPU-only > > deterministic process that on the quiet machine completes in 220 user > > seconds in the presence of, for example, kde rebuild would complete in > > 261, 266 or even 379 user seconds. I am talking about times shown by > > time(1), not actual an execution time. It's the same time as getrusage(2) > > returns in ru_utime field. > > > > Why time that process takes in user seconds depends on what other > > processes are running? > > > > FreeBSD-8.2 STABLE on i7 CPU @ 9200 @ 2.67GHz. > > Some possible factors: > > o Intel Turbo Boost, which raises the clock rate of a single core if the > other cores are idle. A single process on an idle system will run faster. > > o i7 chips have a shared L3 cache across all cores, so a single process on > an idle system will tend to have more of its data in cache compared to a > system with multiple processes, so it spends less time waiting for slower > physical memory lookups. > > o Process accounting isn't exact. I may be wrong, but I don't think > timestamps are taken every time a syscall is invoked and returns. Some > time marked as "user" may actually be "system" time, in which case you may > be seeing the effect of contention in the kernel as more processes are > run. This is very true. You can only really trust the sum of system + user time and compare that across runs. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 16 18:46:47 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6311F1065687 for ; Thu, 16 Jun 2011 18:46:47 +0000 (UTC) (envelope-from cattelan@thebarn.com) Received: from x.digitalelves.com (x.digitalelves.com [209.98.77.55]) by mx1.freebsd.org (Postfix) with ESMTP id 197B88FC13 for ; Thu, 16 Jun 2011 18:46:46 +0000 (UTC) Received: from [IPv6:::1] (localhost [127.0.0.1]) (authenticated bits=0) by x.digitalelves.com (8.14.4/8.14.4) with ESMTP id p5GIWddG021625 for ; Thu, 16 Jun 2011 13:32:39 -0500 (CDT) (envelope-from cattelan@digitalelves.com) Message-ID: <4DFA4C47.8060503@digitalelves.com> Date: Thu, 16 Jun 2011 13:32:39 -0500 From: Russell Cattelan User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: kexec or similar for FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 18:46:47 -0000 I have been contacted about possibly implementing a fast reboot mechanism for FreeBSD similar to kexec on Linux. I have just started looking into how this accomplished so I figured a note to freebsd hackers would also be a good place to ask for comments. Has anybody looked at doing something like kexec? Is it the right thing to do for FreeBSD. I'm concerned that the way FreeBSD handles early kernel modules (loaded via the boot loader) vs linux which does everything via initrd is going to be a problem. Thanks for any help on this. -Russell Cattelan From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 16 18:54:52 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E50B1106566B for ; Thu, 16 Jun 2011 18:54:52 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 916EC8FC0A for ; Thu, 16 Jun 2011 18:54:52 +0000 (UTC) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.14.4/8.14.4) with ESMTP id p5GIspXt056136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jun 2011 11:54:51 -0700 (PDT) (envelope-from mj@feral.com) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.14.4/8.14.4/Submit) with ESMTP id p5GIspPm056133; Thu, 16 Jun 2011 11:54:51 -0700 (PDT) (envelope-from mj@feral.com) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Thu, 16 Jun 2011 11:54:51 -0700 (PDT) From: Matthew Jacob To: Russell Cattelan In-Reply-To: <4DFA4C47.8060503@digitalelves.com> Message-ID: References: <4DFA4C47.8060503@digitalelves.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (ns1.feral.com [127.0.0.1]); Thu, 16 Jun 2011 11:54:51 -0700 (PDT) Cc: freebsd-hackers@freebsd.org Subject: Re: kexec or similar for FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mj@feral.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 18:54:53 -0000 Hi Russell! Yes, I think it is. Solaris supports something like this and the idea here is that with complicated I/O subsystems it's too hard to get them and locks cleaned up in a crash, but you want to get all the forensics you can, so doing a jump to a preloaded kernel that has a small and separate running address space seems a good way to go. If I were doing this, I'd try and set up the alternate kernel to be in the same state it would be just after the loader has prelinked all the pieces together. So, you run along in the loader, and jump to the kernel where all the pieces are linked together. Perhaps you could extend the loader to preload/prelink the alternate kernel as well (or just copy and relocate the main kernel). On Thu, 16 Jun 2011, Russell Cattelan wrote: > I have been contacted about possibly implementing a fast reboot > mechanism for FreeBSD similar to kexec on Linux. > > I have just started looking into how this accomplished so I figured > a note to freebsd hackers would also be a good place to ask > for comments. > > Has anybody looked at doing something like kexec? > > Is it the right thing to do for FreeBSD. I'm concerned that the way > FreeBSD handles early kernel modules (loaded via the boot loader) > vs linux which does everything via initrd is going to be a problem. > > Thanks for any help on this. > > -Russell Cattelan > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 16 20:08:30 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A678F106564A for ; Thu, 16 Jun 2011 20:08:30 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 36F588FC18 for ; Thu, 16 Jun 2011 20:08:30 +0000 (UTC) Received: by fxm11 with SMTP id 11so1971537fxm.13 for ; Thu, 16 Jun 2011 13:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=SuQBkPr5Mf053ilQsgPCQLNuCrTV1NCwHSRzdFsOTAw=; b=SYLVafDu8L9d/O2Ae/YPmHscKoEU/rvKz8VPtCktXLcL6RIStxFi6qDlNqxce5LZJE nxY8R7WK8GsNnfNlHCXDtqKHMXvSZvrAjYMtzlFjEi5K1G6hI5KVVTjVQwddrqM1+egj /Yfi8e60BMX9FQe8gKkjfXFb9alOaB9EAMDrQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Q6snhWMtewCdadtjz1ZVfpOg9hzA4BYN/5qgs9Uh4IJBzyj2tjKT0/Dtbj7mFutEWq GhLp5D+ZToAROfx4UeeMiqj6KmFNpc5qxow95ZZjXdWjvmSbeh21wA0RRS4EYe9mIjoX 3us35JlqaYkwycEAP5UaFnfQc4q/j0E1BbQRs= Received: by 10.223.37.153 with SMTP id x25mr1581820fad.117.1308254909255; Thu, 16 Jun 2011 13:08:29 -0700 (PDT) Received: from localhost (lan-78-157-92-5.vln.skynet.lt [78.157.92.5]) by mx.google.com with ESMTPS id g8sm990894fai.44.2011.06.16.13.08.27 (version=SSLv3 cipher=OTHER); Thu, 16 Jun 2011 13:08:28 -0700 (PDT) Date: Thu, 16 Jun 2011 23:06:16 +0300 From: Gleb Kurtsou To: Russell Cattelan Message-ID: <20110616200616.GA67011@tops> References: <4DFA4C47.8060503@digitalelves.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4DFA4C47.8060503@digitalelves.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org Subject: Re: kexec or similar for FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 20:08:30 -0000 On (16/06/2011 13:32), Russell Cattelan wrote: > I have been contacted about possibly implementing a fast reboot > mechanism for FreeBSD similar to kexec on Linux. > > I have just started looking into how this accomplished so I figured > a note to freebsd hackers would also be a good place to ask > for comments. > > Has anybody looked at doing something like kexec? I was working on similar project some time ago. First of all you have to leave hardware in known good state for a new kernel. Reseting devices can be generally accomplished by unloading corresponding kernel modules (even if they are compiled in kernel). The biggest problem for me was timers and programmable interrupt controller. I didn't make it work properly, but my goals where much wider than replacing with another FreeBSD kernel. Aim was to restore initial BIOS state as much as possible. > Is it the right thing to do for FreeBSD. I'm concerned that the way > FreeBSD handles early kernel modules (loaded via the boot loader) > vs linux which does everything via initrd is going to be a problem. I find loader code easy work with. You could write dummy filesystem implementation for libstand. So that customized loader will load both kernel and modules yet while running FreeBSD. Your "reboot" procedure wouldn't even use any BIOS io interrupts. Linux boot is a real mess imho. > > Thanks for any help on this. > > -Russell Cattelan From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 17 03:35:55 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 886BB1065673 for ; Fri, 17 Jun 2011 03:35:55 +0000 (UTC) (envelope-from cattelan@thebarn.com) Received: from x.digitalelves.com (x.digitalelves.com [209.98.77.55]) by mx1.freebsd.org (Postfix) with ESMTP id 547958FC08 for ; Fri, 17 Jun 2011 03:35:55 +0000 (UTC) Received: from funky-wifi.x.thebarn.com (localhost [127.0.0.1]) (authenticated bits=0) by x.digitalelves.com (8.14.4/8.14.4) with ESMTP id p5H3ZrGQ047739; Thu, 16 Jun 2011 22:35:54 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <4DFACB99.1030707@thebarn.com> Date: Thu, 16 Jun 2011 22:35:53 -0500 From: Russell Cattelan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Gleb Kurtsou References: <4DFA4C47.8060503@digitalelves.com> <20110616200616.GA67011@tops> In-Reply-To: <20110616200616.GA67011@tops> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: kexec or similar for FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 03:35:55 -0000 On 6/16/11 3:06 PM, Gleb Kurtsou wrote: > On (16/06/2011 13:32), Russell Cattelan wrote: >> I have been contacted about possibly implementing a fast reboot >> mechanism for FreeBSD similar to kexec on Linux. >> >> I have just started looking into how this accomplished so I figured >> a note to freebsd hackers would also be a good place to ask >> for comments. >> >> Has anybody looked at doing something like kexec? > I was working on similar project some time ago. First of all you have to > leave hardware in known good state for a new kernel. Reseting devices > can be generally accomplished by unloading corresponding kernel modules > (even if they are compiled in kernel). The biggest problem for me was > timers and programmable interrupt controller. I didn't make it work > properly, but my goals where much wider than replacing with another > FreeBSD kernel. Aim was to restore initial BIOS state as much as > possible. What were your goals beyond booting a new kernel? I think getting back to a known BIOS state is kinda required to get a kernel through the boot process. From what I can tell the main goal of kexec is to avoid the process of re-initializing the hardware via BIOS. >> Is it the right thing to do for FreeBSD. I'm concerned that the way >> FreeBSD handles early kernel modules (loaded via the boot loader) >> vs linux which does everything via initrd is going to be a problem. > I find loader code easy work with. You could write dummy filesystem > implementation for libstand. So that customized loader will load both > kernel and modules yet while running FreeBSD. Your "reboot" procedure > wouldn't even use any BIOS io interrupts. Linux boot is a real mess > imho. > So it is possible to get back to the loader once the kernel is booted? So the running kernel could load the new kernel / modules and then jump back to the loader to start the boot process. >> Thanks for any help on this. >> >> -Russell Cattelan From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 17 16:40:31 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 793381065687 for ; Fri, 17 Jun 2011 16:40:31 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 45EB98FC14 for ; Fri, 17 Jun 2011 16:40:31 +0000 (UTC) Received: by iwr19 with SMTP id 19so1862100iwr.13 for ; Fri, 17 Jun 2011 09:40:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=C/N3JN9Jadur94NASsVr5keuxRHFgesd+QwnXvwXGzg=; b=br5Iz4uHh+9hRY4N7u2kak6zWds9pkd6IzaW5AAzAljeCn5BuAfLQFrjSMJiZtOzoQ 7fhHEfBDhI3WEkJbJWjz4q59+k5H9MyHngGPrTquVMq8Z8eRaiMXnV5Q5QYnfyTpGfmu 9kXbcPdGtej807FOScGtxRBcqz4K2S22BKFAw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; b=n2FDvNM3VrcrSzx6+xQA6MRfPySF7DL5D8cyykj9nmBAGaRyJ7Kzf7cvPkWn1sEz7h F1iubNP1U43Wt/6RQcn3jyskgkC5lFyDdyi5/7zddY/58lh69MqCPupc2Kmj87yO2vxf 6+cfF2CzfyOQgOsnJW9yKj0//8/6ipXEZYy+Q= Received: by 10.231.206.6 with SMTP id fs6mr1993819ibb.70.1308328830107; Fri, 17 Jun 2011 09:40:30 -0700 (PDT) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.231.49.193 with HTTP; Fri, 17 Jun 2011 09:40:00 -0700 (PDT) From: Chris Rees Date: Fri, 17 Jun 2011 17:40:00 +0100 X-Google-Sender-Auth: MiYEt7dttdBVWMzKFxDg6tRAr-g Message-ID: To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: CONF class of files X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 16:40:31 -0000 Hi all, Macros are being tested for bsd.port.mk that use a new class of files, in the same vein as the BINOWN variables I have introduced CONFOWN, CONFGRP, CONFMODE and CONFDIR. Please would someone review and give an opinion on [1]? I'd _really_ appreciate getting it in before 9-R Chris http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/157062 From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 17 18:53:25 2011 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97769106566B; Fri, 17 Jun 2011 18:53:25 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 590048FC08; Fri, 17 Jun 2011 18:53:25 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p5HIn2T5033191 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Fri, 17 Jun 2011 12:49:03 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Fri, 17 Jun 2011 12:48:52 -0600 Content-Transfer-Encoding: 7bit Message-Id: <1A08B2C2-D0D8-47E1-ADBC-86D7EC2E9112@bsdimp.com> References: To: Chris Rees X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Fri, 17 Jun 2011 12:49:04 -0600 (MDT) Cc: hackers@FreeBSD.org Subject: Re: CONF class of files X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 18:53:25 -0000 I like it. I think we should get it in ASAP. Warner On Jun 17, 2011, at 10:40 AM, Chris Rees wrote: > Hi all, > > Macros are being tested for bsd.port.mk that use a new class of files, > in the same vein as the BINOWN variables I have introduced CONFOWN, > CONFGRP, CONFMODE and CONFDIR. > > Please would someone review and give an opinion on [1]? > > I'd _really_ appreciate getting it in before 9-R > > Chris > > http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/157062 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 17 18:59:32 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB110106564A; Fri, 17 Jun 2011 18:59:32 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 82B3D8FC22; Fri, 17 Jun 2011 18:59:32 +0000 (UTC) Received: by iyj12 with SMTP id 12so3215312iyj.13 for ; Fri, 17 Jun 2011 11:59:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=xb037ZZZC9Isg/bd6dsDDSLyszTYl+aKg+Fsl5M9yB0=; b=J8GWpykfMdT0bCPsEhfVFZwKD7TN2zjUqPDKUoRSYV3+762aEsbV8TnAjnBdaztBGG k3E7cXZ9dRmbYwOiZIsfHDyUDRf3BsXgA0H5khhqwgadeADGhG7eK3PDJ5DnU5htNE0s GRzc6pzD6h5I2x4MApv5CLqUwRJfJmFX8v6DA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=oBjOozYc8ykjQDY0mZkXb9Ljf1P+o5qim3/fdr6Wefxt2RdXj0CJM9ngW2vZyjtR5Y /1O95jBcgBDROiZyadbsx15OJ94v2jPIRX3kqo4immjpljuKm07P5S6nnCMyNFc20A1f STPeT91oTZfx1GTFpc9LvRtGqTdbZdXYJhIdw= MIME-Version: 1.0 Received: by 10.231.200.82 with SMTP id ev18mr2158131ibb.45.1308337171817; Fri, 17 Jun 2011 11:59:31 -0700 (PDT) Sender: utisoft@gmail.com Received: by 10.231.49.193 with HTTP; Fri, 17 Jun 2011 11:59:31 -0700 (PDT) Received: by 10.231.49.193 with HTTP; Fri, 17 Jun 2011 11:59:31 -0700 (PDT) In-Reply-To: <1A08B2C2-D0D8-47E1-ADBC-86D7EC2E9112@bsdimp.com> References: <1A08B2C2-D0D8-47E1-ADBC-86D7EC2E9112@bsdimp.com> Date: Fri, 17 Jun 2011 19:59:31 +0100 X-Google-Sender-Auth: tJJX3MXmZu233lms6SMkeIQz8zs Message-ID: From: Chris Rees To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Chris Rees , hackers@freebsd.org Subject: Re: CONF class of files X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 18:59:32 -0000 On 17 Jun 2011 19:53, "Warner Losh" wrote: > > I like it. I think we should get it in ASAP. > > Warner You have a src bit ;) Chris From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 18 08:19:15 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2E0A106566B for ; Sat, 18 Jun 2011 08:19:15 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 928F48FC08 for ; Sat, 18 Jun 2011 08:19:15 +0000 (UTC) Received: by vxc34 with SMTP id 34so3477929vxc.13 for ; Sat, 18 Jun 2011 01:19:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=524e53r+IrAVpf9ZP7ocKDTGIua43FqcWnpXCbEbJr4=; b=bL21x7UNR364c3bx0QeZy6g/6CpODDEM4wwUNyeBWTnBJgrnw6PmYdqcZl/DiiMzWL ATrxQtd0I9T/IphTEyWf9Mq8EnAfbRhvXLzkrSI7FvclL58VmlPtuJMOvFLt3YV1rjq6 H6Ou8jgCALNSRRBMBdzuzauEnQcmRSuLGxF1Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=xw2y1oPkB75vETud1gAxztDg9X/5Gy1JZAdyjD+OsAIi472+UzvkyNR1+4TvlS6Air pGZNKbA2qJ0W3RPybTncmoQGM2H41NDZn0OC/1MMJzOe4MVt31BMwukpDBuKgL+OWnFo lU3bzn7YAuhqZhDKfEuAUGl3QT5va+aY5p6Vc= MIME-Version: 1.0 Received: by 10.220.210.69 with SMTP id gj5mr1176170vcb.58.1308385154590; Sat, 18 Jun 2011 01:19:14 -0700 (PDT) Received: by 10.220.189.202 with HTTP; Sat, 18 Jun 2011 01:19:14 -0700 (PDT) Date: Sat, 18 Jun 2011 01:19:14 -0700 Message-ID: From: Garrett Cooper To: dfr@freebsd.org Content-Type: multipart/mixed; boundary=0022154700ae5e694204a5f828b1 Cc: freebsd-hackers@freebsd.org Subject: [PATCH] improve MOD_DPF macro and other misc. cleanup X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 08:19:16 -0000 --0022154700ae5e694204a5f828b1 Content-Type: text/plain; charset=ISO-8859-1 Hi Doug, I tried using the MODULE_DEBUG #define and I ran into some compile issues. This patch gets things to work and adds an official option / entry to NOTES for help with other folks debugging kern_module.c logic. I also added some additional data to assist with determining causes of failure, as well as remove an impossible == NULL case when using malloc(.., M_WAITOK). Thanks! -Garrett --0022154700ae5e694204a5f828b1 Content-Type: text/x-patch; charset=US-ASCII; name="mod_dpf.patch" Content-Disposition: attachment; filename="mod_dpf.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gp2al9af1 SW5kZXg6IHN5cy9rZXJuL2tlcm5fbW9kdWxlLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2tlcm4va2Vy bl9tb2R1bGUuYwkocmV2aXNpb24gMjIzMTM4KQorKysgc3lzL2tlcm4va2Vybl9tb2R1bGUuYwko d29ya2luZyBjb3B5KQpAQCAtMjUsNiArMjUsNyBAQAogICovCiAKICNpbmNsdWRlICJvcHRfY29t cGF0LmgiCisjaW5jbHVkZSAib3B0X2dsb2JhbC5oIgogCiAjaW5jbHVkZSA8c3lzL2NkZWZzLmg+ CiBfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CkBAIC00NCw2ICs0NSwxNSBAQAogI2luY2x1ZGUgPHN5 cy9tb2R1bGUuaD4KICNpbmNsdWRlIDxzeXMvbGlua2VyLmg+CiAKKyNpZmRlZiBNT0RVTEVfREVC VUcKKyNpbmNsdWRlIDxzeXMvc3lzY3RsLmg+CisKK2ludAltb2RfZGVidWcgPSAxOworCitTWVND VExfSU5UKF9kZWJ1ZywgT0lEX0FVVE8sIG1vZHVsZV9kZWJ1ZywgQ1RMVFlQRV9JTlR8Q1RMRkxB R19SV3xDVExGTEFHX1RVTiwKKyAgICAmbW9kX2RlYnVnLCAwLCAia2VybmVsIG1vZHVsZSBldmVu dHMgdG8gaW50ZXJjZXB0Iik7CisjZW5kaWYKKwogc3RhdGljIE1BTExPQ19ERUZJTkUoTV9NT0RV TEUsICJtb2R1bGUiLCAibW9kdWxlIGRhdGEgc3RydWN0dXJlcyIpOwogCiBzdHJ1Y3QgbW9kdWxl IHsKQEAgLTE2NCwxMCArMTc0LDYgQEAKIAl9CiAJbmFtZWxlbiA9IHN0cmxlbihkYXRhLT5uYW1l KSArIDE7CiAJbmV3bW9kID0gbWFsbG9jKHNpemVvZihzdHJ1Y3QgbW9kdWxlKSArIG5hbWVsZW4s IE1fTU9EVUxFLCBNX1dBSVRPSyk7Ci0JaWYgKG5ld21vZCA9PSBOVUxMKSB7Ci0JCU1PRF9YVU5M T0NLOwotCQlyZXR1cm4gKEVOT01FTSk7Ci0JfQogCW5ld21vZC0+cmVmcyA9IDE7CiAJbmV3bW9k LT5pZCA9IG5leHRpZCsrOwogCW5ld21vZC0+bmFtZSA9IChjaGFyICopKG5ld21vZCArIDEpOwpA QCAtMTkwLDcgKzE5Niw3IEBACiAKIAlNT0RfWExPQ0tfQVNTRVJUOwogCi0JTU9EX0RQRihSRUZT LCAoIm1vZHVsZV9yZWZlcmVuY2U6IGJlZm9yZSwgcmVmcz0lZFxuIiwgbW9kLT5yZWZzKSk7CisJ TU9EX0RQRihSRUZTLCAibW9kdWxlX3JlZmVyZW5jZTogYmVmb3JlLCByZWZzPSVkXG4iLCBtb2Qt PnJlZnMpOwogCW1vZC0+cmVmcysrOwogfQogCkBAIC0yMDEsMTIgKzIwNywxNyBAQAogCU1PRF9Y TE9DS19BU1NFUlQ7CiAKIAlpZiAobW9kLT5yZWZzIDw9IDApCi0JCXBhbmljKCJtb2R1bGVfcmVs ZWFzZTogYmFkIHJlZmVyZW5jZSBjb3VudCIpOworCQlwYW5pYygibW9kdWxlX3JlbGVhc2U6IGJh ZCByZWZlcmVuY2UgY291bnQsIHJlZnM9JWRcbiIsCisJCSAgICBtb2QtPnJlZnMpOwogCi0JTU9E X0RQRihSRUZTLCAoIm1vZHVsZV9yZWxlYXNlOiBiZWZvcmUsIHJlZnM9JWRcbiIsIG1vZC0+cmVm cykpOwotCQorCU1PRF9EUEYoUkVGUywgIm1vZHVsZV9yZWxlYXNlOiBiZWZvcmUsIG1vZHVsZT0l cyByZWZzPSVkXG4iLAorCSAgICBtb2QtPm5hbWUsIG1vZC0+cmVmcyk7CisKIAltb2QtPnJlZnMt LTsKIAlpZiAobW9kLT5yZWZzID09IDApIHsKKwkJTU9EX0RQRihSRUZTLAorCQkgICAgIm1vZHVs ZV9yZWxlYXNlOiBmcmVlaW5nIGxhc3QgcmVmZXJlbmNlIHRvIG1vZHVsZTogJXNcbiIsCisJCSAg ICBtb2QtPm5hbWUpOwogCQlUQUlMUV9SRU1PVkUoJm1vZHVsZXMsIG1vZCwgbGluayk7CiAJCWlm IChtb2QtPmZpbGUpCiAJCQlUQUlMUV9SRU1PVkUoJm1vZC0+ZmlsZS0+bW9kdWxlcywgbW9kLCBm bGluayk7CkluZGV4OiBzeXMvc3lzL21vZHVsZS5oCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9zeXMvbW9k dWxlLmgJKHJldmlzaW9uIDIyMzEzOCkKKysrIHN5cy9zeXMvbW9kdWxlLmgJKHdvcmtpbmcgY29w eSkKQEAgLTE3NywxOCArMTc3LDE4IEBACiB2b2lkCW1vZHVsZV9zZXRzcGVjaWZpYyhtb2R1bGVf dCwgbW9kc3BlY2lmaWNfdCAqKTsKIHN0cnVjdCBsaW5rZXJfZmlsZSAqbW9kdWxlX2ZpbGUobW9k dWxlX3QpOwogCi0jaWZkZWYJTU9EX0RFQlVHCisjaWZkZWYJTU9EVUxFX0RFQlVHCiBleHRlcm4g aW50IG1vZF9kZWJ1ZzsKICNkZWZpbmUJTU9EX0RFQlVHX1JFRlMJMQogCi0jZGVmaW5lCU1PRF9E UEYoY2F0LCBhcmdzKSBkbyB7CQkJCQkJXAorI2RlZmluZQlNT0RfRFBGKGNhdCwgZm10LCAuLi4p IGRvIHsJCQkJCVwKIAlpZiAobW9kX2RlYnVnICYgTU9EX0RFQlVHXyMjY2F0KQkJCQlcCi0JCXBy aW50ZihhcmdzKTsJCQkJCQlcCisJCXByaW50ZihmbXQsICMjX19WQV9BUkdTX18pOwkJCQlcCiB9 IHdoaWxlICgwKQogCi0jZWxzZQkvKiAhTU9EX0RFQlVHICovCisjZWxzZQkvKiAhTU9EVUxFX0RF QlVHICovCiAKLSNkZWZpbmUJTU9EX0RQRihjYXQsIGFyZ3MpCisjZGVmaW5lCU1PRF9EUEYoY2F0 LCBmbXQsIC4uLikKICNlbmRpZgogI2VuZGlmCS8qIF9LRVJORUwgKi8KIAo= --0022154700ae5e694204a5f828b1--