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
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 earlier
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 refclock for
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?
Yes,
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
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 #20:
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 MFC
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,
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
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 and
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
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
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?
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.
And
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's
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
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
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 assume it
* 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 always be called
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 :-) We need
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
21 matches
Mail list logo
