Re: CFT for vendor openzfs - week 5 reminder + memdisk images
> # kldload zfs > can't handle raw ops yet!!! > can't handle raw ops yet!!! > can't handle raw ops yet!!! > ZFS filesystem version: 5 > ZFS storage pool version: features support 5000 > can't handle raw ops yet!!! I'm working on it - Ryan reminded me of it today. It will probably get fixed before the merge. KSTAT_TYPE_RAW isn't supported in legacy ZFS, so strictly speaking it's not a regression (apart from the annoying reminder on debug kernels). -M ___ 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 for vendor openzfs - week 5 reminder + memdisk images
Op 04-08-2020 om 02:24 schreef Matthew Macy: On Wednesday, July 8th I issued the initial call for testing for the update to HEAD to vendored openzfs. We'd like to give users roughly a month to test before merging. The tentative merge date is August 17th. Again, I hope it's not terribly controversial to point out that it really rests with users of non amd64 platforms to test to avoid any unpleasant surprises the next time they update their trees following the merge. amd64, i386, and aarch64 memdisk images can be found at: https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/ If you're using a platform not listed above and would be inclined to test if you had an image to work with, let us know. Alternatively, you can still build following the instructions below. The review for merging in to base can be found at: https://reviews.freebsd.org/D25872 == NB: Do NOT zpool upgrade unless you are willing to live without the ability to ever rollback to the legacy zfs kmod. Checkout updated HEAD: % git clone https://github.com/mattmacy/networking.git -b projects/openzfs_vendor freebsd Checkout updated openzfs in to sys/contrib: % git clone https://github.com/zfsonfreebsd/ZoF.git -b projects/openzfs_vendor freebsd/sys/contrib/openzfs Build world and kernel with whatever your usual configuration is. Where possible the openzfs kmod is backward compatible with the cmd utils in HEAD so common operations work with existing tools and the new kmod. In the projects/openzfs_vendor branch of ZoF ozfs libraries are backward compatible with the zfs kmod in HEAD. Although ideally one would test this in a separate boot environment, the interoperability should allow one to rollback without too much difficulty. NB: The patch updates /etc/rc.d/zfs - so if you skip mergemaster pools other than the root pool will not be imported at boot. Thanks in advance for your time. -M ___ freebsd...@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe, send any mail to "freebsd-fs-unsubscr...@freebsd.org" I just downloaded the freebsd-openzfs-amd64-2020081100-memstick.img image and installed it as a fresh install. (ZFS install) Then i imported a pool that is a mirrored zfs pool of 6 WD drives created with FreeBSD 12.1 without any problem. The only thing i see when the ZFS module is loaded is the message can't handle raw ops yet!!! # kldload zfs can't handle raw ops yet!!! can't handle raw ops yet!!! can't handle raw ops yet!!! ZFS filesystem version: 5 ZFS storage pool version: features support 5000 can't handle raw ops yet!!! regards Johan ___ 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: kldref: too many segments on kernel build
On Wed, 19 Aug 2020 at 00:19, Dustin Marquess wrote: > > On Tue, Aug 18, 2020 at 3:19 PM Michael Butler > wrote: > > > > Any thoughts as to why this is happening when I build a (custom) kernel? > > > > kldxref: /boot/kernel/kernel: too many segments > > I'm seeing this too. I haven't tried actually booting the kernel > because of this. This is fallout from Clang 11. The kernel should boot fine despite the warnings, and this should be cleaned up in the near future (by increasing the number of segments supported by kldxref, by changing the kernel linker script, or a combination of both). ___ 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
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? thanks, Ganbold > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > ___ 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: funny thing with the drm0
On Wed, Aug 19, 2020 at 3:22 AM Lizbeth Mutterhunt, Ph.D < lizbethmutterh...@gmail.com> wrote: > After having had some near-death-experiences in Greece I'm back to my > screens. As horizon arises, BSD gets up --- and if it is 3 a.m.! :-) > > > But this is the experience with my Dell Vostro on 13 current: > > > After finally recompiling the kernel with the drm-module inside and > the trick of injecting the > This is not the way to do it. Modern hardware require drm-kmod from ports, or if you want the latest drm-devel-kmod. Then add /boot/modules/drm.ko and /boot/modules/i915kms.ko to kld_list in /etc/rc.conf > > device IWNFW > Again, this is not needed, firmware is autoloaded on module load. Just add if_iwn to kld_list in /etc/rc.conf > > I get a *nice* message a bootup: > > Aug 19 02:51:10 current kernel: info: [drm] Initialized drm 1.1.0 20060810 > Aug 19 02:51:10 current kernel: drmn0: on vgapci0 > Aug 19 02:51:10 current kernel: info: [drm] Memory usable by graphics > device = 2048M > Aug 19 02:51:10 current kernel: info: [drm] MTRR allocation failed. > Graphics performance may suffer. > Aug 19 02:51:10 current kernel: intel_iicbb0 on drmn0 > Aug 19 02:51:10 current kernel: iicbus0: on > iicbb_nostop0 addr 0x1 > Aug 19 02:51:10 current kernel: iic0: on iicbus0 > Aug 19 02:51:10 current kernel: iicbus1: on intel_gmbus0 > Aug 19 02:51:10 current kernel: iic1: on iicbus1 > Aug 19 02:51:10 current kernel: intel_iicbb1 on drmn0 > Aug 19 02:51:10 current kernel: iicbus2: on > iicbb_nostop1 addr 0x12 > Aug 19 02:51:10 current kernel: iic2: on iicbus2 > Aug 19 02:51:10 current kernel: iicbus3: on intel_gmbus1 > Aug 19 02:51:10 current kernel: iic3: on iicbus3 > Aug 19 02:51:10 current kernel: intel_iicbb2 on drmn0 > Aug 19 02:51:10 current kernel: iicbus4: on > iicbb_nostop2 addr 0x12 > Aug 19 02:51:10 current kernel: iic4: on iicbus4 > Aug 19 02:51:10 current kernel: iicbus5: on intel_gmbus2 > Aug 19 02:51:10 current kernel: iic5: on iicbus5 > Aug 19 02:51:10 current kernel: intel_iicbb3 on drmn0 > Aug 19 02:51:10 current kernel: iicbus6: on > iicbb_nostop3 addr 0x12 > Aug 19 02:51:10 current kernel: iic6: on iicbus6 > Aug 19 02:51:10 current kernel: iicbus7: on intel_gmbus3 > Aug 19 02:51:10 current kernel: iic7: on iicbus7 > Aug 19 02:51:10 current kernel: intel_iicbb4 on drmn0 > Aug 19 02:51:10 current kernel: iicbus8: on > iicbb_nostop4 addr 0x12 > Aug 19 02:51:10 current kernel: iic8: on iicbus8 > Aug 19 02:51:10 current kernel: iicbus9: on intel_gmbus4 > Aug 19 02:51:10 current kernel: iic9: on iicbus9 > Aug 19 02:51:10 current kernel: intel_iicbb5 on drmn0 > Aug 19 02:51:10 current kernel: iicbus10: on > iicbb_nostop5 addr 0x12 > > And furthermore: > > Aug 19 02:51:10 current kernel: info: [drm] MSI enabled 1 message(s) > Aug 19 02:51:10 current kernel: info: [drm] Supports vblank timestamp > caching Rev 1 (10.10.201> > Aug 19 02:51:10 current kernel: info: [drm] Driver supports precise > vblank timestamp query. > Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920 on drmn0 > Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920: detached > Aug 19 02:51:10 current kernel: drm_iic_dp_aux0 on drmn0 > Aug 19 02:51:10 current kernel: drmn0: taking over the fictitious > range 0xe000-0xf000 > Aug 19 02:51:10 current kernel: info: [drm] Connector LVDS-1: get mode > from tunables: > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.modes.LVDS-1 > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.default_mode > Aug 19 02:51:10 current kernel: info: [drm] Connector VGA-1: get mode > from tunables: > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.modes.VGA-1 > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.default_mode > Aug 19 02:51:10 current kernel: info: [drm] Connector HDMI-A-1: get > mode from tunables: > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.modes.HDMI-A-1 > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.default_mode > Aug 19 02:51:10 current kernel: info: [drm] Connector DP-1: get mode > from tunables: > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.modes.DP-1 > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.default_mode > Aug 19 02:51:10 current kernel: fbd0 on drmn0 > Aug 19 02:51:10 current kernel: WARNING: Device "fb" is Giant locked > and may be deleted before> > Aug 19 02:51:10 current kernel: VT: Replacing driver "vga" with new "fb". > ug 19 02:51:10 current kernel: info: [drm] Initialized i915 1.6.0 > 20080730 for drmn0 on minor 0 > > so far so good, quality of text in grafics 1368x1024 is perfectly > initialized. but now, when starting xinit or lightdm or sddm or > whatever I get a kernel panic: > > Dump header from device: /dev/ada0p4 > Architecture: i386 > Architecture Version: 4 > Dump Length: 97792 > Blocksize: 512 > Compression: none > Dumptime: 2020-08-19 02:49:00 +0200 > Hostname: current > Magic: FreeBSD Text Dump > Version
Re: kldref: too many segments on kernel build
> On 19. Aug 2020, at 06:19, Dustin Marquess wrote: > > On Tue, Aug 18, 2020 at 3:19 PM Michael Butler > wrote: >> >> Any thoughts as to why this is happening when I build a (custom) kernel? >> >> kldxref: /boot/kernel/kernel: too many segments > > I'm seeing this too. I haven't tried actually booting the kernel > because of this. I also see this... The kernel boots just fine. Best regards Michael > > -Dustin > ___ > 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" ___ 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: kldref: too many segments on kernel build
On Tue, 18 Aug 2020 23:19:08 -0500 Dustin Marquess wrote: > On Tue, Aug 18, 2020 at 3:19 PM Michael Butler > wrote: > > > > Any thoughts as to why this is happening when I build a (custom) kernel? > > > > kldxref: /boot/kernel/kernel: too many segments > > I'm seeing this too. I haven't tried actually booting the kernel > because of this. > Same here, but I was able to boot the kernel (installed to /boot/test) with no errors. But Xorg fails to start. That may not be related to the kldxref error itself but is perhaps due to other changes in the kernel which cause the Nvidia driver to fail at startup. I'm not willing to rebuild the Nvidia driver to test my hypothesis. -- Gary Jennejohn ___ 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"
