From owner-freebsd-stable Mon Feb 19 14:58:15 2001 Delivered-To: freebsd-stable@freebsd.org Received: from guru.mired.org (okc-65-26-235-186.mmcable.com [65.26.235.186]) by hub.freebsd.org (Postfix) with SMTP id 5F60437B491 for ; Mon, 19 Feb 2001 14:58:12 -0800 (PST) Received: (qmail 2779 invoked by uid 100); 19 Feb 2001 22:58:10 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14993.42242.471726.423046@guru.mired.org> Date: Mon, 19 Feb 2001 16:58:10 -0600 To: stable@freebsd.org Subject: Lockups during periodic daily, take two... X-Mailer: VM 6.89 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Got it. My thanks to those who provided suggestions for getting into DDB with this. It seems that XFree86-4 interferes with DDB in some strange way, and I can't get into it *at all* if I've got X running, changing VTs or not. Anyway, it's a bug in fdesc. Analysis below. As verification, if I unmount fdesc, the daily processing runs from crontab just fine. I kind of like <(...), so I'd like fdesc back. Is devfs reasonablye safe, and does it provide /dev/fd? If so, I'll turn that on. If not - and no one who familiar with the code wants to try and fix it - I'll take a whack at it. ,
, 0,
, 4, 0) getdirentries+0xf4(5 ) Xint0x80_syscall+0x2b According to gdb on the core dump, the fdesc_readdir is: 0xc019223e is in fdesc_readdir (../../miscfs/fdesc/fdesc_vnops.c:614). 609 while (i < sizeof(rootent) / sizeof(rootent[0]) && 610 uio->uio_resid >= UIO_MX) { 611 dt = &rootent[i]; 612 switch (dt->d_fileno) { 613 case FD_CTTY: 614 if (cttyvp(uio->uio_procp) == NULL) 615 continue; 616 break; 617 618 case FD_STDIN: On the face of it, the while loop in fdesc_readdir is simply broken. If you hit one of the continues in the loop (there are others further down), you have missed anything in the loop that might change either i or uip, meaning the loop doesn't terminate. It may be waiting on other events to change it, but somehow I doubt it for the fdesc code. Further, note that the code that is finding the continue in this case is checking for a controlling terminal, which would explain the difference in behavior between In checking the CVS repository, I note that the last commit of this code to a releng branch was december of 99, but the -current version was worked on a a couple of weeks ago, and this while loop vanished from the code in the first commit after that commit in december of 99. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message