John Baldwin [EMAIL PROTECTED] écrivait (wrote) :
I'm about to commit some changes to the clock interrupt code on the x86,
try again once those are in place.
Yes, fixed: no more clock skew now.
FreeBSD yoko.hsc.fr 5.0-CURRENT FreeBSD 5.0-CURRENT #70: Fri Oct 6
13:32:01 CEST 2000
On Thu, 5 Oct 2000, Wesley Morgan wrote:
I'm getting a panic in ufs_extattr_uepm_destroy() because in ffs_vfsops.c
it is being called (line 788) with ump NULL:
ufs_extattr_uepm_destroy(ump-um_extattr);
Of course disabling FFS_EXTATTR gets rid of this:)
Hmm. I added these changes
On Fri, Oct 06, 2000 at 09:41:29AM -0400, Robert Watson wrote:
Index: ffs_vfsops.c
===
RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_vfsops.c,v
retrieving revision 1.129
diff -u -r1.129 ffs_vfsops.c
--- ffs_vfsops.c 2000/10/04
On Fri, 6 Oct 2000, David O'Brien wrote:
This has a KNF style problem. The line you remove should stay and
"ump = VFSTOUFS(mp);" added.
Well, either way, it has to be moved further up in the function or you
dereference the NULL pointer. Bruce also pointed out the style problem,
and I'll
Those of you who peruse slashdot will've already seen this - it's a Linux
binary, and requires humungous amounts of memory disk, 384MB 4GB
respectively.
http://www.x86-64.org/downloads/
Stephen
--
The views expressed above are not those of PGS Tensor.
"We've heard that a
=== joy
install -C -c -o root -g wheel -m 555 joy.ko /boot/kernel
install -C -c -o root -g wheel -m 444 joy.8.gz /usr/share/man/man8
install: joy.8.gz: No such file or directory
*** Error code 71
--
Steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in
Following is partial dmesg output from 5.0(13)-CURRENT-20001002 kernel
with advanced debugging prints:
==={{{
mi_startup(): call subsystem 0x880(142606336), microuptime is 1.4027506
mi_startup(): call subsystem 0x880(142606336), microuptime is 1.4027897
mi_startup(): call subsystem
On 06-Oct-00 Valentin Nechayev wrote:
Following is partial dmesg output from 5.0(13)-CURRENT-20001002 kernel
with advanced debugging prints:
The problem was that the interrupt threads for the clk interrupt introduced
enough latency that occasionally (mostly during a heavy load of interrupts)
At Fri, 6 Oct 2000 22:00:23 + (UTC), jhb wrote:
JB The problem was that the interrupt threads for the clk interrupt introduced
JB enough latency that occasionally (mostly during a heavy load of interrupts)
JB tc_windup() wasn't called soon enough to update the timecounter. Making
On my
On 06-Oct-00 Valentin Nechayev wrote:
At Fri, 6 Oct 2000 22:00:23 + (UTC), jhb wrote:
JB The problem was that the interrupt threads for the clk interrupt
introduced
JB enough latency that occasionally (mostly during a heavy load of
interrupts)
JB tc_windup() wasn't called soon enough
newest source code, cvsup an hour ago or so ... if I do a build of the
kernel (to enable DDB), it compiles fine. If I do a 'make -j16 world', it
panic's with the following:
mode = 0100600, inum = 729, fs = /tmp
panic: ffs_valloc: dup alloc
cpuid = 0; lapic.id =
and a DDB trace that
Hey, sorry fr the mini uprising, but I guess you fixed the boot disk issue
that I was having because I can now boot 1004 from boot floppies. For some
reason my backup kernels couldn't boot the system fully after a cvsup, but I
won't get int all that.
System's up and running. Gotta make changes
12 matches
Mail list logo
