Re: Strange USB loop
On Tue, Aug 25, 2020 at 12:46:01AM +0200, Hans Petter Selasky wrote: > On 2020-08-24 18:37, bob prohaska wrote: > > After updating to > > FreeBSD 13.0-CURRENT (GENERIC) #5 r364475: Mon Aug 24 06:47:29 PDT 2020 > > on a Pi3 it was necessary to disconnect the mouse, keyboard and usb-serial > > You are after: > > https://svnweb.freebsd.org/changeset/base/364433 > > You may want to try a kernel before: > > r364379 A kernel for FreeBSD 13.0-CURRENT (GENERIC) #6 r364378: Tue Aug 25 00:46:27 PDT 2020 compiled and installed without incident, but the problem persists. This time I plugged the keyboard into the hub and got a stream of uhub_reattach_port: giving up port reset - device vanished which didn't stop when the keyboard was removed. If the keyboard is moved to the Pi's internal USB connectors the keyboard is recognized and works, but the once-per-second "...device vanished" messages continue. Attempts to repeat this behavior were frustrating. After a few iterations the error message was triggered by plugging in an FTDI usb-serial adapter, but the messages stopped when it was unplugged. The hub is Bus /dev/usb Device /dev/ugen1.4: ID 05e3:0610 Genesys Logic, Inc. 4-port hub The disk adapter is Bus /dev/usb Device /dev/ugen1.5: ID 152d:1561 JMicron Technology Corp. / JMicron USA Technology Corp. JMS561U two ports SATA 6Gb/s bridge Are either of these known troublmakers? Thanks for reading! bob prohaska ___ 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"
OpenZFS support merged
r364746 merged OpenZFS support in to HEAD. The change should be transparent unless you want to use new features. I caution against 'zpool upgrade' for the next few weeks. https://svnweb.freebsd.org/base?view=revision&revision=364746 If you encounter problems please report them to me, Ryan Moeller, and -current. ___ 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: Strange USB loop
On 2020-08-24 18:37, bob prohaska wrote: After updating to FreeBSD 13.0-CURRENT (GENERIC) #5 r364475: Mon Aug 24 06:47:29 PDT 2020 on a Pi3 it was necessary to disconnect the mouse, keyboard and usb-serial You are after: https://svnweb.freebsd.org/changeset/base/364433 You may want to try a kernel before: r364379 --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"
deprecation of drm-legacy-kmod
[ cross posted across several mailing lists, please respect reply-to ] Hi! It is time to deprecate drm-legacy-kmod, since it is taking too much time to maintain and are holding off changes in other areas. drm-legacy-kmod was created to aid in the transition to the LinuxKPI based graphics drivers, at a time when the new drivers only supported amd64. Since then, the new drivers have been updated to support more architectures and more GPUs, and the burden of maintaining drm-legacy-kmod has increased. It became apparent with the update of xorg-server to 1.20 that drm-legacy-kmod is too old to work with certain aspects of the graphics stack, and it is also holding back changes in areas of the FreeBSD base system such as VM scaling and optimization. The VM locking protocol needs to be changed, and to port those changes to these drivers would require extensive reworking of its use of the FreeBSD VM subsystem. This means it is time for it to go. The driver will remain for a transition period. For FreeBSD 13-CURRENT, this will be fairly short, as there are changes to FreeBSD base that breaks the drivers. For FreeBSD 12, the driver will remain a bit longer, to ease in transition. On FreeBSD 12, there is also the option of using the graphics drivers in base, although those are supported on a best-effort basis only. Regards -- Niclas Zeising FreeBSD Graphics Team ___ 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: again this ugly graphic driver sloopy mistake
"Vanbreukelingen Ltd." wrote: > No! > > No freeBSD on this laptop anymore, sorry. I'm deluded like hell from > this sessions; after 30 hours of compiling world I get a "disk full". > Trying my luck with openBSD here. Apologies for not sending you a bigger disk. > consider this as a divorcing paper. Don't worry, I'm sure it won't be contested. ___ 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: CFT: major update to if_ure
Ganbold Tsagaankhuu wrote this message on Wed, Aug 19, 2020 at 16:27 +0800: > On Tue, Jul 28, 2020 at 2:35 AM John-Mark Gurney wrote: > > > Ganbold Tsagaankhuu wrote this message on Mon, Jul 27, 2020 at 18:29 +0800: > > > On Mon, Jul 27, 2020 at 5:14 AM John-Mark Gurney > > wrote: > > > > > > > Ganbold Tsagaankhuu wrote this message on Sun, Jul 26, 2020 at 11:05 > > +0800: > > > > > On Sun, Jul 26, 2020 at 7:13 AM John-Mark Gurney > > > > wrote: > > > > > > > > > > > Hello, > > > > > > > > > > > > I'd like people who have ure (RealTek) based USB devices to test > > > > > > review D25809[0]. > > > > > > > > > > > > This update adds support for: > > > > > > - HW VLAN tagging > > > > > > - HW checksum offload for IPv4 and IPv6 > > > > > > - tx and rx aggreegation (for full gige speeds) > > > > > > - multiple transactions > > > > > > > > > > > > In my testing, I am able to get 900-950Mbps depending upon > > > > > > TCP or UDP, which is a significant improvement over the previous > > > > > > 91Mbps (~8kint/sec*1500bytes/packet*1packet/int). > > > > > > > > > > Does performance improve for if_ure device on USB2? > > > > > I will try to test it in a couple of days on NanoPI R1 and R1S > > boards. > > > > > > > > Yes, it should. > > > > > > > > I never tested the before driver on USB2, but I'm now able to get > > > > 211Mbps TX and 190Mbps RX TCP, and 227Mbps TX and 225Mbps RX UDP. > > > > > > > > I believe it is likely that the same 91Mbps speed limit applied to > > > > USB2 as well. > > > > > > Couldn't find your iperf test scripts and I tested only tcp: > > > > My test script isn't performance, just features, and I'm thinking about > > how/where to publish it... > > > > You can also test UDP using -u w/ iperf3 and adjust the bandwidth w/ > > -b 300m (or other Mbps)... > > > > > root@nanopi-r1s-h5:~ # iperf3 -c 192.168.111.1 > > > Connecting to host 192.168.111.1, port 5201 > > > [ 5] local 192.168.111.10 port 28569 connected to 192.168.111.1 port > > 5201 > > > [ ID] Interval Transfer Bitrate Retr Cwnd > > > [ 5] 0.00-1.00 sec 27.4 MBytes 230 Mbits/sec0 95.4 KBytes > > > [ 5] 1.00-2.00 sec 27.6 MBytes 232 Mbits/sec0 95.4 KBytes > > > [ 5] 2.00-3.00 sec 27.7 MBytes 232 Mbits/sec0 95.4 KBytes > > > [ 5] 3.00-4.00 sec 27.6 MBytes 232 Mbits/sec0 95.4 KBytes > > > [ 5] 4.00-5.00 sec 27.6 MBytes 232 Mbits/sec0 95.4 KBytes > > > [ 5] 5.00-6.00 sec 27.6 MBytes 232 Mbits/sec0 95.4 KBytes > > > [ 5] 6.00-7.00 sec 27.7 MBytes 232 Mbits/sec0 95.4 KBytes > > > [ 5] 7.00-8.00 sec 27.7 MBytes 232 Mbits/sec0 95.4 KBytes > > > [ 5] 8.00-9.00 sec 27.6 MBytes 232 Mbits/sec0 95.4 KBytes > > > [ 5] 9.00-10.00 sec 27.6 MBytes 232 Mbits/sec0 95.4 KBytes > > > - - - - - - - - - - - - - - - - - - - - - - - - - > > > [ ID] Interval Transfer Bitrate Retr > > > [ 5] 0.00-10.00 sec 276 MBytes 232 Mbits/sec0 > > sender > > > [ 5] 0.00-10.79 sec 276 MBytes 215 Mbits/sec > > > receiver > > > > > > iperf Done. > > > root@nanopi-r1s-h5:~ # iperf3 -c 192.168.111.1 -R > > > Connecting to host 192.168.111.1, port 5201 > > > Reverse mode, remote host 192.168.111.1 is sending > > > [ 5] local 192.168.111.10 port 29384 connected to 192.168.111.1 port > > 5201 > > > [ ID] Interval Transfer Bitrate > > > [ 5] 0.00-1.00 sec 12.1 MBytes 102 Mbits/sec > > > [ 5] 1.00-2.00 sec 12.1 MBytes 102 Mbits/sec > > > [ 5] 2.00-3.00 sec 12.1 MBytes 101 Mbits/sec > > > [ 5] 3.00-4.00 sec 12.1 MBytes 102 Mbits/sec > > > [ 5] 4.00-5.00 sec 12.1 MBytes 102 Mbits/sec > > > [ 5] 5.00-6.00 sec 12.1 MBytes 102 Mbits/sec > > > [ 5] 6.00-7.00 sec 12.1 MBytes 101 Mbits/sec > > > [ 5] 7.00-8.00 sec 12.1 MBytes 102 Mbits/sec > > > [ 5] 8.00-9.00 sec 12.1 MBytes 101 Mbits/sec > > > [ 5] 9.00-10.00 sec 12.1 MBytes 102 Mbits/sec > > > - - - - - - - - - - - - - - - - - - - - - - - - - > > > [ ID] Interval Transfer Bitrate Retr > > > [ 5] 0.00-11.25 sec 121 MBytes 90.3 Mbits/sec 2539 > > > sender > > > [ 5] 0.00-10.00 sec 121 MBytes 101 Mbits/sec > > > receiver > > > > > > iperf Done. > > > root@nanopi-r1s-h5:~ # sysctl -a | grep cpu.0.freq > > > dev.cpu.0.freq_levels: 1248/-1 1008/-1 816/-1 624/-1 480/-1 > > > dev.cpu.0.freq: 1248 > > > > Hmmm... The reverse seems slow, but I can't think of why it'd be that > > slow though. When I did my tests on the USB2 ports, both directions > > were about the same speed... > > > > Thanks for the test! Great to hear things are working... > > When can you commit it? Plan on committing it this week... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@
Re: Strange USB loop
On Mon, Aug 24, 2020 at 05:26:27PM +, Bjoern A. Zeeb wrote: > On 24 Aug 2020, at 16:37, bob prohaska wrote: > > > > > uhub_reattach_port: giving up port reset - device vanished > > uhub_reattach_port: giving up port reset - device vanished > > uhub_reattach_port: giving up port reset - device vanished > > uhub_reattach_port: giving up port reset - device vanished > > uhub_reattach_port: giving up port reset - device vanished > > > > I hit something like it last weekend and found this one: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666 > Hmm, rather discouraging. Same error message, different hardware. Considerable investigation without resolution. Over a year old. Thanks for writing 8=( bob prohaska ___ 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"
HEADS UP: coming changes to a devd event
Greetings I just pushed https://svnweb.freebsd.org/changeset/base/364725 into -current. In documenting all the messages that devd can receive from the kernel, I noticed an inconsistency I'd like to correct. We currently have both system=kernel and system=kern generated by the kernel. This makes no sense, imho. I've decided to transition the 'kern' one to 'kernel' because (a) I think it's less used and (b) I like it less than 'kernel' for this. The one message is generated by newus on resume. It's redundant since we also generate one for ACPI. We don't really document either (until recently), but use the ACPI one in the default devd.conf script. I'm not changing that at all since it doesn't need adjustment. This is a heads up that the other one is changing from system=kern to system=kernel to be more consistent with the other messages generated by the kernel. I've updated the documentation and added an UPDATING entry. For a while, we'll generate both system=kern and system=kernel events for this. Sometime after 13 is branched, I'll remove the system=kern one. If all goes well, I'll MFC the change to generate both to stable/12 in a few days, along with the improved docs to devd.conf (which I may do prior to that), but won't MFC the removal. I don't think this will cause anybody any grief, and the lead times on making changes will be at least 6 months for people following -current, and likely on the scale of years for people following stable branches. Sadly, it's not simple to add a deprecation notice for current users. Just thought I'd give a heads up in case this will cause people grief. 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"
again this ugly graphic driver sloopy mistake
No! No freeBSD on this laptop anymore, sorry. I'm deluded like hell from this sessions; after 30 hours of compiling world I get a "disk full". Trying my luck with openBSD here. Here's what I owe you: pciconf -lv vgapci0@pci0:0:2:0: class=0x03 rev=0x09 hdr=0x00 vendor=0x8086 device=0x0106 subvendor=0x1028 subdevice=0x0510 vendor = 'Intel Corporation' device = '2nd Generation Core Processor Family Integrated Graphics Controller' class = display subclass = VGA dmesg: ---<>--- Copyright (c) 1992-2020 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 13.0-CURRENT #0 r364492: Sat Aug 22 23:30:16 CEST 2020 root@current:/usr/obj/usr/src/i386.i386/sys/MIRANDA i386 FreeBSD clang version 10.0.1 (g...@github.com:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611aa2) WARNING: WITNESS option enabled, expect reduced performance. subsystem 100 vm_mem_init(0)... done. machdep_init_trampoline(0)... done. vm_page_init(0)... done. subsystem 110 pcpu_zones_startup(0)... done. counter_u64_sysinit(&swap_free_completed)... done. counter_u64_sysinit(&poll)... done. uma_startup_pcpu(0)... done. counter_u64_sysinit(&poll_scan)... done. counter_u64_sysinit(&object_collapses)... done. counter_u64_sysinit(&object_bypasses)... done. counter_u64_sysinit(&object_collapse_waits)... done. counter_u64_sysinit(&pqstate_commit_retries)... done. counter_u64_sysinit(&queue_ops)... done. counter_u64_sysinit(&queue_nops)... done. counter_u64_sysinit(&poll_fail)... done. counter_u64_sysinit(&vm_reserv_broken)... done. counter_u64_sysinit(&vm_reserv_freed)... done. counter_u64_sysinit(&vm_reserv_reclaimed)... done. counter_u64_sysinit(&advance)... done. counter_u64_sysinit(&numcachehv)... done. counter_u64_sysinit(&numdrops)... done. counter_u64_sysinit(&dothits)... done. counter_u64_sysinit(&dotdothits)... done. counter_u64_sysinit(&nummiss)... done. counter_u64_sysinit(&nummisszap)... done. counter_u64_sysinit(&numposzaps)... done. counter_u64_sysinit(&numposhits)... done. counter_u64_sysinit(&numnegzaps)... done. counter_u64_sysinit(&numneghits)... done. counter_u64_sysinit(&numfullpathcalls)... done. counter_u64_sysinit(&numfullpathfail1)... done. counter_u64_sysinit(&numfullpathfail2)... done. counter_u64_sysinit(&numfullpathfail4)... done. counter_u64_sysinit(&numfullpathfound)... done. counter_u64_sysinit(&zap_and_exit_bucket_relock_success)... done. counter_u64_sysinit(&numneg_evicted)... done. counter_u64_sysinit(&shrinking_skipped)... done. counter_u64_sysinit(&advance_wait)... done. cryptostats_init(0)... done. counter_u64_sysinit(&swap_free_deferred)... done. subsystem 180 sysctl_register_all(0)... done. vmcounter_startup(0)... done. mallocinit(0)... done. malloc_init(&M_ATADA)... done. malloc_init(&M_CAMDEVQ)... done. malloc_init(&M_SCSIDA)... done. malloc_init(&M_AMR)... done. malloc_init(&M_ATA)... done. malloc_init(&M_ATADMA)... done. malloc_init(&M_ATAPCI)... done. malloc_init(&M_VTBUF)... done. malloc_init(&M_VT)... done. malloc_init(&M_VTFONT)... done. malloc_init(&M_SYSMOUSE)... done. malloc_init(&M_ATHDEV)... done. malloc_init(&M_BALLOON)... done. malloc_init(&M_XENBLOCKFRONT)... done. malloc_init(&M_XENBLOCKBACK)... done. malloc_init(&M_XENNETBACK)... done. malloc_init(&M_ATH_HAL)... done. malloc_init(&CISS_MALLOC_CLASS)... done. malloc_init(&M_XENSTORE)... done. malloc_init(&M_EVTCHN)... done. malloc_init(&M_PRIVCMD)... done. malloc_init(&M_GNTDEV)... done. malloc_init(&M_DEVFS2)... done. malloc_init(&M_DEVFS3)... done. malloc_init(&M_CDEVP)... done. malloc_init(&M_DEVFS4)... done. malloc_init(&M_DEVFSRULE)... done. malloc_init(&M_DEVFS)... done. malloc_init(&M_CDEVPDATA)... done. malloc_init(&M_MSDOSFSNODE)... done. malloc_init(&M_MSDOSFSMNT)... done. malloc_init(&M_MSDOSFSFAT)... done. malloc_init(&M_NEWNFSRVCACHE)... done. malloc_init(&M_NEWNFSDCLIENT)... done. malloc_init(&M_NEWNFSDSTATE)... done. malloc_init(&M_NEWNFSDLOCK)... done. malloc_init(&M_NEWNFSDLOCKFILE)... done. malloc_init(&M_NEWNFSSTRING)... done. malloc_init(&M_NEWNFSUSERGROUP)... done. malloc_init(&M_NEWNFSDREQ)... done. malloc_init(&M_NEWNFSFH)... done. malloc_init(&M_NEWNFSCLOWNER)... done. malloc_init(&M_NEWNFSCLOPEN)... done. malloc_init(&M_NEWNFSCLDELEG)... done. malloc_init(&M_NEWNFSCLCLIENT)... done. malloc_init(&M_NEWNFSCLLOCKOWNER)... done. malloc_init(&M_NEWNFSCLLOCK)... done. malloc_init(&M_NEWNFSV4NODE)... done. malloc_init(&M_NEWNFSDIRECTIO)... done. malloc_init(&M_NEWNFSDIROFF)... done. malloc_init(&M_NEWNFSDROLLBACK)..
Re: Length of ZFS volume names
> On 24. Aug 2020, at 17:20, Shawn Webb wrote: > > Hey FreeBSD peeps, > > The zfs(8) manpage says that the maximum length of a dataset name is > MAXNAMELEN (256 bytes). I've created a ZFS volume that has a dataset > name length of 62. I don't see the ZFS volume in /dev/zvol and I > noticed this sanitized error in dmesg: > > Aug 24 11:07:24 bh-build-01 kernel: [2395] ZFS WARNING: Unable to create ZVOL > tank/bhyve/productname/dev/users/username/username-shortened_productname-dev-01/disk-01 > (error=63). > > So I'm left wondering, does devfs have a smaller limit than ZFS for > node paths? > Might be related: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238112 > Thanks, > > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD > > GPG Key ID: 0xFF2E67A277F8E1FA > GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 > https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc ___ 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: Strange USB loop
On 24 Aug 2020, at 16:37, bob prohaska wrote: > After updating to > FreeBSD 13.0-CURRENT (GENERIC) #5 r364475: Mon Aug 24 06:47:29 PDT 2020 > on a Pi3 it was necessary to disconnect the mouse, keyboard and usb-serial > adapter to allow the machine to mount root from USB via a hub. > > Once the machine came back up with root mounted from USB, I tried plugging > the serial adapter, mouse and keyboard back in via the hub. > > The FTDI serial adapater was recognized without trouble, but when the > elderly Dell mouse was connected, a stream of > > uhub_reattach_port: giving up port reset - device vanished > uhub_reattach_port: giving up port reset - device vanished > uhub_reattach_port: giving up port reset - device vanished > uhub_reattach_port: giving up port reset - device vanished > uhub_reattach_port: giving up port reset - device vanished > > began to scroll on both the monitor and console. Unplugging > the mouse made no difference. Plugging the mouse directly > into the Pi's USB port allowed recognition and function, > but the stream of errors persisted. Network access seems > normal. > > It looks almost as if there's some sort of infinite loop > running in the USB software. The need to disconnect mouse > and keyboard to permit mountroot to work isn't new, but > the "giving up port reset" _is_ new at least to me. > > Are there any experiments which might narrow down what's wrong? I hit something like it last weekend and found this one: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666 /bz ___ 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"
Strange USB loop
After updating to FreeBSD 13.0-CURRENT (GENERIC) #5 r364475: Mon Aug 24 06:47:29 PDT 2020 on a Pi3 it was necessary to disconnect the mouse, keyboard and usb-serial adapter to allow the machine to mount root from USB via a hub. Once the machine came back up with root mounted from USB, I tried plugging the serial adapter, mouse and keyboard back in via the hub. The FTDI serial adapater was recognized without trouble, but when the elderly Dell mouse was connected, a stream of uhub_reattach_port: giving up port reset - device vanished uhub_reattach_port: giving up port reset - device vanished uhub_reattach_port: giving up port reset - device vanished uhub_reattach_port: giving up port reset - device vanished uhub_reattach_port: giving up port reset - device vanished began to scroll on both the monitor and console. Unplugging the mouse made no difference. Plugging the mouse directly into the Pi's USB port allowed recognition and function, but the stream of errors persisted. Network access seems normal. It looks almost as if there's some sort of infinite loop running in the USB software. The need to disconnect mouse and keyboard to permit mountroot to work isn't new, but the "giving up port reset" _is_ new at least to me. Are there any experiments which might narrow down what's wrong? Thanks for reading, bob prohaska ___ 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"
Length of ZFS volume names
Hey FreeBSD peeps, The zfs(8) manpage says that the maximum length of a dataset name is MAXNAMELEN (256 bytes). I've created a ZFS volume that has a dataset name length of 62. I don't see the ZFS volume in /dev/zvol and I noticed this sanitized error in dmesg: Aug 24 11:07:24 bh-build-01 kernel: [2395] ZFS WARNING: Unable to create ZVOL tank/bhyve/productname/dev/users/username/username-shortened_productname-dev-01/disk-01 (error=63). So I'm left wondering, does devfs have a smaller limit than ZFS for node paths? Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: Kernel crash during video transcoding
I re-installed the user land in my jail after re-compiling the sources and from that point I don't have the issue anymore. Seems like some libraries were not properly updated or something like that (maybe libva). In any case if it happens again I'll try to generate a test video with ffmpeg and try to transcode it with similar parameters. That'd be the easiest way to reproduce the issue. Thanks for your insights. Le ven. 21 août 2020 à 22:23, Hans Petter Selasky a écrit : > On 2020-08-16 22:23, Alexandre Levy wrote: > > Any suggestions ? > > Are there any simple steps to reproduce this? > > --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"
