Re: SuperMicro i7 (UP) - very slow performance

2010-09-23 Thread Alexander Motin
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

Re: SuperMicro i7 (UP) - very slow performance

2010-09-23 Thread Andriy Gapon
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 _

Re: SuperMicro i7 (UP) - very slow performance

2010-09-23 Thread Daniel O'Connor
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 throttlin

Re: SuperMicro i7 (UP) - very slow performance

2010-09-23 Thread Bryce
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 throt

Re: SuperMicro i7 (UP) - very slow performance

2010-09-23 Thread Andriy Gapon
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 abou

[releng_8 tinderbox] failure on mips/mips

2010-09-23 Thread FreeBSD Tinderbox
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/b

Re: wifi issues under -stable

2010-09-23 Thread Torfinn Ingolfsen
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 allo

Re: SuperMicro i7 (UP) - very slow performance

2010-09-23 Thread Ian Smith
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 temp

Re: SuperMicro i7 (UP) - very slow performance

2010-09-23 Thread Alexander Motin
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 i

Re: SuperMicro i7 (UP) - very slow performance

2010-09-23 Thread Ian Smith
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 t

kernel: arpresolve: can't allocate llinfo for 10.6.10.240

2010-09-23 Thread Özkan KIRIK
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

Re: wifi issues under -stable

2010-09-23 Thread John Baldwin
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:

Re: FreeBSD 8.1 Stable Unreasanoble Rebooting

2010-09-23 Thread jhell
-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.

Re: FreeBSD 8.1 Stable Unreasanoble Rebooting

2010-09-23 Thread jhell
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

Re: SuperMicro i7 (UP) - very slow performance

2010-09-23 Thread Bryce
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

Re: BIND9 built w/--disable-ipv6 on 8.1-STABLE

2010-09-23 Thread Mark Andrews
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, Austra

Re: FreeBSD 8.1 Stable Unreasanoble Rebooting

2010-09-23 Thread Ian Smith
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