Date: Mon, 16 Nov 1998 12:14:46 -0800 (PST) From: Doug White <dwhite@resnet.uoregon.edu> To: Kevin Day <toasty@home.dragondata.com> Cc: questions@FreeBSD.ORG Subject: Re: MediaGX and calcru: negative time Message-ID: <Pine.BSF.4.03.9811161212540.17775-100000@resnet.uoregon.edu> In-Reply-To: <199811161830.MAA16210@home.dragondata.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This probably belongs on -questions since it's not related to -current .. On Mon, 16 Nov 1998, Kevin Day wrote: > FreeBSD 2.2.7-RELEASE #0: Wed Oct 21 16:22:35 CDT 1998 > devel@kevin1.touchmaster:/usr/src/sys/compile/DEVEL > CPU: Cyrix GXm (0.00-MHz 586-class CPU) > Origin = "CyrixInstead" Id = 0x540 DIR=0x3346 Stepping=3 Revision=3 > real memory = 63963136 (62464K bytes) > avail memory = 60252160 (58840K bytes) okay... > wdc0: unit 0 (wd0): <QUANTUM FIREBALL SE3.2A>, multi-block-16 > wd0: 3079MB (6306048 sectors), 6256 cyls, 16 heads, 63 S/T, 512 B/S > wdc1 at 0x170-0x177 irq 15 on isa > wdc1: unit 0 (atapi): <FX320S/q01>, removable, intr, dma, iordis > wcd0: 5512Kb/sec, 256Kb cache, audio play, 255 volume levels, ejectable tray > wcd0: no disc inside, unlocked Nothing out of the ordinary there... > calcru: negative time: -6644 usec > pid 8197 (dl), uid 0: exited on signal 11 (core dumped) dl is one of your programs? Backtrace the core dump and see what made it fall over. > calcru: negative time: -6644 usec > pid 8211 (dl), uid 0: exited on signal 11 (core dumped) > calcru: negative time: -6644 usec > pid 8211 (dl), uid 0: exited on signal 11 (core dumped) > calcru: negative time: -6644 usec > pid 8211 (dl), uid 0: exited on signal 11 (core dumped) > /kernel: file: table is full > syslogd: /var/run/utmp: Too many open files in system dl was probably leaking file descriptors ... > Now, since Cyrix is supporting us with this product, are there any questions > I can ask them that may shed some light? The calcru is probably related, but I doubt your crashes are. You'll have to analyse the core. > It appears that the problem is brought out by lots of IDE access. The IDE > interface is done internaly, in the CPU. Could timeouts/delays in the IDE > side be slowing the clock somehow? Most likely .. Doug White Internet: dwhite@resnet.uoregon.edu | FreeBSD: The Power to Serve http://gladstone.uoregon.edu/~dwhite | www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.03.9811161212540.17775-100000>