Promise IDE controller crashes 2.4.22

Promise IDE controller crashes 2.4.22

[John Goerzen]

Hi,

I have a Promise 20269-based UDMA 133 IDE controller.  If I have DMA
enabled on this controller, then when it is seeing heavy write activity,
the system freezes.  No messages on the console, ctrl-alt-del does
nothing, magic sysrq does nothing.

Reads do not appear to cause this problem, and the problem also
disappears if I disable DMA on the drive connected to the controller by
using hdparm.

System information:
Linux pi 2.4.22 #3 Sat Oct 25 15:45:50 CDT 2003 i586 GNU/Linux
AMD K6 400MHz processor

lspci:
00:08.0 Unknown mass storage controller: Promise Technology, Inc. 20269
(rev 02)

Drive: Maxtor 6Y160P0 150GB UDMA 133

I have, in my .config:

CONFIG_BLK_DEV_PDC202XX_NEW=y
CONFIG_BLK_DEV_PDC202XX=y

Thanks for any insight.

-- John Goerzen

Re: Promise IDE controller crashes 2.4.22

[Wes Janzen]

Hi,

I'd suspect some sort of PCI problem, especially since you're running a 
K6.  What chipset is your motherboard based on?

I'm running a K6-2 400 on an FIC PA2013 with two PDC20269 controllers 
and my primary drive is a 6Y060L0.  I've had no problem with writes in 
DMA mode locking the system in 2.4.22 or any of the test kernels.  I 
have a 92048D8 that doesn't like UDMA-2 writes, but that won't hang the 
system; it just causes Linux to continually reset the interface until 
the kernel finally disables DMA on the drive.  Oddly, UDMA-1 works fine 
but this is a drive to controller hardware issue and not the drivers 
fault. 

Anyway, since the kernel seems to handle a DMA write gone bad, that 
leads me to believe that this issue is caused by the increased data 
flowing over the PCI bus when using DMA vs using PIO.  I'm not an expert 
though, maybe someone else has an opinion on this?

You might try putting the card in another slot too.  My cards are 
installed in slots 1 & 2 with 2 other PCI cards and an ISA device.  This 
particular motherboard seems to handle a full complement of expansion 
cards without problem, but I remember hearing nightmares about such a 
configuration back when these things were new.

-Wes-

John Goerzen wrote:

>Hi,
>
>I have a Promise 20269-based UDMA 133 IDE controller.  If I have DMA
>enabled on this controller, then when it is seeing heavy write activity,
>the system freezes.  No messages on the console, ctrl-alt-del does
>nothing, magic sysrq does nothing.
>
>Reads do not appear to cause this problem, and the problem also
>disappears if I disable DMA on the drive connected to the controller by
>using hdparm.
>
>System information:
>Linux pi 2.4.22 #3 Sat Oct 25 15:45:50 CDT 2003 i586 GNU/Linux
>AMD K6 400MHz processor
>
>lspci:
>00:08.0 Unknown mass storage controller: Promise Technology, Inc. 20269
>(rev 02)
>
>Drive: Maxtor 6Y160P0 150GB UDMA 133
>
>I have, in my .config:
>
>CONFIG_BLK_DEV_PDC202XX_NEW=y
>CONFIG_BLK_DEV_PDC202XX=y
>
>Thanks for any insight.
>
>-- John Goerzen
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>

Re: Promise IDE controller crashes 2.4.22

[John Goerzen]

On Fri, Nov 28, 2003 at 01:36:57PM -0600, Wes Janzen wrote:
> I'd suspect some sort of PCI problem, especially since you're running a 

Do you happen to have a URL where I can read up on PCI problems with
K6s?  Are the problems unique to Linux?  Note that it's a K6-3, so it's
not really first generation PCI.

> K6.  What chipset is your motherboard based on?

I haven't looked at the motherboard in quite awhile...  it's got a lot
of VIA hardware: the PCI bridge is a VT82C598/694x (Apollo MVP3/Pro133x
AGP).  I also see VT82C596 and VT82C586 in the lspci output.  The box
was used as a server for a couple of years with no obvious hardware
problems.

The motherboard was, if memory serves, manufactured by Epox.  But it's
been ages since I've looked at that, so my memory may be failing.  If it
would help with the diagnosis, though, I could go open it up and find
out.

> have a 92048D8 that doesn't like UDMA-2 writes, but that won't hang the 

Can you translate UDMA-2 into something like UDMA/133?  I'm having
trouble mapping the two in my head (I'm not terribly familiar with IDE
internals)

> Anyway, since the kernel seems to handle a DMA write gone bad, that 
> leads me to believe that this issue is caused by the increased data 
> flowing over the PCI bus when using DMA vs using PIO.  I'm not an expert 
> though, maybe someone else has an opinion on this?

The other thing is that the drives hooked to the on-board IDE channels
work fine.  I don't know if that is important; but I figured I'd mention
it.

> You might try putting the card in another slot too.  My cards are 

Hmm, I could give that a try.

Thanks,
John

Re: Promise IDE controller crashes 2.4.22

[Wes Janzen]

John Goerzen wrote:

>On Fri, Nov 28, 2003 at 01:36:57PM -0600, Wes Janzen wrote:
>  
>
>>I'd suspect some sort of PCI problem, especially since you're running a 
>>    
>>
>
>Do you happen to have a URL where I can read up on PCI problems with
>K6s?
>
Well, I know of the assorted problems with the KT133 & newer from VIA 
and SoundBlaster Live sound cards.  I think changing the latency greatly 
reduced the problems but didn't eradicate it completely, IIRC.  You can 
search on Google for "via soundblaster live" to get some more information.

I know when I posted to the list due to problems with the onboard IDE on 
my board, several people responded that they had problems with their VIA 
boards randomly corrupting data during PCI busmaster transfers.  That 
problem doesn't seem to afflict my board.  Most of those were on newer 
boards (KT/KX133) but some involved the MVP3 which both of us are 
running.  I compared notes with someone with the same motherboard 
revision who didn't have the problems I have, so perhaps some silicon or 
boards were defective in a way that was never detected by VIA or the 
board manufacturer respectively. 

Anyway, if VIA had problems with the later chipset I wouldn't be at all 
surprised if an older version suffered from similar defects.

>  Are the problems unique to Linux? 
>
These problems are not unique to Linux.  Windows configures PCI devices 
differently though and that could have an effect.

> Note that it's a K6-3, so it's
>not really first generation PCI.
>  
>
Well, it was a first-generation chipset in many regards ;-)  Seriously 
though, especially back then VIA was several notches below Intel when it 
came to product quality.  The K6 in any form was a bargain chip and the 
chipsets for it were targetting that market; I doubt they went through 
any qualification program remotely resembling those of Intel.  In other 
words, it may not be first generation for VIA but it wasn't top quality 
either.

I'm not bashing VIA, that's just the reality of it.  My system was flaky 
until I replaced the onboard IDE with the Promise cards.  It became 
solid when I replaced the 3dfx Banshee with an ATI 9000 Pro.  Still I 
don't expect to get the kind of performance out of the cards as I would 
if they were in a comparable PII system.  For example, I seriously doubt 
the 3COM diagnostics complain about PCI bus performance on an Intel system.

> ...
>
>Can you translate UDMA-2 into something like UDMA/133?  I'm having
>trouble mapping the two in my head (I'm not terribly familiar with IDE
>internals)
>
>  
>
UDMA-2 = UDMA/33

It's not really important, I'm just pointing out that if the drive 
stopped responding due to a communication problem between the drive and 
card, the drive would be reset and the system would become responsive 
even if it paused for several seconds.

I should also clarify that the drive communicated fine with the VIA IDE 
in UDMA-2, just not with the Promise controllers.  I have to back the 
drive down to UDMA-1 before writing data or it will reset and fallback 
to PIO.

> ...
>
>The other thing is that the drives hooked to the on-board IDE channels
>work fine.  I don't know if that is important; but I figured I'd mention
>it.
>
>  
>
It may not stress the PCI bus as much, it was designed specifically for 
the chipset, and it's attached to the PCI bus in a significantly 
different manner.  It's just that the fact that using PIO transfers 
implies a large reduction in the PCI bandwidth utilized by the card.  
That and my experience with card to drive communication failure only 
leaves some other cause.  Depending on the type of transfer, it's likely 
that the PCI bus is being completely saturated when bursting write data 
to the drive's cache or even a sustained write.  So going from a high 
PCI load to a lower PCI load solves the problem.

It's possible that the driver is doing something wrong, but I'm using a 
similar hardware configuration and not experiencing the problem.  Many 
more people are using the driver and card with a different board, also 
apparently without problems.  So, add the history of VIA and PCI 
problems and a PCI communication failure looks like a prime candidate.  
You'd be wise to run an extensive memory test though to eliminate that 
cause.  Other possible suspects would be the power supply or a hot cpu.

>>You might try putting the card in another slot too.  My cards are 
>>    
>>
>
>Hmm, I could give that a try.
>  
>
Could be a BIOS setting causing the problem too, but I don't know enough 
about the PCI bus to know which settings you'd want to adjust ;-)  If it 
was me, I'd try the PCI settings first though since my machine is so 
full of cards and cables.

Perhaps someone else can speak up and let us know if another misbehaving 
PCI device could be causing this problem?  For example when the drive is 
hogging the bus during a DMA transfer maybe another card could interrupt 
it and lock up the PCI bus; is it possible and if so, likely?  Maybe 
it's not the bandwidth but a long transfer that's the problem...?  I'd 
rather not try to dig up the PCI specs to answer this question (mainly 
because I don't have the time).

Good luck,
Wes

>Thanks,
>John
>  
>

Re: Promise IDE controller crashes 2.4.22

[Bartlomiej Zolnierkiewicz]

It means two things:

(a) There is a bug in drivers/ide/pci/pdc202xx_new.c:init_hwif_pdc202new(),
    hwif->autodma shouldn't be set to 0 or "idex=dma" parameter won't work.

(b) If you don't use autodma you have to tune desired mode _explicitly_ first,
    because most of ->ide_dma_check() implementations (for pdc202xx_new.c
    it is pdcnew_config_drive_xfer_rate()) check for hwif->autodma.

--bart

On Saturday 29 of November 2003 02:52, John Goerzen wrote:
> On Fri, Nov 28, 2003 at 02:00:55PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > My mistake, it should have been -Xudma5 :-).
>
> I tried the ide2=dma in the kernel and then:
>
> hdparm -d 1 -u 1 -X 69 /dev/hde
>
> That did seem to solve the problem.  Output of hdparm after that
> command:
>
> pi:~# hdparm /dev/hde
>
> /dev/hde:
>  multcount    = 16 (on)
>  IO_support   =  0 (default 16-bit)
>  unmaskirq    =  0 (off)
>  using_dma    =  1 (on)
>  keepsettings =  0 (off)
>  readonly     =  0 (off)
>  readahead    =  8 (on)
>  geometry     = 19929/255/63, sectors = 320173056, start = 0
>
> What does that mean?