There are a set of commits in head that have not been pulled into the
stable/12 branch. Many of these are marked as MFC (and are quite old).
It would be fantastic if they made it into 12.1.
All of these I am currently running against 12.0-RELEASE across multiple
environments (i386, amd64 native,
r352752, r352754
<3
Awesome, thank you!!
On Tue, Sep 24, 2019 at 4:17 PM Ed Maste wrote:
> On Thu, 19 Sep 2019 at 18:30, David Cross wrote:
> >
> > There are a set of commits in head that have not been pulled into the
> > stable/12 branch. Many of these are marked a
I would like to call attention to a number of outstanding bugs with
tickets, 2 of them have patches!
1) kern/189219 (ticket has proposed patch, much better than mine) which is
a crasher when using dummyney on sparc64.. I've had to maintain a separate
kernel patch for >6 months, there's really no r
Could we get re's comments on:
kern/207069, kern/207070, kern/189219, and kern/206231
207069 is the major one for me, it means everytime I installworld I
need to remember to re-edit loader.rc or my system will not boot; this
is a major regression; this IS going to bite people in an existing
insta
I finally got my way through forth and to the point where I have a working
patch; updated ticket with patch and included the testing I had completed.
2 line patch, should be very straightforward to someone familiar with that
code.
Thanks
___
freebsd-stab
Ok, I have been trying to trace this down for awhile..I know quite a bit
about it.. but there's a lot I don't know, or I would have a patch. I have
been trying to solve this on my own, but bringing in some outside
assistance will let me move on with my life.
First up: The stacktrace (from a debu
complex portion of the kernel and some
pointers would be helpful.
On Sat, Jul 2, 2016 at 2:31 PM, David Cross wrote:
> Ok, I have been trying to trace this down for awhile..I know quite a bit
> about it.. but there's a lot I don't know, or I would have a patch. I have
> been try
is pretty complex itself
On Wed, Jul 6, 2016 at 11:18 AM, Konstantin Belousov
wrote:
> On Wed, Jul 06, 2016 at 10:51:28AM -0400, David Cross wrote:
> > Ok.. to reply to my own message, I using ktr and debugging printfs I have
> > found the culprit.. but I am still at a loss to &
Oh, whoops; how do I printout the buffer?
On Wed, Jul 6, 2016 at 11:30 AM, David Cross wrote:
> No kernel messages before (if there were I would have written this off a
> long time ago);
> And as of right now, this is probably the most fsck-ed filesystem on the
> planet!.. I ha
can
setup the kernel in a state that I know will panic when the vnode is
cleaned up, I can force a panic 'early' (kill -9 1), and then I could get
that vnode.. if I could get the vnode list to walk.
On Wed, Jul 6, 2016 at 1:37 PM, Konstantin Belousov
wrote:
> On Wed, Jul 06, 2016 at 12:02
wanted is the buffer and their dependency lists.. I am not
sure where those are under all of this.. bo_*?
On Wed, Jul 6, 2016 at 8:12 PM, Konstantin Belousov
wrote:
> On Wed, Jul 06, 2016 at 02:21:20PM -0400, David Cross wrote:
> > (kgdb) up 5
&g
Ok... I found it.
All of the writes go through ffs_write (including VOP_RECLAIM, so my
statement that VOP_RECLAIM couldn't handle things that vinvalbuf left
behind is obviously incorrect). Sometimes it worked, sometimes it paniced,
I started putting more deugging into it and I noticed the followi
12 matches
Mail list logo
