From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 16 20:06:42 2009 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 6FD36106568B for ; Sun, 16 Aug 2009 20:06:42 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2C8B68FC43 for ; Sun, 16 Aug 2009 20:06:42 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id C887C46B2A; Sun, 16 Aug 2009 16:06:41 -0400 (EDT) Date: Sun, 16 Aug 2009 21:06:41 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Oliver Pinter In-Reply-To: <6101e8c40908151625s52ad9b83ue061de3fab97fbf8@mail.gmail.com> Message-ID: References: <200908152221.n7FMLRuw005799@taverner.cs.berkeley.edu> <6101e8c40908151625s52ad9b83ue061de3fab97fbf8@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-1749418058-1250453201=:1901" Cc: freebsd-hackers@freebsd.org, linux-kernel@vger.kernel.org, David Wagner Subject: Re: Security: information leaks in /proc enable keystroke recovery X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 20:06:42 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --621616949-1749418058-1250453201=:1901 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Sun, 16 Aug 2009, Oliver Pinter wrote: > FreeBSD manages its process files more cautiously than Linux12 : it puts all > register values into the file /proc/pid/regs that can only be read by the > owner of a process, which blocks the information used by This is inaccurate, but largely in an academic sense. The FreeBSD kernels computes debug permissions between two processes from a number of factors, including: - Comparison of uids (effective, real, saved) - Comparison of gids (effective, real, saved) - Subset check on the additional group set - Jail information - Mandatory access control policies There are some other checks that fit the pattern of credential comparison less well: - We deny debugger activity during execve(2) as a robustness protection against possible race conditions. - We have global policy controls, security.bsd.see_other_gids and security.bsd.see_other_uids, which allow administrators to scope not just debugging facilities, but also monitoring facilities. - We have a global policy control, security.bsd.unprivileged_proc_debug, to disable debugging facilities for unprivileged users, on the grounds that (a) this is sometimes a desirable system policy, and (b) all UNIX systems have historically suffered from significant debugger security vulnerabilities and this provides an easy work-around to use if that happens in the future. Which is to say: the UNIX file system permissions appearing in procfs are purely decorative -- they roughly summarize, but do not implement, the above checks. procfs is also deprecated in FreeBSD, and has not been mounted by default for several major releases. Instead, the system call interfaces ktrace(2), ptrace(2), and sysctl(2) provide access to trace data, process debugging, and process state (such as address space layout and file descriptor information). Some legacy setgid kvm tools exist that use libkvm and /dev/kmem, but we are eliminating these as quickly as we can; they may not follow the same policies as those implemented in the kernel. The see_other_uids and see_other_gids policy sysctls narrow the policy on inter-process visibility via monitoring controls -- however, additional hardening is required to enforce this policy universally. For example, administrators will also need to limit access to logs, accounting data, and so on, for this to be fully effective. Beyond this, and assuming the correct implementation of the above, we're into the grounds of classic trusted OS covert channel analysis, against which no COTS UNIX OSes I'm aware of are hardened. This isn't to dismiss these attacks as purely hypothetical -- we've seen some rather compelling examples of covert channels being exploited in unexpected and remarkably practical ways in the last few years (Steven Murdoch's "Hot or Not" paper takes the cake in that regard, I think). However, this next step up from "the kernel doesn't reveal information on processes from other users" involves scheduler hardening, consideration of inter-CPU/core/thread cache interactions, and so on -- things that we don't have a good research, let alone production, OS understanding of. There are tools in FreeBSD that can help with some of these issues -- for example, you can use login classes to pin different users to different CPU threads, cores, or packages. However, this leaves the implementation of policy up to the administrator, rather than simply allowing the administator to specify the policy that mutually untrusting processes can't share CPUs with each other in some window. Robert N M Watson Computer Laboratory University of Cambridge --621616949-1749418058-1250453201=:1901-- From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 16 21:53:36 2009 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 730EC106568D; Sun, 16 Aug 2009 21:53:36 +0000 (UTC) (envelope-from daw@cs.berkeley.edu) Received: from taverner.cs.berkeley.edu (taverner.CS.Berkeley.EDU [128.32.168.222]) by mx1.freebsd.org (Postfix) with ESMTP id 398ED8FC15; Sun, 16 Aug 2009 21:53:36 +0000 (UTC) Received: from taverner.cs.berkeley.edu (localhost.localdomain [127.0.0.1]) by taverner.cs.berkeley.edu (8.14.2/8.14.2) with ESMTP id n7GL9JW5029607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Aug 2009 14:09:19 -0700 Received: (from daw@localhost) by taverner.cs.berkeley.edu (8.14.2/8.14.2/Submit) id n7GL9JNK029605; Sun, 16 Aug 2009 14:09:19 -0700 From: David Wagner Message-Id: <200908162109.n7GL9JNK029605@taverner.cs.berkeley.edu> To: rwatson@FreeBSD.org (Robert Watson) Date: Sun, 16 Aug 2009 14:09:19 -0700 (PDT) In-Reply-To: from "Robert Watson" at Aug 16, 2009 09:06:41 PM Secret-Bounce-Tag: 9a029cbee41caf2ca77a77efa3c13981 X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 16 Aug 2009 22:28:44 +0000 Cc: freebsd-hackers@FreeBSD.org, linux-kernel@vger.kernel.org, David Wagner , Oliver Pinter Subject: Re: Security: information leaks in /proc enable keystroke recovery X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 21:53:36 -0000 Thanks for the comments. > Beyond this, and assuming the correct implementation of the above, > we're into the grounds of classic trusted OS covert channel analysis, > against which no COTS UNIX OSes I'm aware of are hardened. This isn't to > dismiss these attacks as purely hypothetical -- we've seen some rather > compelling examples of covert channels being exploited in unexpected > and remarkably practical ways in the last few years (Steven Murdoch's > "Hot or Not" paper takes the cake in that regard, I think). To be pedantic, I'd say that the Usenix Security paper describes a side channel, not a covert channel. The paper shows how a malicious attacker can attack an unsuspecting victim application. Covert channels are when both the sender and the receiver are malicious and cooperating to transmit information from the sender to the receiver. In contrast, side channels arise when the "sender" is unintentionally and inadvertently leaking information that can be decoded by a malicious receiver, against the interests of the "sender". The attack in the paper is a side channel, not a covert channel. When it comes to covert channels, it is indeed reasonable to throw up your hands and say that defending against covert channels is basically impossible, so why bother? For side channels, though, it's less clear that this is a persuasive argument. I agree we certainly shouldn't discuss the keystroke recovery attack as hypothetical, because it is clearly not hypothetical: the authors implemented it and found that it works. > However, this next step up from "the kernel doesn't reveal information on > processes from other users" involves scheduler hardening, consideration > of inter-CPU/core/thread cache interactions, and so on -- things that we > don't have a good research, let alone production, OS understanding of. Indeed. A major challenge. Good to hear that, in its default configuration, FreeBSD does eliminate the attack vector described in the Usenix Security paper (the EIP/ESP leak). It seems a good starting point would be to limit access to information that we know can enable keystroke recovery -- as FreeBSD apparently already does, but Linux apparently does not. From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 16 23:25:11 2009 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 685701065672 for ; Sun, 16 Aug 2009 23:25:11 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 296F38FC15 for ; Sun, 16 Aug 2009 23:25:11 +0000 (UTC) Received: from [192.168.2.101] (host81-155-13-237.range81-155.btcentralplus.com [81.155.13.237]) by cyrus.watson.org (Postfix) with ESMTPSA id A8A0046B0C; Sun, 16 Aug 2009 19:25:09 -0400 (EDT) Message-Id: <7F29E9E1-AB92-45E3-9DF3-C8455533BA19@FreeBSD.org> From: "Robert N. M. Watson" To: David Wagner In-Reply-To: <200908162109.n7GL9JNK029605@taverner.cs.berkeley.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 17 Aug 2009 00:25:07 +0100 References: <200908162109.n7GL9JNK029605@taverner.cs.berkeley.edu> X-Mailer: Apple Mail (2.936) Cc: freebsd-hackers@FreeBSD.org, linux-kernel@vger.kernel.org, Oliver Pinter Subject: Re: Security: information leaks in /proc enable keystroke recovery X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 23:25:11 -0000 On 16 Aug 2009, at 22:09, David Wagner wrote: >> Beyond this, and assuming the correct implementation of the above, >> we're into the grounds of classic trusted OS covert channel analysis, >> against which no COTS UNIX OSes I'm aware of are hardened. This >> isn't to >> dismiss these attacks as purely hypothetical -- we've seen some >> rather >> compelling examples of covert channels being exploited in unexpected >> and remarkably practical ways in the last few years (Steven Murdoch's >> "Hot or Not" paper takes the cake in that regard, I think). > > To be pedantic, I'd say that the Usenix Security paper describes a > side > channel, not a covert channel. The paper shows how a malicious > attacker > can attack an unsuspecting victim application. > > Covert channels are when both the sender and the receiver are > malicious > and cooperating to transmit information from the sender to the > receiver. > In contrast, side channels arise when the "sender" is unintentionally > and inadvertently leaking information that can be decoded by a > malicious > receiver, against the interests of the "sender". The attack in the > paper is a side channel, not a covert channel. When it comes to > covert > channels, it is indeed reasonable to throw up your hands and say that > defending against covert channels is basically impossible, so why > bother? > For side channels, though, it's less clear that this is a persuasive > argument. Hi David-- I see what you're saying, but I'm not sure I entirely agree on the pedantic definitions front ("two can play at this game"). Historically interesting definitions in DoD 5200.28-STD ("The Orange Book") and NCSC-TG-030 ("A Guide to Understanding Covert Channel Analysis of Trusted Systems") are decidedly hazy on the concept of intention, with some portions specific on its involvement and others entirely disregarding it. These definitions come out of trusted OS research/ development, and might be considered historically anachronistic by some. To my mind, the OS timing issue we're discussing meet two of the definitions of "covert channel" presented in NCSC-TG-030: Definition 4: Covert channels are those that "use entities not normally viewed as data objects to transfer information from one subject to another." Definition 5: Given a non-discretionary (e.g., mandatory) security policy model M and its interpretation I(M) in an operating system, any potential communication between two subjects I(Sh) and I(Si) of I(m) is covert if and only if any communication between the corresponding subject Sh and Si of the model M is illegal in M. Which is to say: what makes something a "covert channel" is not the intention to communicate in violation of a policy, but the *possibility* of communication in violation of system design or security policy. Both documents are concerned primarily with intentional leakage/corruption of information in confidentiality and integrity policies, but their definitions appear more general. The use of the word "mandatory" here is certainly one that also bears consideration: I would argue that the system integrity constraints of historic UNIX, such as those on inter-process control vectors (debugging, signals, ...) do in fact constitute a mandatory policy, albeit not based on information flow control or a particularly clean or well-documented model. As an example: unprivileged users are permitted only limited scope under the discretionary access control policy to delegate rights for objects they own. They can delegate to another user write access to a file via open(2), but not the right to chown the file using chown(2), signal a process using kill(2), etc, making the protections that prevent these operations "mandatory". I would argue that undesired information leakage via I/O timing across process monitoring interfaces qualifies as a covert channel under both definitions above: it's not an intended communication channel provided by the OS design, and that the OS security policy is not intended to allow unintentional communication of I/O data without explicit delegation. The historic covert channel analysis of the timing problem, drawn out in somewhat painful detail in NCSC-TG-030, seems pretty much to apply to this problem. I wouldn't argue that EIP leakage in procfs counted, on the other hand, as it appears to be an intentional, if in retrospect unfortunate, part of the design and policy. I wouldn't doubt that countless other similar "oh, perhaps not" cases of information leakage exist across countless variations on the UNIX theme due to monitoring and debugging interfaces -- for example, netstat's reporting of TCP pending send/receive queues seems likely subject to quite similar problems, as with timestamps on device nodes in /dev, even network interface or protocol statistics from netstat. Coming down on the other side of pedantic, BTW, the Orange Book's definition of "Covert storage channels" seems to ignore intention, "Covert timing channels" seems to require it. >> However, this next step up from "the kernel doesn't reveal >> information on >> processes from other users" involves scheduler hardening, >> consideration >> of inter-CPU/core/thread cache interactions, and so on -- things >> that we >> don't have a good research, let alone production, OS understanding >> of. > > Indeed. A major challenge. Good to hear that, in its default > configuration, FreeBSD does eliminate the attack vector described in > the Usenix Security paper (the EIP/ESP leak). It seems a good > starting > point would be to limit access to information that we know can enable > keystroke recovery -- as FreeBSD apparently already does, but Linux > apparently does not. NCSC-TG-030 has quite a bit to say on the topic of these sorts of things, albeit addressed at a different context and in a different time. I find myself skeptical that the sorts of protections we are waving our hands at apply all that well to UNIX-like systems due to their origin as time-sharing systems. However, I think a more interesting place to direct this analysis would be the current flush of hypervisors, which appear (possibly even claim) to offer much stronger separation in a less time-sharesque way. Robert From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 17 00:58:37 2009 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 BCABB1065672; Mon, 17 Aug 2009 00:58:37 +0000 (UTC) (envelope-from daw@cs.berkeley.edu) Received: from taverner.cs.berkeley.edu (taverner.CS.Berkeley.EDU [128.32.168.222]) by mx1.freebsd.org (Postfix) with ESMTP id 89CE28FC41; Mon, 17 Aug 2009 00:58:37 +0000 (UTC) Received: from taverner.cs.berkeley.edu (localhost.localdomain [127.0.0.1]) by taverner.cs.berkeley.edu (8.14.2/8.14.2) with ESMTP id n7H0wa4X005384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Aug 2009 17:58:37 -0700 Received: (from daw@localhost) by taverner.cs.berkeley.edu (8.14.2/8.14.2/Submit) id n7H0wahu005383; Sun, 16 Aug 2009 17:58:36 -0700 From: David Wagner Message-Id: <200908170058.n7H0wahu005383@taverner.cs.berkeley.edu> To: rwatson@FreeBSD.org (Robert N. M. Watson) Date: Sun, 16 Aug 2009 17:58:36 -0700 (PDT) In-Reply-To: <7F29E9E1-AB92-45E3-9DF3-C8455533BA19@FreeBSD.org> from "Robert N. M. Watson" at Aug 17, 2009 12:25:07 AM Secret-Bounce-Tag: 9a029cbee41caf2ca77a77efa3c13981 X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 17 Aug 2009 01:12:41 +0000 Cc: freebsd-hackers@FreeBSD.org, linux-kernel@vger.kernel.org, David Wagner , Oliver Pinter Subject: Re: Security: information leaks in /proc enable keystroke recovery 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, 17 Aug 2009 00:58:37 -0000 I still think my definitions of "covert channel" vs "side channel" better reflect accepted usage these days, but whatever. I don't have any great desire to debate the definitions. That doesn't seem like a good use of everyone's time. I was trying to define some shorthand to more concisely make my point. Since it appears my preferred shorthand turned out to be a barrier to communication, rather than an aid, I'll try to make my point again, this time spelling it out without using the problematic shorthand. I care more about the ultimate point than the language we use to communicate it. My broader point is this: I accept your argument that there is no point trying to defend against deliberate communication of information between two cooperating processes via some sneaky channel; there is no hope of stopping that in general-purpose commodity OS's. If process X and Y are both colluding to send information from X to Y, they will succeed, no matter how hard we try. We have no hope of closing all such channels, for general-purpose commodity OS's (like FreeBSD or Linux). However I do not accept that this argument means we should throw up our hands and ignore cases where the kernel allows malicious process Y to spy on process X, against X's will. If the kernel has a leak that lets process Y eavesdrop on keystrokes typed into process X, that's arguably worth fixing. Trying to prevent that is not clearly hopeless. There is a significant difference in threat model between "both X and Y are malicious and colluding with each other to facilitate some joint purpose shared by both X and Y" vs "Y is malicious and is attempting to subvert the security of process X, against X's will". If the designers deliberately intended to allow process Y to snoop on the ESP and EIP of process X, even when there is no relationship between X and Y (e.g., they don't have the same uid, and Y isn't root), well, I would claim that was a design error. Facilitating keystroke recovery does not seem like a good design goal. It's possible that the impact could be broader than discussed in the Usenix Security paper. Imagine if process X is doing crypto, say an RSA decryption, and process Y is running on the same machine and is malicious. If process Y is allowed to observe the EIP of process X, then process Y may be able to observe which path process X has taken through the code. In some cases, such as a naive implementation of RSA decryption, this may reveal X's private key. Leaking EIP and ESP to every other user on the same system strikes me as pretty dubious. From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 17 10:11:19 2009 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 0B03D1065690 for ; Mon, 17 Aug 2009 10:11:19 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BB1488FC5B for ; Mon, 17 Aug 2009 10:11:18 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 3C6BB46B29; Mon, 17 Aug 2009 06:11:18 -0400 (EDT) Date: Mon, 17 Aug 2009 11:11:18 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: David Wagner In-Reply-To: <200908170058.n7H0wahu005383@taverner.cs.berkeley.edu> Message-ID: References: <200908170058.n7H0wahu005383@taverner.cs.berkeley.edu> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@FreeBSD.org, linux-kernel@vger.kernel.org, Oliver Pinter Subject: Re: Security: information leaks in /proc enable keystroke recovery 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, 17 Aug 2009 10:11:19 -0000 On Sun, 16 Aug 2009, David Wagner wrote: > I accept your argument that there is no point trying to defend against > deliberate communication of information between two cooperating processes > via some sneaky channel; there is no hope of stopping that in > general-purpose commodity OS's. If process X and Y are both colluding to > send information from X to Y, they will succeed, no matter how hard we try. > We have no hope of closing all such channels, for general-purpose commodity > OS's (like FreeBSD or Linux). Moving beyind EIP/ESP, which are clearly a bad idea: The OS community has not engaged well with the concerns raised by past cache-based crypto side channels, in part because it seemed the least complex solution was hardening crypto against having key-driven footprints in the cache. However, the problem they represent (avoiding the use of shared resources between mutually untrusting processes, and then mitigating efects that remain) definitely sounds like the covert channel problem, with very similar concerns extensively discussed in the documents I referred to. In an interactive system, the scheduling of threads in a process reflect the completion of various events: user I/O, network I/O, disk I/O, or perhaps the expiration of a timer associated with application-internal events (animations, statistics, etc). Monitoring these from another process is intentionally easy on commodity OS's -- there are a variety of monitoring statistics, from the already mentioned process/thread execution time, to context switch counters, wait channels/addresses, lock states, timestamps on special devices, etc, not to mention having CPU sink processes that nice themselves appropriately and hang around monitoring execution of other processes/threads/the kernel through gaps in its own scheduling. Some of the intentional mechanisms are specific to processes, and easy to block by policy. Others are global, and begin the sliding down the slope of "making the system and applications a lot harder to analyze and debug", something that sites frequently hosting large numbers of mutually untrusting users (web farms) may not be willing to deal do. Into the area of techniques that annoy people: my guess is that you may also be able to measure the context switching of processes on other CPUs through very careful timing of events in the kernel on your local CPU. For example, it's a reasonable bet that using the TSC and carefully selected system calls/arguments, you can measure cache line behavior associated with kernel scheduler/statistic lines that will be pulled to another CPU when a context switch takes place. For example, consider per-CPU run queue locks or context switch statistics, which may in edge cases be pulled to another CPU, such as when monitoring takes place. If they are already local to the attacking CPU, no context switch has taken place on the other CPU since you last checked; if they're non-local, a context switch has taken place. Following Colin Percival's paper on cache side channels for RSA, there was a lot of discussion about how the OS could help mitigate these problems: do you provide "security critical sections" around cryptography which introduce temporary but performance-degrading mutual exclusion of caches based on knowledge of the CPU topology, for example. Identifying and offering similar trade-offs between performance and security, avoiding excess complexity, and in particular, limiting the scope of those performance losses to only critical moments will be key if the security community wants to engage the OS community here. Otherwise I suspect these concerns will pass by, unaddressed, again. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 17 14:11:50 2009 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 6A09B106568B for ; Mon, 17 Aug 2009 14:11:50 +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 3D4D38FC3F for ; Mon, 17 Aug 2009 14:11:50 +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 E430346B2D; Mon, 17 Aug 2009 10:11:49 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 3F5338A01D; Mon, 17 Aug 2009 10:11:49 -0400 (EDT) From: John Baldwin To: "Andrey V. Elsukov" Date: Mon, 17 Aug 2009 09:32:54 -0400 User-Agent: KMail/1.9.7 References: <147751250284069@webmail117.yandex.ru> In-Reply-To: <147751250284069@webmail117.yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908170932.54700.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 17 Aug 2009 10:11:49 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-hackers@freebsd.org Subject: Re: Howto setup multiboot with GPT? 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, 17 Aug 2009 14:11:50 -0000 On Friday 14 August 2009 5:07:49 pm Andrey V. Elsukov wrote: > Hi, > > I have installed 8.0-BETA2 amd64 on ZFS root with GPT. I made addition partition and > made new ZFS pool, builded and installed i386 world and kernel to this pool. > So, is there some way to select from which partition i want to boot? Not currently unless you hardcode a specific partition in /boot.config. (You may need a patch from jhay@ to fix the parsing of that file though.) I believe someone (can't recall who) has some changes in a p4 branch to extend gptboot to support a fancier interface with a menu of possible partitions, etc. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 17 15:14:43 2009 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 93AC7106568C; Mon, 17 Aug 2009 15:14:43 +0000 (UTC) (envelope-from artis.caune@gmail.com) Received: from mail-fx0-f205.google.com (mail-fx0-f205.google.com [209.85.220.205]) by mx1.freebsd.org (Postfix) with ESMTP id EF7D28FC67; Mon, 17 Aug 2009 15:14:41 +0000 (UTC) Received: by fxm1 with SMTP id 1so2340920fxm.7 for ; Mon, 17 Aug 2009 08:14:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AAuwRHtU+PByYtCshpR8csbwc14txjcXbNGuqP0YFpY=; b=oEE1JWQhfVsOhPqvq40zS7cW3CEZrJPpf9joT352krxmcjjvdgXsUBLHPm9uj1gx9y 1kMJqrjhqvqEf62VWN3kz6955B8aM30H/mZfIUZzbs3DqYYMzC1UUHUgSHjWj82grgSR bvtI7eNXbIdYXs1TYdD4WtzlRvMOd7VkOtDK0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NhpOFiUwsrXxywqIBvr2DCf28Ji0Fm+F6utUx/EJ4sEa9EVhUfWzGU00u3DcvquZCI I43Uqf+uXnyDc0m5fMMvbhlajZ4cFTzknHkBpa1/sqQaWQp8ZYrbWlTLatZSnRa/P1gw oDA58pd56R7BY+/gfjfZ9CeMzA4VP6fY6VSiM= MIME-Version: 1.0 Received: by 10.103.76.10 with SMTP id d10mr1354990mul.9.1250520228349; Mon, 17 Aug 2009 07:43:48 -0700 (PDT) In-Reply-To: <147751250284069@webmail117.yandex.ru> References: <147751250284069@webmail117.yandex.ru> Date: Mon, 17 Aug 2009 17:43:48 +0300 Message-ID: <9e20d71e0908170743v49cad8f6le715524ce93331b7@mail.gmail.com> From: Artis Caune To: "Andrey V. Elsukov" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Howto setup multiboot with GPT? 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, 17 Aug 2009 15:14:43 -0000 2009/8/15 Andrey V. Elsukov : > Hi, > > I have installed 8.0-BETA2 amd64 on ZFS root with GPT. I made addition pa= rtition and > made new ZFS pool, builded and installed i386 world and kernel to this po= ol. > So, is there some way to select from which partition i want to boot? > > My configuration: >> gpart show ad10 > =3D> =C2=A0 =C2=A0 =C2=A0 =C2=A034 =C2=A01250263661 =C2=A0ad10 =C2=A0GPT = =C2=A0(596G) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A034 =C2=A0 =C2=A0 =C2=A0 =C2=A0 256 =C2= =A0 =C2=A0 1 =C2=A0freebsd-boot =C2=A0(128K) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 290 =C2=A0 =C2=A0 8388608 =C2=A0 =C2=A0 2 =C2= =A0freebsd-swap =C2=A0(4.0G) > =C2=A0 =C2=A0 8388898 =C2=A0 209715200 =C2=A0 =C2=A0 3 =C2=A0freebsd-zfs = =C2=A0(100G) > =C2=A0 218104098 =C2=A0 209715200 =C2=A0 =C2=A0 4 =C2=A0freebsd-zfs =C2= =A0(100G) > =C2=A0 427819298 =C2=A0 822444397 =C2=A0 =C2=A0 =C2=A0 =C2=A0- free - =C2= =A0(392G) > >> zpool list > NAME =C2=A0 =C2=A0SIZE =C2=A0 USED =C2=A0AVAIL =C2=A0 =C2=A0CAP =C2=A0HEA= LTH =C2=A0ALTROOT > amd64 =C2=A099,5G =C2=A010,5G =C2=A089,0G =C2=A0 =C2=A010% =C2=A0ONLINE = =C2=A0- > x86 =C2=A0 =C2=A099,5G =C2=A0 346M =C2=A099,2G =C2=A0 =C2=A0 0% =C2=A0ONL= INE =C2=A0/mnt > >> cat /boot/loader.conf > zfs_load=3D"YES" > vfs.root.mountfrom=3D"zfs:amd64" You can try using one freebsd-zfs partition, one pool and just change bootfs zpool property: # zpool create rpool ad10p3 # zfs create rpool/ROOT/amd64 # zfs create rpool/ROOT/x86 # zpool set bootfs=3Drpool/amd64 rpool echo 'vfs.root.mountfrom=3D"zfs:rpool/amd64"' >> /ROOT/amd64/boot/loader.co= nf echo 'vfs.root.mountfrom=3D"zfs:rpool/x86"' >> /ROOT/x86/boot/loader.conf and then change bootfs on the fly: amd64# zpool set bootfs=3Drpool/x86 rpool amd64# reboot x86# zpool set bootfs=3Drpool/amd64 rpool x86# reboot --=20 Artis Caune Everything should be made as simple as possible, but not simpler. From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 17 16:51:37 2009 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 B6F2F106568D for ; Mon, 17 Aug 2009 16:51:37 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.freebsd.org (Postfix) with SMTP id 29C4D8FC69 for ; Mon, 17 Aug 2009 16:51:20 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 36D9B3981D; Mon, 17 Aug 2009 18:32:31 +0200 (SAST) Date: Mon, 17 Aug 2009 18:32:31 +0200 From: John Hay To: "Andrey V. Elsukov" Message-ID: <20090817163230.GA68166@zibbi.meraka.csir.co.za> References: <147751250284069@webmail117.yandex.ru> <200908170932.54700.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908170932.54700.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org Subject: Re: Howto setup multiboot with GPT? 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, 17 Aug 2009 16:51:37 -0000 On Mon, Aug 17, 2009 at 09:32:54AM -0400, John Baldwin wrote: > On Friday 14 August 2009 5:07:49 pm Andrey V. Elsukov wrote: > > Hi, > > > > I have installed 8.0-BETA2 amd64 on ZFS root with GPT. I made addition partition and > > made new ZFS pool, builded and installed i386 world and kernel to this pool. > > So, is there some way to select from which partition i want to boot? > > Not currently unless you hardcode a specific partition in /boot.config. (You > may need a patch from jhay@ to fix the parsing of that file though.) I > believe someone (can't recall who) has some changes in a p4 branch to extend > gptboot to support a fancier interface with a menu of possible partitions, > etc. My patch is only for gptboot (ufs partitions). From what I looked at gptzfsboot, it only looks at the first pool. You can boot from different filesystems inside a pool though. You can set that with zpool set bootfs=pool/dataset John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 19 03:39:08 2009 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 508AF106568C for ; Wed, 19 Aug 2009 03:39:08 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 9EC018FC16 for ; Wed, 19 Aug 2009 03:39:07 +0000 (UTC) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n7J3NWRj069963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 19 Aug 2009 12:53:33 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-hackers@freebsd.org Date: Wed, 19 Aug 2009 12:53:20 +0930 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3105456.LXgneOTOXJ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200908191253.27951.doconnor@gsoft.com.au> X-Spam-Score: -3.601 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Subject: PCI IRQ latency 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, 19 Aug 2009 03:39:08 -0000 --nextPart3105456.LXgneOTOXJ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, We have a custom PCI (slave only, very slow) card to do data transfer,=20 and on some systems we are seeing problems with the data source FIFO=20 filling up. The data rate is 1.7Mb/sec and the FIFO is 96k in size, however it only=20 generates an IRQ when it has 16k of data in it, so it should have=20 ~4.5msec of buffer available once an IRQ is issued. The systems are Supermicro C2SBA+ with Core 2 Duos of varying speeds=20 (~1.5GHz) running FreeBSD 6.2 amd64. The kernel conf is basically=20 GENERIC, although I have also tried compiling out SMP but the problem=20 still persists. The card is not sharing an IRQ with any other card I can see (it has irq=20 20 and nothing else uses that). Due to the legacy nature of the card the interrupt handler for it is=20 pretty horrible - it reads 16k worth of data out 32 bits at a time=20 doing slave transactions. I can't do bursting because it is reading=20 from a FIFO, and due to the speed of the FIFO & cable runs each read=20 takes several PCI cycles. I did some googling and found=20 http://www.mail-archive.com/freebsd-usb%40freebsd.org/msg04576.html=20 which would seem to indicate we would be OK. Unfortunately it seems that _something_ blocks interrupts for >4=20 milliseconds, however I have no real idea how to go about finding what=20 it is.. Does anyone have any suggestions? (apart from get a new DAQ=20 card, I know this one already :) Thanks. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart3105456.LXgneOTOXJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBKi3Av5ZPcIHs/zowRAjMtAKCYT3Nc9HbO9qQudeDhAh59psI0rgCeP1k+ x2gMEz8wadGi58ji/d1/ZQE= =PVT5 -----END PGP SIGNATURE----- --nextPart3105456.LXgneOTOXJ-- From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 19 07:08:14 2009 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 9ADA6106568C for ; Wed, 19 Aug 2009 07:08:14 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by mx1.freebsd.org (Postfix) with ESMTP id 239C68FC55 for ; Wed, 19 Aug 2009 07:08:13 +0000 (UTC) Received: by bwz2 with SMTP id 2so3264030bwz.43 for ; Wed, 19 Aug 2009 00:08:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=/P4No3b5iXmCixciVw9DcPzvt3RztAVixidlH3Zlmwo=; b=pDXVGVBDz/ytwjQg5iExxNVasTnq1Kbl5lZEn3QZag9gsf8t82HYSGmnvpn90+QU+C w2EkRRq93jT4yNx3DXSgEk8sFva+zDkgj17G11KCFqni6Tw6S4M82boZthRNPwtYVfTa hKmM6JgEmP5/Glynx+BT0uwQ2o2fwnxeS4Wu4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Yv8CtpowYUXVVGCLqRIiPa2vSjUWsaOAkk3JDDCiaxRyJZ0TigspMMO+SMYp03pnBq QNdm+cO6hB4FjsHvg0jeoR5NRbSfuBQ7gO8/7ULXQjmbL0g09642b+0aaJ7j3HgQgkNu DLPajBHGNGWpUds+aY2o6U8+sZBOm3c/m9xMg= MIME-Version: 1.0 Received: by 10.216.8.78 with SMTP id 56mr1539507weq.210.1250663734574; Tue, 18 Aug 2009 23:35:34 -0700 (PDT) In-Reply-To: <200908191253.27951.doconnor@gsoft.com.au> References: <200908191253.27951.doconnor@gsoft.com.au> Date: Wed, 19 Aug 2009 02:35:34 -0400 Message-ID: <5f67a8c40908182335y59679131u373e8a3b27856909@mail.gmail.com> From: Zaphod Beeblebrox To: "Daniel O'Connor" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: PCI IRQ latency 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, 19 Aug 2009 07:08:14 -0000 On Tue, Aug 18, 2009 at 11:23 PM, Daniel O'Connor wrote: > Unfortunately it seems that _something_ blocks interrupts for >4 > milliseconds, however I have no real idea how to go about finding what > it is.. Does anyone have any suggestions? (apart from get a new DAQ > card, I know this one already :) This is a huge shot-in-the-dark, but could this be something like ACPI or some other motherboard legacy cpu-using evil? Would it be possible to test on something opposite-ish of what you're using (ie: amd vs. intel) just to cycle out all the potential goo? From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 19 07:18:37 2009 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 34122106568C for ; Wed, 19 Aug 2009 07:18:37 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 9B3F08FC6B for ; Wed, 19 Aug 2009 07:18:36 +0000 (UTC) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n7J7IXJT077922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 19 Aug 2009 16:48:34 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Zaphod Beeblebrox Date: Wed, 19 Aug 2009 16:48:20 +0930 User-Agent: KMail/1.9.10 References: <200908191253.27951.doconnor@gsoft.com.au> <5f67a8c40908182335y59679131u373e8a3b27856909@mail.gmail.com> In-Reply-To: <5f67a8c40908182335y59679131u373e8a3b27856909@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1857688.HQhRhjnCY3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200908191648.28262.doconnor@gsoft.com.au> X-Spam-Score: -3.601 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: freebsd-hackers@freebsd.org Subject: Re: PCI IRQ latency 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, 19 Aug 2009 07:18:37 -0000 --nextPart1857688.HQhRhjnCY3 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 19 Aug 2009, Zaphod Beeblebrox wrote: > On Tue, Aug 18, 2009 at 11:23 PM, Daniel O'Connor=20 wrote: > > Unfortunately it seems that _something_ blocks interrupts for >4 > > milliseconds, however I have no real idea how to go about finding > > what it is.. Does anyone have any suggestions? (apart from get a > > new DAQ card, I know this one already :) > > This is a huge shot-in-the-dark, but could this be something like > ACPI or some other motherboard legacy cpu-using evil? Would it be > possible to test on something opposite-ish of what you're using (ie: > amd vs. intel) just to cycle out all the potential goo? It's worth a shot, I'll see if I can dig up some other hardware, thanks. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1857688.HQhRhjnCY3 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBKi6dE5ZPcIHs/zowRAqsgAJ9WNdRa3jJDo8kuzmTeYirStXQWjgCgpBBt EFUY0XhqWSdGNv8Quh8p12M= =+wq0 -----END PGP SIGNATURE----- --nextPart1857688.HQhRhjnCY3-- From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 19 07:22:21 2009 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 A891C106564A for ; Wed, 19 Aug 2009 07:22:21 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 1D4A28FC3F for ; Wed, 19 Aug 2009 07:22:20 +0000 (UTC) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n7J7MIFC078084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 19 Aug 2009 16:52:19 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-hackers@freebsd.org Date: Wed, 19 Aug 2009 16:52:10 +0930 User-Agent: KMail/1.9.10 References: <200908191253.27951.doconnor@gsoft.com.au> In-Reply-To: <200908191253.27951.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2910627.2lzZYsk1vF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200908191652.11825.doconnor@gsoft.com.au> X-Spam-Score: -3.601 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Subject: Re: PCI IRQ latency 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, 19 Aug 2009 07:22:21 -0000 --nextPart2910627.2lzZYsk1vF Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 19 Aug 2009, Daniel O'Connor wrote: > Unfortunately it seems that _something_ blocks interrupts for >4 > milliseconds, however I have no real idea how to go about finding > what it is.. Does anyone have any suggestions? (apart from get a new > DAQ card, I know this one already :) Actually it appears I have misread my diagnostics and it's not a lack of=20 interrupts, rather the reading process gets stalled (by up to 5 seconds=20 at a time). Sorry for the noise :( =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart2910627.2lzZYsk1vF Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBKi6gj5ZPcIHs/zowRAk1fAJ0dqcFUW1/g4lPg33xmt8ZK5bEBUwCfZfN/ sUn1B1h83gfDAYlNjwqqL5U= =FWY7 -----END PGP SIGNATURE----- --nextPart2910627.2lzZYsk1vF-- From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 19 09:11:30 2009 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 C9A4E106568C; Wed, 19 Aug 2009 09:11:30 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 8B9778FC43; Wed, 19 Aug 2009 09:11:30 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 122126D41C; Wed, 19 Aug 2009 09:11:29 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id CC881844FF; Wed, 19 Aug 2009 03:57:44 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: David Wagner References: <200908162109.n7GL9JNK029605@taverner.cs.berkeley.edu> Date: Wed, 19 Aug 2009 03:57:44 +0200 In-Reply-To: <200908162109.n7GL9JNK029605@taverner.cs.berkeley.edu> (David Wagner's message of "Sun, 16 Aug 2009 14:09:19 -0700 (PDT)") Message-ID: <861vn85zvr.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@FreeBSD.org, Robert Watson , linux-kernel@vger.kernel.org, Oliver Pinter Subject: Re: Security: information leaks in /proc enable keystroke recovery 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, 19 Aug 2009 09:11:30 -0000 David Wagner writes: > I agree we certainly shouldn't discuss the keystroke recovery attack > as hypothetical, because it is clearly not hypothetical: the authors > implemented it and found that it works. It *is* hypothetical. They were able to collect some keystrokes (but not all) in Linux, but IIUC, all they could do in FreeBSD was figure out whether or not a key was pressed at a certain time (or during a certain interval). They *hypothesize* that the interval between keystrokes can be used to identify the keys being pressed, but they haven't actually done it. I can imagine - purely hypothetically - that it would be possible, but only while the user was typing running text; the parameters would vary greatly from typist to typist, and between keyboard layouts, and you could probably defeat it pretty easily (at least some of the time) by deliberately typing slowly and arythmically, e.g. typing in your password with only one finger. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 19 14:01:39 2009 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 336BC106568D for ; Wed, 19 Aug 2009 14:01:39 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id A21878FC59 for ; Wed, 19 Aug 2009 14:01:38 +0000 (UTC) Received: from inchoate.gsoft.com.au (ppp121-45-173-89.lns11.adl2.internode.on.net [121.45.173.89]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n7JE1ai5090506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 19 Aug 2009 23:31:36 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-hackers@freebsd.org Date: Wed, 19 Aug 2009 23:31:33 +0930 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1676344.O99117rbn3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200908192331.34507.doconnor@gsoft.com.au> X-Spam-Score: -1.507 () AWL,BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Subject: DTrace probes & klds 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, 19 Aug 2009 14:01:39 -0000 --nextPart1676344.O99117rbn3 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Is it possible? the handbook implies not and I can't get it to work, but=20 i could be doing it wrong.. I get fbt traces listed for KLDs (I get new entries for each load of the=20 KLD which seems like a potential problem) but I can't specify an=20 SDT_PROBE and have it work. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1676344.O99117rbn3 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBKjAW+5ZPcIHs/zowRAn7MAKCDq3FLib203Z2c4ddABFt5BQkk4wCgjXr3 MjQicr+Iusexj2tX9VLXPO0= =dcXx -----END PGP SIGNATURE----- --nextPart1676344.O99117rbn3-- From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 20 07:43:13 2009 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 86DE9106568F for ; Thu, 20 Aug 2009 07:43:13 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id D49E08FC6E for ; Thu, 20 Aug 2009 07:43:12 +0000 (UTC) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n7K7hAPp041188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 20 Aug 2009 17:13:10 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Alexander Leidinger Date: Thu, 20 Aug 2009 17:13:07 +0930 User-Agent: KMail/1.9.10 References: <200908192331.34507.doconnor@gsoft.com.au> <20090820081740.436656fu6d4fxoso@webmail.leidinger.net> In-Reply-To: <20090820081740.436656fu6d4fxoso@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4089526.Djy7DDgXFa"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200908201713.08368.doconnor@gsoft.com.au> X-Spam-Score: -3.599 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: freebsd-hackers@freebsd.org Subject: Re: DTrace probes & klds 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, 20 Aug 2009 07:43:13 -0000 --nextPart4089526.Djy7DDgXFa Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thu, 20 Aug 2009, Alexander Leidinger wrote: > Quoting Daniel O'Connor (from Wed, 19 Aug > 2009 > > 23:31:33 +0930): > > Content-Type: text/plain; > > charset=3D"utf-8" > > Content-Transfer-Encoding: quoted-printable > > Content-Disposition: inline > > > > Is it possible? the handbook implies not and I can't get it to > > work, but i could be doing it wrong.. > > > > I get fbt traces listed for KLDs (I get new entries for each load > > of the KLD which seems like a potential problem) but I can't > > specify an SDT_PROBE and have it work. > > Can you show us some example code? /* Recycle fbt as SDT_PROVIDER_DEFINE is said not to work */ SDT_PROBE_DEFINE(fbt, gsio, gsio_intr, test); SDT_PROBE_ARGTYPE(fbt, gsio, gsio_intr, test, 0, "int"); SDT_PROBE_ARGTYPE(fbt, gsio, gsio_intr, test, 1, "int"); =2E.. static void gsio_intr(void *varg) { =2E.. istat =3D g_lcr_inl(sc, PLX_INTCSR); =2E.. SDT_PROBE(fbt, gsio, gsio_intr, test, istat, 0, 0, 0, 0); > In > http://svn.freebsd.org/viewvc/base/user/netchild/linuxulator-dtrace/s >rc/sys/compat/linux/linux_emul.c?revision=3D185383&view=3Dmarkup I have > code which worked at least at some point in time when loaded as a > KLD. Hmm OK, this is on a 7.x system which doesn't have any SDT* stuff in the=20 linuxlator (except for FBT probes) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart4089526.Djy7DDgXFa Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBKjP6M5ZPcIHs/zowRAoRpAJ9kJj1AQeB+1eFRpBbD3tvIxhtDvQCgj8Op ypOO/ERNThpmPrd62dZpvJE= =ViiU -----END PGP SIGNATURE----- --nextPart4089526.Djy7DDgXFa-- From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 20 06:37:43 2009 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 663EC1065672 for ; Thu, 20 Aug 2009 06:37:43 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 0FD6E8FC3D for ; Thu, 20 Aug 2009 06:37:43 +0000 (UTC) Received: from outgoing.leidinger.net (pD9E2C1E2.dip.t-dialin.net [217.226.193.226]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 6B450844169; Thu, 20 Aug 2009 08:17:45 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id F19185B22; Thu, 20 Aug 2009 08:17:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1250749062; bh=GW+sXoqEL6+0KwHT6TLIOf1ewCdSUiY1Wz/o/TPIZnQ=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=WjeQWCxd8XVFiZhm6zv0MBXvZSgnW9zBnWTn4Zhcja962avnG/fTgy6NRQtDQffYx IGSn+vUpBTIbSaXSeNnTqRusChN6jxbwMkCb9sMBlSscacTg5fQpPGcc8u7XVURVop UZ6jktk4JqsT9iZP75BGqZYeuScWXCHIISZGsWbYvQrZRHkIXVRAZq2SN9wNBupi68 +ggkE0s1q4wY6/4/pd2cUvTX8pxeafpcvq6wgBwnsAPwFFX9vJ2UdOpaCtz3v8WQlG 8JD79ROSO8PvfDlSzXnPSqRMLQZqc851CpIMHLEa9b6ApCPbqTkIjgiDdQ/hjaS8HL XZ8EejA567aIQ== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id n7K6HfKO008692; Thu, 20 Aug 2009 08:17:41 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Thu, 20 Aug 2009 08:17:40 +0200 Message-ID: <20090820081740.436656fu6d4fxoso@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Thu, 20 Aug 2009 08:17:40 +0200 From: Alexander Leidinger To: "Daniel O'Connor" References: <200908192331.34507.doconnor@gsoft.com.au> In-Reply-To: <200908192331.34507.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.3.3 / FreeBSD-8.0 X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 6B450844169.B88AB X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.44, required 6, autolearn=disabled, ALL_TRUSTED -1.44, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1251353868.82315@DyV5BtilVqTYXqxD7bUMIg X-EBL-Spam-Status: No X-Mailman-Approved-At: Thu, 20 Aug 2009 12:03:17 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: DTrace probes & klds 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, 20 Aug 2009 06:37:43 -0000 Quoting Daniel O'Connor (from Wed, 19 Aug 2009 23:31:33 +0930): > Content-Type: text/plain; > charset="utf-8" > Content-Transfer-Encoding: quoted-printable > Content-Disposition: inline > > Is it possible? the handbook implies not and I can't get it to work, but > i could be doing it wrong.. > > I get fbt traces listed for KLDs (I get new entries for each load of the > KLD which seems like a potential problem) but I can't specify an > SDT_PROBE and have it work. Can you show us some example code? In http://svn.freebsd.org/viewvc/base/user/netchild/linuxulator-dtrace/src/sys/compat/linux/linux_emul.c?revision=185383&view=markup I have code which worked at least at some point in time when loaded as a KLD. Bye, Alexander. -- A vacuum is a hell of a lot better than some of the stuff that nature replaces it with. -- Tennessee Williams http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 20 15:30:39 2009 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 207AB106568F for ; Thu, 20 Aug 2009 15:30:39 +0000 (UTC) (envelope-from lgj@usenix.org) Received: from lonestar.usenix.org (lonestar.usenix.org [131.106.3.102]) by mx1.freebsd.org (Postfix) with ESMTP id F41F08FC88 for ; Thu, 20 Aug 2009 15:30:38 +0000 (UTC) Received: from vesper.usenix.org (vesper.usenix.org [131.106.3.142]) by lonestar.usenix.org (8.14.2/8.14.2) with ESMTP id n7KFP9ji011860 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 20 Aug 2009 08:30:38 -0700 (PDT) Message-Id: <3A4FB166-BF5E-48A4-A654-D330CA111192@usenix.org> From: Lionel Garth Jones To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 20 Aug 2009 08:30:40 -0700 X-Mailer: Apple Mail (2.930.3) X-DCC-Usenix-Metrics: lonestar; whitelist X-Spam-Status: No, score=-1.4 required=6.0 tests=ALL_TRUSTED autolearn=failed version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on lonestar X-Mailman-Approved-At: Thu, 20 Aug 2009 15:38:09 +0000 Subject: USENIX SustainIT '10 Call For Papers Now Available 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, 20 Aug 2009 15:30:39 -0000 The Program Committee for the the First USENIX Workshop on Sustainable Information Technology (SustainIT '10) invites you to submit your papers. Increasingly, designers of computer systems ranging from small mobile devices to massive datacenters are concerned with sustainable design, including both power and life-cycle costs; these costs should include manufacturing, operation, and disposal of IT systems. We seek papers that evaluate energy-related issues and their aforementioned trade-offs, present novel new ideas, challenge and/or debunk past and present practices, and more. We especially encourage papers that discuss not just energy issues but also how they interact with other dimensions in a sustainable manner. The scope of this workshop is broad, covering research, theory, hardware, software, applications, techniques, etc.--all related to making computing systems greener. Topics of interest related to energy-sustainable computing include but are not limited to: * Energy vs. performance, cost, reliability, usability, security, etc. * Evaluations of long-term total costs of ownership (TCOs, e-waste, growth rates, recycling, etc.) * Total Impact of Ownership (TIO) in the long run (even decades-long) * Workload reduction techniques (e.g., compression, dedup) * Application of virtualization, cloud computing, clustering, and workload management * Hardware-based techniques (e.g., new electronics, clock-gating, disaggregation) * Firmware-based techniques (e.g., APM, ACPI) * Right-sizing techniques (e.g., DVFS, DRPM) * Use of FLASH and other novel storage media * Impact of storage hardware and software stacks * Application-optimization techniques (e.g., compiler-based) * Theory, algorithms, and simulated results * Energy and energy-related metrics (e.g., $$$, Energy-Delay, PUE) * IT services and techniques to manage energy and reduce costs * Sustainability and life-cycle analysis * Practical energy technologies for the developing world * Datacenter techniques (e.g., blade servers, low-power CPUs) * Software-based techniques at all levels, from OS/kernel to applications * Evaluation and modification of business processes to reduce the environmental impact * Economics of energy-efficienct software and hardware design * New datacenter cooling and energy-management issues and designs, including use of renewable energy sources * Thermal and computational fluid dynamics (CFD) models for software and hardware co-design Please submit your work by November 9, 2009. More information and submission guidelines are available at http://www.usenix.org/sustainit10/cfpa SustainIT '10 will take place February 22, 2010, in San Jose, CA. It will be co-located with the 8th USENIX Conference on File and Storage Technologies (FAST '10), which will take place February 23-26, 2010. We look forward to receiving your submissions! Sincerely, Ethan L. Miller, University of California, Santa Cruz Erez Zadok, Stony Brook University SustainIT '10 Program Co-Chairs sustainit10chairs@usenix.org From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 20 18:06:45 2009 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 93CE61065690; Thu, 20 Aug 2009 18:06:45 +0000 (UTC) (envelope-from simon@nitro.dk) Received: from mx.nitro.dk (zarniwoop.nitro.dk [83.92.207.38]) by mx1.freebsd.org (Postfix) with ESMTP id 521EA8FC16; Thu, 20 Aug 2009 18:06:45 +0000 (UTC) Received: from arthur.nitro.dk (arthur.bofh [192.168.2.3]) by mx.nitro.dk (Postfix) with ESMTP id 21B3A2D48D7; Thu, 20 Aug 2009 18:06:44 +0000 (UTC) Received: by arthur.nitro.dk (Postfix, from userid 1000) id E3F045C13; Thu, 20 Aug 2009 20:06:43 +0200 (CEST) Date: Thu, 20 Aug 2009 20:06:43 +0200 From: "Simon L. Nielsen" To: John Baldwin Message-ID: <20090820180643.GA1243@arthur.nitro.dk> References: <147751250284069@webmail117.yandex.ru> <200908170932.54700.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908170932.54700.jhb@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org, "Andrey V. Elsukov" Subject: Re: Howto setup multiboot with GPT? 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, 20 Aug 2009 18:06:45 -0000 On 2009.08.17 09:32:54 -0400, John Baldwin wrote: > On Friday 14 August 2009 5:07:49 pm Andrey V. Elsukov wrote: > > Hi, > > > > I have installed 8.0-BETA2 amd64 on ZFS root with GPT. I made addition partition and > > made new ZFS pool, builded and installed i386 world and kernel to this pool. > > So, is there some way to select from which partition i want to boot? > > Not currently unless you hardcode a specific partition in /boot.config. (You > may need a patch from jhay@ to fix the parsing of that file though.) I > believe someone (can't recall who) has some changes in a p4 branch to extend > gptboot to support a fancier interface with a menu of possible partitions, > etc. I have been playing around with gptboot, but it's not ready for any kind of general use yet. So far I parse and print the complete partition table and has the start of a framework to configure gptboot directly similar to boot0cfg. One of the first features I plan to have working is to be able to select which partition to boot, but it's not the main goal - that's nextboot like functionality. The WIP can be find in FreeBSD.org perforce at //depot/user/simon/gptboot/... AKA http://p4web.freebsd.org/@md=d&cd=//depot/user/simon/gptboot/&c=2qs@//depot/user/simon/gptboot/?ac=83 -- Simon L. Nielsen From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 21 12:42:09 2009 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 7E966106568E for ; Fri, 21 Aug 2009 12:42:09 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 0C6F48FC5B for ; Fri, 21 Aug 2009 12:42:08 +0000 (UTC) Received: from outgoing.leidinger.net (pD9E2C5CB.dip.t-dialin.net [217.226.197.203]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 7AC438445A4; Fri, 21 Aug 2009 14:42:01 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 35C8912F73B; Fri, 21 Aug 2009 14:41:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1250858518; bh=rvnXtSywJa7hlJ95Wg9Nikwow/aZHs6UADe1z7CRQeQ=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=M4IV3bU+UsWg6oIS4hx+XZOzRJ0akEvkLQbJa7OVqESLUSfwwJlvB7rnHHvtOQUcm 1tFHgWqSqePJ4hn8ivFsgrNWrJwfCqwcJMu54Qay3jDAXzZJKANQZ7KR3iPx4of4yD F5phx9SEgbokk+UA8DXJnf7ItJlTzAjlHSBOCAaro4NrQirJJF61njKxInaUnPyO4G H8HAjE0rAWXqP3uPB9/+SVDLhaIqs+hfRRCET2yLJO7Iycj4Z/UYl0YOr6KeHXd6hZ bSrMHnIyHKuqe2dY9P5ma8bCxuTlvBr75WeBxG00VXRvCbXdm3bIshC+1bU1VQUyYQ qbjm3u2GguV3A== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id n7LCfvdq044344; Fri, 21 Aug 2009 14:41:57 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 21 Aug 2009 14:41:57 +0200 Message-ID: <20090821144157.645117jxvao9rmzk@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Fri, 21 Aug 2009 14:41:57 +0200 From: Alexander Leidinger To: "Daniel O'Connor" References: <200908192331.34507.doconnor@gsoft.com.au> <20090820081740.436656fu6d4fxoso@webmail.leidinger.net> <200908201713.08368.doconnor@gsoft.com.au> In-Reply-To: <200908201713.08368.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.3.3 / FreeBSD-8.0 X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 7AC438445A4.DC4AB X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.44, required 6, autolearn=disabled, ALL_TRUSTED -1.44, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1251463322.59472@Dfw4ddEFycCgVtoaZxG0Yw X-EBL-Spam-Status: No X-Mailman-Approved-At: Fri, 21 Aug 2009 13:43:31 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: DTrace probes & klds 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, 21 Aug 2009 12:42:09 -0000 Quoting Daniel O'Connor (from Thu, 20 Aug 2009 17:13:07 +0930): > On Thu, 20 Aug 2009, Alexander Leidinger wrote: >> Quoting Daniel O'Connor (from Wed, 19 Aug >> 2009 >> >> 23:31:33 +0930): >> > Content-Type: text/plain; >> > charset="utf-8" >> > Content-Transfer-Encoding: quoted-printable >> > Content-Disposition: inline >> > >> > Is it possible? the handbook implies not and I can't get it to >> > work, but i could be doing it wrong.. >> > >> > I get fbt traces listed for KLDs (I get new entries for each load >> > of the KLD which seems like a potential problem) but I can't >> > specify an SDT_PROBE and have it work. >> >> Can you show us some example code? > > /* Recycle fbt as SDT_PROVIDER_DEFINE is said not to work */ > SDT_PROBE_DEFINE(fbt, gsio, gsio_intr, test); > SDT_PROBE_ARGTYPE(fbt, gsio, gsio_intr, test, 0, "int"); > SDT_PROBE_ARGTYPE(fbt, gsio, gsio_intr, test, 1, "int"); I don't think you can define a fbt probe by hand. You can define a provider on your own via SDT_PROVIDER_DEFINE (in only one place/file), and then use this provider instead of fbt above. Let's assume you defined a gsio provider, then the SDT_PROBE_DEFINE could be SDT_PROBE_DEFINE(gsio, , gsio_intr, test); If there's only one file, it does not make much sense to add an unique part of the name of the file, but if you have multiple files it can be helpful. But this is just an example, for example in GEOM it would make sense to name the provider "geom", and instead of the file name use the module name, e.g. mirror, raid3, core/whatever, ... instead. Bye, Alexander. -- Fry: Where's Captain Bender? Off catastrophizing some other planet? http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 21 17:10:12 2009 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 6A2E4106568F for ; Fri, 21 Aug 2009 17:10:12 +0000 (UTC) (envelope-from brampton@gmail.com) Received: from mail-ew0-f209.google.com (mail-ew0-f209.google.com [209.85.219.209]) by mx1.freebsd.org (Postfix) with ESMTP id E15288FC13 for ; Fri, 21 Aug 2009 17:10:11 +0000 (UTC) Received: by ewy5 with SMTP id 5so1396044ewy.36 for ; Fri, 21 Aug 2009 10:10:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Pi2jGAmQaoO2vgPpRidBPt7EKM8k/7Qo8RsVyahOksg=; b=PbicYdsP+57JnBle7JN3CLfX1h9uAWF8UNaWX4wvm2InbrZHStinZnDw8xfq2X8ASu XFqmNL+hDN0ki5EGAuWnGSD48h+3aGNGRLQhAGxdkzFSeKSjBXaHBL++Rmd2a8LodEFG 5oJ1XK3XUUjgepUHBtEIp61BbErQ7CsVHkVy0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; b=d/S37BiAAMsx5H58KB+UK+j4RqhWB0rZXhCexnvTPlykwZZjDTcSwVJZOQCl+nGJRl Vw4zK+yOCTq0ENn9Rpj0u8tsgmahMn70b9BHA4YrHvxQgYS5Cpj+cn9Z0KdFWOMf/nRI UcRPsVGOFppDew8XypXAGz7qCDKRX6bhYsYrk= MIME-Version: 1.0 Sender: brampton@gmail.com Received: by 10.216.47.201 with SMTP id t51mr252433web.198.1250874610423; Fri, 21 Aug 2009 10:10:10 -0700 (PDT) Date: Fri, 21 Aug 2009 18:10:10 +0100 X-Google-Sender-Auth: 0c2b677ac477fa79 Message-ID: From: Andrew Brampton To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: DTrace lockup on a dual processor VMWare 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, 21 Aug 2009 17:10:12 -0000 Hi, I am running a amd64 FreeBSD 7.2 inside a VMWare, and DTrace has been working great. However, I have just changed my VMWare to use two processors instead of one, and things have started to break. I can load the dtraceall module but when I run hotkernel the machine hangs. I have DDB compiled into the kernel, but I was unable to break into it, instead I used a remote GDB (on the host machine) to give me the follow backtraces: CPU 0 #0 rdtsc (n=) at ./machine/cpufunc.h:379 #1 DELAY (n=) at /usr/7.2/sys/amd64/isa/clock.c:290 #2 0xffffffff80512d2a in _mtx_lock_spin (m=0xffffff00018b4128, tid=18446742974215591648, opts=, file=, line=) at /usr/7.2/sys/kern/kern_mutex.c:480 #3 0xffffffff80513304 in _mtx_lock_spin_flags (m=0xffffff00018b4128, opts=0, file=0xffffffff80f31600 "/usr/7.2/sys/modules/cyclic/../../cddl/dev/cyclic/cyclic.c", line=574) at /usr/7.2/sys/kern/kern_mutex.c:229 #4 0xffffffff80f30ca0 in cyclic_fire (frame=0xfffffffe89ce7ae0) at /usr/7.2/sys/modules/cyclic/../../cddl/dev/cyclic/cyclic.c:574 #5 cyclic_clock (frame=0xfffffffe89ce7ae0) at /usr/7.2/sys/modules/cyclic/../../cddl/dev/cyclic/amd64/cyclic_machdep.c:99 #6 0xffffffff807cf7bb in lapic_handle_timer (frame=0xfffffffe89ce7ae0) at /usr/7.2/sys/amd64/amd64/local_apic.c:695 #7 0xffffffff807c9db7 in Xtimerint () at /usr/7.2/sys/amd64/amd64/apic_vector.S:103 CPU 1 #0 smp_rendezvous_cpus (map=2, setup_func=0, action_func=0xffffffff80f301a0 , teardown_func=0xffffffff80558b00 , arg=0xfffffffe8a8e94e0) at /usr/7.2/sys/kern/subr_smp.c:388 #1 0xffffffff80f3055e in xcall (arg=, c=, func=0, param=0x46) at /usr/7.2/sys/modules/cyclic/../../cddl/dev/cyclic/amd64/cyclic_machdep.c:131 #2 0xffffffff80f301ed in cyclic_reprogram (cpu=, exp=) at /usr/7.2/sys/modules/cyclic/../../cddl/dev/cyclic/cyclic.c:540 #3 0xffffffff80f31194 in cyclic_add_here (cpu=0xffffff00018b4100, hdlr=0xfffffffe8a8e95a0, when=0xfffffffe8a8e9590, flags=0) at /usr/7.2/sys/modules/cyclic/../../cddl/dev/cyclic/cyclic.c:765 #4 0xffffffff80f314ea in cyclic_omni_start (omni=) at /usr/7.2/sys/modules/cyclic/../../cddl/dev/cyclic/cyclic.c:956 #5 cyclic_add_omni (omni=) at /usr/7.2/sys/modules/cyclic/../../cddl/dev/cyclic/cyclic.c:1226 #6 0xffffffff80f21665 in profile_enable (arg=, id=2149531648, parg=0x0) at /usr/7.2/sys/modules/dtrace/profile/../../../cddl/dev/profile/profile.c:450 #7 0xffffffff80f3c6cf in dtrace_ecb_enable (probe=0x1, arg=) at /usr/7.2/sys/modules/dtrace/dtrace/../../../cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c:9656 #8 dtrace_ecb_create_enable (probe=0x1, arg=) at /usr/7.2/sys/modules/dtrace/dtrace/../../../cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c:10471 #9 0xffffffff80f40142 in dtrace_match (pkp=0xfffffffe8a8e9800, priv=31, uid=27929688, zoneid=0, matched=0xffffffff80f3c130 , arg=0xffffff000db1f840) at /usr/7.2/sys/modules/dtrace/dtrace/../../../cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c:7212 #10 0xffffffff80f40346 in dtrace_probe_enable (desc=0xffffff0001a9d218, enab=0xffffff000db1f840) at /usr/7.2/sys/modules/dtrace/dtrace/../../../cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c:7992 #11 0xffffffff80f40434 in dtrace_enabling_match (enab=0xffffff000db1f840, nmatched=0xffffff000db83528) at /usr/7.2/sys/modules/dtrace/dtrace/../../../cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c:11366 #12 0xffffffff80f4c19a in dtrace_ioctl (dev=, cmd=, addr=0xffffff000db83520 "", flags=, td=0xffffff0001ab7370) at /usr/7.2/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/dtrace_ioctl.c:380 #13 0xffffffff804b14e6 in devfs_ioctl_f (fp=0xffffff00014db780, com=3222304774, data=0xffffff000db83520, cred=, td=0xffffff0001ab7370) at /usr/7.2/sys/fs/devfs/devfs_vnops.c:602 #14 0xffffffff80562063 in fo_ioctl (td=0xffffff0001ab7370, fd=7, com=3222304774, data=0xffffff000db83520 "") at /usr/7.2/sys/sys/file.h:269 #15 kern_ioctl (td=0xffffff0001ab7370, fd=7, com=3222304774, data=0xffffff000db83520 "") at /usr/7.2/sys/kern/sys_generic.c:627 #16 0xffffffff805622c9 in ioctl (td=0xffffff0001ab7370, uap=0xfffffffe8a8e9bf0) at /usr/7.2/sys/kern/sys_generic.c:571 #17 0xffffffff807e54fc in syscall (frame=0xfffffffe8a8e9c80) at /usr/7.2/sys/amd64/amd64/trap.c:900 #18 0xffffffff807c971b in Xfast_syscall () at /usr/7.2/sys/amd64/amd64/exception.S:330 It seems that CPU 0 is doing nothing, permanently stuck on line 379 of cpufunc.h, whereas CPU 1 is spinning inside the loop on line 388 of subr_smp.c. On thing I notice that when I run hotkernel on a single processor VMWare it prints out: > hotkernel Sampling... Hit Ctrl+C to end dtrace: buffer size lowered to 1m dtrace: aggregation size lowered to 1m When I run it on the dual-processor VMWare it only prints > hotkernel Sampling... Hit Ctrl+C to end So I suspect it is locking up before it gets to the code that prints "buffer size lowered". Additionally, I have built my own kernel, using all the standard options and sources, with just the following extra options: options KDTRACE_FRAME # Ensure frames are compiled in options KDTRACE_HOOKS # Kernel DTrace hooks options DDB_CTF options DEVICE_POLLING options KDB options KDB_UNATTENDED options DDB options GDB options BREAK_TO_DEBUGGER options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN options DEBUG_MEMGUARD options HWPMC_HOOKS device hwpmc Can anyone suggest anything to try and debug/fix this problem. I'm happy to hack the kernel sources if need be. thanks Andrew From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 22 00:11:44 2009 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 2760D1065692 for ; Sat, 22 Aug 2009 00:11:44 +0000 (UTC) (envelope-from prvs=1477fe8467=brian@FreeBSD.org) Received: from idcmail-mo1so.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id E550E8FC0A for ; Sat, 22 Aug 2009 00:11:43 +0000 (UTC) Received: from pd4ml1so-ssvc.prod.shaw.ca ([10.0.141.141]) by pd4mo1so-svcs.prod.shaw.ca with ESMTP; 21 Aug 2009 17:43:14 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=1 a=jXIcuBD92DkA:10 a=MJPcHhXccCG8eBs0us8XwA==:17 a=MMwg4So0AAAA:8 a=6I5d2MoRAAAA:8 a=5YGrx33GWETTkirStJ4A:9 a=g4j8IMfFdvu3XwZY5bcA:7 a=PyhIxysxrHXm1dhOcRgkKtL00x0A:4 a=WJ3hkfHDukgA:10 a=SV7veod9ZcQA:10 a=eD_158NIy2d-rMiV:21 a=T4PnxdgngV8PoDVD:21 Received: from unknown (HELO store.lan.Awfulhak.org) ([70.79.162.198]) by pd4ml1so-dmz.prod.shaw.ca with ESMTP; 21 Aug 2009 17:43:14 -0600 Received: from store.lan.Awfulhak.org (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 8BBEEC433AA_A8F310EB for ; Fri, 21 Aug 2009 23:43:10 +0000 (GMT) Received: from gw.Awfulhak.org (gw.lan.Awfulhak.org [172.16.0.1]) by store.lan.Awfulhak.org (Sophos Email Appliance) with ESMTP id 54CBDC460F3_A8F310EF for ; Fri, 21 Aug 2009 23:43:10 +0000 (GMT) Received: from dev.lan.Awfulhak.org (brian@dev.lan.Awfulhak.org [172.16.0.5]) by gw.Awfulhak.org (8.14.3/8.14.3) with ESMTP id n7LNhDeB078138; Fri, 21 Aug 2009 16:43:13 -0700 (PDT) (envelope-from brian@FreeBSD.org) Date: Fri, 21 Aug 2009 16:43:12 -0700 From: Brian Somers To: freebsd-hackers@FreeBSD.org Message-ID: <20090821164312.641fe2bd@dev.lan.Awfulhak.org> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.5; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: kernel panics in in_lltable_lookup (with INVARIANTS) 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, 22 Aug 2009 00:11:44 -0000 Hi, I've been working on a fix to address an issue that came up with our update of openssh-5. The issue is that openssh-5 now uses pipe() to create stdin/stdout channels between sshd and the server side program where it used to use socketpair(). Because it uses pipe(), stdin is no longer bi-directional and cannot be used for both input and output by a child process. This breaks the use of ssh as a tunnel with ppp on either end (set device "!ssh -e none host ppp -direct label") I talked with des@ for a while and then with the openssh folks and have not been able to resolve the issues in openssh that made them choose to enforce the use of pipe() over socketpair(). I now have a patch to ppp that makes ppp detect that it's connected via pipe() and causes it to use stdin for input and stdout for output (usually it expects just one descriptor). Although I'm happy with the patch and planned on requesting permission to commit, I've bumped into a show-stopper that seems unrelated, so I thought I'd ask here if anyone has seen this or has any suggestions as to what the problem might be. The issue.... I'm seeing a panic when I send traffic through a ppp link: panic string is: sin_family 18 Stack trace starts: in_lltable_lookup() llentry_update() flowtable_lookup() ip_output() .... The panic is due to a KASSERT in in_lltable_lookup() that expects the sockaddr to be AF_INET. Number 18 is AF_LINK. AFAICT this is happening while setting up a temporary route for the first outbound packet. I haven't been able to do much investigation yet due to other patches in my tree that seem to have broken all my kernel symbols, but once I get a clean rebuild I should be back in business. If anyone has any suggestions, I'm all ears! Cheers. -- Brian Somers Don't _EVER_ lose your sense of humour ! From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 22 00:44:39 2009 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 80BE1106568B; Sat, 22 Aug 2009 00:44:39 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by mx1.freebsd.org (Postfix) with ESMTP id 27D158FC17; Sat, 22 Aug 2009 00:44:38 +0000 (UTC) Received: by an-out-0708.google.com with SMTP id d14so372868and.13 for ; Fri, 21 Aug 2009 17:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=sg6Lm1cqfh3BxtbFqTmq4StabKTYzKO7wAGdWIzqkKY=; b=IzzsxeISv0gPEEqxAWyZFW1aTVnq0mp9vKa+zJuGRY+Omq48h8JeInVXCLymPCUHng am6cc68msGU6MTGOPXykGbEd+geKFiOyUuh2tUUne5AWJuHRGofW6ZZkvWZtaG9rjMHb KPHPJMNS07zuM1IoYjBKoOKUaqQhTCnjss+W8= 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=HTlEnbjZoTZv2KwIzaxcqM+cWPXD5f6Xrap635EjeKjy+AVLYDCvmiKmBBlMLBgdB9 Z19Vev1ORFld8UojIWzUKSjfit/uo4PPlnOk1O0f+dFuimNA/GWlTRQJULW7tPCs6ao3 LIHntE/sq6lxt0X3r/foMKWbG5NdqEb9+cEUc= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.55.18 with SMTP id d18mr1899444ana.80.1250900025724; Fri, 21 Aug 2009 17:13:45 -0700 (PDT) In-Reply-To: <20090821164312.641fe2bd@dev.lan.Awfulhak.org> References: <20090821164312.641fe2bd@dev.lan.Awfulhak.org> Date: Fri, 21 Aug 2009 17:13:45 -0700 X-Google-Sender-Auth: 0378d475c0acc9ae Message-ID: <3c1674c90908211713j36415b96q58b0ed66cc82713f@mail.gmail.com> From: Kip Macy To: Brian Somers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: kernel panics in in_lltable_lookup (with INVARIANTS) 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, 22 Aug 2009 00:44:39 -0000 Try this: Index: sys/net/flowtable.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/net/flowtable.c (revision 196382) +++ sys/net/flowtable.c (working copy) @@ -688,6 +688,12 @@ struct rtentry *rt =3D ro->ro_rt; struct ifnet *ifp =3D rt->rt_ifp; + if (ifp->if_flags & IFF_POINTOPOINT) { + RTFREE(rt); + ro->ro_rt =3D NULL; + return (ENOENT); + } + if (rt->rt_flags & RTF_GATEWAY) l3addr =3D rt->rt_gateway; else You'll need to apply this by hand as gmail munges the formatting. -Kip On Fri, Aug 21, 2009 at 16:43, Brian Somers wrote: > Hi, > > I've been working on a fix to address an issue that came up with > our update of openssh-5. =A0The issue is that openssh-5 now uses > pipe() to create stdin/stdout channels between sshd and the server > side program where it used to use socketpair(). =A0Because it uses > pipe(), stdin is no longer bi-directional and cannot be used for both > input and output by a child process. =A0This breaks the use of ssh > as a tunnel with ppp on either end (set device "!ssh -e none host > ppp -direct label") > > I talked with des@ for a while and then with the openssh folks and > have not been able to resolve the issues in openssh that made them > choose to enforce the use of pipe() over socketpair(). =A0I now have a > patch to ppp that makes ppp detect that it's connected via pipe() and > causes it to use stdin for input and stdout for output (usually it expect= s > just one descriptor). =A0Although I'm happy with the patch and planned on > requesting permission to commit, I've bumped into a show-stopper > that seems unrelated, so I thought I'd ask here if anyone has seen > this or has any suggestions as to what the problem might be. > > The issue.... > > I'm seeing a panic when I send traffic through a ppp link: > > panic string is: sin_family 18 > Stack trace starts: > =A0 =A0in_lltable_lookup() > =A0 =A0llentry_update() > =A0 =A0flowtable_lookup() > =A0 =A0ip_output() > =A0 =A0.... > > The panic is due to a KASSERT in in_lltable_lookup() that expects the > sockaddr to be AF_INET. =A0Number 18 is AF_LINK. > > AFAICT this is happening while setting up a temporary route for the > first outbound packet. =A0I haven't been able to do much investigation > yet due to other patches in my tree that seem to have broken all my > kernel symbols, but once I get a clean rebuild I should be back in > business. > > If anyone has any suggestions, I'm all ears! > > Cheers. > > -- > Brian Somers =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 > Don't _EVER_ lose your sense of humour ! =A0 =A0 =A0 =A0 =A0 =A0 =A0 > _______________________________________________ > 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= " > --=20 When harsh accusations depart too far from the truth, they leave bitter consequences. --Tacitus From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 22 01:36:59 2009 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 88993106568C for ; Sat, 22 Aug 2009 01:36:59 +0000 (UTC) (envelope-from kindman@amc-os.com) Received: from smtpfb2-g21.free.fr (smtpfb2-g21.free.fr [212.27.42.10]) by mx1.freebsd.org (Postfix) with ESMTP id 247BA8FC0C for ; Sat, 22 Aug 2009 01:36:56 +0000 (UTC) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by smtpfb2-g21.free.fr (Postfix) with ESMTP id 4A6EED19E99 for ; Sat, 22 Aug 2009 03:20:08 +0200 (CEST) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id B10CD4C8089 for ; Sat, 22 Aug 2009 03:20:02 +0200 (CEST) Received: from kmlaptop (blackforest.amc-os.net [88.174.102.207]) by smtp4-g21.free.fr (Postfix) with SMTP id 9A7764C8081 for ; Sat, 22 Aug 2009 03:19:59 +0200 (CEST) Message-ID: From: "Aurlien Mr" To: Date: Sat, 22 Aug 2009 03:19:52 +0200 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18005 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 X-RFC2646: Format=Flowed; Original Subject: Common interface for sensors/health monitoring 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, 22 Aug 2009 01:36:59 -0000 Hi, I've been using FreeBSD for years in all my servers, but I'm facing a big problem today. All servers are under monitoring using a couple of applications and scripts. Monitored items for each server especially are CPU/mobo/UPS/HDD temperatures, CPU load, memory use, fans speed, PSU/UPS voltages, HDD/RAID status&usage, network connectivity, UPS load, battery status & runtime, ... My concern today, excepted that there is no way to gather all the data through a unique interface and that consequently we have to change the scripts depending on hardware, is that some information are no longer available at all, especially concerning the MB IC, ie. temperatures, voltages & fan speed. Actually, some SMBus controllers (like from 2006 or so) are not supported by any driver and I didn't find any port updated to access the IC directly (if even possible). Currently, I sometimes have to use mbmon with direct I/O, sometimes mbmon with SMBus, sometimes healthd and sometimes nothing works (PR 137668 or 136762 as examples in my case). Besides that, I was quite surprised that these information are available in OpenBSD through a very simple and unique sysctl interface, with up-to-date drivers, working on all my servers with a generic install. I know that below this presentation layer, this may be much less perfect, and by digging in, I found that a 2007 GSoC project for porting the OpenBSD sensor framework was realised and planned to be put in HEAD. I also read hundreds of mails concerning this project, and why finally it was not commited. As developer, I fully understand some of the concerns in these threads and that there are probably lots of things to change and work on, integrate it in a cleaner repository like snmp or whatever; and I'd be glad to help in any possible way to improve this. But in the meantime, as netadmin, this kind of information can be very important to prevent or diagnose major problems; so I'd like to know what is being planned/done on this subject, as I didn't find any more information related to this than a discussion during bsdcan 2008. Thanks for your help and time, Aurlien From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 22 02:17:32 2009 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 1086D106568C for ; Sat, 22 Aug 2009 02:17:32 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 94E688FC21 for ; Sat, 22 Aug 2009 02:17:31 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id l26so274160fgb.12 for ; Fri, 21 Aug 2009 19:17:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=q6zZtHN49s3wb4LHzR9X56LGyEIk9DTQAM6uKOtov5U=; b=PtooL+g3M0S8KHYcMF2MQKBLdiOM4QEAtxwOLeZw3eRAAtv4f1+KPMgZdkBbUsBZhT gYOBIUwyIYaitXzYCI6xIZOtg4L3Vm81HBEv+c9WUxrEmURC7xaRtLn9AIcUywe87YiM JGR++ySIj9fC9CqL/WiWO7g74pD4C8d/JP1Uo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qDVZEwfvkLpkUeJQgQa93Yf0chZlppth5xWcFxrxheB3XxjcDOXCzPvs+Hvh1Y6ikF hF5h1Dc6ix42GSl1O3oFzKXJb7Z9U8Kgf/Bv1Fze+uGJ6xYCugyzG0FM1QZQtXOp8yFb UtNtwOyY5tddJwYr5jNQbMzld3Dk6axbLybhc= MIME-Version: 1.0 Received: by 10.86.170.4 with SMTP id s4mr1388390fge.9.1250907450561; Fri, 21 Aug 2009 19:17:30 -0700 (PDT) In-Reply-To: References: Date: Sat, 22 Aug 2009 04:17:30 +0200 Message-ID: <6101e8c40908211917k69c82491w3cff00a527d14873@mail.gmail.com> From: Oliver Pinter To: =?ISO-8859-1?Q?Aur=E9lien_M=E9r=E9?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Common interface for sensors/health monitoring 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, 22 Aug 2009 02:17:32 -0000 Hello! When I good know, no common interface exisit in current freebsd kernel, but some other sysctl interfece exisit: coretemp, aiboost ... ~> sysctl dev.coretemp dev.coretemp.0.%desc: CPU On-Die Thermal Sensors dev.coretemp.0.%driver: coretemp dev.coretemp.0.%parent: cpu0 dev.coretemp.1.%desc: CPU On-Die Thermal Sensors dev.coretemp.1.%driver: coretemp dev.coretemp.1.%parent: cpu1 dev.coretemp.2.%desc: CPU On-Die Thermal Sensors dev.coretemp.2.%driver: coretemp dev.coretemp.2.%parent: cpu2 dev.coretemp.3.%desc: CPU On-Die Thermal Sensors dev.coretemp.3.%driver: coretemp dev.coretemp.3.%parent: cpu3 ~> sysctl dev.acpi_aiboost dev.acpi_aiboost.0.%desc: ASUStek AIBOOSTER dev.acpi_aiboost.0.%driver: acpi_aiboost dev.acpi_aiboost.0.%location: handle=3D\_SB_.PCI0.SBRG.ASOC dev.acpi_aiboost.0.%pnpinfo: _HID=3DATK0110 _UID=3D16843024 dev.acpi_aiboost.0.%parent: acpi0 dev.acpi_aiboost.0.temp0: 190 dev.acpi_aiboost.0.temp1: 300 dev.acpi_aiboost.0.volt0: 1144 dev.acpi_aiboost.0.volt1: 3328 dev.acpi_aiboost.0.volt2: 5064 dev.acpi_aiboost.0.volt3: 12096 dev.acpi_aiboost.0.fan0: 1962 dev.acpi_aiboost.0.fan1: 1180 dev.acpi_aiboost.0.fan2: 1278 dev.acpi_aiboost.0.fan3: 0 dev.acpi_aiboost.0.fan4: 0 but no common if.. On 8/22/09, Aur=E9lien M=E9r=E9 wrote: > Hi, > > I've been using FreeBSD for years in all my servers, but I'm facing a big > problem today. All servers are under monitoring using a couple of > applications and scripts. Monitored items for each server especially are > CPU/mobo/UPS/HDD temperatures, CPU load, memory use, fans speed, PSU/UPS > voltages, HDD/RAID status&usage, network connectivity, UPS load, battery > status & runtime, ... > > My concern today, excepted that there is no way to gather all the data > through a unique interface and that consequently we have to change the > scripts depending on hardware, is that some information are no longer > available at all, especially concerning the MB IC, ie. temperatures, > voltages & fan speed. Actually, some SMBus controllers (like from 2006 or > so) are not supported by any driver and I didn't find any port updated to > access the IC directly (if even possible). Currently, I sometimes have to > use mbmon with direct I/O, sometimes mbmon with SMBus, sometimes healthd = and > sometimes nothing works (PR 137668 or 136762 as examples in my case). > > Besides that, I was quite surprised that these information are available = in > OpenBSD through a very simple and unique sysctl interface, with up-to-dat= e > drivers, working on all my servers with a generic install. I know that be= low > this presentation layer, this may be much less perfect, and by digging in= , I > found that a 2007 GSoC project for porting the OpenBSD sensor framework w= as > realised and planned to be put in HEAD. I also read hundreds of mails > concerning this project, and why finally it was not commited. > > As developer, I fully understand some of the concerns in these threads an= d > that there are probably lots of things to change and work on, integrate i= t > in a cleaner repository like snmp or whatever; and I'd be glad to help in > any > possible way to improve this. But in the meantime, as netadmin, this kind= of > information can be very important to prevent or diagnose major problems; = so > I'd like to know what is being planned/done on this subject, as I didn't > find any > more information related to this than a discussion during bsdcan 2008. > > Thanks for your help and time, > Aur=E9lien > > > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 22 05:23:07 2009 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 0EA16106568B; Sat, 22 Aug 2009 05:23:07 +0000 (UTC) (envelope-from prvs=147868619d=brian@FreeBSD.org) Received: from idcmail-mo2no.shaw.ca (idcmail-mo2no.shaw.ca [64.59.134.9]) by mx1.freebsd.org (Postfix) with ESMTP id B73338FC08; Sat, 22 Aug 2009 05:23:06 +0000 (UTC) Received: from pd7ml2no-ssvc.prod.shaw.ca ([10.0.153.162]) by pd7mo1no-svcs.prod.shaw.ca with ESMTP; 21 Aug 2009 22:55:07 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=1 a=BN5Fd0iOSU8A:10 a=MJPcHhXccCG8eBs0us8XwA==:17 a=6I5d2MoRAAAA:8 a=MMwg4So0AAAA:8 a=IdckobKmQywhugN5PFQA:9 a=H-E4T0RX_QdEYwG9dNAA:7 a=OZVq9tP-p7W9Ef3SHkVHqKDqpjkA:4 a=SV7veod9ZcQA:10 a=WJ3hkfHDukgA:10 a=yMt3MqSJ3BES6okv:21 a=47XE9mHQPc2XRumx:21 Received: from unknown (HELO store.lan.Awfulhak.org) ([70.79.162.198]) by pd7ml2no-dmz.prod.shaw.ca with ESMTP; 21 Aug 2009 22:55:07 -0600 Received: from store.lan.Awfulhak.org (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id AF5DAC433AA_A8F7A27B; Sat, 22 Aug 2009 04:55:03 +0000 (GMT) Received: from gw.Awfulhak.org (gw.lan.Awfulhak.org [172.16.0.1]) by store.lan.Awfulhak.org (Sophos Email Appliance) with ESMTP id CFCCFC460F8_A8F7A24F; Sat, 22 Aug 2009 04:55:00 +0000 (GMT) Received: from dev.lan.Awfulhak.org (brian@dev.lan.Awfulhak.org [172.16.0.5]) by gw.Awfulhak.org (8.14.3/8.14.3) with ESMTP id n7M4t38I090440; Fri, 21 Aug 2009 21:55:03 -0700 (PDT) (envelope-from brian@FreeBSD.org) Date: Fri, 21 Aug 2009 21:55:03 -0700 From: Brian Somers To: Kip Macy Message-ID: <20090821215503.3eec9a15@dev.lan.Awfulhak.org> In-Reply-To: <3c1674c90908211713j36415b96q58b0ed66cc82713f@mail.gmail.com> References: <20090821164312.641fe2bd@dev.lan.Awfulhak.org> <3c1674c90908211713j36415b96q58b0ed66cc82713f@mail.gmail.com> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.5; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@FreeBSD.org Subject: Re: kernel panics in in_lltable_lookup (with INVARIANTS) 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, 22 Aug 2009 05:23:07 -0000 On Fri, 21 Aug 2009 17:13:45 -0700 Kip Macy wrote: > Try this: >=20 > Index: sys/net/flowtable.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/net/flowtable.c (revision 196382) > +++ sys/net/flowtable.c (working copy) > @@ -688,6 +688,12 @@ > struct rtentry *rt =3D ro->ro_rt; > struct ifnet *ifp =3D rt->rt_ifp; >=20 > + if (ifp->if_flags & IFF_POINTOPOINT) { > + RTFREE(rt); > + ro->ro_rt =3D NULL; > + return (ENOENT); > + } > + > if (rt->rt_flags & RTF_GATEWAY) > l3addr =3D rt->rt_gateway; > else >=20 > You'll need to apply this by hand as gmail munges the formatting. >=20 > -Kip Hi, That certainly stops the panic, however data routed to the tun interface doesn't come out the back end and data written to the back end doesn't come out the tun interface. After connecting a 7-stable and a -current box, I get this sending a ping packet from the stable box: -stable: TCP/IP: OUT ICMP: 172.16.1.22:8 ---> 172.16.1.20 (36/84) Physical: write Physical: 7e 3d c0 1c fd 00 12 02 1b 3a c1 1c 64 e8 04 75 ~=3D.......:..d= ..u Physical: 84 a1 93 62 d5 e2 c1 86 1e 63 60 9a f4 82 54 43 ...b.....c`...TC Physical: 01 00 70 7c 7e ..p|~ meaning that ppp sees the ICMP when it reads the back of the tun interface, and writes the encapsulated data to its physical link (the "other end"). -current: Physical: read Physical: 7e 3d c0 1c fd 00 12 02 1b 3a c1 1c 64 e8 04 75 ~=3D.......:..d= ..u Physical: 84 a1 93 62 d5 e2 c1 86 1e 63 60 9a f4 82 54 43 ...b.....c`...TC Physical: 01 00 70 7c 7e ..p|~ TCP/IP: IN ICMP: 172.16.1.22:8 ---> 172.16.1.20 (36/84) meaning that ppp reads data from the physical link, decapsulates it and writes an ICMP to the back of the tun interface. Then nothing (no ICMP reply). Sending an icmp from the -current box doesn't wake ppp at all. On the -stable box: brian@gw ~ $ ifconfig tun0 tun0: flags=3D8051 metric 0 mtu 1540 inet6 fe80::240:f4ff:feb1:1c85%tun0 prefixlen 64 scopeid 0x6=20 inet 172.16.1.22 --> 172.16.1.20 netmask 0xffffffff=20 Opened by PID 89468 brian@gw ~ $ route get 172.16.1.20 route to: 172.16.1.20 destination: 172.16.1.20 gateway: 172.16.1.22 interface: tun0 flags: recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu ex= pire 0 0 0 0 0 0 1540 = 0=20 and on the -current box: brian@dev ~ $ ifconfig tun0 tun0: flags=3D8051 metric 0 mtu 1540 inet 172.16.1.20 --> 172.16.1.22 netmask 0xffffffff=20 inet6 fe80::240:f4ff:feb1:10da%tun0 prefixlen 64 scopeid 0x7=20 Opened by PID 1647 brian@dev ~ $ route get 172.16.1.22 route to: 172.16.1.22 destination: 172.16.1.22 gateway:=20 interface: tun0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1540 1 0=20 According to ``netstat -I tun0'', Opkts is increasing when I send from the -current box, although netstat -s doesn't seem to see any more icmps. Maybe this problem isn't a routing problem. I'll look into it further and figure out if the packet is getting to the tun driver and if so, what it thinks it's doing with it. Thanks. > On Fri, Aug 21, 2009 at 16:43, Brian Somers wrote: > > Hi, > > > > I've been working on a fix to address an issue that came up with > > our update of openssh-5. =C2=A0The issue is that openssh-5 now uses > > pipe() to create stdin/stdout channels between sshd and the server > > side program where it used to use socketpair(). =C2=A0Because it uses > > pipe(), stdin is no longer bi-directional and cannot be used for both > > input and output by a child process. =C2=A0This breaks the use of ssh > > as a tunnel with ppp on either end (set device "!ssh -e none host > > ppp -direct label") > > > > I talked with des@ for a while and then with the openssh folks and > > have not been able to resolve the issues in openssh that made them > > choose to enforce the use of pipe() over socketpair(). =C2=A0I now have= a > > patch to ppp that makes ppp detect that it's connected via pipe() and > > causes it to use stdin for input and stdout for output (usually it expe= cts > > just one descriptor). =C2=A0Although I'm happy with the patch and plann= ed on > > requesting permission to commit, I've bumped into a show-stopper > > that seems unrelated, so I thought I'd ask here if anyone has seen > > this or has any suggestions as to what the problem might be. > > > > The issue.... > > > > I'm seeing a panic when I send traffic through a ppp link: > > > > panic string is: sin_family 18 > > Stack trace starts: > > =C2=A0 =C2=A0in_lltable_lookup() > > =C2=A0 =C2=A0llentry_update() > > =C2=A0 =C2=A0flowtable_lookup() > > =C2=A0 =C2=A0ip_output() > > =C2=A0 =C2=A0.... > > > > The panic is due to a KASSERT in in_lltable_lookup() that expects the > > sockaddr to be AF_INET. =C2=A0Number 18 is AF_LINK. > > > > AFAICT this is happening while setting up a temporary route for the > > first outbound packet. =C2=A0I haven't been able to do much investigati= on > > yet due to other patches in my tree that seem to have broken all my > > kernel symbols, but once I get a clean rebuild I should be back in > > business. > > > > If anyone has any suggestions, I'm all ears! > > > > Cheers. --=20 Brian Somers Don't _EVER_ lose your sense of humour ! From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 22 06:23:24 2009 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 8A99B106564A; Sat, 22 Aug 2009 06:23:24 +0000 (UTC) (envelope-from prvs=147868619d=brian@FreeBSD.org) Received: from idcmail-mo2no.shaw.ca (idcmail-mo2no.shaw.ca [64.59.134.9]) by mx1.freebsd.org (Postfix) with ESMTP id 4656F8FC08; Sat, 22 Aug 2009 06:23:24 +0000 (UTC) Received: from pd5ml1no-ssvc.prod.shaw.ca ([10.0.153.166]) by pd5mo1no-svcs.prod.shaw.ca with ESMTP; 22 Aug 2009 00:23:23 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=1 a=BN5Fd0iOSU8A:10 a=MJPcHhXccCG8eBs0us8XwA==:17 a=MMwg4So0AAAA:8 a=6I5d2MoRAAAA:8 a=WjMnBSSxO-EoTGR0udEA:9 a=kpSaYsJ00ac9p5FhZI0A:7 a=0lk8cbqpZ2AkvQ2dHkYWBBAbHKgA:4 a=WJ3hkfHDukgA:10 a=SV7veod9ZcQA:10 a=oT_qS19YcmfGFLjL:21 a=muCfklCqJyDb6q-C:21 a=rThCOlcHAwnlt5MDfQAA:9 a=N4gblhJppo-Cwfda_TnVvv8n3pAA:4 Received: from unknown (HELO store.lan.Awfulhak.org) ([70.79.162.198]) by pd5ml1no-dmz.prod.shaw.ca with ESMTP; 22 Aug 2009 00:23:23 -0600 Received: from store.lan.Awfulhak.org (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id B82A0C433AA_A8F8ED7B; Sat, 22 Aug 2009 06:23:19 +0000 (GMT) Received: from gw.Awfulhak.org (gw.lan.Awfulhak.org [172.16.0.1]) by store.lan.Awfulhak.org (Sophos Email Appliance) with ESMTP id D43D7C460F8_A8F8ED4F; Sat, 22 Aug 2009 06:23:16 +0000 (GMT) Received: from dev.lan.Awfulhak.org (brian@dev.lan.Awfulhak.org [172.16.0.5]) by gw.Awfulhak.org (8.14.3/8.14.3) with ESMTP id n7M6NJ5f093931; Fri, 21 Aug 2009 23:23:19 -0700 (PDT) (envelope-from brian@FreeBSD.org) Date: Fri, 21 Aug 2009 23:23:13 -0700 From: Brian Somers To: Brian Somers Message-ID: <20090821232313.21a9a7f9@dev.lan.Awfulhak.org> In-Reply-To: <20090821224134.11d9a2a1@dev.lan.Awfulhak.org> References: <20090821164312.641fe2bd@dev.lan.Awfulhak.org> <3c1674c90908211713j36415b96q58b0ed66cc82713f@mail.gmail.com> <20090821215503.3eec9a15@dev.lan.Awfulhak.org> <20090821224134.11d9a2a1@dev.lan.Awfulhak.org> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.5; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/fwEDmRUiczzg7LzfVY6+Xz1"; protocol="application/pgp-signature" Cc: freebsd-hackers@FreeBSD.org, Kip Macy Subject: Re: kernel panics in in_lltable_lookup (with INVARIANTS) 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, 22 Aug 2009 06:23:24 -0000 --Sig_/fwEDmRUiczzg7LzfVY6+Xz1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, 21 Aug 2009 22:41:34 -0700 Brian Somers wrote: > On Fri, 21 Aug 2009 21:55:03 -0700 Brian Somers wrote: > > On Fri, 21 Aug 2009 17:13:45 -0700 Kip Macy wrote: > > > Try this: > > >=20 > > > Index: sys/net/flowtable.c > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > --- sys/net/flowtable.c (revision 196382) > > > +++ sys/net/flowtable.c (working copy) > > > @@ -688,6 +688,12 @@ > > > struct rtentry *rt =3D ro->ro_rt; > > > struct ifnet *ifp =3D rt->rt_ifp; > > >=20 > > > + if (ifp->if_flags & IFF_POINTOPOINT) { > > > + RTFREE(rt); > > > + ro->ro_rt =3D NULL; > > > + return (ENOENT); > > > + } > > > + > > > if (rt->rt_flags & RTF_GATEWAY) > > > l3addr =3D rt->rt_gateway; > > > else > > >=20 > > > You'll need to apply this by hand as gmail munges the formatting. > > >=20 > > > -Kip > >=20 > > Hi, > >=20 > > That certainly stops the panic, however data routed to the tun > > interface doesn't come out the back end and data written > > to the back end doesn't come out the tun interface. > [.....] > > Maybe this problem isn't a routing problem. I'll > > look into it further and figure out if the packet is getting to the tun > > driver and if so, what it thinks it's doing with it. >=20 > I wasn't correct - the data *IS* being read out of the back of > the tunnel device. When I send the ICMP, it goes into the tun > device and comes out the back end as an AF_LINK packet. ppp > silently discards this (ironically I have a comment noting > that I should really track unidentified packet counts). >=20 > I'll try to figure out what in if_tun.c is corrupting the family next... if_tun.c is fine. The data passed from if_output() has family AF_LINK - hence the original panic from flowtable_lookup(). So the question is "why is ip_output() sending AF_LINK traffic instead of AF_INET traffic?". Still looking.... > > > On Fri, Aug 21, 2009 at 16:43, Brian Somers wrote: > > > > Hi, > > > > > > > > I've been working on a fix to address an issue that came up with > > > > our update of openssh-5. =C2=A0The issue is that openssh-5 now uses > > > > pipe() to create stdin/stdout channels between sshd and the server > > > > side program where it used to use socketpair(). =C2=A0Because it us= es > > > > pipe(), stdin is no longer bi-directional and cannot be used for bo= th > > > > input and output by a child process. =C2=A0This breaks the use of s= sh > > > > as a tunnel with ppp on either end (set device "!ssh -e none host > > > > ppp -direct label") > > > > > > > > I talked with des@ for a while and then with the openssh folks and > > > > have not been able to resolve the issues in openssh that made them > > > > choose to enforce the use of pipe() over socketpair(). =C2=A0I now = have a > > > > patch to ppp that makes ppp detect that it's connected via pipe() a= nd > > > > causes it to use stdin for input and stdout for output (usually it = expects > > > > just one descriptor). =C2=A0Although I'm happy with the patch and p= lanned on > > > > requesting permission to commit, I've bumped into a show-stopper > > > > that seems unrelated, so I thought I'd ask here if anyone has seen > > > > this or has any suggestions as to what the problem might be. > > > > > > > > The issue.... > > > > > > > > I'm seeing a panic when I send traffic through a ppp link: > > > > > > > > panic string is: sin_family 18 > > > > Stack trace starts: > > > > =C2=A0 =C2=A0in_lltable_lookup() > > > > =C2=A0 =C2=A0llentry_update() > > > > =C2=A0 =C2=A0flowtable_lookup() > > > > =C2=A0 =C2=A0ip_output() > > > > =C2=A0 =C2=A0.... > > > > > > > > The panic is due to a KASSERT in in_lltable_lookup() that expects t= he > > > > sockaddr to be AF_INET. =C2=A0Number 18 is AF_LINK. > > > > > > > > AFAICT this is happening while setting up a temporary route for the > > > > first outbound packet. =C2=A0I haven't been able to do much investi= gation > > > > yet due to other patches in my tree that seem to have broken all my > > > > kernel symbols, but once I get a clean rebuild I should be back in > > > > business. > > > > > > > > If anyone has any suggestions, I'm all ears! > > > > > > > > Cheers. --=20 Brian Somers Don't _EVER_ lose your sense of humour ! --Sig_/fwEDmRUiczzg7LzfVY6+Xz1 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iQCVAwUBSo+O1w7tvOdmanQhAQIAnwP/Se8AMCkjKf2kSgsAzezESaNxHganOqbx FcRx2W1541yJBpTNJqtu4GMlQdQSRmhooIt6k3To8XXSac13d9pBCB8Z8vCmeqs+ ALwgQnUBK+i5hXTuAdFlFMdEKqPyj9vRz8gPOiIznxhVMGXzq/Qe3n1ypfRdxF6Z 2o5B8qm7/UU= =iQ+U -----END PGP SIGNATURE----- --Sig_/fwEDmRUiczzg7LzfVY6+Xz1-- From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 22 06:35:44 2009 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 A0A87106568D for ; Sat, 22 Aug 2009 06:35:44 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id 4FBE28FC13 for ; Sat, 22 Aug 2009 06:35:44 +0000 (UTC) Received: by yxe11 with SMTP id 11so708205yxe.3 for ; Fri, 21 Aug 2009 23:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=2RYSxzi9KXcK1lj+utqc76z1PpEnhrCGGxaYJwbkYt4=; b=nhV0DnfOB3XgrPwpCVn9xpbBOeF0Cpq7fIi5GDoBLK6voQ/wicg4ifZxzDjzPbvDGe e3YnvRx0gQp9acPNpXWRO+1XkRn9L6ntW3um01ppmB4wPRUwcd5f4KXVYGWZAOkTpuRf 857fNMDYTqcZERhGvwQ01pmVZkRj3fPpRP3R8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ts7JuEnDeZxzETrR31RwmOYWWPjoKt7XhAQ8nODWzq+HeMedKEV8sZ4qfpmJM7hX62 es6gUYto6E7f3WU4SK84XaHkBdCzyuRlLbZRXbrqoIaX3mP1Xc1uuLEQCHnB9I85nvQV F5fPtABpt0cHUr5WN7Gn9uLnGXxs5UObigU5g= MIME-Version: 1.0 Received: by 10.91.192.14 with SMTP id u14mr1668706agp.2.1250921026695; Fri, 21 Aug 2009 23:03:46 -0700 (PDT) In-Reply-To: <6101e8c40908211917k69c82491w3cff00a527d14873@mail.gmail.com> References: <6101e8c40908211917k69c82491w3cff00a527d14873@mail.gmail.com> Date: Sat, 22 Aug 2009 03:03:46 -0300 Message-ID: <19e9a5dc0908212303j28a6913er604bfd06e7df81ec@mail.gmail.com> From: Gonzalo Nemmi To: Oliver Pinter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: =?ISO-8859-1?Q?Aur=E9lien_M=E9r=E9?= , freebsd-hackers@freebsd.org Subject: Re: Common interface for sensors/health monitoring 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, 22 Aug 2009 06:35:44 -0000 On Fri, Aug 21, 2009 at 11:17 PM, Oliver Pinter wrot= e: > Hello! > > When I good know, no common interface exisit in current freebsd > kernel, but some other sysctl interfece exisit: coretemp, aiboost ... > > ~> sysctl dev.coretemp > dev.coretemp.0.%desc: CPU On-Die Thermal Sensors > dev.coretemp.0.%driver: coretemp > dev.coretemp.0.%parent: cpu0 > dev.coretemp.1.%desc: CPU On-Die Thermal Sensors > dev.coretemp.1.%driver: coretemp > dev.coretemp.1.%parent: cpu1 > dev.coretemp.2.%desc: CPU On-Die Thermal Sensors > dev.coretemp.2.%driver: coretemp > dev.coretemp.2.%parent: cpu2 > dev.coretemp.3.%desc: CPU On-Die Thermal Sensors > dev.coretemp.3.%driver: coretemp > dev.coretemp.3.%parent: cpu3 > > ~> sysctl dev.acpi_aiboost > dev.acpi_aiboost.0.%desc: ASUStek AIBOOSTER > dev.acpi_aiboost.0.%driver: acpi_aiboost > dev.acpi_aiboost.0.%location: handle=3D\_SB_.PCI0.SBRG.ASOC > dev.acpi_aiboost.0.%pnpinfo: _HID=3DATK0110 _UID=3D16843024 > dev.acpi_aiboost.0.%parent: acpi0 > dev.acpi_aiboost.0.temp0: 190 > dev.acpi_aiboost.0.temp1: 300 > dev.acpi_aiboost.0.volt0: 1144 > dev.acpi_aiboost.0.volt1: 3328 > dev.acpi_aiboost.0.volt2: 5064 > dev.acpi_aiboost.0.volt3: 12096 > dev.acpi_aiboost.0.fan0: 1962 > dev.acpi_aiboost.0.fan1: 1180 > dev.acpi_aiboost.0.fan2: 1278 > dev.acpi_aiboost.0.fan3: 0 > dev.acpi_aiboost.0.fan4: 0 > > but no common if.. > Is there an acpi_dell or something like that? > > On 8/22/09, Aur=E9lien M=E9r=E9 wrote: > > Hi, > > > > I've been using FreeBSD for years in all my servers, but I'm facing a b= ig > > problem today. All servers are under monitoring using a couple of > > applications and scripts. Monitored items for each server especially ar= e > > CPU/mobo/UPS/HDD temperatures, CPU load, memory use, fans speed, PSU/UP= S > > voltages, HDD/RAID status&usage, network connectivity, UPS load, batter= y > > status & runtime, ... > > > > My concern today, excepted that there is no way to gather all the data > > through a unique interface and that consequently we have to change the > > scripts depending on hardware, is that some information are no longer > > available at all, especially concerning the MB IC, ie. temperatures, > > voltages & fan speed. Actually, some SMBus controllers (like from 2006 = or > > so) are not supported by any driver and I didn't find any port updated = to > > access the IC directly (if even possible). Currently, I sometimes have = to > > use mbmon with direct I/O, sometimes mbmon with SMBus, sometimes health= d > and > > sometimes nothing works (PR 137668 or 136762 as examples in my case). > > > > Besides that, I was quite surprised that these information are availabl= e > in > > OpenBSD through a very simple and unique sysctl interface, with > up-to-date > > drivers, working on all my servers with a generic install. I know that > below > > this presentation layer, this may be much less perfect, and by digging > in, I > > found that a 2007 GSoC project for porting the OpenBSD sensor framework > was > > realised and planned to be put in HEAD. I also read hundreds of mails > > concerning this project, and why finally it was not commited. > > > > As developer, I fully understand some of the concerns in these threads > and > > that there are probably lots of things to change and work on, integrate > it > > in a cleaner repository like snmp or whatever; and I'd be glad to help = in > > any > > possible way to improve this. But in the meantime, as netadmin, this ki= nd > of > > information can be very important to prevent or diagnose major problems= ; > so > > I'd like to know what is being planned/done on this subject, as I didn'= t > > find any > > more information related to this than a discussion during bsdcan 2008. > > > > Thanks for your help and time, > > Aur=E9lien > +10 I was looking for the same info a time ago .. something that would allow me to gather all the info from the same place, but the only thing I came up with was the very same discussion about the sensors framework port and nothing else. Any info on any such proyect will be greatly apreciated Regards From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 22 07:04:17 2009 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 39B621065744 for ; Sat, 22 Aug 2009 07:04:17 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outI.internet-mail-service.net (outi.internet-mail-service.net [216.240.47.232]) by mx1.freebsd.org (Postfix) with ESMTP id 843BA8FC08 for ; Sat, 22 Aug 2009 07:04:13 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 65FB5B094E; Sat, 22 Aug 2009 00:04:17 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id F3B2F2D6004; Sat, 22 Aug 2009 00:04:12 -0700 (PDT) Message-ID: <4A8F986A.3040405@elischer.org> Date: Sat, 22 Aug 2009 00:04:10 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Aur=E9lien_M=E9r=E9?= References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org Subject: Re: Common interface for sensors/health monitoring 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, 22 Aug 2009 07:04:17 -0000 Aurlien Mr wrote: > Hi, > > I've been using FreeBSD for years in all my servers, but I'm facing a big > problem today. All servers are under monitoring using a couple of > applications and scripts. Monitored items for each server especially are > CPU/mobo/UPS/HDD temperatures, CPU load, memory use, fans speed, PSU/UPS > voltages, HDD/RAID status&usage, network connectivity, UPS load, battery > status & runtime, ... > > My concern today, excepted that there is no way to gather all the data > through a unique interface and that consequently we have to change the > scripts depending on hardware, is that some information are no longer > available at all, especially concerning the MB IC, ie. temperatures, > voltages & fan speed. Actually, some SMBus controllers (like from 2006 or > so) are not supported by any driver and I didn't find any port updated to > access the IC directly (if even possible). Currently, I sometimes have to > use mbmon with direct I/O, sometimes mbmon with SMBus, sometimes healthd and > sometimes nothing works (PR 137668 or 136762 as examples in my case). > > Besides that, I was quite surprised that these information are available in > OpenBSD through a very simple and unique sysctl interface, with up-to-date > drivers, working on all my servers with a generic install. I know that below > this presentation layer, this may be much less perfect, and by digging in, I > found that a 2007 GSoC project for porting the OpenBSD sensor framework was > realised and planned to be put in HEAD. I also read hundreds of mails > concerning this project, and why finally it was not commited. > > As developer, I fully understand some of the concerns in these threads and > that there are probably lots of things to change and work on, integrate it > in a cleaner repository like snmp or whatever; and I'd be glad to help in > any > possible way to improve this. But in the meantime, as netadmin, this kind of > information can be very important to prevent or diagnose major problems; so > I'd like to know what is being planned/done on this subject, as I didn't > find any > more information related to this than a discussion during bsdcan 2008. The purists won out in that one by shouting loudly and screaming about socialized healthware. Consequently we have 47 million unsupported devices. > > Thanks for your help and time, > Aurlien > > > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 22 07:05:56 2009 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 F1C55106568D for ; Sat, 22 Aug 2009 07:05:56 +0000 (UTC) (envelope-from marc@msys.ch) Received: from sleipnir.msys.ch (smtp.msys.ch [157.161.101.10]) by mx1.freebsd.org (Postfix) with ESMTP id 9A2428FC1A for ; Sat, 22 Aug 2009 07:05:56 +0000 (UTC) Received: from mail.msys.ch (smtp.msys.ch [157.161.101.10]) by sleipnir.msys.ch (8.14.3/8.14.1) with ESMTP id n7M6oOA9012780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 22 Aug 2009 08:50:24 +0200 (CEST) Received: from [192.168.17.107] (gw.vnode.ch [62.12.170.129]) (authenticated bits=0) by mail.msys.ch (8.14.3/8.14.1) with ESMTP id n7M6oNFt023874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 22 Aug 2009 08:50:23 +0200 (CEST) Message-Id: <2DC22872-96F5-4C0A-82E4-F9755A10E245@msys.ch> From: Marc Balmer To: Gonzalo Nemmi In-Reply-To: <19e9a5dc0908212303j28a6913er604bfd06e7df81ec@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 22 Aug 2009 08:50:23 +0200 References: <6101e8c40908211917k69c82491w3cff00a527d14873@mail.gmail.com> <19e9a5dc0908212303j28a6913er604bfd06e7df81ec@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL Cc: =?ISO-8859-1?Q?Aur=E9lien_M=E9r=E9?= , freebsd-hackers@FreeBSD.org, Oliver Pinter Subject: Re: Common interface for sensors/health monitoring 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, 22 Aug 2009 07:05:57 -0000 Am 22.08.2009 um 08:03 schrieb Gonzalo Nemmi: > On Fri, Aug 21, 2009 at 11:17 PM, Oliver Pinter =20 > wrote: > >> Hello! >> >> When I good know, no common interface exisit in current freebsd >> kernel, but some other sysctl interfece exisit: coretemp, aiboost ... >> >> ~> sysctl dev.coretemp >> dev.coretemp.0.%desc: CPU On-Die Thermal Sensors >> dev.coretemp.0.%driver: coretemp >> dev.coretemp.0.%parent: cpu0 >> dev.coretemp.1.%desc: CPU On-Die Thermal Sensors >> dev.coretemp.1.%driver: coretemp >> dev.coretemp.1.%parent: cpu1 >> dev.coretemp.2.%desc: CPU On-Die Thermal Sensors >> dev.coretemp.2.%driver: coretemp >> dev.coretemp.2.%parent: cpu2 >> dev.coretemp.3.%desc: CPU On-Die Thermal Sensors >> dev.coretemp.3.%driver: coretemp >> dev.coretemp.3.%parent: cpu3 >> >> ~> sysctl dev.acpi_aiboost >> dev.acpi_aiboost.0.%desc: ASUStek AIBOOSTER >> dev.acpi_aiboost.0.%driver: acpi_aiboost >> dev.acpi_aiboost.0.%location: handle=3D\_SB_.PCI0.SBRG.ASOC >> dev.acpi_aiboost.0.%pnpinfo: _HID=3DATK0110 _UID=3D16843024 >> dev.acpi_aiboost.0.%parent: acpi0 >> dev.acpi_aiboost.0.temp0: 190 >> dev.acpi_aiboost.0.temp1: 300 >> dev.acpi_aiboost.0.volt0: 1144 >> dev.acpi_aiboost.0.volt1: 3328 >> dev.acpi_aiboost.0.volt2: 5064 >> dev.acpi_aiboost.0.volt3: 12096 >> dev.acpi_aiboost.0.fan0: 1962 >> dev.acpi_aiboost.0.fan1: 1180 >> dev.acpi_aiboost.0.fan2: 1278 >> dev.acpi_aiboost.0.fan3: 0 >> dev.acpi_aiboost.0.fan4: 0 >> >> but no common if.. >> > > Is there an acpi_dell or something like that? > > >> >> On 8/22/09, Aur=E9lien M=E9r=E9 wrote: >>> Hi, >>> >>> I've been using FreeBSD for years in all my servers, but I'm =20 >>> facing a big >>> problem today. All servers are under monitoring using a couple of >>> applications and scripts. Monitored items for each server =20 >>> especially are >>> CPU/mobo/UPS/HDD temperatures, CPU load, memory use, fans speed, =20 >>> PSU/UPS >>> voltages, HDD/RAID status&usage, network connectivity, UPS load, =20 >>> battery >>> status & runtime, ... >>> >>> My concern today, excepted that there is no way to gather all the =20= >>> data >>> through a unique interface and that consequently we have to change =20= >>> the >>> scripts depending on hardware, is that some information are no =20 >>> longer >>> available at all, especially concerning the MB IC, ie. temperatures, >>> voltages & fan speed. Actually, some SMBus controllers (like from =20= >>> 2006 or >>> so) are not supported by any driver and I didn't find any port =20 >>> updated to >>> access the IC directly (if even possible). Currently, I sometimes =20= >>> have to >>> use mbmon with direct I/O, sometimes mbmon with SMBus, sometimes =20 >>> healthd >> and >>> sometimes nothing works (PR 137668 or 136762 as examples in my =20 >>> case). >>> >>> Besides that, I was quite surprised that these information are =20 >>> available >> in >>> OpenBSD through a very simple and unique sysctl interface, with >> up-to-date >>> drivers, working on all my servers with a generic install. I know =20= >>> that >> below >>> this presentation layer, this may be much less perfect, and by =20 >>> digging >> in, I >>> found that a 2007 GSoC project for porting the OpenBSD sensor =20 >>> framework >> was >>> realised and planned to be put in HEAD. I also read hundreds of =20 >>> mails >>> concerning this project, and why finally it was not commited. >>> >>> As developer, I fully understand some of the concerns in these =20 >>> threads >> and >>> that there are probably lots of things to change and work on, =20 >>> integrate >> it >>> in a cleaner repository like snmp or whatever; and I'd be glad to =20= >>> help in >>> any >>> possible way to improve this. But in the meantime, as netadmin, =20 >>> this kind >> of >>> information can be very important to prevent or diagnose major =20 >>> problems; >> so >>> I'd like to know what is being planned/done on this subject, as I =20= >>> didn't >>> find any >>> more information related to this than a discussion during bsdcan =20 >>> 2008. >>> >>> Thanks for your help and time, >>> Aur=E9lien >> > > +10 > > I was looking for the same info a time ago .. something that would =20 > allow me > to gather all the info from the same place, but the only thing I =20 > came up > with was the very same discussion about the sensors framework port and > nothing else. > > Any info on any such proyect will be greatly apreciated The OpenBSD sensors framework lacks some desireable features, e.g. =20 event capabilities like getting an event if a certain threshold is =20 exceeded. And it propbably was used for things that it better had not =20= (yes, I am culprit for on of these (ab)uses...). I am sure these features could be added if only the code was in the =20 tree to hack on... - Marc Balmer From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 22 10:45:56 2009 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 6E9E6106568F; Sat, 22 Aug 2009 10:45:56 +0000 (UTC) (envelope-from prvs=147868619d=brian@FreeBSD.org) Received: from idcmail-mo1so.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id 172218FC08; Sat, 22 Aug 2009 10:45:55 +0000 (UTC) Received: from pd2ml1so-ssvc.prod.shaw.ca ([10.0.141.139]) by pd2mo1so-svcs.prod.shaw.ca with ESMTP; 22 Aug 2009 04:45:55 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=1 a=BN5Fd0iOSU8A:10 a=MJPcHhXccCG8eBs0us8XwA==:17 a=6I5d2MoRAAAA:8 a=MMwg4So0AAAA:8 a=P8dKc2PLvlz1ZIgMnPUA:9 a=9F4otH7t7ER6egtWpK8A:7 a=Za4Oqx47EjDomjW2aHXlsWOaN8IA:4 a=SV7veod9ZcQA:10 a=WJ3hkfHDukgA:10 a=qpoLnDooHhmQrEM_:21 a=L1stWGbGfJ4UFiL2:21 a=ZmYtWbBkNySDe_TuI5kA:9 a=qp8cfZTJBEHZnvW2cXDrL_p3AtQA:4 Received: from unknown (HELO store.lan.Awfulhak.org) ([70.79.162.198]) by pd2ml1so-dmz.prod.shaw.ca with ESMTP; 22 Aug 2009 04:45:55 -0600 Received: from store.lan.Awfulhak.org (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id B3D6FC433AA_A8FCC5FB; Sat, 22 Aug 2009 10:45:51 +0000 (GMT) Received: from gw.Awfulhak.org (gw.lan.Awfulhak.org [172.16.0.1]) by store.lan.Awfulhak.org (Sophos Email Appliance) with ESMTP id 37C7AC460F6_A8FCC5BF; Sat, 22 Aug 2009 10:45:47 +0000 (GMT) Received: from dev.lan.Awfulhak.org (brian@dev.lan.Awfulhak.org [172.16.0.5]) by gw.Awfulhak.org (8.14.3/8.14.3) with ESMTP id n7MAjnSR005267; Sat, 22 Aug 2009 03:45:50 -0700 (PDT) (envelope-from brian@FreeBSD.org) Date: Sat, 22 Aug 2009 03:45:37 -0700 From: Brian Somers To: Kip Macy Message-ID: <20090822034537.76b16271@dev.lan.Awfulhak.org> In-Reply-To: <20090821232313.21a9a7f9@dev.lan.Awfulhak.org> References: <20090821164312.641fe2bd@dev.lan.Awfulhak.org> <3c1674c90908211713j36415b96q58b0ed66cc82713f@mail.gmail.com> <20090821215503.3eec9a15@dev.lan.Awfulhak.org> <20090821224134.11d9a2a1@dev.lan.Awfulhak.org> <20090821232313.21a9a7f9@dev.lan.Awfulhak.org> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.5; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/gLiWnsbK4uMkpc41Y3jyX3S"; protocol="application/pgp-signature" Cc: freebsd-hackers@FreeBSD.org, Brian Somers Subject: Re: kernel panics in in_lltable_lookup (with INVARIANTS) 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, 22 Aug 2009 10:45:56 -0000 --Sig_/gLiWnsbK4uMkpc41Y3jyX3S Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, 21 Aug 2009 23:23:13 -0700 Brian Somers wrote: > On Fri, 21 Aug 2009 22:41:34 -0700 Brian Somers wrot= e: > > On Fri, 21 Aug 2009 21:55:03 -0700 Brian Somers wro= te: > > > On Fri, 21 Aug 2009 17:13:45 -0700 Kip Macy wrote: > > > > Try this: > > > >=20 > > > > Index: sys/net/flowtable.c > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > --- sys/net/flowtable.c (revision 196382) > > > > +++ sys/net/flowtable.c (working copy) > > > > @@ -688,6 +688,12 @@ > > > > struct rtentry *rt =3D ro->ro_rt; > > > > struct ifnet *ifp =3D rt->rt_ifp; > > > >=20 > > > > + if (ifp->if_flags & IFF_POINTOPOINT) { > > > > + RTFREE(rt); > > > > + ro->ro_rt =3D NULL; > > > > + return (ENOENT); > > > > + } > > > > + > > > > if (rt->rt_flags & RTF_GATEWAY) > > > > l3addr =3D rt->rt_gateway; > > > > else > > > >=20 > > > > You'll need to apply this by hand as gmail munges the formatting. > > > >=20 > > > > -Kip > > >=20 > > > Hi, > > >=20 > > > That certainly stops the panic, however data routed to the tun > > > interface doesn't come out the back end and data written > > > to the back end doesn't come out the tun interface. > > [.....] > > > Maybe this problem isn't a routing problem. I'll > > > look into it further and figure out if the packet is getting to the t= un > > > driver and if so, what it thinks it's doing with it. > >=20 > > I wasn't correct - the data *IS* being read out of the back of > > the tunnel device. When I send the ICMP, it goes into the tun > > device and comes out the back end as an AF_LINK packet. ppp > > silently discards this (ironically I have a comment noting > > that I should really track unidentified packet counts). > >=20 > > I'll try to figure out what in if_tun.c is corrupting the family next... >=20 > if_tun.c is fine. The data passed from if_output() has family > AF_LINK - hence the original panic from flowtable_lookup(). >=20 > So the question is "why is ip_output() sending AF_LINK traffic > instead of AF_INET traffic?". >=20 > Still looking.... =46rom what I can tell, this is what is happening: ip_output() is called with ro =3D=3D NULL. ip_output() calls flowtable_lookup() with a zeroed 'ro'. flowtable_lookup() calls ft->ft_rtalloc() (really rtalloc1_fib()) to initialise 'ro' and ends up with ro->ro_rt->rt_gateway->sa_family set to AF_LINK. Your original patch frees ro->ro_rt and fails before calling llentry_update() with ro->ro_rt->rt_gateway->sa_family !=3D AF_INET. Now, when flowtable_lookup() fails, ro->ro_rt is NULL and ip_output()s 'dst' gets set up with family AF_INET. Unfortunately, right after this, after checking for IP_SENDONES, IP_ROUTETOIF and IN_MULTICAST, the ip_output() code decides to call in_rtalloc_ign() (which eventually just calls rtalloc1_fib()) to initialise ro->ro_rt and then sets dst to be ro->ro_rt->rt_gateway -- which is *still* an AF_LINK address! Finally ip_output() calls ifp->if_output() (really tunoutput()) with dst's family set to AF_LINK, tunoutput() queues it to the tun character device, ppp reads it and drops it on the floor 'cos it doesn't know what to do with AF_LINK. The tun driver is more or less the same as the -stable version, so it seems that ip_output() is to blame. The only relevant part that seems substantially different is rtalloc1_fib(), so right now I'm guessing that the RTF_CLONING code in -stable always clones the route with a gw family of AF_INET and expectations are met after that. I'll look some more on the weekend... > > > > On Fri, Aug 21, 2009 at 16:43, Brian Somers wrot= e: > > > > > Hi, > > > > > > > > > > I've been working on a fix to address an issue that came up with > > > > > our update of openssh-5. =C2=A0The issue is that openssh-5 now us= es > > > > > pipe() to create stdin/stdout channels between sshd and the server > > > > > side program where it used to use socketpair(). =C2=A0Because it = uses > > > > > pipe(), stdin is no longer bi-directional and cannot be used for = both > > > > > input and output by a child process. =C2=A0This breaks the use of= ssh > > > > > as a tunnel with ppp on either end (set device "!ssh -e none host > > > > > ppp -direct label") > > > > > > > > > > I talked with des@ for a while and then with the openssh folks and > > > > > have not been able to resolve the issues in openssh that made them > > > > > choose to enforce the use of pipe() over socketpair(). =C2=A0I no= w have a > > > > > patch to ppp that makes ppp detect that it's connected via pipe()= and > > > > > causes it to use stdin for input and stdout for output (usually i= t expects > > > > > just one descriptor). =C2=A0Although I'm happy with the patch and= planned on > > > > > requesting permission to commit, I've bumped into a show-stopper > > > > > that seems unrelated, so I thought I'd ask here if anyone has seen > > > > > this or has any suggestions as to what the problem might be. > > > > > > > > > > The issue.... > > > > > > > > > > I'm seeing a panic when I send traffic through a ppp link: > > > > > > > > > > panic string is: sin_family 18 > > > > > Stack trace starts: > > > > > =C2=A0 =C2=A0in_lltable_lookup() > > > > > =C2=A0 =C2=A0llentry_update() > > > > > =C2=A0 =C2=A0flowtable_lookup() > > > > > =C2=A0 =C2=A0ip_output() > > > > > =C2=A0 =C2=A0.... > > > > > > > > > > The panic is due to a KASSERT in in_lltable_lookup() that expects= the > > > > > sockaddr to be AF_INET. =C2=A0Number 18 is AF_LINK. > > > > > > > > > > AFAICT this is happening while setting up a temporary route for t= he > > > > > first outbound packet. =C2=A0I haven't been able to do much inves= tigation > > > > > yet due to other patches in my tree that seem to have broken all = my > > > > > kernel symbols, but once I get a clean rebuild I should be back in > > > > > business. > > > > > > > > > > If anyone has any suggestions, I'm all ears! > > > > > > > > > > Cheers. --=20 Brian Somers Don't _EVER_ lose your sense of humour ! --Sig_/gLiWnsbK4uMkpc41Y3jyX3S Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iQCVAwUBSo/MXA7tvOdmanQhAQImqQP7Bp+8ggpe247WlLnucfB/T4lsJoaiPhWi gV3gbGvCEyy5WP1d2lZFQzcMx/JacteL40GivXlhuzdF4NrovYWPTRGVINF4W+cf lzFC7UsECuXwyDIJrRLTQHHe0zFjpxu9fazpWma44HXE76XJwIiis6jVmai7flAl rc5kuMOLuQI= =V+gY -----END PGP SIGNATURE----- --Sig_/gLiWnsbK4uMkpc41Y3jyX3S-- From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 22 13:13:41 2009 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 CC230106568B for ; Sat, 22 Aug 2009 13:13:41 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 3AB538FC13 for ; Sat, 22 Aug 2009 13:13:40 +0000 (UTC) Received: from inchoate.gsoft.com.au (ppp121-45-173-89.lns11.adl2.internode.on.net [121.45.173.89]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n7MDDbK2070186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 22 Aug 2009 22:43:38 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Alexander Leidinger Date: Sat, 22 Aug 2009 22:43:27 +0930 User-Agent: KMail/1.9.10 References: <200908192331.34507.doconnor@gsoft.com.au> <200908201713.08368.doconnor@gsoft.com.au> <20090821144157.645117jxvao9rmzk@webmail.leidinger.net> In-Reply-To: <20090821144157.645117jxvao9rmzk@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1261833.sVJBPotx2D"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200908222243.35466.doconnor@gsoft.com.au> X-Spam-Score: -1.531 () AWL,BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: freebsd-hackers@freebsd.org Subject: Re: DTrace probes & klds 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, 22 Aug 2009 13:13:42 -0000 --nextPart1261833.sVJBPotx2D Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Fri, 21 Aug 2009, Alexander Leidinger wrote: > Quoting Daniel O'Connor (from Thu, 20 Aug > 2009 > > 17:13:07 +0930): > > On Thu, 20 Aug 2009, Alexander Leidinger wrote: > >> Quoting Daniel O'Connor (from Wed, 19 Aug > >> 2009 > >> > >> 23:31:33 +0930): > >> > Content-Type: text/plain; > >> > charset=3D"utf-8" > >> > Content-Transfer-Encoding: quoted-printable > >> > Content-Disposition: inline > >> > > >> > Is it possible? the handbook implies not and I can't get it to > >> > work, but i could be doing it wrong.. > >> > > >> > I get fbt traces listed for KLDs (I get new entries for each > >> > load of the KLD which seems like a potential problem) but I > >> > can't specify an SDT_PROBE and have it work. > >> > >> Can you show us some example code? > > > > /* Recycle fbt as SDT_PROVIDER_DEFINE is said not to work */ > > SDT_PROBE_DEFINE(fbt, gsio, gsio_intr, test); > > SDT_PROBE_ARGTYPE(fbt, gsio, gsio_intr, test, 0, "int"); > > SDT_PROBE_ARGTYPE(fbt, gsio, gsio_intr, test, 1, "int"); > > I don't think you can define a fbt probe by hand. You can define a > provider on your own via SDT_PROVIDER_DEFINE (in only one > place/file), and then use this provider instead of fbt above. Let's > assume you defined a gsio provider, then the SDT_PROBE_DEFINE could > be > SDT_PROBE_DEFINE(gsio, , gsio_intr, > test); Yes, I only wanted to reuse fbt because the handbook says=20 SDT_PROBE_DEFINE doesn't work as a KLD. > If there's only one file, it does not make much sense to add an > unique part of the name of the file, but if you have multiple files > it can be helpful. But this is just an example, for example in GEOM > it would make sense to name the provider "geom", and instead of the > file name use the module name, e.g. mirror, raid3, core/whatever, ... > instead. Hmmm. I have tried that, but not joy :( SDT_PROVIDER_DEFINE(gsio); SDT_PROBE_DEFINE(gsio, main, gsio_intr, test); SDT_PROBE_ARGTYPE(gsio, main, gsio_intr, test, 0, "int"); SDT_PROBE_ARGTYPE(gsio, main, gsio_intr, test, 1, "int"); =2E.. SDT_PROBE(gsio, main, gsio_intr, test, istat, 0, 0, 0, 0); I built my module with WITH_CTF=3D1 and I see that ctfconvert is run,=20 however when I load it the Dtrace providers/providers aren't there. Building it into the kernel works but isn't ideal. Hmm, initially I was building my KLD outside of the tree, however when I=20 build it with buildkernel & load it dtrace -l crashes the system and I=20 can't get a crashdump at the moment.. I'll try again when I can get to=20 the console. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1261833.sVJBPotx2D Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBKj+7/5ZPcIHs/zowRArLwAJwPpVqVWss6MpMWXxqGRnTm3EJUzQCfb6ZZ ZjNKHKvNQPKzRA+xtAcAzZM= =bgKn -----END PGP SIGNATURE----- --nextPart1261833.sVJBPotx2D-- From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 22 06:09:49 2009 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 5DDEE106564A; Sat, 22 Aug 2009 06:09:49 +0000 (UTC) (envelope-from prvs=147868619d=brian@Awfulhak.org) Received: from idcmail-mo2no.shaw.ca (idcmail-mo2no.shaw.ca [64.59.134.9]) by mx1.freebsd.org (Postfix) with ESMTP id 1354F8FC1A; Sat, 22 Aug 2009 06:09:48 +0000 (UTC) Received: from pd7ml2no-ssvc.prod.shaw.ca ([10.0.153.162]) by pd5mo1no-svcs.prod.shaw.ca with ESMTP; 21 Aug 2009 23:41:40 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=1 a=BN5Fd0iOSU8A:10 a=MJPcHhXccCG8eBs0us8XwA==:17 a=6I5d2MoRAAAA:8 a=MMwg4So0AAAA:8 a=g6kdJJKMxq21qQ3NCfAA:9 a=5kP0PoyluC1s4KTuiH4A:7 a=HKIDxmP8TC9LG-Yg7iNi9MoiEDkA:4 a=SV7veod9ZcQA:10 a=WJ3hkfHDukgA:10 a=0dbfaRH7gSmKxhbu:21 a=N9QTdzOVIOTVbCiS:21 Received: from unknown (HELO store.lan.Awfulhak.org) ([70.79.162.198]) by pd7ml2no-dmz.prod.shaw.ca with ESMTP; 21 Aug 2009 23:41:40 -0600 Received: from store.lan.Awfulhak.org (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 7DCDCC433B6_A8F8510B; Sat, 22 Aug 2009 05:41:36 +0000 (GMT) Received: from gw.Awfulhak.org (gw.lan.Awfulhak.org [172.16.0.1]) by store.lan.Awfulhak.org (Sophos Email Appliance) with ESMTP id 11D66C460F8_A8F850CF; Sat, 22 Aug 2009 05:41:32 +0000 (GMT) Received: from dev.lan.Awfulhak.org (brian@dev.lan.Awfulhak.org [172.16.0.5]) by gw.Awfulhak.org (8.14.3/8.14.3) with ESMTP id n7M5fYmq092308; Fri, 21 Aug 2009 22:41:34 -0700 (PDT) (envelope-from brian@Awfulhak.org) Date: Fri, 21 Aug 2009 22:41:34 -0700 From: Brian Somers To: Kip Macy Message-ID: <20090821224134.11d9a2a1@dev.lan.Awfulhak.org> In-Reply-To: <20090821215503.3eec9a15@dev.lan.Awfulhak.org> References: <20090821164312.641fe2bd@dev.lan.Awfulhak.org> <3c1674c90908211713j36415b96q58b0ed66cc82713f@mail.gmail.com> <20090821215503.3eec9a15@dev.lan.Awfulhak.org> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.5; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 22 Aug 2009 13:43:37 +0000 Cc: freebsd-hackers@FreeBSD.org, Brian Somers Subject: Re: kernel panics in in_lltable_lookup (with INVARIANTS) 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, 22 Aug 2009 06:09:49 -0000 On Fri, 21 Aug 2009 21:55:03 -0700 Brian Somers wrote: > On Fri, 21 Aug 2009 17:13:45 -0700 Kip Macy wrote: > > Try this: > >=20 > > Index: sys/net/flowtable.c > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- sys/net/flowtable.c (revision 196382) > > +++ sys/net/flowtable.c (working copy) > > @@ -688,6 +688,12 @@ > > struct rtentry *rt =3D ro->ro_rt; > > struct ifnet *ifp =3D rt->rt_ifp; > >=20 > > + if (ifp->if_flags & IFF_POINTOPOINT) { > > + RTFREE(rt); > > + ro->ro_rt =3D NULL; > > + return (ENOENT); > > + } > > + > > if (rt->rt_flags & RTF_GATEWAY) > > l3addr =3D rt->rt_gateway; > > else > >=20 > > You'll need to apply this by hand as gmail munges the formatting. > >=20 > > -Kip >=20 > Hi, >=20 > That certainly stops the panic, however data routed to the tun > interface doesn't come out the back end and data written > to the back end doesn't come out the tun interface. [.....] > Maybe this problem isn't a routing problem. I'll > look into it further and figure out if the packet is getting to the tun > driver and if so, what it thinks it's doing with it. I wasn't correct - the data *IS* being read out of the back of the tunnel device. When I send the ICMP, it goes into the tun device and comes out the back end as an AF_LINK packet. ppp silently discards this (ironically I have a comment noting that I should really track unidentified packet counts). I'll try to figure out what in if_tun.c is corrupting the family next... Cheers. > > On Fri, Aug 21, 2009 at 16:43, Brian Somers wrote: > > > Hi, > > > > > > I've been working on a fix to address an issue that came up with > > > our update of openssh-5. =C2=A0The issue is that openssh-5 now uses > > > pipe() to create stdin/stdout channels between sshd and the server > > > side program where it used to use socketpair(). =C2=A0Because it uses > > > pipe(), stdin is no longer bi-directional and cannot be used for both > > > input and output by a child process. =C2=A0This breaks the use of ssh > > > as a tunnel with ppp on either end (set device "!ssh -e none host > > > ppp -direct label") > > > > > > I talked with des@ for a while and then with the openssh folks and > > > have not been able to resolve the issues in openssh that made them > > > choose to enforce the use of pipe() over socketpair(). =C2=A0I now ha= ve a > > > patch to ppp that makes ppp detect that it's connected via pipe() and > > > causes it to use stdin for input and stdout for output (usually it ex= pects > > > just one descriptor). =C2=A0Although I'm happy with the patch and pla= nned on > > > requesting permission to commit, I've bumped into a show-stopper > > > that seems unrelated, so I thought I'd ask here if anyone has seen > > > this or has any suggestions as to what the problem might be. > > > > > > The issue.... > > > > > > I'm seeing a panic when I send traffic through a ppp link: > > > > > > panic string is: sin_family 18 > > > Stack trace starts: > > > =C2=A0 =C2=A0in_lltable_lookup() > > > =C2=A0 =C2=A0llentry_update() > > > =C2=A0 =C2=A0flowtable_lookup() > > > =C2=A0 =C2=A0ip_output() > > > =C2=A0 =C2=A0.... > > > > > > The panic is due to a KASSERT in in_lltable_lookup() that expects the > > > sockaddr to be AF_INET. =C2=A0Number 18 is AF_LINK. > > > > > > AFAICT this is happening while setting up a temporary route for the > > > first outbound packet. =C2=A0I haven't been able to do much investiga= tion > > > yet due to other patches in my tree that seem to have broken all my > > > kernel symbols, but once I get a clean rebuild I should be back in > > > business. > > > > > > If anyone has any suggestions, I'm all ears! > > > > > > Cheers. --=20 Brian Somers Don't _EVER_ lose your sense of humour ! From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 22 14:29:38 2009 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 DD0D9106568B for ; Sat, 22 Aug 2009 14:29:38 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B3B4C8FC08 for ; Sat, 22 Aug 2009 14:29:38 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 55E6C46B1A; Sat, 22 Aug 2009 10:29:38 -0400 (EDT) Date: Sat, 22 Aug 2009 15:29:38 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Marc Balmer In-Reply-To: <2DC22872-96F5-4C0A-82E4-F9755A10E245@msys.ch> Message-ID: References: <6101e8c40908211917k69c82491w3cff00a527d14873@mail.gmail.com> <19e9a5dc0908212303j28a6913er604bfd06e7df81ec@mail.gmail.com> <2DC22872-96F5-4C0A-82E4-F9755A10E245@msys.ch> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: =?ISO-8859-15?Q?Aur=E9lien_M=E9r=E9?= , Oliver Pinter , Gonzalo Nemmi , freebsd-hackers@FreeBSD.org Subject: Re: Common interface for sensors/health monitoring 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, 22 Aug 2009 14:29:38 -0000 On Sat, 22 Aug 2009, Marc Balmer wrote: >> I was looking for the same info a time ago .. something that would allow me >> to gather all the info from the same place, but the only thing I came up >> with was the very same discussion about the sensors framework port and >> nothing else. >> >> Any info on any such proyect will be greatly apreciated > > The OpenBSD sensors framework lacks some desireable features, e.g. event > capabilities like getting an event if a certain threshold is exceeded. And > it propbably was used for things that it better had not (yes, I am culprit > for on of these (ab)uses...). > > I am sure these features could be added if only the code was in the tree to > hack on... One of the things I'd particularly like to see is an alignment between kernel/user level monitoring frameworks and the SNMP model (especially relating to traps). The SNMP information model (MIBs, agents, traps, etc) has its limitations, but having a compatible model at all layers of the system will make it easier to store, manipulate, manage, and report this information consistently throughout the OS and larger distributed systems. Robert From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 22 16:29:36 2009 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 11D78106568E for ; Sat, 22 Aug 2009 16:29:36 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id BB83B8FC19 for ; Sat, 22 Aug 2009 16:29:35 +0000 (UTC) Received: from outgoing.leidinger.net (pD9E2CC10.dip.t-dialin.net [217.226.204.16]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id E0EA884534E; Sat, 22 Aug 2009 18:29:27 +0200 (CEST) Received: from unknown (IO.Leidinger.net [192.168.2.103]) by outgoing.leidinger.net (Postfix) with ESMTP id E2F4C6F72D; Sat, 22 Aug 2009 18:29:24 +0200 (CEST) Date: Sat, 22 Aug 2009 18:29:23 +0200 From: Alexander Leidinger To: Marc Balmer Message-ID: <20090822182923.000064e0@unknown> In-Reply-To: <2DC22872-96F5-4C0A-82E4-F9755A10E245@msys.ch> References: <6101e8c40908211917k69c82491w3cff00a527d14873@mail.gmail.com> <19e9a5dc0908212303j28a6913er604bfd06e7df81ec@mail.gmail.com> <2DC22872-96F5-4C0A-82E4-F9755A10E245@msys.ch> X-Mailer: Claws Mail 3.7.2cvs15 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: E0EA884534E.76F7A X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.44, required 6, autolearn=disabled, ALL_TRUSTED -1.44) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1251563370.9932@/TR0LWj481Gl1yBxMjczCw X-EBL-Spam-Status: No X-Mailman-Approved-At: Sat, 22 Aug 2009 17:43:39 +0000 Cc: =?ISO-8859-1?Q?Aur=E9lien_M=E9r=E9?= , Oliver Pinter , Gonzalo Nemmi , freebsd-hackers@FreeBSD.org Subject: Re: Common interface for sensors/health monitoring 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, 22 Aug 2009 16:29:36 -0000 On Sat, 22 Aug 2009 08:50:23 +0200 Marc Balmer wrote: > The OpenBSD sensors framework lacks some desireable features, e.g. > event capabilities like getting an event if a certain threshold is > exceeded. And it propbably was used for things that it better had This assumes the kernel is monitoring the device periodically (in the general case, as there are a lot of dump sensors which do not send events on their own). The framework as in the SoC did not provide this feature to keep the kernel part simple. You want to see a value, you poll the kernel for it, and the userland would have been responsible to fire up an event. For smart sensors which trigger an event on their own (interrupt), you can use the exiting kernel event framework (and the idea in the SoC was to use it for such sensors). The devd is the userland side of it. > not (yes, I am culprit for on of these (ab)uses...). > > I am sure these features could be added if only the code was in the > tree to hack on... The event stuff is in the kernel, go ahead and write a driver for your smart sensor which fires events on its own. Bye, Alexander. From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 22 16:31:18 2009 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 3F4C81065690 for ; Sat, 22 Aug 2009 16:31:18 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id ED0DE8FC13 for ; Sat, 22 Aug 2009 16:31:17 +0000 (UTC) Received: from outgoing.leidinger.net (pD9E2CC10.dip.t-dialin.net [217.226.204.16]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id CAE4884534E for ; Sat, 22 Aug 2009 18:31:12 +0200 (CEST) Received: from unknown (IO.Leidinger.net [192.168.2.103]) by outgoing.leidinger.net (Postfix) with ESMTP id 073D16F784 for ; Sat, 22 Aug 2009 18:31:06 +0200 (CEST) Date: Sat, 22 Aug 2009 18:31:05 +0200 From: Alexander Leidinger To: freebsd-hackers@freebsd.org Message-ID: <20090822183105.00007262@unknown> In-Reply-To: <4A8F986A.3040405@elischer.org> References: <4A8F986A.3040405@elischer.org> X-Mailer: Claws Mail 3.7.2cvs15 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: CAE4884534E.BA715 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.44, required 6, autolearn=disabled, ALL_TRUSTED -1.44) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1251563473.51388@bARgrvJ+Ww9XVJAhDECgow X-EBL-Spam-Status: No X-Mailman-Approved-At: Sat, 22 Aug 2009 17:43:49 +0000 Subject: Re: Common interface for sensors/health monitoring 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, 22 Aug 2009 16:31:18 -0000 On Sat, 22 Aug 2009 00:04:10 -0700 Julian Elischer wrote: > The purists won out in that one by shouting loudly and screaming > about socialized healthware. Consequently we have 47 million > unsupported devices. You forgot to tell that now nobody wants to touch this subject anymore, as he may be the target of similar shouting then. Bye, Alexander. From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 22 18:00:25 2009 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 D5F83106568B for ; Sat, 22 Aug 2009 18:00:25 +0000 (UTC) (envelope-from marc@msys.ch) Received: from sleipnir.msys.ch (smtp.msys.ch [157.161.101.10]) by mx1.freebsd.org (Postfix) with ESMTP id 65CF88FC0A for ; Sat, 22 Aug 2009 18:00:24 +0000 (UTC) Received: from mail.msys.ch (smtp.msys.ch [157.161.101.10]) by sleipnir.msys.ch (8.14.3/8.14.1) with ESMTP id n7MHx1sv022478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 22 Aug 2009 19:59:01 +0200 (CEST) Received: from [192.168.17.107] (gw.vnode.ch [62.12.170.129]) (authenticated bits=0) by mail.msys.ch (8.14.3/8.14.1) with ESMTP id n7MHx01W026248 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 22 Aug 2009 19:59:01 +0200 (CEST) Message-Id: <5A17DFEE-F618-4027-92C5-6EA339B78BF1@msys.ch> From: Marc Balmer To: Alexander Leidinger In-Reply-To: <20090822182923.000064e0@unknown> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 22 Aug 2009 19:59:00 +0200 References: <6101e8c40908211917k69c82491w3cff00a527d14873@mail.gmail.com> <19e9a5dc0908212303j28a6913er604bfd06e7df81ec@mail.gmail.com> <2DC22872-96F5-4C0A-82E4-F9755A10E245@msys.ch> <20090822182923.000064e0@unknown> X-Mailer: Apple Mail (2.936) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL Cc: =?ISO-8859-1?Q?Aur=E9lien_M=E9r=E9?= , Gonzalo Nemmi , freebsd-hackers@freebsd.org, Oliver Pinter Subject: Re: Common interface for sensors/health monitoring 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, 22 Aug 2009 18:00:25 -0000 Am 22.08.2009 um 18:29 schrieb Alexander Leidinger: > On Sat, 22 Aug 2009 08:50:23 +0200 Marc Balmer wrote: > >> The OpenBSD sensors framework lacks some desireable features, e.g. >> event capabilities like getting an event if a certain threshold is >> exceeded. And it propbably was used for things that it better had > > This assumes the kernel is monitoring the device periodically (in the > general case, as there are a lot of dump sensors which do not send > events on their own). The framework as in the SoC did not provide this > feature to keep the kernel part simple. You want to see a value, you > poll the kernel for it, and the userland would have been responsible > to > fire up an event. > > For smart sensors which trigger an event on their own (interrupt), you > can use the exiting kernel event framework (and the idea in the SoC > was to use it for such sensors). The devd is the userland side of it. > >> not (yes, I am culprit for on of these (ab)uses...). >> >> I am sure these features could be added if only the code was in the >> tree to hack on... > > The event stuff is in the kernel, go ahead and write a driver for your > smart sensor which fires events on its own. Well, most of the sensors are likely I2C or 1-Wire devices and these can only be polled. From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 22 18:48:58 2009 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 B13F3106573C for ; Sat, 22 Aug 2009 18:48:58 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id A18A18FC08 for ; Sat, 22 Aug 2009 18:48:58 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 5CA771A4080; Sat, 22 Aug 2009 11:48:58 -0700 (PDT) Date: Sat, 22 Aug 2009 11:48:58 -0700 From: Alfred Perlstein To: Alexander Leidinger Message-ID: <20090822184858.GC21946@elvis.mu.org> References: <4A8F986A.3040405@elischer.org> <20090822183105.00007262@unknown> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090822183105.00007262@unknown> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org Subject: Re: Common interface for sensors/health monitoring 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, 22 Aug 2009 18:48:58 -0000 * Alexander Leidinger [090822 10:44] wrote: > On Sat, 22 Aug 2009 00:04:10 -0700 Julian Elischer > wrote: > > > The purists won out in that one by shouting loudly and screaming > > about socialized healthware. Consequently we have 47 million > > unsupported devices. > > You forgot to tell that now nobody wants to touch this subject anymore, > as he may be the target of similar shouting then. I say good riddence, if someone wants thier hardware not to melt then each machine should be personally responsible and enroll in a private monitoring service we don't need project sponsored health monitoring. (ron paul!) -- - Alfred Perlstein .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250 .- FreeBSD committer From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 22 18:57:15 2009 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 C45C3106568C for ; Sat, 22 Aug 2009 18:57:15 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from cauchy.math.missouri.edu (cauchy.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id 930F88FC12 for ; Sat, 22 Aug 2009 18:57:15 +0000 (UTC) Received: from laptop3.gateway.2wire.net (cauchy.math.missouri.edu [128.206.184.213]) by cauchy.math.missouri.edu (8.14.3/8.14.3) with ESMTP id n7MIvEH1098190 for ; Sat, 22 Aug 2009 13:57:15 -0500 (CDT) (envelope-from stephen@missouri.edu) Message-ID: <4A903F8A.3010303@missouri.edu> Date: Sat, 22 Aug 2009 13:57:14 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.1.22) Gecko/20090807 SeaMonkey/1.1.17 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4A8F986A.3040405@elischer.org> <20090822183105.00007262@unknown> <20090822184858.GC21946@elvis.mu.org> In-Reply-To: <20090822184858.GC21946@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Common interface for sensors/health monitoring 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, 22 Aug 2009 18:57:15 -0000 Alfred Perlstein wrote: > * Alexander Leidinger [090822 10:44] wrote: >> On Sat, 22 Aug 2009 00:04:10 -0700 Julian Elischer >> wrote: >> >>> The purists won out in that one by shouting loudly and screaming >>> about socialized healthware. Consequently we have 47 million >>> unsupported devices. >> You forgot to tell that now nobody wants to touch this subject anymore, >> as he may be the target of similar shouting then. > > I say good riddence, if someone wants thier hardware not to melt > then each machine should be personally responsible and enroll in > a private monitoring service we don't need project sponsored health > monitoring. > > (ron paul!) > I think that this kind of talk calls for boycotting certain device drivers! From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 22 19:12:08 2009 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 99C7A106564A; Sat, 22 Aug 2009 19:12:08 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 29DB98FC16; Sat, 22 Aug 2009 19:12:08 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 615811CD18; Sat, 22 Aug 2009 21:12:07 +0200 (CEST) Date: Sat, 22 Aug 2009 21:12:07 +0200 From: Ed Schouten To: freebsd-hackers@FreeBSD.org Message-ID: <20090822191207.GP1292@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xzSe+wpn+kb4oFkG" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: kmacy@FreeBSD.org Subject: CFT: Patch for the Xen console 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: Sat, 22 Aug 2009 19:12:08 -0000 --xzSe+wpn+kb4oFkG Content-Type: multipart/mixed; boundary="mio/lN7rX3OFvPvp" Content-Disposition: inline --mio/lN7rX3OFvPvp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi folks, Today I was doing some cleanups to our kernel message/debug console code and I noticed we have only one driver in the tree that does some really spooky things with its console device, namely the Xen console driver. I did some cleanups and basically fixed the following: - It now uses the CONSOLE_DRIVER() way to declare a driver, instead of using CONS_DRIVER() (which has some arguments which are no-ops nowadays), which means we can remove CONS_DRIVER() entirely. - It doesn't use cn_checkc anymore. The driver had a cn_getc routine, but it was never being called, because it was overlapped by cn_checkc. cn_checkc is deprecated in favour of cn_getc, so I removed cn_getc and renamed cn_checkc to cn_getc. - It doesn't runtime patch the functions inside struct consdev anymore. I'm planning on changing the consdev code to disallow drivers to patch their own functions, because the structure containing them may be shared between multiple console devices. Because I don't have a system with Xen, I was only capable of compile-testing the driver. Are there any (8.0-)users here who can test the attached patch for me? Thanks! --=20 Ed Schouten WWW: http://80386.nl/ --mio/lN7rX3OFvPvp Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="xencons.diff" Content-Transfer-Encoding: quoted-printable --- sys/dev/xen/console/console.c +++ sys/dev/xen/console/console.c @@ -45,17 +45,15 @@ static void xcons_force_flush(void); static void xencons_priv_interrupt(void *); =20 -static cn_probe_t xccnprobe; -static cn_init_t xccninit; -static cn_getc_t xccngetc; -static cn_putc_t xccnputc; -static cn_putc_t xccnputc_dom0; -static cn_checkc_t xccncheckc; +static cn_probe_t xc_cnprobe; +static cn_init_t xc_cninit; +static cn_term_t xc_cnterm; +static cn_getc_t xc_cngetc; +static cn_putc_t xc_cnputc; =20 #define XC_POLLTIME (hz/10) =20 -CONS_DRIVER(xc, xccnprobe, xccninit, NULL, xccngetc,=20 - xccncheckc, xccnputc, NULL); +CONSOLE_DRIVER(xc); =20 static int xen_console_up; static boolean_t xc_start_needed; @@ -105,7 +103,7 @@ }; =20 static void -xccnprobe(struct consdev *cp) +xc_cnprobe(struct consdev *cp) { cp->cn_pri =3D CN_REMOTE; sprintf(cp->cn_name, "%s0", driver_name); @@ -113,37 +111,19 @@ =20 =20 static void -xccninit(struct consdev *cp) +xc_cninit(struct consdev *cp) {=20 CN_LOCK_INIT(cn_mtx,"XCONS LOCK"); =20 } -int -xccngetc(struct consdev *dev) -{ - int c; - if (xc_mute) - return 0; - do { - if ((c =3D xccncheckc(dev)) =3D=3D -1) { -#ifdef KDB - if (!kdb_active) -#endif - /* - * Polling without sleeping in Xen - * doesn't work well. Sleeping gives - * other things like clock a chance to - * run - */ - tsleep(&cn_mtx, PWAIT | PCATCH, - "console sleep", XC_POLLTIME); - } - } while(c =3D=3D -1); - return c; + +static void +xc_cnterm(struct consdev *cp) +{=20 } =20 -int -xccncheckc(struct consdev *dev) +static int +xc_cngetc(struct consdev *dev) { int ret =3D (xc_mute ? 0 : -1); =20 @@ -162,17 +142,27 @@ } =20 static void -xccnputc(struct consdev *dev, int c) +xc_cnputc_domu(struct consdev *dev, int c) { xcons_putc(c); } =20 static void -xccnputc_dom0(struct consdev *dev, int c) +xc_cnputc_dom0(struct consdev *dev, int c) { HYPERVISOR_console_io(CONSOLEIO_write, 1, (char *)&c); } =20 +static void +xc_cnputc(struct consdev *dev, int c) +{ + + if (xen_start_info->flags & SIF_INITDOMAIN) + xc_cnputc_dom0(dev, c); + else + xc_cnputc_domu(dev, c); +} + extern int db_active; static boolean_t xcons_putc(int c) @@ -226,10 +216,6 @@ { int error; =20 - if (xen_start_info->flags & SIF_INITDOMAIN) { - xc_consdev.cn_putc =3D xccnputc_dom0; - }=20 - xccons =3D tty_alloc(&xc_ttydevsw, NULL); tty_makedev(xccons, NULL, "xc%r", 0); =20 @@ -388,7 +374,7 @@ tp =3D (struct tty *)v; =20 tty_lock(tp); - while ((c =3D xccncheckc(NULL)) !=3D -1) + while ((c =3D xc_cngetc(NULL)) !=3D -1) ttydisc_rint(tp, c, 0); =20 if (xc_start_needed) { --mio/lN7rX3OFvPvp-- --xzSe+wpn+kb4oFkG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkqQQwcACgkQ52SDGA2eCwVCRwCeJN1fuv6S3qqiYFQwvI1MpWRI 3z4AnioibEcAKOYq7x9lFoNqbDtk5nhB =3Yi7 -----END PGP SIGNATURE----- --xzSe+wpn+kb4oFkG-- From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 22 19:59:48 2009 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 54628106568B for ; Sat, 22 Aug 2009 19:59:48 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outN.internet-mail-service.net (outn.internet-mail-service.net [216.240.47.237]) by mx1.freebsd.org (Postfix) with ESMTP id 3C0158FC16 for ; Sat, 22 Aug 2009 19:59:48 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 8D077B9858; Sat, 22 Aug 2009 12:59:47 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 46A7F2D6013; Sat, 22 Aug 2009 12:59:47 -0700 (PDT) Message-ID: <4A904E32.2010609@elischer.org> Date: Sat, 22 Aug 2009 12:59:46 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Stephen Montgomery-Smith References: <4A8F986A.3040405@elischer.org> <20090822183105.00007262@unknown> <20090822184858.GC21946@elvis.mu.org> <4A903F8A.3010303@missouri.edu> In-Reply-To: <4A903F8A.3010303@missouri.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Common interface for sensors/health monitoring 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, 22 Aug 2009 19:59:48 -0000 Stephen Montgomery-Smith wrote: > Alfred Perlstein wrote: >> * Alexander Leidinger [090822 10:44] wrote: >>> On Sat, 22 Aug 2009 00:04:10 -0700 Julian Elischer >>> wrote: >>> >>>> The purists won out in that one by shouting loudly and screaming >>>> about socialized healthware. Consequently we have 47 million >>>> unsupported devices. >>> You forgot to tell that now nobody wants to touch this subject anymore, >>> as he may be the target of similar shouting then. >> >> I say good riddence, if someone wants thier hardware not to melt >> then each machine should be personally responsible and enroll in >> a private monitoring service we don't need project sponsored health >> monitoring. >> >> (ron paul!) >> > > I think that this kind of talk calls for boycotting certain device drivers! In OpenBSD they have project sponsored healthware and sometimes you have to wait in a queue to get you notifications, and sometimes the queue is so long events have to get merged! Not for me! I want all my individual events to be lost After I get them. It's my right! > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 22 19:21:06 2009 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 AE318106568B for ; Sat, 22 Aug 2009 19:21:06 +0000 (UTC) (envelope-from aurelien.mere@amc-os.com) Received: from smtpfb1-g21.free.fr (smtpfb1-g21.free.fr [212.27.42.9]) by mx1.freebsd.org (Postfix) with ESMTP id 241998FC1A for ; Sat, 22 Aug 2009 19:21:04 +0000 (UTC) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by smtpfb1-g21.free.fr (Postfix) with ESMTP id C988F2DFE5 for ; Sat, 22 Aug 2009 21:02:51 +0200 (CEST) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id 58A344C80DC; Sat, 22 Aug 2009 21:02:43 +0200 (CEST) Received: from kmlaptop (blackforest.amc-os.net [88.174.102.207]) by smtp4-g21.free.fr (Postfix) with SMTP id 5B51A4C810D; Sat, 22 Aug 2009 21:02:41 +0200 (CEST) Message-ID: From: "Aurlien Mr" To: "Alexander Leidinger" , "Marc Balmer" References: <6101e8c40908211917k69c82491w3cff00a527d14873@mail.gmail.com><19e9a5dc0908212303j28a6913er604bfd06e7df81ec@mail.gmail.com><2DC22872-96F5-4C0A-82E4-F9755A10E245@msys.ch> <20090822182923.000064e0@unknown> Date: Sat, 22 Aug 2009 21:02:32 +0200 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18005 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 X-RFC2646: Format=Flowed; Original X-Mailman-Approved-At: Sat, 22 Aug 2009 20:44:20 +0000 Cc: freebsd-hackers@FreeBSD.org, Gonzalo Nemmi , Oliver Pinter Subject: Re: Common interface for sensors/health monitoring 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, 22 Aug 2009 19:21:06 -0000 >> The OpenBSD sensors framework lacks some desireable features, e.g. >> event capabilities like getting an event if a certain threshold is >> exceeded. And it propbably was used for things that it better had > > This assumes the kernel is monitoring the device periodically (in the > general case, as there are a lot of dump sensors which do not send > events on their own). The framework as in the SoC did not provide this > feature to keep the kernel part simple. You want to see a value, you > poll the kernel for it, and the userland would have been responsible to > fire up an event. In my pratical case, this is perfectly satisfying. Probably most of the controllers I work with don't even support event triggering, and we already have the scripts to trigger events depending on the polled values. I'm worried that today drivers don't exist or don't seem to be maintained to provide these values. So, I would be satisfied just by getting the values. I would be very satisfied if it was in a common interface. Heaven with triggers... I'm just afraid by reading your email that the situation doesn't seem to have evolved since the discussion regarding the SoC, maybe even more taboo, and that I'll have to keep writing my own software and drivers to get the data I want in the future if I want to get this data under FreeBSD.. Is it the case ? Thx Aurlien