hello,
i've started to test the 2.6 series of kernels and observed a
strange thing: with moderate background load, the system clock
(i.e. time) seems to slow down to about 60% of normal speed
and the normally reliable ntp process (v4.2.0)
details: working interactively with a couple of background dummy
processes (*1), my system clock slowed down approx 90 mins over
a period of approx 4 hrs real time.
(*1) infinite loop: 1 rip, 1 encode -- both run at nice 10
the kernel logs show messages on the form:
localhost kernel: Losing too many ticks!
localhost kernel: TSC cannot be used as a timesource.
(Are you running with SpeedStep?)
localhost kernel: Falling back to a sane timesource.
localhost kernel: set_rtc_mmss: can't update from 5 to 58
without the background load, the system keeps perfect time.
==> any ideas of what could be going on would be appreciated.
hardware details
Intel P4 2.53gz on Supermicro P4SAA mobo (Intel 7205 chipset)
1gb memory; multiple drives; Promise Ultra/133 raid controller
software
kernel 2.6.1 w/APIC and PREEMPT options turned on.
Fedora Core 1 + selected development packages (verified on 2.4).
more info available on request.
regards,
--
Steinar Hauan, dept of ChemE -- [email protected]
Carnegie Mellon University, Pittsburgh PA, USA
On Tue, 2004-01-20 at 12:36, Steinar Hauan wrote:
> i've started to test the 2.6 series of kernels and observed a
> strange thing: with moderate background load, the system clock
> (i.e. time) seems to slow down to about 60% of normal speed
> and the normally reliable ntp process (v4.2.0)
>
> details: working interactively with a couple of background dummy
> processes (*1), my system clock slowed down approx 90 mins over
> a period of approx 4 hrs real time.
>
> (*1) infinite loop: 1 rip, 1 encode -- both run at nice 10
>
> the kernel logs show messages on the form:
>
> localhost kernel: Losing too many ticks!
> localhost kernel: TSC cannot be used as a timesource.
> (Are you running with SpeedStep?)
How quickly do you see this message? Does it happen right at boot time,
or during load?
> localhost kernel: Falling back to a sane timesource.
> localhost kernel: set_rtc_mmss: can't update from 5 to 58
>
> without the background load, the system keeps perfect time.
>
> ==> any ideas of what could be going on would be appreciated.
You seem to be losing lots of timer ticks. If this happens enough, the
system will fall back to the PIT thinking that your cpu frequency must
have changed w/o notification.
You might want to try the attached patch to see if we're overreacting
when we fall back to the PIT or if your system really is having trouble.
Basically I'm just disabling the lost tick compensation code, which
means if your system is really having issues, you'll still lose time.
> hardware details
> Intel P4 2.53gz on Supermicro P4SAA mobo (Intel 7205 chipset)
> 1gb memory; multiple drives; Promise Ultra/133 raid controller
> software
> kernel 2.6.1 w/APIC and PREEMPT options turned on.
Also, do you see the problem when preempt is disabled (without using the
attached patch?)
thanks
-john
===== arch/i386/kernel/timers/timer_tsc.c 1.35 vs edited =====
--- 1.35/arch/i386/kernel/timers/timer_tsc.c Wed Jan 7 00:31:11 2004
+++ edited/arch/i386/kernel/timers/timer_tsc.c Tue Jan 20 13:22:54 2004
@@ -226,7 +226,7 @@
delta += delay_at_last_interrupt;
lost = delta/(1000000/HZ);
delay = delta%(1000000/HZ);
- if (lost >= 2) {
+ if (0 && (lost >= 2)) {
jiffies_64 += lost-1;
/* sanity check to ensure we're not always losing ticks */
On Tue, 2004-01-20 at 16:26, john stultz wrote:
> On Tue, 2004-01-20 at 12:36, Steinar Hauan wrote:
> > i've started to test the 2.6 series of kernels and observed a
> > strange thing: with moderate background load, the system clock
> > (i.e. time) seems to slow down to about 60% of normal speed
> > and the normally reliable ntp process (v4.2.0)
omission in original post:
[...] ntp process "was running", but failed to update time.
> > the kernel logs show messages on the form:
> >
> > localhost kernel: Losing too many ticks!
> > localhost kernel: TSC cannot be used as a timesource.
> > (Are you running with SpeedStep?)
>
> How quickly do you see this message? Does it happen right at boot time,
> or during load?
boottime:
Jan 19 08:59:24 localhost kernel: Linux version 2.6.1
(root@offa) (gcc version 3.3.2 20031218
(Red Hat Linux 3.3.2-5)) #2
SMP Sat Jan 17 18:05:09 EST 2004
(yes, i have SMP enabled even for a single cpu machine; the kernel
will be run on a multitude of machines of which most are SMP)
log messages prior to time issues:
Jan 20 04:02:01 localhost anacron[6057]: Updated timestamp for
job `cron.daily' to
2004-01-20
Jan 20 04:05:38 localhost kernel: hdb: dma_timer_expiry:
dma status == 0x61
Jan 20 04:05:48 localhost kernel: hdb: DMA timeout error
Jan 20 04:05:48 localhost kernel: hdb: dma timeout error:
status=0xd0 {Busy }
Jan 20 04:05:48 localhost kernel: hda: DMA disabled
Jan 20 04:05:48 localhost kernel: hdb: DMA disabled
Jan 20 04:05:48 localhost kernel: ide0: reset: success
(hda and hdb are on the same controller; the only active disk at
this time should be hda ... hdb should be essentially idle
except for cron.daily scripts running around then)
timing error starts here; interactive work
Jan 20 07:52:40 localhost kernel: Losing too many ticks!
> You might want to try the attached patch to see if we're overreacting
[...]
> Also, do you see the problem when preempt is disabled
testing overnight failed to reproduce the problem. note that the
original event only occurred after about 12 hrs of testing.
i'll install lm_sensors & smarttools and run cpuburn for a while
to ensure this is not related to any hardware issues.
--> other suggestions also appreciated.
regards,
--
Steinar Hauan, dept of ChemE -- [email protected]
Carnegie Mellon University, Pittsburgh PA, USA
On Wed, 2004-01-21 at 07:06, Steinar Hauan wrote:
> On Tue, 2004-01-20 at 16:26, john stultz wrote:
> > How quickly do you see this message? Does it happen right at boot time,
> > or during load?
>
> boottime:
> Jan 19 08:59:24 localhost kernel: Linux version 2.6.1
> (root@offa) (gcc version 3.3.2 20031218
> (Red Hat Linux 3.3.2-5)) #2
> SMP Sat Jan 17 18:05:09 EST 2004
>
> (yes, i have SMP enabled even for a single cpu machine; the kernel
> will be run on a multitude of machines of which most are SMP)
>
> log messages prior to time issues:
>
> Jan 20 04:02:01 localhost anacron[6057]: Updated timestamp for
> job `cron.daily' to
> 2004-01-20
> Jan 20 04:05:38 localhost kernel: hdb: dma_timer_expiry:
> dma status == 0x61
> Jan 20 04:05:48 localhost kernel: hdb: DMA timeout error
> Jan 20 04:05:48 localhost kernel: hdb: dma timeout error:
> status=0xd0 {Busy }
> Jan 20 04:05:48 localhost kernel: hda: DMA disabled
> Jan 20 04:05:48 localhost kernel: hdb: DMA disabled
> Jan 20 04:05:48 localhost kernel: ide0: reset: success
>
> (hda and hdb are on the same controller; the only active disk at
> this time should be hda ... hdb should be essentially idle
> except for cron.daily scripts running around then)
>
> timing error starts here; interactive work
>
> Jan 20 07:52:40 localhost kernel: Losing too many ticks!
Hmm. It might be that IDE PIO mode on your system blocks interrupts for
too long.
> > You might want to try the attached patch to see if we're overreacting
> [...]
> > Also, do you see the problem when preempt is disabled
>
> testing overnight failed to reproduce the problem. note that the
> original event only occurred after about 12 hrs of testing.
Sorry, that was vague. Did you fail to reproduce the problem using the
patch or with preempt disabled?
> i'll install lm_sensors & smarttools and run cpuburn for a while
> to ensure this is not related to any hardware issues.
I doubt its its a hardware fault issue, but more likely some driver not
working properly with your hardware and blocking interrupts for too
long.
thanks
-john
hi john,
i think this sounds like the same issue that i've been seeing with 2.5/2.6
kernels for a while now. smp kernel on a dual PIII machine without preempt.
after running for a while the "losing ticks" shows up in dmesg, and the system
loses a lot of time. load seems to make it worse, so that just might be the
trigger.
i'll try that one-liner as well when i get a chance - you said that if the
system still loses time, that narrows it down to hardware, yes?
thanks...
timothy
On Wed, Jan 21, 2004 at 10:19:26AM -0800, john stultz wrote:
> On Wed, 2004-01-21 at 07:06, Steinar Hauan wrote:
> > On Tue, 2004-01-20 at 16:26, john stultz wrote:
> > > How quickly do you see this message? Does it happen right at boot time,
> > > or during load?
> >
> > boottime:
> > Jan 19 08:59:24 localhost kernel: Linux version 2.6.1
> > (root@offa) (gcc version 3.3.2 20031218
> > (Red Hat Linux 3.3.2-5)) #2
> > SMP Sat Jan 17 18:05:09 EST 2004
> >
> > (yes, i have SMP enabled even for a single cpu machine; the kernel
> > will be run on a multitude of machines of which most are SMP)
> >
> > log messages prior to time issues:
> >
> > Jan 20 04:02:01 localhost anacron[6057]: Updated timestamp for
> > job `cron.daily' to
> > 2004-01-20
> > Jan 20 04:05:38 localhost kernel: hdb: dma_timer_expiry:
> > dma status == 0x61
> > Jan 20 04:05:48 localhost kernel: hdb: DMA timeout error
> > Jan 20 04:05:48 localhost kernel: hdb: dma timeout error:
> > status=0xd0 {Busy }
> > Jan 20 04:05:48 localhost kernel: hda: DMA disabled
> > Jan 20 04:05:48 localhost kernel: hdb: DMA disabled
> > Jan 20 04:05:48 localhost kernel: ide0: reset: success
> >
> > (hda and hdb are on the same controller; the only active disk at
> > this time should be hda ... hdb should be essentially idle
> > except for cron.daily scripts running around then)
> >
> > timing error starts here; interactive work
> >
> > Jan 20 07:52:40 localhost kernel: Losing too many ticks!
>
> Hmm. It might be that IDE PIO mode on your system blocks interrupts for
> too long.
>
> > > You might want to try the attached patch to see if we're overreacting
> > [...]
> > > Also, do you see the problem when preempt is disabled
> >
> > testing overnight failed to reproduce the problem. note that the
> > original event only occurred after about 12 hrs of testing.
>
> Sorry, that was vague. Did you fail to reproduce the problem using the
> patch or with preempt disabled?
>
> > i'll install lm_sensors & smarttools and run cpuburn for a while
> > to ensure this is not related to any hardware issues.
>
> I doubt its its a hardware fault issue, but more likely some driver not
> working properly with your hardware and blocking interrupts for too
> long.
>
> thanks
> -john
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
well, it does *say* the following:
..... host bus clock speed is 133.0266 MHz.
checking TSC synchronization across 2 CPUs: passed.
Starting migration thread for cpu 0
is there a good way to check IDE PIO?
timothy
On Thu, Jan 22, 2004 at 11:42:35AM -0800, john stultz wrote:
> On Thu, 2004-01-22 at 11:37, timothy parkinson wrote:
> > hi john,
> >
> > i think this sounds like the same issue that i've been seeing with 2.5/2.6
> > kernels for a while now. smp kernel on a dual PIII machine without preempt.
> >
> > after running for a while the "losing ticks" shows up in dmesg, and the system
> > loses a lot of time. load seems to make it worse, so that just might be the
> > trigger.
> >
> > i'll try that one-liner as well when i get a chance - you said that if the
> > system still loses time, that narrows it down to hardware, yes?
>
> Well, not necessarily hardware, but it narrows it down to something
> blocking interrupts for way too long. IDE PIO for example seems to be a
> likely culprit. Another possibility on SMP systems is your cpu TSCs not
> being in sync.
>
> thanks
> -john
>
>
>
On Thu, 2004-01-22 at 11:50, timothy parkinson wrote:
> well, it does *say* the following:
>
> ..... host bus clock speed is 133.0266 MHz.
> checking TSC synchronization across 2 CPUs: passed.
> Starting migration thread for cpu 0
That looks fine then.
> is there a good way to check IDE PIO?
Run "/sbin/hdparm /dev/hdX" and look for "using_dma = 0".
thanks
-john
su -c "/usr/sbin/hdparm /dev/hda"
Password:
/dev/hda:
multcount = 16 (on)
IO_support = 1 (32-bit)
unmaskirq = 0 (off)
using_dma = 0 (off)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 65535/16/63, sectors = 156301488, start = 0
but...
su -c "/usr/sbin/hdparm -d1 /dev/hda"
Password:
/dev/hda:
setting using_dma to 1 (on)
HDIO_SET_DMA failed: Operation not permitted
using_dma = 0 (off)
it's an 80gig western digital from about 2-3 years ago.
On Thu, Jan 22, 2004 at 11:54:02AM -0800, john stultz wrote:
> On Thu, 2004-01-22 at 11:50, timothy parkinson wrote:
> > well, it does *say* the following:
> >
> > ..... host bus clock speed is 133.0266 MHz.
> > checking TSC synchronization across 2 CPUs: passed.
> > Starting migration thread for cpu 0
>
> That looks fine then.
>
> > is there a good way to check IDE PIO?
>
> Run "/sbin/hdparm /dev/hdX" and look for "using_dma = 0".
>
> thanks
> -john
>
>
>
>
>
>
On Thu, 2004-01-22 at 12:00, timothy parkinson wrote:
> su -c "/usr/sbin/hdparm /dev/hda"
> Password:
>
> /dev/hda:
> multcount = 16 (on)
> IO_support = 1 (32-bit)
> unmaskirq = 0 (off)
> using_dma = 0 (off)
> keepsettings = 0 (off)
> readonly = 0 (off)
> readahead = 256 (on)
> geometry = 65535/16/63, sectors = 156301488, start = 0
>
> but...
>
> su -c "/usr/sbin/hdparm -d1 /dev/hda"
> Password:
>
> /dev/hda:
> setting using_dma to 1 (on)
> HDIO_SET_DMA failed: Operation not permitted
> using_dma = 0 (off)
>
> it's an 80gig western digital from about 2-3 years ago.
Its likely you need to enable support in the kernel for your IDE
controller, or your DMA on your controller isn't supported.
thanks
-john
On Thu, 2004-01-22 at 11:37, timothy parkinson wrote:
> hi john,
>
> i think this sounds like the same issue that i've been seeing with 2.5/2.6
> kernels for a while now. smp kernel on a dual PIII machine without preempt.
>
> after running for a while the "losing ticks" shows up in dmesg, and the system
> loses a lot of time. load seems to make it worse, so that just might be the
> trigger.
>
> i'll try that one-liner as well when i get a chance - you said that if the
> system still loses time, that narrows it down to hardware, yes?
Well, not necessarily hardware, but it narrows it down to something
blocking interrupts for way too long. IDE PIO for example seems to be a
likely culprit. Another possibility on SMP systems is your cpu TSCs not
being in sync.
thanks
-john
On Thu, Jan 22, 2004 at 01:21:45PM -0800, john stultz wrote:
> On Thu, 2004-01-22 at 12:00, timothy parkinson wrote:
> > su -c "/usr/sbin/hdparm /dev/hda"
> > Password:
> >
> > /dev/hda:
> > multcount = 16 (on)
> > IO_support = 1 (32-bit)
> > unmaskirq = 0 (off)
> > using_dma = 0 (off)
> > keepsettings = 0 (off)
> > readonly = 0 (off)
> > readahead = 256 (on)
> > geometry = 65535/16/63, sectors = 156301488, start = 0
> >
> > but...
> >
> > su -c "/usr/sbin/hdparm -d1 /dev/hda"
> > Password:
> >
> > /dev/hda:
> > setting using_dma to 1 (on)
> > HDIO_SET_DMA failed: Operation not permitted
> > using_dma = 0 (off)
> >
> > it's an 80gig western digital from about 2-3 years ago.
>
> Its likely you need to enable support in the kernel for your IDE
> controller, or your DMA on your controller isn't supported.
>
> thanks
> -john
>
>
so, apparently the problem was that i just needed to enable dma... which meant
that i needed to set "CONFIG_BLK_DEV_VIA82CXXX=y" in my .config.
been running all night/morning with load - no "losing ticks" message or slowing
clock yet. thanks for pointing me in the right direction.
think we could improve that error message? i'd never have guessed that it was
hard disk related if you hadn't told me...
timothy
On Fri, 2004-01-23 at 11:02, timothy parkinson wrote:
> On Thu, Jan 22, 2004 at 01:21:45PM -0800, john stultz wrote:
> > Its likely you need to enable support in the kernel for your IDE
> > controller, or your DMA on your controller isn't supported.
>
> so, apparently the problem was that i just needed to enable dma... which meant
> that i needed to set "CONFIG_BLK_DEV_VIA82CXXX=y" in my .config.
>
> been running all night/morning with load - no "losing ticks" message or slowing
> clock yet. thanks for pointing me in the right direction.
>
> think we could improve that error message? i'd never have guessed that it was
> hard disk related if you hadn't told me...
Well, lost ticks can be caused by many things, but your point is valid,
the message could be a bit more elightening.
thanks
-john
On Fri, Jan 23, 2004 at 11:17:29AM -0800, john stultz wrote:
> On Fri, 2004-01-23 at 11:02, timothy parkinson wrote:
> > On Thu, Jan 22, 2004 at 01:21:45PM -0800, john stultz wrote:
> > > Its likely you need to enable support in the kernel for your IDE
> > > controller, or your DMA on your controller isn't supported.
> >
> > so, apparently the problem was that i just needed to enable dma... which meant
> > that i needed to set "CONFIG_BLK_DEV_VIA82CXXX=y" in my .config.
> >
> > been running all night/morning with load - no "losing ticks" message or slowing
> > clock yet. thanks for pointing me in the right direction.
> >
> > think we could improve that error message? i'd never have guessed that it was
> > hard disk related if you hadn't told me...
>
> Well, lost ticks can be caused by many things, but your point is valid,
> the message could be a bit more elightening.
>
> thanks
> -john
>
>
googling for this issue turns up quite a few questions about it - there's
already one possible answer in the source, couldn't hurt to stick in a few
more:
if (lost_count++ > 100) {
printk(KERN_WARNING "Losing too many ticks!\n");
printk(KERN_WARNING "TSC cannot be used as a timesource.\n"
"Are you running with SpeedStep?\n"
+ "Perhaps you should enable DMA using \"hdparm\"?\n"
+ "etc..........)\n");
printk(KERN_WARNING "Falling back to a sane timesource.\n");
clock_fallback();
}
not that you have to actually listen to me or anything... :-)
On Fri, 2004-01-23 at 11:36, timothy parkinson wrote:
> On Fri, Jan 23, 2004 at 11:17:29AM -0800, john stultz wrote:
> > Well, lost ticks can be caused by many things, but your point is valid,
> > the message could be a bit more elightening.
>
> googling for this issue turns up quite a few questions about it - there's
> already one possible answer in the source, couldn't hurt to stick in a few
> more:
>
>
> if (lost_count++ > 100) {
> printk(KERN_WARNING "Losing too many ticks!\n");
> printk(KERN_WARNING "TSC cannot be used as a timesource.\n"
> "Are you running with SpeedStep?\n"
> + "Perhaps you should enable DMA using \"hdparm\"?\n"
> + "etc..........)\n");
> printk(KERN_WARNING "Falling back to a sane timesource.\n");
> clock_fallback();
> }
>
> not that you have to actually listen to me or anything... :-)
Looks good by me. Would you mind sending such a patch to Andrew?
thanks
-john
On Fri, Jan 23, 2004 at 12:06:45PM -0800, john stultz wrote:
> On Fri, 2004-01-23 at 11:36, timothy parkinson wrote:
> > On Fri, Jan 23, 2004 at 11:17:29AM -0800, john stultz wrote:
> > > Well, lost ticks can be caused by many things, but your point is valid,
> > > the message could be a bit more elightening.
> >
> > googling for this issue turns up quite a few questions about it - there's
> > already one possible answer in the source, couldn't hurt to stick in a few
> > more:
> >
> >
> > if (lost_count++ > 100) {
> > printk(KERN_WARNING "Losing too many ticks!\n");
> > printk(KERN_WARNING "TSC cannot be used as a timesource.\n"
> > "Are you running with SpeedStep?\n"
> > + "Perhaps you should enable DMA using \"hdparm\"?\n"
> > + "etc..........)\n");
> > printk(KERN_WARNING "Falling back to a sane timesource.\n");
> > clock_fallback();
> > }
> >
> > not that you have to actually listen to me or anything... :-)
>
> Looks good by me. Would you mind sending such a patch to Andrew?
>
> thanks
> -john
>
no problem, i'll take it from here.
* Running with SpeedStep (this is a cpu thing i assume?) could cause this.
* Not having DMA enabled on your hard disk(s) could cause this. See the hdparm
utility to enable it.
* Incorrect TSC synchronization on SMP systems could cause this.
* Anything else?
thanks,
timothy
On Fri, 2004-01-23 at 12:38, timothy parkinson wrote:
> no problem, i'll take it from here.
>
> * Running with SpeedStep (this is a cpu thing i assume?) could cause this.
> * Not having DMA enabled on your hard disk(s) could cause this. See the hdparm
> utility to enable it.
> * Incorrect TSC synchronization on SMP systems could cause this.
> * Anything else?
Not that I can think of right off. Sounds good.
Thanks!
-john
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
timothy parkinson <[email protected]> wrote:
> * Running with SpeedStep (this is a cpu thing i assume?) could cause this.
> * Not having DMA enabled on your hard disk(s) could cause this. See the hdparm
> utility to enable it.
> * Incorrect TSC synchronization on SMP systems could cause this.
> * Anything else?
Yepp:
Jan 27 20:12:12 tatooine kernel: Losing too many ticks!
I had to set "CONFIG_IDE_TASK_IOCTL=y" in my .config in order to get
it working.
- --
Bastard Administrator in $hell
GPG-Key at http://lists.notified.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFAFthyLMyTO8Kj/uQRAojoAJ9ZIdhKEij8DW/QdkO1ZG9ksi1hqwCeMGQA
jjROcxpIDSJgirm931LKl0c=
=v37i
-----END PGP SIGNATURE-----
On Tuesday 27 of January 2004 22:30, markus reichelt wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> timothy parkinson <[email protected]> wrote:
> > * Running with SpeedStep (this is a cpu thing i assume?) could cause
> > this. * Not having DMA enabled on your hard disk(s) could cause this.
> > See the hdparm utility to enable it.
> > * Incorrect TSC synchronization on SMP systems could cause this.
> > * Anything else?
>
> Yepp:
>
> Jan 27 20:12:12 tatooine kernel: Losing too many ticks!
>
> I had to set "CONFIG_IDE_TASK_IOCTL=y" in my .config in order to get
> it working.
How's that possible?
This config option only exports HDIO_DRIVE_TASKFILE ioctl to user-space.
--bart
On Sat, Jan 31, 2004 at 12:32:23AM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Tuesday 27 of January 2004 22:30, markus reichelt wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > timothy parkinson <[email protected]> wrote:
> > > * Running with SpeedStep (this is a cpu thing i assume?) could cause
> > > this. * Not having DMA enabled on your hard disk(s) could cause this.
> > > See the hdparm utility to enable it.
> > > * Incorrect TSC synchronization on SMP systems could cause this.
> > > * Anything else?
> >
> > Yepp:
> >
> > Jan 27 20:12:12 tatooine kernel: Losing too many ticks!
> >
> > I had to set "CONFIG_IDE_TASK_IOCTL=y" in my .config in order to get
> > it working.
>
> How's that possible?
> This config option only exports HDIO_DRIVE_TASKFILE ioctl to user-space.
>
> --bart
>
without that, "hdparm -d1 /dev/hda" would claim that dma wasn't supported on my
harddrive.
i'm positive it's the only variable, i didn't change anything else!
timothy