OpenSolaris

Printable Version Enter a New Search
Bug ID 5079015
Synopsis A combination of ISTALE and IMOD/ICHG/IATTCHG can lead ufs to loop forever
State 10-Fix Delivered (Fix available in build)
Category:Subcategory kernel:ufs
Keywords IATTCHG | ICHG | IMOD | ISTALE | infinite | loop | performance | rtiq_reviewed | ufs | ufs-cleanup | ufs_idle_some | ufs_rmidle | ufs_thread_idle
Responsible Engineer Wolfgang Schremser
Reported Against solaris_9 , solaris_10
Duplicate Of
Introduced In solaris_2.0
Commit to Fix snv_99
Fixed In snv_99
Release Fixed solaris_nevada(snv_99)
Related Bugs 6344135 , 6477168 , 4507281
Submit Date 27-July-2004
Last Update Date 24-September-2008
Description
Here is the description about the weird symptom which occurred on one of our SunRay servers in Shanghai : 

"As I recall, we had an mpstat running for more than an hour and the results were the same, CPU 1 was always pegged at 100% sys time. We also ran prstat a couple of times and there was nothing of interest using CPU time (most processes in the top 10 were reporting 0.1% or lower). It was the results of mpstat and prstat that caught our attention since it looked like there was no load on the system but we had a CPU running 100% in the kernel. This combined with long delays in NFS client response (in minutes) and local file response time on the NFS server, led us to believe that we had a problem. With Kishore's help over the phone, we used MDB to determine that CPU 1 was spending most of it's time in UFS."

The thread was running on that cpu in the following stack trace:

ufs_rmidle+0x30(30018b55b98, 2a1000ddd44, 22, 1, 2a1000ddd44, 2a1000ddd3c)
ufs_idle_some+0x164(14a2c00, 14a2c00, 30018b55b98, 30018b55c38, 30018b55cf8, 0)
ufs_thread_idle+0x1b4(0, 0, 1438518, 1438518, 144e1e2, 0)
thread_start+4(0, 0, 0, 0, 0, 0)
Work Around
N/A
Comments
N/A