> I attempted to investigate this further, while very reproducible, it's
> difficult get a good trace. Once the bug is fully engaged, it becomes
> impossible to break into ddb, the system is completely unresponsive.
>
> However, triggering ddb a few seconds before and stepping through
> instructions is possible. The breakpoint chain seems to follow below:
>
> ffs_read
> VOP_READ
> uvn_io
> uvn_get
> uvm_fault_lower_io
> uvm_fault_lower
> uvm_fault
> upageflttrap
> userret
>
> followed by an infinite stream of:
>
> kernel: double fault trap, code=0
>
> with the ddb pager triggered, but unable to break out of.
>
> I hope this information is helpful to someone.
>
> Regards
> Lloyd

Hi Lloyd,

Thank you for getting that!

I see in ffs_read, there are some diagnostic lines, seems like I could
rebuild the kernel with that.

I am hoping I have time to enable diagnostics and try this in a VM.
Might be easier to capture a good stacktrace?

Getting pretty close to a release window and it'd be nice to have this
fixed.

-Henrich

Reply via email to