misc/164328: NSvDuaFN
>Number: 164328 >Category: misc >Synopsis: NSvDuaFN >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: update >Submitter-Id: current-users >Arrival-Date: Fri Jan 20 08:00:25 UTC 2012 >Closed-Date: >Last-Modified: >Originator: jKvQoOcRq >Release:QGsdbDdasrk >Organization: LoKvyOZNUdXzlfv >Environment: Yours is a cleevr way of thinking about it. >Description: Yours is a cleevr way of thinking about it. >How-To-Repeat: Yours is a cleevr way of thinking about it. >Fix: Yours is a cleevr way of thinking about it. >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: junk/164328: NSvDuaFN
Synopsis: NSvDuaFN State-Changed-From-To: open->closed State-Changed-By: sunpoet State-Changed-When: Fri Jan 20 08:07:54 UTC 2012 State-Changed-Why: Junk PR. Responsible-Changed-From-To: freebsd-bugs->gnats-admin Responsible-Changed-By: sunpoet Responsible-Changed-When: Fri Jan 20 08:07:54 UTC 2012 Responsible-Changed-Why: Junk PR. http://www.freebsd.org/cgi/query-pr.cgi?pr=164328 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/164329: hw.acpi.thermal.tz0.temperature shows strange value
>Number: 164329 >Category: kern >Synopsis: hw.acpi.thermal.tz0.temperature shows strange value >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Jan 20 08:30:14 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Alexander Shikov >Release:9.0-RELEASE >Organization: IT Consulting LLC >Environment: FreeBSD noc.itcons.net.ua 9.0-RELEASE FreeBSD 9.0-RELEASE #1: Thu Jan 19 22:57:17 EET 2012 r...@noc.itcons.net.ua:/usr/obj/usr/src/sys/NOC i386 >Description: I have two Hewlett-Packard Proliant DL360 servers. One is running 9.0-RELEASE, second is running 8.1-RELEASE. On both there is a problem with thermal control: hw.acpi.thermal.tz0.temperature shows strange temperature: # sysctl hw.acpi.thermal hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 8,3C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 9,8C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 31,3C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: 4 hw.acpi.thermal.tz0._TC2: 4 hw.acpi.thermal.tz0._TSP: 60 But the temperature in colocation is much more bigger than 8,3C. >How-To-Repeat: I believe that a problem is repeatable on HP Proliant DL350 and DL360 servers. >Fix: No fix. >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/164329: [acpi] hw.acpi.thermal.tz0.temperature shows strange value
Old Synopsis: hw.acpi.thermal.tz0.temperature shows strange value New Synopsis: [acpi] hw.acpi.thermal.tz0.temperature shows strange value Responsible-Changed-From-To: freebsd-bugs->freebsd-acpi Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jan 20 09:00:34 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=164329 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/164094: bsdinstall(8): installer progress over 100%
On Tue, Jan 17, 2012 at 11:57:10PM -0600, Nathan Whitehorn wrote: > On 01/17/12 23:23, Ariane van der Steldt wrote: > > Hi Nathan, > > > > On Sat, Jan 14, 2012 at 07:42:24AM +0100, Ariane van der Steldt wrote: > >> On Fri, Jan 13, 2012 at 07:49:12PM -0600, Nathan Whitehorn wrote: > >>> On 01/13/12 19:16, ead...@freebsd.org wrote: > FreeBSD installer changed my MBR-only partition table to MBR+GPT > partition table. > > > The other OS does not have GPT logic; I want to be at least warned > this is happening and prefer to have the option at least. > Alternatively, the installer may opt not to install a GPT if the disk > does not require it (as in the case in this machine) > >>> Can you give some more details here? This is something that the > >>> installer is not programmed to do and that I cannot reproduce. > >> Sure. I used a VM to reproduce the problem, so I could provide pretty > >> screenshots in an attempt to better explain the problem. > >> > >> > >> Pre-install: > >> only 1 OS installed, windows XP, using MBR partition table. > >> > >> Using a live CD, I can instruct fdisk to (pointlessly) alter the active > >> partition, as can be seen in attached screenshot 1 > >> > >> > >> Post-install: > >> Both windows XP and FreeBSD are installed. > >> Unfortunately, fdisk can no longer be used to alter the active > >> partition, gpart is to be used instead. > >> As can be seen in attached screenshot 2, fdisk fails. > >> > >> After install, only gpart can be used to change the active partition. > > Upon rereading the manpage for gpart, I'm wondering if what I concluded > > really happened. On closer examination, it's possible the geom logic > > blocked fdisk from modifying the partition table. Can you tell me how I > > can confirm out what partitioning schemes are present on my harddisk? > > I put the output of gpart show at the bottom of the e-mail, which > > suggests the mbr scheme is used regardless. > > > > If geom indeed blocks fdisk from altering the partition table, I'm > > wondering what the use of the binary is though, as it seems gpart does > > everything fdisk does, but without failing. > > > > # gpart show > > => 63 1250263665 ada0 MBR (596G) > >63 209712447 1 ntfs [active] (100G) > > 209712510 102398310 2 ntfs (48G) > > 312110820 937426896 3 freebsd (447G) > >1249537716 726012- free - (354M) > > > > => 0 937426896 ada0s3 BSD (447G) > >0 929038336 1 freebsd-ufs (443G) > >9290383368388559 2 freebsd-swap (4G) > >937426895 1 - free - (512B) > > That implies it's just MBR + BSD label. Why did you think it was GPT? > Geom does prevent many utilities from altering the partition table. I > was under the impression that fdisk had been modified to actually use > geom these days, so it should have worked, but it's possible that didn't > work somehow. I came under that impression because fdisk didn't work, while before installing freebsd, it did work. gpart, due to its name and coupled with a refusing fdisk, made me jump to the conclusion that I had been given a GPT table. Is there a technical reason that geom is not automatically activated on every partition table? It seems to me that unifying these would reduce complexity and confusion to the end user. And I see no reason why the boot volume has this recognized and activated automatically, but other devices don't. -- Ariane ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/164094: bsdinstall(8): installer progress over 100%
On 20/01/2012 09:46, Ariane van der Steldt wrote: I came under that impression because fdisk didn't work, while before installing freebsd, it did work. gpart, due to its name and coupled with a refusing fdisk, made me jump to the conclusion that I had been given a GPT table. gpart is just a geom partitioner: its name has nothing to do with GPT. -- Bruce Cran ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/164335: nLcigoaWEu
>Number: 164335 >Category: misc >Synopsis: nLcigoaWEu >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Fri Jan 20 14:10:08 UTC 2012 >Closed-Date: >Last-Modified: >Originator: xczILQOoHDNhpWKPURl >Release:HYncwSQGHM >Organization: PhPgnAgWQ >Environment: HHIS I should have tohguht of that! >Description: HHIS I should have tohguht of that! >How-To-Repeat: HHIS I should have tohguht of that! >Fix: HHIS I should have tohguht of that! >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: junk/164335: nLcigoaWEu
Synopsis: nLcigoaWEu State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Fri Jan 20 15:00:58 UTC 2012 State-Changed-Why: and forever, and forever, and forever. Responsible-Changed-From-To: freebsd-bugs->gnats-admin Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jan 20 15:00:58 UTC 2012 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=164335 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/162741: commit references a PR
The following reply was made to PR kern/162741; it has been noted by GNATS. From: dfil...@freebsd.org (dfilter service) To: bug-follo...@freebsd.org Cc: Subject: Re: kern/162741: commit references a PR Date: Sat, 21 Jan 2012 05:03:19 + (UTC) Author: alc Date: Sat Jan 21 05:03:10 2012 New Revision: 230418 URL: http://svn.freebsd.org/changeset/base/230418 Log: MFC r226163, r228317, and r228324 Fix the handling of an empty kmem map by sysctl_kmem_map_free(). Eliminate the possibility of 32-bit arithmetic overflow in the calculation of vm_kmem_size that may occur if the system administrator has specified a vm.vm_kmem_size tunable value that exceeds the hard cap. Eliminate stale numbers from a comment. PR: 162741 Modified: stable/9/sys/kern/kern_malloc.c Directory Properties: stable/9/sys/ (props changed) stable/9/sys/amd64/include/xen/ (props changed) stable/9/sys/boot/ (props changed) stable/9/sys/boot/i386/efi/ (props changed) stable/9/sys/boot/ia64/efi/ (props changed) stable/9/sys/boot/ia64/ski/ (props changed) stable/9/sys/boot/powerpc/boot1.chrp/ (props changed) stable/9/sys/boot/powerpc/ofw/ (props changed) stable/9/sys/cddl/contrib/opensolaris/ (props changed) stable/9/sys/conf/ (props changed) stable/9/sys/contrib/dev/acpica/ (props changed) stable/9/sys/contrib/octeon-sdk/ (props changed) stable/9/sys/contrib/pf/ (props changed) stable/9/sys/contrib/x86emu/ (props changed) Modified: stable/9/sys/kern/kern_malloc.c == --- stable/9/sys/kern/kern_malloc.cSat Jan 21 04:24:19 2012 (r230417) +++ stable/9/sys/kern/kern_malloc.cSat Jan 21 05:03:10 2012 (r230418) @@ -265,8 +265,8 @@ sysctl_kmem_map_free(SYSCTL_HANDLER_ARGS u_long size; vm_map_lock_read(kmem_map); - size = kmem_map->root != NULL ? - kmem_map->root->max_free : kmem_map->size; + size = kmem_map->root != NULL ? kmem_map->root->max_free : + kmem_map->max_offset - kmem_map->min_offset; vm_map_unlock_read(kmem_map); return (sysctl_handle_long(oidp, &size, 0, req)); } @@ -661,12 +661,9 @@ kmeminit(void *dummy) /* * Try to auto-tune the kernel memory size, so that it is - * more applicable for a wider range of machine sizes. - * On an X86, a VM_KMEM_SIZE_SCALE value of 4 is good, while - * a VM_KMEM_SIZE of 12MB is a fair compromise. The + * more applicable for a wider range of machine sizes. The * VM_KMEM_SIZE_MAX is dependent on the maximum KVA space - * available, and on an X86 with a total KVA space of 256MB, - * try to keep VM_KMEM_SIZE_MAX at 80MB or below. + * available. * * Note that the kmem_map is also used by the zone allocator, * so make sure that there is enough space. @@ -703,11 +700,11 @@ kmeminit(void *dummy) /* * Limit kmem virtual size to twice the physical memory. * This allows for kmem map sparseness, but limits the size - * to something sane. Be careful to not overflow the 32bit - * ints while doing the check. + * to something sane. Be careful to not overflow the 32bit + * ints while doing the check or the adjustment. */ - if (((vm_kmem_size / 2) / PAGE_SIZE) > cnt.v_page_count) - vm_kmem_size = 2 * cnt.v_page_count * PAGE_SIZE; + if (vm_kmem_size / 2 / PAGE_SIZE > mem_size) + vm_kmem_size = 2 * mem_size * PAGE_SIZE; #ifdef DEBUG_MEMGUARD tmp = memguard_fudge(vm_kmem_size, vm_kmem_size_max); ___ svn-src-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org" ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/162741: commit references a PR
The following reply was made to PR kern/162741; it has been noted by GNATS. From: dfil...@freebsd.org (dfilter service) To: bug-follo...@freebsd.org Cc: Subject: Re: kern/162741: commit references a PR Date: Sat, 21 Jan 2012 07:22:05 + (UTC) Author: alc Date: Sat Jan 21 07:21:44 2012 New Revision: 230419 URL: http://svn.freebsd.org/changeset/base/230419 Log: MFC r226163, r228317, and r228324 Fix the handling of an empty kmem map by sysctl_kmem_map_free(). Eliminate the possibility of 32-bit arithmetic overflow in the calculation of vm_kmem_size that may occur if the system administrator has specified a vm.vm_kmem_size tunable value that exceeds the hard cap. Eliminate stale numbers from a comment. PR: 162741 Modified: stable/8/sys/kern/kern_malloc.c Directory Properties: stable/8/sys/ (props changed) stable/8/sys/amd64/include/xen/ (props changed) stable/8/sys/cddl/contrib/opensolaris/ (props changed) stable/8/sys/contrib/dev/acpica/ (props changed) stable/8/sys/contrib/pf/ (props changed) Modified: stable/8/sys/kern/kern_malloc.c == --- stable/8/sys/kern/kern_malloc.cSat Jan 21 05:03:10 2012 (r230418) +++ stable/8/sys/kern/kern_malloc.cSat Jan 21 07:21:44 2012 (r230419) @@ -258,8 +258,8 @@ sysctl_kmem_map_free(SYSCTL_HANDLER_ARGS u_long size; vm_map_lock_read(kmem_map); - size = kmem_map->root != NULL ? - kmem_map->root->max_free : kmem_map->size; + size = kmem_map->root != NULL ? kmem_map->root->max_free : + kmem_map->max_offset - kmem_map->min_offset; vm_map_unlock_read(kmem_map); return (sysctl_handle_long(oidp, &size, 0, req)); } @@ -595,12 +595,9 @@ kmeminit(void *dummy) /* * Try to auto-tune the kernel memory size, so that it is - * more applicable for a wider range of machine sizes. - * On an X86, a VM_KMEM_SIZE_SCALE value of 4 is good, while - * a VM_KMEM_SIZE of 12MB is a fair compromise. The + * more applicable for a wider range of machine sizes. The * VM_KMEM_SIZE_MAX is dependent on the maximum KVA space - * available, and on an X86 with a total KVA space of 256MB, - * try to keep VM_KMEM_SIZE_MAX at 80MB or below. + * available. * * Note that the kmem_map is also used by the zone allocator, * so make sure that there is enough space. @@ -637,11 +634,11 @@ kmeminit(void *dummy) /* * Limit kmem virtual size to twice the physical memory. * This allows for kmem map sparseness, but limits the size - * to something sane. Be careful to not overflow the 32bit - * ints while doing the check. + * to something sane. Be careful to not overflow the 32bit + * ints while doing the check or the adjustment. */ - if (((vm_kmem_size / 2) / PAGE_SIZE) > cnt.v_page_count) - vm_kmem_size = 2 * cnt.v_page_count * PAGE_SIZE; + if (vm_kmem_size / 2 / PAGE_SIZE > mem_size) + vm_kmem_size = 2 * mem_size * PAGE_SIZE; /* * Tune settings based on the kmem map's size at this time. ___ svn-src-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org" ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/162741: [PATCH] vm_kmem_size miscalculated due to int type overflow sometimes
Synopsis: [PATCH] vm_kmem_size miscalculated due to int type overflow sometimes State-Changed-From-To: patched->closed State-Changed-By: alc State-Changed-When: Sat Jan 21 07:58:11 UTC 2012 State-Changed-Why: All active branches have been fixed. http://www.freebsd.org/cgi/query-pr.cgi?pr=162741 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
