Re: Override default ICMP (and other protocols) default replies.
Am 20.08.2008 um 19:27 schrieb Javier Ubillos: Hi freebsd-hackers. (Sorry for cross posting, but I got no reply when posting to freebsd-questions) I'm implementing a NAT (1 ip - 1 ip) like router. I have chosen to use pcaplib to pick up the packets. I have an implementation which picks up the packets, inspects them, rewrites the destination/source ip-addresses and sends them out on the repective interface. The problem I'm facing however is that my interfaces are answering to e.g. icmp-echo (ping) automatically, and I don't know how to turn this behaviour off. What I want to happen is that if A pings C, my router B in between should simply forward the packets w/o any automatic reactions. A --> B --> C So that if e.g. C is down, no echo-reply is sent back (or if C is up, that C is actually sending the echo-reply. Does any one know how to turn off the automatic replies (ICMP and whatever else I haven't forseen yet) or does any one know where I can find out more about the issue? bpf, which libpcap uses, gives you a copy of the received packet, so the kernel will process it. Typically, if you want to process packets before the host sees them, you'd use ipfw(4) and a divert(4) socket, like natd(8) does. This allows you to modify any packet entering the system, modify it, and (if appropriate) reinject it into the stack. You can also configure your own tun(4) interface to get packets out of the kernel and process them, which might be ideal if you want to process all traffic for an IP. And finally, unless you have really weird requirements, ipfw or pf rules will likely work without any special programming. HTH, Stefan -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kldfind
Am 16.05.2006 um 23:15 schrieb Ricardo A. Reis: I writed one script for find freebsd kernel modules, ... [EMAIL PROTECTED]:~/kldfind] # ./kldfind -h Options: -c-- find all matchs for category -s-- string match ... http://ricardo.epm.br/freebsd/script/ It's a nice little script, but I think it can be improved in a few aspects. Just off the top of my head: Exit codes: plase see sysexits(3) for a number of well-defined exit codes and their meanings. If your script is invoked with the -c or -s switch, but no search term was provided, help() will exit with 0; EX_USAGE (64) would be more appropriate. Options handling: FreeBSD (and Posix) provide getopt(1) for options processing; while your script doesn't use options as such (-c, -h, and -s are really sub-commands, not options here), it's probably worthwile to use the standard functionality anyway. Functionality: inside the loop in search(), the sleep is superflous. Also, using exit inside the loop will terminate the script. With the current construction, only the first component of the KLD search path will ever be searched. It is debatable whether not finding any matching modules should be an error. Output format: there's no easy way to post-process the search results with a script. A pretty print version of the output is nice, but for a system utility, the default should be something that can be easily post-processed with another script. Stefan -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: On the use of Tun interfaces.
Am 18.07.2006 um 06:39 schrieb David Gilbert: [3:15:[EMAIL PROTECTED]:~/devel/failsafe> netstat -rn ... 192.168.22.1 192.168.12.2 UH 00 tun0 shouldn't the last route there be active? Any clues here? The last time I tried to get a tun interface set up (admittedly, back in 2.2 days), I had similiar problems with weird routing entries. IIRC, when configuring the tun interface, I failed to initialize all sockaddr's properly. The interface looked right, but the routes were botched. memset took care of it then. HTH, Stefan -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: get DMI information in kernel
Am 22.08.2006 um 14:45 schrieb [EMAIL PROTECTED]: How do i get DMI Informations (stuff displayed by dmidecode) in a kernel module? I need some "System Information" like Vendor,Model and OEM String identifying hardware on a Thinkpad. kenv(2) has smbios entries; they're available through getenv() and getenv_() in the kernel. See http://www.freebsd.org/cgi/ cvsweb.cgi/src/sys/boot/i386/libi386/smbios.c for the history. Stefan -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can anybody terminate an IP-IP tunnel for me?
Am 08.06.2007 um 05:41 schrieb Greg 'groggy' Lehey: How do I terminate the IP-IP tunnel at my end? I'm using OpenVPN for similar porposes, albeit on lower latency DSL links. OpenVPN can run over UDP or TCP, and can work through NAT, and even with dynamic IPs. Stefan -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can anybody terminate an IP-IP tunnel for me?
Am 08.06.2007 um 17:47 schrieb Oliver Fromme: While OpenVPN works well usually, it is generally not advisable to run it over TCP, especially if your link is not guaranteed to have 0% packet loss, which might be the case for satellite links. Running OpenVPN over UDP is fine. Sure, but slightly less than perfect connectivity is still better than none: being stuck on a corporate network, where you can use the proxy to establish a TCP connection to port 443, for example. Stefan -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Solaris 10 zones / jails
Just picked this announcement up from /.: <http://groups.google.com/groups? selm=c1j796%2424c%241%40news1nwk.SFbay.Sun.COM&oe=UTF-8&output=gplain> Apparently, it is conceptually similiar to FreeBSD jails, but has slightly more advanced configuration management. Maybe some incentive for an enterprising hacker to move our implementation forward in that respect as well... Stefan -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to write a new line discipline?
Am 16.03.2004 um 06:59 schrieb Daniel O'Connor: The current disciplines seem to be either very very old, or 'hacks' for things like PPP or SLIP :( In another life, I put together a small line discipline to "talk" to dumb UPSes that signal via DTR and RTS, and can be shut down via DSR or CTS. This was in the 2.2 timeframe, so I doubt this will be of much use to you, but here it is anyway: <http://ftp.hanse.de/pub/people/stefan.bethke/FreeBSD/dumb_ups -0.01.tar.gz> Stefan -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kmem_malloc crashes running FreeBSD 5.2.1-RELEASE-p5
Am 29.04.2004 um 02:01 schrieb Kris Kennaway: On Wed, Apr 28, 2004 at 02:40:38PM -0700, John Uhlig wrote: On the web, freebsd mailing lists and bug lists, I have seen existing thread about "kmem_malloc and kmem_map too small" problems - but no evidence of a fix or patch. We experienced the same problem running 4.9 but were able to fix it by setting the MAXMEM option in our kernel conf file to a value 1GB less than actual physical memory size. This does not help with 5.2.1-RELEASE-p5. See PR 53416. You just need to tune your kernel resource allocation to deal with the large amount of memory your system has. I recently enquired about advice for this exact situation on -current (see http://lists.freebsd.org/pipermail/freebsd-current/2004-April/ 026065.html), but didn't really get any. The PR does not give advice on which parameters in which way, or list a solution. My own experimentation has been inconclusive; the machine still panics when running the daily scripts. I'm running a cron job every minute to record various vm statistics now; hopefully this will give me further pointers. How does PAE affect this? My box has 6 GB, but I have disabled PAE for the moment. And just for clarification: the panic is with basically no load, just some file system pressure (two jails running the daily scripts); otherwise, the machine is unused. Stefan -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kmem_malloc crashes running FreeBSD 5.2.1-RELEASE-p5
Am 04.05.2004 um 01:11 schrieb Kris Kennaway: I'm pretty sure it's just a matter of the right tuning. All I needed to do was to add this on my heavily loaded 4GB machine: options VM_KMEM_SIZE_MAX=419430400 #400MB Thanks, that appears to have resolved the issue. I encountered no more panics even with heavy cvs up and ports builds in multiple jails simultaneously. -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ata_catch_inflight causes boot freeze
Am 16.01.2005 um 05:11 schrieb Kris Maglione: On my laptop, while the call to ata_catch_inflight is in dev/ata/ata-all.c, my laptop freezes at boot, after detecting acd0 and doing GEOM: Configure for ad0. I don't mind commenting out the line in my builds, but others shouldn't have to go through what I did to come to the same conclusion (building the kernel from various dates and burning it to a FreesBIE CD). Anyway, I'm not familiar enought with the kernel archetecture to figure out why the function causes a boot freeze. I only figured out that it did by reviewing commits between the dates that it worked and the dates that it didn't. I'm willing to provide whatever information/help that I can to come up with a more permanent solution. Just so this doesn't get lost, you might want to open a PR, including the exact commit that you think introduced this. You also might want to drop a note to Søren (sos@), author of much of the ATA code. Stefan -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IBM Active Protection System Approach
Am 22.08.2005 um 17:26 schrieb Søren Schmidt: On 22/08/2005, at 10:08, [EMAIL PROTECTED] wrote: what would be the best approach to implement aps on FreeBSD? I got an Accelerometer driver which will deliver data. First Version is available at https://sourceforge.net/project/showfiles.php? group_id=138242&package_id=160977 We have to poll the device for information quiet often to detect a possible shock early enough to park disk drive heads. Urhm, what type of "accidents" is it we want to protect against here ? It will take several tens of mS to get the heads parked if not hundreds, and the worst case scenario would be that the "accident" will happen just as the heads are on the way to the parking zone which would *really* destroy data on there, unless the disk has special HW to just quickly lift the heads or something. I have no insight into either IBM's or Apple's implementation, but I've read that they both rely on detecting the machine being in freefall, or similar acceleration states, as a cue to have the HD park the heads before a possible impact. Early reports from Mac enthusiast sites (and I believe similar reports from IBM users) indicate that the hysteresis is so small that gently pounding the table the notebook is sitting on will make the drive park the heads, and lead to 10 to 20 seconds delay before the drive can be accessed again. Given how tightly coupled mechanically the HD in most notebooks is to it's shell, it seems a very good idea to pursue. If you have access to a new(ish) PowerBook, I recommend checking out http://www.kernelthread.com/software/ams/. The sensitivity of the accelerometer is truely astounding. (For those who haven't seen it: you turn the notebook, and the demo window is turned so it stays level. It takes *really* small movements to confuse the system.) Stefan -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: increasing dd disk to disk transfer rate
Am 13.01.2006 um 14:29 schrieb Christoph P. Kukulies: Just for the record: Before I wanted to give back in my faulty disk to my computer supplier as a case for warranty, I zeroed out the faulty disk. dd if=/dev/zero of=/dev/ad2 bs=1m It took half an hour to zero out the 80GB. Transferrate 44 MB/s? And not a single error ? Or is this normal? Depending on the model, 44 MB/s seems quite OK. Certainly on the fast side for a 2.5" laptop drive, but not unheard of these days. It is quite possible that the disk controller had a couple of sectors it could not read anymore (and giving I/O errors for them), but was able to reallocate once you wrote to them. I would still ditch the disk, though. Would be interesting to see what the smart reallocated sector count says. Stefan -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] Fancy rc startup style RFC
Am 18.04.2006 um 22:56 schrieb Eric Anderson: Anish Mistry wrote: If I could figure out how to make sh do colors, I'd do it. :) Is that all? :) #!/bin/sh # Nico Golde Homepage: http://www.ngolde.de # Last change: Mon Feb 16 16:24:41 CET 2004 for attr in 0 1 4 5 7 ; do echo "" printf "ESC[%s;Foreground;Background - \n" $attr for fore in 30 31 32 33 34 35 36 37; do for back in 40 41 42 43 44 45 46 47; do printf '\033[%s;%s;%sm %02s;%02s ' $attr $fore $back $fore $back done printf '\n' done printf '\033[0m' done But can you do it without the printf's? That's the key. We don't have printf until later in the boot process.. echo -e is your friend, see sh(1). $ echo -e '\e[0;32;46m' gives green on cyan in my xterm. Stefan -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jumpstart for freebsd.
Am Donnerstag, 13.03.03, um 20:46 Uhr (Europe/Berlin) schrieb Anshuman Kanwar: I've spent most of last year automating the installation of FreeBSD systems at my workplace. [...] As a result of all the above, I wrote a set of perl scripts that do a very similar job for FreeBSD. [...] If there is any interest in this work, I will be more than happy to see it become one of the ways of installing FreeBSD. Of course, some modifications would be required to make these scripts more generic, robust and user friendly. The questions I have are: 1) Is this duplication of any prev. work ? Can't speak to that, although I'm certain that many shops have custom scripts to do this. 2) If no then how should I go about trying to integrate the code into FreeBSD? You should try to create a port for it. The Porter's Handbook explains how to do that. http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/ index.html Also, you might want to compare your approach compares to FreeBSD From Scratch: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/fbsd-from-scratch/ index.html Stefan -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: more gpart/glabel problems
Am 14.01.2011 um 11:37 schrieb Daniel Braniss: > now: > glabel lable r0 mfid0 > so what am I doing wrong? glabel uses the last sector of the device to store the label. GPT keeps it's backup table there. Additionally, GEOM then tastes the glabel device, and the size of the glabel device (label/r0) does not agree with the GPT table, since it's one sector smaller than the device that you created the GPT table on. Are you trying to label the entire array, or individual partitions? If you want to label the entire device, do that first, and then create the GPT table on the label device. If you want to label individual partitions, then use the gpart label options, or newfs options. Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
iotop (dtrace?)
I've got two systems with a constantly high rate of disk I/O that sometimes seems to be overwhelmed from it. Before trying to decide if a hardware upgrade will help, I'd like to figure out which processes generate the load. I've found a couple scripts named iotop which appear to produce what I would be interested in, but they appear to require Solaris or Linux. Has someone ported over one of them, or would have a suggestion how to go about writing a custom dtrace script to gather this kind of information? I can successfully run a couple of sample dtrace scripts on these 8-stable amd64 boxes. Thanks, Stefan Solaris dtrace-based iotop: http://prefetch.net/articles/solaris.dtracetopten.html Linux /proc-based Python script: http://guichaz.free.fr/iotop/ -- Stefan BethkeFon +49 151 14070811 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: iotop (dtrace?)
Am 25.10.2011 um 22:50 schrieb Baptiste Daroussin: > On Tue, Oct 25, 2011 at 10:34:39PM +0200, Stefan Bethke wrote: >> I've got two systems with a constantly high rate of disk I/O that sometimes >> seems to be overwhelmed from it. Before trying to decide if a hardware >> upgrade will help, I'd like to figure out which processes generate the load. >> >> I've found a couple scripts named iotop which appear to produce what I would >> be interested in, but they appear to require Solaris or Linux. >> >> Has someone ported over one of them, or would have a suggestion how to go >> about writing a custom dtrace script to gather this kind of information? >> >> I can successfully run a couple of sample dtrace scripts on these 8-stable >> amd64 boxes. >> > > Can't 'top -mio' do the job? D'oh! Thanks! Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Limiting disk I/O by jail or uid?
I have a process that tends to eat up all available disk bandwidth. I have other processes that I would like to have preference over this one process. Is there a facility that would allow me to assign priorities based on jail ID or uid? This is on 8-stable (but will upgrade to 9 soon) on ZFS. The straightforward solution is to separate the datasets onto their own disks, which I'm planning to do, but a software facility would be that much more flexible. Thanks, Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Limiting disk I/O by jail or uid?
Am 21.11.2011 um 19:32 schrieb Adam Vande More: > On Mon, Nov 21, 2011 at 11:47 AM, Stefan Bethke wrote: > I have a process that tends to eat up all available disk bandwidth. I have > other processes that I would like to have preference over this one process. > Is there a facility that would allow me to assign priorities based on jail ID > or uid? > > This is on 8-stable (but will upgrade to 9 soon) on ZFS. > > The straightforward solution is to separate the datasets onto their own > disks, which I'm planning to do, but a software facility would be that much > more flexible. > > > http://wiki.freebsd.org/Hierarchical_Resource_Limits Interesting, but it doesn't seem to offer limiting the I/O bandwidth induced by a process or jail, or assigning different priorities, which would need to be implemented in the ZFS or GEOM schedulers, I suppose. Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Limiting disk I/O by jail or uid?
Am 21.11.2011 um 21:40 schrieb Adam Vande More: > On Mon, Nov 21, 2011 at 1:58 PM, Stefan Bethke wrote: > > Interesting, but it doesn't seem to offer limiting the I/O bandwidth induced > by a process or jail, or assigning different priorities, which would need to > be implemented in the ZFS or GEOM schedulers, I suppose. > > Limiting CPU has long been the poor man's IO scheduler, and has usually > worked pretty well for me but has required some trial and error. YMMV Good point, I'll give that a try. Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Limiting disk I/O by jail or uid?
Am 21.11.2011 um 21:42 schrieb Stefan Bethke: > Am 21.11.2011 um 21:40 schrieb Adam Vande More: > >> On Mon, Nov 21, 2011 at 1:58 PM, Stefan Bethke wrote: >> >> Interesting, but it doesn't seem to offer limiting the I/O bandwidth induced >> by a process or jail, or assigning different priorities, which would need to >> be implemented in the ZFS or GEOM schedulers, I suppose. >> >> Limiting CPU has long been the poor man's IO scheduler, and has usually >> worked pretty well for me but has required some trial and error. YMMV > > Good point, I'll give that a try. Unfortunately, the process I want to limit is not sufficiently CPU bound to be limited that way vs. all the other processes. I guess I'll put in a second disk. Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Limiting disk I/O by jail or uid?
Am 24.11.2011 um 09:15 schrieb Jason Hellenthal: > > Hi Stefan, > > This is probably what you are looking for. Give it a shot. > > https://jhell.googlecode.com/hg/base/vendor/vehosting/slowdown.c Just tried this: Unfortunately, my app is not slowed down sufficiently. I'm afraid I need something that actually re-prioritizes actual disk I/O. Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: cron(8) mis-feature with @reboot long after system startup
Am 25.11.2011 um 08:02 schrieb Jason Hellenthal: > When using @reboot with cron you expect your proccesses to always start when > the system boots up and only when the system boots. But long after the system > in question had been booted, my @reboot processes ran again! after a > (/etc/rc.d/cron restart). This is normally fine and dandy until one of your > @reboot jobs needs to contain a process that purges files "files that are > already in use by a running daemon since the system has not rebooted" and > becomes hazardous. > > So with that said... is there a way we could actually make this run @reboot > only ? I didn't even know cron had this feature. Why wouldn't you add custom rc.d scripts for these tasks, or add the commands to rc.local? Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: cron(8) mis-feature with @reboot long after system startup
Am 26.11.2011 um 11:54 schrieb Chris Rees: > PLEASE let's not go down the route of that. How long? What if I need to > restart cron shortly after boot? What if boot takes longer? Plus "interesting" time changes during boot due to ntpdate/ntpd. -- Stefan BethkeFon +49 151 14070811 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
TEMPer USB Thermometer
Various outfits including Brando are selling a cheap-ish USB thermometer named “TEMPer”. (I need one to monitor my home server closet.) I've put together a small command line utility that reads out the temperature from the LM75 sensor in the TEMPer: http://wiki.zs64.net/TEMPer_USB_Thermometer To run it, you will need to have the driver for WinChipHead USB-to-serial controller loaded (uchcom(8) on FreeBSD). It puts the LM75 into 12-bit resolution mode (about one measurement per second) and outputs temperature data once per second in degrees Celcius. The LM75 thermostat is connected to an LED, so you can use that as an indicator of temperature. Note that driving the LED dissipates enough power (probably through the current-limiting resistor) that the measured temperature rises by two degrees. usage: temper [-d device] [-h high] [-l low] [-n count] -d device USB serial port of the TEMPer -h high thermostat on temperature -l low thermostat off temperature -n countnumber of readings to take, <0 is infinite If the high temperature is below the low temperature, operation of the thermostat is reversed, and the output is turned on when the measured temperature is below the threshold. Enjoy! Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Metablock caching & negative block #
Zhihui Zhang wrote: > By the way, all other metablocks seem to be delay-written. In other words, > they are not written synchronously. What happens if the system crashes > before their updates go to disk. I read in the mailinglist that FreeBSD > metadata I/O are conservative. Can anyone describe this a little bit for > me. AFAIK, the non-static information in the superblock and others can easily be reconstructed by fsck (the information is gathered anyway). Stefan -- Mühlendamm 12 | Voice +49-40-256848, +49-177-3504009 D-22089 Hamburg | e-mail: stefan.bet...@hanse.de Germany | s...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Seti project / stats reset, new version available
Matthew Dillon wrote: > For people who have idle cpu to spare, this is a good time to start > putting those cycles to good use with the Seti project! The project > has been running a beta test for a while, but as of May 13th 1999 they > reset the stats and introduced new clients for Unix, Windows, and the > Mac. > > I recommend that FreeBSDrs download the FreeBSD3.1 client, even if > you are running 4.x, so our stats do not split up. If you are > already running the seti client, you need to download a new rev! I've just updated the port to v1.1. Beware, however: all versions for FreeBSD try to invoke /usr/lib/sendmail to send mail, instead of /usr/sbin/sendmail. A fix is in the works, or so I am told by the relevant s...@home people. Stefan -- Mühlendamm 12 | Voice +49-40-256848, +49-177-3504009 D-22089 Hamburg | e-mail: stefan.bet...@hanse.de Germany | s...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Seti project / stats reset, new version available
Kris Kennaway wrote:
> On Tue, 18 May 1999, Ueda, Kazukiyo wrote:
>
>> I'm pleased to participate in such cool project. Is anybody kind
>> enough to tell me how to run this program while the FreeBSD box is
>> idle?
>
> Install the astro/setiathome port.
Make sure you have the newest version of the port (for setiathome-1.1).
Pre-1.1 version don't work anymore. Unfortunatly, the release of 1.1 came
too late for the 3.2 CDs. Even more unfortunate is the fact that all
versions (including 1.1) try to send mail by invoking /usr/lib/sendmail...
I guess I'll be changing the port quite rapidly for the next few days as
next version comes out, which is supposed to fix the sendmail as well as
the proxy problem.
> One thing I've been meaning to look at though is that it seems to run it
> at niceness 1, which isn't exactly friendly to the other consumers of
> CPU. You should be able to tweak it easily, though.
Would you suggest a different default nice level, then, and what should it
be?
One can easily modifiy ${PREFIX}/etc/rc.d/setiathome.sh to run it with
-nice 100, and I'm open to making a level other that 1 the default.
Stefan
--
Mühlendamm 12 | Voice +49-40-256848, +49-177-3504009
D-22089 Hamburg | e-mail: stefan.bet...@hanse.de
Germany | s...@freebsd.org
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: ports/astro/setiathome Makefile ports/astro/setiathome/files setiathome.sh setiathome.1 ports/astro/setiathome/pkg INSTALL
[ crossposted to -ports, please follow up to -hackers ] s...@freebsd.org wrote: > - Added support for SMP systems to etc/rc.d/setiathome.sh > - Added etc/setiathome.conf with options to set the nice level, the max. > number of processes to run, the working directory, and the the user id > to run as. > - setiathome.1 was missing from Makefile (and +CONTENTS subsequently) > - Updated the man page to reflect the changes. I've left out idprio(8) for now. If someone could point me to a man page explaining the use of kern.quantum, and when it might be useful to fiddle with that knob, I'll happily add that reference to the setiathome man page. Stefan -- Stefan Bethke Muehlendamm 12Phone: +49-40-256848, +49-177-3504009 D-22087 Hamburg Hamburg, Germany To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: ports/astro/setiathome Makefile ports/astro/setiathome/files setiathome.sh setiathome.1 ports/astro/setiathome/pkg INSTALL
Julian Elischer wrote: > > > On Wed, 19 May 1999, Stefan Bethke wrote: >> >> I've left out idprio(8) for now. >> >> If someone could point me to a man page explaining the use of >> kern.quantum, and when it might be useful to fiddle with that knob, I'll >> happily add that reference to the setiathome man page. > > In 3.2 kern.quantum is set to be teh frequency of how often the kernel > re-evaluates the scheduling. Defualt is 10 (10 times per second). > changing it to 50 > (sysctl -w kern.quantum=50) would make it re-evaluate this more often. > in -current and post 3.2 (as of a few minutes ago) it is > measured as uSeconds thus the default is 10 and the equivalent > new value would be 2. (sysctl -w kern.quantum=2) > > There were various reasons for the change and hopefully few people had > used the (new) kern.quantum feature so the changeover will hopefully > impact few people. Thanks, Julian, but I think _I_ know how it works. Please point me to the relevant man page in 2.2, 3.x and -current, so I can include that reference in setiathome's man mage. Stefan -- Stefan Bethke Muehlendamm 12Phone: +49-40-256848, +49-177-3504009 D-22087 Hamburg Hamburg, Germany To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Interfacing devices with multiple parents within newbus
Am 06.07.2012 um 17:33 schrieb Arnaud Lacombe: > I assume you are talking about devclass_get_device()/device_find_child(). > > That's neither correct nor robust in a couple of way: > 1) you have no guarantee a device unit will always give you the same resource. > 2) there is no reference counting on the returned device. > 3) there is no track record of the reference being given. > > About (1), lower unit devices can fails to attach[0], thus newly > attached bus will now have a negative offset. > > About (2) and (3), referenced device (think KLD) might go away and the > child will not be told. In this situation, I want the child to be > detached prior to its parent. > > As such, looking up other node by name would fit in what I call > "bypassing newbus purpose". I might just as well export a damn > function pointer and make my life easier. I believe there is one more thing that needs to be addressed, which I ran into while trying to do the arge/mdio attachment: 4) the device attach method may require access to the other device to complete the attachment, but that other might not be attached yet. Circular dependencies nonwithstanding, it would be highly desirable for a device driver developer to be able to simply declare all prerequisites for attachment, and have newbus call attach only after everything is there. Right now, the drivers attach method is called by the parent bus as soon as enumeration is completed. A notification mechanism (similar to the devfs notification but with an exposed KPI) might be an alternative, as mentioned in this thread. Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
