Re: AMD Phenom II X4 temperature issues (was Re: hardware monitor)
You can also try shutting down (obviously), then removing the heat sink, put some thermal paste on the processor and reinstall the heat sink. Sometimes there isn't much (any) thermal paste there and the processor can't get the heat into the heat sink. On 2013, Aug 4, at 15:22, Gary Aitken wrote: > Ok, so now I see that my cpu temperature shoots up pretty dang fast when a > build is going on. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
RE: Geli and crunchgen (/rescue)
Hi Devin,
Thankyou. I'll look further into the openssl reference (off-list) in a few
minutes.
The geom stuff is a little bit tricky to get going, because only glabel and
gpart have the necessary parts in them. Pawel left
enough clues to enable the other geom classes (good engineering)
The flags RELEASE_CRUNCH or RESCUE is tested in the geom/Makefile and defines
STATIC_GEOM_CLASSES which is tested in the source; so:
I've added this and similar to geom eli (mirror, shsec raid...)
===
--- class/eli/geom_eli.c(revision 253832)
+++ class/eli/geom_eli.c(working copy)
@@ -54,9 +54,14 @@
#include "core/geom.h"
#include "misc/subr.h"
+#ifdef STATIC_GEOM_CLASSES
+#define PUBSYM(x) geli_##x
+#else
+#define PUBSYM(x) x
+#endif
-uint32_t lib_version = G_LIB_VERSION;
-uint32_t version = G_ELI_VERSION;
+uint32_t PUBSYM(lib_version) = G_LIB_VERSION;
+uint32_t PUBSYM(version) = G_ELI_VERSION;
#defineGELI_BACKUP_DIR "/var/backups/"
#defineGELI_ENC_ALGO "aes"
@@ -99,7 +104,8 @@
* clear [-v] prov ...
* dump [-v] prov ...
*/
-struct g_command class_commands[] = {
+
+struct g_command PUBSYM(class_commands)[] = {
{ "init", G_FLAG_VERBOSE, eli_main,
{
{ 'a', "aalgo", "", G_TYPE_STRING },
Then I needed to add relevant parts (I'm really only interested in eli, mirror,
shsec) in the /usr/src/sbin/geom/Makefile, but I
tested clean compilation of the other common classes.
--- Makefile(revision 253832)
+++ Makefile(working copy)
@@ -4,18 +4,40 @@
.PATH: ${.CURDIR}/class/part \
${.CURDIR}/class/label \
+ ${.CURDIR}/class/eli \
+ ${.CURDIR}/class/mirror \
+ ${.CURDIR}/class/shsec \
${.CURDIR}/core \
- ${.CURDIR}/misc
+${.CURDIR}/../../sys/geom/eli ${.CURDIR}/../../sys/crypto/sha2 \
+ ${.CURDIR}/misc
+# For geom friends, move these up
+# ${.CURDIR}/class/raid \
+# ${.CURDIR}/class/sched \
+# ${.CURDIR}/class/stripe \
+# ${.CURDIR}/class/journal \
PROG= geom
SRCS= geom.c geom_label.c geom_part.c subr.c
+SRCS+= geom_eli.c
+SRCS+= g_eli_crypto.c
+SRCS+= g_eli_key.c
+SRCS+= pkcs5v2.c
+SRCS+= sha2.c
+SRCS+= geom_mirror.c geom_shsec.c
+#SRCS+= geom_raid.c geom_sched.c geom_stripe.c
+#SRCS+= geom_journal.c geom_journal_ufs.c
NO_MAN=
WARNS?=2
CFLAGS+=-I${.CURDIR} -I${.CURDIR}/core -DSTATIC_GEOM_CLASSES
+# For eli & friends
+CFLAGS+= -I${.CURDIR}/../../sys
-DPADD= ${LIBGEOM} ${LIBSBUF} ${LIBBSDXML} ${LIBUTIL}
-LDADD= -lgeom -lsbuf -lbsdxml -lutil
+DPADD= ${LIBGEOM} ${LIBSBUF} ${LIBBSDXML} ${LIBUTIL} ${LIBMD} ${LIBCRYPTO}
+LDADD= -lgeom -lsbuf -lbsdxml -lutil -lmd -lcrypto
Then adding to boot_crunch.conf:
progs geom
special geom objs geom.o geom_label.o geom_part.o geom_mirror.o geom_shsec.o
geom_eli.o sha2.o pkcs5v2.o g_eli_key.o g_eli_crypto.o
subr.o
ln geom geli
ln geom gmirror
ln geom gshsec
And
libs -lgeom -lkiconv -lm -lwrap
libs -lssl -lcrypto -lmd
# Note: I added a few other things so kiconv and wrap may not be needed for geom
Resulted in release/i386/boot_crunch and /rescue performing satisfactorily :)
Thanks for your help, and clues.
Kind regards, Dewayne.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: AMD Phenom II X4 temperature issues (was Re: hardware monitor)
On 08/04/13 21:39, Frank Leonhardt wrote: > On 05/08/2013 03:01, Gary Aitken wrote: >>> 50C isn't crazy. >> Actually, the 50C figure is just where it shoots to for starters. >> Mfg specs say 62C max, so I stall the process when it gets around >> 59 and still climbing steeply. > > The manufactures specs I found when I looked that range of CPUs up > was 71C > > http://www.amd.com/us/products/desktop/processors/phenom-ii/Pages/phenom-ii-model-number-comparison.aspx > > But there could be two figures - one for maximum desirable working > and one for maximum "or else". Maybe; although the number I quoted wasn't from AMD, and the two I just found at amd both said 71. >>> Did you get anywhere with the ACPI suggestion Try >>> hw.acpi.thermal.tz0.active=1 to make the fan come on and stay on >>> (tz0 or as appropriate). >> The fan is on and stays on all the time at the moment... > > It it full speed all the time? I really don't know what full speed on the fan is / feels like / sounds like. It's pretty quiet and there's a noisy old system nearby... xmbmon doesn't show fan speeds, nor does amdtemp provide access to them. Is there some other kernel module for fan speeds? >>> Here's the fun part. Is your system doing a thermal overload >>> shutdown? >> There is no indication in messages; the last thing before it shut >> down the last time was some su's and root logins. > > This suggests it's not the ACPI in FreeBSD shutting you down, but > something on the motherboard. That was my guess as well. >>> it might help if you posted the results of "sysctl >>> hw.acpi.thermal", but in the mean time look at: >>> >>> hw.acpi.thermal.tz0._HOT hw.acpi.thermal.tz0._CRT >>> >> I don't see any of those; here's what shows up in sysctl -a : >> >> hw.acpi.supported_sleep_state: S1 S3 S4 S5 >> hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 >> hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 >> hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 >> hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 >> hw.acpi.handle_reboot: 0 hw.acpi.reset_video: 0 >> hw.acpi.cpu.cx_lowest: C1 > > Yep - definitely suggests that the thermal control isn't being done > by FreeBSD! ok, but how do I get it in there if I want it? > Go no further on this route, but check the > motherboard/BIOS. I had one machine shut itself down due to a faulty > thermistor (raise the threshold/ignore) but it normally happens when > the parameters are wrong or the fan has failed. As your fan hasn't > failed and the reported temperature is believable my best guesses are > that the BIOS is either picking the wrong shutdown temperature for > the CPU or your air ducting isn't good enough and it really is > getting too hot. Is there a chance that the BIOS pre-dates the CPU > and just doesn't know its working parameters, and is therefore > playing safe? I'll check the BIOS next time I reboot. Air ducting shouldn't be a problem; I've got the side of the case off... > Incidentally, ACPI is an Intel specification but applies AMD64 CPUs > too. The thermal module only works on some chip-sets. FWIW I've found > it works on more AMD platforms than it does Intel ones. > > Regards, Frank. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: AMD Phenom II X4 temperature issues (was Re: hardware monitor)
On 05/08/2013 03:01, Gary Aitken wrote: > 50C isn't crazy. Actually, the 50C figure is just where it shoots to for starters. Mfg specs say 62C max, so I stall the process when it gets around 59 and still climbing steeply. The manufactures specs I found when I looked that range of CPUs up was 71C http://www.amd.com/us/products/desktop/processors/phenom-ii/Pages/phenom-ii-model-number-comparison.aspx But there could be two figures - one for maximum desirable working and one for maximum "or else". Did you get anywhere with the ACPI suggestion Try hw.acpi.thermal.tz0.active=1 to make the fan come on and stay on (tz0 or as appropriate). The fan is on and stays on all the time at the moment... It it full speed all the time? Here's the fun part. Is your system doing a thermal overload shutdown? There is no indication in messages; the last thing before it shut down the last time was some su's and root logins. This suggests it's not the ACPI in FreeBSD shutting you down, but something on the motherboard. it might help if you posted the results of "sysctl hw.acpi.thermal", but in the mean time look at: hw.acpi.thermal.tz0._HOT hw.acpi.thermal.tz0._CRT I don't see any of those; here's what shows up in sysctl -a : hw.acpi.supported_sleep_state: S1 S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.reset_video: 0 hw.acpi.cpu.cx_lowest: C1 Yep - definitely suggests that the thermal control isn't being done by FreeBSD! Go no further on this route, but check the motherboard/BIOS. I had one machine shut itself down due to a faulty thermistor (raise the threshold/ignore) but it normally happens when the parameters are wrong or the fan has failed. As your fan hasn't failed and the reported temperature is believable my best guesses are that the BIOS is either picking the wrong shutdown temperature for the CPU or your air ducting isn't good enough and it really is getting too hot. Is there a chance that the BIOS pre-dates the CPU and just doesn't know its working parameters, and is therefore playing safe? Incidentally, ACPI is an Intel specification but applies AMD64 CPUs too. The thermal module only works on some chip-sets. FWIW I've found it works on more AMD platforms than it does Intel ones. Regards, Frank. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: AMD Phenom II X4 temperature issues (was Re: hardware monitor)
On 08/04/13 18:30, Frank Leonhardt wrote: > On 05/08/2013 00:29, Gary Aitken wrote: >> On 08/04/13 17:22, Gary Aitken wrote: >>> Ok, so now I see that my cpu temperature shoots up pretty dang >>> fast when a build is going on. >>> >>> I'm running an AMD Phenom II X4 with the AMD-supplied fan in an >>> ASUS M4A89TD PRO / USB3 motherboard. >>> >>> The system "works fine" unless I start a cpu-intensive build. If >>> I leave it unattended, after some time the system shuts down >>> abruptly. I'm guessing it's because of excessive cpu >>> temperatures. >>> >>> When doing port builds, or any cpu-intensive job, the temperature >>> of the CPU goes from 45 to 50 in about 30 seconds. I pretty much >>> have to manually suspend and resume the build process to keep it >>> down. If I do that, I avoid the abrupt shutdown. >>> >>> Needless to say, this makes unattended operation a >>> non-starter... >>> >>> Does anyone else have a similar setup they can provide me some >>> related experience on? >> BTW, the mobo temp stays down around 32. >> > > Did you get that from the ACPI? I think so; via amdtemp and xmbmon > Obvious answers are a bigger fan, but a lot of home-build machines > don't match the airflow through the case properly - if the CPU fan is > blowing pre-warmed air on to the CPU it's not as good as blowing > outside air. > > 50C isn't crazy. Some would say that was barely warm, in fact. Cooler > is always better, but you possibly don't need to worry about this. > Some CPUs use what they call passive temperature management, and > power management, which means they increase or reduce the clock rate > depending on the workload and whether it's getting too hot. Faster > switching means more heat. So getting hotter when doing a lot of work > makes sense and could be expected. (Winchesters really heat up like > you wouldn't believe when you move the heads a lot). Actually, the 50C figure is just where it shoots to for starters. Mfg specs say 62C max, so I stall the process when it gets around 59 and still climbing steeply. > Did you get anywhere with the ACPI suggestion (you emailed me > privately, whether you meant to or not, but didn't mention the > outcome). There's a lot there in the ACPI you might want to look in > to, including fan control. If I understand it correctly, "passive > cooling" will be engaged by acpi_thermal if the cpufreq drivers are > in use, which may not be what you want. Try > hw.acpi.thermal.tz0.active=1 to make the fan come on and stay on (tz0 > or as appropriate). The fan is on and stays on all the time at the moment... > Here's the fun part. Is your system doing a thermal overload > shutdown? it will say so on the console, or in the message log. You > didn't say, you just said it "shut down". If it's deciding to shut > down through over-temperature it does not necesarily mean it's > overheating; it could be that it has incorrectly set the shutdown > temperatue for your CPU to be far too low - possibly because it > doesn't recognise it and is being over-cautious. There is no indication in messages; the last thing before it shut down the last time was some su's and root logins. > it might help if you posted the results of "sysctl hw.acpi.thermal", > but in the mean time look at: > > hw.acpi.thermal.tz0._HOT hw.acpi.thermal.tz0._CRT > > (replace tz0 with whatever tz you're worried about). I don't see any of those; here's what shows up in sysctl -a : hw.acpi.supported_sleep_state: S1 S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.reset_video: 0 hw.acpi.cpu.cx_lowest: C1 > The first is the temperature when the system is supposed to stop what > it's doing and suspend to disk (if it can). When it reaches the value > on _CRT it'll write a message to the log file and shut down > immediately to prevent damage. You can set these to whatever you > want, but you have to set hw.acpi.thermal.user_override to 1 first > before it will let you. Final trick - make sure you specify the > temperatures like > > sysctl hw.acpi.thermal.tz0._CRT=80C # sysctl hw.acpi.thermal.user_override sysctl: unknown oid 'hw.acpi.thermal.user_override' obviously, something missing... I tried loading coretemp, but no additional hw.acpi variables; and the man page says it is for intel, not amd. > Don't specify it as 80.0C (as it will display) and don't forget the C > or it will assume degrees Kelvin! > > Regards, Frank. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: AMD Phenom II X4 temperature issues (was Re: hardware monitor)
On 05/08/2013 00:29, Gary Aitken wrote: On 08/04/13 17:22, Gary Aitken wrote: Ok, so now I see that my cpu temperature shoots up pretty dang fast when a build is going on. I'm running an AMD Phenom II X4 with the AMD-supplied fan in an ASUS M4A89TD PRO / USB3 motherboard. The system "works fine" unless I start a cpu-intensive build. If I leave it unattended, after some time the system shuts down abruptly. I'm guessing it's because of excessive cpu temperatures. When doing port builds, or any cpu-intensive job, the temperature of the CPU goes from 45 to 50 in about 30 seconds. I pretty much have to manually suspend and resume the build process to keep it down. If I do that, I avoid the abrupt shutdown. Needless to say, this makes unattended operation a non-starter... Does anyone else have a similar setup they can provide me some related experience on? BTW, the mobo temp stays down around 32. Did you get that from the ACPI? Obvious answers are a bigger fan, but a lot of home-build machines don't match the airflow through the case properly - if the CPU fan is blowing pre-warmed air on to the CPU it's not as good as blowing outside air. 50C isn't crazy. Some would say that was barely warm, in fact. Cooler is always better, but you possibly don't need to worry about this. Some CPUs use what they call passive temperature management, and power management, which means they increase or reduce the clock rate depending on the workload and whether it's getting too hot. Faster switching means more heat. So getting hotter when doing a lot of work makes sense and could be expected. (Winchesters really heat up like you wouldn't believe when you move the heads a lot). Did you get anywhere with the ACPI suggestion (you emailed me privately, whether you meant to or not, but didn't mention the outcome). There's a lot there in the ACPI you might want to look in to, including fan control. If I understand it correctly, "passive cooling" will be engaged by acpi_thermal if the cpufreq drivers are in use, which may not be what you want. Try hw.acpi.thermal.tz0.active=1 to make the fan come on and stay on (tz0 or as appropriate). Here's the fun part. Is your system doing a thermal overload shutdown? it will say so on the console, or in the message log. You didn't say, you just said it "shut down". If it's deciding to shut down through over-temperature it does not necesarily mean it's overheating; it could be that it has incorrectly set the shutdown temperatue for your CPU to be far too low - possibly because it doesn't recognise it and is being over-cautious. it might help if you posted the results of "sysctl hw.acpi.thermal", but in the mean time look at: hw.acpi.thermal.tz0._HOT hw.acpi.thermal.tz0._CRT (replace tz0 with whatever tz you're worried about). The first is the temperature when the system is supposed to stop what it's doing and suspend to disk (if it can). When it reaches the value on _CRT it'll write a message to the log file and shut down immediately to prevent damage. You can set these to whatever you want, but you have to set hw.acpi.thermal.user_override to 1 first before it will let you. Final trick - make sure you specify the temperatures like sysctl hw.acpi.thermal.tz0._CRT=80C Don't specify it as 80.0C (as it will display) and don't forget the C or it will assume degrees Kelvin! Regards, Frank. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: AMD Phenom II X4 temperature issues (was Re: hardware monitor)
On 8/4/2013 6:29 PM, Gary Aitken wrote: On 08/04/13 17:22, Gary Aitken wrote: Ok, so now I see that my cpu temperature shoots up pretty dang fast when a build is going on. I'm running an AMD Phenom II X4 with the AMD-supplied fan in an ASUS M4A89TD PRO / USB3 motherboard. The system "works fine" unless I start a cpu-intensive build. If I leave it unattended, after some time the system shuts down abruptly. I'm guessing it's because of excessive cpu temperatures. When doing port builds, or any cpu-intensive job, the temperature of the CPU goes from 45 to 50 in about 30 seconds. I pretty much have to manually suspend and resume the build process to keep it down. If I do that, I avoid the abrupt shutdown. Needless to say, this makes unattended operation a non-starter... Does anyone else have a similar setup they can provide me some related experience on? BTW, the mobo temp stays down around 32. You need a better heatsink and fan for your CPU. If you're idle temp is 45, that's too high. By using powerd, so it's 800MHz, and being idle I'm at around 26C, presumably. It peaks at 45C on parallel builds. In the meantime, you can set the maximum cpu speed, which I recommend powerd for. Here's a tip when shopping, get a big beefy heatsink with a standard fan size, and replace the fan with something beefier. Either that or water cooling. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: AMD Phenom II X4 temperature issues (was Re: hardware monitor)
On 08/04/13 17:22, Gary Aitken wrote: > Ok, so now I see that my cpu temperature shoots up pretty dang fast when a > build is going on. > > I'm running an AMD Phenom II X4 with the AMD-supplied fan in an > ASUS M4A89TD PRO / USB3 motherboard. > > The system "works fine" unless I start a cpu-intensive build. > If I leave it unattended, after some time the system shuts down abruptly. > I'm guessing it's because of excessive cpu temperatures. > > When doing port builds, or any cpu-intensive job, the temperature of the > CPU goes from 45 to 50 in about 30 seconds. > > I pretty much have to manually suspend and resume the build process > to keep it down. If I do that, I avoid the abrupt shutdown. > > Needless to say, this makes unattended operation a non-starter... > > Does anyone else have a similar setup they can provide me some related > experience on? BTW, the mobo temp stays down around 32. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Archiving a log file
On 04/08/2013 14:38, Terje Elde wrote: On 4. aug. 2013, at 12:54, Frank Leonhardt wrote: The program writing the log is actually called flubnutz and it doesn't play nice with newsyslog, reopen handles on a signal or anything else Then you're out of luck for normal rotation. No matter if you rename the file, or even delete it, it'll keep writing to the same file (the moved file, not the same filename). I suppose your options are to either restart it to have it reopen the file, or if that's not desirable for whatever reason, look see if it'll play nice if you put a named pipe where the logfile is supposed to be. Then you can handle data as you'd like from the pipe. Terje Thanks. The consensus seems to be that there is no way to do this other than "start from a different place". It'd be difficult for the kernel to trim a file from the start unless it was on a block boundary, so it's not implemented and explains the numerous work arounds for dealing with logs (fifo to log manager, signalling an application to reopen logs because file has changed and so on). So I will carry on using my original bodge, happy in the knowledge that it may not be perfect, but there's no better method known to exist unless I want to implement a better truncate() in the kernel. Regards, Frank. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
AMD Phenom II X4 temperature issues (was Re: hardware monitor)
Ok, so now I see that my cpu temperature shoots up pretty dang fast when a build is going on. I'm running an AMD Phenom II X4 with the AMD-supplied fan in an ASUS M4A89TD PRO / USB3 motherboard. The system "works fine" unless I start a cpu-intensive build. If I leave it unattended, after some time the system shuts down abruptly. I'm guessing it's because of excessive cpu temperatures. When doing port builds, or any cpu-intensive job, the temperature of the CPU goes from 45 to 50 in about 30 seconds. I pretty much have to manually suspend and resume the build process to keep it down. If I do that, I avoid the abrupt shutdown. Needless to say, this makes unattended operation a non-starter... Does anyone else have a similar setup they can provide me some related experience on? Thanks, Gary On 08/04/13 15:15, Polytropon wrote: > On Sun, 04 Aug 2013 14:48:56 -0600, Gary Aitken wrote: >> Can anyone suggest a hardware monitor app in the ports tree? >> I've got an amd64 which may have a temperature issue, >> but I can't see it to tell... > > If it's primarily about temperature... amdtemp (kernel > module), healthd (system service), mbmon and xmbmon (in > the ports collection). > > ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: hardware monitor
On 04/08/2013 21:48, Gary Aitken wrote: Can anyone suggest a hardware monitor app in the ports tree? I've got an amd64 which may have a temperature issue, but I can't see it to tell... Try "sysctl hw.acpi.thermal" For more information see "man acpi" and man "acpi_thermal". If you're lucky it gives you information on the ACPI thermal control system, if you have one. If you want an alarm based on this, a shell script is easy enough. If that doesn't do it for you, try some of the others. I've known these to work (sometimes) /usr/ports/sysutils/lmmon /usr/ports/sysutils/consolehm /usr/ports/sysutils/mbmon And there are some fun modules you can add to loader.conf (stuff I've done in the past, but could be on an early version of FreeBSD) coretemp_load="YES" smbus_load="YES" smb_load="YES" intpm_load="YES" ichsmb_load="YES" Then give "sysctl dev.cpu | grep temperature" a try. If you're worried about your Winchesters getting over-cooked you can use smartctl, available in /usr/ports/sysutils/smartmontools. Something like "smartctl -a /dev/ad?? | grep -i temp" should do the trick. It lets you mess with the drive SMART (self-diagnositc) system and it can tell you all sorts of stuff about you drive performance to make you really paranoid. Regards, Frank. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: hardware monitor
On Sun, 04 Aug 2013 14:48:56 -0600, Gary Aitken wrote: > Can anyone suggest a hardware monitor app in the ports tree? > I've got an amd64 which may have a temperature issue, > but I can't see it to tell... If it's primarily about temperature... amdtemp (kernel module), healthd (system service), mbmon and xmbmon (in the ports collection). -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
hardware monitor
Can anyone suggest a hardware monitor app in the ports tree? I've got an amd64 which may have a temperature issue, but I can't see it to tell... Thanks, Gary ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: how to make mkinstalldirs
On 08/04/13 13:25, Eduardo Morras wrote: > On Sun, 04 Aug 2013 12:24:46 -0600 > Gary Aitken wrote: > >> Can anyone give me some hints on how to manually (or automagically) create >> mkinstalldirs for a port? >> >> ports/graphics/ufraw fails to build due to >> >> install: /usr/local/share/glib-2.0/gettext/mkinstalldirs: No such file or >> directory >> >> It's not supposed to be needed if automake is >= 1.9, but automake in the >> ports >> tree is 1.4. > > Today I updated my system (9.1) and automake updated from 1.12.6 to 1.14 > > Perhaps you forget to update the ports tree first typo on my part. should read: It's not supposed to be needed if automake is >= 1.19, but automake in the ports tree is 1.14 I'm up to date with automake as far as I know, and ufraw still requires mkinstalldirs to build. Thanks for the reply, though, Gary ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: virtualbox-ose fails to build on FreeBSD 9.2-BETA2 #0 r253698
On 02/08/2013 16:54, John wrote: > Hello list, > > I'm trying to install virtualbox on a new machine running > FreeBSD 9.2-BETA2 #0 r253698. The ports version is 324162. Is it a > problem with the port or my machine? This was fixed by: commenting everything out of /etc/make.conf svn to 9-stable, make world (etc) reboot then deleting all installed ports then removing everything from /usr/local then rm -rf /usr/ports portsnap install svn then checkout ports install virtualbox-ose sorry for the noise -- John ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: how to make mkinstalldirs
On Sun, 04 Aug 2013 12:24:46 -0600 Gary Aitken wrote: > Can anyone give me some hints on how to manually (or automagically) create > mkinstalldirs for a port? > > ports/graphics/ufraw fails to build due to > > install: /usr/local/share/glib-2.0/gettext/mkinstalldirs: No such file or > directory > > It's not supposed to be needed if automake is >= 1.9, but automake in the > ports > tree is 1.4. Today I updated my system (9.1) and automake updated from 1.12.6 to 1.14 Perhaps you forget to update the ports tree first > > Gary --- --- Eduardo Morras ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
how to make mkinstalldirs
Can anyone give me some hints on how to manually (or automagically) create mkinstalldirs for a port? ports/graphics/ufraw fails to build due to install: /usr/local/share/glib-2.0/gettext/mkinstalldirs: No such file or directory It's not supposed to be needed if automake is >= 1.9, but automake in the ports tree is 1.4. Gary ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Archiving a log file
On 4. aug. 2013, at 12:54, Frank Leonhardt wrote: > The program writing the log is actually called flubnutz and it doesn't play > nice with newsyslog, reopen handles on a signal or anything else Then you're out of luck for normal rotation. No matter if you rename the file, or even delete it, it'll keep writing to the same file (the moved file, not the same filename). I suppose your options are to either restart it to have it reopen the file, or if that's not desirable for whatever reason, look see if it'll play nice if you put a named pipe where the logfile is supposed to be. Then you can handle data as you'd like from the pipe. Terje ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Archiving a log file
On 04/08/2013 04:04, mikel king wrote:
On Aug 3, 2013, at 7:11 PM, Frank Leonhardt wrote:
The answer isn't (AFAIK) newsyslog
I did some more digging on the whole log piping thing and apache includes a
nifty little application called rotatelogs which lives in
/usr/local/sbin/rotatelogs on my system that I built form the ports. From the
man page:
NAME
rotatelogs - Piped logging program to rotate Apache logs
SYNOPSIS
rotatelogs [ -l ] [ -f ] logfile rotationtime|filesizeM [ offset ]
SUMMARY
rotatelogs is a simple program for use in conjunction with Apache's
piped logfile feature. It supports rotation based on a time interval or maximum
size of the log.
It looks pretty simple to use just create your log format directive like:
LogFormat "%t \"%r\" %>s \"%{Referer}i\" %b" SpecialFormat
CustomLog "| /usr/local/sbin/rotatelogs /var/log/httpd-access.log
86400" SpecialFormat
I hope that helps. I know I shall be experimenting with this one tomorrow.
Thanks for looking at it, but I probably shouldn't have picked Apache as
an example. I thought it would be something people were familiar with.
The program writing the log is actually called flubnutz and it doesn't
play nice with newsyslog, reopen handles on a signal or anything else.
FWIW I've been using newsyslog since 1998 from most regular system
services and I don't have any problem with it.
(I lied about it being called "flubnutz", before anyone Googles it - but
it's not an Apache-specific issue, as Apache logs are handled well
enough with newsyslog except where you're running virtual hosts with
their own log files, in which case it's a PITA.).
Regards, Frank.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Assign program call to a key
On Sat, 3 Aug 2013 14:43:14 + (UTC), jb wrote: > Polytropon edvax.de> writes: > > > > > Is there a way to assign a predefined program call to a key > > in X, _independently_ from the window manager or desktop > > environment in use? > > ... > > https://wiki.archlinux.org/index.php/Extra_Keyboard_Keys_in_Xorg > It may give you some hints. The last entries on the page look interesting, but "keytouch" and "actkbd" are not available, only "xbindkeys" is in the ports collection. >From the description Allows you to launch shell commands under X with your keyboard it seems to be exactly what I'm looking for. Thanks for the *pointer! ;-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
