On Wed, Dec 05, 2018 at 10:03:38PM +0100, Anton Lindqvist wrote:
> On Sat, Dec 01, 2018 at 04:34:57PM +0100, Anton Lindqvist wrote:
> > On Tue, Nov 27, 2018 at 05:52:15PM -0800, Greg Steuck wrote:
> > > I booted the patched kernel and it seems to have gone farther and I
> > > believe
> > >
> Here's a new diff taking a different approach. Keeping tracing off until
> all secondary CPUs have booted solves the issue of accessing curcpu()
> too early. Another issue was then discovered, curproc can be NULL before
> the idle thread tied the current CPU has started. Currently running with
>
On Sat, Dec 01, 2018 at 04:34:57PM +0100, Anton Lindqvist wrote:
> On Tue, Nov 27, 2018 at 05:52:15PM -0800, Greg Steuck wrote:
> > I booted the patched kernel and it seems to have gone farther and I believe
> > reached init before crashing.
>
> By performing a semi-automated bisect I was able to
Hi Anton,
Unfortunately it's still crashing. The log is below, but to make
sure I'm not deluding myself, the source tree is
https://github.com/blackgnezdo/src/tree/anton-kcov-dec1
This is the workdir where I'm building:
commit fea58d64a837907fd3b5c45eb2b77351ac105d5f (HEAD -> anton-kcov-dec1)
On 01/12/18(Sat) 16:34, Anton Lindqvist wrote:
> On Tue, Nov 27, 2018 at 05:52:15PM -0800, Greg Steuck wrote:
> > I booted the patched kernel and it seems to have gone farther and I believe
> > reached init before crashing.
>
> By performing a semi-automated bisect I was able to identify the
On Tue, Nov 27, 2018 at 05:52:15PM -0800, Greg Steuck wrote:
> I booted the patched kernel and it seems to have gone farther and I believe
> reached init before crashing.
By performing a semi-automated bisect I was able to identify the source
files that are incompatible with tracing. Common for
I booted the patched kernel and it seems to have gone farther and I believe
reached init before crashing.
boot> b bsd.anton
booting hd0a:bsd.anton: 12380226+2360336+270368+0+675840
[684182+128+754752+529898]=0x10d8f48
entry point at 0x1001000
[ using 1969992 bytes of bsd ELF symbol table ]
On Mon, Nov 26, 2018 at 08:43:12AM -0800, Greg Steuck wrote:
> Thanks for the patch, I'll give it a go. Should I make up a patch reporting
> #error when trying to build kcov with MP in the meantime? The next person
> won't have to find it the hard way...
Please try out the diff first. I'd rather
Thanks for the patch, I'll give it a go. Should I make up a patch reporting
#error when trying to build kcov with MP in the meantime? The next person
won't have to find it the hard way...
On Sun, Nov 25, 2018 at 11:21 PM Anton Lindqvist wrote:
> Hi Greg,
>
> On Sun, Nov 25, 2018 at 10:13:52AM
Hi Greg,
On Sun, Nov 25, 2018 at 10:13:52AM -0800, Greg Steuck wrote:
> Hi Anton,
>
> I tried to boot a kernel with kcov based on GENERIC.MP and the machine
> reboots without a peep immediately after
>
> vmm0 at mainbus0: VMX (using slow L1TF mitigation)
>
> Switching off either of kcov or MP
Hi Anton,
I tried to boot a kernel with kcov based on GENERIC.MP and the machine
reboots without a peep immediately after
vmm0 at mainbus0: VMX (using slow L1TF mitigation)
Switching off either of kcov or MP results in normally working kernels. I'm
attaching two concatenated dmesgs. The effect
11 matches
Mail list logo
