kernel panics #20
Comments
|
Thanks for reporting. It looks like #19 in terms of a root cause, at least. Please, try #19 (comment). Panics won't go away entirely, but you shouldn't see crashes so often. In the meantime, I'm trying to solve the root cause itself. |
|
OK Dmitry. For now, I am going to try and will let you know. |
|
I reverted 718bdb6 and it has been working waaaay better since. So you are certainly right, the problem is the same as the other issue. Do you want me to close this issue ? I humbly ask you what you think about reverting the commit in the source code for now, as it would prevent other people to reach this problem. This is up to you of course. |
I'll close it as a duplicate of #19.
It's important to unmask the panic with 718bdb6 because it'll help me to verify the root cause solved with upcoming patches. |
|
@snail59 Please, try https://github.com/mcusim/freebsd-src/tree/dpaa2. GENERIC kernel had worked for me for ~14 hours under high network load till the moment I stopped the test myself. details: #19 (comment) |
|
@dsalychev I just saw your email. |
|
So, I tried it and quickly got a kernel panic: |
|
I tried rebuilding everything once again and booting without the USB modem but it still panics |
|
@dsalychev out of curiosity, does it make sense? Is there something obvious ? |
|
It definitely does. Could you try a85d6c9? I've probably made a mistake with: |
|
Just tried it. |
|
@snail59 sounds good :) |
|
So, it has been running for some time... And I had no problem at all. I could do way more than my original scenario. Good work mate :-) |
It'd be really good :) I hope I'll be able to commit those changes till 14.0. Thanks for testing! |
|
I hope too ! Otherwise (unless you revert your last commit), FreeBSD 14.0 won't install on ten64 :-/ |
|
For your information (I know this is not your code's fault), you rebased your branch on main while there currently is a problem preventing the compilation. I could not figure out yet which commit is faulty. Neither what is happening exactly as I am not a developer :-D |
|
It looks like you've to re-compile the world as well. This worked for me: |
For information (because this has nothing to do with the current issue) , I dug and it appears that it fails when using ccache and succeeds without. I suspect this is so since the LIB32 option was activated on aarch64. |
netlink(4) calls back into the driver during detach and it attempts to start an internal synchronized op recursively, causing an interruptible hang. Fix it by failing the ioctl if the VI has been marked as DOOMED by cxgbe_detach. Here's the stack for the hang for reference. #6 begin_synchronized_op #7 cxgbe_media_status #8 ifmedia_ioctl #9 cxgbe_ioctl #10 if_ioctl #11 get_operstate_ether #12 get_operstate #13 dump_iface #14 rtnl_handle_ifevent #15 rtnl_handle_ifnet_event #16 rt_ifmsg #17 if_unroute #18 if_down #19 if_detach_internal #20 if_detach #21 ether_ifdetach #22 cxgbe_vi_detach #23 cxgbe_detach #24 DEVICE_DETACH MFC after: 3 days Sponsored by: Chelsio Communications
Hello,
Recently, my ten64 started crashing multiple times per day.
dpni9 and dpni8 are 10Gb nics; in my case, dpni9 is facing internet while dpni8 serves my local network.
Plus, I use vlans, mostly for vmware virtual machines.
Communication between internet and my local network works pretty fine, but
I tried different scenarios:
As soon as VM ( so in a vlan) begins to communicate with any other network, the ten64 crashes:
This is a less unstable configuration, but it eventually crashes anyway:
It quickly crashes, even without activity
Tell me if you need more information or tests from me. My build machine is fast so it does not bother me to compile multiple times.
The text was updated successfully, but these errors were encountered: