https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231659
Lev A. Serebryakov changed:
What|Removed |Added
Keywords||IntelNetworking
--
You are r
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231659
--- Comment #12 from Lev A. Serebryakov ---
Ok. Now I have kernel with INVARIANTs and WITNESS and I have space fro
crashdumps.
I've got 3 crashdumps with exactly same panic message:
Assertion (staterr & E1000_RXD_STAT_DD) != 0 failed at
/d
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231659
Kubilay Kocak changed:
What|Removed |Added
Keywords||crash
Status|New
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231659
--- Comment #11 from Lev A. Serebryakov ---
(In reply to Eugene Grosbein from comment #10)
I understand it. Yes, I'll try this tomorrow.
And I'll try to add some BIG FAN to this box (it is passively cooled MiniTIX
box), as I start to suspe
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231659
--- Comment #10 from Eugene Grosbein ---
(In reply to Lev A. Serebryakov from comment #9)
You can still add some USB stick and configure kernel to use its /dev/da0s1b
partition as crashdump target. The kernel is somewhat picky when it deci
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231659
--- Comment #9 from Lev A. Serebryakov ---
(In reply to Mark Johnston from comment #8)
I mean, that new kernel with NETDUMP option enabled silently reboots without
"panic" message, debugger prompt, crashdump or thing like this. Simple reboo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231659
--- Comment #8 from Mark Johnston ---
(In reply to Lev A. Serebryakov from comment #7)
Do you mean NETDUMP? The system crashes when you configure netdump on the
router, or after? You might try setting debug.debugger_on_panic=1 to see if
a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231659
--- Comment #7 from Lev A. Serebryakov ---
Adding NETBOOT doesn't help. I've checked at console and system simply reboots
now, without panic, crash report or debugger or anything like this.
Ok. I'll add INVARIANTS and WITNESS to kernel and
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231659
--- Comment #6 from Lev A. Serebryakov ---
(In reply to Mark Johnston from comment #5)
Ooooh, thank you, I've missed this feature, I'll rebuild it with it! Great!
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231659
Mark Johnston changed:
What|Removed |Added
CC||ma...@freebsd.org
--- Comment #5 f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231659
--- Comment #4 from Lev A. Serebryakov ---
(In reply to Eugene Grosbein from comment #3)
Unfortunately, not right now. It is NanoBSD installation of my home router, so
it doesn't have permanent writable storage and auto-reboots.
I could re
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231659
Eugene Grosbein changed:
What|Removed |Added
CC||eu...@freebsd.org
--- Comment #3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231659
--- Comment #2 from Lev A. Serebryakov ---
Stopping all bpf consumers (dhcp client, dhcp server) doesn't help.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freeb
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231659
--- Comment #1 from Lev A. Serebryakov ---
Steps to reproduce for me:
(1) Two hosts:
192.168.134.1, 12-ALPHA7, slow, without AES-NI
192.168.134.2, 11-STABLE, fast, with AES-NI
(2) Setup IPsec transport for TCP port 5201 (iperf3 part):
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231659
Lev A. Serebryakov changed:
What|Removed |Added
Summary|12-ALPHA6 r338900 crashes |12-ALPHA7 r338900 crashes
15 matches
Mail list logo
