[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 17 Sep 2013 00:03:56 +0200
From: magnum <john.magnum@...hmail.com>
To: john-users@...ts.openwall.com
Subject: Re: --fork using different OpenCL devices
On 15 sep 2013, at 02:00, Solar Designer <solar@...nwall.com> wrote:
> On Mon, Sep 09, 2013 at 01:08:00AM +0200, magnum wrote:
>> On 8 aug 2013, at 05:30, Solar Designer <solar@...nwall.com> wrote:
>>> Unfortunately, in the
>>> current implementation of --fork there's some use of signals - such as
>>> to get the status line printed by all children on a keypress - and this
>>> appears incompatible with AMD's SDK.
>>
>> How? Does it crash and burn or do we just not get the status print from children?
>
> It used to crash (on any signal sent between the processes) in the same
> way that it crashed on Ctrl-C (that is, with the
> "../../../thread/semaphore.cpp:87: sem_wait() failed" message). However,
> when I inadvertently invoked a GPU format along with --fork more
> recently (with Catalyst 13.6 beta on "well"), this crash somehow did not
> happen. I did not test it any further, so I don't know if it ran
> correctly in other aspects.
>
> You might want to do some testing with different Catalyst versions.
Apparently, both Bull's 13.4 and Well's 13.6beta work fine with timers, signals and keypresses. Maybe we don't even have to use OS_TIMER=0 anymore, or is that unrelated?
magnum
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
