https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270163
--- Comment #9 from Timothy Pearson ---
(In reply to Timothy Pearson from comment #8)
Note that when the device is firewalled, every access returns 0xff, so the
reference to a driver lock is probably just the relevant bit being returned as
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270163
--- Comment #8 from Timothy Pearson ---
OK, looks like it's on data transmission, CARP was just the first transmission
on the device when it was set up. With CARP disabled, the log looks similar,
everything looks OK then it dies somewhere
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270163
--- Comment #7 from Timothy Pearson ---
(In reply to Zhenlei Huang from comment #6)
Yes, I'll just need a bit of time to shuffle the configuration around.
Two other data points:
An Intel I340-T4 I had available to test with appears to wo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270163
Zhenlei Huang changed:
What|Removed |Added
CC||z...@freebsd.org
--- Comment #6 fr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270163
--- Comment #5 from Timothy Pearson ---
Created attachment 240807
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=240807&action=edit
Kernel output with debugging enabled
Here is a capture of the kernel log with debugging enabled.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270163
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--- Comment #4 fro
To view an individual PR, use:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id).
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and ob
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270083
Mark Linimon changed:
What|Removed |Added
CC|n...@freebsd.org |
Assignee|b...@freebsd.o
