DMA timeouts on SIS IDE
Hi,
the lspci output you previously sent confirmed that the SiS IDE driver does set the UDMA timings correctly. Given this is out of the suspects list, I'd advise to :
- test the hardware (uneasy on a notebook, 2.5" IDE drives aren't as common as 3.5" ones)
- try latest ACPI on sourceforge and enable ACPI in the BIOS if not already done (seems to have helped once : http://marc.theaimsgroup.com/?l=linux-kernel&m=104212864518052&w=4)
LB.
Quoted 6 lines · Lionel Bouton
the lspci output you previously sent confirmed that the SiS IDE driver does set the UDMA timings correctly. Given this is out of the suspects list, I'd advise to :
- test the hardware (uneasy on a notebook, 2.5" IDE drives aren't as common as 3.5" ones)
As you say, testing could be tricky. However, the machine is only about one month old, so it shouldn't be dying already.
Quoted 3 lines
- try latest ACPI on sourceforge and enable ACPI in the BIOS if not already done (seems to have helped once :
http://marc.theaimsgroup.com/?l=linux-kernel&m=104212864518052&w=4)
patch tells me those are already applied to 2.6.0-test2. I tried booting with pci=noacpi, just in case, but the problem remains. I can't find any BIOS settings relating to ACPI.
Signature · 2 lines
Måns Rullgård [email protected]
Quoted 10 lines · [email protected] (Måns Rullgård) writes:
Quoted 6 lines
the lspci output you previously sent confirmed that the SiS IDE driver does set the UDMA timings correctly. Given this is out of the suspects list, I'd advise to :
- test the hardware (uneasy on a notebook, 2.5" IDE drives aren't as common as 3.5" ones)
As you say, testing could be tricky. However, the machine is only about one month old, so it shouldn't be dying already.
Quoted 7 lines
Quoted 3 lines
- try latest ACPI on sourceforge and enable ACPI in the BIOS if not already done (seems to have helped once :
http://marc.theaimsgroup.com/?l=linux-kernel&m=104212864518052&w=4)patch tells me those are already applied to 2.6.0-test2. I tried booting with pci=noacpi, just in case, but the problem remains. I can't find any BIOS settings relating to ACPI.
The issue is still unresolved.
I noticed that sometimes I also get this in the kernel log:
hda: dma_timer_expiry: dma status == 0x21
hda: DMA timeout error
hda: dma timeout error: status=0xd0 { Busy }
hda: DMA disabled
ide0: reset: success
Loosing too many ticks!
TSC cannot be used as a timesource. (Are you running with SpeedStep?) Falling back to a sane timesource.
I am not using SpeedStep, so that message must be triggered by the IDE errors. The errors only happen when writing very large (hundreds of megabytes) amounts of data at rate above a few megabytes per second. It's never happened when just doing normal things like compiling stuff.
Signature · 2 lines
Måns Rullgård [email protected]
Quoted 11 lines · [email protected] (Måns Rullgård) writes:
I noticed that sometimes I also get this in the kernel log:
hda:
dma_timer_expiry: dma status ==0x21
hda: DMA timeout error
hda: dma timeout error: status=0xd0 { Busy }hda: DMA disabled
ide0: reset: success
Loosing too many ticks!
TSC cannot be used as a timesource. (Are you running with SpeedStep?) Falling back to a sane timesource.
This appears to have been fixed in 2.6.0-test4.
Signature · 2 lines
Måns Rullgård [email protected]
Quoted 6 lines · [email protected] (Måns Rullgård) writes:
Quoted 6 lines
I noticed that sometimes I also get this in the kernel log:
hda:
dma_timer_expiry: dma status ==0x21
hda: DMA timeout error
hda: dma timeout error: status=0xd0 { Busy }
Quoted 7 lines
Quoted 5 lines
hda: DMA disabled
ide0: reset: success
Loosing too many ticks!
TSC cannot be used as a timesource. (Are you running with SpeedStep?) Falling back to a sane timesource.This appears to have been fixed in 2.6.0-test4.
I'm afraid I was wrong. It happened again.
Signature · 2 lines
Måns Rullgård [email protected]