freebsd-stable Digest, Vol 349, Issue 6
freebsd-sta...@freebsd.org
freebsd...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
or, via email, send a message with subject or body 'help' to
freebsd-sta...@freebsd.org
You can reach the person managing the list at
freebsd-st...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-stable digest..."
Today's Topics:
1. Re: Multi node storage, ZFS (Ivan Voras)
2. 8-STABLE freezes on UDP traffic (DNS), 7.x doesn't (Attila Nagy)
3. Re: 8-STABLE freezes on UDP traffic (DNS), 7.x doesn't
(Michael Loftis)
4. Re: 8-STABLE freezes on UDP traffic (DNS), 7.x doesn't
(Mike Tancsa)
5. Exchange ActiveSync account (Jack Raats)
6. Re: 8.x Amd64, ATA SATA mode reporting (Alexander Motin)
7. Re: Exchange ActiveSync account (Torfinn Ingolfsen)
8. Re: 8-STABLE freezes on UDP traffic (DNS), 7.x doesn't
(Pyun YongHyeon)
9. Re: 8-STABLE freezes on UDP traffic (DNS), 7.x doesn't
(Pyun YongHyeon)
10. Re: 8-STABLE freezes on UDP traffic (DNS), 7.x doesn't
(Attila Nagy)
11. 8-STABLE/amd64: kernel panic after a minute of mounting xfs
(Nezmer)
12. Dtrong elcheapo-ZFS-disk recommendation [Was: Re: ahcich
timeouts, only with ahci, not with ataahci] (Harald Schmalzbauer)
13. Re: Powerd and est / eist functionality (Ian Smith)
14. Re: 8-STABLE/amd64: kernel panic after a minute of mounting
xfs (Peter Jeremy)
15. Re: Powerd and est / eist functionality (John Long)
16. Re: Powerd and est / eist functionality (Alexander Motin)
17. Re: Powerd and est / eist functionality (Jeremy Chadwick)
18. NFS lockd problem (Giulio Ferro)
----------------------------------------------------------------------
Message: 1
Date: Thu, 25 Mar 2010 14:01:21 +0100
From: Ivan Voras <ivo...@freebsd.org>
Subject: Re: Multi node storage, ZFS
To: freebsd...@freebsd.org
Message-ID: <hofmr0$i08$1...@dough.gmane.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 03/25/10 00:45, Michal wrote:
> backend storage for databases. It's all well and good having 1 ZFS
> server, but it's fragile in the the sense of no redundancy, then we have
> 1 ZFS server and a 2nd with DRBD, but that's a waste of money...think 12
> TB, and you need to pay for another 12TB box for redundancy, and you are
> still looking at 1 server. I am thinking a cheap solution but one that
> has IO throughput, redundancy and is easy to manange and expand across
> multiple nodes.
Well, what I described is kind of like that, centered around trying to
best balance redundancy and cost. For example, you don't need two 12 TB
boxes in a mirror. Depending on what you need you can get only one 12 TB
box at the start, then with ZFS trivially extend that storage with
another 12 TB box when you need it, repeat to infinity (each box will
internally have RAID6 or something like that). Of course then you have a
problem if a single box fails, which you can get around by using
triplets of 12 TB boxes in RAIDZ, etc. etc.
------------------------------
Message: 2
Date: Thu, 25 Mar 2010 15:22:04 +0100
From: Attila Nagy <b...@fsn.hu>
Subject: 8-STABLE freezes on UDP traffic (DNS), 7.x doesn't
To: Mailing List FreeBSD Stable <freebsd...@FreeBSD.org>
Message-ID: <4BAB718C...@fsn.hu>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Hi,
I have some recursive nameservers, running unbound and 7.2-STABLE #0:
Wed Sep 2 13:37:17 CEST 2009 on a bunch of HP BL460c machines (bce
interfaces).
These work OK.
During the process of migrating to 8.x, I've upgraded one of these
machines to 8.0-STABLE #25: Tue Mar 9 18:15:34 CET 2010 (the dates
indicate an approximate time, when the source was checked out from
cvsup.hu.freebsd.org, I don't know the exact revision).
The first problem was that the machine occasionally lost network access
for some minutes. I could log in on the console, and I could see the
processes, involved in network IO in "keglim" state, but couldn't do any
network IO. This lasted for some minutes, then everything came back to
normal.
I could fix this issue by raising kern.ipc.nmbclusters to 51200
(doubling from its default size), when I can't see these blackouts.
But now the machine freezes. It can run for about a day, and then it
just freezes. I can't even break in to the debugger with sending NMI to it.
top says:
last pid: 92428; load averages: 0.49, 0.40, 0.38 up 0+21:13:18
07:41:43
43 processes: 2 running, 38 sleeping, 1 zombie, 2 lock
CPU: 1.3% user, 0.0% nice, 1.3% system, 26.0% interrupt, 71.3% idle
Mem: 1682M Active, 99M Inact, 227M Wired, 5444K Cache, 44M Buf, 5899M Free
Swap:
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
45011 bind 4 49 0 1734M 1722M RUN 2 37:42 22.17% unbound
712 bind 3 44 0 70892K 19904K uwait 0 71:07 3.86%
python2.6
The common in these freezes seems to be the high interrupt count.
Normally, during load the CPU times look like this:
CPU: 3.5% user, 0.0% nice, 1.8% system, 0.4% interrupt, 94.4% idle
I could observe a "freeze", where top remained running and everything
was 0%, except interrupt, which was 25% exactly (the machine has four
cores), and another, where I could save the following console output:
CPU: 0.0% user, 0.0% nice, 0.2% system, 50.0% interrupt, 49.8% idle
.......(partial, broken line)....32M 2423M *udp 1 50:16 10.89% unbound
714 bind 3 44 0 70892K 26852K uwait 3 8:41 4.69%
python2.6
61004 root 1 62 0 37428K 10876K *udp 1 0:00 1.56% python
706 root 1 44 0 2696K 624K piperd 1 0:07 0.00%
readproctit
Both unbound and python accepts DNS requests, and it seems when 25%
interrupt happens, only unbound is in *udp state, where it is 50%, both
programs are in that state.
------------------------------
Message: 3
Date: Thu, 25 Mar 2010 09:39:40 -0600
From: Michael Loftis <mlo...@wgops.com>
Subject: Re: 8-STABLE freezes on UDP traffic (DNS), 7.x doesn't
To: Mailing List FreeBSD Stable <freebsd...@FreeBSD.org>
Message-ID: <886B21E1787F0003B89E34B6@[192.168.1.44]>
Content-Type: text/plain; charset=us-ascii; format=flowed
--On Thursday, March 25, 2010 3:22 PM +0100 Attila Nagy <b...@fsn.hu> wrote:
<...>
> Both unbound and python accepts DNS requests, and it seems when 25%
> interrupt happens, only unbound is in *udp state, where it is 50%, both
> programs are in that state.
Try turning of hardware TSO/checksum offload if it's availble on your
chipset? ifconfig <interface> -rxcsum -txcsum -tso -- I'm only using nfe
chips right now, but w/ the TSO/CSUM on they lock up constantly under high
load. We're pretty sure it's mostly the nfe driver, or the chips
themselves, but have never ruled out some generic 8.x hardware offload
issues.
------------------------------
Message: 4
Date: Thu, 25 Mar 2010 11:48:02 -0400
From: Mike Tancsa <mi...@sentex.net>
Subject: Re: 8-STABLE freezes on UDP traffic (DNS), 7.x doesn't
To: freebsd...@freebsd.org
Message-ID: <201003251548....@lava.sentex.ca>
Content-Type: text/plain; charset="us-ascii"; format=flowed
At 11:39 AM 3/25/2010, Michael Loftis wrote:
>--On Thursday, March 25, 2010 3:22 PM +0100 Attila Nagy <b...@fsn.hu> wrote:
>
><...>
>>Both unbound and python accepts DNS requests, and it seems when 25%
>>interrupt happens, only unbound is in *udp state, where it is 50%, both
>>programs are in that state.
>
>Try turning of hardware TSO/checksum offload if it's availble on
>your chipset? ifconfig <interface> -rxcsum -txcsum -tso -- I'm only
>using nfe chips right now, but w/ the TSO/CSUM on they lock up
>constantly under high load. We're pretty sure it's mostly the nfe
>driver, or the chips themselves, but have never ruled out some
>generic 8.x hardware offload issues.
There were also a bunch of commits last night for the bce driver. If
its the NIC in RELENG_8, perhaps those bug fixes might help
<http://lists.freebsd.org/pipermail/svn-src-stable-8/2010-March/001804.html>http://lists.freebsd.org/pipermail/svn-src-stable-8/2010-March/001804.html
http://lists.freebsd.org/pipermail/svn-src-stable-8/2010-March/001803.html
---Mike
>_______________________________________________
>freebsd...@freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>To unsubscribe, send any mail to "freebsd-stabl...@freebsd.org"
--------------------------------------------------------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mi...@sentex.net
Providing Internet since 1994 www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike
------------------------------
Message: 5
Date: Thu, 25 Mar 2010 14:11:00 +0100
From: "Jack Raats" <ja...@jarasoft.net>
Subject: Exchange ActiveSync account
To: <freebsd...@freebsd.org>, <freebsd-...@freebsd.org>,
<postfi...@postfix.org>
Message-ID: <4FBFE9F90804409B855AD118FE27B11E@jarasc430>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I have an Exchange ActiveSync account and I would like to get this mail on my freebsd 7.3-stable server.
I donn't haven an imap or pop account, only the information of the activesync account.
Can anyone give me a clue how to achieve this?
Thanks for your time!
Jack Raats
------------------------------
Message: 6
Date: Thu, 25 Mar 2010 19:17:26 +0200
From: Alexander Motin <m...@FreeBSD.org>
Subject: Re: 8.x Amd64, ATA SATA mode reporting
To: John Long <fb...@sstec.com>
Cc: freeBSD-STABLE Mailing List <freebsd...@freebsd.org>
Message-ID: <4BAB9AA6...@FreeBSD.org>
Content-Type: text/plain; charset=ISO-8859-1
John Long wrote:
> Moved from another thread
>>> I csupd to stable amd64 8.0 and rebuilt then noticed from dmesg that
> I went from SATA150 (it should be SATA300) to >> udma100 SATA.
>>
>>This is a bug/quirk of some changes in ata(4). Your drive should be
>>operating at full SATA speed (probably SATA300). You can bring this up
>>in another thread if you want, but it's purely cosmetic as far as I
>>know. atacontrol(8) and diskinfo(8) -t and -c will come in handy.
>
> I am looking for stability and find this possibly disconcerting.
> It looks like you are right about cosmetic for the speed test is about
> the same in either. In Generic atacontrol cannot determine the mode at
> all and in stable it shows up but as the wrong thing, udma100 SATA
> instead of SATA300.
The problem is that ICH7 chipset unable to report negotiated SATA speed.
That's why only SATA reported there.
UDMA100 report is also correct there (even if it looks strange). As SATA
just wraps all existing parallel ATA protocols, from ATA protocol point
of view that mode is active.
--
Alexander Motin
------------------------------
Message: 7
Date: Thu, 25 Mar 2010 19:18:04 +0100
From: Torfinn Ingolfsen <torfinn....@broadpark.no>
Subject: Re: Exchange ActiveSync account
To: freebsd...@freebsd.org
Message-ID: <20100325191804.73c0c...@broadpark.no>
Content-Type: text/plain; CHARSET=US-ASCII
On Thu, 25 Mar 2010 14:11:00 +0100
Jack Raats <ja...@jarasoft.net> wrote:
> I have an Exchange ActiveSync account and I would like to get this mail on my freebsd 7.3-stable server.
> I donn't haven an imap or pop account, only the information of the activesync account.
>
> Can anyone give me a clue how to achieve this?
>From http://en.wikipedia.org/wiki/Activesync
"Activesync uses ActiveSync Exchange, a proprietary protocol, requiring
other vendors to license the protocol to achieve compatibility."
In other words; it might not be possible.
HTH
--
Regards,
Torfinn Ingolfsen
------------------------------
Message: 8
Date: Thu, 25 Mar 2010 11:36:28 -0700
From: Pyun YongHyeon <pyu...@gmail.com>
Subject: Re: 8-STABLE freezes on UDP traffic (DNS), 7.x doesn't
To: Attila Nagy <b...@fsn.hu>
Cc: Mailing List FreeBSD Stable <freebsd...@freebsd.org>
Message-ID: <2010032518...@michelle.cdnetworks.com>
Content-Type: text/plain; charset=us-ascii
On Thu, Mar 25, 2010 at 03:22:04PM +0100, Attila Nagy wrote:
> Hi,
>
> I have some recursive nameservers, running unbound and 7.2-STABLE #0:
> Wed Sep 2 13:37:17 CEST 2009 on a bunch of HP BL460c machines (bce
> interfaces).
> These work OK.
>
> During the process of migrating to 8.x, I've upgraded one of these
> machines to 8.0-STABLE #25: Tue Mar 9 18:15:34 CET 2010 (the dates
> indicate an approximate time, when the source was checked out from
> cvsup.hu.freebsd.org, I don't know the exact revision).
>
> The first problem was that the machine occasionally lost network access
> for some minutes. I could log in on the console, and I could see the
> processes, involved in network IO in "keglim" state, but couldn't do any
> network IO. This lasted for some minutes, then everything came back to
> normal.
> I could fix this issue by raising kern.ipc.nmbclusters to 51200
> (doubling from its default size), when I can't see these blackouts.
>
> But now the machine freezes. It can run for about a day, and then it
> just freezes. I can't even break in to the debugger with sending NMI to it.
> top says:
> last pid: 92428; load averages: 0.49, 0.40, 0.38 up 0+21:13:18
> 07:41:43
> 43 processes: 2 running, 38 sleeping, 1 zombie, 2 lock
> CPU: 1.3% user, 0.0% nice, 1.3% system, 26.0% interrupt, 71.3% idle
> Mem: 1682M Active, 99M Inact, 227M Wired, 5444K Cache, 44M Buf, 5899M Free
> Swap:
>
> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
> 45011 bind 4 49 0 1734M 1722M RUN 2 37:42 22.17% unbound
> 712 bind 3 44 0 70892K 19904K uwait 0 71:07 3.86%
> python2.6
>
> The common in these freezes seems to be the high interrupt count.
> Normally, during load the CPU times look like this:
> CPU: 3.5% user, 0.0% nice, 1.8% system, 0.4% interrupt, 94.4% idle
>
> I could observe a "freeze", where top remained running and everything
> was 0%, except interrupt, which was 25% exactly (the machine has four
> cores), and another, where I could save the following console output:
> CPU: 0.0% user, 0.0% nice, 0.2% system, 50.0% interrupt, 49.8% idle
When you see high number of interrupts, could you check this comes
from bce(4)? I guess you can use systat(1) to check how many number
interrupts are generated from bce(4).
> .......(partial, broken line)....32M 2423M *udp 1 50:16 10.89% unbound
> 714 bind 3 44 0 70892K 26852K uwait 3 8:41 4.69%
> python2.6
> 61004 root 1 62 0 37428K 10876K *udp 1 0:00 1.56% python
> 706 root 1 44 0 2696K 624K piperd 1 0:07 0.00%
> readproctit
>
> Both unbound and python accepts DNS requests, and it seems when 25%
> interrupt happens, only unbound is in *udp state, where it is 50%, both
> programs are in that state.
------------------------------
Message: 9
Date: Thu, 25 Mar 2010 11:52:58 -0700
From: Pyun YongHyeon <pyu...@gmail.com>
Subject: Re: 8-STABLE freezes on UDP traffic (DNS), 7.x doesn't
To: Michael Loftis <mlo...@wgops.com>
Cc: Mailing List FreeBSD Stable <freebsd...@freebsd.org>
Message-ID: <2010032518...@michelle.cdnetworks.com>
Content-Type: text/plain; charset=us-ascii
On Thu, Mar 25, 2010 at 09:39:40AM -0600, Michael Loftis wrote:
>
>
> --On Thursday, March 25, 2010 3:22 PM +0100 Attila Nagy <b...@fsn.hu> wrote:
>
> <...>
> >Both unbound and python accepts DNS requests, and it seems when 25%
> >interrupt happens, only unbound is in *udp state, where it is 50%, both
> >programs are in that state.
>
> Try turning of hardware TSO/checksum offload if it's availble on your
> chipset? ifconfig <interface> -rxcsum -txcsum -tso -- I'm only using nfe
> chips right now, but w/ the TSO/CSUM on they lock up constantly under high
> load. We're pretty sure it's mostly the nfe driver, or the chips
If you have nfe(4) issues please file PR for that. I'm not aware of
TSO, Tx checksum offloading related issue of nfe(4). Due to lack of
documentation for the controller it might be hard to analyze the
issue but it may help other users who are suffering from the same
issue.
> themselves, but have never ruled out some generic 8.x hardware offload
> issues.
------------------------------
Message: 10
Date: Thu, 25 Mar 2010 20:30:56 +0100
From: Attila Nagy <b...@fsn.hu>
Subject: Re: 8-STABLE freezes on UDP traffic (DNS), 7.x doesn't
To: pyu...@gmail.com
Cc: Mailing List FreeBSD Stable <freebsd...@freebsd.org>
Message-ID: <4BABB9F0...@fsn.hu>
Content-Type: text/plain; charset=ISO-8859-1
Pyun YongHyeon wrote:
> On Thu, Mar 25, 2010 at 03:22:04PM +0100, Attila Nagy wrote:
>
>> Hi,
>>
>> I have some recursive nameservers, running unbound and 7.2-STABLE #0:
>> Wed Sep 2 13:37:17 CEST 2009 on a bunch of HP BL460c machines (bce
>> interfaces).
>> These work OK.
>>
>> During the process of migrating to 8.x, I've upgraded one of these
>> machines to 8.0-STABLE #25: Tue Mar 9 18:15:34 CET 2010 (the dates
>> indicate an approximate time, when the source was checked out from
>> cvsup.hu.freebsd.org, I don't know the exact revision).
>>
>> The first problem was that the machine occasionally lost network access
>> for some minutes. I could log in on the console, and I could see the
>> processes, involved in network IO in "keglim" state, but couldn't do any
>> network IO. This lasted for some minutes, then everything came back to
>> normal.
>> I could fix this issue by raising kern.ipc.nmbclusters to 51200
>> (doubling from its default size), when I can't see these blackouts.
>>
>> But now the machine freezes. It can run for about a day, and then it
>> just freezes. I can't even break in to the debugger with sending NMI to it.
>> top says:
>> last pid: 92428; load averages: 0.49, 0.40, 0.38 up 0+21:13:18
>> 07:41:43
>> 43 processes: 2 running, 38 sleeping, 1 zombie, 2 lock
>> CPU: 1.3% user, 0.0% nice, 1.3% system, 26.0% interrupt, 71.3% idle
>> Mem: 1682M Active, 99M Inact, 227M Wired, 5444K Cache, 44M Buf, 5899M Free
>> Swap:
>>
>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
>> 45011 bind 4 49 0 1734M 1722M RUN 2 37:42 22.17% unbound
>> 712 bind 3 44 0 70892K 19904K uwait 0 71:07 3.86%
>> python2.6
>>
>> The common in these freezes seems to be the high interrupt count.
>> Normally, during load the CPU times look like this:
>> CPU: 3.5% user, 0.0% nice, 1.8% system, 0.4% interrupt, 94.4% idle
>>
>> I could observe a "freeze", where top remained running and everything
>> was 0%, except interrupt, which was 25% exactly (the machine has four
>> cores), and another, where I could save the following console output:
>> CPU: 0.0% user, 0.0% nice, 0.2% system, 50.0% interrupt, 49.8% idle
>>
>
> When you see high number of interrupts, could you check this comes
> from bce(4)? I guess you can use systat(1) to check how many number
> interrupts are generated from bce(4).
>
I've tried it multiple times, but couldn't yet catch the moment when the
machine was still alive (so the script could run) and there were
increased amount of interrupts.
------------------------------
Message: 11
Date: Thu, 25 Mar 2010 21:32:10 +0200
From: Nezmer <b...@nezmer.info>
Subject: 8-STABLE/amd64: kernel panic after a minute of mounting xfs
To: freebsd...@freebsd.org
Message-ID: <20100325193127.GA80926@mail>
Content-Type: text/plain; charset=us-ascii
(8-STABLE/amd64 Feb 25th)
Hi,
This is the 1st time FreeBSD panics on me. It happened after a
minute of mounting an XFS partition. I'm not sure It's XFS but It's the
only part of the OS I try for the 1st time.
kernel: vn_iowait doing nothing on FreeBSD?
last message repeated 15 times
kernel:
kernel:
kernel: Fatal trap 12: page fault while in kernel mode
kernel: cpuid = 1; apic id = 01
kernel: fault virtual address = 0x290
kernel: fault code = supervisor read data, page not present
kernel: instruction pointer = 0x20:0xffffffff8057e38e
kernel: stack pointer = 0x28:0xffffff80790af7d0
kernel: frame pointer = 0x28:0xffffff80790af7f0
kernel: code segment = base 0x0, limit 0xfffff, type 0x1b
kernel: = DPL 0, pres 1, long 1, def32 0, gran 1
kernel: processor eflags = interrupt enabled, resume, IOPL = 0
kernel: current process = 4668 (umount)
kernel: trap number = 12
kernel: panic: page fault
kernel: cpuid = 1
kernel: Uptime: 31m48s
kernel: Cannot dump. Device not defined or unavailable.
kernel: Automatic reboot in 15 seconds - press a key on the console to abort
kernel: --> Press a key on the console to reboot,
kernel: --> or switch off the system now.
kernel: Rebooting...
------------------------------
Message: 12
Date: Fri, 26 Mar 2010 00:04:41 +0100
From: Harald Schmalzbauer <h.schma...@omnilan.de>
Subject: Dtrong elcheapo-ZFS-disk recommendation [Was: Re: ahcich
timeouts, only with ahci, not with ataahci]
To: Jeremy Chadwick <fre...@jdc.parodius.com>
Cc: Alexander Motin <m...@freebsd.org>, freebsd...@freebsd.org
Message-ID: <4BABEC09...@omnilan.de>
Content-Type: text/plain; charset="iso-8859-1"
Harald Schmalzbauer schrieb am 14.03.2010 12:12 (localtime):
> Harald Schmalzbauer schrieb am 13.03.2010 22:27 (localtime):
>> Am 03.03.2010 12:06, schrieb Jeremy Chadwick:
>>> On Wed, Mar 03, 2010 at 09:28:25AM +0100, Harald Schmalzbauer wrote:
>>>> Alexander Motin schrieb am 03.03.2010 09:18 (localtime):
>>>>> Harald Schmalzbauer wrote:
>>>>>> Alexander Motin schrieb am 23.02.2010 16:10 (localtime):
>>>>>>> Harald Schmalzbauer wrote:
>>>>>>>> I'm frequently getting my machine locked with ahcichX timeouts:
>>>>>>>> ahcich2: Timeout on slot 0
>>>>>>>> ahcich2: is 00000000 cs 00000001 ss 00000000 rs 00000001 tfd c0
>>>>>>>> serr
>>>>>>>> 00000000
>>>>>>>> ahcich2: Timeout on slot 8
>>>>>>>> ahcich2: is 00000000 cs 00000100 ss 00000000 rs 00000100 tfd c0
>>>>>>>> serr
>>>>>>>> 00000000
>>>>>>>> ahcich2: Timeout on slot 8
>>>>>>>> ahcich2: is 00000000 cs fffff07f ss ffffff7f rs ffffff7f tfd c0
>>>>>>>> serr
>>>>>>>> 00000000
>>>>>>>> ...
>>>>>>> Looking that is (Interrupt status) is zero and `rs == cs | ss`
>>>>>>> (running
>>>>>>> command bitmasks in driver and hardware), controller doesn't report
>>>>>>> command completion. Looking on TFD status 0xc0 with BUSY bit set, I
>>>>>>> would suppose that either disk stuck in command processing for some
>>>>>>> reason, or controller missed command completion status.
>>>>>>>
>>>>>>> Have you noticed 30 second (default ATA timeout) pause before
>>>>>>> timeout
>>>>>>> message printed? Just want to be sure that driver waited enough
>>>>>>> before
>>>>>>> give up.
>>>>>>>
>>>>>>>> This happens when backup over GbE overloads ZFS/HDD capabilities.
>>>>>>>> I reduced vfs.zfs.txg.timeout to 1 to prevent the machine from
>>>>>>>> locking
>>>>>>>> up almost immediately, but from it still happens.
>>>>>>>> When I don't use ahci but ataahci (the old driver if I
>>>>>>>> understand things
>>>>>>>> correct) I also see the ZFS burst write congestion, but this
>>>>>>>> doesn't
>>>>>>>> lead to controller timeouts, thus blocking the machine.
>>>>>>>>
>>>>>>>> Sometimes the machine recovers from the disk lock, but most
>>>>>>>> often I have
>>>>>>>> to reboot.
>>>>>>> How it looks when it doesn't? Can you send me full log messages?
>>>>>> Hello, this morning I had a stall, but the machine recovered after
>>>>>> about
>>>>>> one Minute. Here's what I got from the kernel:
>>>>>> ahcich2: Timeout on slot 29
>>>>>> ahcich2: is 00000000 cs 00000003 ss e0000003 rs e0000003 tfd c0 serr
>>>>>> 00000000
>>>>>> em1: watchdog timeout -- resetting
>>>>>> em1: watchdog timeout -- resetting
>>>>>> ahcich2: Timeout on slot 10
>>>>>> ahcich2: is 00000000 cs 00006000 ss 00007c00 rs 00007c00 tfd c0 serr
>>>>>> 00000000
>>>>>> ahcich2: Timeout on slot 18
>>>>>> ahcich2: is 00000000 cs 00040000 ss 00000000 rs 00040000 tfd c0 serr
>>>>>> 00000000
>>>>>> ahcich2: Timeout on slot 2
>>>>>> ahcich2: is 00000000 cs 00000004 ss 00000000 rs 00000004 tfd c0 serr
>>>>>> 00000000
>>>>>> ahcich2: Timeout on slot 2
>>>>>> ahcich2: is 00000000 cs 00000000 ss 0000000c rs 0000000c tfd 40 serr
>>>>>> 00000000
>>>>>>
>>>>>> Does this tell you something useful?
>>>>> It doesn't. Looking on logged register content - commands are indeed
>>>>> still running and no interrupts requested. Interesting to see em1
>>>>> watchdog timeout there. Aren't they related somehow?
>>>> dmesg | grep "irq 18":
>>>> uhci0: <Intel 82801I (ICH9) USB controller> port 0x20c0-0x20df irq
>>>> 18 at device 26.0 on pci0
>>>> uhci4: <Intel 82801I (ICH9) USB controller> port 0x2040-0x205f irq
>>>> 18 at device 29.2 on pci0
>>>> em1: <Intel(R) PRO/1000 Network Connection 6.9.14> port
>>>> 0x1000-0x103f mem 0xe1920000-0xe193ffff,0xe1900000-0xe191ffff irq 18
>>>> at device 2.0 on pci3
>>>> ichsmb0: <Intel 82801I (ICH9) SMBus controller> port 0x2000-0x201f
>>>> mem 0xe1a22000-0xe1a220ff irq 18 at device 31.3 on pci0
>>>>
>>>> The don't share the same IRQ at least.
...
For the records: I replaced the Samsung F2 1.5TB 5200rpm EcoGreen Drives.
In my dreams that should improove my 3-disk RAIDZ from 33MB/s avarage
(>5G transferes) to about 60MB/s.
In reality, it improoved it to 90MB/s, _and_ completely eliminatong the
ahcich timeouts, as well as the burst writes where the complete machine
stuck while ZFS flushed/wrote trransaction groups.
So the difference in ZFS usage between the disks is far beond my
imagination.
I can higly recommend the:
=== START OF INFORMATION SECTION ===
Model Family: Hitachi Deskstar 7K2000
Device Model: Hitachi HDS722020ALA330
Serial Number: JK1174YAH9ZH7W
Firmware Version: JKAOA28A
User Capacity: 2,000,398,934,016 bytes
Device is: In smartctl database [for details use: -P show]
ATA Version is: 8
ATA Standard is: ATA-8-ACS revision 4
Local Time is: Thu Mar 25 23:48:13 2010 CET
Some TB restored so far, no errors, no oddities, no problems at all.
Same server, same FreeBSD, but ahci.ko enabled again (so with NCQ,
thanks mav and friends).
I can confirm that the F2 Samsung drives worked fine with the old ata
driver (speaking without enabling NQC) and ZFS. They did their job for 2
weeks without any error in that time, but reproducable showed ahcich
timeouts (with the newer ahci.ko) if load was higher than about 50MB/s
@raizd with 3 disks (same ICH9)
So if I got my problem solved by replacing my HDDs (even the old one had
the latest firmware) ans also got triple performance :))
Just to share the info.
Thanks,
-Harry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100325/140d48ba/signature-0001.pgp
------------------------------
Message: 13
Date: Fri, 26 Mar 2010 15:24:20 +1100 (EST)
From: Ian Smith <smi...@nimnet.asn.au>
Subject: Re: Powerd and est / eist functionality
To: John Long <fb...@sstec.com>
Cc: Alexander Motin <m...@freebsd.org>, FreeBSD-STABLE Mailing List
<freebsd...@freebsd.org>
Message-ID: <2010032600...@sola.nimnet.asn.au>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 24 Mar 2010, John Long wrote:
> At 11:27 PM 3/22/2010, Alexander Motin wrote:
> >John Long wrote:
> >> Hello, I am putting together a couple update servers. Went with c2d
> >> E7500 on gigabyte G41M-ES2L boards. fbsd 8.0 release generic (so far)
> >> amd64, 1g mem, 1tb wd cavier blk, fresh system.
> >> My Kill-a-watt shows 41 watts idle and when I enable powerd then it
> >> climbs to 43 watts idle.
I'm interested in this apparently strange finding. Can you show sysctl
dev.cpu after boot but before running powerd, and after starting powerd?
I wonder particularly what dev.cpu.o.freq is before running powerd, ie
whether it boots up at full speed? We've seen some that haven't,
perhaps influenced by BIOS settings?
Turning on debug.cpufreq.verbose and hw.acpi.verbose may add clues?
> >> It shows that the freq is controlled well, goes down to 365 mhz but
> >> the tdp is not decreased, rather it increases.
Yes you're only getting p4tcc throttling as Alexander points out. You'll
need to get est working to get power reduction from lower frequencies,
which likely won't correspond to these f/8 step throttling frequencies.
As Jeremy suggested, here's how to turn throttling off, and something
like what you could expect with est working:
http://lists.freebsd.org/pipermail/freebsd-stable/2010-March/055666.html
> >> If I disable eist, c1 and c3 helpers in bios, as per suggestion in
> >> mail archive, then it adds 1 watt to both figures. I was hoping to get
> >> this total tdp down to a very low amount, and it is but it should
> >> theoretically go lower with powerd, right?
If powerd were actually reducing frequency (and voltage) via est it
certainly would. Finding out why est is failing to attach on your
hardware is the only likely path to success, try focusing on that and
ignoring side issues. Have you browsed freebsd-acpi archives re this?
> >> load 3%, current freq 365 MHz ( 7), wanted freq 365 MHz
> >> load 0%, current freq 365 MHz ( 7), wanted freq 365 MHz
> >
> >Your ACPI BIOS seems not reporting tables required to control EIST. So
> >powerd probably uses only thermal throttling, which is not really
> >effective for power saving on modern CPUs. You should check your BIOS
> >options or may be update BIOS.
> >
> >If you have no luck with EIST - try to use C-states if BIOS reports at
> >least them. It also can be quite effective.
> >
> >--
> >Alexander Motin
>
> Thanks for the info, I did try to kick it to C3 and that helped poquito
> amount. Everything is enabled in bios that matters to this, that does help a
> little too but powerd actually raises tdp a little. See other recent reply
> for more info.
Have you tried C2? Are you running the latest BIOS? And perhaps your
ACPI ASL may be amenable to repair, if Gigabyte ACPI is broken here?
cheers, Ian
------------------------------
Message: 14
Date: Fri, 26 Mar 2010 18:11:06 +1100
From: Peter Jeremy <peter...@acm.org>
Subject: Re: 8-STABLE/amd64: kernel panic after a minute of mounting
xfs
To: Nezmer <b...@nezmer.info>
Cc: freebsd...@freebsd.org
Message-ID: <20100326071...@server.vk2pj.dyndns.org>
Content-Type: text/plain; charset="us-ascii"
On 2010-Mar-25 21:32:10 +0200, Nezmer <b...@nezmer.info> wrote:
>This is the 1st time FreeBSD panics on me. It happened after a
>minute of mounting an XFS partition. I'm not sure It's XFS but It's the
>only part of the OS I try for the 1st time.
>
>kernel: vn_iowait doing nothing on FreeBSD?
This is part of XFS. I'm not sure how important it is.
>kernel: Fatal trap 12: page fault while in kernel mode
...
>kernel: Cannot dump. Device not defined or unavailable.
Unfortunately, there's not much that can be done given this
information. As a minimum, you need a backtrace. Ideally, you need a
core-dump to investigate the cause.
See http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html
--
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100326/ce2b0913/attachment-0001.pgp
------------------------------
Message: 15
Date: Fri, 26 Mar 2010 01:20:19 -0700
From: John Long <fb...@sstec.com>
Subject: Re: Powerd and est / eist functionality
To: Ian Smith <smi...@nimnet.asn.au>
Cc: Alexander Motin <m...@freebsd.org>, FreeBSD-STABLE Mailing List
<freebsd...@freebsd.org>
Message-ID: <5.2.1.1.2.201003...@mail.sstec.com>
Content-Type: text/plain; charset="us-ascii"; format=flowed
At 09:24 PM 3/25/2010, Ian Smith wrote:
>On Wed, 24 Mar 2010, John Long wrote:
> > At 11:27 PM 3/22/2010, Alexander Motin wrote:
> > >John Long wrote:
> > >> Hello, I am putting together a couple update servers. Went with c2d
> > >> E7500 on gigabyte G41M-ES2L boards. fbsd 8.0 release generic (so
far)
> > >> amd64, 1g mem, 1tb wd cavier blk, fresh system.
> > >> My Kill-a-watt shows 41 watts idle and when I enable powerd then it
> > >> climbs to 43 watts idle.
>
>I'm interested in this apparently strange finding. Can you show sysctl
>dev.cpu after boot but before running powerd, and after starting powerd?
>
>I wonder particularly what dev.cpu.o.freq is before running powerd, ie
>whether it boots up at full speed? We've seen some that haven't,
>perhaps influenced by BIOS settings?
Bios is most recent re their site. F6 I believe. boots to same 41 watts.
%sysctl dev.cpu
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.freq: 2933
dev.cpu.0.freq_levels: 2933/-1 2566/-1 2199/-1 1833/-1 1466/-1 1099/-1
733/-1 366/-1
dev.cpu.0.cx_supported: C1/1 C2/1 C3/150
dev.cpu.0.cx_lowest: C1
dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 500us
dev.cpu.1.%desc: ACPI CPU
dev.cpu.1.%driver: cpu
dev.cpu.1.%location: handle=\_PR_.CPU1
dev.cpu.1.%pnpinfo: _HID=none _UID=0
dev.cpu.1.%parent: acpi0
dev.cpu.1.cx_supported: C1/1 C2/1 C3/150
dev.cpu.1.cx_lowest: C1
dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% last 500us
%powerd -n adp
about 3 secs later
%sysctl dev.cpu
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.freq: 1833
dev.cpu.0.freq_levels: 2933/-1 2566/-1 2199/-1 1833/-1 1466/-1 1099/-1
733/-1 366/-1
dev.cpu.0.cx_supported: C1/1 C2/1 C3/150
dev.cpu.0.cx_lowest: C1
dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 500us
dev.cpu.1.%desc: ACPI CPU
dev.cpu.1.%driver: cpu
dev.cpu.1.%location: handle=\_PR_.CPU1
dev.cpu.1.%pnpinfo: _HID=none _UID=0
dev.cpu.1.%parent: acpi0
dev.cpu.1.cx_supported: C1/1 C2/1 C3/150
dev.cpu.1.cx_lowest: C1
dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% last 500us
wait about 10 more sec and it is down to min freq and pwr is up to 44 watts.
%sysctl dev.cpu
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.freq: 366
dev.cpu.0.freq_levels: 2933/-1 2566/-1 2199/-1 1833/-1 1466/-1 1099/-1
733/-1 366/-1
dev.cpu.0.cx_supported: C1/1 C2/1 C3/150
dev.cpu.0.cx_lowest: C1
dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 500us
dev.cpu.1.%desc: ACPI CPU
dev.cpu.1.%driver: cpu
dev.cpu.1.%location: handle=\_PR_.CPU1
dev.cpu.1.%pnpinfo: _HID=none _UID=0
dev.cpu.1.%parent: acpi0
dev.cpu.1.cx_supported: C1/1 C2/1 C3/150
dev.cpu.1.cx_lowest: C1
dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% last 500us
>Turning on debug.cpufreq.verbose and hw.acpi.verbose may add clues?
Either of the above makes no change in dev.cpu out but sysctl -a gets
really noisy in places
cpufreq: dup done, inserting new level 1833 after 2199
cpufreq: expand set added rel setting 62% to 1833 level
cpufreq: dup set considering derived setting 1466
cpufreq: removed last relative driver: p4tcc1
cpufreq: dup done, inserting new level 1466 after 1833
cpufreq: expand set added rel setting 50% to 1466 level
cpufreq: dup set considering derived setting 1099
cpufreq: removed last relative driver: p4tcc1
cpufreq: dup done, inserting new level 1099 after 1466
cpufreq: expand set added rel setting 37% to 1099 level
cpufreq: dup set considering derived setting 733
cpufreq: removed last relative driver: p4tcc1
cpufreq: dup done, inserting new level 733 after 1099
cpufreq: expand set added rel setting 25% to 733 level
cpufreq: dup set considering derived setting 366
cpufreq: removed last relative driver: p4tcc1
cpufreq: dup done, inserting new level 366 after 733
cpufreq: expand set added rel setting 12% to 366 level
cpufreq: setting rel freq 10000 on p4tcc1 (cpu 1)
cpufreq: get returning known freq 2933
cpufreq: get returning known freq 2933
cpufreq: get returning known freq 2933
cpufreq: get returning known freq 2933
cpufreq: get returning known freq 2933
cpufreq: get returning known freq 2933
cpufreq: get returning known freq 2933
cpufreq: get returning known freq 2933
cpufreq: get returning known freq 2933
cpufreq: get returning known freq 2933
cpufreq: get returning known freq 2933
cpufreq: get returning known freq 2933
cpufreq: get returning known freq 2933
cpufreq: get returning known freq 2933
cpufreq: get returning known freq 2933
cpufreq: get returning known freq 2933
cpufreq: adding 8 relative settings
cpufreq: adding abs setting 2933 at head
cpufreq: expand set added rel setting 100% to 2933 level
cpufreq: dup set considering derived setting 2566
cpufreq: removed last relative driver: p4tcc0
cpufreq: dup done, inserting new level 2566 after 2933
cpufreq: expand set added rel setting 87% to 2566 level
cpufreq: dup set considering derived setting 2199
cpufreq: removed last relative driver: p4tcc0
cpufreq: dup done, inserting new level 2199 after 2566
cpufreq: expand set added rel setting 75% to 2199 level
cpufreq: dup set considering derived setting 1833
cpufreq: removed last relative driver: p4tcc0
cpufreq: dup done, inserting new level 1833 after 2199
cpufreq: expand set added rel setting 62% to 1833 level
cpufreq: dup set considering derived setting 1466
cpufreq: removed last relative driver: p4tcc0
cpufreq: dup done, inserting new level 1466 after 1833
cpufreq: expand set added rel setting 50% to 1466 level
cpufreq: dup set considering derived setting 1099
........
Hundreds of those lines, Keeps repeating, fast to slow to fast etc...
>
> > >> It shows that the freq is controlled well, goes down to 365 mhz but
> > >> the tdp is not decreased, rather it increases.
>
>Yes you're only getting p4tcc throttling as Alexander points out. You'll
>need to get est working to get power reduction from lower frequencies,
>which likely won't correspond to these f/8 step throttling frequencies.
>
>As Jeremy suggested, here's how to turn throttling off, and something
>like what you could expect with est working:
>http://lists.freebsd.org/pipermail/freebsd-stable/2010-March/055666.html
from link:
I would recommend you to disable it by setting:
hint.p4tcc.0.disabled=1
hint.acpi_throttle.0.disabled=1
I get unknown oid on both. Not sure how to disable p4tcc here. What I have
to work with.
dev.p4tcc.0.%desc: CPU Frequency Thermal Control
dev.p4tcc.0.%driver: p4tcc
dev.p4tcc.0.%parent: cpu0
dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1
2500/-1 1250/-1
dev.p4tcc.1.%desc: CPU Frequency Thermal Control
dev.p4tcc.1.%driver: p4tcc
dev.p4tcc.1.%parent: cpu1
dev.p4tcc.1.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1
2500/-1 1250/-1
Tried variations of dev instead of hint, no go.
going to c3 lowers it about a watt with powerd running to 43. c2 would be
somewhere inbetween?
%sysctl -a | grep lowest
debug.cpufreq.lowest: 0
hw.acpi.cpu.cx_lowest: C1
dev.cpu.0.cx_lowest: C1
dev.cpu.1.cx_lowest: C1
%
%sysctl -a | grep C1
hw.acpi.cpu.cx_lowest: C1
dev.cpu.0.cx_supported: C1/1 C2/1 C3/150
dev.cpu.0.cx_lowest: C1
dev.cpu.1.cx_supported: C1/1 C2/1 C3/150
dev.cpu.1.cx_lowest: C1
%
%sysctl hw.acpi.cpu.cx_lowest=C2
hw.acpi.cpu.cx_lowest: C1 -> C2
42/43 watts now
%sysctl dev.cpu.0.cx_lowest=C2
dev.cpu.0.cx_lowest: C2 -> C2
%sysctl dev.cpu.1.cx_lowest=C2
dev.cpu.1.cx_lowest: C2 -> C2
no other change with above 2 lines.
%killall powerd
It drops to 41 watts while still in C2
>
> > >> If I disable eist, c1 and c3 helpers in bios, as per suggestion in
> > >> mail archive, then it adds 1 watt to both figures. I was hoping
to get
> > >> this total tdp down to a very low amount, and it is but it should
> > >> theoretically go lower with powerd, right?
>
>If powerd were actually reducing frequency (and voltage) via est it
>certainly would. Finding out why est is failing to attach on your
>hardware is the only likely path to success, try focusing on that and
>ignoring side issues. Have you browsed freebsd-acpi archives re this?
Sounds right, I did not find the est code yet to peruse it some. Otherwise
I am out of clues on what to do.
> > >> load 3%, current freq 365 MHz ( 7), wanted freq 365 MHz
> > >> load 0%, current freq 365 MHz ( 7), wanted freq 365 MHz
> > >
> > >Your ACPI BIOS seems not reporting tables required to control EIST. So
> > >powerd probably uses only thermal throttling, which is not really
> > >effective for power saving on modern CPUs. You should check your BIOS
> > >options or may be update BIOS.
> > >
> > >If you have no luck with EIST - try to use C-states if BIOS reports at
> > >least them. It also can be quite effective.
> > >
> > >--
> > >Alexander Motin
> >
> > Thanks for the info, I did try to kick it to C3 and that helped poquito
> > amount. Everything is enabled in bios that matters to this, that does
help a
> > little too but powerd actually raises tdp a little. See other recent reply
> > for more info.
>
>Have you tried C2? Are you running the latest BIOS? And perhaps your
>ACPI ASL may be amenable to repair, if Gigabyte ACPI is broken here?
Changes to the asl are a bit more than I would want to get into. If I can
find the est code then I might dig further..
Bios is most recent, has EIST, c1e and c2e I believe enabled. That seems to
do the best all by itself. Maybe It does no good to beat a dead horse??
:-) I see an ITE IT8718F-S chip on board. mbmon does work somewhat but its
code is way old and does not see the newer chip versions. some good docs
with mbmon in usr/local/share/docs tho..
%mbmon -d -A
Summary of Detection:
* ISA monitor(s):
** Nat.Semi.Con. Chip LM78 found.
** Int.Tec.Exp. Chip IT8705F/IT8712F or SIS950 found
vcore is 1.14 now but most of the rest are not correct readings. It is 1.28
without bios settings enabled.
It never gets lower. Probably if I declock it below 2.93. 1.05 is what I
was hoping to go down to or lower at 365mhz.
%mbmon
Temp.= 191.0, 0.0, 0.0; Rot.= 874, 3358, 2657
Vcore = 1.14, 1.92; Volt. = 3.31, 4.92, 1.09, -14.19, -6.12
Temp.= 191.0, 0.0, 0.0; Rot.= 874, 3358, 2657
Vcore = 1.15, 1.92; Volt. = 3.31, 4.92, 1.09, -14.19, -6.12
%
%powerd -n adp
%mbmon
Temp.= 191.0, 0.0, 0.0; Rot.= 874, 3358, 2657
Vcore = 1.18, 1.92; Volt. = 3.31, 4.92, 1.22, -14.19, -6.12
Temp.= 191.0, 0.0, 0.0; Rot.= 874, 3358, 2657
Vcore = 1.14, 1.92; Volt. = 3.31, 4.92, 1.16, -14.19, -6.12
It jumped up in vcore a little there with powerd. C1E and C2E which include
P-states are what I am really after and I think that the bios by itself
provides those changes better than any other changes in these settings.
>
>cheers, Ian
Thanks to everyone that responded.
John
------------------------------
Message: 16
Date: Fri, 26 Mar 2010 10:31:39 +0200
From: Alexander Motin <m...@FreeBSD.org>
Subject: Re: Powerd and est / eist functionality
To: John Long <fb...@sstec.com>
Cc: FreeBSD-STABLE Mailing List <freebsd...@freebsd.org>
Message-ID: <4BAC70EB...@FreeBSD.org>
Content-Type: text/plain; charset=ISO-8859-1
John Long wrote:
>>Have you tried C2? Are you running the latest BIOS? And perhaps your
>>ACPI ASL may be amenable to repair, if Gigabyte ACPI is broken here?
As I can see, your ACPI reports C3 state support. You may try it also.
Here is my notes about power and C3 also:
http://wiki.freebsd.org/TuningPowerConsumption
--
Alexander Motin
------------------------------
Message: 17
Date: Fri, 26 Mar 2010 02:14:47 -0700
From: Jeremy Chadwick <fre...@jdc.parodius.com>
Subject: Re: Powerd and est / eist functionality
To: John Long <fb...@sstec.com>
Cc: Alexander Motin <m...@freebsd.org>, FreeBSD-STABLE Mailing List
<freebsd...@freebsd.org>, Ian Smith <smi...@nimnet.asn.au>
Message-ID: <20100326091...@icarus.home.lan>
Content-Type: text/plain; charset=us-ascii
On Fri, Mar 26, 2010 at 01:20:19AM -0700, John Long wrote:
> >Yes you're only getting p4tcc throttling as Alexander points out. You'll
> >need to get est working to get power reduction from lower frequencies,
> >which likely won't correspond to these f/8 step throttling frequencies.
> >
> >As Jeremy suggested, here's how to turn throttling off, and something
> >like what you could expect with est working:
> >http://lists.freebsd.org/pipermail/freebsd-stable/2010-March/055666.html
>
> from link:
> I would recommend you to disable it by setting:
> hint.p4tcc.0.disabled=1
> hint.acpi_throttle.0.disabled=1
>
> I get unknown oid on both. Not sure how to disable p4tcc here. What
> I have to work with.
These are /boot/loader.conf tunables, not sysctl. I'm pretty sure I
stated that in my previous mail...?
> Bios is most recent, has EIST, c1e and c2e I believe enabled. That
> seems to do the best all by itself. Maybe It does no good to beat a
> dead horse?? :-) I see an ITE IT8718F-S chip on board. mbmon does
> work somewhat but its code is way old and does not see the newer
> chip versions. some good docs with mbmon in usr/local/share/docs
> tho..
> %mbmon -d -A
> Summary of Detection:
> * ISA monitor(s):
> ** Nat.Semi.Con. Chip LM78 found.
> ** Int.Tec.Exp. Chip IT8705F/IT8712F or SIS950 found
>
> vcore is 1.14 now but most of the rest are not correct readings. It
> is 1.28 without bios settings enabled.
> It never gets lower. Probably if I declock it below 2.93. 1.05 is
> what I was hoping to go down to or lower at 365mhz.
>
> %mbmon
> Temp.= 191.0, 0.0, 0.0; Rot.= 874, 3358, 2657
> Vcore = 1.14, 1.92; Volt. = 3.31, 4.92, 1.09, -14.19, -6.12
>
> Temp.= 191.0, 0.0, 0.0; Rot.= 874, 3358, 2657
> Vcore = 1.15, 1.92; Volt. = 3.31, 4.92, 1.09, -14.19, -6.12
> %
> %powerd -n adp
> %mbmon
> Temp.= 191.0, 0.0, 0.0; Rot.= 874, 3358, 2657
> Vcore = 1.18, 1.92; Volt. = 3.31, 4.92, 1.22, -14.19, -6.12
>
> Temp.= 191.0, 0.0, 0.0; Rot.= 874, 3358, 2657
> Vcore = 1.14, 1.92; Volt. = 3.31, 4.92, 1.16, -14.19, -6.12
Ignore all of the above values -- mbmon doesn't work properly with your
board, or that sub-revision of IT chip. It's that simple. Re-read the
rant I sent you for explanation; I already covered all the bases. :-) I
disagree about the mbmon docs -- they're more like chaotic brain dumps
or scribbled notes than actual coherent, well-written instructions or
details. That said, I have utmost respect for SHIMIZU Yoshifumi and his
efforts/work.
I'm willing to make an exception here. If you can get the following
information from the motherboard manufacturer, I'd be willing to add
support for your board to bsdhwmon. What I need:
1) The exact H/W monitoring IC they use (not what mbmon says, and
not what's silkscreened on the chip),
2) If the H/W monitoring IC is tied in to SMBus,
3) What the SMBus slave address is they chose for the H/W IC
4) Output of "kenv | grep smbios" from your system.
Assuming all of the above meets necessary criteria, I can probably add
support for this board to bsdhwmon. I have only slight qualms/concerns
adding consumer boards to bsdhwmon, but the big kicker is that the board
**must** have an actual H/W monitoring IC tied/wired to SMBus. I *will
not* use the old LPC/ISA (/dev/io) infrastructure.
> It jumped up in vcore a little there with powerd. C1E and C2E which
> include P-states are what I am really after and I think that the
> bios by itself provides those changes better than any other changes
> in these settings.
...and this would fall under the est(4) subset driver for cpufreq(4).
--
| 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 |
------------------------------
Message: 18
Date: Fri, 26 Mar 2010 11:08:26 +0100
From: Giulio Ferro <au...@zirakzigil.org>
Subject: NFS lockd problem
To: "freeb...@freebsd.org" <freeb...@freebsd.org>,
freebsd...@freebsd.org
Message-ID: <4BAC879A...@zirakzigil.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Outset:
1 NFS server (with lockd)
2 NFS client (with lockd)
The clients serve several jails with apache, whose data (www) resides on
the server
From time to time everything seem to freeze. Then, after one minute or
so, the system
works again as nothing had happened.
In these occasions I get this in the logs on the client madchines:
Mar 26 10:29:38 virt1 kernel: nfs server
192.168.40.121:/data/mount_servers/wwwsec/www: lockd not responding
followed shortly after by:
Mar 26 10:29:38 virt1 kernel: nfs server
192.168.40.121:/data/mount_servers/wwwsec/www: lockd is alive again
On the server I only get this:
Mar 26 10:29:31 data1 kernel: NLM: failed to contact remote rpcbind,
stat = 5, port = 28416
I don't think it's a network problem, since all connections are local
and high speed (1Gb/s)
I must admit that, with the other nfs problem I reported weeks ago, this
kind of freebsd system seems
less than stable to me, and this is very disappointing...
Anyway I'd appreciate any pointer on this issue...
------------------------------
End of freebsd-stable Digest, Vol 349, Issue 6
**********************************************