https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
Wolfram Schneider changed:
What|Removed |Added
Resolution|--- |Unable to Reproduce
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #33 from o...@j.email.ne.jp ---
(In reply to ota from comment #32)
I removed the bottom/2nd swapoff_all() since the above post and testing ( I
shutdown multiple times in a day ) but haven't had any issues such as panic or
any da
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #32 from o...@j.email.ne.jp ---
(In reply to Conrad Meyer from comment #31)
if tmpfs uses large memory so that files on tmpfs were swapped out, the 1st
swapoff_all() can fail due to insufficient memory.
vfs_unmountall() will un
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #31 from Conrad Meyer ---
(In reply to Conrad Meyer from comment #30)
One other comment: Should the existing swapoff_all() call at the end of
bufshutdown() should be deleted if we are moving the call higher up? Or is
there valu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #30 from Conrad Meyer ---
(In reply to ota from comment #29)
Why is this line changed? It seems gratuitous:
> static TAILQ_HEAD(swdevt_head, swdevt) swtailq =
> TAILQ_HEAD_INITIALIZER(swtailq);
Second: Can swapoff_all be mov
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
o...@j.email.ne.jp changed:
What|Removed |Added
Attachment #189605|0 |1
is obsolete|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #28 from Conrad Meyer ---
(In reply to ota from comment #27)
Patch seems incomplete. There is a mismatched brace added in swapoff_all.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #27 from o...@j.email.ne.jp ---
Created attachment 189605
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=189605&action=edit
swapoff, umount, swapoff
Primary target of the patch is for NFS swapfiles but also reduces ch
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
Wolfram Schneider changed:
What|Removed |Added
Blocks||224975
Referenced Bugs:
http
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #26 from o...@j.email.ne.jp ---
(In reply to Wolfram Schneider from comment #21)
shutdown case is taken care by
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187081 - swaplate
"reboot" doesn't call this as you discover.
--
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #25 from o...@j.email.ne.jp ---
Isn't this problem because "umount" happens before "swapoff"?
I also use NFS swapfiles from time to time and when I forget to swapoff such
files before shutdown, kernel panics, too.
# mount -t nf
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #24 from Mark Millard ---
(In reply to Andriy Gapon from comment #23)
[Ignore if you care not for my history and
opinion for swapfile usage vs. partition
usage.]
I will note that when I ran into the deadlock
problems from usin
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #23 from Andriy Gapon ---
I have a feeling that the current design for the file-backed swap is broken.
--
You are receiving this mail because:
You are the assignee for the bug.
___
f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #22 from Konstantin Belousov ---
(In reply to Conrad Meyer from comment #20)
Because we do not enforce a policy in the kernel on the possible md(4) usage.
Even assuming that we do, we would need
(a) teach VFS to see through md(
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #21 from Wolfram Schneider ---
(In reply to Mark Millard from comment #13)
Hi Mark,
good point about "reboot" <-> "shutdown -r now". The handbook recommends to use
shutdown. My bad.
I tried shutdown -r now on the console and
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #20 from Conrad Meyer ---
(In reply to Konstantin Belousov from comment #18)
Re: (1) If the database is owned and operated by the kernel, YES.
Why not swapoff any such vnode backed file before reclaiming the vnode, or at
least
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #19 from Mark Millard ---
(In reply to Konstantin Belousov from comment #18)
It is probably not clear about my notes (other
and shutdown -r now vs. reboot testing directly):
My experience was deadlocks during normal operation
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #18 from Konstantin Belousov ---
(In reply to Andriy Gapon from comment #15)
This is perhaps going too far on the silly fest. Andrey, you do understand
VFS, so I am quite frustrated.
1. If the vnode carriers some database, sho
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #17 from Conrad Meyer ---
(In reply to Andriy Gapon from comment #15)
+1 to all of this. We know what devices/files are used for swap and should be
able to prevent this panic for user-initiated action like umount.
--
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #16 from Mark Millard ---
(In reply to Konstantin Belousov from comment #14)
You have written in the past that for file based
(vnode-based) swap files the system is deadlock
prone in a manor not under significant user control.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #15 from Andriy Gapon ---
(In reply to Konstantin Belousov from comment #14)
On the other hand, if the kernel knows that a vnode is used for swap and the
kernel knows that the force reclaim of that vnode will lead to a panic, th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #14 from Konstantin Belousov ---
(In reply to Mark Millard from comment #13)
There is no race, the system behaves as it supposed to. If swap storage is
revoked, the swap in procedure panics. I am not sure that trying to conver
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #13 from Mark Millard ---
(In reply to Wolfram Schneider from comment #12)
Does the problem happen for:
shutdown -r now
instead of reboot?
I ask because the man page for reboot says that
reboot does not cleanly shut down all
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #12 from Wolfram Schneider ---
(In reply to Konstantin Belousov from comment #11)
the complain is: I built and installed a new kernel on 12-current. I run
"reboot" and the kernel panics during shutdown and hangs in the kernel d
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #11 from Konstantin Belousov ---
I do not quite understand what a cause for the complain is. If the system
cannot get the swapped out page data on swapoff, this means that the data is
corrupted. Preventing further user data co
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
Wolfram Schneider changed:
What|Removed |Added
Blocks||206048
Referenced Bugs:
http
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
Mark Millard changed:
What|Removed |Added
CC||mar...@dsl-only.net
--- Comment #10
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #9 from Wolfram Schneider ---
(In reply to Wolfram Schneider from comment #4)
I do not see the kernel panic if there are more than 100MB swap space in use.
So, we have a lower bound of 10MB and and upper bound of 100MB swap usa
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #8 from Peter Holm ---
(In reply to Doug Moore from comment #7)
The scenario is:
- Use a vnode backed memory disk as swap device.
- unmount the file system containing the vnode.
The problem is also seen with an old 10.3-STABLE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
Mark Linimon changed:
What|Removed |Added
Keywords||patch
--
You are receiving this ma
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #7 from Doug Moore ---
I don't have the means to reproduce this bug. For someone who does (Peter?),
could you possibly add this assertion to the code and see if the conditions
that trigger the bug trigger the assertion first?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #6 from Wolfram Schneider ---
(In reply to Peter Holm from comment #3)
Peter, can you repeat the stress test with the mount flag sync (mount -o sync
/mnt) for the filesystem with the active swap file? Thanks.
--
You are recei
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #5 from Wolfram Schneider ---
Older, similar reports:
FreeBSD 7.x/8.0
http://www.bsdportal.ru/viewtopic.php?p=137518
FreeBSD 9.3
http://forum.lissyara.su/viewtopic.php?t=43340
FreeBSD 6.x
http://www.bsdforen.de/threads/swap_p
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #4 from Wolfram Schneider ---
Note: it seems that you need some swap space in use. 5MB may be not enough,
make sure you use at least 10-20MB
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
Wolfram Schneider changed:
What|Removed |Added
Status|New |Open
--
You are receiving thi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #3 from Peter Holm ---
I can repeat this with:
Unmount a file system with an active swap file.
Details @ https://people.freebsd.org/~pho/stress/log/swapoff2.txt
--
You are receiving this mail because:
You are the assignee for
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #2 from Wolfram Schneider ---
the suspect commit is:
commit c123c7433b7eb3ccacfa1bae8ae136c61cfe8462
Author: alc
Date: Tue Nov 28 17:46:03 2017 +
When the swap pager allocates space on disk, it requests contiguous
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
Wolfram Schneider changed:
What|Removed |Added
URL||https://reviews.freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #1 from Wolfram Schneider ---
here are screen shots from the VNC console:
https://people.freebsd.org/~wosch/tmp/pr-224479/swapoff-device.png
https://people.freebsd.org/~wosch/tmp/pr-224479/swapoff-file.png
--
You are receivin
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
Bug ID: 224479
Summary: kernel panic in reboot+swapoff sys call
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Af
40 matches
Mail list logo
