VIA VT82C686X

VIA VT82C686X

[David D.W. Downey]

Woohoo! Just found out that ATA66 on the VIA aint too great.

I set the kernel boot options idebus=66 ide0=ata66 enabling ATA66
according to dmesg. The HDD is a WDC UDMA100 30.5GB drive. I retried the

dd if=/dev/hda7 of=/tmp/testing2.img bs=1024k count=2000 

on one VT, ran renice -20 on the dd process then ran procinfo on another
and top on a 3rd. I logged into a fourth and ran sync;sync;sync;sync;sync.

After @30 seconds the machine became totally unresponsive, locking up all
but the current VT.

I let it sit there and waited until the dd finished in case the renice was
what killed the control. When dd finished I tried running any type of
command but the tty was completely frozen. All other VTs were non
responsive as well.


This is gonna be fun when I test the Promise controller. hehe


David D.W. Downey


-
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: VIA VT82C686X

[Byron Stanoszek]

On Tue, 30 Jan 2001, David D.W. Downey wrote:

> 
> Woohoo! Just found out that ATA66 on the VIA aint too great.
> 
> I set the kernel boot options idebus=66 ide0=ata66 enabling ATA66
> according to dmesg. The HDD is a WDC UDMA100 30.5GB drive. I retried the

The 'idebus=xx' parameter doesn't refer to the speed of the IDE drive, but
instead the speed of the PCI bus. On the VIA686, that speed should always be 33
(unless you're overclocking). Setting it to 66 will cause the VIA driver to
believe your PCI bus is running at 66MHz and will program the IDE controller to
run at half the speed to maintain 33MHz. In reality, your controller now runs
at 16.

I believe v3.20 of the via82cxxx.c driver disallows any setting lower than 20
or higher than 50.

AFAIK the driver auto-selects the speed of your drive based on how it is
configured in the BIOS, and whether you have the 40- or 80-wire cable. The
'ide0=ata66' option should not be necessary.

To others, I've been running this driver with both a KX133 and a KT133 (both
via686a) for quite some time now and have never seen any problems. Just make
sure 'idebus=xx' matches the speed of your PCICLK as shown in the bios and
you'll be fine (Default is 33).

Regards,
 Byron

-- 
Byron Stanoszek                         Ph: (330) 644-3059
Systems Programmer                      Fax: (330) 644-8110
Commercial Timesharing Inc.             Email: bstanoszek@comtime.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: VIA VT82C686X

[Frédéric L. W. Meunier]

Me too. But I couldn't get UDMA 66 after changing my BIOS
settings and booting. With 33 it's very stable (what I used
with 2.4.0). A diff:

-hda: 30015216 sectors (15368 MB) w/2048KiB Cache, CHS=1868/255/63, UDMA(33)
+hda: 30015216 sectors (15368 MB) w/2048KiB Cache, CHS=1868/255/63, UDMA(66)
...
+hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
+hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
VFS: Mounted root (ext2 filesystem) readonly.
-Freeing unused kernel memory: 200k freed
+Freeing unused kernel memory: 204k freed
+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 }
+ide0: reset: success

I know this is a known issue, but I thought testing would be
OK. ASUS K7V with the shipped cable.

-- 
0@pervalidus.{net, {dyndns.}org} Tel: 55-21-717-2399 (Niterói-RJ BR)
-
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: VIA VT82C686X

[David D.W. Downey]

On Tue, 30 Jan 2001, Byron Stanoszek wrote:

> (unless you're overclocking). Setting it to 66 will cause the VIA driver to
> believe your PCI bus is running at 66MHz and will program the IDE controller to
> run at half the speed to maintain 33MHz. In reality, your controller now runs
> at 16.

I removed the ide and ata setting. System is running stably as in no
kernel crashes, but I am getting daemon and shell crashes. With this
current kernel I've had 1 kernel crash in about 3 hours as compared to 1
every 10 or 15 minutes. Crash, reboot, 10 minutes or so crash, reboot. ect
ect.

I'm wanting to test something else out. I'm wondering if there isn't some
hardware issue with the RAM. This particular board will do 1GB of PC133,
or 2.5GB of PC100. I'm wondering if there isn't something wrong with how
it reads the speed and the appropriate limitation. It's running stably if
I only run 768MB of PC133 RAM. But if I run a solid 1GB of PC133 I get
segfaults and sig11 crashes constantly. All the RAM has been
professionally tested and certified.

Any clues would be appreciated. 

David


-
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: VIA VT82C686X

[Andre Hedrick]

On Tue, 30 Jan 2001, David D.W. Downey wrote:

> 
> Woohoo! Just found out that ATA66 on the VIA aint too great.
> 
> I set the kernel boot options idebus=66 ide0=ata66 enabling ATA66

Sorry but you are not right in this world .......

Where in you manual does is "QUOTE" you can drive the ATA/IDE bus at 66MHz?


> according to dmesg. The HDD is a WDC UDMA100 30.5GB drive. I retried the
> 
> dd if=/dev/hda7 of=/tmp/testing2.img bs=1024k count=2000 
> 
> on one VT, ran renice -20 on the dd process then ran procinfo on another
> and top on a 3rd. I logged into a fourth and ran sync;sync;sync;sync;sync.
> 
> After @30 seconds the machine became totally unresponsive, locking up all
> but the current VT.
> 
> I let it sit there and waited until the dd finished in case the renice was
> what killed the control. When dd finished I tried running any type of
> command but the tty was completely frozen. All other VTs were non
> responsive as well.
> 
> 
> This is gonna be fun when I test the Promise controller. hehe
> 
> 
> David D.W. Downey
> 
> 
> -
> 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: VIA VT82C686X

[Andre Hedrick]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=X-UNKNOWN, Size: 2080 bytes --]


You system did something funny or the new VIA code did it.
But because you observed this pattern the new feature that on Linux has
kicked in and hopefull recovered the system for you.

On Wed, 31 Jan 2001, [iso-8859-1] Frédéric L. W. Meunier wrote:

> Me too. But I couldn't get UDMA 66 after changing my BIOS
> settings and booting. With 33 it's very stable (what I used
> with 2.4.0). A diff:
> 
> -hda: 30015216 sectors (15368 MB) w/2048KiB Cache, CHS=1868/255/63, UDMA(33)
> +hda: 30015216 sectors (15368 MB) w/2048KiB Cache, CHS=1868/255/63, UDMA(66)
> ...
> +hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> +hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
> VFS: Mounted root (ext2 filesystem) readonly.
> -Freeing unused kernel memory: 200k freed
> +Freeing unused kernel memory: 204k freed
> +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 }
> +ide0: reset: success

Because you did not see DMA_DISABLED

The auto_dma_crc downgrade feature turned down the transfer rate of the
drive/host pair until the iCRC issue stablized.

Cheers,

> I know this is a known issue, but I thought testing would be
> OK. ASUS K7V with the shipped cable.
> 
> -- 
> 0@pervalidus.{net, {dyndns.}org} Tel: 55-21-717-2399 (Niterói-RJ BR)
> -
> 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: VIA VT82C686X

[Byron Stanoszek]

On Tue, 30 Jan 2001, David D.W. Downey wrote:

> I removed the ide and ata setting. System is running stably as in no
> kernel crashes, but I am getting daemon and shell crashes. With this
> current kernel I've had 1 kernel crash in about 3 hours as compared to 1
> every 10 or 15 minutes. Crash, reboot, 10 minutes or so crash, reboot. ect
> ect.
> 
> I'm wanting to test something else out. I'm wondering if there isn't some
> hardware issue with the RAM. This particular board will do 1GB of PC133,
> or 2.5GB of PC100. I'm wondering if there isn't something wrong with how
> it reads the speed and the appropriate limitation. It's running stably if
> I only run 768MB of PC133 RAM. But if I run a solid 1GB of PC133 I get
> segfaults and sig11 crashes constantly. All the RAM has been
> professionally tested and certified.

That definitely sounds like a RAM problem. The system should perform the same
independent of how many RAM chips you put in there (segfault-wise). If you're
still in doubt, you can try booting up with memtest86 and run it for several
hours with only the memory chip that you think might be causing the problem.

You can grab the bootdisk image from:
  ftp://ftp.winds.org/linux/images/memtest86-2.5.bin

and just write it to a floppy with 'cat memtest86-2.5.bin > /dev/fd0', then
boot up with that disk.

Regards,
 Byron

-- 
Byron Stanoszek                         Ph: (330) 644-3059
Systems Programmer                      Fax: (330) 644-8110
Commercial Timesharing Inc.             Email: bstanoszek@comtime.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: VIA VT82C686X

[Stephen Wille Padnos]

Byron Stanoszek wrote:

> On Tue, 30 Jan 2001, David D.W. Downey wrote:
>
> > I removed the ide and ata setting. System is running stably as in no
> > kernel crashes, but I am getting daemon and shell crashes. With this
> > current kernel I've had 1 kernel crash in about 3 hours as compared to 1
> > every 10 or 15 minutes. Crash, reboot, 10 minutes or so crash, reboot. ect
> > ect.
> >
> > I'm wanting to test something else out. I'm wondering if there isn't some
> > hardware issue with the RAM. This particular board will do 1GB of PC133,
> > or 2.5GB of PC100. I'm wondering if there isn't something wrong with how
> > it reads the speed and the appropriate limitation. It's running stably if
> > I only run 768MB of PC133 RAM. But if I run a solid 1GB of PC133 I get
> > segfaults and sig11 crashes constantly. All the RAM has been
> > professionally tested and certified.
>
> That definitely sounds like a RAM problem. The system should perform the same
> independent of how many RAM chips you put in there (segfault-wise). If you're
> still in doubt, you can try booting up with memtest86 and run it for several
> hours with only the memory chip that you think might be causing the problem.
>

Even though the motherboard *should* perform the same regardless of the amount
of RAM, it may not.  Physically, the refresh needs higher current drive when
there are more modules.  I have seen a BIOS option to set the DRAM refresh
current (RAS, CAS settable to 10 or 16 mA each), but that was only on one
motherboard that I can remember - you might want to check for this.

-
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: VIA VT82C686X

[alex]

On Wed, Jan 31, 2001 at 12:13:21PM -0500, Stephen Wille Padnos wrote:
> Even though the motherboard *should* perform the same regardless of the amount
> of RAM, it may not.  Physically, the refresh needs higher current drive when
> there are more modules.  I have seen a BIOS option to set the DRAM refresh
> current (RAS, CAS settable to 10 or 16 mA each), but that was only on one
> motherboard that I can remember - you might want to check for this.

It should also be noted that there are several motherboards out there that 
claim to support 1GB or more of RAM which just plain don't, causing problems 
like this because the design is inadequate for the power requirements of that 
many chips (I have, unfortunately, had to work with some of these).  Sometimes 
you can work around it using different types of RAM (buffered vs. unbuffered, 
etc) but even this is iffy and not something I'd rely on for anything too 
important.

-alex
-
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/