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 y
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
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 a
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,
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 t
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
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 co
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[3757
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 am
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
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 seco
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) produce
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
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/) overwri
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_AR
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 gene
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/
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 |
18 matches
Mail list logo
