On 05-Jan-01 Kazutaka YOKOTA wrote:
> In order to declare a mutex which will be used before malloc(9)
> becomes available in the kernel, MUTEX_DECLARE() should be used, then
> it should be initialized by passing the MTX_COLD flag to mtx_init(),
> so that a statically allocated buffer will be used
> On Sat, Dec 30, 2000 at 03:13:24AM +1000, Andrew Kenneth Milton wrote:
> > Is there a nice way to stop vga_pci from attaching to my video card, or
> > to allow another driver to attach to it after vga_pci has done its thing?
> >
> > At the moment I'm removing all traces of vga_pci from the Make
In order to declare a mutex which will be used before malloc(9)
becomes available in the kernel, MUTEX_DECLARE() should be used, then
it should be initialized by passing the MTX_COLD flag to mtx_init(),
so that a statically allocated buffer will be used, instead of
malloc()ing a buffer, right?
Wi
I have a largely rewritten version of netgraph
ready for commit.
It is redesigned to work in an SMP "ouside the BGL" environment.
I have not completed it to the stage yet that it will run
without BGL yet but it's close and it's running stably.
I hope to commit this in about 24 hours (maybe
Jake
I applied the patch:
#define LPT_DEBUG
--- lpt.c Thu Dec 7 17:33:12 2000
+++ lpt.c.hack Thu Jan 4 00:46:41 2001
@@ -394,6 +394,7 @@
/* retrieve the ppbus irq */
BUS_READ_IVAR(ppbus, dev, PPBUS_IVAR_IRQ, &irq);
+#if 0
if (irq > 0) {
/* declare our interrupt handler */
sc->i
On Fri, 5 Jan 2001, The Hermit Hacker wrote:
>
> morning all ...
>
> running 5.0-CURRENT here, and found the other day that mcopidl
> started to segfault the other day in kdelibs (from CVS) ... this evening,
> someone brought up the possibility that its a threading issue, and
> suggested t
hi everybody and Happy New Year,
anybody to commit http://www.FreeBSD.org/cgi/query-pr.cgi?pr=19635 ?
one of the reasons it was not commited was due to an overflow problem
which has been fixed since.
thanks by advance..
Cyrille.
--
home: mailto:[EMAIL PROTECTED] work: mailto:[EMAIL PROTECTED]
morning all ...
running 5.0-CURRENT here, and found the other day that mcopidl
started to segfault the other day in kdelibs (from CVS) ... this evening,
someone brought up the possibility that its a threading issue, and
suggested taking -pthread out of the compile to see if it fixes it .
[[ This is drifting over into -arch, so I'm ccing there and asking
people to redirect there. ]]
[[ The context is what to do about certain kinds of locking with
pccard code raising the bigger issue of what to do with interrupts
and sleepers in a hostile environemnt ]]
In message <[EMAIL
In message <[EMAIL PROTECTED]> Will Andrews writes:
: > I'm still not sure about the shell environment actually buying
: > anything, but I could see how it might help.
:
: I'm not understanding what you're saying here.
I'm saying I agree with Garrett in that I don't see what checking for
valid s
On Thu, Jan 04, 2001 at 04:20:48PM -0700, Warner Losh wrote:
> First off, we do still have a significant part of the user base that
> is using older, slower machines. Many of them run embedded systems,
> some of which use apply(1). I have a big problem with this argument
> since it is doesn't un
In message <[EMAIL PROTECTED]> Will Andrews writes:
: What, exactly, are we trading off by making apply(1) a bit more
: paranoid? A couple extra cpu cycles? Maybe you haven't noticed, but
: these days there's almost nobody still using 100MHz chips. And out of
: the ones that do, how many will u
On Thu, Jan 04, 2001 at 02:09:53PM -0500, Garrett Wollman wrote:
> What is the reason for this change?
Paranoia. There's nothing wrong with a little extra paranoia in case
someone tries to use apply(1) through suidperl on a web interface.
Granted, it's not likely to happen, but you never know.
Well I seem to remember a post about the TAILQ_* macro's but I seemed to
have deleted it. My current freebsd source will not compile because of a
problem in mpool.c which is related to these macro's. If anyone has an
idea on this could you either forward the fix for the brokenness or repost
here?
On 04-Jan-01 Tomasz Paszkowski wrote:
>
>
> Current from 03.01.2001 have kernel panic (GENERIC kernel configuration to),
> when doing /etc/periodic/weekly/310.locate >& /dev/null
Can you build a kernel with 'DDB', 'INVARIANTS', 'INVARIANT_SUPPORT', and
'WITNESS' and get a backtrace when it p
Current from 03.01.2001 have kernel panic (GENERIC kernel configuration to),
when doing /etc/periodic/weekly/310.locate >& /dev/null
--
_ __ __
/ \ | | / / / \ / \ -- Tomasz Paszkowski --- NS88-6BONE
| |\ \| | \ \ |/ \||/ \| === BSD is for people w
Graham Wheeler <[EMAIL PROTECTED]> writes:
> Sometime back I submitted a short manual contribution about the
> kernel.conf file. I note that this hasn't found its way into the
> handbook; I'm attaching it to this message in the hope that someone will
> add it and commit it.
This should be a man p
I have a Sony VAIO PCG-Z600NE with an internal fxp0. I do not configure the
network in rc.conf as I do not want to launch dhclient unconditionnaly.
As long as the interface has not been brought up, I get errors when packets
are seen on it (well, I guess this is it, I receive approximately two
mes
Hi all
Sometime back I submitted a short manual contribution about the
kernel.conf file. I note that this hasn't found its way into the
handbook; I'm attaching it to this message in the hope that someone will
add it and commit it.
regards
gram
--
Dr Graham WheelerE-mail:
Sorry, me lame. I got distrcacted between committing usbdevs and its
derivative usbdevs.h.
I've committed the file and am doing a complete kernel build and will
commit uscanner.c 1.8 again after that.
Sorry.
Nick
On Thu, 4 Jan 2001, John Indra wrote:
> Dear all...
>
> Recent -CURRENT make b
On Thu, 04 Jan 2001 10:07:37 GMT, "Pierre Y. Dampure" wrote:
> If the goal is to make modifications in one place only (and that
> certainly seems to be the case, hence usbdev2h.awk), maybe what's
> required is a new field in the usbdevs table, so that the tables used by
> the various *.c get ge
On Thu, Jan 04, 2001 at 10:07:37AM +, Pierre Y. Dampure wrote:
>Hmmm. It looks like there were other bits missing... the MELCO LUATX
>entry was replaced in the last commit to usbdevs by two new entries,
>LUATX1 and LUATX5, but if_aue.c was not modified to reflect this. You
>need to do this ma
Hmmm. It looks like there were other bits missing... the MELCO LUATX
entry was replaced in the last commit to usbdevs by two new entries,
LUATX1 and LUATX5, but if_aue.c was not modified to reflect this. You
need to do this manually.
If the goal is to make modifications in one place only (and th
On Wed, Jan 03, 2001 at 10:00:22AM -0800, David O'Brien wrote:
> On Wed, Jan 03, 2001 at 05:54:26PM +0100, Nicolas Souchu wrote:
> > A program that previously worked (-current of November) with -pthread now
> > fails with an abort and a " in free(): error: recursive call" warning.
>
> I need a co
John Indra wrote:
>
> Dear all...
>
> Recent -CURRENT make buildkernel target died with this message:
>
> ===> uscanner
> cc -O -pipe -g -D_KERNEL -Wall -Wredundant-decls -Wnested-externs
> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline
> -Wcast-qual -fformat-extensions -a
Join
---
Pavel Bolotin
System Engineer
V6 Company
phone: 913-9313
[EMAIL PROTECTED]
---
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
26 matches
Mail list logo
