Re: IDE + CPU Scaling problem on Via EPIA systems

[Dave Jones]

On Mon, Nov 28, 2005 at 12:02:32AM -0500, gboyce wrote:
 > Folks,
 > 
 > While attempting to setup a new server using a Via EPIA-M motherboard 
 > (Nehemiah processor), I encountered a problem when I enabled CPU Frequency 
 > scaling via the powernowd daemon.
 > 
 > The system is using software RAID 1 on a pair of IDE drives.  Everything 
 > goes fine until powernowd is enabled.  At that point I get the following 
 > errors:
 > 
 > [4294871.703000] hda: dma_timer_expiry: dma status == 0x20
 > [4294871.703000] hda: DMA timeout retry
 > [4294871.703000] hda: timeout waiting for DMA
 > [4294871.703000] hda: status error: status=0x58 { DriveReady SeekComplete 
 > DataRequest }
 > [4294871.703000]
 > [4294871.703000] ide: failed opcode was: unknown
 > [4294871.703000] hda: drive not ready for command
 > [4294958.589000] hda: dma_timer_expiry: dma status == 0x20
 > [4294958.589000] hda: DMA timeout retry
 > [4294958.589000] hda: timeout waiting for DMA
 > [4294958.589000] hda: status error: status=0x58 { DriveReady SeekComplete 
 > DataRequest }
 > [4294958.589000]
 > [4294958.589000] ide: failed opcode was: unknown
 > [4294958.589000] hda: drive not ready for command
 > 
 > I ran the system for an extended time previously with no problem, but at 
 > this point I did not use powernowd, and I was not using RAID.
 > 
 > The system is running Ubuntu, but I also encountered someone else with the 
 > same problem on an older Via EPIA system and SuSE.  The ubuntu kernel I'm 
 > using is 2.6.12-10-386.
 > 
 > I've attached the full dmesg output as well.
 > 
 > For now I'm just going to turn off cpu scaling.  Someday I'd like to use 
 > it though.  Any suggestions for things I can try?  Or is this perhaps a 
 > known issue of some sort?

On some variants of the VIA C3, we need to quiesce all DMA operations
before we do a speed transition. We currently don't do that.
I do have a patch from someone which adds support in the longhaul
driver to wait for IDE transactions to stop, but to do it cleanly,
we really need some callbacks into the IDE layer.

The longhaul driver right now is pretty much a case of
"if it works for you great, if not, don't use it".

		Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/