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
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
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
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]
[ 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.
[ 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?
Still dma problems for 2.6.20-rc5
Any updates with this problem? Have you tried newest kernel? Thanks.
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".
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.
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?
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
Martin, could you try 2.6.25-rc2?
Martin - ping... Can you please re-test with latest kernel?
I'm closing this bug, please re-open if it still happens with recent kernels.
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!