In article <C0Ju8I.1uux@austin.ibm.com> jstump@auntbea.austin.ibm.com (John E. Stump) writes:
quoted text
>In article <1993Jan08.142417.1962@gold.sub.org> Eckehard.Stolz@bbs.gold.sub.org (Eckehard Stolz) writes:
>>I've a Problem with the Syquest 5110 (88MB) and the Seagate St01/02
>>Controller. I managed Linux (99p2) to detect +0the drive and to fdisk it. I
>>tried some Head/Cylinder/Sector values and it seemed to work. I was also
>>able to mkfs the disk, but when I tried to copy data to the mounted disk,
>>the system is rebooting.
>
>This has been a problem for quite a while now. Unfortunately, I'm too
>ignorant of SCSI workings, so all I can do is whine about it. Would
>somebody PLEASE look into this problem? (Note: I can READ syquest DOS
>filesystems just fine. I imagine I could read minix file systems as
>well, except I can't write to it. It's just writes to blow it up.)
>
>If it helps, I am running a 486DX. Eckehard, do you too?


        You are right, this one has been around for a while.  I would really
love it if someone could track this down.  I know people who have the Adaptec
with the Syquest and have no trouble at all, for what it is worth.  Before you
try to debug the kernel, please check and see if any of the following (from the
FAQ) apply:


quoted text
>QUESTION: The seagate driver doesn't work.
>
>ANSWER: There are several possibilities
>1) Is the board jumpered for IRQ5 ? 
>
>The factory settings are
>for MSLOSS, and have interrupts disabled.  Interrupts are controlled
>by the W3 (ST01) or JP3 (ST02) jumper, which should have pins FG 
>shorted.  See your manual.
>
>2) Cached machines will not have problems IF the Seagate's address
>space (typically C8000 - CAFFFF) is not marked "non cacheable."
>This applies to the i486 internal cache as well as i386/i486 
>external caches.
>
>This can be set in the XCMOS of most machines.  If you can't disable
>cache for the Seagate's area (16K in size, starting at the base
>address), then you must disable the cache entirely, otherwise
>it won't work.


        If none of the above apply, then my guess is that there may be some
kind of kernel stack overflow problem, and the only reason that I guess this is
that I have seen a spontaneous reboot when I was trying to use too much kernel
stack space.  If it is not a stack overflow problem, then it is almost
certainly a memory corruption problem somewhere.  One way of trying to narrow
this down is to add #define DEBUG to seagate.c, and see what information you
obtain.  You will lose all of the info from the screen when the system reboots,
so you will have to pay close attention.

        If in fact there is a kernel stack overflow, it is possible that 
it is caused by an infinite recursion in the seagate driver.
I would suggest adding some kind of printk("foo"); in some of the
internal routines in the seagate, and try and see if any pattern emerges.

        Another possibility is that there is an array that is local to some
function (i.e. it lives on the stack), and this is being passed to the seagate
driver, and the seagate driver is writing outside of the boundaries.

        A third possibility is that one of the variables st0x_cr_sr/st0x_dr
does not contain what it should.  This could be checked periodically, and one
could have the kernel panic if either of these variables were found to contain
something that they should not be (These variables are pointers to the memory
mapped data and status registers on the seagate).

        If someone who is experiencing this problem with the Syquest wants to
dig in and try and solve it, drop me a line.  I can provide suggestions
of things to try, patches, etc.

-Eric
-- 
Eric Youngdale