Re: Qemu and audio input?
On Sun, Jun 17, 2012 at 9:43 PM, Alexandre Ratchov a...@caoua.org wrote: On Thu, Jun 14, 2012 at 12:54:49PM +0200, Tomas Bodzar wrote: Hi all, have someone working audio input with Qemu on OpenBSD? IIRC, sdl is play-only. Adding a sndio backend could add record-only support (and possibly better play-only support as well). Qemu is not weired so writing one wouldn't be very complicated. But see below. qemu-system-i386 -audio-help shows that there are two drivers available (sdl and wav), but both states 'Does not support capture'. In Windows 7 guest it shows mic device, but I used qemu-system-i386 -soundhw hda . so it's just presented or is that really working? Can find things like this https://www.redhat.com/archives/libvir-list/2011-January/msg00335.html , but there is not hda-duplex in OpenBSD Qemu and searching in archives doesn't return results yet either. Any tips? Full-duplex is different. Qemu emulates a eap(4) device, ie pci audio device that does DMA block by block. The N-th block in the record stream is recorded while the N-th block of the play stream is played. That's what any software on the gest would expect. Obviously, this can't work because the host requires some buffering as well. So there's no way to get full-duplex audio in a emulator that uses a eap(4) style device as model for audio. Unless we let play and record streams out of sync, in which case full-duplex won't be very useful. If so it's easier to emulate two devices, one for playback and one for recording. The same applies to synchronization, e.g., audio-video synchronization in the case of a play-only device in the guest. What do you try to do? If audio input/output will be working then it's possible to use Microsoft Office Communicator and/or Lync for Live meetings. Just idea for now as it can end quite complicated. But in same time it probably means that support for audio input is missing in more ports/apps, right? -- Alexandre
Re: OpenBSD forked
On 18 June 2012 15:46, Raymond Lillard rlill...@sonic.net wrote: On 06/17/2012 12:31 PM, Peter J. Philipp wrote: Having followed OpenBSD for quite some time I noticed that good developers come and go. They come in, make something great happen, and disappear again. Also there have been forks and I also noticed that no fork gets a light judgment. Rightfully so. And then I always appreciated the permanent element in OpenBSD that guides our attention to areas we as users and sideliners don't always see immediately. I'll keep buying CD's when available and I do donations here and there when I feel like it, and I don't regret it. ditto. I almost always remain silent in political matters, (relating to OpenBSD that is). I will list some reasons why I am not going anywhere soon for a free OS. I have been using, donating hardware and purchasing CDs since 3.0. Reason 1: Legacy Architectures I have many legacy machines in service because they can be acquired for next to free (sometimes just free). These legacy machines are very good at exposing subtle bugs not found by compiling and running on Intel/AMD hardware. Since these legacy architectures are strange in the i386/AMD64 context, exploiters are unlikely to bother with them. None of my Internet facing machines are on popular architectures. I have seen attackers come and leave as soon as they figure out what they are up against. The combination of OpenBSD and uncommon architectures is a very tough nut to crack. Reason 2: Security This is an unknown. All FOSS claims to be free, fast and secure. Even Microsoft claims to be secure. Maybe the new team will be as fanatical as Theo, likely not if their FAQ is to be believed. Their reputation for security will be revealed with the passage of time. Reason 3: Crypto I don't know where the new project is located, but they seem to have a server in Southfield, MI USA and another in Denmark. I hope none of the developers is subject to US export laws regarding cryptography and that the code is maintained on servers also not subject to those laws. Just look at the recent MegaUpLoad case. That case is reportedly about a bunch of ripped off movies. I have googled a bit and have not found a physical location for the project or its code. Reason 4: Stability The new project FAQ states they intend to be less restrictive with the codebase when it comes to experimenting with features. Maybe in the long run some of the new features may be introduced into OBSD, but in the near term I expect much instability given the broad range of deeply embedded things they intend to change. Reason 1 is a big problem for me and my crusty old war horses. Reasons 2 3 may be unfounded, the secrecy here (there are no developer names listed on the project web site) is not very confidence building. As to reason 4, I am only mildly interested in fast. I want correct and stable execution above all else. For this reason I expect to continue with OBSD for a long time. I do have considerable sympathy for clearing GNU out of the code base though. Now going back into lurker mode. Regards, Ray The secretive nature is concerning. But I hope that this situation can somehow turn out to be beneficial to both projects in the long term. As long as my favourite and most relied upon OS continues to evolve, I will be happy. And I will certainly continue to buy from and donate to the OpenBSD project where possible. Shane
Re: OpenBSD forked
The secretive nature is concerning. But I hope that this situation can somehow turn out to be beneficial to both projects in the long term. As long as my favourite and most relied upon OS continues to evolve, I will be happy. And I will certainly continue to buy from and donate to the OpenBSD project where possible. Well let me break some secrets. It is run by Marco Peereboom, and the machines it operators on are associated with the company comformal and their partners. Dale Rahn is in there too. So is Thordur, certain. Owain is involved too, I think. I am certain someone can use their git to find out who they are. Ariane wants to be involved as well, but is still waiting to see how others in the project feel. All of those people work for Marco Peereboom as employees and contractors. They are a US operation.
Re: OpenBSD forked
On 14/06/2012 3:44 AM, Dominguez, Roland wrote: I just came across this article and was wondering if it's legit: http://www.h-online.com/open/news/item/OpenBSD-forked-to-create-Bitrig-161695 4.html Those who do not study history... https://www.bitrig.org/viewgit/?a=viewblobp=bitrigh=59fc82dbaf7eaff6cf9ee6aa607951587f5d6d7fhb=HEADf=usr.bin/banner/banner.1
Re: pf-smp alpha on freebsd
On Jun 17, 2012, at 7:53 PM, Ted Unangst wrote: On Sun, Jun 17, 2012 at 11:43, Holger Glaess wrote: i dident wont start about smp on openbsd but what about this porject ? Did you read the part below? I think it's pretty clear this project isn't going to have much relevance for OpenBSD. From the very beginning of the project it was clear, that code is going to diverge significantly from original OpenBSD code. OpenBSD has always developed pf without taking into account that code can ever get multithreaded, thus quite a lot needed to be changed. Thus, I've started with removing the #ifdef __FreeBSD__ from the code, and later I didn't hesitate even a fraction of second if I wanted to toss some code. The pros is that now code is much more readable and understandible then in head, the cons is that diff between us and OpenBSD is huge, although amount of shared code is huge, too. So, later on only manual merging of features from OpenBSD is possible and bulk imports of entire pf into FreeBSD are no longer possible. This sounds like a messy decision. Is this single-mutex stuff in pf true for OpenBSD as of now or a port quirk of FreeBSD's version? I worked on a heavily multi-threaded firewall core for a few years and I would be glad to help pf itself instead of a 4.5-based pf port going SMP, chasing rainbows and unicorns. Franco
Re: OpenBSD forked
On 2012-06-18 02:46, Raymond Lillard wrote: Reason 4: Stability The new project FAQ states they intend to be less restrictive with the codebase when it comes to experimenting with features. Maybe in the long run some of the new features may be introduced into OBSD, but in the near term I expect much instability given the broad range of deeply embedded things they intend to change. This is very much what I'd expect: they experiment with several features, being not-so-stable most of the the process, but maybe once some of those features mature and become stable enough, they can be ported back to OpenBSD. Their work getting rid of GNU stuff will, inevitably, affect OpenBSD (if they succeed at that anyway). -- Hugo Osvaldo Barrera
Re: OpenBSD forked
yes. some more, some less. The feature argument - surely any barriers there must mean that that ideal goes against everything OpenBSD stands for. I wonder if that's just a developer enticer. I wouldn't mind better ARM support but I don't see why that couldn't be done under the OpenBSD project anyway. From the website atleast, maybe the code says more. I fail to see the reasoning. Why not do something good every day and install BOINC.
Re: OpenBSD forked
Their work getting rid of GNU stuff will, inevitably, affect OpenBSD (if they succeed at that anyway). Hmm, I personally prefer BSD Style licence. For me, BSD Philosophy has much more freedom. NOT Copyleft. ( I love it very much ) I'd like to see more BSD style stuffs coming in. anyway GPL is also doing a good job in the world of Open Source. -- Thank you Indunil Jayasooriya
Re: pf-smp alpha on freebsd
No, there is no single mutex around PF specifically in OpenBSD, the whole kernel is wrapped in a biglock. I think if they work out all the nits and dead-ends we may have something to learn from this effort, but I don't see this code coming back to OpenBSD. It's not critical because they can change the state table implementation later - OpenBSD has reorganised this several times with more planned - but we've put quite a bit of effort into removing hash tables in our kernel wherever possible, partly due to their attackability. My personal preference would be to go with a lockless or lock-on-write RB tree for the state table, but without an SMP-safe network stack there's little motivation to work on such things (though it remains somewhere on my todo list). On Mon, Jun 18, 2012 at 10:06:01AM +0200, Franco Fichtner wrote: On Jun 17, 2012, at 7:53 PM, Ted Unangst wrote: On Sun, Jun 17, 2012 at 11:43, Holger Glaess wrote: i dident wont start about smp on openbsd but what about this porject ? Did you read the part below? I think it's pretty clear this project isn't going to have much relevance for OpenBSD. From the very beginning of the project it was clear, that code is going to diverge significantly from original OpenBSD code. OpenBSD has always developed pf without taking into account that code can ever get multithreaded, thus quite a lot needed to be changed. Thus, I've started with removing the #ifdef __FreeBSD__ from the code, and later I didn't hesitate even a fraction of second if I wanted to toss some code. The pros is that now code is much more readable and understandible then in head, the cons is that diff between us and OpenBSD is huge, although amount of shared code is huge, too. So, later on only manual merging of features from OpenBSD is possible and bulk imports of entire pf into FreeBSD are no longer possible. This sounds like a messy decision. Is this single-mutex stuff in pf true for OpenBSD as of now or a port quirk of FreeBSD's version? I worked on a heavily multi-threaded firewall core for a few years and I would be glad to help pf itself instead of a 4.5-based pf port going SMP, chasing rainbows and unicorns.
Re: pf-smp alpha on freebsd
On Jun 18, 2012, at 11:31 AM, Ryan McBride wrote: No, there is no single mutex around PF specifically in OpenBSD, the whole kernel is wrapped in a biglock. I think if they work out all the nits and dead-ends we may have something to learn from this effort, but I don't see this code coming back to OpenBSD. It's not critical because they can change the state table implementation later - OpenBSD has reorganised this several times with more planned - but we've put quite a bit of effort into removing hash tables in our kernel wherever possible, partly due to their attackability. My personal preference would be to go with a lockless or lock-on-write RB tree for the state table, but without an SMP-safe network stack there's little motivation to work on such things (though it remains somewhere on my todo list). Okay, I've seen practical real world applications with a single-threaded packet capture going into multiple queues for any number of parallel threads. The beauty is going lockless on those multiple queues if you can make sure the same connections always go to the same thread. This, however, is only interesting if you need to go heavy on throughput or processing, namely DPI and friends. It's fairly straight forward from pf's perspective, but I don't know if pfsync may grow more challenging in the process. Hmm, that SMP-safe network stack sounds interesting, too, but IMO this won't help pf as much as the multi-threading. The two would play together for even more scalability, though. Also, I remember having headaches from trying to bounce packets to their designated CPU (soft interrupt context) under Linux to make the distribution queues lockless themselves. SMP-infused network stacks alone won't cut it, if you are going for anything more than raw IP forwarding throughput. Franco
Re: OpenBSD forked
Well. From PC-BSD ,FreeBSD gained much benefit. Hope that might happen here too. Regards, Jay.
Re: acpiac(4) manual page and sensorsd(8)
On Sat, Jun 16, 2012 at 10:24:02PM -0700, Robert Connolly wrote: Hello. The acpiac(4) man page mentions that the AC power source status can be monitored by sensorsd(8), but sensorsd(8) does not monitor this sensor as far as I know. apmd(8) does however. Could the acpiac(4) man page be reworded to reflect this? Thanks hi. i asked mark kettenis about this. his reply: This is incorrect. The acpiac(4) driver provides a sensor that can be monitored by sensorsd(8). Now apmd(8) monitors the power status as well, but this is not done through the sensors framework. so it appears acpiac(4) is correct. jmc
Re: 8-ports serial card compatible with OpenBSD
On Sun, 17 Jun 2012 22:36:55 -0400 Nick Holland n...@holland-consulting.net wrote: On 06/17/12 18:24, Jiri B wrote: Hello, could anybody recommend OpenBSD compatible 8-ports serial card? I'd like to build a small console server. Thank you. jirib So cheap, it's worth a try: http://www.newegg.com/Product/Product.aspx?Item=N82E16815124099 I bought a few of these cards a few years back. They didn't work. Then somewhere around 4.8 or 4.9, support for the chip I had was added, but the older card I had didn't work on anything under than a P4, and even there, it caused a huge interrupt storm, slowed the machine down and drastically increased power consumption. On a P3 or slower system (inc. macppc or sparc64), the system just hung as it spun up the serial ports. Then, somewhere before 5.1, iirc, something fixed that and now it works nicely on anything I've put it in. BUT: This is not the card I ordered. Same vendor, same price point, but the card has clearly been revised. So I can't tell you if THIS card works. I keep getting tempted to buy one, but I also look at the older card still in the box on my shelf...and think...sheesh, when I buy this one, it will be revised a week later, and nothing will be gained by anyone. Nick. We use one from www.visionsystems.de: VSCOM 800H UPCI 8x RS232 16C950 (128Byte FIFO),921kbps + MINIBOX 8 X RS232/DB9 Anschlussbox RS232,8x DB9 puc0 at pci0 dev 7 function 0 VScom 400H/800H rev 0x00: ports: 4 com com3 at puc0 port 0 irq 11: st16650, 32 byte fifo com4 at puc0 port 1 irq 11: st16650, 32 byte fifo com5 at puc0 port 2 irq 11: st16650, 32 byte fifo com6 at puc0 port 3 irq 11: st16650, 32 byte fifo puc1 at pci0 dev 7 function 1 VScom 800H rev 0x00: ports: 4 com com7 at puc1 port 0 irq 11: st16650, 32 byte fifo com8 at puc1 port 1 irq 11: st16650, 32 byte fifo com9 at puc1 port 2 irq 11: st16650, 32 byte fifo com10 at puc1 port 3 irq 11: st16650, 32 byte fifo com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo in an old desktop PC - 2 other machines we tried couldn't cope with it (died or crashed after 2-3 weeks uptime, maybe unrelated though). Alf
Re: OpenBSD forked
NO. GPL IS COUNTER-PRODUCTIVE TO TRUE FREE SOFTWARE. YES, I KNOW I AM SHOUTING. PLEASE EDUCATE YOURSELF ABOUT THE PERVERTED GOALS OF THE FSF. On Mon, Jun 18, 2012, at 02:55 PM, Indunil Jayasooriya wrote: Their work getting rid of GNU stuff will, inevitably, affect OpenBSD (if they succeed at that anyway). Hmm, I personally prefer BSD Style licence. For me, BSD Philosophy has much more freedom. NOT Copyleft. ( I love it very much ) I'd like to see more BSD style stuffs coming in. anyway GPL is also doing a good job in the world of Open Source. -- Thank you Indunil Jayasooriya
Re: OpenBSD forked
speaking of stuck CAPSLOCK, anyone else having DEL/INS problems on US keyboards w/ Euro key on 5? They're cheapo USB Dell manufactured by Logitech. Tweaking wscons flags didn't help (not running X11); should I remap keys individually? -- p NO. GPL IS COUNTER-PRODUCTIVE TO TRUE FREE SOFTWARE. YES, I KNOW I AM SHOUTING. PLEASE EDUCATE YOURSELF ABOUT THE PERVERTED GOALS OF THE FSF. On Mon, Jun 18, 2012, at 02:55 PM, Indunil Jayasooriya wrote: Their work getting rid of GNU stuff will, inevitably, affect OpenBSD (if they succeed at that anyway). Hmm, I personally prefer BSD Style licence. For me, BSD Philosophy has much more freedom. NOT Copyleft. ( I love it very much ) I'd like to see more BSD style stuffs coming in. anyway GPL is also doing a good job in the world of Open Source. -- Thank you Indunil Jayasooriya
acpitz critical temperature is too high
Hello. During boot I see: acpitz0 at acpi0: critical temperature is 200 degC The acpitz(4) man page mentions that the system will power down if this critical temperature is reached. I assume this temperature is retrieved from BIOS, but I do not have an option in BIOS setup for it. Can I hard code this temperature in sys/dev/acpi/acpitz.c to a saner number? If so, it looks like I need to define sc-sc_crt, or possibly _CRT. Or is there another way to do this? Thanks
Re: acpitz critical temperature is too high
On Mon, Jun 18, 2012 at 06:35:58AM -0700, Robert Connolly wrote: Hello. During boot I see: acpitz0 at acpi0: critical temperature is 200 degC The acpitz(4) man page mentions that the system will power down if this critical temperature is reached. I assume this temperature is retrieved from BIOS, but I do not have an option in BIOS setup for it. Can I hard code this temperature in sys/dev/acpi/acpitz.c to a saner number? If so, it looks like I need to define sc-sc_crt, or possibly _CRT. Or is there another way to do this? Thanks Why do you want to do this? -ml
Story behind PCC's removal?
So, from what I can tell, PCC has been removed from the core tree. I have not been able to find the story behind why it was moved out, except some minor mention of a lack of maintainer? Is there still any active effort to move the code base of OpenBSD away from GCC dependence? -- Aaron W. Hsu | arcf...@sacrideo.us | http://www.sacrideo.us Programming is just another word for the lost art of thinking.
Re: CVE-2012-0217: SYSRET 64-bit operating system privilege escalation vulnerability on Intel CPU hardware
On Wed, Jun 13, 2012 at 12:54 AM, Philip Guenther guent...@gmail.com wrote: On Tuesday, June 12, 2012, bj.perso wrote: FreeBSD and NetBSD seem affected, how about OpenBSD ? Nope. The necessary check(s) for setting bogus return addresses has been in place since, uh, 2004. Ditto for always returning from signal handlers using iretq instead of sysretq. To correct and clarify: while the bogus return address checks date back to 2004, the return from signal handler path wasn't *forced* to use iretq until OpenBSD 5.0. Previous versions used iretq normally, but manually written code could force it to use sysretq and trigger this issue. (Thank you to Rafal Wojtczuk for the original discussion and for catching my misleading note above.) So, if you're still running and64 OpenBSD 4.9 or earlier on Intel hardware, you need to upgrade. (Thanks, Intel, for screwing this up.) Philip Guenther
Nitpick: typo in mv(1) man page
$ diff mv.1.new mv.1 79c79 when the respective destination path is a non-empty directory, --- when the respective destination path is a non-empy directory, -- Scott McEachern https://www.blackstaff.ca
libemu compilation
Trying to compile libemu (http://libemu.carnivore.it/) on 5.1. Make all breaks at: gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I ../.. -Werror -Wall -g -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGE_FILES -g -O2 -Wstrict-prototypes -MT scprofiler.o -MD -MP -MF .deps/scprofiler.Tpo -c -o scprofiler.o scprofiler.c cc1: warnings being treated as errors In file included from scprofiler.c:50: /usr/include/arpa/inet.h:74: warning: 'struct in_addr' declared inside parameter list /usr/include/arpa/inet.h:74: warning: its scope is only this definition or declaration, which is probably not what you want /usr/include/arpa/inet.h:75: warning: 'struct in_addr' declared inside parameter list *** Error code 1 Stop in /root/libemu/testsuite (line 92 of /usr/share/mk/sys.mk). *** Error code 1 Stop in /root/libemu (line 375 of Makefile). *** Error code 1 Stop in /root/libemu (line 260 of Makefile). Tried to go forward with CC=gcc -Werror make, but that didn't work. Just curious if there's any way to proceed. Pointers (ahem :)) appreciated. -- http://www.glumbert.com/media/shift http://www.youtube.com/watch?v=tGvHNNOLnCk This officer's men seem to follow him merely out of idle curiosity. -- Sandhurst officer cadet evaluation. Securing an environment of Windows platforms from abuse - external or internal - is akin to trying to install sprinklers in a fireworks factory where smoking on the job is permitted. -- Gene Spafford learn french: http://www.youtube.com/watch?v=30v_g83VHK4
Re: libemu compilation
Nevermind. Disabled the flags in the Makefile and I was done. -- http://www.glumbert.com/media/shift http://www.youtube.com/watch?v=tGvHNNOLnCk This officer's men seem to follow him merely out of idle curiosity. -- Sandhurst officer cadet evaluation. Securing an environment of Windows platforms from abuse - external or internal - is akin to trying to install sprinklers in a fireworks factory where smoking on the job is permitted. -- Gene Spafford learn french: http://www.youtube.com/watch?v=30v_g83VHK4
Re: Nitpick: typo in mv(1) man page
On 06/18/12 14:44, Scott McEachern wrote: $ diff mv.1.new mv.1 79c79 when the respective destination path is a non-empty directory, --- when the respective destination path is a non-empy directory, Erm, sorry 'about that... $ diff -u mv.1 mv.1.new --- mv.1Wed Jun 6 14:22:11 2012 +++ mv.1.newMon Jun 18 15:11:35 2012 @@ -76,7 +76,7 @@ In both forms, a .Ar source operand is skipped with an error message -when the respective destination path is a non-empy directory, +when the respective destination path is a non-empty directory, or when the source is a non-directory file but the destination path is a directory, or vice versa. .Pp -- Scott McEachern https://www.blackstaff.ca
Re: libemu compilation
bofh wrote: Nevermind. Disabled the flags in the Makefile and I was done. Sounds like you're ignoring the problem which is usually a bad thing to do. You're probably missing a header, or possibly the sequencing of the header files is wrong. (inet(3) may help)
Re: libemu compilation
On 2012-06-18, bofh goodb...@gmail.com wrote: Trying to compile libemu (http://libemu.carnivore.it/) on 5.1. Make all breaks at: gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I ../.. -Werror -Wall -g -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGE_FILES -g -O2 -Wstrict-prototypes -MT scprofiler.o -MD -MP -MF .deps/scprofiler.Tpo -c -o scprofiler.o scprofiler.c cc1: warnings being treated as errors In file included from scprofiler.c:50: /usr/include/arpa/inet.h:74: warning: 'struct in_addr' declared inside parameter list missing header. it's going to need most or all of these: sys/types.h sys/socket.h netinet/in.h arpa/inet.h
Re: Story behind PCC's removal?
On 2012 Jun 18 (Mon) at 17:16:25 + (+), Aaron W. Hsu wrote: :lack of maintainer That is exactly the case. Nobody actually did the work make it rock our socks. -- Shaw's Principle: Build a system that even a fool can use, and only a fool will want to use it.
Re: Story behind PCC's removal?
That' sad - who got lost? STEFAN Gesendet: Montag, 18. Juni 2012 um 23:44 Uhr Von: Peter Hessler phess...@theapt.org An: Aaron W. Hsu arcf...@sacrideo.us Cc: misc@openbsd.org Betreff: Re: Story behind PCC's removal? On 2012 Jun 18 (Mon) at 17:16:25 + (+), Aaron W. Hsu wrote: :lack of maintainer That is exactly the case. Nobody actually did the work make it rock our socks. -- Shaw's Principle: Build a system that even a fool can use, and only a fool will want to use it.
Re: Nitpick: typo in mv(1) man page
Committed, thanks! On Mon, Jun 18, 2012 at 12:35 PM, Scott McEachern sc...@blackstaff.ca wrote: On 06/18/12 14:44, Scott McEachern wrote: $ diff mv.1.new mv.1 79c79 when the respective destination path is a non-empty directory, --- when the respective destination path is a non-empy directory, Erm, sorry 'about that... $ diff -u mv.1 mv.1.new --- mv.1 Wed Jun 6 14:22:11 2012 +++ mv.1.new Mon Jun 18 15:11:35 2012 @@ -76,7 +76,7 @@ In both forms, a .Ar source operand is skipped with an error message -when the respective destination path is a non-empy directory, +when the respective destination path is a non-empty directory, or when the source is a non-directory file but the destination path is a directory, or vice versa. .Pp -- Scott McEachern https://www.blackstaff.ca
Re: Story behind PCC's removal?
On Mon, Jun 18, 2012 at 10:16 AM, Aaron W. Hsu arcf...@sacrideo.us wrote: Is there still any active effort to move the code base of OpenBSD away from GCC dependence? There's some grassroots effort to make Clang a viable option, but nothing super organized at the moment.
Re: OpenBSD forked
geez, it's a /segway/ -- p Dont steal the thread. On Jun 18, 2012 9:55 AM, Peter Laufenberg open...@laufenberg.ch wrote: speaking of stuck CAPSLOCK, anyone else having DEL/INS problems on US keyboards w/ Euro key on 5? They're cheapo USB Dell manufactured by Logitech. Tweaking wscons flags didn't help (not running X11); should I remap keys individually? -- p NO. GPL IS COUNTER-PRODUCTIVE TO TRUE FREE SOFTWARE. YES, I KNOW I AM SHOUTING. PLEASE EDUCATE YOURSELF ABOUT THE PERVERTED GOALS OF THE FSF. On Mon, Jun 18, 2012, at 02:55 PM, Indunil Jayasooriya wrote: Their work getting rid of GNU stuff will, inevitably, affect OpenBSD (if they succeed at that anyway). Hmm, I personally prefer BSD Style licence. For me, BSD Philosophy has much more freedom. NOT Copyleft. ( I love it very much ) I'd like to see more BSD style stuffs coming in. anyway GPL is also doing a good job in the world of Open Source. -- Thank you Indunil Jayasooriya
Re: acpitz critical temperature is too high
I want to initiate a shutdown if the temperature gets too high. I have been using sensorsd(8), but sensorsd(8) only reacts once to the high (or low) event, leaving it up to the program/script to run timers to keep checking if the temperature gets worse. For my satisfaction, the timers would have to keep running until the system cooled down below the high temperature, so that sensorsd(8) will pick up the monitoring from there. When the temperature gets to a warning level, I would like sensorsd(8) to notify logged in users (me), mail root, step down the CPU with apm -L, and then let the kernel do a shutdown, with acpitz(4), if the temperature continues to rise to critical. This would be easier and more simple for me than using sensorsd(8) alone (no timers). I checked this out a little bit today. Some laptop manufacturers release Windows programs to control these temperature settings. I don't know if the setting is permanent/saved in BIOS, but if it is then I could run it from a Windows Livecd to reset the critical temperature. Another idea was installing Coreboot (free-bios), but I doubt my mainboard is supported, and it could brick my system. Or, configure the OpenBSD kernel to ignore the BIOS setting, and use my hard coded temperature instead. Or, use sensorsd(8) and a script. On Mon, Jun 18, 2012 at 9:35 AM, Mike Larkin mlar...@azathoth.net wrote: On Mon, Jun 18, 2012 at 06:35:58AM -0700, Robert Connolly wrote: Hello. During boot I see: acpitz0 at acpi0: critical temperature is 200 degC The acpitz(4) man page mentions that the system will power down if this critical temperature is reached. I assume this temperature is retrieved from BIOS, but I do not have an option in BIOS setup for it. Can I hard code this temperature in sys/dev/acpi/acpitz.c to a saner number? If so, it looks like I need to define sc-sc_crt, or possibly _CRT. Or is there another way to do this? Thanks Why do you want to do this? -ml
Re: errors compiling webkit on lemote
My loongson patches didn't make 5.1 so either run -current (recommended) or backport my patches to 5.1 Either way, you won't get JavaScript, so please keep that in mind (or help me out! :) ) ~Brian
Re: acpitz critical temperature is too high
How about setting low to the warning level, and high to the shutdown level? That way you should be able to handle all 3 states w/o timers. below being normal, within where it notifies and steps down CPU and above where it does shutdown. 2012/6/19 Robert Connolly robertconnolly1...@gmail.com I want to initiate a shutdown if the temperature gets too high. I have been using sensorsd(8), but sensorsd(8) only reacts once to the high (or low) event, leaving it up to the program/script to run timers to keep checking if the temperature gets worse. For my satisfaction, the timers would have to keep running until the system cooled down below the high temperature, so that sensorsd(8) will pick up the monitoring from there. When the temperature gets to a warning level, I would like sensorsd(8) to notify logged in users (me), mail root, step down the CPU with apm -L, and then let the kernel do a shutdown, with acpitz(4), if the temperature continues to rise to critical. This would be easier and more simple for me than using sensorsd(8) alone (no timers). I checked this out a little bit today. Some laptop manufacturers release Windows programs to control these temperature settings. I don't know if the setting is permanent/saved in BIOS, but if it is then I could run it from a Windows Livecd to reset the critical temperature. Another idea was installing Coreboot (free-bios), but I doubt my mainboard is supported, and it could brick my system. Or, configure the OpenBSD kernel to ignore the BIOS setting, and use my hard coded temperature instead. Or, use sensorsd(8) and a script. On Mon, Jun 18, 2012 at 9:35 AM, Mike Larkin mlar...@azathoth.net wrote: On Mon, Jun 18, 2012 at 06:35:58AM -0700, Robert Connolly wrote: Hello. During boot I see: acpitz0 at acpi0: critical temperature is 200 degC The acpitz(4) man page mentions that the system will power down if this critical temperature is reached. I assume this temperature is retrieved from BIOS, but I do not have an option in BIOS setup for it. Can I hard code this temperature in sys/dev/acpi/acpitz.c to a saner number? If so, it looks like I need to define sc-sc_crt, or possibly _CRT. Or is there another way to do this? Thanks Why do you want to do this? -ml
misayukiunk【有】【票】hpjm【开】kjl【1】
æ¨å¥½misayuki æå ¬å¸æ¯ææä¸å®æ°é¢ç å ç¨è½¦ç¥¨å¯èµ°å¯¹è½¦å¤ç°ä»£èµ°å¼, å¦è´µå ¬å¸ææ¤é è¦, æå ¬å¸å° ç«è¯ä¸ºæ¨æèµ°å¡ã ç¨è½¦ç¹ä»ä¼ï¼æ¬¢è¿æ¥çµå¨è¯¢ã ＱＱ: 815821020 å¼ å¾·æ çµè¯ :l35 3O75 9889 11:19:21
Re: acpitz critical temperature is too high
sensorsd(8)'s low goes in the other direction. If I set low to 60C, it will go off if the CPU is running at 50C. Sensorsd(8) isn't made for such fine control as some of us would like. If the battery is low, we want the sensor to alert us. If the temperature is low, we do not want to be alerted. So a medium setting simply wouldn't work with the way sensorsd(8) works. Furthermore, I checked out Windows and Acer software, and I don't see a way of resetting the BIOS critical temperature. They use daemons, and so my kernel hack option to take advantage of acpitz(4) looks like a good idea. On Mon, Jun 18, 2012 at 8:05 PM, Artturi Alm artturi@gmail.com wrote: How about setting low to the warning level, and high to the shutdown level? That way you should be able to handle all 3 states w/o timers. below being normal, within where it notifies and steps down CPU and above where it does shutdown.
