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
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 [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
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
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
>
>
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?