Date: Tue, 26 Jun 2012 07:44:02 -0700 From: Bitweasil <bitweasil@...il.com> To: "john-dev@...ts.openwall.com" <john-dev@...ts.openwall.com> 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 <gat3way@...il.com> wrote: > > On Tue, Jun 26, 2012 at 2:54 AM, magnum <john.magnum@...hmail.com> 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.