Re: FUSE Call for Testing

On Fri, Aug 9, 2019 at 3:02 AM Gary Jennejohn wrote: > > On Thu, 8 Aug 2019 12:34:52 -0600 > Alan Somers wrote: > > [snip] > > > VM images: > > http://ftp0.nyi.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/13.0-CURRENT/amd64/20190808/ > > ISOs:

Re: FUSE Call for Testing

On Thu, 8 Aug 2019 12:34:52 -0600 Alan Somers wrote: [snip] > VM images: > http://ftp0.nyi.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/13.0-CURRENT/amd64/20190808/ > ISOs: http://ftp0.nyi.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.0/ > > Thanks for any feedback you can give! So, I tried

Re: FUSE Call for Testing

Damjan, thanks for the suggestion. I did like Alan suggested and: clay@bsd13:~ % pkg info -r fusefs-libs pkg: No package(s) matching fusefs-libs clay@bsd13:~ % pkg info -r fusefs-libs3 pkg: No package(s) matching fusefs-libs3 I'm sitting here looking at a pkg search fuse in LXTerminal and I see:

Re: FUSE Call for Testing

On Thu, Aug 8, 2019 at 10:25 PM Damjan Jovanovic wrote: > NTFS-3G (sysutils/fusefs-ntfs) is probably the most widely used FUSE > filesystem. > fusefs-exfat is also pretty commonly used. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP

Re: FUSE Call for Testing

NTFS-3G (sysutils/fusefs-ntfs) is probably the most widely used FUSE filesystem. On Fri, Aug 9, 2019 at 4:21 AM Clay Daniels Jr. wrote: > Alan, I'm pretty much into 13.0 Current and most weeks install the newest > snapshot build. I don't know if I use FUSE or not, if you must know the > truth.

Re: FUSE Call for Testing

Clay, Thanks for offering to help. If you don't know whether or not you're currently using FUSE, just do "pkg info -r fusefs-libs" and " pkg info -r fusefs-libs3". There are a few fuse ports that don't depend on either fusefs-libs or fusefs-libs3, but not many. If you don't find any, but

Re: FUSE Call for Testing

Alan, I'm pretty much into 13.0 Current and most weeks install the newest snapshot build. I don't know if I use FUSE or not, if you must know the truth. I do some hobby coding, lurk here on the email lists and Forum, and try to learn all I can. So do you have any specific suggestions for programs

Re: FUSE Call for Testing

On Thu, Aug 08, 2019 at 12:34:52PM -0600, Alan Somers wrote: > The new FUSE driver has just landed in current. It raises the protocol > level from 7.8 to 7.23, fixes many bugs, adds a test suite for the > driver, and adds many new features. New features include: Thanks for sharing your work! --

FUSE Call for Testing

The new FUSE driver has just landed in current. It raises the protocol level from 7.8 to 7.23, fixes many bugs, adds a test suite for the driver, and adds many new features. New features include: * Optional kernel-side permissions checks (-o default_permissions) * Implement VOP_MKNOD,

Re: testing early microcode loading

Intel microcode updates has landed in >>>> the kernel in r337715, and in the sysutils/devcpu-data port as of 1.20. >>>> I'd like to solicit some testing of the feature ahead of 12.0. >>> Hey there Mark, >>> So I've just tested this on a kabylake system ru

Re: testing early microcode loading

On Tue, Sep 11, 2018 at 10:20:56AM +0200, Andrea Venturoli wrote: > On 9/10/18 8:26 PM, Mark Johnston wrote: > > Hi, > > > > Support for boot-time loading of Intel microcode updates has landed in > > the kernel in r337715, and in the sysutils/devcpu-data port as of 1.20. > > Thanks for your

Re: testing early microcode loading

On 9/10/18 8:26 PM, Mark Johnston wrote: Hi, Support for boot-time loading of Intel microcode updates has landed in the kernel in r337715, and in the sysutils/devcpu-data port as of 1.20. Thanks for your work. Altough I cannot test it yet, I appreciate it. Just one question: what about AMD?

Re: testing early microcode loading

kernel in r337715, and in the sysutils/devcpu-data port as of 1.20. >>> I'd like to solicit some testing of the feature ahead of 12.0. >> Hey there Mark, >> So I've just tested this on a kabylake system running a kernel/world >> from Sept 7th which I believe is recent

Re: testing early microcode loading

of 1.20. > > I'd like to solicit some testing of the feature ahead of 12.0. > > Hey there Mark, > So I've just tested this on a kabylake system running a kernel/world > from Sept 7th which I believe is recent enough. > > After updating /boot/loader.conf as per your

Re: testing early microcode loading

On 9/10/18 11:26 AM, Mark Johnston wrote: Hi, Support for boot-time loading of Intel microcode updates has landed in the kernel in r337715, and in the sysutils/devcpu-data port as of 1.20. I'd like to solicit some testing of the feature ahead of 12.0. The port has been modified to install

testing early microcode loading

Hi, Support for boot-time loading of Intel microcode updates has landed in the kernel in r337715, and in the sysutils/devcpu-data port as of 1.20. I'd like to solicit some testing of the feature ahead of 12.0. The port has been modified to install /boot/firmware/intel-ucode.bin. This file

Re: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted

Hi Tested both images in both modes on: Intel® Server Board S1200KP E3-1230 CPU BIOS/legacy mode work perfectly UEFI failed. Not surprising as I have never gotten FreeBSD UEFI to work on this motherboard. Console displayed: - /boot/kernel/kernel Booting...

Re: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted

20180529-r334337-memstick.img > > We are interested in testing both UEFI and CSM/BIOS/legacy mode, as we > would like to get this included in the upcoming 11.2-RELEASE if the > change that had been committed addresses several boot issues reported > recently. > > Please help test,

Re: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted

are available at: https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-mini-memstick.img https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-memstick.img We are interested in testing

RE: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted

available at: > https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-mini-memstick.img > https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-memstick.img > > We are interested

Re: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted

SeaBIOS 1.10.2 Upgrading seems to do the trick > Am 03.06.2018 um 06:25 schrieb Idwer Vollering : > > 2018-06-03 7:23 GMT+02:00 Albert : >> Hi, >> >> >> I successfully tested the memstick.img on: >> Acer Chromebook 14 (EDGAR) [CB3-431-C5EX] >> >> The Results: >> UEFI (Coreboot) works

Re: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted

2018-06-03 7:23 GMT+02:00 Albert : > Hi, > > > I successfully tested the memstick.img on: > Acer Chromebook 14 (EDGAR) [CB3-431-C5EX] > > The Results: > UEFI (Coreboot) works perfectly, no issues there. > BIOS (SeaBIOS) does *NOT* work. It puts the machine into a bootloop until > the install

Re: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted

at: https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-mini-memstick.img https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-memstick.img We are interested in testing both

Re: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted

Hi, I successfully tested the memstick.img on: Acer Chromebook 14 (EDGAR) [CB3-431-C5EX] The Results: UEFI (Coreboot) works perfectly, no issues there. BIOS (SeaBIOS) does *NOT* work. It puts the machine into a bootloop until the install medium is disconnected. It does, however, make it past

Re: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted

20180529-r334337-memstick.img > > We are interested in testing both UEFI and CSM/BIOS/legacy mode, as we > would like to get this included in the upcoming 11.2-RELEASE if the > change that had been committed addresses several boot issues reported > recently. > > Please help test,

Re: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted

ts/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-memstick.img > > We are interested in testing both UEFI and CSM/BIOS/legacy mode, as we > would like to get this included in the upcoming 11.2-RELEASE if the > change that had been committed addresses several bo

Re: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted

>https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD >-12.0-CURRENT-amd64-20180529-r334337-mini-memstick.img Works fine on a Lenovo ThinkPad x201 Fails on a Dell PowerEdge 2950 - The USB stick doen't show up in the boot menu - After fixing the partition table entries,

Re: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted

CURRENT-amd64-20180529-r334337-memstick.img > > We are interested in testing both UEFI and CSM/BIOS/legacy mode, as we > would like to get this included in the upcoming 11.2-RELEASE if the > change that had been committed addresses several boot issues reported > recently. > > Please help

Re: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted

CURRENT-amd64-20180529-r334337-memstick.img > > We are interested in testing both UEFI and CSM/BIOS/legacy mode, as we > would like to get this included in the upcoming 11.2-RELEASE if the > change that had been committed addresses several boot issues reported > recently. > >

Re: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted

-amd64-20180529-r334337-memstick.img > > We are interested in testing both UEFI and CSM/BIOS/legacy mode, as we > would like to get this included in the upcoming 11.2-RELEASE if the > change that had been committed addresses several boot issues reported > recently. > > Pleas

Re: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted

reebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-memstick.img GB> GB> We are interested in testing both UEFI and CSM/BIOS/legacy mode, as we GB> would like to get this included in the upcoming 11.2-RELEASE if the GB> change that had be

Re: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted

-r334337-memstick.img > >We are interested in testing both UEFI and CSM/BIOS/legacy mode, as we >would like to get this included in the upcoming 11.2-RELEASE if the >change that had been committed addresses several boot issues reported >recently. >Please help test, and report back (both

Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted

/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-mini-memstick.img https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-memstick.img We are interested in testing both UEFI and CSM/BIOS/legacy mode, as we would

Re: CloverEFIBoot (was Re: Call for Testing: UEFI Changes)

he processor will not be fixed by Intel and that still needs support for the traditional BIOS. I also bought a 3TB HD (they were easier to find that 2T). If I leave the disk dedicated to FreeBSD it recognizes the complete 3TB and will happily use ZFS for everything, however I want to dual boot so after lots

Re: CloverEFIBoot (was Re: Call for Testing: UEFI Changes)

to find that 2T). >> >> If I leave the disk dedicated to FreeBSD it recognizes the complete 3TB and >> will happily use ZFS for everything, however I want to dual boot so after >> lots of testing I ended up ignoring 1 TB of HD :(. >> >> It does happen that th

Re: CloverEFIBoot (was Re: Call for Testing: UEFI Changes)

y were easier to find that 2T). If I leave the disk dedicated to FreeBSD it recognizes the complete 3TB and will happily use ZFS for everything, however I want to dual boot so after lots of testing I ended up ignoring 1 TB of HD :(. It does happen that there is a really nice boot loader that coul

Re: CloverEFIBoot (was Re: Call for Testing: UEFI Changes)

nd that 2T). > > If I leave the disk dedicated to FreeBSD it recognizes the complete 3TB and > will happily use ZFS for everything, however I want to dual boot so after > lots of testing I ended up ignoring 1 TB of HD :(. > > It does happen that there is a really nice boot

CloverEFIBoot (was Re: Call for Testing: UEFI Changes)

use ZFS for everything, however I want to dual boot so after lots of testing I ended up ignoring 1 TB of HD :(. It does happen that there is a really nice boot loader that could have saved the day but it is very difficult to install standalone: https://sourceforge.net/projects/cloverefiboot

Re: Call for Testing: UEFI Changes

On Thu, Apr 5, 2018 at 7:23 PM, Zaphod Beeblebrox wrote: > As I said I would, I put the contents of /boot onto the FAT-formated EFI > partition. This is suboptimal. The default is to use "kernel.old" ... etc > ... which cannot be done on a FAT partition... at least not with

Re: Call for Testing: UEFI Changes

8 while still achieving the same effect. The observed > > regression was that the kernel would usually end up drawing > > incorrectly at the old resolution on a subset of the screen, due to > > incorrect framebuffer information. > > > > Explicit testing of these change

Re: Call for Testing: UEFI Changes

e to > incorrect framebuffer information. > > Explicit testing of these changes, the latest of which happened in > r331326, and any feedback from this testing would be greatly > appreciated. Testing should be done with either `options EFIRT` in > your kernel config or efirt.ko

Re: Call for Testing: UEFI Changes

If you're thinking on it, you should know that the DVD version works. The difference, AFAICT, is that it simply calls loader.efi directly. Ie: bootx64.efi is loader.efi, not boot1.efi. Loader.efi doesn't seem to change the screen mode when it starts. When the kernel starts afterwards, this

Re: Call for Testing: UEFI Changes

On Tue, Apr 3, 2018 at 3:17 PM, Kyle Evans wrote: > Hi, > > Right- so, `gop set 0` should've immediately cleared your screen and > put it into 1920x1080, full stop. If it did not, I think that's > indicative of some kind of interestingly broken firmware... > > Regardless!

Re: Call for Testing: UEFI Changes

Hi, Right- so, `gop set 0` should've immediately cleared your screen and put it into 1920x1080, full stop. If it did not, I think that's indicative of some kind of interestingly broken firmware... Regardless! We're clearly bad at trying to set a mode before the kernel starts, so r331904 sets the

Re: Call for Testing: UEFI Changes

I did as you asked. You can see the result at: https://owncloud.towernet.ca/s/6K3pGknCyGTi7du ... but the long and short of it is that even though the loader is printing in the center of the screen (text mode?), it sees the 1920x1080 mode as the "mode 0" ... I even tried "gop set 0" ... which it

Re: Call for Testing: UEFI Changes

On Mon, Apr 2, 2018 at 5:51 PM, Zaphod Beeblebrox wrote: > On Sun, Apr 1, 2018 at 7:41 PM, David NewHamlet > wrote: >> >> Fixed in: FreeBSD-12.0-CURRENT-amd64-20180329-r331740-disc1.iso >> >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176694

Re: Call for Testing: UEFI Changes

I've booted that image on my zbook 15. I show in the boot that I can deliberately load efirt.ko ... and it doesn't help. I also show that I can "type blind" after the system boots ... so everything but the screen is working. In case you can't quite make it out, I hit right cursor twice (move to

Re: Call for Testing: UEFI Changes

On Sun, Apr 1, 2018 at 7:38 AM, Tomoaki AOKI wrote: > Confirmed both loader (with boot1) part and efirt.ko part. > Working OK on my ThinkPad420 (with nvidia GPU) at r331864. > > No benefit (VGA resolution) but no new harm (no panic nor silent > reboot). > > *Maybe

Re: Call for Testing: UEFI Changes

Fixed in: FreeBSD-12.0-CURRENT-amd64-20180329-r331740-disc1.iso https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176694 On Mon, Apr 2, 2018 at 12:38 AM, Tomoaki AOKI wrote: > Confirmed both loader (with boot1) part and efirt.ko part. > Working OK on my ThinkPad420

Re: Call for Testing: UEFI Changes

Confirmed both loader (with boot1) part and efirt.ko part. Working OK on my ThinkPad420 (with nvidia GPU) at r331864. No benefit (VGA resolution) but no new harm (no panic nor silent reboot). *Maybe gracefully falling back to mode 0. As I'm on x11/nvidia-driver, completely no test is done with

Re: Testing requested: Hybrid ISO/USB boot

> On 24 Mar 2018, at 07:31, Benno Rice wrote: > I think I’ve addressed this in this revision: > > https://svnweb.freebsd.org/changeset/base/331463 > > > And I’ve regenerated the image here: > >

Re: Call for Testing: UEFI Changes

On 2018-03-25 14:52, Sheda wrote: >> >> I've tested on two different computers, my ThinkPad x230 and my desktop >> with a Intel DQ77MK motherboard. I've only done light testing such as >> loading efirt.ko and running efibootmgr to check the boot settings, but it >&

Re: Call for Testing: UEFI Changes

> > I've tested on two different computers, my ThinkPad x230 and my desktop > with a Intel DQ77MK motherboard. I've only done light testing such as > loading efirt.ko and running efibootmgr to check the boot settings, but it > has worked fine. > I also haven't seen any i

Re: Call for Testing: UEFI Changes

by r327058 while still achieving the same effect. The observed regression was that the kernel would usually end up drawing incorrectly at the old resolution on a subset of the screen, due to incorrect framebuffer information. Explicit testing of these changes, the latest of which happened in r331326

Re: Testing requested: Hybrid ISO/USB boot

Hi, i wrote: > > If byte 38977 (decimal) was 0xef rather than 0x00, then it would be marked > > as an El Torito boot image for EFI. Benno Rice wrote: > I’ve regenerated the image here: > https://people.freebsd.org/~benno/hybrid-bootonly-20180323-00.iso.xz Looks better now: El Torito images

Re: Testing requested: Hybrid ISO/USB boot

> On Mar 22, 2018, at 1:48 PM, Thomas Schmitt wrote: > > Hi, > > Benno Rice wrote: >> I’ve been working on the ability to create hybrid ISO/HDD boot images for >> x86, a la what Linux systems do with ISOHYBRID. > > Waving friendly over the fence i feel entitled to give

Re: Testing requested: Hybrid ISO/USB boot

gt; https://people.freebsd.org/~benno/hybrid-bootonly.iso.xz < > https://people.freebsd.org/~benno/hybrid-bootonly.iso.xz> > > I’ve tested this image under qemu and VMware under all four of the > BIOS/UEFI and CD/HDD combinations. I’ve also booted a system build around > an Asus X

Re: Testing requested: Hybrid ISO/USB boot

Hi Benno, > On 23. Mar 2018, at 8:50 AM, Franco Fichtner wrote: > > APU1C boot: aborts with "Invalid partition" 3x, then "No /boot/loader" > and then escapes to "FreeBSD/x86 boot" etc. Small follow-up: the hybrid-bootonly.iso goes blank on this one due to no dual boot /

Re: Testing requested: Hybrid ISO/USB boot

ntirely sure if the porting was ok as there were quite a few challenges... but for the sake of testing...) Bhyve boot: ok VirtualBox boot: ok (when using extension .iso) APU1C boot: aborts with "Invalid partition" 3x, then "No /boot/loader" and then escapes to "FreeBSD/x

Re: Testing requested: Hybrid ISO/USB boot

Hi, Benno Rice wrote: > I’ve been working on the ability to create hybrid ISO/HDD boot images for > x86, a la what Linux systems do with ISOHYBRID. Waving friendly over the fence i feel entitled to give some neighbor's review. > The general theory seems to > be that ISO images have a 32KB hunk

Re: Call for Testing: UEFI Changes

kernel would usually end up drawing >> incorrectly at the old resolution on a subset of the screen, due to >> incorrect framebuffer information. >> >> Explicit testing of these changes, the latest of which happened in >> r331326, and any feedback from this testing woul

Testing requested: Hybrid ISO/USB boot

and CD/HDD combinations. I’ve also booted a system build around an Asus X399 Prime motherboard with this dd’ed to a USB stick. I’d love some testing on more systems, especially things that are more likely to have more customized boot firmwares (I’m thinking Dell, HP, etc). Many thanks,

Re: Call for Testing: UEFI Changes

ection is now done differently to avoid regression > caused by r327058 while still achieving the same effect. The observed > regression was that the kernel would usually end up drawing > incorrectly at the old resolution on a subset of the screen, due to > incorrect framebuffer

Re: Call for Testing: UEFI Changes

On Thu, Mar 22, 2018 at 10:16 AM, Peter Lei wrote: > On 3/22/18 8:56 AM, Tomoaki AOKI wrote: >> Hi. >> For problem 2, try reverting r331241 alone. >> This worked for my ThinkPad T420. > > > I also hit this after updating to latest and was about to post when I > saw this thread

Re: Call for Testing: UEFI Changes

On Thu, Mar 22, 2018 at 10:18 AM, Kyle Evans wrote: > On Thu, Mar 22, 2018 at 10:16 AM, Peter Lei wrote: >> On 3/22/18 8:56 AM, Tomoaki AOKI wrote: >>> Hi. >>> For problem 2, try reverting r331241 alone. >>> This worked for my ThinkPad T420. >> >> >> I

Re: Call for Testing: UEFI Changes

On 3/22/18 8:56 AM, Tomoaki AOKI wrote: > Hi. > For problem 2, try reverting r331241 alone. > This worked for my ThinkPad T420. I also hit this after updating to latest and was about to post when I saw this thread - I build efirt into the kernel and it's now doing a panic on boot. It appears to

Re: Call for Testing: UEFI Changes

Hi. For problem 2, try reverting r331241 alone. This worked for my ThinkPad T420. On Thu, 22 Mar 2018 08:22:13 -0500 Kyle Evans wrote: > On Thu, Mar 22, 2018 at 5:13 AM, Jakob Alvermark wrote: > > Hi! > > > > > > Just updated to r331345. > > > > Two

Re: Call for Testing: UEFI Changes

On Thu, Mar 22, 2018 at 5:13 AM, Jakob Alvermark wrote: > Hi! > > > Just updated to r331345. > > Two problems: > > 1. boot/efi.4th is added to /usr/src/ObsoleteFiles.inc but still included in > loader.rc. Loader fails to load it and subsequently fails to load modules. >

Re: Call for Testing: UEFI Changes

52 >> Címzett: FreeBSD Current >> Tárgy: Re: Call for Testing: UEFI Changes >> >> >> >>> On 22 Mar 2018, at 12:13, Jakob Alvermark <ja...@alvermark.net> wrote: >>> >>> Hi! >>> >>> >>> Just updated to r331345. &

RE: Call for Testing: UEFI Changes

-freebsd-curr...@freebsd.org [mailto:owner-freebsd-curr...@freebsd.org] Meghatalmazó Toomas Soome Küldve: 2018. március 22. 11:52 Címzett: FreeBSD Current Tárgy: Re: Call for Testing: UEFI Changes > On 22 Mar 2018, at 12:13, Jakob Alvermark <ja...@alvermark.net> wrote: > > Hi! >

Re: Call for Testing: UEFI Changes

erently to avoid regression >> caused by r327058 while still achieving the same effect. The observed >> regression was that the kernel would usually end up drawing >> incorrectly at the old resolution on a subset of the screen, due to >> incorrect framebuffer information. >>

Re: Call for Testing: UEFI Changes

the screen, due to incorrect framebuffer information. Explicit testing of these changes, the latest of which happened in r331326, and any feedback from this testing would be greatly appreciated. Testing should be done with either `options EFIRT` in your kernel config or efirt.ko loaded along wi

Call for Testing: UEFI Changes

effect. The observed regression was that the kernel would usually end up drawing incorrectly at the old resolution on a subset of the screen, due to incorrect framebuffer information. Explicit testing of these changes, the latest of which happened in r331326, and any feedback from this testing would

Call for testing VMware open-vm-tools update

, and there was a kernel panic that affected HEAD/amd64. That has been addressed and vmware has started QA for the tools for FreeBSD 11.1-R and 10.3-R amd64 and i386. I've given this update a fair amount of testing and it gets a "works on my machine" certification from me. The new version is available

Re: Attn: CI/Jenkins people; Run bhyve instance for testing pf

to learn more about it. It’s starting to become usable, yes. Pf within a jail should behave more or less like the "normal" one. Plus you will be testing per-vnet functionality, which the project needs anyhow, in one go. It *should* behave the same, but the fact is that a setup like t

Re: Attn: CI/Jenkins people; Run bhyve instance for testing pf

On 07/18/2017 02:55 AM, Panagiotes Mousikides wrote: Den 2017-07-16 kl. 21:11, skrev Alan Somers: On Sun, Jul 16, 2017 at 2:44 PM, Panagiotes Mousikides <pagg...@yandex.com> wrote: Hello everybody! I am working on adding tests to the FreeBSD test suite for testing pf, the network

Re: Attn: CI/Jenkins people; Run bhyve instance for testing pf

Den 2017-07-16 kl. 21:11, skrev Alan Somers: On Sun, Jul 16, 2017 at 2:44 PM, Panagiotes Mousikides <pagg...@yandex.com> wrote: Hello everybody! I am working on adding tests to the FreeBSD test suite for testing pf, the network packet filter. These tests need at least two machines r

Attn: CI/Jenkins people; Run bhyve instance for testing pf

Hello everybody! I am working on adding tests to the FreeBSD test suite for testing pf, the network packet filter. These tests need at least two machines running and connected to each other, with one machine generating network traffic and the other running pf and filtering the traffic. I

Re: Attn: CI/Jenkins people; Run bhyve instance for testing pf

On Sun, Jul 16, 2017 at 2:44 PM, Panagiotes Mousikides <pagg...@yandex.com> wrote: > Hello everybody! > > I am working on adding tests to the FreeBSD test suite for testing pf, the > network packet filter. > > These tests need at least two machines running and connected t

Re: 64-bit inodes (ino64) Status Update and Call for Testing

Hi Jilles, Thanks for bringing this up. And of course, thanks to kib@ for including the d_namlen size bump and for his work in driving the rest of this change through to completion. On Sun, May 21, 2017 at 5:14 AM, Jilles Tjoelker wrote: > We have another type in this area

Re: 64-bit inodes (ino64) Status Update and Call for Testing

On Sun, May 21, 2017 at 05:25:35PM +0300, Konstantin Belousov wrote: > On Sun, May 21, 2017 at 04:03:55PM +0200, Jilles Tjoelker wrote: > > On Sun, May 21, 2017 at 03:31:18PM +0300, Konstantin Belousov wrote: > > > On Sun, May 21, 2017 at 02:14:56PM +0200, Jilles Tjoelker wrote: > > > > We have

Re: 64-bit inodes (ino64) Status Update and Call for Testing

On Sun, May 21, 2017 at 04:03:55PM +0200, Jilles Tjoelker wrote: > On Sun, May 21, 2017 at 03:31:18PM +0300, Konstantin Belousov wrote: > > On Sun, May 21, 2017 at 02:14:56PM +0200, Jilles Tjoelker wrote: > > > We have another type in this area which is too small in some situations: > > > uint8_t

Re: 64-bit inodes (ino64) Status Update and Call for Testing

On Sun, May 21, 2017 at 03:31:18PM +0300, Konstantin Belousov wrote: > On Sun, May 21, 2017 at 02:14:56PM +0200, Jilles Tjoelker wrote: > > We have another type in this area which is too small in some situations: > > uint8_t for struct dirent.d_namlen. For filesystems that store filenames > > as

Re: 64-bit inodes (ino64) Status Update and Call for Testing

On Sun, May 21, 2017 at 02:14:56PM +0200, Jilles Tjoelker wrote: > We have another type in this area which is too small in some situations: > uint8_t for struct dirent.d_namlen. For filesystems that store filenames > as upto 255 UTF-16 code units, the name to be stored in d_name may be > upto 765

Re: 64-bit inodes (ino64) Status Update and Call for Testing

pat32 ABI, NFS and > ZFS, addressing ABI compat issues and investigating and fixing ports > failures. rmacklem@ provided feedback on NFS changes, emaste@ and > jhb@ provided feedback and review on the ABI transition support. pho@ > performed extensive testing and identified a nu

Re: 64-bit inodes (ino64) Status Update and Call for Testing

n NFS changes, emaste@ and > > jhb@ provided feedback and review on the ABI transition support. pho@ > > performed extensive testing and identified a number of issues that > > have now been fixed. kris@ performed an initial ports investigation > > followed by an exp-run

Re: 64-bit inodes (ino64) Status Update and Call for Testing

tion -- fixing compat32 ABI, NFS and > ZFS, addressing ABI compat issues and investigating and fixing ports > failures. rmacklem@ provided feedback on NFS changes, emaste@ and > jhb@ provided feedback and review on the ABI transition support. pho@ > performed extensive testing and identifie

64-bit inodes (ino64) Status Update and Call for Testing

on NFS changes, emaste@ and jhb@ provided feedback and review on the ABI transition support. pho@ performed extensive testing and identified a number of issues that have now been fixed. kris@ performed an initial ports investigation followed by an exp-run by antoine@. emaste@ helped with organization

Re: RFC: DTrace probes for debugging or testing in userland programs

*mumble* damnit jordan this requires libdispatch *mumble* -a ___ 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: RFC: DTrace probes for debugging or testing in userland programs

Adrian Chadd wrote in : ad> On 19 December 2016 at 16:04, Jordan Hubbard wrote: ad> > ad> > On Dec 19, 2016, at 12:27 PM, Adrian Chadd wrote: ad> >

Re: RFC: DTrace probes for debugging or testing in userland programs

> On Dec 19, 2016, at 12:27 PM, Adrian Chadd wrote: > > So although I like the sentiment, I don't think using dtrace for > program logging is the right answer. I like what apple did to wrap > the program logging stuff so people didn't just write their own > libraries

Re: RFC: DTrace probes for debugging or testing in userland programs

On 19 December 2016 at 16:04, Jordan Hubbard wrote: > > On Dec 19, 2016, at 12:27 PM, Adrian Chadd wrote: > > So although I like the sentiment, I don't think using dtrace for > program logging is the right answer. I like what apple did to wrap >

RFC: DTrace probes for debugging or testing in userland programs

Hello, > To be clear: my proposal is to replace only debug logging (i.e. for > developers), not the other logging in general, as the subject line > says. Although I agree that DTrace is not lightweight, I think > impact of just adding tracing probes is small. > > -- Hiroki I believe this

RFC: DTrace probes for debugging or testing in userland programs

Hello, > I'd love to see a unified-ish logging API for FreeBSD applications. I > always end up reusing some C code I have here that I based on some > Squid style logging API in ages past. I could always polish it up and > put it up for review. > > I'm not a big fan of requiring dtrace to use it

RFC: DTrace probes for debugging or testing in userland programs

Hello, > You can try to compile a new syslogd, run it, and then attach > dtrace(1) to the syslogd process by "dtrace -q -CI./ > -s ./syslogd_trace.d -p `pgrep syslogd`" in the same directory. one thing that comes to mind is the lack of a way to actually fire these probes without running

Re: RFC: DTrace probes for debugging or testing in userland programs

Hi, I'd love to see a unified-ish logging API for FreeBSD applications. I always end up reusing some C code I have here that I based on some Squid style logging API in ages past. I could always polish it up and put it up for review. I'm not a big fan of requiring dtrace to use it though. On a

RFC: DTrace probes for debugging or testing in userland programs

Hi, I am trying to rewrite userland programs (especially daemons) to support userland DTrace probes to make it possible to trace the behavior by using dtrace(1). The purpose is to provide a consistent interface to enable/collect debug log and show internal states. A lot of daemons define

Re: urtwn(4) / rtwn(4) drivers are merged - call for testing (Was: RTL8812AU / RTL8821AU driver)

Hi! > You need to compile / load rtwn_pci(4) driver too. Ah, oh! Now: sysctl net.wlan.devices says net.wlan.devices: rtwn0 Thanks! Time to experiment 8-} -- p...@opsec.eu+49 171 3101372 4 years to go ! ___

Re: urtwn(4) / rtwn(4) drivers are merged - call for testing (Was: RTL8812AU / RTL8821AU driver)

Sat, 22 Oct 2016 09:22:32 +0300 було написано Kurt Jaeger : Hi! You need to compile / load rtwn_pci(4) driver too. It should be compatible with 11.0-RELEASE (but not with 10 / 9) Hi! > rtwn(4), urtwn(4) and urtwm (from previous emails) drivers were merged > into a > single

Re: urtwn(4) / rtwn(4) drivers are merged - call for testing (Was: RTL8812AU / RTL8821AU driver)

Kurt, No more than idea: kldstat contains rtwn-rtl8192cfwU, but no rtwn-rtl8192cfwU_B. Do you have compiled rtwn-rtl8192cfwU_B.ko in /boot/kernel? Best regards, Michael On Sat, Oct 22, 2016 at 5:19 PM, Kurt Jaeger wrote: > Hi! > > > On -current rtwn has been attached to same

<    1   2   3   4   5   6   7   8   9   10   >