Re: {arch}/conf/DEFAULTS and uart
In message: <20100912170344.ga58...@freebsd.org> Alexander Best writes: : also i noticed that after keywords like "device" there're two tabs, : whereas after the keyword "options" there's one space and a : tab. since i don't know, if this was done on purpose i didn't change : it. It is on purpose. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: NFS lockups with VMware esxi client
> I have NFS sharing a ZFS pool that VMware esxi stores files on. When > put under stress (an OS installation, but not Linux compilation), the > NFS server locks, spiking to 100% CPU usage. Not even kill -KILL can > stop the process, so rebooting is required. > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 885 root 4 44 0 5804K 988K CPU2 0 239:39 100.00% nfsd > > Other people have run into this problem, but I never found a solution. > I'm running 8.1-PRERELEASE on amd64, but I think others have seen the > problem on 8.1-RELEASE. > > zpool status reports that the pool is healthy, so that's not it. My > only two ideas are hosting on something other than ZFS and trying to > reproduce it with a lot of big, random NFS requests. Any other ideas? > I believe it is patched in head/current. A compatible patch is at: http://people.freebsd.org/~rmacklem/freebsd8.1-patches/replay.patch rick ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
NFS lockups with VMware esxi client
I have NFS sharing a ZFS pool that VMware esxi stores files on. When put under stress (an OS installation, but not Linux compilation), the NFS server locks, spiking to 100% CPU usage. Not even kill -KILL can stop the process, so rebooting is required. PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 885 root 4 440 5804K 988K CPU20 239:39 100.00% nfsd Other people have run into this problem, but I never found a solution. I'm running 8.1-PRERELEASE on amd64, but I think others have seen the problem on 8.1-RELEASE. zpool status reports that the pool is healthy, so that's not it. My only two ideas are hosting on something other than ZFS and trying to reproduce it with a lot of big, random NFS requests. Any other ideas? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r212281 breaks KDE
Can you try the attached(hackish) patch?
Index: vm_map.c
===
--- vm_map.c (revision 212479)
+++ vm_map.c (working copy)
@@ -128,7 +128,7 @@
static void vm_map_zfini(void *mem, int size);
static void _vm_map_init(vm_map_t map, pmap_t pmap, vm_offset_t min,
vm_offset_t max);
-static void vm_map_entry_dispose(vm_map_t map, vm_map_entry_t entry);
+void vm_map_entry_dispose(vm_map_t map, vm_map_entry_t entry);
#ifdef INVARIANTS
static void vm_map_zdtor(void *mem, int size, void *arg);
static void vmspace_zdtor(void *mem, int size, void *arg);
@@ -716,7 +716,7 @@
*
* Inverse of vm_map_entry_create.
*/
-static void
+void
vm_map_entry_dispose(vm_map_t map, vm_map_entry_t entry)
{
uma_zfree(map->system_map ? kmapentzone : mapentzone, entry);
Index: vm_mmap.c
===
--- vm_mmap.c (revision 212479)
+++ vm_mmap.c (working copy)
@@ -123,6 +123,8 @@
static int vm_mmap_shm(struct thread *, vm_size_t, vm_prot_t, vm_prot_t *,
int *, struct shmfd *, vm_ooffset_t, vm_object_t *);
+void vm_map_entry_dispose(vm_map_t map, vm_map_entry_t entry);
+
/*
* MPSAFE
*/
@@ -550,6 +552,8 @@
#ifdef HWPMC_HOOKS
struct pmckern_map_out pkm;
vm_map_entry_t entry;
+ vm_map_entry_t free_entry;
+ vm_object_t object;
#endif
vm_offset_t addr;
vm_size_t size, pageoff;
@@ -596,11 +600,25 @@
vm_map_delete(map, addr, addr + size);
#ifdef HWPMC_HOOKS
+ free_entry = map->deferred_freelist;
+ map->deferred_freelist = NULL;
/* downgrade the lock to prevent a LOR with the pmc-sx lock */
vm_map_lock_downgrade(map);
if (pkm.pm_address != (uintptr_t) NULL)
PMC_CALL_HOOK(td, PMC_FN_MUNMAP, (void *) &pkm);
vm_map_unlock_read(map);
+
+ while (free_entry != NULL) {
+ entry = free_entry;
+ free_entry = free_entry->next;
+
+ if ((entry->eflags & MAP_ENTRY_IS_SUB_MAP) == 0) {
+ object = entry->object.vm_object;
+ vm_object_deallocate(object);
+ }
+
+ vm_map_entry_dispose(map, entry);
+ }
#else
vm_map_unlock(map);
#endif
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r212281 breaks KDE
On Sun, Sep 12, 2010 at 10:42:57AM -0400, Michael Butler wrote: > For the last week, on and off, I've been looking for something that > caused KDE to be horridly unstable, i.e. machine freezes with and > without a core-dump. > > Removing r212281 (and r212282) restores that stability. Is there a race > condition that this update exposes by reducing lock strength? > > The most common failure with this code included produces a back-trace > similar to the one attached, > > imb > toshi.auburn.protected-networks.net dumped core - see /var/crash/vmcore.0 > > Sat Sep 11 15:33:22 EDT 2010 > > FreeBSD toshi.auburn.protected-networks.net 9.0-CURRENT FreeBSD 9.0-CURRENT > #5 r212466M: Sat Sep 11 10:10:59 EDT 2010 > r...@toshi.auburn.protected-networks.net:/usr/obj/usr/home/imb/svn/head/sys/TOSHI > i386 > > panic: page fault > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd"... > > Unread portion of the kernel message buffer: > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x22c > fault code= supervisor read, page not present > instruction pointer = 0x20:0xc066705a > stack pointer = 0x28:0xe944b7f8 > frame pointer = 0x28:0xe944b810 > code segment = base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 1938 (kdeinit4) > trap number = 12 > panic: page fault > cpuid = 0 > Uptime: 2m33s > Physical memory: 3049 MB > Dumping 225 MB: 210 194 178 162 146 130 114 98 82 66 50 34 18 2 > > Reading symbols from /boot/modules/vboxdrv.ko...done. > Loaded symbols for /boot/modules/vboxdrv.ko > Reading symbols from /boot/modules/vboxnetflt.ko...done. > Loaded symbols for /boot/modules/vboxnetflt.ko > Reading symbols from /boot/modules/vboxnetadp.ko...done. > Loaded symbols for /boot/modules/vboxnetadp.ko > Reading symbols from /usr/local/modules/fuse.ko...done. > Loaded symbols for /usr/local/modules/fuse.ko > #0 doadump () at pcpu.h:231 > 231 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump () at pcpu.h:231 > #1 0xc06760f7 in boot (howto=260) > at /usr/home/imb/svn/head/sys/kern/kern_shutdown.c:416 > #2 0xc06764e8 in panic (fmt=0x104 ) > at /usr/home/imb/svn/head/sys/kern/kern_shutdown.c:590 > #3 0xc09950ff in trap_fatal (frame=0xe944b7b8, eva=40) > at /usr/home/imb/svn/head/sys/i386/i386/trap.c:980 > #4 0xc0995469 in trap_pfault (frame=0xe944b7b8, usermode=0, eva=556) > at /usr/home/imb/svn/head/sys/i386/i386/trap.c:893 > #5 0xc09958f7 in trap (frame=0xe944b7b8) > at /usr/home/imb/svn/head/sys/i386/i386/trap.c:568 > #6 0xc097e16c in calltrap () > at /usr/home/imb/svn/head/sys/i386/i386/exception.s:168 > #7 0xc066705a in _mtx_lock_sleep (m=0xc81c26e8, tid=3343885696, opts=0, > file=0x0, line=0) at /usr/home/imb/svn/head/sys/kern/kern_mutex.c:369 > #8 0xc09385d8 in vnode_create_vobject (vp=0xc825a330, isize=512, > td=0xc74fa580) at /usr/home/imb/svn/head/sys/vm/vnode_pager.c:111 From the frame 8, please print the content of the *vp, and from it, content of vm object. The corresponding kgdb commands would be frame 8 p *vp p *(vp->v_bufobj.bo_object) pgpJ8BIaOMuQB.pgp Description: PGP signature
Re: r212281 breaks KDE
On 09/12/10 12:19, Kostik Belousov wrote: > On Sun, Sep 12, 2010 at 10:42:57AM -0400, Michael Butler wrote: >> >> Removing r212281 (and r212282) restores that stability. Is there a race >> condition that this update exposes by reducing lock strength? [ .. ] > Does the following change make any difference to you ? It made it worse :-( "Frozen" just as X tries to take over the display, imb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: {arch}/conf/DEFAULTS and uart
On Sun Sep 12 10, Marius Strobl wrote: > On Sun, Sep 12, 2010 at 02:40:49AM +, Alexander Best wrote: > > On Fri Sep 10 10, John Baldwin wrote: > > > On Thursday, September 09, 2010 3:50:45 pm Alexander Best wrote: > > > > On Thu Sep 9 10, Alexander Best wrote: > > > > > On Thu Sep 9 10, Alexander Best wrote: > > > > > > hi there, > > > > > > > > > > > > except for arm most archs seem to enforce uart support in > > > > > > conf/DEFAULTS. is > > > > > > this really necessary? shouldn't DEFAULTS only contain vital > > > > > > devices/options > > > > > > without a kernel on a specific arch won't function at all? > > > > > > > > > > jhb just explained to me, that the uart entry in DEFAULTS is not a > > > > > controller > > > > > or something like that, but the uart backend to use *if* uart gets > > > > > defined in > > > > > the kernel config. > > > > > > > > > > sorry for the noise folks. > > > > > > > > however i found some missing comments and incorrect syntax which i > > > > fixed. > > > > > > > > see the attached patch. > > > > > > I think the ia64 ordering for 'io and mem' is probably more correct > > > (alphabetically sorted), so I would fix i386 and amd64 and leave ia64 > > > alone. > > > > > > The powerpc 'machine' changes are wrong I think as it would break > > > GENERIC64 > > > and powerpc64 kernel configs in general. Nathan purposefully removed > > > 'machine' from the powerpc DEFAULTS. > > > > here's try #2. ;) > > > > diff --git a/sys/sparc64/conf/DEFAULTS b/sys/sparc64/conf/DEFAULTS > > index 38b2408..2e60c94 100644 > > --- a/sys/sparc64/conf/DEFAULTS > > +++ b/sys/sparc64/conf/DEFAULTS > > @@ -5,7 +5,7 @@ > > > > machinesparc64 > > > > -# Pseudo devices. > > +# Pseudo devices > > device mem # Memory and kernel memory devices > > > > # UART chips on this platform > > @@ -17,5 +17,5 @@ deviceuart_z8530 > > optionsGEOM_PART_BSD > > optionsGEOM_PART_VTOC8 > > > > -# Let sunkbd emulate an AT keyboard by default. > > +# Let sunkbd emulate an AT keyboard by default > > IMO this is a complete sentence and thus the period should stay. agreed. :) also i think i accidently replaced the tab between the two words "powerpc" in sys/powerpc/conf/GENERIC with a space. :( also i noticed that after keywords like "device" there're two tabs, whereas after the keyword "options" there's one space and a tab. since i don't know, if this was done on purpose i didn't change it. cheers. alex > > Marius > -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: {arch}/conf/DEFAULTS and uart
On Sun, Sep 12, 2010 at 02:40:49AM +, Alexander Best wrote: > On Fri Sep 10 10, John Baldwin wrote: > > On Thursday, September 09, 2010 3:50:45 pm Alexander Best wrote: > > > On Thu Sep 9 10, Alexander Best wrote: > > > > On Thu Sep 9 10, Alexander Best wrote: > > > > > hi there, > > > > > > > > > > except for arm most archs seem to enforce uart support in > > > > > conf/DEFAULTS. is > > > > > this really necessary? shouldn't DEFAULTS only contain vital > > > > > devices/options > > > > > without a kernel on a specific arch won't function at all? > > > > > > > > jhb just explained to me, that the uart entry in DEFAULTS is not a > > > > controller > > > > or something like that, but the uart backend to use *if* uart gets > > > > defined in > > > > the kernel config. > > > > > > > > sorry for the noise folks. > > > > > > however i found some missing comments and incorrect syntax which i fixed. > > > > > > see the attached patch. > > > > I think the ia64 ordering for 'io and mem' is probably more correct > > (alphabetically sorted), so I would fix i386 and amd64 and leave ia64 alone. > > > > The powerpc 'machine' changes are wrong I think as it would break GENERIC64 > > and powerpc64 kernel configs in general. Nathan purposefully removed > > 'machine' from the powerpc DEFAULTS. > > here's try #2. ;) > > diff --git a/sys/sparc64/conf/DEFAULTS b/sys/sparc64/conf/DEFAULTS > index 38b2408..2e60c94 100644 > --- a/sys/sparc64/conf/DEFAULTS > +++ b/sys/sparc64/conf/DEFAULTS > @@ -5,7 +5,7 @@ > > machine sparc64 > > -# Pseudo devices. > +# Pseudo devices > device mem # Memory and kernel memory devices > > # UART chips on this platform > @@ -17,5 +17,5 @@ device uart_z8530 > options GEOM_PART_BSD > options GEOM_PART_VTOC8 > > -# Let sunkbd emulate an AT keyboard by default. > +# Let sunkbd emulate an AT keyboard by default IMO this is a complete sentence and thus the period should stay. Marius ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r212281 breaks KDE
On Sun, Sep 12, 2010 at 10:42:57AM -0400, Michael Butler wrote:
> For the last week, on and off, I've been looking for something that
> caused KDE to be horridly unstable, i.e. machine freezes with and
> without a core-dump.
>
> Removing r212281 (and r212282) restores that stability. Is there a race
> condition that this update exposes by reducing lock strength?
>
> The most common failure with this code included produces a back-trace
> similar to the one attached,
>
Does the following change make any difference to you ?
diff --git a/sys/vm/vm_mmap.c b/sys/vm/vm_mmap.c
index 63dfb67..d13e488 100644
--- a/sys/vm/vm_mmap.c
+++ b/sys/vm/vm_mmap.c
@@ -597,13 +597,15 @@ munmap(td, uap)
#ifdef HWPMC_HOOKS
/* downgrade the lock to prevent a LOR with the pmc-sx lock */
- vm_map_lock_downgrade(map);
- if (pkm.pm_address != (uintptr_t) NULL)
- PMC_CALL_HOOK(td, PMC_FN_MUNMAP, (void *) &pkm);
- vm_map_unlock_read(map);
-#else
- vm_map_unlock(map);
+ if (pkm.pm_address != (uintptr_t)NULL) {
+ vm_map_lock_downgrade(map);
+ if (pkm.pm_address != (uintptr_t)NULL)
+ PMC_CALL_HOOK(td, PMC_FN_MUNMAP, (void *)&pkm);
+ vm_map_unlock_read(map);
+ vm_map_lock(map);
+ }
#endif
+ vm_map_unlock(map);
/* vm_map_delete returns nothing but KERN_SUCCESS anyway */
return (0);
}
pgpRGcRQOlYVk.pgp
Description: PGP signature
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
Andriy Gapon wrote:
> on 12/09/2010 18:22 Andriy Gapon said the following:
>> Observations are correct, but incomplete; the conclusions are wrong.
>> At the end of the boot there are message like this one:
>> PROCESSOR-0722 [402244] cpu_cx_cst: acpi_cpu0: Got C2 - 245
>> latency
>> This is a result of re-evaluation of _CST because of a notification from
>> ACPI.
>
> But still, as you suggest, a patch like the following should be tested and
> committed:
>
> --- a/sys/dev/acpica/acpi_cpu.c
> +++ b/sys/dev/acpica/acpi_cpu.c
> @@ -828,7 +828,8 @@ acpi_cpu_cx_list(struct acpi_cpu_softc *sc)
> sbuf_new(&sb, sc->cpu_cx_supported, sizeof(sc->cpu_cx_supported),
> SBUF_FIXEDLEN);
> for (i = 0; i < sc->cpu_cx_count; i++) {
> - sbuf_printf(&sb, "C%d/%d ", i + 1, sc->cpu_cx_states[i].trans_lat);
> + sbuf_printf(&sb, "C%d/%d ", sc->cpu_cx_states[i].type,
> + sc->cpu_cx_states[i].trans_lat);
> if (sc->cpu_cx_states[i].type < ACPI_STATE_C3)
> sc->cpu_non_c3 = i;
> }
I am not sure this patch is complete:
1) AFAIR I have seen somewhere example where system had several C-states
with different latency, but the same type - C3. Type only means
enter/exit semantics, and there could be several states with the same
semantics. Not sire how to properly them in this case. May be existing
approach was not so bad. It is ACPI C-states, not CPU C-states, they are
not same. May be we should just mention type somewhere in addition.
2) This change makes heavily understandable values of cx_lowest.
3) If touch cx_lowest, I would prefer to see there possibility to set it
to some abstract C6 or whatever, allowing system automatically choose
state it has available at the moment.
--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
Hi avg. On Sun, 12 Sep 2010 18:38:58 +0300 Andriy Gapon wrote: > > Observations are correct, but incomplete; the conclusions are wrong. > > At the end of the boot there are message like this one: > > PROCESSOR-0722 [402244] cpu_cx_cst: acpi_cpu0: Got C2 - 245 > > latency > > This is a result of re-evaluation of _CST because of a notification from > > ACPI. > But still, as you suggest, a patch like the following should be tested and > committed: Thank you, I'll test your patch. But I'm rebuilding another patches. So please wait next day. -- Norikatsu Shigemura ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
on 12/09/2010 18:22 Andriy Gapon said the following:
> Observations are correct, but incomplete; the conclusions are wrong.
> At the end of the boot there are message like this one:
> PROCESSOR-0722 [402244] cpu_cx_cst: acpi_cpu0: Got C2 - 245
> latency
> This is a result of re-evaluation of _CST because of a notification from ACPI.
>
But still, as you suggest, a patch like the following should be tested and
committed:
--- a/sys/dev/acpica/acpi_cpu.c
+++ b/sys/dev/acpica/acpi_cpu.c
@@ -828,7 +828,8 @@ acpi_cpu_cx_list(struct acpi_cpu_softc *sc)
sbuf_new(&sb, sc->cpu_cx_supported, sizeof(sc->cpu_cx_supported),
SBUF_FIXEDLEN);
for (i = 0; i < sc->cpu_cx_count; i++) {
- sbuf_printf(&sb, "C%d/%d ", i + 1, sc->cpu_cx_states[i].trans_lat);
+ sbuf_printf(&sb, "C%d/%d ", sc->cpu_cx_states[i].type,
+ sc->cpu_cx_states[i].trans_lat);
if (sc->cpu_cx_states[i].type < ACPI_STATE_C3)
sc->cpu_non_c3 = i;
}
P.S. I restored acpi@ cc: which I think is quite relevant, but was somehow lost.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Experimental NFS server oddity
> On Sep 11, 2010, at 5:26 PM, Rick Macklem wrote: > >> On Sep 11, 2010, at 4:20 PM, Rick Macklem wrote: > >> > >>> You can also look in /var/log/messages to see if any of the > >>> daemons > >>> are complaining about something. > >> > >> Only warning I see on a system reboot is: > >> nfsd: can't open /var/db/nfs-stablerestart > >> > >> Creating this file and then rebooting the system seems to get > >> things > >> working. > >> > >> This file certainly wasn't required by the old nfsd. > >> Should this file be created by /etc/rc.d/nfsserver at boot time (if > >> it > >> doesn't exist)? > >> Or should it be created by installworld? > >> > > Technically, it should only be created for a fresh install on a disk > > that has never been set up before. (ie. Not on an update/upgrade > > unless it has never existed before.) > > > > As such, I just documented it in "man nfsv4" for now, > > This is going to bite people on upgrades since > the old server didn't require this file, so people > upgrading from the old nfsd are going to hit > this problem pretty consistently. > > I'd like to at least consider alternatives to the > current behavior; maybe one of the following? > * If the file doesn't exist on startup, create it > and warn loudly. > * Similar to isc-dhcp, periodically make a > a backup copy of the file and only create a > fresh blank one if the file and backup are > both missing. I think this might be a reasonable compromise. The kernel can signal the master nfsd (which remains in userland) to copy the file to a backup after it has been updated, then the backup can be used if the regular one is lost/corrupted. If neither exists, creating new ones seems reasonable. Other opinions? rick > * "make installworld" is certainly capable > of creating this file only if it doesn't already > exist. (That doesn't cover the binary > update case, of course.) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
on 12/09/2010 13:37 Alexander Motin said the following: > Andriy Gapon wrote: >> acpi_lid0: Lid closed >> em0: Link is up 1000 Mbps Full Duplex >> PROCESSOR-0722 [402244] cpu_cx_cst: acpi_cpu0: Got C2 - 245 >> latency >> PROCESSOR-0722 [403097] cpu_cx_cst: acpi_cpu1: Got C2 - 245 >> latency >> PROCESSOR-0722 [403855] cpu_cx_cst: acpi_cpu2: Got C2 - 245 >> latency >> PROCESSOR-0722 [405022] cpu_cx_cst: acpi_cpu3: Got C2 - 245 >> latency >> >> Maybe because of this? >> It seems like you do something and ACPI disables C3, leaving only C2/ > > One strange thing. During boot it can be seen: > acpi_cpu0: Got C2 - 205 latency > acpi_cpu0: Got C3 - 245 latency > , but after boot in sysctl we can see: > dev.cpu.0.cx_supported: C1/3 C2/245 > > It respecting latency it looks like not C3 got lost, but C2. AFAIR, > sysctl numbers C-states completely abstract, just as array indexes. So > thing reported as C2 could instead be C3, while C2 is absent for some > reason. Observations are correct, but incomplete; the conclusions are wrong. At the end of the boot there are message like this one: PROCESSOR-0722 [402244] cpu_cx_cst: acpi_cpu0: Got C2 - 245 latency This is a result of re-evaluation of _CST because of a notification from ACPI. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ZFS v28 is ready for wider testing.
Hi, I have just imported your VirtualBox appliance, created some zpool and wanted to try *dedup* on FreeBSD, but while I was able to enable *dedup*, I was not able to check *dedupratio* because that 'property' is not available, on OpenSolaris it looked like that: # zpool get dedupratio pool NAME PROPERTYVALUE SOURCE tpool dedupratio 1.00x - Regards, vermaden -- KONKURS: Wygraj nowoczesny telefon komorkowy! Sprawdz >> http://linkint.pl/f2803 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
r212281 breaks KDE
For the last week, on and off, I've been looking for something that caused KDE to be horridly unstable, i.e. machine freezes with and without a core-dump. Removing r212281 (and r212282) restores that stability. Is there a race condition that this update exposes by reducing lock strength? The most common failure with this code included produces a back-trace similar to the one attached, imb toshi.auburn.protected-networks.net dumped core - see /var/crash/vmcore.0 Sat Sep 11 15:33:22 EDT 2010 FreeBSD toshi.auburn.protected-networks.net 9.0-CURRENT FreeBSD 9.0-CURRENT #5 r212466M: Sat Sep 11 10:10:59 EDT 2010 r...@toshi.auburn.protected-networks.net:/usr/obj/usr/home/imb/svn/head/sys/TOSHI i386 panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x22c fault code = supervisor read, page not present instruction pointer = 0x20:0xc066705a stack pointer = 0x28:0xe944b7f8 frame pointer = 0x28:0xe944b810 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1938 (kdeinit4) trap number = 12 panic: page fault cpuid = 0 Uptime: 2m33s Physical memory: 3049 MB Dumping 225 MB: 210 194 178 162 146 130 114 98 82 66 50 34 18 2 Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/modules/vboxnetflt.ko...done. Loaded symbols for /boot/modules/vboxnetflt.ko Reading symbols from /boot/modules/vboxnetadp.ko...done. Loaded symbols for /boot/modules/vboxnetadp.ko Reading symbols from /usr/local/modules/fuse.ko...done. Loaded symbols for /usr/local/modules/fuse.ko #0 doadump () at pcpu.h:231 231 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:231 #1 0xc06760f7 in boot (howto=260) at /usr/home/imb/svn/head/sys/kern/kern_shutdown.c:416 #2 0xc06764e8 in panic (fmt=0x104 ) at /usr/home/imb/svn/head/sys/kern/kern_shutdown.c:590 #3 0xc09950ff in trap_fatal (frame=0xe944b7b8, eva=40) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:980 #4 0xc0995469 in trap_pfault (frame=0xe944b7b8, usermode=0, eva=556) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:893 #5 0xc09958f7 in trap (frame=0xe944b7b8) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:568 #6 0xc097e16c in calltrap () at /usr/home/imb/svn/head/sys/i386/i386/exception.s:168 #7 0xc066705a in _mtx_lock_sleep (m=0xc81c26e8, tid=3343885696, opts=0, file=0x0, line=0) at /usr/home/imb/svn/head/sys/kern/kern_mutex.c:369 #8 0xc09385d8 in vnode_create_vobject (vp=0xc825a330, isize=512, td=0xc74fa580) at /usr/home/imb/svn/head/sys/vm/vnode_pager.c:111 #9 0xc0904751 in ufs_lookup_ino (vdp=0xc825a330, vpp=0xe944bb40, cnp=0xe944bb54, dd_ino=0x0) at /usr/home/imb/svn/head/sys/ufs/ufs/ufs_lookup.c:260 #10 0xc0905370 in ufs_lookup (ap=0xe944b97c) at /usr/home/imb/svn/head/sys/ufs/ufs/ufs_lookup.c:215 #11 0xc06f9cc6 in vfs_cache_lookup (ap=0xe944ba08) at vnode_if.h:80 #12 0xc09b2811 in VOP_LOOKUP_APV (vop=0xc0ac7480, a=0xe944ba08) at vnode_if.c:123 #13 0xc0700e89 in lookup (ndp=0xe944bb28) at vnode_if.h:54 #14 0xc070218c in namei (ndp=0xe944bb28) at /usr/home/imb/svn/head/sys/kern/vfs_lookup.c:268 #15 0xc0711513 in kern_statat_vnhook (td=0xc74fa580, flag=0, fd=-100, path=0x2b2aa050 , pathseg=UIO_USERSPACE, sbp=0xe944bbe4, hook=0) at /usr/home/imb/svn/head/sys/kern/vfs_syscalls.c:2352 #16 0xc07116b7 in kern_statat (td=0xc74fa580, flag=0, fd=-100, path=0x2b2aa050 , pathseg=UIO_USERSPACE, sbp=0xe944bbe4) at /usr/home/imb/svn/head/sys/kern/vfs_syscalls.c:2333 #17 0xc07117db in kern_stat (td=0xc74fa580, path=0x2b2aa050 , pathseg=UIO_USERSPACE, sbp=0xe944bbe4) at /usr/home/imb/svn/head/sys/kern/vfs_syscalls.c:2325 #18 0xc071186f in stat (td=0xc74fa580, uap=0xe944bcec) at /usr/home/imb/svn/head/sys/kern/vfs_syscalls.c:2294 #19 0xc06b4087 in syscallenter (td=0xc74fa580, sa=0xe944bce4) at /usr/home/imb/svn/head/sys/kern/subr_trap.c:319 #20 0xc09954cc in syscall (frame=0xe944bd28) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:1095 #21 0xc097e1d1 in Xint0x80_syscall () at /usr/home/imb/svn/head/sys/i386/i386/exception.s:266 #22 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) ___ freebsd-curr
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
Hi.
On Sun, 12 Sep 2010 20:26:07 +0900
Norikatsu Shigemura wrote:
> Humm.. Why only C3 state appear when unplug power? :-(
Ah, I got it. Every times, evaluating _CST on acpi_cpu_cx_cst,
and _CST is a black box because I couldn't see _CST. Maybe,
_CST look at AC status.
So I think that following patch is OK.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
--- sys/dev/acpica/acpi_cpu.c.orig 2010-09-12 01:31:38.144243000 +0900
+++ sys/dev/acpica/acpi_cpu.c 2010-09-12 20:53:49.252917961 +0900
@@ -690,19 +690,11 @@
sc->cpu_cx_count++;
continue;
case ACPI_STATE_C2:
- if (cx_ptr->trans_lat > 100) {
- ACPI_DEBUG_PRINT((ACPI_DB_INFO,
-"acpi_cpu%d: C2[%d] not available.\n",
-device_get_unit(sc->cpu_dev), i));
- continue;
- }
sc->cpu_non_c3 = i;
break;
case ACPI_STATE_C3:
default:
- if (cx_ptr->trans_lat > 1000 ||
- (cpu_quirks & CPU_QUIRK_NO_C3) != 0) {
-
+ if (cpu_quirks & CPU_QUIRK_NO_C3) {
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
"acpi_cpu%d: C3[%d] not available.\n",
device_get_unit(sc->cpu_dev), i));
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
Thank you.
--
Norikatsu Shigemura
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
Hi mav. On Sun, 12 Sep 2010 13:57:21 +0300 Alexander Motin wrote: > BTW, have you tried to unplug power? My laptop hides C3 state when power > cord is plugged-in. Oh! You are right! I got C3 state. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Sep 12 20:14:54 pelsia kernel: ts_to_ct(1284322495.185795464) = [2010-09-12 20:14:55] Sep 12 20:19:04 pelsia kernel: PROCESSOR-0722 [862354] cpu_cx_cst: acpi_cpu0: Got C2 - 205 latency Sep 12 20:19:04 pelsia kernel: PROCESSOR-0722 [862355] cpu_cx_cst: acpi_cpu0: Got C3 - 245 latency Sep 12 20:19:04 pelsia kernel: PROCESSOR-0722 [862936] cpu_cx_cst: acpi_cpu1: Got C2 - 205 latency Sep 12 20:19:04 pelsia kernel: PROCESSOR-0722 [862936] cpu_cx_cst: acpi_cpu1: Got C3 - 245 latency Sep 12 20:19:04 pelsia kernel: PROCESSOR-0722 [863524] cpu_cx_cst: acpi_cpu2: Got C2 - 205 latency Sep 12 20:19:04 pelsia kernel: PROCESSOR-0722 [863524] cpu_cx_cst: acpi_cpu2: Got C3 - 245 latency Sep 12 20:19:04 pelsia power_profile: changed to 'economy' Sep 12 20:19:04 pelsia kernel: PROCESSOR-0722 [864399] cpu_cx_cst: system power profile changedacpi_cpu3: Got C2 to 'economy'- 205 latency Sep 12 20:19:04 pelsia kernel: Sep 12 20:19:04 pelsia kernel: PROCESSOR-0722 [864516] cpu_cx_cst: acpi_cpu3: Got C3 - 245 latency Sep 12 20:19:04 pelsia kernel: acpi_acad0: Off Line Sep 12 20:19:04 pelsia kernel: PROCESSOR-0722 [872292] cpu_cx_cst: acpi_cpu0: Got C2 - 205 latency Sep 12 20:19:04 pelsia kernel: PROCESSOR-0722 [872394] cpu_cx_cst: acpi_cpu0: Got C3 - 245 latency Sep 12 20:19:05 pelsia kernel: PROCESSOR-0722 [873422] cpu_cx_cst: acpi_cpu1: Got C2 - 205 latency Sep 12 20:19:05 pelsia kernel: PROCESSOR-0722 [873422] cpu_cx_cst: acpi_cpu1: Got C3 - 245 latency Sep 12 20:19:05 pelsia kernel: PROCESSOR-0722 [874564] cpu_cx_cst: acpi_cpu2: Got C2 - 205 latency Sep 12 20:19:05 pelsia kernel: PROCESSOR-0722 [874576] cpu_cx_cst: acpi_cpu2: Got C3 - 245 latency Sep 12 20:19:05 pelsia kernel: PROCESSOR-0722 [875727] cpu_cx_cst: acpi_cpu3: Got C2 - 205 latency Sep 12 20:19:05 pelsia kernel: PROCESSOR-0722 [875727] cpu_cx_cst: acpi_cpu3: Got C3 - 245 latency Sep 12 20:19:12 pelsia kernel: PROCESSOR-0722 [889604] cpu_cx_cst: acpi_cpu0: Got C2 - 205 latency Sep 12 20:19:12 pelsia kernel: PROCESSOR-0722 [889604] cpu_cx_cst: acpi_cpu0: Got C3 - 245 latency Sep 12 20:19:13 pelsia kernel: PROCESSOR-0722 [890194] cpu_cx_cst: acpi_cpu1: Got C2 - 205 latency Sep 12 20:19:13 pelsia kernel: PROCESSOR-0722 [890194] cpu_cx_cst: acpi_cpu1: Got C3 - 245 latency Sep 12 20:19:13 pelsia kernel: PROCESSOR-0722 [890784] cpu_cx_cst: acpi_cpu2: Got C2 - 205 latency Sep 12 20:19:13 pelsia kernel: PROCESSOR-0722 [890784] cpu_cx_cst: acpi_cpu2: Got C3 - 245 latency Sep 12 20:19:13 pelsia kernel: PROCESSOR-0722 [891441] cpu_cx_cst: acpi_cpu3: Got C2 - 205 latency Sep 12 20:19:13 pelsia kernel: PROCESSOR-0722 [891441] cpu_cx_cst: acpi_cpu3: Got C3 - 245 latency Sep 12 20:20:43 pelsia kernel: PROCESSOR-0722 [1083168] cpu_cx_cst: acpi_cpu0: Got C2 - 205 latency Sep 12 20:20:43 pelsia kernel: PROCESSOR-0722 [1083197] cpu_cx_cst: acpi_cpu0: Got C3 - 245 latency Sep 12 20:20:43 pelsia kernel: PROCESSOR-0722 [1084498] cpu_cx_cst: acpi_cpu1: Got C2 - 205 latency Sep 12 20:20:43 pelsia kernel: PROCESSOR-0722 [1084498] cpu_cx_cst: acpi_cpu1: Got C3 - 245 latency Sep 12 20:20:43 pelsia kernel: PROCESSOR-0722 [1085468] cpu_cx_cst: acpi_cpu2: Got C2 - 205 latency Sep 12 20:20:43 pelsia kernel: PROCESSOR-0722 [1085468] cpu_cx_cst: acpi_cpu2: Got C3 - 245 latency Sep 12 20:20:44 pelsia kernel: PROCESSOR-0722 [1086504] cpu_cx_cst: acpi_cpu3: Got C2 - 205 latency Sep 12 20:20:44 pelsia kernel: PROCESSOR-0722 [1086508] cpu_cx_cst: acpi_cpu3: Got C3 - 245 latency - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # sysctl -a | grep cx hw.acpi.cpu.cx_lowest: C2 dev.cpu.0.cx_supported: C1/3 C2/205 C3/245 dev.cpu.0.cx_lowest: C2 dev.cpu.0.cx_usage: 12.48% 87.51% 0.00% last 1947us dev.cpu.1.cx_supported: C1/3 C2/205 C3/245 dev.cpu.1.cx_lowest: C2 dev.cpu.1.cx_usage: 60.83% 39.16% 0.00% last 182us dev.cpu.2.cx_supported: C1/3 C2/205 C3/245 dev.cpu.2.cx_lowest: C2 dev.cpu.2.cx_usage: 45.65% 54.34% 0.00% last 36us dev.cpu.3.cx_supported: C1/3 C2/205 C3/245 dev.cpu.3.cx_lowest: C2 dev.cpu.3.cx_usage: 6.78% 93.21% 0.00% last 8038us - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
Alexander Motin wrote: > Andriy Gapon wrote: >> acpi_lid0: Lid closed >> em0: Link is up 1000 Mbps Full Duplex >> PROCESSOR-0722 [402244] cpu_cx_cst: acpi_cpu0: Got C2 - 245 >> latency >> PROCESSOR-0722 [403097] cpu_cx_cst: acpi_cpu1: Got C2 - 245 >> latency >> PROCESSOR-0722 [403855] cpu_cx_cst: acpi_cpu2: Got C2 - 245 >> latency >> PROCESSOR-0722 [405022] cpu_cx_cst: acpi_cpu3: Got C2 - 245 >> latency >> >> Maybe because of this? >> It seems like you do something and ACPI disables C3, leaving only C2/ > > One strange thing. During boot it can be seen: > acpi_cpu0: Got C2 - 205 latency > acpi_cpu0: Got C3 - 245 latency > , but after boot in sysctl we can see: > dev.cpu.0.cx_supported: C1/3 C2/245 > > It respecting latency it looks like not C3 got lost, but C2. AFAIR, > sysctl numbers C-states completely abstract, just as array indexes. So > thing reported as C2 could instead be C3, while C2 is absent for some > reason. BTW, have you tried to unplug power? My laptop hides C3 state when power cord is plugged-in. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
Andriy Gapon wrote: > acpi_lid0: Lid closed > em0: Link is up 1000 Mbps Full Duplex > PROCESSOR-0722 [402244] cpu_cx_cst: acpi_cpu0: Got C2 - 245 > latency > PROCESSOR-0722 [403097] cpu_cx_cst: acpi_cpu1: Got C2 - 245 > latency > PROCESSOR-0722 [403855] cpu_cx_cst: acpi_cpu2: Got C2 - 245 > latency > PROCESSOR-0722 [405022] cpu_cx_cst: acpi_cpu3: Got C2 - 245 > latency > > Maybe because of this? > It seems like you do something and ACPI disables C3, leaving only C2/ One strange thing. During boot it can be seen: acpi_cpu0: Got C2 - 205 latency acpi_cpu0: Got C3 - 245 latency , but after boot in sysctl we can see: dev.cpu.0.cx_supported: C1/3 C2/245 It respecting latency it looks like not C3 got lost, but C2. AFAIR, sysctl numbers C-states completely abstract, just as array indexes. So thing reported as C2 could instead be C3, while C2 is absent for some reason. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
on 12/09/2010 13:25 Norikatsu Shigemura said the following:
> Hi avg.
>
> On Sun, 12 Sep 2010 19:09:52 +0900
> Norikatsu Shigemura wrote:
>> Logic is mistake. I'll re-make a patch and retry.
>
> I re-tried following patch:
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - -
> --- sys/dev/acpica/acpi_cpu.c.orig2010-09-12 01:31:38.144243000 +0900
> +++ sys/dev/acpica/acpi_cpu.c 2010-09-12 19:11:00.906223222 +0900
> @@ -690,19 +690,11 @@
> sc->cpu_cx_count++;
> continue;
> case ACPI_STATE_C2:
> - if (cx_ptr->trans_lat > 100) {
> - ACPI_DEBUG_PRINT((ACPI_DB_INFO,
> - "acpi_cpu%d: C2[%d] not available.\n",
> - device_get_unit(sc->cpu_dev), i));
> - continue;
> - }
> sc->cpu_non_c3 = i;
> break;
> case ACPI_STATE_C3:
> default:
> - if (cx_ptr->trans_lat > 1000 ||
> - (cpu_quirks & CPU_QUIRK_NO_C3) != 0) {
> -
> + if (cpu_quirks & CPU_QUIRK_NO_C3) {
> ACPI_DEBUG_PRINT((ACPI_DB_INFO,
>"acpi_cpu%d: C3[%d] not available.\n",
>device_get_unit(sc->cpu_dev), i));
The above looks good.
> @@ -731,6 +723,9 @@
> cx_ptr++;
> sc->cpu_cx_count++;
> }
> +else {
> +device_printf(sc->cpu_dev, "DEBUG: cx_ptr->p_lvlx IS NULL.\n");
> +}
> }
> AcpiOsFree(buf.Pointer);
What's this? The indentation is messed up too :-)
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - -
>
> Test is OK:
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - -
> # sysctl hw.acpi.cpu.cx_lowest=C2 && sleep 10 && sysctl dev.cpu.0.cx_usage
> dev.cpu.1.cx_usage dev.cpu.2.cx_usage dev.cpu.3.cx_usage
> hw.acpi.cpu.cx_lowest: C3 -> C2
> dev.cpu.0.cx_usage: 2.37% 97.62% last 3028us
> dev.cpu.1.cx_usage: 0.87% 99.12% last 4379us
> dev.cpu.2.cx_usage: 0.54% 99.45% last 14314us
> dev.cpu.3.cx_usage: 1.36% 98.63% last 16982us
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - -
>
> But I don't know how I couldn't get C3:-(.
> Not reachable my DEBUG code.
>
> Thank you.
acpi_lid0: Lid closed
em0: Link is up 1000 Mbps Full Duplex
PROCESSOR-0722 [402244] cpu_cx_cst: acpi_cpu0: Got C2 - 245 latency
PROCESSOR-0722 [403097] cpu_cx_cst: acpi_cpu1: Got C2 - 245 latency
PROCESSOR-0722 [403855] cpu_cx_cst: acpi_cpu2: Got C2 - 245 latency
PROCESSOR-0722 [405022] cpu_cx_cst: acpi_cpu3: Got C2 - 245 latency
Maybe because of this?
It seems like you do something and ACPI disables C3, leaving only C2/
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
Hi mav. On Sun, 12 Sep 2010 13:00:22 +0300 Alexander Motin wrote: > `sysctl -a` is a bad tool to estimate C-states usage. It causes a lot of > context switches, making data dirty. To get more precise data, try: > sysctl hw.acpi.cpu.cx_lowest=C2 && sleep 10 && sysctl dev.cpu.0.cx_usage > dev.cpu.1.cx_usage dev.cpu.2.cx_usage dev.cpu.3.cx_usage I tried, got following results: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # sysctl hw.acpi.cpu.cx_lowest=C2 && sleep 10 && sysctl dev.cpu.0.cx_usage dev.cpu.1.cx_usage dev.cpu.2.cx_usage dev.cpu.3.cx_usage hw.acpi.cpu.cx_lowest: C3 -> C2 dev.cpu.0.cx_usage: 2.37% 97.62% last 3028us dev.cpu.1.cx_usage: 0.87% 99.12% last 4379us dev.cpu.2.cx_usage: 0.54% 99.45% last 14314us dev.cpu.3.cx_usage: 1.36% 98.63% last 16982us # sysctl hw.acpi.cpu.cx_lowest=C2 && sleep 10 && sysctl dev.cpu.0.cx_usage dev.cpu.1.cx_usage dev.cpu.2.cx_usage dev.cpu.3.cx_usage hw.acpi.cpu.cx_lowest: C2 -> C2 dev.cpu.0.cx_usage: 1.82% 98.17% last 2672us dev.cpu.1.cx_usage: 0.71% 99.28% last 3413us dev.cpu.2.cx_usage: 0.00% 100.00% last 13543us dev.cpu.3.cx_usage: 2.00% 97.99% last 16190us - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - That's perfect! Thank you. -- Norikatsu Shigemura ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
Hi avg. On Sun, 12 Sep 2010 19:05:37 +0900 Norikatsu Shigemura wrote: > I re-tried to test following patch. > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - > --- sys/dev/acpica/acpi_cpu.c.orig2010-09-12 01:31:38.144243000 +0900 > +++ sys/dev/acpica/acpi_cpu.c 2010-09-12 18:47:56.057309965 +0900 > @@ -690,19 +690,13 @@ > sc->cpu_cx_count++; > continue; > case ACPI_STATE_C2: : > + ACPI_DEBUG_PRINT((ACPI_DB_INFO, > + "acpi_cpu%d: C2[%d] not available.\n", > + device_get_unit(sc->cpu_dev), i)); > + continue; Logic is mistake. I'll re-make a patch and retry. Thank you. -- Norikatsu Shigemura ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
Norikatsu Shigemura wrote: > On Sun, 12 Sep 2010 12:29:37 +0300 > Alexander Motin wrote: |>> hw.acpi.cpu.cx_lowest has default in C1. Have you tried to rise it via >> sysctl? > > Oops, I forgot usage of cx_lowest. > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - > # sysctl hw.acpi.cpu.cx_lowest=C2 > hw.acpi.cpu.cx_lowest: C1 -> C2 > # sysctl -a | grep cx > hw.acpi.cpu.cx_lowest: C2 > dev.cpu.0.cx_supported: C1/3 C2/245 > dev.cpu.0.cx_lowest: C2 > dev.cpu.0.cx_usage: 19.34% 80.65% last 49us > dev.cpu.1.cx_supported: C1/3 C2/245 > dev.cpu.1.cx_lowest: C2 > dev.cpu.1.cx_usage: 15.28% 84.71% last 922us > dev.cpu.2.cx_supported: C1/3 C2/245 > dev.cpu.2.cx_lowest: C2 > dev.cpu.2.cx_usage: 77.90% 22.09% last 6034us > dev.cpu.3.cx_supported: C1/3 C2/245 > dev.cpu.3.cx_lowest: C2 > dev.cpu.3.cx_usage: 80.28% 19.71% last 398us > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - `sysctl -a` is a bad tool to estimate C-states usage. It causes a lot of context switches, making data dirty. To get more precise data, try: sysctl hw.acpi.cpu.cx_lowest=C2 && sleep 10 && sysctl dev.cpu.0.cx_usage dev.cpu.1.cx_usage dev.cpu.2.cx_usage dev.cpu.3.cx_usage -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
Hi mav. On Sun, 12 Sep 2010 12:29:37 +0300 Alexander Motin wrote: > > But cx_lowest is not changed: > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > - - - - > > $ sysctl -a | grep cx > > hw.acpi.cpu.cx_lowest: C1 : > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > - - - - > hw.acpi.cpu.cx_lowest has default in C1. Have you tried to rise it via > sysctl? Oops, I forgot usage of cx_lowest. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # sysctl hw.acpi.cpu.cx_lowest=C2 hw.acpi.cpu.cx_lowest: C1 -> C2 # sysctl -a | grep cx hw.acpi.cpu.cx_lowest: C2 dev.cpu.0.cx_supported: C1/3 C2/245 dev.cpu.0.cx_lowest: C2 dev.cpu.0.cx_usage: 19.34% 80.65% last 49us dev.cpu.1.cx_supported: C1/3 C2/245 dev.cpu.1.cx_lowest: C2 dev.cpu.1.cx_usage: 15.28% 84.71% last 922us dev.cpu.2.cx_supported: C1/3 C2/245 dev.cpu.2.cx_lowest: C2 dev.cpu.2.cx_usage: 77.90% 22.09% last 6034us dev.cpu.3.cx_supported: C1/3 C2/245 dev.cpu.3.cx_lowest: C2 dev.cpu.3.cx_usage: 80.28% 19.71% last 398us - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - And I can get CPU cooling ~50C(about 45C). Before sysctl cx_lowest=C2, I got 50C~! Thank you. -- Norikatsu Shigemura ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
on 12/09/2010 12:29 Alexander Motin said the following: > hw.acpi.cpu.cx_lowest has default in C1. Have you tried to rise it via > sysctl? > And also check performance_cx_lowest, economy_cx_lowest in /etc/defaults/rc.conf. And /etc/rc.d/power_profile. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
on 12/09/2010 12:26 Norikatsu Shigemura said the following:
> Hi avg and mav.
>
> On Sun, 12 Sep 2010 11:12:20 +0300
> Alexander Motin wrote:
> PROCESSOR-0696 [257314] cpu_cx_cst: acpi_cpu3: C2[1] not
> available.
> PROCESSOR-0730 [257314] cpu_cx_cst: acpi_cpu3: Got C3 - 245
> latency
I think the issue is that C2 is not available for some reason and thus
C3 can't be used either. The way to tell is to use acpidump and look for
the CPU objects' _CST fields.
>>> The "not available" message means that transition latency is defined too
>>> high.
>>> That is, in this case latency is greater than 100 for C2.
>> Just an idea. Limits of 100 and 1000 are defined for detection of
>> C-states using P_LVLx_LAT registers. Because _CST explicitly specifies
>
> Oops! I forgot. Thank you, I tried.
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - -
> --- sys/dev/acpica/acpi_cpu.c.orig2010-09-12 01:31:38.144243000 +0900
> +++ sys/dev/acpica/acpi_cpu.c 2010-09-12 18:06:14.651938193 +0900
> @@ -597,7 +597,7 @@
> /* Validate and allocate resources for C2 (P_LVL2). */
> gas.SpaceId = ACPI_ADR_SPACE_SYSTEM_IO;
> gas.BitWidth = 8;
> -if (AcpiGbl_FADT.C2Latency <= 100) {
> +if (AcpiGbl_FADT.C2Latency <= 1000) {
> gas.Address = sc->cpu_p_blk + 4;
> acpi_bus_alloc_gas(sc->cpu_dev, &cx_ptr->res_type, &sc->cpu_rid,
> &gas, &cx_ptr->p_lvlx, RF_SHAREABLE);
> @@ -613,7 +613,7 @@
> return;
>
> /* Validate and allocate resources for C3 (P_LVL3). */
> -if (AcpiGbl_FADT.C3Latency <= 1000 && !(cpu_quirks & CPU_QUIRK_NO_C3)) {
> +if (AcpiGbl_FADT.C3Latency <= 1 && !(cpu_quirks & CPU_QUIRK_NO_C3)) {
> gas.Address = sc->cpu_p_blk + 5;
> acpi_bus_alloc_gas(sc->cpu_dev, &cx_ptr->res_type, &sc->cpu_rid, &gas,
> &cx_ptr->p_lvlx, RF_SHAREABLE);
The above changes are incorrect.
> @@ -690,7 +690,7 @@
> sc->cpu_cx_count++;
> continue;
> case ACPI_STATE_C2:
> - if (cx_ptr->trans_lat > 100) {
> + if (cx_ptr->trans_lat > 1000) {
> ACPI_DEBUG_PRINT((ACPI_DB_INFO,
>"acpi_cpu%d: C2[%d] not available.\n",
>device_get_unit(sc->cpu_dev), i));
> @@ -700,7 +700,7 @@
> break;
> case ACPI_STATE_C3:
> default:
> - if (cx_ptr->trans_lat > 1000 ||
> + if (cx_ptr->trans_lat > 1 ||
> (cpu_quirks & CPU_QUIRK_NO_C3) != 0) {
>
> ACPI_DEBUG_PRINT((ACPI_DB_INFO,
You should simply remove the check instead of bumping the threshold.
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - -
>
> But cx_lowest is not changed:
Why do you expect it to be changed?
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - -
> $ sysctl -a | grep cx
> hw.acpi.cpu.cx_lowest: C1
> dev.cpu.0.cx_supported: C1/3 C2/245
cx_supported has C2 now though.
> dev.cpu.0.cx_lowest: C1
> dev.cpu.0.cx_usage: 100.00% 0.00% last 3641us
> dev.cpu.1.cx_supported: C1/3 C2/245
> dev.cpu.1.cx_lowest: C1
> dev.cpu.1.cx_usage: 100.00% 0.00% last 798us
> dev.cpu.2.cx_supported: C1/3 C2/245
> dev.cpu.2.cx_lowest: C1
> dev.cpu.2.cx_usage: 100.00% 0.00% last 158us
> dev.cpu.3.cx_supported: C1/3 C2/245
> dev.cpu.3.cx_lowest: C1
> dev.cpu.3.cx_usage: 100.00% 0.00% last 227us
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
Norikatsu Shigemura wrote: > On Sun, 12 Sep 2010 11:12:20 +0300 > Alexander Motin wrote: > PROCESSOR-0696 [257314] cpu_cx_cst: acpi_cpu3: C2[1] not > available. > PROCESSOR-0730 [257314] cpu_cx_cst: acpi_cpu3: Got C3 - 245 > latency I think the issue is that C2 is not available for some reason and thus C3 can't be used either. The way to tell is to use acpidump and look for the CPU objects' _CST fields. >>> The "not available" message means that transition latency is defined too >>> high. >>> That is, in this case latency is greater than 100 for C2. >> Just an idea. Limits of 100 and 1000 are defined for detection of >> C-states using P_LVLx_LAT registers. Because _CST explicitly specifies > > Oops! I forgot. Thank you, I tried. > But cx_lowest is not changed: > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - > $ sysctl -a | grep cx > hw.acpi.cpu.cx_lowest: C1 > dev.cpu.0.cx_supported: C1/3 C2/245 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_usage: 100.00% 0.00% last 3641us > dev.cpu.1.cx_supported: C1/3 C2/245 > dev.cpu.1.cx_lowest: C1 > dev.cpu.1.cx_usage: 100.00% 0.00% last 798us > dev.cpu.2.cx_supported: C1/3 C2/245 > dev.cpu.2.cx_lowest: C1 > dev.cpu.2.cx_usage: 100.00% 0.00% last 158us > dev.cpu.3.cx_supported: C1/3 C2/245 > dev.cpu.3.cx_lowest: C1 > dev.cpu.3.cx_usage: 100.00% 0.00% last 227us > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - hw.acpi.cpu.cx_lowest has default in C1. Have you tried to rise it via sysctl? -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
on 12/09/2010 11:12 Alexander Motin said the following: > Just an idea. Limits of 100 and 1000 are defined for detection of > C-states using P_LVLx_LAT registers. Because _CST explicitly specifies > which states are available, these limitations may not apply there. I > would try to comment these checks in acpi_cpu_cx_cst() and look what > happen. At least I haven't found in ACPI 3.0 specification any latency > limits applied to _CST. Not 100% sure, but what you said does make sense. I couldn't also find any such wording in ACPI 4.0 spec. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
Andriy Gapon wrote: > on 11/09/2010 21:30 Nate Lawson said the following: >>> PROCESSOR-0311 [255895] cpu_attach: acpi_cpu3: P_BLK at 0x410/6 >>> PROCESSOR-0696 [257314] cpu_cx_cst: acpi_cpu3: C2[1] not >>> available. >>> PROCESSOR-0730 [257314] cpu_cx_cst: acpi_cpu3: Got C3 - 245 >>> latency >> I think the issue is that C2 is not available for some reason and thus >> C3 can't be used either. The way to tell is to use acpidump and look for >> the CPU objects' _CST fields. >> > > The "not available" message means that transition latency is defined too high. > That is, in this case latency is greater than 100 for C2. Just an idea. Limits of 100 and 1000 are defined for detection of C-states using P_LVLx_LAT registers. Because _CST explicitly specifies which states are available, these limitations may not apply there. I would try to comment these checks in acpi_cpu_cx_cst() and look what happen. At least I haven't found in ACPI 3.0 specification any latency limits applied to _CST. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
on 12/09/2010 02:14 Norikatsu Shigemura said the following:
> According to acpidump -dt, I could find CPU0CST table, but
> not found _CST.
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - -
> Scope (\)
> {
> Name (SSDT, Package (0x0C)
> {
> :
> "CPU0CST ",
> 0xDA9AB618,
> 0x05CD,
> :
> })
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - -
>
> Hum... ACPI CA 20100806 has a bug?
How do you conclude? Does a different version work?
It seems that our acpidump doesn't dump a dynamically loaded table.
That the table was loaded we can see from these messages:
ACPI: Dynamic OEM Table Load:
ACPI: SSDT 0 005CD (v01 PmRef Cpu0Cst 3001 INTL 20061109)
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
on 11/09/2010 21:30 Nate Lawson said the following: > I think the issue is that C2 is not available for some reason and thus > C3 can't be used either. The way to tell is to use acpidump and look for > the CPU objects' _CST fields. >From reading of the code, C3 should be used in this case even if C2 is not available. But I think that it might get removed for a different reason: PM2_CNT_BLK length seems to be zero. With ACPI_DB_INFO enabled there should be "no BM control" message in the log. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
on 11/09/2010 21:30 Nate Lawson said the following: >> PROCESSOR-0311 [255895] cpu_attach: acpi_cpu3: P_BLK at 0x410/6 >> PROCESSOR-0696 [257314] cpu_cx_cst: acpi_cpu3: C2[1] not >> available. >> PROCESSOR-0730 [257314] cpu_cx_cst: acpi_cpu3: Got C3 - 245 >> latency > > I think the issue is that C2 is not available for some reason and thus > C3 can't be used either. The way to tell is to use acpidump and look for > the CPU objects' _CST fields. > The "not available" message means that transition latency is defined too high. That is, in this case latency is greater than 100 for C2. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
