Re: Assign program call to a key
On Sat, 3 Aug 2013 14:43:14 + (UTC), jb wrote: Polytropon freebsd at 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
Re: Archiving a log file
On 04/08/2013 04:04, mikel king wrote:
On Aug 3, 2013, at 7:11 PM, Frank Leonhardt freebsd-...@fjl.co.uk 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: Archiving a log file
On 4. aug. 2013, at 12:54, Frank Leonhardt fra...@fjl.co.uk 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
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: how to make mkinstalldirs
On Sun, 04 Aug 2013 12:24:46 -0600 Gary Aitken vagab...@blackfoot.net 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 emorr...@yahoo.es ___ 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 08/04/13 13:25, Eduardo Morras wrote: On Sun, 04 Aug 2013 12:24:46 -0600 Gary Aitken vagab...@blackfoot.net 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
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: 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
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
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: Archiving a log file
On 04/08/2013 14:38, Terje Elde wrote: On 4. aug. 2013, at 12:54, Frank Leonhardt fra...@fjl.co.uk 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
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: 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 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 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 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 snip 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? snip 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 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 snip 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? snip 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: 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)
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 vagab...@blackfoot.net 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
