Boot hangs after exausting uhub2: 7 ports with 7 removable, self powered

2019-11-25 Thread Thomas Schweikle 
Hi!

since 12.1-ALPHA9 FreeBSD wont boot anymore into multiuser. 12.0-ALPHA8 is
ok, but not 12.0-ALPHA9. Same for:

- FreeBSD 11.3_RELEASE, 11_STABLE
- FreeBSD 12.1_RELEASE, 12_STABLE
- FreeBSD 13-HEAD

All on zfs without any ufs slice/partition/disk.
It is the same for amd-64 and arm, arm64 architectures.
Looks like ufs only systems do not have any problems booting.

No hints about any changes to boot processes. ZFS loads, finds zfs:zroot.
After this message some usb related stuff is printed, the last line then is
"usb2: 7 ports with 7 removable, self powered". Module opensolaris.ko is
build and loads, right together with module zfs.ko. So zfs shall work.
Any idea what is going wrong here?

-- 
Thomas
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Error building stable/12 (amd64) at r355087

2019-11-25 Thread David Wolfskill 
This is during a source-based update from r355048 to r355087, during
"stage 4.3: building everything" (using META_MODE); meta file reads:

# Meta data file /common/S3/obj/usr/src/amd64.amd64/usr.sbin/camdd/camdd.o.meta
CMD cc -target x86_64-unknown-freebsd12.1 
--sysroot=/common/S3/obj/usr/src/amd64.amd64/tmp 
-B/common/S3/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe   -std=gnu99 
-fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter 
-Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls 
-Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations 
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable  
-Qunused-arguments  -c /usr/src/usr.sbin/camdd/camdd.c -o camdd.o
CMD 
CWD /common/S3/obj/usr/src/amd64.amd64/usr.sbin/camdd
TARGET camdd.o
-- command output --
In file included from /usr/src/usr.sbin/camdd/camdd.c:54:
In file included from 
/common/S3/obj/usr/src/amd64.amd64/tmp/usr/include/machine/bus.h:6:
In file included from 
/common/S3/obj/usr/src/amd64.amd64/tmp/usr/include/x86/bus.h:1043:
In file included from 
/common/S3/obj/usr/src/amd64.amd64/tmp/usr/include/machine/bus_dma.h:34:
/common/S3/obj/usr/src/amd64.amd64/tmp/usr/include/x86/bus_dma.h:182:1: error: 
unknown type name 'bool'
bool bus_dma_dmar_set_buswide(device_t dev);
^
/common/S3/obj/usr/src/amd64.amd64/tmp/usr/include/x86/bus_dma.h:182:31: error: 
unknown type name 'device_t'
bool bus_dma_dmar_set_buswide(device_t dev);
  ^
2 errors generated.

*** Error code 1


Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Claiming that Ukraine meddled in the 2016 US election is aiding and
abetting Putin -- who does not have the US's best interest at heart.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Error building stable/12 (amd64) at r355087

2019-11-25 Thread Konstantin Belousov 
On Mon, Nov 25, 2019 at 03:58:10AM -0800, David Wolfskill wrote:
> This is during a source-based update from r355048 to r355087, during
> "stage 4.3: building everything" (using META_MODE); meta file reads:
> 
> # Meta data file 
> /common/S3/obj/usr/src/amd64.amd64/usr.sbin/camdd/camdd.o.meta
> CMD cc -target x86_64-unknown-freebsd12.1 
> --sysroot=/common/S3/obj/usr/src/amd64.amd64/tmp 
> -B/common/S3/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe   -std=gnu99 
> -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W 
> -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes 
> -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow 
> -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs 
> -Wredundant-decls -Wold-style-definition -Wno-pointer-sign 
> -Wmissing-variable-declarations -Wno-empty-body -Wno-string-plus-int 
> -Wno-unused-const-variable  -Qunused-arguments  -c 
> /usr/src/usr.sbin/camdd/camdd.c -o camdd.o
> CMD 
> CWD /common/S3/obj/usr/src/amd64.amd64/usr.sbin/camdd
> TARGET camdd.o
> -- command output --
> In file included from /usr/src/usr.sbin/camdd/camdd.c:54:
> In file included from 
> /common/S3/obj/usr/src/amd64.amd64/tmp/usr/include/machine/bus.h:6:
> In file included from 
> /common/S3/obj/usr/src/amd64.amd64/tmp/usr/include/x86/bus.h:1043:
> In file included from 
> /common/S3/obj/usr/src/amd64.amd64/tmp/usr/include/machine/bus_dma.h:34:
> /common/S3/obj/usr/src/amd64.amd64/tmp/usr/include/x86/bus_dma.h:182:1: 
> error: unknown type name 'bool'
> bool bus_dma_dmar_set_buswide(device_t dev);
> ^
> /common/S3/obj/usr/src/amd64.amd64/tmp/usr/include/x86/bus_dma.h:182:31: 
> error: unknown type name 'device_t'
> bool bus_dma_dmar_set_buswide(device_t dev);
>   ^
> 2 errors generated.
> 
> *** Error code 1

I hope that this is fixed by r355089.  I did not tracked down how HEAD
was immune to the problem.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Error building stable/12 (amd64) at r355087

2019-11-25 Thread peter . blok 
I can confirm it has been fixed.

> On 25 Nov 2019, at 15:21, Konstantin Belousov  wrote:
> 
> On Mon, Nov 25, 2019 at 03:58:10AM -0800, David Wolfskill wrote:
>> This is during a source-based update from r355048 to r355087, during
>> "stage 4.3: building everything" (using META_MODE); meta file reads:
>> 
>> # Meta data file 
>> /common/S3/obj/usr/src/amd64.amd64/usr.sbin/camdd/camdd.o.meta
>> CMD cc -target x86_64-unknown-freebsd12.1 
>> --sysroot=/common/S3/obj/usr/src/amd64.amd64/tmp 
>> -B/common/S3/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe   -std=gnu99 
>> -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W 
>> -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes 
>> -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow 
>> -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs 
>> -Wredundant-decls -Wold-style-definition -Wno-pointer-sign 
>> -Wmissing-variable-declarations -Wno-empty-body -Wno-string-plus-int 
>> -Wno-unused-const-variable  -Qunused-arguments  -c 
>> /usr/src/usr.sbin/camdd/camdd.c -o camdd.o
>> CMD 
>> CWD /common/S3/obj/usr/src/amd64.amd64/usr.sbin/camdd
>> TARGET camdd.o
>> -- command output --
>> In file included from /usr/src/usr.sbin/camdd/camdd.c:54:
>> In file included from 
>> /common/S3/obj/usr/src/amd64.amd64/tmp/usr/include/machine/bus.h:6:
>> In file included from 
>> /common/S3/obj/usr/src/amd64.amd64/tmp/usr/include/x86/bus.h:1043:
>> In file included from 
>> /common/S3/obj/usr/src/amd64.amd64/tmp/usr/include/machine/bus_dma.h:34:
>> /common/S3/obj/usr/src/amd64.amd64/tmp/usr/include/x86/bus_dma.h:182:1: 
>> error: unknown type name 'bool'
>> bool bus_dma_dmar_set_buswide(device_t dev);
>> ^
>> /common/S3/obj/usr/src/amd64.amd64/tmp/usr/include/x86/bus_dma.h:182:31: 
>> error: unknown type name 'device_t'
>> bool bus_dma_dmar_set_buswide(device_t dev);
>>  ^
>> 2 errors generated.
>> 
>> *** Error code 1
> 
> I hope that this is fixed by r355089.  I did not tracked down how HEAD
> was immune to the problem.
> ___
> freebsd-stable@freebsd.org  mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable 
> 
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org 
> "

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

Re: Error building stable/12 (amd64) at r355087

2019-11-25 Thread Tomoaki AOKI 
r347836 (not MFC'ed) on head eliminates inclusion of machine/bus.h for
usr.sbin/camdd/camdd.c.
This whole commit introduces some bool functions, but head builds fine.

I'm not shure applying camdd.c part alone is OK, so cherry-picked
this revision excluding sys/compat/linuxkpi/common/src/linux_pci.c part
and it fixes build. Not yet tested r355089, though.


On Mon, 25 Nov 2019 16:21:41 +0200
Konstantin Belousov  wrote:

> On Mon, Nov 25, 2019 at 03:58:10AM -0800, David Wolfskill wrote:
> > This is during a source-based update from r355048 to r355087, during
> > "stage 4.3: building everything" (using META_MODE); meta file reads:
> > 
> > # Meta data file 
> > /common/S3/obj/usr/src/amd64.amd64/usr.sbin/camdd/camdd.o.meta
> > CMD cc -target x86_64-unknown-freebsd12.1 
> > --sysroot=/common/S3/obj/usr/src/amd64.amd64/tmp 
> > -B/common/S3/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe   -std=gnu99 
> > -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W 
> > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes 
> > -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow 
> > -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs 
> > -Wredundant-decls -Wold-style-definition -Wno-pointer-sign 
> > -Wmissing-variable-declarations -Wno-empty-body -Wno-string-plus-int 
> > -Wno-unused-const-variable  -Qunused-arguments  -c 
> > /usr/src/usr.sbin/camdd/camdd.c -o camdd.o
> > CMD 
> > CWD /common/S3/obj/usr/src/amd64.amd64/usr.sbin/camdd
> > TARGET camdd.o
> > -- command output --
> > In file included from /usr/src/usr.sbin/camdd/camdd.c:54:
> > In file included from 
> > /common/S3/obj/usr/src/amd64.amd64/tmp/usr/include/machine/bus.h:6:
> > In file included from 
> > /common/S3/obj/usr/src/amd64.amd64/tmp/usr/include/x86/bus.h:1043:
> > In file included from 
> > /common/S3/obj/usr/src/amd64.amd64/tmp/usr/include/machine/bus_dma.h:34:
> > /common/S3/obj/usr/src/amd64.amd64/tmp/usr/include/x86/bus_dma.h:182:1: 
> > error: unknown type name 'bool'
> > bool bus_dma_dmar_set_buswide(device_t dev);
> > ^
> > /common/S3/obj/usr/src/amd64.amd64/tmp/usr/include/x86/bus_dma.h:182:31: 
> > error: unknown type name 'device_t'
> > bool bus_dma_dmar_set_buswide(device_t dev);
> >   ^
> > 2 errors generated.
> > 
> > *** Error code 1
> 
> I hope that this is fixed by r355089.  I did not tracked down how HEAD
> was immune to the problem.
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


-- 
Tomoaki AOKI
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Long-shot: repeatable macOS samba share unmounting during Lightroom import

2019-11-25 Thread peter . blok 
The fruit module forces avahi or mdns_responder to be compiled as well. A share 
dispappearing could be due to some interaction with avahi. It could be that the 
combination samba+fruit+avahi and samba+avahi is having different behavior.

Peter



> On 24 Nov 2019, at 12:15, Pete French  wrote:
> 
> I have a very similar setup to you for serving files to my Mac from a FreeBSD 
> server. I haven't seen the unmount problem, but I di have a few oddities 
> until I added the 'fruit' module on the Samba side, which helps with 
> compatbiloty with the Mac. The appropriate bit of my config looks like this:
> 
>   vfs objects = fruit streams_xattr zfsacl
>   fruit:resource = xattr
>   fruit:encoding = private
> 
> Don't ask me what they do anymore, I added them ages ago, but it does work 
> very nicely for me. You may already have this of course, but worth pointing 
> out just in case as it took me a few years to discover it!
> 
> As someone else has said though, this may well be a Catalina bug. I am not 
> running that (MacBook too old, and not buying another until the new keyboards 
> are avilable n the replacement I want).
> 
> -pete.
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

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

ZFS ghost files on 11.3-STABLE

2019-11-25 Thread Gareth de Vaux 
Hi all, I deleted a file (rm filter) by mistake instead of its backup 'filter~',
however it seems a remnant of a much older version of the file (given by its
date and content) is half hanging around?

$ ls -l filter 
ls: filter: No such file or directory

$ ls -l filter*
-rw-r--r--  1 lordcow  lordcow  18179 Mar 28  2019 filter 
-rw---  1 lordcow  lordcow  19092 Nov 20 23:36 filter~

$ stat filter
stat: filter: stat: No such file or directory

$ stat filter*
1525321853 1911959 -rw-r--r-- 1 lordcow lordcow 4294967295 18179 "Mar 28 
17:07:34 2019" "Mar 28 17:08:07 2019" "Mar 28 17:08:07 2019" "Mar 28 17:07:34 
2019" 18432 24 0x800 filter 
1525321853 833819 -rw--- 1 lordcow lordcow 4294967295 19092 "Aug 10 
22:31:53 2016" "Nov 20 23:36:40 2019" "Nov 24 23:08:13 2019" "Nov 20 23:36:40 
2019" 19456 24 0x800 filter~

$ cat filter 
cat: filter: No such file or directory

$ cat filter*
(cats both files)

A zpool scrub returns no errors

I haven't tried to overwrite the file yet incase anyone wants some output.


FreeBSD 11.3-STABLE #0 r353939

ZFS filesystem version: 5
ZFS storage pool version: features support (5000)
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ZFS ghost files on 11.3-STABLE

2019-11-25 Thread Alan Somers 
On Mon, Nov 25, 2019 at 10:01 AM Gareth de Vaux  wrote:

> Hi all, I deleted a file (rm filter) by mistake instead of its backup
> 'filter~',
> however it seems a remnant of a much older version of the file (given by
> its
> date and content) is half hanging around?
>
> $ ls -l filter
> ls: filter: No such file or directory
>
> $ ls -l filter*
> -rw-r--r--  1 lordcow  lordcow  18179 Mar 28  2019 filter
> -rw---  1 lordcow  lordcow  19092 Nov 20 23:36 filter~
>
> $ stat filter
> stat: filter: stat: No such file or directory
>
> $ stat filter*
> 1525321853 1911959 -rw-r--r-- 1 lordcow lordcow 4294967295 18179 "Mar 28
> 17:07:34 2019" "Mar 28 17:08:07 2019" "Mar 28 17:08:07 2019" "Mar 28
> 17:07:34 2019" 18432 24 0x800 filter
> 1525321853 833819 -rw--- 1 lordcow lordcow 4294967295 19092 "Aug 10
> 22:31:53 2016" "Nov 20 23:36:40 2019" "Nov 24 23:08:13 2019" "Nov 20
> 23:36:40 2019" 19456 24 0x800 filter~
>
> $ cat filter
> cat: filter: No such file or directory
>
> $ cat filter*
> (cats both files)
>
> A zpool scrub returns no errors
>
> I haven't tried to overwrite the file yet incase anyone wants some output.
>
>
> FreeBSD 11.3-STABLE #0 r353939
>
> ZFS filesystem version: 5
> ZFS storage pool version: features support (5000)
>

Oh Lord Cow, is there a directory beginning with the word filter and
containing files named filter and filter~?  Do "ls -ld filter*".
-Alan
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ZFS ghost files on 11.3-STABLE

2019-11-25 Thread Miroslav Lachman 

Gareth de Vaux wrote on 2019/11/25 18:00:

Hi all, I deleted a file (rm filter) by mistake instead of its backup 'filter~',
however it seems a remnant of a much older version of the file (given by its
date and content) is half hanging around?

$ ls -l filter
ls: filter: No such file or directory

$ ls -l filter*
-rw-r--r--  1 lordcow  lordcow  18179 Mar 28  2019 filter
-rw---  1 lordcow  lordcow  19092 Nov 20 23:36 filter~

$ stat filter
stat: filter: stat: No such file or directory

$ stat filter*
1525321853 1911959 -rw-r--r-- 1 lordcow lordcow 4294967295 18179 "Mar 28 17:07:34 2019" "Mar 28 17:08:07 
2019" "Mar 28 17:08:07 2019" "Mar 28 17:07:34 2019" 18432 24 0x800 filter
1525321853 833819 -rw--- 1 lordcow lordcow 4294967295 19092 "Aug 10 22:31:53 2016" "Nov 20 23:36:40 
2019" "Nov 24 23:08:13 2019" "Nov 20 23:36:40 2019" 19456 24 0x800 filter~

$ cat filter
cat: filter: No such file or directory

$ cat filter*
(cats both files)

A zpool scrub returns no errors

I haven't tried to overwrite the file yet incase anyone wants some output.


FreeBSD 11.3-STABLE #0 r353939

ZFS filesystem version: 5
ZFS storage pool version: features support (5000)


Do you have snapshot of this dataset before you run the "rm filter"? 
What files are listed there?
It is possible you have some non printable (invisible) character in the 
filename. It can be trailing space, newline or something else so in fact 
it has different filename than the one of deleted file but it looks the 
same.


Miroslav Lachman
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Long-shot: repeatable macOS samba share unmounting during Lightroom import

2019-11-25 Thread Charles Sprickman via freebsd-stable 

> On Nov 24, 2019, at 10:19 AM, peter.b...@bsd4all.org wrote:
> 
> The fruit module forces avahi or mdns_responder to be compiled as well. A 
> share dispappearing could be due to some interaction with avahi. It could be 
> that the combination samba+fruit+avahi and samba+avahi is having different 
> behavior.

You guys are making feel like my laziness in sticking with AFP is actually 
paying off. :)

Apple’s QA is really garbage these days. I have a hackintosh at home that by 
some fluke of its uniqueness can cause a kernel panic on any mac connecting to 
it via SMB. Can reproduce it all day. Connect, do stuff, and after about 5 
minutes idle, the connecting machine will panic. Report it every time, existed 
since at least 10.12...

Charles

> Peter
> 
> 
> 
>> On 24 Nov 2019, at 12:15, Pete French  wrote:
>> 
>> I have a very similar setup to you for serving files to my Mac from a 
>> FreeBSD server. I haven't seen the unmount problem, but I di have a few 
>> oddities until I added the 'fruit' module on the Samba side, which helps 
>> with compatbiloty with the Mac. The appropriate bit of my config looks like 
>> this:
>> 
>>  vfs objects = fruit streams_xattr zfsacl
>>  fruit:resource = xattr
>>  fruit:encoding = private
>> 
>> Don't ask me what they do anymore, I added them ages ago, but it does work 
>> very nicely for me. You may already have this of course, but worth pointing 
>> out just in case as it took me a few years to discover it!
>> 
>> As someone else has said though, this may well be a Catalina bug. I am not 
>> running that (MacBook too old, and not buying another until the new 
>> keyboards are avilable n the replacement I want).
>> 
>> -pete.
>> ___
>> freebsd-stable@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
> 
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

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

Re: ZFS ghost files on 11.3-STABLE

2019-11-25 Thread Gareth de Vaux 
On Mon 2019-11-25 (18:35), Miroslav Lachman wrote:
> It is possible you have some non printable (invisible) character in the 
> filename. It can be trailing space, newline or something else so in fact

Wow I'm an idiot, thought I'd spotted a bug, yes there was a trailing space,
many thanks.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Access to NETMAP from c++ program

2019-11-25 Thread Ryan Stone 
Remove "using namespace std;" from your program.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"