On Mon, 15 Jan 2001, Albert Cranford wrote:
> I have a working PA-2007 but use a small hard disk. Can I help.
[...]
> Detected 239.833 MHz processor.
[...]
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
[...]
> hda: WDC AC2540F, ATA DISK drive
> hda: set_drive_speed
This sucks! I have had several systems with VIA chipsets and have never had any
problems. Currently I am running a SOYO K6-2 system with UDMA 33 and a SOYO K-7
system with both UDMA-33 and UDMA-66 with not problems. How do we know that
there is not some related hardware problem, (cable, power supp
"David D.W. Downey" <[EMAIL PROTECTED]> writes:
> Good! I'm not the only ome getting this error! Mine is also a VT82C686
> though mine is a VT82C686A (352 BGA). This is on an MSI Model 694D Pro
> motherboard running dual PIII-733 FC-PGA 133MHz Coppermines. RAM is 4
> 256MB PC133 unbuffered 7ns n
On Fri, 12 Jan 2001, John Heil wrote:
> I then changed to the 80 wire cables and retried with only -d1 again,
> and to my surprise, the problems never came back and DMA stayed on.
> A while later, I added -X66 and it too worked great. Then lastly came
> the re-add of the rest giving current stat
Vojtech Pavlik wrote:
>
> Is the board still available for some testing?
>
I have a working PA-2007 but use a small hard disk. Can I help.
PIRQ redirection, working around broken MP-BIOS.
... PIRQ0 -> IRQ 0
Initializing CPU#0
Detected 239.833 MHz processor.
Console: colour dummy device 80x25
Ca
> > Note that "hdparm -X34 -d1" enables old DMA, not UDMA. (The board was
> > advertised as UDMA capable but it isn't AFAIK).
Fwiw, -X34 does not fix the lockups for everyone else.
Vojtech Pavlik wrote:
> Is the board still available for some testing?
The board is not in the same country as me
On Sun, Jan 14, 2001 at 08:38:23PM +0100, Jamie Lokier wrote:
> > I think its significant that two reports I have are FIC PA-2013 but not all.
> > What combination of chips is on the 2013 ?
>
> Reading through my mail logs, I know a board, either FIC PA-2011 or FIC
> PA-2007 (I seem to have chan
Alan Cox wrote:
> I think its significant that two reports I have are FIC PA-2013 but not all.
> What combination of chips is on the 2013 ?
Reading through my mail logs, I know a board, either FIC PA-2011 or FIC
PA-2007 (I seem to have changed my mind somewhere in history) with a
6.4G Quantum Fir
On Sat, 13 Jan 2001, Linus Torvalds wrote:
> Somebody who can test it needs to send me a patch - I'm NOT going to apply
> patches that haven't been tested and that I cannot test myself.
This patch has worked for me and is obvious enough that I haven't bothered
to rewire my box to put the IBM dr
I feel it important to note that the distrib in use for all of this is of
my own design. The specs are at www.kixolinux.com.
Why do I feel this is important? Possibly something I've done in the
distrib could be affecting this as well. I remember reading some weeks ago
about the 2.4.0-test## ser
On Sat, Jan 13, 2001 at 08:41:00PM -0700, TimO wrote:
> > Note that with this patch, all VIA users will get IDE transferrates
> > about 3 MB/sec as opposed to about 20 MB/sec without it (and with
> > UDMA66).
> >
> > Also note that enabling the DMA later with hdparm -X66 -d1 or similar
> > comma
On Sun, Jan 14, 2001 at 12:40:58AM +0100, Andrzej Krzysztofowicz wrote:
> > > 2.4 has code in the pci quirks to disable the register which makes
> > > the chip masquerade as a VP3, and forces it to identify itself as
> > > an MVP3 part. I'm curious whether this has an interaction here.
> >
> >
> > /dev/ide/host0/bus0/target0/lun0:hda: dma_intr: status=0x51 {
> > DriveReady SeekComplete Error } hda: dma_intr: error=0x84 {
> > DriveStatusError BadCRC } hda: dma_intr: status=0x51 { DriveReady
> > SeekComplete Error } hda: dma_intr: error=0x84 { DriveStatusError
> > BadCRC } h
In-Reply-To: <[EMAIL PROTECTED]>
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Bryan O'Sullivan) wrote:
> /dev/ide/host0/bus0/target0/lun0:hda: dma_intr: status=0x51 {
> DriveReady SeekComplete Error } hda: dma_intr: error=0x84 {
> DriveStatusError BadCRC } hda: dma_intr: status=0x5
Vojtech Pavlik wrote:
>
> Ok, here goes the patch.
>
> Note that with this patch, all VIA users will get IDE transferrates
> about 3 MB/sec as opposed to about 20 MB/sec without it (and with
> UDMA66).
>
> This patch disables automatic DMA on all VIA chipsets, including the
> ancient 82c561 for
dom (8.9.3/8.9.3) id WAA01107
for green!ankry; Sat, 13 Jan 2001 22:00:40 +0100
From: Andrzej Krzysztofowicz
Message-Id: <[EMAIL PROTECTED]>
Subject: Re: ide.2.4.1-p3.01112001.patch
To: kufel!green.mif.pg.gda.pl!ankry
Date: Sat, 13 Jan 2001 22:00:40 +0100 (CET)
In-Reply-To: <[EMAIL PROT
With vt86c686b (AOpen AK73Pro) I am having a strange problem.
When accessing disks old-fashioned way (/dev/hdaN or /dev/hdcN)
I do not see corruption, but writing to a RAID-1 made out of
them produces corrupted results.
Does RAID code access the underlying block device the same way
as single part
COOL!
This will kill the VIA problem and allow us to clobber the timeout.
I know where and what to do but it is the how with the current mess of the
driver held togather with duct tape and paper clips and a little bit of
spit here and there.
I can not wait for 2.5 to get started to begin with "
> if (IDE_PCI_DEVID_EQ(d->devid, DEVID_SIS5513) ||
> IDE_PCI_DEVID_EQ(d->devid, DEVID_AEC6260) ||
> IDE_PCI_DEVID_EQ(d->devid, DEVID_PIIX4NX) ||
> - IDE_PCI_DEVID_EQ(d->devid, DEVID_HPT34X))
> + IDE_PCI_DEVID_EQ(d->d
David Woodhouse writes:
> Please can we also stop HPT366 from attempting UDMA66 on the IBM DTLA
> drives, while we're at it? I don't care if it's done by blacklisting the
> DTLA drives, as was done by the patch I resent numerous times, or if it's
> done the other way round by putting known-compati
On 12 Jan 2001, Linus Torvalds wrote:
> In short, let's leave it out of a stable kernel for now, and add
> blacklisting of auto-DMA. Alan has a list. We can play around with
> trying to _fix_ DMA on the VIA chipsets in 2.5.x (and possibly backport
> the thing once it has been sufficiently battlet
On Sat, 13 Jan 2001, David Woodhouse wrote:
>
> Please can we also stop HPT366 from attempting UDMA66 on the IBM DTLA
> drives, while we're at it? I don't care if it's done by blacklisting the
> DTLA drives, as was done by the patch I resent numerous times, or if it's
> done the other way round
Hi!
This is not the case I'm looking for. You have a 686b, a chip that is
not supported in 2.4.0 yet. You can try the via 3.11 driver I posted a
while ago, it adds support for this chip, including UDMA100.
Thanks anyway,
Vojtech
On Sat, Jan 13, 2001 at 09:09:05AM -0800, Bryan O'
v> I can make one for you, but first I'd like to find out what exactly are
v> the problem cases.
I have a VT82C686 motherboard. It has one UDMA-100 slot and two
regular IDE slots. I have an IBM DTTA-371440 (about 18 months old) as
hda (only fat32 filesystems), and an IBM DTLA-307030 as hde
(i.e
On Fri, Jan 12, 2001 at 11:43:23PM +, Alan Cox wrote:
> > I'd like to hear about such reports so that I can start debugging (and
> > perhaps get me one of those failing boards, they must be quite cheap
> > these days).
>
> This is one of the most precise reports I have
>
> |The system is an
On Sat, Jan 13, 2001 at 02:43:30AM +, [EMAIL PROTECTED] wrote:
> > |The system is an AMD K6-3 on a FIC PA-2013 mobo with 3 IDE disks. The
> > |size of hda is 4.3 GB, the size of hdb is 854 MB and the size of hdc is
> > |1.2 GB. Hdd is an IDE CDROM drive
> >
> > I think its significant that
On Fri, Jan 12, 2001 at 04:09:22PM -0800, Linus Torvalds wrote:
> On Fri, 12 Jan 2001, Vojtech Pavlik wrote:
> >
> > However - Alan's IDE patch for 2.2 kills autodma on ALL VIA chipsets.
> > That's because all VIA chipsets starting from vt82c586 to vt82c686b
> > (UDMA100), share the same PCI ID.
]>
> > > To: Linus Torvalds <[EMAIL PROTECTED]>
> > > Cc: Vojtech Pavlik <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> > > Subject: Re: ide.2.4.1-p3.01112001.patch
> > >
> > > > what the bug is, and whether there is some other work-around, an
Hi!
I think that with 2.4.0 your board will operate just fine at UDMA33. If
you can, please do test that. Best mount your drives read only at first,
but I doubt there will be any problems.
Vojtech
On Fri, Jan 12, 2001 at 08:03:49PM -0700, Tkil wrote:
>
> Alan asked:
> > I think its significant
On Fri, Jan 12, 2001 at 11:47:41PM +, Alan Cox wrote:
> > However - Alan's IDE patch for 2.2 kills autodma on ALL VIA chipsets.
> > That's because all VIA chipsets starting from vt82c586 to vt82c686b
> > (UDMA100), share the same PCI ID.
>
> I have no reports of problems with the later stuff
On 12 Jan 2001, Linus Torvalds wrote:
> In article <[EMAIL PROTECTED]>,
> Andre Hedrick <[EMAIL PROTECTED]> wrote:
> >
> >Well that "experimental patch" is designed to get out of the dreaded
> >"DMA Timeout Hang" or deadlock that is most noted by the PIIX4 on the
> >Intel 440*X Chipset groups.
Alan asked:
> I think its significant that two reports I have are FIC PA-2013 but
> not all. What combination of chips is on the 2013 ?
My board here is a FIC PA-2013A (if I recall correctly; the
motherboard only has "PA-2013" on it, no "A") rev 1.1.
It's worth noting that there is at least an
On Fri, 12 Jan 2001, Alan Cox wrote:
> |The system is an AMD K6-3 on a FIC PA-2013 mobo with 3 IDE disks. The
> |size of hda is 4.3 GB, the size of hdb is 854 MB and the size of hdc is
> |1.2 GB. Hdd is an IDE CDROM drive
>
> I think its significant that two reports I have are FIC PA-2013 but n
On Fri, 12 Jan 2001, Linus Torvalds wrote:
>
>
> On Fri, 12 Jan 2001, Andre Hedrick wrote:
> >
> > It works perfectly and exactly as it is defined to work by the rules.
> > Getting the rules correct == 'the concept of "working"'.
>
> Don't be silly.
>
> You're entirely ignoring the concept o
On Fri, 12 Jan 2001, Linus Torvalds wrote:
>
>
> On Fri, 12 Jan 2001, Andre Hedrick wrote:
> >
> > It works perfectly and exactly as it is defined to work by the rules.
> > Getting the rules correct == 'the concept of "working"'.
>
> Don't be silly.
>
> You're entirely ignoring the concept o
On Fri, 12 Jan 2001, Andre Hedrick wrote:
>
> It works perfectly and exactly as it is defined to work by the rules.
> Getting the rules correct == 'the concept of "working"'.
Don't be silly.
You're entirely ignoring the concept of hardware bugs. Which is one very
likely reason for this whole
On Fri, 12 Jan 2001, Linus Torvalds wrote:
>
>
> On Fri, 12 Jan 2001, Andre Hedrick wrote:
> >
> > I told you that I have the new code that is scheduled for 2.5 certified on
> > analizers to be technically correct as it relates to the "state diagrams"
> > in the standard.
>
> "Technically cor
On Fri, 12 Jan 2001, Andre Hedrick wrote:
>
> I told you that I have the new code that is scheduled for 2.5 certified on
> analizers to be technically correct as it relates to the "state diagrams"
> in the standard.
"Technically correct" and "state diagrams as in the standard" mean less
that n
On Fri, 12 Jan 2001, John Heil wrote:
>
> Yes, initially the 686a was problematic, now with an 80 wire cable its
> fine.
>
> One point of clarification... I started out with a simple hdparm -d1
> which failed 85% of the time. I added the other stuff only to enhance the
> -d0 state I was left
To: Linus Torvalds <[EMAIL PROTECTED]>
> > > Cc: Vojtech Pavlik <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> > > Subject: Re: ide.2.4.1-p3.01112001.patch
> > >
> > > > what the bug is, and whether there is some other work-around, and whether
> > >
> > To: Linus Torvalds <[EMAIL PROTECTED]>
> > > Cc: Vojtech Pavlik <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> > > Subject: Re: ide.2.4.1-p3.01112001.patch
> > >
> > > > what the bug is, and whether there is some other work-around, and whethe
TED]>, [EMAIL PROTECTED]
> > Subject: Re: ide.2.4.1-p3.01112001.patch
> >
> > > what the bug is, and whether there is some other work-around, and whether
> > > it is 100% certain that it is just those two controllers (maybe the other
> > > ones are bug
On Sat, 13 Jan 2001, Alan Cox wrote:
> Date: Sat, 13 Jan 2001 00:25:28 + (GMT)
> From: Alan Cox <[EMAIL PROTECTED]>
> To: Linus Torvalds <[EMAIL PROTECTED]>
> Cc: Vojtech Pavlik <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: Re: ide.2.4.1-p3.01112001.
> what the bug is, and whether there is some other work-around, and whether
> it is 100% certain that it is just those two controllers (maybe the other
> ones are buggy too, but the 2.2.x tests basically cured their symptoms too
> and peopl ehaven't reported them because they are "fixed").
I've n
On Fri, 12 Jan 2001, Vojtech Pavlik wrote:
>
> However - Alan's IDE patch for 2.2 kills autodma on ALL VIA chipsets.
> That's because all VIA chipsets starting from vt82c586 to vt82c686b
> (UDMA100), share the same PCI ID.
>
> Would you prefer to filter just vt82c586 and vt82c586a as the comme
> However - Alan's IDE patch for 2.2 kills autodma on ALL VIA chipsets.
> That's because all VIA chipsets starting from vt82c586 to vt82c686b
> (UDMA100), share the same PCI ID.
I have no reports of problems with the later stuff
> Would you prefer to filter just vt82c586 and vt82c586a as the com
> I'd like to hear about such reports so that I can start debugging (and
> perhaps get me one of those failing boards, they must be quite cheap
> these days).
This is one of the most precise reports I have
|The system is an AMD K6-3 on a FIC PA-2013 mobo with 3 IDE disks. The
|size of hda is 4.
On Fri, 12 Jan 2001, Alan Cox wrote:
> > I want to see the code to handle the apparent VIA DMA bug. At this point,
> > preferably by just disabling DMA on VIA chipsets or something like that
> > (if it has only gotten worse since 2.2.x, I'm not interested in seeing any
> > experimental patches fo
On Fri, Jan 12, 2001 at 11:57:37AM -0800, Linus Torvalds wrote:
> > I've got a vt82c586 here (bought it just for testing of this problem),
> > and I wasn't able to create any corruption using that board and the 2.4
> > drivers.
>
> The fact that it works on one board doesn't mean that it works o
On Fri, 12 Jan 2001, Vojtech Pavlik wrote:
>
> I've got a vt82c586 here (bought it just for testing of this problem),
> and I wasn't able to create any corruption using that board and the 2.4
> drivers.
The fact that it works on one board doesn't mean that it works on _every_
board.
This is,
On Fri, Jan 12, 2001 at 10:55:22AM -0800, Linus Torvalds wrote:
> In article <[EMAIL PROTECTED]>,
> Andre Hedrick <[EMAIL PROTECTED]> wrote:
> >
> >Well that "experimental patch" is designed to get out of the dreaded
> >"DMA Timeout Hang" or deadlock that is most noted by the PIIX4 on the
> >Inte
In article <[EMAIL PROTECTED]>,
Andre Hedrick <[EMAIL PROTECTED]> wrote:
>
>Well that "experimental patch" is designed to get out of the dreaded
>"DMA Timeout Hang" or deadlock that is most noted by the PIIX4 on the
>Intel 440*X Chipset groups. Since it appears that their bug was copied
>but oth
In article <[EMAIL PROTECTED]>,
Alan Cox <[EMAIL PROTECTED]> wrote:
>
>The PCI ids I kill autodma on for 2.2 to cover this are:
>
>/*
> * Don't try and tune a VIA 82C586 or 586A
> */
>if (IDE_PCI_DEVID_EQ(devid, DEVID_VP_IDE))
>
On Fri, 12 Jan 2001, Linus Torvalds wrote:
>
>
> On Fri, 12 Jan 2001, Andre Hedrick wrote:
> >
> > Scratch that patch it has 2 typos that are in amd74xx.c
> >
> > will do it again..
>
> I will scratch your new patch too.
>
> I want to see the code to handle the apparent VIA DMA bug
> I want to see the code to handle the apparent VIA DMA bug. At this point,
> preferably by just disabling DMA on VIA chipsets or something like that
> (if it has only gotten worse since 2.2.x, I'm not interested in seeing any
> experimental patches for it during early 2.4.x).
It hasnt gotten wor
On Fri, 12 Jan 2001, Andre Hedrick wrote:
>
> Scratch that patch it has 2 typos that are in amd74xx.c
>
> will do it again..
I will scratch your new patch too.
I want to see the code to handle the apparent VIA DMA bug. At this point,
preferably by just disabling DMA on VIA chipsets
Scratch that patch it has 2 typos that are in amd74xx.c
will do it again..
Andre Hedrick
Linux ATA Development
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
On Fri, Jan 12, 2001 at 12:44:25AM -0800, Andre Hedrick wrote:
>
> AMD Update.
> HPT366 Update.
>
> NASTY-ARSE dma-timeout "hack" as a compile option.
[snip]
ide_dma_timeout_revovery ?
s/revovery/recovery/ perhaps?
Cheers,
--Craig
-
To unsubscribe from this list: send the line "unsubscri
AMD Update.
HPT366 Update.
NASTY-ARSE dma-timeout "hack" as a compile option.
It works 99% of the time but invokes nasty-nasty kernel messages.
double handler, double timerfails dma renable attempt
However deadlock should be gone, lets hope.
It is not exactly correct, but function
59 matches
Mail list logo
