Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 18 Jul 1997 17:50:40 -0700
From:      Amancio Hasty <hasty@rah.star-gate.com>
To:        Wm Brian McCane <root@bmccane.uit.net>
Cc:        hackers@FreeBSD.ORG
Subject:   Re: Strange SCSI problem 
Message-ID:  <199707190050.RAA07456@rah.star-gate.com>
In-Reply-To: Your message of "Fri, 18 Jul 1997 11:42:18 CDT." <199707181642.LAA17049@bmccane.uit.net> 

next in thread | previous in thread | raw e-mail | index | archive | help

Hi,

We need a couple of things, a sample run with tracing enable:

setenv SANE_DEBUG_UMAX 128
scsi -f device -d 255

The actual code which takes care of sending the scsi request is in
sane/sanei/sanei_scsi.c:

  result = scsireq_enter (fd, &hdr);
  if (result < 0)
    {
      DBG(1, "sanei_scsi_cmd: scsi_reqenter() failed: %s\n", strerror (errno));
      return SANE_STATUS_IO_ERROR;
    }
  if (hdr.retsts != SCCMD_OK)
    {
      DBG(1, "sanei_scsi_cmd: scsi returned with status %d\n", hdr.retsts);
      switch (hdr.retsts)
	{
	case SCCMD_TIMEOUT:
	case SCCMD_BUSY:
	  return SANE_STATUS_DEVICE_BUSY;

	case SCCMD_SENSE:
	  if (fd < num_handlers_alloced && sense_handler[fd])
	    return (*sense_handler[fd]) (fd, &hdr.sense[0]);
	  /* fall through */
	default:
	  return SANE_STATUS_IO_ERROR;
	}
    }
You can always add additional error logging if you like.

The trace is important because it will let us know if something before
failed which causes the scanner not to  respond.

Also, do you have target queueing enabled in your scsi driver?

OS version, scsi controller and if you have any other devices on
the scsi bus.


	Tnks,
	Amancio

>From The Desk Of Wm Brian McCane :
> Howdy,
> 
> I have built `gimp' on my system, and also have built `sane'.  Sane is a 
> scanner interface program that directly accesses the SCSI `uk0' device to get
 
> data from the scanner.  Anyway, to make a long story short, when I try to use
 
> `sane', it doesn't get any data from the scanner.  The `scsireq_enter' return
s 
> a success status, and that there were 96 bytes read, but the buffer contains 
> the data that was in it when the function was called.  To experiment with 
> this, I used the `scsi' command:
> 	scsi -f /dev/uk0 -c "12 0 0 0 60 0" -i 96 "i4 i4 i4 i4 i4 i4 i4 i4"
> It reports 96 bytes read, but the buffer contains all 0's, because the `scsi'
 
> command bzero's the buffer before calling the `scsireq_enter' function.  I 
> have looked at the kernel code, and I can't find the problem, but I assume 
> that the data is not being copied into user space from kernel space.  Any 
> ideas?
> 
> 	brian
> 
> 





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707190050.RAA07456>