svn commit: r242906 - in head/sys/dev/usb: . serial
Author: hselasky Date: Mon Nov 12 07:25:51 2012 New Revision: 242906 URL: http://svnweb.freebsd.org/changeset/base/242906 Log: Add new USB IDs. MFC after:1 week PR: usb/173503 Modified: head/sys/dev/usb/serial/u3g.c head/sys/dev/usb/usbdevs Modified: head/sys/dev/usb/serial/u3g.c == --- head/sys/dev/usb/serial/u3g.c Mon Nov 12 07:25:47 2012 (r242905) +++ head/sys/dev/usb/serial/u3g.c Mon Nov 12 07:25:51 2012 (r242906) @@ -319,6 +319,10 @@ static const STRUCT_USB_HOST_ID u3g_devs U3G_DEV(HUAWEI, E1820, U3GINIT_HUAWEISCSI), U3G_DEV(HUAWEI, K3765, U3GINIT_HUAWEI), U3G_DEV(HUAWEI, K3765_INIT, U3GINIT_HUAWEISCSI), + U3G_DEV(HUAWEI, K3770, U3GINIT_HUAWEI), + U3G_DEV(HUAWEI, K3770_INIT, U3GINIT_HUAWEISCSI), + U3G_DEV(HUAWEI, K4505, U3GINIT_HUAWEI), + U3G_DEV(HUAWEI, K4505_INIT, U3GINIT_HUAWEISCSI), U3G_DEV(HUAWEI, ETS2055, U3GINIT_HUAWEI), U3G_DEV(KYOCERA2, CDMA_MSM_K, 0), U3G_DEV(KYOCERA2, KPC680, 0), Modified: head/sys/dev/usb/usbdevs == --- head/sys/dev/usb/usbdevsMon Nov 12 07:25:47 2012(r242905) +++ head/sys/dev/usb/usbdevsMon Nov 12 07:25:51 2012(r242906) @@ -2189,12 +2189,16 @@ product HUAWEI E143D0x143d 3G modem product HUAWEI E143E 0x143e 3G modem product HUAWEI E143F 0x143f 3G modem product HUAWEI E1752 0x1446 3G modem +product HUAWEI K4505 0x1464 3G modem product HUAWEI K3765 0x1465 3G modem product HUAWEI E1820 0x14ac E1820 HSPA+ USB Slider +product HUAWEI K3770 0x14c9 3G modem +product HUAWEI K3770_INIT 0x14d1 K3770 Initial product HUAWEI E3131_INIT 0x14fe 3G modem initial product HUAWEI E3920x1505 LTE modem product HUAWEI E3131 0x1506 3G modem product HUAWEI K3765_INIT 0x1520 K3765 Initial +product HUAWEI K4505_INIT 0x1521 K4505 Initial product HUAWEI ETS2055 0x1803 CDMA modem product HUAWEI E1730x1c05 3G modem product HUAWEI E173_INIT 0x1c0b 3G modem initial ___ 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: r242904 - head/sys/powerpc/include
Author: rpaulo
Date: Mon Nov 12 06:15:54 2012
New Revision: 242904
URL: http://svnweb.freebsd.org/changeset/base/242904
Log:
Allow this file to be used in LOCORE sections of the kernel.
Modified:
head/sys/powerpc/include/bat.h
Modified: head/sys/powerpc/include/bat.h
==
--- head/sys/powerpc/include/bat.h Mon Nov 12 00:30:40 2012
(r242903)
+++ head/sys/powerpc/include/bat.h Mon Nov 12 06:15:54 2012
(r242904)
@@ -71,10 +71,12 @@
#ifndef_MACHINE_BAT_H_
#define_MACHINE_BAT_H_
+#ifndef LOCORE
struct bat {
u_int32_t batu;
u_int32_t batl;
};
+#endif
/* Lower BAT bits (all but PowerPC 601): */
#defineBAT_PBS 0xfffe /* physical block start */
@@ -165,7 +167,7 @@ struct bat {
#defineBATL601(pa, size, v)
\
(((pa) & BAT601_PBN) | (v) | (size))
-#ifdef _KERNEL
+#if defined(_KERNEL) && !defined(LOCORE)
extern struct bat battable[16];
#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"
svn commit: r242903 - head/sys/vm
Author: attilio
Date: Mon Nov 12 00:30:40 2012
New Revision: 242903
URL: http://svnweb.freebsd.org/changeset/base/242903
Log:
Fix DDB command "show map XXX":
- Check that an argument is always available, otherwise current map
printing before to recurse is garbage.
- Spit out a message if an argument is not provided.
- Remove unread nlines variable.
- Use an explicit recursive function, disassociated from the
DB_SHOW_COMMAND() body, in order to make clear prototype and recursion
of the above mentioned function. The code results now much less
obscure.
Submitted by: gianni
Modified:
head/sys/vm/vm_map.c
Modified: head/sys/vm/vm_map.c
==
--- head/sys/vm/vm_map.cSun Nov 11 23:29:45 2012(r242902)
+++ head/sys/vm/vm_map.cMon Nov 12 00:30:40 2012(r242903)
@@ -3975,32 +3975,20 @@ vm_map_lookup_done(vm_map_t map, vm_map_
#include
-/*
- * vm_map_print: [ debug ]
- */
-DB_SHOW_COMMAND(map, vm_map_print)
+static void
+vm_map_print(vm_map_t map)
{
- static int nlines;
- /* XXX convert args. */
- vm_map_t map = (vm_map_t)addr;
- boolean_t full = have_addr;
-
vm_map_entry_t entry;
db_iprintf("Task map %p: pmap=%p, nentries=%d, version=%u\n",
(void *)map,
(void *)map->pmap, map->nentries, map->timestamp);
- nlines++;
-
- if (!full && db_indent)
- return;
db_indent += 2;
for (entry = map->header.next; entry != &map->header;
entry = entry->next) {
db_iprintf("map entry %p: start=%p, end=%p\n",
(void *)entry, (void *)entry->start, (void *)entry->end);
- nlines++;
{
static char *inheritance_name[4] =
{"share", "copy", "none", "donate_copy"};
@@ -4016,14 +4004,11 @@ DB_SHOW_COMMAND(map, vm_map_print)
db_printf(", share=%p, offset=0x%jx\n",
(void *)entry->object.sub_map,
(uintmax_t)entry->offset);
- nlines++;
if ((entry->prev == &map->header) ||
(entry->prev->object.sub_map !=
entry->object.sub_map)) {
db_indent += 2;
- vm_map_print((db_expr_t)(intptr_t)
-entry->object.sub_map,
-full, 0, (char *)0);
+ vm_map_print((vm_map_t)entry->object.sub_map);
db_indent -= 2;
}
} else {
@@ -4040,7 +4025,6 @@ DB_SHOW_COMMAND(map, vm_map_print)
db_printf(", copy (%s)",
(entry->eflags & MAP_ENTRY_NEEDS_COPY) ?
"needed" : "done");
db_printf("\n");
- nlines++;
if ((entry->prev == &map->header) ||
(entry->prev->object.vm_object !=
@@ -4048,17 +4032,23 @@ DB_SHOW_COMMAND(map, vm_map_print)
db_indent += 2;
vm_object_print((db_expr_t)(intptr_t)
entry->object.vm_object,
- full, 0, (char *)0);
- nlines += 4;
+ 1, 0, (char *)0);
db_indent -= 2;
}
}
}
db_indent -= 2;
- if (db_indent == 0)
- nlines = 0;
}
+DB_SHOW_COMMAND(map, map)
+{
+
+ if (!have_addr) {
+ db_printf("usage: show map \n");
+ return;
+ }
+ vm_map_print((vm_map_t)addr);
+}
DB_SHOW_COMMAND(procvm, procvm)
{
@@ -4074,7 +4064,7 @@ DB_SHOW_COMMAND(procvm, procvm)
(void *)p, (void *)p->p_vmspace, (void *)&p->p_vmspace->vm_map,
(void *)vmspace_pmap(p->p_vmspace));
- vm_map_print((db_expr_t)(intptr_t)&p->p_vmspace->vm_map, 1, 0, NULL);
+ vm_map_print((vm_map_t)&p->p_vmspace->vm_map);
}
#endif /* DDB */
___
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: r234352 - in head/sys: amd64/linux32 compat/linux i386/linux kern
On Fri, Jun 29, 2012 at 07:36:26AM +1000, Peter Jeremy wrote: > On 2012-Apr-16 21:22:02 +, Jung-uk Kim wrote: > >Log: > > - Implement pipe2 syscall for Linuxulator. This syscall appeared in 2.6.27 > > but GNU libc used it without checking its kernel version, e. g., Fedora 10. > > Recent versions of flash are complaining about the lack of pipe2(). > Do you have any plans to MFC this? I've had a quick look but there > are non-trivial conflicts in kern/sys_pipe.c on both 8.x & 9.x and > I don't want to spend time resolving them if you have already done so. > Conflicts at least for 9.x were not that scary after all. My only intervention is here: http://people.freebsd.org/~mjg/patches/stable9-pipe2-sys_pipe.diff I'm happy to merge this to stable/9 once someone reviews this. Full path with regenerated syscall.master for easier testing: http://people.freebsd.org/~mjg/patches/stable9-pipe2-full.diff -- Mateusz Guzik ___ 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: r242897 - head/release
On Mon, Nov 12, 2012 at 10:24:02AM +1030, Daniel O'Connor wrote: > > On 12/11/2012, at 9:00, Glen Barber wrote: > >> Since snapdir=visible is non-standard setting, will it be sensible to > >> exclude .snap as well? (maybe also .git?) > >> > > > > Yes, I think so. This was mentioned yesterday, but I had already sent > > this patch for review. I do intend to exclude more dot-dirs. > > > Why not just exclude '.??*' ? > Because I have not yet had a chance to test such a change. Glen pgp19ufkztu9K.pgp Description: PGP signature
Re: svn commit: r242897 - head/release
On 12/11/2012, at 9:00, Glen Barber wrote: >> Since snapdir=visible is non-standard setting, will it be sensible to >> exclude .snap as well? (maybe also .git?) >> > > Yes, I think so. This was mentioned yesterday, but I had already sent > this patch for review. I do intend to exclude more dot-dirs. Why not just exclude '.??*' ? I doubt the source tree will ever grow a top level directory whose name starts with a dot. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
Re: svn commit: r242849 - head/usr.bin/calendar/calendars
On Sunday, 11 November 2012 at 21:16:11 +0100, Marc Balmer wrote: > > The date of the encounter is not clear at all. Some sources list > oct. 27, some oct. 28, and some nov. 10 > (http://en.wikipedia.org/wiki/Henry_Morton_Stanley). I took my information from Wikipedia, the source of all wisdom. It's a pity that the German and English Wikipedias can't even agree on a date, and that other documentation says 10 November. > So this should be researched a bit more. I've done a bit of Googling and come up with Stanley's book "How I found Livingstone", http://www.gutenberg.org/dirs/5/1/5/5157/5157-h/5157-h.htm It states clearly and in great detail that the encounter was on 10 November, though it contains the confusing statement: This was that famous letter bag marked 'November 1, 1870,' which was now delivered into the Doctor's hand 365 days after it left Zanzibar! That would mean 1 November. I've updated the calendar and the English and German Wikipedias, so I thought the matter was done and dusted. But that was the book, not the diary. And then I read in http://en.wikipedia.org/wiki/Henry_Morton_Stanley#Finding_Livingstone : This famous phrase may be a fabrication, as Stanley tore out of his diary the pages relating to the encounter. The diary is available too, but not online. I'll check. And all this for what was really just a spelling error! Greg -- Sent from my desktop computer. Finger g...@freebsd.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua pgpqmIUkacYEW.pgp Description: PGP signature
svn commit: r242901 - head/sys/sys
Author: attilio
Date: Sun Nov 11 23:25:47 2012
New Revision: 242901
URL: http://svnweb.freebsd.org/changeset/base/242901
Log:
Tweak comments.
In collabouration with: alc
Modified:
head/sys/sys/_mutex.h
head/sys/sys/_rwlock.h
Modified: head/sys/sys/_mutex.h
==
--- head/sys/sys/_mutex.h Sun Nov 11 22:43:36 2012(r242900)
+++ head/sys/sys/_mutex.h Sun Nov 11 23:25:47 2012(r242901)
@@ -36,12 +36,11 @@
/*
* Sleep/spin mutex.
*
- * The layout of the first 2 members of struct mtx* is considered fixed.
- * More specifically, it is assumed that there is a member called mtx_lock
- * for every struct mtx* and that other locking primitive structures are
- * not allowed to use such name for their members.
- * If this needs to change, the bits in the mutex implementation might be
- * modified appropriately.
+ * All mutex implementations must always have a member called mtx_lock.
+ * Other locking primitive structures are not allowed to use this name
+ * for their members.
+ * If this rule needs to change, the bits in the mutex implementation must
+ * be modified appropriately.
*/
struct mtx {
struct lock_object lock_object;/* Common lock properties. */
@@ -50,11 +49,12 @@ struct mtx {
/*
* Members of struct mtx_padalign must mirror members of struct mtx.
- * mtx_padalign mutexes can use mtx(9) KPI transparently, without modifies.
- * When using pad-aligned mutexes within structures, they should generally
- * stay as the first member of the struct. This is because otherwise the
- * compiler can generate ever more padding for the struct to keep a correct
- * alignment for the mutex.
+ * mtx_padalign mutexes can use the mtx(9) API transparently without
+ * modification.
+ * Pad-aligned mutexes used within structures should generally be the
+ * first member of the struct. Otherwise, the compiler can generate
+ * additional padding for the struct to keep a correct alignment for
+ * the mutex.
*/
struct mtx_padalign {
struct lock_object lock_object;/* Common lock properties. */
Modified: head/sys/sys/_rwlock.h
==
--- head/sys/sys/_rwlock.h Sun Nov 11 22:43:36 2012(r242900)
+++ head/sys/sys/_rwlock.h Sun Nov 11 23:25:47 2012(r242901)
@@ -37,12 +37,11 @@
/*
* Reader/writer lock.
*
- * The layout of the first 2 members of struct rwlock* is considered fixed.
- * More specifically, it is assumed that there is a member called rw_lock
- * for every struct rwlock* and that other locking primitive structures are
- * not allowed to use such name for their members.
- * If this needs to change, the bits in the rwlock implementation might be
- * modified appropriately.
+ * All reader/writer lock implementations must always have a member
+ * called rw_lock. Other locking primitive structures are not allowed to
+ * use this name for their members.
+ * If this rule needs to change, the bits in the reader/writer lock
+ * implementation must be modified appropriately.
*/
struct rwlock {
struct lock_object lock_object;
@@ -51,12 +50,12 @@ struct rwlock {
/*
* Members of struct rwlock_padalign must mirror members of struct rwlock.
- * rwlock_padalign rwlocks can use rwlock(9) KPI transparently, without
- * modifies.
- * When using pad-aligned rwlocks within structures, they should generally
- * stay as the first member of the struct. This is because otherwise the
- * compiler can generate ever more padding for the struct to keep a correct
- * alignment for the rwlock.
+ * rwlock_padalign rwlocks can use the rwlock(9) API transparently without
+ * modification.
+ * Pad-aligned rwlocks used within structures should generally be the
+ * first member of the struct. Otherwise, the compiler can generate
+ * additional padding for the struct to keep a correct alignment for
+ * the rwlock.
*/
struct rwlock_padalign {
struct lock_object lock_object;
___
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: r242900 - head/usr.bin/calendar/calendars
Author: grog Date: Sun Nov 11 22:43:36 2012 New Revision: 242900 URL: http://svnweb.freebsd.org/changeset/base/242900 Log: Correct date of Stanley's encounter with Livingstone. Obtained from:Henry Morton Stanley, "How I met Livingstone", http://www.gutenberg.org/dirs/5/1/5/5157/5157-h/5157-h.htm MFC after:14 days Modified: head/usr.bin/calendar/calendars/calendar.history Modified: head/usr.bin/calendar/calendars/calendar.history == --- head/usr.bin/calendar/calendars/calendar.historySun Nov 11 21:58:18 2012(r242899) +++ head/usr.bin/calendar/calendars/calendar.historySun Nov 11 22:43:36 2012(r242900) @@ -383,7 +383,6 @@ 10/23 Swallows leave Capistrano 10/25 The UN removes Taiwan and admits the People's Republic of China, 1971 10/26 UN's World Health Organization declares smallpox eradicated, 1978 -10/27 Henry Stanley asks David Livingstone, "Dr. Livingstone, I presume?", 1871 10/27 New York's Boss Tweed is arrested on fraud charges, 1871 10/27 The first New York Subway is opened, 1904 10/28 Columbus discovers Cuba, 1492 @@ -412,6 +411,7 @@ 11/09 Roosevelt establishes the Civil Works Administration, 1933 11/10 41 Women arrested in suffragette demonstrations near White House, 1917 11/10 Cpt. Wirz, commandant of Andersonville Prison hanged, 1865 +11/10 Henry Stanley asks David Livingstone, "Dr. Livingstone, I presume?", 1871 11/11 Washington becomes the 42nd state, 1889 11/12 Dr. Sun Yat-sen's Birthday in Taiwan 11/12 USA first exports oil to Europe, 1861 ___ 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: r242897 - head/release
On Sun, Nov 11, 2012 at 02:25:48PM -0800, Xin Li wrote: > > Log: Prevent including .zfs snapshot directories in the src.txz > > distribution. This can happen if the src/ tree checkout is within > > its own ZFS dataset, and the 'snapdir' ZFS property is set to > > 'visible.' > > Since snapdir=visible is non-standard setting, will it be sensible to > exclude .snap as well? (maybe also .git?) > Yes, I think so. This was mentioned yesterday, but I had already sent this patch for review. I do intend to exclude more dot-dirs. Glen pgpjoQsmG5FKX.pgp Description: PGP signature
Re: svn commit: r242897 - head/release
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/11/12 1:52 PM, Glen Barber wrote:
> Author: gjb (doc,ports committer) Date: Sun Nov 11 21:52:18 2012
> New Revision: 242897 URL:
> http://svnweb.freebsd.org/changeset/base/242897
>
> Log: Prevent including .zfs snapshot directories in the src.txz
> distribution. This can happen if the src/ tree checkout is within
> its own ZFS dataset, and the 'snapdir' ZFS property is set to
> 'visible.'
Since snapdir=visible is non-standard setting, will it be sensible to
exclude .snap as well? (maybe also .git?)
Cheers,
> Approved by: hrs MFC after: 3 days X-MFC-To:stable/9 only
>
> Modified: head/release/Makefile
>
> Modified: head/release/Makefile
> ==
>
>
>
- --- head/release/Makefile Sun Nov 11 15:34:58 2012(r242896)
> +++ head/release/Makefile Sun Nov 11 21:52:18 2012(r242897) @@
> -83,7 +83,7 @@ kernel.txz: src.txz: mkdir -p ${DISTDIR}/usr ln -fs
> ${WORLDDIR} ${DISTDIR}/usr/src - cd ${DISTDIR} && tar cLvJf
> ${.OBJDIR}/src.txz --exclude .svn \ + cd ${DISTDIR} && tar cLvJf
> ${.OBJDIR}/src.txz --exclude .svn --exclude .zfs \ --exclude CVS
> --exclude @ --exclude usr/src/release/dist usr/src
>
> ports.txz:
>
-BEGIN PGP SIGNATURE-
iQEcBAEBCAAGBQJQoCXsAAoJEG80Jeu8UPuzlHQH/iB1qtSH4QcDwxUtIM1gZysI
7xJIcP47dq00W6X9v97p30s149x6VzJP+Ps1zfAt7cgwozTrD5XQGIUcJn/56rUH
4geVwfvkDTK9EqM9yPeederiio+fcSXG9mIQGuW3W345IuUHk9p8wfh6w9rQMKCR
Vor/s9gQ5q5bCb3t6NZ0rAoq1LGs7pWPfU9WckHa/4Ekjw21WziwkiEfOOH4UeJl
z9Di+td1Jd9pzYxh74ZFzEDY4l28/A0Pmmtj0GtNjIFtGJiXGWUgADrSuXozBwPg
7aArwKcoeL/pFsVWhll3IQ/IznMU8BwVLQkDOs5wwSLGqNoKJJvQeNWs+K2f7g4=
=nLZI
-END PGP SIGNATURE-
___
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: r242899 - head/sys/dev/ath
Author: adrian Date: Sun Nov 11 21:58:18 2012 New Revision: 242899 URL: http://svnweb.freebsd.org/changeset/base/242899 Log: Correctly fix the 'scan during STA mode' crash. Modified: head/sys/dev/ath/if_ath.c Modified: head/sys/dev/ath/if_ath.c == --- head/sys/dev/ath/if_ath.c Sun Nov 11 21:57:18 2012(r242898) +++ head/sys/dev/ath/if_ath.c Sun Nov 11 21:58:18 2012(r242899) @@ -5598,6 +5598,13 @@ ath_node_set_tim(struct ieee80211_node * #else struct ath_vap *avp = ATH_VAP(ni->ni_vap); + /* +* Some operating omdes don't set av_set_tim(), so don't +* update it here. +*/ + if (avp->av_set_tim == NULL) + return (0); + return (avp->av_set_tim(ni, enable)); #endif /* ATH_SW_PSQ */ } ___ 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: r242898 - head/sys/dev/ath
Author: adrian Date: Sun Nov 11 21:57:18 2012 New Revision: 242898 URL: http://svnweb.freebsd.org/changeset/base/242898 Log: Remove this; i incorrectly committed the wrong (debug) changes in my previous commit. Modified: head/sys/dev/ath/if_ath_tx.c Modified: head/sys/dev/ath/if_ath_tx.c == --- head/sys/dev/ath/if_ath_tx.cSun Nov 11 21:52:18 2012 (r242897) +++ head/sys/dev/ath/if_ath_tx.cSun Nov 11 21:57:18 2012 (r242898) @@ -1236,8 +1236,6 @@ ath_tx_setds(struct ath_softc *sc, struc struct ath_desc *ds = bf->bf_desc; struct ath_hal *ah = sc->sc_ah; - bzero(bf->bf_desc, sc->sc_tx_desclen * bf->bf_nseg); - ath_hal_setuptxdesc(ah, ds , bf->bf_state.bfs_pktlen /* packet length */ , bf->bf_state.bfs_hdrlen /* header length */ ___ 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: r242897 - head/release
Author: gjb (doc,ports committer)
Date: Sun Nov 11 21:52:18 2012
New Revision: 242897
URL: http://svnweb.freebsd.org/changeset/base/242897
Log:
Prevent including .zfs snapshot directories in the src.txz
distribution. This can happen if the src/ tree checkout is
within its own ZFS dataset, and the 'snapdir' ZFS property
is set to 'visible.'
Approved by: hrs
MFC after:3 days
X-MFC-To: stable/9 only
Modified:
head/release/Makefile
Modified: head/release/Makefile
==
--- head/release/Makefile Sun Nov 11 15:34:58 2012(r242896)
+++ head/release/Makefile Sun Nov 11 21:52:18 2012(r242897)
@@ -83,7 +83,7 @@ kernel.txz:
src.txz:
mkdir -p ${DISTDIR}/usr
ln -fs ${WORLDDIR} ${DISTDIR}/usr/src
- cd ${DISTDIR} && tar cLvJf ${.OBJDIR}/src.txz --exclude .svn \
+ cd ${DISTDIR} && tar cLvJf ${.OBJDIR}/src.txz --exclude .svn --exclude
.zfs \
--exclude CVS --exclude @ --exclude usr/src/release/dist usr/src
ports.txz:
___
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: r242847 - in head/sys: i386/include kern
On 11/11/12 12:31 PM, Adrian Chadd wrote: On 11 November 2012 09:11, Alfred Perlstein wrote: Oh, OK, I didn't know it was so involved. I probably don't have anything to worry about then. :) Nono - I want you to worry about it. But _I_ want there to be a slightly longer term goal that's less about dictating policy in the kernel and more about providing both the flexibility _and_ the feedback so you and others can do this kind of thing in userspace without needing to hack the kernel or recompile. So Alfred - are you up to the challenge? :) Enumerate _every_ thing that maxusers tunes at startup time and make sure it's tunable at run-time? Once that's done, we can turn maxusers into a userland _command_ that can be run _anytime_, and you all can bikeshed over the tuning of _that_ thing until we die from heat death. That way everyone wins. :) adrian Not really, I'm kind of stuck figuring out the following things: 1) why if_lagg doesn't get full bandwidth when in point to point mode. 2) why nfs has regressed with forced unmounts. 3) other critical performance issues wrt nfs,zfs,io. 4) ... other stuff more important. I can't devote any further effort to this maxusers thing, as I see it, I've submitted a fix that is a big step forward for all. If people want to run with this and get excited about it, I am glad. Unfortunately just because I found a light switch and turned it on, doesn't suddenly mean that I owe the community a fancy new vanity installed. After all, it is just a toilet, now that I don't have to worry about everyone pissing all over the seat, my job is done. There are more important goals. I'm not playing the "you touched it, it's your responsibility game" any longer. this is why no one has bothered to fix it, because the community feels that it is ok to saddle someone making a small incremental change with an impossibly hard halting problem of nonsense. So, yeah feel free to install that vanity, but don't make me sorry I flipped a switch. This is why we all carry flashlights around (our personal sysctl.conf), because we're afraid of this community reaction and wonder why there's piss on the seat. I think Bruce said it best: But don't ask alfred to fix all the old mistakes. This will be my last email on this issue. -Alfred ___ 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: r242847 - in head/sys: i386/include kern
On 11 November 2012 09:11, Alfred Perlstein wrote: > Oh, OK, I didn't know it was so involved. I probably don't have anything to > worry about then. :) Nono - I want you to worry about it. But _I_ want there to be a slightly longer term goal that's less about dictating policy in the kernel and more about providing both the flexibility _and_ the feedback so you and others can do this kind of thing in userspace without needing to hack the kernel or recompile. So Alfred - are you up to the challenge? :) Enumerate _every_ thing that maxusers tunes at startup time and make sure it's tunable at run-time? Once that's done, we can turn maxusers into a userland _command_ that can be run _anytime_, and you all can bikeshed over the tuning of _that_ thing until we die from heat death. That way everyone wins. :) adrian ___ 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: r242849 - head/usr.bin/calendar/calendars
The date of the encounter is not clear at all. Some sources list oct. 27, some oct. 28, and some nov. 10 (http://en.wikipedia.org/wiki/Henry_Morton_Stanley). So this should be researched a bit more. ___ 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: r242889 - head/sys/dev/xen/netback
On Sun, Nov 11, 2012 at 10:42:34AM +, Roman Divacky wrote:
> Author: rdivacky
> Date: Sun Nov 11 10:42:34 2012
> New Revision: 242889
> URL: http://svnweb.freebsd.org/changeset/base/242889
>
> Log:
> Change the XNB_ASSERT from a statement expression to do-while(0) as its
> result is never used.
>
> Modified:
> head/sys/dev/xen/netback/netback_unit_tests.c
>
> Modified: head/sys/dev/xen/netback/netback_unit_tests.c
> ==
> --- head/sys/dev/xen/netback/netback_unit_tests.c Sun Nov 11 08:22:58
> 2012(r242888)
> +++ head/sys/dev/xen/netback/netback_unit_tests.c Sun Nov 11 10:42:34
> 2012(r242889)
> @@ -62,7 +62,7 @@ __FBSDID("$FreeBSD$");
> * iff the assertion failed. Note the implied parameters buffer and
> * buflen
> */
> -#define XNB_ASSERT(cond) ({
> \
> +#define XNB_ASSERT(cond) do (
> \
> int passed = (cond);\
> char *_buffer = (buffer); \
> size_t _buflen = (buflen); \
> @@ -71,7 +71,7 @@ __FBSDID("$FreeBSD$");
> strlcat(_buffer, ":" TOSTRING(__LINE__) \
> " Assertion Error: " #cond "\n", _buflen);\
> } \
> - ! passed; })
> + } while (0)
>
>
> /**
Look at r240747.
pgpxokdAt5sJz.pgp
Description: PGP signature
Re: svn commit: r242835 - head/contrib/llvm/lib/Target/X86
On Mon, Nov 12, 2012 at 02:01:47AM +1100, Bruce Evans wrote: > On Sun, 11 Nov 2012, Dimitry Andric wrote: > > > On 2012-11-11 12:53, Bruce Evans wrote: > >> > >> I'm not sure if either of us knows exactly what this does, but I like > >> this change. clang does stack alignment correctly, so it doesn't need > >> the gcc pessimization of aligning in the caller. clang aligns in the > > Apparently we did know. > > >> ... > >> alignment. gcc's alignment in callers doesn't even work, because gcc > >> assumes that it is enough and never does it in callees even when it > >> is necessary: > >> > >>auto int32_t foo[8] __aligned[32]; > >> > >> gcc fails to do the necessary alignment. clang does it. > >> > >>auto int32_t foo[8] __aligned[16]; > >> > >> Both gcc and (hopefully only without the above fix) clang fail to do the > >> necessary alignment. > > > > It works just fine now with clang. For the first example, I get: > > > >pushl %ebp > >movl%esp, %ebp > >andl$-32, %esp > > > > as prolog, and for the second: > > > >pushl %ebp > >movl%esp, %ebp > >andl$-16, %esp > > Good. > > The andl executes very fast. Perhaps not as fast as subl on %esp, > because subl is normal so more likely to be optimized (they nominally > have the same speeds, but %esp is magic). Unfortunately, it seems to > be impossible to both align the stack and reserve some space on it in > 1 instruction -- the andl might not reserve any. I think the biggest hit from the andl instruction is due to the spoiling of the stack engine presented on all Intel processors starting from Pentium Pro. Most likely, predictor cannot handle such change of %esp without throwing the hands up. > > >> special alignment in main(), but assumes that crtso did it. clang also > >> doesn't support -mpreferred-stack-boundary, so it is incompatible with > >> nonstandard ABI's like the one given by always using > >> -mpreferred-stack-boundary=32. > > > > Apparently upstream never saw the need for this option. I strongly > > doubt it is used very often outside FreeBSD... > > It is most useful for working around gcc's behaviour. Hmm, the kernel > and boot blocks uses -mpreferred-stack-boundary=2 on i386 to save space. > This must have been turned off for clang, so the versions that did > 16-bit alignment must have come close to blowing the kernel stack. In > boot blocks, I think there is plenty of stack but alignment wastes code > space. > > I'd like to try -mpreferred-stack-boundary=3 in amd64 kernels, but this > is an i386-only option. > > >> Yes, we need clang/our libraries to handle different alignments and > >> not assume that callers do more than the ABI requires and pessimize > >> on behalf of the libraries. Outside of libraries, the problem is small > >> provided -mpreferred-stack-boundary works, since you can compile > >> everything with the same -mpreferred-stack-boundary. > > > > As far as I can see, with the 4 byte stack alignment that has been the > > default, and is now also clang's default, our libraries should handle > > any "incoming" stack alignment of >= 4 bytes. I don't think anybody > > uses lower stack alignment, except maybe for the special case of boot > > loaders, or extremely size-optimized code. The i386 ABI requires 4 byte alignment, but does not require any larger. I do not see how can we even pretend to support stable ABI while allowing such gratitious changes. > > -Os could reasonably generate lower stack alignment, but that rarely > saves space. -Os generally doesn't give enough control over alignment > for space-time tradeoffs. I made some minor changes in FreeBSD's gcc > to make it _not_ give misaligned 32-bit variables (?) since -Os should > only optimize for space if it doesn't cost much time for small savings > in space. But if you only care about space, it would be useful to > minimize the alignment of everything. > > Bruce pgpytk4oJIvrn.pgp Description: PGP signature
Re: svn commit: r242881 - head/sys/dev/ath
Damnit, I commited the wrong file. I meant if_ath.c instead of if_ath_tx.c. Thanks for pointing it out. Adrian On 10 November 2012 16:34, Adrian Chadd wrote: > Author: adrian > Date: Sun Nov 11 00:34:10 2012 > New Revision: 242881 > URL: http://svnweb.freebsd.org/changeset/base/242881 > > Log: > Don't call av_set_tim() if it's NULL. > > This happens during a scan in STA mode; any queued data frames will > be power save queued but as there's no TIM in STA mode, it panics. > > This was introduced by me when I disabled my driver-aware power save > handling support. > > Modified: > head/sys/dev/ath/if_ath_tx.c > > Modified: head/sys/dev/ath/if_ath_tx.c > == > --- head/sys/dev/ath/if_ath_tx.cSat Nov 10 22:37:06 2012 > (r242880) > +++ head/sys/dev/ath/if_ath_tx.cSun Nov 11 00:34:10 2012 > (r242881) > @@ -1236,6 +1236,8 @@ ath_tx_setds(struct ath_softc *sc, struc > struct ath_desc *ds = bf->bf_desc; > struct ath_hal *ah = sc->sc_ah; > > + bzero(bf->bf_desc, sc->sc_tx_desclen * bf->bf_nseg); > + > ath_hal_setuptxdesc(ah, ds > , bf->bf_state.bfs_pktlen /* packet length */ > , bf->bf_state.bfs_hdrlen /* header length */ ___ 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: r242847 - in head/sys: i386/include kern
Oh, OK, I didn't know it was so involved. I probably don't have anything to worry about then. :) -Alfred On 11/11/12 8:52 AM, Adrian Chadd wrote: Alfred, You're thinking about it one step ahead, not 5 steps ahead. One step ahead: "let's fix maxuser scaling." 5 steps ahead: "Let's find all of the non-dynamic things that maxusers scales, figure out how to make them run-time tunable, and then make a maxusers.sh user-land script that scales these values when you type 'maxusers 512'." Then you can fiddle in userland in your hearts content with how to scale these things. The only recent time I've seen the need for ridiculously large non-default values for mbuf clusters is for one of the 10ge NICs that preallocates them at device startup time, and fails to attach right if they're not all available. With everything dynamically tunable and the maxusers script in userland, you can: * fondle the curves as you want; * export usage stats for all the things that the above tuning does affect (which you've been doing with netstat and mbuf allocation hangs, thankyou!) * start looking at providing much better inspection and auto-tuning tools, which allow the sysadmin to actually start controlling what spirally death their server decides to visit, versus just "spirally death." Adrian ___ 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: r242879 - in head/lib: libc/gen msun/src
On Sun, 11 Nov 2012, Dimitry Andric wrote:
On 2012-11-11 14:07, Bruce Evans wrote:
...
The pessimality of these functions is another problem. C99 only requires
...
- if you compile isnan*(x) calls using gcc _without_ including ,
then you get annoying (and broken) warnings about implicit function
declarations being invalid in C99. This is a bug in clang. These
functions are reserved in C99, so some other warning for them would
be correct, but things warning is wrong in several ways:
- implicit function declarations are not invalid in C9
Implicit function declarations are invalid in C99, not in C89. Clang
defaults to C99. Whether the function is reserved or not, should not
matter.
- the same warning is printed for -ffreestanding, but these functions
are not reserved by C99 then.
Again, I don't agree. Reserved or not is not relevant. If the above
reasoning was followed, we would never have to include either,
because all those prototypes would already be implicitly there? :-)
Oops, I thought it was removed later.
After turning off the broken warning using
-Wno-implicit-function-declarations, everything works right for these
function calls, but of course not for others for which you want this
warning.
So for clang you must include for calling these functions,
No, according to the C99 standard you must include . Quoting
7.12.3.4:
Synopsis:
#include
int isnan(real-floating x);
The synopses of all math functions explicitly have the the #include at
the top.
Except with -ffreestanding, isnan() is not reserved and might not
exist. gcc and clang handle this correctly by not converting isnan*()
into a builtin.
[... isnan() gets turned into an extern function that bypasses better
builtins]
In short, maybe just:
#define isnan __builtin_isnan
? That should cover all cases. With a fallback for !gcc && !clang,
obviously. The functions stay behind for backwards compatibility.
This fails for gcc-3.3.3 which I test on (gcc-3.3.3 produces better
libm code in some cases).
Fixing the pessimizations would reduce the ABI problems. Both libc
and libm should translate to the builtin if it exists and is a real
builtin (not a libcall). This seems reasonable even without -O, since
C99 doesn't require any functions to exist so nothing should take their
addresses or try to call them as non-macros ('(isnan)(x)').
already has complications to use builtins for 1 set of interfaces only.
The only problems are that it is that it is hard to tell if builtins
exist and are real (there are compiler predefines for the set that
uses builtins but not for most sets).
How is it hard to tell? Both gcc and clang support those builtins,
unless you want to support very old versions of gcc, which might not
have them.
It is easy to hard-code ifdefs on the compiler name, but only for
a couple of compiler/version combinations, and this is ugly. Then
there is the problem that some builtins just gives libcalls so they
are useless. In general, whether a builtin gives a libcall is MD.
__builtin_fma() should be an example. It should give hardware fma
on ia64 but doesn't. It should give hardware fma on any future x86
that has fma. Currently it always gives a libcall so it is useless.
With this, the library functions are never used by new compiles and
are only needed by old applications. All static copies of them can
be removed, but the .so ones are still needed until the ABI is changed.
When will the library isnanf() have been deprecated long enough to
remove in .so's too? Maybe it never needed to be preserved, since
old applications will link to old libraries that have it.
I don't think we can ever remove them from libc.so anymore, unless
version bumps are reintroduced. :-)
Sigh, the version has been bumped twice since isnanf() was deprecated.
First from 5 to 6 in 2004 just 3 months days after the deprecation. Then
from 6 to 7 in 2006. The log message says that isnan() and others are
done in the "hard" way instead of relying on fpclassify(), for binary
compatibility since we have never bumpled libm's major number, but that
has also been bumped twice since the deprecation.
Using fpclassify() would actually be the hard way for isnan(), since
there is no builtin for it. Of the functions referred to in the log
message, isinf() is easy using its builtin and isfinite() and isnormal()
are "hard" since they don't have a builtin in gcc.
Summary of the libm builtins:
- isnan(): good but not always used
- isinf(): like isnan()
- isfinite(): only in clang (I don't know if it is more than a libcall)
- isnormal(): like isfinite()
- signbit(): like isnan()
- significand(): only in gcc, and seems to be just a libcall. This one
is a nonstandard old-IEEE API while the others are C99.
- fma(): builtin but useless since it is always (?) a libcall.
- sin(), cos(), ...: only in clang, and useless since they are libcalls at
best. clang seems to have builtins
Re: svn commit: r242847 - in head/sys: i386/include kern
I think there are two issue here. One: you have much better idea of how to tune nmbclusters than I do. Cool! Please put that into the code. I really think that's great and the time you've pit into giving it serious thought is helpful to all. Two: you want to divorce nmbclusters (and therefor maxsockets and some other tunables) from maxusers even though that has been the way to flip a big switch for ages now. This is think is very wrong. "oh you only have to change 1 thing!" Wait... What was that sound? Oh it was the flushing of a toilet that was flushing down 15 years of mailing list information, FAQs and user knowledge down the toilet because the word "maxusers" is no longer hip to the community. That is bad. Please don't do that. On Nov 11, 2012, at 2:53 AM, Peter Wemm wrote: > On Sun, Nov 11, 2012 at 1:41 AM, Albert Perlstein wrote: >> The real conversation goes like this: >> >> user: "Why is my box seeing terrible network performance?" >> bsdguy: "Increase nmbclusters." >> user: "what is that?" >> bsdguy: "Oh those are the mbufs, just tell me your current value." >> user: "oh it's like 128000" >> bsdguy: "hmm try doubling that, go sysctl kern.ipc.nmbclusters=512000 on the >> command line." >> user: "ok" >> an hour passes ... >> user: "hmm now I can't fork any more copies of apache.." >> bsdguy: "oh, ok, you need to increase maxproc for that." >> user: "so sysctl kern.ipc.maxproc=1?" >> bsdguy: "no... one second..." >> >> bsdguy: "ok, so that's sysctl kern.maxproc=1" >> user: "ok... bbiaf" >> >> user: "so now i'm getting log messages about can't open sockets..." >> bsdguy: "oh you need to increase sockets bro... one second..." >> user: "sysctl kern.maxsockets?" >> bsdguy: "oh no.. it's actually back to kern.ipc.maxsockets" >> user: "alrighty then.." >> >> >> bsdguy: "so how is freebsd since I helped you tune it?" >> user: "well i kept hitting other resource limits, boss made me switch to >> Linux, it works out of the box and doesn't require an expert tuner to run a >> large scale server. Y'know as a last ditch effort I looked around for this >> 'maxusers' thing but it seems like some eggheads retired it and instead of >> putting my job at risk, I just went with Linux, no one gets fired for using >> Linux." >> bsdguy: "managers are lame!" >> user: "yeah! managers..." >> >> -Alfred > > Now Albert.. I know that deliberately playing dumb is fun, but there > is no network difference between doubling "kern.maxusers" in > loader.conf (the only place it can be set, it isn't runtime tuneable) > and doubling "kern.ipc.nmbclusters" in the same place. We've always > allowed people to fine-tune derived settings at runtime where it is > possible. > > My position still is that instead of trying to dick around with > maxusers curve slopes to try and somehow get the scaling right, we > should instead be setting sensibly right from the start, by default. > > The current scaling was written when we had severe kva constraints, > did reservations, etc. Now they're a cap on dynamic allocators on > most platforms. > > "Sensible" defaults would be *way* higher than the current maxusers > derived scaling curves. > > My quick survey: > 8G ram -> 65088 clusters -> clusters capped at 6.2% of physical ram > (running head) > 3.5G ram -> 25600 clusters -> clusters capped at 5.0% of physical ram > (running an old head) > 32G ram -> 25600 clusters -> clusters capped at 1.5% of physical ram > (running 9.1-stable) > 72G ram -> 25600 clusters -> clusters capped at 0.06% of physical ram > (9.1-stable again) > > As I've been saying from the beginning.. As these are limits on > dynamic allocators, not reservations, they should be as high as we can > comfortably set them without risking running out of other resources. > > As the code stands now.. the derived limits for 4k, 9k and 16k jumbo > clusters is approximately the same space as 2K clusters. (ie: 1 x 4k > cluster per 2 x 2k clusters, 1 x 16k cluster per 8 2k clusters, and so > on). If we set a constant 6% for nmbclusters (since that's roughly > where we're at now for smaller machines after albert's changes), then > the worse case scenarios for 4k, 9k and 16k clusters are 6% each. ie: > 24% of wired, physical ram. > > Plus all the other values derived from the nmbclusters tunable at boot. > > I started writing this with the intention of suggesting 10% but that > might be a bit high given that: > kern_mbuf.c:nmbjumbop = nmbclusters / 2; > kern_mbuf.c:nmbjumbo9 = nmbclusters / 4; > kern_mbuf.c:nmbjumbo16 = nmbclusters / 8; > .. basically quadruples the worst case limits. > > Out of the box, 6% is infinitely better than we 0.06% we currently get > on a 9-stable machine with 72G ram. > > But I object to dicking around with "maxusers" to derive network > buffer space default limits. If we settle on something like 6%, then > it should be 6%. That's easy to document and explain the meaning of
Re: svn commit: r242881 - head/sys/dev/ath
On 11 November 2012 08:39, Adrian Chadd wrote: > Damnit, I commited the wrong file. I meant if_ath.c instead of if_ath_tx.c. > > Thanks for pointing it out. I'll commit the fix when svn.freebsd.org works again. Adrian ___ 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: r242847 - in head/sys: i386/include kern
Alfred, You're thinking about it one step ahead, not 5 steps ahead. One step ahead: "let's fix maxuser scaling." 5 steps ahead: "Let's find all of the non-dynamic things that maxusers scales, figure out how to make them run-time tunable, and then make a maxusers.sh user-land script that scales these values when you type 'maxusers 512'." Then you can fiddle in userland in your hearts content with how to scale these things. The only recent time I've seen the need for ridiculously large non-default values for mbuf clusters is for one of the 10ge NICs that preallocates them at device startup time, and fails to attach right if they're not all available. With everything dynamically tunable and the maxusers script in userland, you can: * fondle the curves as you want; * export usage stats for all the things that the above tuning does affect (which you've been doing with netstat and mbuf allocation hangs, thankyou!) * start looking at providing much better inspection and auto-tuning tools, which allow the sysadmin to actually start controlling what spirally death their server decides to visit, versus just "spirally death." Adrian ___ 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: r242896 - head/usr.bin/ssh-copy-id
Author: eadler Date: Sun Nov 11 15:34:58 2012 New Revision: 242896 URL: http://svnweb.freebsd.org/changeset/base/242896 Log: Add the standard exit status to the ssh-copy-id man page. Approved by: bcr (mentor) MFC after:3 days Modified: head/usr.bin/ssh-copy-id/ssh-copy-id.1 Modified: head/usr.bin/ssh-copy-id/ssh-copy-id.1 == --- head/usr.bin/ssh-copy-id/ssh-copy-id.1 Sun Nov 11 15:13:24 2012 (r242895) +++ head/usr.bin/ssh-copy-id/ssh-copy-id.1 Sun Nov 11 15:34:58 2012 (r242896) @@ -25,7 +25,7 @@ .\" .\" $FreeBSD$ .\" -.Dd October 3, 2012 +.Dd November 11, 2012 .Dt SSH-COPY-ID 1 .Os .Sh NAME @@ -71,6 +71,8 @@ default. .Pp The remaining arguments are a list of remote hosts to connect to, each one optionally qualified by a user name. +.Sh EXIT STATUS +.Ex -std .Sh HISTORY The .Nm ___ 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: r242895 - head/bin/sh
Author: jilles
Date: Sun Nov 11 15:13:24 2012
New Revision: 242895
URL: http://svnweb.freebsd.org/changeset/base/242895
Log:
sh: Forward-declare struct alias instead of giving up type safety via void *
Modified:
head/bin/sh/input.c
head/bin/sh/input.h
Modified: head/bin/sh/input.c
==
--- head/bin/sh/input.c Sun Nov 11 13:28:04 2012(r242894)
+++ head/bin/sh/input.c Sun Nov 11 15:13:24 2012(r242895)
@@ -350,7 +350,7 @@ pungetc(void)
* We handle aliases this way.
*/
void
-pushstring(char *s, int len, void *ap)
+pushstring(char *s, int len, struct alias *ap)
{
struct strpush *sp;
@@ -365,9 +365,9 @@ pushstring(char *s, int len, void *ap)
sp->prevstring = parsenextc;
sp->prevnleft = parsenleft;
sp->prevlleft = parselleft;
- sp->ap = (struct alias *)ap;
+ sp->ap = ap;
if (ap)
- ((struct alias *)ap)->flag |= ALIASINUSE;
+ ap->flag |= ALIASINUSE;
parsenextc = s;
parsenleft = len;
INTON;
Modified: head/bin/sh/input.h
==
--- head/bin/sh/input.h Sun Nov 11 13:28:04 2012(r242894)
+++ head/bin/sh/input.h Sun Nov 11 15:13:24 2012(r242895)
@@ -45,6 +45,7 @@ extern int parsenleft;/* number of cha
extern char *parsenextc; /* next character in input buffer */
extern int init_editline; /* 0 == not setup, 1 == OK, -1 == failed */
+struct alias;
struct parsefile;
char *pfgets(char *, int);
@@ -52,7 +53,7 @@ int pgetc(void);
int preadbuffer(void);
int preadateof(void);
void pungetc(void);
-void pushstring(char *, int, void *);
+void pushstring(char *, int, struct alias *);
void setinputfile(const char *, int);
void setinputfd(int, int);
void setinputstring(char *, int);
___
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: r242879 - in head/lib: libc/gen msun/src
On 2012-11-11 14:07, Bruce Evans wrote: On Sat, 10 Nov 2012, Dimitry Andric wrote: On 2012-11-10 22:43, Konstantin Belousov wrote: On Sat, Nov 10, 2012 at 09:22:10PM +, Dimitry Andric wrote: ... Author: dim Date: Sat Nov 10 21:22:10 2012 New Revision: 242879 URL: http://svnweb.freebsd.org/changeset/base/242879 Log: Only define isnan, isnanf, __isnan and __isnanf in libc.so, not in libc.a and libc_p.a. In addition, define isnan in libm.a and libm_p.a, but not in libm.so. This makes it possible to statically link executables using both isnan and isnanf with libc and libm. ... So you broke ABI for libm ? No, both libc.so and libm.so are the same as before. Only the .a files are changed. I should probably have made the commit message more clear, sorry about that. Hopefully "fixed" instead of "broke" (except the .so files are unchanged so they are still broken). I use the hack of ifdefing out the definition of __isnanf() in libm. isnan() is already ifdefed out there. I didn't touch the compatibility cruft weak references to isnanf() there -- libc has it too, so it is not needed any more than isnan() here. The pessimality of these functions is another problem. C99 only requires the isnan() API, and only requires it to be a macro. gcc-4.2.1 and clang (but not gcc-3.3.3 which I often test with) provide good builtins for these functions. But the FreeBSD implementation destroys use of the builtins with some help from the ABI: - if you compile isnan*(x) calls using gcc _without_ including , then everything works right -- they builtins are used and are optimal - if you compile isnan*(x) calls using gcc _without_ including , then you get annoying (and broken) warnings about implicit function declarations being invalid in C99. This is a bug in clang. These functions are reserved in C99, so some other warning for them would be correct, but things warning is wrong in several ways: - implicit function declarations are not invalid in C9 Implicit function declarations are invalid in C99, not in C89. Clang defaults to C99. Whether the function is reserved or not, should not matter. - the same warning is printed for -ffreestanding, but these functions are not reserved by C99 then. Again, I don't agree. Reserved or not is not relevant. If the above reasoning was followed, we would never have to include either, because all those prototypes would already be implicitly there? :-) After turning off the broken warning using -Wno-implicit-function-declarations, everything works right for these function calls, but of course not for others for which you want this warning. So for clang you must include for calling these functions, No, according to the C99 standard you must include . Quoting 7.12.3.4: Synopsis: #include int isnan(real-floating x); The synopses of all math functions explicitly have the the #include at the top. and of course for other FP library features, omitting the include is even more impractical. This gives the pessimizations: - the isnan() macro translates to isnan() for doubles, __isnanf() for floats and __isnanfl() for long doubles. The null translation for doubles gives the builtin and it works as above, but the other translations give the library functions with their underscored spelling. Compilers don't understand this spelling, so they don't give the builtins. So isnan() is pessimized when applied to floats and long doubles. Yes, this is rather unfortunate. Though I originally assumed that the libm authors found all the compiler builtins inferior in some way, and therefore supplied their own implementations. :-) OTOH, if you forget that isnan() is type-generic and spell it isnanf() or isnanl(), then the float and long double cases mostly work right again: - same behaviour if is not included (and -O is used) - if is included, then it declares isnanf() but not isnanl(), since only the former is compatibility cruft and has an extern function. So isnanf() always works and the builtin is always used with -O and and the extern function is used without -O. But isnanl() causes the following problems: - -Wimplicit* warning - linkage failure without -O. Another problem is that the extern __isnanl() is broken on x86, but the builtin works. The extern functions do bit tests that are rather slow but not slow enough to be correct (they don't check for pseudo-numbers which the hardware treats as NaNs), but the builtin does a simple x != x test which is probably optimal, and works. Similarly for some other macros (they convert to spelling that compilers don't understand, and at least the classification macros are broken on psudo-numbers, but now the broken cases are mostly ones for which the builtins don't exist or is broken). In short, maybe just: #define isnan __builtin_isnan ? That should cover all cases. With a fallback for
Re: svn commit: r242835 - head/contrib/llvm/lib/Target/X86
On Sun, 11 Nov 2012, Dimitry Andric wrote: On 2012-11-11 12:53, Bruce Evans wrote: I'm not sure if either of us knows exactly what this does, but I like this change. clang does stack alignment correctly, so it doesn't need the gcc pessimization of aligning in the caller. clang aligns in the Apparently we did know. ... alignment. gcc's alignment in callers doesn't even work, because gcc assumes that it is enough and never does it in callees even when it is necessary: auto int32_t foo[8] __aligned[32]; gcc fails to do the necessary alignment. clang does it. auto int32_t foo[8] __aligned[16]; Both gcc and (hopefully only without the above fix) clang fail to do the necessary alignment. It works just fine now with clang. For the first example, I get: pushl %ebp movl%esp, %ebp andl$-32, %esp as prolog, and for the second: pushl %ebp movl%esp, %ebp andl$-16, %esp Good. The andl executes very fast. Perhaps not as fast as subl on %esp, because subl is normal so more likely to be optimized (they nominally have the same speeds, but %esp is magic). Unfortunately, it seems to be impossible to both align the stack and reserve some space on it in 1 instruction -- the andl might not reserve any. special alignment in main(), but assumes that crtso did it. clang also doesn't support -mpreferred-stack-boundary, so it is incompatible with nonstandard ABI's like the one given by always using -mpreferred-stack-boundary=32. Apparently upstream never saw the need for this option. I strongly doubt it is used very often outside FreeBSD... It is most useful for working around gcc's behaviour. Hmm, the kernel and boot blocks uses -mpreferred-stack-boundary=2 on i386 to save space. This must have been turned off for clang, so the versions that did 16-bit alignment must have come close to blowing the kernel stack. In boot blocks, I think there is plenty of stack but alignment wastes code space. I'd like to try -mpreferred-stack-boundary=3 in amd64 kernels, but this is an i386-only option. Yes, we need clang/our libraries to handle different alignments and not assume that callers do more than the ABI requires and pessimize on behalf of the libraries. Outside of libraries, the problem is small provided -mpreferred-stack-boundary works, since you can compile everything with the same -mpreferred-stack-boundary. As far as I can see, with the 4 byte stack alignment that has been the default, and is now also clang's default, our libraries should handle any "incoming" stack alignment of >= 4 bytes. I don't think anybody uses lower stack alignment, except maybe for the special case of boot loaders, or extremely size-optimized code. -Os could reasonably generate lower stack alignment, but that rarely saves space. -Os generally doesn't give enough control over alignment for space-time tradeoffs. I made some minor changes in FreeBSD's gcc to make it _not_ give misaligned 32-bit variables (?) since -Os should only optimize for space if it doesn't cost much time for small savings in space. But if you only care about space, it would be useful to minimize the alignment of everything. 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: r242835 - head/contrib/llvm/lib/Target/X86
On 2012-11-11 12:53, Bruce Evans wrote: On Sat, 10 Nov 2012, Nathan Whitehorn wrote: On 11/09/12 12:56, Dimitry Andric wrote: Log: Reduce LLVM's default stack alignment for i386 from 16 to 4 bytes, as the FreeBSD ABI requires. This is essentially a revert of upstream llvm commit r126226, and it will be reverted by upstream too. MFC after: 1 week ... I'd like to object to this. We have an identical ABI to Linux (and Solaris, as far as I know). Splitting this by platform will only propagate the stack alignment breakage further -- what we need is LLVM/our C library to handle different alignments. Please fix this for real instead of balkanizing the ABI support in LLVM and introducing different ABIs for LLVM and GCC to FreeBSD. I'm not sure if either of us knows exactly what this does, but I like this change. clang does stack alignment correctly, so it doesn't need the gcc pessimization of aligning in the caller. clang aligns in the callee if necessary (except if is lied to about the ABI, then it doesn't know what is necessaary). It is rarely necessary, since most variables are 32 bits or smaller. (Necessary includes when an alignment attribute says so and for optimal alignment of long longs and doubles. The i386 ABI doesn't require alignment for the latter, but optimization doesn't, and when the variables aren't in structs the ABI doesn't prevent them being aligned for optimization.) Always aligning in the caller wastes an average of not quite 8 bytes of stack and cache space per function call, plus sometimes an extra instruction or 2 to do the unnecessary alignment. gcc's alignment in callers doesn't even work, because gcc assumes that it is enough and never does it in callees even when it is necessary: auto int32_t foo[8] __aligned[32]; gcc fails to do the necessary alignment. clang does it. auto int32_t foo[8] __aligned[16]; Both gcc and (hopefully only without the above fix) clang fail to do the necessary alignment. It works just fine now with clang. For the first example, I get: pushl %ebp movl%esp, %ebp andl$-32, %esp as prolog, and for the second: pushl %ebp movl%esp, %ebp andl$-16, %esp The ABI doesn't require the stack to be 16-byte aligned, so alignment is necessary (unless -mpreferred-stack-boundary was used to explictly modify the ABI). gcc only aligns the stack in main(), only to the alignment specified by -mpreferred-stack-boundary, and laboriously passes it down to all functions. clang doesn't do any special alignment in main(), but assumes that crtso did it. clang also doesn't support -mpreferred-stack-boundary, so it is incompatible with nonstandard ABI's like the one given by always using -mpreferred-stack-boundary=32. Apparently upstream never saw the need for this option. I strongly doubt it is used very often outside FreeBSD... ... as far as I know). Splitting this by platform will only propagate the stack alignment breakage further -- what we need is LLVM/our C library to handle different alignments. Please fix this for real instead of balkanizing the ABI support in LLVM and introducing different ABIs for LLVM and GCC to FreeBSD. Yes, we need clang/our libraries to handle different alignments and not assume that callers do more than the ABI requires and pessimize on behalf of the libraries. Outside of libraries, the problem is small provided -mpreferred-stack-boundary works, since you can compile everything with the same -mpreferred-stack-boundary. As far as I can see, with the 4 byte stack alignment that has been the default, and is now also clang's default, our libraries should handle any "incoming" stack alignment of >= 4 bytes. I don't think anybody uses lower stack alignment, except maybe for the special case of boot loaders, or extremely size-optimized code. ___ 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: r242835 - head/contrib/llvm/lib/Target/X86
On 2012-11-11 05:33, Nathan Whitehorn wrote: On 11/09/12 12:56, Dimitry Andric wrote: Author: dim Date: Fri Nov 9 18:56:27 2012 New Revision: 242835 URL: http://svnweb.freebsd.org/changeset/base/242835 Log: Reduce LLVM's default stack alignment for i386 from 16 to 4 bytes, as the FreeBSD ABI requires. This is essentially a revert of upstream llvm commit r126226, and it will be reverted by upstream too. ... I'd like to object to this. We have an identical ABI to Linux (and Solaris, as far as I know). Apparently Linux has standardized on 16-byte stack alignment for 32-bit x86, somewhere in the past. That is, it seems they were forced to do so by the gcc maintainers. Please read: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496 for all the details. Splitting this by platform will only propagate the stack alignment breakage further Apparently, that breakage seems to have existed since the beginning. I don't think it can be fixed anymore; it is probably better to migrate to x86_64 anyway, and repeat all the mistakes of the past once again. :-) -- what we need is LLVM/our C library to handle different alignments. It seems like we need this for all our 32-bit x86 executables and shared libraries, not only our system libraries. At least, that is what I have been told. Please fix this for real instead of balkanizing the ABI support in LLVM and introducing different ABIs for LLVM and GCC to FreeBSD. The balkanization was already there, since FreeBSD's ABI for 32-bit x86 executables has always used 4 byte stack alignment. If anything, Linux is the cause of the balkanization, since they switched from 4 to 16 byte alignment somewhere along the road, and purposefully (or accidentally) lost backwards compatibility. If anything, we should probably send patches to upstream gcc to make them aware of FreeBSD's specific stack alignment, if they are using 16 byte stack alignment now. ___ 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: r242894 - head/lib/libc/gen
Author: dim Date: Sun Nov 11 13:28:04 2012 New Revision: 242894 URL: http://svnweb.freebsd.org/changeset/base/242894 Log: Add an explanatory comment to lib/libc/gen/isnan.c about the fix to make static linking with libc and libm work. Requested by: jilles MFC after:1 week X-MFC-With: 242879 Modified: head/lib/libc/gen/isnan.c Modified: head/lib/libc/gen/isnan.c == --- head/lib/libc/gen/isnan.c Sun Nov 11 12:21:51 2012(r242893) +++ head/lib/libc/gen/isnan.c Sun Nov 11 13:28:04 2012(r242894) @@ -33,6 +33,11 @@ /* * XXX These routines belong in libm, but they must remain in libc for * binary compat until we can bump libm's major version number. + * + * Note this only applies to the dynamic versions of libm and libc, so + * for the static and profiled versions we stub out the definitions. + * Otherwise you cannot link statically to libm and libc at the same + * time, when calling both functions. */ #ifdef PIC ___ 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: r242879 - in head/lib: libc/gen msun/src
On Sat, 10 Nov 2012, Dimitry Andric wrote:
On 2012-11-10 22:43, Konstantin Belousov wrote:
On Sat, Nov 10, 2012 at 09:22:10PM +, Dimitry Andric wrote:
...
Author: dim
Date: Sat Nov 10 21:22:10 2012
New Revision: 242879
URL: http://svnweb.freebsd.org/changeset/base/242879
Log:
Only define isnan, isnanf, __isnan and __isnanf in libc.so, not in
libc.a and libc_p.a. In addition, define isnan in libm.a and libm_p.a,
but not in libm.so.
This makes it possible to statically link executables using both isnan
and isnanf with libc and libm.
...
So you broke ABI for libm ?
No, both libc.so and libm.so are the same as before. Only the .a files
are changed.
I should probably have made the commit message more clear, sorry about
that.
Hopefully "fixed" instead of "broke" (except the .so files are unchanged
so they are still broken). I use the hack of ifdefing out the definition
of __isnanf() in libm. isnan() is already ifdefed out there. I didn't
touch the compatibility cruft weak references to isnanf() there -- libc
has it too, so it is not needed any more than isnan() here.
The pessimality of these functions is another problem. C99 only requires
the isnan() API, and only requires it to be a macro. gcc-4.2.1 and clang
(but not gcc-3.3.3 which I often test with) provide good builtins for
these functions. But the FreeBSD implementation destroys use of the
builtins with some help from the ABI:
- if you compile isnan*(x) calls using gcc _without_ including ,
then everything works right -- they builtins are used and are optimal
- if you compile isnan*(x) calls using gcc _without_ including ,
then you get annoying (and broken) warnings about implicit function
declarations being invalid in C99. This is a bug in clang. These
functions are reserved in C99, so some other warning for them would
be correct, but things warning is wrong in several ways:
- implicit function declarations are not invalid in C9
- the same warning is printed for -ffreestanding, but these functions
are not reserved by C99 then.
After turning off the broken warning using
-Wno-implicit-function-declarations, everything works right for these
function calls, but of course not for others for which you want this
warning.
So for clang you must include for calling these functions, and
of course for other FP library features, omitting the include is even
more impractical. This gives the pessimizations:
- the isnan() macro translates to isnan() for doubles, __isnanf() for
floats and __isnanfl() for long doubles. The null translation for
doubles gives the builtin and it works as above, but the other
translations give the library functions with their underscored
spelling. Compilers don't understand this spelling, so they don't
give the builtins. So isnan() is pessimized when applied to floats
and long doubles.
OTOH, if you forget that isnan() is type-generic and spell it isnanf()
or isnanl(), then the float and long double cases mostly work right
again:
- same behaviour if is not included (and -O is used)
- if is included, then it declares isnanf() but not isnanl(),
since only the former is compatibility cruft and has an extern function.
So isnanf() always works and the builtin is always used with -O and
and the extern function is used without -O. But isnanl() causes the
following problems:
- -Wimplicit* warning
- linkage failure without -O.
Another problem is that the extern __isnanl() is broken on x86, but the
builtin works. The extern functions do bit tests that are rather slow
but not slow enough to be correct (they don't check for pseudo-numbers
which the hardware treats as NaNs), but the builtin does a simple x != x
test which is probably optimal, and works.
Similarly for some other macros (they convert to spelling that compilers
don't understand, and at least the classification macros are broken on
psudo-numbers, but now the broken cases are mostly ones for which the
builtins don't exist or is broken).
Fixing the pessimizations would reduce the ABI problems. Both libc
and libm should translate to the builtin if it exists and is a real
builtin (not a libcall). This seems reasonable even without -O, since
C99 doesn't require any functions to exist so nothing should take their
addresses or try to call them as non-macros ('(isnan)(x)').
already has complications to use builtins for 1 set of interfaces only.
The only problems are that it is that it is hard to tell if builtins
exist and are real (there are compiler predefines for the set that
uses builtins but not for most sets).
With this, the library functions are never used by new compiles and
are only needed by old applications. All static copies of them can
be removed, but the .so ones are still needed until the ABI is changed.
When will the library isnanf() have been deprecated long enough to
remove in .so's too? Maybe it never needed to be preserved, since
old applications will link to old librar
Re: svn commit: r242835 - head/contrib/llvm/lib/Target/X86
On Sat, 10 Nov 2012, Nathan Whitehorn wrote: On 11/09/12 12:56, Dimitry Andric wrote: Log: Reduce LLVM's default stack alignment for i386 from 16 to 4 bytes, as the FreeBSD ABI requires. This is essentially a revert of upstream llvm commit r126226, and it will be reverted by upstream too. MFC after:1 week Modified: head/contrib/llvm/lib/Target/X86/X86Subtarget.cpp Modified: head/contrib/llvm/lib/Target/X86/X86Subtarget.cpp == --- head/contrib/llvm/lib/Target/X86/X86Subtarget.cpp Fri Nov 9 18:23:38 2012 (r242834) +++ head/contrib/llvm/lib/Target/X86/X86Subtarget.cpp Fri Nov 9 18:56:27 2012 (r242835) @@ -416,12 +416,12 @@ X86Subtarget::X86Subtarget(const std::st assert((!In64BitMode || HasX86_64) && "64-bit code requested on a subtarget that doesn't support it!"); - // Stack alignment is 16 bytes on Darwin, FreeBSD, Linux and Solaris (both - // 32 and 64 bit) and for all 64-bit targets. + // Stack alignment is 16 bytes on Darwin, Linux and Solaris (both 32 and 64 + // bit) and for all 64-bit targets. if (StackAlignOverride) stackAlignment = StackAlignOverride; - else if (isTargetDarwin() || isTargetFreeBSD() || isTargetLinux() || - isTargetSolaris() || In64BitMode) + else if (isTargetDarwin() || isTargetLinux() || isTargetSolaris() || + In64BitMode) stackAlignment = 16; } I'd like to object to this. We have an identical ABI to Linux (and Solaris, as far as I know). Splitting this by platform will only propagate the stack alignment breakage further -- what we need is LLVM/our C library to handle different alignments. Please fix this for real instead of balkanizing the ABI support in LLVM and introducing different ABIs for LLVM and GCC to FreeBSD. I'm not sure if either of us knows exactly what this does, but I like this change. clang does stack alignment correctly, so it doesn't need the gcc pessimization of aligning in the caller. clang aligns in the callee if necessary (except if is lied to about the ABI, then it doesn't know what is necessaary). It is rarely necessary, since most variables are 32 bits or smaller. (Necessary includes when an alignment attribute says so and for optimal alignment of long longs and doubles. The i386 ABI doesn't require alignment for the latter, but optimization doesn't, and when the variables aren't in structs the ABI doesn't prevent them being aligned for optimization.) Always aligning in the caller wastes an average of not quite 8 bytes of stack and cache space per function call, plus sometimes an extra instruction or 2 to do the unnecessary alignment. gcc's alignment in callers doesn't even work, because gcc assumes that it is enough and never does it in callees even when it is necessary: auto int32_t foo[8] __aligned[32]; gcc fails to do the necessary alignment. clang does it. auto int32_t foo[8] __aligned[16]; Both gcc and (hopefully only without the above fix) clang fail to do the necessary alignment. The ABI doesn't require the stack to be 16-byte aligned, so alignment is necessary (unless -mpreferred-stack-boundary was used to explictly modify the ABI). gcc only aligns the stack in main(), only to the alignment specified by -mpreferred-stack-boundary, and laboriously passes it down to all functions. clang doesn't do any special alignment in main(), but assumes that crtso did it. clang also doesn't support -mpreferred-stack-boundary, so it is incompatible with nonstandard ABI's like the one given by always using -mpreferred-stack-boundary=32. auto int32_t foo[8] __aligned[8]; Both gcc and (hopefully only without the above fix) clang fail to do the necessary alignment. gcc doesn't even do it if you compile this with -mpreferred-stack-boundary=2, which should tell it not to assume 16-byte alignment. Re-quoting most of the above: as far as I know). Splitting this by platform will only propagate the stack alignment breakage further -- what we need is LLVM/our C library to handle different alignments. Please fix this for real instead of balkanizing the ABI support in LLVM and introducing different ABIs for LLVM and GCC to FreeBSD. Yes, we need clang/our libraries to handle different alignments and not assume that callers do more than the ABI requires and pessimize on behalf of the libraries. Outside of libraries, the problem is small provided -mpreferred-stack-boundary works, since you can compile everything with the same -mpreferred-stack-boundary. 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: r242847 - in head/sys: i386/include kern
On Sun, Nov 11, 2012 at 1:41 AM, Albert Perlstein wrote: > The real conversation goes like this: > > user: "Why is my box seeing terrible network performance?" > bsdguy: "Increase nmbclusters." > user: "what is that?" > bsdguy: "Oh those are the mbufs, just tell me your current value." > user: "oh it's like 128000" > bsdguy: "hmm try doubling that, go sysctl kern.ipc.nmbclusters=512000 on the > command line." > user: "ok" > an hour passes ... > user: "hmm now I can't fork any more copies of apache.." > bsdguy: "oh, ok, you need to increase maxproc for that." > user: "so sysctl kern.ipc.maxproc=1?" > bsdguy: "no... one second..." > > bsdguy: "ok, so that's sysctl kern.maxproc=1" > user: "ok... bbiaf" > > user: "so now i'm getting log messages about can't open sockets..." > bsdguy: "oh you need to increase sockets bro... one second..." > user: "sysctl kern.maxsockets?" > bsdguy: "oh no.. it's actually back to kern.ipc.maxsockets" > user: "alrighty then.." > > > bsdguy: "so how is freebsd since I helped you tune it?" > user: "well i kept hitting other resource limits, boss made me switch to > Linux, it works out of the box and doesn't require an expert tuner to run a > large scale server. Y'know as a last ditch effort I looked around for this > 'maxusers' thing but it seems like some eggheads retired it and instead of > putting my job at risk, I just went with Linux, no one gets fired for using > Linux." > bsdguy: "managers are lame!" > user: "yeah! managers..." > > -Alfred Now Albert.. I know that deliberately playing dumb is fun, but there is no network difference between doubling "kern.maxusers" in loader.conf (the only place it can be set, it isn't runtime tuneable) and doubling "kern.ipc.nmbclusters" in the same place. We've always allowed people to fine-tune derived settings at runtime where it is possible. My position still is that instead of trying to dick around with maxusers curve slopes to try and somehow get the scaling right, we should instead be setting sensibly right from the start, by default. The current scaling was written when we had severe kva constraints, did reservations, etc. Now they're a cap on dynamic allocators on most platforms. "Sensible" defaults would be *way* higher than the current maxusers derived scaling curves. My quick survey: 8G ram -> 65088 clusters -> clusters capped at 6.2% of physical ram (running head) 3.5G ram -> 25600 clusters -> clusters capped at 5.0% of physical ram (running an old head) 32G ram -> 25600 clusters -> clusters capped at 1.5% of physical ram (running 9.1-stable) 72G ram -> 25600 clusters -> clusters capped at 0.06% of physical ram (9.1-stable again) As I've been saying from the beginning.. As these are limits on dynamic allocators, not reservations, they should be as high as we can comfortably set them without risking running out of other resources. As the code stands now.. the derived limits for 4k, 9k and 16k jumbo clusters is approximately the same space as 2K clusters. (ie: 1 x 4k cluster per 2 x 2k clusters, 1 x 16k cluster per 8 2k clusters, and so on). If we set a constant 6% for nmbclusters (since that's roughly where we're at now for smaller machines after albert's changes), then the worse case scenarios for 4k, 9k and 16k clusters are 6% each. ie: 24% of wired, physical ram. Plus all the other values derived from the nmbclusters tunable at boot. I started writing this with the intention of suggesting 10% but that might be a bit high given that: kern_mbuf.c:nmbjumbop = nmbclusters / 2; kern_mbuf.c:nmbjumbo9 = nmbclusters / 4; kern_mbuf.c:nmbjumbo16 = nmbclusters / 8; .. basically quadruples the worst case limits. Out of the box, 6% is infinitely better than we 0.06% we currently get on a 9-stable machine with 72G ram. But I object to dicking around with "maxusers" to derive network buffer space default limits. If we settle on something like 6%, then it should be 6%. That's easy to document and explain the meaning of the tunable. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell ___ 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: r242890 - head/sys/dev/xen/netback
Author: rdivacky
Date: Sun Nov 11 10:45:21 2012
New Revision: 242890
URL: http://svnweb.freebsd.org/changeset/base/242890
Log:
Fix a typo.
Modified:
head/sys/dev/xen/netback/netback_unit_tests.c
Modified: head/sys/dev/xen/netback/netback_unit_tests.c
==
--- head/sys/dev/xen/netback/netback_unit_tests.c Sun Nov 11 10:42:34
2012(r242889)
+++ head/sys/dev/xen/netback/netback_unit_tests.c Sun Nov 11 10:45:21
2012(r242890)
@@ -62,7 +62,7 @@ __FBSDID("$FreeBSD$");
* iff the assertion failed. Note the implied parameters buffer and
* buflen
*/
-#defineXNB_ASSERT(cond) do (
\
+#defineXNB_ASSERT(cond) do {
\
int passed = (cond);\
char *_buffer = (buffer); \
size_t _buflen = (buflen); \
___
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: r242889 - head/sys/dev/xen/netback
Author: rdivacky
Date: Sun Nov 11 10:42:34 2012
New Revision: 242889
URL: http://svnweb.freebsd.org/changeset/base/242889
Log:
Change the XNB_ASSERT from a statement expression to do-while(0) as its
result is never used.
Modified:
head/sys/dev/xen/netback/netback_unit_tests.c
Modified: head/sys/dev/xen/netback/netback_unit_tests.c
==
--- head/sys/dev/xen/netback/netback_unit_tests.c Sun Nov 11 08:22:58
2012(r242888)
+++ head/sys/dev/xen/netback/netback_unit_tests.c Sun Nov 11 10:42:34
2012(r242889)
@@ -62,7 +62,7 @@ __FBSDID("$FreeBSD$");
* iff the assertion failed. Note the implied parameters buffer and
* buflen
*/
-#defineXNB_ASSERT(cond) ({
\
+#defineXNB_ASSERT(cond) do (
\
int passed = (cond);\
char *_buffer = (buffer); \
size_t _buflen = (buflen); \
@@ -71,7 +71,7 @@ __FBSDID("$FreeBSD$");
strlcat(_buffer, ":" TOSTRING(__LINE__) \
" Assertion Error: " #cond "\n", _buflen);\
} \
- ! passed; })
+ } while (0)
/**
___
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: r242847 - in head/sys: i386/include kern
On Sun, Nov 11, 2012 at 1:41 AM, Alfred Perlstein wrote: > On 11/10/12 11:33 PM, Alexey Dokuchaev wrote: >> >> On Sat, Nov 10, 2012 at 10:22:52PM -0800, Peter Wemm wrote: >>> >>> We've had kern.ipc.nmbclusters for years. It is simple to understand, >>> easy to predict the outcome of a change, is runtime adjustable, is a >>> *cap* and not a reservation (like it used to be) and does not require >>> a reboot like maxusers tweaking would, and doesn't change maxproc as a >>> side effect. >>> >>> Tune the caps sensibly by default and move on. maxusers must die. >> >> Big +1. I would also like to get rid of maxusers altogether. >> >> ./danfe > > You aren't really understanding it. > > The contrived examples Peter are giving are *wrong*. What are the correct numbers then? -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell ___ 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: r242847 - in head/sys: i386/include kern
On 11/10/12 11:33 PM, Alexey Dokuchaev wrote: On Sat, Nov 10, 2012 at 10:22:52PM -0800, Peter Wemm wrote: We've had kern.ipc.nmbclusters for years. It is simple to understand, easy to predict the outcome of a change, is runtime adjustable, is a *cap* and not a reservation (like it used to be) and does not require a reboot like maxusers tweaking would, and doesn't change maxproc as a side effect. Tune the caps sensibly by default and move on. maxusers must die. Big +1. I would also like to get rid of maxusers altogether. ./danfe You aren't really understanding it. The contrived examples Peter are giving are *wrong*. Q: "How do I get an extra 2MB of clusters?" A1: "increase kern.ipc.nmbclusters by 1000" A2: "well, 2MB is 1000 clusters, and since you have mode than 768M of ram, you divide that 1000 clusters by 16 to get 62, then multiply that by 8 to reverse the maxusers slope factor above 768M, so you need to find the maxusers value you have and add 496 to it. That will probably increase your clusters by 2MB. Maybe." I am 100% aware that nmbclusters can override maxusers values, in fact it does. The real conversation goes like this: user: "Why is my box seeing terrible network performance?" bsdguy: "Increase nmbclusters." user: "what is that?" bsdguy: "Oh those are the mbufs, just tell me your current value." user: "oh it's like 128000" bsdguy: "hmm try doubling that, go sysctl kern.ipc.nmbclusters=512000 on the command line." user: "ok" an hour passes ... user: "hmm now I can't fork any more copies of apache.." bsdguy: "oh, ok, you need to increase maxproc for that." user: "so sysctl kern.ipc.maxproc=1?" bsdguy: "no... one second..." bsdguy: "ok, so that's sysctl kern.maxproc=1" user: "ok... bbiaf" user: "so now i'm getting log messages about can't open sockets..." bsdguy: "oh you need to increase sockets bro... one second..." user: "sysctl kern.maxsockets?" bsdguy: "oh no.. it's actually back to kern.ipc.maxsockets" user: "alrighty then.." bsdguy: "so how is freebsd since I helped you tune it?" user: "well i kept hitting other resource limits, boss made me switch to Linux, it works out of the box and doesn't require an expert tuner to run a large scale server. Y'know as a last ditch effort I looked around for this 'maxusers' thing but it seems like some eggheads retired it and instead of putting my job at risk, I just went with Linux, no one gets fired for using Linux." bsdguy: "managers are lame!" user: "yeah! managers..." -Alfred ___ 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: r242888 - head/contrib/top
Author: rpaulo
Date: Sun Nov 11 08:22:58 2012
New Revision: 242888
URL: http://svnweb.freebsd.org/changeset/base/242888
Log:
Add "pid" to the help menu (sort keys section).
Modified:
head/contrib/top/commands.c
Modified: head/contrib/top/commands.c
==
--- head/contrib/top/commands.c Sun Nov 11 08:16:33 2012(r242887)
+++ head/contrib/top/commands.c Sun Nov 11 08:22:58 2012(r242888)
@@ -80,11 +80,11 @@ n or # - change number of processes to
#ifdef ORDER
if (displaymode == DISP_CPU)
fputs("\
-o - specify sort order (pri, size, res, cpu, time, threads, jid)\n",
+o - specify sort order (pri, size, res, cpu, time, threads, jid, pid)\n",
stdout);
else
fputs("\
-o - specify sort order (vcsw, ivcsw, read, write, fault, total, jid)\n",
+o - specify sort order (vcsw, ivcsw, read, write, fault, total, jid,
pid)\n",
stdout);
#endif
fputs("\
___
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: r242887 - head/usr.bin/top
Author: rpaulo
Date: Sun Nov 11 08:16:33 2012
New Revision: 242887
URL: http://svnweb.freebsd.org/changeset/base/242887
Log:
Add the PID column to the list of sort keys.
Modified:
head/usr.bin/top/machine.c
Modified: head/usr.bin/top/machine.c
==
--- head/usr.bin/top/machine.c Sun Nov 11 06:29:59 2012(r242886)
+++ head/usr.bin/top/machine.c Sun Nov 11 08:16:33 2012(r242887)
@@ -225,7 +225,7 @@ long percentages();
char *ordernames[] = {
"cpu", "size", "res", "time", "pri", "threads",
"total", "read", "write", "fault", "vcsw", "ivcsw",
- "jid", NULL
+ "jid", "pid", NULL
};
#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"
