Re: 2.0.34pre breaks my system badly

Alan Cox (alan@lxorguk.ukuu.org.uk)
Sun, 17 May 1998 15:42:57 +0100 (BST)


> $ gcc -v
> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.7.2.3/specs
> gcc version 2.7.2.3
>
> Assume nothing.

Ok.

> > 2. The driver updates are in many cases ones vendors have been shipping for
> > months.
>
> Vendor? You mean Digital is supplying Linux with tulip drivers now?

Linux vendors. You know the people who don't ship 2.0.33 cos it as is doesnt
reflect their customer needs. And as a matter of fact Digital did provide
the other tulip driver (de4x5) themselves.

> <RANT>
> I posted *TWICE* two weeks ago about problems with my network card. I

Well I never saw them. Thats life and linux-kernel. Please cc me with
any follow ups.

> ide: i82371 PIIX (Triton) on PCI bus 0 function 57
> ide0: BM-DMA at 0xffa0-0xffa7
> ide1: BM-DMA at 0xffa8-0xffaf
> hda: Maxtor 83500D4, 3339MB w/256kB Cache, CHS=848/128/63, UDMA

Notice 2.0.34pre12 did figure out you had a UDMA drive. So UDMA is being
enabled. Without UDMA handling your UDMA drive wasnt actually being driven
correctly before for all error handling cases. So far it has done the right
thing.

> hda:hda: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
> hda: disabled DMA

then decides it didnt think your UDMA worked. Do you have BIOS settings for
controlling UDMA and if so how are they set right now ? I can think of two
reasons the UDMA would fail on a drive that claims it can do UDMA. One is
that the chipset doesn't support it (or isnt configured to support it by
the BIOS somehow), the other is substandard cabling causing repeated retries.
Im dubious about the latter.

> As you can see, for the most recent 2.0.34pre series, dma gets disabled on
> the hard drives. I believe (I have no evidence of this, however) that dma
> is getting disabled on the network cards as well, and that's what's causing
> the problems.

That would an unfortunate feature. However all that happens when the IDE
code decides to 'disable DMA' is itsets an internal flag the asserts a
reset to the controller. The reset logic has not changed since 2.0.33. All
that is new here is that the driver went

UDMA on
Do this
[wait]
[wait]
[hello ?]
[oh dear]
reset

> Try offering some suggestions that you wouldn't offer to a first time
> Linuxer.

Firstly, back out specifically the change to ide.c and ide.h, and see if
your machine suddenely springs back to life. If it does then there is
something profoundly horrible going on. The fact you report things like
the floppy DMA failing I have to admit does strongly suggest you may be
right about it being DMA problems.

Without the 2.0.34 ide.c/h change you should see no mention of UDMA and
no timeout. Then see how the other drivers behave.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu