> Do we really expect module updates without updating kernel
> to work?
>
> If yes will do iot next time.
yes - if you add, not just change, to the kernel abi in a way
that modules will notice, please bump the version. it should
make this sort of problem more obvious (due to missing file
errors,
On Thu, 2019-05-30 at 03:15 +1000, matthew green wrote:
> thanks for working on this.
>
> > + case PT_FIRSTMACH + 0:
> > + return PT_STEP;
> > + case PT_FIRSTMACH + 1:
> > + return PT_GETREGS;
> [ ... ]
>
> these magic numbers are a little ugly. can you avoid them?
I kno
thanks for working on this.
> + case PT_FIRSTMACH + 0:
> + return PT_STEP;
> + case PT_FIRSTMACH + 1:
> + return PT_GETREGS;
[ ... ]
these magic numbers are a little ugly. can you avoid them?
is there a way to have amd64 have direct access to the i386
values?
> -
On Wed, 29 May 2019, Petr Topiarz wrote:
Thank you for this investigation, now its clear, where the problem lays, I
will reinstall when this is corrected.
Kernel version has just been bumped, so newer kernel with newer modules
(version 8.99.42) should work just fine.
++
Thank you for this investigation, now its clear, where the problem lays,
I will reinstall when this is corrected.
Peter
Dne 29. 05. 19 v 1:38 Paul Goyette napsal(a):
The commit that introduced the new symbol should also have bumped the
kernel version... That's how we keep modules and kernel i
> On 29. May 2019, at 01:38, Paul Goyette wrote:
>
> The commit that introduced the new symbol should also have bumped the kernel
> version... That's how we keep modules and kernel in sync...
>
>
> On Tue, 28 May 2019, m...@netbsd.org wrote:
>
>> Found the commit - looks like newer modules t
