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 conflicts here.
Page faults will govm_mtx - vm_page_queues_mtx
The pageout code
[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
April. None has booted. Each dies with an integer
* 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 conflicts here.
* 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. :)
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 interface
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 hours
On Mon, 23 Apr 2001 21:51:31 -0700, Alfred Perlstein [EMAIL PROTECTED] 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
In message [EMAIL PROTECTED], Garrett Wollman write
s:
On Mon, 23 Apr 2001 21:51:31 -0700, Alfred Perlstein [EMAIL PROTECTED] 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
(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
* Poul-Henning Kamp [EMAIL PROTECTED] [010424 08:36] wrote:
In message [EMAIL PROTECTED], Garrett Wollman write
s:
On Mon, 23 Apr 2001 21:51:31 -0700, Alfred Perlstein [EMAIL PROTECTED] said:
You can find the work I've done so far to make a giant vm mutex
here:
The Mach code we
* 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.
This makes the struct netexport
* 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 package
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
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
increases the
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
April.
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?
Leif
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
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
* 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 good
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
can
# 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
] 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
] 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
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
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: PNP0303 can't assign resources
pca1: AT-style speaker sound at port 0x61 on isa0
WARNING: Driver mistake: repeat
Riccardo Torrini [EMAIL PROTECTED] writes:
pca1: AT-style speaker sound 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
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? ;-)
Well,
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 isn't any
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
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
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,
On Tue, 24 Apr 2001 16:19:59 -0700, Dima Dorfman [EMAIL PROTECTED] 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
[Followups to -questions, please.]
On Wed, 25 Apr 2001 01:58:00 +0200 (CEST), Riccardo Torrini [EMAIL PROTECTED]
said:
unknown: PNP0303 can't assign resources
Keyboard controller.
unknown: PNP0f13 can't assign resources
PS/2 mouse port.
unknown: PNP0501 can't assign resources
Serial
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
get Mach
34 matches
Mail list logo
