:NOTE: I'm not on -current, so if you trim committers, please cc me.
:
:I believe I have discovered a problem w/ -current... I would like more
:data points to see if this is a problem... when I run
:http://people.FreeBSD.org/~jmg/bench.py against a -current box (so far
:I have tested against buil
Matthew Jacob wrote:
>
> > # I cannot stress this enough: **SAVE A WORKING /kernel**
> > cp /kernel /kernel.works
>
> Save a working /modules and /boot as well.
Which is always good advice, but I can clarify the effect on these...
The only change in /boot is /boot/defaults/loader.conf:
diff
> # I cannot stress this enough: **SAVE A WORKING /kernel**
> cp /kernel /kernel.works
Save a working /modules and /boot as well.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
*** CAUTION IS REQUIRED ***!
FYI, an intrusive commit has been done that requires careful attention. If
you ignore this or mess it up, it can burn your house down, shoot your dog,
close your bank accounts, report you to the IRS, or maybe even something
bad.
An old version 51 config(8) will (
Hi,
On a freshly installed snap (5.0-2612-SNAP), after
compiling up a new kernel, the make install fails.
Basically, it tries to 'cp /modules/* /modules.old'
but /modules is empty and the cp fails. We need to
either recognize an empty directory, or not fail
if the cp fails.
the fol
> > > a larger issue. It is not the loader's job to detect the underlying
> > > hardware configuration.
> >
> > Actually, in a broad fashion, it _is_. This is why the loader
> > understands PCI and PnP, for example.
> >
> Why do we want to do that? Are we going to offload device probe routines
> > a larger issue. It is not the loader's job to detect the underlying
> > hardware configuration.
>
> Actually, in a broad fashion, it _is_. This is why the loader
> understands PCI and PnP, for example.
>
Why do we want to do that? Are we going to offload device probe routines to
the loader
> a larger issue. It is not the loader's job to detect the underlying
> hardware configuration.
Actually, in a broad fashion, it _is_. This is why the loader
understands PCI and PnP, for example.
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should learn h
> "Dan" == Dan Moschuk <[EMAIL PROTECTED]> writes:
Dan> I've avoided this conversation, but what would everyone think of
Dan> a tmpfs type of solution with a security minded design? I took a
Dan> brief look at phk's md driver, and it could be quite easily
Dan> molded to do what I want to do.
| >
| > Maybe the soltion is to think out of the box. Maybe temporary
| > filestore should be a more official OS service. Race conditions would
| > be far less common if the OS itself was managing the namespace.
| >
| > You might even expand the capability somewhat. Provide process local,
|
-On [2613 17:08], Bart Thate ([EMAIL PROTECTED]) wrote:
>
>prp is 0x0 but is not checked upon. The check if prp ==0 is done 2 lines
>further on.
>
> if (prp == 0 || prp->pr_usrreqs->pru_attach == 0)
>return (EPROTONOSUPPORT);
>
>
>since
> Given the way VMware works, I'd have nothing against making it a FICL
> words, except...
>
> ...VMware is a port. For some reason, I dislike the idea of having
> support targetted at exclusively one specific port. Though we have
> features added specifically to deal with certain ports, they wer
Hi again ;)
this patch ..
http://www.FreeBSD.org/cgi/cvsweb.cgi/src/sys/kern/uipc_socket.c.diff?r1=1.72&r2=1.73
makes my kernel panic.
a snippet from gdb -k ..
#10 0xc01705b5 in socreate (dom=28, aso=0xca35df20, type=2, proto=0,
p=0xc9959be0) at ../../kern/uipc_socket.c:138
138
> This is the third time this happened to a 4.0-STABLE host of ours.
>
> The problem starts with havnig a number of processes which are unable to
> be killed. So we want to reboot the box.
>
> All goes well, bufdaemon and syncer stop normally.
>
> Then it gets to
>
> syncing disks
> done.
>
auth f28c66a8 subscribe freebsd-current [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
This is the third time this happened to a 4.0-STABLE host of ours.
The problem starts with havnig a number of processes which are unable to
be killed. So we want to reboot the box.
All goes well, bufdaemon and syncer stop normally.
Then it gets to
syncing disks
done.
And there it hangs. At
NOTE: I'm not on -current, so if you trim committers, please cc me.
I believe I have discovered a problem w/ -current... I would like more
data points to see if this is a problem... when I run
http://people.FreeBSD.org/~jmg/bench.py against a -current box (so far
I have tested against builder an
Hi!
On Fri, 9 Jun 2000, Ian Dowse wrote:
> >vm/vm_object.h -> vm/vm_object.ph
> >vm/vm_page.h -> vm/vm_page.ph
> >vm/vm_pageout.h -> vm/vm_pageout.ph
> >vm/vm_pager.h -> vm/vm_pager.ph
> >vm/vm_param.h -> vm/vm_param.ph
> >vm/vm_prot.h -> vm/vm_prot.ph
> >vm/vm_zone.h -> vm/vm_zone.ph
> >vm/vnod
18 matches
Mail list logo
