re: ZFS works on 8.99.34 but fails on 201905260520Z
> 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, vs "error 8".) thanks! .mrg.
Re: [PATCH 1/2] compat32: translate userland PT_* request values into kernel
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 know they are, however I don't think it's really possible. One option is to declare additional set of constants in the amd64 headers but that doesn't really gain us anything, and ends up in kinda-absurd: case PT32_STEP: return PT_STEP; or alike. > is there a way to have amd64 have direct access to the i386 > values? I don't think so. > > --- a/sys/sys/ptrace.h > > +++ b/sys/sys/ptrace.h > > @@ -283,6 +283,10 @@ intptrace_machdep_dorequest(struct lwp *, struct > > lwp *, int, > > #define FIX_SSTEP(p) > > #endif > > > > +#ifndef PTRACE_TRANSLATE_REQUEST32 > > +#define PTRACE_TRANSLATE_REQUEST32(x) x > > +#endif > > + > > can this part live in sys/compat(/netbsd32)? no need for the > public ptrace header to get this, right? > I'll try and see. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
re: [PATCH 1/2] compat32: translate userland PT_* request values into kernel
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? > --- a/sys/sys/ptrace.h > +++ b/sys/sys/ptrace.h > @@ -283,6 +283,10 @@ int ptrace_machdep_dorequest(struct lwp *, struct > lwp *, int, > #define FIX_SSTEP(p) > #endif > > +#ifndef PTRACE_TRANSLATE_REQUEST32 > +#define PTRACE_TRANSLATE_REQUEST32(x) x > +#endif > + can this part live in sys/compat(/netbsd32)? no need for the public ptrace header to get this, right? .mrg.
Re: ZFS works on 8.99.34 but fails on 201905260520Z
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. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: ZFS works on 8.99.34 but fails on 201905260520Z
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 in sync... On Tue, 28 May 2019, m...@netbsd.org wrote: Found the commit - looks like newer modules than kernel. https://v4.freshbsd.org/commit/netbsd/src/IH8Jag0YCI3N6boB !DSPAM:5cedc4b046711245568741! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: ZFS works on 8.99.34 but fails on 201905260520Z
> 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 than kernel. >> https://v4.freshbsd.org/commit/netbsd/src/IH8Jag0YCI3N6boB Do we really expect module updates without updating kernel to work? If yes will do iot next time. -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig signature.asc Description: Message signed with OpenPGP
Re: ZFS works on 8.99.34 but fails on 201905260520Z
Thanks, I will do that, though I do now know how this happened. Dne 28. 05. 19 v 23:40 J. Hannken-Illjes napsal(a): Petr, your kernel is elder than your ZFS module. Please update to a current kernel and try again. -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig On 28. May 2019, at 20:27, Petr Topiarz wrote: Hi Tech-kern, I run two machines with NetBSD amd64 with ZFS, one is with 8.99.34 kernel from february, the other is the latest today, 201905260520Z, It all runs fine with the first one, but as I upgraded the other, ZFS does not load and tels me: modload: zfs: Exec format error and to /var/log messages it writes: May 28 18:55:46 poweredge /netbsd: [ 236.3881944] kobj_checksyms, 988: [zfs]: linker error: symbol `disk_rename' not found May 28 18:55:46 poweredge /netbsd: [ 236.4833169] WARNING: module error: unable to affix module `zfs', error 8 May 28 18:55:50 poweredge /netbsd: [ 240.2655954] kobj_checksyms, 988: [zfs]: linker error: symbol `disk_rename' not found May 28 18:55:50 poweredge /netbsd: [ 240.3599823] WARNING: module error: unable to affix module `zfs', error 8 May 28 18:56:18 poweredge /netbsd: [ 268.0810981] kobj_checksyms, 988: [zfs]: linker error: symbol `disk_rename' not found May 28 18:56:18 poweredge /netbsd: [ 268.1715047] WARNING: module error: unable to affix module `zfs', error 8 considering configuration I got: cat /etc/modules.conf solaris zfs and in /etc/rc.conf I got modules=YES Any hint where to look or what to reconfigure in the kernel? I am using standard netbsd kernel in both cases. thanks Petr
