Am Sun, 19 Feb 2023 06:19:04 -0800
Rick Macklem schrieb:
> I committed a patch that would cause crashes if
> the system was using jails on Feb. 11, but it was
> fixed the next day. It bogusly had a prison_cleanup()
> method in it.
>
> But if you kernel wasn't from main on about Feb. 11
> or you
Hello,
most recent CURRENT crashes on shutdown from multiuser mode (singleuser mode,
used after
repairing failed FFS filesystems, is all right). The crashes go on since
roughly a 1/2 week
from now. The boxes involved are all cumtomized kernels (in most cases hard
linked modules
into kernel). Is
UEFI booting using the 11.0 CURRENT memstick.img causes the following error to
occur:
CODE: SELECT ALLFatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00;
fault virtual address = 0xe8b
fault code = supervisor write data, page not present
instruction pointer = 0x20:0xff
For a short notice:
I have a box that is at the moment stuck with r250670 since this is
version doesn't crash.
Every version above also most recent sources, coredump after several
seconds after the console login shows up with a lot of chat on the
screen regarding CAM and SCSI-like output.
This b
Date: Fri, 03 Oct 2003 05:03:34 -0600
From: Aaron Wohl <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: file system (UFS2) consistancy after -current crash?
After crashes recently ive been geting softupdate inconsistancies.
Directories in w
After crashes recently ive been geting softupdate inconsistancies.
Directories in which a file has recently been renamed have neither the
old file nor the new file. fsck -y recovers the inode and drops it in
lost in found.
I was under the impression that atomic rename() synced all the way to the
[formatting recovered]
On Mon, Apr 03, 2000 at 10:57:46AM +0100, Nick Hibma wrote:
> On Fri, 31 Mar 2000, Paul Haddad wrote:
> > On Wed, 22 Mar 2000, Christopher Masto wrote:
> > > I've been playing around with one of those iopener things and got
> > > myself into a state I thought I could get ou
; <[EMAIL PROTECTED]>; "Stephen Hocking-Senior
> Programmer PGS SPS Perth" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Wednesday, March 22, 2000 12:16 AM
> Subject: Re: Another current crash (cvs-cur.6183
>
>
> &g
hen Hocking-Senior
Programmer PGS SPS Perth" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, March 22, 2000 12:16 AM
Subject: Re: Another current crash (cvs-cur.6183
> On Wed, Mar 22, 2000 at 03:02:02AM +, Paul Richards wrote:
> &
At 4:14 PM -0800 2000/3/22, Matthew Dillon wrote:
> Frankly, I have INVARIANTS (and INVARIANT_SUPPORT) turned on by default
> on all of my kernels.
If it's this useful and this lightweight, may I suggest that we
change the descriptive text around it in the LINT kernel, and cop
Doug Barton wrote:
>
> What kind of overhead does it add? The warning messages in LINT
> look rather dire to me, but I'm interested in knowing the facts..
If you run current, by all means, use INVARIANTS. You'll find a few
selected persons, some even otherwise respectable, that will tell
:On Wed, 22 Mar 2000, Poul-Henning Kamp wrote:
:
:> But it might actually make a lot of sense to make INVARIANTS the
:> default this early in the -CURRENT cycle, protests ?
:
: What kind of overhead does it add? The warning messages in LINT
:look rather dire to me, but I'm interested in kno
On Wed, 22 Mar 2000, Poul-Henning Kamp wrote:
> But it might actually make a lot of sense to make INVARIANTS the
> default this early in the -CURRENT cycle, protests ?
What kind of overhead does it add? The warning messages in LINT
look rather dire to me, but I'm interested in knowing th
cvsup to 6 hours ago.
Fatal trap 12: page fault while in kernel mode
mp_lock = 0102; cpuid = 1; lapic.id = 0100
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc021ad98
stack pointer = 0x10:0xc87d0d88
fr
Fixed. The swap_pager "knew" that B_WRITE was zero. Not nice.
In message <[EMAIL PROTECTED]>, Peter Wemm writes
:
>Stephen Hocking-Senior Programmer PGS SPS Perth wrote:
>
>This one you need to tell phk about: this is one of his sanity checks
>that trapped and found an insane value. (and then
In message <[EMAIL PROTECTED]>, Paul Richards writes:
>Paul Richards wrote:
>>
>>
>> A few more details
>>
>> #11 0xc0167ae6 in biodone (bp=0xc3236250) at ../../kern/vfs_bio.c:2706
>> 2706(*b_iodone) (bp);
>>
>> #10 0xc01df583 in swp_pager_async_iodone (bp=0xc3236250)
>>
On Wed, Mar 22, 2000 at 03:02:02AM +, Paul Richards wrote:
> I've got a different but I think related panic.
>
> #9 0xc0143280 in panic (fmt=0xc0250460 "vm_page_wakeup: page not
> busy!!!")
> at ../../kern/kern_shutdown.c:552
> #10 0xc01df583 in swp_pager_async_iodone (bp=0xc3236250)
>
Paul Richards wrote:
>
>
> A few more details
>
> #11 0xc0167ae6 in biodone (bp=0xc3236250) at ../../kern/vfs_bio.c:2706
> 2706(*b_iodone) (bp);
>
> #10 0xc01df583 in swp_pager_async_iodone (bp=0xc3236250)
> at ../../vm/vm_page.h:346
> 346 KASSERT(m->flags &
Stephen Hocking-Senior Programmer PGS SPS Perth wrote:
>
> cvs-cur.6183 appeared to fix the crash I reported under disk activity & NFS
> but another one has reared its face, when using java with tya15 jit, running
> the Together java IDE.
>
> #0 boot (howto=256) at ../../kern/kern_shutdown.c:30
Stephen Hocking-Senior Programmer PGS SPS Perth wrote:
This one you need to tell phk about: this is one of his sanity checks
that trapped and found an insane value. (and then crashed since you didn't
have DDB)
> #8 0xc0255f21 in Debugger (msg=0xc027b1e8 "d_iocmd botch")
> at machine/cpufunc
cvs-cur.6183 appeared to fix the crash I reported under disk activity & NFS
but another one has reared its face, when using java with tya15 jit, running
the Together java IDE.
#0 boot (howto=256) at ../../kern/kern_shutdown.c:304
#1 0xc013d7e5 in panic (fmt=0xc0273534 "from debugger")
at .
My latest kernel with a cvsup as of around 5 minutes ago seems to have a
problem: Whenever I start xmms, it panics. The xmms window doesn't even
appear, the computer just locks, and I press enter a few times, and the
computer then reboots. I'm not sure why this happens, and I can't switch
out of X
:> that doesn't work, and there's any chance of getting a kernel dump,
:> try getting a kernel dump. Make sure you use a debug (compiled -g)
:> kernel.
:>
:
:While I can't say I truly see the correlation, you definitely know more
:about how it works then me. I've cvsupp'd and upped
> :If you notice, both times it crashed on vm_map_insert.
>
> Try bumping up PMAP_SHPGPERPROC. From LINT:
>
> #
> # Set the number of PV entries per process. Increasing this can
> # stop panics related to heavy use of shared memory. However, that can
> # (combined with large amounts of ph
:the timeout to kill it off because of the interactive mode. Otherwise
:there was ~960,000 accumulated exec()'s altogether in a 5 hour period.
:
:As you can see, cron is the process that crashed it. Two weeks ago it
:was an eggdrop. I've not had any crashes in -CURRENT while this program
:was not
While doing some testing (and actually, in the middle of me trying to
post some results) for the FreeBSD Auditing project, my 4.0-CURRENT box
crashed. These tests involved a barrage of automated exec() calls which
I suspect is what tore it down. I had a similar crash two weeks ago, but
did not hav
On Sunday, 17 October 1999 at 22:42:51 +0200, Michael Reifenberger wrote:
> Hi,
> I got the following crash since a couple of time since upgrading one machine to
> -current as of today. It seems to occurs during somewhat heavier diskaccess.
> Sorry no detailed backtrace for now because I deleted m
]>
>> Cc: FreeBSD-Current <[EMAIL PROTECTED]>
>> Subject: Re: -current crash
>>
>>
>> Doesn't tell *me* a lot maybe a broken driver that's a KLD? It looks
>> like something from spec_strategy is being called that's not in the
>> /kernel
Matthew Jacob <[EMAIL PROTECTED]>
>> Cc: FreeBSD-Current <[EMAIL PROTECTED]>
>> Subject: Re: -current crash
> ...
>> Have you rebuilt the kld?
>
> kernel,modules,world are in sync.
>
> The same configuration worked for several weeks without problems.
&
Matthew Jacob <[EMAIL PROTECTED]>, FreeBSD-Current <[EMAIL PROTECTED]>
>> Subject: Re: -current crash
> ...
>> OK, this is what I was afraid of. I'm committing some fixes.
>
> Thanks.
I'm leaving for the USA in a few hours. If you could test that
befo
On Sun, 17 Oct 1999, Julian Elischer wrote:
...
> the vinum module looks to have been the problem..
> not ethat you had stack elements at 0xc101exxx
> vinum starts at 0c1011000,
Yes.
But you are too late :-)
The fix is allready commited.
Bye!
Michael Reifenberger
Plaut Software GmbH, R/3 Bas
On Mon, 18 Oct 1999, Greg Lehey wrote:
> Date: Mon, 18 Oct 1999 13:40:27 +1300
> From: Greg Lehey <[EMAIL PROTECTED]>
> To: Michael Reifenberger <[EMAIL PROTECTED]>
> Subject: Re: -current crash
Ok, seems to be fixed.
A few stress tests which paniced reliable before do
the vinum module looks to have been the problem..
not ethat you had stack elements at 0xc101exxx
vinum starts at 0c1011000,
On Mon, 18 Oct 1999, Michael Reifenberger wrote:
> On Mon, 18 Oct 1999, Bernd Walter wrote:
> ...
> > What kind of modules were you running?
> (nullum)(root)# kldstat
> Id
On Mon, 18 Oct 1999, Greg Lehey wrote:
> Date: Mon, 18 Oct 1999 12:50:04 +1300
> From: Greg Lehey <[EMAIL PROTECTED]>
> To: Michael Reifenberger <[EMAIL PROTECTED]>
> Cc: Matthew Jacob <[EMAIL PROTECTED]>, FreeBSD-Current <[EMAIL PROTECTED]>
> Subject: Re:
On Mon, 18 Oct 1999, Bernd Walter wrote:
...
> On Mon, Oct 18, 1999 at 12:16:08AM +0200, Michael Reifenberger wrote:
> The combination of vinum raid5 and softupdates is known to trigger a bug
> which may look just as you described.
> I might help if you disable softupdates on the vinum volumes.
Ri
On Mon, Oct 18, 1999 at 12:16:08AM +0200, Michael Reifenberger wrote:
The combination of vinum raid5 and softupdates is known to trigger a bug
which may look just as you described.
I might help if you disable softupdates on the vinum volumes.
--
B.Walter COSMO-Project
On Mon, 18 Oct 1999, Greg Lehey wrote:
> Date: Mon, 18 Oct 1999 12:16:19 +1300
> From: Greg Lehey <[EMAIL PROTECTED]>
> To: Michael Reifenberger <[EMAIL PROTECTED]>,
Matthew Jacob <[EMAIL PROTECTED]>
> Cc: FreeBSD-Current <[EMAIL PROTECTED]>
> Sub
On Sun, 17 Oct 1999, Matthew Jacob wrote:
> Date: Sun, 17 Oct 1999 15:08:10 -0700 (PDT)
> From: Matthew Jacob <[EMAIL PROTECTED]>
> To: Michael Reifenberger <[EMAIL PROTECTED]>
> Cc: FreeBSD-Current <[EMAIL PROTECTED]>
> Subject: Re: -current crash
>
>
Try it w/o vinum, procfs and nfs kernel objects.
On Mon, 18 Oct 1999, Michael Reifenberger wrote:
> On Mon, 18 Oct 1999, Bernd Walter wrote:
> ...
> > What kind of modules were you running?
> (nullum)(root)# kldstat
> Id Refs AddressSize Name
> 17 0xc010 1eb518 kernel
> 2
On Mon, 18 Oct 1999, Bernd Walter wrote:
...
> What kind of modules were you running?
(nullum)(root)# kldstat
Id Refs AddressSize Name
17 0xc010 1eb518 kernel
21 0xc02ec000 cdbc bktr.ko
31 0xc1011000 c3000vinum.ko
41 0xc000 6000 procfs.ko
51 0
Doesn't tell *me* a lot maybe a broken driver that's a KLD? It looks
like something from spec_strategy is being called that's not in the
/kernel space- could be a KLD- are your KLDs up to date for the new
kernel? Like, is this vinum perhaps?
> On Sun, 17 Oct 1999, Matthew Jacob wrote:
> ...
On Sun, Oct 17, 1999 at 10:42:51PM +0200, Michael Reifenberger wrote:
[...]
> #3 0xc02117b1 in trap_pfault ()
> #4 0xc0211313 in trap ()
> #5 0xc101891b in ?? ()
> #6 0xc1018752 in ?? ()
> #7 0xc101854e in ?? ()
> #8 0xc0186a66 in spec_strategy ()
> #9 0xc018601d in spec_vnoperate ()
[...]
On Sun, 17 Oct 1999, Matthew Jacob wrote:
...
> Well, a DDB traceback would help. Failing that, at least what does
> 0xc101891b correspond to otherwise, it's all ENOGUESS
Next try, next crash. No problem. Easy crashing :-)
I tried to find the address 0xc101891b using nm(1) but can't seem
Well, a DDB traceback would help. Failing that, at least what does
0xc101891b correspond to otherwise, it's all ENOGUESS
On Sun, 17 Oct 1999, Michael Reifenberger wrote:
> Hi,
> I got the following crash since a couple of time since upgrading one machine to
> -current as of today. It s
Hi,
I got the following crash since a couple of time since upgrading one machine to
-current as of today. It seems to occurs during somewhat heavier diskaccess.
Sorry no detailed backtrace for now because I deleted my kernel.debug since the
last crash and dumping 256MB takes a long time...
Does
45 matches
Mail list logo
