Date: Sat, 18 Apr 1998 08:54:30 +1000 From: Kerry Morse <kerry.morse@metro.tas.com.au> To: "'freebsd-current@FreeBSD.ORG'" <freebsd-current@FreeBSD.ORG> Subject: RE: Help - please... Adaptec 1542 and Exabyte tape problem... Message-ID: <02B01380C828D1119ED70020AF641C53068561@MTTMail.metro.tas.gov.au>
next in thread | raw e-mail | index | archive | help
> > So basically it's not going to work for at least a while or a few > fixes > > so swapping the controller out over with a PCI controller while no > ones > > looking is my best solution at present... > > I've just found a whole mess of bounce buffer bitrot in the existing > scsi > code and applied some bandaids. I can't test some of the more obscure > > drivers, but an aha1542B + sd0/sd1/st0/cd0 now seems to work fine. > Before, talking to the tape would fail 50% of the time at startup. > > Ironically, I think I to blame for a good chunk of the original > breakage. > The scsi base code (scsi_scsi_cmd() specifically) had some patchwork > to > detect data transfers to/from the per-process kernel stack and how to > manually bounce them. When I moved the kernel stack out of user space > > last year some time, the glue code that checked for requests on the > kstack > no longer worked as it used assumptions about the VM space layout that > were no longer true. However, there was bitrot in other drivers too, > notably worm, ch and st. > > OK, is there a 'patch' I can apply or do I need to pull a whole new > image of > FreeBSD??, currently running the 980414 SNAP.... > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?02B01380C828D1119ED70020AF641C53068561>