Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 26 Jun 2012 07:44:02 -0700
From: Bitweasil <>
To: "" <>
Subject: Re: OpenCL kernel max running time vs. "ASIC hang"

...was everyone on this list except me? Hi, gw. 

From what I've seen, I don't think writing out of bounds is responsible. If I simply change my runtime on my rainbow table generate kernels, I can trigger the bug or go for days without it happening. The only difference is how many steps it runs at a time. It's a very simple kernel, and the hangs were happening at the 10-15% done mark - long before it is anywhere near the bounds of an array. I've definitely gone romping through memory in the past, and I know it causes weird behavior, but my table gen kernels are the simplest and oldest kernels I have, and the steps per invocation value changes nothing about their memory access. 

I'd love to be proved wrong, though! If it were kernel bugs, that's a whole lot easier to deal with!

On Jun 26, 2012, at 0:02, Milen Rangelov <> wrote:

> On Tue, Jun 26, 2012 at 2:54 AM, magnum <> wrote:
> Yes only now, and I was thinking more like 16K rounds x16. Not sure I want to go there unless AMD says somewhere that this is actually a design limit. Maybe they do? I would like to know the exact specified limit.
> In fact I've tried this and it did not help. At present I am changing my whole architecture and refactoring plugins, working currently on "fast" ones. So I don't have much time to play with heavyweight kernels like rar or wpa. Anyway I am becoming more and more confident that the ASIC hangs are actually a result of kernel bugs - e.g out of bounds writes or something like that. 

Content of type "text/html" skipped

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.