The following reply was made to PR kern/31990; it has been noted by GNATS.

From: Manuel Bouyer <bouyer@antioche.eu.org>
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
Cc: gnats-bugs@NetBSD.org, kern-bug-people@NetBSD.org,
	gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: kern/31990: esiop leaves b_resid non-zero
Date: Fri, 4 Nov 2005 14:12:20 +0100

 On Fri, Nov 04, 2005 at 09:06:54AM +0900, YAMAMOTO Takashi wrote:
 > > > 		db> sh buf 0xfffffc001dde6458
 > > > 		  vp 0x0 lblkno 0xdeadbeefdeadbeef blkno 0x0 dev 0x802
 > > > 		  error 0 flags 0x1c0210<BUSY,DONE,PHYS,RAW,READ>
 > > > 		  bufsize 0x200 bcount 0x200 resid 0x200
 > > > 		  data 0x120018000 saveaddr 0x0 dep 0x0
 > > > 		  iodone 0xfffffc0000480420
 > > > 
 > > > 	after putting some printf,
 > > > 	esiop_intr seems to call esiop_scsicmd_end with offset == 0.
 > > 
 > > I don't see a problem here. Calling esiop_scsicmd_end with offset == 0 is
 > > valid, if the command didn't complete properly. Can you give more detail on
 > > what you see wrong here ?
 > 
 > i expect an error, if the command didn't complete properly.
 
 It's possible that the drive did complete the command without transfering
 any data. In this case I would expect it to return a CHECK CONDITION status,
 but it seems it doesn't. I'll have to check the standards, but I think the
 target is required to return CHECK CONDITION in this case.
 
 Can you turn on the various DEBUG bits in esiop.c and see what the drive
 returns in this case ? First you could add a printf() in esiop_scsicmd_end()
 to see what xs->status is.
 
 -- 
 Manuel Bouyer <bouyer@antioche.eu.org>
      NetBSD: 26 ans d'experience feront toujours la difference
 --