Bug 7506

Summary: it821x: long wait time due to dma_timer_expiry
Product: IO/Storage Reporter: Martin von Gagern (Martin.vGagern)
Component: IDEAssignee: Bartlomiej Zolnierkiewicz (bzolnier)
Status: REJECTED INSUFFICIENT_DATA    
Severity: normal CC: alan, kernel, protasnb
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.19-rc3 - 2.6.23-rc2 Subsystem:
Regression: --- Bisected commit-id:
Attachments: dmesg of 2.6.19-rc3 for boot and modprobe it821x noraid=1
dmesg of 2.6.22 for boot and modprobe it821x noraid=1
console log of 2.6.23-rc2 for insmod it821x.ko noraid=1

Description Martin von Gagern 2006-11-12 23:38:39 UTC
Most recent kernel where this bug did not occur: unknown
Distribution: Gentoo (with sys-kernel/vanilla-sources-2.6.19_rc3)
Hardware Environment: ASUS P5GDC-V MB
                      root FS on SATA HDD
                      IT8212 onboard in IDE (not RAID) mode
                      2 x FUJITSU MPG3409AT E as masters for this
Software Environment: Grub, Bash

Problem Description:
1. modprobe it821x takes thirty seconds.
2. dmesg notes dma_timer_expiry
3. hdparm has using_dma = 0 for one drive afterwards, 1 for the other

Steps to reproduce:
1. boot with "init=/bin/bash"
2. mount / -o remount,rw
3. modprobe it821x noraid=1
4. wait half a minute for modprobe to return
5. note dmesg output
Comment 1 Martin von Gagern 2006-11-12 23:40:44 UTC
Created attachment 9480 [details]
dmesg of 2.6.19-rc3 for boot and modprobe it821x noraid=1

The most interesting part in my opinion is this:

[   38.176438] hdc: cache flushes not supported
[   38.186746]	hdc:<4>hdc: dma_timer_expiry: dma status == 0x61
[   68.181673] hdc: DMA timeout error
[   68.191251] hdc: dma timeout error: status=0x58 { DriveReady SeekComplete
Dat
aRequest }
[   68.212116] ide: failed opcode was: unknown
Comment 2 Martin von Gagern 2006-11-12 23:51:38 UTC
Relations to other bug reports:
bug #7507 describes my even worse results with the new pata_it821x
Original Gentoo bug report is http://bugs.gentoo.org/152779
Comment 3 Martin von Gagern 2006-11-12 23:59:40 UTC
This lspci here was done with 2.6.18-gentoo-r1 patched kernel sources,
but I would not expect a difference there.

# lspci -vvs 1f.1
00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)
IDE Controller (rev 03) (prog-if 8a [Master SecP PriP])
        Subsystem: ASUSTeK Computer Inc. P5GD1-VW Mainboard
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 18
        Region 0: I/O ports at <unassigned>
        Region 1: I/O ports at <unassigned>
        Region 2: I/O ports at <unassigned>
        Region 3: I/O ports at <unassigned>
        Region 4: I/O ports at ffa0 [size=16]
Comment 4 Bartlomiej Zolnierkiewicz 2006-12-16 15:16:46 UTC
[    1.184882] ICH6: not 100% native mode: will probe irqs later
[    1.196845]     ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:DMA
[    1.216950] Probing IDE interface ide0...
[    1.888970] hda: Pioneer DVD-ROM ATAPIModel DVD-106S 012, ATAPI CD/DVD-ROM drive
[    2.624557] hdb: PLEXTOR CD-R PX-W2410A, ATAPI CD/DVD-ROM drive
[    2.689575] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
[    2.701565] Probing IDE interface ide1...

...

[   37.428236] IT8212: IDE controller at PCI slot 0000:01:04.0
[   37.440017] ACPI: PCI Interrupt 0000:01:04.0[A] -> GSI 23 (level, low) -> IRQ 20
[   37.459086] IT8212: chipset revision 19
[   37.468663] it8212: forcing bypass mode.
[   37.478337] it821x: controller in pass through mode.
[   37.489019] IT8212: 100% native mode on irq 20
[   37.499117]     ide1: BM-DMA at 0xbc00-0xbc07, BIOS settings: hdc:pio, hdd:pio
[   37.517589]     ide2: BM-DMA at 0xbc08-0xbc0f, BIOS settings: hde:pio, hdf:pio
[   37.536456] Probing IDE interface ide1...
[   37.800907] hdc: FUJITSU MPG3409AT E, ATA DISK drive
[   38.066758] hdd: FUJITSU MPG3409AT E, ATA DISK drive

It could be (this is pure guess) that there are "interesting" interactions
between piix and it821x drivers as ide_hwif_t data structure for ide1 is first
filled by piix and then reused by it821x.

Martin, could you please try disabling piix and ide_generic host drivers
in your kernel config, rebuild and retry?  it821x should than own ide0 and ide1.
[ CONFIG_BLK_DEV_PIIX=n and CONFIG_IDE_GENERIC=n ]

Thanks.
Comment 5 Martin von Gagern 2006-12-18 11:30:11 UTC
[ CONFIG_BLK_DEV_PIIX=n and CONFIG_IDE_GENERIC=n ]

I built them as modules, used init=bash to make sure no modules were loaded, but
still got the same result when loading it821x.

I still have CONFIG_ATA_PIIX=y, and getting rid of that would be a harder
problem as my root FS is on that SATA disk. Should I try make that effort?
Comment 6 Martin von Gagern 2007-01-22 16:54:34 UTC
Still dma problems for 2.6.20-rc5
Comment 7 Natalie Protasevich 2007-07-08 13:15:37 UTC
Any updates with this problem? Have you tried newest kernel?
Thanks.
Comment 8 Martin von Gagern 2007-07-09 05:56:44 UTC
Created attachment 11977 [details]
dmesg of 2.6.22 for boot and modprobe it821x noraid=1

(In reply to comment #7)
> Any updates with this problem? Have you tried newest kernel?

Just tried 2.6.22, problem still exists. Attaching a dmesg.
Timestamps 95.569237 through 126.551877 are printed to console directly after the call to "modprobe it821x noraid=1".
Comment 9 Martin von Gagern 2007-08-09 04:39:41 UTC
Created attachment 12331 [details]
console log of 2.6.23-rc2 for insmod it821x.ko noraid=1

Still got this error. However, this time I've got a warning message from kernel/irq/resend.c:70 check_irq_resend() as well. Maybe that will help.

There are some changes in my setup for this run. The kernel is pretty much a "make defconfig". I configured an initramfs containing a busybox, so I could make my PIIX drivers modules and run these tests without loading them.
Comment 10 Martin von Gagern 2007-09-04 11:32:13 UTC
I did some more experiments on this one here as well. The repartitioning mentioned in bug 7507 comment 9 didn't help here either. I found out that I could enable DMA using hdparm, but when I tried to access the drives, I got timeouts mentioned in dmesg, and the using_dma flag got reset again.
When I tried to create a new file system on one of the drives, my system would freeze for the larger part of every second or so. A currently active media player only gave me short bursts of sound with long silence in between. Eventually my watchdog software decided, not completely unjustified, that the system could use a reboot. Could it be simple DMA-less I/O blocking my system that badly, or is this an indication of something else going wrong?
Comment 11 Alan 2007-09-10 08:53:56 UTC
Moving this over to Bart as the old IDE layer maintainer.

DMA-less I/O cancertainly make your machine chug badly but there isn't anything that should cause problems with DMA on an IT821x except CD drives on old chips which isn't what you have
Comment 12 Bartlomiej Zolnierkiewicz 2008-02-16 10:45:29 UTC
Martin, could you try 2.6.25-rc2?
Comment 13 Natalie Protasevich 2008-04-05 02:18:03 UTC
Martin - ping... Can you please re-test with latest kernel?
Comment 14 Bartlomiej Zolnierkiewicz 2008-06-18 15:53:40 UTC
I'm closing this bug, please re-open if it still happens with recent kernels.
Comment 15 Martin von Gagern 2008-06-20 11:35:17 UTC
Sorry, this got lost in my backlog. Don't have these drives in my case any more, but connected them in order to test this, one at a time. Result: one drive still failed, while the other worked. So it might have been a hardware issue all along.

Sorry for not trying out single drives before; as both drives had worked in a previous system, I had assumed them functional, but perhaps the same cause that broke this previous system broke one of the drives as well, whatever cause that might have been. Sorry again!