Re: VIA VT82C686X
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT82C686X
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT82C686X
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: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT82C686X
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT82C686X
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 [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT82C686X
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 [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT82C686X
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT82C686X
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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT82C686X
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: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
VIA VT82C686X
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
VIA VT82C686X
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT82C686X
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: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT82C686X
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 (Niteri-RJ BR)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT82C686X
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT82C686X
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT82C686X
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 [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
