From owner-freebsd-hackers Fri Jan 30 11:41:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA02897 for hackers-outgoing; Fri, 30 Jan 1998 11:41:38 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from db2server.voga.com.br (db2server.voga.com.br [200.239.39.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA02475 for ; Fri, 30 Jan 1998 11:38:45 -0800 (PST) (envelope-from daniel_sobral@voga.com.br) From: daniel_sobral@voga.com.br Received: from papagaio.voga.com.br (papagaio.voga.com.br [200.239.39.2]) by db2server.voga.com.br (8.8.3+2.6Wbeta9/8.8.7) with SMTP id RAA20856 for ; Fri, 30 Jan 1998 17:12:00 -0200 Received: by papagaio.voga.com.br(Lotus SMTP MTA v1.06 (346.7 3-18-1997)) id 0325659C.006EF616 ; Fri, 30 Jan 1998 17:11:59 -0300 X-Lotus-FromDomain: VOGA To: hackers@FreeBSD.ORG Message-ID: <8325659C.006CFFB1.00@papagaio.voga.com.br> Date: Fri, 30 Jan 1998 17:11:55 -0300 Subject: Re: TRUSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe hackers" > truss *may* cause problems, timing wise -- the > target process is stopped until it is restarted, > and that may be a problem in your case. > Without more information, I can't quite say, > I'm afraid. Oops. Sorry. I have talked quite a bit about the driver last two weeks, so I ended up forgetting the context. This is an encryption card. The test program works like this: write(known-string) read(encrypted-string) write(encrypted-string) read(decrypted-string> Now, when the device receive a write() call, it moves the data to a buffer, starts the encryption/decryption through a timeout() call, and returns. Read() will wait until all data is converted, and then move it back from the buffer. In the test program, read() will always block, and will be wakeup()ed by the crypt() process, called by timeout(). So, what does crypt() do? Well, read a byte, write it to the device, read back from the device, store it, update pointers. It is actually a big switch() statement (dfa), because it will often have to timeout() itself again and return, since the device is very slow. Read() does have some critical regions (race conditions against crypt()), "solved" through splsoftclock(). Last of all, it happens that the decrypted-string will only differ on one of the modes (turbo). No matter what mode I test first, it will always be that mode the one to fail. Which is a strong hint that my code may be, in fact, buggy. I only asked because I don't know truss, I'm not sure if I can truss it (okay, bad pun, but you used it first on Dr. Dobbs!). I see only two possibilities (of the blame being with truss): corruption of either read() or write() data (extremely unlikely), or screwing up issues with splsoftclock(). Is it possible that truss screws up with splsoftclock() and, thus, the race condition get triggered on the turbo mode? I'll gather _much_ more data on this problem when I get back home, but, for now, the only data I can gather is more information on truss, from this list... :-) Happily, it seems that the author of truss actually subscribes to it, and it's indeed a very nice person... :-) Btw, if you're going to cc the message to me (or reply to me and cc to -hackers), please cc also to dcs@gns.com.br. -- Daniel C. Sobral (8-DCS) Daniel_Sobral@voga.com.br Tagline: * FreeBSD. Earth.