On Tue, Apr 24, 2001 at 10:25:47PM +0200, Riccardo Torrini wrote:
> # man man
> Formatting page, please wait...mdoc error: end-macro (.em)
>respecification is not allowed. (#20)
>Should this have been `.Em ...'?
> User Abort.
> Done.
>
>
> This happens over last week. World of this nigh
Those who dial will know its meaning: 6545666,555,666,654555654
On Tue, 24 Apr 2001, Julian Elischer wrote:
> Poul-Henning Kamp wrote:
> >
>
> > I'm sure you are fully aware of the implications of the strategically
> > placed "supposed" in your own sentence. I have never heard anybody
> > g
Poul-Henning Kamp wrote:
>
> I'm sure you are fully aware of the implications of the strategically
> placed "supposed" in your own sentence. I have never heard anybody
> get Mach code multithreaded yet.
Mach has successfully run in multiprocessor multithreadded
systems since 1991.
>
--
[Followups to -questions, please.]
<
said:
> unknown: can't assign resources
Keyboard controller.
> unknown: can't assign resources
PS/2 mouse port.
> unknown: can't assign resources
Serial port whose settings conflict with one of your configured serial
ports.
> unknown: can't assign
< said:
> This is not a bug. This is an FAQ. So much that it's actually
> documented in (*gasp!*) the FAQ:
Unfortunately, the A in the FAQ is wrong.
The ``can't assign resources'' messages indicate that the devices are
legacy ISA devices for which a non-PnP-aware driver is compiled into
the k
Figured people running 5.0-CURRENT might be interested in this news -- I
know this is a feature we've been asked about frequently, and Chris has
done a great job in making it happen :-). There are still a few tweaks
being worked out in the ACL code, and we need to write some regression
tests, bu
Hi.
[I don't know if this belongs to current, but please be nice and fwd
this to the proper entity if needs be. Please also keep me as Cc: ]
I stumbled on this quite old pr today, looking for a fix for my problem
(see subject).
I can confirm that the fix works here. Just tested it on -stable
(4
On Tue, 24 Apr 2001, Terry Lambert wrote:
> It seems to me that these things are not boot-time tunable, and
> should be (really, they should be runtime tunable, but there
$ sysctl -a | grep maxf
kern.maxfiles: 360
kern.maxfilesperproc: 360
`maxfiles' and `maxfilesperproc' have been runtime tuna
On 24-Apr-01 (23:19:59/GMT) Dima Dorfman wrote:
>> WARNING: Driver mistake: repeat make_dev("pcaudio")
>> WARNING: Driver mistake: repeat make_dev("pcaudioctl")
> As it says, this is a driver mistake. It's a bug.
Ok. It happens from first days of devfs. I'm looking into
gnats but there i
Garance A Drosihn <[EMAIL PROTECTED]> writes:
> At 1:19 PM -0700 4/21/01, Dima Dorfman wrote:
> >Does that mean everyone is blind and missed my arrogant
> >cross-post of the amazingly short patch to do this, or
> >are we just interested in discussing it and not testing
> >the implementation? ;-)
>
Riccardo Torrini <[EMAIL PROTECTED]> writes:
> pca1: at port 0x61 on isa0
> WARNING: Driver mistake: repeat make_dev("pcaudio")
> WARNING: Driver mistake: repeat make_dev("pcaudioctl")
As it says, this is a driver mistake. It's a bug. I don't know if
it's new or not since I don't have an
I'm trying to understand why this happens at boot and if is
my fault (maybe), strange hardware or undocumented feature :)
isa0: unexpected small tag 14
unknown: can't assign resources
pca1: at port 0x61 on isa0
WARNING: Driver mistake: repeat make_dev("pcaudio")
WARNING: Driver mista
The ready-made PICOBSD-diskimages all seems to be based on FreeBSD 3.x
I also doesn't seem to be able to make picobsd from current sources, althugh I didn't
try that hard.
Is picobsd stale?
Leif
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of
] Why assign them the value of 0? Why not just stick them in the BSS?
] The SI_SUB_TUNABLE checks will initialize them to a value anyways..
Mostly, to leave them where I found them, for paranoia reasons.
Terry Lambert
] This looks good except that ncallout is still based on MAXFILES,
] without this being fixed I think people might get bitten by
] raising the tuneable too high then being unable to allocate
] enough callouts. Can you take a look at this and make sure there's
] nothing else using MAXFILES like th
# man man
Formatting page, please wait...mdoc error: end-macro (.em)
respecification is not allowed. (#20)
Should this have been `.Em ...'?
User Abort.
Done.
This happens over last week. World of this night (after
cvsup with also make kernel and mergemaster, for 4 times).
I have also trye
On 24-Apr-01 Terry Lambert wrote:
> It seems to me that these things are not boot-time tunable, and
> should be (really, they should be runtime tunable, but there
> are some nasty pageable region allocations for networking that
> appear to require contiguous regions for no good reason which I
> c
* Terry Lambert <[EMAIL PROTECTED]> [010424 11:59] wrote:
> It seems to me that these things are not boot-time tunable, and
> should be (really, they should be runtime tunable, but there
> are some nasty pageable region allocations for networking that
> appear to require contiguous regions for no
It seems to me that these things are not boot-time tunable, and
should be (really, they should be runtime tunable, but there
are some nasty pageable region allocations for networking that
appear to require contiguous regions for no good reason which I
can discern). That means that the best we can
On Tue, Apr 24, 2001 at 09:25:34AM -0700, Alfred Perlstein wrote:
> Sounds like some excellent work that was long over due. Go for it. :)
Agreed.
I've always found there are doc hackers willing to help with markup
problems on request, so I don't think that's a serious issue.
Kris
PGP signat
>
> I think the only path that we "officially" support is 3.x -> 3.4-stable ->
> 4.0-R -> 4.x-stable.
Is this official path described somewhere?
i.e. cvsup to RELENG_3
make world
make kernel
reboot
cvsup to ...
eg-
I've got a 3.2-release I'd like to update.
Perhaps I just should do a binary?
On 24-Apr-01 Gregory Bond wrote:
> [please CC replies; I'm not on the -current list]
>
> I'm trying to boot a -CURRENT kernel to confirm it really does fix a problem
> with my hardware (see kern/26046).
>
> I've tried a couple of snapshots from current.freeebsd.org between 1st the
> 15th
> Apr
Brian Somers <[EMAIL PROTECTED]> wrote:
>> If I'm not mistaken, the size of the environment is already
>> taken into account by the xargs utility (subtracted from
>> ARG_MAX). So this isn't an issue at all.
>
> Unless xargs runs a command with lots of arguments and that command
> increase
> The Mach code we originally inherited was supposed to already by
> multiprocessor safe. Did we manage to eliminate that capability?
Yes and no. The vm_map layer still has the necessary locking calls,
but the vm_object and pmap layers don't. The pmap is still similar
enough that the original
* Bruce A. Mah <[EMAIL PROTECTED]> [010424 09:04] wrote:
> (Apologies to -doc people who have probably heard this ad nauseum.)
>
> Over the past few months, I've been working on a project that I've
> taken to calling RELNOTESng, which is the overhaul of RELNOTES.TXT and
> related files that we pa
* Poul-Henning Kamp <[EMAIL PROTECTED]> [010424 03:08] wrote:
>
> http://phk.freebsd.dk/patch/export.patch
>
> 20010424export.patch
>
> This patch moves the netexport structure from the fs-specific
> mountstructure to struct mount.
>
&g
* Poul-Henning Kamp <[EMAIL PROTECTED]> [010424 08:36] wrote:
> In message <[EMAIL PROTECTED]>, Garrett Wollman write
> s:
> >< said:
> >
> >> You can find the work I've done so far to make a giant vm mutex
> >> here:
> >
> >The Mach code we originally inherited was supposed to already by
> >multi
(Apologies to -doc people who have probably heard this ad nauseum.)
Over the past few months, I've been working on a project that I've
taken to calling RELNOTESng, which is the overhaul of RELNOTES.TXT and
related files that we package along with a FreeBSD distribution.
I've been soliciting feedb
In message <[EMAIL PROTECTED]>, Garrett Wollman write
s:
>< said:
>
>> You can find the work I've done so far to make a giant vm mutex
>> here:
>
>The Mach code we originally inherited was supposed to already by
>multiprocessor safe. Did we manage to eliminate that capability?
I'm sure you are f
< said:
> You can find the work I've done so far to make a giant vm mutex
> here:
The Mach code we originally inherited was supposed to already by
multiprocessor safe. Did we manage to eliminate that capability?
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe free
John Baldwin <[EMAIL PROTECTED]> wrote:
>> my current kernel cvsupped around Apr 14th tells me about
>> duplicate locks and lock order reversal. Is this reason to worry?
> This is a FAQ. Please keep up with -current if you are tracking it.
That's simply impossible. We would need another 24 ho
http://phk.freebsd.dk/patch/export.patch
20010424export.patch
This patch moves the netexport structure from the fs-specific
mountstructure to struct mount.
This makes the "struct netexport *" paramter to the vfs_export
and vfs_checkexport
* Alfred Perlstein <[EMAIL PROTECTED]> [010423 21:51] wrote:
> You can find the work I've done so far to make a giant vm mutex
> here:
>
> http://people.freebsd.org/~alfred/vm.diff
I've refreshed the diff, it now makes it to:
vfs_default.c 545 <- recurses on vm_mtx here, oops. :)
vop_stdcreate
* Rik van Riel <[EMAIL PROTECTED]> [010423 23:27] wrote:
> On Mon, 23 Apr 2001, Alfred Perlstein wrote:
>
> > requires vm_page_queues_mtx:
> > manipulation of vm_page_queues
>
> [snip]
>
> > pmaps spotted:
> > pmap_copy_page
> > pmap_page_protect
>
> There is potential for nasty lock ordering
34 matches
Mail list logo
