Re: Promise PDC20265, VIA KT133 and corruption
Petr Vandrovec wrote: > > Hi Andre, > if you remember, last week I complained that Promise corrupts data > when I copy them from hdh to hde. Today I did some more experiments > (running 2.4.1-ac1) and found: > > 1) Debian sid's 'cmp' prints incorrect offsets when files differ >in more than one place if distance > cmp buffer size :-( > 2) When I read data from hdh (UDMA2 Toshiba) sometime last four >bytes of 4KB page (== probably last 4 bytes of read request) >are not read at all and old contents of page is left here >(it happens about once per 20MB read; and in about 1% of >these last 8 bytes of page are incorrect). >I have no idea whether promise or KT133 is at fault, but >it for sure does not happen under Windows... > 3) During write some corruption can happen on either hde (IBM >DTLA-307045 running UDMA5) or hdh - it looks like that >data are shifted on HDD, as fsck then complains about >imagic set, dtime set while inode not deleted and so on, >and then it cleaned inodes 178200-178300 from my hde :-( >Fortunately they were mostly in old kernel trees, >not in current data (except one inode, which was just >created by dpkg) > 4) So I compiled kernel without IDE DMA support at all and now >everything works at PIO4 without any corruption... > > If anybody has any idea what I should try to get UDMA to > work under Linux here... > > lspci: > > 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02) > 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] > 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22) > 00:04.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10) > 00:04.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) > 00:04.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) > 00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) > 00:0a.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 06) > 00:11.0 Unknown mass storage controller: Promise Technology, Inc. 20265 (rev 02) > 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 04) > > Thanks, > Petr Vandrovec > [EMAIL PROTECTED] I've got a very similar setup, but i've got a SCSI hard drive as well. In copying a rather large file (600+ MB) from my home directory (on the SCSI drive) to my IDE drive (on the promise controller, ata/100). scsi drive is ext2, the ide drive is vfat (basically to share movies and music w/ windoze). First try at copying, I got corruption. Second try, cp segfaulted. Looked, and sure enough, had an oops sitting for me in syslog, so here it is: ksymoops 2.3.7 on i686 2.4.1-ac2. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.1-ac2/ (default) -m /boot/System.map-2.4.1-ac2 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Feb 3 23:38:01 patience kernel: Unable to handle kernel paging request at virtual address 81180b00 Feb 3 23:38:01 patience kernel: c0123a60 Feb 3 23:38:01 patience kernel: *pde = Feb 3 23:38:01 patience kernel: Oops: 0002 Feb 3 23:38:01 patience kernel: CPU:0 Feb 3 23:38:01 patience kernel: EIP: 0010:[__remove_inode_page+48/96] Feb 3 23:38:01 patience kernel: EFLAGS: 00010202 Feb 3 23:38:01 patience kernel: eax: c102b228 ebx: c1202058 ecx: 0106 edx: 81180b00 Feb 3 23:38:01 patience kernel: esi: c532a828 edi: c1202058 ebp: 1532 esp: cc8c5eac Feb 3 23:38:01 patience kernel: ds: 0018 es: 0018 ss: 0018 Feb 3 23:38:01 patience kernel: Process cp (pid: 483, stackpage=cc8c5000) Feb 3 23:38:01 patience kernel: Stack: c1202074 c012a476 c1202058 c0309758 c0309930 0002 c012bc18 Feb 3 23:38:01 patience kernel:c0309758 c0309938 c012bd80 c030992c Feb 3 23:38:01 patience kernel:0002 0001 cc8c5f58 15ece000 0005 0001 Feb 3 23:38:01 patience kernel: Call Trace: [reclaim_page+790/1024] [__alloc_pages_limit+120/176] [__alloc_pages+304/736] [generic_file_write+724/1408] [] [default_fat_file_write+34/80] Feb 3 23:38:01 patience kernel: Code: 89 02 8b 43 10 8b 53 34 c7 43 08 00 00 00 00 85 c0 74 03 89 Using defaults from ksymoops -t elf32-i386 -a i386 Code; Before first symbol <_EIP>: Code; Before first symbol 0: 89 02
Re: Promise PDC20265, VIA KT133 and corruption
Petr Vandrovec wrote: Hi Andre, if you remember, last week I complained that Promise corrupts data when I copy them from hdh to hde. Today I did some more experiments (running 2.4.1-ac1) and found: 1) Debian sid's 'cmp' prints incorrect offsets when files differ in more than one place if distance cmp buffer size :-( 2) When I read data from hdh (UDMA2 Toshiba) sometime last four bytes of 4KB page (== probably last 4 bytes of read request) are not read at all and old contents of page is left here (it happens about once per 20MB read; and in about 1% of these last 8 bytes of page are incorrect). I have no idea whether promise or KT133 is at fault, but it for sure does not happen under Windows... 3) During write some corruption can happen on either hde (IBM DTLA-307045 running UDMA5) or hdh - it looks like that data are shifted on HDD, as fsck then complains about imagic set, dtime set while inode not deleted and so on, and then it cleaned inodes 178200-178300 from my hde :-( Fortunately they were mostly in old kernel trees, not in current data (except one inode, which was just created by dpkg) 4) So I compiled kernel without IDE DMA support at all and now everything works at PIO4 without any corruption... If anybody has any idea what I should try to get UDMA to work under Linux here... lspci: 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22) 00:04.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10) 00:04.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) 00:04.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) 00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) 00:0a.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 06) 00:11.0 Unknown mass storage controller: Promise Technology, Inc. 20265 (rev 02) 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 04) Thanks, Petr Vandrovec [EMAIL PROTECTED] I've got a very similar setup, but i've got a SCSI hard drive as well. In copying a rather large file (600+ MB) from my home directory (on the SCSI drive) to my IDE drive (on the promise controller, ata/100). scsi drive is ext2, the ide drive is vfat (basically to share movies and music w/ windoze). First try at copying, I got corruption. Second try, cp segfaulted. Looked, and sure enough, had an oops sitting for me in syslog, so here it is: ksymoops 2.3.7 on i686 2.4.1-ac2. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.1-ac2/ (default) -m /boot/System.map-2.4.1-ac2 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Feb 3 23:38:01 patience kernel: Unable to handle kernel paging request at virtual address 81180b00 Feb 3 23:38:01 patience kernel: c0123a60 Feb 3 23:38:01 patience kernel: *pde = Feb 3 23:38:01 patience kernel: Oops: 0002 Feb 3 23:38:01 patience kernel: CPU:0 Feb 3 23:38:01 patience kernel: EIP: 0010:[__remove_inode_page+48/96] Feb 3 23:38:01 patience kernel: EFLAGS: 00010202 Feb 3 23:38:01 patience kernel: eax: c102b228 ebx: c1202058 ecx: 0106 edx: 81180b00 Feb 3 23:38:01 patience kernel: esi: c532a828 edi: c1202058 ebp: 1532 esp: cc8c5eac Feb 3 23:38:01 patience kernel: ds: 0018 es: 0018 ss: 0018 Feb 3 23:38:01 patience kernel: Process cp (pid: 483, stackpage=cc8c5000) Feb 3 23:38:01 patience kernel: Stack: c1202074 c012a476 c1202058 c0309758 c0309930 0002 c012bc18 Feb 3 23:38:01 patience kernel:c0309758 c0309938 c012bd80 c030992c Feb 3 23:38:01 patience kernel:0002 0001 cc8c5f58 15ece000 0005 0001 Feb 3 23:38:01 patience kernel: Call Trace: [reclaim_page+790/1024] [__alloc_pages_limit+120/176] [__alloc_pages+304/736] [generic_file_write+724/1408] [d201] [default_fat_file_write+34/80] Feb 3 23:38:01 patience kernel: Code: 89 02 8b 43 10 8b 53 34 c7 43 08 00 00 00 00 85 c0 74 03 89 Using defaults from ksymoops -t elf32-i386 -a i386 Code; Before first symbol _EIP: Code; Before first symbol 0: 89 02 mov%eax,(%edx) Code; 0002
