For now, p_mtx protects p_pgrp in struct proc. This is quite
troublesome for the following reason:
In some cases, we grab a p_pgrp via struct proc in order to, say,
access the session information of the process group. In other cases,
we traverse the members of a process group in order to, say, se
http://phk.freebsd.dk/patch/devfs.patch
20010522devfs.patch
This patch changes the way deletes are managed in DEVFS.
This fixes a number of warnings relating to removed cloned
devices.
It also makes it possible to recreate deleted devices with
Hi,
This is the same box which had the "panic: workitem_free: still on list"
and this looks related, except this time it went down with a kernel trap
type 12 in worklist_remove()
kernel cvsup approx 0300 GMT on Sunday.
DDB says:
worklist_remove(deadc0de)
free_diradd(deadc0de) <--
Hi,
I've seem to have the swap-related variety of this one:
panic: mutex vm not owned at ../../vm/vm_page.h:328
...from a kernel cvsup approx 0300 GMT on Sunday.
But I'm surprised. This box has 128MB and will rarely swap building world
(which is what it was doing). The only other oddity is tha
In article <[EMAIL PROTECTED]>,
Kris Kennaway <[EMAIL PROTECTED]> wrote:
> On Mon, May 21, 2001 at 06:26:40PM +0300, Ruslan Ermilov wrote:
> > Is there any sense at all in bumping __FreeBSD_version in -CURRENT?
> > (I would have liked to see FreeBSD 5.0-RELEASE go with 50.)
>
> I think so :-
* Dima Dorfman <[EMAIL PROTECTED]> [010521 20:02] wrote:
> David Malone <[EMAIL PROTECTED]> writes:
> > On Mon, May 21, 2001 at 01:44:16AM -0700, Dima Dorfman wrote:
> >
> > > exit1 calls shmexit with vm_mtx held on line 228 of kern_exit.c
> > > (rev. 1.127). Actually, shmexit_myhook should alwa
David Malone <[EMAIL PROTECTED]> writes:
> On Mon, May 21, 2001 at 01:44:16AM -0700, Dima Dorfman wrote:
>
> > exit1 calls shmexit with vm_mtx held on line 228 of kern_exit.c
> > (rev. 1.127). Actually, shmexit_myhook should always be called with
> > vm_mtx held, so shm_delete_mapping can't assu
On Mon, May 21, 2001 at 06:26:40PM +0300, Ruslan Ermilov wrote:
> Hi!
>
> Is there any sense at all in bumping __FreeBSD_version in -CURRENT?
> (I would have liked to see FreeBSD 5.0-RELEASE go with 50.)
I think so :-) We need the ability to feature test.
Kris
PGP signature
The reason it is failing is that the assigned IRQ is 0 or 255. If I
can't assume that that setup is done, I might as well start implementing
PCI resource allocation, because that is what is missing here.
The problem is not that the PCI device is not initialised, but that the
device is assigned a
On Mon, May 21, 2001 at 01:44:16AM -0700, Dima Dorfman wrote:
> exit1 calls shmexit with vm_mtx held on line 228 of kern_exit.c
> (rev. 1.127). Actually, shmexit_myhook should always be called with
> vm_mtx held, so shm_delete_mapping can't assume it isn't held.
The following seems to work. It'
>
> The bottom line is this; in your driver, ask for the resources that you
> need. If you don't get them, you fail. The PCI bus infrastructure is
> being worked on to improve your chances of getting these resources; it's
> not something that a driver writer should be worrying about per se.
> > > Could be, and I certainly don't know much about this code. But
> > > it seems like the driver is being given reason to assume it has a
> > > working device when it doesn't really have one. I assume the device
> > > is unusable without its interrupt, so shouldn't it fail at probe or
> > > a
On Mon, May 21, 2001 at 09:49:19PM +0200, The Unicorn wrote:
> Delete ports/www/jakarta-tomcat/files
> Updater failed: Cannot delete "/usr/ports/www/jakarta-tomcat/files": Directory not
>empty
As posted before:
rm -rf /usr/ports/www/jakarta-tomcat
re-cvsup
--
wca
To Unsubsc
I ran into a minor error in the doc for readv. I double
checked the kernel code and it checks against UIO_MAXIOV.
writev.2 is correct.
-john
Index: read.2
===
RCS file: /home/ncvs/src/lib/libc/sys/read.2,v
retrieving revision 1.
On 19-May-01 Matthew Thyer wrote:
> Is it possible that background fsck is not the culprit here ? I think
> this may be fallout from the dirpref changes as Chris Knight recently
> emailed in <018b01c0c496$07ed13d0$[EMAIL PROTECTED]>. The solution
> is to unmount all your filesystems, fsck them
Hi!
The below patch moves /sys/miscfs/* to /sys/fs.
Also, it installs missing headers to /usr/include
and removes explicit -I${.CURDIR}/../../sys lines
from various Makefiles.
For testers: the patch assumes that the repo-copy
of /sys/miscfs/* to /sys/fs has already been made,
so you will also ne
Hi!
Is there any sense at all in bumping __FreeBSD_version in -CURRENT?
(I would have liked to see FreeBSD 5.0-RELEASE go with 50.)
Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.65
>Date: Mon, 21 May 2001 17:15:32 +0300
>From: Ruslan Ermilov <[EMAIL PROTECTED]>
[I note that I included -current by mistake; I had intended to include
-stable. But since the thread has started dhw]
>On Mon, May 21, 2001 at 07:01:19AM -0700, David Wolfskill wrote:
>> Seems that perhaps the
On Mon, May 21, 2001 at 07:01:19AM -0700, David Wolfskill wrote:
> Seems that perhaps the MFC of some changes to mbuf.h also needed some
> corresponding changes elsewhere (such as netncp/ncp_rq.c).
>
> This is on a system running:
> FreeBSD dhcp-133.catwhisker.org 4.3-STABLE FreeBSD 4.3-STABLE #2
Seems that perhaps the MFC of some changes to mbuf.h also needed some
corresponding changes elsewhere (such as netncp/ncp_rq.c).
This is on a system running:
FreeBSD dhcp-133.catwhisker.org 4.3-STABLE FreeBSD 4.3-STABLE #20: Sun May 20 06:23:46
PDT 2001 [EMAIL PROTECTED]:/common/S2/obj/usr/s
> > Could be, and I certainly don't know much about this code. But
> > it seems like the driver is being given reason to assume it has a
> > working device when it doesn't really have one. I assume the device
> > is unusable without its interrupt, so shouldn't it fail at probe or
> > attach time
> > I tried Dima's patch (the one which Alfred has committed) and I
> > get an earlier mutex recursion panic, probably when a local progam
> > that uses shm forks and exits. I scribbled down this trace from
> > it:
> Is there such a program in the base system?
Nope - it's part of a radio refcloc
David Malone <[EMAIL PROTECTED]> writes:
> > Please try the attached patch. I make no claims of its correctness,
> > but this e-mail is coming to you via X on -current updated a few hours
> > ago so it works here :-).
>
> I tried Dima's patch (the one which Alfred has committed) and I
> get an e
> Please try the attached patch. I make no claims of its correctness,
> but this e-mail is coming to you via X on -current updated a few hours
> ago so it works here :-).
I tried Dima's patch (the one which Alfred has committed) and I
get an earlier mutex recursion panic, probably when a local p
24 matches
Mail list logo
