I have hard drives hda, hdb, hdc and cdrom hdd. hda/hdb are connected by 80-wired cable; hdc/hdd are connected by 40-wired cable. When i "boot: gentoo debug" from Gentoo LiveCD-i686 installer 2006.1 CD disk, I see that hda and hdb are noted as hda: ..., UDMA(100) hdb: ..., UDMA(100) /* here, '...' is some text that I omitted by can reproduce if you need */. This is ok. But also, I see hdc: ..., UDMA(100) This is not ok for 40-wired cable that cannot provide so high throughput. I expect UDMA(33) only. I suppose that's why I see a moment later a parcel of messages like: dma_intr: status=0x51 { DR, SC, E } dma_intr: error=0x84 { DSE, BadCRC } during initialization of hdc partitions (as far as I understood that). There is no such messages during initialization of hda/hdb. /* I made some abbreviations; shall type it whole at your request */ Note: ide=nodma kernel option solves this problem. Other systems (both gentoo booted from HDD and wihdows booted from HDD) handle hdc at a proper speed and experience no problems with hdc. The same problem is with another livecd that I have, 2005.1. The difference is that 2006.1 hangs after a while (and 2005.1 does not), but I suppose this is another bug and will file it as a separate bug a moment later. Reproducible: Always Steps to Reproduce: 1. use 40-wired ATA cable 2. attach fast (udma100-capable) HDD with this cable 3. boot gentoo liveCD-i686 installer 2006.1 CD also, use 'debug' kernel option to see udma mode. Actual Results: hdx: ... UDMA(100) Expected Results: hdx: ... UDMA(33)
*** Bug 171622 has been marked as a duplicate of this bug. ***
I am sorry. This is wrong: >> Other systems (both gentoo booted from HDD and wihdows booted from HDD) handle hdc at a proper speed and experience no problems with hdc. The correct is that Gentoo booted from HDD detects hdc as UDMA(100) as well (kernel 2.6.13-gentoo-r5) and there are same IDE errors. So, now I'm not even sure that this is a bug. (I suppose it can be if there is a way to know which IDE cable is used). I made a mistake because I looked at hdparm results instead of grepping dmesg. Sorry. I am not sure, shall I try to move this bug report to Gentoo Linux/Core system?
It's fine. I'm going to reassign this to the kernel team. Since you said the LiveCD 2006.1 exhibits this behavior, I'm going to assume that means 2.6.17 does it, which is what we used on that CD. You'll need to let the kernel team know what kernel version is on your installed system, and likely assist them in testing further kernels to find out if the problem is fixed in the latest kernels. Thanks for taking the time to troubleshoot this yourself, it really helps. =]
I use kernel 2.6.13-gentoo-r5. Some of hardware details are mentioned in Bug 171622.
Additional hardware details (hope they are useful): BIOS says: "Secondary IDE no 80-wired cable...." Linux says: # uname -a Linux *** 2.6.13-gentoo-r5 #22 Fri Mar 23 02:43:50 MSK 2007 i686 AMD Athlon(tm) XP 1700+ AuthenticAMD GNU/Linux # cat /proc/ide/via ----------VIA BusMastering IDE Configuration---------------- Driver Version: 3.38 South Bridge: VIA vt8233a Revision: ISA 0x0 IDE 0x6 Highest DMA rate: UDMA133 BM-DMA base: 0xdc00 PCI clock: 33.3MHz Master Read Cycle IRDY: 0ws Master Write Cycle IRDY: 0ws 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: yes yes Post Write Buffer: yes yes Enabled: yes yes Simplex only: no no Cable Type: 80w 80w -------------------drive0----drive1----drive2----drive3----- Transfer Mode: UDMA UDMA UDMA UDMA Address Setup: 120ns 120ns 120ns 120ns Cmd Active: 90ns 90ns 90ns 90ns Cmd Recovery: 30ns 30ns 30ns 30ns Data Active: 90ns 90ns 90ns 90ns Data Recovery: 30ns 30ns 30ns 30ns Cycle Time: 22ns 22ns 22ns 60ns Transfer Rate: 88.8MB/s 88.8MB/s 88.8MB/s 33.3MB/s note, I did not use hdc by this moment, so possible fallback to lower speed had not happen yet. Also, I tried to find more info of how it happens that it incorrectly detects 80-wired cable: # cd /usr/src/linux/drivers/ide/pci/ --- via82cxxx.c.BAK 2007-03-23 02:37:31.000000000 +0300 +++ via82cxxx.c 2007-03-23 02:43:25.000000000 +0300 @@ -467,6 +467,7 @@ case VIA_UDMA_100: pci_read_config_dword(dev, VIA_UDMA_TIMING, &u); + printk("case VIA_UDMA_100: u = 0x%x\n", (int)u); for (i = 24; i >= 0; i -= 8) if (((u >> i) & 0x10) || (((u >> i) & 0x20) && @@ -480,6 +481,7 @@ case VIA_UDMA_133: pci_read_config_dword(dev, VIA_UDMA_TIMING, &u); + printk("case VIA_UDMA_133: u = 0x%x\n", (int)u); for (i = 24; i >= 0; i -= 8) if (((u >> i) & 0x10) || (((u >> i) & 0x20) && # make && make install && reboot ... # dmesg |grep VIA_UDMA_ case VIA_UDMA_133: u = 0xf1f1f6f6 ...When I plug both primary and secondary 80-wired cables, I see: case VIA_UDMA_133: u = 0xf1f1f1f6 (remember, hdd is cdrom)
Please reproduce on the latest kernel, currently 2.6.20
gentoo-sources-2.6.20 is masked for x86. I've tried gentoo-sources-2.6.20-r3. System boots up, but keyboard does not work. `grep sectors /var/log/messages` for 2.6.20-r3 read like that: hda: 156312576 sectors (80032 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100) hdb: 390721968 sectors (200049 MB) w/8192KiB Cache, CHS=24321/255/63, UDMA(100) hdc: 488397168 sectors (250059 MB) w/8192KiB Cache, CHS=30401/255/63 This is no matter which cable (40-wired or 80-wired) is used for secondary IDE. (no dma even with 80-wired cable... I don't know why. But I am not sure if I have setup kernel properly; I used my 2.6.13 .config, then rewrote it with menuconfig) For comparison: my current (2.6.13) kernel reports (also no matter whether 40-wired or 80-wired cable is used): hda: 156312576 sectors (80032 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100) hdb: 390721968 sectors (200049 MB) w/8192KiB Cache, CHS=24321/255/63, UDMA(100) hdc: 488397168 sectors (250059 MB) w/8192KiB Cache, CHS=30401/255/63, UDMA(100) /* as for keyboard, it seems there is difference: input: AT Translated Set 2 keyboard as /class/input/input3 -- for 2.6.20 (doesn't work) input: AT Translated Set 2 keyboard on isa0060/serio0 -- for 2.6.13 (works) I didn't try to find what does it mean. */ If there is a need to see /proc/ide/via or add some printk or something like that, it is possible though not very quick due to that keyboard problem.
Addition to previous message: $ `grep hdd /var/log/messages` hdd: ATAPI 40X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33) ide1: BM-DMA at 0xdc08-0xdc0f, BIOS settings: hdc:DMA, hdd:DMA for both kernels and both cables.
I've managed to start 2.6.20 kernel with keyboard: the problem was that ps/2 keyboard did not work if I had USB mouse plugged and have configured CONFIG_USB_HID=y. 2.6.13 works well. back to IDE, the problem seems to remain for 2.6.20: # uname -a Linux *** 2.6.20-gentoo-r3 #1 PREEMPT Sat Mar 24 04:00:23 MSK 2007 i686 AMD Athlon(tm) XP 1700+ AuthenticAMD GNU/Linux # dmesg |grep hdc ide1: BM-DMA at 0xdc08-0xdc0f, BIOS settings: hdc:DMA, hdd:DMA hdc: SAMSUNG SP2514N, ATA DISK drive hdc: max request size: 512KiB hdc: 488397168 sectors (250059 MB) w/8192KiB Cache, CHS=30401/255/63 hdc: cache flushes supported hdc: hdc1 hdc2 < hdc5hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdc: dma_intr: error=0x84 { DriveStatusError BadCRC } hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdc: dma_intr: error=0x84 { DriveStatusError BadCRC } hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdc: dma_intr: error=0x84 { DriveStatusError BadCRC } hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdc: dma_intr: error=0x84 { DriveStatusError BadCRC } hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdc: dma_intr: error=0x84 { DriveStatusError BadCRC } hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdc: dma_intr: error=0x84 { DriveStatusError BadCRC } hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdc: dma_intr: error=0x84 { DriveStatusError BadCRC } hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdc: dma_intr: error=0x84 { DriveStatusError BadCRC } hdc6 hdc7 hdc8 hdc9 hdc10 > proc says for hdc (I see there is no more /proc/ide/via, but there is /proc/ide/hdx/*): /dev/hdc: multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) geometry = 30401/255/63, sectors = 250059350016, start = 0 (hmmm, dmesg did not write which DMA mode it is, but /proc reports dma is on) I guess I can trust 'hdc: dma_intr: ...' messages that let to know that wrong dma detection is still actual. For reference, I tried 80-wired hdc/hdd, there was no i/o errors. also, hdparm -tT says for 80-wired: /dev/hdc: Timing cached reads: 1060 MB in 2.00 seconds = 529.89 MB/sec Timing buffered disk reads: 204 MB in 3.00 seconds = 67.91 MB/sec and for 40-wired: /dev/hdc: Timing cached reads: 1008 MB in 2.00 seconds = 502.97 MB/sec Timing buffered disk reads: 116 MB in 3.04 seconds = 38.10 MB/sec I suppose it have lowered dma mode after 8 errors.
Any news here? Do you still have the same problem? If so, can you please test with the latest development kernel, 2.6.23-rc7 as of this writing. Please post your kernel .config and your dmesg output.
Created attachment 131618 [details] config-2.6.19
Created attachment 131619 [details] config-2.6.23
Created attachment 131621 [details] dmesg-2.6.19
Created attachment 131623 [details] dmesg-2.6.23
Created attachment 131624 [details] uname-2.6.19
Created attachment 131626 [details] uname-2.6.23
The problem seems to remain with 2.6.23-rc7; at least, messages "hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }" are still present in dmesg. Reboot with 40-wired ide1 cable and kernel from http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.23-rc7.tar.gz $ uname -a >uname-2.6.23 $ zcat /proc/config.gz >config-2.6.23 $ dmesg >dmesg-2.6.23 For reference: reboot with 40-wired cable and my current kernel (2.6.19) $ uname -a >uname-2.6.19 $ zcat /proc/config.gz >config-2.6.19 $ dmesg >dmesg-2.6.19 As for everyday use, I use 80-wired cable and all is ok ("dmesg |grep hdc" displays no problems).
I've been looking at your earlier results (with the printk) against the VIA specs, the specs are a little confusing though. The IDE drivers are slowly being replaced by experimental libata-based drivers. Do you think you could try the PATA_VIA driver and just confirm the problem also exists there? I think it will. Please also post lspci output.
Created attachment 131729 [details] lspci
Sorry, I have doubts if I can turn PATA_VIA driver on. I try 2.6.23-rc7 with ATA and PATA_VIA options on, but I get the same message "Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2" as I had without these options. So, I cannot confirm the problem in a driver, because I am don't know if it is used. $ zcat /proc/config.gz |grep VIA # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set CONFIG_BLK_DEV_VIA82CXXX=y # CONFIG_SATA_VIA is not set CONFIG_PATA_VIA=y # CONFIG_VIA_RHINE is not set # CONFIG_VIA_VELOCITY is not set CONFIG_HW_RANDOM_VIA=y CONFIG_AGP_VIA=y # CONFIG_SENSORS_VIA686A is not set # CONFIG_SND_VIA82XX is not set # CONFIG_SND_VIA82XX_MODEM is not set $ dmesg |egrep -i "VIA|IDE|ATA" [...skipped...] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller at PCI slot 0000:00:11.1 PCI: VIA VLink IRQ fixup for 0000:00:11.1, from 255 to 11 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt8233a (rev 00) IDE UDMA133 controller on pci0000:00:11.1 [...skipped...] The above is with 80-wired cable. Shall I proceed with this configuration and test 40-wired cable? Shall I turn CONFIG_IDE off / turn SCSI on / change something else and try again?
I disabled 'old' ATA driver and I see: scsi0 : pata_via scsi1 : pata_via ata1: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001dc00 irq 14 ata2: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001dc08 irq 15 and ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 ata2.00: BMDMA stat 0x64 ata2.00: cmd c8/00:08:6a:40:1d/00:00:00:00:00/e1 tag 0 cdb 0x12 data 4096 in res 51/84:00:71:40:1d/00:00:00:00:00/e1 Emask 0x10 (ATA bus error) ata2: soft resetting port ata2.00: configured for UDMA/100 ata2.01: configured for UDMA/66 ata2: EH complete complete config and dmesg will be attached as config-2.6.23-rc7-with-PATA and dmesg-2.6.23-rc7-with-PATA. I hope that is a confirmation of a problem.
Created attachment 131737 [details] config-2.6.23-rc7-with-PATA
Created attachment 131738 [details] dmesg-2.6.23-rc7-with-PATA
Thanks, sent a mail to linux-ide
Created attachment 131879 [details, diff] possible via cable detection fix
Please try the attached patch with the pata_via driver. If you could also add a printk into via_cable_detect() to print the value of ata66 after it is read that would be interesting.
This patch is already present in 2.6.23-rc7 that I tested above. Also, I've added the following: --- pata_via.c.orig 2007-09-25 23:26:37.000000000 +0400 +++ pata_via.c 2007-09-26 03:41:39.000000000 +0400 @@ -297,6 +297,9 @@ /* Get 80-wire cable detection bit */ pci_read_config_byte(pdev, 0x50 + offset, &cable80_status); + printk("XXX: udma_type %d cable80_status 0x%x: portno %d devno %d\n", + (int)udma_type, (int)cable80_status, + (int)(ap->port_no), (int)(adev->devno)); cable80_status &= 0x10; pci_write_config_byte(pdev, 0x50 + offset, ut | cable80_status); (I am not very sure that that is dma66 register. Let me know if I should print something else instead). The resulting dmesgs will be attached as dmesg80 (both cables are 80-wired) and dmesg40 (second is 40-wire).
Created attachment 131891 [details] dmesg40
Created attachment 131893 [details] dmesg80
Here is output of via_cable_detect(): @@ -180,6 +181,7 @@ return ATA_CBL_PATA_UNK; /* UDMA 100 or later */ pci_read_config_dword(pdev, 0x50, &ata66); + printk("via_cable_detect: ata66 = 0x%lx\n", (long)ata66); /* Check both the drive cable reporting bits, we might not have two drives */ if (ata66 & (0x10100000 >> (16 * ap->port_no))) 80-wired primary and 80-wired secondary: dmesg80-2:via_cable_detect: ata66 = 0xf1f1f1f2 dmesg80-2:via_cable_detect: ata66 = 0xf1f1f1f2 80-wired primary and 40-wired secondary: dmesg40-2:via_cable_detect: ata66 = 0xf1f1f6f6 dmesg40-2:via_cable_detect: ata66 = 0xf1f1f6f6
Thanks for all the testing. I never got any response to my mail upstream about this. Could you please file a bug against pata_via at http://bugzilla.kernel.org and post the new URL here? Don't worry about adding too many details, I'll add them once you have filed the bug.
Filed as http://bugzilla.kernel.org/show_bug.cgi?id=9168
