ide.2.4.1-p3.01112001.patch

ide.2.4.1-p3.01112001.patch

[Andre Hedrick]

[-- Attachment #1: Type: text/plain, Size: 350 bytes --]


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 timer........fails dma renable attempt

However deadlock should be gone, lets hope.

It is not exactly correct, but function :-((

Cheers,

Andre Hedrick
Linux ATA Development

[-- Attachment #2: Type: application/octet-stream, Size: 8953 bytes --]

Re: ide.2.4.1-p3.01112001.patch

[Andre Hedrick]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Linus Torvalds]

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 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).

We've already had one major fs corruption due to this, I want that fixed
_first_.

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Alan Cox]

> 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, its just its a very specific combination and its a 
well known problem (vendors dont enable auto dma for ide for this reason)
2.2.16 just covers the cases I know about (and slightly overdoes it for now)

> We've already had one major fs corruption due to this, I want that fixed
> _first_.

I've got other reports too. 

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))
                {
                        autodma_default = 0;
                        break;
                }
                if (IDE_PCI_DEVID_EQ(devid, DEVID_VP_OLDIDE))
                {
                        autodma_default = 0;
                        break;
                }


PCI_VENDOR_ID_VIA,     PCI_DEVICE_ID_82C586_0
PCI_VENDOR_ID_VIA,     PCI_DEVICE_ID_82C586_1



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Linus Torvalds]

In article <E14H8hl-0004ji-00@the-village.bc.nu>,
Alan Cox  <alan@lxorguk.ukuu.org.uk> 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))
>                {
>                        autodma_default = 0;
>                        break;
>                }
>                if (IDE_PCI_DEVID_EQ(devid, DEVID_VP_OLDIDE))
>                {
>                        autodma_default = 0;
>                        break;
>                }
>
>
>PCI_VENDOR_ID_VIA,     PCI_DEVICE_ID_82C586_0
>PCI_VENDOR_ID_VIA,     PCI_DEVICE_ID_82C586_1

Can I get a patch, Andre?

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Adrian Bunk]

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 during early 2.4.x).
>
> It hasnt gotten worse, its just its a very specific combination and its a
> well known problem (vendors dont enable auto dma for ide for this reason)
> 2.2.16 just covers the cases I know about (and slightly overdoes it for now)
>
> > We've already had one major fs corruption due to this, I want that fixed
> > _first_.
>
> I've got other reports too.
>...

At least some of the reported problems with VIA chipsets are fixed with
the VIA IDE driver v3.11 [1]. Are there any problems that still occur with
this driver?

cu,
Adrian

[1] http://www.lib.uaa.alaska.edu/linux-kernel/archive/2001-Week-02/1291.html


-- 
A "No" uttered from deepest conviction is better and greater than a
"Yes" merely uttered to please, or what is worse, to avoid trouble.
                -- Mahatma Ghandi




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Andre Hedrick]

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 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).

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 chipset makers......you see the picture clearly, right?

> We've already had one major fs corruption due to this, I want that fixed
> _first_.

Well since I do not have VIA boards and Vojtech Pavlik <vojtech@suse.cz>
is doing that chipset, take that issue to him.  VIA has always been a HACK
fro mthe beginning because it was written off the whitepapers that stink.

The AMD and HPT366 code were to be in 2.4.0 release, but the early
surprize caused most to be off guard.

I will pull the TIMEOUT but this is one you have bitched me out before
about not fixing or attempting to fix.  You can not have it both ways.
This is why I made it a compile option and not default.  I have one report
that it does not help....thus I changed it to a compile option.  Yes one
report took it from mainstream to option.

Cheers,

Andre Hedrick
Linux ATA Development


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Linus Torvalds]

In article <Pine.LNX.4.10.10101121009230.1147-100000@master.linux-ide.org>,
Andre Hedrick  <andre@linux-ide.org> 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 chipset makers......you see the picture clearly, right?

No.

That experimental patch is _experimental_, and has not been reported by
anybody to fix anything at all.  Also, the DMA timeout on PIIX4 seems to
have nothing at all to do with the very silent corruption on VIA. At
least nobody has reported any error messages being produced on the VIA
corruption cases.

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 battletested that people believe
it truly will work).

			Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Vojtech Pavlik]

On Fri, Jan 12, 2001 at 10:55:22AM -0800, Linus Torvalds wrote:
> In article <Pine.LNX.4.10.10101121009230.1147-100000@master.linux-ide.org>,
> Andre Hedrick  <andre@linux-ide.org> 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 chipset makers......you see the picture clearly, right?
> 
> No.
> 
> That experimental patch is _experimental_, and has not been reported by
> anybody to fix anything at all.  Also, the DMA timeout on PIIX4 seems to
> have nothing at all to do with the very silent corruption on VIA. At
> least nobody has reported any error messages being produced on the VIA
> corruption cases.
> 
> 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 battletested that people believe
> it truly will work).

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.

Does anyone still have any vt82c586 or vt82c586a the 2.4 VIA driver is
corrupting data on?

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).

-- 
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Linus Torvalds]

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 fact, why I will _NOT_ accept anything but a simple auto-dma
disable for this problem for early 2.4.x. I hope that people will continue
to work on and debug this problem, but it's just been around for too long,
and it's obvious enough that it doesn't happen with all hardware that I
doubt there is any other reasonable solution that doesn't require some
_very_ extensive testing to verify.

I'd love to see people who see these problems and are willing to test out
patches to fix it. But in parallel with that, I definitely want the 2.2.x
"disable auto-DMA" thing for the big public. We can enable it later if
some patch does seem to fix it for good.

			Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Vojtech Pavlik]

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 _every_
> board.

Of course. That's why I'm calling for bug reports.

> This is, in fact, why I will _NOT_ accept anything but a simple auto-dma
> disable for this problem for early 2.4.x. I hope that people will continue
> to work on and debug this problem, but it's just been around for too long,
> and it's obvious enough that it doesn't happen with all hardware that I
> doubt there is any other reasonable solution that doesn't require some
> _very_ extensive testing to verify.
> 
> I'd love to see people who see these problems and are willing to test out
> patches to fix it. But in parallel with that, I definitely want the 2.2.x
> "disable auto-DMA" thing for the big public. We can enable it later if
> some patch does seem to fix it for good.

Sure.

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
Alan's code says or simply unconditionally kill autodma on all of VIA
chipsets, as Alan's code does?

-- 
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Alan Cox]

> 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 comment in
> Alan's code says or simply unconditionally kill autodma on all of VIA
> chipsets, as Alan's code does?

I'd take a 2.2 patch to cut down the range too
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Vojtech Pavlik]

On Fri, Jan 12, 2001 at 11:47:41PM +0000, 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 least the one you sent to me is about 586b. Which is the later stuff.

> > Would you prefer to filter just vt82c586 and vt82c586a as the comment in
> > Alan's code says or simply unconditionally kill autodma on all of VIA
> > chipsets, as Alan's code does?
> 
> I'd take a 2.2 patch to cut down the range too

I can make one for you, but first I'd like to find out what exactly are
the problem cases.

-- 
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Bryan O'Sullivan]

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. plugged into the UDMA-100 slot).  I've never seen any problems
with DMA on the newer drive, but if I turn on DMA and do anything with
the older drive, I get stuff like this:

  /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: 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 } 

The driver attempts to reset ide0 a few times, gets more of the above,
then gives up with an I/O error.

I've been seeing these problems as long as I've been tracking the 2.3
series, up to and including 2.4.0.  I can't boot a 2.2 kernel on this
machine to compare, as it doesn't recognise hde (which is where Linux
lives).

Here's the output of lspci under 2.4.0, in case it's useful:

  00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02)
  00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305
  00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22)
  00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10)
  00:04.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
  00:04.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
  00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
  00:09.0 CardBus bridge: Texas Instruments PCI1225 (rev 01)
  00:09.1 CardBus bridge: Texas Instruments PCI1225 (rev 01)
  00:0a.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
  00:0b.0 Multimedia audio controller: Creative Labs SB Live! EMU10000 (rev 08)
  00:0b.1 Input device controller: Creative Labs SB Live! (rev 08)
  00:11.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device 0d30 (rev 02)
  01:00.0 VGA compatible controller: nVidia Corporation: Unknown device 0150 (rev a3)

If you need any more information, I can dig it out.

	<b
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Vojtech Pavlik]

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'Sullivan wrote:
> 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. plugged into the UDMA-100 slot).  I've never seen any problems
> with DMA on the newer drive, but if I turn on DMA and do anything with
> the older drive, I get stuff like this:
> 
>   /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: 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 } 
> 
> The driver attempts to reset ide0 a few times, gets more of the above,
> then gives up with an I/O error.
> 
> I've been seeing these problems as long as I've been tracking the 2.3
> series, up to and including 2.4.0.  I can't boot a 2.2 kernel on this
> machine to compare, as it doesn't recognise hde (which is where Linux
> lives).
> 
> Here's the output of lspci under 2.4.0, in case it's useful:
> 
>   00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02)
>   00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305
>   00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22)
>   00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10)
>   00:04.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
>   00:04.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
>   00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
>   00:09.0 CardBus bridge: Texas Instruments PCI1225 (rev 01)
>   00:09.1 CardBus bridge: Texas Instruments PCI1225 (rev 01)
>   00:0a.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
>   00:0b.0 Multimedia audio controller: Creative Labs SB Live! EMU10000 (rev 08)
>   00:0b.1 Input device controller: Creative Labs SB Live! (rev 08)
>   00:11.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device 0d30 (rev 02)
>   01:00.0 VGA compatible controller: nVidia Corporation: Unknown device 0150 (rev a3)
> 
> If you need any more information, I can dig it out.
> 
> 	<b

-- 
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Linus Torvalds]

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
> Alan's code says or simply unconditionally kill autodma on all of VIA
> chipsets, as Alan's code does?

Right now, for 2.4.1, I'd rather have the patch to just do the same as
2.2.x. We can figure it out better when we get a better idea of exactly
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").

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Alan Cox]

> 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 not seen reports on the later chips. If they had been buggy and then 
fixed I'd have expected much unhappy ranting before the change

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[John Heil]

On Sat, 13 Jan 2001, Alan Cox wrote:

> Date: Sat, 13 Jan 2001 00:25:28 +0000 (GMT)
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> To: Linus Torvalds <torvalds@transmeta.com>
> Cc: Vojtech Pavlik <vojtech@suse.cz>, linux-kernel@vger.kernel.org
> 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 their symptoms too
> > and peopl ehaven't reported them because they are "fixed").
> 
> I've not seen reports on the later chips. If they had been buggy and then 
> fixed I'd have expected much unhappy ranting before the change

The "fix" was an hdparm command like hdparm -X66 -m16c1d1 /dev/hda.
Which I set for my VIA 686a on a Tyan mobo w a 1G Athlon.

Interestingly, initially feeding that chip 40 wire cables (w/o the
-X66 of course) would result in the crc errors followed by DMA turn off,
about 85% of time... Other 15% was fine and DMA worked great.

I then switched to the 80 wire cable and DMA became rock solid at
which point the -X66 was added.

Just thought I'd add some data points :) 

> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
> 

-----------------------------------------------------------------
John Heil
South Coast Software
Custom systems software for UNIX and IBM MVS mainframes
1-714-774-6952
kerndev@sc-software.com
johnhscs@sc-software.com
http://www.sc-software.com
-----------------------------------------------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Linus Torvalds]

On Fri, 12 Jan 2001, John Heil wrote:

> On Sat, 13 Jan 2001, Alan Cox wrote:
> 
> > Date: Sat, 13 Jan 2001 00:25:28 +0000 (GMT)
> > From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> > To: Linus Torvalds <torvalds@transmeta.com>
> > Cc: Vojtech Pavlik <vojtech@suse.cz>, linux-kernel@vger.kernel.org
> > 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 their symptoms too
> > > and peopl ehaven't reported them because they are "fixed").
> > 
> > I've not seen reports on the later chips. If they had been buggy and then 
> > fixed I'd have expected much unhappy ranting before the change
> 
> The "fix" was an hdparm command like hdparm -X66 -m16c1d1 /dev/hda.
> Which I set for my VIA 686a on a Tyan mobo w a 1G Athlon.

Careful. It may be that your fix just avoids the corruption because the
other changes make it ok - like the 16-sector multi-count thing maybe
hides a problem that might still exist - it just changes the "normal"
timing so that you won't ever see it in practice any more.

These kinds of magic interactions is why I'm not at all happy about driver
changes until people really know what it was that caused it, and _know_
that it's gone.

Anyway, for you the problem apparently happened even on a 686a, but just
the 586 series. Correct?

			Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[John Heil]

On Fri, 12 Jan 2001, Linus Torvalds wrote:

> Date: Fri, 12 Jan 2001 16:52:00 -0800 (PST)
> From: Linus Torvalds <torvalds@transmeta.com>
> To: John Heil <kerndev@sc-software.com>
> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>, Vojtech Pavlik <vojtech@suse.cz>,
>     linux-kernel@vger.kernel.org
> Subject: Re: ide.2.4.1-p3.01112001.patch
> 
> 
> 
> On Fri, 12 Jan 2001, John Heil wrote:
> 
> > On Sat, 13 Jan 2001, Alan Cox wrote:
> > 
> > > Date: Sat, 13 Jan 2001 00:25:28 +0000 (GMT)
> > > From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> > > To: Linus Torvalds <torvalds@transmeta.com>
> > > Cc: Vojtech Pavlik <vojtech@suse.cz>, linux-kernel@vger.kernel.org
> > > 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 their symptoms too
> > > > and peopl ehaven't reported them because they are "fixed").
> > > 
> > > I've not seen reports on the later chips. If they had been buggy and then 
> > > fixed I'd have expected much unhappy ranting before the change
> > 
> > The "fix" was an hdparm command like hdparm -X66 -m16c1d1 /dev/hda.
> > Which I set for my VIA 686a on a Tyan mobo w a 1G Athlon.
> 
> Careful. It may be that your fix just avoids the corruption because the
> other changes make it ok - like the 16-sector multi-count thing maybe
> hides a problem that might still exist - it just changes the "normal"
> timing so that you won't ever see it in practice any more.
> 
> These kinds of magic interactions is why I'm not at all happy about driver
> changes until people really know what it was that caused it, and _know_
> that it's gone.
> 
> Anyway, for you the problem apparently happened even on a 686a, but just
> the 586 series. Correct?

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 with.

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.

> 
> 			Linus
> 

-----------------------------------------------------------------
John Heil
South Coast Software
Custom systems software for UNIX and IBM MVS mainframes
1-714-774-6952
kerndev@sc-software.com
johnhscs@sc-software.com
http://www.sc-software.com
-----------------------------------------------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Linus Torvalds]

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 with.

This sounds like a totally different thing than the DMA corruption - this
sounds like you just got CRC error messages, and the driver still did the
right thing? 

The 82c586 corruption seems to be silently just writing (and maybe
reading) bad data to the disk.

The case of CRC errors and recivering from them (or fixing them with a
good cable) is different - when the CRC errors are noticed, they cause the
command to be re-tried and thus no data corruption should occur.

Basically it's the difference between being "silently bad" and "noisily
good". Sounds like you are in the "noisily good" category - a category
that I don't worry about ;)

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Matthias Andree]

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.

Yuck. What UDMA mode does your kernel put the drive in at boot WITHOUT
the -X option? -X66 means UDMA 2 (33).

-- 
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Andre Hedrick]

On Fri, 12 Jan 2001, Linus Torvalds wrote:

> 
> 
> On Fri, 12 Jan 2001, John Heil wrote:
> 
> > On Sat, 13 Jan 2001, Alan Cox wrote:
> > 
> > > Date: Sat, 13 Jan 2001 00:25:28 +0000 (GMT)
> > > From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> > > To: Linus Torvalds <torvalds@transmeta.com>
> > > Cc: Vojtech Pavlik <vojtech@suse.cz>, linux-kernel@vger.kernel.org
> > > 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 their symptoms too
> > > > and peopl ehaven't reported them because they are "fixed").
> > > 
> > > I've not seen reports on the later chips. If they had been buggy and then 
> > > fixed I'd have expected much unhappy ranting before the change
> > 
> > The "fix" was an hdparm command like hdparm -X66 -m16c1d1 /dev/hda.
                                                         ^^
There no chipset calls that allow one to envoke 32-bit data access on the
data-taskfile register.  This may bite you in the arse! (see below)

> > Which I set for my VIA 686a on a Tyan mobo w a 1G Athlon.
> 
> Careful. It may be that your fix just avoids the corruption because the
> other changes make it ok - like the 16-sector multi-count thing maybe
> hides a problem that might still exist - it just changes the "normal"
> timing so that you won't ever see it in practice any more.

This is why it is better to do on paper the timings and not create code
that is varible based on the "ide-bus-clock" not the "pci-bus-clock".
You can only run timings at 33MHz clocking, period.  The exceptions are
for those that can report from the chipset that a clocking-base other than
33 is detected.

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.

> These kinds of magic interactions is why I'm not at all happy about driver
> changes until people really know what it was that caused it, and _know_
> that it's gone.

Linus I know how the driver is to work and how it behaves in
non-multimodes, but I am not sure that even Mark Lord could tells you or
me about the true nature of the current multimode with various chipsets.

Sheesh some of them are now documenting that special bits must be set to
do 32-bit word access on the dataport.

Cheers,

Andre Hedrick
Linux ATA Development



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Linus Torvalds]

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 nothing to me.

They have very little to do with the concept of "working", which is all I
really personally care about.

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Andre Hedrick]

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 correct" and "state diagrams as in the standard" mean less
> that nothing to me.
> 
> They have very little to do with the concept of "working", which is all I
> really personally care about.

Translation:

You can do a bit level tracking of data and verify that what went down you
get it back across the entire disk.  This can be done in a random-pattern
that does not over-write (obvious) or from head->tail or tail->head.

It works perfectly and exactly as it is defined to work by the rules.
Getting the rules correct == 'the concept of "working"'.

However that model of IO is not complete yet. :-((

Cheers,

Andre Hedrick
Linux ATA Development

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Linus Torvalds]

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 discussion in the first place.

ANYBODY who does driver development without taking the real world into
account is a dangerous person. Stacks of papers, diagrams and rules are
absolutely WORTHLESS if you can't just understand the fact that
documentation is nothing more than a guide-line.

Once you realize that documentation should be laughed at, peed upon, put
on fire, and just ridiculed in general, THEN, and only then, have you
reached the level where you can safely read it and try to use it to
actually implement a driver.

I'm continually amazed and absolutely scared silly by your blind trust in
paperwork, whether it be standards or committees or vendor documentation.

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Andre Hedrick]

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 of hardware bugs. Which is one very
> likely reason for this whole discussion in the first place.
> 
> ANYBODY who does driver development without taking the real world into
> account is a dangerous person. Stacks of papers, diagrams and rules are
> absolutely WORTHLESS if you can't just understand the fact that
> documentation is nothing more than a guide-line.
> 
> Once you realize that documentation should be laughed at, peed upon, put
> on fire, and just ridiculed in general, THEN, and only then, have you
> reached the level where you can safely read it and try to use it to
> actually implement a driver.
> 
> I'm continually amazed and absolutely scared silly by your blind trust in
> paperwork, whether it be standards or committees or vendor documentation.

Test and Verify!  It has been abused on an ATA-Analyzer!
It was written while running on an ATA-Analyzer!
The real world does not get any more real than on an ATA-Analyzer!
Since this was a done by direct access with out the FS/VM mess it is an
exact method of operation, it is a perfect data-signal trace.
Perfect == fits exactly in the boundaries of the state-diagrams.

This is how you write code, LT.

Follow the rules, and the verify the rules are correct.
If they are not, fix it until it is correct and see what happened in the
rules.  I have offered to get you signed letters of technical
certification by the drive makers, and you have declined.

The idea of just banging code to get the desired result regardless of
public methods published to insure comman design/correctness is all but
silly.  What do you think timing tables are for, wallpaper or to line the
bottom of a bird cage?  Sheesh....  You have to access a PCI-bus, CPU, AGP
and all these other things in the correct event windows, or do you?

Regards,

Andre Hedrick
Linux ATA Development

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Andre Hedrick]

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 of hardware bugs. Which is one very
> likely reason for this whole discussion in the first place.

First you get the access correct and assume no bugs, round one.
After this is fixed, then you address the "hardware bugs" by execption
rules and not the basic premis, the endless round.

Regards,

Andre Hedrick
Linux ATA Development

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Vojtech Pavlik]

On Fri, Jan 12, 2001 at 04:52:00PM -0800, Linus Torvalds wrote:
> 
> 
> On Fri, 12 Jan 2001, John Heil wrote:
> 
> > On Sat, 13 Jan 2001, Alan Cox wrote:
> > 
> > > Date: Sat, 13 Jan 2001 00:25:28 +0000 (GMT)
> > > From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> > > To: Linus Torvalds <torvalds@transmeta.com>
> > > Cc: Vojtech Pavlik <vojtech@suse.cz>, linux-kernel@vger.kernel.org
> > > 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 their symptoms too
> > > > and peopl ehaven't reported them because they are "fixed").
> > > 
> > > I've not seen reports on the later chips. If they had been buggy and then 
> > > fixed I'd have expected much unhappy ranting before the change
> > 
> > The "fix" was an hdparm command like hdparm -X66 -m16c1d1 /dev/hda.
> > Which I set for my VIA 686a on a Tyan mobo w a 1G Athlon.
> 
> Careful. It may be that your fix just avoids the corruption because the
> other changes make it ok - like the 16-sector multi-count thing maybe
> hides a problem that might still exist - it just changes the "normal"
> timing so that you won't ever see it in practice any more.
> 
> These kinds of magic interactions is why I'm not at all happy about driver
> changes until people really know what it was that caused it, and _know_
> that it's gone.
> 
> Anyway, for you the problem apparently happened even on a 686a, but just
> the 586 series. Correct?

Yes, but this is a different problem. No corruption was happening here.

-- 
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Vojtech Pavlik]

[-- Attachment #1: Type: text/plain, Size: 1526 bytes --]

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.
> > 
> > Would you prefer to filter just vt82c586 and vt82c586a as the comment in
> > Alan's code says or simply unconditionally kill autodma on all of VIA
> > chipsets, as Alan's code does?
> 
> Right now, for 2.4.1, I'd rather have the patch to just do the same as
> 2.2.x. We can figure it out better when we get a better idea of exactly
> 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").
> 
> 		Linus

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, and up to the 686a UDMA66 chipset.

Also note that enabling the DMA later with hdparm -X66 -d1 or similar
command is not safe, and usually works by pure luck on VIA chipsets.
This however, would need some non-minor changes to the generic code to
fix.

But perhaps it's still worth ...

-- 
Vojtech Pavlik
SuSE Labs

[-- Attachment #2: via-no-autodma.diff --]
[-- Type: text/plain, Size: 996 bytes --]

diff -urN linux-old/drivers/ide/ide-pci.c linux/drivers/ide/ide-pci.c
--- linux-old/drivers/ide/ide-pci.c	Wed Jan  3 01:58:45 2001
+++ linux/drivers/ide/ide-pci.c	Sat Jan 13 14:54:53 2001
@@ -663,7 +663,9 @@
 		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, DEVID_HPT34X)  ||
+		    IDE_PCI_DEVID_EQ(d->devid, DEVID_VIA_IDE) ||
+		    IDE_PCI_DEVID_EQ(d->devid, DEVID_VP_IDE))
 			autodma = 0;
 		if (autodma)
 			hwif->autodma = 1;
diff -urN linux-old/drivers/ide/via82cxxx.c linux/drivers/ide/via82cxxx.c
--- linux-old/drivers/ide/via82cxxx.c	Tue Nov  7 20:02:24 2000
+++ linux/drivers/ide/via82cxxx.c	Sat Jan 13 14:52:26 2001
@@ -602,7 +602,6 @@
 #ifdef CONFIG_BLK_DEV_IDEDMA
 	if (hwif->dma_base) {
 		hwif->dmaproc = &via82cxxx_dmaproc;
-		hwif->autodma = 1;
 	}
 #endif /* CONFIG_BLK_DEV_IDEDMA */
 }

Re: ide.2.4.1-p3.01112001.patch

[Alan Cox]

>  		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, DEVID_HPT34X)  ||
> +		    IDE_PCI_DEVID_EQ(d->devid, DEVID_VIA_IDE) ||
> +		    IDE_PCI_DEVID_EQ(d->devid, DEVID_VP_IDE))
>  			autodma = 0;
>  		if (autodma)
>  			hwif->autodma = 1;

How about

		    && !force_dma)


__setup("force_dma") ...

So those who want to play fast can
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Andre Hedrick]

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 "rm -rf ./drivers/ide"
and start with "mkdir ./drivers/ata" ;-))  Okay not quite that radical but
very close....

On Sat, 13 Jan 2001, Alan Cox wrote:

> >  		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, DEVID_HPT34X)  ||
> > +		    IDE_PCI_DEVID_EQ(d->devid, DEVID_VIA_IDE) ||
> > +		    IDE_PCI_DEVID_EQ(d->devid, DEVID_VP_IDE))
> >  			autodma = 0;
> >  		if (autodma)
> >  			hwif->autodma = 1;
> 
> How about
> 
> 		    && !force_dma)
> 
> 
> __setup("force_dma") ...
> 
> So those who want to play fast can
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
> 

Andre Hedrick
Linux ATA Development

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[TimO]

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, and up to the 686a UDMA66 chipset.
> 
> Also note that enabling the DMA later with hdparm -X66 -d1 or similar
> command is not safe, and usually works by pure luck on VIA chipsets.
> This however, would need some non-minor changes to the generic code to
> fix.
> 
> But perhaps it's still worth ...
> 
> --
> Vojtech Pavlik
> SuSE Labs
> 
>

_ouch_  Will -X66 -d1c1m16 be as stable with this patch as version 2.1e
has been for me??  It has always (auto)set transfer speeds properly and
I have never seen corruption with my 686a -- 'cept when patching from
test11-pre7 to test12-pre1, and I'm pretty sure that was from other
factors.

===============
-- Tim
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Vojtech Pavlik]

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 safe, and usually works by pure luck on VIA chipsets.
> > This however, would need some non-minor changes to the generic code to
> > fix.
> 
> _ouch_  Will -X66 -d1c1m16 be as stable with this patch as version 2.1e
> has been for me??  It has always (auto)set transfer speeds properly and
> I have never seen corruption with my 686a -- 'cept when patching from
> test11-pre7 to test12-pre1, and I'm pretty sure that was from other
> factors.

Well, can't tell. For some reason hdparm doesn't tell the VIA driver to
update the timings in the chipset when changing modes. The fact that
UDMA will start to work after this command is only due to that the VIA
chips do have a built in filter for UDMA commands, notice the command
sent to the harddrive, and switch the UDMA mode on. However the timings
stay as were, as perhaps the BIOS set them up. So it may work or may
not. 

As I said, getting it to work reliably needs changes in the generic code
(hdparm should call the correct ioctl, and the ioctl must call the
timing routine in the specific chipset code).

If the patch I sent to Linus gets applied, I'll probably submit another
one that will allow to override the no-dma rule by a kernel command line
option, as Alan Cox suggested.

-- 
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Stephen Clark]

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 supply, etc ) with the
systems that reported problems? What percentage of people are running OK VS
those that are not?

Now everybody with a VIA chipset is going to be punished!

My $.02
Steve

Vojtech Pavlik wrote:

> 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.
> > >
> > > Would you prefer to filter just vt82c586 and vt82c586a as the comment in
> > > Alan's code says or simply unconditionally kill autodma on all of VIA
> > > chipsets, as Alan's code does?
> >
> > Right now, for 2.4.1, I'd rather have the patch to just do the same as
> > 2.2.x. We can figure it out better when we get a better idea of exactly
> > 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").
> >
> >               Linus
>
> 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, and up to the 686a UDMA66 chipset.
>
> Also note that enabling the DMA later with hdparm -X66 -d1 or similar
> command is not safe, and usually works by pure luck on VIA chipsets.
> This however, would need some non-minor changes to the generic code to
> fix.
>
> But perhaps it's still worth ...
>
> --
> Vojtech Pavlik
> SuSE Labs
>
>   ------------------------------------------------------------------------
>
>    via-no-autodma.diffName: via-no-autodma.diff
>                       Type: Plain Text (text/plain)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

VIA IDE corruption - anyone experiencing it with 2.4.0?

[Vojtech Pavlik]

On Sat, Jan 13, 2001 at 06:03:11AM -0600, Thomas Molina wrote:

> Are you looking for specific chipsets or configurations?  Following is
> my VP3/MVP3 chipset lspci output if you are gathering a group of
> testers.  I've enabled autoDMA at various points in the testing cycle
> (not consistently) but haven't noticed any fs corruption.

Ok. So what I'm exactly looking for:

Cases of harddrive corruption (that is, trashing your fs,
reading/writing bad data) on VIA chipsets. UDMA-caused CRC errors don't
fall into this category, they're harmless to the data.

Preferably with the driver from the 2.4.0 kernel. If possible, try also
the VIA 3.11 driver posted to the list earlier. If you don't have it, I
can e-mail it to you.

Don't use any hdparm command in your init scripts (this is important)
with the VIA driver and 2.4.0, setting the speed or dma usage with
hdparm would interfere with the driver autotuning.

If you fear to test, you can mount your fs readonly (no corruption can
happen) and use your swap partition for read-write test. You can even
mke2fs the swap for a while.

Anyone who experienced this kind of problems with 2.4 and the VIA
driver, please speak up, so I can fix it.

I'm not currently looking for success reports, I've already got success
reports for every type VIA IDE chip out there. 

I'll need the motherboard type and revision, lspci -vvxxx, dmesg,
hdparm -i and /proc/ide/via listings ...

Thanks.

-- 
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Alan Cox]

> 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 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 not all.
What combination of chips is on the 2013 ?

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[davej]

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 not all.
> What combination of chips is on the 2013 ?

The FIC PA-2013 is one of the stranger types of MVP3.
(A mixture of 82c597 host bridge and 82c598 PCI bridge).

As discussed some time ago on this list, there are some of these
boards, which initially seem to be an MVP3, but have the host bridge ID
set to an VP3. (Real reasoning behind this never figured out).

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.

I have a list of known 'hybrid' boards, and known true (both halves) MVP3
boards and also a collection of lspci -xxx outputs from a selection of
them. If anyone wants any of this stuff, shout and I'll put it up
for ftp/www.

I'm curious if all of the other boards in Alans bug reports also
fall into the stranger category.

regards,

Davej.

-- 
| Dave Jones.        http://www.suse.de/~davej
| SuSE Labs

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Vojtech Pavlik]

On Sat, Jan 13, 2001 at 02:43:30AM +0000, davej@suse.de 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 not all.
> > What combination of chips is on the 2013 ?
> 
> The FIC PA-2013 is one of the stranger types of MVP3.
> (A mixture of 82c597 host bridge and 82c598 PCI bridge).

598 + 586b

> As discussed some time ago on this list, there are some of these
> boards, which initially seem to be an MVP3, but have the host bridge ID
> set to an VP3. (Real reasoning behind this never figured out).

Windows driver compatibility, so that VP3 drivers would work on MVP3 as
well.

> 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 do anything but change the ID so that Linux drivers are not
confused anymore. This caused a lot of trouble in 2.2, especially with
the old VIA IDE driver.

> I have a list of known 'hybrid' boards, and known true (both halves) MVP3
> boards and also a collection of lspci -xxx outputs from a selection of
> them. If anyone wants any of this stuff, shout and I'll put it up
> for ftp/www.

Actually, the definitions of what's a 'true VIA xxx chipset' change over
time, as VIA upgrades the southbridges in the specs. You'll now fing
that the VPX chipset is 587vpx + 586b, but when released the 587vpx was
coupled with the old 586 south.

Fortunately all these chips use PIIX-compatible extensions to the PCI
bus, so they are all interchangeable to some degree.

> I'm curious if all of the other boards in Alans bug reports also
> fall into the stranger category.

It's possible. I have a board (VA-503A), which has a masqueraded 598,
which identifies itself as 597, and a 686a southbridge. This got the
2.2 ide driver completely confused, for example. 

-- 
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Vojtech Pavlik]

On Fri, Jan 12, 2001 at 11:43:23PM +0000, 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 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 not all.
> What combination of chips is on the 2013 ?

As far as I know the same as on FIC VA-503+, that is vt82c598 north and
vt82c586b south - the MVP3 chipset. I've got the VA-503+ here and it
works really well. the 503+ and the 2013 differ only in form factor, one
is Baby AT (503+) and the other is ATX.

It's vt82c586b, and most probably 3041 silicon - the most bugless VIA
southbridge I know of ...

Weird. Could the person who reported it test the 2.4.0 kernel? I think
the 2.2 drivers had some MVP3 (and 3041 silicon)  related bugs. 3041 has
some registers layed out differently from all other chips.

Btw, this is not the 586 nor 586a, so changing the test to test for just
these two probably won't be the right thing to do ...

-- 
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Jamie Lokier]

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 Fireball ST, 64MB RAM and an AMD K6-233.  The chipset
reports as VIA VP2/97; sorry, I do not have access to get the PCI IDs.

It locks up with DMA enabled, typically after a few hours, and has done
that since 2.1 kernel days.

Unfortunately it locks up with Mandrake 7.2 which is not very old (based
on 2.2.17 kernels -- it's not my PC any more but I installed Mandrake on
it recently).

Kernel option "ide=nodma" fixes this -- no lockups.

After that "hdparm -X34 -d1" enables DMA and the board remains reliable.
I observed one lockup in several years, while X was starting so it could
have been X.  -X34 does not change the results of "hdparm -t".

Note that "hdparm -X34 -d1" enables old DMA, not UDMA.  (The board was
advertised as UDMA capable but it isn't AFAIK).

enjoy,
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Vojtech Pavlik]

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 changed my mind somewhere in history) with a
> 6.4G Quantum Fireball ST, 64MB RAM and an AMD K6-233.  The chipset
> reports as VIA VP2/97; sorry, I do not have access to get the PCI IDs.

PA-2007 is indeed a VP2/97, a very nice board, with vt82c595+vt82c586b.

> It locks up with DMA enabled, typically after a few hours, and has done
> that since 2.1 kernel days.
> 
> Unfortunately it locks up with Mandrake 7.2 which is not very old (based
> on 2.2.17 kernels -- it's not my PC any more but I installed Mandrake on
> it recently).
> 
> Kernel option "ide=nodma" fixes this -- no lockups.
> 
> After that "hdparm -X34 -d1" enables DMA and the board remains reliable.
> I observed one lockup in several years, while X was starting so it could
> have been X.  -X34 does not change the results of "hdparm -t".
> 
> Note that "hdparm -X34 -d1" enables old DMA, not UDMA.  (The board was
> advertised as UDMA capable but it isn't AFAIK).

It should be able to do UDMA33.

Is the board still available for some testing?

-- 
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Albert Cranford]

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
Calibrating delay loop... 478.41 BogoMIPS
Memory: 61920k/65536k available (1197k kernel code, 3228k reserved, 432k data, 244k init, 0k highmem)
Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
CPU: Before vendor init, caps: 008001bf 008005bf 00000000, vendor = 2
CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line)
CPU: After vendor init, caps: 008001bf 008005bf 00000000 00000000
CPU: After generic, caps: 008001bf 008005bf 00000000 00000000
CPU: Common caps: 008001bf 008005bf 00000000 00000000
CPU: AMD-K6tm w/ multimedia extensions stepping 02
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
.............SNIP..............
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c586a IDE UDMA33 controller on pci0:7.1
    ide0: BM-DMA at 0xfff0-0xfff7, BIOS settings: hda:pio, hdb:pio
hda: WDC AC2540F, ATA DISK drive
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
hda: set_drive_speed_status: error=0x04 { DriveStatusError }
hda: 1056384 sectors (541 MB) w/64KiB Cache, CHS=524/32/63, DMA

lspci -vv
00:00.0 Host bridge: VIA Technologies, Inc. VT82C595/97 [Apollo VP2/97] (rev 03)
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR+
        Latency: 32 set

00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA [Apollo VP] (rev 25)
        Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0 set

00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06) (prog-if 8a [Master SecP PriP])
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 set
        Region 4: I/O ports at fff0 [size=16]
-- 
Albert Cranford Deerfield Beach FL USA
ac9410@bellsouth.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Henrique de Moraes Holschuh]

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_status: status=0x51 { DriveReady SeekComplete Error }
> hda: set_drive_speed_status: error=0x04 { DriveStatusError }
> hda: 1056384 sectors (541 MB) w/64KiB Cache, CHS=524/32/63, DMA

I have a FIC PA-2007 (the older one, with a 586A bridge instead of the 586B
of later FIC PA-2007 boards), running at 75MHz FSB (PCI bus runs at 37.5MHz,
so I suppose I should use idebus=37.5 if I were to try 2.4.x), and a Quantum
Fireball lct15 30MB.

It works flawlessly in UDMA mode 2 (although I have to force the drive to
UDMA mode 2 with -X66 before enabling dma, because the bogus beta BIOS I use
sets it to UDMA4 which is not supported by the 586A). Kernel is 2.2.18,
without the 2.4.x ide backport.

The lspci output is exactly the same as yours.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Jamie Lokier]

> > 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 (Wales vs. France), but I
visit it every few months so there is some chance of me testing it on
that timescale.  AFAIK there are no computer experts in the area to
enable remote access ;-)

> It should be able to do UDMA33.

It does not look hopeful.  Let us look at an old email:

From: Jamie Lokier <jamie@tantalophile.demon.co.uk>
To: Michel Aubry <giovanni@sudfr.com>
Subject: Re: mozilla+XFree86+Linux-2.1.x  => HARD LOCKUP (addition)

On Wed, Dec 09, 1998 at 04:30:34PM +0100, Michel Aubry wrote:
> Is this to say that your bios has no "select UDMA" or so capability???
> Is your motherboard an old one? (that was not udma compliant).

It has "Bus Master DMA" option, but no "UDMA" option.  It's an FIC
PC-2011, manufactured about August 1997.  I always assumed the hardware
did UDMA (that's one reason I bought it).

>       you should edit via82c586.c , uncomment or add a 
> "#define DISPLAY_VIA_TIMINGS"
>       and recompile your kernel...

Will do, at my next recompile.  Would that be with the patch you sent me?

> You ought to know that linux kernel via patch requires your bios to be
> udma compliant. If not, all you can do safely is run it dma only!

Is this strictly true?  You've obviously got all the chipset docs, and I
doubt anything on the motherboard interferes with IDE timings/state
machines.

> > [root@tantalophile linux]# hdparm -I /dev/hda

>       this one is not running udma!

I know, I did hdparm -X34 explicitly to avoid lockups.

> > [root@tantalophile linux]# hdparm -i /dev/hda
> 
>       this one is running udma!

And with these settings unchanged, the system locks up from time to
time.

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Tkil]

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 another full revision level
(2.x), and the BIOSes for these different revisions are *not*
compatible (as I found out to my chagrin ;-).

Also, the FIC PA-513 (maybe 512?) should be a very similar board, only
wired for an AT power supply where the PA-2013 is an ATX board.

I've never seen the DMA data corruption on this box, but I'd really
really like to get something better than 3MB/s off my UDMA/66-capable
drives.  I'm pretty sure that (prior to the 2.2.18 squelching of all
VIA IDE UDMA) that hda and hdc would come up with DMA enabled, at the
very least.  Is there a safe way to test various hdparm settings?  I'm 
even willing to buy a scratch disk if that would help...

Looking at the chips, I have:

1. VIA
   VT82C598MVP
   9828CE Taiwan
   13G003900

2. VIA
   VT82C586B
   S7-SB
   9826CD Taiwan
   14B013511

It has an Award BIOS with a variety of WinBond support chips (looks
like at least 4 on-board cache chips, and one near the BIOS EEPROM).

Here's the relevant dmesg bits:

| PCI: PCI BIOS revision 2.10 entry at 0xfb490
| PCI: Using configuration type 1
| PCI: Probing PCI hardware
| PCI: 00:38 [1106/0586]: Work around ISA DMA hangs (00)
| Activating ISA DMA hang workarounds.
| Detected PS/2 Mouse Port.
| Serial driver version 4.27 with no serial options enabled
| ttyS00 at 0x03f8 (irq = 4) is a 16550A
| ttyS01 at 0x02f8 (irq = 3) is a 16550A
| Real Time Clock Driver v1.09
| VP_IDE: IDE controller on PCI bus 00 dev 39
| VP_IDE: not 100% native mode: will probe irqs later
|     ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:DMA, hdb:DMA
| ide0: VIA Bus-Master (U)DMA Timing Config Success
|     ide1: BM-DMA at 0xe008-0xe00f, BIOS settings: hdc:DMA, hdd:DMA
| ide1: VIA Bus-Master (U)DMA Timing Config Success
| hda: WDC WD307AA, ATA DISK drive
| hdc: Maxtor 96147H8, ATA DISK drive
| ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
| ide1 at 0x170-0x177,0x376 on irq 15
| hda: WDC WD307AA, 29333MB w/2048kB Cache, CHS=59598/16/63
| hdc: Maxtor 96147H8, 58623MB w/2048kB Cache, CHS=7473/255/63
| Floppy drive(s): fd0 is 1.44M
| FDC 0 is a post-1991 82077
| Partition check:
|  sda: sda1 sda2 sda3 < sda5 sda6 sda7 >
|  hda: [PTBL] [3739/255/63] hda1
|  hdc: hdc1
| apm: BIOS version 1.2 Flags 0x07 (Driver version 1.13)

Short version of lspci:

| 00:00.0 Host bridge: VIA Technologies, Inc. VT82C597 [Apollo VP3] (rev 04)
| 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP]
| 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586 ISA [Apollo VP] (rev 41)
| 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06)
| 00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 02)
| 00:07.3 Bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 10)
| 00:08.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c875 (rev 03)
| 00:0a.0 Ethernet controller: Digital Equipment Corporation DECchip 21140 [FasterNet] (rev 22)
| 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP [Millennium G200 AGP] (rev 01)

I've included "hdparm" and "lspci -vvxxx" output below, omitting
non-chipset related things (SCSI, Ethernet, and VGA).  If it matters,
this board is running 100MHz FSB with a 450MHz K6-3 CPU and 384MB (3 x
128MB DIMMs) of PC-100 SDRAM.

If I can provide any more information, please don't hesitate to ask.

Thanks,
t.

hdparm output:

| # for i in hda hdc ; do hdparm /dev/$i ; hdparm -i /dev/$i ; done
| 
| /dev/hda:
|  multcount    =  0 (off)
|  I/O support  =  0 (default 16-bit)
|  unmaskirq    =  0 (off)
|  using_dma    =  0 (off)
|  keepsettings =  0 (off)
|  nowerr       =  0 (off)
|  readonly     =  0 (off)
|  readahead    =  8 (on)
|  geometry     = 3739/255/63, sectors = 60074784, start = 0
| 
| /dev/hda:
| 
|  Model=WDC WD307AA, FwRev=05.05B05, SerialNo=WD-WMA11
|  Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
|  RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40
|  BuffType=3(DualPortCache), BuffSize=2048kB, MaxMultSect=16, MultSect=off
|  DblWordIO=no, maxPIO=2(fast), DMA=yes, maxDMA=0(slow)
|  CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=60074784
|  tDMA={min:120,rec:120}, DMA modes: mword0 mword1 *mword2 
|  IORDY=on/off, tPIO={min:120,w/IORDY:120}, PIO modes: mode3 mode4 
| 
| 
| /dev/hdc:
|  multcount    =  0 (off)
|  I/O support  =  0 (default 16-bit)
|  unmaskirq    =  0 (off)
|  using_dma    =  0 (off)
|  keepsettings =  0 (off)
|  nowerr       =  0 (off)
|  readonly     =  0 (off)
|  readahead    =  8 (on)
|  geometry     = 7473/255/63, sectors = 120060864, start = 0
| 
| /dev/hdc:
| 
|  Model=Maxtor 96147H8, FwRev=BAC51KJ0, SerialNo=N80CP5KC
|  Config={ Fixed }
|  RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
|  BuffType=3(DualPortCache), BuffSize=2048kB, MaxMultSect=16, MultSect=off
|  DblWordIO=no, maxPIO=2(fast), DMA=yes, maxDMA=0(slow)
|  CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=120060864
|  tDMA={min:120,rec:120}, DMA modes: mword0 mword1 *mword2 
|  IORDY=on/off, tPIO={min:120,w/IORDY:120}, PIO modes: mode3 mode4 

lspci -vvxxx output:

| 00:00.0 Host bridge: VIA Technologies, Inc. VT82C597 [Apollo VP3] (rev 04)
| 	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
| 	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
| 	Latency: 16 set
| 	Region 0: Memory at e0000000 (32-bit, prefetchable)
| 	Capabilities: [a0] AGP version 1.0
| 		Status: RQ=7 SBA+ 64bit- FW- Rate=1
| 		Command: RQ=7 SBA+ AGP- 64bit- FW- Rate=1
| 00: 06 11 97 05 06 00 90 02 04 00 00 06 00 10 00 00
| 10: 08 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 00
| 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
| 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 50: 80 0a 05 40 00 00 00 00 98 80 10 10 20 20 28 30
| 60: 3f 2a 00 23 e4 e4 e4 00 01 00 50 00 60 67 00 00
| 70: e1 0a 6c 00 00 80 40 00 00 00 00 00 00 00 00 40
| 80: 00 00 00 00 c0 00 00 00 02 00 00 00 00 00 00 00
| 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| a0: 02 00 10 00 01 02 00 07 00 00 00 00 0a 00 00 00
| b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| f0: 00 00 00 00 00 00 00 00 00 00 00 00 01 00 97 05
|
| 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP]
| 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
| 	Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
| 	Latency: 0 set
| 	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
| 	I/O behind bridge: 0000d000-0000dfff
| 	Memory behind bridge: e4000000-e7ffffff
| 	Prefetchable memory behind bridge: e8000000-e8ffffff
| 	BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
| 00: 06 11 98 85 07 00 20 22 00 00 04 06 00 00 01 00
| 10: 00 00 00 00 00 00 00 00 00 01 01 00 d0 d0 00 00
| 20: 00 e4 f0 e7 00 e8 f0 e8 00 00 00 00 00 00 00 00
| 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0c 00
| 40: f0 ec 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
| 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586 ISA [Apollo VP] (rev 41)
| 	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
| 	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
| 	Latency: 0 set
| 00: 06 11 86 05 8f 00 00 02 41 00 01 06 00 00 80 00
| 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 40: 00 05 00 00 01 00 10 a0 21 00 c4 00 00 00 00 f3
| 50: 24 00 00 00 00 00 a0 90 00 06 f7 00 10 00 00 00
| 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
| 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06) (prog-if 8a)
| 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
| 	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
| 	Latency: 64 set
| 	Region 4: I/O ports at e000
| 00: 06 11 71 05 07 00 80 02 06 8a 01 01 00 40 00 00
| 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 20: 01 e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 40: 0b f2 09 3a 69 00 f0 00 a8 a8 a8 a8 ff 00 ff ff
| 50: 03 03 03 03 00 00 00 00 a8 a8 a8 a8 00 00 00 00
| 60: 00 02 00 00 00 00 00 00 00 02 00 00 00 00 00 00
| 70: 22 00 00 00 00 00 00 00 42 00 00 00 00 00 00 00
| 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| d0: 06 00 71 05 00 00 00 00 00 00 00 00 00 00 00 00
| e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
| 00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 02)
| 	Subsystem: Unknown device 0925:1234
| 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
| 	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
| 	Latency: 64 set, cache line size 08
| 	Interrupt: pin D routed to IRQ 9
| 	Region 4: I/O ports at e400
| 00: 06 11 38 30 07 00 00 02 02 00 03 0c 08 40 00 00
| 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 20: 01 e4 00 00 00 00 00 00 00 00 00 00 25 09 34 12
| 30: 00 00 00 00 00 00 00 00 00 00 00 00 09 04 00 00
| 40: 00 00 00 00 c6 00 11 18 00 00 00 00 00 00 00 00
| 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 60: 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| c0: 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
| 00:07.3 Bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 10)
| 	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
| 	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
| 00: 06 11 40 30 00 00 80 02 10 00 80 06 00 00 00 00
| 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 40: 40 88 09 00 78 38 00 00 01 60 00 00 00 00 00 00
| 50: 00 7c ee 88 00 00 00 00 00 00 00 00 00 00 00 00
| 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Vojtech Pavlik]

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 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 another full revision level
> (2.x), and the BIOSes for these different revisions are *not*
> compatible (as I found out to my chagrin ;-).
> 
> Also, the FIC PA-513 (maybe 512?) should be a very similar board, only
> wired for an AT power supply where the PA-2013 is an ATX board.
> 
> I've never seen the DMA data corruption on this box, but I'd really
> really like to get something better than 3MB/s off my UDMA/66-capable
> drives.  I'm pretty sure that (prior to the 2.2.18 squelching of all
> VIA IDE UDMA) that hda and hdc would come up with DMA enabled, at the
> very least.  Is there a safe way to test various hdparm settings?  I'm 
> even willing to buy a scratch disk if that would help...
> 
> Looking at the chips, I have:
> 
> 1. VIA
>    VT82C598MVP
>    9828CE Taiwan
>    13G003900
> 
> 2. VIA
>    VT82C586B
>    S7-SB
>    9826CD Taiwan
>    14B013511
> 
> It has an Award BIOS with a variety of WinBond support chips (looks
> like at least 4 on-board cache chips, and one near the BIOS EEPROM).
> 
> Here's the relevant dmesg bits:
> 
> | PCI: PCI BIOS revision 2.10 entry at 0xfb490
> | PCI: Using configuration type 1
> | PCI: Probing PCI hardware
> | PCI: 00:38 [1106/0586]: Work around ISA DMA hangs (00)
> | Activating ISA DMA hang workarounds.
> | Detected PS/2 Mouse Port.
> | Serial driver version 4.27 with no serial options enabled
> | ttyS00 at 0x03f8 (irq = 4) is a 16550A
> | ttyS01 at 0x02f8 (irq = 3) is a 16550A
> | Real Time Clock Driver v1.09
> | VP_IDE: IDE controller on PCI bus 00 dev 39
> | VP_IDE: not 100% native mode: will probe irqs later
> |     ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:DMA, hdb:DMA
> | ide0: VIA Bus-Master (U)DMA Timing Config Success
> |     ide1: BM-DMA at 0xe008-0xe00f, BIOS settings: hdc:DMA, hdd:DMA
> | ide1: VIA Bus-Master (U)DMA Timing Config Success
> | hda: WDC WD307AA, ATA DISK drive
> | hdc: Maxtor 96147H8, ATA DISK drive
> | ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> | ide1 at 0x170-0x177,0x376 on irq 15
> | hda: WDC WD307AA, 29333MB w/2048kB Cache, CHS=59598/16/63
> | hdc: Maxtor 96147H8, 58623MB w/2048kB Cache, CHS=7473/255/63
> | Floppy drive(s): fd0 is 1.44M
> | FDC 0 is a post-1991 82077
> | Partition check:
> |  sda: sda1 sda2 sda3 < sda5 sda6 sda7 >
> |  hda: [PTBL] [3739/255/63] hda1
> |  hdc: hdc1
> | apm: BIOS version 1.2 Flags 0x07 (Driver version 1.13)
> 
> Short version of lspci:
> 
> | 00:00.0 Host bridge: VIA Technologies, Inc. VT82C597 [Apollo VP3] (rev 04)
> | 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP]
> | 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586 ISA [Apollo VP] (rev 41)
> | 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06)
> | 00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 02)
> | 00:07.3 Bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 10)
> | 00:08.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c875 (rev 03)
> | 00:0a.0 Ethernet controller: Digital Equipment Corporation DECchip 21140 [FasterNet] (rev 22)
> | 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP [Millennium G200 AGP] (rev 01)
> 
> I've included "hdparm" and "lspci -vvxxx" output below, omitting
> non-chipset related things (SCSI, Ethernet, and VGA).  If it matters,
> this board is running 100MHz FSB with a 450MHz K6-3 CPU and 384MB (3 x
> 128MB DIMMs) of PC-100 SDRAM.
> 
> If I can provide any more information, please don't hesitate to ask.
> 
> Thanks,
> t.
> 
> hdparm output:
> 
> | # for i in hda hdc ; do hdparm /dev/$i ; hdparm -i /dev/$i ; done
> | 
> | /dev/hda:
> |  multcount    =  0 (off)
> |  I/O support  =  0 (default 16-bit)
> |  unmaskirq    =  0 (off)
> |  using_dma    =  0 (off)
> |  keepsettings =  0 (off)
> |  nowerr       =  0 (off)
> |  readonly     =  0 (off)
> |  readahead    =  8 (on)
> |  geometry     = 3739/255/63, sectors = 60074784, start = 0
> | 
> | /dev/hda:
> | 
> |  Model=WDC WD307AA, FwRev=05.05B05, SerialNo=WD-WMA11
> |  Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
> |  RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40
> |  BuffType=3(DualPortCache), BuffSize=2048kB, MaxMultSect=16, MultSect=off
> |  DblWordIO=no, maxPIO=2(fast), DMA=yes, maxDMA=0(slow)
> |  CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=60074784
> |  tDMA={min:120,rec:120}, DMA modes: mword0 mword1 *mword2 
> |  IORDY=on/off, tPIO={min:120,w/IORDY:120}, PIO modes: mode3 mode4 
> | 
> | 
> | /dev/hdc:
> |  multcount    =  0 (off)
> |  I/O support  =  0 (default 16-bit)
> |  unmaskirq    =  0 (off)
> |  using_dma    =  0 (off)
> |  keepsettings =  0 (off)
> |  nowerr       =  0 (off)
> |  readonly     =  0 (off)
> |  readahead    =  8 (on)
> |  geometry     = 7473/255/63, sectors = 120060864, start = 0
> | 
> | /dev/hdc:
> | 
> |  Model=Maxtor 96147H8, FwRev=BAC51KJ0, SerialNo=N80CP5KC
> |  Config={ Fixed }
> |  RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
> |  BuffType=3(DualPortCache), BuffSize=2048kB, MaxMultSect=16, MultSect=off
> |  DblWordIO=no, maxPIO=2(fast), DMA=yes, maxDMA=0(slow)
> |  CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=120060864
> |  tDMA={min:120,rec:120}, DMA modes: mword0 mword1 *mword2 
> |  IORDY=on/off, tPIO={min:120,w/IORDY:120}, PIO modes: mode3 mode4 
> 
> lspci -vvxxx output:
> 
> | 00:00.0 Host bridge: VIA Technologies, Inc. VT82C597 [Apollo VP3] (rev 04)
> | 	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> | 	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> | 	Latency: 16 set
> | 	Region 0: Memory at e0000000 (32-bit, prefetchable)
> | 	Capabilities: [a0] AGP version 1.0
> | 		Status: RQ=7 SBA+ 64bit- FW- Rate=1
> | 		Command: RQ=7 SBA+ AGP- 64bit- FW- Rate=1
> | 00: 06 11 97 05 06 00 90 02 04 00 00 06 00 10 00 00
> | 10: 08 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 00
> | 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
> | 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | 50: 80 0a 05 40 00 00 00 00 98 80 10 10 20 20 28 30
> | 60: 3f 2a 00 23 e4 e4 e4 00 01 00 50 00 60 67 00 00
> | 70: e1 0a 6c 00 00 80 40 00 00 00 00 00 00 00 00 40
> | 80: 00 00 00 00 c0 00 00 00 02 00 00 00 00 00 00 00
> | 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | a0: 02 00 10 00 01 02 00 07 00 00 00 00 0a 00 00 00
> | b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | f0: 00 00 00 00 00 00 00 00 00 00 00 00 01 00 97 05
> |
> | 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP]
> | 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> | 	Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
> | 	Latency: 0 set
> | 	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> | 	I/O behind bridge: 0000d000-0000dfff
> | 	Memory behind bridge: e4000000-e7ffffff
> | 	Prefetchable memory behind bridge: e8000000-e8ffffff
> | 	BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
> | 00: 06 11 98 85 07 00 20 22 00 00 04 06 00 00 01 00
> | 10: 00 00 00 00 00 00 00 00 00 01 01 00 d0 d0 00 00
> | 20: 00 e4 f0 e7 00 e8 f0 e8 00 00 00 00 00 00 00 00
> | 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0c 00
> | 40: f0 ec 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> |
> | 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586 ISA [Apollo VP] (rev 41)
> | 	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
> | 	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> | 	Latency: 0 set
> | 00: 06 11 86 05 8f 00 00 02 41 00 01 06 00 00 80 00
> | 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | 40: 00 05 00 00 01 00 10 a0 21 00 c4 00 00 00 00 f3
> | 50: 24 00 00 00 00 00 a0 90 00 06 f7 00 10 00 00 00
> | 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> |
> | 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06) (prog-if 8a)
> | 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> | 	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> | 	Latency: 64 set
> | 	Region 4: I/O ports at e000
> | 00: 06 11 71 05 07 00 80 02 06 8a 01 01 00 40 00 00
> | 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | 20: 01 e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | 40: 0b f2 09 3a 69 00 f0 00 a8 a8 a8 a8 ff 00 ff ff
> | 50: 03 03 03 03 00 00 00 00 a8 a8 a8 a8 00 00 00 00
> | 60: 00 02 00 00 00 00 00 00 00 02 00 00 00 00 00 00
> | 70: 22 00 00 00 00 00 00 00 42 00 00 00 00 00 00 00
> | 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | d0: 06 00 71 05 00 00 00 00 00 00 00 00 00 00 00 00
> | e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> |
> | 00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 02)
> | 	Subsystem: Unknown device 0925:1234
> | 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> | 	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> | 	Latency: 64 set, cache line size 08
> | 	Interrupt: pin D routed to IRQ 9
> | 	Region 4: I/O ports at e400
> | 00: 06 11 38 30 07 00 00 02 02 00 03 0c 08 40 00 00
> | 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | 20: 01 e4 00 00 00 00 00 00 00 00 00 00 25 09 34 12
> | 30: 00 00 00 00 00 00 00 00 00 00 00 00 09 04 00 00
> | 40: 00 00 00 00 c6 00 11 18 00 00 00 00 00 00 00 00
> | 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | 60: 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | c0: 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> |
> | 00:07.3 Bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 10)
> | 	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> | 	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> | 00: 06 11 40 30 00 00 80 02 10 00 80 06 00 00 00 00
> | 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | 40: 40 88 09 00 78 38 00 00 01 60 00 00 00 00 00 00
> | 50: 00 7c ee 88 00 00 00 00 00 00 00 00 00 00 00 00
> | 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

-- 
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[junio]

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 partitions are accessed from the userland?

My test goes like this:

    cd /
    raidstop /dev/md2

    # Baseline: single device case seem to work OK
    # with both 2.1e and 3.11
    for dev in a7 c7
    do
        mke2fs /dev/hd$dev
        mount /dev/hd$dev /mnt
        tar cf - usr | ( cd /mnt && tar xfp - )
        sync
        umount /mnt
        mount -o ro /dev/hd$dev /mnt
        tar cf - usr | ( cd /mnt && tar df - )
        # no problem reported from `tar df'
        umount /mnt
    done

    # RAID-1 /dev/md2 is built out of /dev/hda7 and /dev/hdc7

    # not quite, but exact `force' switch withheld :-)
    mkraid /dev/md2
    # wait until /proc/mdstat says /dev/md2 is fully reconstructed

    mke2fs /dev/md2
    mount /dev/md2 /mnt
    tar cf - usr | ( cd /mnt && tar xfp - )
    sync
    umount /mnt
    mount -o ro /dev/md2 /mnt
    tar cf - usr | ( cd /mnt && tar df - )
    # many errors.
    umount /mnt
    raidstop /dev/md2
    sync
    mkdir -p /mnt/1 /mnt/2
    mount -o ro /dev/hda7 /mnt/1
    mount -o ro /dev/hdc7 /mnt/2
    tar cf - usr | ( cd /mnt/1 && tar df - )
    # many differences.
    tar cf - usr | ( cd /mnt/2 && tar df - )
    # many differences.

    umount /dev/hda7
    umount /dev/hdc7
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Andre Hedrick]

On 12 Jan 2001, Linus Torvalds wrote:

> In article <Pine.LNX.4.10.10101121009230.1147-100000@master.linux-ide.org>,
> Andre Hedrick  <andre@linux-ide.org> 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 chipset makers......you see the picture clearly, right?
> 
> No.

Oh, then I need to explain....but later.

> That experimental patch is _experimental_, and has not been reported by
> anybody to fix anything at all.  Also, the DMA timeout on PIIX4 seems to
> have nothing at all to do with the very silent corruption on VIA. At
> least nobody has reported any error messages being produced on the VIA
> corruption cases.

Yes corruption verses deadlock that can wack superblock....hummm
Two evils, mame or kill one or leave both active...

> 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 battletested that people believe
> it truly will work).

Linus we are talking about blacklisting every PIIX4 that is 440BX/GX/LX/NX 
in this case and that is a major list.  VIA has its own problems and that
need special cases attention by one person work on always, thus the
poor^H^H^H^H bold sucker^H^H^H^H^H^H guy known as Vojtech Pavlik from SuSE
is having to much fun....

Cheers,

Andre Hedrick
Linux ATA Development


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[David Woodhouse]

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 battletested that people believe
> it truly will work).

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 drives (include
"FUJITSU MPE3136AT") into a whitelist. But it needs doing.

-- 
dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Linus Torvalds]

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 by putting known-compatible drives (include
> "FUJITSU MPE3136AT") into a whitelist. But it needs doing.

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.

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[David Woodhouse]

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 drive back on the HPT366 - the lid's 
actually screwed on for once.

It adds all the IBM Deskstar 75GXP and 40GV drives to the HPT366's UDMA
mode 4 blacklist, forcing them to drop to mode 3, with which myself and
the one other tester who responded were unable to find problems.

IIRC the drives actually used in the testing were the 30GB and 45GB 75GXP
models - IBM-DTLA-3070{30,45}. I've blacklisted the 40GV models too with
this patch, just to be on the safe side. It's a reasonable assumption that
the IDE interfaces on the slower drives share the same compatibility
problems with the HPT366.

(And I've fixed the Pine bug which was stripping trailing whitespace and 
making my patches fail to apply too :)

Index: drivers/ide/hpt366.c
===================================================================
RCS file: /inst/cvs/linux/drivers/ide/Attic/hpt366.c,v
retrieving revision 1.1.2.7
diff -u -r1.1.2.7 hpt366.c
--- drivers/ide/hpt366.c	2001/01/05 11:10:44	1.1.2.7
+++ drivers/ide/hpt366.c	2001/01/14 17:15:23
@@ -55,6 +55,15 @@
 };
 
 const char *bad_ata66_4[] = {
+	"IBM-DTLA-307075",
+	"IBM-DTLA-307060",
+	"IBM-DTLA-307045",
+	"IBM-DTLA-307030",
+	"IBM-DTLA-307020",
+	"IBM-DTLA-307015",
+	"IBM-DTLA-305040",
+	"IBM-DTLA-305030",
+	"IBM-DTLA-305020",
 	"WDC AC310200R",
 	NULL
 };

-- 
dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Russell King]

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 drives (include
> "FUJITSU MPE3136AT") into a whitelist. But it needs doing.

I've been wondering recently why there isn't an option to tell the kernel
"even if you've been configured to use dma by default, please don't on this
IDE interface".  There is an option for tuning the interface up, but
nothing to tune down.

It strikes me that this might be a good thing to have.  Comments?
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |         Russell King        rmk@arm.linux.org.uk      --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Craig Schlenter]

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 linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/