Re: Possible issue with linux xattr support?

2023-09-04 Thread Felix Palmen
* Dmitry Chagin  [20230904 21:49]:
> On Mon, Sep 04, 2023 at 08:43:02PM +0200, Felix Palmen wrote:
> > I guess I'll now do a full rebuild of my linuxulator userspace branch on
> > a kernel with that patch, just to be sure it won't break anything else,
> > this will take a few hours, I will report back. So far looking really
> > good :)

This completed while I was sleeping. No issues!

With ~120 "Linux ports" building fine, using all sorts of tools (like
python and some tools from coreutils), I think it's fair to assume it's
all fixed now.

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature


Re: Possible issue with linux xattr support?

2023-09-04 Thread Felix Palmen
* Dmitry Chagin  [20230904 21:49]:
> On Mon, Sep 04, 2023 at 08:43:02PM +0200, Felix Palmen wrote:
> > Thanks a lot for the quick patch! I have to admit I don't fully
> > understand it immediately, but I assume it's an attempt to only list
> > attributes not in system.* when that namespace is restricted?
> 
> no,
> +   if (error == EPERM)
> +   break;
> mean that listxattr will fail if user is unauthorized to access system
> namespace, ie, listxattr will return ENOTSUP

Ah, now I get it, so breaking out of the loop there will leave
attrnamespace at EXTATTR_NAMESPACE_SYSTEM if that was the cause,
therefore error_to_xattrerror() works as expected. Nice!

Well, given that I really don't expect any further problems, but give my
poor builder a few hours to *really* verify :)

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature


Re: Possible issue with linux xattr support?

2023-09-04 Thread Felix Palmen
Hello Dmitry,

* Dmitry Chagin  [20230904 21:29]:
> Thanks for the report,
> please, try this: https://people.freebsd.org/~dchagin/lxattr.patch
> Don't be surprised, there 2 fixes

Thanks a lot for the quick patch! I have to admit I don't fully
understand it immediately, but I assume it's an attempt to only list
attributes not in system.* when that namespace is restricted?

Well, it *does* solve the issue with 'cp -p' from GNU coreutils!

I guess I'll now do a full rebuild of my linuxulator userspace branch on
a kernel with that patch, just to be sure it won't break anything else,
this will take a few hours, I will report back. So far looking really
good :)

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature


Re: Possible issue with linux xattr support?

2023-09-04 Thread Felix Palmen
* Felix Palmen  [20230904 15:39]:
> For some reason (I still have to try to get more information about it,
> will do soon), something else is broken now. While install from GNU
> coreutils works fine, some build systems use 'cp -p' to install files
> instead, which now fails with:
> 
> | cp: preserving permissions for [...]: Operation not permitted

The issue seems to be with listing attributes:

| root@15-default:/wrkdirs/usr/ports/x11/linuxsrc-libxcb/work/libxcb-1.15/doc # 
truss /compat/linux/bin/cp -pR ./tutorial 
'/wrkdirs/usr/ports/x11/linuxsrc-libxcb/work/stage/compat/linux/usr/share/doc/libxcb/'
 2>&1 | grep xattr
| linux_flistxattr(0x4,0x0,0x0)ERR#-1 'Operation not 
permitted'
| linux_flistxattr(0x4,0x0,0x0)ERR#-1 'Operation not 
permitted'
| linux_llistxattr(0xcdd9,0x0,0x0) ERR#-1 'Operation not 
permitted'

The following q patch makes it work again:

#v+
diff --git a/sys/compat/linux/linux_xattr.c b/sys/compat/linux/linux_xattr.c
index 74b47f1cbaec..0b5af084b1b1 100644
--- a/sys/compat/linux/linux_xattr.c
+++ b/sys/compat/linux/linux_xattr.c
@@ -198,7 +198,7 @@ listxattr(struct thread *td, struct listxattr_args *args)
if (error == 0)
td->td_retval[0] = cnt;
free(data, M_LINUX);
-   return (error_to_xattrerror(attrnamespace, error));
+   return (error_to_xattrerror(EXTATTR_NAMESPACE_SYSTEM, error));
 }
 
 int
#v-

I think this makes sense, because listxattr iterates over all
namespaces, so there's no sane way to know whether the EPERM was caused
by trying to access "system" or something else.

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature


Re: Possible issue with linux xattr support?

2023-09-04 Thread Felix Palmen
Hello Dmitry,

* Dmitry Chagin  [20230830 14:04]:
> Thanks, I see, I agree with your change, taken into account.

Thanks a lot for committing the fix/workaround as well as the new
feature! I just upgraded my test builders to 15-CURRENT to double-check.

For some reason (I still have to try to get more information about it,
will do soon), something else is broken now. While install from GNU
coreutils works fine, some build systems use 'cp -p' to install files
instead, which now fails with:

| cp: preserving permissions for [...]: Operation not permitted

I'm pretty sure this worked fine with the patch you linked earlier, and
also with my own change taking the namespace into account ...

Did you change anything else in your commits compared to the patch?

I'll post a followup as soon as I could get some truss output to know
exactly which syscall causes the issue now!

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature


Re: Possible issue with linux xattr support?

2023-08-30 Thread Felix Palmen
* Felix Palmen  [20230830 12:58]:
> * Dmitry Chagin  [20230830 13:48]:
> > I don't changed setxattr syscalls due to EPERM is a valid error from it,
> > however here's the essential difference between Linux and FreeBSD.
> > FreeBSD does not permits manipulatingg attributes in the
> > system namespace for unprivileged accounts.
> 
> Interesting! (and, a weird design ...)

I meant the filesystem-specific policies of course. Quoting fail on my
side.

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature


Re: Possible issue with linux xattr support?

2023-08-30 Thread Felix Palmen
* Dmitry Chagin  [20230830 13:48]:
> On Wed, Aug 30, 2023 at 12:01:13PM +0200, Felix Palmen wrote:
> > Unfortunately, install from GNU coreutils is now unable to install
> > anything again. I tried both as 'nobody' and as 'root', it doesn't make
> > a difference:
> > [...]
> > I assume the fsetxattr call needs some adjustment of error codes as well
> > to make GNU tools play nice.
> > 
> 
> I don't changed setxattr syscalls due to EPERM is a valid error from it,
> however here's the essential difference between Linux and FreeBSD.
> FreeBSD does not permits manipulatingg attributes in the
> system namespace for unprivileged accounts.

Interesting! (and, a weird design ...)

> https://people.freebsd.org/~dchagin/xattr.patch

Yes, that's basically the same change I meanwhile did locally, except I
restricted the adjustment to cases of writing the system namespace --
not sure that's good for anything though.

In short: Works fine that way!

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature


Re: Possible issue with linux xattr support?

2023-08-30 Thread Felix Palmen
* Felix Palmen  [20230830 12:01]:
> * Dmitry Chagin  [20230830 12:22]:
> > On Wed, Aug 30, 2023 at 11:20:39AM +0200, Felix Palmen wrote:
> > > * Unprivileged user will get ENOTSUP when trying to access the system
> > >   namespace (regardless of the new jail setting), so GNU tools like e.g.
> > >   coreutils install should "just work".
> > ENOTSUP or ENODATA (getxattr)
> 
> Unfortunately, install from GNU coreutils is now unable to install
> anything again. I tried both as 'nobody' and as 'root', it doesn't make
> a difference:

Sorry for the noise ... this little change fixes it for me:
https://people.freebsd.org/~zirias/patches/linux-setxattr.patch

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature


Re: Possible issue with linux xattr support?

2023-08-30 Thread Felix Palmen
* Felix Palmen  [20230830 12:01]:
> Unfortunately, install from GNU coreutils is now unable to install
> anything again. I tried both as 'nobody' and as 'root', it doesn't make
> a difference:
> [...]
> I assume the fsetxattr call needs some adjustment of error codes as well
> to make GNU tools play nice.

On a second thought, shouldn't it be two separate patches in the end?

* Some adjustment of the error codes seems to be needed to correctly
  mimick Linux, so GNU tools et al don't misinterpret some error as
  being "fatal"

* Optionally allowing access to the system namespace from within a jail
  is also needed for some use cases (as shown by HBSD having a patch),
  but is in fact unrelated to the issue with Linux *xattr calls

Please correct me if I'm wrong here ;)

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature


Re: Possible issue with linux xattr support?

2023-08-30 Thread Felix Palmen
* Dmitry Chagin  [20230830 12:22]:
> On Wed, Aug 30, 2023 at 11:20:39AM +0200, Felix Palmen wrote:
> > * Unprivileged user will get ENOTSUP when trying to access the system
> >   namespace (regardless of the new jail setting), so GNU tools like e.g.
> >   coreutils install should "just work".
> ENOTSUP or ENODATA (getxattr)

Unfortunately, install from GNU coreutils is now unable to install
anything again. I tried both as 'nobody' and as 'root', it doesn't make
a difference:

| # /compat/linux/usr/bin/install -c .libs/libexpat.so.1.8.10 
/wrkdirs/usr/ports/textproc/linuxsrc-expat/work/stage/compat/linux/usr/lib64/libexpat.so.1.8.10
| /compat/linux/usr/bin/install: setting permissions for 
‘/wrkdirs/usr/ports/textproc/linuxsrc-expat/work/stage/compat/linux/usr/lib64/libexpat.so.1.8.10’:
 Operation not permitted

.. and truss shows this again:

| linux_fsetxattr(0x4,0x401860e8,0x134dd0,0x1c,0x0) ERR#-1 'Operation not 
permitted'

This is without the new jail option. When I enable it, it still fails
the same way as 'nobody' (which poudriere uses for building), but works
fine as 'root'.

I assume the fsetxattr call needs some adjustment of error codes as well
to make GNU tools play nice.

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature


Re: Possible issue with linux xattr support?

2023-08-30 Thread Felix Palmen
* Dmitry Chagin  [20230830 11:57]:
> On Tue, Aug 29, 2023 at 08:58:13PM +0200, Felix Palmen wrote:
> > Thanks again for quickly fixing this! Can this still make 14.0-RELEASE?
> > 
> I think yes, thanks for testing, I revised the error handling and made
> it more precise, can you test new patch in your environment.
> 
> https://people.freebsd.org/~dchagin/xattr.patch

Great, thanks! I see you now chose to add a jail option, certainly the
cleanest solution.

Will test later today. Just to make sure I have the correct expectation
about the behavior with the new patch applied:

* Unprivileged user will get ENOTSUP when trying to access the system
  namespace (regardless of the new jail setting), so GNU tools like e.g.
  coreutils install should "just work".
* Root will get either ENOTSUP, or a fully working access to system.*
  with the new jail setting enabled.

Are these assumptions correct?

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature


Re: Possible issue with linux xattr support?

2023-08-29 Thread Felix Palmen
* Dmitry Chagin  [20230829 23:16]:
> On Tue, Aug 29, 2023 at 03:02:58PM -0400, Shawn Webb wrote:
> > Back in 2019, I had a similar issue: I needed access to be able to
> > read/write to the system extended attribute namespace from within a
> > jailed context. I wrote a rather simple patch that provides that
> > support on a per-jail basis:
> > 
> > https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/commit/96c85982b45e44a6105664c7068a92d0a61da2a3
> > 
> > Hopefully that's useful to someone.
> > 
> 
> Nice, thank you. I'd prefer to disable it by default, like on a host.

When it's disabled by default, it will require additional configuration
to make "Linux jails" work again.

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature


Re: Possible issue with linux xattr support?

2023-08-29 Thread Felix Palmen
* Shawn Webb  [20230829 15:25]:
> On Tue, Aug 29, 2023 at 09:15:03PM +0200, Felix Palmen wrote:
> > * Kyle Evans  [20230829 14:07]:
> > > On 8/29/23 14:02, Shawn Webb wrote:
> > > > Back in 2019, I had a similar issue: I needed access to be able to
> > > > read/write to the system extended attribute namespace from within a
> > > > jailed context. I wrote a rather simple patch that provides that
> > > > support on a per-jail basis:
> > > > 
> > > > https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/commit/96c85982b45e44a6105664c7068a92d0a61da2a3
> > > > 
> > > > Hopefully that's useful to someone.
> > > > 
> > > > Thanks,
> > > > 
> > > 
> > > FWIW (which likely isn't much), I like this approach much better; it makes
> > > more sense to me that it's a feature controlled by the creator of the jail
> > > and not one allowed just by using a compat ABI within a jail.
> > 
> > Well, a typical GNU userland won't work in a jail without this, that's
> > what I know now. But I'm certainly with you, it doesn't feel logical
> > that a Linux binary can do something in a jail a FreeBSD binary can't.
> > 
> > So, indeed, making it a jail option sounds better.
> > 
> > Unless, bringing back a question raised earlier in this thread: What's
> > the reason to restrict this in a jailed context in the first place? IOW,
> > could it just be allowed unconditionally?
> 
> In HardenedBSD's case, since we use filesystem extended attributes to
> toggle exploit mitigations on a per-application basis, there's now a
> conceptual security boundary between the host and the jail.
> 
> Should the jail and the host share resources, like executables, a
> jailed process could toggle an exploit mitigation, and the toggle
> would bubble up to the host. So the next time the host executed
> /shared/app/executable/here, the security posture of the host would be
> affected.

Isn't the sane approach here *not* to share any executables with a jail
other than via a read-only nullfs mount?

> FreeBSD uses ELF header tagging, not filesystem extended attributes,
> to toggle exploit mitigations. So my description above is moot for
> FreeBSD users. I'm just hoping to share a unique perspective.

Thanks!

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature


Re: Possible issue with linux xattr support?

2023-08-29 Thread Felix Palmen
* Kyle Evans  [20230829 14:07]:
> On 8/29/23 14:02, Shawn Webb wrote:
> > Back in 2019, I had a similar issue: I needed access to be able to
> > read/write to the system extended attribute namespace from within a
> > jailed context. I wrote a rather simple patch that provides that
> > support on a per-jail basis:
> > 
> > https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/commit/96c85982b45e44a6105664c7068a92d0a61da2a3
> > 
> > Hopefully that's useful to someone.
> > 
> > Thanks,
> > 
> 
> FWIW (which likely isn't much), I like this approach much better; it makes
> more sense to me that it's a feature controlled by the creator of the jail
> and not one allowed just by using a compat ABI within a jail.

Well, a typical GNU userland won't work in a jail without this, that's
what I know now. But I'm certainly with you, it doesn't feel logical
that a Linux binary can do something in a jail a FreeBSD binary can't.

So, indeed, making it a jail option sounds better.

Unless, bringing back a question raised earlier in this thread: What's
the reason to restrict this in a jailed context in the first place? IOW,
could it just be allowed unconditionally?

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature


Re: Possible issue with linux xattr support?

2023-08-29 Thread Felix Palmen
* Dmitry Chagin  [20230829 21:12]:
> On Tue, Aug 29, 2023 at 07:02:22PM +0200, Felix Palmen wrote:
> > So, using user.* works, using system.* doesn't, and maybe a bit
> > surprising(?), dumping all attributes which by default excludes the
> > system namespace doesn't work either.
> > 
> 
> As expected, the second patch intended to allow access to system
> namespace in jailed env.

Not exactly, according to the manual, 'getfattr -d' *excludes* the
system namespace by default, so I would have expected it to work. But
maybe that's an issue with the getfattr tool itself.

> > I still wonder, is the first patch needed anyways? Maybe I fail to
> > understand something here. Won't it map *every* EPERM to ENOSUP and
> > can't this be an issue?
> > 
> 
> fine, thanks. Gnu tools running under unprivileged user will fail, eg
> ls, which uses getfattr() to get the posix acl

Ah, I see, that would still break "Linux jails" then...

Thanks again for quickly fixing this! Can this still make 14.0-RELEASE?

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature


Re: Possible issue with linux xattr support?

2023-08-29 Thread Felix Palmen
* Dmitry Chagin  [20230829 17:45]:
> On Tue, Aug 29, 2023 at 12:59:11PM +0200, Felix Palmen wrote:
> > Thanks, I can confirm this avoids the issue in both cases I experienced
> > (install from GNU coreutils and python).
> > 
> thanks, this is the first half of the fix, it works for you due to you
> are running tools under unprivileged user, afaiu. The second I have
> tested by myself :)

Sure, poudriere is running all builds as "nobody" by default.

> > If I understand this patch correctly, it completely avoids EPERM,
> > masking it as not supported, so callers should consider it non-fatal,
> > allowing to silently ignore writing of "system" attributes while still
> > keeping other functionality?
> > 
> system namespace is accessible only for privileged user, for others Linux
> returns ENOTSUP. So many tools ignores this error, eg ls.
> 
> the second: https://people.freebsd.org/~dchagin/sea_jailed.patch

Ok, I did some tests in a poudriere jail using Linux bash, as root.
First, with only the first patch:

| bash-5.2# getfattr -d /bin/sh
| getfattr: /bin/sh: Operation not supported
| bash-5.2# setfattr -n user.foo -v bar /bin/sh
| bash-5.2# getfattr -n user.foo /bin/sh
| getfattr: Removing leading '/' from absolute path names
| # file: bin/sh
| user.foo="bar"
| bash-5.2# setfattr -x user.foo /bin/sh
| bash-5.2# setfattr -x system.foo /bin/sh
| setfattr: /bin/sh: Operation not supported

So, using user.* works, using system.* doesn't, and maybe a bit
surprising(?), dumping all attributes which by default excludes the
system namespace doesn't work either.

Then with the second patch applied as well:

| bash-5.2# getfattr -d /bin/sh
| bash-5.2# setfattr -n system.foo -v bar /bin/sh
| bash-5.2# getfattr -d /bin/sh -m-
| getfattr: Removing leading '/' from absolute path names
| # file: bin/sh
| system.foo="bar"
| 
| bash-5.2# setfattr -x system.foo /bin/sh
| bash-5.2# getfattr -d /bin/sh -m-
| bash-5.2#

This looks perfectly fine, thanks a lot!

I still wonder, is the first patch needed anyways? Maybe I fail to
understand something here. Won't it map *every* EPERM to ENOSUP and
can't this be an issue?

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature


Re: Possible issue with linux xattr support?

2023-08-29 Thread Felix Palmen
* Dmitry Chagin  [20230828 18:57]:
> On Mon, Aug 28, 2023 at 08:03:33AM +0200, Felix Palmen wrote:
> > * Cy Schubert  [20230827 16:59]:
> > > 
> > > If we are to break it to fix a problem, maybe a sysctl to enable/disable 
> > > then?
> > 
> > IMHO depends on the exact nature of the problem. If it's confirmed that
> > it (always and only) breaks for jailed processes, just disabling it for
> > them would be the better workaround. "No-op" calls won't break anything.
> > 
> 
> please, try: https://people.freebsd.org/~dchagin/xattrerror.patch

Thanks, I can confirm this avoids the issue in both cases I experienced
(install from GNU coreutils and python).

If I understand this patch correctly, it completely avoids EPERM,
masking it as not supported, so callers should consider it non-fatal,
allowing to silently ignore writing of "system" attributes while still
keeping other functionality?

I wonder whether this could cause trouble in other scenarios (like a
read-only fs or actually missing file permissions)?

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature


Re: Possible issue with linux xattr support?

2023-08-28 Thread Felix Palmen
* Cy Schubert  [20230827 16:59]:
> On August 27, 2023 12:55:23 PM PDT, Felix Palmen  wrote:
> >* Dmitry Chagin  [20230827 22:46]:
> >> On Sun, Aug 27, 2023 at 07:59:32PM +0200, Felix Palmen wrote:
> >> > * Dmitry Chagin  [20230827 20:54]:
> >> > > 1. which fs are you using?
> >> > 
> >> > ZFS.
> >> > 
> >> > > 2. jailed?
> >> > 
> >> > Yes, this is during building ports with poudriere.
> >> > 
> >> 
> >> I think it's a weird prohibition on changing system namespace extattr
> >> attributes, look to comments in extattr_check_cred()
> >
> >Maybe that's when I should finally start trying to understand the stuff
> >in src.git ;)
> >
> >> I can fix this completely disabling exttatr for jailed proc,
> >> however, it's gonna be bullshit, though
> >
> >Would probably be better than nothing. AFAIK, "Linux jails" are used a
> >lot, probably with userlands from distributions actually using xattr.
> >
> >Cheers, Felix
> >
> 
> If we are to break it to fix a problem, maybe a sysctl to enable/disable then?

IMHO depends on the exact nature of the problem. If it's confirmed that
it (always and only) breaks for jailed processes, just disabling it for
them would be the better workaround. "No-op" calls won't break anything.

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature


Re: Possible issue with linux xattr support?

2023-08-27 Thread Felix Palmen
* Dmitry Chagin  [20230827 22:46]:
> On Sun, Aug 27, 2023 at 07:59:32PM +0200, Felix Palmen wrote:
> > * Dmitry Chagin  [20230827 20:54]:
> > > 1. which fs are you using?
> > 
> > ZFS.
> > 
> > > 2. jailed?
> > 
> > Yes, this is during building ports with poudriere.
> > 
> 
> I think it's a weird prohibition on changing system namespace extattr
> attributes, look to comments in extattr_check_cred()

Maybe that's when I should finally start trying to understand the stuff
in src.git ;)

> I can fix this completely disabling exttatr for jailed proc,
> however, it's gonna be bullshit, though

Would probably be better than nothing. AFAIK, "Linux jails" are used a
lot, probably with userlands from distributions actually using xattr.

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature


Re: Possible issue with linux xattr support?

2023-08-27 Thread Felix Palmen
* Dmitry Chagin  [20230827 20:54]:
> 1. which fs are you using?

ZFS.

> 2. jailed?

Yes, this is during building ports with poudriere.

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature


Re: Possible issue with linux xattr support?

2023-08-27 Thread Felix Palmen
* Felix Palmen  [20230825 19:54]:
> To verify, I removed xattr support completely from coreutils (and also
> sed) in commit "linuxsrc: Disable usage of xattr" and indeed, with this
> change, GNU's install works as it should.

I now ran into a second case which makes it very likely the xattr
support is indeed the problem. Trying to create a port for python
setuptools, calling "setup.py install" with debugging opened showed me
this error:

#v+
  File 
"/wrkdirs/usr/ports/devel/linuxsrc-setuptools/work/setuptools-63.1.0/setuptools/_distutils/command/install.py",
 line 706, in run
self.run_command(cmd_name)
  File 
"/wrkdirs/usr/ports/devel/linuxsrc-setuptools/work/setuptools-63.1.0/setuptools/_distutils/cmd.py",
 line 317, in run_command
self.distribution.run_command(command)
  File 
"/wrkdirs/usr/ports/devel/linuxsrc-setuptools/work/setuptools-63.1.0/setuptools/dist.py",
 line 1217, in run_command
super().run_command(command)
  File 
"/wrkdirs/usr/ports/devel/linuxsrc-setuptools/work/setuptools-63.1.0/setuptools/_distutils/dist.py",
 line 987, in run_command
cmd_obj.run()
  File 
"/wrkdirs/usr/ports/devel/linuxsrc-setuptools/work/setuptools-63.1.0/setuptools/command/install_egg_info.py",
 line 42, in run
self.execute(
  File 
"/wrkdirs/usr/ports/devel/linuxsrc-setuptools/work/setuptools-63.1.0/setuptools/_distutils/cmd.py",
 line 338, in execute
util.execute(func, args, msg, dry_run=self.dry_run)
  File 
"/wrkdirs/usr/ports/devel/linuxsrc-setuptools/work/setuptools-63.1.0/setuptools/_distutils/util.py",
 line 344, in execute
func(*args)
  File 
"/wrkdirs/usr/ports/devel/linuxsrc-setuptools/work/setuptools-63.1.0/setuptools/command/install_egg_info.py",
 line 63, in copytree
unpack_archive(self.source, self.target, skimmer)
  File 
"/wrkdirs/usr/ports/devel/linuxsrc-setuptools/work/setuptools-63.1.0/setuptools/archive_util.py",
 line 53, in unpack_archive
driver(filename, extract_dir, progress_filter)
  File 
"/wrkdirs/usr/ports/devel/linuxsrc-setuptools/work/setuptools-63.1.0/setuptools/archive_util.py",
 line 88, in unpack_directory
shutil.copystat(f, target)
  File "/usr/lib64/python3.11/shutil.py", line 380, in copystat
_copyxattr(src, dst, follow_symlinks=follow)
  File "/usr/lib64/python3.11/shutil.py", line 322, in _copyxattr
names = os.listxattr(src, follow_symlinks=follow_symlinks)
^^
PermissionError: [Errno 1] Operation not permitted: 
'setuptools.egg-info/top_level.txt'
#v-

I then rebuilt python passing "ac_cv_header_sys_xattr_h=no" to its
configure script, so it thinks there is no sys/xattr.h header. Indeed,
this made the problem installing setuptools go away.

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature


Re: Possible issue with linux xattr support?

2023-08-25 Thread Felix Palmen
* Felix Palmen  [20230825 19:54]:
> So, hoping for someone with some knowledge how to debug this ;)

Information I forgot to add, sorry:

I did my tests on an aarch64 machine with a kernel built from
a98a0090b2ba64ff0bc3cf71a00fb5f9e31fc1d3.

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature


Possible issue with linux xattr support?

2023-08-25 Thread Felix Palmen
Hi all and Dmitry,

(CC to Dmitry because he added this linux xattr support in
22dca7acf7756c07d3ccbfdc8dfd10fd9ad3f9cf)

I'm currently working on an idea to build a userland for Linuxulator
from source here:
https://github.com/Zirias/zfbsd-ports/commits/linux

Now I ran into an issue with the first port using the full "base"
userland for building (I tried expat2 for this): The "install" tool from
GNU coreutils was unable to set file permissions, and truss showed me
this:

| linux_fsetxattr(0x4,0x401860e8,0x134dd0,0x1c,0x0) ERR#-1 'Operation
| not permitted'

To verify, I removed xattr support completely from coreutils (and also
sed) in commit "linuxsrc: Disable usage of xattr" and indeed, with this
change, GNU's install works as it should.

So, hoping for someone with some knowledge how to debug this ;)

Thanks, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature


Re: Problem compiling py-* ports

2023-04-18 Thread Felix Palmen
* Marek Zarychta  [20230418 11:41]:
> What is the culprit?

Most likely some leftovers from older package versions (so it's only a
problem when building in the live system. A clean jail won't have the
offending files).

>  Removing blindly all py- packages for all affected
> hosts with dependent software is not the best solution.

Depending on your situation, it might or might not be faster than trying
to identify the exact offending files and just removing them ;)

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer (mentee) --{web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature


Re: Problem compiling py-* ports

2023-04-18 Thread Felix Palmen
* Filippo Moretti  [20230418 08:12]:
>   File "/usr/local/lib/python3.9/site-packages/setuptools/_importlib.py", 
> line 31, in 
>     if isinstance(ob, importlib_metadata.MetadataPathFinder)
> AttributeError: module 'importlib_metadata' has no attribute 
> 'MetadataPathFinder'

Looks like you're building directly on your host (not in clean jails)
and the build picks up "something" that's already installed.

I'd probably try to uninstall all python packages, check whether there
are leftovers in LOCALBASE/lib/python3.9 (and remove them if necessary)
and then do a rebuild.

You can avoid this class of issues using poudriere btw...

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer (mentee) --{web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature


Re: Trying to compile theNVIDIA driver ........ however no ^bsd.sysdir.mk^

2022-11-07 Thread Felix Palmen
* louis.free...@xs4all.nl  [20221107 16:21]:
> So I downloaded the driver from the NVIDIA site and tried to compile. That … 
> does not work
> 
> How to fix this!?

Use the port: https://www.freshports.org/x11/nvidia-driver/

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer (mentee) --{web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature


Re: Good practices with bectl

2022-09-21 Thread Felix Palmen
* Nuno Teixeira  [20220921 00:11]:
> (...)
> maybe:
> > yes | make DESTDIR=${BASEDIR} delete-old delete-old-libs

Exactly, DESTDIR is used by all the targets.

BTW, you can just set BATCH_DELETE_OLD_FILES=yes (either on the
command-line or in make.conf) instead of using "yes" here.

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer (mentee) --{web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature


Re: Error during installkernel

2021-10-26 Thread Felix Palmen
* Filippo Moretti via current  [20211026 13:53]:
> I tried to update my system today everything fine but installkernel:==> zlib 
> (install)install -T release -o root -g wheel -m 555 zlib.ko 
> /boot/kernel/install -T dbg -o root -g wheel -m 555 zlib.ko.debug 
> /usr/lib/debug/boot/kernel/kldxref /boot/kernelfailed to read 
> progbitsef_read_entry failed*** Signal 11Stop.make[3]: stopped in 
> /usr/src/sys/modules*** Error code 1Stop.make[2]: stopped in 
> /usr/obj/usr/src/amd64.amd64/sys/STING*** Error code 1Stop.make[1]: stopped 
> in /usr/src*** Error code 1Stop.make: stopped in /usr/src[root@sting 
> /usr/src]# 
> 
> [root@sting /usr/src]# uname -aFreeBSD sting 14.0-CURRENT FreeBSD 
> 14.0-CURRENT #57 heads/main-n250195-6ba2210ee03: Thu Oct 21 21:19:23 CEST 
> 2021 filippo@sting:/usr/obj/usr/src/amd64.amd64/sys/STING amd64 Filippo

Ignore it. The new kernel should boot anyways, and after installworld,
installkernel will finish successfully.

It seems kldxref again needs some new feature, but it's not part of the
temporary tools built, so the host's (old) kldxref is used.

-- 
 Dipl.-Inform. Felix Palmen ,.//..
 {web}  http://palmen-it.de  {jabber} [see email]   ,//palmen-it.de
 {pgp public key} http://palmen-it.de/pub.txt   //   """""""""""
 {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A


signature.asc
Description: PGP signature


Re: git: "overlay" of own remote-branch on official freebsd-ports repo

2021-10-12 Thread Felix Palmen
* Warner Losh  [20211012 10:01]:
> tl;dr: branches are cheap and well supported in git. You just make a branch
> for your
> local changes, and update that however you see fit.
> 
> For ports I have like that, I've just created a branch in git. I rebase the
> branch forward
> each time I update.

+1, I do basically the same. I'd say having a local branch in your local
repo is one ot the killer features of git over svn.

I just do a few details slightly different, maybe it helps as one
possible example. I only fetch 'main' from the official repo and rebase
my 'local' branch onto that. During the rebase, it's easy to solve any
conflicts with changes in 'main'. You still keep a list of your local
commits, well organized.

I recently decided to also publish my local branch. So now I just have
two remotes on my local ports repo, the official FreeBSD repo and
another one on github, looking like this:

  # git remote -v
  origin  https://github.com/Zirias/zfbsd-ports.git (fetch)
  origin  https://github.com/Zirias/zfbsd-ports.git (push)
  upstreamhttps://git.freebsd.org/ports.git (fetch)
  upstreamhttps://git.freebsd.org/ports.git (push)

With that and remote branch tracking set up correctly, I just need these
commands (I have them in a script) to update from the official repo,
rebase and force push to my github repo:

  git checkout local
  git fetch upstream main:main && git rebase main
  git push -f --all

BTW, git leaves working copy changes alone if possible, so maybe it's
poudriere's way of using git that erases them – just use git directly
instead of poudriere. And then, I always hated having random local
changes not organized in any way, this quickly grows into a maintenance
nightmare, so I'm very thankful I can now easily use git branches
instead.

-- 
 Dipl.-Inform. Felix Palmen ,.//..
 {web}  http://palmen-it.de  {jabber} [see email]   ,//palmen-it.de
 {pgp public key} http://palmen-it.de/pub.txt   //   """""""""""
 {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A


signature.asc
Description: PGP signature


Re: Writing large build logs to NFS extremely slow?

2021-10-09 Thread Felix Palmen
* Rick Macklem  [20211009 15:35]:
> Felix Palmen wrote:
> Assuming your NFS performance is acceptable for other things and it
> is only this log file that is a problem, then I doubt there is much you
> can do to improve it.

Yes, that's the only problem I found so far…

> --> Append (as in O_APPEND opens) are a poor case for NFS, since there
>   is no append write in NFS. To approximate append write, it must flush
>   all dirty data to the server, do a Getattr to find out the file's 
> current
>   size and then do the write (over and over and over again).

Ok, thanks for the insight here! So maybe, I could have a look at
poudriere's code? If I understand you correctly, keeping the file open
and just issuing more write() calls wouldn't trigger that problem?

> You could try the "nocto" mount option, which might help, if the log file
> is being re-opened many times, but I doubt it will help.

Well, I take any suggestion, so will try that as well and report back,
thanks again!

Side note, please don't CC/To me, I'm subscribed the list ;)

-- 
 Dipl.-Inform. Felix Palmen ,.//..
 {web}  http://palmen-it.de  {jabber} [see email]   ,//palmen-it.de
 {pgp public key} http://palmen-it.de/pub.txt   //   """""""""""
 {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A


signature.asc
Description: PGP signature


Re: Writing large build logs to NFS extremely slow?

2021-10-09 Thread Felix Palmen
* Mehmet Erol Sanliturk  [20211007 10:42]:
> The problem is caused mainly by  NFS definition parameters .
> 
> If you study NFS definition parameters one by one , I think you will be
> able to find which one is effective .
> 
> My opinion is the one setting is "write directly to disk" , i.e. , "do not
> use the cache" .
> 
> In the  "write directly to disk" case , without completion of a write , the
> computer in use is waiting for completion of previous write operation
> before writing a new record . This is useful in case of abrupt program
> terminations because every record is written into the disk file , by
> consuming more time .

Well this is kind of what I assume might be the problem. Could anyone
give me a hint what configuration to change on FreeBSD?

-- 
 Dipl.-Inform. Felix Palmen ,.//..
 {web}  http://palmen-it.de  {jabber} [see email]   ,//palmen-it.de
 {pgp public key} http://palmen-it.de/pub.txt   //   """""""""""
 {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A


signature.asc
Description: PGP signature


Writing large build logs to NFS extremely slow?

2021-10-06 Thread Felix Palmen
Hi all,

I use a -CURRENT bhyve vm for testing port builds with poudriere. As
this vm is only running when needed, but I want to always have access to
the build logs, I use NFS to mount /usr/local/poudriere/data/logs from
the host.

I noticed some few ports take ridiculously long to build while barely
using any CPU time at all. On a closer look, that's all ports producing
a lot of compiler (warning) output, e.g. gcc, gnutls, gtk2, …

So I assume appending to a large file via NFS gets slower and slower. Is
there any mount option I could try to fix this? Right now I only have
`nolockd`, I also tried `noncontigwr` which didn't change anything.

Thinking about alternatives to NFS, are there any news for client-side
9p virtfs? I found <https://github.com/swills/virtfs-9p-kmod> which
still builds with a few minor adaptions, but trying to mount a 9p share
freezes the machine.

Would you suggest a different mailing list to ask?

BR, Felix

-- 
 Dipl.-Inform. Felix Palmen ,.//..
 {web}  http://palmen-it.de  {jabber} [see email]   ,//palmen-it.de
 {pgp public key} http://palmen-it.de/pub.txt   //   """""""""""
 {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A


signature.asc
Description: PGP signature


Re: Is there any OS builtin git command like svnlite ?

2021-03-14 Thread Felix Palmen
* Guido Falsi via freebsd-current  [20210314 
21:36]:
> The git port has flavors. The full port can be excessive, git@lite looks
> good, if one only wants basic functionality there is also git@tiny, but I
> don't know what limitations that entails.

git@tiny has all options disabled except for curl, which is needed to
access http(s) repos. git@lite also has iconv, pcre, git-subtree and
git-send-email. So, the tiny flavor is perfectly suitable for cloning
and working with the FreeBSD repos.

-- 
 Dipl.-Inform. Felix Palmen ,.//..
 {web}  http://palmen-it.de  {jabber} [see email]   ,//palmen-it.de
 {pgp public key} http://palmen-it.de/pub.txt   //   """""""""""
 {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A


signature.asc
Description: PGP signature


iwn(4) crashing when wlan device is brought up, CA-N-6200

2014-11-26 Thread Felix Palmen
Hi all,

I just bought a Centrino Advanced N-6200 mini-pcie card because it should be 
supported by iwn(4) -- unfortunately it leads to a kernel panic the instant I 
try to do

# ifconfig wlan0 up

The creation of wlan0 on top of iwn0 works. Here are the (I hope) most 
relevant exerpts from core.txt:

FreeBSD photon.home.palmen-it.de 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r275075: 
Wed Nov 26 11:06:23 CET 2014 r...@photon.home.palmen-
it.de:/usr/obj/usr/src/sys/NODEBUG  amd64

dmesg:
[...]
iwn0: Intel Centrino Advanced-N 6200 mem 0xf020-0xf0201fff at device 0.0 
on pci1
wlan0: Ethernet address: 00:27:c1:03:a0:89
iwn0: iwn_read_firmware: ucode rev=0x09dd0401
iwn0: iwn_intr: fatal firmware error
iwn_fatal_intr: bad firmware error log address 0x
iwn0: iwn_panicked: controller panicked, iv_state = 0; resetting...
iwn0: iwn_read_firmware: ucode rev=0x09dd0401
iwn0: iwn_hw_init: timeout waiting for adapter to initialize, error 35
iwn0: iwn_init_locked: could not initialize hardware, error 35
iwn0: iwn5000_post_alive: could not configure WiMAX coexistence, error 35

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0xffe0
fault code  = supervisor write data, page not present
instruction pointer = 0x20:0x809a300a
stack pointer   = 0x28:0xfe0107cdda70
frame pointer   = 0x28:0xfe0107cddaa0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 0 (iwn0 net80211 taskq)
trap number = 12

stacktrace:
(kgdb) #0  doadump (textdump=value optimized out) at pcpu.h:219
#1  0x80962918 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:447
#2  0x80962e40 in panic (fmt=value optimized out)
at /usr/src/sys/kern/kern_shutdown.c:746
#3  0x80dae65f in trap_fatal (frame=value optimized out, 
eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:866
#4  0x80dae9ac in trap_pfault (frame=0xfe0107cdd9c0, 
usermode=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:677
#5  0x80dadfce in trap (frame=0xfe0107cdd9c0)
at /usr/src/sys/amd64/amd64/trap.c:426
#6  0x80d90342 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:231
#7  0x809a300a in firmware_put (p=0x0, flags=1)
at /usr/src/sys/kern/subr_firmware.c:367
#8  0x82638c58 in iwn_init_locked (sc=0xfe0002599000)
at /usr/src/sys/modules/iwn/../../dev/iwn/if_iwn.c:8646
#9  0x82633e3c in iwn_ioctl (ifp=value optimized out, 
cmd=value optimized out, data=value optimized out)
at /usr/src/sys/modules/iwn/../../dev/iwn/if_iwn.c:4924
#10 0x809b4975 in taskqueue_run_locked (queue=0xf80005efe900)
at /usr/src/sys/kern/subr_taskqueue.c:356
#11 0x809b5788 in taskqueue_thread_loop (arg=value optimized out)
at /usr/src/sys/kern/subr_taskqueue.c:623
#12 0x8092aa8a in fork_exit (
callout=0x809b56c0 taskqueue_thread_loop, 
arg=0xfe0001de70f0, frame=0xfe0107cddc00)
at /usr/src/sys/kern/kern_fork.c:977
#13 0x80d9087e in fork_trampoline ()
at /usr/src/sys/amd64/amd64/exception.S:605
#14 0x in ?? ()

I pasted the complete core.txt here: http://pastebin.com/KipkYx1y

Best regards,
Felix

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: iwn(4) crashing when wlan device is brought up, CA-N-6200

2014-11-26 Thread Felix Palmen
Hi Adrian,

Am Mittwoch, 26. November 2014, 09:27:32 schrieb Adrian Chadd:
 Oh! Please file a PR for this.

Done, https://bugs.freebsd.org/bugzilla//show_bug.cgi?id=195433

 This is two problems:
 
 * the NIC isn't being setup fully correctly - I'll see if i have an
 Intel 6200 in my pile-o-nics;
 * .. and the re-initialise path is slightly broken it seems and it's
 panicing. :)

I thought so, the page fault leading to the panic happens during a re-
initialization attempt. A single PR is still ok? I guess further conversation 
should take place through the PR now ... just in case, if it helps debugging, 
I could build the kernel with full debugging capabilities and provide the 
dumped core.

Thanks for your reply!

BR, Felix
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org