On 2009?01?07? 12:14, James Carlson wrote: > I'm trying to debug a problem I'm seeing in RBridges, and I'm not > quite sure where to turn. Suggestions welcome. > > The problem is that when my link-add function (which runs in a > separate task) calls mac_open_by_linkid(), that call sometimes takes > 15 seconds or more to run on some platforms. This seems abnormal to > me, but I guess I'm not sure whether I should consider it a bug. > (That's likely question #1.) > > What happens is that mac_open_by_linkid() calls > dls_devnet_prop_task_wait(), and it sits there for 15 seconds stuck in > a cv_wait. Clearly, since it's cv_wait, I'd be hosed even if I could > handle signals here. (I currently can't, but that could be fixable.) > > I've tried tracing dls_devnet_prop_task() itself, and I see it taking > about 15 seconds to run, and all of that time spent in a single call > to door_ki_upcall_limited(). > I don't know the answer to your question. But this upcall would reinitialize the link property of the given link. So it should take the same amount of time as if you run "dladm init-linkprop bge1". Can you try that when you keep bge1 unplumb and see how that takes?
Then you can probably try to initialize each link property and see which one really take that much time. Thanks - Cathy > That's where things get fuzzy. I've tried dtracing and trussing > dlmgmtd, and I don't see it wasting any time at all, so I don't know > where that 15 seconds is going. > > Does this ring any bells for anyone? Could it be devfs again? (I've > seen really long delays on some systems in touching anything in /dev, > and these delays appear to be related to the devfsadmd song and dance > routine.) > > Some possibly-helpful details: I've seen this effect only on x86 > systems -- whitestar2-5.east, which is a blade system with two 'bge' > interfaces. It happens only on bge1, which is not plumbed up by > default. > > I plan to work around it by making it so that I hang forever waiting > for this to finish, though that doesn't seem like the best possible > solution. > _______________________________________________ networking-discuss mailing list [email protected]
