Re: freebsd and utf-8 directory names
Thanks for confirming this. I just closed that bug. :-) Kevin On Thu, Jul 03, 2014 at 05:24:54PM +0200, M&S - Krasznai András wrote: > Hi, Kevin, > > > I made the experiment and there was no fault, the "result" contains the stat > outputs. > I used login-class (according to the handbook) to set the environment, and > added the -L hu_HU.UTF-8 option to the appropriate line in fstab > > > rgds > > András > > From: owner-freebsd-curr...@freebsd.org [owner-freebsd-curr...@freebsd.org] > On Behalf Of Kevin Lo [ke...@freebsd.org] > Sent: Thursday, July 03, 2014 5:33 AM > To: d...@gmx.com > Cc: freebsd-current@freebsd.org; David Chisnall > Subject: Re: freebsd and utf-8 directory names > > On Wed, Jul 02, 2014 at 12:27:07AM +0200, d...@gmx.com wrote: > > > > David Chisnall wrote, On 07/01/2014 19:06: > > > Please note that forums.freebsd.org is not a bug tracker. I tried > > > searching the bug tracker for bugs with FAT and filename or FAT and > > > utf-8/utf8/character in their names and could not find any reference to > > > this issue. > > > > > > If you actually want to see bugs fixed, rather than just complain about > > > them, please file them here: > > > https://bugs.freebsd.org/bugzilla/enter_bug.cgi Make sure that you > > > provide all of the steps required to reproduce them. > > > > I neglected to submit a bug report because: > > (1) there were already at least 3 bug reports related to (FAT32 and) > > character sets or encodings, some of them even had patches; > > (2) the reports were very old, indicating that the FreeBSD developers don't > > care about FAT32; > > (3) at least one report was seemingly related, and I didn't want to create > > a(nother) possible duplicate. > > > > But now, eat this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191540 > > Well, I'm going to close that PR. :-) > First, set LANG environment variable to hu_HU.UTF-8 in your case: > > # setenv LANG hu_HU.UTF-8 > > Second, mount the FAT32 partition in Hungarian locale: > > # mount_msdosfs -L hu_HU.UTF-8 /dev/da0s1 /mnt > > Third, untar your attachement file: > > # tar xvf /mnt/files.zip > x 1’.txt > x 2–.txt > > # stat 1’.txt > 128 244744 -rwxr-xr-x 1 root wheel 4294967295 0 "Jan 1 08:00:00 1980" "Aug > 1 16:57:52 2011" "Aug 1 16:57:52 2011" "Jul 3 11:28:24 2014" 16384 0 0x800 > 1’.txt > > # stat 2–.txt > 128 244746 -rwxr-xr-x 1 root wheel 4294967295 0 "Jan 1 08:00:00 1980" "Aug > 1 16:55:20 2011" "Aug 1 16:55:20 2011" "Jul 3 11:28:24 2014" 16384 0 0x800 > 2–.txt > > Let me know if that works for you, thanks. > > Kevin > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
keyboard break to debugger broken?
So, I recently tried to break into the debugger w/ the various key sequences that I know about, and none of them worked... I've tried CTRL-ESC, ALT-ESC, CTRL-ALT-ESC, CTRL-PRTSCR, ALT-PRTSCR and CTRL-ALT-PRTSCR, and many other different ones... I've verified that I can sysctl debug.kdb.enter=1 to enter the debugger, and the CTRL-ALT-PAUSE works to suspend the machine, and CTRL-ALT-DEL works to reboot... Does anyone know if this works? Thanks for the pointers... btw, I'm having trouble on 9stable too. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: EDEADLK from fcntl(F_SETFL) ?
On Thu, Jul 03, 2014 at 07:15:51PM -0700, Adrian Chadd wrote:
> Hi,
>
> I'm currently testing this out. It seems to be working out alright.
>
> adrian@test3:~/work/freebsd % svn diff stable/10/src/sys/kern/
>
> Index: stable/10/src/sys/kern/kern_lockf.c
>
> ===
>
> --- stable/10/src/sys/kern/kern_lockf.c (revision 267627)
>
> +++ stable/10/src/sys/kern/kern_lockf.c (working copy)
>
> @@ -1425,6 +1425,14 @@
>
> if (lockf_debug & 1)
>
> lf_print("lf_setlock: deadlock", lock);
>
> #endif
>
> +
>
> + /*
>
> +* If the lock isn't waiting, return EAGAIN
>
> +* rather than EDEADLK.
>
> +*/
>
> + if (((lock->lf_flags & F_WAIT) == 0) &&
>
> + (error == EDEADLK))
>
> + error = EAGAIN;
>
> lf_free_lock(lock);
>
> goto out;
>
> }
>
> On 3 July 2014 17:45, Adrian Chadd wrote:
> > Hi!
> >
> > I've seen sqlite3 crap out due to "disk IO error". It looks like the
> > F_SETFL path is returning EDEADLK when it shouldn't be - only the
> > "wait" version of this should be.
> >
> > The kernel code looks to be:
> >
> > lf_setlock() -> lf_add_outgoing() -> lf_add_edge() -> graph_add_edge()
> > -> EDEADLK
> >
> > .. and lf_setlock() will return an error from lf_add_outgoing()
> > without checking if it's (a) EDEADLK, and (b) whether we're going to
> > sleep or not.
> >
> > So, sqlite3 trips up on this. I'm sure other things do. What should
> > the correct thing be? It looks like EWOULDBLOCK is the correct value
> > to return for F_SETFL failing, not EDEADLK.
> >
> > What do those-who-know-POSIX-standards-better-than-I think?
I doubt that the patch is correct. If there is an issue in kernel, the
patch only hides it.
Note that lf_setlock() first calls lf_getblock() to verify that there
is no contending lock on the range, and if there is a conflicting lock,
the very first statement inside the if() checks for F_WAIT.
Either you get a real deadlock, or there is a bug elsewere.
pgpMP3M3B_cHb.pgp
Description: PGP signature
Re: keyboard break to debugger broken?
On Fri, 4 Jul 2014 02:28-0700, John-Mark Gurney wrote: > So, I recently tried to break into the debugger w/ the various key > sequences that I know about, and none of them worked... I've tried > CTRL-ESC, ALT-ESC, CTRL-ALT-ESC, CTRL-PRTSCR, ALT-PRTSCR and > CTRL-ALT-PRTSCR, and many other different ones... I've verified that > I can sysctl debug.kdb.enter=1 to enter the debugger, and the > CTRL-ALT-PAUSE works to suspend the machine, and CTRL-ALT-DEL works > to reboot... > > Does anyone know if this works? > > Thanks for the pointers... > > btw, I'm having trouble on 9stable too. You might need to modify and load a keymap, specifying debug as the action for the appropriate combination of keys. Have a look at the files in /usr/share/syscons/keymaps/. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD iscsi target
On Thu, Jul 03, 2014 at 08:39:42PM -0700, Kevin Oberman wrote: > > > > In real world "Reality is quite different than it actually is". > > > > http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/white_paper_c11-696669.html > > > > See "Packet Path Theory of Operation. Ingress Mode". > > > > > Yep. It is really crappy LAGG (fixed three-tupple hash... yuck!) and is > really nothing but 4 10G Ethernet ports using a 40G PHY in yhe 4x10G form. > > Note that they don't make any claim of 802.3ba compliance. It only states > that "40 Gigabit Ethernet is now part of the IEEE 802.3ba standard." So it > is, but this device almost certainly predates the completion of the > standard to get a product for which there was great demand. It's a data > center product and for typical cases of large numbers of small flow, it > should do the trick. Probably does not interoperate with true 80-2.3ba > hardware, either. > > My boss at the time I retired last November was on the committee that wrote > 802.3ba. He would be a good authority on whether the standard has any vague > wording that would allow this, but he retired 5 month after I did and I > have no contact information for him. But I'm pretty sure that there is no > way that this is legitimate 40G Ethernet. 802.3ba describe only end point of ethernet. ASIC, internal details of implemetations NICs, switches, fabrics -- out of standart scope. Bottleneck can be in any point of packet flow. In first pappers of netmap test demonstarated NIC can't do saturation of 10G in one stream 64 bytes packet -- need use multiple rings for transmit. I think need use general rule: one flow transfer can hit performance limitation. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD iscsi target
On Fri, Jul 4, 2014 at 12:16 PM, Slawa Olhovchenkov wrote: > On Thu, Jul 03, 2014 at 08:39:42PM -0700, Kevin Oberman wrote: > > > > > > > In real world "Reality is quite different than it actually is". > > > > > > > http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/white_paper_c11-696669.html > > > > > > See "Packet Path Theory of Operation. Ingress Mode". > > > > > > > > Yep. It is really crappy LAGG (fixed three-tupple hash... yuck!) and is > > really nothing but 4 10G Ethernet ports using a 40G PHY in yhe 4x10G > form. > > > > Note that they don't make any claim of 802.3ba compliance. It only states > > that "40 Gigabit Ethernet is now part of the IEEE 802.3ba standard." So > it > > is, but this device almost certainly predates the completion of the > > standard to get a product for which there was great demand. It's a data > > center product and for typical cases of large numbers of small flow, it > > should do the trick. Probably does not interoperate with true 80-2.3ba > > hardware, either. > > > > My boss at the time I retired last November was on the committee that > wrote > > 802.3ba. He would be a good authority on whether the standard has any > vague > > wording that would allow this, but he retired 5 month after I did and I > > have no contact information for him. But I'm pretty sure that there is no > > way that this is legitimate 40G Ethernet. > > 802.3ba describe only end point of ethernet. > ASIC, internal details of implemetations NICs, switches, fabrics -- > out of standart scope. > Bottleneck can be in any point of packet flow. > In first pappers of netmap test demonstarated NIC can't do saturation > of 10G in one stream 64 bytes packet -- need use multiple rings for > transmit. > that was actually just a configuration issue which since then has been resolved. The 82599 can do 14.88 Mpps on a single ring (and is the only 10G nic i have encountered who can do so). Besides, performance with short packets has nothing to do with the case you were discussing, namely throughput for a single large flow. > I think need use general rule: one flow transfer can hit performance > limitation. > This is neither a useful nor it is restricted to a single flow. Everything "can" underperform depending on the hw/sw configuration, but not necessarily has to. cheers luigi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD iscsi target
On Fri, Jul 04, 2014 at 12:25:35PM +0200, Luigi Rizzo wrote: > On Fri, Jul 4, 2014 at 12:16 PM, Slawa Olhovchenkov wrote: > > > On Thu, Jul 03, 2014 at 08:39:42PM -0700, Kevin Oberman wrote: > > > > > > > > > > In real world "Reality is quite different than it actually is". > > > > > > > > > > http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/white_paper_c11-696669.html > > > > > > > > See "Packet Path Theory of Operation. Ingress Mode". > > > > > > > > > > > Yep. It is really crappy LAGG (fixed three-tupple hash... yuck!) and is > > > really nothing but 4 10G Ethernet ports using a 40G PHY in yhe 4x10G > > form. > > > > > > Note that they don't make any claim of 802.3ba compliance. It only states > > > that "40 Gigabit Ethernet is now part of the IEEE 802.3ba standard." So > > it > > > is, but this device almost certainly predates the completion of the > > > standard to get a product for which there was great demand. It's a data > > > center product and for typical cases of large numbers of small flow, it > > > should do the trick. Probably does not interoperate with true 80-2.3ba > > > hardware, either. > > > > > > My boss at the time I retired last November was on the committee that > > wrote > > > 802.3ba. He would be a good authority on whether the standard has any > > vague > > > wording that would allow this, but he retired 5 month after I did and I > > > have no contact information for him. But I'm pretty sure that there is no > > > way that this is legitimate 40G Ethernet. > > > > 802.3ba describe only end point of ethernet. > > ASIC, internal details of implemetations NICs, switches, fabrics -- > > out of standart scope. > > Bottleneck can be in any point of packet flow. > > In first pappers of netmap test demonstarated NIC can't do saturation > > of 10G in one stream 64 bytes packet -- need use multiple rings for > > transmit. > > > > ?that was actually just a configuration issue which since then > has been ?resolved. The 82599 can do 14.88 Mpps on a single ring > (and is the only 10G nic i have encountered who can do so). Thanks for clarification. > Besides, performance with short packets has nothing to do with the case > you were discussing, namely throughput for a single large flow. This is only illustration about hardware limitation. Perforamnce may be not only bandwidth limited, but interrupt/pps (per flow) limited. > > I think need use general rule: one flow transfer can hit performance > > limitation. > > > > ?This is neither a useful nor it is restricted to a single flow. > > Everything "can" underperform depending > on the hw/sw configuration, but not necessarily has to. Yes. And estimate to ideal hw/sw configuration and enviroment -- bad think. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Boot loader too large
On Fri, Jul 4, 2014 at 5:57 PM, Alie Tan wrote: > Hi, > > I am getting Boot loader too large message while using > FreeBSD-11.0-CURRENT-i386-20140701-r268111-disc1.iso > > Is there any way to solve this issue? > Strange, resizing the freebsd-boot to 128k solved my issue. why default slice size making such issue? > > Thanks in advance > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Boot loader too large
Hi, I am getting Boot loader too large message while using FreeBSD-11.0-CURRENT-i386-20140701-r268111-disc1.iso Is there any way to solve this issue? Thanks in advance ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: keyboard break to debugger broken?
On 2014-Jul-04 02:28:48 -0700, John-Mark Gurney wrote: >So, I recently tried to break into the debugger w/ the various key >sequences that I know about, and none of them worked... I've tried >CTRL-ESC, ALT-ESC, CTRL-ALT-ESC, CTRL-PRTSCR, ALT-PRTSCR and >CTRL-ALT-PRTSCR, and many other different ones... I've verified that >I can sysctl debug.kdb.enter=1 to enter the debugger, and the >CTRL-ALT-PAUSE works to suspend the machine, and CTRL-ALT-DEL works >to reboot... > >Does anyone know if this works? It works for me on 10.0. Do you have debug.kdb.break_to_debugger=1 and hw.syscons.kbd_debug=1 (if you're using syscons)? -- Peter Jeremy pgpRWEUgfMxEM.pgp Description: PGP signature
Re: 10.0-RELEASE BTX halted on DELL R900
Try use the loader from 9.2R. Huang Wen Hui > 在 2014年7月4日，15:37，wsk 写道： > > lists >I met a BTX halted problem while upgrade Freebsd 9.0-RC3 to 10.0-Release > via freebsd-update. > and please check the link below: > http://sw.gddsn.org.cn/jopens/test/btx.jpg > > BTW: I can booted 10.0-R from DVD-ROM as expected but got same error message > with flash-driver. > any ideas? > > -- > wsk > > > > > ___ > freebsd-sta...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Intercepting calls in PIC mode
Hello,
Consider the following:
---
#include
#include
extern "C" void* memset(void *block, int c, size_t size)
__attribute__((weak, alias("__int_memset"), visibility("default")));
extern "C" __attribute__((visibility("default")))
void* __int_memset(void *block, int c, size_t size) {
puts("Hello");
return NULL;
}
int main()
{
void *(*F)(void *b, int c, size_t len) = memset;
char a[5];
memset(a, 0, sizeof(a));
F(a, 0, sizeof(a));
return 0;
}
---
It intercepts the memset() calls without issue on both x86-64 FreeBSD
9.2 and Linux. However, with the -fPIC option specified in the cc's
command line, only the first (direct) call work on FreeBSD, but not the
second (indirect) one. Note is that on Linux both the calls are
intercepted--no matter whether the -fPIC option is specified or not.
The question is: is there a way to intercept indirect calls on FreeBSD?
Thanks,
--
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on ia64/ia64
TB --- 2014-07-04 12:28:06 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-07-04 12:28:06 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-07-04 12:28:06 - starting HEAD tinderbox run for ia64/ia64 TB --- 2014-07-04 12:28:06 - cleaning the object tree TB --- 2014-07-04 12:28:06 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-07-04 12:28:33 - At svn revision 268242 TB --- 2014-07-04 12:28:34 - building world TB --- 2014-07-04 12:28:34 - CROSS_BUILD_TESTING=YES TB --- 2014-07-04 12:28:34 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-04 12:28:34 - MAKESYSPATH=/src/share/mk TB --- 2014-07-04 12:28:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-04 12:28:34 - SRCCONF=/dev/null TB --- 2014-07-04 12:28:34 - TARGET=ia64 TB --- 2014-07-04 12:28:34 - TARGET_ARCH=ia64 TB --- 2014-07-04 12:28:34 - TZ=UTC TB --- 2014-07-04 12:28:34 - __MAKE_CONF=/dev/null TB --- 2014-07-04 12:28:34 - cd /src TB --- 2014-07-04 12:28:34 - /usr/bin/make -B buildworld >>> Building an up-to-date bmake(1) [...] cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign-c /src/contrib/bmake/lst.lib/lstFindFrom.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign-c /src/contrib/bmake/lst.lib/lstFirst.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign-c /src/contrib/bmake/lst.lib/lstForEach.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign-c /src/contrib/bmake/lst.lib/lstForEachFrom.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign-c /src/contrib/bmake/lst.lib/lstInit.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign-c /src/contrib/bmake/lst.lib/lstInsert.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign-c /src/contrib/bmake/lst.lib/lstIsAtEnd.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PA
Re: 10.0-RELEASE BTX halted on DELL R900
--- Original message --- From: "wsk" Date: 4 July 2014, 15:21:48 > lists > I met a BTX halted problem while upgrade Freebsd 9.0-RC3 to > 10.0-Release via freebsd-update. > and please check the link below: > http://sw.gddsn.org.cn/jopens/test/btx.jpg > > BTW: I can booted 10.0-R from DVD-ROM as expected but got same error > message with flash-driver. > any ideas? > > -- > wsk > Look ACPI settings in the BIOS. I think he should have ACPI v1. -- Vladislav V. Prodan System & Network Administrator support.od.ua ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: uefi boot on Apple Mac
On 24 May 2014 19:39, Rafael Espíndola wrote: > > Yes, I got that in the mac laptops I tried, it worked on a Mac Pro. It > might be the frame buffer corruption that Ed Maste was mentioning. I purchased a new MacBook Air yesterday (model identifier MacBookAir6,2). UEFI boot and vt(4) worked correctly. (My image included Rafael's patch; I haven't tried a boot without.) I also committed a change to display the framebuffer parameters (address, dimensions, etc.) on boot, in order to help identify the source of this issue. If you have a moment can you build a new USB stick image and give it a try? -Ed ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: uefi boot on Apple Mac
Hi, On my MacbookPro11,3, I got this error message: http://sw.gddsn.org.cn/freebsd/uefi.jpg cheers, Huang WenHui 2014-07-04 22:13 GMT+08:00 Ed Maste : > On 24 May 2014 19:39, Rafael Espíndola wrote: > > > > Yes, I got that in the mac laptops I tried, it worked on a Mac Pro. It > > might be the frame buffer corruption that Ed Maste was mentioning. > > I purchased a new MacBook Air yesterday (model identifier > MacBookAir6,2). UEFI boot and vt(4) worked correctly. (My image > included Rafael's patch; I haven't tried a boot without.) > > I also committed a change to display the framebuffer parameters > (address, dimensions, etc.) on boot, in order to help identify the > source of this issue. If you have a moment can you build a new USB > stick image and give it a try? > > -Ed > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Intercepting calls in PIC mode
On Fri, Jul 04, 2014 at 04:12:51PM +0400, Ivan A. Kosarev wrote:
> Hello,
>
> Consider the following:
>
> ---
> #include
> #include
>
> extern "C" void* memset(void *block, int c, size_t size)
> __attribute__((weak, alias("__int_memset"), visibility("default")));
>
> extern "C" __attribute__((visibility("default")))
> void* __int_memset(void *block, int c, size_t size) {
> puts("Hello");
> return NULL;
> }
>
> int main()
> {
> void *(*F)(void *b, int c, size_t len) = memset;
> char a[5];
> memset(a, 0, sizeof(a));
> F(a, 0, sizeof(a));
> return 0;
> }
> ---
>
> It intercepts the memset() calls without issue on both x86-64 FreeBSD
> 9.2 and Linux. However, with the -fPIC option specified in the cc's
> command line, only the first (direct) call work on FreeBSD, but not the
> second (indirect) one. Note is that on Linux both the calls are
> intercepted--no matter whether the -fPIC option is specified or not.
Your example is rather convoluted, I will try to explain below why.
First, I am sure that C99 does not allow to override the semantic of the
standard-defined functions. That said, a call to memset(3) can be
inlined by a compiler, so there could be nothing to intercept.
Second, FreeBSD implementation of the weak ELF symbols is non-compliant.
The dynamic linker prioritizes non-weak symbols over the weak. This at
least explains why your code snippet does not segfaults: the memset(3)
from libc is not interposed by your memset() implementation, so libc can
at least initialize itself. If you remove weak attribute from the memset(),
debug version of libc fails with assertions in jemalloc, while normal
build just segfaults.
That said, there are also differences in the static linker behaviour.
Clang generates the following code to obtain the address of the memset(3)
function:
movqmemset@GOTPCREL(%rip), %rsi
The in-tree ld from binutils 2.17.redhat generates the
R_X86_64_GLOB_DAT relocation to fill the GOT entry for the memset
symbol. Processor of the GLOB_DAT in the rtld-elf always starts
the lookup of the requested symbol in the object next from main.
For your code, this means libc is searched for memset to fill the
slot, and you get a libc symbol.
The ld from the stock build of binutils 2.24, on the other hand, does not
generate a relocation at all, it resolves memset internally from the same
object file and fills the offset directly into instruction. I.e., when
the program is linked with new ld, it works as you intend. This is
probably the reason why it worked for you on Linux.
I am not sure what conclusion could be made from the story I just told you.
Might be, 'do not try to interpose std C functions' and 'put interposers
into the LD_PRELOADed objects' ?
pgpBuunCMU9Uu.pgp
Description: PGP signature
Re: Intercepting calls in PIC mode
You could hijack the GOT entry, but that assumes the symbol has been
resolved first (either LD_BIND_NOW or the function has been called at
least once). You could also use LD_PRELOAD.
On Jul 04, 2014 04:12 PM +0400, Ivan A. Kosarev wrote:
> Hello,
>
> Consider the following:
>
> ---
> #include
> #include
>
> extern "C" void* memset(void *block, int c, size_t size)
> __attribute__((weak, alias("__int_memset"), visibility("default")));
>
> extern "C" __attribute__((visibility("default")))
> void* __int_memset(void *block, int c, size_t size) {
> puts("Hello");
> return NULL;
> }
>
> int main()
> {
> void *(*F)(void *b, int c, size_t len) = memset;
> char a[5];
> memset(a, 0, sizeof(a));
> F(a, 0, sizeof(a));
> return 0;
> }
> ---
>
> It intercepts the memset() calls without issue on both x86-64 FreeBSD
> 9.2 and Linux. However, with the -fPIC option specified in the cc's
> command line, only the first (direct) call work on FreeBSD, but not the
> second (indirect) one. Note is that on Linux both the calls are
> intercepted--no matter whether the -fPIC option is specified or not.
>
> The question is: is there a way to intercept indirect calls on FreeBSD?
>
> Thanks,
>
> --
>
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
pgpa0KBnqTBfh.pgp
Description: PGP signature
ZFS ARC max sort of not working?
It looks like the following no longer works on head? vfs.zfs.arc_max="8G" But this does? vfs.zfs.arc_max="8589934592" sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS ARC max sort of not working?
On 2014-07-04 11:56, Sean Bruno wrote: > It looks like the following no longer works on head? > > vfs.zfs.arc_max="8G" > > But this does? > > vfs.zfs.arc_max="8589934592" > > sean > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > 8G = 8 x 2^30 (1024*1024*1024) That is correct. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: ZFS ARC max sort of not working?
On Fri, 2014-07-04 at 11:58 -0400, Allan Jude wrote: > On 2014-07-04 11:56, Sean Bruno wrote: > > It looks like the following no longer works on head? > > > > vfs.zfs.arc_max="8G" > > > > But this does? > > > > vfs.zfs.arc_max="8589934592" > > > > sean > > > > ___ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > > > 8G = 8 x 2^30 (1024*1024*1024) > > That is correct. > Sure, but up until recently on head (last month or two) the shorthand of 8G worked. sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS ARC max sort of not working?
On 2014-07-04 12:06, Sean Bruno wrote: > On Fri, 2014-07-04 at 11:58 -0400, Allan Jude wrote: >> On 2014-07-04 11:56, Sean Bruno wrote: >>> It looks like the following no longer works on head? >>> >>> vfs.zfs.arc_max="8G" >>> >>> But this does? >>> >>> vfs.zfs.arc_max="8589934592" >>> >>> sean >>> >>> ___ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" >>> >> >> 8G = 8 x 2^30 (1024*1024*1024) >> >> That is correct. >> > > Sure, but up until recently on head (last month or two) the shorthand of > 8G worked. > > sean > > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > Sorry, I misread the question. -- Allan Jude signature.asc Description: OpenPGP digital signature
[HEADS-UP] Problem with clang in 9-stable [was: r268244 (stable/9) seems to break "sysctl hw.ncpu"]
Hi, Can you try to reproduce this: Checkout 9-stable's src/sbin/sysctl only. cd /usr/9-stable/src/sbin/sysctl env CC=clang make clean all ./sysctl -n hw.ncpu Then: env CC=gcc make clean all ./sysctl -n hw.ncpu clang --version FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 Target: x86_64-unknown-freebsd9.1 Thread model: posix gcc --version gcc (GCC) 4.2.1 20070831 patched [FreeBSD] Copyright (C) 2007 Free Software Foundation, Inc. When compiling the code with clang, no output is happening. When compiling with gcc, the FreeBSD 9-stable sysctl operates correctly. How do we proceed? Can more people check this and reproduce? When compiling the -10 and -11 version of sysctl with clang and gcc, everything is fine! Thank you! --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS ARC max sort of not working?
poke hps? -a On 4 July 2014 08:56, Sean Bruno wrote: > It looks like the following no longer works on head? > > vfs.zfs.arc_max="8G" > > But this does? > > vfs.zfs.arc_max="8589934592" > > sean > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [HEADS-UP] Problem with clang in 9-stable [was: r268244 (stable/9) seems to break "sysctl hw.ncpu"]
On Fri, Jul 04, 2014 at 08:09:21PM +0200, Hans Petter Selasky wrote: > Hi, > > Can you try to reproduce this: > > Checkout 9-stable's src/sbin/sysctl only. > > cd /usr/9-stable/src/sbin/sysctl > > env CC=clang make clean all > ./sysctl -n hw.ncpu > > Then: > > env CC=gcc make clean all > ./sysctl -n hw.ncpu > > > clang --version > FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 > Target: x86_64-unknown-freebsd9.1 > Thread model: posix > > gcc --version > gcc (GCC) 4.2.1 20070831 patched [FreeBSD] > Copyright (C) 2007 Free Software Foundation, Inc. > Hmm... I should have mentioned this part earlier (sorry!): I've been using clang as the system compiler since about ... autumn 2012 (long ago enough that I forgot that it might be "odd" for stable/9). > When compiling the code with clang, no output is happening. When > compiling with gcc, the FreeBSD 9-stable sysctl operates correctly. How > do we proceed? > > Can more people check this and reproduce? Well, here's what I see: g1-252(9.3-P)[22] svn co file:///svn/freebsd/src/base/stable/9/sbin/sysctl Asysctl/sysctl.c Asysctl/sysctl.8 Asysctl/Makefile U sysctl Checked out revision 268249. g1-252(9.3-P)[23] cd sysctl/ g1-252(9.3-P)[24] env CC=clang make clean all rm -f sysctl sysctl.o sysctl.8.gz sysctl.8.cat.gz Warning: Object directory not changed from original /tmp/hps/sysctl clang -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -c sysctl.c clang -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -o sysctl sysctl.o gzip -cn sysctl.8 > sysctl.8.gz g1-252(9.3-P)[25] ./sysctl -n hw.ncpu g1-252(9.3-P)[26] env CC=gcc make clean all rm -f sysctl sysctl.o sysctl.8.gz sysctl.8.cat.gz Warning: Object directory not changed from original /tmp/hps/sysctl clang -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -c sysctl.c clang -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -o sysctl sysctl.o gzip -cn sysctl.8 > sysctl.8.gz g1-252(9.3-P)[27] ./sysctl -n hw.ncpu g1-252(9.3-P)[28] > When compiling the -10 and -11 version of sysctl with clang and gcc, > everything is fine! That's moderately seriously kinky And not in a Good Way. :-/ > Thank you! At least I have some evidence that I might not be merely hallucinating Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpUqV_GqtL6t.pgp Description: PGP signature
Re: [HEADS-UP] Problem with clang in 9-stable [was: r268244 (stable/9) seems to break "sysctl hw.ncpu"]
Hi, I've reverted the MFC of r267960: http://svnweb.freebsd.org/changeset/base/268263 I did some checking and the patch makes access to a non-initialized variable, due to other missing patches prior to mine, probably making compiler differences show up on my side. It appears the patch cannot be ported to 9-stable then. So I'll just leave it there. David: Thank you for your error-report. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS ARC max sort of not working?
Related to the global sysctl changes recently perhaps? - Original Message - From: "Sean Bruno" To: "freebsd-current" Sent: Friday, July 04, 2014 4:56 PM Subject: ZFS ARC max sort of not working? It looks like the following no longer works on head? vfs.zfs.arc_max="8G" But this does? vfs.zfs.arc_max="8589934592" sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on ia64/ia64
TB --- 2014-07-05 02:47:07 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-07-05 02:47:07 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-07-05 02:47:07 - starting HEAD tinderbox run for ia64/ia64 TB --- 2014-07-05 02:47:07 - cleaning the object tree TB --- 2014-07-05 02:47:08 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-07-05 02:47:34 - At svn revision 268264 TB --- 2014-07-05 02:47:35 - building world TB --- 2014-07-05 02:47:35 - CROSS_BUILD_TESTING=YES TB --- 2014-07-05 02:47:35 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-05 02:47:35 - MAKESYSPATH=/src/share/mk TB --- 2014-07-05 02:47:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-05 02:47:35 - SRCCONF=/dev/null TB --- 2014-07-05 02:47:35 - TARGET=ia64 TB --- 2014-07-05 02:47:35 - TARGET_ARCH=ia64 TB --- 2014-07-05 02:47:35 - TZ=UTC TB --- 2014-07-05 02:47:35 - __MAKE_CONF=/dev/null TB --- 2014-07-05 02:47:35 - cd /src TB --- 2014-07-05 02:47:35 - /usr/bin/make -B buildworld >>> Building an up-to-date bmake(1) [...] cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign-c /src/contrib/bmake/lst.lib/lstFindFrom.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign-c /src/contrib/bmake/lst.lib/lstFirst.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign-c /src/contrib/bmake/lst.lib/lstForEach.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign-c /src/contrib/bmake/lst.lib/lstForEachFrom.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign-c /src/contrib/bmake/lst.lib/lstInit.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign-c /src/contrib/bmake/lst.lib/lstInsert.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\".../share/mk:/usr/share/mk\" -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign-c /src/contrib/bmake/lst.lib/lstIsAtEnd.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PA
Re: ZFS ARC max sort of not working?
On 07/05/14 02:01, Steven Hartland wrote: Related to the global sysctl changes recently perhaps? I'll have a look. The global tunables only support integers and strings, no human shortcuts. This should be easy to fix though. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS ARC max sort of not working?
On 07/05/14 07:40, Hans Petter Selasky wrote: On 07/05/14 02:01, Steven Hartland wrote: Related to the global sysctl changes recently perhaps? I'll have a look. The global tunables only support integers and strings, no human shortcuts. This should be easy to fix though. Hi, The following commit should fix the above mentioned problem: http://svnweb.freebsd.org/changeset/base/268285 --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
