Re: Booting loops (Downloading SCSI SCRIPTS)
Thanks for your very interesting posting.
On Mon, 27 Nov 2000, Chiaki Ishikawa wrote:
> X-PMC-CI-e-mail-id: 14163
>
> Hi,
>
> I saw Karl Hammar's post about the booting problem of TEKRAM card and
> the resulting exchanges and learned about sym53c8xx=mpar:n boot parameter.
> I have a Tekram DC390U2B
> card that has been working fine on a
> Gigabyte 586SG [with AMD K6-III/400 on a powerleap adaptor]
> with the sym53c8xx driver under linux 2.4.0-testXX for a while.
>
> Imagine my surprise that when I tried to move the Tekram card
> to a new motherboard, namely, SOYO K7VTA with AMD Duron 750,
> the kernel won't boot successfully due to the infinite
> SCRIPT DOWNLOAD loop caused apparently due to an error encountered
> by the sym53c8xxdriver.
> I scratched my head for a couple of days until I realized that
> the same problem reported Karl Hammar seemed to be at work.
>
> I added sym53c8xx=mpar:n and the system boots fine now.
> (I put the appropriate "append=..." in my /etc/lilo.conf in the end.)
>
> I am not sure if the wiring of the board itself to blame, or
> to blame the BIOS which may not enable the proper PCI bus parity
> info reporting.
There are bunches of things to blame, in my opinion.
The PCI specifications require that PCI devices that deal with persistent
data _do_ perform PCI parity checking and report errors. However, it seems
that most drivers and bioses just donnot care about or, may-be, take care
of PCI parity being not checked and error ignored.
This is not acceptable, in my opinion. And as a result, hardwares that
fail miserably when PCI parity checking is enabled are not uncommon
nawadays.
> (By the way, I take that the "master PCI parity"
> is the parity bit reported for PCI bus transaction and
> NOT the SCSI bus parity.
> Am I correct?)
You are.
> I think the documentation of sym53c8xx might want to
> include the error symptoms (infinite loop of repeated SCRIPT DOWNLOAD)
> and/or the name of the problematic motherboards, etc. when
> the "mpar:n" is required.
I didn't expect PCI parity checking to lead to spurious permanent errors
of this kind when I have decided to make the sym53c8xx driver PCI
compliant by default. The infinite loop has been a great surprise to me.
Btw, I never observed it on the hardwares I was and am using.
As I wrote in a previous posting, my latest driver version detects the
problem and performs the disabling.
> In this case, I think the Tekram SCSI card is
> probably NOT to blame since it worked fine in Gigabyte 586SG.
Hmmm... it is very probable, but not proven. The only way to prove it
would be to check `in vivo' the actual signal timings.
> Even on Soyo SY-K7VTA, I think the driver worked once (and only
> once) when I tried to run "insmod sym53c8xx" initially.
> But that driver is from very old Storm Linux beta CD (Debian GNU/Linux
> 2.2.12) and I am not sure if the sym53c8xx had the mpar checking
> feature back then.
This might be the case. I donnot remember.
> Also the board had only video card and Tekram
> DC390U2B only when insmod worked.
> The next day after I inserted Intel EEPRO100 ethernet
> card, insmod no longer worked and I could not access the scsi disk
> until I figure out the sym53c8xx load parameter.
Interesting.
> Strange things do happen, doesn't it?
>
> I am going to write to SOYO about the problem since I think probably
> the BIOS is to blame. One of these days, it is hard to believe that
> the hardware wiring scheme is faulty when we have begun using 133Mhz
> memory, etc. on a home PC. (I tend to think that such glaring error is
> or should be caught by a vendor like SOYO before shipment. Oh, I
> realize there is a version B of that motherboard, I wonder what it
> means.
> Follow the manual link at the upper right hand corner of the
> following URL.
>
> http://www.soyo.com.tw/product/k7vta.htm
>
> If BIOS is at fault, maybe
> they can release an upgrade for the fix.
>
> I think these vendors are simply unaware of these problems and if we
> report them often enough, they will take note and fix the future
> products. (Well, that's my hope anyway. Writing the names of
> the motherboards in the document is also a subtle pressure
> on these vendors.)
If their product installs windows and is able to run it a couple of hours
without apparent problems, they probably consider they can sell it.
This is commonly called `Windows compatible' hardware. :-)
Until my latest MotherBoard I only wanted to use Intel Chipsets and CPUs.
The main reason is that errata are made publically available by Intel.
I needed PCI 64 bit 66 MHz, but due to the 840 fiasco, I have replaced my
glich-free for 3 years ASUS PL97 Mobo by a SuperMicro 370 DLE ServerWorks
III LE chipset based. The hardware works great, but not having the errata
is a huge frutration to me. Btw, never got weird problems with my
hardwares since 6 years.
Gérard.
Reply to: