Re: [expert] Lost interrupt revisited

2000-03-07 Thread Civileme

On Tue, 07 Mar 2000, you wrote:
> Civileme wrote:
> > We are obviously dealing with something very subtle at the
> > edge--the bleeding edge it would seem.  What is different about
> > Seagate drives?  I tried Fujitsu, Maxtor, IBM, and Quantum in the
> > same position and none showed the problem.  It seems to take
> > three conditions
> > 
> > 1.  Large Seagate Drive (8.4G or bigger)
> > 2.  VIA MVP3 or MVP4 chipset Super7 motherboard with IDT, AMD,
> > INtel, or Cyrix processor
> > 3.  Linux-Mandrake 6.0 6.1(6.5MacMillan) or 7.0
> 
> 
> Civileme, please have a look at this (if you didn't already): 
>   http://kt.linuxcare.com/kt2214_54.epl   (the 2nd item)  
> 
> While it is not exactly the same problem, it has also to do
> with "lost interrupt" and it seems to be a pure hardware problem.
> 

Yep, flaky disk drive timing.  The strangeness was that I was able to make
something happen positively by swapping it away then back to /dev/hda


I never had a drive on the same IDE channel with the offensive Seagate.
It is interesting that the signal reflection mentioned there is WD drives withj
PII and PIII processors while I am observing this with Seagate and Super7
processors.  Also, it appears, the problem relates to timing requirements
becoming more strict as we progress upward in the processors we compile for. 
FreeBSD and Win98 showed NO errors and are 386 compiled.  L-M 6.0, 6.1, and 7.0
are 586 compiled and obviously do not permit the sloppiness built into the
Seagate, just as kernels built for the 686 and 586 gaVE EXTREMELY nasty
performance with WDC and Maxtor drives on the same IDE channel for PII and PIII
processors.


And yes, it appears UDMA/66 is not ready for prime time unless you have a 386
compiled kernel 


Thanks for the heads-up.  I'll be following that one, but it appears time for a
convocation of Disk drive manufacturers with topics interoperability and
quality.

And I won't be putting any Maxtor master/WD slave combos up at all.  Looks like
that is downright dangerous to your data and temperament.

Civileme

Now on the Seagate I am seeing the lost interrupt on the OTHER channel and I am
having trouble with the initial command set, but I am willing to bet it is an
unwelcome signal reflection.  

Thus far, the IBM branded drives seem to be above this .

 > --  > Jean-Louis
Debert[EMAIL PROTECTED] > 74 Annemasse  France > old Linux fan



Re: [expert] Lost interrupt revisited

2000-03-07 Thread Jean-Louis Debert

Civileme wrote:
> We are obviously dealing with something very subtle at the
> edge--the bleeding edge it would seem.  What is different about
> Seagate drives?  I tried Fujitsu, Maxtor, IBM, and Quantum in the
> same position and none showed the problem.  It seems to take
> three conditions
> 
> 1.  Large Seagate Drive (8.4G or bigger)
> 2.  VIA MVP3 or MVP4 chipset Super7 motherboard with IDT, AMD,
> INtel, or Cyrix processor
> 3.  Linux-Mandrake 6.0 6.1(6.5MacMillan) or 7.0


Civileme, please have a look at this (if you didn't already): 
  http://kt.linuxcare.com/kt2214_54.epl   (the 2nd item)  

While it is not exactly the same problem, it has also to do
with "lost interrupt" and it seems to be a pure hardware problem.

-- 
Jean-Louis Debert[EMAIL PROTECTED]
74 Annemasse  France
old Linux fan



[expert] Lost interrupt revisited

2000-03-07 Thread Civileme

Within the past three days, someone posted to the expert list on
a lost interrupt which stopped his installation of Mandrake 7.0. 
I have managed to duplicate the error, at least I think so.  I
hope the poster will respond with his equipment configuration.

OK  VIA MVP4 Chipset, K6-2 standard clocking 100MHz bus and
500MHz processor--dropped to 80 and then to 75 and finally to 66
in an attempt to pass the error.

Settings for UDMA/PIO/Prefetch and HDD Block mode were progressed
truth-table style.  None seemed to have any effect on the error.

an 80-pin UDMA cable was removed.  Still no effect.

The drive caused an error as follows 
Invalid code 

Kernel Panic 
Attempting to kill inactive process
In swapping processes
hdc: lost interrupt  (That was my Creative CDRW)

The drive was a seagate barracuda 7200 rpm 7.6ms nominally 10.2
G.  It looked like the 6.0/6.1 problem with large UDMA Seagate
Drives and MVP super7 chipsets all over again.  I salvaged one of
those Seagate drives by putting it as /dev/hdc and setting it to
NORMAL, so I tried that.

hda: lost interrupt  (that was my Creative CDRW)

Uh huh.  Well I put a 2.5G Maxtor drive at hda instead of the
CD-ROM

Passed the boot point where it was failing and signal 11ed after
loading second stage from CD-ROM

Now I wanted the exact wording for the error so I restored the
Seagate to drive /dev/hda and ran the CD boot again.

Signal 11ed on second stage.

I dropped the clock 5%

THe thing is installing.  UDMA is auto, Prefetch is on, PIO is
auto, HDD Block is enabled  mem is 8ns and cycle time is 2. 
Installing at 95Khz/475MHz processor without any trouble.

I would guess it is an initial load of some NVRAM in the Seagate
which is "cured" by setting it temporarily to drive C.

IN the original failure position, I was able to install FreeBSD
and to remove FreeBSD and install Win98 and to remove win98 and
fail on VEnus and Helios with the typical large Seagate errors
previously reported.  None of these installs had any effect on
the Seagate drive as far as its behavior toward an AIR install
was concerned.

We are obviously dealing with something very subtle at the
edge--the bleeding edge it would seem.  What is different about
Seagate drives?  I tried Fujitsu, Maxtor, IBM, and Quantum in the
same position and none showed the problem.  It seems to take
three conditions

1.  Large Seagate Drive (8.4G or bigger)
2.  VIA MVP3 or MVP4 chipset Super7 motherboard with IDT, AMD,
INtel, or Cyrix processor
3.  Linux-Mandrake 6.0 6.1(6.5MacMillan) or 7.0


And it seems to be cured by functioning as /dev/hdc in an
attempted install with a non-seagate /dev/hda

Once the "cure" is performed, it will install.

But will it boot?

LIL-

Using the boot floppy does bring it up.  Obviously Seagate is
doing something very diferent from other manufacturers.

I have observed similar or worse problems on an Intel TX chipset
with a Seagate large Drive where the install seemed to go
perfectly well but the HDD was completely corrupt afterward.  On
a TX chipset board, the position of the drive mattered not a
whit.  It installed without error messages and was completely
corrupt.

On SiS super-7 chipsets on boards I have a lot of trouble making
hiccup during burn-in testing, I also have trouble with Seagate
large drives, though they work like champs as /dev/hdc and
NORMAL.

OK this system is running with the large Seagate in /dev/hda
(primary boot) but it will boot only from boot disks.  

SO is that where you encountered the "Lost Interrupt"?  Was it a
Seagate Drive?  If it was, what was the Chipset and Processor?


And does anyone need a cheap Seagate barracuda, capable of
hyperfast accesses in Windows or FreeBSD?

Civileme

-- 
experimentation involving more than 500 trials with an
ordinary slice of bread and a tablespoon of peanut butter
has determined that the probability a random toss will
land sticky side down (SSD) is approximately .98