Re: svn commit: r219679 - head/sys/i386/include
On 3/16/11 2:16 PM, Ivan Voras wrote: On 16 March 2011 21:03, Erik Trulsson wrote: On Wed, Mar 16, 2011 at 06:45:53PM +0100, Roman Divacky wrote: On Wed, Mar 16, 2011 at 12:32:56PM -0400, Jung-uk Kim wrote: On Tuesday 15 March 2011 08:45 pm, Maxim Dounin wrote: This isn't really different as long as GENERIC kernel used, as GENERIC defines I486_CPU. Fixed in r219698, sorry. Actually, I think we should remove i486 from GENERIC at some point. It has too many limitations. For example, I really love to implement atomic 64-bit mem read/write using cmpxchg8b (no 0xf00f joke, please) but I cannot do that cleanly without removing I486 support or checking cpu_class at run-time. :-( if we drop i486 I think it makes sense to require something that has at least SSE2, thus we can have the same expectations as on amd64. No, that would remove support from far too many machines that people actually use to run FreeBSD. There are probably only a handful of people (if that) who actually run FreeBSD on an actual 486-class machine, but requiring SSE2 would mean dropping support for Pentium-III and Athlon-XP equipped machines and I believe there are a large number of such machines still in use, and they are still perfectly suitable for a large number of tasks. This is understandable but I also think it deserves a poll at stable@ and current@. It might be worth keeping i486 for all of 9-stable but removing it before 10-stable. Judging from previous releases, 9.x would be supported until at least 2016. I don't follow the embedded world that much, but from what I saw, most (incl. Soekris) are moving to Atom designs which support SSE2. not sure what is in the Soekris and other embedded machines but do keep them in mind. many are now 586 class I guess but there may still be some 486 ones around. I believe you can now get a 486 core in some arrays. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r219710 - head/lib/libc/sys
Author: marcel
Date: Thu Mar 17 04:40:37 2011
New Revision: 219710
URL: http://svn.freebsd.org/changeset/base/219710
Log:
When building libc with the syscall compatibility, don't also generate the
syscall assembly files. This results in conflicting dependencies and can
cause unexpected results for parallel builds. This is because the .c file
and the .S file both generate the same .o file.
Submitted by: Simon Gerraty
Sponsored by: Juniper Networks
Modified:
head/lib/libc/sys/Makefile.inc
Modified: head/lib/libc/sys/Makefile.inc
==
--- head/lib/libc/sys/Makefile.inc Thu Mar 17 04:30:43 2011
(r219709)
+++ head/lib/libc/sys/Makefile.inc Thu Mar 17 04:40:37 2011
(r219710)
@@ -18,7 +18,10 @@
# Sources common to both syscall interfaces:
SRCS+= stack_protector.c stack_protector_compat.c __error.c
.if !defined(WITHOUT_SYSCALL_COMPAT)
-SRCS+= fcntl.c ftruncate.c lseek.c mmap.c pread.c pwrite.c truncate.c
+SYSCALL_COMPAT_SRCS= fcntl.c ftruncate.c lseek.c mmap.c pread.c \
+ pwrite.c truncate.c
+SRCS+= ${SYSCALL_COMPAT_SRCS}
+NOASM+=${SYSCALL_COMPAT_SRCS:S/.c/.o/}
PSEUDO+= _fcntl.o
.endif
SRCS+= sigwait.c
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r219709 - head/lib/libc/stdlib
Author: marcel Date: Thu Mar 17 04:30:43 2011 New Revision: 219709 URL: http://svn.freebsd.org/changeset/base/219709 Log: Don't add sigwait.c to MISRCS here when sigwait.c lives under ../sys and it's already added to SRCS there. Modified: head/lib/libc/stdlib/Makefile.inc Modified: head/lib/libc/stdlib/Makefile.inc == --- head/lib/libc/stdlib/Makefile.inc Thu Mar 17 01:05:54 2011 (r219708) +++ head/lib/libc/stdlib/Makefile.inc Thu Mar 17 04:30:43 2011 (r219709) @@ -9,7 +9,7 @@ MISRCS+=_Exit.c a64l.c abort.c abs.c ate getsubopt.c hcreate.c heapsort.c imaxabs.c imaxdiv.c \ insque.c l64a.c labs.c ldiv.c llabs.c lldiv.c lsearch.c malloc.c \ merge.c ptsname.c qsort.c qsort_r.c radixsort.c rand.c random.c \ - reallocf.c realpath.c remque.c sigwait.c strfmon.c strtoimax.c \ + reallocf.c realpath.c remque.c strfmon.c strtoimax.c \ strtol.c strtoll.c strtoq.c strtoul.c strtonum.c strtoull.c \ strtoumax.c strtouq.c system.c tdelete.c tfind.c tsearch.c twalk.c ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r219708 - head/usr.bin/vmstat
On 17 March 2011 02:05, Ed Maste wrote: > Author: emaste > Date: Thu Mar 17 01:05:54 2011 > New Revision: 219708 > URL: http://svn.freebsd.org/changeset/base/219708 > > Log: > Remove uptime validity check that hasn't been necessary since r151417 > switched to clock_gettime. vmstat will now not exit with an error > if run on a system with 10 years of uptime. I hope you have a system to test this on :) ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r219708 - head/usr.bin/vmstat
Author: emaste
Date: Thu Mar 17 01:05:54 2011
New Revision: 219708
URL: http://svn.freebsd.org/changeset/base/219708
Log:
Remove uptime validity check that hasn't been necessary since r151417
switched to clock_gettime. vmstat will now not exit with an error
if run on a system with 10 years of uptime.
Modified:
head/usr.bin/vmstat/vmstat.c
Modified: head/usr.bin/vmstat/vmstat.c
==
--- head/usr.bin/vmstat/vmstat.cThu Mar 17 00:29:53 2011
(r219707)
+++ head/usr.bin/vmstat/vmstat.cThu Mar 17 01:05:54 2011
(r219708)
@@ -409,14 +409,10 @@ static long
getuptime(void)
{
struct timespec sp;
- time_t uptime;
(void)clock_gettime(CLOCK_MONOTONIC, &sp);
- uptime = sp.tv_sec;
- if (uptime <= 0 || uptime > 60*60*24*365*10)
- errx(1, "time makes no sense; namelist must be wrong");
- return(uptime);
+ return(sp.tv_sec);
}
static void
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r219707 - in head/sys/contrib/dev/acpica: . common compiler events include
Author: jkim
Date: Thu Mar 17 00:29:53 2011
New Revision: 219707
URL: http://svn.freebsd.org/changeset/base/219707
Log:
Merge ACPICA 20110316.
Modified:
head/sys/contrib/dev/acpica/changes.txt
head/sys/contrib/dev/acpica/common/dmtable.c
head/sys/contrib/dev/acpica/common/dmtbdump.c
head/sys/contrib/dev/acpica/common/dmtbinfo.c
head/sys/contrib/dev/acpica/compiler/aslcompiler.y
head/sys/contrib/dev/acpica/compiler/dtcompiler.h
head/sys/contrib/dev/acpica/compiler/dtio.c
head/sys/contrib/dev/acpica/compiler/dttable.c
head/sys/contrib/dev/acpica/compiler/dttemplate.h
head/sys/contrib/dev/acpica/compiler/dtutils.c
head/sys/contrib/dev/acpica/events/evmisc.c
head/sys/contrib/dev/acpica/events/evxfgpe.c
head/sys/contrib/dev/acpica/include/acdisasm.h
head/sys/contrib/dev/acpica/include/acglobal.h
head/sys/contrib/dev/acpica/include/acpixf.h
head/sys/contrib/dev/acpica/include/actbl2.h
Directory Properties:
head/sys/contrib/dev/acpica/ (props changed)
Modified: head/sys/contrib/dev/acpica/changes.txt
==
--- head/sys/contrib/dev/acpica/changes.txt Wed Mar 16 22:51:34 2011
(r219706)
+++ head/sys/contrib/dev/acpica/changes.txt Thu Mar 17 00:29:53 2011
(r219707)
@@ -1,7 +1,49 @@
-11 February 2011. Summary of changes for version 20110211:
+16 March 2011. Summary of changes for version 20110316:
+
+x
+1) ACPI CA Core Subsystem:
+
+Fixed a problem caused by a _PRW method appearing at the namespace root scope
+during the setup of wake GPEs. A fault could occur if a _PRW directly under
the
+root object was passed to the AcpiSetupGpeForWake interface. Lin Ming.
+
+Implemented support for "spurious" Global Lock interrupts. On some systems, a
+global lock interrupt can occur without the pending flag being set. Upon a GL
+interrupt, we now ensure that a thread is actually waiting for the lock before
+signaling GL availability. Rafael Wysocki, Bob Moore.
+
+Example Code and Data Size: These are the sizes for the OS-independent
acpica.lib
+produced by the Microsoft Visual C++ 9.0 32-bit compiler. The debug version of
+the code includes the debug output trace mechanism and has a much larger code
and
+data size.
+
+ Previous Release (VC 9.0):
+Non-Debug Version: 89.7K Code, 23.7K Data, 113.4K Total
+Debug Version: 163.9K Code, 67.5K Data, 231.4K Total
+ Current Release (VC 9.0):
+Non-Debug Version: 89.8K Code, 23.8K Data, 113.6K Total
+Debug Version: 164.2K Code, 67.9K Data, 232.1K Total
+
+2) iASL Compiler/Disassembler and Tools:
+
+Implemented full support for the "SLIC" ACPI table. Includes support in the
+header files, disassembler, table compiler, and template generator. Bob Moore,
+Lin Ming.
-This release is available at www.acpica.org/downloads
+AcpiXtract: Correctly handle embedded comments and messages from AcpiDump.
+Apparently some or all versions of acpidump will occasionally emit a comment
like
+"Wrong checksum", etc., into the dump file. This was causing problems for
+AcpiXtract. ACPICA BZ 905.
+
+iASL: Fix the Linux makefile by removing an inadvertent double file inclusion.
+ACPICA BZ 913.
+
+AcpiExec: Update installation of operation region handlers. Install one
handler
+for a user-defined address space. This is used by the ASL test suite (ASLTS).
+
+
+11 February 2011. Summary of changes for version 20110211:
1) ACPI CA Core Subsystem:
Modified: head/sys/contrib/dev/acpica/common/dmtable.c
==
--- head/sys/contrib/dev/acpica/common/dmtable.cWed Mar 16 22:51:34
2011(r219706)
+++ head/sys/contrib/dev/acpica/common/dmtable.cThu Mar 17 00:29:53
2011(r219707)
@@ -192,6 +192,13 @@ static const char *AcpiDmMadtS
"Unknown SubTable Type" /* Reserved */
};
+static const char *AcpiDmSlicSubnames[] =
+{
+"Public Key Structure",
+"Windows Marker Structure",
+"Unknown SubTable Type" /* Reserved */
+};
+
static const char *AcpiDmSratSubnames[] =
{
"Processor Local APIC/SAPIC Affinity",
@@ -270,7 +277,7 @@ ACPI_DMTABLE_DATAAcpiDmTableData[] =
{ACPI_SIG_MSCT, NULL, AcpiDmDumpMsct, DtCompileMsct,
TemplateMsct, "Maximum System Characteristics Table"},
{ACPI_SIG_RSDT, NULL, AcpiDmDumpRsdt, DtCompileRsdt,
TemplateRsdt, "Root System Description Table"},
{ACPI_SIG_SBST, AcpiDmTableInfoSbst,NULL, NULL,
TemplateSbst, "Smart Battery Specification Table"},
-{ACPI_SIG_SLIC, AcpiDmTableInfoSlic,NULL, NULL,
NULL, "Software Licensing Descripti
svn commit: r219706 - in head/sys/mips/cavium: . octe
Author: jmallett
Date: Wed Mar 16 22:51:34 2011
New Revision: 219706
URL: http://svn.freebsd.org/changeset/base/219706
Log:
o) Set MAC addresses starting at the MAC base for all management ports, not
just the MR-730.
o) Start MAC addresses for the non-management ports after the management
ports.
Submitted by: Bhanu Prakash (with modifications)
Modified:
head/sys/mips/cavium/if_octm.c
head/sys/mips/cavium/octe/ethernet-common.c
head/sys/mips/cavium/octe/ethernet-common.h
head/sys/mips/cavium/octe/ethernet.c
Modified: head/sys/mips/cavium/if_octm.c
==
--- head/sys/mips/cavium/if_octm.c Wed Mar 16 20:54:58 2011
(r219705)
+++ head/sys/mips/cavium/if_octm.c Wed Mar 16 22:51:34 2011
(r219706)
@@ -175,28 +175,13 @@ octm_attach(device_t dev)
return (ENXIO);
}
- switch (cvmx_sysinfo_get()->board_type) {
-#if defined(OCTEON_VENDOR_LANNER)
- case CVMX_BOARD_TYPE_CUST_LANNER_MR730:
- /*
-* The MR-730 uses its first two MACs for the management
-* ports.
-*/
- mac = 0;
- memcpy((u_int8_t *)&mac + 2, octeon_bootinfo->mac_addr_base,
- 6);
- mac += sc->sc_port;
- cvmx_mgmt_port_set_mac(sc->sc_port, mac);
- break;
-#endif
- default:
- mac = cvmx_mgmt_port_get_mac(sc->sc_port);
- if (mac == CVMX_MGMT_PORT_GET_MAC_ERROR) {
- device_printf(dev, "unable to read MAC.\n");
- return (ENXIO);
- }
- break;
- }
+ /*
+* Set MAC address for this management port.
+*/
+ mac = 0;
+ memcpy((u_int8_t *)&mac + 2, octeon_bootinfo->mac_addr_base, 6);
+ mac += sc->sc_port;
+ cvmx_mgmt_port_set_mac(sc->sc_port, mac);
/* No watermark for input ring. */
mixx_irhwm.u64 = 0;
Modified: head/sys/mips/cavium/octe/ethernet-common.c
==
--- head/sys/mips/cavium/octe/ethernet-common.c Wed Mar 16 20:54:58 2011
(r219705)
+++ head/sys/mips/cavium/octe/ethernet-common.c Wed Mar 16 22:51:34 2011
(r219706)
@@ -269,34 +269,19 @@ void cvm_oct_common_poll(struct ifnet *i
*/
int cvm_oct_common_init(struct ifnet *ifp)
{
- static int count;
char mac[6] = {
octeon_bootinfo->mac_addr_base[0],
octeon_bootinfo->mac_addr_base[1],
octeon_bootinfo->mac_addr_base[2],
octeon_bootinfo->mac_addr_base[3],
octeon_bootinfo->mac_addr_base[4],
- octeon_bootinfo->mac_addr_base[5] + count};
+ octeon_bootinfo->mac_addr_base[5] };
cvm_oct_private_t *priv = (cvm_oct_private_t *)ifp->if_softc;
- switch (cvmx_sysinfo_get()->board_type) {
-#if defined(OCTEON_VENDOR_LANNER)
- case CVMX_BOARD_TYPE_CUST_LANNER_MR730:
- /*
-* The MR-730 uses its first two MACs for the management
-* ports.
-*/
- mac[5] += 2;
- break;
-#endif
- default:
- break;
- }
+ mac[5] += cvm_oct_mac_addr_offset++;
ifp->if_mtu = ETHERMTU;
- count++;
-
cvm_oct_mdio_setup_device(ifp);
cvm_oct_common_set_mac_address(ifp, mac);
Modified: head/sys/mips/cavium/octe/ethernet-common.h
==
--- head/sys/mips/cavium/octe/ethernet-common.h Wed Mar 16 20:54:58 2011
(r219705)
+++ head/sys/mips/cavium/octe/ethernet-common.h Wed Mar 16 22:51:34 2011
(r219706)
@@ -51,3 +51,5 @@ int cvm_oct_sgmii_init(struct ifnet *ifp
int cvm_oct_spi_init(struct ifnet *ifp);
void cvm_oct_spi_uninit(struct ifnet *ifp);
int cvm_oct_xaui_init(struct ifnet *ifp);
+
+extern unsigned int cvm_oct_mac_addr_offset;
Modified: head/sys/mips/cavium/octe/ethernet.c
==
--- head/sys/mips/cavium/octe/ethernet.cWed Mar 16 20:54:58 2011
(r219705)
+++ head/sys/mips/cavium/octe/ethernet.cWed Mar 16 22:51:34 2011
(r219706)
@@ -103,6 +103,15 @@ static struct taskqueue *cvm_oct_link_ta
*/
static int cvm_oct_num_output_buffers;
+/*
+ * The offset from mac_addr_base that should be used for the next port
+ * that is configured. By convention, if any mgmt ports exist on the
+ * chip, they get the first mac addresses. The ports controlled by
+ * this driver are numbered sequencially following any mgmt addresses
+ * that may exist.
+ */
+unsigned int cvm_oct_mac_addr_offset;
+
/**
* Function to update link status.
*/
@@ -318,6 +327,20 @@ int cvm_oct_init_module(device_t bus)
printf("cavi
Re: svn commit: r219679 - head/sys/i386/include
On 16 March 2011 21:03, Erik Trulsson wrote: > On Wed, Mar 16, 2011 at 06:45:53PM +0100, Roman Divacky wrote: >> On Wed, Mar 16, 2011 at 12:32:56PM -0400, Jung-uk Kim wrote: >> > On Tuesday 15 March 2011 08:45 pm, Maxim Dounin wrote: >> > > This isn't really different as long as GENERIC kernel used, as >> > > GENERIC defines I486_CPU. >> > >> > Fixed in r219698, sorry. >> > >> > Actually, I think we should remove i486 from GENERIC at some point. >> > It has too many limitations. For example, I really love to implement >> > atomic 64-bit mem read/write using cmpxchg8b (no 0xf00f joke, please) >> > but I cannot do that cleanly without removing I486 support or >> > checking cpu_class at run-time. :-( >> >> if we drop i486 I think it makes sense to require something that has >> at least SSE2, thus we can have the same expectations as on amd64. > > No, that would remove support from far too many machines that people > actually use to run FreeBSD. > There are probably only a handful of people (if that) who actually run > FreeBSD on an actual 486-class machine, but requiring SSE2 would mean > dropping support for Pentium-III and Athlon-XP equipped machines and > I believe there are a large number of such machines still in use, and > they are still perfectly suitable for a large number of tasks. This is understandable but I also think it deserves a poll at stable@ and current@. It might be worth keeping i486 for all of 9-stable but removing it before 10-stable. Judging from previous releases, 9.x would be supported until at least 2016. I don't follow the embedded world that much, but from what I saw, most (incl. Soekris) are moving to Atom designs which support SSE2. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r219699 - head/sys/kern
On 16 March 2011 21:37, Ivan Voras wrote: > For now, there's a report (which actually inspired me to retest and > commit this) from someone who tried this on 2x 15k RPM SAS drives, > with much better results using read_max=128 (thread "gmirror > performance" on freebsd-fs@). I estimate that because his drives were > 15kRPM from the start, the improvement isn't as drastic going from 8 > to 128 as on these SATA drives I tested on (faster seeks). He went > from ~~ 195 MB/s to ~~ 258 MB/s while I go from ~~ 50 MB/s to ~~ 140 > MB/s. Btw I also tested that random IO isn't affected by this: it isn't. The read-ahead heuristics is working. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r219679 - head/sys/i386/include
On Wed, 16 Mar 2011 21:03:46 +0100 Erik Trulsson wrote: > There are probably only a handful of people (if that) who actually run > FreeBSD on an actual 486-class machine, but requiring SSE2 would mean > dropping support for Pentium-III and Athlon-XP equipped machines and > I believe there are a large number of such machines still in use, and > they are still perfectly suitable for a large number of tasks. Some low power x86 CPUs don't have SSE2 either. -- Bruce Cran ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r219699 - head/sys/kern
On 16 March 2011 20:59, Garrett Cooper wrote: > On Wed, Mar 16, 2011 at 12:51 PM, Ivan Voras wrote: >> On 16 March 2011 18:46, Roman Divacky wrote: >>> >>> On Wed, Mar 16, 2011 at 04:22:59PM +, Ivan Voras wrote: >>> > Author: ivoras >>> > Date: Wed Mar 16 16:22:59 2011 >>> > New Revision: 219699 >>> > URL: http://svn.freebsd.org/changeset/base/219699 >>> > >>> > Log: >>> > The hardware has caught up; improvements are now observed even at 128, >>> > but stay conservative and bump read_max to "only" 64 (it will probably >>> > be >>> > a good idea to increase this to 128 after the next major release). >>> >>> how did you measure this? >> >> Specifically for this commit: my desktop 2xSATA 7200 RPM drives, >> gmirror, single read "dd" stream, bs=1m. (Are there any ready read >> multi-stream read tests which are not trivial i.e. they start from >> different positions in the file?) > > Would be interesting to see how well things work with the new > geom_raid bits and with other drives (SAS, SCSI). Yes, I'd be interested in that; I'll try it when I get the chance to test new hardware. For now, there's a report (which actually inspired me to retest and commit this) from someone who tried this on 2x 15k RPM SAS drives, with much better results using read_max=128 (thread "gmirror performance" on freebsd-fs@). I estimate that because his drives were 15kRPM from the start, the improvement isn't as drastic going from 8 to 128 as on these SATA drives I tested on (faster seeks). He went from ~~ 195 MB/s to ~~ 258 MB/s while I go from ~~ 50 MB/s to ~~ 140 MB/s. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r219679 - head/sys/i386/include
On Wednesday 16 March 2011 01:45 pm, Roman Divacky wrote: > On Wed, Mar 16, 2011 at 12:32:56PM -0400, Jung-uk Kim wrote: > > On Tuesday 15 March 2011 08:45 pm, Maxim Dounin wrote: > > > This isn't really different as long as GENERIC kernel used, as > > > GENERIC defines I486_CPU. > > > > Fixed in r219698, sorry. > > > > Actually, I think we should remove i486 from GENERIC at some > > point. It has too many limitations. For example, I really love > > to implement atomic 64-bit mem read/write using cmpxchg8b (no > > 0xf00f joke, please) but I cannot do that cleanly without > > removing I486 support or checking cpu_class at run-time. :-( > > if we drop i486 I think it makes sense to require something that > has at least SSE2, thus we can have the same expectations as on > amd64. > > and we can use sse2 unconditionally (str*, mem* etc.) This is a proof-of-concept patch for sys/x86/isa/clock.c: http://people.freebsd.org/~jkim/clock.diff You see the complexity, just because I wanted to load 64-bit value atomically... :-( Jung-uk Kim ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r219679 - head/sys/i386/include
On Wed, Mar 16, 2011 at 06:45:53PM +0100, Roman Divacky wrote: > On Wed, Mar 16, 2011 at 12:32:56PM -0400, Jung-uk Kim wrote: > > On Tuesday 15 March 2011 08:45 pm, Maxim Dounin wrote: > > > This isn't really different as long as GENERIC kernel used, as > > > GENERIC defines I486_CPU. > > > > Fixed in r219698, sorry. > > > > Actually, I think we should remove i486 from GENERIC at some point. > > It has too many limitations. For example, I really love to implement > > atomic 64-bit mem read/write using cmpxchg8b (no 0xf00f joke, please) > > but I cannot do that cleanly without removing I486 support or > > checking cpu_class at run-time. :-( > > if we drop i486 I think it makes sense to require something that has > at least SSE2, thus we can have the same expectations as on amd64. No, that would remove support from far too many machines that people actually use to run FreeBSD. There are probably only a handful of people (if that) who actually run FreeBSD on an actual 486-class machine, but requiring SSE2 would mean dropping support for Pentium-III and Athlon-XP equipped machines and I believe there are a large number of such machines still in use, and they are still perfectly suitable for a large number of tasks. -- Erik Trulsson ertr1...@student.uu.se ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r219702 - head/sys/boot/i386/common
On Wed Mar 16 11, Andrey V. Elsukov wrote:
> Author: ae
> Date: Wed Mar 16 20:04:56 2011
> New Revision: 219702
> URL: http://svn.freebsd.org/changeset/base/219702
>
> Log:
> Set control flags in putc(). This should fix zfsboot hangs in drvread().
i was looking at xputc() and putchar() and was wondering why these are two
seperate functions? their funcionality can very easily be merged into a single
one.
cheers.
alex
>
> PR: kern/153552
> Reviewed by:jhb
> MFC after: 1 week
>
> Modified:
> head/sys/boot/i386/common/cons.c
>
> Modified: head/sys/boot/i386/common/cons.c
> ==
> --- head/sys/boot/i386/common/cons.c Wed Mar 16 17:09:51 2011
> (r219701)
> +++ head/sys/boot/i386/common/cons.c Wed Mar 16 20:04:56 2011
> (r219702)
> @@ -37,6 +37,7 @@ void
> putc(int c)
> {
>
> + v86.ctl = V86_FLAGS;
> v86.addr = 0x10;
> v86.eax = 0xe00 | (c & 0xff);
> v86.ebx = 0x7;
--
a13x
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r219703 - head/sys/boot/i386/zfsboot
Author: ae Date: Wed Mar 16 20:19:48 2011 New Revision: 219703 URL: http://svn.freebsd.org/changeset/base/219703 Log: The size of zfsboot2 grown up to 64 Kbytes in r219089. Increase NSECT up to 128 sectors too. Reviewed by: jhb, pjd Modified: head/sys/boot/i386/zfsboot/Makefile head/sys/boot/i386/zfsboot/zfsldr.S Modified: head/sys/boot/i386/zfsboot/Makefile == --- head/sys/boot/i386/zfsboot/Makefile Wed Mar 16 20:04:56 2011 (r219702) +++ head/sys/boot/i386/zfsboot/Makefile Wed Mar 16 20:19:48 2011 (r219703) @@ -66,7 +66,7 @@ zfsldr.out: zfsldr.o CLEANFILES+= zfsboot2 zfsboot.ld zfsboot.ldr zfsboot.bin zfsboot.out \ zfsboot.o zfsboot.s zfsboot.s.tmp xreadorg.h sio.o -# We currently allow 32768 bytes for zfsboot - in practice it could be +# We currently allow 65536 bytes for zfsboot - in practice it could be # any size up to 3.5Mb but keeping it fixed size simplifies zfsldr. # BOOT2SIZE= 65536 Modified: head/sys/boot/i386/zfsboot/zfsldr.S == --- head/sys/boot/i386/zfsboot/zfsldr.S Wed Mar 16 20:04:56 2011 (r219702) +++ head/sys/boot/i386/zfsboot/zfsldr.S Wed Mar 16 20:19:48 2011 (r219703) @@ -37,7 +37,7 @@ .set SIZ_PAG,0x1000 # Page size .set SIZ_SEC,0x200 # Sector size - .set NSECT,0x40 + .set NSECT,0x80 .globl start .globl xread .code16 ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r219702 - head/sys/boot/i386/common
Author: ae
Date: Wed Mar 16 20:04:56 2011
New Revision: 219702
URL: http://svn.freebsd.org/changeset/base/219702
Log:
Set control flags in putc(). This should fix zfsboot hangs in drvread().
PR: kern/153552
Reviewed by: jhb
MFC after:1 week
Modified:
head/sys/boot/i386/common/cons.c
Modified: head/sys/boot/i386/common/cons.c
==
--- head/sys/boot/i386/common/cons.cWed Mar 16 17:09:51 2011
(r219701)
+++ head/sys/boot/i386/common/cons.cWed Mar 16 20:04:56 2011
(r219702)
@@ -37,6 +37,7 @@ void
putc(int c)
{
+ v86.ctl = V86_FLAGS;
v86.addr = 0x10;
v86.eax = 0xe00 | (c & 0xff);
v86.ebx = 0x7;
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r219699 - head/sys/kern
On Wed, Mar 16, 2011 at 12:51 PM, Ivan Voras wrote: > On 16 March 2011 18:46, Roman Divacky wrote: >> >> On Wed, Mar 16, 2011 at 04:22:59PM +, Ivan Voras wrote: >> > Author: ivoras >> > Date: Wed Mar 16 16:22:59 2011 >> > New Revision: 219699 >> > URL: http://svn.freebsd.org/changeset/base/219699 >> > >> > Log: >> > The hardware has caught up; improvements are now observed even at 128, >> > but stay conservative and bump read_max to "only" 64 (it will probably be >> > a good idea to increase this to 128 after the next major release). >> >> how did you measure this? > > Specifically for this commit: my desktop 2xSATA 7200 RPM drives, > gmirror, single read "dd" stream, bs=1m. (Are there any ready read > multi-stream read tests which are not trivial i.e. they start from > different positions in the file?) Would be interesting to see how well things work with the new geom_raid bits and with other drives (SAS, SCSI). Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r219699 - head/sys/kern
On Wed, 16 Mar 2011 20:51:17 +0100 Ivan Voras wrote: > (Are there any ready read > multi-stream read tests which are not trivial i.e. they start from > different positions in the file?) I think sysutils/fio can do that. -- Bruce Cran ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r219699 - head/sys/kern
On 16 March 2011 18:46, Roman Divacky wrote: > > On Wed, Mar 16, 2011 at 04:22:59PM +, Ivan Voras wrote: > > Author: ivoras > > Date: Wed Mar 16 16:22:59 2011 > > New Revision: 219699 > > URL: http://svn.freebsd.org/changeset/base/219699 > > > > Log: > > The hardware has caught up; improvements are now observed even at 128, > > but stay conservative and bump read_max to "only" 64 (it will probably be > > a good idea to increase this to 128 after the next major release). > > how did you measure this? Specifically for this commit: my desktop 2xSATA 7200 RPM drives, gmirror, single read "dd" stream, bs=1m. (Are there any ready read multi-stream read tests which are not trivial i.e. they start from different positions in the file?) results: read_max=32 -> 78 MB/s read_max=64 -> 136 MB/s read_max=128 -> 141 MB/s I'm the one who previously bumped read_max from 8 to 32 about a year ago, based on tests under an (otherwise idle, naturally) VMWare cluster on a FC SAN, and a similar point of saturation was at read_max=64. Now it is at 128 with raw hardware. Maybe it should be tuned at 2^(major_freebsd_version-2) :) (as for safety & stability, I've put 2-3 new web servers in production this year with read_max=128 irregardless of this commit. It's stable). ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r219699 - head/sys/kern
On Wed, Mar 16, 2011 at 04:22:59PM +, Ivan Voras wrote: > Author: ivoras > Date: Wed Mar 16 16:22:59 2011 > New Revision: 219699 > URL: http://svn.freebsd.org/changeset/base/219699 > > Log: > The hardware has caught up; improvements are now observed even at 128, > but stay conservative and bump read_max to "only" 64 (it will probably be > a good idea to increase this to 128 after the next major release). how did you measure this? ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r219679 - head/sys/i386/include
On Wed, Mar 16, 2011 at 12:32:56PM -0400, Jung-uk Kim wrote: > On Tuesday 15 March 2011 08:45 pm, Maxim Dounin wrote: > > This isn't really different as long as GENERIC kernel used, as > > GENERIC defines I486_CPU. > > Fixed in r219698, sorry. > > Actually, I think we should remove i486 from GENERIC at some point. > It has too many limitations. For example, I really love to implement > atomic 64-bit mem read/write using cmpxchg8b (no 0xf00f joke, please) > but I cannot do that cleanly without removing I486 support or > checking cpu_class at run-time. :-( if we drop i486 I think it makes sense to require something that has at least SSE2, thus we can have the same expectations as on amd64. and we can use sse2 unconditionally (str*, mem* etc.) ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r219701 - head/sys/dev/dc
Author: yongari
Date: Wed Mar 16 17:09:51 2011
New Revision: 219701
URL: http://svn.freebsd.org/changeset/base/219701
Log:
Remove too expensive bus_dmamap_sync(9) call in dc_rx_resync().
With this change, driver may not notice updated descriptor status
change when bounce buffers are active. However, rxeof() in next run
will handle the synchronization.
Change dc_rxeof() a bit to return the number of processed frames in
RX descriptor ring. Previously it returned the number of frames
that were successfully passed to upper stack which in turn means it
ignored frames that were discarded due to errors. The number of
processed frames in RX descriptor ring is used to detect whether
driver is out of sync with controller's current descriptor pointer.
Returning number of processed frames reduces unnecessary (probably
wrong) re-synchronization.
Reviewed by: marius
Modified:
head/sys/dev/dc/if_dc.c
Modified: head/sys/dev/dc/if_dc.c
==
--- head/sys/dev/dc/if_dc.c Wed Mar 16 16:44:08 2011(r219700)
+++ head/sys/dev/dc/if_dc.c Wed Mar 16 17:09:51 2011(r219701)
@@ -2790,8 +2790,6 @@ dc_rx_resync(struct dc_softc *sc)
pos = sc->dc_cdata.dc_rx_prod;
for (i = 0; i < DC_RX_LIST_CNT; i++) {
- bus_dmamap_sync(sc->dc_rx_ltag, sc->dc_rx_lmap,
- BUS_DMASYNC_POSTREAD | BUS_DMASYNC_POSTWRITE);
cur_rx = &sc->dc_ldata.dc_rx_list[pos];
if (!(le32toh(cur_rx->dc_status) & DC_RXSTAT_OWN))
break;
@@ -2862,6 +2860,7 @@ dc_rxeof(struct dc_softc *sc)
bus_dmamap_sync(sc->dc_rx_mtag, sc->dc_cdata.dc_rx_map[i],
BUS_DMASYNC_POSTREAD);
total_len = DC_RXBYTES(rxstat);
+ rx_npkts++;
if (sc->dc_flags & DC_PNIC_RX_BUG_WAR) {
if ((rxstat & DC_WHOLEFRAME) != DC_WHOLEFRAME) {
@@ -2939,7 +2938,6 @@ dc_rxeof(struct dc_softc *sc)
DC_UNLOCK(sc);
(*ifp->if_input)(ifp, m);
DC_LOCK(sc);
- rx_npkts++;
}
sc->dc_cdata.dc_rx_prod = i;
@@ -3263,7 +3261,7 @@ dc_intr(void *arg)
struct dc_softc *sc;
struct ifnet *ifp;
uint32_t r, status;
- int curpkts, n;
+ int n;
sc = arg;
@@ -3293,9 +3291,7 @@ dc_intr(void *arg)
CSR_WRITE_4(sc, DC_ISR, status);
if (status & DC_ISR_RX_OK) {
- curpkts = ifp->if_ipackets;
- dc_rxeof(sc);
- if (curpkts == ifp->if_ipackets) {
+ if (dc_rxeof(sc) == 0) {
while (dc_rx_resync(sc))
dc_rxeof(sc);
}
@@ -3319,9 +3315,7 @@ dc_intr(void *arg)
|| (status & DC_ISR_RX_NOBUF)) {
r = CSR_READ_4(sc, DC_FRAMESDISCARDED);
ifp->if_ierrors += (r & 0x) + ((r >> 17) & 0x7ff);
- curpkts = ifp->if_ipackets;
- dc_rxeof(sc);
- if (curpkts == ifp->if_ipackets) {
+ if (dc_rxeof(sc) == 0) {
while (dc_rx_resync(sc))
dc_rxeof(sc);
}
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r219700 - head/sys/x86/x86
Author: jkim
Date: Wed Mar 16 16:44:08 2011
New Revision: 219700
URL: http://svn.freebsd.org/changeset/base/219700
Log:
Revert r219676.
Requested by: jhb, bde
Modified:
head/sys/x86/x86/tsc.c
Modified: head/sys/x86/x86/tsc.c
==
--- head/sys/x86/x86/tsc.c Wed Mar 16 16:22:59 2011(r219699)
+++ head/sys/x86/x86/tsc.c Wed Mar 16 16:44:08 2011(r219700)
@@ -263,10 +263,12 @@ sysctl_machdep_tsc_freq(SYSCTL_HANDLER_A
if (tsc_timecounter.tc_frequency == 0)
return (EOPNOTSUPP);
- freq = tsc_timecounter.tc_frequency;
+ freq = tsc_freq;
error = sysctl_handle_64(oidp, &freq, 0, req);
- if (error == 0 && req->newptr != NULL)
- tsc_timecounter.tc_frequency = freq;
+ if (error == 0 && req->newptr != NULL) {
+ tsc_freq = freq;
+ tsc_timecounter.tc_frequency = tsc_freq;
+ }
return (error);
}
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r219679 - head/sys/i386/include
On Tuesday 15 March 2011 08:45 pm, Maxim Dounin wrote: > This isn't really different as long as GENERIC kernel used, as > GENERIC defines I486_CPU. Fixed in r219698, sorry. Actually, I think we should remove i486 from GENERIC at some point. It has too many limitations. For example, I really love to implement atomic 64-bit mem read/write using cmpxchg8b (no 0xf00f joke, please) but I cannot do that cleanly without removing I486 support or checking cpu_class at run-time. :-( Jung-uk Kim ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r219699 - head/sys/kern
Author: ivoras Date: Wed Mar 16 16:22:59 2011 New Revision: 219699 URL: http://svn.freebsd.org/changeset/base/219699 Log: The hardware has caught up; improvements are now observed even at 128, but stay conservative and bump read_max to "only" 64 (it will probably be a good idea to increase this to 128 after the next major release). Modified: head/sys/kern/vfs_cluster.c Modified: head/sys/kern/vfs_cluster.c == --- head/sys/kern/vfs_cluster.c Wed Mar 16 16:09:08 2011(r219698) +++ head/sys/kern/vfs_cluster.c Wed Mar 16 16:22:59 2011(r219699) @@ -71,7 +71,7 @@ static int write_behind = 1; SYSCTL_INT(_vfs, OID_AUTO, write_behind, CTLFLAG_RW, &write_behind, 0, "Cluster write-behind; 0: disable, 1: enable, 2: backed off"); -static int read_max = 32; +static int read_max = 64; SYSCTL_INT(_vfs, OID_AUTO, read_max, CTLFLAG_RW, &read_max, 0, "Cluster read-ahead max block count"); ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r219698 - head/sys/i386/include
Author: jkim
Date: Wed Mar 16 16:09:08 2011
New Revision: 219698
URL: http://svn.freebsd.org/changeset/base/219698
Log:
Rework r219679. Always check CPU class at run-time to make it predictable.
Unfortunately, it pulls in but it is small enough and
namespace pollution is minimal, I hope.
Pointed out by: bde
Pointy hat: jkim
Modified:
head/sys/i386/include/cpu.h
Modified: head/sys/i386/include/cpu.h
==
--- head/sys/i386/include/cpu.h Wed Mar 16 12:40:58 2011(r219697)
+++ head/sys/i386/include/cpu.h Wed Mar 16 16:09:08 2011(r219698)
@@ -39,6 +39,7 @@
/*
* Definitions unique to i386 cpu support.
*/
+#include
#include
#include
#include
@@ -69,14 +70,13 @@ voidswi_vm(void *);
static __inline uint64_t
get_cyclecount(void)
{
-#if defined(I486_CPU) || defined(KLD_MODULE)
struct bintime bt;
- binuptime(&bt);
- return ((uint64_t)bt.sec << 56 | bt.frac >> 8);
-#else
+ if (cpu_class == CPUCLASS_486) {
+ binuptime(&bt);
+ return ((uint64_t)bt.sec << 56 | bt.frac >> 8);
+ }
return (rdtsc());
-#endif
}
#endif
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r219672 - in head: share/man/man9 sys/i386/include
Hello! On Wed, Mar 16, 2011 at 04:26:26PM +0200, Kostik Belousov wrote: > On Wed, Mar 16, 2011 at 05:00:42PM +0300, Maxim Dounin wrote: > > Hello! > > > > On Wed, Mar 16, 2011 at 04:44:35PM +1100, Bruce Evans wrote: > > > > > On Tue, 15 Mar 2011, Jung-uk Kim wrote: > > > > > > >On Tuesday 15 March 2011 03:55 pm, Jung-uk Kim wrote: > > > >>On Tuesday 15 March 2011 03:33 pm, Maxim Dounin wrote: > > > >>>Hello! > > > >>> > > > >>>On Tue, Mar 15, 2011 at 05:14:26PM +, Jung-uk Kim wrote: > > > Author: jkim > > > Date: Tue Mar 15 17:14:26 2011 > > > New Revision: 219672 > > > URL: http://svn.freebsd.org/changeset/base/219672 > > > > > > Log: > > > Unconditionally use binuptime(9) for get_cyclecount(9) on > > > i386. Since this function is almost exclusively used for random > > > harvesting, there is no need for micro-optimization. Adjust > > > the manual page accordingly. > > > >>> > > > >>>Note that on early boot only dummy timecounter available, and > > > >>>binuptime() has no entropy. > > > > > > >>>As a result of this change random(9) won't have entropy on early > > > >>>boot on i386, and arc4random(9) as well. While there are no > > > >>>known major security problems associated with it - it at least > > > >>>makes stack protector easily bypasseable as it now (again after > > > >>>r198295) uses well-known stack guard instead of random one. And > > > >>>there may be other issues as well. > > > > > > Is dummy timecounter used for long enough to matter? I think completion > > > of clock initialization is still bogusly late for histrotical reasons, > > > but there is still a second or two between completion of timecounter > > > initialization and user mode. The earlier stages of booting might > > > take 20 seconds but should be faster, so they might not provided much > > > more entropy from clocks. > > > > The problem is initial random number generator initialization > > (random(9) and acr4random(9)) and various early boot things which > > use random. Most notably it's stack protector (which has to be > > initialized as early as possible, and requires special handling of > > code which is run before it's initialized), but there are also other > > things to care about - AFAIR booting from nfs uses the same ports > > without entropy and so on. > > > > Right now the only entropy used at early boot are from > > get_cyclecount() call, which has at least some entropy on most > > platforms (notable exceptions are arm and i386 with i486 cpus). > > With dummy timecounter there are no entropy at early boot. > > > > After boot everything is eventually reseeded (random(9) at > > proc0_post(), arc4random(9) and /dev/random at userland startup > > scripts) and becomes safe. > proc0_post() is not called after the boot, it is executed during the boot. s/after boot/later in boot process/ > Why is the randomness for the stack protector critical at that stage ? > Most kernel threads are started after INTRINSIC_POST, at least this is > what I see from looking at kernel.h. > > Might be, the ssp initialization should be moved after SI_SUB_INTRINSIC_POST ? Random initialization used to be done at SI_SUB_INTRINSIC_POST. It was proven to be error-prone: there are at least several places in kernel which tried to use random(9) and/or arc4random(9) before SI_SUB_INTRINSIC_POST. That's why SI_SUB_RANDOM was explicitly introduced at a earliest point where we have some randomness (and stack protector initialization was moved to be after this point). While stack protector initialization may be moved later (though I doubt INSTRINSIC_POST would do - I believe we already have interrupts enabled at this point), cleanup of other places will be required, too. And I bet other similar problems will be introduced as time passes. Maxim Dounin ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r219672 - in head: share/man/man9 sys/i386/include
On Wed, Mar 16, 2011 at 05:00:42PM +0300, Maxim Dounin wrote: > Hello! > > On Wed, Mar 16, 2011 at 04:44:35PM +1100, Bruce Evans wrote: > > > On Tue, 15 Mar 2011, Jung-uk Kim wrote: > > > > >On Tuesday 15 March 2011 03:55 pm, Jung-uk Kim wrote: > > >>On Tuesday 15 March 2011 03:33 pm, Maxim Dounin wrote: > > >>>Hello! > > >>> > > >>>On Tue, Mar 15, 2011 at 05:14:26PM +, Jung-uk Kim wrote: > > Author: jkim > > Date: Tue Mar 15 17:14:26 2011 > > New Revision: 219672 > > URL: http://svn.freebsd.org/changeset/base/219672 > > > > Log: > > Unconditionally use binuptime(9) for get_cyclecount(9) on > > i386. Since this function is almost exclusively used for random > > harvesting, there is no need for micro-optimization. Adjust > > the manual page accordingly. > > >>> > > >>>Note that on early boot only dummy timecounter available, and > > >>>binuptime() has no entropy. > > > > >>>As a result of this change random(9) won't have entropy on early > > >>>boot on i386, and arc4random(9) as well. While there are no > > >>>known major security problems associated with it - it at least > > >>>makes stack protector easily bypasseable as it now (again after > > >>>r198295) uses well-known stack guard instead of random one. And > > >>>there may be other issues as well. > > > > Is dummy timecounter used for long enough to matter? I think completion > > of clock initialization is still bogusly late for histrotical reasons, > > but there is still a second or two between completion of timecounter > > initialization and user mode. The earlier stages of booting might > > take 20 seconds but should be faster, so they might not provided much > > more entropy from clocks. > > The problem is initial random number generator initialization > (random(9) and acr4random(9)) and various early boot things which > use random. Most notably it's stack protector (which has to be > initialized as early as possible, and requires special handling of > code which is run before it's initialized), but there are also other > things to care about - AFAIR booting from nfs uses the same ports > without entropy and so on. > > Right now the only entropy used at early boot are from > get_cyclecount() call, which has at least some entropy on most > platforms (notable exceptions are arm and i386 with i486 cpus). > With dummy timecounter there are no entropy at early boot. > > After boot everything is eventually reseeded (random(9) at > proc0_post(), arc4random(9) and /dev/random at userland startup > scripts) and becomes safe. proc0_post() is not called after the boot, it is executed during the boot. Why is the randomness for the stack protector critical at that stage ? Most kernel threads are started after INTRINSIC_POST, at least this is what I see from looking at kernel.h. Might be, the ssp initialization should be moved after SI_SUB_INTRINSIC_POST ? This is definitely irrelevant for usermode ssp, since the first thread enters usermode long after the INTRINSIC_POST is done. > > > I have entropy stuff mostly turned off and often don't even have enough > > entropy to run ed on /etc/fstab early. Don't know if I have clock entropy > > turned off. > > > > >>>Hope you thought well before moving i386 to a set of platforms > > >>>which have no early boot randomness at all. And you have good > > >>>reason for doing it. > > > > I asked for moving all platforms to binuptime() so that the bugs could > > be seen by everyone :-). Didn't know about this bug. > > If you want to change get_cyclecount() to be alias to binuptime() > - we may consider adding another machdep call to extract early > entropy. > > I still not quite understand the reasons though. I consider > binuptime() to be some (bad one) fallback for get_cyclecount() on > platforms which has no hardware counter available. Moving all > platforms to bad fallback looks strange. > > Maxim Dounin pgp994enhgrAr.pgp Description: PGP signature
Re: svn commit: r219672 - in head: share/man/man9 sys/i386/include
Hello! On Wed, Mar 16, 2011 at 04:44:35PM +1100, Bruce Evans wrote: > On Tue, 15 Mar 2011, Jung-uk Kim wrote: > > >On Tuesday 15 March 2011 03:55 pm, Jung-uk Kim wrote: > >>On Tuesday 15 March 2011 03:33 pm, Maxim Dounin wrote: > >>>Hello! > >>> > >>>On Tue, Mar 15, 2011 at 05:14:26PM +, Jung-uk Kim wrote: > Author: jkim > Date: Tue Mar 15 17:14:26 2011 > New Revision: 219672 > URL: http://svn.freebsd.org/changeset/base/219672 > > Log: > Unconditionally use binuptime(9) for get_cyclecount(9) on > i386. Since this function is almost exclusively used for random > harvesting, there is no need for micro-optimization. Adjust > the manual page accordingly. > >>> > >>>Note that on early boot only dummy timecounter available, and > >>>binuptime() has no entropy. > > >>>As a result of this change random(9) won't have entropy on early > >>>boot on i386, and arc4random(9) as well. While there are no > >>>known major security problems associated with it - it at least > >>>makes stack protector easily bypasseable as it now (again after > >>>r198295) uses well-known stack guard instead of random one. And > >>>there may be other issues as well. > > Is dummy timecounter used for long enough to matter? I think completion > of clock initialization is still bogusly late for histrotical reasons, > but there is still a second or two between completion of timecounter > initialization and user mode. The earlier stages of booting might > take 20 seconds but should be faster, so they might not provided much > more entropy from clocks. The problem is initial random number generator initialization (random(9) and acr4random(9)) and various early boot things which use random. Most notably it's stack protector (which has to be initialized as early as possible, and requires special handling of code which is run before it's initialized), but there are also other things to care about - AFAIR booting from nfs uses the same ports without entropy and so on. Right now the only entropy used at early boot are from get_cyclecount() call, which has at least some entropy on most platforms (notable exceptions are arm and i386 with i486 cpus). With dummy timecounter there are no entropy at early boot. After boot everything is eventually reseeded (random(9) at proc0_post(), arc4random(9) and /dev/random at userland startup scripts) and becomes safe. > I have entropy stuff mostly turned off and often don't even have enough > entropy to run ed on /etc/fstab early. Don't know if I have clock entropy > turned off. > > >>>Hope you thought well before moving i386 to a set of platforms > >>>which have no early boot randomness at all. And you have good > >>>reason for doing it. > > I asked for moving all platforms to binuptime() so that the bugs could > be seen by everyone :-). Didn't know about this bug. If you want to change get_cyclecount() to be alias to binuptime() - we may consider adding another machdep call to extract early entropy. I still not quite understand the reasons though. I consider binuptime() to be some (bad one) fallback for get_cyclecount() on platforms which has no hardware counter available. Moving all platforms to bad fallback looks strange. Maxim Dounin ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r219697 - head/contrib/gcc/config/i386
Author: mm
Date: Wed Mar 16 12:40:58 2011
New Revision: 219697
URL: http://svn.freebsd.org/changeset/base/219697
Log:
Fix -march/-mtune=native autodetection for Intel Core 2 CPUs
Obtained from:gcc 4.3 (partial rev. 119454; GPLv2)
MFC after:2 weeks
Modified:
head/contrib/gcc/config/i386/driver-i386.c
Modified: head/contrib/gcc/config/i386/driver-i386.c
==
--- head/contrib/gcc/config/i386/driver-i386.c Wed Mar 16 08:58:09 2011
(r219696)
+++ head/contrib/gcc/config/i386/driver-i386.c Wed Mar 16 12:40:58 2011
(r219697)
@@ -39,6 +39,7 @@ const char *host_detect_local_cpu (int a
#define bit_SSE2 (1 << 26)
#define bit_SSE3 (1 << 0)
+#define bit_SSSE3 (1 << 9)
#define bit_CMPXCHG16B (1 << 13)
#define bit_3DNOW (1 << 31)
@@ -66,7 +67,7 @@ const char *host_detect_local_cpu (int a
unsigned int vendor;
unsigned int ext_level;
unsigned char has_mmx = 0, has_3dnow = 0, has_3dnowp = 0, has_sse = 0;
- unsigned char has_sse2 = 0, has_sse3 = 0, has_cmov = 0;
+ unsigned char has_sse2 = 0, has_sse3 = 0, has_ssse3 = 0, has_cmov = 0;
unsigned char has_longmode = 0, has_cmpxchg8b = 0;
unsigned char is_amd = 0;
unsigned int family = 0;
@@ -107,6 +108,7 @@ const char *host_detect_local_cpu (int a
has_sse = !!(edx & bit_SSE);
has_sse2 = !!(edx & bit_SSE2);
has_sse3 = !!(ecx & bit_SSE3);
+ has_ssse3 = !!(ecx & bit_SSSE3);
/* We don't care for extended family. */
family = (eax >> 8) & ~(1 << 4);
@@ -148,7 +150,9 @@ const char *host_detect_local_cpu (int a
/* We have no idea. Use something reasonable. */
if (arch)
{
- if (has_sse3)
+ if (has_ssse3)
+ cpu = "core2";
+ else if (has_sse3)
{
if (has_longmode)
cpu = "nocona";
@@ -230,6 +234,9 @@ const char *host_detect_local_cpu (int a
cpu = "generic";
}
break;
+case PROCESSOR_GEODE:
+ cpu = "geode";
+ break;
case PROCESSOR_K6:
if (has_3dnow)
cpu = "k6-3";
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r219680 - in head/bin: ln rm test
On 16 March 2011 02:54, Alexander Best wrote: > On Tue Mar 15 11, Jilles Tjoelker wrote: >> Author: jilles >> Date: Tue Mar 15 22:22:11 2011 >> New Revision: 219680 >> URL: http://svn.freebsd.org/changeset/base/219680 >> >> Log: >> bin: Prefer strrchr() to rindex(). > > shouldn't the rindex(3) manual contain a note regarding it's depricated nature > and the fact that strchr(3) is preferred? > Indeed, both index(3) and rindex(3) are marked legacy in POSIX -2004, and are cut from -2008 edition. -- wbr, pluknet ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r219696 - head/lib/libc/gen
Author: pjd
Date: Wed Mar 16 08:58:09 2011
New Revision: 219696
URL: http://svn.freebsd.org/changeset/base/219696
Log:
From fts.c comment:
The "FTS_NOSTAT" option can avoid a lot of calls to stat(2) if it knows that a
directory could not possibly have subdirectories. This is decided by looking
at
the link count: a subdirectory would increment its parent's link count by
virtue of its own ".." entry. This assumption only holds for UFS-like
filesystems that implement links and directories this way, so we must punt for
others.
It looks like ZFS is a UFS-like file system, as the above also holds for ZFS.
Add ZFS to the list of file systems that allow for such optimization.
MFC after:1 month
Modified:
head/lib/libc/gen/fts-compat.c
head/lib/libc/gen/fts.c
Modified: head/lib/libc/gen/fts-compat.c
==
--- head/lib/libc/gen/fts-compat.c Wed Mar 16 08:56:22 2011
(r219695)
+++ head/lib/libc/gen/fts-compat.c Wed Mar 16 08:58:09 2011
(r219696)
@@ -110,6 +110,7 @@ struct _fts_private {
static const char *ufslike_filesystems[] = {
"ufs",
+ "zfs",
"nfs",
"nfs4",
"ext2fs",
Modified: head/lib/libc/gen/fts.c
==
--- head/lib/libc/gen/fts.c Wed Mar 16 08:56:22 2011(r219695)
+++ head/lib/libc/gen/fts.c Wed Mar 16 08:58:09 2011(r219696)
@@ -100,6 +100,7 @@ struct _fts_private {
static const char *ufslike_filesystems[] = {
"ufs",
+ "zfs",
"nfs",
"nfs4",
"ext2fs",
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r219695 - head/sys/mips/cavium/octe
Author: jmallett
Date: Wed Mar 16 08:56:22 2011
New Revision: 219695
URL: http://svn.freebsd.org/changeset/base/219695
Log:
o) Tear down receive interrupt on detach.
Submitted by: Bhanu Prakash
Modified:
head/sys/mips/cavium/octe/ethernet-common.h
head/sys/mips/cavium/octe/ethernet.c
head/sys/mips/cavium/octe/octebus.c
head/sys/mips/cavium/octe/octebusvar.h
Modified: head/sys/mips/cavium/octe/ethernet-common.h
==
--- head/sys/mips/cavium/octe/ethernet-common.h Wed Mar 16 08:51:36 2011
(r219694)
+++ head/sys/mips/cavium/octe/ethernet-common.h Wed Mar 16 08:56:22 2011
(r219695)
@@ -39,7 +39,7 @@ void cvm_oct_common_set_multicast_list(s
void cvm_oct_common_set_mac_address(struct ifnet *ifp, const void *);
int cvm_oct_init_module(device_t);
-void cvm_oct_cleanup_module(void);
+void cvm_oct_cleanup_module(device_t);
/*
* XXX/juli
Modified: head/sys/mips/cavium/octe/ethernet.c
==
--- head/sys/mips/cavium/octe/ethernet.cWed Mar 16 08:51:36 2011
(r219694)
+++ head/sys/mips/cavium/octe/ethernet.cWed Mar 16 08:56:22 2011
(r219695)
@@ -250,7 +250,7 @@ static void cvm_oct_configure_common_hw(
error = bus_setup_intr(bus, sc->sc_rx_irq, INTR_TYPE_NET | INTR_MPSAFE,
cvm_oct_do_interrupt, NULL, cvm_oct_device,
- NULL);
+ &sc->sc_rx_intr_cookie);
if (error != 0) {
device_printf(bus, "could not setup workq irq");
return;
@@ -473,17 +473,16 @@ int cvm_oct_init_module(device_t bus)
*
* @return Zero on success
*/
-void cvm_oct_cleanup_module(void)
+void cvm_oct_cleanup_module(device_t bus)
{
int port;
+ struct octebus_softc *sc = device_get_softc(bus);
/* Disable POW interrupt */
cvmx_write_csr(CVMX_POW_WQ_INT_THRX(pow_receive_group), 0);
-#if 0
/* Free the interrupt handler */
- free_irq(8 + pow_receive_group, cvm_oct_device);
-#endif
+ bus_teardown_intr(bus, sc->sc_rx_irq, sc->sc_rx_intr_cookie);
callout_stop(&cvm_oct_poll_timer);
cvm_oct_rx_shutdown();
Modified: head/sys/mips/cavium/octe/octebus.c
==
--- head/sys/mips/cavium/octe/octebus.c Wed Mar 16 08:51:36 2011
(r219694)
+++ head/sys/mips/cavium/octe/octebus.c Wed Mar 16 08:56:22 2011
(r219695)
@@ -112,7 +112,7 @@ octebus_attach(device_t dev)
static int
octebus_detach(device_t dev)
{
- cvm_oct_cleanup_module();
+ cvm_oct_cleanup_module(dev);
return (0);
}
Modified: head/sys/mips/cavium/octe/octebusvar.h
==
--- head/sys/mips/cavium/octe/octebusvar.h Wed Mar 16 08:51:36 2011
(r219694)
+++ head/sys/mips/cavium/octe/octebusvar.h Wed Mar 16 08:56:22 2011
(r219695)
@@ -33,6 +33,7 @@ struct octebus_softc {
device_t sc_dev;
struct resource *sc_rx_irq;
+ void *sc_rx_intr_cookie;
struct resource *sc_rgmii_irq;
struct resource *sc_spi_irq;
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r219694 - in head/sys: contrib/octeon-sdk mips/cavium/octe
Author: jmallett
Date: Wed Mar 16 08:51:36 2011
New Revision: 219694
URL: http://svn.freebsd.org/changeset/base/219694
Log:
o) Clean up FPA pools on module unload.
o) Allocate output buffer pool based on available output queues.
Submitted by: Bhanu Prakash (with modifications)
Modified:
head/sys/contrib/octeon-sdk/cvmx-fpa.h
head/sys/mips/cavium/octe/ethernet.c
head/sys/mips/cavium/octe/wrapper-cvmx-includes.h
Modified: head/sys/contrib/octeon-sdk/cvmx-fpa.h
==
--- head/sys/contrib/octeon-sdk/cvmx-fpa.h Wed Mar 16 08:22:29 2011
(r219693)
+++ head/sys/contrib/octeon-sdk/cvmx-fpa.h Wed Mar 16 08:51:36 2011
(r219694)
@@ -154,6 +154,19 @@ static inline void cvmx_fpa_enable(void)
}
/**
+ * Reset FPA to disable. Make sure buffers from all FPA pools are freed
+ * before disabling FPA.
+ */
+static inline void cvmx_fpa_disable(void)
+{
+cvmx_fpa_ctl_status_t status;
+
+status.u64 = cvmx_read_csr(CVMX_FPA_CTL_STATUS);
+status.s.reset = 1;
+cvmx_write_csr(CVMX_FPA_CTL_STATUS, status.u64);
+}
+
+/**
* Get a new block from the FPA
*
* @param pool Pool to get the block from
Modified: head/sys/mips/cavium/octe/ethernet.c
==
--- head/sys/mips/cavium/octe/ethernet.cWed Mar 16 08:22:29 2011
(r219693)
+++ head/sys/mips/cavium/octe/ethernet.cWed Mar 16 08:51:36 2011
(r219694)
@@ -98,6 +98,11 @@ struct ifnet *cvm_oct_device[TOTAL_NUMBE
*/
static struct taskqueue *cvm_oct_link_taskq;
+/*
+ * Number of buffers in output buffer pool.
+ */
+static int cvm_oct_num_output_buffers;
+
/**
* Function to update link status.
*/
@@ -185,13 +190,13 @@ static void cvm_do_timer(void *arg)
}
}
-
/**
* Configure common hardware for all interfaces
*/
static void cvm_oct_configure_common_hw(device_t bus)
{
struct octebus_softc *sc;
+ int pko_queues;
int error;
int rid;
@@ -199,13 +204,34 @@ static void cvm_oct_configure_common_hw(
/* Setup the FPA */
cvmx_fpa_enable();
- cvm_oct_mem_fill_fpa(CVMX_FPA_PACKET_POOL, CVMX_FPA_PACKET_POOL_SIZE,
num_packet_buffers);
- cvm_oct_mem_fill_fpa(CVMX_FPA_WQE_POOL, CVMX_FPA_WQE_POOL_SIZE,
num_packet_buffers);
- if (CVMX_FPA_OUTPUT_BUFFER_POOL != CVMX_FPA_PACKET_POOL)
- cvm_oct_mem_fill_fpa(CVMX_FPA_OUTPUT_BUFFER_POOL,
CVMX_FPA_OUTPUT_BUFFER_POOL_SIZE, 128);
+ cvm_oct_mem_fill_fpa(CVMX_FPA_PACKET_POOL, CVMX_FPA_PACKET_POOL_SIZE,
+num_packet_buffers);
+ cvm_oct_mem_fill_fpa(CVMX_FPA_WQE_POOL, CVMX_FPA_WQE_POOL_SIZE,
+num_packet_buffers);
+ if (CVMX_FPA_OUTPUT_BUFFER_POOL != CVMX_FPA_PACKET_POOL) {
+ /*
+* If the FPA uses different pools for output buffers and
+* packets, size the output buffer pool based on the number
+* of PKO queues.
+*/
+ if (OCTEON_IS_MODEL(OCTEON_CN38XX))
+ pko_queues = 128;
+ else if (OCTEON_IS_MODEL(OCTEON_CN3XXX))
+ pko_queues = 32;
+ else if (OCTEON_IS_MODEL(OCTEON_CN50XX))
+ pko_queues = 32;
+ else
+ pko_queues = 256;
+
+ cvm_oct_num_output_buffers = 4 * pko_queues;
+ cvm_oct_mem_fill_fpa(CVMX_FPA_OUTPUT_BUFFER_POOL,
+CVMX_FPA_OUTPUT_BUFFER_POOL_SIZE,
+cvm_oct_num_output_buffers);
+ }
if (USE_RED)
- cvmx_helper_setup_red(num_packet_buffers/4,
num_packet_buffers/8);
+ cvmx_helper_setup_red(num_packet_buffers/4,
+ num_packet_buffers/8);
/* Enable the MII interface */
if (!octeon_is_simulation())
@@ -303,11 +329,13 @@ int cvm_oct_init_module(device_t bus)
int num_ports = cvmx_helper_ports_on_interface(interface);
int port;
- for (port = cvmx_helper_get_ipd_port(interface, 0); port <
cvmx_helper_get_ipd_port(interface, num_ports); port++) {
+ for (port = 0; port < num_ports; port++) {
cvmx_pip_prt_tagx_t pip_prt_tagx;
- pip_prt_tagx.u64 =
cvmx_read_csr(CVMX_PIP_PRT_TAGX(port));
+ int pkind = cvmx_helper_get_ipd_port(interface, port);
+
+ pip_prt_tagx.u64 =
cvmx_read_csr(CVMX_PIP_PRT_TAGX(pkind));
pip_prt_tagx.s.grp = pow_receive_group;
- cvmx_write_csr(CVMX_PIP_PRT_TAGX(port),
pip_prt_tagx.u64);
+ cvmx_write_csr(CVMX_PIP_PRT_TAGX(pkind),
pip_prt_tagx.u64);
}
}
@@ -475,4 +503,13 @@ void cvm
svn commit: r219693 - in head/sys/mips: include mips
Author: jmallett
Date: Wed Mar 16 08:22:29 2011
New Revision: 219693
URL: http://svn.freebsd.org/changeset/base/219693
Log:
o) Properly size caches and TLB on Octeon.
o) Make COP0_SYNC do nothing on Octeon, which is fully interlocked.
Submitted by: Bhanu Prakash (with modifications)
Modified:
head/sys/mips/include/cpuregs.h
head/sys/mips/mips/cpu.c
Modified: head/sys/mips/include/cpuregs.h
==
--- head/sys/mips/include/cpuregs.h Wed Mar 16 04:03:13 2011
(r219692)
+++ head/sys/mips/include/cpuregs.h Wed Mar 16 08:22:29 2011
(r219693)
@@ -198,12 +198,10 @@
#endif
/* CPU dependent mtc0 hazard hook */
-#ifdef CPU_CNMIPS
-#defineCOP0_SYNC nop; nop; nop; nop; nop;
+#if defined(CPU_CNMIPS) || defined(CPU_RMI)
+#defineCOP0_SYNC
#elif defined(CPU_SB1)
#define COP0_SYNC ssnop; ssnop; ssnop; ssnop; ssnop; ssnop; ssnop; ssnop;
ssnop
-#elif defined(CPU_RMI)
-#define COP0_SYNC
#else
/*
* Pick a reasonable default based on the "typical" spacing described in the
@@ -571,6 +569,7 @@
* 16/1MIPS_COP_0_CONFIG1 ..33 Configuration register 1.
* 16/2MIPS_COP_0_CONFIG2 ..33 Configuration register 2.
* 16/3MIPS_COP_0_CONFIG3 ..33 Configuration register 3.
+ * 16/4 MIPS_COP_0_CONFIG4 ..33 Configuration register 4.
* 17 MIPS_COP_0_LLADDR .336 Load Linked Address.
* 18 MIPS_COP_0_WATCH_LO .336 WatchLo register.
* 19 MIPS_COP_0_WATCH_HI .333 WatchHi register.
@@ -656,7 +655,7 @@
#define MIPS_CONFIG1_TLBSZ_MASK0x7E00 /* bits 30..25
# tlb entries minus one */
#define MIPS_CONFIG1_TLBSZ_SHIFT 25
-#defineMIPS_MAX_TLB_ENTRIES64
+#defineMIPS_MAX_TLB_ENTRIES128
#define MIPS_CONFIG1_IS_MASK 0x01C0 /* bits 24..22 icache
sets per way */
#define MIPS_CONFIG1_IS_SHIFT 22
@@ -679,6 +678,10 @@
#define MIPS_CONFIG1_EP0x0002 /* EJTAG
implemented */
#define MIPS_CONFIG1_FP0x0001 /* FPU
implemented */
+#define MIPS_CONFIG4_MMUSIZEEXT0x00FF /* bits 7.. 0
MMU Size Extension */
+#define MIPS_CONFIG4_MMUEXTDEF 0xC000 /* bits 15.14 MMU
Extension Definition */
+#define MIPS_CONFIG4_MMUEXTDEF_MMUSIZEEXT 0x4000 /* This values
denotes CONFIG4 bits */
+
/*
* Values for the code field in a break instruction.
*/
Modified: head/sys/mips/mips/cpu.c
==
--- head/sys/mips/mips/cpu.cWed Mar 16 04:03:13 2011(r219692)
+++ head/sys/mips/mips/cpu.cWed Mar 16 08:22:29 2011(r219693)
@@ -52,6 +52,11 @@ __FBSDID("$FreeBSD$");
#include
#include
+#if defined(CPU_CNMIPS)
+#include
+#include
+#endif
+
static void cpu_identify(void);
struct mips_cpuinfo cpuinfo;
@@ -70,6 +75,9 @@ mips_get_identity(struct mips_cpuinfo *c
u_int32_t prid;
u_int32_t cfg0;
u_int32_t cfg1;
+#if defined(CPU_CNMIPS)
+ u_int32_t cfg4;
+#endif
u_int32_t tmp;
memset(cpuinfo, 0, sizeof(struct mips_cpuinfo));
@@ -96,6 +104,13 @@ mips_get_identity(struct mips_cpuinfo *c
cpuinfo->tlb_nentries =
((cfg1 & MIPS_CONFIG1_TLBSZ_MASK) >> MIPS_CONFIG1_TLBSZ_SHIFT) + 1;
+ /* Add extended TLB size information from config4. */
+#if defined(CPU_CNMIPS)
+ cfg4 = mips_rd_config4();
+ if ((cfg4 & MIPS_CONFIG4_MMUEXTDEF) ==
MIPS_CONFIG4_MMUEXTDEF_MMUSIZEEXT)
+ cpuinfo->tlb_nentries += (cfg4 & MIPS_CONFIG4_MMUSIZEEXT) *
0x40;
+#endif
+
/* L1 instruction cache. */
tmp = (cfg1 & MIPS_CONFIG1_IL_MASK) >> MIPS_CONFIG1_IL_SHIFT;
if (tmp != 0) {
@@ -103,10 +118,9 @@ mips_get_identity(struct mips_cpuinfo *c
cpuinfo->l1.ic_nways = (((cfg1 & MIPS_CONFIG1_IA_MASK) >>
MIPS_CONFIG1_IA_SHIFT)) + 1;
cpuinfo->l1.ic_nsets =
1 << (((cfg1 & MIPS_CONFIG1_IS_MASK) >>
MIPS_CONFIG1_IS_SHIFT) + 6);
- cpuinfo->l1.ic_size =
- cpuinfo->l1.ic_linesize * cpuinfo->l1.ic_nsets *
cpuinfo->l1.ic_nways;
}
+#ifndef CPU_CNMIPS
/* L1 data cache. */
tmp = (cfg1 & MIPS_CONFIG1_DL_MASK) >> MIPS_CONFIG1_DL_SHIFT;
if (tmp != 0) {
@@ -116,15 +130,36 @@ mips_get_identity(struct mips_cpuinfo *c
cpuinfo->l1.dc_nsets =
1 << (((cfg1 & MIPS_CONFIG1_DS_MASK) >>
MIPS_CONFIG1_DS_SHIFT) + 6);
}
-#ifdef CPU_CNMIPS
+#else
/*
-* Octeon does 128 byte line-size. But Config-Sel1 doesn't show
-* 128 line-size, 1 Set, 64 ways.
+* Some Octeon cache configuration parameters are by model family, not
+* config1.
*/
+ if (OCTEON_IS_MODEL(OCTEON_CN3XXX)) {
+ /* Octeon and
Re: svn commit: r219646 - head/sys/x86/isa
On Tue, 15 Mar 2011, Jung-uk Kim wrote: On Tuesday 15 March 2011 02:13 pm, Bruce Evans wrote: On Tue, 15 Mar 2011, Jung-uk Kim wrote: ... I disagree. I think we should keep away from i8254 as much as possible. It is adequate for DELAY(), and is the only timer that is available on all x86. You need large complications in DELAY() to make it work as well as the old code using the i8254, for no gain until there is an x86 without an i8254. Intel started killing off i8254 (and other "legacy" ISA devices), starting from "Mobile Internet Device" platforms. Even for other so-called "legacy-free" platforms, it isn't adequate any more because of unpredictable SMI# interference. I thought of getting a SandyBridge system and decided not to since it it kills too much of my hardware. Lengthening the delay due to SMI# interference doesn't matter in DELAY(), since normal interrupts also lengthen it. SMI# would have to corrupt the i8254 state to cause larger problems. (This is too easy to do since the i8254 cannot be used without clobbering its current state by more than advancing its countdown.) Even in this patch, it isn't clear that the low level timecounters are initialized before they are used. The timecounter is always initialized first, then set. It is still unclear whether they are initialized enough before they are used since their setting is neither locked nor atomic. ... accessing it. In fact, I can now see a reproducible bug in DELAY(): - find an x86 that can run at 4GHz - run it in 386 mode - start it so that tsc_freq is 0x1000ULL - use the machdep.tsc_freq sysctl to tune tsc_freq to 0x machdep.tsc_freq should never have modified tsc_freq in the first place. I am going to remove that soon. No, changing tsc_freq is what machdep.tsc_freq is for. Breaking this would be backed out :-). You can fix it using a generation count or something. [More examples of races.] Now don't you think we should really kill delay by TSC? ;-) I always said that it should never have existed. This leaves similar bugs in timecounter intiialization, but there is some protection from generation counts and time-domain locking there. The sysctl is hackish in writing directly to the timecounter freqquency variable instead of calling a tc function like tc_setclock(). I forget why it does that. (I said tc_init() before. tc_init() is only for initial initialization and tc_setclock() is intended only for adjustments to the time.) Bruce ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r219646 - head/sys/x86/isa
On Tue, 15 Mar 2011, Jung-uk Kim wrote: On Tuesday 15 March 2011 03:51 pm, John Baldwin wrote: On Tuesday, March 15, 2011 3:26:11 pm Jung-uk Kim wrote: Now don't you think we should really kill delay by TSC? ;-) Delay by TSC fixed known deadlocks with the i8254 based DELAY() due to the use of locks. Be careful that you don't re-introduce old bugs. Yeah, that's perfectly understood. I don't understand it. I don't know of any deadlocks except the ones in ddb that I fixed, and there were deadlocks, they can't have been fixed by using the TSC, since the TSC is not always available. It is not even always available on systems that have a P-state invariant TSC synchronized across all CPUs, since it is not initialized early, so the old deadlock avoidance is still needed. In fact, I found the deadlock using ddb to debug TSC initialization which used the i8254 (not via DELAY()) for calibrating the TSC frequency. Also, you can use a TSC for DELAY() in cases when it is not safe to use it for the timecounter (if it is not in sync across cores, but is used in a machine with invariant TSCs or where the user knows they won't ever throttle it). Modern Intel CPUs all have invariant TSCs that are more or less in sync across cores, and we should certainly still use the TSC for DELAY() in that case. Even if they aren't in sync (so we can't use it for the timecounter) we should still use the TSC if they are invariant as it is far cheaper than anything else. That, too, is well understood. You know I added tsc_is_invariant myself. :-) "1: [pause;] decl %eax; jne 1b" in a loop works just as well as rdtsc in a loop if the TSC is _not_ P-state invariant. Both break similarly if the TSC frequency changes. You have to change the loop count if the frequency changes, but it is hard to tell if this is necessary. Telling if it is necessary requires reading a real hardware timer to recalibrate occasionally from within the loop and without, and the timer read from within the loop gives the same locking complications that you are trying to avoid. However, why do we need cheaper DELAY() when we trying to "delay" something with it? kib mentioned bus activity. "1: decl %eax; jne 1b" doesn't have that. I wonder if rdtsc has it. Phenom has much slower rdtsc than Athlon to help make it P-state invariant. Does this involve bus activity? What does "pause" do in a loop that is only accessing registers? Bruce ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
