Alfred Perlstein wrote: > * Scott Long <scottl_at_FreeBSD.org> [041001 00:40] wrote: > >> | if_em wedging under | | | "wedging" under | >> | high pps | Not done | - | high | > > > I've seen this for months... > mlaier figured this one out. Hopefully we can MFC it today for BETA7. > >> |------------------+-------------+----------------+----------------------| >> | | | | A process cannot be | >> | | | | interrupted while | >> | | | | waiting on a lock. | >> | rpc.lockd(8) | | | Fixing this requires | >> | stability | -- | -- | that the RPC code be | >> | | | | taught how to deal | >> | | | | with lock | >> | | | | cancellation and | >> | | | | interruption events. | > > > Thinking about it... I think Darwin has the fix, I'll see if I can > merge it. > That would be wonderful! > >> |------------------+-------------+----------------+----------------------| >> | | | | Truss appears to | >> | | | | have another | >> | | | | problem. It is | >> | | | | repeatable by | >> | | | | running "truss -f | >> | More truss | Not done | -- | fsck -p /", | >> | problems | | | suspending it with | >> | | | | ^Z, and then killing | >> | | | | truss. It will leave | >> | | | | behind the fsck | >> | | | | processes which will | >> | | | | be unkillable. | > > > This fixes it: > > Index: kern_sig.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/kern_sig.c,v > retrieving revision 1.290 > diff -u -r1.290 kern_sig.c > --- kern_sig.c 31 Aug 2004 07:34:53 -0000 1.290 > +++ kern_sig.c 1 Oct 2004 08:27:12 -0000 > _at__at_ -1775,6 +1775,16 _at__at_ > !((prop & SA_CONT) && (p->p_flag & P_STOPPED_SIG))) > return; > /* > + * SIGKILL: Remove procfs STOPEVENTs. > + */ > + if (sig == SIGKILL) { > + /* from procfs_ioctl.c: PIOCBIC */ > + p->p_stops = 0; > + /* from procfs_ioctl.c: PIOCCONT */ > + p->p_step = 0; > + wakeup(&p->p_step); > + } > + /* > * Some signals have a process-wide effect and a per-thread > * component. Most processing occurs when the process next > * tries to cross the user boundary, however there are some > I see that you already committed this, thanks! Let it settle for a few days and we'll get it into RC1. > > >> | | | | The LOR reported in | >> | | | | PR kern/55175 needs | >> | filedesc LOR | Not done | -- | to be fixed. | >> | | | | Filedesc locking | >> | | | | needs to be heavily | >> | | | | reviewed in general. | > > > Oy this thing... :) > > The only thing blocking this was that we need to access the filedesc > as the process shuts down for nfs locks, Darwin has a workaround that > I'll see if i can incorporate. > Is this one still actually a problem? I haven't seen anyone complain about it in months. ScottReceived on Fri Oct 01 2004 - 12:33:58 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:15 UTC