NetBSD Problem Report #2726

From gnats  Sun Sep  1 12:34:24 1996
Received: from falcon.dol-esa.gov by pain.lcs.mit.edu (8.7.5/8.7.3) with ESMTP id MAA02143 for <gnats-bugs@gnats.netbsd.org>; Sun, 1 Sep 1996 12:31:48 -0400 (EDT)
Message-Id: <199609011631.MAA16115@owl.dol-esa.gov>
Date: Sun, 1 Sep 1996 12:31:36 -0400 (EDT)
To: gnats-bugs@NetBSD.ORG
Cc: is@beverly.rhein.de
Subject: HP Scanjet driver patch for NetBSD/Amiga
X-Send-Pr-Version: 3.95

>Number:         2726
>Category:       port-amiga
>Synopsis:       HP Scanjet driver patch for NetBSD/Amiga
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-amiga-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Sep 01 12:35:00 +0000 1996
>Closed-Date:    
>Last-Modified:  Thu Jun 03 10:19:43 +0000 2021
>Originator:     Kenneth Stailey
>Release:        1.2_BETA
>Organization:
US DOL/ESA/DASM
>Environment:
System: NetBSD owl 1.2_BETA NetBSD 1.2_BETA (OWL) #3: Wed Aug 21 18:26:07 EDT 1996 kstailey@owl:/usr/src/sys/arch/i386/compile/OWL [960807] i386


>Description:
The scanjet_ctl_{read|write} routines do not set SCSI_POLL.  This seems to
have no effect on machines as fast as a i486DX2/66, but slower machines
hang probably because the SCSI operation is not done soon enough.
>How-To-Repeat:
Put an HP ScanJet on an amiga, rebooting will hang when scanjet_ctl_write()
calls scsi_scsi_cmd().
>Fix:
This was tested on i486 and amiga.  This is for /sys/scsi/ss_scanjet.c

The line numbers may be off if you have not yet applied my patch for
HP ScanJet 4P, kern/2663.

Note that amiga needed "loadbsd -I ff netbsd" too.

--- ss_scanjet.c.pre-amiga	Sat Aug 31 21:45:33 1996
+++ ss_scanjet.c	Sat Aug 31 21:46:12 1996
@@ -311,7 +311,7 @@
 	_lto3b(size, cmd.len);
 	return (scsi_scsi_cmd(ss->sc_link, (struct scsi_generic *) &cmd,
 	    sizeof(cmd), (u_char *) buf, size, 0, 100000, NULL,
-	    flags | SCSI_DATA_OUT));
+	    flags | SCSI_DATA_OUT | SCSI_POLL));
 }


@@ -332,7 +332,7 @@
 	_lto3b(size, cmd.len);
 	return (scsi_scsi_cmd(ss->sc_link, (struct scsi_generic *) &cmd,
 	    sizeof(cmd), (u_char *) buf, size, 0, 100000, NULL,
-	    flags | SCSI_DATA_IN));
+	    flags | SCSI_DATA_IN | SCSI_POLL));
 }


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: hwr 
State-Changed-When: Mon Apr 26 13:36:58 PDT 1999 
State-Changed-Why:  
Could you check if this is still true with the actual scsi code? 
State-Changed-From-To: feedback->suspended 
State-Changed-By: hwr 
State-Changed-When: Tue Apr 27 03:17:44 PDT 1999 
State-Changed-Why:  
This is more a problem with the Amiga SCSI-driver 


Responsible-Changed-From-To: kern-bug-people->port-amiga-maintainer 
Responsible-Changed-By: hwr 
Responsible-Changed-When: Tue Apr 27 03:17:44 PDT 1999 
Responsible-Changed-Why:  
This is an Amiga problem 
State-Changed-From-To: suspended->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 11 Mar 2018 22:49:07 +0000
State-Changed-Why:
there is no reason for this PR to be suspended.


From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-amiga/2726 (HP Scanjet driver patch for NetBSD/Amiga)
Date: Fri, 21 May 2021 21:05:30 +0000

 Current equivalent of the ancient patch in this PR follows.

 Whether it will still serve as a workaround for the real issues, I
 have no idea.


 Index: dev/scsipi/ss_scanjet.c
 ===================================================================
 RCS file: /cvsroot/src/sys/dev/scsipi/ss_scanjet.c,v
 retrieving revision 1.54
 diff -u -p -r1.54 ss_scanjet.c
 --- dev/scsipi/ss_scanjet.c	20 Nov 2016 15:37:19 -0000	1.54
 +++ dev/scsipi/ss_scanjet.c	21 May 2021 21:03:37 -0000
 @@ -314,7 +314,7 @@ scanjet_ctl_write(struct ss_softc *ss, c

  	return scsipi_command(ss->sc_periph,
  	    (void *)&cmd, sizeof(cmd), (void *)tbuf, size, 0, 100000, NULL,
 -	    flags | XS_CTL_DATA_OUT);
 +	    flags | XS_CTL_DATA_OUT | XS_CTL_POLL);
  }


 @@ -335,7 +335,7 @@ scanjet_ctl_read(struct ss_softc *ss, ch

  	return scsipi_command(ss->sc_periph,
  	    (void *)&cmd, sizeof(cmd), (void *)tbuf, size, 0, 100000, NULL,
 -	    flags | XS_CTL_DATA_IN);
 +	    flags | XS_CTL_DATA_IN | XS_CTL_POLL);
  }




 -- 
 David A. Holland
 dholland@netbsd.org

>Unformatted:
 >>> RCPT To:<kstailey@dol-esa.gov>
 <<< 550 <kstailey@dol-esa.gov>... User unknown


 It seems that the author email is no longer valid:

    ----- Transcript of session follows -----
 ... while talking to dol-esa.gov.:


 Date: Tue Apr 27 12:18:20 MEST 1999
 <is> It looks like this happens because some bug in the A3000
 <is> onboard scsi DMA code doesn not handle odd or unexpected or
 <is> odd-and-unexpectedly-short transfer lengths correctly.
 <is> However, I can't do anything about it without a device that
 <is> DOES odd or unexpected transfer lengths.
 <is> Heiko:
 <is> - Kenneth Stailey is the inventor of the "PINT" package.
 Ah. didn't know. At least the kstailey@dol-esa.gov address is no longer true
 <is> - Charles did a lot of work to make his drivers really work.
 Yes. saw this. Charles is one of the guys like Jason, that have clue in every a
 rea. Frightening :)
 <is> - Charles refused that patch, because it does the wrong thing,
 <is> instead of fixing the buggy driver.
 *sigh* This is not noted in the PR
 <is> - Kenneth doesn't exist anymore, for what I know (after some
 <is> intermezzo at Openbsd); to the least, PINT hasn't been updated
 <is> for a Looong time.
 <is> - I think we should just get a generic Scsi "cpu" driver
 <is> (which still needs fixing the amiga 33c93 dma), drop explicit
 <is> scanner support, and use the sane package instead (which gets
 <is> us a couple of newer scanners anyway)
 I guess I'm gonna copy&paste this in the PR and set it to suspend state
 <is> Btw: the Mustek line of scanners is broken too, partly in
 <is> themselves, but might additionally suffer from the Amiga 33c93
 <is> dma bug.
 <is> Soren has sent me his Mustek, I verified that it fails in
 <is> different ways connected to the DraCo vs. connected to the
 <is> A3000. I'll look at it after 1.4
 <is> all 33c93 revisions have firmware bugs. code has to workaround
 <is> them by not assuming the obvious combinations of high and low
 <is> nibble in the status byte, but accepting all in the state
 <is> machine ;-)

Home	PR Database Search