Re: panic: softdep_deallocate_dependencies
On 05/09/14 00:05, Ted Unangst wrote: On Thu, May 08, 2014 at 17:59, STeve Andre' wrote: Twice now in three or so weeks, I've gotten a panic on my -current_amd64 W500 laptop. I've updated my tree several times during this time, and have not seen other problems besides the known acpi heat problem. Thanks, I think we've fixed this. Really! I'll update/compile and start beating on stuff with ff and chrome tonight. --STeve
Re: panic: softdep_deallocate_dependencies
On 05/08/14 23:41, Philip Guenther wrote:
On Thu, May 8, 2014 at 8:14 PM, STeve Andre' wrote:
On 05/08/14 22:43, Philip Guenther wrote:
On Thu, May 8, 2014 at 2:59 PM, STeve Andre' wrote:
Twice now in three or so weeks, I've gotten a panic on my -current_amd64
W500 laptop. I've updated my tree several times during this time, and
have
not seen other problems besides the known acpi heat problem.
Uh, what was the date of the cvs update of your kernel build when they
started? What was the cvs update date of your kernel before *that*?
(I.e,
what's your best estimate of the window in which the change to the kernel
which triggered the panic occurred?
(What, you don't keep a log of the timestamps of your kernel
updates+builds? Doesn't everyone?)
Actually, I do keep past kernels so I have the build date for them.
I *thought* I had some notes on when this started but I am
ashamed to see that I didn't put them in a safe place.
Well, make your best, but conservative estimate of the window in which it
started. ("Certainly after _that_ kernel; not sure if before _this_ kernel
but certainly before this+1...")
This first occurred after I created an April 16th kernel. I'm
pretty sure of that.
I have both firefox and chrome running but I'm getting the feeling that
things
get more weird as I use lots of tabs in chrome.
You're pushing the vm subsystem enough to page. Since you have 8GB, I
wonder if you've raised yourkern.bufcachepercent, thus pushing on it
harder.
Nope, I try to avoid the knobs when possible. It's been at 20%
ever since (bob?) raised it to 20%.
Ok. I guess it's just memory pressure from chrome.
I don't think I'm swapping? At least I haven't seen top tell me that.
...In the past (like a year+) ago, there were times when chrome
went crazy with memory and I did swap. But chrome has gotten
better--I don't think I've seen it do that for some time now.
Heh, the backtrace starts from "uvm_pageout" so yes, it decided to page
*DUH*. sigh. Still recovering from Penguicon or something. Well,
that would be consistent with chrome's rabbid usage of memory
from time to time.
I'm going to test stuff after a rebuild of the world, re Ted's comments.
something out. :-)
I'm not sure how well I can pin this down. If I go too far back with
an older kernel I'll be out of sync with userland. Any suggestions
on how to test this more?
I don't recall any kernel ABI changes in the window, but hold off for now.
Eyes more familiar with the involved subsystem may consider the backtrace
you gave (thanks!) enough.
Philip Guenther
--STeve
Re: panic: softdep_deallocate_dependencies
On 05/08/14 22:43, Philip Guenther wrote:
On Thu, May 8, 2014 at 2:59 PM, STeve Andre' wrote:
Twice now in three or so weeks, I've gotten a panic on my -current_amd64
W500 laptop. I've updated my tree several times during this time, and have
not seen other problems besides the known acpi heat problem.
Uh, what was the date of the cvs update of your kernel build when they
started? What was the cvs update date of your kernel before *that*? (I.e,
what's your best estimate of the window in which the change to the kernel
which triggered the panic occurred?
(What, you don't keep a log of the timestamps of your kernel
updates+builds? Doesn't everyone?)
Actually, I do keep past kernels so I have the build date for them.
I *thought* I had some notes on when this started but I am
ashamed to see that I didn't put them in a safe place.
I have both firefox and chrome running but I'm getting the feeling that
things
get more weird as I use lots of tabs in chrome.
You're pushing the vm subsystem enough to page. Since you have 8GB, I
wonder if you've raised yourkern.bufcachepercent, thus pushing on it harder.
Nope, I try to avoid the knobs when possible. It's been at 20%
ever since (bob?) raised it to 20%.
I don't think I'm swapping? At least I haven't seen top tell me that.
...In the past (like a year+) ago, there were times when chrome
went crazy with memory and I did swap. But chrome has gotten
better--I don't think I've seen it do that for some time now.
panic: softdep_deallocate_dependencies: dangling deps
Stopped at Debugger+0x5: leave
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
IF RUNNING SMP, USE 'mach ddbcpu <#>' AND 'trace' ON OTHER PROCESSORS, TOO.
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb{1}> ddb{1}> Debugger() at Debugger+0x5
panic() at panic+0xfe
softdep_deallocate_dependencies() at softdep_deallocate_dependencies+0x1b
brelse() at brelse+0x61
ffs_write() at ffs_write+0x419
VOP_WRITE() at VOP_WRITE+0x3f
uvn_io() at uvn_io+0x1a0
uvm_pager_put() at uvm_pager_put+0x92
uvmpd_scan_inactive() at uvmpd_scan_inactive+0x5a3
uvmpd_scan() at uvmpd_scan+0x6e
uvm_pageout() at uvm_pageout+0x5b
This is *likely* to be a bug in the "don't cache pages being paged out"
commit, but it would be nice to be sure it didn't start before then...
Philip Guenther
I'm not sure how well I can pin this down. If I go too far back with
an older kernel I'll be out of sync with userland. Any suggestions
on how to test this more?
Thanks!
--STeve Andre'
Re: panic: softdep_deallocate_dependencies
On 08.05.2014 23:59, STeve Andre' wrote:
Twice now in three or so weeks, I've gotten a panic on my
-current_amd64
W500 laptop. I've updated my tree several times during this time,
and have
not seen other problems besides the known acpi heat problem.
I have both firefox and chrome running but I'm getting the feeling
that things
get more weird as I use lots of tabs in chrome.
OT - Quite funny and interesting description of modern browsers :-)
https://www.usenix.org/system/files/1403_02-08_mickens.pdf
I don't think it matters but my boot disk is a 960g Crucial SSD.
--STeve Andre'
panic: softdep_deallocate_dependencies: dangling deps
Stopped at Debugger+0x5: leave
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS
PANIC!
IF RUNNING SMP, USE 'mach ddbcpu <#>' AND 'trace' ON OTHER
PROCESSORS, TOO.
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb{1}> ddb{1}> Debugger() at Debugger+0x5
panic() at panic+0xfe
softdep_deallocate_dependencies() at
softdep_deallocate_dependencies+0x1b
brelse() at brelse+0x61
ffs_write() at ffs_write+0x419
VOP_WRITE() at VOP_WRITE+0x3f
uvn_io() at uvn_io+0x1a0
uvm_pager_put() at uvm_pager_put+0x92
uvmpd_scan_inactive() at uvmpd_scan_inactive+0x5a3
uvmpd_scan() at uvmpd_scan+0x6e
uvm_pageout() at uvm_pageout+0x5b
end trace frame: 0x0, count: -11
ddb{1}> CPU not specified
ddb{1}> Stopped at Debugger+0x5: leave
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS
PANIC!
IF RUNNING SMP, USE 'mach ddbcpu <#>' AND 'trace' ON OTHER
PROCESSORS, TOO.
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb{0}> Stopped at Debugger+0x5: leave
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS
PANIC!
IF RUNNING SMP, USE 'mach ddbcpu <#>' AND 'trace' ON OTHER
PROCESSORS, TOO.
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb{1}> Debugger() at Debugger+0x5
panic() at panic+0xfe
softdep_deallocate_dependencies() at
softdep_deallocate_dependencies+0x1b
brelse() at brelse+0x61
ffs_write() at ffs_write+0x419
VOP_WRITE() at VOP_WRITE+0x3f
uvn_io() at uvn_io+0x1a0
uvm_pager_put() at uvm_pager_put+0x92
uvmpd_scan_inactive() at uvmpd_scan_inactive+0x5a3
uvmpd_scan() at uvmpd_scan+0x6e
uvm_pageout() at uvm_pageout+0x5b
end trace frame: 0x0, count: -11
ddb{1}> Debugger() at Debugger+0x5
end trace frame: 0x80002207cab0, count: 0
ddb{1}>PID PPID PGRPUID S FLAGS WAIT COMMAND
27484 1 27484 0 30x80 poll ftpd
11680 15813 11680 1000 30x83 ttyin ksh
15813 6621 3503 1000 30xb2 select xterm
16802 4523 16802 1000 30x83 ttyin ksh
4523 6621 3503 1000 30xb2 select xterm
27410 18597 3503 1000 30x82 thrsleep chrome
7576 18597 3503 1000 3 0x482 kqread chrome
16218 18597 3503 1000 3 0x482 thrsleep chrome
658 18597 3503 1000 3 0x482 thrsleep chrome
7989 18597 3503 1000 3 0x482 thrsleep chrome
11847 18597 3503 1000 3 0x482 thrsleep chrome
20010 18597 3503 1000 2 0x482 chrome
15059 18597 3503 1000 3 0x482 kqread chrome
27259 18597 3503 1000 3 0x482 thrsleep chrome
20832 18597 3503 1000 3 0x482 thrsleep chrome
26369 18597 3503 1000 3 0x482 thrsleep chrome
4610 18597 3503 1000 3 0x482 thrsleep chrome
13262 18597 3503 1000 3 0x482 thrsleep chrome
8575 18597 3503 1000 3 0x482 netio chrome
7173 18597 3503 1000 2 0x4000482 chrome
29279 18597 3503 1000 3 0x482 thrsleep chrome
17470 18597 3503 1000 2 0x4000482 chrome
28899 18597 3503 1000 3 0x482 thrsleep chrome
29261 18597 3503 1000 30x82 thrsleep chrome
10383 18597 3503 1000 3 0x482 kqread chrome
26250 18597 3503 1000 3 0x482 thrsleep chrome
29984 18597 3503 1000 3 0x482 thrsleep chrome
1661 18597 3503 1000 3 0x482 thrsleep chrome
26874 18597 3503 1000 3 0x482 thrsleep chrome
18381 18597 3503 1000 2 0x482 chrome
22068 18597 3503 1000 3 0x482 kqread chrome
5164 18597 3503 1000 3 0x482 thrsleep chrome
3419 18597 3503 1000 3 0x482 thrsleep chrome
11293 18597 3503 1000 3 0x482 thrsleep chrome
14060 18597 3503 1000 3 0x482 thrsleep chrome
15908 18597 3503 1000 30x82 thrsleep chrome
22526 18597 3503 1000 3 0x482 kqread chrome
3139 18597 3503 1000 3 0x482 thrsleep chrome
16815 18597 3503 1000 3 0x482 thrsleep chrome
9024 18597 3503 1000 3 0x400
Re: panic: softdep_deallocate_dependencies
On Thu, May 08, 2014 at 17:59, STeve Andre' wrote: > Twice now in three or so weeks, I've gotten a panic on my -current_amd64 > W500 laptop. I've updated my tree several times during this time, and have > not seen other problems besides the known acpi heat problem. Thanks, I think we've fixed this.
Re: panic: softdep_deallocate_dependencies
I'll be taking a peek based on what I see in his traceback. Travelling at
the moment.
On 9 May 2014 06:44, "Philip Guenther" wrote:
> On Thu, May 8, 2014 at 8:14 PM, STeve Andre' wrote:
>
> > On 05/08/14 22:43, Philip Guenther wrote:
> >
> >> On Thu, May 8, 2014 at 2:59 PM, STeve Andre' wrote:
> >>
> >> Twice now in three or so weeks, I've gotten a panic on my
> -current_amd64
> >>> W500 laptop. I've updated my tree several times during this time, and
> >>> have
> >>> not seen other problems besides the known acpi heat problem.
> >>>
> >>> Uh, what was the date of the cvs update of your kernel build when they
> >> started? What was the cvs update date of your kernel before *that*?
> >> (I.e,
> >> what's your best estimate of the window in which the change to the
> kernel
> >> which triggered the panic occurred?
> >>
> >> (What, you don't keep a log of the timestamps of your kernel
> >> updates+builds? Doesn't everyone?)
> >>
> >
> > Actually, I do keep past kernels so I have the build date for them.
> > I *thought* I had some notes on when this started but I am
> > ashamed to see that I didn't put them in a safe place.
>
>
> Well, make your best, but conservative estimate of the window in which it
> started. ("Certainly after _that_ kernel; not sure if before _this_ kernel
> but certainly before this+1...")
>
> I have both firefox and chrome running but I'm getting the feeling that
> >>
> >>> things
> >>> get more weird as I use lots of tabs in chrome.
> >>>
> >>> You're pushing the vm subsystem enough to page. Since you have 8GB, I
> >> wonder if you've raised yourkern.bufcachepercent, thus pushing on it
> >> harder.
> >>
> >
> > Nope, I try to avoid the knobs when possible. It's been at 20%
> > ever since (bob?) raised it to 20%.
> >
>
> Ok. I guess it's just memory pressure from chrome.
>
>
>
> > I don't think I'm swapping? At least I haven't seen top tell me that.
> >
>
> > ...In the past (like a year+) ago, there were times when chrome
> > went crazy with memory and I did swap. But chrome has gotten
> > better--I don't think I've seen it do that for some time now.
>
>
> Heh, the backtrace starts from "uvm_pageout" so yes, it decided to page
> something out. :-)
>
>
>
> > I'm not sure how well I can pin this down. If I go too far back with
> > an older kernel I'll be out of sync with userland. Any suggestions
> > on how to test this more?
> >
>
> I don't recall any kernel ABI changes in the window, but hold off for now.
> Eyes more familiar with the involved subsystem may consider the backtrace
> you gave (thanks!) enough.
>
>
> Philip Guenther
Re: panic: softdep_deallocate_dependencies
On Thu, May 8, 2014 at 8:14 PM, STeve Andre' wrote:
> On 05/08/14 22:43, Philip Guenther wrote:
>
>> On Thu, May 8, 2014 at 2:59 PM, STeve Andre' wrote:
>>
>> Twice now in three or so weeks, I've gotten a panic on my -current_amd64
>>> W500 laptop. I've updated my tree several times during this time, and
>>> have
>>> not seen other problems besides the known acpi heat problem.
>>>
>>> Uh, what was the date of the cvs update of your kernel build when they
>> started? What was the cvs update date of your kernel before *that*?
>> (I.e,
>> what's your best estimate of the window in which the change to the kernel
>> which triggered the panic occurred?
>>
>> (What, you don't keep a log of the timestamps of your kernel
>> updates+builds? Doesn't everyone?)
>>
>
> Actually, I do keep past kernels so I have the build date for them.
> I *thought* I had some notes on when this started but I am
> ashamed to see that I didn't put them in a safe place.
Well, make your best, but conservative estimate of the window in which it
started. ("Certainly after _that_ kernel; not sure if before _this_ kernel
but certainly before this+1...")
I have both firefox and chrome running but I'm getting the feeling that
>>
>>> things
>>> get more weird as I use lots of tabs in chrome.
>>>
>>> You're pushing the vm subsystem enough to page. Since you have 8GB, I
>> wonder if you've raised yourkern.bufcachepercent, thus pushing on it
>> harder.
>>
>
> Nope, I try to avoid the knobs when possible. It's been at 20%
> ever since (bob?) raised it to 20%.
>
Ok. I guess it's just memory pressure from chrome.
> I don't think I'm swapping? At least I haven't seen top tell me that.
>
> ...In the past (like a year+) ago, there were times when chrome
> went crazy with memory and I did swap. But chrome has gotten
> better--I don't think I've seen it do that for some time now.
Heh, the backtrace starts from "uvm_pageout" so yes, it decided to page
something out. :-)
> I'm not sure how well I can pin this down. If I go too far back with
> an older kernel I'll be out of sync with userland. Any suggestions
> on how to test this more?
>
I don't recall any kernel ABI changes in the window, but hold off for now.
Eyes more familiar with the involved subsystem may consider the backtrace
you gave (thanks!) enough.
Philip Guenther
Re: panic: softdep_deallocate_dependencies
On Thu, May 8, 2014 at 2:59 PM, STeve Andre' wrote:
> Twice now in three or so weeks, I've gotten a panic on my -current_amd64
> W500 laptop. I've updated my tree several times during this time, and have
> not seen other problems besides the known acpi heat problem.
>
Uh, what was the date of the cvs update of your kernel build when they
started? What was the cvs update date of your kernel before *that*? (I.e,
what's your best estimate of the window in which the change to the kernel
which triggered the panic occurred?
(What, you don't keep a log of the timestamps of your kernel
updates+builds? Doesn't everyone?)
I have both firefox and chrome running but I'm getting the feeling that
> things
> get more weird as I use lots of tabs in chrome.
>
You're pushing the vm subsystem enough to page. Since you have 8GB, I
wonder if you've raised yourkern.bufcachepercent, thus pushing on it harder.
> panic: softdep_deallocate_dependencies: dangling deps
> Stopped at Debugger+0x5: leave
> RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
> IF RUNNING SMP, USE 'mach ddbcpu <#>' AND 'trace' ON OTHER PROCESSORS, TOO.
> DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
> ddb{1}> ddb{1}> Debugger() at Debugger+0x5
> panic() at panic+0xfe
> softdep_deallocate_dependencies() at softdep_deallocate_dependencies+0x1b
> brelse() at brelse+0x61
> ffs_write() at ffs_write+0x419
> VOP_WRITE() at VOP_WRITE+0x3f
> uvn_io() at uvn_io+0x1a0
> uvm_pager_put() at uvm_pager_put+0x92
> uvmpd_scan_inactive() at uvmpd_scan_inactive+0x5a3
> uvmpd_scan() at uvmpd_scan+0x6e
> uvm_pageout() at uvm_pageout+0x5b
>
This is *likely* to be a bug in the "don't cache pages being paged out"
commit, but it would be nice to be sure it didn't start before then...
Philip Guenther
panic: softdep_deallocate_dependencies
Twice now in three or so weeks, I've gotten a panic on my -current_amd64
W500 laptop. I've updated my tree several times during this time, and have
not seen other problems besides the known acpi heat problem.
I have both firefox and chrome running but I'm getting the feeling that
things
get more weird as I use lots of tabs in chrome.
I don't think it matters but my boot disk is a 960g Crucial SSD.
--STeve Andre'
panic: softdep_deallocate_dependencies: dangling deps
Stopped at Debugger+0x5: leave
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
IF RUNNING SMP, USE 'mach ddbcpu <#>' AND 'trace' ON OTHER PROCESSORS, TOO.
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb{1}> ddb{1}> Debugger() at Debugger+0x5
panic() at panic+0xfe
softdep_deallocate_dependencies() at softdep_deallocate_dependencies+0x1b
brelse() at brelse+0x61
ffs_write() at ffs_write+0x419
VOP_WRITE() at VOP_WRITE+0x3f
uvn_io() at uvn_io+0x1a0
uvm_pager_put() at uvm_pager_put+0x92
uvmpd_scan_inactive() at uvmpd_scan_inactive+0x5a3
uvmpd_scan() at uvmpd_scan+0x6e
uvm_pageout() at uvm_pageout+0x5b
end trace frame: 0x0, count: -11
ddb{1}> CPU not specified
ddb{1}> Stopped at Debugger+0x5: leave
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
IF RUNNING SMP, USE 'mach ddbcpu <#>' AND 'trace' ON OTHER PROCESSORS, TOO.
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb{0}> Stopped at Debugger+0x5: leave
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
IF RUNNING SMP, USE 'mach ddbcpu <#>' AND 'trace' ON OTHER PROCESSORS, TOO.
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb{1}> Debugger() at Debugger+0x5
panic() at panic+0xfe
softdep_deallocate_dependencies() at softdep_deallocate_dependencies+0x1b
brelse() at brelse+0x61
ffs_write() at ffs_write+0x419
VOP_WRITE() at VOP_WRITE+0x3f
uvn_io() at uvn_io+0x1a0
uvm_pager_put() at uvm_pager_put+0x92
uvmpd_scan_inactive() at uvmpd_scan_inactive+0x5a3
uvmpd_scan() at uvmpd_scan+0x6e
uvm_pageout() at uvm_pageout+0x5b
end trace frame: 0x0, count: -11
ddb{1}> Debugger() at Debugger+0x5
end trace frame: 0x80002207cab0, count: 0
ddb{1}>PID PPID PGRPUID S FLAGS WAIT COMMAND
27484 1 27484 0 30x80 poll ftpd
11680 15813 11680 1000 30x83 ttyin ksh
15813 6621 3503 1000 30xb2 select xterm
16802 4523 16802 1000 30x83 ttyin ksh
4523 6621 3503 1000 30xb2 select xterm
27410 18597 3503 1000 30x82 thrsleep chrome
7576 18597 3503 1000 3 0x482 kqread chrome
16218 18597 3503 1000 3 0x482 thrsleep chrome
658 18597 3503 1000 3 0x482 thrsleep chrome
7989 18597 3503 1000 3 0x482 thrsleep chrome
11847 18597 3503 1000 3 0x482 thrsleep chrome
20010 18597 3503 1000 2 0x482 chrome
15059 18597 3503 1000 3 0x482 kqread chrome
27259 18597 3503 1000 3 0x482 thrsleep chrome
20832 18597 3503 1000 3 0x482 thrsleep chrome
26369 18597 3503 1000 3 0x482 thrsleep chrome
4610 18597 3503 1000 3 0x482 thrsleep chrome
13262 18597 3503 1000 3 0x482 thrsleep chrome
8575 18597 3503 1000 3 0x482 netio chrome
7173 18597 3503 1000 2 0x4000482 chrome
29279 18597 3503 1000 3 0x482 thrsleep chrome
17470 18597 3503 1000 2 0x4000482 chrome
28899 18597 3503 1000 3 0x482 thrsleep chrome
29261 18597 3503 1000 30x82 thrsleep chrome
10383 18597 3503 1000 3 0x482 kqread chrome
26250 18597 3503 1000 3 0x482 thrsleep chrome
29984 18597 3503 1000 3 0x482 thrsleep chrome
1661 18597 3503 1000 3 0x482 thrsleep chrome
26874 18597 3503 1000 3 0x482 thrsleep chrome
18381 18597 3503 1000 2 0x482 chrome
22068 18597 3503 1000 3 0x482 kqread chrome
5164 18597 3503 1000 3 0x482 thrsleep chrome
3419 18597 3503 1000 3 0x482 thrsleep chrome
11293 18597 3503 1000 3 0x482 thrsleep chrome
14060 18597 3503 1000 3 0x482 thrsleep chrome
15908 18597 3503 1000 30x82 thrsleep chrome
22526 18597 3503 1000 3 0x482 kqread chrome
3139 18597 3503 1000 3 0x482 thrsleep chrome
16815 18597 3503 1000 3 0x482 thrsleep chrome
9024 18597 3503 1000 3 0x482 thrsleep chrome
21044 18597 3503 1000 3 0x482 thrsleep chrome
21241 18597 3503 1000 30x82 thrsleep chrome
14538 18597 3503 1000 3 0x482 kqread
Re: panic softdep_deallocate_dependencies
On Fri, Jul 19, 2013 at 1:13 PM, Roger Hammerstein wrote:
> i had another machine panic with this, and no disk errors.amd64, openbsd 5.3.
...
> ddb{0}> show panic
> softdep_deallocate_dependencies: unrecovered I/O error
> ddb{0}> trace
> Debugger() at Debugger+0x5
> panic() at panic+0xe4
> softdep_deallocate_dependencies() at softdep_deallocate_dependencies+0x43
> brelse() at brelse+0x68
> sd_buf_done() at sd_buf_done+0x7a
> mpi_intr() at mpi_intr+0x40
> Xintr_ioapic_edge18() at Xintr_ioapic_edge18+0xe8
So in the email thread you cited, the original poster turned off
softdeps and miod noted that should should avoid the panic. You
haven't done so because...you like to panic? softdeps speeds things
up for you so much that it makes up for the occasional panics?
(If I was hitting that, I might be tempted to add a printf() to the
default case of sd_buf_done() that showed the exact error and any
other info that might be pulled the from the xs, like the associated
buf's blkno and/or lblkno.)
Philip Guenther
Re: panic softdep_deallocate_dependencies
i had another machine panic with this, and no disk errors.amd64, openbsd 5.3.
it looks like outlook or the demimer ate the dmesg of my last message.
on reboot, /var needed manual fscking, and some bind logfiles were
unreferencedand put in lost+found.
ddb{0}> show panic
softdep_deallocate_dependencies: unrecovered I/O error
ddb{0}> trace
Debugger() at Debugger+0x5
panic() at panic+0xe4
softdep_deallocate_dependencies() at softdep_deallocate_dependencies+0x43
brelse() at brelse+0x68
sd_buf_done() at sd_buf_done+0x7a
mpi_intr() at mpi_intr+0x40
Xintr_ioapic_edge18() at Xintr_ioapic_edge18+0xe8
--- interrupt ---
Bad frame pointer: 0x800026132f10
end trace frame: 0x800026132f10, count: -7
cpu_idle_cycle+0x13:
ddb{0}>
ddb{0}> ps
PID PPID PGRPUID S FLAGS WAIT COMMAND
1676 7380 1676 0 30x80 ttyin ksh
7380 16232 7380 0 30x88 pause ksh
16232 28134 16232 1000 30x88 pause ksh
28134 7618 7618 1000 30x80 selectsshd
7618 5766 7618 0 30x80 poll sshd
30029 1 22491 70 3 0x4100080 kqreadnamed
14696 1 22491 70 3 0x4100080 thrsleep named
8590 1 22491 70 3 0x4100080 thrsleep named
24645 1 22491 70 3 0x4100080 thrsleep named
4014 1 22491 70 3 0x4100080 thrsleep named
17408 1 22491 70 3 0x410 getblknamed
4351 1 22491 70 3 0x4100080 thrsleep named
17728 1 22491 70 3 0x4100080 thrsleep named
18529 1 22491 70 3 0x4100080 thrsleep named
16617 1 22491 70 3 0x4100080 thrsleep named
22491 1 22491 70 30x80 sigwait named
10069 25041 10069 0 30x80 ttyin ksh
25041 9889 25041 0 30x88 pause ksh
# bioctl sd0Volume Status Size Device
mpi0 0 Online 499558383104 sd0 RAID1
0 Online 500107861504 0:9.0 noencl
1 Online 500107861504 0:1.0 noencl
mpi0 at pci3 dev 0 function 0 "Symbios Logic SAS1068E" rev 0x08: msi
scsibus0 at mpi0: 112 targets
sd0 at scsibus0 targ 0 lun 0: SCSI3 0/direct fixed
naa.
