2eae3be7^M
size 3000 blocks 18^M
ino 2830913 ipref 2826056^M
panic: ffs_valloc: dup alloc^M
cpu0: Begin traceback...^M
vpanic() at netbsd:vpanic+0x13c^M
snprintf() at netbsd:snprintf^M
ffs_valloc() at netbsd:ffs_valloc+0x889^M
ufs_makeinode() at netbsd:ufs_makeinode+0x5e^M
ufs_create() at netbsd:ufs_create
At Tue, 19 Oct 2010 22:37:52 +1030, Brett Lymn wrote:
On Wed, Oct 13, 2010 at 11:26:05AM -0500, KAMADA Ken'ichi wrote:
Yes, I was testing a similar patch to yours (skip calling wdstart()
when !device_is_active()) after my previous email. It did not crash
so far. I'm now running with
At Tue, 12 Oct 2010 11:34:03 -0500, David Young wrote:
On Tue, Oct 05, 2010 at 04:23:39PM -0500, KAMADA Ken'ichi wrote:
At Fri, 19 Mar 2010 17:51:46 -0500, myself wrote:
I'm seeing a panic: ffs_valloc: dup alloc.
Does anyone have a similar panic?
The kernel is -current from
Does stuffing a couple sync calls somewhere before it starts
suspending devices (wherever that is, I don't know) make the problems
go away?
I use ACPI S3 sleep, and sys_sync() is called in pmf_system_suspend()
from acpi_enter_sleep_state(). I'm not sure if it is late enough.
You're right.
On Mar 20, 2010, at 7:17 PM, David Holland wrote:
On Sat, Mar 20, 2010 at 05:03:16PM -0400, Steven Bellovin wrote:
Let me see if I can find my first note on the subject -- it might
give a clue about the date of any changes.
Turns out that I sendpr-ed it in September: kern/42104.
I even
On Sun, Mar 21, 2010 at 04:49:05PM -0400, Steven Bellovin wrote:
That sounds like maybe the problem is not on the suspend side but on
the resume side, that is, that stuff is being written out before (some
layer of) the disk subsystem is ready to go again. With vanilla FFS
such writes
On Fri, Mar 19, 2010 at 05:51:46PM -0500, KAMADA Ken'ichi wrote:
I'm seeing a panic: ffs_valloc: dup alloc.
Does anyone have a similar panic?
I have seen various file system panics after suspend/resume for quite
a while:
NetBSD rover 5.99.18 NetBSD 5.99.18 (ROVER2) #10: Tue Sep 29 08:18:23
On Mar 20, 2010, at 7:59 AM, Brett Lymn wrote:
On Fri, Mar 19, 2010 at 05:51:46PM -0500, KAMADA Ken'ichi wrote:
I'm seeing a panic: ffs_valloc: dup alloc.
Does anyone have a similar panic?
I have seen various file system panics after suspend/resume for quite
a while:
NetBSD rover
On Sat, Mar 20, 2010 at 10:29:44PM +1030, Brett Lymn wrote:
I have given up on suspending because my filesystems would be
corrupted with monotonous regularity. The chances of a corruption
seems to increase with the amount of disk activity happening on
suspend. It seems like something is
On Mar 20, 2010, at 3:49 PM, David Holland wrote:
On Sat, Mar 20, 2010 at 10:29:44PM +1030, Brett Lymn wrote:
I have given up on suspending because my filesystems would be
corrupted with monotonous regularity. The chances of a corruption
seems to increase with the amount of disk activity
On Sat, Mar 20, 2010 at 04:06:32PM -0400, Steven Bellovin wrote:
That suggests that something is flushing buffers to a device that's
suspended and it's throwing them away instead of rejecting them or
panicing.
Possibly
Although it doesn't quite make sense, because in most cases
On Mar 20, 2010, at 4:17 PM, David Holland wrote:
On Sat, Mar 20, 2010 at 04:06:32PM -0400, Steven Bellovin wrote:
That suggests that something is flushing buffers to a device that's
suspended and it's throwing them away instead of rejecting them or
panicing.
Possibly
Although it
On Sat, Mar 20, 2010 at 05:03:16PM -0400, Steven Bellovin wrote:
Let me see if I can find my first note on the subject -- it might
give a clue about the date of any changes.
Turns out that I sendpr-ed it in September: kern/42104.
I even responded to the PR, not that I had any useful
Hi,
I'm seeing a panic: ffs_valloc: dup alloc.
Does anyone have a similar panic?
The kernel is -current from March 15.
I cannot repeat the panic reliably, but it seems to occur after
suspend/resume (immediately or several minutes later).
The panic occured in /home, which is a ffs on cgd on wd
14 matches
Mail list logo
