Hallo,
I have a problem with the driver for Initio SCSI Controller 9100 SCSI,
a dual channel UW SCSI-Controller. On checking the SCSI bus the systems
has problems to initialize the CD-RW Sanyo (aka Brainwave) BP4-N SCSI
The CD-RW has SCSI-ID 6 on the second Controller. It is shown on
system startup an GENERIC CRD-BP4
scsi: aborting command due to timeout: pid 72, scsi 1, channel 0, id 6 lun
1 inquery 20 00 00 ff 00
SCSI host 1 abort (pid 70) timed out - resetting
SCSI bus is being reset for host 1 channel 0
SCSI host 1 channel 0 (pid 72) timed out - trying harder
SCSI bus is being reset for host 1 channel 0
tul_bad_seq.c=1
The rest of the messages I could not get because it scrolls too
fast. That's why I attached the /var/log/messages file to give you all the
needed information.
My system is a dual processor PIII-700 system with 512MB RAM.
The systems needed very much time (about the quarter of an hour) to boot
up if I turn on the CD-writer. This time I have been waiting for half an
hour without reaching the login sequence.
When I try to access it after boot the system gives error messages similar
to the one I mentioned above.
I had this problem both with Kernel 2.2.17 and 2.2.19.
Please help me.
Kind regards
Ingo Tischer
[email protected]
Hi Ingo,
> I have a problem with the driver for Initio SCSI Controller 9100 SCSI,
> a dual channel UW SCSI-Controller. On checking the SCSI bus the systems
> has problems to initialize the CD-RW Sanyo (aka Brainwave) BP4-N SCSI
> The CD-RW has SCSI-ID 6 on the second Controller. It is shown on
> system startup an GENERIC CRD-BP4
>
> I had this problem both with Kernel 2.2.17 and 2.2.19.
Check your termination. The initio drivers are very sensitive to
termination errors (use active if possible), and make sure you follow all
the normal rules regarding scsi.
Most problems I've seen are caused by lousy termination, or using three
way busses. I've also seen some problems with some cd writers (Yamaha to
be exact), that I haven't been able to solve yet.
Regards,
Bas Vermeulen
--
"God, root, what is difference?"
-- Pitr, User Friendly
"God is more forgiving."
-- Dave Aronson
On Thu, 5 Jul 2001 11:32:12, [email protected] wrote:
> > I have a problem with the driver for Initio SCSI Controller 9100 SCSI,
> > a dual channel UW SCSI-Controller. On checking the SCSI bus the systems
> > has problems to initialize the CD-RW Sanyo (aka Brainwave) BP4-N SCSI
> > The CD-RW has SCSI-ID 6 on the second Controller. It is shown on
> > system startup an GENERIC CRD-BP4
> >
> > I had this problem both with Kernel 2.2.17 and 2.2.19.
>
> Check your termination. The initio drivers are very sensitive to
> termination errors (use active if possible), and make sure you follow all
> the normal rules regarding scsi.
>
> Most problems I've seen are caused by lousy termination, or using three
> way busses. I've also seen some problems with some cd writers (Yamaha to
> be exact), that I haven't been able to solve yet.
There's a bug in i91uscsi.c, init_tulip where it cycles through the onboard NVRAM
config. On the controller there's a single byte per device but it cycles through the
NVRAM in words. Since x86 words are two bytes a piece this means that the
code uses the NVRAM config for the device on twice the SCSI id - the only one
that's right is the one on id 0.
The patch below has been working here since January - though I've just extracted
this one fix from a much larger modification that I've done to the driver - proc fs
support, merging of i91uscsi.h and ini9100u.h since they contain many of the
same definitions but the two definitions are different which looks extremely
dangerous to me! i91uscsi.h is no more here.
I may have missed something with this one fix.
--- drivers/scsi/i91uscsi.cold Thu Jul 5 20:50:04 2001
+++ drivers/scsi/i91uscsi.c Thu Jul 5 20:55:03 2001
@@ -590,8 +590,8 @@
int init_tulip(HCS * pCurHcb, SCB * scbp, int tul_num_scb, BYTE * pbBiosAdr, int seconds)
{
int i;
- BYTE *pwFlags;
BYTE *pbHeads;
+ UCHAR *pTarg;
SCB *pTmpScb, *pPrevScb = NULL;
pCurHcb->HCS_NumScbs = tul_num_scb;
@@ -673,12 +673,12 @@
TUL_WR(pCurHcb->HCS_Base + TUL_GCTRL1,
((pCurHcb->HCS_Config & HCC_AUTO_TERM) >> 4) | (TUL_RD(pCurHcb->HCS_Base, TUL_GCTRL1) & 0xFE));
+ pTarg = &i91unvramp->NVMSCSIInfo[0].MVM_Targ0Config;
for (i = 0,
- pwFlags = & (i91unvramp->NVM_SCSIInfo[0].NVM_Targ0Config),
pbHeads = pbBiosAdr + 0x180;
i < pCurHcb->HCS_MaxTar;
- i++, pwFlags++) {
- pCurHcb->HCS_Tcs[i].TCS_Flags = *pwFlags & ~(TCF_SYNC_DONE | TCF_WDTR_DONE);
+ i++) {
+ pCurHcb->HCS_Tcs[i].TCS_Flags = *(pTarg+i);
if (pCurHcb->HCS_Tcs[i].TCS_Flags & TCF_EN_255)
pCurHcb->HCS_Tcs[i].TCS_DrvFlags = TCF_DRV_255_63;
else
Trevor Hemsley, Brighton, UK.
[email protected]
> There's a bug in i91uscsi.c, init_tulip where it cycles through the
> onboard NVRAM config. On the controller there's a single byte per
> device but it cycles through the NVRAM in words. Since x86 words are
> two bytes a piece this means that the code uses the NVRAM config for
> the device on twice the SCSI id - the only one that's right is the one
> on id 0.
>
> The patch below has been working here since January - though I've just
> extracted this one fix from a much larger modification that I've done
> to the driver - proc fs support, merging of i91uscsi.h and ini9100u.h
> since they contain many of the same definitions but the two definitions
> are different which looks extremely dangerous to me! i91uscsi.h is no
> more here.
'k. What I don't get about your patch is the following:
1. There seems to be a typo in there (You change NVM_SCSIInfo
into NVMSCSIInfo, without patching the header file, which just won't
work). Another type is changing NVM into MVM on the same line.
2. You change the pwFlags into pTarg, without actually changing anything,
since pwFlags is defined as BYTE, which is defined as unsigned char
in i91uscsi.h. The name may be confusing, but then please just change
the name.
3. The original code (which was not written by me, of which I *know* that
it's butt-ugly, but that works for my situation) filters out
TCF_SYNC_DONE and TCF_WDTR_DONE. So the only thing you changed is
not filtering out those flags. If that's what you want to do,
please just do that.
On another note, if you'd like to get the documentation for the chipset,
so you can rewrite the driver from scratch, please just let me know.
I don't really have the time to get this thing properly updated, and it
would be a pity if it dropped out of 2.5.
The same goes for the Initio A100 driver. If you're serious, I'm willing
to send you the card and documentation I have.
Regards,
Bas Vermeulen
> --- drivers/scsi/i91uscsi.cold Thu Jul 5 20:50:04 2001
> +++ drivers/scsi/i91uscsi.c Thu Jul 5 20:55:03 2001
> @@ -590,8 +590,8 @@
> int init_tulip(HCS * pCurHcb, SCB * scbp, int tul_num_scb, BYTE * pbBiosAdr, int seconds)
> {
> int i;
> - BYTE *pwFlags;
> BYTE *pbHeads;
> + UCHAR *pTarg;
> SCB *pTmpScb, *pPrevScb = NULL;
>
> pCurHcb->HCS_NumScbs = tul_num_scb;
> @@ -673,12 +673,12 @@
> TUL_WR(pCurHcb->HCS_Base + TUL_GCTRL1,
> ((pCurHcb->HCS_Config & HCC_AUTO_TERM) >> 4) | (TUL_RD(pCurHcb->HCS_Base, TUL_GCTRL1) & 0xFE));
>
> + pTarg = &i91unvramp->NVMSCSIInfo[0].MVM_Targ0Config;
> for (i = 0,
> - pwFlags = & (i91unvramp->NVM_SCSIInfo[0].NVM_Targ0Config),
> pbHeads = pbBiosAdr + 0x180;
> i < pCurHcb->HCS_MaxTar;
> - i++, pwFlags++) {
> - pCurHcb->HCS_Tcs[i].TCS_Flags = *pwFlags & ~(TCF_SYNC_DONE | TCF_WDTR_DONE);
> + i++) {
> + pCurHcb->HCS_Tcs[i].TCS_Flags = *(pTarg+i);
> if (pCurHcb->HCS_Tcs[i].TCS_Flags & TCF_EN_255)
> pCurHcb->HCS_Tcs[i].TCS_DrvFlags = TCF_DRV_255_63;
> else
>
>
> Trevor Hemsley, Brighton, UK.
> [email protected]
>
--
"God, root, what is difference?"
-- Pitr, User Friendly
"God is more forgiving."
-- Dave Aronson
On Fri, 6 Jul 2001 07:56:39, [email protected] wrote:
> What I don't get about your patch is the following:
Two things:
1) I must not try to type in patches while watching my phone bill to
BT click up the pennies!
2) I must check the source I'm diffing against to make sure that Alan
hasn't fixed the bug in the AC series already!
;-)
--
Trevor Hemsley, Brighton, UK.
[email protected]