Re: kernel config question
John Baldwin writes: > -[8] In order to have a kernel that can run the 4.x binaries needed to > -do an installworld, you must include the COMPAT_FREEBSD4 option in > -your kernel. Failure to do so may leave you with a system that is > -hard to boot to recover. A similar kernel option COMPAT_FREEBSD5 is > -required to run the 5.x binaries on more recent kernels. And so on > -for COMPAT_FREEBSD6 and COMPAT_FREEBSD7. > +[8] The new kernel must be able to run existing binaries used by > +an installworld. When upgrading across major versions, the new > +kernel's configuration must include the correct COMPAT_FREEBSD > +option for existing binaries (e.g. COMPAT_FREEBSD11 to run 11.x > +binaries). Failure to do so may leave you with a system that is > +hard to boot to recover. A GENERIC kernel will include suitable > +compatibility options to run binaries from older branches. Maybe not perfect, but _much_ better. Thanks. Respectfully, Robert Huff ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildworld falure: truncated or malformed archive
On Wed, Jan 2, 2019, 1:42 PM John Baldwin On 12/31/18 12:08 PM, Warner Losh wrote: > > On Mon, Dec 31, 2018, 1:36 PM Ryan Stone > > >> Does this mean that it's currently impossible to build a world with > >> debug symbols? > >> > > > > Yes. Clang is simply too big until 64 bit offset support goes in. > > We actually build clang (and llvm) with stripped down debug symbols by > default. If you don't put any DEBUG_* foo in src.conf you will get debug > symbols for all of the world including the limited ones for clang. (We > use -gline-tables-only or some > Yea, DEBUG_FLAGS=-g is what breaks it... Warner > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: kernel config question
On 1/2/19 1:31 PM, Robert Huff wrote: > > John Baldwin writes: > >> >> [8] In order to have a kernel that can run the 4.x binaries >> >> needed to do an installworld, you must include the >> >> COMPAT_FREEBSD4 option in your kernel. [...] >> >> > No, COMPAT_FREEBSD4 is not needed. Maybe COMPAT_FREEBSD11 is needed. >> >> Yes, that text needs to be made more generic to say that you will need >> COMPAT_FREEBSD. Though we've also had some major branches that >> didn't get a COMPAT_FREEBSD option. > > Are any of those still supported? I'm not sure, but I mean more that you can't assume we will always have a COMPAT_FREEBSD. There was a COMPAT_FREEBSD11. It looks like we actually only skipped COMPAT_FREEBSD8 to date. Perhaps we can just avoid worrying about the lack of COMPAT_FREEBSD. The text does say "and so on" for newer versions, but it's probably not clear. How about this: Index: UPDATING === --- UPDATING(revision 342703) +++ UPDATING(working copy) @@ -1901,12 +1901,13 @@ COMMON ITEMS: can be deleted by "make delete-old-libs", but you have to make sure that no program is using those libraries anymore. - [8] In order to have a kernel that can run the 4.x binaries needed to - do an installworld, you must include the COMPAT_FREEBSD4 option in - your kernel. Failure to do so may leave you with a system that is - hard to boot to recover. A similar kernel option COMPAT_FREEBSD5 is - required to run the 5.x binaries on more recent kernels. And so on - for COMPAT_FREEBSD6 and COMPAT_FREEBSD7. + [8] The new kernel must be able to run existing binaries used by + an installworld. When upgrading across major versions, the new + kernel's configuration must include the correct COMPAT_FREEBSD + option for existing binaries (e.g. COMPAT_FREEBSD11 to run 11.x + binaries). Failure to do so may leave you with a system that is + hard to boot to recover. A GENERIC kernel will include suitable + compatibility options to run binaries from older branches. Make sure that you merge any new devices from GENERIC since the last time you updated your kernel config file. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: kernel config question
John Baldwin writes: > >> [8] In order to have a kernel that can run the 4.x binaries > >> needed to do an installworld, you must include the > >> COMPAT_FREEBSD4 option in your kernel. [...] > > > No, COMPAT_FREEBSD4 is not needed. Maybe COMPAT_FREEBSD11 is needed. > > Yes, that text needs to be made more generic to say that you will need > COMPAT_FREEBSD. Though we've also had some major branches that > didn't get a COMPAT_FREEBSD option. Are any of those still supported? Curiously, Robert Huff ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: kernel config question
On 1/2/19 12:02 PM, Kurt Jaeger wrote: > Hi! > >> FreeBSD 12.0-CURRENT #0 r331659: Thu Mar 29 12:31:36 EDT 2018 amd64 >> >> to CURRENT (as of last midnight. >> Does this, in src/UPDATING: >> >> [8] In order to have a kernel that can run the 4.x binaries >> needed to do an installworld, you must include the >> COMPAT_FREEBSD4 option in your kernel. [...] > >> (It seems ... irrational ... one would need compatibility stuff >> going back to FreeBSD 4 to rebuild/update FreeBSD 13.) > > No, COMPAT_FREEBSD4 is not needed. Maybe COMPAT_FREEBSD11 is needed. Yes, that text needs to be made more generic to say that you will need COMPAT_FREEBSD. Though we've also had some major branches that didn't get a COMPAT_FREEBSD option. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildworld falure: truncated or malformed archive
On 12/31/18 12:08 PM, Warner Losh wrote: > On Mon, Dec 31, 2018, 1:36 PM Ryan Stone >> Does this mean that it's currently impossible to build a world with >> debug symbols? >> > > Yes. Clang is simply too big until 64 bit offset support goes in. We actually build clang (and llvm) with stripped down debug symbols by default. If you don't put any DEBUG_* foo in src.conf you will get debug symbols for all of the world including the limited ones for clang. (We use -gline-tables-only or some such for clang). -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: kernel config question
Hi! > FreeBSD 12.0-CURRENT #0 r331659: Thu Mar 29 12:31:36 EDT 2018 amd64 > > to CURRENT (as of last midnight. > Does this, in src/UPDATING: > > [8] In order to have a kernel that can run the 4.x binaries > needed to do an installworld, you must include the > COMPAT_FREEBSD4 option in your kernel. [...] >(It seems ... irrational ... one would need compatibility stuff > going back to FreeBSD 4 to rebuild/update FreeBSD 13.) No, COMPAT_FREEBSD4 is not needed. Maybe COMPAT_FREEBSD11 is needed. -- p...@freebsd.org +49 171 3101372 One year to go ! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
kernel config question
I'm updating a machine from: FreeBSD 12.0-CURRENT #0 r331659: Thu Mar 29 12:31:36 EDT 2018 amd64 to CURRENT (as of last midnight. Does this, in src/UPDATING: [8] In order to have a kernel that can run the 4.x binaries needed to do an installworld, you must include the COMPAT_FREEBSD4 option in your kernel. Failure to do so may leave you with a system that is hard to boot to recover. A similar kernel option COMPAT_FREEBSD5 is required to run the 5.x binaries on more recent kernels. And so on for COMPAT_FREEBSD6 and COMPAT_FREEBSD7. still apply? (It seems ... irrational ... one would need compatibility stuff going back to FreeBSD 4 to rebuild/update FreeBSD 13.) Respectfully, Robert Huff ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r342378: usbconfig takes 3-5 minutes to read the bus
On 1/2/19 4:57 PM, Hans Petter Selasky wrote: On 1/2/19 4:47 PM, Matthias Apitz wrote: After card removal and insert devd(8) starts a new pcsd: Does pcsd install this devd(8) rule? I thought pcsd would no longer need to be restarted. > Let's move this thread freebsd-usb only. Have a look here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231076 --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r342378: usbconfig takes 3-5 minutes to read the bus
On 1/2/19 4:47 PM, Matthias Apitz wrote: After card removal and insert devd(8) starts a new pcsd: Does pcsd install this devd(8) rule? I thought pcsd would no longer need to be restarted. --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r342378: usbconfig takes 3-5 minutes to read the bus
El día miércoles, enero 02, 2019 a las 12:37:37p. m. +0100, Hans Petter Selasky escribió: > > Nothing. Only on boot it sees the card: > > And you are using the latest version of pcsd ? Yes. Compiled with all ports from December 23. > > > Jan 2 11:25:39 c720-r342378 kernel: ugen0.1: <0x8086 XHCI root HUB> at > > usbus0 > > Jan 2 11:25:39 c720-r342378 kernel: ugen1.1: at > > usbus1 > > Jan 2 11:25:39 c720-r342378 kernel: ugen1.2: > 0x8000> at usbus1 > > Jan 2 11:25:39 c720-r342378 kernel: ugen0.2: at > > usbus0 > > Jan 2 11:25:39 c720-r342378 kernel: ugen0.3: > 0xe056> at usbus0 > > Jan 2 11:25:39 c720-r342378 kernel: ugen0.4: > Token> at usbus0 > > There has been some changes in libusb recently . After card removal and insert devd(8) starts a new pcsd: Jan 2 16:39:11 c720-r342378 kernel: ugen0.4: at usbus0 Jan 2 16:39:11 c720-r342378 root[13636]: CCID uTrust, type: ATTACH, system: USB, subsystem: INTERFACE Jan 2 16:39:11 c720-r342378 root[13637]: /usr/local/sbin/pcscd --debug --foreground This sits hanging on /dev/usb/1.1.0: # lsof -p 13639 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME pcscd 13639 root cwd VDIR 0,113 10242 / pcscd 13639 root rtd VDIR 0,113 10242 / pcscd 13639 root txt VREG 0,113 121992 15279826 /usr/local/sbin/pcscd pcscd 13639 root txt VREG 0,113 151560 29294355 /libexec/ld-elf.so.1 pcscd 13639 root txt VREG 0,11398016 29294906 /usr/lib/libusb.so.3 pcscd 13639 root txt VREG 0,11327640 29294864 /usr/lib/librt.so.1 pcscd 13639 root txt VREG 0,113 135712 29293769 /lib/libthr.so.3 pcscd 13639 root txt VREG 0,113 2063072 29294412 /lib/libc.so.7 pcscd 13639 root0r VCHR 0,43 0t0 43 /dev/null pcscd 13639 root1u VCHR 0,43 0t0 43 /dev/null pcscd 13639 root2u VCHR 0,43 0t0 43 /dev/null pcscd 13639 root3u unix 0xf800609ff6d0 0t0 ->0xf800163fa368 pcscd 13639 root4u PIPE 0xf8004f13c2f816384 ->0xf8004f13c460 pcscd 13639 root5u PIPE 0xf8004f13c4600 ->0xf8004f13c2f8 pcscd 13639 root6u unix 0xf80072b03a38 0t0 /var/run/pcscd/pcscd.comm pcscd 13639 root7u PIPE 0xf8004e5422f816384 ->0xf8004e542460 pcscd 13639 root8u PIPE 0xf8004e5424600 ->0xf8004e5422f8 pcscd 13639 root9u PIPE 0xf8004e50900016384 ->0xf8004e509168 pcscd 13639 root 10u PIPE 0xf8004e5091680 ->0xf8004e509000 pcscd 13639 root 11u VCHR 0,52 0t0 52 /dev/usb/1.1.0 pcscd 13639 root 12u VCHR 0,52 0t0 52 /dev/usb/1.1.0 (note: the older working proc had open /dev/usb/0.4.0) > What does "procstat -ak" output. Does it hang on any "usb" functions? # ps ax | grep pcs 13639 - I 0:00,01 /usr/local/sbin/pcscd --debug --foreground 13967 4 S+ 0:00,01 grep pcs # procstat -k 13639 PIDTID COMMTDNAME KSTACK 13639 100287 pcscd - mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep pipe_read dofileread kern_readv sys_read amd64_syscall fast_syscall_common 13639 100821 pcscd - mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep pipe_read dofileread kern_readv sys_read amd64_syscall fast_syscall_common 13639 100822 pcscd - mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sx_xlock_hard _sx_xlock usbd_enum_lock_sig usb_ref_device usb_open devfs_open VOP_OPEN_APV vn_open_vnode vn_open_cred kern_openat amd64_syscall fast_syscall_common matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars, Druschba instead of Nazis, to live instead of to survive. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r342378: usbconfig takes 3-5 minutes to read the bus
On 1/2/19 11:48 AM, Matthias Apitz wrote: El día miércoles, enero 02, 2019 a las 09:44:06a. m. +0100, Hans Petter Selasky escribió: On 1/1/19 2:51 PM, Matthias Apitz wrote: Now with r342378, it works only after boot but not after withdraw/re-insert anymore. To separate the problem from GnuPG and it's software stack, I have here some small tests with usbconfig(8). First usbconfig reads fine the bus, but then it takes 3-5 minutes to get any results, see below. Did you update the user-space libusb aswell? I did a complete 'make installworld' and they look updated: $ ls -l /usr/lib/libusb* -r--r--r-- 1 root wheel 573256 31 dic. 12:19 /usr/lib/libusb_p.a -r--r--r-- 1 root wheel 541506 31 dic. 12:19 /usr/lib/libusb.a lrwxr-xr-x 1 root wheel 11 31 dic. 12:33 /usr/lib/libusb.so -> libusb.so.3 -r--r--r-- 1 root wheel 98016 31 dic. 12:33 /usr/lib/libusb.so.3 -r--r--r-- 1 root wheel 73910 31 dic. 12:19 /usr/lib/libusbhid_p.a -r--r--r-- 1 root wheel 71390 31 dic. 12:19 /usr/lib/libusbhid.a lrwxr-xr-x 1 root wheel 14 31 dic. 12:33 /usr/lib/libusbhid.so -> libusbhid.so.4 -r--r--r-- 1 root wheel 23720 31 dic. 12:33 /usr/lib/libusbhid.so.4 At boot time a process is launched by devd(8) which reads the OpenPGP card and this works fine and has the device open: $ ps ax | grep pcs 501 v0- S 0:00,22 /usr/local/sbin/pcscd --debug --foreground # lsof -p 501 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME pcscd 501 root cwd VDIR 0,113 10242 / pcscd 501 root rtd VDIR 0,113 10242 / pcscd 501 root txt VREG 0,113 121992 15279826 /usr/local/sbin/pcscd pcscd 501 root txt VREG 0,113 151560 29294355 /libexec/ld-elf.so.1 pcscd 501 root txt VREG 0,11398016 29294906 /usr/lib/libusb.so.3 pcscd 501 root txt VREG 0,11327640 29294864 /usr/lib/librt.so.1 pcscd 501 root txt VREG 0,113 135712 29293769 /lib/libthr.so.3 pcscd 501 root txt VREG 0,113 2063072 29294412 /lib/libc.so.7 pcscd 501 root txt VREG 0,113 135192 1905 /usr/local/lib/pcsc/drivers/ifd-ccid.bundle/Contents/FreeBSD/libccid.so pcscd 501 root0r VCHR 0,43 0t0 43 /dev/null pcscd 501 root1u VREG 0,113 3568882411580 / (/dev/ada0p2) pcscd 501 root2u VREG 0,113 3568882411580 / (/dev/ada0p2) pcscd 501 root3u VREG 0,113 3568882411580 / (/dev/ada0p2) pcscd 501 root4u PIPE 0xf800162fd8e816384 ->0xf800162fda50 pcscd 501 root5u PIPE 0xf800162fda500 ->0xf800162fd8e8 pcscd 501 root6u unix 0xf800164036d0 0t0 /var/run/pcscd/pcscd.comm pcscd 501 root7u unix 0xf80016feaa38 0t0 /var/run/pcscd/pcscd.comm pcscd 501 root9u PIPE 0xf800162fd2f816384 ->0xf800162fd460, cnt=2, in=2 pcscd 501 root 10u PIPE 0xf800162fd4600 ->0xf800162fd2f8 pcscd 501 root 11u PIPE 0xf800162f28e816384 ->0xf800162f2a50 pcscd 501 root 12u PIPE 0xf800162f2a500 ->0xf800162f28e8 pcscd 501 root 13u VCHR 0,87 0t0 87 /dev/usb/0.4.0 pcscd 501 root 14u VCHR 0,87 0t0 87 /dev/usb/0.4.0 $ gpg2 --card-status Reader ...: Identiv uTrust 3512 SAM slot Token (55511725600891) 00 00 Application ID ...: D2760001240102010005532B Version ..: 2.1 Manufacturer .: ZeitControl Serial number : 532B Name of cardholder: Matthias Apitz ... When I withdraw the OpenPGP card devd(8) hooks kill that proc and restarts a new one on card insert. But this new proc hangs. The same happens when I disable the devd(8) start of this proc and start the same proc from a shell (for debugging). This hangs too. Looks like something makes the USB stack broken after the point where devd(8) can launch fine the first proc of pcscd. Any error messages in dmesg? Hi, Nothing. Only on boot it sees the card: And you are using the latest version of pcsd ? Jan 2 11:25:39 c720-r342378 kernel: ugen0.1: <0x8086 XHCI root HUB> at usbus0 Jan 2 11:25:39 c720-r342378 kernel: ugen1.1: at usbus1 Jan 2 11:25:39 c720-r342378 kernel: ugen1.2: at usbus1 Jan 2 11:25:39 c720-r342378 kernel: ugen0.2: at usbus0 Jan 2 11:25:39 c720-r342378 kernel: ugen0.3: at usbus0 Jan 2 11:25:39 c720-r342378 kernel: ugen0.4: at usbus0 There has been some changes in libusb recently . What does "procstat -ak" output. Does it hang on any "usb" functions? --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to
Re: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"
On 2/01/2019 4:56 pm, Matthew Macy wrote: I just updated world/kernel/ports to today's HEAD and packages and pkg "upgraded" chrome to be broken in this way. This isn't an isolated issue. On Tue, Jan 1, 2019 at 9:55 PM Matthew Macy wrote: I just updated world/kernel/ports to today's HEAD and packages and pkg "upgraded" chrome to be broken in this way. This isn't an isolated issue. On Tue, Jan 1, 2019 at 9:53 PM Matthias Apitz wrote: El día viernes, diciembre 28, 2018 a las 12:55:32p. m. -0800, Cy Schubert escribió: In message , Antoine Brodin writes: On Fri, Dec 28, 2018 at 8:39 PM Graham Perrin wrote: On Fri, 28 Dec 2018 at 16:31, Emiel Kollof wrot e: Confirmed with Chromium on my CURRENT box: … Thanks folks. Should I report it as a bug with devel/glib20? Hi, I think it's a regression in the toolchain (the problem doesn't occur on 11.2 or 12.0), so it should be reported to freebsd-toolchain@ No issue here however I rebuilt glib on Dec 21. I see the same with www/chromium on r342378 and ports, both from Dec 23. matthias -- The issue is being tracked in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103 Per my last comment (comment 36), any base change(s) required to resolve the issue, once identified, should be tracked separately as a blocking issue. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"
I just updated world/kernel/ports to today's HEAD and packages and pkg "upgraded" chrome to be broken in this way. This isn't an isolated issue. On Tue, Jan 1, 2019 at 9:53 PM Matthias Apitz wrote: > > El día viernes, diciembre 28, 2018 a las 12:55:32p. m. -0800, Cy Schubert > escribió: > > > In message > il.com> > > , Antoine Brodin writes: > > > On Fri, Dec 28, 2018 at 8:39 PM Graham Perrin > > > wrote: > > > > > > > > On Fri, 28 Dec 2018 at 16:31, Emiel Kollof > > > > wrot > > > e: > > > > > > > > > Confirmed with Chromium on my CURRENT box: > > > > > > > > … > > > > > > > > Thanks folks. Should I report it as a bug with devel/glib20? > > > > > > Hi, > > > > > > I think it's a regression in the toolchain (the problem doesn't occur > > > on 11.2 or 12.0), so it should be reported to freebsd-toolchain@ > > > > No issue here however I rebuilt glib on Dec 21. > > I see the same with www/chromium on r342378 and ports, both from Dec 23. > > matthias > > -- > Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 > Public GnuPG key: http://www.unixarea.de/key.pub > October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars, > Druschba > instead of Nazis, to live instead of to survive. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r342378: usbconfig takes 3-5 minutes to read the bus
El día miércoles, enero 02, 2019 a las 09:44:06a. m. +0100, Hans Petter Selasky escribió: > On 1/1/19 2:51 PM, Matthias Apitz wrote: > > Now with r342378, it works only after boot but not after withdraw/re-insert > > anymore. To separate the problem from GnuPG and it's software stack, I have > > here some > > small tests with usbconfig(8). First usbconfig reads fine the bus, but then > > it takes 3-5 minutes to get any results, see below. > > Did you update the user-space libusb aswell? I did a complete 'make installworld' and they look updated: $ ls -l /usr/lib/libusb* -r--r--r-- 1 root wheel 573256 31 dic. 12:19 /usr/lib/libusb_p.a -r--r--r-- 1 root wheel 541506 31 dic. 12:19 /usr/lib/libusb.a lrwxr-xr-x 1 root wheel 11 31 dic. 12:33 /usr/lib/libusb.so -> libusb.so.3 -r--r--r-- 1 root wheel 98016 31 dic. 12:33 /usr/lib/libusb.so.3 -r--r--r-- 1 root wheel 73910 31 dic. 12:19 /usr/lib/libusbhid_p.a -r--r--r-- 1 root wheel 71390 31 dic. 12:19 /usr/lib/libusbhid.a lrwxr-xr-x 1 root wheel 14 31 dic. 12:33 /usr/lib/libusbhid.so -> libusbhid.so.4 -r--r--r-- 1 root wheel 23720 31 dic. 12:33 /usr/lib/libusbhid.so.4 At boot time a process is launched by devd(8) which reads the OpenPGP card and this works fine and has the device open: $ ps ax | grep pcs 501 v0- S 0:00,22 /usr/local/sbin/pcscd --debug --foreground # lsof -p 501 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME pcscd 501 root cwd VDIR 0,113 10242 / pcscd 501 root rtd VDIR 0,113 10242 / pcscd 501 root txt VREG 0,113 121992 15279826 /usr/local/sbin/pcscd pcscd 501 root txt VREG 0,113 151560 29294355 /libexec/ld-elf.so.1 pcscd 501 root txt VREG 0,11398016 29294906 /usr/lib/libusb.so.3 pcscd 501 root txt VREG 0,11327640 29294864 /usr/lib/librt.so.1 pcscd 501 root txt VREG 0,113 135712 29293769 /lib/libthr.so.3 pcscd 501 root txt VREG 0,113 2063072 29294412 /lib/libc.so.7 pcscd 501 root txt VREG 0,113 135192 1905 /usr/local/lib/pcsc/drivers/ifd-ccid.bundle/Contents/FreeBSD/libccid.so pcscd 501 root0r VCHR 0,43 0t0 43 /dev/null pcscd 501 root1u VREG 0,113 3568882411580 / (/dev/ada0p2) pcscd 501 root2u VREG 0,113 3568882411580 / (/dev/ada0p2) pcscd 501 root3u VREG 0,113 3568882411580 / (/dev/ada0p2) pcscd 501 root4u PIPE 0xf800162fd8e816384 ->0xf800162fda50 pcscd 501 root5u PIPE 0xf800162fda500 ->0xf800162fd8e8 pcscd 501 root6u unix 0xf800164036d0 0t0 /var/run/pcscd/pcscd.comm pcscd 501 root7u unix 0xf80016feaa38 0t0 /var/run/pcscd/pcscd.comm pcscd 501 root9u PIPE 0xf800162fd2f816384 ->0xf800162fd460, cnt=2, in=2 pcscd 501 root 10u PIPE 0xf800162fd4600 ->0xf800162fd2f8 pcscd 501 root 11u PIPE 0xf800162f28e816384 ->0xf800162f2a50 pcscd 501 root 12u PIPE 0xf800162f2a500 ->0xf800162f28e8 pcscd 501 root 13u VCHR 0,87 0t0 87 /dev/usb/0.4.0 pcscd 501 root 14u VCHR 0,87 0t0 87 /dev/usb/0.4.0 $ gpg2 --card-status Reader ...: Identiv uTrust 3512 SAM slot Token (55511725600891) 00 00 Application ID ...: D2760001240102010005532B Version ..: 2.1 Manufacturer .: ZeitControl Serial number : 532B Name of cardholder: Matthias Apitz ... When I withdraw the OpenPGP card devd(8) hooks kill that proc and restarts a new one on card insert. But this new proc hangs. The same happens when I disable the devd(8) start of this proc and start the same proc from a shell (for debugging). This hangs too. Looks like something makes the USB stack broken after the point where devd(8) can launch fine the first proc of pcscd. > Any error messages in dmesg? Nothing. Only on boot it sees the card: Jan 2 11:25:39 c720-r342378 kernel: ugen0.1: <0x8086 XHCI root HUB> at usbus0 Jan 2 11:25:39 c720-r342378 kernel: ugen1.1: at usbus1 Jan 2 11:25:39 c720-r342378 kernel: ugen1.2: at usbus1 Jan 2 11:25:39 c720-r342378 kernel: ugen0.2: at usbus0 Jan 2 11:25:39 c720-r342378 kernel: ugen0.3: at usbus0 Jan 2 11:25:39 c720-r342378 kernel: ugen0.4: at usbus0 matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars, Druschba instead of Nazis, to live instead of to survive. signature.asc Description: PGP signature
Re: r342378: usbconfig takes 3-5 minutes to read the bus
On 1/1/19 2:51 PM, Matthias Apitz wrote: Now with r342378, it works only after boot but not after withdraw/re-insert anymore. To separate the problem from GnuPG and it's software stack, I have here some small tests with usbconfig(8). First usbconfig reads fine the bus, but then it takes 3-5 minutes to get any results, see below. Did you update the user-space libusb aswell? Any error messages in dmesg? --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
