Re: [PATCH] Fix CFLAGS overwrite by Makefile
On Tue, May 24, 2011 at 11:08:52PM -0400, Arnaud Lacombe wrote:
> Hi,
>
> On Tue, May 24, 2011 at 10:54 PM, Arnaud Lacombe wrote:
> > ps: for static library and loader, I derived the total size as the sum
> > of the size of the text/data/bss section of the member object using :
> >
> > size *.o | awk 'BEGIN {text=0; data=0; bss=0;}; {text+=$1; data+=$2;
> > bss+=$3}; END {print text " " data " " bss " '$i'"}'
> >
> > where $i is the cpu type to test. make(1) is passed either CPUTYPE=$i
> > for i in i[3456]86, or the empty string. The compiler used for the
> > test is gcc, and it is the compiler build during a buildworld stage,
> > in the tmp directory.
> >
> just to cut loose any question about my environment, additionally to
> the original patch, I made the following modification to the tree to
> try to isolate it from the host:
> - applied the following patch:
[...]
> - manually created two symlinks:
> 1) include/machine -> ../sys/i386/include/
> 2) include/x86 -> ../sys/x86/include/
>
> The host is running a custom 8.2-STABLE/amd64 kernel (only config
> change) on the following CPU:
>
> CPU: Intel(R) Xeon(R) CPU X3430 @ 2.40GHz (2394.00-MHz K8-class
> CPU)
> Origin = "GenuineIntel" Id = 0x106e5 Family = 6 Model = 1e Stepping = 5
>
> Features=0xbfebfbff
>
> Features2=0x98e3fd
> AMD Features=0x28100800
> AMD Features2=0x1
> TSC: P-state invariant
>
> I am still not sure what is the default gcc target architecture on this
> machine.
Why not go along a supported way, and do a cross-build?
--
Ruslan Ermilov
r...@freebsd.org
FreeBSD committer
___
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: [PATCH] Fix CFLAGS overwrite by Makefile
on 25/05/2011 15:25 Ruslan Ermilov said the following:
> On Tue, May 24, 2011 at 11:08:52PM -0400, Arnaud Lacombe wrote:
>> Hi,
>>
>> On Tue, May 24, 2011 at 10:54 PM, Arnaud Lacombe wrote:
>>> ps: for static library and loader, I derived the total size as the sum
>>> of the size of the text/data/bss section of the member object using :
>>>
>>> size *.o | awk 'BEGIN {text=0; data=0; bss=0;}; {text+=$1; data+=$2;
>>> bss+=$3}; END {print text " " data " " bss " '$i'"}'
>>>
>>> where $i is the cpu type to test. make(1) is passed either CPUTYPE=$i
>>> for i in i[3456]86, or the empty string. The compiler used for the
>>> test is gcc, and it is the compiler build during a buildworld stage,
>>> in the tmp directory.
>>>
>> just to cut loose any question about my environment, additionally to
>> the original patch, I made the following modification to the tree to
>> try to isolate it from the host:
>> - applied the following patch:
>
> [...]
>
>> - manually created two symlinks:
>> 1) include/machine -> ../sys/i386/include/
>> 2) include/x86 -> ../sys/x86/include/
>>
>> The host is running a custom 8.2-STABLE/amd64 kernel (only config
>> change) on the following CPU:
>>
>> CPU: Intel(R) Xeon(R) CPU X3430 @ 2.40GHz (2394.00-MHz K8-class
>> CPU)
>> Origin = "GenuineIntel" Id = 0x106e5 Family = 6 Model = 1e Stepping = 5
>>
>> Features=0xbfebfbff
>>
>> Features2=0x98e3fd
>> AMD Features=0x28100800
>> AMD Features2=0x1
>> TSC: P-state invariant
>>
>> I am still not sure what is the default gcc target architecture on this
>> machine.
Default target architecture should not depend on current machine.
It is in gcc manual page:
generic
Produce code optimized for the most common IA32/AMD64/EM64T
processors. If you know the CPU on which your code will run,
then you should use the corresponding -mtune option instead of
-mtune=generic. But, if you do not know exactly what CPU users
of your application will have, then you should use this option.
As new processors are deployed in the marketplace, the behavior
of this option will change. Therefore, if you upgrade to a
newer version of GCC, the code generated option will change to
reflect the processors that were most common when that version
of GCC was released.
There is no -march=generic option because -march indicates the
instruction set the compiler can use, and there is no generic
instruction set applicable to all processors. In contrast,
-mtune indicates the processor (or, in this case, collection of
processors) for which the code is optimized.
...
i686
Same as "generic", but when used as "march" option, PentiumPro
instruction set will be used, so the code will run on all i686
family chips.
> Why not go along a supported way, and do a cross-build?
There is nothing wrong about the day he does it.
And a classic cross-build won't help with setting i586 or lower that he needs:
i586, pentium
Intel Pentium CPU with no MMX support.
Just my 2 cents.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Fix CFLAGS overwrite by Makefile
On Tuesday, May 24, 2011 5:30:37 pm Arnaud Lacombe wrote: > Hi, > > On Tue, May 24, 2011 at 4:41 PM, Dimitry Andric wrote: > > On 2011-05-24 22:09, Arnaud Lacombe wrote: > >> > >> Many Makefile (espectially under sys/boot/) overwrite the value of CFLAGS. > >> This is an issue if you want to generate code for a specific CPU as before > >> the > >> Makefile is interpreted, CFLAGS might already have been set with CPU > >> specific > >> settings by, which is source from sys.mk. > > > > ... > >> > >> --- a/sys/boot/i386/boot2/Makefile > >> +++ b/sys/boot/i386/boot2/Makefile > > > > ... > > > > The problem with this patch is that for some of the things you fixed, > > stuff like boot-time programs, you NEVER want any CPU specific settings! > > You must use the default, lowest common denominator setting instead, or > > there is no guarantee the boot program will be correct. > > > To use your argument against you: with the default, the boot program > is not correct (see below). Thousands of machines succesfully booting FreeBSD would seem to contradict your assertion. > > So that is why these Makefiles purposefully overwrite CFLAGS. it is not > > by accident. > You just might be right, but unless the code say the overwrite is > _on_purpose_, I would not assume the state of mind of the author, one > way or another. The boot code is certainly intended to be something that works across the board. Also, I doubt you will see any user-visible performance difference from changing the optimization options for the boot code. > > Besides, for space-constrained things like boot2, you > > might not even be able to compile it when using non-standard settings, > > since the code might grow too large. > > > or can shrink by using more optimized instructions. Well, your test in a later e-mail is a bit flawed. GCC tends to insert a lot of padding for newer CPUs to align things on more optimal boundaries. We run 'sed' over the assembly version of boot2 to strip all that out. However, the more important point for the boot code is that it needs to just work. > The original trouble I met, is that building for an i586 target in a > 32bits jail, on top of an amd64 system[0] (I do not have control over > that setup) produces incorrect binaries. The current fix I've got is > to define MACHINE_ARCH=i386 and CPUTYPE=i586. This enforces > `-march=i586' to be passed to the compiler, for all except the > bootloader (because it overwrites CFLAGS). With this, binaries > produced works fine (ie. /bin/sh no longer SIGILL when bringing up the > system). So I suspect that gcc default to i686 in this setup and > corrupt all the binaries, thus the attached patch. Wait. You must have something wrong in your jail if you can't do a buildworld with CPUTYPE set to none and have it do the right thing. You need to find your root problem. Forcing CPUCFLAGS for the boot code is a band-aid, it's not the right solution to your problem. It may be that your jail is not a pure 32-bit jail (some things like a 32-bit ps won't really work in with a 64-bit host for example). Also, until recently, the machine_arch sysctl reported amd64 for 32-bit binaries. That was recently changed and might also help your world build to be more correct. You could also try doing 'make buildworld TARGET=i386' in a 64-bit jail. However, one question is what problem are you trying to solve? -- John Baldwin ___ 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: [PATCH] Fix CFLAGS overwrite by Makefile
Hi, On Wed, May 25, 2011 at 9:43 AM, John Baldwin wrote: >> The original trouble I met, is that building for an i586 target in a >> 32bits jail, on top of an amd64 system[0] (I do not have control over >> that setup) produces incorrect binaries. The current fix I've got is >> to define MACHINE_ARCH=i386 and CPUTYPE=i586. This enforces >> `-march=i586' to be passed to the compiler, for all except the >> bootloader (because it overwrites CFLAGS). With this, binaries >> produced works fine (ie. /bin/sh no longer SIGILL when bringing up the >> system). So I suspect that gcc default to i686 in this setup and >> corrupt all the binaries, thus the attached patch. > > Wait. You must have something wrong in your jail if you can't do a buildworld > with CPUTYPE set to none and have it do the right thing. You need to find > your root problem. Forcing CPUCFLAGS for the boot code is a band-aid, it's > not the right solution to your problem. > Unless error of my part, I never mentioned it was using `buildworld', which it is not. The system uses bare calls to make(1) in the sys/boot/ directory. As the jail is 32bits, it was expected not to be an issue, but the jail compiler uses /lib/libstand.a to link the loader, and it obviously contains i686-only instructions, which trigger a reset of an i586-only CPU. The more broad issue with the setup is that gcc within that environment, without being told -march=i586, produces i686 instructions which are incompatible with the target CPU. - Arnaud ___ 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: [PATCH] Fix CFLAGS overwrite by Makefile
Hi, On Wed, May 25, 2011 at 9:43 AM, John Baldwin wrote: > On Tuesday, May 24, 2011 5:30:37 pm Arnaud Lacombe wrote: >> Hi, >> >> On Tue, May 24, 2011 at 4:41 PM, Dimitry Andric wrote: >> > On 2011-05-24 22:09, Arnaud Lacombe wrote: >> >> >> >> Many Makefile (espectially under sys/boot/) overwrite the value of > CFLAGS. >> >> This is an issue if you want to generate code for a specific CPU as > before >> >> the >> >> Makefile is interpreted, CFLAGS might already have been set with CPU >> >> specific >> >> settings by, which is source from sys.mk. >> > >> > ... >> >> >> >> --- a/sys/boot/i386/boot2/Makefile >> >> +++ b/sys/boot/i386/boot2/Makefile >> > >> > ... >> > >> > The problem with this patch is that for some of the things you fixed, >> > stuff like boot-time programs, you NEVER want any CPU specific settings! >> > You must use the default, lowest common denominator setting instead, or >> > there is no guarantee the boot program will be correct. >> > >> To use your argument against you: with the default, the boot program >> is not correct (see below). > > Thousands of machines succesfully booting FreeBSD would seem to contradict > your assertion. > my assertion is backed by experiment, so I'm fine with the contradiction. >> > So that is why these Makefiles purposefully overwrite CFLAGS. it is not >> > by accident. >> You just might be right, but unless the code say the overwrite is >> _on_purpose_, I would not assume the state of mind of the author, one >> way or another. > > The boot code is certainly intended to be something that works across the > board. Also, I doubt you will see any user-visible performance difference > from changing the optimization options for the boot code. > Saving a few kilobytes of space might be more important than speed in some environment. >> > Besides, for space-constrained things like boot2, you >> > might not even be able to compile it when using non-standard settings, >> > since the code might grow too large. >> > >> or can shrink by using more optimized instructions. > > Well, your test in a later e-mail is a bit flawed. GCC tends to insert > a lot of padding for newer CPUs to align things on more optimal boundaries. > That does not explain at all why the default setting always produces the worst code, size-wise. > We run 'sed' over the assembly version of boot2 to strip all that out. > ... to save 4 bytes. > However, the more important point for the boot code is that it needs to > just work. > and it does not, because gcc defaults are _bad_. - Arnaud ___ 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: [rfc] remove hlt_cpus et al sysctls and related code
on 23/05/2011 19:28 Andriy Gapon said the following: > I propose the following path for moving forward. > - use hint.lapic.X.disabled to disable individual CPUs by their APIC ID > - use machdep.hyperthreading_allowed tunable to disable second logical CPU on > each > real core > > The above should already work as expected. One thing is that currently we > have > handling of machdep.hyperthreading_allowed tunable under SCHED_ULE. I plan to > make it unconditional. > > Things to remove: > - all the related sysctls for dynamic onlining/offlining > - machdep.hlt_logical_cpus tunable (it duplicates hint.lapic.X.disabled) > > It's possible to keep machdep.hlt_logical_cpus and just add some code to > convert > hlt_logical_cpus mask to a set of individual hint.lapic.X.disabled, but I > don't > see very much value in that. But if there is a good reason to keep that > tunable, > I am prepared to jump through this hoop. > > If no one objects to this proposal, I will provide a patch soon. The patch is here: http://people.freebsd.org/~avg/cpu-offline-sysctl.diff It should implement the strategy described above. I have mp_watchdog alone for now. It seems to have the same issues with respect to dynamic CPU state change. Besides its compilation is disabled when SCHED_ULE is enabled. mp_watchdog is a nice idea, but I wonder if anyone actually uses it (with success). -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Fix CFLAGS overwrite by Makefile
On Wednesday, May 25, 2011 11:34:29 am Arnaud Lacombe wrote: > Hi, > > On Wed, May 25, 2011 at 9:43 AM, John Baldwin wrote: > >> The original trouble I met, is that building for an i586 target in a > >> 32bits jail, on top of an amd64 system[0] (I do not have control over > >> that setup) produces incorrect binaries. The current fix I've got is > >> to define MACHINE_ARCH=i386 and CPUTYPE=i586. This enforces > >> `-march=i586' to be passed to the compiler, for all except the > >> bootloader (because it overwrites CFLAGS). With this, binaries > >> produced works fine (ie. /bin/sh no longer SIGILL when bringing up the > >> system). So I suspect that gcc default to i686 in this setup and > >> corrupt all the binaries, thus the attached patch. > > > > Wait. You must have something wrong in your jail if you can't do a buildworld > > with CPUTYPE set to none and have it do the right thing. You need to find > > your root problem. Forcing CPUCFLAGS for the boot code is a band-aid, it's > > not the right solution to your problem. > > > Unless error of my part, I never mentioned it was using `buildworld', > which it is not. The system uses bare calls to make(1) in the > sys/boot/ directory. As the jail is 32bits, it was expected not to be > an issue, but the jail compiler uses /lib/libstand.a to link the > loader, and it obviously contains i686-only instructions, which > trigger a reset of an i586-only CPU. > > The more broad issue with the setup is that gcc within that > environment, without being told -march=i586, produces i686 > instructions which are incompatible with the target CPU. Huh? GCC does not generate i686 instructions by default on FreeBSD/i386. It generates i486 instructions but that is all. Are you sure you aren't running the 64-bit gcc (which will generate i686 instructions by default)? -- John Baldwin ___ 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: [rfc] remove hlt_cpus et al sysctls and related code
On Wed, May 25, 2011 at 9:15 AM, Andriy Gapon wrote: > on 23/05/2011 19:28 Andriy Gapon said the following: >> I propose the following path for moving forward. >> - use hint.lapic.X.disabled to disable individual CPUs by their APIC ID >> - use machdep.hyperthreading_allowed tunable to disable second logical CPU >> on each >> real core >> >> The above should already work as expected. One thing is that currently we >> have >> handling of machdep.hyperthreading_allowed tunable under SCHED_ULE. I plan >> to >> make it unconditional. >> >> Things to remove: >> - all the related sysctls for dynamic onlining/offlining >> - machdep.hlt_logical_cpus tunable (it duplicates hint.lapic.X.disabled) >> >> It's possible to keep machdep.hlt_logical_cpus and just add some code to >> convert >> hlt_logical_cpus mask to a set of individual hint.lapic.X.disabled, but I >> don't >> see very much value in that. But if there is a good reason to keep that >> tunable, >> I am prepared to jump through this hoop. >> >> If no one objects to this proposal, I will provide a patch soon. > > The patch is here: > http://people.freebsd.org/~avg/cpu-offline-sysctl.diff > It should implement the strategy described above. > > I have mp_watchdog alone for now. It seems to have the same issues with > respect > to dynamic CPU state change. Besides its compilation is disabled when > SCHED_ULE > is enabled. mp_watchdog is a nice idea, but I wonder if anyone actually uses > it > (with success). I'll have to test out the patch, but at first glance it seems ok (at least the machdep.hyperthreading_allowed changes which $WORK depends upon). Thanks! -Garrett ___ 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: [PATCH] Fix CFLAGS overwrite by Makefile
on 25/05/2011 19:28 John Baldwin said the following: > On Wednesday, May 25, 2011 11:34:29 am Arnaud Lacombe wrote: >> The more broad issue with the setup is that gcc within that >> environment, without being told -march=i586, produces i686 >> instructions which are incompatible with the target CPU. > > Huh? GCC does not generate i686 instructions by default on FreeBSD/i386. It > generates i486 instructions but that is all. Are you sure you aren't running > the 64-bit gcc (which will generate i686 instructions by default)? Just curious if Arnaud has forgot to set UNAME_m="i386" UNAME_p="i386" in the environment of his build shell within the jail. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Fix CFLAGS overwrite by Makefile
Hi, On Wed, May 25, 2011 at 12:28 PM, John Baldwin wrote: > On Wednesday, May 25, 2011 11:34:29 am Arnaud Lacombe wrote: >> Hi, >> >> On Wed, May 25, 2011 at 9:43 AM, John Baldwin wrote: >> >> The original trouble I met, is that building for an i586 target in a >> >> 32bits jail, on top of an amd64 system[0] (I do not have control over >> >> that setup) produces incorrect binaries. The current fix I've got is >> >> to define MACHINE_ARCH=i386 and CPUTYPE=i586. This enforces >> >> `-march=i586' to be passed to the compiler, for all except the >> >> bootloader (because it overwrites CFLAGS). With this, binaries >> >> produced works fine (ie. /bin/sh no longer SIGILL when bringing up the >> >> system). So I suspect that gcc default to i686 in this setup and >> >> corrupt all the binaries, thus the attached patch. >> > >> > Wait. You must have something wrong in your jail if you can't do a > buildworld >> > with CPUTYPE set to none and have it do the right thing. You need to find >> > your root problem. Forcing CPUCFLAGS for the boot code is a band-aid, > it's >> > not the right solution to your problem. >> > >> Unless error of my part, I never mentioned it was using `buildworld', >> which it is not. The system uses bare calls to make(1) in the >> sys/boot/ directory. As the jail is 32bits, it was expected not to be >> an issue, but the jail compiler uses /lib/libstand.a to link the >> loader, and it obviously contains i686-only instructions, which >> trigger a reset of an i586-only CPU. >> >> The more broad issue with the setup is that gcc within that >> environment, without being told -march=i586, produces i686 >> instructions which are incompatible with the target CPU. > > Huh? GCC does not generate i686 instructions by default on FreeBSD/i386. It > generates i486 instructions but that is all. something is odd somewhere. > Are you sure you aren't running > the 64-bit gcc (which will generate i686 instructions by default)? > yes. # which gcc /usr/bin/gcc # file /usr/bin/gcc /usr/bin/gcc: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 7.1, statically linked, FreeBSD-style, stripped # gcc -v Using built-in specs. Target: i386-undermydesk-freebsd Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] # uname -a FreeBSD build 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May 1 07:18:07 UTC 2009 r...@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 The fact that /usr/bin/gcc is statically linked made me think we may have built internally, but it is also statically linked on a 8.2 machine from release packages. - Arnaud ___ 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"
Weird issue with hastd(8)
Hi Pawel, I am observing strange errors while synchronizing the data between primary and secondary. I keep getting the following error messages: May 25 11:09:19 eights hastd[10113]: [test] (secondary) Unable to receive request header: Socket is not connected. May 25 11:09:24 eights hastd[37571]: [test] (secondary) Worker process exited ungracefully (pid=10113, exitcode=75). May 25 11:10:17 eights hastd[12109]: [test] (secondary) Unable to receive request header: Socket is not connected. May 25 11:10:18 eights hastd[37571]: [test] (secondary) Worker process exited ungracefully (pid=12109, exitcode=75). May 25 11:10:39 eights hastd[14685]: [test] (secondary) Unable to receive request header: Socket is not connected. May 25 11:10:44 eights hastd[37571]: [test] (secondary) Worker process exited ungracefully (pid=14685, exitcode=75). The synchronization steel proceeds, but it's slow due to the need to re-negotiate and re-spawn the secondary worker. I have tried to ktrace both server and client at the same time. For some reason the primary keeps sending data, while client gets 0-read from the recvfrom at some point, while the primary keeps sending more data. This is 8-STABLE code on both ends. Any ideas of what could be wrong here are appreciated. -Maxim ___ 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: Weird issue with hastd(8)
On 5/25/2011 11:21 AM, Maxim Sobolev wrote: Hi Pawel, I am observing strange errors while synchronizing the data between primary and secondary. I keep getting the following error messages: May 25 11:09:19 eights hastd[10113]: [test] (secondary) Unable to receive request header: Socket is not connected. May 25 11:09:24 eights hastd[37571]: [test] (secondary) Worker process exited ungracefully (pid=10113, exitcode=75). May 25 11:10:17 eights hastd[12109]: [test] (secondary) Unable to receive request header: Socket is not connected. May 25 11:10:18 eights hastd[37571]: [test] (secondary) Worker process exited ungracefully (pid=12109, exitcode=75). May 25 11:10:39 eights hastd[14685]: [test] (secondary) Unable to receive request header: Socket is not connected. May 25 11:10:44 eights hastd[37571]: [test] (secondary) Worker process exited ungracefully (pid=14685, exitcode=75). The synchronization steel proceeds, but it's slow due to the need to re-negotiate and re-spawn the secondary worker. I have tried to ktrace both server and client at the same time. For some reason the primary keeps sending data, while client gets 0-read from the recvfrom at some point, while the primary keeps sending more data. This is 8-STABLE code on both ends. Any ideas of what could be wrong here are appreciated. Sorry, forgot the traces. Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts Tel: +1-646-651-1110 Fax: +1-866-857-6942 Web: http://www.sippysoft.com MSN: sa...@sippysoft.com Skype: SippySoft 83257 hastd1306344078.593820 CALL recvfrom(0x7,0x80360d400,0x8c,MSG_WAITALL,0,0) 83257 hastd1306344078.593825 GIO fd 7 read 140 bytes 0x 0204 0100 636d 6400 0068 0200 0804 0800 7365 7100 0068 |..cmd..hseq..h| 0x0022 0100 0807 0800 6f66 6673 6574 2040 0807 |offset @..| 0x0044 0800 6c65 6e67 7468 0200 110c 0400 636f 6d70 7265 7373 |lengthcompress| 0x0066 696f 6e00 6c7a 6600 0605 0400 7369 7a65 0068 80e8 0100 |ion.lzf...size.h..| 0x0088 || 83257 hastd1306344078.593830 RET recvfrom 140/0x8c 83257 hastd1306344078.593851 CALL recvfrom(0x7,0x8030c4000,0x1e880,MSG_WAITALL,0,0) 83257 hastd1306344098.677645 GIO fd 7 read 4096 bytes 0x 0200 1f10 031a 0003 2403 2e03 3803 4200 034c 0356 0360 036a 0003 7403 7e03 8803 |..$...8.B..L.V.`.j..t.~...| 0x0022 9200 031f 9c03 a603 b003 ba00 03c4 03ce 03d8 03e2 0003 ec03 f603 f518 1600 65bb 124e |..e..N| 0x0044 378d 1f11 8f00 b402 0700 0103 0402 0200 96a4 939a ba28 ac5b 6400 1401 0814 0a03 |7..(.[d...| [...] 0x0ff0 7c26 017d 2601 7e20 0c09 7f26 0180 2601 ||&.}&.~ ...&..&.| 83257 hastd1306344098.677664 RET recvfrom 125056/0x1e880 83257 hastd1306344098.678035 CALL _umtx_op(0x801223120,0x9,0,0,0) 83257 hastd1306344098.678046 RET _umtx_op 0 83257 hastd1306344098.678048 RET _umtx_op 0 83257 hastd1306344098.678050 CALL recvfrom(0x7,0x7f9fdf70,0x5,MSG_WAITALL,0,0) 83257 hastd1306344098.678057 GIO fd 7 read 0 bytes "" 83257 hastd1306344098.678060 RET recvfrom 0 83257 hastd1306344098.678064 CALL pwrite(0x4,0x8030c4000,0x2,0x40208a00) 83257 hastd1306344098.678097 CALL stat(0x7f9fd590,0x7f9fd510) 83257 hastd1306344098.678102 NAMI "/usr/share/nls/C/libc.cat" 83257 hastd1306344098.678108 RET stat -1 errno 2 No such file or directory 83257 hastd1306344098.678111 CALL stat(0x7f9fd590,0x7f9fd510) 83257 hastd1306344098.678115 NAMI "/usr/share/nls/libc/C" 83257 hastd1306344098.678121 RET stat -1 errno 2 No such file or directory 83257 hastd1306344098.678123 GIO fd 4 wrote 4096 bytes 0x 1003 1a00 0324 032e 0338 0342 0003 4c03 5603 6003 6a00 0374 037e 0388 0392 0003 9c03 |.$...8.B..L.V.`.j..t.~| 0x0022 a603 b003 ba00 03c4 03ce 03d8 03e2 0003 ec03 f603 f518 1600 65bb 124e 378d 118f 00b4 |e..N7.| 0x0044 0207 0001 0304 0200 0002 0096 a493 9aba 28ac 5b64 0014 0108 140a 0300 0403 ea39 239c |(.[d...9#.| [...] 0x0f8a 0a60 014a 011c 011c 0126 0130 013a 0001 4401 4e01 5801 6200 016c 0176 0180 018a |.`.J...&.0.:..D.N.X.b..l.v| 0x0fac 0001 9401 9e01 a801 b200 01bc 01c6 01d0 01da 0001 e401 ee01 f802 0200 020c 0216 0220 |. | 0x0fce 022a 0002 3402 3e02 4802 5200 025c 0266 0270 027a 0002 8402 8e02 9802 a200 02ac 02b6 |.*..4.>.H.R..\.f.p.z..| 0x0ff0 02c0 02ca
Re: [PATCH] Fix CFLAGS overwrite by Makefile
On Wed, May 25, 2011 at 09:43:15AM -0400, John Baldwin wrote: > It may be that your jail is not a pure 32-bit jail (some things like a 32-bit > ps won't really work in with a 64-bit host for example). Also, until Err, is it broken (again) ? I committed the 32bit compat shims for kinfo_proc long time ago, and do have ps working in 32bit jail in stable/8. > recently, the machine_arch sysctl reported amd64 for 32-bit binaries. That > was recently changed and might also help your world build to be more correct. > You could also try doing 'make buildworld TARGET=i386' in a 64-bit jail. > However, one question is what problem are you trying to solve? pgpFpeV5knWr5.pgp Description: PGP signature
Re: Weird issue with hastd(8)
On 25.5.2011 20:24, Maxim Sobolev wrote: On 5/25/2011 11:21 AM, Maxim Sobolev wrote: Hi Pawel, I am observing strange errors while synchronizing the data between primary and secondary. I keep getting the following error messages: May 25 11:09:19 eights hastd[10113]: [test] (secondary) Unable to receive request header: Socket is not connected. May 25 11:09:24 eights hastd[37571]: [test] (secondary) Worker process exited ungracefully (pid=10113, exitcode=75). May 25 11:10:17 eights hastd[12109]: [test] (secondary) Unable to receive request header: Socket is not connected. May 25 11:10:18 eights hastd[37571]: [test] (secondary) Worker process exited ungracefully (pid=12109, exitcode=75). May 25 11:10:39 eights hastd[14685]: [test] (secondary) Unable to receive request header: Socket is not connected. May 25 11:10:44 eights hastd[37571]: [test] (secondary) Worker process exited ungracefully (pid=14685, exitcode=75). I can only confirm this behavior. I have already reported this to Mikolaj and we are trying to hunt down the problem. I have started observing suddenly after some update. Unfortunately I haven't noted which revision I started to observe this bug ;( Do you happen to use some net.inet sysctls/tunables? The synchronization steel proceeds, but it's slow due to the need to re-negotiate and re-spawn the secondary worker. I have tried to ktrace both server and client at the same time. For some reason the primary keeps sending data, while client gets 0-read from the recvfrom at some point, while the primary keeps sending more data. This is 8-STABLE code on both ends. Any ideas of what could be wrong here are appreciated. Sorry, forgot the traces. Regards, ___ 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" -- S pozdravom / Best regards Daniel Gerzo, FreeBSD committer ___ 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: [PATCH] Fix CFLAGS overwrite by Makefile
On Wednesday, May 25, 2011 1:03:10 pm Arnaud Lacombe wrote: > Hi, > > On Wed, May 25, 2011 at 12:28 PM, John Baldwin wrote: > > On Wednesday, May 25, 2011 11:34:29 am Arnaud Lacombe wrote: > >> Hi, > >> > >> On Wed, May 25, 2011 at 9:43 AM, John Baldwin wrote: > >> >> The original trouble I met, is that building for an i586 target in a > >> >> 32bits jail, on top of an amd64 system[0] (I do not have control over > >> >> that setup) produces incorrect binaries. The current fix I've got is > >> >> to define MACHINE_ARCH=i386 and CPUTYPE=i586. This enforces > >> >> `-march=i586' to be passed to the compiler, for all except the > >> >> bootloader (because it overwrites CFLAGS). With this, binaries > >> >> produced works fine (ie. /bin/sh no longer SIGILL when bringing up the > >> >> system). So I suspect that gcc default to i686 in this setup and > >> >> corrupt all the binaries, thus the attached patch. > >> > > >> > Wait. You must have something wrong in your jail if you can't do a > > buildworld > >> > with CPUTYPE set to none and have it do the right thing. You need to find > >> > your root problem. Forcing CPUCFLAGS for the boot code is a band-aid, > > it's > >> > not the right solution to your problem. > >> > > >> Unless error of my part, I never mentioned it was using `buildworld', > >> which it is not. The system uses bare calls to make(1) in the > >> sys/boot/ directory. As the jail is 32bits, it was expected not to be > >> an issue, but the jail compiler uses /lib/libstand.a to link the > >> loader, and it obviously contains i686-only instructions, which > >> trigger a reset of an i586-only CPU. > >> > >> The more broad issue with the setup is that gcc within that > >> environment, without being told -march=i586, produces i686 > >> instructions which are incompatible with the target CPU. > > > > Huh? GCC does not generate i686 instructions by default on FreeBSD/i386. It > > generates i486 instructions but that is all. > something is odd somewhere. > > > Are you sure you aren't running > > the 64-bit gcc (which will generate i686 instructions by default)? > > > yes. > > # which gcc > /usr/bin/gcc > > # file /usr/bin/gcc > /usr/bin/gcc: ELF 32-bit LSB executable, Intel 80386, version 1 > (FreeBSD), for FreeBSD 7.1, statically linked, FreeBSD-style, stripped > > # gcc -v > Using built-in specs. > Target: i386-undermydesk-freebsd > Configured with: FreeBSD/i386 system compiler > Thread model: posix > gcc version 4.2.1 20070719 [FreeBSD] > > # uname -a > FreeBSD build 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May 1 07:18:07 > UTC 2009 r...@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > amd64 ^ I think this is probably going to confuse make and some other things as well. -- John Baldwin ___ 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: [PATCH] Fix CFLAGS overwrite by Makefile
Hi, On Wed, May 25, 2011 at 3:44 PM, John Baldwin wrote: > On Wednesday, May 25, 2011 1:03:10 pm Arnaud Lacombe wrote: >> Hi, >> >> On Wed, May 25, 2011 at 12:28 PM, John Baldwin wrote: >> > On Wednesday, May 25, 2011 11:34:29 am Arnaud Lacombe wrote: >> >> Hi, >> >> >> >> On Wed, May 25, 2011 at 9:43 AM, John Baldwin wrote: >> >> >> The original trouble I met, is that building for an i586 target in a >> >> >> 32bits jail, on top of an amd64 system[0] (I do not have control over >> >> >> that setup) produces incorrect binaries. The current fix I've got is >> >> >> to define MACHINE_ARCH=i386 and CPUTYPE=i586. This enforces >> >> >> `-march=i586' to be passed to the compiler, for all except the >> >> >> bootloader (because it overwrites CFLAGS). With this, binaries >> >> >> produced works fine (ie. /bin/sh no longer SIGILL when bringing up the >> >> >> system). So I suspect that gcc default to i686 in this setup and >> >> >> corrupt all the binaries, thus the attached patch. >> >> > >> >> > Wait. You must have something wrong in your jail if you can't do a >> > buildworld >> >> > with CPUTYPE set to none and have it do the right thing. You need to > find >> >> > your root problem. Forcing CPUCFLAGS for the boot code is a band-aid, >> > it's >> >> > not the right solution to your problem. >> >> > >> >> Unless error of my part, I never mentioned it was using `buildworld', >> >> which it is not. The system uses bare calls to make(1) in the >> >> sys/boot/ directory. As the jail is 32bits, it was expected not to be >> >> an issue, but the jail compiler uses /lib/libstand.a to link the >> >> loader, and it obviously contains i686-only instructions, which >> >> trigger a reset of an i586-only CPU. >> >> >> >> The more broad issue with the setup is that gcc within that >> >> environment, without being told -march=i586, produces i686 >> >> instructions which are incompatible with the target CPU. >> > >> > Huh? GCC does not generate i686 instructions by default on FreeBSD/i386. > It >> > generates i486 instructions but that is all. >> something is odd somewhere. >> >> > Are you sure you aren't running >> > the 64-bit gcc (which will generate i686 instructions by default)? >> > >> yes. >> >> # which gcc >> /usr/bin/gcc >> >> # file /usr/bin/gcc >> /usr/bin/gcc: ELF 32-bit LSB executable, Intel 80386, version 1 >> (FreeBSD), for FreeBSD 7.1, statically linked, FreeBSD-style, stripped >> >> # gcc -v >> Using built-in specs. >> Target: i386-undermydesk-freebsd >> Configured with: FreeBSD/i386 system compiler >> Thread model: posix >> gcc version 4.2.1 20070719 [FreeBSD] >> >> # uname -a >> FreeBSD build 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May 1 07:18:07 >> UTC 2009 r...@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC >> amd64 > ^ > > I think this is probably going to confuse make and some other things as well. > This is what I meant when I said "canadian setup". HOST=amd64, BUIILD=i386 and TARGET=i586. I'm now trying to track down the original instruction triggering the SIGILL, but it is in a library and that section of the memory does not seem to be included in the core. Moreover I do not think I have any way on a broken system to get the address at which libraries get loaded (understand that ldd(1) is dynamically linked, and as the libc the likely culprit, rendering ldd(1) useless). - Arnaud ___ 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: [PATCH] Fix CFLAGS overwrite by Makefile
Hi, On Wed, May 25, 2011 at 4:10 PM, Arnaud Lacombe wrote: > I'm now trying to track down the original instruction triggering the > SIGILL, but it is in a library and that section of the memory does not > seem to be included in the core. Moreover I do not think I have any > way on a broken system to get the address at which libraries get > loaded (understand that ldd(1) is dynamically linked, and as the libc > the likely culprit, rendering ldd(1) useless). > ok, the reason the whole system appears broken is because `/libexec/ld-elf.so.1' is broken, it contains several CMOV instructions. The objects it is made from are clear from any CMOV, so this code likely comes from the jail's lib. I guess that the responsible for building the jail environment had the wonderful idea to use the host /usr/lib32 and put them in the jail /usr/lib, without knowing that those libraries are i686-optimized, That also explain the /boot/loader brokenness which links against the jail's libstand.a. - Arnaud ___ 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: Weird issue with hastd(8)
On 5/25/2011 12:07 PM, Daniel Gerzo wrote: I can only confirm this behavior. I have already reported this to Mikolaj and we are trying to hunt down the problem. I have started observing suddenly after some update. Unfortunately I haven't noted which revision I started to observe this bug ;( Do you happen to use some net.inet sysctls/tunables? Not really. The only sysctls we override are UDP ones: net.inet.udp.blackhole=1 # --SSP-- net.inet.udp.recvspace=332800 # --SSP-- net.inet.udp.maxdgram=57344 # --SSP-- net.link.ether.inet.log_arp_wrong_iface=0 # - But at least it is good to know that we are not alone with this issue. -Maxim ___ 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"
