Re: SuperMicro i7 (UP) - very slow performance
Bryce wrote: > I don't think it is temperature, I have never seen temps above the low > 60's C and the speed never goes down from 2.8 Ghz. This is what I see > when running your dd for a while: > > br...@tahiti[~]>sysctl -a | grep temperature > dev.cpu.0.temperature: 55.0C > dev.cpu.1.temperature: 55.0C > dev.cpu.2.temperature: 51.0C > dev.cpu.3.temperature: 52.0C > dev.cpu.4.temperature: 59.0C > dev.cpu.5.temperature: 61.0C > dev.cpu.6.temperature: 51.0C > dev.cpu.7.temperature: 52.0C > br...@tahiti[~]>sysctl -n dev.cpu.0.freq > 2801 Looks not bad, but I would checked it during good compilation, using all cores. Just to compare, my Core i7-870 with boxed cooler reports: 31C being idle with tuned power management, 53C being idle without any power management, 85C during `make -j16`. That system did `make -j16 universe` in about 3 hours AFAIR. PS: AFAIK dev.cpu.0.freq won't report you if frequency was lowered due to overheating. -- Alexander Motin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SuperMicro i7 (UP) - very slow performance
on 23/09/2010 11:26 Alexander Motin said the following: > PS: AFAIK dev.cpu.0.freq won't report you if frequency was lowered due > to overheating. I think that you are correct about this. And last I checked we simply ignored thermal throttling interrupt. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SuperMicro i7 (UP) - very slow performance
On 23/09/2010, at 21:26, Andriy Gapon wrote: > on 23/09/2010 11:26 Alexander Motin said the following: >> PS: AFAIK dev.cpu.0.freq won't report you if frequency was lowered due >> to overheating. > > I think that you are correct about this. > And last I checked we simply ignored thermal throttling interrupt. I could not get cpufreq to show a lower frequency when I tried overheating a CPU even though the performance dropped. It would be really nice if there was some notification of CPU throttling :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SuperMicro i7 (UP) - very slow performance
On Sep 22, 9:35 am, nickolas...@gmail.com wrote: > > md5 -t is quite a small benchmark, even with his misfunctioning CPU it > > took <6 seconds to complete. > > > If his problem is a misapplied heatsink/fan, then his CPU could be > > throttling when it gets hot, the hotter it gets the more it throttles, > > which could explain his massive buildworld walltime. Perhaps running > > something like: > > > apply -0 "md5 -t" `jot 10` > > > would display a notable difference. > I don't think is heat & throttling related. Here's the temps while doing a make -j16 buildworld: dev.cpu.0.temperature: 57.0C dev.cpu.1.temperature: 57.0C dev.cpu.2.temperature: 54.0C dev.cpu.3.temperature: 54.0C dev.cpu.4.temperature: 57.0C dev.cpu.5.temperature: 57.0C dev.cpu.6.temperature: 55.0C dev.cpu.7.temperature: 55.0C IMO, the problem is preventing the system from even loading up the CPU's enough to even get hot - I have never seen it over 61 C. If sit & watch top -P during a buildworld, it rarely get's all 8 CPU's loaded up with idle numbers near 0%. A vast majority of the time one CPU is maxed and the others are mostly idle. > You may also run openssl speed or "linpack" test > (/usr/ports/math/linpack) or hpl (/usr/ports/benchmarks/hpl) to load > your CPU > ___ > freebsd-sta...@freebsd.org mailing > listhttp://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SuperMicro i7 (UP) - very slow performance
on 23/09/2010 15:37 Daniel O'Connor said the following: > > On 23/09/2010, at 21:26, Andriy Gapon wrote: >> on 23/09/2010 11:26 Alexander Motin said the following: >>> PS: AFAIK dev.cpu.0.freq won't report you if frequency was lowered due >>> to overheating. >> >> I think that you are correct about this. >> And last I checked we simply ignored thermal throttling interrupt. > > I could not get cpufreq to show a lower frequency when I tried overheating a > CPU even though the performance dropped. > > It would be really nice if there was some notification of CPU throttling :) cpufreq is not designed to monitor what is going on in cpu. cpufreq knows what cpu supports and knows host to set a certain frequency (performance level rather). -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[releng_8 tinderbox] failure on mips/mips
TB --- 2010-09-23 11:13:24 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-23 11:13:24 - starting RELENG_8 tinderbox run for mips/mips TB --- 2010-09-23 11:13:24 - cleaning the object tree TB --- 2010-09-23 11:14:35 - cvsupping the source tree TB --- 2010-09-23 11:14:35 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup5.freebsd.org /tinderbox/RELENG_8/mips/mips/supfile TB --- 2010-09-23 11:18:16 - building world TB --- 2010-09-23 11:18:16 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-23 11:18:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-23 11:18:16 - TARGET=mips TB --- 2010-09-23 11:18:16 - TARGET_ARCH=mips TB --- 2010-09-23 11:18:16 - TZ=UTC TB --- 2010-09-23 11:18:16 - __MAKE_CONF=/dev/null TB --- 2010-09-23 11:18:16 - cd /src TB --- 2010-09-23 11:18:16 - /usr/bin/make -B buildworld >>> World build started on Thu Sep 23 11:18:17 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /obj/mips/src/tmp/usr/bin/ld: BFD 2.15 [FreeBSD] 2004-05-23 assertion fail /src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elfxx-mips.c:1899 /obj/mips/src/tmp/usr/bin/ld: BFD 2.15 [FreeBSD] 2004-05-23 assertion fail /src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elfxx-mips.c:1902 /obj/mips/src/tmp/usr/bin/ld: BFD 2.15 [FreeBSD] 2004-05-23 assertion fail /src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elfxx-mips.c:1899 /obj/mips/src/tmp/usr/bin/ld: BFD 2.15 [FreeBSD] 2004-05-23 assertion fail /src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elfxx-mips.c:1902 /obj/mips/src/tmp/usr/bin/ld: BFD 2.15 [FreeBSD] 2004-05-23 assertion fail /src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elfxx-mips.c:1899 /obj/mips/src/tmp/usr/bin/ld: BFD 2.15 [FreeBSD] 2004-05-23 assertion fail /src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elfxx-mips.c:1902 /obj/mips/src/tmp/usr/bin/ld: BFD 2.15 [FreeBSD] 2004-05-23 assertion fail /src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elfxx-mips.c:1899 /obj/mips/src/tmp/usr/bin/ld: BFD 2.15 [FreeBSD] 2004-05-23 assertion fail /src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elfxx-mips.c:1902 *** Error code 1 Stop in /src/usr.bin/tftp. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-09-23 14:41:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-09-23 14:41:37 - ERROR: failed to build world TB --- 2010-09-23 14:41:37 - 2068.47 user 6701.08 system 12493.33 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-mips-mips.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: wifi issues under -stable
On Wed, 22 Sep 2010 16:46:43 -0500 Jim Bryant wrote: > One (this one) has an intel pro wireless 3945ABG installed, which returns: > > wpi0: irq 18 at device 0.0 on pci6 > wpi0: Driver Revision 20071127 > wpi0: 0x1000 bytes of rid 0x10 res 3 failed (0, 0x). > wpi0: could not allocate memory resource > device_attach: wpi0 attach returned 6 > > and the broadcom used in the other does the exact same thing. > > I'm thinking that this isn't really a problem with the wifi, but may be > a mini-pci-e issue. More likelely, it is ACPI-related. Simply put: many laptops have broken ACPI implementations. Other OS'es might have a workaround for them, but FreeBSD does not. Since almost none of todays' laptops work correctly with ACPI disabled, this is a major pain. (Some laptops overheat when ACPI is disbled, because of disabled thermal management). You can try to figure out if the problem is acpi-related with the following hint in /boot/loader.conf (but beware of thermal problems; don't run the laptop too long with acpi disabled): hint.acpi.0.disabled="1" > does anyone know how to solve this problem? Well, if you can identify exactly where the problem is, you might be able to work around it. However, the task isn't easy. Sometimes, forcing IRQ routing might help (but at least in 7.x this only works with acpi disabled). Using other OS'es (Linux) to identify if they do something different with the resources (irq, memeory etc. for devices) migh help pointing out wherer the problem might be. However, you will be speninding some time comparing outputs from a FreeBSD verbose boot with the same information from Linux. (This thread reminds me that I should test FreeBSD 8.1 on my old Acer laptop, which have acpi problems, and haven't worked with 6.0 - 8.0.) -- Torfinn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SuperMicro i7 (UP) - very slow performance
On Thu, 23 Sep 2010, Alexander Motin wrote: > Bryce wrote: > > I don't think it is temperature, I have never seen temps above the low > > 60's C and the speed never goes down from 2.8 Ghz. This is what I see > > when running your dd for a while: > > > > br...@tahiti[~]>sysctl -a | grep temperature > > dev.cpu.0.temperature: 55.0C > > dev.cpu.1.temperature: 55.0C > > dev.cpu.2.temperature: 51.0C > > dev.cpu.3.temperature: 52.0C > > dev.cpu.4.temperature: 59.0C > > dev.cpu.5.temperature: 61.0C > > dev.cpu.6.temperature: 51.0C > > dev.cpu.7.temperature: 52.0C > > br...@tahiti[~]>sysctl -n dev.cpu.0.freq > > 2801 > > Looks not bad, but I would checked it during good compilation, using all > cores. > > Just to compare, my Core i7-870 with boxed cooler reports: > 31C being idle with tuned power management, > 53C being idle without any power management, > 85C during `make -j16`. > That system did `make -j16 universe` in about 3 hours AFAIR. > > PS: AFAIK dev.cpu.0.freq won't report you if frequency was lowered due > to overheating. Thanks, I've often wondered about that (among other things :) So not looking much like overheating. But don't these messages requoted below seem at all significant? At least, I've never seen them before: > est0: on cpu0 > est0: Invalid id16 (set, cur) = (20, 21) > est0: Can't check freq 2667, it may be invalid > est0: Invalid id16 (set, cur) = (19, 21) > est0: Can't check freq 2533, it may be invalid > est0: Invalid id16 (set, cur) = (18, 21) > est0: Can't check freq 2400, it may be invalid > est0: Invalid id16 (set, cur) = (17, 21) > est0: Can't check freq 2267, it may be invalid > est0: Invalid id16 (set, cur) = (16, 21) > est0: Can't check freq 2133, it may be invalid > est0: Invalid id16 (set, cur) = (15, 21) > est0: Can't check freq 2000, it may be invalid > est0: Invalid id16 (set, cur) = (14, 21) > est0: Can't check freq 1867, it may be invalid > est0: Invalid id16 (set, cur) = (13, 21) > est0: Can't check freq 1733, it may be invalid > est0: Invalid id16 (set, cur) = (12, 21) > est0: Can't check freq 1600, it may be invalid cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SuperMicro i7 (UP) - very slow performance
Ian Smith wrote: > So not looking much like overheating. But don't these messages requoted > below seem at all significant? At least, I've never seen them before: > >> est0: on cpu0 >> est0: Invalid id16 (set, cur) = (20, 21) >> est0: Can't check freq 2667, it may be invalid >> est0: Invalid id16 (set, cur) = (19, 21) >> est0: Can't check freq 2533, it may be invalid >> est0: Invalid id16 (set, cur) = (18, 21) >> est0: Can't check freq 2400, it may be invalid >> est0: Invalid id16 (set, cur) = (17, 21) >> est0: Can't check freq 2267, it may be invalid >> est0: Invalid id16 (set, cur) = (16, 21) >> est0: Can't check freq 2133, it may be invalid >> est0: Invalid id16 (set, cur) = (15, 21) >> est0: Can't check freq 2000, it may be invalid >> est0: Invalid id16 (set, cur) = (14, 21) >> est0: Can't check freq 1867, it may be invalid >> est0: Invalid id16 (set, cur) = (13, 21) >> est0: Can't check freq 1733, it may be invalid >> est0: Invalid id16 (set, cur) = (12, 21) >> est0: Can't check freq 1600, it may be invalid They are not. It is specifics of EIST behavior on multicore CPUs. It is impossible to test P-states during driver attach (before AP CPUs started). I have already disabled this check for SMP systems. -- Alexander Motin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SuperMicro i7 (UP) - very slow performance
On Thu, 23 Sep 2010, Alexander Motin wrote: > Date: Thu, 23 Sep 2010 19:42:29 +0300 > From: Alexander Motin > To: Ian Smith > Cc: Bryce , FreeBSD Stable > Subject: Re: SuperMicro i7 (UP) - very slow performance > > Ian Smith wrote: > > So not looking much like overheating. But don't these messages requoted > > below seem at all significant? At least, I've never seen them before: > > > >> est0: on cpu0 > >> est0: Invalid id16 (set, cur) = (20, 21) > >> est0: Can't check freq 2667, it may be invalid > >> est0: Invalid id16 (set, cur) = (19, 21) > >> est0: Can't check freq 2533, it may be invalid > >> est0: Invalid id16 (set, cur) = (18, 21) > >> est0: Can't check freq 2400, it may be invalid > >> est0: Invalid id16 (set, cur) = (17, 21) > >> est0: Can't check freq 2267, it may be invalid > >> est0: Invalid id16 (set, cur) = (16, 21) > >> est0: Can't check freq 2133, it may be invalid > >> est0: Invalid id16 (set, cur) = (15, 21) > >> est0: Can't check freq 2000, it may be invalid > >> est0: Invalid id16 (set, cur) = (14, 21) > >> est0: Can't check freq 1867, it may be invalid > >> est0: Invalid id16 (set, cur) = (13, 21) > >> est0: Can't check freq 1733, it may be invalid > >> est0: Invalid id16 (set, cur) = (12, 21) > >> est0: Can't check freq 1600, it may be invalid > > They are not. It is specifics of EIST behavior on multicore CPUs. It is > impossible to test P-states during driver attach (before AP CPUs > started). I have already disabled this check for SMP systems. Ok, thanks. That's me out of ideas .. but lurking with interest. cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
kernel: arpresolve: can't allocate llinfo for 10.6.10.240
Hi all, I'm using FreeBSD 8.1-201008 amd64 snapshot. When I watch log messages I see "kernel: arpresolve: can't allocate llinfo for 10.0.16.251" messages repeating once per 2 minutes. When I saw this log, default router changes unexpectedly. Normally default router should be 193.X.Y.Z, but after this log default router shown as 10.0.16.251. And routing really changes. I watch the changes on routing table via "route -n monitor" command. I couldnt see anything about default route changes. I tried with both net.inet net.inet.flowtable.enable=0 and net.inet.flowtable.enable=1. Nothing changes. I think, arp table overflows and overwrites the routing table. I captured the packges while this problem occurs. the tcpdump file: http://193.255.128.30/~ryland/flowdata_10_0_16_251 tcpdump -w /home/flowdata_10_0_16_251 -ni bce0.116 host 10.0.16.251 system has 2x 4core Xeon, 32GB ram, about 5000 clients and 152 if_vlan interfaces, 5 real NICs. Any ideas? Regards, Özkan KIRIK Mersin University @ Turkey ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: wifi issues under -stable
On Thursday, September 23, 2010 12:08:40 pm Torfinn Ingolfsen wrote: > On Wed, 22 Sep 2010 16:46:43 -0500 > Jim Bryant wrote: > > > One (this one) has an intel pro wireless 3945ABG installed, which returns: > > > > wpi0: irq 18 at device 0.0 on pci6 > > wpi0: Driver Revision 20071127 > > wpi0: 0x1000 bytes of rid 0x10 res 3 failed (0, 0x). > > wpi0: could not allocate memory resource > > device_attach: wpi0 attach returned 6 > > > > and the broadcom used in the other does the exact same thing. > > > > I'm thinking that this isn't really a problem with the wifi, but may be > > a mini-pci-e issue. > > More likelely, it is ACPI-related. Simply put: many laptops have > broken ACPI implementations. Other OS'es might have a workaround for > them, but FreeBSD does not. Well, in this case the breakage is probably that something in the ACPI initialization clears the resource ranges in a PCI-PCI bridge. However, I would not quite say that ACPI is broken in that case as FreeBSD's PCI-PCI bridge driver needs to handle this sort of case anyway in order to truly handle hotplug devices and 'PNP OS == YES', so this is really FreeBSD's fault rather than ACPI or the BIOS. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 8.1 Stable Unreasanoble Rebooting
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/16/2010 15:33, Michael BlackHeart wrote:
> 2010/9/16 Jeremy Chadwick :
>> On Thu, Sep 16, 2010 at 08:37:29PM +0400, Michael BlackHeart wrote:
>>> Today I've got a pretty strange event. It looks like a reboot but
>>> unreasonable as far as I see. Before server's uptime was over month,
>>> it's sometimes have to reboot for kernel updates or somethings like
>>> that. I've digen all logs and didn't find a reason, so here they all.
>>>
>>> auth.log
>>> Sep 16 13:59:58 diablo sshd[2284]: Received signal 15; terminating.
>>> Sep 16 14:04:26 diablo sshd[2290]: Server listening on 0.0.0.0 port 22442.
>>>
>>> cron - nothing
>>> debug.log - nothing
>>> dmesg - nothing
>>>
>>> messages
>>> Sep 16 13:44:55 diablo transmission-daemon[7965]: Couldn't create
>>> socket: Protocol not supported (fdlimit.c:651)
>>> Sep 16 13:45:31 diablo last message repeated 5 times
>>> Sep 16 13:47:23 diablo last message repeated 13 times
>>> Sep 16 13:57:40 diablo last message repeated 51 times
>>> Sep 16 13:59:48 diablo last message repeated 12 times
>>> Sep 16 14:00:18 diablo named[1575]: stopping command channel on
>>> 127.0.0.1#953
>>> Sep 16 14:00:18 diablo named[1575]: exiting
>>> Sep 16 14:00:18 diablo syslogd: exiting on signal 15
>>> Sep 16 14:02:31 diablo syslogd: kernel boot file is /boot/kernel/kernel
>>> Sep 16 14:02:31 diablo kernel: Copyright (c) 1992-2010 The FreeBSD Project.
>>> {...}
>>
>> This sure looks like a legitimate reboot to me (e.g. shutdown -r now);
>> note how your system daemons (named, syslogd) are being shut down with
>> SIGTERM. You can check with "last" (shutdown/reboot vs. crash).
>>
>>
>> I would highly recommend taking this machine offline and reinstalling
>> the OS, in addition to newfs'ing all existing filesystems (restore from
>> last known good backup). buildworld/installworld and
>> buildkernel/installkernel may not be enough depending on what the
>> individual did. It's likely the machine could be compromised in some
>> way, especially if there's any service on it which is public-facing,
>> regardless of authentication mechanisms you've deployed in front of it.
>>
>>
>> --
>> | Jeremy Chadwick j...@parodius.com |
>> | Parodius Networking http://www.parodius.com/ |
>> | UNIX Systems Administrator Mountain View, CA, USA |
>> | Making life hard for others since 1977. PGP: 4BD6C0CB |
>>
>>
>
> That looks reasonable
> last says:
> reboot ~ th 16 sen 14:04
> reboot ~ th 16 sen 14:03
> shutdown ~ th 16 sen 13:59
>
> and it's pretty good syncs with logs but there's no anybody access to
> physical console 'cos it's not even plugged in. That's for the first.
> Next, I've got, I believe, pretty strong passwords, and also root
> can't log in directly, but wheel user also is in operators so he also
> can reboot or shutdown, but there's no any attempts or successful
> logins. All potentialy dangerous services run under their own
> unprerileged users, and so on. Crontabs also doesn't contain scripts,
> I prefer periodic system, and there's no anyway anything that cause
> reboot.
> Thing that worries me it that there were multiple reboots and shutdown
> that goes up by itself without anyone pressing a button. And in
> messages log there's fsck segment that indicates to unnormal shutdown
> or reboot. It looks like it started to shutting down but was in some
> case interrupted and after powering up it few times reboots itself.
> But commonly FreeBSD doesn't reboot by it's own will.
> The same hardware worked over a half a year under 8.0 stables without
> such a problem. I just would like to understand from where this
> problem comes up.
> This machine doesn't contain any critical info so I'll wait for a bit.
> Also I'd like to notice that recently I've tuned hdd's spindown exept
> system hdd by atacontrol port, powerd and CPU frequency lowering in
> idle, maybe something of this could cause this problem? And where
> could I check this out?
You might just want to go through your /etc/rc.d/*, crontabs,
/etc/periodic/* and /etc/rc* to check for any commands that call
shutdown(8) or reboot(8).
Not really malicious but a rogue user that was once a staffer can plant
a shutdown/reboot command in any one of the above matching files and
have it run by at(1). This really sounds like the case here.
1). Check the above files. egrep -nr "(shutdown|reboot)" on those.
2). Inspect the files for at(1) reboot(8) shutdown(8) or paths to
unintelligible binaries that have been setuid=0(u+s) owner=root.
3). Keep in mind a rogue staffer may have well cp(1) shutdown(8) to
another command or created a script containing shutdown(8) to another
command that matches another system command or has replaced one.
Thats just a few things to go on for now. Others may have more to add to it.
Regards &
Re: FreeBSD 8.1 Stable Unreasanoble Rebooting
On 09/23/2010 14:38, jhell wrote:
> On 09/16/2010 15:33, Michael BlackHeart wrote:
>> 2010/9/16 Jeremy Chadwick :
>>> On Thu, Sep 16, 2010 at 08:37:29PM +0400, Michael BlackHeart wrote:
Today I've got a pretty strange event. It looks like a reboot but
unreasonable as far as I see. Before server's uptime was over month,
it's sometimes have to reboot for kernel updates or somethings like
that. I've digen all logs and didn't find a reason, so here they all.
auth.log
Sep 16 13:59:58 diablo sshd[2284]: Received signal 15; terminating.
Sep 16 14:04:26 diablo sshd[2290]: Server listening on 0.0.0.0 port 22442.
cron - nothing
debug.log - nothing
dmesg - nothing
messages
Sep 16 13:44:55 diablo transmission-daemon[7965]: Couldn't create
socket: Protocol not supported (fdlimit.c:651)
Sep 16 13:45:31 diablo last message repeated 5 times
Sep 16 13:47:23 diablo last message repeated 13 times
Sep 16 13:57:40 diablo last message repeated 51 times
Sep 16 13:59:48 diablo last message repeated 12 times
Sep 16 14:00:18 diablo named[1575]: stopping command channel on
127.0.0.1#953
Sep 16 14:00:18 diablo named[1575]: exiting
Sep 16 14:00:18 diablo syslogd: exiting on signal 15
Sep 16 14:02:31 diablo syslogd: kernel boot file is /boot/kernel/kernel
Sep 16 14:02:31 diablo kernel: Copyright (c) 1992-2010 The FreeBSD Project.
{...}
>>>
>>> This sure looks like a legitimate reboot to me (e.g. shutdown -r now);
>>> note how your system daemons (named, syslogd) are being shut down with
>>> SIGTERM. You can check with "last" (shutdown/reboot vs. crash).
>>>
>>>
>>> I would highly recommend taking this machine offline and reinstalling
>>> the OS, in addition to newfs'ing all existing filesystems (restore from
>>> last known good backup). buildworld/installworld and
>>> buildkernel/installkernel may not be enough depending on what the
>>> individual did. It's likely the machine could be compromised in some
>>> way, especially if there's any service on it which is public-facing,
>>> regardless of authentication mechanisms you've deployed in front of it.
>>>
>>>
>>> --
>>> | Jeremy Chadwick j...@parodius.com |
>>> | Parodius Networking http://www.parodius.com/ |
>>> | UNIX Systems Administrator Mountain View, CA, USA |
>>> | Making life hard for others since 1977. PGP: 4BD6C0CB |
>>>
>>>
>
>> That looks reasonable
>> last says:
>> reboot ~ th 16 sen 14:04
>> reboot ~ th 16 sen 14:03
>> shutdown ~ th 16 sen 13:59
>
>> and it's pretty good syncs with logs but there's no anybody access to
>> physical console 'cos it's not even plugged in. That's for the first.
>> Next, I've got, I believe, pretty strong passwords, and also root
>> can't log in directly, but wheel user also is in operators so he also
>> can reboot or shutdown, but there's no any attempts or successful
>> logins. All potentialy dangerous services run under their own
>> unprerileged users, and so on. Crontabs also doesn't contain scripts,
>> I prefer periodic system, and there's no anyway anything that cause
>> reboot.
>> Thing that worries me it that there were multiple reboots and shutdown
>> that goes up by itself without anyone pressing a button. And in
>> messages log there's fsck segment that indicates to unnormal shutdown
>> or reboot. It looks like it started to shutting down but was in some
>> case interrupted and after powering up it few times reboots itself.
>> But commonly FreeBSD doesn't reboot by it's own will.
>> The same hardware worked over a half a year under 8.0 stables without
>> such a problem. I just would like to understand from where this
>> problem comes up.
>> This machine doesn't contain any critical info so I'll wait for a bit.
>> Also I'd like to notice that recently I've tuned hdd's spindown exept
>> system hdd by atacontrol port, powerd and CPU frequency lowering in
>> idle, maybe something of this could cause this problem? And where
>> could I check this out?
>
> You might just want to go through your /etc/rc.d/*, crontabs,
> /etc/periodic/* and /etc/rc* to check for any commands that call
> shutdown(8) or reboot(8).
>
> Not really malicious but a rogue user that was once a staffer can plant
> a shutdown/reboot command in any one of the above matching files and
> have it run by at(1). This really sounds like the case here.
>
> 1). Check the above files. egrep -nr "(shutdown|reboot)" on those.
> 2). Inspect the files for at(1) reboot(8) shutdown(8) or paths to
> unintelligible binaries that have been setuid=0(u+s) owner=root.
> 3). Keep in mind a rogue staffer may have well cp(1) shutdown(8) to
> another command or created a script containing shutdown(8) to another
> command that matches another system command or has repla
Re: SuperMicro i7 (UP) - very slow performance
Just wanted to follow up and show what things looks like in the 'building everything' part of build world. It has been running almost 23 hours... br...@tahiti[~]>vmstat 1 procs memory pagedisks faults cpu r b w avmfre flt re pi pofr sr da0 da1 in sy cs us sy id 11 0 0 1201M 2770M 282 0 0 0 318 0 0 0 10 238 475 14 1 85 12 2 0 1185M 2773M 1269 0 0 0 1944 0 0 02 279 643 97 3 0 12 0 0 1154M 2811M 1756 0 0 0 11603 0 0 06 893 701 95 3 2 12 0 0 1157M 2808M 845 0 0 063 0 0 02 475 575 96 2 2 11 0 0 1157M 2804M 1917 0 0 0 1077 0 0 08 970 737 97 3 0 11 0 0 1158M 2801M 1597 0 0 0 930 0 0 0 10 1213 664 96 4 0 11 0 0 1172M 2796M 1782 0 0 0 467 0 0 08 1009 692 97 3 0 11 0 0 1178M 2792M 1128 0 0 0 1 0 0 02 205 546 99 1 0 ^C br...@tahiti[~]>iostat 1 tty da0 da1 da2 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 0 221 39.75 0 0.00 39.92 0 0.00 36.16 0 0.00 13 1 1 0 85 0 545 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 97 0 3 0 0 0 295 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 98 0 2 0 0 0 537 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 98 0 1 0 0 078 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 99 0 1 0 0 078 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 96 0 4 0 0 0 307 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 97 0 2 0 1 078 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 98 0 2 0 0 ^C br...@tahiti[~]>sysctl dev.cpu | grep temperature dev.cpu.0.temperature: 59.0C dev.cpu.1.temperature: 59.0C dev.cpu.2.temperature: 56.0C dev.cpu.3.temperature: 56.0C dev.cpu.4.temperature: 59.0C dev.cpu.5.temperature: 59.0C dev.cpu.6.temperature: 56.0C dev.cpu.7.temperature: 56.0C ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: BIND9 built w/--disable-ipv6 on 8.1-STABLE
There is way too much misinformation here. named probes the kernel to work out if it supports IPv6 or not. named -4 turns off IPv6 so there is no need to disable it at compile time. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 8.1 Stable Unreasanoble Rebooting
On Thu, 23 Sep 2010, jhell wrote:
> On 09/16/2010 15:33, Michael BlackHeart wrote:
> > 2010/9/16 Jeremy Chadwick :
> >> On Thu, Sep 16, 2010 at 08:37:29PM +0400, Michael BlackHeart wrote:
> >>> Today I've got a pretty strange event. It looks like a reboot but
> >>> unreasonable as far as I see. Before server's uptime was over month,
> >>> it's sometimes have to reboot for kernel updates or somethings like
> >>> that. I've digen all logs and didn't find a reason, so here they all.
> >>>
> >>> auth.log
> >>> Sep 16 13:59:58 diablo sshd[2284]: Received signal 15; terminating.
> >>> Sep 16 14:04:26 diablo sshd[2290]: Server listening on 0.0.0.0 port
> >>> 22442.
> >>>
> >>> cron - nothing
> >>> debug.log - nothing
> >>> dmesg - nothing
> >>>
> >>> messages
> >>> Sep 16 13:44:55 diablo transmission-daemon[7965]: Couldn't create
> >>> socket: Protocol not supported (fdlimit.c:651)
> >>> Sep 16 13:45:31 diablo last message repeated 5 times
> >>> Sep 16 13:47:23 diablo last message repeated 13 times
> >>> Sep 16 13:57:40 diablo last message repeated 51 times
> >>> Sep 16 13:59:48 diablo last message repeated 12 times
Michael, were these above messages to be expected?
> >>> Sep 16 14:00:18 diablo named[1575]: stopping command channel on
> >>> 127.0.0.1#953
> >>> Sep 16 14:00:18 diablo named[1575]: exiting
> >>> Sep 16 14:00:18 diablo syslogd: exiting on signal 15
> >>> Sep 16 14:02:31 diablo syslogd: kernel boot file is /boot/kernel/kernel
> >>> Sep 16 14:02:31 diablo kernel: Copyright (c) 1992-2010 The FreeBSD
> >>> Project.
> >>> {...}
> >>
> >> This sure looks like a legitimate reboot to me (e.g. shutdown -r now);
> >> note how your system daemons (named, syslogd) are being shut down with
> >> SIGTERM. You can check with "last" (shutdown/reboot vs. crash).
> >>
> >>
> >> I would highly recommend taking this machine offline and reinstalling
> >> the OS, in addition to newfs'ing all existing filesystems (restore from
> >> last known good backup). buildworld/installworld and
> >> buildkernel/installkernel may not be enough depending on what the
> >> individual did. It's likely the machine could be compromised in some
> >> way, especially if there's any service on it which is public-facing,
> >> regardless of authentication mechanisms you've deployed in front of it.
> >>
[..]
> > That looks reasonable
> > last says:
> > reboot ~ th 16 sen 14:04
> > reboot ~ th 16 sen 14:03
> > shutdown ~ th 16 sen 13:59
> >
> > and it's pretty good syncs with logs but there's no anybody access to
> > physical console 'cos it's not even plugged in. That's for the first.
> > Next, I've got, I believe, pretty strong passwords, and also root
> > can't log in directly, but wheel user also is in operators so he also
> > can reboot or shutdown, but there's no any attempts or successful
> > logins. All potentialy dangerous services run under their own
> > unprerileged users, and so on. Crontabs also doesn't contain scripts,
> > I prefer periodic system, and there's no anyway anything that cause
> > reboot.
> > Thing that worries me it that there were multiple reboots and shutdown
> > that goes up by itself without anyone pressing a button. And in
> > messages log there's fsck segment that indicates to unnormal shutdown
> > or reboot. It looks like it started to shutting down but was in some
> > case interrupted and after powering up it few times reboots itself.
> > But commonly FreeBSD doesn't reboot by it's own will.
> > The same hardware worked over a half a year under 8.0 stables without
> > such a problem. I just would like to understand from where this
> > problem comes up.
> > This machine doesn't contain any critical info so I'll wait for a bit.
> > Also I'd like to notice that recently I've tuned hdd's spindown exept
> > system hdd by atacontrol port, powerd and CPU frequency lowering in
> > idle, maybe something of this could cause this problem? And where
> > could I check this out?
>
> You might just want to go through your /etc/rc.d/*, crontabs,
> /etc/periodic/* and /etc/rc* to check for any commands that call
> shutdown(8) or reboot(8).
>
> Not really malicious but a rogue user that was once a staffer can plant
> a shutdown/reboot command in any one of the above matching files and
> have it run by at(1). This really sounds like the case here.
>
> 1). Check the above files. egrep -nr "(shutdown|reboot)" on those.
> 2). Inspect the files for at(1) reboot(8) shutdown(8) or paths to
> unintelligible binaries that have been setuid=0(u+s) owner=root.
> 3). Keep in mind a rogue staffer may have well cp(1) shutdown(8) to
> another command or created a script containing shutdown(8) to another
> command that matches another system command or has replaced one.
>
> Thats just a few things to go on for now. Others may have more to add t
