Bug 203976 - panic: page fault on regular traffic routing
Summary: panic: page fault on regular traffic routing
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.2-RELEASE
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks: 204186
  Show dependency treegraph
 
Reported: 2015-10-23 09:42 UTC by ikv
Modified: 2015-11-01 09:47 UTC (History)
1 user (show)

See Also:


Attachments
core dump (159.30 KB, text/plain)
2015-10-23 09:42 UTC, ikv
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description ikv 2015-10-23 09:42:28 UTC
Created attachment 162382 [details]
core dump

System gets in panic while regular routing tasks, such as nat. Repeating by bittorrent traffic passing throug every time on loads above 70 mbit/s.
The behavour of the 10.2 system on another machine was the same. Both systems network interfaces are bge aggregated by lacp lagg.
Error dump in attachment.
Comment 1 Kristof Provost freebsd_committer 2015-10-23 11:30:22 UTC
Can you also add your pf rules?

At first glance this looks like it's probably a PF problem.
Comment 2 ikv 2015-10-23 11:34:11 UTC
(In reply to Kristof Provost from comment #1)
These rules works fine on freebsd 9.3.
Comment 3 Kristof Provost freebsd_committer 2015-10-23 11:36:18 UTC
I'm not suggesting your rules are wrong (the panic should never happen, no matter what the rules are), but knowing what they are is useful during debugging.
Comment 4 ikv 2015-10-23 11:42:05 UTC
(In reply to Kristof Provost from comment #3)
I wont posting my rules. By the way, i have this problem on 2 different systems with different pf rulesets.
rules are simple - pass, block, nat - nothing extra ordinary. The common thing is hardware - bge interfaces in lagg. (ProLiant DL360p Gen8)
Comment 5 Kristof Provost freebsd_committer 2015-10-23 11:46:34 UTC
(In reply to ikv from comment #4)
You can censor the IP addresses, if you like, but knowing what type of scrub options you've got, and if you're using anything like route-to, dup-to, ... is quite useful.
Comment 6 Kristof Provost freebsd_committer 2015-10-23 11:52:07 UTC
Are you running with 'scrub fragment crop' or 'scrub fragment drop-ovl' by any chance?

If so, can you confirm that the problem goes away if you switch to 'scrub fragment reassemble'? 

The crop/drop-ovl code has been removed in CURRENT, and I suspect it's the cause of your panics.
Comment 7 ikv 2015-10-23 12:05:38 UTC
(In reply to Kristof Provost from comment #6)
indeed i use crop. Can't test right at this time since i rolled back to 9.3, but i'll test it soon and reply results.
Comment 8 ikv 2015-10-23 14:56:50 UTC
(In reply to Kristof Provost from comment #6)
You were right, i replaced "corp" by "reassemble" - now it works fine.
Thanks a lot!
Comment 9 Mark Linimon freebsd_committer freebsd_triage 2015-10-25 13:28:55 UTC
To submitter: so can this PR be closed now?
Comment 10 ikv 2015-10-26 07:50:10 UTC
(In reply to Mark Linimon from comment #9)
I think need kernel fixes to prevent such problems in future.
Comment 11 Kristof Provost freebsd_committer 2015-10-26 14:05:31 UTC
To be clear: this panic will not happen on CURRENT, because the code (scrub crop/drop-ovl) in which it occurs has been removed.

Right now I don't plan to investigate this problem any further.