Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 19 Feb 2004 15:33:24 -0300
From:      Cristiano Duarte <cunha17@uol.com.br>
To:        "Justin T. Gibbs" <gibbs@scsiguy.com>
Cc:        aic7xxx@freebsd.org
Subject:   Re: BUG introduced in kernels above 2.4.18 ?
Message-ID:  <40350174.7000305@uol.com.br>
In-Reply-To: <370790000.1077213725@aslan.btc.adaptec.com>
References:  <4034D259.5050001@uol.com.br> <370790000.1077213725@aslan.btc.adaptec.com>

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

Justin T. Gibbs escreveu:
>>Feb 13 17:53:15 thor kernel: blk: queue c130d574, I/O limit 4095Mb (mask 0xffffffff)
>>Feb 13 17:53:15 thor kernel: (scsi0:A:3:0): Unexpected busfree while idle
>>Feb 13 17:53:15 thor kernel: SEQADDR == 0x156
>>Feb 13 17:53:15 thor kernel: (scsi0:A:3:0): No or incomplete CDB sent to device.
>>Feb 13 17:53:15 thor kernel: scsi0: Issued Channel A Bus Reset. 1 SCBs aborted
>>Feb 13 17:53:15 thor kernel: (scsi0:A:6:0): No or incomplete CDB sent to device.
>>Feb 13 17:53:15 thor kernel: (scsi0:A:6:0): Protocol violation in Message-in phase.  Attempting to abort.
>>Feb 13 17:53:15 thor kernel: (scsi0:A:6:0): Abort Message Sent
> 
> 
> These are caused by one or more of your devices either violating the
> SCSI protocol, or the utility you are using to talk to the scanner
> failing to properly setup the SCSI command.  Pervious versions of
> the driver did not flag these errors, but it is not a bug that
> the driver now does.  I would suggest auditing your scanner software
> to ensure that it is properly setting the cdb length in all commands
> that it sends since this is often the cause of such issues.
Do you mean that the kernels above 2.4.18 just reports the errors or raise the errors?
If these errors were supposed to happen with kernels below 2.4.18 why these kernels work and newer don't ?
IMO just sending the error messages to stdout/syslog don't make devices stop working. Or the new kernels "check" the protocol violation and the older don't ?
What I mean is that the scanner is recognized and is totally functional with kernel 2.4.18(in Fedora Core 1) and is totally useless with kernel 2.4.20/2.4.22(in RedHat9 or Fedora Core 1). If a protocol violation is happening because of the scanner or scanner utility, this violation is supposed to happen with kernel 2.4.18 and, even if this kernel doesn't check for violations, when this violation happen, the kernel should reject the scanner, what doesn't happen.
BTW, the software I'm using is SANE(sane-find-scanner and scanimage) and they are working with kernels 2.4.18 and below, get garbage with kernel 2.4.20 and don't work at all with kernels 2.4.22 and 2.4.24.

Best Regards,

Cristiano Duarte



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