9-STABLE -> NFS -> NetAPP:

[Rick Macklem]

Marc Fournier wrote:
> On 2013-02-13, at 3:54 PM, Rick Macklem <rmacklem at uoguelph.ca> wrote:
> 
> >>
> > The pid that is in "T" state for the "ps auxlH".
> 
> Different server, last kernel update on Jan 22nd, https process this
> time instead of du last time.
> 
> I've attached:
> 
> ps auxlH
> ps auxlH of just the processes that are in TJ state (6 httpd servers)
> procstat output for each of the 6 process
> 
> 
> 
> 
> They are included as attachments … if these don't make it through, let
> me know, just figured I'd try and keep it compact ...
Well, I've looked at this call path a little closer:
16693 104135 httpd            -                mi_switch+0x186 thread_suspend_check+0x19f sleepq_catch_signals+0x1c5
  sleepq_timedwait_sig+0x19 _sleep+0x2ca clnt_vc_call+0x763 clnt_reconnect_call+0xfb newnfs_request+0xadb
  nfscl_request+0x72 nfsrpc_accessrpc+0x1df nfs34_access_otw+0x56 nfs_access+0x306 vn_open_cred+0x5a8
  kern_openat+0x20a amd64_syscall+0x540 Xfast_syscall+0xf7 

I am probably way off, since I am not familiar with this stuff, but it
seems to me that thread_suspend_check() should just return 0 for the
case where stop_allowed == SIG_STOP_NOT_ALLOWED (TDF_SBDRY flag set)
instead of sitting in the loop and doing a mi_switch(). I'm not even
sure if it should call thread_suspend_check() for this case, but there
are cases in thread_suspend_check() that I don't understand.

Although I don't really understand thread_suspend_check(), I've attached
a simple patch that might be a starting point for fixing this?

I wouldn't recommend trying the patch until kib and/or jhb weigh in
on whether it makes any sense.

rick


-------------- next part --------------
A non-text attachment was scrubbed...
Name: sigstop.patch
Type: text/x-patch
Size: 2847 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20130214/545a55bb/attachment.bin>