Short INQUIRY return

Hello.

Background:
Promise TX4 SATA300 with sata_promise driver generates lots of errors,
both read and write.

I'm now trying to port Promise-written driver, which works ok with
2.6.11, to 2.6.22,
so that I can hopefully discover the error-inducing difference between
them, and gain
some understanding of kernel internals in the process.

I have somewhat cleaned up the horrible mess the Promise driver code
is, so that it compiles,
loads and attaches to the controller.

Problem:

Its internal port scan prints out correct information about hard
drive(s) discovered, and correctly
(i think) fills out response to the INQUIRY command, but when scsi
subsystem receives it back,
it contains some garbage instead.

The same code works ok on 2.6.11, and I think it would work ok up to
2.6.16 at least, but I have not checked yet.

Question:
Can anyone please point out some drastic change in SCSI subsystem (and what it would take to fix the driver up)
that would result in such behavior, so that I can save some time
digging it up myself?

./lxnt

Just at the top of my head without looking at the code at all. I would say the bigest change would be the use of use_sg != 0 for all commands in Later kernels. (k>=2.6.17)
Look for and around the scsi_cmnd->request_buffer usage. It used to be that for commands like INQUIRY it points to a linear char pointer. Today it will always point to a scatterlist array and use_sg is the sg count of that array. (Usually ==1 in the INQUIRY case)

Just a shot in the dark
(Where is the code for that driver?)
Boaz

That was it. Driver blindly wrote whatever number of bytes it felt like straight to the pointer.

I lifted some code from scsi_debug.c:

sgpnt = (struct scatterlist *)SCpnt->request_buffer; kaddr = (unsigned char *)kmap_atomic(sgpnt->page, KM_USER0); buff = kaddr + sgpnt->offset;
bufflen = sgpnt->length;

buf[...] = ...

kunmap_atomic(kaddr, KM_USER0);

which seemed to do the trick.
(is this the proper way or it works by some miracle only?)

I tried
dd if=/dev/sdc1 of=/dev/null bs=1048576 count=1024 and the kernel crashed. Not surprising.

Now up-hacking MODE_SENSE support based on drivers/usb/storage/datafab.c

Thank you very much.

I found it at promise.com:
http://www.promise.com/support/download/download2_eng.asp?productId=139&category=driver&os=100&go=GO

My current version is at http://lxnt.info/tx4/023/
(modified files only)

The code in cam subdirectory is quite clean - I suspect it is some OS-independent part that is used in Windows and BIOS too. I did not touch it.

./lxnt