On 10/03/2003 04:52 PM, David Woodhouse wrote: > Also, can you reset the profile counts (readprofile -r) and get a > reading from the time when it's doing this alone, rather than including > everything from boot onwards. Here is the output of readprofile after reset and before nftld holds my cpu: 1 __generic_copy_to_user 0.0139 1 write_profile 0.0208 380 default_idle 9.5000 382 total 0.0003 Then I simply entered "ls /mnt/doc" (which is mounted at boot to /dev/nftla1), and got the following result (I skipped those with one occasion only): 2 __delay 0.0333 2 sock_poll 0.0500 2 unix_poll 0.0135 3 __const_udelay 0.0833 284 _DoC_WaitReady 2.8400 577 __rdtsc_delay 20.6071 1199 default_idle 29.9750 2084 total 0.0018 This is the output a few seconds later (also skipped some lines): 2 add_wait_queue 0.0500 2 __generic_copy_to_user 0.0278 2 sock_poll 0.0500 3 __delay 0.0500 3 unix_poll 0.0203 5 __const_udelay 0.1389 607 _DoC_WaitReady 6.0700 1199 default_idle 29.9750 1243 __rdtsc_delay 44.3929 3082 total 0.0026 So, __rdtsc_delay and _DoC_WaitReady seem to be the source of the problem. I hope these will help you investigate. I have attached the three outputs of readprofile for your reference. > If it does it only sometimes, is there any pattern to when it starts or > stops? Once it has started, it would never stop. Sometimes, after fsck on the doc, and remount, it becomes normal. But this time, I even tried booting using the doc and perform some operations (like 'find .') and rebooting back using my harddisk, and also tried booting using dos floppy and used dinfo without the problem, but when back to Linux the problem was still there. I think dformating in dos is my last resort. Selwyn