en 2eae3be7 gen 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 ne
On Wed, Oct 20, 2010 at 01:11:20PM -0500, KAMADA Ken'ichi wrote:
>
> I had no crash for a week (two weeks if the "skip-wdstart" test is
> counted). Seems good. I'm back to -current.
>
It seems good to me too, no crashes. Prior to this I was getting a
crash at least once a day possibly more fr
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
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 your patch and will be back in a
> week or so. It will ta
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 ha
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 March 15.
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 March 15.
> I cannot repeat the panic reliably, but it seems to occur after
> suspend/resume (immediatel
> 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 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 wr
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.
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 usef
On Sat, Mar 20, 2010 at 04:06:32PM -0400, Steven Bellovin wrote:
> Of course, rejecting them wouldn't seem to do any good; what's needed,
> I suspect, is for the device to queue them (as usual) but not fire up
> the disk when in suspending mode.
Steven,
You're right. When a disk driver is suspen
On Mar 20, 2010, at 4:50 PM, Steven Bellovin wrote:
>
> 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 ins
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
>
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
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 activ
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
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 pani
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 (ROVE
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
20 matches
Mail list logo
