dummynet -- changing scheduler resets pipe bw ?
I have been reading the ipfw man pages and /usr/src/sys/netinet/ipfw/dummynet.txt to try to better understand how to set up queues/pipes/schedulars/flows. I noticed something odd... changing the sched type [a] doesn't seem to change the type away from WF2Q+ [b] resets the bw to 'unlimited' Maybe I don't have qfq? Rudy Output: 158 ipfw -v pipe 5 show answer for cmd 130, len 4096 5: 6.000 Mbit/s0 ms burst 0 q131077 50 sl. 0 flows (1 buckets) sched 65541 weight 0 lmax 0 pri 0 droptail sched 65541 type FIFO flags 0x0 0 buckets 0 active 159 ipfw pipe 5 config sched qfq 160 ipfw -v pipe 5 show answer for cmd 130, len 4096 5: unlimited 0 ms burst 0 q131077 50 sl. 0 flows (1 buckets) sched 65541 weight 0 lmax 0 pri 0 droptail sched 65541 type FIFO flags 0x0 0 buckets 0 active 161 ipfw pipe 5 config bw 6Mbit/s 162 ipfw -v pipe 5 show answer for cmd 130, len 4096 5: 6.000 Mbit/s0 ms burst 0 q131077 50 sl. 0 flows (1 buckets) sched 65541 weight 0 lmax 0 pri 0 droptail sched 65541 type FIFO flags 0x0 0 buckets 0 active 166 ipfw sched list 1: 21.000 Mbit/s0 ms burst 0 sched 1 type WF2Q+ flags 0x0 0 buckets 0 active 2: 21.000 Mbit/s0 ms burst 0 sched 2 type WF2Q+ flags 0x0 0 buckets 0 active 3: 6.000 Mbit/s0 ms burst 0 sched 3 type WF2Q+ flags 0x0 0 buckets 0 active 4: 12.000 Mbit/s0 ms burst 0 sched 4 type WF2Q+ flags 0x0 0 buckets 0 active 5: 6.000 Mbit/s0 ms burst 0 sched 5 type WF2Q+ flags 0x0 0 buckets 1 active Children flowsets: 5 0 ip 0.0.0.0/0 0.0.0.0/0 19389008 15491784384 204 174119 1090892 00022: 12.000 Mbit/s0 ms burst 0 sched 22 type WF2Q+ flags 0x0 0 buckets 0 active Children flowsets: 23 167 ipfw pipe 5 config sched qfq 168 ipfw sched list 1: 21.000 Mbit/s0 ms burst 0 sched 1 type WF2Q+ flags 0x0 0 buckets 0 active 2: 21.000 Mbit/s0 ms burst 0 sched 2 type WF2Q+ flags 0x0 0 buckets 0 active 3: 6.000 Mbit/s0 ms burst 0 sched 3 type WF2Q+ flags 0x0 0 buckets 0 active 4: 12.000 Mbit/s0 ms burst 0 sched 4 type WF2Q+ flags 0x0 0 buckets 0 active 5: unlimited 0 ms burst 0 sched 5 type WF2Q+ flags 0x0 0 buckets 1 active Children flowsets: 5 0 ip 0.0.0.0/0 0.0.0.0/0 19449511 15527760672 00 1095037 00022: 12.000 Mbit/s0 ms burst 0 sched 22 type WF2Q+ flags 0x0 0 buckets 0 active Children flowsets: 23 FreeBSD jejen.monkeybrains.net 8.1-STABLE FreeBSD 8.1-STABLE #2: Wed Oct 20 15:55:41 PDT 2010 r...@pulga.monkeybrains.net:/usr/obj/usr/src/sys/JEJEN amd64 strings /boot/kernel/dummynet.ko.symbols | head -1 $FreeBSD: src/sys/netinet/ipfw/ip_dummynet.c,v 1.5.2.3 2010/03/23 09:58:59 luigi Exp $ ___ 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: How to get suspend/resume work on IBM T60?
On Tuesday 16 November 2010 14:31:39 Yue Wu wrote: No, even the indicating light indicates the status is still in suspend, I have to press and hold the power key to power off. You'll probably need to talk to the guys over on freebsd-a...@freebsd.org for help then. -- Bruce Cran ___ 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
chflags on zfs (sappnd)
Hi everbody, from http://wiki.freebsd.org/ZFS I understand that chflags are supported by zfs. But if I have a file with sappnd on a zfs filesystem, I am unable to execute a command like this: # touch lili # chflags sappnd lili # ls -lrto lili -rw-r--r-- 1 root wheel sappnd 5 Nov 17 12:38 lili # echo lala lili # echo lala lili -su: echo: write error: Operation not permitted So, the first time it worked, but it stops working on any consequent time (when the file is no more empty). I found a bug report on: http://www.freebsd.org/cgi/query-pr.cgi?pr=149495 where a patch is suggested. Nevertheless, even though my sources are newer than the suggested patch, my source tree does not contain it. Do we know anything more about it? # uname -a FreeBSD myhost 8.1-STABLE FreeBSD 8.1-STABLE #1: Fri Nov 5 17:27:37 EET 2010 root@:/mnt/obj/mnt/src/sys/GENERIC amd64 Thank you all for your time in advance, mamalos -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 ___ 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: chflags on zfs (sappnd)
On 2010/11/17 at 18:49, George Mamalakis mama...@eng.auth.gr wrote: Hi everbody, from http://wiki.freebsd.org/ZFS I understand that chflags are supported by zfs. But if I have a file with sappnd on a zfs filesystem, I am unable to execute a command like this: # touch lili # chflags sappnd lili # ls -lrto lili -rw-r--r-- 1 root wheel sappnd 5 Nov 17 12:38 lili # echo lala lili # echo lala lili -su: echo: write error: Operation not permitted So, the first time it worked, but it stops working on any consequent time (when the file is no more empty). I found a bug report on: http://www.freebsd.org/cgi/query-pr.cgi?pr=149495 where a patch is suggested. Nevertheless, even though my sources are newer than the suggested patch, my source tree does not contain it. Do we know anything more about it? # uname -a FreeBSD myhost 8.1-STABLE FreeBSD 8.1-STABLE #1: Fri Nov 5 17:27:37 EET 2010 root@:/mnt/obj/mnt/src/sys/GENERIC amd64 Thank you all for your time in advance, mamalos I can't reproduce the warning message here. When I do the second 'echo', nothing appeared. But the file content was unchanged. I am using zfs version 15. #uname -a FreeBSD pluton.xbsd.name 8.1-STABLE FreeBSD 8.1-STABLE #0: Wed Nov 17 08:13:47 CST 2010 d...@pluton.xbsd.name:/opt/obj/sysbld/usr/src/sys/pluton-amd64 amd64 -- If a scientist uncovers a publishable fact, it will become central to his theory. His theory, in turn, will become central to all scientific truth. ___ 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: Call for testers: FPU changes
On Tue, Nov 16, 2010 at 08:46:23PM -0500, Mike Tancsa wrote:
On 11/16/2010 5:19 PM, Kostik Belousov wrote:
Would your conclusion be that the patch seems to increase the throughput
of the aesni(4) ?
I think that on small-sized blocks, when using aesni(4), the dominating
factor is the copying/copyout of the data to/from the kernel address
space. Still would be interesting to compare the full output
of openssl speed on aesni(4) with and without the patch I posted.
Hi,
There does seem to be some improvement on large blocks. But there are
some freakishly fast times. On other sizes, there is no difference in
speed it would seem
I did 20 runs. Updated stats at http://www.tancsa.com/fpu.html
Thank you. Indeed, I think that the test units are too small so that
random system events can cause the variation. Nonetheless, patch seems
to help, so I committed it.
Meantime, the similar change may be beneficial for padlock(4) too.
f you are going to test it, please note that most likely, openssl padlock
engine does not use padlock(4), I do not know for sure.
diff --git a/sys/crypto/via/padlock.c b/sys/crypto/via/padlock.c
index 77e059b..ba63093 100644
--- a/sys/crypto/via/padlock.c
+++ b/sys/crypto/via/padlock.c
@@ -170,7 +170,7 @@ padlock_newsession(device_t dev, uint32_t *sidp, struct
cryptoini *cri)
struct padlock_session *ses = NULL;
struct cryptoini *encini, *macini;
struct thread *td;
- int error;
+ int error, saved_ctx;
if (sidp == NULL || cri == NULL)
return (EINVAL);
@@ -238,10 +238,18 @@ padlock_newsession(device_t dev, uint32_t *sidp, struct
cryptoini *cri)
if (macini != NULL) {
td = curthread;
- error = fpu_kern_enter(td, ses-ses_fpu_ctx, FPU_KERN_NORMAL);
+ if (!is_fpu_kern_thread(0)) {
+ error = fpu_kern_enter(td, ses-ses_fpu_ctx,
+ FPU_KERN_NORMAL);
+ saved_ctx = 1;
+ } else {
+ error = 0;
+ saved_ctx = 0;
+ }
if (error == 0) {
error = padlock_hash_setup(ses, macini);
- fpu_kern_leave(td, ses-ses_fpu_ctx);
+ if (saved_ctx)
+ fpu_kern_leave(td, ses-ses_fpu_ctx);
}
if (error != 0) {
padlock_freesession_one(sc, ses, 0);
diff --git a/sys/crypto/via/padlock_cipher.c b/sys/crypto/via/padlock_cipher.c
index 0ae26c8..1456ddf 100644
--- a/sys/crypto/via/padlock_cipher.c
+++ b/sys/crypto/via/padlock_cipher.c
@@ -205,7 +205,7 @@ padlock_cipher_process(struct padlock_session *ses, struct
cryptodesc *enccrd,
struct thread *td;
u_char *buf, *abuf;
uint32_t *key;
- int allocated, error;
+ int allocated, error, saved_ctx;
buf = padlock_cipher_alloc(enccrd, crp, allocated);
if (buf == NULL)
@@ -250,14 +250,21 @@ padlock_cipher_process(struct padlock_session *ses,
struct cryptodesc *enccrd,
}
td = curthread;
- error = fpu_kern_enter(td, ses-ses_fpu_ctx, FPU_KERN_NORMAL);
+ if (!is_fpu_kern_thread(0)) {
+ error = fpu_kern_enter(td, ses-ses_fpu_ctx, FPU_KERN_NORMAL);
+ saved_ctx = 1;
+ } else {
+ error = 0;
+ saved_ctx = 0;
+ }
if (error != 0)
goto out;
padlock_cbc(abuf, abuf, enccrd-crd_len / AES_BLOCK_LEN, key, cw,
ses-ses_iv);
- fpu_kern_leave(td, ses-ses_fpu_ctx);
+ if (saved_ctx)
+ fpu_kern_leave(td, ses-ses_fpu_ctx);
if (allocated) {
crypto_copyback(crp-crp_flags, crp-crp_buf, enccrd-crd_skip,
diff --git a/sys/crypto/via/padlock_hash.c b/sys/crypto/via/padlock_hash.c
index 58c58b2..0fe182b 100644
--- a/sys/crypto/via/padlock_hash.c
+++ b/sys/crypto/via/padlock_hash.c
@@ -366,17 +366,24 @@ padlock_hash_process(struct padlock_session *ses, struct
cryptodesc *maccrd,
struct cryptop *crp)
{
struct thread *td;
- int error;
+ int error, saved_ctx;
td = curthread;
- error = fpu_kern_enter(td, ses-ses_fpu_ctx, FPU_KERN_NORMAL);
+ if (!is_fpu_kern_thread(0)) {
+ error = fpu_kern_enter(td, ses-ses_fpu_ctx, FPU_KERN_NORMAL);
+ saved_ctx = 1;
+ } else {
+ error = 0;
+ saved_ctx = 0;
+ }
if (error != 0)
return (error);
if ((maccrd-crd_flags CRD_F_KEY_EXPLICIT) != 0)
padlock_hash_key_setup(ses, maccrd-crd_key, maccrd-crd_klen);
error = padlock_authcompute(ses, maccrd, crp-crp_buf, crp-crp_flags);
- fpu_kern_leave(td, ses-ses_fpu_ctx);
+ if (saved_ctx)
+ fpu_kern_leave(td, ses-ses_fpu_ctx);
return (error);
}
Re: chflags on zfs (sappnd)
On 17.11.2010, at 11:49, George Mamalakis wrote: Hi everbody, from http://wiki.freebsd.org/ZFS I understand that chflags are supported by zfs. But if I have a file with sappnd on a zfs filesystem, I am unable to execute a command like this: # touch lili # chflags sappnd lili # ls -lrto lili -rw-r--r-- 1 root wheel sappnd 5 Nov 17 12:38 lili # echo lala lili # echo lala lili -su: echo: write error: Operation not permitted So, the first time it worked, but it stops working on any consequent time (when the file is no more empty). I found a bug report on: http://www.freebsd.org/cgi/query-pr.cgi?pr=149495 And: http://www.freebsd.org/cgi/query-pr.cgi?pr=151082cat=kern where a patch is suggested. Nevertheless, even though my sources are newer than the suggested patch, my source tree does not contain it. Do we know anything more about it? The fix was committed to CURRENT on Oct 8th (r213634). The commit message talks about MFC after a week, however to me it looks like the fix hasn't made it to 8-STABLE yet. Also, there seems to be a related commit r213673 which essentially reverts r213634 and has a more general approach to handling ioflags with zfs. This commit was on Oct 10th, again 1 week MFC grace period, again not in 8-STABLE yet, at least to my knowlegde. Maybe MFC was simply forgotten, maybe there's a good reason to delay it, I don't know. We're using my patch (the one mentioned in the PRs) for now and append-only works as intended. Applying the changes in r213673 to 8-STABLE might be an option too, if you're considering patching to get the append flag working. Anyway, hopefully one of these fixes gets MFCd to 8-STABLE soon. Markus ___ 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
acpi(ca) mfc for 8.2
I want to do MFC of ACPICA imports to stable/8 before 8.2 release. This would obviously include commits that fix mismerges or remove obsolete code. Plus some other small enhancements/fixes in our ACPI code. This is what I currently have: svn status: http://people.freebsd.org/~avg/acpi-stable-8.txt svn diff: http://people.freebsd.org/~avg/acpi-stable-8.diff svn log ...:http://people.freebsd.org/~avg/acpi-stable-8.log Please note that the svn diff above can not be used with patch(1), because of some svn peculiarities related to files in vendor area. Here's a plain diff that should be more useful: http://people.freebsd.org/~avg/acpi-stable-8.plain.diff I will appreciate any testing and reviews. Mobile users who track stable/8 would be the primary candidates, I guess :-) Thanks a lot! -- Andriy Gapon signature.asc Description: OpenPGP digital signature
Re: chflags on zfs (sappnd)
on 17/11/2010 18:38 Markus Gebert said the following: On 17.11.2010, at 11:49, George Mamalakis wrote: Hi everbody, from http://wiki.freebsd.org/ZFS I understand that chflags are supported by zfs. But if I have a file with sappnd on a zfs filesystem, I am unable to execute a command like this: # touch lili # chflags sappnd lili # ls -lrto lili -rw-r--r-- 1 root wheel sappnd 5 Nov 17 12:38 lili # echo lala lili # echo lala lili -su: echo: write error: Operation not permitted So, the first time it worked, but it stops working on any consequent time (when the file is no more empty). I found a bug report on: http://www.freebsd.org/cgi/query-pr.cgi?pr=149495 And: http://www.freebsd.org/cgi/query-pr.cgi?pr=151082cat=kern where a patch is suggested. Nevertheless, even though my sources are newer than the suggested patch, my source tree does not contain it. Do we know anything more about it? The fix was committed to CURRENT on Oct 8th (r213634). The commit message talks about MFC after a week, however to me it looks like the fix hasn't made it to 8-STABLE yet. Also, there seems to be a related commit r213673 which essentially reverts r213634 and has a more general approach to handling ioflags with zfs. This commit was on Oct 10th, again 1 week MFC grace period, again not in 8-STABLE yet, at least to my knowlegde. Maybe MFC was simply forgotten, maybe there's a good reason to delay it, I don't know. We're using my patch (the one mentioned in the PRs) for now and append-only works as intended. Applying the changes in r213673 to 8-STABLE might be an option too, if you're considering patching to get the append flag working. Anyway, hopefully one of these fixes gets MFCd to 8-STABLE soon. Good analysis, but did you forget to CC the committer(s)? It is known that sometimes the committers do need a gentle (or not so) nudging :-) -- 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: Call for testers: FPU changes
On 11/17/2010 11:35 AM, Kostik Belousov wrote:
Meantime, the similar change may be beneficial for padlock(4) too.
f you are going to test it, please note that most likely, openssl padlock
engine does not use padlock(4), I do not know for sure.
diff --git a/sys/crypto/via/padlock.c b/sys/crypto/via/padlock.c
index 77e059b..ba63093 100644
--- a/sys/crypto/via/padlock.c
+++ b/sys/crypto/via/padlock.c
Patch applied cleanly
Full results at the bottom of
http://www.tancsa.com/fpu.html
On large blocks, version 1 vs the above patch show no significant
difference. This is with openssl using the cryptodev engine. I also
compared to the openssl padlock engine which gave interesting results!
0(via)# cat version1.txt | sed -e 's/k//g' | awk '{print $6}' 1
0(via)# cat version2.txt | sed -e 's/k//g' | awk '{print $6}' 2
0(via)# ministat 1 2
x 1
+ 2
N Min MaxMedian AvgStddev
x 30 2591851.6 6645345.1 4326340.6 4227917.6 1083181.2
+ 30 2574883.9 8830282.8 4033610.4 4241195.6 1519334.8
No difference proven at 95.0% confidence
0(via)# cat version1.txt | sed -e 's/k//g' | awk '{print $5}' 1
0(via)# cat version2.txt | sed -e 's/k//g' | awk '{print $5}' 2
0(via)# ministat 1 2
N Min MaxMedian AvgStddev
x 30 1124673.3 2320883.7 1527677.1 1550631.9 295165.4
+ 30 1069788.2 2508865.7 1594506.2 1588193.2 389414.33
No difference proven at 95.0% confidence
0(via)#
___
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: chflags on zfs (sappnd)
On 17.11.2010, at 20:00, Andriy Gapon wrote: on 17/11/2010 18:38 Markus Gebert said the following: On 17.11.2010, at 11:49, George Mamalakis wrote: Hi everbody, from http://wiki.freebsd.org/ZFS I understand that chflags are supported by zfs. But if I have a file with sappnd on a zfs filesystem, I am unable to execute a command like this: # touch lili # chflags sappnd lili # ls -lrto lili -rw-r--r-- 1 root wheel sappnd 5 Nov 17 12:38 lili # echo lala lili # echo lala lili -su: echo: write error: Operation not permitted So, the first time it worked, but it stops working on any consequent time (when the file is no more empty). I found a bug report on: http://www.freebsd.org/cgi/query-pr.cgi?pr=149495 And: http://www.freebsd.org/cgi/query-pr.cgi?pr=151082cat=kern where a patch is suggested. Nevertheless, even though my sources are newer than the suggested patch, my source tree does not contain it. Do we know anything more about it? The fix was committed to CURRENT on Oct 8th (r213634). The commit message talks about MFC after a week, however to me it looks like the fix hasn't made it to 8-STABLE yet. Also, there seems to be a related commit r213673 which essentially reverts r213634 and has a more general approach to handling ioflags with zfs. This commit was on Oct 10th, again 1 week MFC grace period, again not in 8-STABLE yet, at least to my knowlegde. Maybe MFC was simply forgotten, maybe there's a good reason to delay it, I don't know. We're using my patch (the one mentioned in the PRs) for now and append-only works as intended. Applying the changes in r213673 to 8-STABLE might be an option too, if you're considering patching to get the append flag working. Anyway, hopefully one of these fixes gets MFCd to 8-STABLE soon. Good analysis, but did you forget to CC the committer(s)? It is known that sometimes the committers do need a gentle (or not so) nudging :-) Right :-) mm@ and pjd@ now CCed. Markus ___ 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: High cpu usage when using ZFS cache device
On Wed, Nov 17, 2010 at 8:47 AM, Christer Solskogen christer.solsko...@gmail.com wrote: Will try to reboot server now to se if that has any impact. It seems to have solved it. At least temporary. -- chs, ___ 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: Call for testers: FPU changes
On Wed, Nov 17, 2010 at 02:18:50PM -0500, Mike Tancsa wrote:
On 11/17/2010 11:35 AM, Kostik Belousov wrote:
Meantime, the similar change may be beneficial for padlock(4) too.
f you are going to test it, please note that most likely, openssl padlock
engine does not use padlock(4), I do not know for sure.
diff --git a/sys/crypto/via/padlock.c b/sys/crypto/via/padlock.c
index 77e059b..ba63093 100644
--- a/sys/crypto/via/padlock.c
+++ b/sys/crypto/via/padlock.c
Patch applied cleanly
Full results at the bottom of
http://www.tancsa.com/fpu.html
On large blocks, version 1 vs the above patch show no significant
difference. This is with openssl using the cryptodev engine. I also
compared to the openssl padlock engine which gave interesting results!
0(via)# cat version1.txt | sed -e 's/k//g' | awk '{print $6}' 1
0(via)# cat version2.txt | sed -e 's/k//g' | awk '{print $6}' 2
0(via)# ministat 1 2
x 1
+ 2
N Min MaxMedian AvgStddev
x 30 2591851.6 6645345.1 4326340.6 4227917.6 1083181.2
+ 30 2574883.9 8830282.8 4033610.4 4241195.6 1519334.8
No difference proven at 95.0% confidence
0(via)# cat version1.txt | sed -e 's/k//g' | awk '{print $5}' 1
0(via)# cat version2.txt | sed -e 's/k//g' | awk '{print $5}' 2
0(via)# ministat 1 2
N Min MaxMedian AvgStddev
x 30 1124673.3 2320883.7 1527677.1 1550631.9 295165.4
+ 30 1069788.2 2508865.7 1594506.2 1588193.2 389414.33
No difference proven at 95.0% confidence
0(via)#
Thank you once more.
If nothing new pops up, I will commit the MFC tomorrow.
Unfortunately, no suspend/resume testers appeared, so be it.
pgpCEmxG512GE.pgp
Description: PGP signature
Re: acpi(ca) mfc for 8.2
On Wed, 2010-11-17 at 20:43 +0200, Andriy Gapon wrote: I want to do MFC of ACPICA imports to stable/8 before 8.2 release. This would obviously include commits that fix mismerges or remove obsolete code. Plus some other small enhancements/fixes in our ACPI code. This is what I currently have: svn status: http://people.freebsd.org/~avg/acpi-stable-8.txt svn diff: http://people.freebsd.org/~avg/acpi-stable-8.diff svn log ...: http://people.freebsd.org/~avg/acpi-stable-8.log Please note that the svn diff above can not be used with patch(1), because of some svn peculiarities related to files in vendor area. Here's a plain diff that should be more useful: http://people.freebsd.org/~avg/acpi-stable-8.plain.diff I will appreciate any testing and reviews. Mobile users who track stable/8 would be the primary candidates, I guess :-) Thanks a lot! On my system: FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.1-STABLE FreeBSD 8.1-STABLE #0 r215086: Wed Nov 10 11:07:30 EST 2010 r...@rabbitsden.rabbitslawn.verizon.net:/usr/obj/usr/src/sys/TPX60 i386 running on ThinkPad X60, I get proliferation of acpi_tz0: error fetching current temperature -- AE_NOT_FOUND messages after applying the patch. Verbose dmesg from before and after cold boots are available at: http://members.verizon.net/~akovalenko/ACPI/dmesg.before.bz2 http://members.verizon.net/~akovalenko/ACPI/dmesg.after.bz2 respectively. Now, on this machine tz0 is not a real thermal zone but some kind of implement to initiate system shutdown for some case I never had enough time or inclination to track through ASL. Real thermal zone is tz1. hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 1 hw.acpi.thermal.tz0.temperature: 45.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 127.0C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: -1 hw.acpi.thermal.tz0._TC2: -1 hw.acpi.thermal.tz0._TSP: -1 hw.acpi.thermal.tz1.temperature: 43.0C hw.acpi.thermal.tz1.active: -1 hw.acpi.thermal.tz1.passive_cooling: 1 hw.acpi.thermal.tz1.thermal_flags: 0 hw.acpi.thermal.tz1._PSV: 75.0C hw.acpi.thermal.tz1._HOT: -1 hw.acpi.thermal.tz1._CRT: 97.0C hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz1._TC1: 5 hw.acpi.thermal.tz1._TC2: 4 hw.acpi.thermal.tz1._TSP: 600 If I can provide any additional information or test any patches, please, let me know. Also, I would like to take this opportunity to thank you for your work. -- Alexandre Kovalenko (Олександр Коваленко) -- Ovi Mail: Making email access easy http://mail.ovi.com ___ 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: acpi(ca) mfc for 8.2
On Wed, 2010-11-17 at 20:43 +0200, Andriy Gapon wrote: I want to do MFC of ACPICA imports to stable/8 before 8.2 release. This would obviously include commits that fix mismerges or remove obsolete code. Plus some other small enhancements/fixes in our ACPI code. This is what I currently have: svn status: http://people.freebsd.org/~avg/acpi-stable-8.txt svn diff: http://people.freebsd.org/~avg/acpi-stable-8.diff svn log ...: http://people.freebsd.org/~avg/acpi-stable-8.log Please note that the svn diff above can not be used with patch(1), because of some svn peculiarities related to files in vendor area. Here's a plain diff that should be more useful: http://people.freebsd.org/~avg/acpi-stable-8.plain.diff I will appreciate any testing and reviews. Mobile users who track stable/8 would be the primary candidates, I guess :-) Thanks a lot! On my system: FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.1-STABLE FreeBSD 8.1-STABLE #0 r215086: Wed Nov 10 11:07:30 EST 2010 r...@rabbitsden.rabbitslawn.verizon.net:/usr/obj/usr/src/sys/TPX60 i386 running on ThinkPad X60, I get proliferation of acpi_tz0: error fetching current temperature -- AE_NOT_FOUND messages after applying the patch. Verbose dmesg from before and after cold boots are available at: http://members.verizon.net/~akovalenko/ACPI/dmesg.before.bz2 http://members.verizon.net/~akovalenko/ACPI/dmesg.after.bz2 respectively. Now, on this machine tz0 is not a real thermal zone but some kind of implement to initiate system shutdown for some case I never had enough time or inclination to track through ASL. Real thermal zone is tz1. hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 1 hw.acpi.thermal.tz0.temperature: 45.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 127.0C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: -1 hw.acpi.thermal.tz0._TC2: -1 hw.acpi.thermal.tz0._TSP: -1 hw.acpi.thermal.tz1.temperature: 43.0C hw.acpi.thermal.tz1.active: -1 hw.acpi.thermal.tz1.passive_cooling: 1 hw.acpi.thermal.tz1.thermal_flags: 0 hw.acpi.thermal.tz1._PSV: 75.0C hw.acpi.thermal.tz1._HOT: -1 hw.acpi.thermal.tz1._CRT: 97.0C hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz1._TC1: 5 hw.acpi.thermal.tz1._TC2: 4 hw.acpi.thermal.tz1._TSP: 600 If I can provide any additional information or test any patches, please, let me know. Also, I would like to take this opportunity to thank you for your work. -- Alexandre Kovalenko (Олександр Коваленко) -- Ovi Mail: Making email access easy http://mail.ovi.com ___ 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: acpi(ca) mfc for 8.2
On Wednesday 17 November 2010 05:04 pm, Alexandre Sunny Kovalenko
wrote:
On Wed, 2010-11-17 at 20:43 +0200, Andriy Gapon wrote:
I want to do MFC of ACPICA imports to stable/8 before 8.2
release. This would obviously include commits that fix mismerges
or remove obsolete code. Plus some other small enhancements/fixes
in our ACPI code.
This is what I currently have:
svn status: http://people.freebsd.org/~avg/acpi-stable-8.txt
svn diff: http://people.freebsd.org/~avg/acpi-stable-8.diff
svn log ...:http://people.freebsd.org/~avg/acpi-stable-8.log
Please note that the svn diff above can not be used with
patch(1), because of some svn peculiarities related to files in
vendor area.
Here's a plain diff that should be more useful:
http://people.freebsd.org/~avg/acpi-stable-8.plain.diff
I will appreciate any testing and reviews.
Mobile users who track stable/8 would be the primary candidates,
I guess :-) Thanks a lot!
On my system:
FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.1-STABLE FreeBSD
8.1-STABLE #0 r215086: Wed Nov 10 11:07:30 EST 2010
r...@rabbitsden.rabbitslawn.verizon.net:/usr/obj/usr/src/sys/TPX60
i386
running on ThinkPad X60, I get proliferation of
acpi_tz0: error fetching current temperature -- AE_NOT_FOUND
messages after applying the patch.
Verbose dmesg from before and after cold boots are available
at:
http://members.verizon.net/~akovalenko/ACPI/dmesg.before.bz2
http://members.verizon.net/~akovalenko/ACPI/dmesg.after.bz2
respectively.
Now, on this machine tz0 is not a real thermal zone but some kind
of implement to initiate system shutdown for some case I never had
enough time or inclination to track through ASL. Real thermal zone
is tz1.
hw.acpi.thermal.min_runtime: 0
hw.acpi.thermal.polling_rate: 10
hw.acpi.thermal.user_override: 1
hw.acpi.thermal.tz0.temperature: 45.0C
hw.acpi.thermal.tz0.active: -1
hw.acpi.thermal.tz0.passive_cooling: 0
hw.acpi.thermal.tz0.thermal_flags: 0
hw.acpi.thermal.tz0._PSV: -1
hw.acpi.thermal.tz0._HOT: -1
hw.acpi.thermal.tz0._CRT: 127.0C
hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
hw.acpi.thermal.tz0._TC1: -1
hw.acpi.thermal.tz0._TC2: -1
hw.acpi.thermal.tz0._TSP: -1
hw.acpi.thermal.tz1.temperature: 43.0C
hw.acpi.thermal.tz1.active: -1
hw.acpi.thermal.tz1.passive_cooling: 1
hw.acpi.thermal.tz1.thermal_flags: 0
hw.acpi.thermal.tz1._PSV: 75.0C
hw.acpi.thermal.tz1._HOT: -1
hw.acpi.thermal.tz1._CRT: 97.0C
hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
hw.acpi.thermal.tz1._TC1: 5
hw.acpi.thermal.tz1._TC2: 4
hw.acpi.thermal.tz1._TSP: 600
If I can provide any additional information or test any patches,
please, let me know.
Ouch... Can you please try the attached patch?
Thanks,
Jung-uk Kim
Index: sys/dev/acpica/acpi_thermal.c
===
--- sys/dev/acpica/acpi_thermal.c (revision 215429)
+++ sys/dev/acpica/acpi_thermal.c (working copy)
@@ -181,14 +181,16 @@ static intacpi_tz_cooling_unit =
-1;
static int
acpi_tz_probe(device_t dev)
{
-intresult;
+ char *name;
-if (acpi_get_type(dev) == ACPI_TYPE_THERMAL !acpi_disabled(thermal)) {
- device_set_desc(dev, Thermal Zone);
- result = -10;
-} else
- result = ENXIO;
-return (result);
+ if (!acpi_disabled(thermal)) {
+ name = acpi_name(acpi_get_handle(dev));
+ if (name != NULL strcmp(name, \\_TZ_) == 0) {
+ device_set_desc(dev, Thermal Zone);
+ return (-10);
+ }
+ }
+ return (ENXIO);
}
static int
___
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: acpi(ca) mfc for 8.2
On Wednesday 17 November 2010 05:41 pm, Jung-uk Kim wrote: On Wednesday 17 November 2010 05:04 pm, Alexandre Sunny Kovalenko wrote: On Wed, 2010-11-17 at 20:43 +0200, Andriy Gapon wrote: I want to do MFC of ACPICA imports to stable/8 before 8.2 release. This would obviously include commits that fix mismerges or remove obsolete code. Plus some other small enhancements/fixes in our ACPI code. This is what I currently have: svn status: http://people.freebsd.org/~avg/acpi-stable-8.txt svn diff: http://people.freebsd.org/~avg/acpi-stable-8.diff svn log ...: http://people.freebsd.org/~avg/acpi-stable-8.log Please note that the svn diff above can not be used with patch(1), because of some svn peculiarities related to files in vendor area. Here's a plain diff that should be more useful: http://people.freebsd.org/~avg/acpi-stable-8.plain.diff I will appreciate any testing and reviews. Mobile users who track stable/8 would be the primary candidates, I guess :-) Thanks a lot! On my system: FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.1-STABLE FreeBSD 8.1-STABLE #0 r215086: Wed Nov 10 11:07:30 EST 2010 r...@rabbitsden.rabbitslawn.verizon.net:/usr/obj/usr/src/sys/TPX6 0 i386 running on ThinkPad X60, I get proliferation of acpi_tz0: error fetching current temperature -- AE_NOT_FOUND messages after applying the patch. Verbose dmesg from before and after cold boots are available at: http://members.verizon.net/~akovalenko/ACPI/dmesg.before.bz2 http://members.verizon.net/~akovalenko/ACPI/dmesg.after.bz2 respectively. Now, on this machine tz0 is not a real thermal zone but some kind of implement to initiate system shutdown for some case I never had enough time or inclination to track through ASL. Real thermal zone is tz1. hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 1 hw.acpi.thermal.tz0.temperature: 45.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 127.0C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: -1 hw.acpi.thermal.tz0._TC2: -1 hw.acpi.thermal.tz0._TSP: -1 hw.acpi.thermal.tz1.temperature: 43.0C hw.acpi.thermal.tz1.active: -1 hw.acpi.thermal.tz1.passive_cooling: 1 hw.acpi.thermal.tz1.thermal_flags: 0 hw.acpi.thermal.tz1._PSV: 75.0C hw.acpi.thermal.tz1._HOT: -1 hw.acpi.thermal.tz1._CRT: 97.0C hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz1._TC1: 5 hw.acpi.thermal.tz1._TC2: 4 hw.acpi.thermal.tz1._TSP: 600 If I can provide any additional information or test any patches, please, let me know. Ouch... Can you please try the attached patch? Please ignore this patch. I need little bit more thinking. Sorry, Jung-uk Kim ___ 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: Console options for legacy-free mini-itx server?
On Wed, Nov 17, 2010 at 01:42:15PM +1100, Ian Smith wrote: I'm used to seeing est either attach to both CPUs, or fail to attach to either CPU. Here it's attached to cpu0, but not to cpu1. Is that odd? It seems odd, but since I don't know what est does (there isn't a man page), I'm not sure how it (possibly) being broken affects me. Cheers, -- Andrew ___ 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: acpi(ca) mfc for 8.2
On Wednesday 17 November 2010 05:48 pm, Jung-uk Kim wrote: On Wednesday 17 November 2010 05:41 pm, Jung-uk Kim wrote: On Wednesday 17 November 2010 05:04 pm, Alexandre Sunny Kovalenko wrote: On Wed, 2010-11-17 at 20:43 +0200, Andriy Gapon wrote: I want to do MFC of ACPICA imports to stable/8 before 8.2 release. This would obviously include commits that fix mismerges or remove obsolete code. Plus some other small enhancements/fixes in our ACPI code. This is what I currently have: svn status: http://people.freebsd.org/~avg/acpi-stable-8.txt svn diff: http://people.freebsd.org/~avg/acpi-stable-8.diff svn log ...:http://people.freebsd.org/~avg/acpi-stable-8.log Please note that the svn diff above can not be used with patch(1), because of some svn peculiarities related to files in vendor area. Here's a plain diff that should be more useful: http://people.freebsd.org/~avg/acpi-stable-8.plain.diff I will appreciate any testing and reviews. Mobile users who track stable/8 would be the primary candidates, I guess :-) Thanks a lot! On my system: FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.1-STABLE FreeBSD 8.1-STABLE #0 r215086: Wed Nov 10 11:07:30 EST 2010 r...@rabbitsden.rabbitslawn.verizon.net:/usr/obj/usr/src/sys/TP X6 0 i386 running on ThinkPad X60, I get proliferation of acpi_tz0: error fetching current temperature -- AE_NOT_FOUND messages after applying the patch. Verbose dmesg from before and after cold boots are available at: http://members.verizon.net/~akovalenko/ACPI/dmesg.before.bz2 http://members.verizon.net/~akovalenko/ACPI/dmesg.after.bz2 respectively. Now, on this machine tz0 is not a real thermal zone but some kind of implement to initiate system shutdown for some case I never had enough time or inclination to track through ASL. Real thermal zone is tz1. hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 1 hw.acpi.thermal.tz0.temperature: 45.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 127.0C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: -1 hw.acpi.thermal.tz0._TC2: -1 hw.acpi.thermal.tz0._TSP: -1 hw.acpi.thermal.tz1.temperature: 43.0C hw.acpi.thermal.tz1.active: -1 hw.acpi.thermal.tz1.passive_cooling: 1 hw.acpi.thermal.tz1.thermal_flags: 0 hw.acpi.thermal.tz1._PSV: 75.0C hw.acpi.thermal.tz1._HOT: -1 hw.acpi.thermal.tz1._CRT: 97.0C hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz1._TC1: 5 hw.acpi.thermal.tz1._TC2: 4 hw.acpi.thermal.tz1._TSP: 600 If I can provide any additional information or test any patches, please, let me know. Ouch... Can you please try the attached patch? Please ignore this patch. I need little bit more thinking. I think I know what's going on. Andriy, it seems this change is missing from your patchset (maybe more): http://svn.freebsd.org/viewvc/base/head/sys/contrib/dev/acpica/utilities/utglobal.c?r1=210976r2=213806 Jung-uk Kim ___ 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: Console options for legacy-free mini-itx server?
On Thu, 2010-11-18 at 10:06 +1100, Andrew Reilly wrote: On Wed, Nov 17, 2010 at 01:42:15PM +1100, Ian Smith wrote: I'm used to seeing est either attach to both CPUs, or fail to attach to either CPU. Here it's attached to cpu0, but not to cpu1. Is that odd? It seems odd, but since I don't know what est does (there isn't a man page), I'm not sure how it (possibly) being broken affects me. Cheers, Faint reference to 'est' could be found in 'man cpufreq'. HTH, -- Alexandre Kovalenko (Олександр Коваленко) -- Ovi Mail: Making email access easy http://mail.ovi.com ___ 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: Console options for legacy-free mini-itx server?
On Wed, Nov 17, 2010 at 06:26:56PM -0500, Alexandre Sunny Kovalenko wrote: On Thu, 2010-11-18 at 10:06 +1100, Andrew Reilly wrote: On Wed, Nov 17, 2010 at 01:42:15PM +1100, Ian Smith wrote: I'm used to seeing est either attach to both CPUs, or fail to attach to either CPU. Here it's attached to cpu0, but not to cpu1. Is that odd? It seems odd, but since I don't know what est does (there isn't a man page), I'm not sure how it (possibly) being broken affects me. Cheers, Faint reference to 'est' could be found in 'man cpufreq'. Thanks for the reference! From reading that, it seems as though the sysctl-exposed functionality matches the dmesg.boot description (speed controls only available on cpu 0): 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/9 2799/83000 2666/77000 2533/71000 2399/65000 2266/59000 2133/53000 1999/46000 1866/4 1733/34000 1599/28000 1466/22000 1333/16000 1199/1 1049/8750 899/7500 749/6250 599/5000 449/3750 299/2500 149/1250 dev.cpu.0.cx_supported: C1/3 C2/205 C3/245 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 311us 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/3 C2/205 C3/245 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% last 191us Since the cpufreq man page lists the inability to set the frequency of different CPUs differently, perhaps this isn't a bug at all? Cheers, -- Andrew ___ 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: Console options for legacy-free mini-itx server?
On Thu, 2010-11-18 at 10:40 +1100, Andrew Reilly wrote: On Wed, Nov 17, 2010 at 06:26:56PM -0500, Alexandre Sunny Kovalenko wrote: On Thu, 2010-11-18 at 10:06 +1100, Andrew Reilly wrote: On Wed, Nov 17, 2010 at 01:42:15PM +1100, Ian Smith wrote: I'm used to seeing est either attach to both CPUs, or fail to attach to either CPU. Here it's attached to cpu0, but not to cpu1. Is that odd? It seems odd, but since I don't know what est does (there isn't a man page), I'm not sure how it (possibly) being broken affects me. Cheers, Faint reference to 'est' could be found in 'man cpufreq'. Thanks for the reference! From reading that, it seems as though the sysctl-exposed functionality matches the dmesg.boot description (speed controls only available on cpu 0): 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/9 2799/83000 2666/77000 2533/71000 2399/65000 2266/59000 2133/53000 1999/46000 1866/4 1733/34000 1599/28000 1466/22000 1333/16000 1199/1 1049/8750 899/7500 749/6250 599/5000 449/3750 299/2500 149/1250 dev.cpu.0.cx_supported: C1/3 C2/205 C3/245 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 311us 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/3 C2/205 C3/245 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% last 191us Since the cpufreq man page lists the inability to set the frequency of different CPUs differently, perhaps this isn't a bug at all? Cheers, Does portion of 'devinfo -rv' similar to the snippet below show 'est' attached to both CPUs? ... cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU0 ACPI I/O ports: 0x1014 0x1015 acpi_perf0 acpi_throttle0 coretemp0 == est0 p4tcc0 cpufreq0 cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU1 ACPI I/O ports: 0x1014 0x1015 acpi_perf1 acpi_throttle1 coretemp1 == est1 p4tcc1 cpufreq1 ... -- Alexandre Kovalenko (Олександр Коваленко) -- Ovi Mail: Making email access easy http://mail.ovi.com ___ 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: High cpu usage when using ZFS cache device
same problem here after ~ 30 days with a production server and 2 SSD Intel X25M as L2. so we update and reboot the 8-STABLE server every month. 2010/11/17 Christer Solskogen christer.solsko...@gmail.com On Wed, Nov 17, 2010 at 8:47 AM, Christer Solskogen christer.solsko...@gmail.com wrote: Will try to reboot server now to se if that has any impact. It seems to have solved it. At least temporary. -- chs, ___ 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 ___ 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: Console options for legacy-free mini-itx server?
Hi Alexandre, On Wed, Nov 17, 2010 at 06:56:53PM -0500, Alexandre Sunny Kovalenko wrote: On Thu, 2010-11-18 at 10:40 +1100, Andrew Reilly wrote: 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/9 2799/83000 2666/77000 2533/71000 2399/65000 2266/59000 2133/53000 1999/46000 1866/4 1733/34000 1599/28000 1466/22000 1333/16000 1199/1 1049/8750 899/7500 749/6250 599/5000 449/3750 299/2500 149/1250 dev.cpu.0.cx_supported: C1/3 C2/205 C3/245 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 311us 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/3 C2/205 C3/245 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% last 191us Since the cpufreq man page lists the inability to set the frequency of different CPUs differently, perhaps this isn't a bug at all? Cheers, Does portion of 'devinfo -rv' similar to the snippet below show 'est' attached to both CPUs? ... cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU0 ACPI I/O ports: 0x1014 0x1015 acpi_perf0 acpi_throttle0 coretemp0 == est0 p4tcc0 cpufreq0 cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU1 ACPI I/O ports: 0x1014 0x1015 acpi_perf1 acpi_throttle1 coretemp1 == est1 p4tcc1 cpufreq1 ... Yes, but as you can see they are not nested under coretemp. devices: cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU0 ACPI I/O ports: 0x414 0x415 acpi_perf0 est0 p4tcc0 cpufreq0 cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU1 ACPI I/O ports: 0x414 0x415 acpi_perf1 est1 p4tcc1 cpufreq1 This seems to be at odds with the dmesg and sysctl view of things? Cheers, -- Andrew ___ 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: Console options for legacy-free mini-itx server?
On 15-11-2010 05:55, Andrew Reilly wrote: Oh: the other thing about this system: I can't warm-start it, have to power down and then manually hit the power-on button. Attempting to reboot leaves the console sitting at something like Stopping other CPUs forever. Andrew, No solution for you unfortunately, just a me too. I have this exact issue on a (very) small box I bought recently. Details here: http://lists.freebsd.org/pipermail/freebsd-acpi/2010-October/006813.html My post didn't yield any responses, and I haven't found a solution. There is a few acpi reboot related looking sysctls though. They didn't do anything for me, but maybe they will work for you, if you haven't already tried them: # sysctl hw.acpi | grep reboot hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 Good luck, Thomas Steen Rasmussen ___ 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: Console options for legacy-free mini-itx server?
On Thu, 2010-11-18 at 11:13 +1100, Andrew Reilly wrote: Hi Alexandre, On Wed, Nov 17, 2010 at 06:56:53PM -0500, Alexandre Sunny Kovalenko wrote: On Thu, 2010-11-18 at 10:40 +1100, Andrew Reilly wrote: 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/9 2799/83000 2666/77000 2533/71000 2399/65000 2266/59000 2133/53000 1999/46000 1866/4 1733/34000 1599/28000 1466/22000 1333/16000 1199/1 1049/8750 899/7500 749/6250 599/5000 449/3750 299/2500 149/1250 dev.cpu.0.cx_supported: C1/3 C2/205 C3/245 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 311us 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/3 C2/205 C3/245 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% last 191us Since the cpufreq man page lists the inability to set the frequency of different CPUs differently, perhaps this isn't a bug at all? Cheers, Does portion of 'devinfo -rv' similar to the snippet below show 'est' attached to both CPUs? ... cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU0 ACPI I/O ports: 0x1014 0x1015 acpi_perf0 acpi_throttle0 coretemp0 == est0 p4tcc0 cpufreq0 cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU1 ACPI I/O ports: 0x1014 0x1015 acpi_perf1 acpi_throttle1 coretemp1 == est1 p4tcc1 cpufreq1 ... Yes, but as you can see they are not nested under coretemp. devices: cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU0 ACPI I/O ports: 0x414 0x415 acpi_perf0 est0 p4tcc0 cpufreq0 cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU1 ACPI I/O ports: 0x414 0x415 acpi_perf1 est1 p4tcc1 cpufreq1 This seems to be at odds with the dmesg and sysctl view of things? Cheers, I am sorry -- in the attempt to point them out, I have messed up the alignment -- they *should not* be nested under coretemp. It is strange that 'est' reported error on attach, yet seems to be attached to the device. This said, I am way out of my depth here -- hopefully someone smarter than I will chime in. -- Alexandre Kovalenko (Олександр Коваленко) -- Ovi Mail: Making email access easy http://mail.ovi.com ___ 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: Console options for legacy-free mini-itx server?
On Wed, 17 Nov 2010, Alexandre Sunny Kovalenko wrote: On Thu, 2010-11-18 at 11:13 +1100, Andrew Reilly wrote: Hi Alexandre, On Wed, Nov 17, 2010 at 06:56:53PM -0500, Alexandre Sunny Kovalenko wrote: On Thu, 2010-11-18 at 10:40 +1100, Andrew Reilly wrote: 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/9 2799/83000 2666/77000 2533/71000 2399/65000 2266/59000 2133/53000 1999/46000 1866/4 1733/34000 1599/28000 1466/22000 1333/16000 1199/1 1049/8750 899/7500 749/6250 599/5000 449/3750 299/2500 149/1250 dev.cpu.0.cx_supported: C1/3 C2/205 C3/245 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 311us 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/3 C2/205 C3/245 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% last 191us Since the cpufreq man page lists the inability to set the frequency of different CPUs differently, perhaps this isn't a bug at all? Cheers, Does portion of 'devinfo -rv' similar to the snippet below show 'est' attached to both CPUs? ... cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU0 ACPI I/O ports: 0x1014 0x1015 acpi_perf0 acpi_throttle0 coretemp0 == est0 p4tcc0 cpufreq0 cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU1 ACPI I/O ports: 0x1014 0x1015 acpi_perf1 acpi_throttle1 coretemp1 == est1 p4tcc1 cpufreq1 ... Yes, but as you can see they are not nested under coretemp. devices: cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU0 ACPI I/O ports: 0x414 0x415 acpi_perf0 est0 p4tcc0 cpufreq0 cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU1 ACPI I/O ports: 0x414 0x415 acpi_perf1 est1 p4tcc1 cpufreq1 This seems to be at odds with the dmesg and sysctl view of things? Cheers, I am sorry -- in the attempt to point them out, I have messed up the alignment -- they *should not* be nested under coretemp. It is strange that 'est' reported error on attach, yet seems to be attached to the device. This said, I am way out of my depth here -- hopefully someone smarter than I will chime in. That's not me :) I only noticed it in the context of Andrew originally saying that it hung after Stopping other CPUs, and it seemed unusual. Sorry for the wild goose chase .. 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: Degraded zpool cannot detach old/bad drive
Hi jhell, everyone, Thanks for your feedback and support everyone. Indeed after successfully disabling /dev/gptid/* zfs managed to find all the gpt/ labels without a problem and the array looked exactly the way it did in the very beginning. So at that point I could say that I was able to fully recover the array without data loss to exactly the state it was in the beginning of its creation. Not without adventure though ;) Ironically due to some other reasons just after I fully recovered it I had to destroy it and rebuild from scratch with raidz2 vdevs (of 8 disks) rather than raidz1s (of 4 disks) ;) Basically I need better redundancy so that I can handle double disk failure in a vdev. Seems like the chance of a second disk failing while rebuilding the zpool for like 15 hours on those 2TB disks is quite significant. I wonder if this conversion will reduce the IOPs of the pool in half ... Anyway, thank you once again. Highly appreciated. I hope this is a helpful piece of discussion for other people having similar problems. Cheers, Rumen Telbizov On Tue, Nov 16, 2010 at 8:55 PM, jhell jh...@dataix.net wrote: On 11/16/2010 16:15, Rumen Telbizov wrote: It seems like *kern.geom.label.gptid.enable: 0 *does not work anymore? I am pretty sure I was able to hide all the /dev/gptid/* entries with this sysctl variable before but now it doesn't quite work for me. I could be wrong but I believe that is more of a loader tuneable than a sysctl that should be modified at run-time. Rebooting with this set to 0 will disable showing the /dev/gptid directory. This makes me wonder if those sysctl's should be marked read-only at run-time. Though you could even rm -rf /dev/gptid ;) -- jhell,v -- Rumen Telbizov http://telbizov.com ___ 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
