Jochen wrote: And Roar wrote: I have got a very strong feeling I was wrong. (Sorry) In my experience with the SII chip you set up a buffer in its shared memory with the MSCP "packet" layed out, and the node number of where you wanted it to go at the front. Then you write the that address into the descriptor register and the SII chip picks it up and drops it off at the drive. In my case I was writing the equivalent of the SCSI INQUIRE command, and then a bit later, the SII chip interrupts you to tell you that there is a new descriptor in its buffers and if you look at it (which I did from the kernel debugger because I had just panic'd on the interrupt :-) you can see that the drive has returned to you the information you requested. Questions that were unanswered in my mind when I put this down about this time last year were: 1) maintaining the physical/virtual mapping between the 128KB buffer and main memory. 2) Hooking the MSCP code that was there so that it could fill in the packets. 3) Writing the bus "enumerator" for config so that I could create a device instance for each disk I found (tapes I would ignore for now) 4) Hooking send and receive queues through a top level structure that would feed/retrieve them from the SII chip. So I tried last night to get a 'diff' of my build tree from the cvs tree but since its from 1.5.1 pre-release, the number of diffs is _huge_ relative to the 1.5.2 tree. I'll put a tarball of my sys tree up later today for anyone who might want to look at it. What I've not been able to find was my code that set up the INQ command. It shouldn't be too hard to recreate however. --Chuck