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:
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
"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
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
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 state.
"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 non
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
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:
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
> > 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
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
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
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
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##
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
> >
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 }
/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 } hda:
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.
This doesn't
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
command is not
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##
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
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
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
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
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:
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
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
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))
> +
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
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
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
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
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
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
]>
> > > 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
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
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
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
[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
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
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
At
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 AMD K6-3
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 two
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.
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.
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
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
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-compatible
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-devid,
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
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
)
by kufel.dom (8.9.3/8.9.3) id WAA01107
for green!ankry; Sat, 13 Jan 2001 22:00:40 +0100
From: Andrzej Krzysztofowicz kufel!ankry
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
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 486's,
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=0x51 {
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
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
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
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
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
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
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
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.0
> 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
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
> 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
> 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
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
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
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
>
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
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
> 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
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
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 "unsubscribe
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 or
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 worse,
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. At this
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))
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 other
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
Intel 440*X
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, in
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 on
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 for it
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.3
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
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 comment in
1 - 100 of 112 matches
Mail list logo
