Short INQUIRY return

Short INQUIRY return

[Alexander Sabourenkov]

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

Re: Short INQUIRY return

[Boaz Harrosh]

On Thu, Oct 25 2007 at 15:03 +0200, Alexander Sabourenkov <screwdriver@lxnt.info> wrote:
> 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?
> 
> 

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

Re: Short INQUIRY return

[Alexander Sabourenkov]

Boaz Harrosh wrote:
> 
> 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)

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

> Just a shot in the dark

Thank you very much.

> (Where is the code for that driver?)

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