Date: Thu, 5 Nov 1998 19:24:54 -0500 (EST) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: current@FreeBSD.ORG Subject: Grrr... calcru: negative time blah blah blah Message-ID: <199811060024.TAA14156@skynet.ctr.columbia.edu>
next in thread | raw e-mail | index | archive | help
Recently, the EE department got a bunch of new Dell machines with 450Mhz PII CPUs. This one particular system is an SMP box with 512MB of RAM and a 3D Labs Fire GL 100 <mumble> adapter. Somebody installed FreeBSD 3.0-RELEASE on this system (my brainwashing scheme is working! Soon I will rule the wor--! Uh, wait. You didn't hear that.) and discovered that this display adapter isn't supported by XFree86 (yet) so they downloaded the XFCom_3DLabs server from somewhere. The system seems to run fin until they start this X server. The server loads, but it does something unfriendly to the system that produces the following errors: calcru: negative time of -36857 usec for pid 4036 (csh) calcru: negative time of -51744 usec for pid 4043 (w) calcru: negative time of -26704 usec for pid 4044 (ps) calcru: negative time of -47557 usec for pid 4046 (reboot) calcru: negative time of -46489 usec for pid 304 (hostname) calcru: negative time of -24935 usec for pid 310 (ps) Also, the system becomes really slow at this point: keystrokes are echoed on the console very slowly. Naturally, there's no source for the XFCom_3DLabs X server. I built a kernel from the 3.0-19981103-SNAP distribution: this changes the behavior slightly in that the calcru messages no longer appear, however the X server crashes shortly after startup: pid 254 (XFCom_3DLabs), uid 0: exited on signal 6 (core dumped) And the system once again feels very slow and sluggish. This slowness doesn't go away until the system is rebooted. I know this has been talked about before. This problem is 100% reproducible with this X server. It happens with both an SMP kernel and a UP kernel on the same hardware. Anybody have any clues how to go about tracking this down? As an aside, I've only seen these messages once before on the Dell PowerEdge 2300/400 machine that I've been using for driver development. With the tulip clone chips, I managed to generate an interrupt storm on several occasions which would foul up the machine pretty good. Basically, the driver code would trigger an error interrupt of sorts and the code that was meant to handle the interrupt would inadvertently trigger the same interrupt over again, resulting in an infinite loop condition. Once or twice I've done this late at night while sitting at my terminal at home trying to remote test a driver on the machine in the lab; since the machine is stuck and I can't reboot it from home, I have to wait until I come to work the next morning to clobber it. At times, when I come in, I see these same messages on the console. I took this to mean that the interrupt storm was interfering with the processing of clock ticks which botched the CPU accounting for some of the daemon processes that were running when I triggered the problem. Anyway. If anyone has any clues as to how to deal with this problem, I'd love to hear of it. We may be stuck with these cards, and the Powers That Be (tm) want to use FreeBSD on these systems for a course; I'd hate to have to tell them that they'll have to make due with console only mode. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811060024.TAA14156>