VT82C686A corruption with 2.4.x

VT82C686A corruption with 2.4.x

[Nicholas Knight]

I have a Soyo K7VIA motherboard which uses VT82C686A, with an 800mhz Athlon
CPU in it.
So far I've never run a 2.3* or 2.4* kernel on it, I've only done that on my
P3 using a propriatory micron motherboard that uses an intel BX2 chipset.
However, I recently trashed my linux installation (doing things totaly
unrelated to the kernel) and now would be more than happy to assist in
trying to figure out what the heck is causing the filesystem corruption on
VIA chipsets, but so far I've only found bits and peices of information on
it, and have been unable to locate a compiliation of information avalible on
the problem, so I'd know just where to start.
If anyone could point me to a good place to start looking, besides the
thousands of messages containing just bits and peices of information, I
could get to work on some testing.

-NK

-
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: VT82C686A corruption with 2.4.x

[Tobias Ringstrom]

So you have not seen any corruption, but are willing to do testing.  Very
kind, but you could have choosen a better subject, I think.  There are a
lot more rumours that facts regarding the VIA drivers right now.

/Tobias


On Tue, 30 Jan 2001, Nicholas Knight wrote:

> I have a Soyo K7VIA motherboard which uses VT82C686A, with an 800mhz Athlon
> CPU in it.
> So far I've never run a 2.3* or 2.4* kernel on it, I've only done that on my
> P3 using a propriatory micron motherboard that uses an intel BX2 chipset.
> However, I recently trashed my linux installation (doing things totaly
> unrelated to the kernel) and now would be more than happy to assist in
> trying to figure out what the heck is causing the filesystem corruption on
> VIA chipsets, but so far I've only found bits and peices of information on
> it, and have been unable to locate a compiliation of information avalible on
> the problem, so I'd know just where to start.
> If anyone could point me to a good place to start looking, besides the
> thousands of messages containing just bits and peices of information, I
> could get to work on some testing.

-
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: VT82C686A corruption with 2.4.x

[David D.W. Downey]

Actually what rumors are you hearing?

Right now I can tell you from personal experience that the VIA VT82C686A
chipset is causing kernel deaths, corrupted data on my drives, and UDMA
issues (meaning that when I enable the UDMA support the kernel
CONSISTENTLY crashes.)

This is all pre patch-2.4.1-pre11. I've not tested the new patch as of yet
as I was in a car accident and have not felt well enough to mess with
things. I will however be testing the new patch in about a half hour. The
test bed will be the SMP box I've been talking about on the list, Red Hat
7.0 (only one that will install on the machine without dying instantly
during installation) and using the KGCC rather than the GCC that comes
with RH7.

Supposedly there are a couple of other patches available to add as well,
but I'm not sure where they are exactly. I just downloaded the patch that
Voj gave (v3.20) for the VIA chipsets.


Nicholas, give me a bit and I'll let you know what's going on with my
tests here. I can consistently get the current kernel to die simply by
running

dd if=/dev/hda4 of=/tmp/testing.img bs=1024M count=2k


TRy this on your box with the patch-2.4.1-pre11 added to the kernel source
and let me know what you get. Maybe we can work on this together.


David D.W. Downey



On Tue, 30 Jan 2001, Tobias Ringstrom wrote:

> So you have not seen any corruption, but are willing to do testing.  Very
> kind, but you could have choosen a better subject, I think.  There are a
> lot more rumours that facts regarding the VIA drivers right now.
> 
> /Tobias
> 
> 
> On Tue, 30 Jan 2001, Nicholas Knight wrote:
> 
> > I have a Soyo K7VIA motherboard which uses VT82C686A, with an 800mhz Athlon
> > CPU in it.
> > So far I've never run a 2.3* or 2.4* kernel on it, I've only done that on my
> > P3 using a propriatory micron motherboard that uses an intel BX2 chipset.
> > However, I recently trashed my linux installation (doing things totaly
> > unrelated to the kernel) and now would be more than happy to assist in
> > trying to figure out what the heck is causing the filesystem corruption on
> > VIA chipsets, but so far I've only found bits and peices of information on
> > it, and have been unable to locate a compiliation of information avalible on
> > the problem, so I'd know just where to start.
> > If anyone could point me to a good place to start looking, besides the
> > thousands of messages containing just bits and peices of information, I
> > could get to work on some testing.
> 
> -
> 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/
> 

-
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: VT82C686A corruption with 2.4.x

[David Raufeisen]

bash-2.04# dmesg | grep -i udma
VP_IDE: VIA vt82c686a IDE UDMA66 controller on pci0:7.1
hda: 30015216 sectors (15368 MB) w/2048KiB Cache, CHS=1868/255/63, UDMA(66)
hdb: 80041248 sectors (40981 MB) w/2048KiB Cache, CHS=4982/255/63, UDMA(66)
hdc: ATAPI 52X CD-ROM drive, 192kB Cache, UDMA(33)

bash-2.04# uname -a
Linux prototype 2.4.1 #1 Tue Jan 30 01:45:38 PST 2001 i686 unknown

bash-2.04# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/hda2              14G  3.7G   10G  26% /
/dev/hdb1              38G   20G   19G  51% /storage

I dunno what you wanted to do by:

> dd if=/dev/hda4 of=/tmp/testing.img bs=1024M count=2k

Becuase it won't read 1024M into memory at once, says memory exhausted..

So I did..

bash-2.04# cd /storage
bash-2.04# dd if=/dev/hda2 of=testing.img bs=1024k count=2000
2000+0 records in
2000+0 records out
bash-2.04# ls -sh testing.img 
2.0G testing.img
bash-2.04#

No problems here (nothing in dmesg, no crashing..) Course interactivity in X was total shit while dd was
running =\.

On Tuesday, 30 January 2001, at 11:51:58 (-0800),
David D.W. Downey wrote:

> 
> Actually what rumors are you hearing?
> 
> Right now I can tell you from personal experience that the VIA VT82C686A
> chipset is causing kernel deaths, corrupted data on my drives, and UDMA
> issues (meaning that when I enable the UDMA support the kernel
> CONSISTENTLY crashes.)
> 
> This is all pre patch-2.4.1-pre11. I've not tested the new patch as of yet
> as I was in a car accident and have not felt well enough to mess with
> things. I will however be testing the new patch in about a half hour. The
> test bed will be the SMP box I've been talking about on the list, Red Hat
> 7.0 (only one that will install on the machine without dying instantly
> during installation) and using the KGCC rather than the GCC that comes
> with RH7.
> 
> Supposedly there are a couple of other patches available to add as well,
> but I'm not sure where they are exactly. I just downloaded the patch that
> Voj gave (v3.20) for the VIA chipsets.
> 
> 
> Nicholas, give me a bit and I'll let you know what's going on with my
> tests here. I can consistently get the current kernel to die simply by
> running
> 
> dd if=/dev/hda4 of=/tmp/testing.img bs=1024M count=2k
> 
> 
> TRy this on your box with the patch-2.4.1-pre11 added to the kernel source
> and let me know what you get. Maybe we can work on this together.
> 
> 
> David D.W. Downey
> 

-- 
David Raufeisen <david@fortyoz.org>
Cell: (604) 818-3596
-
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: VT82C686A corruption with 2.4.x

[David D.W. Downey]

OK, here is the output of lspci -v on the SMP box I'm having trouble with
as requested...


00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev c4)
	Flags: bus master, medium devsel, latency 0
	Memory at d0000000 (32-bit, prefetchable)
	Capabilities: [a0] AGP version 2.0
	Capabilities: [c0] Power Management version 2

00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP] (prog-if 00 [Normal decode])
	Flags: bus master, 66Mhz, medium devsel, latency 0
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: 00009000-00009fff
	Memory behind bridge: d4000000-d7ffffff
	Prefetchable memory behind bridge: d8000000-d9ffffff
	Capabilities: [80] Power Management version 2

00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22)
	Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge
	Flags: bus master, stepping, medium devsel, latency 0

00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10) (prog-if 8a [Master SecP PriP])
	Flags: bus master, medium devsel, latency 32
	I/O ports at a000
	Capabilities: [c0] Power Management version 2

00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
	Flags: medium devsel
	Capabilities: [68] Power Management version 2

00:0c.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device 0d30 (rev 02)
	Subsystem: Promise Technology, Inc.: Unknown device 4d33
	Flags: bus master, medium devsel, latency 32, IRQ 11
	I/O ports at ac00
	I/O ports at b000
	I/O ports at b400
	I/O ports at b800
	I/O ports at bc00
	Memory at db000000 (32-bit, non-prefetchable)
	Capabilities: [58] Power Management version 1

00:0e.0 SCSI storage controller: Advanced System Products, Inc ABP940-UW
	Flags: bus master, medium devsel, latency 32, IRQ 15
	I/O ports at c000
	Memory at db020000 (32-bit, non-prefetchable)

00:10.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
	Subsystem: Netgear FA310TX
	Flags: bus master, medium devsel, latency 32, IRQ 11
	I/O ports at c400
	Memory at db021000 (32-bit, non-prefetchable)

01:00.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo 3 (rev 01) (prog-if 00 [VGA])
	Subsystem: 3Dfx Interactive, Inc. Voodoo3 AGP
	Flags: 66Mhz, fast devsel
	Memory at d4000000 (32-bit, non-prefetchable)
	Memory at d8000000 (32-bit, prefetchable)
	I/O ports at 9000
	Capabilities: [54] AGP version 1.0
	Capabilities: [60] Power Management version 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: VT82C686A corruption with 2.4.x

[David D.W. Downey]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3771 bytes --]

OK, just completed the upgrade to 2.4.1-pre12 + via82cxxxx.diff.

SYSTEM SPECS CHANGES
===================
Shut off ACPI
Shut off 2nd IDE controller in BIOS
Shut off APM
Disabled UDMA support in BIOS
Removed 256MB RAM (768M total RAM) *


Everything is running stabler now. Here's what I've got set up right now.


VIA SUPPORT
============
00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev c4)
	Flags: bus master, medium devsel, latency 0
	Memory at d0000000 (32-bit, prefetchable)
	Capabilities: [a0] AGP version 2.0
	Capabilities: [c0] Power Management version 2

00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP] (prog-if 00 [Normal decode])
	Flags: bus master, 66Mhz, medium devsel, latency 0
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: 00009000-00009fff
	Memory behind bridge: d4000000-d7ffffff
	Prefetchable memory behind bridge: d8000000-d9ffffff
	Capabilities: [80] Power Management version 2

00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22)
	Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge
	Flags: bus master, stepping, medium devsel, latency 0

00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10) (prog-if 8a [Master SecP PriP])
	Flags: bus master, medium devsel, latency 32
	I/O ports at a000
	Capabilities: [c0] Power Management version 2

00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
	Flags: medium devsel
	Capabilities: [68] Power Management version 2

00:0c.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device 0d30 (rev 02)
	Subsystem: Promise Technology, Inc.: Unknown device 4d33
	Flags: bus master, medium devsel, latency 32, IRQ 11
	I/O ports at ac00
	I/O ports at b000
	I/O ports at b400
	I/O ports at b800
	I/O ports at bc00
	Memory at db000000 (32-bit, non-prefetchable)
	Capabilities: [58] Power Management version 1

00:0e.0 SCSI storage controller: Advanced System Products, Inc ABP940-UW
	Flags: bus master, medium devsel, latency 32, IRQ 15
	I/O ports at c000
	Memory at db020000 (32-bit, non-prefetchable)

00:10.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
	Subsystem: Netgear FA310TX
	Flags: bus master, medium devsel, latency 32, IRQ 11
	I/O ports at c400
	Memory at db021000 (32-bit, non-prefetchable)

01:00.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo 3 (rev 01) (prog-if 00 [VGA])
	Subsystem: 3Dfx Interactive, Inc. Voodoo3 AGP
	Flags: 66Mhz, fast devsel
	Memory at d4000000 (32-bit, non-prefetchable)
	Memory at d8000000 (32-bit, prefetchable)
	I/O ports at 9000
	Capabilities: [54] AGP version 1.0
	Capabilities: [60] Power Management version 1


PROMISE SUPPORT
===============
PDC20265: IDE controller on PCI bus 00 dev 60
PDC20265: chipset revision 2
PDC20265: not 100% native mode: will probe irqs later
PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.



DMESG - VIA
==============
PCI: Using IRQ router VIA [1106/0686] at 00:07.0
System Vendor: VIA Technologies, Inc..
VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:07.1
[drm] AGP 0.99 on VIA Apollo Pro @ 0xd0000000 64MB
[drm] AGP 0.99 on VIA Apollo Pro @ 0xd0000000 64MB
[drm] AGP 0.99 on VIA Apollo Pro @ 0xd0000000 64MB


DD TESTING
==========
[root@timberwolf /root]# dd if=/dev/hda7 of=/tmp/testing.img bs=1024k count=20002000+0 records in
2000+0 records out
[root@timberwolf /root]# ls -al /tmp/testing.img
-rw-r--r--    1 root     root     2097152000 Jan 29 17:54 /tmp/testing.img
[root@timberwolf /root]# ls -alh /tmp/testing.img
-rw-r--r--    1 root     root         2.0G Jan 29 17:54 /tmp/testing.img
[root@timberwolf /root]#




I'm also attaching a ksyms dump.


David D.W. Downey


[-- Attachment #2: Type: TEXT/plain, Size: 2711 bytes --]

Address   Symbol                            Defined by
f286a060  advansys_proc_info                [advansys]
f286a060  __insmod_advansys_S.text_L60896   [advansys]
f286caf0  advansys_reset                    [advansys]
f286c770  advansys_abort                    [advansys]
f286c660  advansys_command                  [advansys]
f286a58c  advansys_detect                   [advansys]
f286d084  advansys_biosparam                [advansys]
f287b0e0  __insmod_advansys_S.data_L15488   [advansys]
f287ef00  __insmod_advansys_S.bss_L128      [advansys]
f2878e60  __insmod_advansys_S.rodata_L8808  [advansys]
f286c350  advansys_release                  [advansys]
f286c698  advansys_queuecommand             [advansys]
f286a000  __insmod_advansys_O/lib/modules/2.4.1-pre12/kernel/drivers/scsi/advansys.o_M3A761A3A_V132097  [advansys]
f286c444  advansys_info                     [advansys]
f286d10c  advansys_setup                    [advansys]
f2862344  tulip_debug                       [tulip]
f28626e0  t21040_csr13                      [tulip]
f285ba98  tulip_mdio_write                  [tulip]
f285a29c  t21142_start_nway                 [tulip]
f2862348  tulip_tbl                         [tulip]
f28626f0  t21041_csr13                      [tulip]
f28626fa  t21041_csr14                      [tulip]
f2862704  t21041_csr15                      [tulip]
f285d160  comet_timer                       [tulip]
f2862a44  tulip_max_interrupt_work          [tulip]
f285b288  tulip_interrupt                   [tulip]
f285a060  __insmod_tulip_S.text_L23186      [tulip]
f285a000  __insmod_tulip_O/lib/modules/2.4.1-pre12/kernel/drivers/net/tulip/tulip.o_M3A761A39_V132097  [tulip]
f2862a40  tulip_rx_copybreak                [tulip]
f285a790  tulip_parse_eeprom                [tulip]
f285d118  mxic_timer                        [tulip]
f285c710  pnic_do_nway                      [tulip]
f285bbf0  tulip_select_media                [tulip]
f2861784  medianame                         [tulip]
f285b930  tulip_mdio_read                   [tulip]
f28629c0  __insmod_tulip_S.bss_L136         [tulip]
f285c568  tulip_check_duplex                [tulip]
f285a060  t21142_timer                      [tulip]
f285a3b0  t21142_lnk_change                 [tulip]
f28620ca  t21142_csr14                      [tulip]
f285fb80  __insmod_tulip_S.rodata_L9522     [tulip]
f285ad58  tulip_read_eeprom                 [tulip]
f286198c  tulip_media_cap                   [tulip]
f285c840  pnic_lnk_change                   [tulip]
f28620c0  __insmod_tulip_S.data_L1664       [tulip]
f285c914  pnic_timer                        [tulip]
f285cb60  tulip_timer                       [tulip]

Re: VT82C686A corruption with 2.4.x

[Vojtech Pavlik]

Hi!

1) You don't seem to have any drives on the VIA controller. If this is
true, I don't think this can be a VIA IDE driver problem.

2) In your original message you suggest bs=1024M, which isn't a very
good idea, even on a 768 MB system. Here with bs=1024k it seems to run
fine.

3) You sent next to none VIA related debugging info. lspci -v itself
isn't much valuable because I don't get the register contents. Also
hdparm -i of the drives attached to the VIA chip would be useful. Plus
also the contents of /proc/ide/via.

4) Did you check the problem you're experiencing isn't a memory problem?
That'd go away with removing some RAM.

Vojtech

PS. I'm not sure how wise is to use both ACPI and APM at once. Well, I
never used either in a server environment - I don't think it makes much
sense.

PPS. What should I do with a ksyms dump of the Advansys SCSI and a Tulip
NIC drivers? It isn't related anyhow.


-- 
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: VT82C686A corruption with 2.4.x

[David Raufeisen]

On Wednesday, 31 January 2001, at 08:36:42 (+0100),
Vojtech Pavlik wrote:

> Hi!
> 
> 1) You don't seem to have any drives on the VIA controller. If this is
> true, I don't think this can be a VIA IDE driver problem.
>

Hi, Are you referring to Mark or me?

I have drives on my VIA (only..) IDE controller:

VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686a IDE UDMA66 controller on pci0:7.1
VP_IDE: ATA-66/100 forced bit set (WARNING)!!
    ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:DMA
VP_IDE: ATA-66/100 forced bit set (WARNING)!!
    ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
hda: Maxtor 51536H2, ATA DISK drive
hdb: Maxtor 94098U8, ATA DISK drive
hdc: CD-ROM 52X/AKH, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 30015216 sectors (15368 MB) w/2048KiB Cache, CHS=1868/255/63, UDMA(66)
hdb: 80041248 sectors (40981 MB) w/2048KiB Cache, CHS=4982/255/63, UDMA(66)
hdc: ATAPI 52X CD-ROM drive, 192kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
Partition check:
 hda: hda1 hda2
 hdb: hdb1
 
> 2) In your original message you suggest bs=1024M, which isn't a very
> good idea, even on a 768 MB system. Here with bs=1024k it seems to run
> fine.
>
> 3) You sent next to none VIA related debugging info. lspci -v itself
> isn't much valuable because I don't get the register contents. Also
> hdparm -i of the drives attached to the VIA chip would be useful. Plus
> also the contents of /proc/ide/via.

I didn't supply anything either, even though my configuration works great it
might prove useful to someone comparing:

bash-2.04# hdparm -i /dev/hda

/dev/hda:

 Model=Maxtor 51536H2, FwRev=JAC61HU0, SerialNo=F203VTHC
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=30015216
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4 
 DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4 udma5 
bash-2.04# hdparm -i /dev/hdb

/dev/hdb:

 Model=Maxtor 94098U8, FwRev=FA500S60, SerialNo=G8066RQC
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
 CurCHS=17475/15/63, CurSects=16513875, LBA=yes, LBAsects=80041248
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4 
 DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4 
bash-2.04# 

bash-2.04# cat /proc/ide/via 
----------VIA BusMastering IDE Configuration----------------
Driver Version:                     2.1e
South Bridge:                       VIA vt82c686a rev 0x22
Command register:                   0x7
Latency timer:                      32
PCI clock:                          33MHz
Master Read  Cycle IRDY:            0ws
Master Write Cycle IRDY:            0ws
FIFO Output Data 1/2 Clock Advance: off
BM IDE Status Register Read Retry:  on
Max DRDY Pulse Width:               No limit
-----------------------Primary IDE-------Secondary IDE------
Read DMA FIFO flush:           on                  on
End Sect. FIFO flush:          on                  on
Prefetch Buffer:               on                  on
Post Write Buffer:             on                  on
FIFO size:                      8                   8
Threshold Prim.:              1/2                 1/2
Bytes Per Sector:             512                 512
Both channels togth:          yes                 yes
-------------------drive0----drive1----drive2----drive3-----
BMDMA enabled:        yes       yes       yes        no
Transfer Mode:       UDMA      UDMA      UDMA   DMA/PIO
Address Setup:       30ns      30ns      30ns     120ns
Active Pulse:        90ns      90ns      90ns     330ns
Recovery Time:       30ns      30ns      30ns     270ns
Cycle Time:          30ns      30ns      60ns     600ns
Transfer Rate:   66.0MB/s  66.0MB/s  33.0MB/s   3.3MB/s

bash-2.04# lspci -v (trimmed)
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02)
        Flags: bus master, medium devsel, latency 8
        Memory at e0000000 (32-bit, prefetchable) [size=64M]
        Capabilities: [a0] AGP version 2.0
        Capabilities: [c0] Power Management version 2

00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (prog-if 00 [Normal decode])
        Flags: bus master, 66Mhz, medium devsel, latency 0
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
        I/O behind bridge: 00009000-00009fff
        Memory behind bridge: dde00000-dfefffff
        Prefetchable memory behind bridge: cdc00000-ddcfffff
        Capabilities: [80] Power Management version 2

00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22)
        Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge
        Flags: bus master, stepping, medium devsel, latency 0

00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10) (prog-if 8a [Master SecP PriP])
        Flags: bus master, medium devsel, latency 32
        I/O ports at ffa0 [size=16]
        Capabilities: [c0] Power Management version 2

00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) (prog-if 00 [UHCI])
        Subsystem: Unknown device 0925:1234
        Flags: bus master, medium devsel, latency 64, IRQ 9
        I/O ports at cc00 [size=32]
        Capabilities: [80] Power Management version 2

00:07.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) (prog-if 00 [UHCI])
        Subsystem: Unknown device 0925:1234
        Flags: bus master, medium devsel, latency 64, IRQ 9
        I/O ports at d000 [size=32]
        Capabilities: [80] Power Management version 2

00:07.4 SMBus: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
        Flags: medium devsel
        Capabilities: [68] Power Management version 2

> 4) Did you check the problem you're experiencing isn't a memory problem?
> That'd go away with removing some RAM.

I assume this was to Mark, I have no problem:)
 
> Vojtech Pavlik
> SuSE Labs

-- 
David Raufeisen <david@fortyoz.org>
Cell: (604) 818-3596
-
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: VT82C686A corruption with 2.4.x

[safemode]

David Raufeisen wrote:

> On Wednesday, 31 January 2001, at 08:36:42 (+0100),
> Vojtech Pavlik wrote:
>
> > Hi!
> >
> > 1) You don't seem to have any drives on the VIA controller. If this is
> > true, I don't think this can be a VIA IDE driver problem.
> >
>
> Hi, Are you referring to Mark or me?
>
> I have drives on my VIA (only..) IDE controller:
>
> VP_IDE: IDE controller on PCI bus 00 dev 39
> VP_IDE: chipset revision 16
> VP_IDE: not 100% native mode: will probe irqs later
> VP_IDE: VIA vt82c686a IDE UDMA66 controller on pci0:7.1
> VP_IDE: ATA-66/100 forced bit set (WARNING)!!
>     ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:DMA
> VP_IDE: ATA-66/100 forced bit set (WARNING)!!
>     ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
> hda: Maxtor 51536H2, ATA DISK drive
> hdb: Maxtor 94098U8, ATA DISK drive
> hdc: CD-ROM 52X/AKH, ATAPI CD/DVD-ROM drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> hda: 30015216 sectors (15368 MB) w/2048KiB Cache, CHS=1868/255/63, UDMA(66)
> hdb: 80041248 sectors (40981 MB) w/2048KiB Cache, CHS=4982/255/63, UDMA(66)
> hdc: ATAPI 52X CD-ROM drive, 192kB Cache, UDMA(33)
> Uniform CD-ROM driver Revision: 3.12
> Partition check:
>  hda: hda1 hda2
>  hdb: hdb1
>
> > 2) In your original message you suggest bs=1024M, which isn't a very
> > good idea, even on a 768 MB system. Here with bs=1024k it seems to run
> > fine.
> >
> > 3) You sent next to none VIA related debugging info. lspci -v itself
> > isn't much valuable because I don't get the register contents. Also
> > hdparm -i of the drives attached to the VIA chip would be useful. Plus
> > also the contents of /proc/ide/via.
>
> I didn't supply anything either, even though my configuration works great it
> might prove useful to someone comparing:
>
> bash-2.04# hdparm -i /dev/hda
>
> /dev/hda:
>
>  Model=Maxtor 51536H2, FwRev=JAC61HU0, SerialNo=F203VTHC
>  Config={ Fixed }
>  RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
>  BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
>  CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=30015216
>  IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
>  PIO modes: pio0 pio1 pio2 pio3 pio4
>  DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4 udma5
> bash-2.04# hdparm -i /dev/hdb
>
> /dev/hdb:
>
>  Model=Maxtor 94098U8, FwRev=FA500S60, SerialNo=G8066RQC
>  Config={ Fixed }
>  RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
>  BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
>  CurCHS=17475/15/63, CurSects=16513875, LBA=yes, LBAsects=80041248
>  IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
>  PIO modes: pio0 pio1 pio2 pio3 pio4
>  DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4
> bash-2.04#
>
> bash-2.04# cat /proc/ide/via
> ----------VIA BusMastering IDE Configuration----------------
> Driver Version:                     2.1e
> South Bridge:                       VIA vt82c686a rev 0x22
> Command register:                   0x7
> Latency timer:                      32
> PCI clock:                          33MHz
> Master Read  Cycle IRDY:            0ws
> Master Write Cycle IRDY:            0ws
> FIFO Output Data 1/2 Clock Advance: off
> BM IDE Status Register Read Retry:  on
> Max DRDY Pulse Width:               No limit
> -----------------------Primary IDE-------Secondary IDE------
> Read DMA FIFO flush:           on                  on
> End Sect. FIFO flush:          on                  on
> Prefetch Buffer:               on                  on
> Post Write Buffer:             on                  on
> FIFO size:                      8                   8
> Threshold Prim.:              1/2                 1/2
> Bytes Per Sector:             512                 512
> Both channels togth:          yes                 yes
> -------------------drive0----drive1----drive2----drive3-----
> BMDMA enabled:        yes       yes       yes        no
> Transfer Mode:       UDMA      UDMA      UDMA   DMA/PIO
> Address Setup:       30ns      30ns      30ns     120ns
> Active Pulse:        90ns      90ns      90ns     330ns
> Recovery Time:       30ns      30ns      30ns     270ns
> Cycle Time:          30ns      30ns      60ns     600ns
> Transfer Rate:   66.0MB/s  66.0MB/s  33.0MB/s   3.3MB/s
>
> bash-2.04# lspci -v (trimmed)
> 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02)
>         Flags: bus master, medium devsel, latency 8
>         Memory at e0000000 (32-bit, prefetchable) [size=64M]
>         Capabilities: [a0] AGP version 2.0
>         Capabilities: [c0] Power Management version 2
>
> 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (prog-if 00 [Normal decode])
>         Flags: bus master, 66Mhz, medium devsel, latency 0
>         Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
>         I/O behind bridge: 00009000-00009fff
>         Memory behind bridge: dde00000-dfefffff
>         Prefetchable memory behind bridge: cdc00000-ddcfffff
>         Capabilities: [80] Power Management version 2
>
> 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22)
>         Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge
>         Flags: bus master, stepping, medium devsel, latency 0
>
> 00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10) (prog-if 8a [Master SecP PriP])
>         Flags: bus master, medium devsel, latency 32
>         I/O ports at ffa0 [size=16]
>         Capabilities: [c0] Power Management version 2
>
> 00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) (prog-if 00 [UHCI])
>         Subsystem: Unknown device 0925:1234
>         Flags: bus master, medium devsel, latency 64, IRQ 9
>         I/O ports at cc00 [size=32]
>         Capabilities: [80] Power Management version 2
>
> 00:07.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) (prog-if 00 [UHCI])
>         Subsystem: Unknown device 0925:1234
>         Flags: bus master, medium devsel, latency 64, IRQ 9
>         I/O ports at d000 [size=32]
>         Capabilities: [80] Power Management version 2
>
> 00:07.4 SMBus: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
>         Flags: medium devsel
>         Capabilities: [68] Power Management version 2
>
> > 4) Did you check the problem you're experiencing isn't a memory problem?
> > That'd go away with removing some RAM.
>
> I assume this was to Mark, I have no problem:)
>
> > Vojtech Pavlik
> > SuSE Labs
>
> --
> David Raufeisen <david@fortyoz.org>
> Cell: (604) 818-3596

>From what I gather this chipset on 2.4.x is only stable if you cripple just about everything that makes
it worth having (udma, 2nd ide channel  etc etc)  ?    does it even work when all that's done now or is
it fully functional?
I used some pre 2.4.1 kernel before it thrashed my disk and i had UDMA disabled in bios and kernel and
the corruption persisted.  I heard somewhere that it may have been linked to swap ?     Anyway, I'm
using 2.2.19-pre7 right now with DMA and it's doing perfect ...with better responsiveness than 2.4.x .
Could this be because of via problems on the 2.4.x kernel or is it 2.4.x arch ?

-
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: VT82C686A corruption with 2.4.x

[Vojtech Pavlik]

On Tue, Jan 30, 2001 at 11:55:25PM -0800, David Raufeisen wrote:
> On Wednesday, 31 January 2001, at 08:36:42 (+0100),
> Vojtech Pavlik wrote:
> 
> > Hi!
> > 
> > 1) You don't seem to have any drives on the VIA controller. If this is
> > true, I don't think this can be a VIA IDE driver problem.
> >
> 
> Hi, Are you referring to Mark or me?

I was referring to David D.W. Downey, the one who started this thread.
He was in the To: fiels, you and Mark were in Cc:

> > 2) In your original message you suggest bs=1024M, which isn't a very
> > good idea, even on a 768 MB system. Here with bs=1024k it seems to run
> > fine.
> >
> > 3) You sent next to none VIA related debugging info. lspci -v itself
> > isn't much valuable because I don't get the register contents. Also
> > hdparm -i of the drives attached to the VIA chip would be useful. Plus
> > also the contents of /proc/ide/via.
> 
> I didn't supply anything either, even though my configuration works great it
> might prove useful to someone comparing:

Sorry, this message indeed was directed to someone else. Thanks for your
info, anyway, it's always useful to have some positive evidence that the
thing does work for people.

-- 
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: VT82C686A corruption with 2.4.x

[Vojtech Pavlik]

On Wed, Jan 31, 2001 at 04:48:41AM -0500, safemode wrote:

> From what I gather this chipset on 2.4.x is only stable if you
> cripple just about everything that makes
> it worth having (udma, 2nd ide channel  etc etc)  ?    does it even
> work when all that's done now or is it fully functional?

For most people (95% at least) it's fully functional, including DMA
(even UDMA100), both channels (I have never seen a problem with the 2nd
channel?), etc. There are some people who have problems, namely Abit KT7
users, but a BIOS upgrade seems to fix those case usually.

> I used some pre 2.4.1 kernel before it thrashed my disk and i had UDMA
> disabled in bios and kernel and the corruption persisted.  I heard
> somewhere that it may have been linked to swap ?     Anyway, I'm using
> 2.2.19-pre7 right now with DMA and it's doing perfect ...with better
> responsiveness than 2.4.x .  Could this be because of via problems on
> the 2.4.x kernel or is it 2.4.x arch ?

No, probably not.

-- 
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: VT82C686A corruption with 2.4.x

[Mark Hahn]

>From what I gather this chipset on 2.4.x is only stable if you cripple just about everything that makes
> it worth having (udma, 2nd ide channel  etc etc)  ?    does it even work when all that's done now or is
> it fully functional?

it seems to be fully functional for some or most people,
with two, apparently, reporting major problems.

my via (kt133) is flawless in 2.4.1 (a drive on each channel,
udma enabled and in use) and has for all the 2.3's since I got it.

-
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: VT82C686A corruption with 2.4.x

[David D.W. Downey]

On Wed, 31 Jan 2001, Vojtech Pavlik wrote:

> > > 1) You don't seem to have any drives on the VIA controller. If this is
> > > true, I don't think this can be a VIA IDE driver problem.
> > >

Umm, since the only 2 controllers in the machine are the VIA Vt82C686A and
the Promise PDC20265, yes I AM running drives on the VIA controller.

I have NO drives on the ATA100 controller which is the Promise
controller. Everything is running off the VIA.

> 
> > > 2) In your original message you suggest bs=1024M, which isn't a very
> > > good idea, even on a 768 MB system. Here with bs=1024k it seems to run
> > > fine.
> > >

Yes, that was a typo. My apologies. It _should_ have been a k not an M.

> > > 3) You sent next to none VIA related debugging info. lspci -v itself
> > > isn't much valuable because I don't get the register contents. Also
> > > hdparm -i of the drives attached to the VIA chip would be useful. Plus
> > > also the contents of /proc/ide/via.
> > 

OK, here are quite a few outputs. 

lspci -n outputs

00:00.0 Class 0600: 1106:0691 (rev c4)
00:01.0 Class 0604: 1106:8598
00:07.0 Class 0601: 1106:0686 (rev 22)
00:07.1 Class 0101: 1106:0571 (rev 10)
00:07.4 Class 0600: 1106:3057 (rev 30)
00:07.5 Class 0401: 1106:3058 (rev 20)
00:0c.0 Class 0180: 105a:0d30 (rev 02)
00:0e.0 Class 0100: 10cd:2300
00:10.0 Class 0200: 11ad:0002 (rev 20)
01:00.0 Class 0300: 121a:0005 (rev 01)


lspci -H1 outputs

00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev c4)
00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10)
00:0c.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device 0d30 (rev 02)
00:0e.0 SCSI storage controller: Advanced System Products, Inc ABP940-UW
00:10.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
01:00.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo 3 (rev 01)

lspci -m outputs

00:00.0 "Host bridge" "VIA Technologies, Inc." "VT82C691 [Apollo PRO]" -rc4 "" ""
00:01.0 "PCI bridge" "VIA Technologies, Inc." "VT82C598 [Apollo MVP3 AGP]" "" ""
00:07.0 "ISA bridge" "VIA Technologies, Inc." "VT82C686 [Apollo Super]" -r22 "VIA Technologies, Inc." "VT82C686/A PCI to ISA Bridge"
00:07.1 "IDE interface" "VIA Technologies, Inc." "VT82C586 IDE [Apollo]" -r10 -p8a "" ""
00:07.4 "Host bridge" "VIA Technologies, Inc." "VT82C686 [Apollo Super ACPI]" -r30 "" ""
00:07.5 "Multimedia audio controller" "VIA Technologies, Inc." "VT82C686 [Apollo Super AC97/Audio]" -r20 "VIA Technologies, Inc." "VT82C686 [Apollo Super AC97/Audio]"
00:0c.0 "Unknown mass storage controller" "Promise Technology, Inc." "0d30" -r02 "Promise Technology, Inc." "0d30"
00:0e.0 "SCSI storage controller" "Advanced System Products, Inc" "ABP940-UW" "" ""
00:10.0 "Ethernet controller" "Lite-On Communications Inc" "LNE100TX" -r20 "Netgear" "FA310TX"
01:00.0 "VGA compatible controller" "3Dfx Interactive, Inc." "Voodoo 3" -r01 "3Dfx Interactive, Inc." "Voodoo3 AGP"

lspci outputs

00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev c4)
00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10)
00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 [Apollo Super AC97/Audio] (rev 20)
00:0c.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device 0d30 (rev 02)
00:0e.0 SCSI storage controller: Advanced System Products, Inc ABP940-UW
00:10.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
01:00.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo 3 (rev 01)


hdparm -i /dev/hda outputs


/dev/hda:

 Model=WDC WD300BB-00AUA1, FwRev=18.20D18, SerialNo=WD-WMA6W1132085
 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
 RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40
 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=58633344
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4 
 DMA modes: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4 udma5 

hdparm -i /dev/hdc outputs


/dev/hdc:

 Model=WDC WD153AA, FwRev=05.05B05, SerialNo=WD-WMA0R1258522
 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
 RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40
 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=30064608
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4 
 DMA modes: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4 

cat /proc/ide/via outputs

----------VIA BusMastering IDE Configuration----------------
Driver Version:                     3.20
South Bridge:                       VIA vt82c686a
Revision:                           ISA 0x22 IDE 0x10
BM-DMA base:                        0xb000
PCI clock:                          33MHz
Master Read  Cycle IRDY:            1ws
Master Write Cycle IRDY:            1ws
BM IDE Status Register Read Retry:  yes
Max DRDY Pulse Width:               No limit
-----------------------Primary IDE-------Secondary IDE------
Read DMA FIFO flush:          yes                 yes
End Sector FIFO flush:         no                  no
Prefetch Buffer:               no                  no
Post Write Buffer:             no                  no
Enabled:                      yes                 yes
Simplex only:                  no                  no
Cable Type:                   40w                 40w
-------------------drive0----drive1----drive2----drive3-----
Transfer Mode:       UDMA       PIO      UDMA       PIO
Address Setup:       30ns     120ns      30ns     120ns
Cmd Active:          90ns      90ns      90ns      90ns
Cmd Recovery:        30ns      30ns      30ns      30ns
Data Active:         90ns     330ns      90ns     330ns
Data Recovery:       30ns     270ns      30ns     270ns
Cycle Time:          60ns     600ns      60ns     600ns
Transfer Rate:   33.0MB/s   3.3MB/s  33.0MB/s   3.3MB/s


Other than this I don't know what else to give you.

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: VT82C686A corruption with 2.4.x

[David Riley]

Mark Hahn wrote:
> 
> >>From what I gather this chipset on 2.4.x is only stable if you cripple just about everything that makes
> > it worth having (udma, 2nd ide channel  etc etc)  ?    does it even work when all that's done now or is
> > it fully functional?
> 
> it seems to be fully functional for some or most people,
> with two, apparently, reporting major problems.
> 
> my via (kt133) is flawless in 2.4.1 (a drive on each channel,
> udma enabled and in use) and has for all the 2.3's since I got it.

Not to make a "mee too" post but...

It's worked flawlessly for me.  Always.  Since it seems to work fine for
just about everyone else, I'd venture to say that it's a board specific
issue, quite likely with the BIOS.  Some other problems seem to have to
do with the memory; I remember the KX133 had some definite problems with
memory timing, especially with large amounts (3 DIMMS were a problem on
some motherboards that were loosely laid out).

My 2 cents,
	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: VT82C686A corruption with 2.4.x

[safemode]

Mark Hahn wrote:

> >From what I gather this chipset on 2.4.x is only stable if you cripple just about everything that makes
> > it worth having (udma, 2nd ide channel  etc etc)  ?    does it even work when all that's done now or is
> > it fully functional?
>
> it seems to be fully functional for some or most people,
> with two, apparently, reporting major problems.
>
> my via (kt133) is flawless in 2.4.1 (a drive on each channel,
> udma enabled and in use) and has for all the 2.3's since I got it.

I'm wondering... Perhaps it's a problem motherboard specific.  I'm using the KA7 and saw pretty bad
problems (extreme fs corruption)  and bad latency. Perhaps the K7V and the KT7's dont have this problem.  I
dont see any of the problems with dma enabled on 2.2.x

Output of 2.2.19-pre7 lspci -v
  00:00.0 Host bridge: VIA Technologies, Inc. VT8371 [KX133] (rev 02)
        Flags: bus master, medium devsel, latency 0
        Memory at d0000000 (32-bit, prefetchable)
        Capabilities: [a0] AGP version 2.0

00:01.0 PCI bridge: VIA Technologies, Inc. VT8371 [KX133 AGP]  (prog-if 00 [Normal decode])
        Flags: bus master, 66Mhz, medium devsel, latency 0
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
        I/O behind bridge: 0000c000-0000cfff
        Memory behind bridge: d4000000-d7ffffff
        Prefetchable memory behind bridge: d8000000-d9ffffff
        Capabilities: [80] Power Management version 2

00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22)
        Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge
        Flags: bus master, stepping, medium devsel, latency 0

00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10) (prog-if 8a [Master SecP PriP])
        Flags: bus master, medium devsel, latency 32
        I/O ports at d000
        Capabilities: [c0] Power Management version 2



-
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: VT82C686A corruption with 2.4.x

[Tobias Ringstrom]

On Wed, 31 Jan 2001, safemode wrote:

> I'm wondering... Perhaps it's a problem motherboard specific.  I'm
> using the KA7 and saw pretty bad problems (extreme fs corruption)
> and bad latency. Perhaps the K7V and the KT7's dont have this problem.
> I dont see any of the problems with dma enabled on 2.2.x

But are you using the same DMA mode in 2.2 as in 2.4?  You can check that
using hdparm -i, I believe.

/Tobias

-
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: VT82C686A corruption with 2.4.x

[safemode]

Tobias Ringstrom wrote:

> On Wed, 31 Jan 2001, safemode wrote:
>
> > I'm wondering... Perhaps it's a problem motherboard specific.  I'm
> > using the KA7 and saw pretty bad problems (extreme fs corruption)
> > and bad latency. Perhaps the K7V and the KT7's dont have this problem.
> > I dont see any of the problems with dma enabled on 2.2.x
>
> But are you using the same DMA mode in 2.2 as in 2.4?  You can check that
> using hdparm -i, I believe.
>
> /Tobias

yea i know. . same mode       i also had a big problem with DMA timeouts on
2.4 so  .. i dont know what's up with 2.4 and my motherboard ...    2.2
hasn't shown a single irq or DMA error yet since going back to it.
currently 2.2.19-pre7 is using UDMA4     i just flashed the bios today so ..
hopefully that should have fixed any problems.  I get 24MB/s each according
to hdparm -t   on my hdd's and both are on the same channel.   This is much
better than i ever got with 2.4 even when only one drive was on a channel.
Right now my k7-2 750 is at 849mhz with a FSB of 114Mhz and PCI at 34Mhz.
my nbench performance under 2.2 is comparable to results for 1Ghz t-bird's so
i'm happy with 2.2.  The only thing that would make me want to upgrade would
be latency patches.  I'm convinced 2.4 has performance issues so i guess i'll
be using 2.2 until 2.5 begins.      Is it really only 1 or 2 people having
this Via corruption problem?   i doubt it's a bios problem because wouldn't
2.2 be effected by a bios bug if 2.4 is?   In either case the changelogs dont
show any  fixes for it.

-
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: VT82C686A corruption with 2.4.x

[Alan Cox]

> better than i ever got with 2.4 even when only one drive was on a channel.
> Right now my k7-2 750 is at 849mhz with a FSB of 114Mhz and PCI at 34Mhz.

Hint: people who overclock machines get suprising odd results and bad stuff
happens. Please dont waste developers time unless you can reproduce it at
the intended speed for the components

-
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: VT82C686A corruption with 2.4.x

[safemode]

Alan Cox wrote:

> > better than i ever got with 2.4 even when only one drive was on a channel.
> > Right now my k7-2 750 is at 849mhz with a FSB of 114Mhz and PCI at 34Mhz.
>
> Hint: people who overclock machines get suprising odd results and bad stuff
> happens. Please dont waste developers time unless you can reproduce it at
> the intended speed for the components

Like i said .. i just did that within the last 5 min   it has nothing to do
with any problems i've been talking about

-
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: VT82C686A corruption with 2.4.x

[Byron Stanoszek]

On Wed, 31 Jan 2001, safemode wrote:

> yea i know. . same mode       i also had a big problem with DMA timeouts on
> 2.4 so  .. i dont know what's up with 2.4 and my motherboard ...    2.2
> hasn't shown a single irq or DMA error yet since going back to it.
> currently 2.2.19-pre7 is using UDMA4     i just flashed the bios today so ..
> hopefully that should have fixed any problems.  I get 24MB/s each according
> to hdparm -t   on my hdd's and both are on the same channel.   This is much
> better than i ever got with 2.4 even when only one drive was on a channel.
> Right now my k7-2 750 is at 849mhz with a FSB of 114Mhz and PCI at 34Mhz.
> my nbench performance under 2.2 is comparable to results for 1Ghz t-bird's so
> i'm happy with 2.2.  The only thing that would make me want to upgrade would
> be latency patches.  I'm convinced 2.4 has performance issues so i guess i'll
> be using 2.2 until 2.5 begins.      Is it really only 1 or 2 people having
> this Via corruption problem?   i doubt it's a bios problem because wouldn't
> 2.2 be effected by a bios bug if 2.4 is?   In either case the changelogs dont
> show any  fixes for it.

If your FSB is running at 114 MHz, you should try the kernel parameter
idebus=37 to get DMA working correctly. Otherwise you'll see an ide-reset error
on bootup because the instructions are too fast. The VIA driver on 2.2 doesn't
correctly program the PCI card, so you don't see weird behavior running 2.2
with a faster PCI clock.

(Note: 1.14 * 33 = 37.6 PCI Clk)

It also matters what motherboard you're using, and if it can support speeds up
past 100. If you're serious about overclocking, buy one of the new KT133A
boards that support speeds up to 133 (or an average overclocked 145 limit).

For instance, my Epox KX133 board is unstable at anything above 110 FSB, but
I've seen the Abit KT7 go as high as 116. You should also have some good
memory that is rated for 150MHz, otherwise you're just asking for trouble.

As always, if you have problems with the kernel and want to submit a bug
report, please put all the settings back to normal and test thoroughly before
continuing. It's funny how many bug reports I've heard from people who've
overclocked their FSB and expected the IDE DMA to be set appropriately under
2.4... maybe this should be mentioned somewhere in ide.txt, even though
overclocking is frowned upon.

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: VT82C686A corruption with 2.4.x

[safemode]

Byron Stanoszek wrote:

> On Wed, 31 Jan 2001, safemode wrote:
>
> > yea i know. . same mode       i also had a big problem with DMA timeouts on
> > 2.4 so  .. i dont know what's up with 2.4 and my motherboard ...    2.2
> > hasn't shown a single irq or DMA error yet since going back to it.
> > currently 2.2.19-pre7 is using UDMA4     i just flashed the bios today so ..
> > hopefully that should have fixed any problems.  I get 24MB/s each according
> > to hdparm -t   on my hdd's and both are on the same channel.   This is much
> > better than i ever got with 2.4 even when only one drive was on a channel.
> > Right now my k7-2 750 is at 849mhz with a FSB of 114Mhz and PCI at 34Mhz.
> > my nbench performance under 2.2 is comparable to results for 1Ghz t-bird's so
> > i'm happy with 2.2.  The only thing that would make me want to upgrade would
> > be latency patches.  I'm convinced 2.4 has performance issues so i guess i'll
> > be using 2.2 until 2.5 begins.      Is it really only 1 or 2 people having
> > this Via corruption problem?   i doubt it's a bios problem because wouldn't
> > 2.2 be effected by a bios bug if 2.4 is?   In either case the changelogs dont
> > show any  fixes for it.
>
> If your FSB is running at 114 MHz, you should try the kernel parameter
> idebus=37 to get DMA working correctly. Otherwise you'll see an ide-reset error
> on bootup because the instructions are too fast. The VIA driver on 2.2 doesn't
> correctly program the PCI card, so you don't see weird behavior running 2.2
> with a faster PCI clock.
>
> (Note: 1.14 * 33 = 37.6 PCI Clk)
>
> It also matters what motherboard you're using, and if it can support speeds up
> past 100. If you're serious about overclocking, buy one of the new KT133A
> boards that support speeds up to 133 (or an average overclocked 145 limit).
>
> For instance, my Epox KX133 board is unstable at anything above 110 FSB, but
> I've seen the Abit KT7 go as high as 116. You should also have some good
> memory that is rated for 150MHz, otherwise you're just asking for trouble.

My KA7 can go over 160Mhz FSB
Yes i know about memory speed limitions ..that's why you are able to choose
HW clock - PCI   so  at those high speeds it's actually   say  120Mhz - 33
keeping you below or near 100 and not well over the spec of the ram.    Anyway i
dont go that high    110 is safe an doesn't cause any heat increase and gives me
100Mhz more.  nbench shows my performance about equal to t-bird 1ghz.  at least in
memory and integer.   The KA7 lets you increase the FSB without increasing the
PCI bus speed,  so i dont have to worry about changing ide bus timings, PCI is
still at 33 - 34   not enough to hurt any cards.

>
> As always, if you have problems with the kernel and want to submit a bug
> report, please put all the settings back to normal and test thoroughly before
> continuing. It's funny how many bug reports I've heard from people who've
> overclocked their FSB and expected the IDE DMA to be set appropriately under
> 2.4... maybe this should be mentioned somewhere in ide.txt, even though
> overclocking is frowned upon.

As i mentioned in older emails, i did this _today_   i mentioned this "bug" over
two weeks ago.   I turned off DMA in the bios and kernel and the "bug" was still
present.   you can read the old emails and see for yourself.

>
> Regards,
>  Byron
>
> --
> Byron Stanoszek                         Ph: (330) 644-3059
> Systems Programmer                      Fax: (330) 644-8110
> Commercial Timesharing Inc.             Email: bstanoszek@comtime.com

OK ok..  just forget i ever mentioned it ..  It has nothing to do with anything
i've been talking about problem wise because i _JUST_ did it now ...   It is the
cause of nothing because they all happened before i did anything to the speed.
This is a 2.4.x kernel problem.  It has nothing to do with overclocking because at
the time i didn't.  When i used 2.2.x it did not have any problems and i did not
overclock.    As of now i have no problems with ide resets or dma timeouts (which
is what i said before), regardless of if i'm overclocking it now or not.  It's
working great (better than great) without changing anyhing in 2.2.19-pre7.
 heh.   so everyone can stop flipping out over overclocking because i made sure
hardware settings were default failsafe even before deciding it was definitely a
kernel problem and i never had the settings over spec before the problem surfaced.

-
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: VT82C686A corruption with 2.4.x

[Vojtech Pavlik]

On Wed, Jan 31, 2001 at 05:57:45PM -0500, safemode wrote:
> Alan Cox wrote:
> 
> > > better than i ever got with 2.4 even when only one drive was on a channel.
> > > Right now my k7-2 750 is at 849mhz with a FSB of 114Mhz and PCI at 34Mhz.
> >
> > Hint: people who overclock machines get suprising odd results and bad stuff
> > happens. Please dont waste developers time unless you can reproduce it at
> > the intended speed for the components
> 
> Like i said .. i just did that within the last 5 min   it has nothing to do
> with any problems i've been talking about

Btw, if you run your FSB at 114 MHz, you need to pass 'idebus=38' to the
IDE driver so that it knows your PCI bus runs at 38 MHz (3x38 = 114).

Otherwise you'll get incorrect timing etc.

-- 
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: VT82C686A corruption with 2.4.x

[Vojtech Pavlik]

On Wed, Jan 31, 2001 at 07:46:31PM -0500, Byron Stanoszek wrote:

> > yea i know. . same mode       i also had a big problem with DMA timeouts on
> > 2.4 so  .. i dont know what's up with 2.4 and my motherboard ...    2.2
> > hasn't shown a single irq or DMA error yet since going back to it.
> > currently 2.2.19-pre7 is using UDMA4     i just flashed the bios today so ..
> > hopefully that should have fixed any problems.  I get 24MB/s each according
> > to hdparm -t   on my hdd's and both are on the same channel.   This is much
> > better than i ever got with 2.4 even when only one drive was on a channel.
> > Right now my k7-2 750 is at 849mhz with a FSB of 114Mhz and PCI at 34Mhz.
> > my nbench performance under 2.2 is comparable to results for 1Ghz t-bird's so
> > i'm happy with 2.2.  The only thing that would make me want to upgrade would
> > be latency patches.  I'm convinced 2.4 has performance issues so i guess i'll
> > be using 2.2 until 2.5 begins.      Is it really only 1 or 2 people having
> > this Via corruption problem?   i doubt it's a bios problem because wouldn't
> > 2.2 be effected by a bios bug if 2.4 is?   In either case the changelogs dont
> > show any  fixes for it.
> 
> If your FSB is running at 114 MHz, you should try the kernel parameter
> idebus=37 to get DMA working correctly. Otherwise you'll see an ide-reset error
> on bootup because the instructions are too fast. The VIA driver on 2.2 doesn't
> correctly program the PCI card, so you don't see weird behavior running 2.2
> with a faster PCI clock.
> 
> (Note: 1.14 * 33 = 37.6 PCI Clk)

It's 38:

114 / 3 == 38 == 1.14 * 33.333333

But definitely it isn't 34 or the default 33.

-- 
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: VT82C686A corruption with 2.4.x

[Vojtech Pavlik]

On Wed, Jan 31, 2001 at 08:52:58PM -0500, safemode wrote:

> My KA7 can go over 160Mhz FSB
> Yes i know about memory speed limitions ..that's why you are able to choose
> HW clock - PCI   so  at those high speeds it's actually   say  120Mhz - 33
> keeping you below or near 100 and not well over the spec of the ram.    Anyway i
> dont go that high    110 is safe an doesn't cause any heat increase and gives me
> 100Mhz more.  nbench shows my performance about equal to t-bird 1ghz.  at least in
> memory and integer.   The KA7 lets you increase the FSB without increasing the
> PCI bus speed,  so i dont have to worry about changing ide bus timings, PCI is
> still at 33 - 34   not enough to hurt any cards.

Ugh. What chips your KA7 has? As far as I know the KX133 chip (vt8731)
can't do asynchronous PCI, allowing for 2x, 3x and 4x FSB/PCI divisors
only. So I don't a way to have your FSB at 114 and your PCI at 34 with
this chip.

> OK ok..  just forget i ever mentioned it ..  It has nothing to do with anything
> i've been talking about problem wise because i _JUST_ did it now ...   It is the
> cause of nothing because they all happened before i did anything to the speed.
> This is a 2.4.x kernel problem.  It has nothing to do with overclocking because at
> the time i didn't.  When i used 2.2.x it did not have any problems and i did not
> overclock.    As of now i have no problems with ide resets or dma timeouts (which
> is what i said before), regardless of if i'm overclocking it now or not.  It's
> working great (better than great) without changing anyhing in 2.2.19-pre7.
>  heh.   so everyone can stop flipping out over overclocking because i made sure
> hardware settings were default failsafe even before deciding it was definitely a
> kernel problem and i never had the settings over spec before the problem surfaced.

Ok. So do you still have a working 2.2 setup and a non-working 2.4
setup? Would you be able to send me the usual (lspci -vvxxx, dmesg,
hdparm -t /dev/hd*, hdparm -i /dev/hd*, cat /proc/ide/via) data for both
so that I can compare them?

If I find any differences, I'll know what the bug is.

-- 
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: VT82C686A corruption with 2.4.x

[safemode]

Vojtech Pavlik wrote:

> On Wed, Jan 31, 2001 at 08:52:58PM -0500, safemode wrote:
>
> > My KA7 can go over 160Mhz FSB
> > Yes i know about memory speed limitions ..that's why you are able to choose
> > HW clock - PCI   so  at those high speeds it's actually   say  120Mhz - 33
> > keeping you below or near 100 and not well over the spec of the ram.    Anyway i
> > dont go that high    110 is safe an doesn't cause any heat increase and gives me
> > 100Mhz more.  nbench shows my performance about equal to t-bird 1ghz.  at least in
> > memory and integer.   The KA7 lets you increase the FSB without increasing the
> > PCI bus speed,  so i dont have to worry about changing ide bus timings, PCI is
> > still at 33 - 34   not enough to hurt any cards.
>
> Ugh. What chips your KA7 has? As far as I know the KX133 chip (vt8731)
> can't do asynchronous PCI, allowing for 2x, 3x and 4x FSB/PCI divisors
> only. So I don't a way to have your FSB at 114 and your PCI at 34 with
> this chip.

Actually it can and it's a simple bios option.  I'd show you but it's in the manual and
it's hard to scan stuff without a scanner.     You can have asynchronous FSB up to
28Mhz    so i can have 128Mhz FSB with 33Mhz PCI      after that i have to use the
synchronous increase which changes PCI as i change the FSB value   but the other value
gets added onto that asynchronously.  It's really a standard feature of this board.
I'm not making it up and the proof is me not changing idebus at all and still working
after a day at full load and semi-constant usage and MANY compiles.   also the bios
screen doesn't lie.


>
> > OK ok..  just forget i ever mentioned it ..  It has nothing to do with anything
> > i've been talking about problem wise because i _JUST_ did it now ...   It is the
> > cause of nothing because they all happened before i did anything to the speed.
> > This is a 2.4.x kernel problem.  It has nothing to do with overclocking because at
> > the time i didn't.  When i used 2.2.x it did not have any problems and i did not
> > overclock.    As of now i have no problems with ide resets or dma timeouts (which
> > is what i said before), regardless of if i'm overclocking it now or not.  It's
> > working great (better than great) without changing anyhing in 2.2.19-pre7.
> >  heh.   so everyone can stop flipping out over overclocking because i made sure
> > hardware settings were default failsafe even before deciding it was definitely a
> > kernel problem and i never had the settings over spec before the problem surfaced.
>
> Ok. So do you still have a working 2.2 setup and a non-working 2.4
> setup? Would you be able to send me the usual (lspci -vvxxx, dmesg,
> hdparm -t /dev/hd*, hdparm -i /dev/hd*, cat /proc/ide/via) data for both
> so that I can compare them?
>
> If I find any differences, I'll know what the bug is.
>
> --
> Vojtech Pavlik
> SuSE Labs

I cant get anything from 2.4 because I kind of dont want to re-format and re-install
debian again and lose my email and logs and config scripts.  It's seriously that bad.
fsck would say it fixed everything ..  I would reboot and immediately it would come up
with certain files having IO errors and then inode errors.   Strangely though, this
didn't occur the very first time i booted with the kernel...   it took about 3 days
until it happened, but after that it would happen all the time and even after
reboots.   I even disabled DMA support for both and it still happened .  So i really
doubt it has to do with the via specific driver for DMA support in the kernel (ie.
there is no /proc/ide/via).    i'll look into finding some way of running 2.4 so that
it cant destroy my filesystems.

-
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: VT82C686A corruption with 2.4.x

[David D.W. Downey]

Yeah, I'm seriously beginning to think it's a board specific issue. If I
drop the RAM count down to 768MB I get far less drops in app deaths
now. I'm living in Sunnyvale CA which is part of the Rolling Blackouts
designated spots in CA. Ever since the power companies have been
instituting this I've seen equipment that otherwise ran great all of a
sudden start flaking.

I've got this particular machine connected to a UPS so I figured the
voltage regulation would be right on the money. Now, I'm not so sure since
a number of people have brought this up. I'm going to drop her down to
768MB and then try a 128MB DIMM in there. I want to see if it can handle
that. Since the 128s have less draw than the 256s do, maybe this will
work.

Right now I've got the full 1GB in there. What I'm seeing now is
application deaths, occational X11 lockups, but SUPRIZE! SUPRIZE! no more
drive corruptions since I removed the DMA flag from the drives, disabled
DMA use in the BIOS and replaced the ATA66 cable with an ATA33.

For everyone out there that's assisted in tracking this down and assisted
in getting a working fix going.. .THANK YOU!

For now, I'm going to have to play keep in step with the kernel, patches,
and the VIA driver. Voj, can you directly add me to whatever ANNOUNCE list
you use for announcing the latest release of the driver?

Once again thanks folks. It's still not totally stable here, but it's a
DAMN sight farther than it was before. While not TOTALLY convinced that
it's a local hardware issue, I do thank folks for their 2 cents. :-)


On Wed, 31 Jan 2001, David Riley
wrote:

> Mark Hahn wrote:
> > 
> > >>From what I gather this chipset on 2.4.x is only stable if you cripple just about everything that makes
> > > it worth having (udma, 2nd ide channel  etc etc)  ?    does it even work when all that's done now or is
> > > it fully functional?
> > 
> > it seems to be fully functional for some or most people,
> > with two, apparently, reporting major problems.
> > 
> > my via (kt133) is flawless in 2.4.1 (a drive on each channel,
> > udma enabled and in use) and has for all the 2.3's since I got it.
> 
> Not to make a "mee too" post but...
> 
> It's worked flawlessly for me.  Always.  Since it seems to work fine for
> just about everyone else, I'd venture to say that it's a board specific
> issue, quite likely with the BIOS.  Some other problems seem to have to
> do with the memory; I remember the KX133 had some definite problems with
> memory timing, especially with large amounts (3 DIMMS were a problem on
> some motherboards that were loosely laid out).
> 
> My 2 cents,
> 	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/
> 

-
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: VT82C686A corruption with 2.4.x

[Byron Stanoszek]

On Thu, 1 Feb 2001, safemode wrote:

> Vojtech Pavlik wrote:
> 
> > Ugh. What chips your KA7 has? As far as I know the KX133 chip (vt8731)
> > can't do asynchronous PCI, allowing for 2x, 3x and 4x FSB/PCI divisors
> > only. So I don't a way to have your FSB at 114 and your PCI at 34 with
> > this chip.
> 
> Actually it can and it's a simple bios option.  I'd show you but it's in the manual and
> it's hard to scan stuff without a scanner.     You can have asynchronous FSB up to
> 28Mhz    so i can have 128Mhz FSB with 33Mhz PCI      after that i have to use the
> synchronous increase which changes PCI as i change the FSB value   but the other value
> gets added onto that asynchronously.  It's really a standard feature of this board.
> I'm not making it up and the proof is me not changing idebus at all and still working
> after a day at full load and semi-constant usage and MANY compiles.   also the bios
> screen doesn't lie.

Yeah, by bios does the same thing too on the Abit KT7(a). But you might not
want to run your PCI clock at 34 instead of 33. Two problems can occur. If you
don't specify idebus=34 on the kernel prompt, the IDE timings might eventually
get a DMA reset under 100% disk access. If you do say idebus=34, then you drop
your maximum throughput from 33 MB/s to 27MB/s.

I was curious and compiled a list of timings from Vojtech's formula for certain
idebus=xx MHz ratings (I _think_ the UDMA-66 timings are correct, maybe you can
check on these, Vojtech..)

Clock | Setup  Active  Recover  Cycle  UDMA | UDMA-33  UDMA-66  UDMA-100
   21 |    1       2        1      3    0   |   28.0     56.0      84.0
   22 |    1       2        1      3    0   |   29.3     58.6      88.0
   23 |    1       2        1      3    0   |   30.6     61.2      92.0
   24 |    1       2        1      3    0   |   32.0     64.0      96.0
   25 |    1       2        1      3    0   |   33.3     66.6     100.0
   26 |    1       2        2      4    0   |   26.0     52.0      78.0
   27 |    1       2        2      4    0   |   27.0     54.0      81.0
   28 |    1       2        2      4    0   |   28.0     56.0      84.0
   29 |    1       3        1      4    0   |   29.0     58.0      87.0
   30 |    1       3        1      4    0   |   30.0     60.0      90.0
   31 |    1       3        1      4    0   |   31.0     62.0      93.0
   32 |    1       3        1      4    0   |   32.0     64.0      96.0
   33 |    1       3        1      4    0   |   33.0     66.0      99.0
   34 |    1       3        2      5    0   |   27.2     54.4      81.6
   35 |    1       3        2      5    0   |   28.0     56.0      84.0
   36 |    1       3        2      5    0   |   28.8     57.6      86.4
   37 |    1       3        2      5    0   |   29.6     59.2      88.8
   38 |    1       3        2      5    0   |   30.4     60.8      91.2
   39 |    1       3        2      5    0   |   31.2     62.4      93.6
   40 |    1       3        2      5    0   |   32.0     64.0      96.0
   41 |    2       3        2      5    0   |   32.8     65.6      98.4
   42 |    2       4        2      6    0   |   28.0     56.0      84.0
   43 |    2       4        2      6    0   |   28.6     57.2      86.0
   44 |    2       4        2      6    1   |   29.3     58.6      88.0
   45 |    2       4        2      6    1   |   30.0     60.0      90.0
   46 |    2       4        2      6    1   |   30.6     61.2      92.0
   47 |    2       4        2      6    1   |   31.3     62.6      94.0
   48 |    2       4        2      6    1   |   32.0     64.0      96.0
   49 |    2       4        2      6    1   |   32.6     65.2      98.0
   50 |    2       4        2      6    1   |   33.3     66.6     100.0
   51 |    2       4        3      7    1   |   29.1     58.2      87.4
   52 |    2       4        3      7    1   |   29.7     59.4      89.1
   53 |    2       4        3      7    1   |   30.2     60.4      90.8
   54 |    2       4        3      7    1   |   30.8     61.6      92.5
   55 |    2       4        3      7    1   |   31.4     62.8      94.2
   56 |    2       5        3      8    1   |   28.0     56.0      84.0
   57 |    2       5        3      8    1   |   28.5     57.0      85.5
   58 |    2       5        3      8    1   |   29.0     58.0      87.0
   59 |    2       5        3      8    1   |   29.5     59.0      88.5
   60 |    2       5        3      8    1   |   30.0     60.0      90.0

Personally I like the 113 MHz FSB setting, which runs PCI at 37 and memory at
150 (133*1.13). It helps to have memory rated for 150. :) I've had a system
run at this rate for the past 4 months now and I've never had any problems.
Of course, your results may vary.

-- 
Byron Stanoszek                         Ph: (330) 644-3059
Systems Programmer                      Fax: (330) 644-8110
Commercial Timesharing Inc.             Email: byron@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: VT82C686A corruption with 2.4.x

[Vojtech Pavlik]

On Thu, Feb 01, 2001 at 11:46:08AM -0500, Byron Stanoszek wrote:

> Yeah, by bios does the same thing too on the Abit KT7(a).

Ok, I'll remember this. This is most likely the cause of the problems
many people had with the KT7 in the past.

> But you might not
> want to run your PCI clock at 34 instead of 33. Two problems can occur. If you
> don't specify idebus=34 on the kernel prompt, the IDE timings might eventually
> get a DMA reset under 100% disk access. If you do say idebus=34, then you drop
> your maximum throughput from 33 MB/s to 27MB/s.
> 
> I was curious and compiled a list of timings from Vojtech's formula for certain
> idebus=xx MHz ratings (I _think_ the UDMA-66 timings are correct, maybe you can
> check on these, Vojtech..)
> 
> Clock | Setup  Active  Recover  Cycle  UDMA | UDMA-33  UDMA-66  UDMA-100
>    21 |    1       2        1      3    0   |   28.0     56.0      84.0
>    22 |    1       2        1      3    0   |   29.3     58.6      88.0
>    23 |    1       2        1      3    0   |   30.6     61.2      92.0
[snip]
>    31 |    1       3        1      4    0   |   31.0     62.0      93.0
>    32 |    1       3        1      4    0   |   32.0     64.0      96.0
>    33 |    1       3        1      4    0   |   33.0     66.0      99.0
>    34 |    1       3        2      5    0   |   27.2     54.4      81.6
[snip]
>    59 |    2       5        3      8    1   |   29.5     59.0      88.5
>    60 |    2       5        3      8    1   |   30.0     60.0      90.0

Well, the table depends on what type of southbridge chip are you using -
if it's 586b or other UDMA33 chip, 586b/686a or other UDMA66 chip or the
UDMA100 capable 686b.

The U33 chips do UDMA timing in PCICLK (T = 30ns @ 33MHz) increments, U66 in
PCICLK*2 (T = 15ns @ 33 MHz) increments, and for U100 it's assumed that
there is an external 100MHz clock fed to the chip, so that the UDMA timing is
in T = 10ns increments independent of the PCICLK. I'm not 100% sure about
the last, it might be just PCICLK*3 (T = 10ns @ 33 MHz). An experiment needs
to be carried out to verify this.

So, s ahort excerpt of the table will look like:

Chip   | Clock | Setup Active Recover | T  | UDMA-33  UDMA-66  UDMA-100
586b   |    25 |    1      2       1  | 40 | 2T=25.0  xxxxxxx  xxxxxxxx
686a   |    25 |    1      2       1  | 20 | 3T=33.3  2T=50.0  xxxxxxxx
686b   |    25 |    1      2       1  | 10 | 6T=33.3  4T=66.6  2T=100.0

Chip   | Clock | Setup Active Recover | T  | UDMA-33  UDMA-66  UDMA-100
586b   |    33 |    1      2       1  | 30 | 2T=33.3  xxxxxxx  xxxxxxxx
686a   |    33 |    1      2       1  | 15 | 4T=33.3  2T=66.6  xxxxxxxx
686b   |    33 |    1      2       1  | 10 | 6T=33.3  4T=66.6  2T=100.0

... that is, if the 686b indeed has a 100MHz clock source. If not, then
in the case of 25 MHz, T would be 13.3ns. If you can verify this, it'd
be nice.

-- 
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: VT82C686A corruption with 2.4.x

[Byron Stanoszek]

On Thu, 1 Feb 2001, Vojtech Pavlik wrote:

> On Thu, Feb 01, 2001 at 11:46:08AM -0500, Byron Stanoszek wrote:
> 
> > Yeah, by bios does the same thing too on the Abit KT7(a).
> 
> Ok, I'll remember this. This is most likely the cause of the problems
> many people had with the KT7 in the past.

What cause are you referring to? As far as I know, there are two options to
increasing the FSB clock.. one increases both FSB+PCICLK, the other just
increases FSB. If you increase the FSB only, it should keep PCICLK at a solid
33. (But I could be wrong, I've never tested that. I can tomorrow though.)

> The U33 chips do UDMA timing in PCICLK (T = 30ns @ 33MHz) increments, U66 in
> PCICLK*2 (T = 15ns @ 33 MHz) increments, and for U100 it's assumed that
> there is an external 100MHz clock fed to the chip, so that the UDMA timing is
> in T = 10ns increments independent of the PCICLK. I'm not 100% sure about
> the last, it might be just PCICLK*3 (T = 10ns @ 33 MHz). An experiment needs
> to be carried out to verify this.

I don't have a KT7A personally, I only have a KT7. Can anyone else with a KT7A
verify this? By verify, I take it you mean to use idebus=33 and overclock
PCICLK? :) At least that would determine if UDMA100 is based on PCI or an
external 100MHz source.

Regards,
 Byron

-- 
Byron Stanoszek                         Ph: (330) 644-3059
Systems Programmer                      Fax: (330) 644-8110
Commercial Timesharing Inc.             Email: byron@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: VT82C686A corruption with 2.4.x

[Vojtech Pavlik]

On Thu, Feb 01, 2001 at 01:20:00PM -0500, Byron Stanoszek wrote:

> > On Thu, Feb 01, 2001 at 11:46:08AM -0500, Byron Stanoszek wrote:
> > 
> > > Yeah, by bios does the same thing too on the Abit KT7(a).
> > 
> > Ok, I'll remember this. This is most likely the cause of the problems
> > many people had with the KT7 in the past.
> 
> What cause are you referring to? As far as I know, there are two options to
> increasing the FSB clock.. one increases both FSB+PCICLK, the other just
> increases FSB. If you increase the FSB only, it should keep PCICLK at a solid
> 33. (But I could be wrong, I've never tested that. I can tomorrow though.)

I mean that people can alter the PCI clock on these boards and that 33
doesn't to be always exactly 33 due to rounding errors if used with a
FSB other than 66 or 100 or 133.

Could it be that the PCI bus is not asynchronous, but only
pseudo-synchronous, allowing for divisors of 5, 4.5, 4, 3.5, 3, 2.5, 2?

> > The U33 chips do UDMA timing in PCICLK (T = 30ns @ 33MHz) increments, U66 in
> > PCICLK*2 (T = 15ns @ 33 MHz) increments, and for U100 it's assumed that
> > there is an external 100MHz clock fed to the chip, so that the UDMA timing is
> > in T = 10ns increments independent of the PCICLK. I'm not 100% sure about
> > the last, it might be just PCICLK*3 (T = 10ns @ 33 MHz). An experiment needs
> > to be carried out to verify this.
> 
> I don't have a KT7A personally, I only have a KT7. Can anyone else with a KT7A
> verify this? By verify, I take it you mean to use idebus=33 and overclock
> PCICLK? :) At least that would determine if UDMA100 is based on PCI or an
> external 100MHz source.

Actually he should use the correct idebus= so that the Active/Recover
timings are correct. If KT7A doesn't work with UDMA at high PCI clocks
*even when* idebus= is correct would mean that the UDMA timing is in
1/(PCICLK*3) units instead of units of 10ns.

Anyone help us?

-- 
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: VT82C686A corruption with 2.4.x

[safemode]

Vojtech Pavlik wrote:

> On Thu, Feb 01, 2001 at 01:20:00PM -0500, Byron Stanoszek wrote:
>
> > > On Thu, Feb 01, 2001 at 11:46:08AM -0500, Byron Stanoszek wrote:
> > >
> > > > Yeah, by bios does the same thing too on the Abit KT7(a).
> > >
> > > Ok, I'll remember this. This is most likely the cause of the problems
> > > many people had with the KT7 in the past.
> >
> > What cause are you referring to? As far as I know, there are two options to
> > increasing the FSB clock.. one increases both FSB+PCICLK, the other just
> > increases FSB. If you increase the FSB only, it should keep PCICLK at a solid
> > 33. (But I could be wrong, I've never tested that. I can tomorrow though.)
>
> I mean that people can alter the PCI clock on these boards and that 33
> doesn't to be always exactly 33 due to rounding errors if used with a
> FSB other than 66 or 100 or 133.
>
> Could it be that the PCI bus is not asynchronous, but only
> pseudo-synchronous, allowing for divisors of 5, 4.5, 4, 3.5, 3, 2.5, 2?
>
> > > The U33 chips do UDMA timing in PCICLK (T = 30ns @ 33MHz) increments, U66 in
> > > PCICLK*2 (T = 15ns @ 33 MHz) increments, and for U100 it's assumed that
> > > there is an external 100MHz clock fed to the chip, so that the UDMA timing is
> > > in T = 10ns increments independent of the PCICLK. I'm not 100% sure about
> > > the last, it might be just PCICLK*3 (T = 10ns @ 33 MHz). An experiment needs
> > > to be carried out to verify this.
> >
> > I don't have a KT7A personally, I only have a KT7. Can anyone else with a KT7A
> > verify this? By verify, I take it you mean to use idebus=33 and overclock
> > PCICLK? :) At least that would determine if UDMA100 is based on PCI or an
> > external 100MHz source.
>
> Actually he should use the correct idebus= so that the Active/Recover
> timings are correct. If KT7A doesn't work with UDMA at high PCI clocks
> *even when* idebus= is correct would mean that the UDMA timing is in
> 1/(PCICLK*3) units instead of units of 10ns.
>
> Anyone help us?
>
> --
> Vojtech Pavlik
> SuSE Labs

I for one dont use the KT7 motherboards    but i know from experience that
increasing the FSB only effects ram speed ( at least negatively anyway)  i have
100Mhz ram and 133Mhz ram so once i'm at 114Mhz the 100Mhz ram cant handle too much
more ..   so 114Mhz is what i stay at.   My PCI clock is not changed at all and so
far (for the last couple days) the hdd's on my idebus have not had any problems what
so ever.   Sorry but i've only got UDMA66 drives and idebus is whatever the 2.2.x
kernel defaults to.    I'm guessing any sort of corruption caused by 2.4.x had
something to do with that dirty page writes mail that was sent to the list a while
ago and was probably fixed but never made it to the changelog.     I'll stick to 2.2
until 2.5 though just in case.    What would be interesting is figuring out why the
kernel can't recover somehow from infinite ide irq reset loops which are usually
brought on by dma timeouts.   That would at least somewhat usefull for when they
actually happen (I saw them numerous times in 2.4.x but not since going back to
2.2.x).


-
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: VT82C686A corruption with 2.4.x

[Alan Chandler]

On Thu, 1 Feb 2001 19:06:53 +0100, Vojtech Pavlik wrote:

>On Thu, Feb 01, 2001 at 11:46:08AM -0500, Byron Stanoszek wrote:
>
>> Yeah, by bios does the same thing too on the Abit KT7(a).
>
>Ok, I'll remember this. This is most likely the cause of the problems
>many people had with the KT7 in the past.
>
I've had (I now have 2.4.1 with dma off) the problems with a KT7,
although according to the BIOS its set to 100FSB/33PCI and the option
to tweak the clock further is set to zero

One further thought though - 1/3 of 100 is actually 33.3333Mhz.  What
if the flexibility in the motherboard is actually causing the bus to
be exactly 1/3 of 100

Interpolating according to Byron Stanoszek's table  for UDMA-33 (where
I have the problem) this could have a not insignificant effect on the
paramter given the chip.


Alan

alan@chandlerfamily.org.uk
http://www.chandler.u-net.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/