[Openmcl-devel] freebsd 9.1 amd64
cduret at gmail.com
Thu Feb 14 02:20:13 CST 2013
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
> me while running 9.1/amd64 under a VMware VM. (VMware made the VM appear
> 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
> 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
> 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
>>>>> in the CCL trunk. If people who can reproduce this could try the
>>>>> that'd be helpful.
>>>> I fresh checkout of trunk does the following on both of my virtual
>>>> $ ./fx86cl64
>>>> Unhandled exception 10 at 0x300001050b6b, context->regs at
>>>> received signal 10; faulting address: 0x300001050b6b
>>>> ? for help
>>>>  Clozure CL kernel debugger:
>>>> I installed misc/compat6x as stated in .
>>> 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.
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openmcl-devel