[Openmcl-devel] freebsd 9.1 amd64

[Cyrille Duret]

mm it seems to be OK !

I will try deeper tests later and let you know if I have this problem again

Thank you for your work ;-)

On Thu, Feb 14, 2013 at 8:58 AM, Gary Byers <gb at clozure.com> wrote:

> I made a change to the trunk kernel source that seemed to fix the problem
> for
> me while running 9.1/amd64 under a VMware VM.  (VMware made the VM appear
> to
> have AVX.)  I wanted to try to test it on some real AVX-enabled hardware;
> unfortunately, the only AVX-enabled hardware I have has network adapters
> that were made less than 5 years ago and are therefore a total mystery to
> FreeBSD ...
>
> I'll keep wrestling with that (may be able to find a supported
> USB->ethernet
> or USB->wifi adapter); if people who use FreeBSD 9.1 on amd64 could test
> these changes, that'd be helpful.
>
> The changes are just in source in the trunk and they only affect the lisp
> kernel, so to test them you need to:
>
> 1) check out or "svn update" a copy of the "freebsdx86" tree from the
> trunk.
> 2) do:
>
>
> $ cd ccl/lisp-kernel/freebsdx8664
> $ make
> $ cd ../..
> $ ./fx86cl64
>
> I find that I can do things like:
>
> ? (dotimes (i 10) (rebuild-ccl :full t))
>
> reliably after those changes; before they were made, that would die on
> the first or second iteration with a cryptic message from the
> 'sigreturn' system call (often the same message that people have
> reported, occasionally something different but just as cryptic.)
>
> The old saying ("testing can confirm the presence of bugs but doesn't
> prove their absence") seems to apply here: I haven't been able to
> provoke the bug yet, but I'm not 100% confident that I understand why
> the change avoids the problem.  (The change has to do with how
> "alternate signal stacks" are allocated and the symptom has been that
> a stack-allocated data structure that describes the state of a thread
> when an exception occurs is apparently getting corrupted in some way
> so that it can't be used to restore the thread's state ("sigreturn")
> sometimes.  Those things are at least somewhat related, but I don't
> fully understand how one thing (the old way of allocating stacks for
> signal processing)  causes the other (corruption of the signal context.)
>
>
>
> On Sun, 10 Feb 2013, Mark Cox wrote:
>
>
>> On 10/02/2013, at 10:06 AM, R. Matthew Emerson wrote:
>>
>>
>>> On Feb 9, 2013, at 6:55 PM, Mark Cox <markcox80 at gmail.com> wrote:
>>>
>>>  On 09/02/2013, at 1:14 AM, Gary Byers wrote:
>>>>
>>>>  I was able to run 9.1 under VMware and think/hope that this is now
>>>>> fixed
>>>>> in the CCL trunk.  If people who can reproduce this could try the
>>>>> trunk,
>>>>> that'd be helpful.
>>>>>
>>>>
>>>> I fresh checkout of trunk does the following on both of my virtual
>>>> machines:
>>>>
>>>> $ ./fx86cl64
>>>> Unhandled exception 10 at 0x300001050b6b, context->regs at
>>>> #x7fffffffd280
>>>> received signal 10; faulting address: 0x300001050b6b
>>>> ? for help
>>>> [88099] Clozure CL kernel debugger:
>>>>
>>>> I installed misc/compat6x as stated in [1].
>>>>
>>>
>>> Can you please try it with a locally-built lisp kernel?  That is, do
>>>
>>> cd lisp-kernel/freebsdx8664 && make clean && make
>>>
>>
>> My apologies. I did not do this.
>>
>> The Core 2 Duo rebuilds fine, but the Core i7 signals the same error as
>> originally reported by Cyrille.
>>
>> Mark
>> ______________________________**_________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/**listinfo/openmcl-devel<http://clozure.com/mailman/listinfo/openmcl-devel>
>>
>>
>>  ______________________________**_________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/**listinfo/openmcl-devel<http://clozure.com/mailman/listinfo/openmcl-devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20130214/2634f137/attachment.htm>