"Poul-Henning Kamp" wrote:
> In message <[EMAIL PROTECTED]>, "Greg 'groggy' Lehey
"
> writes:
>
> >> Optimizing fsck is a valid project, I just wish it would be somebody
> >> who would also finish the last 30% who would do it.
> >
> >Poul-Henning, how can you justify the second half of that s
David Schultz wrote:
> This is because floating point
> support on Alpha is broken unless you specifically tell gcc to
> unbreak it by specifying -mieee.
Sounds like the ability to turn "-mieee" off at all, let alone
making it the default, is bad? If so, why is that the way it
is configured?
> I
Steve Sizemore wrote:
> Thanks for the explanation. If I were a programmer, it would be very
> useful. As it is, it's still interesting. I have no way of judging the
> quality of the code in question, other than the empirical result that
> it works in most cases.
Well, then you are stuck with the
Thus spake Ruslan Ermilov <[EMAIL PROTECTED]>:
> Yes, as I have suspected, the gdtoa change is responsible
> for a breakage. libc corresponding to this lib/libc works:
>
> cvs -q up -P -d -D'2003/03/12 20:20:00'
>
> : Using /home/ru/w/f/usr.bin/awk/nawk nawk...
>
> This version, together
> I'll stop as soon as KSE is finished, fair ?
I'm very disappointed in this response. Poul, everything else I've read
from you to date has been reasonable except for this posting.
I would think that you, yourself, should be especially sensitive to
criticism of unfinished projects. Things such
Hi, Terry -
On Mon, Mar 17, 2003 at 07:02:31PM -0800, Terry Lambert wrote:
> "Andrew P. Lentvorski, Jr." wrote:
> > being sent is SETLKW which is a blocking wait until lock is granted. If
> > the server thinks the file is already locked, it will hang *and* that is
> > the proper behavior.
>
> It
On Monday, 17 March 2003 at 23:02:38 -0500, Jeff Roberson wrote:
> On Mon, 17 Mar 2003, Terry Lambert wrote:
>
>> Jeff Roberson wrote:
>>> On Mon, 17 Mar 2003, Brooks Davis wrote:
I am still intrested in improvements to fsck since I'm planning to buy
several systems with two 1.4TB IDE RAI
Bakul Shah wrote:
> > Sorry, but the track-to-track seek latency optimizations you
> > are referring to are turned off, given the newfs defaults, and
> > have been for a very long time.
>
> I was thinking of the basic idea of cylinder groups as good
> for normal load, not so good for fsck when you
In message <[EMAIL PROTECTED]>, "Greg 'groggy' Lehey"
writes:
>> Optimizing fsck is a valid project, I just wish it would be somebody
>> who would also finish the last 30% who would do it.
>
>Poul-Henning, how can you justify the second half of that sentence? I
>take exception to the implication
In message <[EMAIL PROTECTED]>, FUJITA Kazutoshi wrote
:
>Hi,
>
>My -CURRENT(2003/03/12) laptop(ThinkPad X23) can't be suspended.
>
>When I try
>
># acpiconf -s 1
>
>I have console message
>
>'acpi0: AcpiGetSleepTypeData failed - AE_NOT_FOUND'
>
>How can I solve this?
>
>
>dmesg output is attached.
In message <[EMAIL PROTECTED]>, Brad Knowles writes:
>At 10:39 PM +0100 2003/03/17, Poul-Henning Kamp wrote:
>
>> Optimizing fsck is a valid project, I just wish it would be somebody
>> who would also finish the last 30% who would do it.
>
> Just what are you saying? Is Julian Elischer not
Hi,
My -CURRENT(2003/03/12) laptop(ThinkPad X23) can't be suspended.
When I try
# acpiconf -s 1
I have console message
'acpi0: AcpiGetSleepTypeData failed - AE_NOT_FOUND'
How can I solve this?
dmesg output is attached.
Regards,
Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1
> > UFS is the real problem here, not fsck. Its tradeoffs for
> > improving normal access latencies may have been right in the
> > past but not for modern big disks.
...
> Sorry, but the track-to-track seek latency optimizations you
> are referring to are turned off, given the newfs defaul
On Mon, Mar 17, 2003 at 23:02:38 -0500, Jeff Roberson wrote:
> On Mon, 17 Mar 2003, Terry Lambert wrote:
> > Jeff Roberson wrote:
> > > On Mon, 17 Mar 2003, Brooks Davis wrote:
> > > > I am still intrested in improvements to fsck since I'm planning to buy
> > > > several systems with two 1.4TB IDE
Jeff Roberson wrote:
> On Mon, 17 Mar 2003, Terry Lambert wrote:
> > Jeff Roberson wrote:
> > > On Mon, 17 Mar 2003, Brooks Davis wrote:
> > > > I am still intrested in improvements to fsck since I'm planning to buy
> > > > several systems with two 1.4TB IDE RAID5 arrays in them soon.
> > >
> > > F
On Mon, 17 Mar 2003, Terry Lambert wrote:
> Jeff Roberson wrote:
> > On Mon, 17 Mar 2003, Brooks Davis wrote:
> > > I am still intrested in improvements to fsck since I'm planning to buy
> > > several systems with two 1.4TB IDE RAID5 arrays in them soon.
> >
> > For these types of systems doing a
Jeff Roberson wrote:
> On Mon, 17 Mar 2003, Brooks Davis wrote:
> > I am still intrested in improvements to fsck since I'm planning to buy
> > several systems with two 1.4TB IDE RAID5 arrays in them soon.
>
> For these types of systems doing a block caching layer with a prefetch
> that understands
Bakul Shah wrote:
> > I have been tending UNIX computers of all sorts for many years and
> > there is one bit of wisdom that has yet to fail me:
> >
> > Every now and then, boot in single-user and run full fsck
> > on all filesystems.
> >
> > If this had failed to be productive, I would
Julian Elischer wrote:
> The problem space is
>
> Fsck of UFS/FFS partitions is too slow for 200GB+ filesystems.
>
> The solution space can not contain any answer that includes redefining
> UFS/FFS. Welcome to the real world. :-)
"Use smaller than 200GB+ filesystems".
8-).
-- Terry
To Unsubsc
Bakul Shah wrote:
> UFS is the real problem here, not fsck. Its tradeoffs for
> improving normal access latencies may have been right in the
> past but not for modern big disks. The seek time & RPM have
> not improved very much in the past 20 years while disk
> capacity has increased by a factor
From: "Aaron Wohl" <[EMAIL PROTECTED]>
> replacement for MAKDEV to mkae them? ... and I cant seem to get truss to
> run at all on any program...
> bash-2.05b# truss mpd
> truss: cannot open /proc/curproc/mem: No such file or directory
> truss: cannot open /proc/1107/mem: No such file or directory
>
"Andrew P. Lentvorski, Jr." wrote:
> The dump doesn't seem to be attached. However, I note that the request
> being sent is SETLKW which is a blocking wait until lock is granted. If
> the server thinks the file is already locked, it will hang *and* that is
> the proper behavior.
It is, to ensure
Maxime Henrion writes:
> Andrew Gallatin wrote:
> >
> > I'm seeing the following panic under heavy NFS client usage on an SMP
> > w/kernel sources from Weds. evening. Has this been fixed?
>
> If I'm not mistaken, this is the problem Jeff fixed in revision 1.134 of
> vfs_cluster.c.
>
G
On Mon, 17 Mar 2003, Andrew Gallatin wrote:
>
> I'm seeing the following panic under heavy NFS client usage on an SMP
> w/kernel sources from Weds. evening. Has this been fixed?
>
> Thanks,
>
> Drew
I believe that is fixed in nfs_vnops.c 1.200.
>
> panic: lockmgr: locking against myself
> cpuid
Andrew Gallatin wrote:
>
> I'm seeing the following panic under heavy NFS client usage on an SMP
> w/kernel sources from Weds. evening. Has this been fixed?
If I'm not mistaken, this is the problem Jeff fixed in revision 1.134 of
vfs_cluster.c.
Cheers,
Maxime
To Unsubscribe: send mail to [EMAI
After configuring an md in current (as of last Friday), I will later
panic. Unfortunately (or not), the kernel on this system was built
without symbols, witness, invariants, or debugger. So I built a new
kernel with all of those things and...no more panics. Makes debug a bit
difficult.
I then bui
I'm seeing the following panic under heavy NFS client usage on an SMP
w/kernel sources from Weds. evening. Has this been fixed?
Thanks,
Drew
panic: lockmgr: locking against myself
cpuid = 0; lapic.id =
Debugger("panic")
Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0
db> t
Im trying to run pptp under 5.0 -current. (first time with mpd so
probably some config issue)
I get these errors:
mpd: pid 1102, version 3.13 ([EMAIL PROTECTED] 09:35
17-Mar-2003)
[pptp0] can't create socket node: No such file or directory
mpd: local IP address for PPTP is 10.23.0.3
[pptp0] using
Generic Viagra is now available to consumers
As low as $2.25 per dose (50 mg)
No Doctor's Consutation required
"Silagra is as good as Viagra - just cheaper!"
Costs over 65% less than Brand Name
(Generic Sildenafil Citrate (Silagra)
and Viagra. both consist of 100 mg of
sildenafil citrate)
Priv
Am Mo, 2003-03-17 um 23.08 schrieb David Schultz:
> Thus spake Franz Klammer <[EMAIL PROTECTED]>:
> > cvsup and build (kernel + userland, empty /usr/obj):
> > FreeBSD ds9.webonaut.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sun Mar 16
> > 17:53:22 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DS9 i
On Mon, 17 Mar 2003, Brooks Davis wrote:
> On Mon, Mar 17, 2003 at 12:45:15PM -0800, Julian Elischer wrote:
> > I might add that the test filesystem was 95% full with about 8,000,000
> > directories on it. It was populated with multiple copies of /bin
> > and /etc as a test set :-)
>
> How muc
>:D
I booted the two floppies again. I tried what you said. hw.eisa_slots="0".
It got farther this time. I got a full dmesg. However, it was followed by
this:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x7
fault code= supervisor read, page not present
instr
On Monday, 17 March 2003 at 22:39:02 +0100, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Bakul Shah writes:
>
>> UFS is the real problem here, not fsck. Its tradeoffs for
>> improving normal access latencies may have been right in the
>> past but not for modern big disks. The seek t
At 10:39 PM +0100 2003/03/17, Poul-Henning Kamp wrote:
Optimizing fsck is a valid project, I just wish it would be somebody
who would also finish the last 30% who would do it.
Just what are you saying? Is Julian Elischer not the right
person to be working on this, because he has a history of
Hello,
$ gdb -k /sys/i386/compile/HP6100/kernel.debug /usr/crash/vmcore.0
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
On Mon, 17 Mar 2003, Brooks Davis wrote:
> On Mon, Mar 17, 2003 at 12:45:15PM -0800, Julian Elischer wrote:
> > I might add that the test filesystem was 95% full with about 8,000,000
> > directories on it. It was populated with multiple copies of /bin
> > and /etc as a test set :-)
>
> How much li
On Mon, Mar 17, 2003 at 01:07:53PM -0800, David O'Brien wrote:
> On Mon, Mar 17, 2003 at 12:43:19PM -0800, Crist J. Clark wrote:
> > On Mon, Mar 17, 2003 at 09:11:12AM -0800, David O'Brien wrote:
> > > On Mon, Mar 17, 2003 at 12:28:34AM -0800, Crist J. Clark wrote:
> > > > +kldxref_start () {
> > >
On Mon, 17 Mar 2003, Bakul Shah wrote:
> > Now, before we go off and design YABFS, can we just get real for
> > a second ?
>
>
> I am skeptical you will get more than a factor of 2
> improvement without changing the FS (but hey, that is 3 hours
> for Julian so I am sure he will be happy with t
On Mon, Mar 17, 2003 at 02:12:31PM -0800, David Schultz wrote:
> Thus spake Ruslan Ermilov <[EMAIL PROTECTED]>:
> > Hold off upgrading your Alphas for a moment.
> > Something broke libc recently that results in
> > (at least) floating point exceptions from
> > awk(1) (this is not related to today's
On Mon, Mar 17, 2003 at 12:45:15PM -0800, Julian Elischer wrote:
> I might add that the test filesystem was 95% full with about 8,000,000
> directories on it. It was populated with multiple copies of /bin
> and /etc as a test set :-)
How much like you're real file mix does this look? If your rea
Thus spake Ruslan Ermilov <[EMAIL PROTECTED]>:
> Hold off upgrading your Alphas for a moment.
> Something broke libc recently that results in
> (at least) floating point exceptions from
> awk(1) (this is not related to today's awk
> upgrade).
>
> I've been able to reproduce this on beast.freebsd.o
> You talk like I have a choice :-)
> I cannot change ufs/ffs and even if I could the clients wouldn't go for
> it.
What about changing the size of block size or cyl grp size?
Do they change things much?
> The problem space is
>
> Fsck of UFS/FFS partitions is too slow for 200GB+ filesystems.
>
Thus spake Franz Klammer <[EMAIL PROTECTED]>:
> cvsup and build (kernel + userland, empty /usr/obj):
> FreeBSD ds9.webonaut.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sun Mar 16
> 17:53:22 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DS9 i386
>
>
> since my update from yesterday (above), fontco
On Mon, Mar 17, 2003 at 01:21:19PM -0800, Andrew P. Lentvorski, Jr. wrote:
> On Sun, 16 Mar 2003, Steve Sizemore wrote:
>
> The dump doesn't seem to be attached. However, I note that the request
It appears that there are problems sending the raw dump. I've tried
twice - once 2 minutes after I se
> Now, before we go off and design YABFS, can we just get real for
> a second ?
I leave it to others to design YAFS, I just wanted to
complain about this one :-) Every few years I seriously look
at speeding up fsck but give up. I remember even asking
about it a few years ago on one of these grou
On Mon, 17 Mar 2003, Bakul Shah wrote:
> Anyway, support for all of these have to be done in the
> filesystem first before fsck can benefit.
yep
> If instead you spend time "optimizing" just fsck, you will
> likely make it far more complex (and potentially harder to
> get right).
You talk l
Thanks for your thoughts. .
Some good points..
On Mon, 17 Mar 2003, Bakul Shah wrote:
> UFS is the real problem here, not fsck. Its tradeoffs for
> improving normal access latencies may have been right in the
> past but not for modern big disks. The seek time & RPM have
> not improved very muc
In message <[EMAIL PROTECTED]>, Bakul Shah writes:
>UFS is the real problem here, not fsck. Its tradeoffs for
>improving normal access latencies may have been right in the
>past but not for modern big disks. The seek time & RPM have
>not improved very much in the past 20 years while disk
>capaci
UFS is the real problem here, not fsck. Its tradeoffs for
improving normal access latencies may have been right in the
past but not for modern big disks. The seek time & RPM have
not improved very much in the past 20 years while disk
capacity has increased by a factor of about 20,000 (and GB/$
ev
Hello, current! How are you?
I have:
FreeBSD 5.0-CURRENT 24 Feb 2003 21:55:43 MSK.
I have very rcent sources of -CURRENT (updated 17 Mar 2003 about
20:00 MSK (GMT+3)).
`make buildwolrd' was failed (only very tail of output is here):
cc -pg -O -pipe -march=pentiumpro -DTERMIOS -DANSI_
On Sun, 16 Mar 2003, Steve Sizemore wrote:
> Sorry - I was trying to be too helpful. I actually did capture the raw
> dump but appended the decoded output. This time, I've attached a
> real raw dump.
The dump doesn't seem to be attached. However, I note that the request
being sent is SETLKW whic
On Mon, Mar 17, 2003 at 12:43:19PM -0800, Crist J. Clark wrote:
> On Mon, Mar 17, 2003 at 09:11:12AM -0800, David O'Brien wrote:
> > On Mon, Mar 17, 2003 at 12:28:34AM -0800, Crist J. Clark wrote:
> > > +kldxref_start () {
> > > + if [ -z "$kldxref_module_path" ]; then
> > > + MODULE_PATHS=
On Mon, 17 Mar 2003 12:22:33 -0800 (PST)
Julian Elischer <[EMAIL PROTECTED]> wrote:
Howdy,
> It wouldn;t be super fast but at least it COULD be used to check a > 30TB array,
> where the in-memory version would beed a process VM space > of 24MB which is clearly
> impossible on a x86.
I'm sure
I might add that the test filesystem was 95% full with about 8,000,000
directories on it. It was populated with multiple copies of /bin
and /etc as a test set :-)
On Mon, 17 Mar 2003, Julian Elischer wrote:
> this is a full 100% forground fsck -y
>
> On Mon, 17 Mar 2003, Alfred Perlstein wrote:
On Mon, Mar 17, 2003 at 09:11:12AM -0800, David O'Brien wrote:
> On Mon, Mar 17, 2003 at 12:28:34AM -0800, Crist J. Clark wrote:
> > +kldxref_start () {
> > + if [ -z "$kldxref_module_path" ]; then
> > + MODULE_PATHS=`sysctl -n kern.module_path`
> > + else
> > + MODULE_PATHS
this is a full 100% forground fsck -y
On Mon, 17 Mar 2003, Alfred Perlstein wrote:
> * Julian Elischer <[EMAIL PROTECTED]> [030317 12:22] wrote:
> >
> > Is there anyone working on fsck?
> > Recent timings with a fast machine with 1TB filesystems
> > show that it takes abuot 6 hours to fsck such
* Julian Elischer <[EMAIL PROTECTED]> [030317 12:22] wrote:
>
> Is there anyone working on fsck?
> Recent timings with a fast machine with 1TB filesystems
> show that it takes abuot 6 hours to fsck such a filesystem
> (on a fast array with a lot of RAM)
>
> This is with a version of fsck that alr
Is there anyone working on fsck?
Recent timings with a fast machine with 1TB filesystems
show that it takes abuot 6 hours to fsck such a filesystem
(on a fast array with a lot of RAM)
This is with a version of fsck that already has some locally developed
speedups and changes. I have not dared tim
Ahh, that explains why the multiple /dev/md* didn't help the problem.
I'm looking into the vmstat options, but can't figure out how to extract
the malloc-per-bucket-quota limit for the system (I've read man vmstat,
and tried vmstat -z and vmstat -m, but the only "Limit" listed is under
vmstat -z,
In message <[EMAIL PROTECTED]>, "John Stockdale" writes:
>OS: FreeBSD 5.0-CURRENT, JPSNAP20030314
>
>I'm running a Dual Xeon system with 1GB DDRRAM, and trying to create a
>ram disk to compile under, specifically to compile the kernel.
>
>I've tried several methods, involving either creating one 51
OS: FreeBSD 5.0-CURRENT, JPSNAP20030314
I'm running a Dual Xeon system with 1GB DDRRAM, and trying to create a
ram disk to compile under, specifically to compile the kernel.
I've tried several methods, involving either creating one 512MB disk
with mdconfig or mdmfs. No matter what options I speci
>
> Got that crash again, with sync-on-panic disabled. The interesting thing
> is that the stack trace might be corrupted or inaccurate (maybe some tail
> recursion optimisation or inlining is going on around): although it seems
> to indicate that the panic is the one from "bwrite: need chained iod
hi!
cvsup and build (kernel + userland, empty /usr/obj):
FreeBSD ds9.webonaut.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sun Mar 16
17:53:22 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DS9 i386
since my update from yesterday (above), fontconfig can't read his
configuration file. it claims the
On Mon, Mar 17, 2003 at 12:28:34AM -0800, Crist J. Clark wrote:
> +kldxref_start () {
> + if [ -z "$kldxref_module_path" ]; then
> + MODULE_PATHS=`sysctl -n kern.module_path`
> + else
> + MODULE_PATHS="$kldxref_module_path"
> + fi
Please change the logic to posi
Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, walt writes:
If inclusion of INVARIANTS serves to disguise bugs in
the kernel, I wonder if kernel committers should be
using this option routinely?
Please check into our current reality :-)
Hm. How do I parse that sentence? If you are im
On Mon, Mar 17, 2003 at 06:43:11PM +0200, Ruslan Ermilov wrote:
> On Mon, Mar 17, 2003 at 06:40:37PM +0200, Ruslan Ermilov wrote:
> > Yes, as I have suspected, the gdtoa change is responsible
> > for a breakage. libc corresponding to this lib/libc works:
> >
> > cvs -q up -P -d -D'2003/03/12
On Mon, Mar 17, 2003 at 06:40:37PM +0200, Ruslan Ermilov wrote:
> Yes, as I have suspected, the gdtoa change is responsible
> for a breakage. libc corresponding to this lib/libc works:
>
> cvs -q up -P -d -D'2003/03/12 20:20:00'
>
> : Using /home/ru/w/f/usr.bin/awk/nawk nawk...
>
> This v
Yes, as I have suspected, the gdtoa change is responsible
for a breakage. libc corresponding to this lib/libc works:
cvs -q up -P -d -D'2003/03/12 20:20:00'
: Using /home/ru/w/f/usr.bin/awk/nawk nawk...
This version, together with contrib/gdtoa, doesn't:
cvs -q up -P -d -D'2003
Hi!
Hold off upgrading your Alphas for a moment.
Something broke libc recently that results in
(at least) floating point exceptions from
awk(1) (this is not related to today's awk
upgrade).
I've been able to reproduce this on beast.freebsd.org
by building the fresh libc.a and linking awk with
it,
On Mon, Mar 17, 2003 at 07:51:34AM -0800, Brooks Davis wrote:
> On Mon, Mar 17, 2003 at 07:44:02AM -0600, Robert Garrett wrote:
> > On Mon, Mar 17, 2003 at 03:10:08AM -0800, Doug Barton wrote:
> > > Are you guys precisely following the instructions in src/UPDATING?
> > most definately, the new comp
On Mon, Mar 17, 2003 at 07:44:02AM -0600, Robert Garrett wrote:
> On Mon, Mar 17, 2003 at 03:10:08AM -0800, Doug Barton wrote:
> > Are you guys precisely following the instructions in src/UPDATING?
> most definately, the new compiler depends on new syscalls in the kernel,
> and the kernel depends
"ËÒ¡¤Ø³ÅéÁàËÅÇ·Õè¨ÐÇҧἹ ÂèÍÁá»ÅÇèҤسÇҧἹ·Õè¨ÐÅéÁàËÅÇ"
¨ÔÁ âÃËì¹ ¹Ñ¡»ÃѪÒÍѹ´Ñº 1 ¢Í§âÅ¡
àªè¹ ¤Ø³¤Ô´ÇèÒ㹪ÕÇÔµ¹ÕéàÃÒ¤§äÁèÁÕ·Ò§ÃÇ ¤Ø³¡çä¨ÐäÁèÁÕ·Ò§ÃÇÂàÅÂ
ËÃ×Í "¤Ø³¤Ô´ÇèÒÊÑ¡Çѹ¶Ö§©Ñ¹µéͧÃÇÂá¹èæ"
¨ÔÁ âÃËì¹ ºÍ¡ÇèÒ
"¶éҤسÂѧ·ÓÊÔ觷Õè¤Ø³·ÓÍÂÙè·Ø¡Çѹ¹Õé ÍÕ¡ 3 »Õ¢éҧ˹éÒÅͧ¤Ô´´Ù
"ËÒ¡¤Ø³ÅéÁàËÅÇ·Õè¨ÐÇҧἹ ÂèÍÁá»ÅÇèҤسÇҧἹ·Õè¨ÐÅéÁàËÅÇ"
¨ÔÁ âÃËì¹ ¹Ñ¡»ÃѪÒÍѹ´Ñº 1 ¢Í§âÅ¡
àªè¹ ¤Ø³¤Ô´ÇèÒ㹪ÕÇÔµ¹ÕéàÃÒ¤§äÁèÁÕ·Ò§ÃÇ ¤Ø³¡çä¨ÐäÁèÁÕ·Ò§ÃÇÂàÅÂ
ËÃ×Í "¤Ø³¤Ô´ÇèÒÊÑ¡Çѹ¶Ö§©Ñ¹µéͧÃÇÂá¹èæ"
¨ÔÁ âÃËì¹ ºÍ¡ÇèÒ
"¶éҤسÂѧ·ÓÊÔ觷Õè¤Ø³·ÓÍÂÙè·Ø¡Çѹ¹Õé ÍÕ¡ 3 »Õ¢éҧ˹éÒÅͧ¤Ô´´Ù
Petri Helenius wrote:
[ ... Citeseer earch terms for professional strength networking ... ]
> These seem quite network-heavy, I was more interested in references
> of SMP stuff and how the coherency is maintained and what is
> the overhead of maintaining the coherency in read/write operations
> an
On Mon, Mar 17, 2003 at 03:10:08AM -0800, Doug Barton wrote:
> Are you guys precisely following the instructions in src/UPDATING?
most definately, the new compiler depends on new syscalls in the kernel,
and the kernel depends on new options in the compiler. I could not find
anything about this sit
I've just committed the right fix for this (which is to nuke the bogus
KASSERT). I have one or two other fixes in the pipe for lucent cards,
but had hoped to get them 'perfect' rather than 'a lot better' before
committing them. Since my time has been short, I'll go ahead and try
to commit the 'be
In message: <[EMAIL PROTECTED]>
"Sam Leffler" <[EMAIL PROTECTED]> writes:
: > * Alfred Perlstein <[EMAIL PROTECTED]> [030316 21:19] wrote:
: > > um..
: > >
: > ...
: > 840 _FLAGS_OUTRANGE) {
: > 841 WI_UNLOCK(sc);
: > 842 return;
: > 843
Daniel C. Sobral wrote:
Crist J. Clark wrote:
Perhaps it would be a good idea to build a linker.hints file with
kldxref(8) at boot time. At least, I can't think of any really good
reasons why _not_ to do it.
[...]
This is my first stab at rc-ng for a long while, so please be gentle
if I've not ha
Crist J. Clark wrote:
Perhaps it would be a good idea to build a linker.hints file with
kldxref(8) at boot time. At least, I can't think of any really good
reasons why _not_ to do it.
[...]
This is my first stab at rc-ng for a long while, so please be gentle
if I've not handled that the best way. P
Crist J. Clark wrote:
Also, what's the best way/is there a way to figure out the boot
directory rather than hardwire /boot/kernel?
dirname `sysctl -n kern.bootfile`
--
Daniel C. Sobral (8-DCS)
Gerencia de Operacoes
Divisao de Comunicacao de Dados
Coordenacao de Seguranca
TCO
Fon
Le 2003-03-12, Jeff Roberson écrivait :
> > > Can you please print bp? I'd like to know what all of the members are. A
> > > cluster buf should NEVER have BX_BKGRDWRITE set. This is totally bogus.
Got that crash again, with sync-on-panic disabled. The interesting thing
is that the stack trace
Are you guys precisely following the instructions in src/UPDATING?
On Mon, 17 Mar 2003, Scott Sipe wrote:
> I second that problem. Tried doing an upgrade yesterday, and it didn't
> work--missing libc.so.4 error given during make installworld.
>
> Scott
>
> - Original Message -
> From: "R
On Sun, 16 Mar 2003, Lucas Reddinger wrote:
> The one alternative would be to compile a stripped kernel on another
> machine, and install off of it. I did this, but I do not have enough
> knowledge of the 5.x kernel/modules to be able to do this myself. If
> someone could give me some help with thi
> If you are asking for paper references, then I can at least tell
> you where to start; go to: http://citeseer.nj.nec.com/cs and look
> for "Jeff Mogul", "DEC Western Research Laboratories", "Mohit
> Aron", "Peter Druschel", "Sally Floyd", Van Jacobson", "SCALA",
> "TCP Rate halving", "Receiver Li
I second that problem. Tried doing an upgrade yesterday, and it didn't
work--missing libc.so.4 error given during make installworld.
Scott
- Original Message -
From: "Robert Garrett" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, March 16, 2003 3:53 AM
Subject: source upgrade
subscribe
Buurtnet
Oldambt 69
3524 BD Utrecht
030-2898094
06-17058904
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Gentleman,
Please correct me if I am wrong but it appears, that the source upgrade
path from 4.* to 5.0 is broken. I havent played with it much but it appears
thatbuilding the kernel, depends on somethings new to the -current compiler, and the
compiler is dependant on stuff in the 5.-cur
On Mon, Mar 17, 2003 at 12:28:34AM -0800, Crist J. Clark wrote:
>
> Index: src/etc/rc.d/kldxref
> ===
> RCS file: src/etc/rc.d/kldxref
> diff -N src/etc/rc.d/kldxref
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ src/etc/rc.d/kldxref
On Fri, Mar 14, 2003 at 07:27:42PM -0800, Peter Wemm wrote:
> "Crist J. Clark" wrote:
> >
> > --C7zPtVaVf+AK4Oqc
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> >
> > Perhaps it would be a good idea to build a linker.hints file with
> > kldxref(8) at boot time. At
Petri Helenius wrote:
> > This also has the desirable side effect that stack processing will
> > occur on the same CPU as the interrupt processing occurred. This
> > avoids inter-CPU memory bus arbitration cycles, and ensures that
> > you won't engage in a lot of unnecessary L1 cache busting. Hen
90 matches
Mail list logo
