[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Booting loops (Downloading SCSI SCRIPTS)



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.

(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?)

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.

In this case, I think the Tekram SCSI card is 
probably NOT to blame since it worked fine in Gigabyte 586SG.

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.
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.

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.)

-- 
     Ishikawa, Chiaki        ishikawa@personal-media.co.jp.NoSpam  or         
 (family name, given name) Chiaki.Ishikawa@personal-media.co.jp.NoSpam
    Personal Media Corp.      ** Remove .NoSpam at the end before use **     
  Shinagawa, Tokyo, Japan 142-0051




Reply to: