Bug 16153
| Summary: | no more parallel port zip drive | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Fritz Heinrichmeyer <jfh> |
| Component: | kern | Assignee: | Nick Hibma <n_hibma> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.0-CURRENT | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Fritz Heinrichmeyer
2000-01-17 09:00:01 UTC
Responsible Changed From-To: gnats-admin->freebsd-bugs I've spent some time trying to track this down, but failed unfortunately. As far as I can see the problem is somewhere in the inner core of the ppbus. The drive responds fairly normally and returns the 36 bytes CAM requested (INQUIRY command). But then ppbus/vpo bails out with a DATA_OVERFLOW error '...error/timeout (5)'. Nick FYI, a piece of log file to show that the bug must be lower down and most probably is not the drives fault: vpo0: XPT_SCSI_IO (0x12) request count = 0, r = 0xa8 count = 1, r = 0xa8 count = 2, r = 0xa8 .... count = 35, r = 0xa8 count = 36, r = 0xa8 vpo_do_scsi = 0, status = 0x0, count = 36, vpo_error = 5 12 0 0 0 24 0 vpo0: VP0 error/timeout (5) vpo0: XPT_SCSI_IO (0x12) request vpo_do_scsi = 0, status = 0x0, count = 36, vpo_error = 2 12 0 0 0 24 0 vpo0: VP0 error/timeout (2) vpo0: XPT_SCSI_IO (0x12) request vpo_do_scsi = 0, status = 0x0, count = 36, vpo_error = 2 12 0 0 0 24 0 count = 36, r = 0xa8 vpo_do_scsi = 0, status = 0x0, count = 36, vpo_error = 5 12 0 0 0 24 0 vpo0: VP0 error/timeout (5) vpo0: XPT_SCSI_IO (0x12) request vpo_do_scsi = 0, status = 0x0, count = 36, vpo_error = 2 12 0 0 0 24 0 vpo0: VP0 error/timeout (2) The last error is most probably caused by the fact that the drive is confused. When count = 36, r should have been 0xb8. Nick I've seen reports of this problem happening with EPP and "PS/2" mode on the parallel port (I have no idea what "PS/2" mode on a parallel port would be though). The error is due to the mode of the parallel port. ppc driver detects NIBBLE (also called compatible) but the ZIP driver thinks the parallel port is in EPP mode. The ZIP protocol is completly different from one to another. So I guess that NIBBLE is right and EPP false. The problem comes certainly from one of the functions in the ppbus framework that returns the available modes of the parallel port to the zip driver. Either the ppc didn't initialize the info. correctly or the ppbus functions interpret it incorrectly. Nicholas nsouch@freebsd.org State Changed From-To: open->feedback Feedback requested (in previous submission to PR) A patch has been committed to CURRENT (rev. 1.10 of
dev/ppbus/ppb_base.c) and STABLE (rev. 1.10.2.1 of same file). Diff
attached below.
Let me know if that fixed the problem for you.
Nick
===================================================================
RCS file: /home/ncvs/src/sys/dev/ppbus/ppb_base.c,v
retrieving revision 1.10.2.1
retrieving revision 1.10
diff -wu -r1.10.2.1 -r1.10
--- src/sys/dev/ppbus/ppb_base.c 2000/08/01 23:26:26 1.10.2.1
+++ /home/ncvs/src/sys/dev/ppbus/ppb_base.c 2000/01/14 00:17:54
1.10
@@ -131,11 +131,10 @@
struct ppb_data *ppb = DEVTOSOFTC(bus);
int old_mode = ppb_get_mode(bus);
- if (PPBUS_SETMODE(device_get_parent(bus), mode))
- return -1;
-
+ if (!PPBUS_SETMODE(device_get_parent(bus), mode)) {
/* XXX yet device mode = ppbus mode = chipset mode */
ppb->mode = (mode & PPB_MASK);
+ }
return (old_mode);
}
--
Work: n_hibma@qubesoft.com Personal: n_hibma@webweaving.org
Responsible Changed From-To: freebsd-bugs->n_hibma Remind me to close this PR. State Changed From-To: feedback->closed The stated fix has been MFC-ed into 4.1STABLE |
