Re: Panic on GENERIC @ 6481b4
On Tue, Aug 13, 2024 at 3:45 PM Warner Losh wrote: > > > On Tue, Aug 13, 2024, 4:02 PM Alexander Ziaee > wrote: > >> On 2024-08-13 17:51 -04:00 EDT, "Shawn Webb" >> wrote: >> > On Tue, Aug 13, 2024 at 09:45:54PM UTC, Alexander Ziaee wrote: >> >> >> Compiling freebsd-current/generic at head commit 6481b4 on >> freebsd-current/generic from July 11th after a `make cleanworld` panics on >> bare metal boot on a thinkpad x230. >> >> > I had the same issue. I rebuilt/reinstalled the >> graphics/gpu-firmware-kmod and >> > graphics/drm-515-kmod ports. After a reboot, all was well. >> >> Cool, thanks Shawn! >> >> Should we put an entry in UPDATING when current will panic without the >> latest drm-kmod, or some other type of instruction somewhere? >> > > Every time you update the kernel, you must rebuild drm-kmod. If you don't > all bets are off. > > I have a different panic with the kernel from 20 minutes ago. Joy. > > Warner > > Best, >> Alex >> > I have long had PORTS_MODULES+= graphics/drm-61-kmod in /etc/src.conf. Thei does result in the module being rebuilt every time I build a kernel, but it assures that it will work on the boot of the new kernel. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Re: Multi cons support has disappeared (on Alder Lake) was: Alt+Fn isn't functional. Has this been removed?
On Tue, Apr 2, 2024 at 11:53 AM Tomoaki AOKI wrote: > On Tue, 02 Apr 2024 08:53:15 -0700 > Chris wrote: > > > On 2024-04-02 04:32, Tomoaki AOKI wrote: > > > On Tue, 02 Apr 2024 00:42:23 -0700 > > > Chris wrote: > > > > > >> On 2024-04-01 22:51, Kevin Oberman wrote: > > >> > On Mon, Apr 1, 2024 at 3:05 PM Chris > wrote: > > >> > > > >> >> I experience challenges running FreeBSD on my Alder Lake laptop. > > >> >> With some help on the list and Bugzilla, I was able to get Graphics > > >> >> WiFi at least working. But still wasn't as stable as running on > > >> >> more dated CPU's. As it is; I'm only able to use CURRENT. Beginning > > >> >> of last week, in hopes of getting a more stable experience. I wiped > > >> >> the partition (UFS) and unpacked the version available on the > FreeBSD > > >> >> ftp servers at that time. I quickly discovered that multi-cons > (Ctrl+ > > >> >> Alt+Fn || Alt+Fn) was no longer available. I posted this discovery > to > > >> >> the list. But no solution was discovered. I've since attempted to > use > > >> >> 2 more different newer versions. Both of them were also w/o > multi-con(s) > > >> >> support. What must I do to fix, or uncover the cause of this? > > >> >> I only load the associated GPU module in rc.conf(5) (no keyboard > settings). > > >> >> I'm also unable to get multi-cons booting from any of the boot > media > > >> >> produced within the last week. > > >> >> > > >> >> Following are some specifics: > > >> >> > > >> >> CPU: 12th Gen Intel(R) Core(TM) i3-1215U (2496.00-MHz K8-class CPU) > > >> >> > > >> >> IdeaPad 3 17IAU7 > > >> >> > [Lots of details elided]] > > >> > > > >> > I have a T16 and ran into that issue. It may be that BIOS changes > have > > >> > broken things, but I found that, by default, the F keys control > volume, > > >> > screen brightness, and many other things. I can use Fn+F[1-12] to > perform > > >> > traditional function key functions. I found that bios has an option > to make > > >> > the traditional functions the default which is how I am running > today and > > >> > have since shortly after I purchased the computer. One I set that > BIOS > > >> > option, everything worked "properly". I now use Fn+F[1-12] to > adjust volume > > >> > and screen brightness. I hope to get mute to work, but I need to > figure out > > >> > which event is set when Fn+F1 is pressed to write trivial devd > support for > > >> > it. > > >> Well, I can't explain it. I set everything up in the BIOS to work > > >> "traditionally" > > >> and everything worked fine up until the upgrade. Where everything went > > >> "south" > > >> in the Fn department. But since you mentioned it. I thought I'd > review the > > >> settings > > >> and sure enough, the Function key settings had changed. I have no > > >> explanation. I > > >> haven't been to the BIOS settings since initial setup. But only that > > >> setting > > >> was > > >> changed. I can't thank you enough for mentioning this, Kevin. I > *really* > > >> appreciate > > >> your taking the time to reply! > > > > > > So I was correct. ;-) > > I don't know how in the I missed your suggestion. Thank you for > figuring > > it out, > > (even if I somehow missed it)! How embarrassing. > > Maybe just because my previous post was sent to this ML only, not > including your email directly as a recipient. ;-) > FWIW, when I sent the message to "All", bsdforge had blocked it (550 5.0.0 REJECT, too much abuse from your host). If this is an indication that my system is misbehaving, please let me know. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Re: Multi cons support has disappeared (on Alder Lake) was: Alt+Fn isn't functional. Has this been removed?
0:0:22:0: class=0x078000 rev=0x01 hdr=0x00 vendor=0x8086 > device=0x51e0 subvendor=0x17aa subdevice=0x3815 > vendor = 'Intel Corporation' > device = 'Alder Lake PCH HECI Controller' > class = simple comms > ahci0@pci0:0:23:0: class=0x010601 rev=0x01 hdr=0x00 vendor=0x8086 > device=0x51d3 subvendor=0x8086 subdevice=0x7270 > vendor = 'Intel Corporation' > device = 'Alder Lake-P SATA AHCI Controller' > class = mass storage > subclass = SATA > pcib2@pci0:0:29:0: class=0x060400 rev=0x01 hdr=0x01 vendor=0x8086 > device=0x51b1 subvendor=0x17aa subdevice=0x381f > vendor = 'Intel Corporation' > device = 'Alder Lake PCI Express x1 Root Port' > class = bridge > subclass = PCI-PCI > isab0@pci0:0:31:0: class=0x060100 rev=0x01 hdr=0x00 vendor=0x8086 > device=0x5182 subvendor=0x17aa subdevice=0x382b > vendor = 'Intel Corporation' > device = 'Alder Lake PCH eSPI Controller' > class = bridge > subclass = PCI-ISA > hdac0@pci0:0:31:3: class=0x040380 rev=0x01 hdr=0x00 vendor=0x8086 > device=0x51c8 subvendor=0x17aa subdevice=0x3881 > vendor = 'Intel Corporation' > device = 'Alder Lake PCH-P High Definition Audio Controller' > class = multimedia > subclass = HDA > ichsmb0@pci0:0:31:4:class=0x0c0500 rev=0x01 hdr=0x00 vendor=0x8086 > device=0x51a3 subvendor=0x17aa subdevice=0x382f > vendor = 'Intel Corporation' > device = 'Alder Lake PCH-P SMBus Host Controller' > class = serial bus > subclass = SMBus > none4@pci0:0:31:5: class=0x0c8000 rev=0x01 hdr=0x00 vendor=0x8086 > device=0x51a4 subvendor=0x17aa subdevice=0x381c > vendor = 'Intel Corporation' > device = 'Alder Lake-P PCH SPI Controller' > class = serial bus > nvme0@pci0:1:0:0: class=0x010802 rev=0x01 hdr=0x00 vendor=0x2646 > device=0x5013 subvendor=0x2646 subdevice=0x5013 > vendor = 'Kingston Technology Company, Inc.' > device = 'KC3000/FURY Renegade NVMe SSD E18' > class = mass storage > subclass = NVM > sdhci_pci0@pci0:2:0:0: class=0x080501 rev=0x01 hdr=0x00 vendor=0x1217 > device=0x8621 subvendor=0x17aa subdevice=0x3874 > vendor = 'O2 Micro, Inc.' > device = 'SD/MMC Card Reader Controller' > class = base peripheral > subclass = SD host controller > > Id Refs AddressSize Name > 1 95 0x8020 1d527c0 kernel > 21 0x81f54000287e8 fusefs.ko > 31 0x82d8f000 1e3228 i915kms.ko > 42 0x82f7300085090 drm.ko > 51 0x82ff9000 22b8 iic.ko > 62 0x82ffc000 40e9 linuxkpi_video.ko > 73 0x83001000 7358 dmabuf.ko > 83 0x83009000 3378 lindebugfs.ko > 91 0x8300d000 c338 ttm.ko > 101 0x8301a000 5760 cuse.ko > 111 0x8302 3390 acpi_wmi.ko > 121 0x83024000 4250 ichsmb.ko > 131 0x83029000 2178 smbus.ko > 141 0x8302c00091260 if_iwlwifi.ko > 151 0x830be000 5f90 ig4.ko > 161 0x830c4000 4d20 ng_ubt.ko > 173 0x830c9000 bbb8 netgraph.ko > 182 0x830d5000 a250 ng_hci.ko > 192 0x830e 2670 ng_bluetooth.ko > 201 0x830e3000 3218 iichid.ko > 215 0x830e7000 3380 hidbus.ko > 221 0x830eb000 21e8 hms.ko > 231 0x830ee000 40a8 hidmap.ko > 241 0x830f3000 3355 hmt.ko > 251 0x830f7000 22cc hconf.ko > 26 1 0xffff830fa000 2260 pflog.ko > 271 0x830fd00056540 pf.ko > 281 0x83154000 3560 fdescfs.ko > > > Thanks! > > --Chri I have a T16 and ran into that issue. It may be that BIOS changes have broken things, but I found that, by default, the F keys control volume, screen brightness, and many other things. I can use Fn+F[1-12] to perform traditional function key functions. I found that bios has an option to make the traditional functions the default which is how I am running today and have since shortly after I purchased the computer. One I set that BIOS option, everything worked "properly". I now use Fn+F[1-12] to adjust volume and screen brightness. I hope to get mute to work, but I need to figure out which event is set when Fn+F1 is pressed to write trivial devd support for it. BTW, if you have not found it, Fn+K is screen lock. Most everything on my T16 now works with FreeBSD CURRENT. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Re: Removing fdisk and bsdlabel (legacy partition tools)
Killing these would be excellent. I have not used either in many years for either MBR or GPT. The first time used gpart on an MBR disc, I realized that fdisk and bsdlabel, which I'd always found rather clunky, should die, but for years I kept seeing people claim that gpart was only for GPT and that fdisk/bsdlabel was the only way to do MBR. The name (gpt plus 2 letters) seemed to make this clear to some people. Hopefully this has pretty much passed. I do want to open a bug report to fix up the documentation which fails to clarify the units of numeric arguments in gpart, though... bytes vs. blocks for the most part. On Wed, Jan 24, 2024 at 2:28 PM George Michaelson wrote: > I would agree personally, to moving to ports (eg ports/sysutils) with > a DEPRECATED in the DESCR or something, or better yet a Make > invokation event to say "superceded, here is how to proceed against > advice") or something. > > -G > > On Thu, Jan 25, 2024 at 3:30 AM Warner Losh wrote: > > > > On Wed, Jan 24, 2024 at 8:45 AM Ed Maste wrote: > >> > >> MBR (PC BIOS) partition tables were historically maintained with > >> fdisk(8), but gpart(8) has long been the preferred method for working > >> with partition tables of all types. fdisk has been declared as > >> obsolete in the man page since 2015. Similarly BSD disklabels were > >> historically maintained with bsdlabel. It does not yet have a > >> deprecation notice - I have proposed a man page addition in > >> https://reviews.freebsd.org/D43563. > >> > >> I would like to disconnect these from the build, and subsequently > >> remove them. This is prompted by a recent bsdlabel bug report which > >> uncovered a longstanding buffer overflow in that tool. Effort is much > >> better focused on contemporary, maintained tools rather than > >> investigating issues in deprecated ones. Removing these tools would > >> happen in FreeBSD 15 only (no change in 14 or 13). > >> > >> Code review to disconnect fdisk: https://reviews.freebsd.org/D43575 > >> > >> Note that this effort is limited to these maintenance tools only - > >> there is no change to kernel or gpart support for MBR or BSD > >> disklablel partitioning. That said, MBR partitioning and BSD > >> disklabels are best considered legacy formats and should be avoided > >> for new installations, if possible. > >> > >> If anyone is using fdisk and/or bsdlabel rather than gpart I would > >> appreciate knowing what is preventing you from using the contemporary > >> tools. > > > > > > nanobsd's legacy.sh still is using disklabel in two spots. > > > > But one is to just do gpart create -s bsd and the other is to display > it. Easy > > to fix, but even easier to delete legacy.sh entirely. It's not really > needed any > > more and was a product of CHS addressing... Now that we use LBA, it's > > better to use the new embedded ones. Even at $WORK where we kinda > > use legacy, we replace the partitioning stuff with our own custom > thing... > > > > Those are the only users in the tree, but not for long :) > > > > fdisk was good, but somewhere around the CHS -> LBA transition things > > got weird with it, and for really big disks there were reports of issues > that > > I could never encounter when I set out to fix them... Most likely due to > a > > mismatch in the CHS data and the LBA data being recorded in the MBR. > > The in-kernel gpart copes so much better. > > > > I wouldn't object to making these ports, but both these programs use > 'sekret' > > bits from the kernel that might not remain exposed as we clean things up. > > Though the IOCTLs they do (or used to do) may no longer be relevant. It's > > been so long that I've forgotten > > > > Warner > > > > -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Re: How to upgrade an EOL FreeBSD release or how to make it working again
Old packages are not retained after EOL, but ports are version agnostic (more or less, as the current ports tree is only ar tested to run on supported versions and some are marked as "BROKEN" for some versions). All ports are available from the GIT repo (cgit.freebsd.org). On Mon, Jan 15, 2024 at 10:49 AM Mario Marietto wrote: > Hello. > > Do you have deleted forever the set of packages and ports for FreeBSD 11 > or you keep them stored in DVDs that I can buy or download for a small > amount of money ? If yes,where ? To rebuild everything is out of my > expertise. > > On Mon, Jan 15, 2024 at 7:15 PM David Chisnall > wrote: > >> On 15 Jan 2024, at 16:46, Mario Marietto wrote: >> > >> > The ARM Chromebook is based on armv7,it is still recent. >> >> For reference, the ARMv7 architecture was introduced in 2005. The last >> cores that implemented the architecture were released in 2014. This is not >> a ‘recent’ architecture, it’s one that’s 19 years old and has been largely >> dead for several years. >> >> > But let's change perspective for a moment,don't think about the ARM >> Chromebook. My question is : how to upgrade FreeBSD when it goes EOL. >> >> Generally, run `freebsd-update`. This is a very different question from >> ‘how do I do a new install of an old an unsupported version?' >> >> > I ask this because there is a huge difference here between FreeBSD and >> Linux. Today if you need to use , for example Ubuntu 14.0, you can use it >> as is. Yes,there will be a lot of bugs,but it will work without crashes. >> But if you want to use an old FreeBSD system,nothing will work for you. >> So,do you know some methods to install even packages or ports ? You >> know,there are cases when you need to do some experiments so that you can >> keep your machine off the internet,so you aren't scared that someone can >> compromise it. Totally prohibiting the users to use an old system,removing >> ports and packages is not a choice that I approve of. And I'm not the only >> one that thinks like this. >> >> If you want to use an old and unsupported version of FreeBSD, no one is >> stopping you, but: >> >> - You will need to build the releases. The source code is still in git, >> you can. The scripts for building the release images are right there in >> the repo. Just grab the relevant release or releng branch and go. >> >> - You will need to build packages. Newer versions of the ports tree >> will not be tested with the older release, so you may need to use an older >> checkout of the ports tree. Poudriere will build a package repo for you. >> >> In both cases, if you’re using older versions you almost certainly *will* >> have security vulnerabilities. The project strongly advises you not to do >> this and not to blame us when you install known-insecure software and end >> up compromised. >> >> The project does not have enough active contributors to keep maintaining >> things indefinitely. This is why release have a five-year supported >> lifetime. If you want to pick up an old branch and maintain it, you’re >> welcome to. In the past, companies have picked up old branches and >> maintained them for customers that had a dependency on them. If you want >> to pay someone to maintain an old branch (and have deep pockets) then there >> are probably a few companies that will happily take your money. >> >> Maintaining binaries is a slightly different issue, but it’s not totally >> unrelated. Keeping old packages around consumes disk space and costs the >> project money (remember, every package is mirrored across the CDN, so this >> isn’t just a single disk). Even if it were free, philosophically, I think >> making it easy for users to install known-insecure software is a bad idea >> but if you want to keep a package repo with out-of-date packages online >> indefinitely then you can. You can run Poudriere and even cross-compile >> from a fairly beefy cloud machine quite easily. >> >> It’s been a while since I did a full package build, but I would guess >> that you could do a single package build (all ports) for about $50 on a >> cloud VM, more (2-3x) if it’s emulated. Storing the results for a small >> number of users will cost around $10-20/month. If you think this is an >> important thing to do, then you are absolutely welcome to spend your own >> money on doing it. >> >> David >> >> > > -- > Mario. > -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
freebsd-current@freebsd.org
On Tue, Aug 8, 2023 at 10:50 AM Michael Butler wrote: > On 8/8/23 10:56, Tomoaki AOKI wrote: > > On Tue, 8 Aug 2023 17:02:32 +0300 > > Konstantin Belousov wrote: > > [ .. snip .. ] > > >> The workaround is switched on automatically, when kernel detects 'small > cores' > >> reported by CPUID. > > > > If I read the code correctly, vm.pmap.pcid_invlpg_workaround > > (precicely, the corresponding variable) is set to non-zero when the > > workaround is enabled. Not sure it was detected correctly at the > > original reporter's environment, but forcibly setting the tunable to 1 > > didn't reported to help sufficiently. > > Currently, only setting tunable vm.pmap.pcid_enabled to 0 could help. > > I'm seeing similar stability problems on an N95-based device. This too > is an Alderlake-N device with only E-cores although I'm running it with > a compilation with CPUTYPE=tremont .. from an older, verbose start-up .. > > PPIM 0: PA=0x40, VA=0x8271, size=0x1d5000, mode=0x1 > pmap: large map 8 PML4 slots (4096 GB) > VT(efifb): resolution 800x600 > Preloaded elf kernel "/boot/kernel.new/kernel" at 0x8234e000. > Preloaded boot_entropy_cache "/boot/entropy" at 0x82357d08. > Preloaded cpu_microcode "/boot/firmware/intel-ucode.bin" at > 0x82357d60. > Preloaded hostuuid "/etc/hostid" at 0x82357dc0. > Preloaded TSLOG data "TSLOG" at 0x82357e10. > CPU: Intel(R) N95 (1689.60-MHz K8-class CPU) >Origin="GenuineIntel" Id=0xb06e0 Family=0x6 Model=0xbe Stepping=0 > > > Features=0xbfebfbff > > > Features2=0x7ffafbbf >AMD Features=0x2c100800 >AMD Features2=0x121 >Structured Extended > > Features=0x239ca7eb >Structured Extended > > Features2=0x98c007bc >Structured Extended > > Features3=0xfc184410 >XSAVE Features=0xf >IA32_ARCH_CAPS=0x180fd6b >VT-x: Basic Features=0x3da0500 > Pin-Based Controls=0xff > Primary Processor > > Controls=0xfffbfffe > Secondary Processor > > Controls=0x75d7fff > Exit Controls=0x3da0500 > Entry Controls=0x3da0500 > EPT Features=0x6f34141 > VPID Features=0xf01 >TSC: P-state invariant, performance statistics > 64-Byte prefetching > L2 cache: 2048 kbytes, 16-way associative, 64 bytes/line > real memory = 17179869184 (16384 MB) > Physical memory chunk(s): > 0x0001 - 0x0009dfff, 581632 bytes (142 pages) > 0x0009f000 - 0x0009, 4096 bytes (1 pages) > 0x0010 - 0x5fff, 1609564160 bytes (392960 pages) > 0x62401000 - 0x7264dfff, 270848000 bytes (66125 pages) > 0x75fff000 - 0x75ff, 4096 bytes (1 pages) > 0x00011000 - 0x000462497fff, 14533881856 bytes (3548311 pages) > 0x00047fa0 - 0x00047fb68fff, 1478656 bytes (361 pages) > avail memory = 16363008000 (15604 MB) > CPU microcode: updated from 0xc to 0x10 > MADT: Found CPU APIC ID 0 ACPI ID 0: enabled > SMP: Added CPU 0 (AP) > MADT: Found CPU APIC ID 2 ACPI ID 1: enabled > SMP: Added CPU 2 (AP) > MADT: Found CPU APIC ID 4 ACPI ID 2: enabled > SMP: Added CPU 4 (AP) > MADT: Found CPU APIC ID 6 ACPI ID 3: enabled > SMP: Added CPU 6 (AP) > > On start-up, vm.pmap.pcid_invlpg_workaround=1 but seemingly random > faults still occurred under load, for example, 'make buildworld'. > Apparent misreads of source-files resulting in syntax errors were the > most common symptom. Compilation reattempts (mostly) succeed. > > Initially, I put this down to an inadequate power-supply but setting > vm.pmap.pcid_enabled=0 seems to have stabilised it. > > I guess there's another dragon in there .. :-( > > Michae > Just to add another report (in the wrong mail list as it is also on a system running 13.2), I have a very similar system from a different manufacturer with the same Alder Lake processor. I will note that the SSD interface is SATA, not nvme. I was getting crashes and corrupt file systems, especially when installing large ports and using rsync to backup the system. I see many, almost identical systems on Amazon that use the same form factor CPU, SSD, RAM, etc, probably all using the same motherboard from a single manufacturer. There are going to be more issues as these boxes are generally <$225 US. (Mine was a bit more expensive to get a VGA connector for my ancient monitor. I had not tried the tuneable, but largely resolved the issue by installing a 250 MB hard drive and putting the system there. In the couple of months since I did this I have had two cra
Re: problem with poudriere && port ftp/curl
On Fri, Aug 11, 2023 at 3:00 PM Jan Beich wrote:
> Matthias Apitz writes:
>
> > I have the following problem with poudriere on 14-CURRENT and ports from
> > git head: every time when I start poudriere-bulk it removes a port
> > already compile fine (and all its dependent ports) with the message:
> >
> > ...
>
> > The difference seems to be +/-GSSAPI_BASE and +/-GSSAPI_NONE.
> > I have not set anything about
> > this in the port's options or jail's make.conf.
> >
> > What can I do to fix this?
>
> Maybe poudriere is confused by GSSAPI_${${SSL_DEFAULT} == base :?BASE
> :NONE}
> in OPTIONS_DEFAULT due ssl!=base in DEFAULT_VERSIONS via make.conf(5).
> Try filing a bug against ftp/curl.
>
> $ env -i __MAKE_CONF= PORT_DBDIR=/var/empty make -V
> '${OPTIONS_DEFAULT:M*GSS*}'
> GSSAPI_BASE
> $ env -i __MAKE_CONF= PORT_DBDIR=/var/empty DEFAULT_VERSIONS=ssl=openssl
> make -V '${OPTIONS_DEFAULT:M*GSS*}'
> GSSAPI_NONE
>
> See also
> https://cgit.freebsd.org/ports/diff/ftp/curl/Makefile?id=6d324c1f70c9
>
> I can't reproduce on -CURRENT when only using base OpenSSL 3.0.
>
There are several ports with this problem. Since VirtualBox (and
libvncserver) need openssl31, I now delete openssl31, upgrade ports as
required, and then "package add
/usr/ports/packages/All/openssl31-3.1.2.pkg" when finished.
Just today I hit openldap-client trying to use openssl31 even though
make.conf does not define it as default. Several other ports also don't
honor the fairly new USES=openssl and, if they find an openssl installed,
will use it. Since Aug. 1, I have had several other ports hit this issue.
You really, really don't want ports using openssl31 unless you are sure
that they or any port which they depend on are also using openssl31. If you
get shareable libraries with conflicts, it is a pain to clean them up.
Maybe a message to all committers that they need to be sure that
OPENSSLBASE is not used without USES=openssl. (At least I believe that is
the case.)
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Re: Has the update procedure changed?
On Mon, Aug 7, 2023 at 9:12 AM Matthias Apitz wrote:
> El día lunes, agosto 07, 2023 a las 08:51:55a. m. -0700, Kevin Oberman
> escribió:
>
> > On Sun, Aug 6, 2023 at 9:51 AM Tim Kellers wrote:
> >
> > >
> > >
> > > On Aug 6, 2023, at 11:05 AM, Kevin Oberman
> wrote:
> > >
> > >
> > > On Sat, Aug 5, 2023 at 10:51 PM Matthias Apitz
> wrote:
> > >
> > >> In the past I was used to use the following procedure to install a new
> > >> kernel and world:
> > >>
> > >> # cd /usr/src
> > >> # make installkernel
> > >> # shutdown -r now
> > >>
> > >> boot -s from the loader prompt
> > >>
> > >> # adjkerntz -i
> > >> # mount -a -t ufs
> > >> # mergemaster -p
> > >> # cd /usr/src
> > >> # make installworld
> > >> # mergemaster
> > >> # yes | make delete-old
> > >> # yes | make delete-old-libs
> > >>
> > >> # reboot
> > >>
> > ...
>
> > I am more confused about "etcupdate -p". Both files put it after the
> > kernel installation and reboot but before the installworld. The man page
> > for etcupdate says that '-p' it should be run before "make buildworld"
> and
> > I have always followed the man pages.
>
> The man page of mergemaster says:
>
> -p Pre-buildworld mode.
>
"
>
> i.e. it must be run after installkernel and before installworld to
> adjust the new /etc/group and /etc/master.passwd. After installworld
> mergemaster
> should be run (or etcupdate) without -p to adjust all the scripts below
> /etc, /etc/rc.d/ ... I've used this procedure above for many years and
> it always let me decide it I want the new or the old or deal later with
> the diff of all these files. And so I did it yesterday and it worked fine
> again.
>
> Will check the next time what etcupdate wants to do, because it seems
> the sucsessor of mergemaster.
>
> matthias
>
> --
> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/
> +49-176-38902045
> Public GnuPG key: http://www.unixarea.de/key.pub
>
etcupdate is the successor to mergemaster. It is vastly better, but does
have a learning curve when you first start using it. Also, it has quite a
few commands that are seldom needed and I think that intimidates people a
bit. Unless you understand a three-way merge, it is confusing. It's not
complicated, but different from mergemster. (freebsd-update always has done
a three-way merge.)
I don't see how you get this from the man page.
"Compares only files known to be
essential to the success of {build|install}world, i.e.,
/etc/group and /etc/master.passwd.
If it is potentially updating files that MIGHT be essential to a successful
buildworld, running it after buildkernel seems quite wrong. At least I read
{build|install}world as buildworld or installworld.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Re: 14.0 boot failure
I closed the ticket. I think I may have pulled sources just as the MAXCPU size was updated. I did another pull the next day and it built and is running fine. On Tue, Aug 8, 2023 at 10:56 AM Matthias Apitz wrote: > > A kernel git cloned on August 6 boots fine. > > -- > Matthias Apitz > E-mail: g...@unixarea.de > WWW: http://www.unixarea.de/ > phone: +49-170-4527211 > > Am 08.08.2023 19:39, schrieb Graham Perrin: > > On 05/08/2023 00:45, Kevin Oberman wrote: > >> A new kernel built from sources pulled today (4-Aug) at 5:26 UTC fails > >> to boot. … > > > > I refrained from updating after reading this. > > > > Any news? > > > > TIA > > -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Re: Has the update procedure changed?
On Sun, Aug 6, 2023 at 9:51 AM Tim Kellers wrote: > > > On Aug 6, 2023, at 11:05 AM, Kevin Oberman wrote: > > > On Sat, Aug 5, 2023 at 10:51 PM Matthias Apitz wrote: > >> In the past I was used to use the following procedure to install a new >> kernel and world: >> >> # cd /usr/src >> # make installkernel >> # shutdown -r now >> >> boot -s from the loader prompt >> >> # adjkerntz -i >> # mount -a -t ufs >> # mergemaster -p >> # cd /usr/src >> # make installworld >> # mergemaster >> # yes | make delete-old >> # yes | make delete-old-libs >> >> # reboot >> >> Now the handbook >> https://docs.freebsd.org/en/books/handbook/cutting-edge/#makeworld >> says only: >> >> # cd /usr/src >> # make installkernel >> # shutdown -r now >> # cd /usr/src >> # make installworld >> # shutdown -r now >> >> Has this changed in past two years? >> >> Thanks >> >> matthias >> -- >> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ >> +49-176-38902045 >> Public GnuPG key: http://www.unixarea.de/key.pub >> > > Wow! Several obvious reasons that this looks just wrong. (Then again, so > is yours in one case.) > 1. "mergemaster -p" MUST be run before you build the kernel. (Actually, > hte man page says it should be run BEFORE buildworld and that is what I've > always done although I have never seen a case where it was needed until > buildkernel. > 2. While mergemaster(8) is still in the system, you really should be using > etcupdate(8). You also need to understand how a three-way merge is done and > that you often need to edit the merged file when first running it. It's > pretty simple to run and rarely is needed after the first run, but it is > critical to do this for /etc files that you have modified. It's generally > just picking which of the two (original/yours) you want in the final file. > The big win with etcupdate(8) is that it only needs to be run once for > modified files in almost all cases. > 3. Where is "make check-old" and the other tests to get rid of old files. > Leaving these around can lead to serious issues. > 4. If you don't do adjkerntz -i, you might find files installed in the > future which can get REALLY confusing! > > Historically, the final source of truth for all of this is > /usr/src/UPDATING. It has been updated for etcupdate(8) and is handled by > imp@, so I tend to believe it is correct. > > OK. Everyone who knows better, please explain why. I didn't mention "fsck > -p" but I'm really paranoid and it really, really should not be needed > unless something goes wrong in the shutdown after installing the new kernel. > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkober...@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > > I’ve always used the procedure listed at line 90 of the Makefile in > /usr/src as the source of truth. Has that changed? > > Tim > UPDATING seems to match the Makefile except that Makefile is far less detailed. The Makefile even says "See src/UPDATING `COMMON ITEMS' for more complete information." I am more confused about "etcupdate -p". Both files put it after the kernel installation and reboot but before the installworld. The man page for etcupdate says that '-p' it should be run before "make buildworld" and I have always followed the man pages. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Re: Has the update procedure changed?
On Sat, Aug 5, 2023 at 10:51 PM Matthias Apitz wrote: > In the past I was used to use the following procedure to install a new > kernel and world: > > # cd /usr/src > # make installkernel > # shutdown -r now > > boot -s from the loader prompt > > # adjkerntz -i > # mount -a -t ufs > # mergemaster -p > # cd /usr/src > # make installworld > # mergemaster > # yes | make delete-old > # yes | make delete-old-libs > > # reboot > > Now the handbook > https://docs.freebsd.org/en/books/handbook/cutting-edge/#makeworld > says only: > > # cd /usr/src > # make installkernel > # shutdown -r now > # cd /usr/src > # make installworld > # shutdown -r now > > Has this changed in past two years? > > Thanks > > matthias > -- > Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ > +49-176-38902045 > Public GnuPG key: http://www.unixarea.de/key.pub > Wow! Several obvious reasons that this looks just wrong. (Then again, so is yours in one case.) 1. "mergemaster -p" MUST be run before you build the kernel. (Actually, hte man page says it should be run BEFORE buildworld and that is what I've always done although I have never seen a case where it was needed until buildkernel. 2. While mergemaster(8) is still in the system, you really should be using etcupdate(8). You also need to understand how a three-way merge is done and that you often need to edit the merged file when first running it. It's pretty simple to run and rarely is needed after the first run, but it is critical to do this for /etc files that you have modified. It's generally just picking which of the two (original/yours) you want in the final file. The big win with etcupdate(8) is that it only needs to be run once for modified files in almost all cases. 3. Where is "make check-old" and the other tests to get rid of old files. Leaving these around can lead to serious issues. 4. If you don't do adjkerntz -i, you might find files installed in the future which can get REALLY confusing! Historically, the final source of truth for all of this is /usr/src/UPDATING. It has been updated for etcupdate(8) and is handled by imp@, so I tend to believe it is correct. OK. Everyone who knows better, please explain why. I didn't mention "fsck -p" but I'm really paranoid and it really, really should not be needed unless something goes wrong in the shutdown after installing the new kernel. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Re: Fwd: Unreliability with DHCP
On Sat, Aug 5, 2023 at 3:16 PM Graham Perrin wrote: > On 05/08/2023 12:39, Oleksandr Kryvulia wrote: > > 04.08.23 19:07, Graham Perrin пише: > >> > >> Can anyone from freebsd-net@ help? > >> > >> > >> Forwarded Message > >> Subject: Unreliability with DHCP > >> Date: Sun, 30 Jul 2023 16:17:43 +0100 > >> From: Graham Perrin > >> Organisation: FreeBSD > >> To: FreeBSD CURRENT > >> > >> > >> > >> 1. Sleep (suspend) whilst connected to one network > >> > >> 2. connect to a network elsewhere > >> > >> 3. wake (resume). > >> > >> Result: > >> > >> /etc/resolv.conf frequently contains outdated information. In some > >> (maybe all) such cases, the IPv4 inet address is outdated; and so on. > >> > >> Which /etc/rc.d/ file(s) should I attempt to fix? > >> > >> I imagine using the resume keyword, which is currently used by only > >> one script: > >> > >> % rcorder -k resume /etc/rc.d/* > >> /etc/rc.d/ntpd > >> % > >> > >> > >> I routinely run the command below to work around the bug (and observe > >> the states of things) – run _after_ the bug bites. I'd prefer a fix, > >> to prevent the bites. > >> > >> ls /var/run/resolvconf/interfaces/ ; route delete default ; ifconfig > >> wlan0 down && ifconfig em0 down && sleep 5 ; ls > >> /var/run/resolvconf/interfaces/ ; ifconfig em0 up && sleep 15 > >> ; ls /var/run/resolvconf/interfaces/ ; cat /etc/resolv.conf ; ping -c > >> 2 -4 freshports.org > >> > > > > > > As dirty workaround I have in my /etc/rc.resume > > > > service netif restart > > service routing restart > > > Thanks, I'll try when I'm next on campus. > > I do know that 'service routing restart' can be problematic. Please, > see, for example, <https://pastebin.com/raw/mXmVPruq>; I had something > similar a few minutes ago. > My usual solution is "service netif restart wlan0" (or the interface you are using). It should restart the interface, if rc.conf calls for it, dhcpclient and wpa_supplicant (if appropriate). -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
14.0 boot failure
A new kernel built from sources pulled today (4-Aug) at 5:26 UTC fails to boot. This is the output of the boot attempt: VT-x: PAT,HLT, MTF, PAUSE, EPT, UG, VPID, VID, Post Intr TSC: P-state invariant, performance statistics real memory = 25769883776 (24576 MB) panic: vm_phys_enq_range: page 0xfe00285c8a58 and npages 8 are misaligned cpuid = 0 time = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x822abbał vpanic() at vpanic+0x149/frame 0x822abbf0 panic() at panic+0x43/frame 0x822abc50 vm_phys_enq_range() at vm_phys_eng_range+0x12d/frame 0x822abc60 vm_phys_alloc_contig() at vm_phys_alloc_contig+8x557/frame 0x822abcf8 vm_page_find_contig_domain() at vm_page_find_contig_domain+0xbe/frame 0x822abd68 vm_page_alloc_contig_domain() at vm_page_alloc_contig_domain+0x135/frame 0x822abdf8 kmem_alloc_contig_pages() at kmem_alloc_contig_pages+8x92/frame 0x822abe88 kmem_alloc_attr_domainset() at kmem_alloc_attr_domainset+0x20d/frame Bx822abf48 vm_ksubmap_init() at vm_ksubmap_init+0x65/frame 0x822abf80 cpu_startup() at cpu_startup+0x28b/frame Bx822abfa8 mi_startup() at mi_startup+8x1f1/frame 0x822abff8 btext() at btext+0x23 KDB: enter: panic [ thread pid 8 tid 0 ] Stopped at kdb_enter+0x32: movq $0,0xdec6e3(%rip db> Any ideas? Pior working kernel (which I'm now running) is n263931-5aee3e14d491. Died too early in the boot for a dump.
Re: rsync use with -tmsdosfs mounted file system? file has vanished: . . .
On Sun, Jul 16, 2023 at 1:57 PM Mark Millard wrote: > I used a sequence that looked like: > > mount -onoatime -tmsdosfs /dev/gpt/CA72optM2efi /CA72optM2efi-media/ \ > && rsync -x --delete -aAUHhh --info=progress2 /boot/efi/ > /CA72optM2efi-media/ > > that got: > > file has vanished: "/CA72optM2efi-media/BCM271~5.DTB" > file has vanished: "/CA72optM2efi-media/BCM271~6.DTB" > 73.77K 0%1.63MB/s0:00:00 (xfr#7, to-chk=0/493) rsync > warning: some files vanished before they could be transferred (code 24) at > main.c(1357) [sender=3.2.7] > > After that, activity reported the likes of: > > rsync: [generator] delete_file: unlink(overlays/VC4-KM~8.DTB) failed: > Read-only file system (30) > and: > rsync: [receiver] mkstemp "/CA72optM2efi-media/.fixup4.dat.2Wonu9" failed: > Read-only file system (30) > > More than rsync was odd at that point: > > # ls -Tld /CA72optM2efi-media/*.DTB > ls: /CA72optM2efi-media/BCM271~5.DTB: No such file or directory > ls: /CA72optM2efi-media/BCM271~6.DTB: No such file or directory > > # rm /CA72optM2efi-media/*/*.DTB > override rwxr-xr-x root/wheel uarch for > /CA72optM2efi-media/overlays/SDHOST~1.DTB? y > rm: /CA72optM2efi-media/overlays/SDHOST~1.DTB: Read-only file system > . . . > > But: > > # mount | grep media > /dev/gpt/CA72optM2efi on /CA72optM2efi-media (msdosfs, local, noatime) > > So the mount itself was not the source of the read-only status so far. > > I then tried: > > # umount /CA72optM2efi-media > # newfs_msdos /dev/da0p1 > # mount -onoatime -tmsdosfs /dev/gpt/CA72optM2efi /mnt > # cp -aRx /boot/efi/ /mnt/ > cp: utimensat: /mnt: Invalid argument > > (which is normal). > > # umount /mnt > > No more oddities , so far after that. > > > For reference: > > # uname -apKU > FreeBSD CA72-16Gp-ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #99 > main-n264171-2a0c0aea4209-dirty: Fri Jul 14 21:00:44 PDT 2023 > > root@CA72-16Gp-ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 > arm64 aarch64 1400093 1400093 > > # pkg info rsync > rsync-3.2.7 > Name : rsync > Version: 3.2.7 > Installed on : Sat Jul 15 14:53:48 2023 PDT > Origin : net/rsync > Architecture : FreeBSD:14:aarch64 > . . . > Annotations: > FreeBSD_version: 1400092 > build_timestamp: 2023-07-02T06:57:44+ > built_by : poudriere-git-3.3.99.20220831 > cpe: cpe:2.3:a:samba:rsync:3.2.7:freebsd14:aarch64 > port_checkout_unclean: no > port_git_hash : f45cd5bd9d4b > ports_top_checkout_unclean: yes > ports_top_git_hash: 880f72e54deb > > > === > Mark Millard > marklmi at yahoo.co <http://yahoo.com> This looks a bit like an issue I was hitting on a 4 CPU, 4 thread Alder Lake processor and 500GB SSD running 13.2-RELEASE. I saw several very strange corruptions, at least one "rsync warning: some files vanished before they could be transferred". In one (the last) case, the system crashed. The 'disc' was corrupted badly enough that fsck failed and I could not boot up the system. The disk was UFS2 GPT format and EFI boot. The interface is SATA, not nVME. In this case, I was installing on a new system and copying the majority of the file system from my old system. The 'fix' is strange and probably not one many other can use. I installed a spinning rust drive of 500GB and installed FreeBSD and used rsync again and it worked. I can't say whether it was a fluke that it worked, but it really smells like some sort of race condition. Could be rsync , VFS, or device driver. Since then I have seen one crash while backing up the system disk using rsync. No corruption and doing another rsync after reboot worked fine, but it was a much smaller run as the first attempt was nearly complete when the system crashed. Maybe unrelated. I do have the core file from the crash. Stil, something weird has been going on. Same issue on two identical systems, so not likely hardware. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Re: Where did the nvd devices go?
Just found another breakage due to nvd becoming a symlimk. I use gkrellm as my system monitor and, after the update, my SSD showed no activity. Easy fix to edit the configuration to disable nvd0 and enable nda0, but another case of a tool not following the symlink. If I get a little time tomorrow. I'll try finding the code in gkrellm and see if I can figure out whether the breakage is a roble in the port or a system issue, but no promises. On Wed, Jun 21, 2023 at 8:43 PM Warner Losh wrote: > > > On Wed, Jun 21, 2023 at 8:47 PM Kevin Oberman wrote: > >> >> Commands used were "gpart show nvd0" and "geli attach -d -k >> /dev/nvd0p7". Also tried both with and without the "/dev" which fail for >> nvd* and succeed with nda*. >> > > Ah. I see the problem. libgeom doesn't parse the nodes, nor does > it use them when searching for a geom by name... > > I need to carefully think about how to fix it, though, since it may be an > ABI change and we're getting trickily close > to 14 to be mucking with this... > > Warner > -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Re: Where did the nvd devices go?
On Wed, Jun 21, 2023 at 5:52 PM Warner Losh wrote: > > > On Wed, Jun 21, 2023, 6:22 PM Kevin Oberman wrote: > >> Well, they are still around, but not functional. They are symlinks to nda >> devices, but the symlinks don't work well. >> > > They work for filesystem access. > Not too surprised, but I didn't try it. Should have looked more closely before sending it. > > I have no idea when the symlink of nvd to nda happened, but after updating >> my system to main-n263630-ab3e6234ab6e, at least geom related commands no >> longer function using nvd0p?. I hit this when trying to use gpart and geli. >> gpart claims "gpart: No such geom: /dev/nvd0." geli responds (after >> entering a passphrase) "geli: Provider not found: "/dev/nvd0p7"My previous >> system version was main-n262908-c16e08e5f324. >> > > These will work with nda. They should likely work with the nvd aliases, > but don't it seems (though you don't need the /dev/ for geom commands). > > Was this just a failure of muscle memory, or was there persistent config > that failed? > Yes, I had confirmed that nda worked and I know that /dev is not required for geom commands, but I've never bothered to test whether gpt/label worked and I tend to use labels. > > Was this intentional? If so, why was this change made? If not, could it >> be fixed? Since I usually use geli with the /dev/gpt devices, I didn't >> notice it right away, but it could certainly surprise many users. >> > Commands used were "gpart show nvd0" and "geli attach -d -k /dev/nvd0p7". Also tried both with and without the "/dev" which fail for nvd* and succeed with nda*. All these questions are answered in the UPDATING entry from when I switched > the default: > I should have checked UPDATING. -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkober...@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Where did the nvd devices go?
Well, they are still around, but not functional. They are symlinks to nda devices, but the symlinks don't work well. I have no idea when the symlink of nvd to nda happened, but after updating my system to main-n263630-ab3e6234ab6e, at least geom related commands no longer function using nvd0p?. I hit this when trying to use gpart and geli. gpart claims "gpart: No such geom: /dev/nvd0." geli responds (after entering a passphrase) "geli: Provider not found: "/dev/nvd0p7"My previous system version was main-n262908-c16e08e5f324. Was this intentional? If so, why was this change made? If not, could it be fixed? Since I usually use geli with the /dev/gpt devices, I didn't notice it right away, but it could certainly surprise many users. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Re: Status of Alder and Raptor lake on FreeBSD Current
On Wed, Apr 12, 2023 at 11:43 AM Mike Karels wrote: > On 12 Apr 2023, at 9:59, Dries Michiels wrote: > > > Hello current mailing list, > > > > I was wondering what the status of Alder/Raptor lake support is on > FreeBSD? > > Does it boot? Integrated graphics are supported from what I recall with > the > > newest drm drivers. > -current and 13.2 boot and run on Alder Lake, and probably Raptor Lake (I > haven’t heard of any tests). There is a bug, probably in hardware, that > affects page invalidation on E-cores, but a workaround changes the > mechanism > on the E-cores to compensate. I have no information on graphics, maybe > someone else does. > It works with drm-515-kmod, but I have been unable to get VA-API or DRM to work much. driinfo reports swrast. Performance is pretty bad compared to my 12 year old Ivy Lake, but surprisingly fast with all 12 threads on my ThinkPad T16 running. a 1180p video runs at about 13% of the total CPU capacity. glxgears get a rather paltry 900 FPS. But everything seems to work. Mike > -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Re: i915: RCS timing out when being idled
On Sat, Dec 31, 2022 at 9:58 AM obiwac wrote: > Hey, > > I didn't find a more appropriate mailing list to post to, so here it goes: > I'm afraid I can't really help with your problem, but issues with graphics should be sent to FreeBSD graphics GitHub <https://github.com/freebsd/drm-kmod/>. I think having this outside of the standard FreeBSD support structure has bothered me since it was moved from the Bugziila a few years ago. If you want a mailing list, x...@freebsd.org would be most appropriate, though you need to subscribe first. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Re: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? (on FreeBSD14 CURRENT)
On Sun, Nov 13, 2022 at 2:11 PM Tomoaki AOKI wrote: > On Sun, 13 Nov 2022 09:53:00 -0800 > Steve Rikli wrote: > > > On Sun, Nov 13, 2022 at 04:47:40PM +0100, louis.free...@xs4all.nl wrote: > > > I noticed that after disabling gdm in /etc/rc.conf ^"gdm_enable="N"^ > the system stays active. > > > However . that is also the end the GUI in this case GNOME. > > > > > > Since I could not work which a machine hibernating every ^10 minutes^, > I have disabled gdm for the moment. > > > That does not take away that that is .. ridiculous !! > > > > Seems like you aren't alone in that opinion -- there are several threads > > for multiple OSes about this same topic. Kirk's findings below match my > > recollection -- this is Gnome default behavior nowdays. > > > > In any case, since we obviously can't use the Linux systemD settings to > > control the behavior in FreeBSD, a few folks mentioned other workarounds > > with things like dconf; e.g. this suggestion which came originally from > > the Arch linux folks: > > > > https://twitter.com/_neelc/status/1487200568149831681 > > > > https://wiki.archlinux.org/title/GDM#GDM_auto-suspend_(GNOME_3.28) > > > > Something like: > > > > sudo -u gdm dbus-launch gsettings set \ > > org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type > 'nothing' > > > > >From the threads, it sounds like part of the problem is this behavior > and > > settings are per-user, so making a system-wide change is hard. Not sure > > how this workaround will play in your situation. > > > > My FreeBSD servers don't run a gui display manager; my Debian laptop > > runs gdm3 display manager but I switched to Xfce for the window manager > > around the time Gnome3 came out (too many changes for my taste). Fwiw > > the Xfce Power Manager has controls for system power save / sleep mode > > for "On battery" and "Plugged in", including "never". > > Found these. > > > https://unix.stackexchange.com/questions/289640/how-to-create-a-default-system-wide-dconf-setting-starting-from-just-created-ad > > > https://askubuntu.com/questions/1038184/how-to-lockdown-system-wide-settings-with-dconf > > /etc/ in those should be read /usr/local/etc/ on FreeBSD. > And possibly defaults of each application are stored > under /usr/local/share/ or under /usr/local/lib/. > > BTW, I'm basically using x11/mate, a fork from Gnome2. > It doesn't sleep by default on AC powerline. > (Old installation succeeding Gnome2 settings. So current default could > be different, though.) > > > > > Cheers, > > sr. > This is the source of foolishness that led to the creation of Linux Mint and to Mate. Mate does not have this stupidness and I suspect that Cinnamon does not, either. Gnome has simply gone off the rails. Another option is to NOT use gdm, but start Gnome with startx, which I have always done. You will need to create a suitable .xinitrc to set up dbus and run X as a child: exec ck-launch-session dbus-launch --exit-with-session mate-session Under Linux this stuff is all wrapped around systemd which makes dealing with it a pain. I am not remotely expert on this, but it works OK and I am hoping to figure out a bit more as time is available. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Re: Status of Alder Lake support
On Sat, Aug 20, 2022 at 11:45 AM Amar Takhar wrote: > On 2022-08-20 11:36 -0700, Kevin Oberman wrote: > > > Wow! That's a little more disturbing. > > Especially since it's a i9-12900KF so I have a whole 8 cores disabled! > > > > As to the audio issue, I've been having a similar issue for some time, > > especially with Firefox using any of the available audio systems. Works > best > > with OSS. > > > > What I hear is not popping, but brief dropouts which I perceived as > pops. It > > sounds a lot like data rate mismatch where the audio is output at a > slightly > > faster rate than it is input. As a result, the buffers empty > periodically and > > you hear a fraction of a second of silence. > > Yes exactly. Sorry it's better described as clipping and that is exactly > what I > thought was happening too. There were some suggestions in that ticket I > tried > to no avail. It's almost like something is blocking the buffer from being > filled. The same issue happens when I use an external USB audio card but > it's > nowhere near as bad. > > After this many months I'd like to say I've gotten used to it but some > videos > are particularly bad so there is some correlation to what audio is being > played. > > > > This is not an Alder Lake issue as it's been hitting me on my Comet Lake > > processor. > > Oh well that's good to know you should update that ticket (#263385) as > I've only > known Alder Lake to be an issue up to this point. > > Is this happening on CURRENT? I'll upgrade for sure if I can use my E > cores and > avoid UFS corruption. > > > Amar. > My Alder Lake has only run CURRENT as it is most likely going to get graphics support and a fix for hte file system crashes first. Sadly, disabling soft updates does not fix the problem. I got one more VFS crash after disabling them. Still, a single dump while building around 1000 ports is a huge improvement! Having soft updates enabled clearly makes the likelihood of a crash much greater. I have opened ticket 266145 on this problem if you want to see if this goes anywhere. Since it looks like a mix of performance and efficiency core will be hte norm from now on from both Intel and AMD, this clearly will need some attention soon. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Re: Status of Alder Lake support
On Sat, Aug 20, 2022, 11:14 Amar Takhar wrote: > I've run into this in my situation some BIOs updates cause constant > reboots > especially when playing video. I also have serious audio issues with > continous > popping that I've been unable to solve there is a ticket for that as well: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263385#add_comment > > I'll give CURRENT A shot again in the next day or two to see if this is > all > fixed thanks for the update! > > > Amar. > Wow! That's a little more disturbing. As to the audio issue, I've been having a similar issue for some time, especially with Firefox using any of the available audio systems. Works best with OSS. What I hear is not popping, but brief dropouts which I perceived as pops. It sounds a lot like data rate mismatch where the audio is output at a slightly faster rate than it is input. As a result, the buffers empty periodically and you hear a fraction of a second of silence. This is not an Alder Lake issue as it's been hitting me on my Comet Lake processor. > >
Re: Status of Alder Lake support
Thanks for the info, Alexander. I really appreciate it. I'll find out for myself next week when my SSD gets here, though I might try booting from a thumb drive and see what happens. On Fri, Aug 19, 2022, 18:43 Alexander Motin wrote: > Hi Kevin, > > On 19.08.2022 20:50, Kevin Oberman wrote: > > What is the current state of support for Alder Lake CPUs with a mix of > > "performance" and "Efficiency" cores. I just received my first system > > with such a processor and will be installing FreeBSD as soon as my SSD > > arrives. I have no idea what issues I might run into. (Will it even > work?) > > Generally they work. I have one in my lab since they appeared, and its > biggest problem is UEFI console screwed by ASUS, which I partially > fixed. At some BIOS versions they also broke PXE booting, but then > fixed it in later update. > > The FreeBSD scheduler still has no idea about P and E cores, just trying > to balance load equally based on cache topology (which is not symmetric > there), but it is not too bad, since cores performance is not so > dramatically different. > > hwpmc(4) also does not differentiate P and E cores, and since they have > different counters, it means that only few universal architectural > counters are usable, which are sufficient for basic profiling though. > > There were some stability issues reported, but were solved by either > FreeBSD or BIOS update, so still not really diagnosed AFAIK. > > -- > Alexander Motin >
Status of Alder Lake support
What is the current state of support for Alder Lake CPUs with a mix of "performance" and "Efficiency" cores. I just received my first system with such a processor and will be installing FreeBSD as soon as my SSD arrives. I have no idea what issues I might run into. (Will it even work?) -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Re: network address not restored on resume
On Tue, Mar 22, 2022 at 3:03 PM Chuck Tuffli wrote: > On a recent-ish current (git hash 66b86c8a7604), after resuming from > sleep, the main network interface doesn't get restored. Further, > manually fixing this via service netif or ifconfig seems to fail. Am I > doing something wrong? > > root@stargate:~ # uname -a > FreeBSD stargate.tuffli.net 14.0-CURRENT FreeBSD 14.0-CURRENT #2 > main-n253430-66b86c8a7604: Sat Feb 26 23:35:02 PST 2022 > root@stargate:~ # ifconfig igc0 > igc0: flags=8863 metric 0 mtu 1500 > > options=4e527bb > ether 1c:69:7a:a9:cd:1c > inet 192.168.5.10 netmask 0xff00 broadcast 192.168.5.255 > media: Ethernet autoselect (1000baseT ) > status: active > nd6 options=29 > root@stargate:~ # zzz > root@stargate:~ # ifconfig igc0 > igc0: flags=8c22 metric 0 mtu 1500 > > options=4e527bb > ether 1c:69:7a:a9:cd:1c > media: Ethernet autoselect (1000baseT ) > status: active > nd6 options=29 > root@stargate:~ # service netif restart igc0 > Stopping Network: igc0. > igc0: flags=8c22 metric 0 mtu 1500 > > options=4e527bb > ether 1c:69:7a:a9:cd:1c > media: Ethernet autoselect (1000baseT ) > status: active > nd6 options=29 > Starting Network: igc0. > igc0: flags=8863 metric 0 mtu 1500 > > options=4e527bb > ether 1c:69:7a:a9:cd:1c > inet 192.168.5.10 netmask 0xff00 broadcast 192.168.5.255 > media: Ethernet autoselect > status: no carrier > nd6 options=29 > root@stargate:~ # > root@stargate:~ # ifconfig igc0 > igc0: flags=8c22 metric 0 mtu 1500 > > options=4e527bb > ether 1c:69:7a:a9:cd:1c > media: Ethernet autoselect (1000baseT ) > status: active > nd6 options=29 > root@stargate:~ # ifconfig igc0 inet 192.168.5.10/24 > igc0: flags=8c22 metric 0 mtu 1500 > > options=4e527bb > ether 1c:69:7a:a9:cd:1c > media: Ethernet autoselect (1000baseT ) > status: active > nd6 options=29 > root@stargate:~ # > Not enough information to guess. What is the content of /etc/rc.conf in regard to configuration of this interface? What shows up in the log file when this happens (usually /var/log/messages)? The log information is particularly important. (Note that I don't have an igc interface.) -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Re: EFI boot partition overwritten
My deep apologies for the top post. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Re: EFI boot partition overwritten
On my laptop, which comes with W10 installed, I wanted to shrink W10 to 256G and put FreeBSD on a new 680G partition and make FreeBSD the default boot. This was all easy except setting up boot and making it default. I just created a EFI/FreeBSD folder in the existing EFI partition (ada0p1) and dropped loader.efi into it. Then I could use efibootmgr(8) to do the rest. It was not too easy to figure out the first time and documentation would have been really nice. Took a while googling (duckduckgoing?) to discover the existence of efibootmgr (thanks Netflix!) and bit longer to figure out just how to use it (man page is really quite good), but it worked perfectly. If anyone cares, efibootmgr on dmy laptop shows: Boot to FW : false BootCurrent: 0001 Timeout: 2 seconds BootOrder : 0001, , 0019, 001A, 001B, 001C, 001D, 001E, 001F, 0020, 0021, 0022, 0023 +Boot0001* FreeBSD Boot* Windows Boot Manager Boot0019* USB CD Boot001A* USB FDD Boot001B* NVMe0 Boot001C* NVMe1 Boot001D* ATA HDD0 Boot001E* ATA HDD1 Boot001F* USB HDD Boot0020* PXE BOOT Boot0021* LENOVO CLOUD Boot0022 Other CD Boot0023 Other HDD Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 On Fri, Jul 16, 2021 at 1:15 PM Michael Gmelin wrote: > > > > On 16. Jul 2021, at 19:38, Warner Losh wrote: > > > > On Fri, Jul 16, 2021 at 6:14 AM Thomas Laus wrote: > > > >> Group: > >> > >> This is an issue for more than just CURRENT. The 'usr/src/UPDATING' > >> file has the instructions for updating the ZFS bootblocks but not the > >> EFI partition. I recently upgraded a RELEASE-12.2 to RELEASE-13.0. The > >> freebsd-update procedure did not upgrade the ZFS bootblocks. I forgot > >> that this PC was UEFI only and overwrote the first partition with the > >> gptzfsboot code. That made my system un-bootable. I found the recovery > >> procedure on one of the FreeBSD forums and was able to reformat the EFI > >> MSDOS partition, create the proper directory structure, and copy the > >> loader.efi file to the correct location and filename using the Live > >> Filesystem running on the installation CD. > >> > >> I searched the man pages and the UPDATING file for instructions but came > >> up empty and had to resort to finding the answer on one of the forums. > >> The filenames have changed since FreeBSD first supported EFI and some of > >> the forum instructions are out of date. My problem must be fairly > >> common and the recovery procedure should be in a man page with a > >> footnote or man reference somewhere on the install media. > >> > >> Since CURRENT receives more updates to the EFI boot loader than the > >> release versions, there should be instructions in the CURRENT > >> 'usr/src/UPDATING' file on how to update the EFI bootcode. > >> > > > > There should be. Yes. Last time I went hunting for a place to shoe-horn > it > > in, I got distracted by something else. > > > > The instructions are relatively straight forward. I'm writing them here > for > > your benefit, and also in case someone wants to send me a diff/pull > request > > to include them. Or better yet, put this in the handbook and we can > > reference > > a location from there. > > > > WARNING: This is a quick run-through of how to do this if you need to. > > The example commands given might not be exactly right for all > installations > > as differing numbers of partitions will change the '-i' parameters. > > > > Frist, you need a partition that's of the right type. For GPT that type > is > > `efi` > > as shown in `gpart show ` eg > > # gpart show ada0 > > =>40 2000409184 ada0 GPT (954G) > > 401600- free - (800K) > >1640 1992292792 2 freebsd-ufs (950G) > > 1992294432 700 3 freebsd-swap (3.3G) > > 1999294432 1114792 4 efi (544M) > > > > If you don't have one, you'll need to create one. In the above exmaple, > > I had installed the system with a tiny partition for booting with legacy > > BIOS, but then moved to booting with UEFI. I did this by turning off > > swapping and doing the following: > > # gpart resize -i 3 -s 700 ada0 > > I then created a new efi partition: > > # gpart add -t efi ada0 > > and I let it autosize. > > > > Next, I needed a FAT32 filesystem on that device. FAT16 usually will > > work and often FAT12, but there are known examples of system integrators
Re: etcupdate: Failed to build new tree
On Fri, Jul 2, 2021 at 2:31 AM Nuno Teixeira wrote: > Hello, > > Last update I have some issues with etcupdate: > > etcupdate warning: "No previous tree to compare against, a sane comparison > is not possible." > > That I corrected with: > > etcupdate extract > etcupdate diff > /tmp/etc.diff > patch -R < /tmp/etc.diff > (etcupdate diff doesn't show any diffs.) > > Today I've just updated current and etcupdate -p gives: > > "Failed to build new tree" > > What might be wrong? > > Thanks > Nuno Teixeira > I'm no expert. In fact, I just started using etcupdate in the past couple of months but I think you need to read the man page section on "Default Mode". In most cases, it looks to me like there is no reason to specify the mode. Default Mode just does the right thing when starting from scratch. There are clearly reasons to use the modes for various reasons. but I don't think it should be used in most cases. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Re: Files in /etc containing empty VCSId header
On Wed, Jun 9, 2021 at 2:02 AM Michael Gmelin wrote: > > > > On 9. Jun 2021, at 01:15, Ian Lepore wrote: > > > > On Tue, 2021-06-08 at 15:11 -0700, Rodney W. Grimes wrote: > >>> On Tue, 8 Jun 2021 09:41:34 + > >>> Mark Linimon wrote: > >>> > >>>> On Mon, Jun 07, 2021 at 01:58:01PM -0600, Ian Lepore wrote: > >>>>> Sometimes it's a real interesting exercise to figure out where > >>>>> a > >>>>> file on your runtime system comes from in the source world. > >> > >> There is a command for that which does or use to do a pretty > >> decent job of it called whereis(1). > >> > > > > revolution > whereis ntp.conf > > ntp.conf: > > revolution > whereis netif > > netif: > > That line might make it to a shirt one day: > > > revolution > whereis services > > ;) > Michael > Just to clarify for those not willing or able to RTFM, it only works for executables, not conf files or libraries. It reports the location of the executable, the man page and the port location, if it is a port. For those who did RTFM, it is wrong. It claims that it reports on the location of the source, but that is not the case as far as I know. I have never seen it return anything from /usr/src. > whereis cc cc: /usr/bin/cc /usr/share/man/man1/cc.1.gz > whereis postfix postfix: /usr/local/sbin/postfix /usr/local/man/man1/postfix.1.gz /usr/ports/mail/postfix -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Re: Alternate Screen
We went through this "alternate screen" thing about 12 or more years ago and almost everyone hated it except those used to Linux behavior. I don't think it ever made it into a release after all of the screams of pain. It drives me crazy when editing on the Linux Mint VM I run from time to time. I've never been able to figure out why anyone would find it an improvement an I suspect it was inserted in some Unix code back in the days of the VT100 or VT220 terminal which were super popular and supported it. I guess it's because someone thought it was a cool thing and that terminal based editors were the perfect use. In any case, please make it STOP! -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 On Sat, May 15, 2021 at 10:46 AM Gleb Popov wrote: > On Thu, May 13, 2021 at 5:02 PM Eric van Gyzen wrote: > > > There was a recent discussion about a terminal database update and the > > new Alternate Screen behavior. I'm curious about the resolution, but I > > can't find that discussion. Would someone kindly send a clue-by-four > > via overnight express? > > > > Ultimately, I'd like to know how to get the old behavior back, with no > > alternate screen, and thereby reduce my blood pressure. > > > > When I enter `ee`, I can't scroll in my Konsole window anymore. Instead, > the cursor inside the text editor is moving. > > Is this relevant to that "alternate screen" problem? > ___ > 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: Trying to build Current
On Thu, Apr 15, 2021 at 4:19 AM Willem Jan Withagen via freebsd-current < freebsd-current@freebsd.org> wrote: > On 15-4-2021 12:44, Yuri Pankov wrote: > > Willem Jan Withagen via freebsd-current wrote: > >> On 15-4-2021 11:47, Gary Jennejohn wrote: > >>> On Thu, 15 Apr 2021 10:51:39 +0200 > >>> Willem Jan Withagen via freebsd-current > >>> wrote: > >>> > >>>> Hi, > >>>> > >>>> I actually went completely back to the basic setup with directories > >>>> /usr/src and /usr/obj > >>>> But even then I do not manage to buildworld. > >>>> The process keeps bumping into missing bsm/audit. > >>>> > >>>> First case was when it tried to build the 64bit libc. > >>>> I copied the bsm directory into > >>>>__ /usr/obj/usr/src/amd64.amd64/tmp/usr/include/sys/ > >>>> > >>>> Which allowed it to continue. > >>>> But then a bit further on it halts again in 32bit libc. > >>>> Whcih I could fix the same way. > >>>> > >>>> --- fts.o --- > >>>> In file included from /usr/src/lib/libc/gen/fts.c:40: > >>>> In file included from > >>>> /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/mount.h:38: > >>>> > /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/ucred.h:42:10: > >>>> > >>>> fatal error: 'bsm/audit.h' file not found > >>>> #include > >>>> ^ > >>>> > >>>> Even defining HISTORICAL_MAKE_WORLD did not help, but then I'm not > doing > >>>> 'make world' > >>>> > >>>> So why is this include file missing? > >>>> > >>> Try running make includes first. This step is missing because you are > NOT > >>> doing a buildworld. > >>> > >> Well actual the commands were: > >> > >> rm -rf /usr/src /usr/obj > >> mkdir -p /usr/src /usr/obj > >> cd /usr/src > >> git clone https://git.freebsd.org/src.git . > >> make -j16 buildworld > >> > >> But I'll give it a shot anyways. > > Anything in /etc/make.conf and /etc/src.conf? > I had the same idea, but only after I asked the question > There was quite a lot of old cruft there > Removed it all, and I'm trying fresh again. > But Clang building, even with ccache takes quite some time. > > --WjW > --WjW > You can greatly reduce buildworld time by adding "WITHOUT_LLVM_TARGET_ALL=YES" to /etc/src.conf. This will not build all of the back-ends for other platforms. Of course, it means that you can't cross-compile for them, but I would assume that installing the full llvm11 port would take care of this, so I don't understand why building them is default. This may be shortened to "I don't understand", of course. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: FreeBSD mini-Git Primer
The updated mini-Git Primer is now included in the Developer's Handbook. See Chapter 5. I have sent a number of suggestions for some non-technical changes to Warner, but have not heard back yet. Perhaps he didn't care for them. As I am a real novice who has had to destroy my clone of the sources and start over twice, I find it unlikely that i will be of significant use on the technical side for a while. Git is philosophically very different from RCS/CVS/SVN and the different mindset is taking me a while to fully grasp. I will say that specifying a hash that is in main but not part of the branch you are working on is probably a rather poor idea. I probably could have easily fixed it, but I had no luck in finding the right incantation and eventually blew /usr/src away and started over. (How do you fix a detached clone?) I also find net/gitup a marvelous tool for replacing portsnap. In several ways, it is clearly superior and I look forward to seeing it in the base. I mean, what is simpler than: # gitup -c ports (just once to create the initial clone) #gitup ports (to update, perhaps in periodic(8)) Of course, you do need to edit gitup.conf to select the preferred branch and repo site, but it's pretty obvious. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 On Thu, Apr 8, 2021 at 1:14 AM Graham Perrin wrote: > On 02/03/2021 06:33, Graham Perrin wrote: > > Re: Git, shallow clone hashes, commit counts and system/security updates > > > On 02/03/2021 05:42, Kevin Oberman wrote: > > > > Re: Panic after updating from source > > > >> On Mon, Mar 1, 2021 at 6:31 PM Michael Sierchio > >> wrote: > >> > >>> … > >> > >> You need to be aware that the shallow clone hash will not include the > >> commit count which will be used in future security updates to make it > >> easy > >> to check whether your system needs to be updated or not. A full clone > >> does > >> require more space, but I was surprised at how little extra space it > >> requires. Warner is updating his git mini-guide to point out this > >> issue. > >> If you run STABLE, it's a really significant concern. You can convert > >> the > >> shallow clone to a full one with "git fetch --unshallow". This will take > >> some time to run. > >> -- > >> Kevin Oberman, Part time kid herder and retired Network Engineer > >> E-mail: rkober...@gmail.com > >> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > >> ___ > >> freebsd-questi...@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-questions > > > > … Thank you, Kevin and Warner. > > > > I see the FreeBSD mini-Git Primer in the November/December 2020 edition > of the FreeBSD Journal > <https://issue.freebsdfoundation.org/publication/?i=690210&ver=html5&p=8> > (and the review copy that was publicised in September 2020). > > For news of a future edition, if any, should I simply watch > <https://bsdimp.blogspot.com/search/label/git>? > > Thanks > > (I have another question about deep and shallow … I'll post separately > to freebsd-questions …) > > ___ 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: 13.0 RC4 might be delayed
On Sun, Mar 28, 2021 at 9:36 PM Gleb Popov wrote: > On Mon, Mar 29, 2021 at 4:37 AM David G Lawrence via freebsd-current < > freebsd-current@freebsd.org> wrote: > > > > > On 27/03/21 06:04, David G Lawrence via freebsd-current wrote: > > > >>> On Fri, Mar 26, 2021 at 1:01 PM Graham Perrin < > > grahamper...@gmail.com> > > > >>> wrote: > > > >>> > > > >>>> On 26/03/2021 03:40, The Doctor via freebsd-current wrote: > > > >>>>> ??? if people are having issues with ports like ??? > > > >>>> > > > >>>> If I'm not mistaken: > > > >>>> > > > >>>> * 13.0-RC3 seems to be troublesome, as a guest machine, with > > > >>>> emulators/virtualbox-ose 6.1.18 as the host > > > >>>> > > > >>>> * no such trouble with 12.0-RELEASE-p5 as a guest. > > > >>>> > > > >>>> I hope to refine the bug report this weekend. > > > >>>> > > > >>> > > > >>> Had nothing but frequent guest lockups on 6.1.18 with my Win7 > > system. > > > >>> That > > > >>> was right after 6.1.18 was put into ports. Fell back to legacy (v5) > > and > > > >>> will try again shortly to see if it's any better. > > > >> > > > >> Kevin, > > > >> > > > >> ?? Make sure you have these options in your /etc/sysctl.conf : > > > >> > > > >> vfs.aio.max_buf_aio=8192 > > > >> vfs.aio.max_aio_queue_per_proc=65536 > > > >> vfs.aio.max_aio_per_proc=8192 > > > >> vfs.aio.max_aio_queue=65536 > > > >> > > > >> ?? ...otherwise the guest I/O will random hang in VirtualBox. > > This > > > >> issue was > > > >> mitigated in a late 5.x VirtualBox by patching to not use AIO, but > > the > > > >> issue > > > >> came back in 6.x when that patch wasn't carried forward. > > > > > > > > Sorry I lost that patch. Can you point me to the patch? Maybe it can > > be > > > > easily ported. > > > > > > > > > > I found the relevant commit. Please give me some time for testing and > > > I'll put this patch back in the tree. > > > >If you're going to put that patch back in, then AIO should probably be > > made an option in the port config, as shutting AIO off by default will > > have a significant performance impact. Without AIO, all guest IO will > > be become synchronous. > > > > Are you sure about that? Without AIO, VBox uses a generic POSIX backend, > which is based on pthread, I think. > At least VirtualBax without AIO has some serious performance issues without AIO. At least a Win7 guest does on certain operations. I would really prefer better aio values. I don't recall who suggested those to me, but I took them and made them more reasonable, but I am sure they are not close to optimal and I don't understand their use well enough to get them right. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: 13.0 RC4 might be delayed
On Sat, Mar 27, 2021 at 5:07 AM dmilith . wrote: > It may not only be Virtualbox, but also happens under Vmware VMs. > > I use Vmware Fusion 7 pro as my software build-host on top of my Mac > Pro for years now, but I can't build much with 13.0 cause regular > build processes (like sed, awk, grep, zsh) turn into zombies randomly. > Example shot from my private CI from yesterday: > http://s.verknowsys.com/12f14b0350ee3baeb8f153cd48764bc8.png > > The issue doesn't happen on 12.2, 12.1, 12.0 or older releases. > > I reported this issue (I'm testing it since 13-alpha) here: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253718 > > In RC3 it feels it got even worse and happens even more often… It's a > critical release blocker if you ask me… > > kind regards > Daniel > > On 27/03/2021, David G Lawrence via freebsd-current > wrote: > >> On Fri, Mar 26, 2021 at 1:01 PM Graham Perrin > >> wrote: > >> > >> > On 26/03/2021 03:40, The Doctor via freebsd-current wrote: > >> > > ??? if people are having issues with ports like ??? > >> > > >> > If I'm not mistaken: > >> > > >> > * 13.0-RC3 seems to be troublesome, as a guest machine, with > >> > emulators/virtualbox-ose 6.1.18 as the host > >> > > >> > * no such trouble with 12.0-RELEASE-p5 as a guest. > >> > > >> > I hope to refine the bug report this weekend. > >> > > >> > >> Had nothing but frequent guest lockups on 6.1.18 with my Win7 system. > >> That > >> was right after 6.1.18 was put into ports. Fell back to legacy (v5) and > >> will try again shortly to see if it's any better. > > > > Kevin, > > > >Make sure you have these options in your /etc/sysctl.conf : > > > > vfs.aio.max_buf_aio=8192 > > vfs.aio.max_aio_queue_per_proc=65536 > > vfs.aio.max_aio_per_proc=8192 > > vfs.aio.max_aio_queue=65536 > > > >...otherwise the guest I/O will random hang in VirtualBox. This issue > > was > > mitigated in a late 5.x VirtualBox by patching to not use AIO, but the > > issue > > came back in 6.x when that patch wasn't carried forward. > > > > -DG > > ___ > > 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" > > > > > -- > -- > Daniel Dettlaff > Versatile Knowledge Systems > verknowsys.com > My problem was resolved when I spent the time to read the pkg-message in the port. It is running just fine, now. Somehow I missed David's message, as well. Not good. Unfortunate that the patches to turn off AIO did not make it into V6. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: VirtualBox 6.1.18⋯, Windows (was: 13.0 RC4 might be delayed)
Host is FreeBSD 13-STABLE.Guest is Win 7 which I depend on for Quicken. I also use it to access a bank account at a bank that refuses access from any OS other than Windows or MacOS. I managed to access it for about a year by having Firefox lie and claim to be Windows, but that stopped working. They make the almost humorous claim that only Windows and MacOS are adequately secure. At this point I have no idea if the issue is with VirtualBx or FreeBSD, but, after seeing more details of your problem, I doubt mine is related. I really suspect it's VirtualBox, so I will drop out of this discussion as it appears that I don't have an issue with it. After some more work on it, I'll open a ticket with emulators@. Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 On Fri, Mar 26, 2021 at 7:23 PM Graham Perrin wrote: > On 26/03/2021 21:55, Kevin Oberman wrote: > > On Fri, Mar 26, 2021 at 1:01 PM Graham Perrin > <mailto:grahamper...@gmail.com>> wrote: > > > > > > If I'm not mistaken: > > > > … > > > > Had nothing but frequent guest lockups on 6.1.18 with my Win7 system. > > That was right after 6.1.18 was put into ports. Fell back to legacy > > (v5) and will try again shortly to see if it's any better. > > Windows 7 guest or host? > > For me, Windows 10 20H2 guest is rock solid. > > % pkg info -x virtualbox > virtualbox-ose-6.1.18 > virtualbox-ose-kmod-6.1.18_1 > % freebsd-version -kru > 14.0-CURRENT > 14.0-CURRENT > 14.0-CURRENT > % uname -a > FreeBSD mowa219-gjp4-8570p 14.0-CURRENT FreeBSD 14.0-CURRENT #90 > main-n245648-66f138563be: Thu Mar 25 08:00:54 GMT 2021 > root@mowa219-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG > amd64 > % > > ___ 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: 13.0 RC4 might be delayed
On Fri, Mar 26, 2021 at 1:01 PM Graham Perrin wrote: > On 26/03/2021 03:40, The Doctor via freebsd-current wrote: > > … if people are having issues with ports like … > > If I'm not mistaken: > > * 13.0-RC3 seems to be troublesome, as a guest machine, with > emulators/virtualbox-ose 6.1.18 as the host > > * no such trouble with 12.0-RELEASE-p5 as a guest. > > I hope to refine the bug report this weekend. > Had nothing but frequent guest lockups on 6.1.18 with my Win7 system. That was right after 6.1.18 was put into ports. Fell back to legacy (v5) and will try again shortly to see if it's any better. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: On 14-CURRENT: no ports options anymore?
On Sat, Mar 13, 2021 at 2:51 PM Dan Mahoney (Ports) wrote: > If this isn’t at least in /usr/ports/UPDATING it sure should be. > > -Dan > Ditto! While it did not take me long to discover that the ncurses shareable had bumped the version, I wasted a lot of time rebuilding ports one by one. At least a heads-up would have been nice. The way to do this is unclear, though, as it was a base library update. I assume that it only bit those running current or 13. Those running 13-STABLE, as I was, had no warning. I'm not sure a note in UPDATING would have been appropriate, but a post to stable@ and current@ would have been nice. Or, did I miss them? This would also be made VERY clear in the 13.0 Release Notes. I suspect installing misc/compat12x would have worked. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: Panic with wifi + usb in latest FreeBSD-current
Small correction... My rtwn is running at 1 MB, not Mb. I have two tools watching the network, one does bits and the other bytes. Still, performance is really bad. Can't say whether it's the driver or something else, but I'll be gathering data as I can between reboots of my current system. Sorry for the bogus information. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 On Mon, Sep 14, 2020 at 9:52 AM Kevin Oberman wrote: > On Sun, Sep 13, 2020 at 11:31 PM Adrian Chadd > wrote: > >> On Sun, 13 Sep 2020 at 22:34, Warner Losh wrote: >> >> > >> > >> > On Sun, Sep 13, 2020, 11:29 PM Adrian Chadd >> > wrote: >> > >> >> Yeah, this was also reported in #freebsd-wireless today. >> >> >> >> Is there a lock being held in the rtwn path that shouldn't be? >> >> >> > >> > I'll check in the morning... this was like the 20th thing to go wrong >> this >> > weekend, so I copied the panic down, send the email and grabbed a beer >> and >> > turned it off... >> > >> >> Ok. I checked the driver and the usb stack; nothing in the change lists >> obviously stands out to me at 11pm on a Sunday. >> >> Can you see if any locks are held? or an epoch? Something smells fishy. >> (defining EPOCH_TRACE will dump the list of epochs, if I'm reading the >> subr_sleepqueue.c code correctly.) >> >> Ok, so, since I dug a bit more on a hunch, I bet the NET epoch is being >> held - it's grabbed in rtwn_bulk_rx_callback, and rtwn_rx_common is >> reading >> some registers as part of processing the receive queue. I bet that act of >> reading registers over blocking USB is causing things to explode. >> >> If it is net epoch then we're going to have to think of a better design >> pattern here to migrate all of these here wifi drivers to, because I >> guarantee you they're all behaving poorly in this newer world order. >> >> >> >> Thanks, >> >> >> -adrian >> > While I have not seen panics, performance of my rtwn has simply cratered. > Trying to move files to my new laptop, which has an rtwn, it crawls at > about 1.5 Mbps. Before I built an updated kernel, I was seeing 60M. Of > course, this is complicated by the continual kernel lockups I keep getting, > so I really didn't think much about it until I saw Warner's note. > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkober...@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > ___ 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: Panic with wifi + usb in latest FreeBSD-current
On Sun, Sep 13, 2020 at 11:31 PM Adrian Chadd wrote: > On Sun, 13 Sep 2020 at 22:34, Warner Losh wrote: > > > > > > > On Sun, Sep 13, 2020, 11:29 PM Adrian Chadd > > wrote: > > > >> Yeah, this was also reported in #freebsd-wireless today. > >> > >> Is there a lock being held in the rtwn path that shouldn't be? > >> > > > > I'll check in the morning... this was like the 20th thing to go wrong > this > > weekend, so I copied the panic down, send the email and grabbed a beer > and > > turned it off... > > > > Ok. I checked the driver and the usb stack; nothing in the change lists > obviously stands out to me at 11pm on a Sunday. > > Can you see if any locks are held? or an epoch? Something smells fishy. > (defining EPOCH_TRACE will dump the list of epochs, if I'm reading the > subr_sleepqueue.c code correctly.) > > Ok, so, since I dug a bit more on a hunch, I bet the NET epoch is being > held - it's grabbed in rtwn_bulk_rx_callback, and rtwn_rx_common is reading > some registers as part of processing the receive queue. I bet that act of > reading registers over blocking USB is causing things to explode. > > If it is net epoch then we're going to have to think of a better design > pattern here to migrate all of these here wifi drivers to, because I > guarantee you they're all behaving poorly in this newer world order. > > > > Thanks, > > > -adrian > While I have not seen panics, performance of my rtwn has simply cratered. Trying to move files to my new laptop, which has an rtwn, it crawls at about 1.5 Mbps. Before I built an updated kernel, I was seeing 60M. Of course, this is complicated by the continual kernel lockups I keep getting, so I really didn't think much about it until I saw Warner's note. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: Livelock on recent current
On Fri, Sep 11, 2020 at 1:01 AM wrote: > > > On 09.09.20 06:18, Kevin Oberman wrote: > > > > I am seeing a problem since I moved to current on my laptop this > week. > > > > It's odd as it is linked to the keyboard. As long as the keyboard is > > > > active, everything is fine, but if the keyboard is not used, after a > > > > few minutes, it locks up and gets very hot. The system may be busy > > > > or idle. The system seems completely locked. It does not respond in > > > > the network and the display, X or just vt is frozen. The only factor > > > > is use > > of the > > > keyboard. > > > > I'm actually very happy someone else ran into this too! I have a Lenovo > T490 > > (azerty edition, yeah I known ...) I found it incredible hard to > describe, > but i > > have the exact same problem. > > I categorized it as "random system freezes", but now that you say its > related to > > keyboard interaction it makes sense when I observe the lock. > > > > System locks up when it happens and the fan ramps up AFTER the dead lock. > > I'm pretty sure the getting "hot" symptom is caused by the deadlock and > not a > > symptom of the deadlock. > > Maybe a very important factor, the issue is not present in STABLE-12, I > downgraded previous week to verify this. > > > > > > > > > Reminds me of this bug: > > > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225341 > > > > I am also using a non default keyboard layout, as described in the bug > above. > > I'll probably try the patch in the coming weekend to see if it helps. > > > > > > > > I've been experiencing similar hangs when that timer in atkbd is > enabled. > > It > > > doesn't seem to happen in the default keyboard configuration, though. > > > > > > -Jan I'm happy to see that I am not crazy! This is mostly anecdotal. The freezes have occurred regularly, without question, but the details are not statistically verified. This is based on my perceptions. The only things I am really sure of is that the system is unusable on head and runs well on 12.1-Release. This system has a rather new Intel GPU, the Comet Lake, and is only supported on head with drm-devel-kmod, so moving back to 12.1 is not an option. I am curious what processor is on the T490. I am using the default keyboard layout. On terminal sessions (vt), when the keyboard is idle. I have had the system run for a couple of hours or longer with no problems. To get bigger ports to build, I usually switch to another vty and keep that one fairly busy. It will freeze when no vty is active, but as long as any is active every minute or less. I have had freezes in under a minute, but rarely. Moving on to other possibly related (or not) issues: When running on X (MATE), it may freeze whether the keyboard is active or not. OTOH, it seems to freeze less often. I've had X lock up mid-word but also run for 15 or more minutes. It eventually does freeze, but I don't think I've ever gone more than 10 minutes on an idle keyboard without a freeze without X running. Switching to a vty and keeping it fairly active still seems to keep the system alive while X is being used. X is performing very poorly. If the processors are busy, say by building a port, screen updates are very slow, often pausing for several seconds. Expose events seem to often redraw all windows which is very annoying. Several times I thought the system was frozen only to suddenly have the screen update and everything be normal, again. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: Livelock on recent current
On Wed, Sep 9, 2020 at 3:01 AM Thomas Mueller wrote: > > I am seeing a problem since I moved to current on my laptop this week. > It's > > odd as it is linked to the keyboard. As long as the keyboard is active, > > everything is fine, but if the keyboard is not used, after a few minutes, > > it locks up and gets very hot. The system may be busy or idle. The system > > seems completely locked. It does not respond in the network and the > > display, X or just vt is frozen. The only factor is use of the keyboard. > > > I'm not sure what information I might collect. > > > The system is a ThinkPad L15 with 4GN of DRAMM (more on order) . > > FreeBSD 13.0-CURRENT #2 r365481M: Tue Sep 8 20:16:02 PDT 2020 > > root@ptavv:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 > > FreeBSD ptavv 13.0-CURRENT FreeBSD 13.0-CURRENT #2 r365481M: Tue Sep 8 > 20:16:02 PDT 2020 > > root@ptavv:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG > amd64 > > Intel(R) Core(TM) i5-10210U CPU (Crystal Lake) > > > Kevin Oberman, Part time kid herder and retired Network Engineer > > Overheating, maybe? > > I can see CPU temperature with "envstat" (NetBSD) or > sysctl -a | grep "temperature" (FreeBSD) : > don't know how Linux does it. > > Is there any way you could run > sysctl -a | grep "temperature" > at one- or two-minute intervals, perhaps on a different virtual terminal? > > I've heard of laptops getting hot, but that was not specifically connected > to keyboard inactivity. > > Tom > On FreeBSD on Intel, just load coretemp.ko and it's in dev.cpu.?.temperature, where ? is the CPU. When running my desktop, I have it continuously displayed with the gkrellm2 system display. Since it will fail when the system is idle, I don't think it gets hot until after the lock-up, but I'll confirm it when I get back to that system later today. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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"
Livelock on recent current
I am seeing a problem since I moved to current on my laptop this week. It's odd as it is linked to the keyboard. As long as the keyboard is active, everything is fine, but if the keyboard is not used, after a few minutes, it locks up and gets very hot. The system may be busy or idle. The system seems completely locked. It does not respond in the network and the display, X or just vt is frozen. The only factor is use of the keyboard. I'm not sure what information I might collect. The system is a ThinkPad L15 with 4GN of DRAMM (more on order) . FreeBSD 13.0-CURRENT #2 r365481M: Tue Sep 8 20:16:02 PDT 2020 root@ptavv:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 FreeBSD ptavv 13.0-CURRENT FreeBSD 13.0-CURRENT #2 r365481M: Tue Sep 8 20:16:02 PDT 2020 root@ptavv:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 Intel(R) Core(TM) i5-10210U CPU (Crystal Lake) -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: Is pkg site forbidden by brower?
On Sat, Sep 5, 2020 at 8:04 PM Yoshihiro Ota wrote: > Hi, > > Is "403 Forbidden" an intended response for a brower access to > http://pkg.freebsd.org/FreeBSD:12:i386/ nowdays? > > I used to see available packages with a brower and decided which one to > use. > How can I find distributions like "latest", "release_X", etc? > > Hiro Does https://pkg-status.freebsd.org/builds?jailname=121amd64 have what you want? I can't believe that there is no way to see a log of failed builds, but I can only see the new failures and no information on previous builds. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055 ___ 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: Please check the current beta git conversions
On Tue, Sep 1, 2020 at 7:38 PM Thomas Mueller wrote: > from Ed Maste: > > > > Any guidance on amount of diskspace and how long it takes to clone the > repo ? > > > I see just over 3GB in my clone, including about 2.5GB in the .git > directory. > > > If you have only one checkout git will require a bit more disk space > > than svn. However, if you have two or more working trees (say, vanilla > > FreeBSD and multiple work-in-progress trees, or head and stable > > branches, etc.) using "git worktree" will share the .git directory and > > in total will occupy less space than the equivalent in svn. > > > I'd expect clones to take minutes, although cgit-beta is running on a > > lower spec jail host and might have trouble if many people are cloning > > at the same time. > > 2.5 GB in .git directory sounds crazy and incomprehensible to me. > > Only src tree I would be interested in now is HEAD (13-current), though I > would also want the ports and doc trees. Would that mollify the diskspace > bloat? > > I had trouble with the ethernet and wireless network drivers in FreeBSD 12 > and 13-current, but there subsequently was a post on a big improvement to > the network drivers for HEAD but not 12-stable. > > So I am abandoning FreeBSD 12.x . > > Hopefully I could update 13-current from within 13-current where I have no > internet access but could use git from NetBSD, where I also have svn. > > Tom > Not really much different from subversion. .svn in /usr/sys is also 2.5G, at least for 12.1. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: slow USB 3.0 on -current
On Sun, Jul 12, 2020 at 2:55 PM John-Mark Gurney wrote: > Hans Petter Selasky wrote this message on Sun, Jul 12, 2020 at 09:57 +0200: > > On 2020-07-12 00:44, John-Mark Gurney wrote: > > > Hello, > > > > > > I'm having issues getting good ethernet performance from a USB ethernet > > > adapter (ure) under FreeBSD on an HP EliteDesk 705 G2 Mini[1]. It's an > > > AMD PRO A10-8700B based system using the AMD A78 FCH chipset. > > > > > > Under FreeBSD -current (r362596), 12.1-R and 11.4-R, the RealTek USB > > > adapter only gets around 10MB/sec performance. During the transfer, > > > the CPU usage is only around 3-5%, so it's definitely not CPU bound. > > > > > > I have tested Windows 10 and NetBSD 9.0 performance, and both provide > > > 100MB/sec+ w/o troubles. > > > > > > I have attached dmesg from both FreeBSD -current and NetBSD 9.0. > > > > > > Any hints on how to fix this? > > > > > > This may be related, but I'm also having issues w/ booting when I have > > > both a SD USB 2.0 card reader AND the ure plugged into USB 3.0 ports. > > > > > > If I move the SD card reader to USB 2.0, the umass device will attach > > > and work. I have also attached a clip of the dmesg from that > > > happening. > > > > > > Has anyone else seen this issue? Ideas or thoughts on how to resolve > > > the performance issues? > > > > Can you check the output from ifconfig. What is the actual link speed. I > > suspect it has something to do with the MII bus code/implementation. > > ifconfig is reporting it's 1000baseT. > > > Also check output from "vmstat -i" during usage to see if the number of > > IRQ/s is low. > > Not sure what is considered low, but I'm seeing consistently around > 7800 int/s for xhci0. > > -- > John-Mark Gurney Voice: +1 415 225 5579 > This is just for clarification, but is 'MB' MBytes? In the networking world that is what it would mean, but the context leads me to think that you mean Mbits. It's also possible that some numbers are in bits and some in Bytes, causing real confusion. I'm sure that 1000baseT is bits, of course. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: Undeletable files after kyua test runs
On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling wrote: > Hi, > > I recently stumbled across undeletable files that are generated by kyua > test runs, > for example > > -rwxr-xr-x 1 root wheel 0 May 9 13:10 > /tmp/kyua.aB4q62/8676/work/fileforaudit > > I haven't yet identified the test that generate those files, but it is > impossible > to delete them. I have clear_tmp_enable="YES" set in the /etc/rc.conf, but > on every boot the system argues that these file aren't deletable. > I tried to 'rm -rf' them by hand but, even this wasn't possible. I have > looked for > any extend attributes, but I didn't find any. > > Has anyone an idea how this is possible and may how these files can be > deleted? > > --Gordon Have you done 'ls -o' to check for flags like schg? -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: Problem compiling Chromium
On Sun, Jun 7, 2020 at 9:49 AM bob prohaska wrote: > Don't know about AMD, but on ARM failures that resemble this are > common. In some cases the actual error message is tens or a hundred > lines prior to the last make output. > > If you search for the string Error: or maybe error: does anything > show up? Including the colon : helps to reduce irrelevant hits. > > Good luck, > > bob prohaska > The correct way to do this is to build aagain without doing a make clean and with MAKE_JOBS_UNSAFE. This will use only a single build stream and the error(s) will be at the end. The instructions after the failure mention this, but not why. (Actually there are a couple of reasons.) Doing a make clean will result in a build from the beginning and will take a very, very long time in a single stream. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > On Sun, Jun 07, 2020 at 04:27:24PM +, Filippo Moretti wrote: > > Good evening, FreeBSD > sting 13.0-CURRENT FreeBSD 13.0-CURRENT #2 r361787: Sun Jun?? 7 15:02:09 > CEST 2020 root@sting:/usr/obj/usr/src/amd64.amd64/sys/STING?? > amd64 > > > > the build fails with the following > message/common/extensions/api/action.json > ../../chrome/common/extensions/api/browser_action.json > ../../chrome/common/extensions/api/browsing_data.json > ../../chrome/common/extensions/api/extension.json > ../../chrome/common/extensions/api/idltest.idl > ../../chrome/common/extensions/api/page_action.json > ../../chrome/common/extensions/api/top_sites.json > > ninja: build stopped: subcommand failed. > > ===> Compilation failed unexpectedly. > > Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure > to > > the maintainer. > > *** Error code 1 > > > > Stop. > > make: stopped in /usr/ports/www/chromium > > > > ===>>> make build failed for www/chromium > > ===>>> Aborting update > > > > I enclose the list of packages installedsincerelyFilippo > > > > ___ > > 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" > ___ 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: sort.core error doing installworld on Current.
On Thu, Apr 16, 2020 at 12:39 PM Kevin Oberman wrote: > So you some how had a sort core dump sitting in > /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir. The questions, how > did get there? I'd take a look at the date on the file and, it it is older > than the buildworld, just assume that it was left-over garbage. In either > case, you can delete it and do another installworld. > > That should most likely fix things, but, if the buildworld or installworld > had a crash of sort(1) that left the file, further investigation might be > needed. Re-making the zoneinfo would help track it down should this be a re > al bug, but it's my uneducated guess that it's not. > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkober...@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > Please forgive that awful post! I missed a part of your message by laziness. It's odd that the error of sort(1) crashing was not caught by the script. Clearly, sort should NOT crash! Again, a re-build of zoneinfo might catch something. Looking at the core might tell you which "sort" was involved... the one you just built or the one in the base system. This could be just a FOTU, but I would not bet on it. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > > On Thu, Apr 16, 2020 at 11:49 AM Johan Hendriks > wrote: > >> I have a machine running FreeBSD head. >> rev 13.0-CURRENT #11 r360008 >> >> This is a quite powerful machine, so i thought it was a good idea to let >> that server do the build and for my virtualbox machine i can use the >> powerful machine to do a installword over NFS. >> >> But when i did the make installworld step the client so to say gives an >> error. >> >> install -o root -g wheel -m 444 >> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/Zulu >> /usr/share/zoneinfo/Zulu >> install -o root -g wheel -m 444 >> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/posixrules >> /usr/share/zoneinfo/posixrules >> install -o root -g wheel -m 444 >> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core >> /usr/share/zoneinfo/sort.core >> install: /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core: >> Permission denied >> *** Error code 71 >> >> Stop. >> bmake[5]: stopped in /usr/src/share/zoneinfo >> *** Error code 1 >> >> Stop. >> bmake[4]: stopped in /usr/src/share >> *** Error code 1 >> >> Stop. >> bmake[3]: stopped in /usr/src >> *** Error code 1 >> >> Stop. >> bmake[2]: stopped in /usr/src >> *** Error code 1 >> >> Stop. >> bmake[1]: stopped in /usr/src >> *** Error code 1 >> >> Stop. >> make: stopped in /usr/src >> .ERROR_TARGET='installworld' >> .ERROR_META_FILE='' >> .MAKE.LEVEL='0' >> MAKEFILE='' >> .MAKE.MODE='normal' >> _ERROR_CMD='.PHONY' >> .CURDIR='/usr/src' >> .MAKE='make' >> .OBJDIR='/usr/obj/usr/src/amd64.amd64' >> .TARGETS='installworld' >> DESTDIR='' >> LD_LIBRARY_PATH='' >> MACHINE='amd64' >> MACHINE_ARCH='amd64' >> MAKEOBJDIRPREFIX='/usr/obj' >> MAKESYSPATH='/usr/src/share/mk' >> MAKE_VERSION='20181221' >> PATH='/sbin:/bin:/usr/sbin:/usr/bin' >> SRCTOP='/usr/src' >> OBJTOP='/usr/obj/usr/src/amd64.amd64' >> >> It looks likes sort coredumps in the usr/share/zoneinfo part of the base. >> As it has no permission on the NFS share it errors out. >> On the server itself, the installworld goes well, but it leaves a >> sort.core file behind in /usr/share/zoneinfo >> >> cd /usr/share/zoneinfo >> ls -al >> >> ___ 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: sort.core error doing installworld on Current.
ai you some how had a sort core dump sitting in
/usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir. The questions, how
did get there? I'd take a look at the date on the file and, it it is older
than the buildworld, just assume that it was left-over garbage. In either
case, you can delete it and do another installworld.
That should most likely fix things, but, if the buildworld or installworld
had a crash of sort(1) that left the file, further investigation might be
needed. Re-making the zoneinfo would help track it down should this be a
rel bug, but it's my uneducated guess that it's not.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
On Thu, Apr 16, 2020 at 11:49 AM Johan Hendriks
wrote:
> I have a machine running FreeBSD head.
> rev 13.0-CURRENT #11 r360008
>
> This is a quite powerful machine, so i thought it was a good idea to let
> that server do the build and for my virtualbox machine i can use the
> powerful machine to do a installword over NFS.
>
> But when i did the make installworld step the client so to say gives an
> error.
>
> install -o root -g wheel -m 444
> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/Zulu
> /usr/share/zoneinfo/Zulu
> install -o root -g wheel -m 444
> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/posixrules
> /usr/share/zoneinfo/posixrules
> install -o root -g wheel -m 444
> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core
> /usr/share/zoneinfo/sort.core
> install: /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core:
> Permission denied
> *** Error code 71
>
> Stop.
> bmake[5]: stopped in /usr/src/share/zoneinfo
> *** Error code 1
>
> Stop.
> bmake[4]: stopped in /usr/src/share
> *** Error code 1
>
> Stop.
> bmake[3]: stopped in /usr/src
> *** Error code 1
>
> Stop.
> bmake[2]: stopped in /usr/src
> *** Error code 1
>
> Stop.
> bmake[1]: stopped in /usr/src
> *** Error code 1
>
> Stop.
> make: stopped in /usr/src
> .ERROR_TARGET='installworld'
> .ERROR_META_FILE=''
> .MAKE.LEVEL='0'
> MAKEFILE=''
> .MAKE.MODE='normal'
> _ERROR_CMD='.PHONY'
> .CURDIR='/usr/src'
> .MAKE='make'
> .OBJDIR='/usr/obj/usr/src/amd64.amd64'
> .TARGETS='installworld'
> DESTDIR=''
> LD_LIBRARY_PATH=''
> MACHINE='amd64'
> MACHINE_ARCH='amd64'
> MAKEOBJDIRPREFIX='/usr/obj'
> MAKESYSPATH='/usr/src/share/mk'
> MAKE_VERSION='20181221'
> PATH='/sbin:/bin:/usr/sbin:/usr/bin'
> SRCTOP='/usr/src'
> OBJTOP='/usr/obj/usr/src/amd64.amd64'
>
> It looks likes sort coredumps in the usr/share/zoneinfo part of the base.
> As it has no permission on the NFS share it errors out.
> On the server itself, the installworld goes well, but it leaves a
> sort.core file behind in /usr/share/zoneinfo
>
> cd /usr/share/zoneinfo
> ls -al
> -r--r--r-- 1 root wheel 118 Apr 16 20:25 Zulu
> -r--r--r-- 1 root wheel3519 Apr 16 20:25 posixrules
> -r--r--r-- 1 root wheel 8982528 Apr 16 20:25 sort.core
> -r--r--r-- 1 root wheel 19424 Apr 16 20:25 zone.tab
> -r--r--r-- 1 root wheel 17955 Apr 16 20:25 zone1970.tab
>
> my src.conf file looks like this
> WITHOUT_BLUETOOTH=yes
> WITHOUT_CALENDAR=yes
> WITHOUT_DICT=yes
> WITHOUT_GAMES=yes
> WITHOUT_I4B=yes
> WITHOUT_IPFILTER=yes
> WITHOUT_IPX=yes
> WITHOUT_LPR=yes
> WITHOUT_PROFILE=yes
> WITHOUT_SENDMAIL=yes
> WITHOUT_SHAREDOCS=yes
> WITHOUT_WIRELESS=yes
> WITHOUT_HAST=yes
> WITHOUT_LLVM_TARGET_{MIPS,POWERPC,SPARC,RISCV}= YES
> WITHOUT_LIB32=yes
>
> in /etc/make.conf i have the following
> MALLOC_PRODUCTION=yes
> BATCH_DELETE_OLD_FILES= yes
> CUPS_OVERWRITE_BASE=yes
>
>
> What can i do about this?
>
> Thank you for your time.
>
>
> ___
> 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: .debug files, skip?
On Fri, Apr 10, 2020 at 4:07 AM Andriy Gapon wrote:
> On 10/04/2020 09:55, Alexey Dokuchaev wrote:
> > On Sun, Apr 05, 2020 at 07:41:38PM -0400, Ed Maste wrote:
> >> On Sun, 5 Apr 2020 at 08:32, Jeffrey Bouquet wrote:
> >>>
> >>> A recent build[k,w] [ ** stable 12.1] and many .debug files I'd
> >>> like to skip if poss. A knob?
> >>
> >> Yes, from src.conf(5):
> >> WITHOUT_DEBUG_FILES
> >> Set to avoid building or installing standalone debug
> >> files for each executable binary and shared library.
> >
> > I have "MK_DEBUG_FILES=no" in /etc/make.conf, which one is more correct?
>
> WITHOUT_.
>
> See bsd.mkopt.mk.
>
> # Users should generally define WITH_FOO or WITHOUT_FOO, but the build
> # system should use MK_FOO={yes,no} when it needs to override the
> # user's desires or default behavior.
>
> --
> Andriy Gapon
>
Or see src.conf man page which states:
The values of variables are ignored regardless of their setting; even if
they would be set to “FALSE” or “NO”. The presence of an option causes it
to be honored by make(1).
Kevin Oberman, Network Engineer, Retired
___
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: New Xorg - different key-codes
On Wed, Mar 11, 2020 at 1:51 PM Greg Rivers wrote: > On Wednesday, 11 March 2020 13:53:45 CDT Peter Jeremy wrote: > > On 2020-Mar-11 10:29:08 +0100, Niclas Zeising > wrote: > > >This has to do with switching to using evdev to handle input devices on > > >FreeBSD 12 and CURRENT. There's been several reports, and suggested > > >solutions to this, as well as an UPDATING entry detailing the change. > > > > The UPDATING entry says that it's switched from devd to udev. There's no > > mention of evdev or that the keycodes have been roto-tilled. It's > basically > > a vanilla "things have been changed, see the documentation" entry. Given > > that entry, it's hardly surprising that people are confused. > > > Indeed, the change has been a bit inconvenient and time consuming to deal > with. > > But I don't think we should let this overshadow the dedication and very > hard work that Niclas and the graphics team have done and continue to do to > keep FreeBSD relevant on the desktop. I for one am very grateful for that. > > -- > Greg > And the people involved have been very active in helping people resolve the problems. In particular, Michael Gmelin had been very helpful in providing a workaround for the failure of the brightness control buttons on my rather ancient T520. He has also provided a solution for the failure of the volume control buttons that I've had since the last update to MATE. I have yet to try it as something else (no idea what) had magically fixed this after a couple of months of them not working. I can't figure out what "fixed" this, but it just started working a couple of weeks ago. Until/unless it fails, I'm not touching things. Also, my apologies to Michael as I have not responded to him with a status update for WAY too long. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: The support for AMD graphics and how freebsd hardware support
On Tue, Sep 24, 2019 at 8:56 PM wrote: > developed > Reply-To: > X-Priority: 1 > Importance: high > Disposition-Notification-To: > X-Confirm-Reading-To: > Return-Receipt-To: > Hello, > 1. Does freebsd current and freebsd stable 12 fully support all features > of AMD Radeon RX 5700, Vega and RX 500 series including the hardware video > decoding features? > AMD Radeon support is probably the weakest of the three main GPU providers, but someone else may be able to confirm the status of those particular units. You would be far more likely to get information on X related issues by sending to the x...@freebsd.org mailing list. > > 2. From website, https://wiki.freebsd.org/Graphics#AMD_Graphics, it says > "Update drm-stable to Linux 4.16 for FreeBSD 12.0". Does it mean freebsd > hardware support or drivers are copied or translated from linux kernel > codes? > They are derived with minimal changes from the Linux code. FreeBSD has kernel modules that provide kernel support. These modules are not part of FreeBSD. They are GPL licensed, so are built as a port, drm-kmod and a group of slave ports that are for specific kernel versions. > > 3. How are freebsd hardware support really developed? In linux kernel > mailing list, there are over 2,000 emails per day from hardware vendors > such as Intel, AMD, Huawei, Samsung, Sony submitting patches or hardware > drivers. What about BSD? I did not find any such equivalence in freebsd > after googling. > Only Nvidia provides any significant support for its products on FreeBSD and, as a result, almost all other X code is identical or very nearly identical to the Linux code. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: fusefs & ntfs-3g
On Sun, Sep 8, 2019 at 4:46 PM Michael Butler wrote: > On 9/8/19 7:09 PM, Alan Somers wrote: > > On Sun, Sep 8, 2019 at 5:00 PM Clay Daniels Jr. < > clay.daniels...@gmail.com> > > wrote: > > > >> I want to view my Windows C: drive on ata0p4. > >> This is what I have: > [...] > >> root@bsd13:/home/clay # ntfs-3g -o default_permissons /dev/ada0p4 /mnt > >> * Windows is hibernated, refused to mount. > >> The disk contains an unclean file system (0, 0). > >> Metadata kept in Windows cache, refused to mount. > >> Falling back to read-only mount because the NTFS partition is in an > unsafe > >> state. Please resume and shutdown Windows fully (no hibernation > >> or fast restarting. > >> > >> I'm having a roadblock here. Maybe someone knows the answer. > >> > > > > I'm assuming that you already ascertained that the Windows file system > was > > in fact clean? If so, then this sounds like a problem with fusefs-ntfs, > > not with fuse in general. I've CC'd its maintainer. He may be able to > > help you. > > -Alan > > Windows-10 has a changed default; it does the equivalent of hibernation > to facilitate "fast start". ntfs-3g won't touch a partition for writing > in that mode :-( > > If I recall correctly, there is a setting you must change from in > Windows under control panel -> system -> power and sleep. From there you > should be able to disable the "fast start" option and, after shutting > down, ntfs-3g will allow a read/write mount, > I can confirm this. It is documented, but not obvious. You ave two choices: 1. Change the system setting, more or less as Michael suggests. I'm away from my only W10 system, so I can't check the exact details. 2. Force a full shutdown by starting a command window and entering "shutdown /s /f /t 0". This is a one-time full shutdown. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: 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 Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > 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. 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 to install and test FUSE? I kind of like the no-x console & the > > Xterminal window too, and dabble with clang cc (strictly C, no C++) and > > Python too. Let me know. > > > > Clay Daniels > > > > On Thu, Aug 8, 2019 at 1:36 PM 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: > > > * Optional kernel-side permissions checks (-o default_permissions) > > > * Implement VOP_MKNOD, VOP_BMAP, and VOP_ADVLOCK > > > * Allow interrupting FUSE operations > > > * Support named pipes and unix-domain sockets in fusefs file systems > > > * Forward UTIME_NOW during utimensat(2) to the daemon > > > * kqueue support for /dev/fuse > > > * Allow updating mounts with "mount -u" > > > * Allow exporting fusefs file systems over NFS > > > * Server-initiated invalidation of the name cache or data cache > > > * Respect RLIMIT_FSIZE > > > * Try to support servers as old as protocol 7.4 > > > > > > Performance enhancements include: > > > > > > * Implement FUSE's FOPEN_KEEP_CACHE and FUSE_ASYNC_READ flags > > > * Cache file attributes > > > * Cache lookup entries, both positive and negative > > > * Server-selectable cache modes: writethrough, writeback, or uncached > > > * Write clustering > > > * Readahead > > > * Use counter(9) for statistical reporting > > > > > > Now would be a good time for the community to test it. If you are > > > BCCed to this email, it's because you maintain a FUSE-related port. > > > Please test your port on the latest FreeBSD CURRENT image and let me > > > know if you have any problems or find any bugs. > > > > > > Even if you don't maintain a FUSE port, you can still help. If you > > > use current and commonly use any FUSE file systems, please try them > > > out after upgrading to the latest image. > > > > > > Additionally, the following FUSE-related ports don't have maintainers. > > > If you use one of them, or know somebody who does, please test them on > > > current, and consider adopting the port: > > > deskutils/kdeconnect-kde > > > devel/gvfs > > > devel/py-fusefs > > > sysutils/fusefs-afuse > > > sysutils/fusefs-chironfs > > > sysutils/fusefs-cryptofs > > > sysutils/fusefs-funionfs > > > sysutils/fusefs-fusepak > > > sysutils/fusefs-httpfs > > > sysutils/fusefs-s3backer > > > sysutils/fusefs-sqlfs > > > sysutils/fusefs-zip > > > sysutils/p5-Brackup > > > sysutils/p5-Fuse > > > > > > 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! > > > -Alan > > > ___ > > > 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" > > > ___ > 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: kernel config question
On Wed, Jan 2, 2019 at 5:02 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. 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 > Some ports may require compat ports. E.g. plexmediaserver requires compat9x. Oddly, compat9x requires compat10x, so I need 9, 10, and 11. Now that 10 is EOL, I wish Plex would start building their blobs against 11. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: drm changes and updating to 12.0
On Sun, Nov 4, 2018 at 12:15 PM Niclas Zeising wrote: > On 11/4/18 8:29 PM, Robert Huff wrote: > > > > I have a set of older machines (e.g. AMD Phenom II, Radeon HD3300 > > gpu) which will be updated from 11. to 12.0 once 12 is out > > and the initial round of bugs are squashed. > > One system is being done now, to allow time to catch any major > > problems and then plan the update process. > > Looking at src/UPDATING, the only thing I don't understand is the > > whole drm-kmod change. Is there an authoritative write-up on what's > > going on, how to choose the right drivers for my hardware, and how to > > do this from source without forcing a fresh install? > > > > We are working on better documentation for this, but the main highlights > are: In most cases graphics/drm-kmod should suffice, especially on > somewhat modern hardware. You can also install any of the drm-*-kmod > ports directly, if you want a specific version. In general graphics > hardware older than from 2013 requires drm-legacy-kmod instead. > drm-kmod will also install drm-legacy-kmod on i386. > > The same drivers in drm-legacy-kmod is also available in base on 12, so > you can use the base drivers. This is deprecated however, and not the > case for 13-CURRENT. > > You can install the drivers either from pkg, if you are using the > GENERIC kernel, or build from ports if you have a customized kernel or > if you are tracking for instance 12-STABLE or 13-CURRENT. > > If you are using drm-legacy-kmod or the base driver with AMD graphics > cards you might also need to install xf86-video-ati-legacy rather than > xf86-video-ati. > > Regards > -- > Niclas Zeising I'm curious where 2013 comes from. I know that Intel Sandy Bridge graphics is supported with VAAPI acceleration by drm-stable-kmod, since it i working on the system I am using to send this message. I bought it in 2011, the year Sandy Bridge was introduced to production products. In general, when in doubt, I'd try drm-stable-kmod for questionable devices and fall back to drm-legacy-kmod it it fails. If y0ou use ports, I'd build both paskages to make it easier to recover if drm-stable-kmod fails. Also, be sure to make the proper adjustments to /etc/rc.conf as per the package message. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: DRM: radeonkms … can not be unloaded (kernel panic)) …
On Sat, Oct 20, 2018 at 1:28 AM Hans Petter Selasky wrote: > On 10/20/18 3:10 AM, Graham Perrin wrote: > > On 20/10/2018 00:01, Graham Perrin wrote: > > > >> kldunload radeonkms > >> > >> – results in a kernel panic. > > > > Found, at < > https://github.com/FreeBSDDesktop/kms-drm/issues/90#issuecomment-415859021> > under 'drm-devel-kmod g20180822 screen freeze': > > > >>> … normally you never unload the graphics driver so we haven't spent > time on proper cleanup. Also, the drm module will cause panic if you try > load load it again after unload. > > > > > > > > Is the principle for -next- the same as for -devel-, should I simply > _never_ attempt to unload the module? > > > > $ date ; uname -v > > Sat 20 Oct 2018 02:06:21 BST > > FreeBSD 12.0-BETA1 r339438 GENERIC > > $ pkg query '%o %v %R' drm-kmod drm-next-kmod gpu-firmware-kmod > > graphics/drm-next-kmod 4.11.g20180822 poudriere > > graphics/gpu-firmware-kmod g20180825 FreeBSD > > I recommend building these modules from source, /usr/src which match you > currently installed kernel! > > --HPS > This is a really good practice for all kernel modules from ports. If you build your kernel from source, put them into /etc/rc.conf to define PORTS_MODULES to always rebuild all modules when the kernel is built. Even if you install packages for your release, you need to realize that packages are built against the oldest supported minor release of a major release and that works or all ports that only have to match system ABIs which remain stable for the life of a major release. But, while the KBI (Kernel Binary Interface) usually remains stable, it occasionally does and did between 11.1 and 11.2 which meant that two ports failed when installed from packages on 11.2 system until 11.1 went EOL this month. I really wish that the portsmgr team would come up with a policy to maintain an archive of port based kernel modules whenever there is a minor release where people who have broken systems can get trusted packages. Some people are really not very capable of building from ports. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: drm-kmod, drm-next-kmod, radeonkms.ko, suspend and resume
Ack! It's been too long (at least a decade) since I've looked at a dump. Thanks! (kgdb) bt #0 sched_switch (td=0xf80008060600, newtd=0xf8000421, flags=) at /usr/src/sys/kern/sched_4bsd.c:1066 1066SDT_PROBE0(sched, , , on__cpu); (kgdb) bt #0 sched_switch (td=0xf80008060600, newtd=0xf8000421, flags=) at /usr/src/sys/kern/sched_4bsd.c:1066 #1 0x80b045f6 in mi_switch (flags=, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:439 #2 0x80b4b8bc in sleepq_catch_signals (wchan=0xf80008416a80, pri=0) at /usr/src/sys/kern/subr_sleepqueue.c:510 #3 0x80b4b3ff in sleepq_wait_sig (wchan=, pri=) at /usr/src/sys/kern/subr_sleepqueue.c:701 #4 0x825cdc88 in linux_add_to_sleepqueue (wchan=0xf80008416a80, task=0xf80008416a80, wmesg=, timeout=0, state=) at /usr/src/sys/compat/linuxkpi/common/src/linux_schedule.c:62 #5 0x825cdd7b in linux_schedule_timeout (timeout=0) at /usr/src/sys/compat/linuxkpi/common/src/linux_schedule.c:315 #6 0x8248769a in gen5_ring_put_irq (ring=0xfe000229f1f8) at /usr/src/sys/dev/drm2/i915/intel_ringbuffer.c:776 #7 0x825cad58 in linux_kthread_fn (arg=) at /usr/src/sys/compat/linuxkpi/common/src/linux_kthread.c:156 #8 0x80abd983 in fork_exit ( callout=0x825cad10 , arg=0x0, frame=0xfe0232ef1ac0) at /usr/src/sys/kern/kern_fork.c:1072 #9 0x80f59c4e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:975 #10 0x in ?? () Current language: auto; currently minimal What other output can I provide? -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 On Sat, Oct 6, 2018 at 10:34 AM Warner Losh wrote: > > > On Sat, Oct 6, 2018 at 10:22 AM Kevin Oberman wrote: > >> Due to lack of space on /var, I am unable to get a dump. (I'll get that >> fixed soon, but shuffling partitions take more time than I have right now. >> > > You can run savecore after you boot the system and direct its output to > another partition, eg 'savecore /home/crash' Unless you are doing a lot of > swapping, this is usually perfectly fine... > > 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: drm-kmod, drm-next-kmod, radeonkms.ko, Intel (Sandy Bridge), suspend and resume
On Sat, Oct 6, 2018 at 9:58 AM Graham Perrin wrote: > On 06/10/2018 17:20, Kevin Oberman wrote: > > > Re: drm-kmod, drm-next-kmod, radeonkms.ko, suspend and resume > > >> … > > > > Likely unrelated, but not necessarily... > > > > Running 11.2-STABLE r338990 (27-Sept), after the recent churn of mesa > and gnome, suspend/resume is also broken on my Intel (Sandy Bridge) system. > This may be an entirely different issue, but it seemed worth mentioning. > System is running drm-stable-kmod. … > > Kevin, please, what output do you get from this? > > uname -v ; pkg query '%n %v %R' drm-kmod ; pkg query '%n %v %R' > drm-stable-kmod ; pkg query '%n %v %R' drm-next-kmod > I am building from ports, so no repos. FreeBSD 11.2-STABLE #0 r338990: Thu Sep 27 21:13:37 PDT 2018 root@rogue:/usr/obj/usr/src/sys/GENERIC.4BSD Exit 69 drm-stable-kmod g20180822 unknown-repository Exit 69 -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: drm-kmod, drm-next-kmod, radeonkms.ko, suspend and resume
On Sat, Oct 6, 2018 at 12:46 AM Graham Perrin wrote: > On 06/10/2018 04:16, Pete Wright wrote: > > > Re: Radeon HD 7570M: drm: deep frustration with r339186 > > > … struggling with suspend/resume issues as well on my end with recent > 12-ALPHA releases. … radeonkms.ko … on my systems it's broken regardless > if i load the drm modules. … > > Pete, please, what output do you get from this? > > uname -v ; pkg query '%n %v %R' drm-kmod ; pkg query '%n %v %R' > drm-next-kmod > Likely unrelated, but not necessarily... Running 11.2-STABLE r338990 (27-Sept), after the recent churn of mesa and gnome, suspend/resume is also broken on my Intel (Sandy Bridge) system. This may be an entirely different issue, but it seemed worth mentioning. System is running drm-stable-kmod. I don't suspend often, so I am unsure whether this started propr to the last update to the drm-stable-kmod port. So this MAY not be current specific. Due to lack of space on /var, I am unable to get a dump. (I'll get that fixed soon, but shuffling partitions take more time than I have right now. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: Speed problems with both system openssl and security/openssl-devel
On Wed, Sep 12, 2018 at 4:48 PM Lev Serebryakov wrote: > Hello Brnrd, > >I'm benchmarking new hardware (rather limited one, but still) which > supports AES-NI (Celeron J3160). > >I'm comparing simple "openssl speed aes-256-cbc" and "openssl speed -evp > aes-256-cbc" on FreeBSD 12-ALPHA4 (built by myself with all debug options > turned off) and Debian Linux 9.5.0 booted from install DVD (without > installation). > > Simple "openssl speed aes-256-cbc" shows same numbers both in > single-threaded and multi-threaded mode (for all 4 cores). Linux is > marginally faster, > but it is in the margin of measurement error. > > But "openssl speed -evp aes-256-cbc" gives me very disappointing results. > FreeBSD's openssl is WAY slower than Linux one. It is even slower than > non-evp mode for small blocks. > > Here are results (As reported by openssl, with fractions dropped): > > Lin 1894220637 21300 57967 58769 58769 > Free 1893120591 21282 58342 58731 58779 > Lin-evp 97049 151466 183905 194385 197514 197727 > Free-evp 283810845 35362 81892 131264 137579 > > Linux have openssl 1.1.0f, and I've tried both system /usr/bin/openssl > (1.0.2p) > and /usr/local/bin/openssl from security/openssl-devel port (1.1.0i), > results are > virtually the same. I have "ASM" and "SSE2" options enabled in port. > > What happens here? Why does FreeBSD's build of openssl use AES-NI so > inefficient? > > -- > Best regards, > Lev mailto:l...@freebsd.org This is probably not the issue, but aesni is not in the GENERIC kernel. Are you sure aesni.ko is loaded? % kldstat | grep aesni If not found, "kldload aesni" and add aesni_load="YES" to /boot/loader.conf -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: ntpd as ntpd user question
On Mon, Jul 23, 2018 at 7:25 PM, Ian Lepore wrote: > On Mon, 2018-07-23 at 18:54 -0700, bob prohaska wrote: > > On Mon, Jul 23, 2018 at 09:34:26PM +0200, Herbert J. Skuhra wrote: > > > > > > > > > Yes, first you press m. Then you will see differences of installed > > > file (left) and new file (right). Then you press either l or > > > r: > > > > > > l | 1: choose left diff > > > r | 2: choose right diff > > > > > > If the diff tries to remove/add to many lines you can: > > > > > > el: edit left diff > > > er: edit right diff > > > > > > And if done you can view the merged file (v) before installing (i) > > > it. > > > > > > I am sure, someone can explain it better! :) > > > > > Perhaps, but you've made the essential point. Your reply let me > > understand that > > mergemaster does not really "master" the merge, it rather identifies > > files needing > > to be merged and then starts sdiff to let me modify files. Never > > having even looked > > at sdiff, the learning curve proved very steep. Too steep, in fact. > > > > I'm going to try a more incremental approach. > > > > Thank you _very_ much! > > > > bob prohaska > > Your reaction to mergemaster is about the same as mine was when I first > encountered it very long ago, and re-discovered when I tried it a > couple years ago. It just seems like more trouble than it's worth, I > can usually figure out what's broken and fix it by hand faster than > messing with all the merge stuff. > > But, someone told me that if you give mergemaster the right flags it > can potentially be intervention-free. Those apparently aren't the flag > or two that're suggested at the bottom of UPDATING. So I didn't really > dig into that any deeper, but I toss it out there in case someone can > expand on it. > > It certainly makes some sense that it could be done intervention-free. > When doing other diff-based merges (like 'svn update') you only have to > intervene when there's an actual conflict between some local change > you've made and the incoming changes. > > It gets a LOT simpler if you use "mergemaster -iPUF" Only those files you have modified will show up. In most cases, it just zips right by. In most that it does not, the use of 'r' or 'l' in merge is all you need and always 'r' eccepton lines you have modified, yourself, so you should know about them. I should note that 'U' does have a small "race" in it, so it i possible to get biten by it, but it is very unlikely. Has to do with multiple commits that touch the same lines in the file in a timing that is out of sync with your running it. I use '-iPF' because I m paranoid. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: [regression] The USB WiFi card stopped working: if_run doesn't create the 'run0' interface any more
On Wed, Jul 4, 2018 at 12:17 PM, Warner Losh wrote: > > > On Wed, Jul 4, 2018, 2:13 PM Kevin Oberman wrote: > >> On Wed, Jul 4, 2018 at 11:49 AM, Yuri wrote: >> >> > On 07/04/18 07:27, Rodney W. Grimes wrote: >> > >> >> Devd/devmatch is one of the largest changes recently, >> >> it could be something in that code path. >> >> >> >> Do you get the if_run.ko module loaded? What does kldstat show >> >> immediately after boot and before you try to "fix" anything with >> >> ifconfig. >> >> >> >> >> >> It definitely did create the run0 interface before, and now it doesn't. >> >>> >> >> I wonder if the kernel module is no longer loading... >> >> >> > >> > >> > if_run.ko isn't loaded after boot. But I think it is supposed to be >> loaded >> > by devd too. >> > >> > >> > Yuri >> > >> >> A quick perusal of /etc/devd.conf does not indicate that devd will load >> the >> driver. It is possible that I missed something, but "run" i only >> referenced >> as a part of long regex to stop or start pccard-ether. >> > > Look at etc/devd/devmatch.conf > > Warner > Oops! That's why I said "quick perusal". (On my 11.2-STABLE system, it's in /etc/devd/usb.conf) I don't have a system HEAD running here ATM. Thanks! -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: [regression] The USB WiFi card stopped working: if_run doesn't create the 'run0' interface any more
On Wed, Jul 4, 2018 at 12:06 PM, Yuri wrote: > On 07/04/18 12:00, Rodney W. Grimes wrote: > >> Just for fun to see if this can clear up your issue add >> if_run_load="YES" >> to /boot/loader.conf >> > > > This doesn't help. In the presence of preloaded if_run.ko wpa_supplicant > still can't initialize wlan0. > > > Yuri This is a shot in the dark, but I have a possibly similar issue with my Intel 6205 (iwn) card. It appears that thee is a race involving the timing of the iwn (wlan0) coming up and the start of the wpa_supplicant. I see the interface start, and aesociate but immediately go down. dhclient starts, but fails. If I kill the interface (service netif stop wlan0) and manually start it (ifconfig wlan0 up), it comes up fine. I can then start the wpa_supplicant and dhclient to get it working. From this point, it remains stable. If I just let it bounce up and down, it usually will eventually come up, but it can take some time and, on occasion it simply fails to some up unless I intervene. wlans_iwn0="wlan0" ifconfig_wlan0="WPA SYNCDHCP" -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: [regression] The USB WiFi card stopped working: if_run doesn't create the 'run0' interface any more
On Wed, Jul 4, 2018 at 11:49 AM, Yuri wrote: > On 07/04/18 07:27, Rodney W. Grimes wrote: > >> Devd/devmatch is one of the largest changes recently, >> it could be something in that code path. >> >> Do you get the if_run.ko module loaded? What does kldstat show >> immediately after boot and before you try to "fix" anything with >> ifconfig. >> >> >> It definitely did create the run0 interface before, and now it doesn't. >>> >> I wonder if the kernel module is no longer loading... >> > > > if_run.ko isn't loaded after boot. But I think it is supposed to be loaded > by devd too. > > > Yuri > A quick perusal of /etc/devd.conf does not indicate that devd will load the driver. It is possible that I missed something, but "run" i only referenced as a part of long regex to stop or start pccard-ether. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: error building clang in HEAD
On Tue, Jun 26, 2018 at 11:00 AM, Gary Jennejohn wrote: > On Tue, 26 Jun 2018 18:24:12 +0200 > Gary Jennejohn wrote: > > > On Mon, 25 Jun 2018 11:28:18 -0700 > > Bryan Drewery wrote: > > > > > On 6/24/2018 12:57 AM, Gary Jennejohn wrote: > > > > On Sat, 23 Jun 2018 17:05:16 +0200 > > > > Dimitry Andric wrote: > > > > > > > >> On 23 Jun 2018, at 15:40, Gary Jennejohn > wrote: > > > >>> > > > >>> There is a strange error building clang with this use case: > > > >>> > > > >>> cd /usr/src > > > >>> make -j10 makeworld > > > >> > > > >> What's the "makeworld" target? I've not heard of this. > > > >> > > > > > > > > A typo. I meant buildowrld. > > > > > > > >>> which produces this error output: > > > >>> > > > >>> ===> lib/clang/libclang (all) > > > >>> error: unable to rename temporary 'Sema/SemaTemplate-12ad7e30.o.tmp' > to output file 'Sema/SemaTemplate.o': 'No such file or directory' > > > >>> 1 error generated. > > > >>> --- Sema/SemaTemplate.o --- > > > >>> *** [Sema/SemaTemplate.o] Error code 1 > > > >> > > > >> This typically happens if "make obj" was not run before the rest of > the > > > >> make targets. Normally, the order is: make obj, then make depend, > then > > > >> make (a.k.a. make all). > > > >> > > > >> Is there a directory /usr/obj/usr/src/lib/libclang/Sema ? > > > >> > > > > > > > > Well, I would hope/expect that make buildworld does make obj. > > > > > > > > Yes, the directory was there. > > > > > > > > > > Actually neither 'make obj' nor 'make depend' is done or needed anymore > > > in buildworld. > > > > > > The directory above is incorrect, please check for > > > > > > /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/Sema > > > > > > > Well, now everything is there because I ran a buildworld without -j. > > > > > Do you have another Makefile or script that is executing > > > buildworld for you? > > > > > > > No, I use a bash alias named mw: > > mw is aliased to `pushd /usr/src;time make -s -j$NCPU buildworld;popd' > > > > NCPU is defined as 10. > > > > > What's in your src.conf and make.conf? > > > > > > > The only changes I made recently were to /etc/src.conf when I added: > > > > WITHOUT_LLVM_TARGET_AARCH64=yes > > WITHOUT_LLVM_TARGET_ARM=ys > > WITHOUT_LLVM_TARGET_MIPS=yes > > WITHOUT_LLVM_TARGET_POWERPC=yes > > WITHOUT_LLVM_TARGET_SPARC=yes > > WITH_LLVM_TARGET_X86=yes > > > > Otherwise, I haven't touched src.conf or make.conf in a long time. > > > > I removed some old cruft from src.conf and now make -j10 buildworld is > succeeding, even after rm -rf /usr/obj/usr. > > Thanks for pointing me in the right direction. > > -- > Gary Jennejohn > I'd like to hear what triggered this as removing unneeded LLVM targets seems like a good idea if you know that you won't need them. Building LLVM takes a long time on my 7+ year old, memory constrained (8G) system. Anything that reduces that time would be nice. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: Can't seem to use 5GHz APs with Intel wireless
On Fri, Jun 1, 2018 at 2:10 AM, Dhananjay Balan wrote:
> Hi,
>
> (Apologies if this is the wrong list, please point me at the right one if
> you know)
>
> I run 12-CURRENT (r334442) on a Thinkpad X230. This machine has an Intel
> Centrino Advanced N 6205. But freebsd only uses in in 11g mode. When I
> try to scan, it won't even display 5GHz aps.
>
>
> wlan0: flags=8843 metric 0 mtu
> 1500
> ether a4:4e:31:02:70:3c
> inet 192.168.1.108 netmask 0x broadcast 192.168.255.255
> nd6 options=29
> media: IEEE 802.11 Wireless Ethernet MCS mode 11ng
> status: associated
> ssid SSID channel 7 (2442 MHz 11g ht/20) bssid bc:8a:e8:0b:a9:3f
> regdomain FCC4 country DE authmode WPA2/802.11i privacy ON
> deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 10 scanvalid 60
> protmode CTS ampdulimit 32k ampdudensity 16 -amsdutx amsdurx
> shortgi
> -stbc -ldpc wme roaming MANUAL
> groups: wlan
>
>
>
> From reading man pages, I can see that iwn(4) supports 11n. Is it
> really supprted? What can I do to enable 11n?
>
>
> Here are my configs
>
> /etc/rc.conf
> wlans_iwn0="wlan0"
> ifconfig_wlan0="ssid SSID WPA SYNCDHCP"
>
>
> /etc/wpa_supplicant.conf
> ctrl_interface=/var/run/wpa_supplicant
> eapol_version=2
> ap_scan=1
> fast_reauth=1
>
> network={
> ssid="SSID"
> scan_ssid=0
> psk="PSK"
> priority=5
> }
>
>
> /boot/loader.conf
> # wifi
> if_iwn_load="YES"
> iwn1000fw_load="YES"
> iwn100fw_load="YES"
> iwn105fw_load="YES"
> iwn135fw_load="YES"
> iwn2000fw_load="YES"
> iwn2030fw_load="YES"
> iwn4965fw_load="YES"
> iwn5000fw_load="YES"
> iwn5150fw_load="YES"
> iwn6000fw_load="YES"
> iwn6000g2afw_load="YES"
> iwn6000g2bfw_load="YES"
> iwn6050fw_load="YES"
> ___
>
First, if you are using GENERIC, the driver and firmware are either in the
kernel (driver) or auto-loaded. Yo should not have anything about this in
your loader.conf.
As far as other configuration goes, rc.local should not need (or want) the
SSID. That is why it is in wpa_supplicant.conf. All global wpa_supplicant
global definition is not needed except for eapol_version=2 as 1 is default.
Normally teh default works, but some APs insist on V2. Still, it should not
hurt to define everything.
I do find the iwn driver to be pretty poor and sometimes a bit unstable,
but it does work. I have 11n and 54 MHz working. what do you see with
'ifconfig wlan0 list aps'? If 54M is available, it should show up.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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: SSP_CFLAGS for kernel
On Sat, May 5, 2018 at 4:33 AM, Rozhuk Ivan wrote: > On Sat, 5 May 2018 12:38:37 +0200 > bryn1u85 wrote: > > > Don't touch src.conf > > I want to buils kernel and system with SSP too Not relevant. /etc/make.conf definitions are applied to ALL make operations and that includes kernel and module building. /etc/src.conf definitions are only applied to the kernel, modules, and ports. When src.conf was created, it was explicitly NOT intended that the file be used for building ports, but someone has changed that. It probably should have been used for ports that built kernel modules, but not any others, but that is not the case. >From bsd.port.mk: # We prefer to pass MK_*=no but it was only supported after a certain # revision. Passing WITHOUT_* may conflict with a make.conf or src.conf's # WITH_* value. Note that ports *do* pull in src.conf. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: Nvidia issue with CURRENT
On Mon, Apr 23, 2018 at 1:53 AM, Mateusz Piotrowski <0...@freebsd.org> wrote: > On Mon, 23 Apr 2018 09:00:33 +0200 > "O. Hartmann" wrote: > > >In /etc/src.conf , therefore you should add something similar to (like > >I added to mine): > > > >PORTS_MODULES= > >PORTS_MODULES+= x11/nvidia-driver > >PORTS_MODULES+= emulators/virtualbox-ose-kmod > > Shouldn't it go into make.conf(5)? That's what the manual suggests. > Ans the man page should be fixed. By putting it into make.conf, it pollutes the environment of ever make(1) run on the system. (Yes, unlikely to ever cause a problem,) In src.conf it only impacts the builds of the system and ports. This is why src.conf was created a few years ago. In fact, it was originally supposed to only impact the build of the system, but the ports Mk files were modified to pull it in, to, much to my annoyance. I liked being able to modify compile options just for the system without them breaking ports builds. Simple rule... any definition used by make(1) only for system builds belongs in /etc/sec.conf. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: Nvidia issue with CURRENT
On Sun, Apr 22, 2018 at 6:40 PM, Greg 'groggy' Lehey wrote: > On Sunday, 22 April 2018 at 12:42:37 +0200, Mariusz Zaborski wrote: > > > I'm attaching also Xorg log. > > This seems to have got lost. > > Greg Please be sure that attachments are typed "text/plain". I believe all other MIME type are removed for security reasons. I also believe that text/SOME CHARACTER-SET will also be removed as they can be abused. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: failing to install 11.1R on VMWare
Mercy! He probably assumed memory in GB and thought 4GB was plenty. Dumb but understandable mistake. I've made similar ones, but try not to make a habit of it. (My wife probably disagrees.) Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 On Sat, Apr 7, 2018 at 4:31 AM, Ion-Mihai Tetcu wrote: > > [ combining 2 mails sent yesterday that didn't made it to the list ] > > Lol, looking over the one that fails ... RAM is set at 4MB. Which I > think it might be the default on that cluster for some reason. > I'll test now with a sane amount of RAM. Apologies for the noise. > > Yep, with 1GB it's OK. > Can't wait for the next week to kill the guy who configured that VM > before handling it over to me. > Sorry again for waisting your time. > > > On Fri, 6 Apr 2018 23:44:17 +0300 > Ion-Mihai Tetcu wrote: > > > On Fri, 6 Apr 2018 11:30:26 -0700 (PDT) > > "Rodney W. Grimes" wrote: > > > > > > On Fri, 6 Apr 2018 08:39:27 -0700 (PDT) > > > > "Rodney W. Grimes" wrote: > > > > > > > > > > On Thu, 5 Apr 2018 22:38:51 -0700 (PDT) > > > > > > "Rodney W. Grimes" wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > I'm trying to install FreeBSD on : > > > > > > > > VMWare ESXi, 6.0.0, 5050593 > > > > > > > > > > > > > > > > Guest OS: FreeBSD (64-bit) > > > > > > > > Compatibility: ESXi 6.0 and later (VM version 11) > > > > > > > > > > > > > > > > For 11.1R I'm getting the boot menu, then: > > > > > > > > /boot/kernel/kernel text=014972f8 > > > > > > > > elf64_loadimage: read failed > > > > > > > > can't load file: '/boot/kernel/kernel': input/output error > > > > > > > > ... > > > > > > > > (for 10.4R similar just with a different address). > > > > [ .. ] > > > > > > I relocated the VM on one of the 6.5.0 hosts (just the VM, not > > > > anything else) and got the same result trying to boot the 10.4R > > > > boot-only ISO). Would it make any diff if I create the VM from > > > > scratch on that host? > > > > > > Um, moving .vmx files around between versions of vsphere has to be > > > done with a good deal of care, and given your having "issues" to > > > start with I would not add that complexity to this problem. > > > > > > Create an new empty vm on 6.5.0, and use HW level 8, that is > > > portable accross 5.5 to 6.5. > > > > > > Also try sticking with ONLY IDE disks and cdrom, that might > > > be causing an issue. > > > > OK I created a new machine, almost with defaults (changed the disk to > > IDE and independent-nonpersistent, put the CDROM on the same > > controller) on 6.5.0 with Compatibility set to ESXi 5.0 and later (VM > > version 8) and the installer booted OK, got to the welcome screen. > > I'll play more tomorrow since it's almost midnight and I have to be up > > in 4h. Many thanks for the help. > > > > > > Here's the vmx of it: > > >>> > > .encoding = "UTF-8" > > config.version = "8" > > virtualHW.version = "8" > > nvram = "FREEBSD-test2.nvram" > > pciBridge0.present = "TRUE" > > svga.present = "TRUE" > > pciBridge4.present = "TRUE" > > pciBridge4.virtualDev = "pcieRootPort" > > pciBridge4.functions = "8" > > pciBridge5.present = "TRUE" > > pciBridge5.virtualDev = "pcieRootPort" > > pciBridge5.functions = "8" > > pciBridge6.present = "TRUE" > > pciBridge6.virtualDev = "pcieRootPort" > > pciBridge6.functions = "8" > > pciBridge7.present = "TRUE" > > pciBridge7.virtualDev = "pcieRootPort" > > pciBridge7.functions = "8" > > vmci0.present = "TRUE" > > hpet0.present = "TRUE" > > memSize = "1024" > > sched.cpu.units = "mhz" > > sched.cpu.affinity = "all" > > sched.cpu.latencySensitivity = "normal" > > sched.mem.affinity = "all" > > powerType.pow
Re: Jan 18 04:05 vboxdrv.ko breaks r328637: Wed Jan 31 kernel. crashes
On Mon, Feb 5, 2018 at 2:49 AM, Taavi wrote: > Hi > > Not really wanting to do that. Using pkg binary system for purpose > > That would lead to question why binary package driver crashes kernel? > > regards, > Taavi > This is a real problem with kmod packages. If hte kernel is modified in any way, modules must be re-built. It may take a while for the package to get re-built for a given change as the port has not been modified. The recommended method is to put port modules into /etc/src.conf PORTS_MODULES list so that kernel rebuild will always rebuild the modules, but that only works if the kernel IS built from sources and re-installed. It will be a bigger issue when more people start doing binary updates to the kernel.more routinely. ___ 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: Poll: should man(1)'s default pager change to "less -s"?
On Tue, Dec 12, 2017 at 12:40 PM, Alan Somers wrote:
> On Tue, Dec 12, 2017 at 1:39 PM, Chris H wrote:
>
>> On Tue, 12 Dec 2017 12:27:37 -0800 "Kevin Oberman"
>> said
>>
>> On Tue, Dec 12, 2017 at 12:02 PM, Chris H wrote:
>>>
>>> > On Tue, 12 Dec 2017 10:15:10 -0800
>>> said
>>> >
>>> > On Tue, Dec 12, 2017 at 11:03:54AM -0700, Alan Somers wrote:
>>> >> > Should man(1)'s default pager change to "less -s"? Vote and flame
>>> at
>>> >> the
>>> >> > Phabricator link below.
>>> >> > > https://reviews.freebsd.org/V7
>>> >> >
>>> >> Does not work.
>>> >>
>>> >> Unhandled Exception ("AphrontMalformedRequestException")
>>> >> Your browser did not submit a "phcid" cookie with client state
>>> >> information in the request. Check that cookies are enabled.
>>> >> If this problem persists, you may need to clear your cookies.
>>> >>
>>> >> Of course, I don't have an account on https://reviews.freebsd.org/
>>> >>
>>> > Hah! I got the same (alarming) feedback too. I then tried to just log
>>> in,
>>> > and it worked. Guess you'll need, or create an account? :-)
>>> >
>>> > --Chris
>>> >
>>> >
>>> >> --
>>> >> Steve
>>> >>
>>> >
>>> I have not used those ancient, very limited pagers for years, but I am
>>> sure
>>> that almost nobody has even heard of the much more powerful
>>> sysutils/most.
>>>
>> Ooo... I may have voted too soon. :-O
>> Thanks for the pointer, Kevin!
>>
>> --Chris
>>
>
> most looks pretty cool. The only probably I noticed in my brief
> inspection was that it doesn't support the Home and End keys.
>
Having started with most(1) in days before we had and
(VT220s), my fingers are trained for t (top) and b (bottom). Adding support
for those keys should be pretty trivial. I'll drop the author a note asking
if they might be added for 5.1.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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: Poll: should man(1)'s default pager change to "less -s"?
On Tue, Dec 12, 2017 at 12:02 PM, Chris H wrote:
> On Tue, 12 Dec 2017 10:15:10 -0800 said
>
> On Tue, Dec 12, 2017 at 11:03:54AM -0700, Alan Somers wrote:
>> > Should man(1)'s default pager change to "less -s"? Vote and flame at
>> the
>> > Phabricator link below.
>> > > https://reviews.freebsd.org/V7
>> >
>> Does not work.
>>
>> Unhandled Exception ("AphrontMalformedRequestException")
>> Your browser did not submit a "phcid" cookie with client state
>> information in the request. Check that cookies are enabled.
>> If this problem persists, you may need to clear your cookies.
>>
>> Of course, I don't have an account on https://reviews.freebsd.org/
>>
> Hah! I got the same (alarming) feedback too. I then tried to just log in,
> and it worked. Guess you'll need, or create an account? :-)
>
> --Chris
>
>
>> --
>> Steve
>>
>
I have not used those ancient, very limited pagers for years, but I am sure
that almost nobody has even heard of the much more powerful sysutils/most.
While newer than more or less, it is hardly new in most senses as I first
used it on VMS systems at least a quarter century ago, probably longer.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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: iwm not in GENERIC kernel
On Sun, Oct 29, 2017 at 9:49 AM, Ngie Cooper (yaneurabeya) < yaneurab...@gmail.com> wrote: > > > On Oct 29, 2017, at 02:46, Thomas Mueller wrote: > > … > > > Is that binary blob the reason why rsu is not in GENERIC? > > > > I use rsu for Hiro H50191 USB wireless adapter. > > Yup. > But I thought that all modern wireless interfaces and many others load blobs. Is the source for the firmware blob for iwn (which is in GENERIC) available? -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: cve-2017-13077 - WPA2 security vulni
On Tue, Oct 17, 2017 at 9:57 AM, David Wolfskill wrote: > On Tue, Oct 17, 2017 at 12:51:23PM -0400, Allan Jude wrote: > > > > > Question: Should one expect a wpa_supplicant-2.6_2 executable built > > > under FreeBSD stable/11 (amd64) to work on the same hardware, but > > > running head? > > > > Did you run the version from ports, or did you run the base /etc/rc.d > > script with your rc.conf set to point to the ports binary? This will run > > the command with -c /etc/wpa_supplicant.conf overriding the ports > default. > > > > So this is expected to work in this way. > > Ah. When I installed the port, I was reminded: > > | ... > | ===> Registering installation for wpa_supplicant-2.6_2 > | Installing wpa_supplicant-2.6_2... > | To use the ports version of WPA Supplicant instead of the base, add: > | > | wpa_supplicant_program="/usr/local/sbin/wpa_supplicant" > | > | to /etc/rc.conf > | > | ===> SECURITY REPORT: > | > > So I did that. I did not do anything to the existing > /etc/rc.d/wpa_supplicant, which had been installed as part of base > FreeBSD. > > > > > Peace, > david > -- > David H. Wolfskill da...@catwhisker.org > Unsubstantiated claims of "Fake News" are evidence that the claimant lies > again. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > Possibly silly question, but are any of the defaults for the port different from those on the base system? DEBUG_* seem most likely to differ, but I'd like to know if there are any others. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: cve-2017-13077 - WPA2 security vulni
On Mon, Oct 16, 2017 at 8:55 AM, Adrian Chadd wrote: > hi, > > I got the patches a couple days ago. I've been busy with personal life > stuff so I haven't updated our in-tree hostapd/wpa_supplicant. If > someone beats me to it, great, otherwise I'll try to do it in the next > couple days. > > I was hoping (!) for a hostap/wpa_supplicant 2.7 update to just update > everything to but so far nope. It should be easy enough to update the > port for now as it's at 2.6. > > > > -adrian > > > On 16 October 2017 at 06:04, Cy Schubert wrote: > > In message <44161b4d-f834-a01d-6ddb-475f20876...@freebsd.org>, Lev > Serebryakov > > writes: > >> On 16.10.2017 13:38, blubee blubeeme wrote: > >> > >> > well, that's a cluster if I ever seen one. > >> It is really cluster: CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, > >> CVE-2017-13080, CVE-2017-13081, CVE-2017-13082, CVE-2017-13084, > >> CVE-2017-13086,CVE-2017-13087, CVE-2017-13088. > > > > The gory details are here: https://w1.fi/security/2017-1/ > wpa-packet-number-reuse-with-replayed-messages.txt > > > > The announcement is here: > > https://www.krackattacks.com/ > > > > > > -- > > Cheers, > > Cy Schubert > > FreeBSD UNIX: Web: http://www.FreeBSD.org > > > > The need of the many outweighs the greed of the few. > > > While I do not encourage waiting, it is quite likely that the upstream patch wil show up very soon now that the vulnerability is public. It's also worth noting that fixing either end of the connection is all that is required, as I understand it. So getting an update for your AP is not required. That is very fortunate as the industry has a rather poor record of getting out firmware updates for hardware more than a few months old. Also, it appears that Windows and iOS are not vulnerable due to flaws in their implementation of the WPA2 spec. (Of course, if you update your AP(s), you no longer need to worry about your end devices. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: How do GEOM_PART_* options configure geom_part_* modules??
On Thu, Sep 28, 2017 at 6:09 PM, Rodney W. Grimes < freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > On Thu, Sep 28, 2017 at 11:12 AM, Kevin Oberman > wrote: > > > > > On Thu, Sep 28, 2017 at 9:13 AM, Warner Losh wrote: > > > > > >> On Thu, Sep 28, 2017 at 10:00 AM, Nick Hibma > > >> wrote: > > >> > > >> > I created a new kernel config file from scratch, wondered what the > > >> > GEOM_PART_MBR option and friends were doing, search for them, didn't > > >> find > > >> > them in the tree, and deleted them from my config. But... de > resulting > > >> disk > > >> > image didn't boot, because of the fact that it didn't recognise the > MBR > > >> > partitions (it only had a single diskid entry on the mount-root > prompt). > > >> > > > >> > Can anyone explain to me how these kernel options work, as in: they > are > > >> > defined in kernel configs and as a consequence in opt_geom.h, but > how > > >> are > > >> > they actually used to select which geom_part_* modules/kernel parts > to > > >> > build? I thought these options were translated to stuff that cpp > would > > >> use, > > >> > but there are not uses of for example GEOM_PART_MBR anywhere for > > >> example! > > >> > > > >> > > > >> > The module always build them because they are listed in the module's > > >> > Makefile. > > >> > > > >> > The kernel only sometimes does. Here's the key lines from > conf/files: > > >> > files:geom/geom_bsd_enc.c optional geom_bsd | geom_part_bsd > > >> > files:geom/part/g_part_apm.c optional geom_part_apm > > >> > files:geom/part/g_part_bsd.c optional geom_part_bsd > > >> > files:geom/part/g_part_bsd64.c optional geom_part_bsd64 > > >> > files:geom/part/g_part_ebr.c optional geom_part_ebr > > >> > files:geom/part/g_part_gpt.c optional geom_part_gpt > > >> > files:geom/part/g_part_ldm.c optional geom_part_ldm > > >> > files:geom/part/g_part_mbr.c optional geom_part_mbr > > >> > files:geom/part/g_part_vtoc8.c optional geom_part_vtoc8 > > >> > > > >> > which turn on/off which files get included. config "helpfully" > converts > > >> the > > >> > upper case options to lower case for this. > > >> > > > >> > Warner > > >> > > > >> > > > >> > *slaps forehead* Goose chase! > > >> > > > >> > I actually knew that... and, at the time, thought it was weird > > >> behaviour. > > >> > ''grep" would not have failed me if those options would be uppercase > > >> there > > >> > ... > > >> > > > >> > > >> I've been nibbled to death by these geese often enough to have a > PTSD-like > > >> reaction when someone mentions it and habitually add -i to my greps... > > >> > > >> Warner > > > > > > > > > This horrid POLA violation seems to have been in FreeBSD configuration > > > since at least 3.0 and probably goes back to the creation of the > > > configuration process. > > > > > > Any idea why such a horrible POLA was ever introduced? Seems like an > > > obviously bad idea in an OS that is ALMOST always case sensitive. > > > > > > > It's received code from the old 4.3 BSD config program (or maybe the > net-2 > > config program). > > We had best not have any code direct from 4.3 or net-2, it should be from > 4.4BSDLite, any code prior to that is subject of the lawsuit. > > > -- > Rod Grimes > rgri...@freebsd.org > I believe any code in 4.3 BSD that was developed by CSRG was not subject of the suit. Copyright on that code by the Regents of UC, not AT&T. (So was any code I wrote.) Many utilities were from v8 or descended from AT&T code, but a great deal was not. It was what UC was getting paid for. My first Unix experience was with 4.2 BSD and I was not concerned with copyrights as I was working for UC (at least my paychecks said so) and we had an AT&T license for Unix, so it was simply not an issue. The system was a VAX-11/750 at the UC-Davis Department of Applied Science located at Lawrence Livermore Lab. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: How do GEOM_PART_* options configure geom_part_* modules??
On Thu, Sep 28, 2017 at 9:13 AM, Warner Losh wrote: > On Thu, Sep 28, 2017 at 10:00 AM, Nick Hibma > wrote: > > > I created a new kernel config file from scratch, wondered what the > > GEOM_PART_MBR option and friends were doing, search for them, didn't find > > them in the tree, and deleted them from my config. But... de resulting > disk > > image didn't boot, because of the fact that it didn't recognise the MBR > > partitions (it only had a single diskid entry on the mount-root prompt). > > > > Can anyone explain to me how these kernel options work, as in: they are > > defined in kernel configs and as a consequence in opt_geom.h, but how are > > they actually used to select which geom_part_* modules/kernel parts to > > build? I thought these options were translated to stuff that cpp would > use, > > but there are not uses of for example GEOM_PART_MBR anywhere for example! > > > > > > The module always build them because they are listed in the module's > > Makefile. > > > > The kernel only sometimes does. Here's the key lines from conf/files: > > files:geom/geom_bsd_enc.c optional geom_bsd | geom_part_bsd > > files:geom/part/g_part_apm.c optional geom_part_apm > > files:geom/part/g_part_bsd.c optional geom_part_bsd > > files:geom/part/g_part_bsd64.c optional geom_part_bsd64 > > files:geom/part/g_part_ebr.c optional geom_part_ebr > > files:geom/part/g_part_gpt.c optional geom_part_gpt > > files:geom/part/g_part_ldm.c optional geom_part_ldm > > files:geom/part/g_part_mbr.c optional geom_part_mbr > > files:geom/part/g_part_vtoc8.c optional geom_part_vtoc8 > > > > which turn on/off which files get included. config "helpfully" converts > the > > upper case options to lower case for this. > > > > Warner > > > > > > *slaps forehead* Goose chase! > > > > I actually knew that... and, at the time, thought it was weird behaviour. > > ''grep" would not have failed me if those options would be uppercase > there > > ... > > > > I've been nibbled to death by these geese often enough to have a PTSD-like > reaction when someone mentions it and habitually add -i to my greps... > > Warner This horrid POLA violation seems to have been in FreeBSD configuration since at least 3.0 and probably goes back to the creation of the configuration process. Any idea why such a horrible POLA was ever introduced? Seems like an obviously bad idea in an OS that is ALMOST always case sensitive. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: [tzsetup] can't set up local timezone if CMOS is set to UTC
On Mon, Aug 7, 2017 at 2:48 PM, Marius Strobl wrote: > On Mon, Aug 07, 2017 at 09:51:15AM +0300, Boris Samorodov wrote: > > 07.08.2017 09:44, Boris Samorodov ?: > > > Hi Marius, All, > > > > > > Subj at today's amd64-HEAD. If I use command "sudo tzsetup" and > > > choose YES (CMOS clock is set to UTC), the program just quits. > > > Yea, my clocks are at UTC but I want to get time at local timezone. :-) > > > > > > I've found a recent commit to tzsetup, is it the cause? > > > > Hm. There is a log message at r322097: > > --- > > - Make the initial UTC dialog actually work by giving the relevant files > >the necessary treatment and then exit when choosing "Yes" there > instead > >of moving on to the time zone menu regardless. > > --- > > > > I must misunderstand something. > > > > So my question is: how to set up local time zone if CMOS is set to UTC? > > Yeah, I hadn't thought of the case where one would like to set up > a configuration in which the RTC is using UTC but the timezone is > not. So I've reverted the corresponding part of r322097 for now as > I don't see an obvious way to give /etc/wall_cmos_clock appropriate > treatment in all 3 relevant cases (UTC/UTC, !UTC/UTC and !UTC/!UTC > regarding RTC/timezone) for all interactive and non-interactive > ways of using tzsetup(8). > > Marius Thanks for the quick fix, Marius. FWIW, it the system is not running Windows (dual boot), it has long been standard BSD practice to set the RTC to UTC and then set the timezone to local time. I've seen this back to the days of at least BSD4.3 (NOT FreeBSD) but 20 or more years ago. I have worked at two places with hundreds of systems, all running this way, including all of "my" systems. The practice of setting RTC on Unix-only platforms to local time really started with dual-boot systems, especially Windows. (I first saw this on a BSD Unix/VMS dual boot system.) -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: Ports still broken by ino64?
On Fri, Jun 23, 2017 at 8:19 PM, Thomas Mueller wrote: > On Fri, Jun 23, 2017 at 4:12 PM, Thomas Mueller > wrote: > > > > I remember some ports on FreeBSD-current were rendered nonbuildable by > the > > > introduction of 64-bit inodes (ino64). > > > > What is the progress on resolving those snags? > > > > I haven't heard anything recently and was unable to find anything on > > > wiki.freebsd.org. > > > > So how do I know the current status? > > > > I am particularly concerned with gcc5-aux and gcc6-aux which should be > of > > > concern because ports-mgmt/synth requires gcc6-aux as a dependency. > > > > There was never a BROKEN in any of these ports' Makefile. > > > Tom > > > > IIRC, there was no general issue with building ports, though a few may > have > > needed a fix. It was that packages built after the change were not > > available and older binaries would not work. I believe that the issue > went > > away as soon as a new package build was completed. This took longer than > > usual as ALL packages had to be re-built, not just those which had been > > updated since the last build. > > > Kevin Oberman, Part time kid herder and retired Network Engineer > > So I guess I could update my FreeBSD-current installation, building from > 11-stable host, and try again to build synth? > > But all the dependencies that build successfully and installed before the > system crash would have to be rebuilt from the start. > > It will take some time before I get to it, with an 11.1-BETA2 installation > being built up and some NetBSD installations being updated (not easy, > problems are such as to dissuade me from tryimg to use pkgsrc on FreeBSD). > > I know that any old FreeBSD-current installation from January 2016 or > August 2015 must not be touched lest all or nearly all packages be rendered > nonfunctional due to shared libraries out of sync, not to mention ino64. > > Upgrade after FreeBSD 11.1-STABLE/BETA2 installation is built up and ready > to take over. > > One thing that might put rebuilding FreeBSD-current to a higher priority > would be an update to > $SRC_BASE/sys/dev/re/if_re.c > > Tom > Maybe not, but I think so. synth(8) requires the ada compiler which means lang/gcc6-aux or lang/gcc5-aux and those DID require work to install on ino64. I believe that this is now resolved, but I would seriously consider simply installing synth from the package. It has no run or lib depends, so installing the package is risk-free. synth is the only package I install on my development system,though I do consider installing chromium and libreoffice from packages now and then... like every time I have to rebuild either. (libreoffice is awaiting for a rebuild right now. Maybe tomorrow. I built Chromium yesterday.) -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: Ports still broken by ino64?
On Fri, Jun 23, 2017 at 4:12 PM, Thomas Mueller wrote: > I remember some ports on FreeBSD-current were rendered nonbuildable by the > introduction of 64-bit inodes (ino64). > > What is the progress on resolving those snags? > > I haven't heard anything recently and was unable to find anything on > wiki.freebsd.org. > > So how do I know the current status? > > I am particularly concerned with gcc5-aux and gcc6-aux which should be of > concern because ports-mgmt/synth requires gcc6-aux as a dependency. > > There was never a BROKEN in any of these ports' Makefile. > > Tom > IIRC, there was no general issue with building ports, though a few may have needed a fix. It was that packages built after the change were not available and older binaries would not work. I believe that the issue went away as soon as a new package build was completed. This took longer than usual as ALL packages had to be re-built, not just those which had been updated since the last build. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: firefox/ rust failed to install on FreeBSD 12-CURRENT
On Sun, May 28, 2017 at 1:12 PM, blubee blubeeme wrote: > I am using the default tcsh shell and sudo -c isn't a valid sudo command. > > > On Mon, May 29, 2017 at 3:49 AM, Kevin Oberman > wrote: > >> On Sun, May 28, 2017 at 12:24 PM, Konstantin Belousov < >> kostik...@gmail.com> wrote: >> [...] >> More exactly, don't build rust with 'sudo buildcommand' where >> 'buildcommand' could be make, portmaster, or any other command that will >> build rust. >> >> You can, however, 'sudo -c' and then run the build with no problem. I do >> this regularly. 'sudo -c' really makes your environment into root with a >> new shell and you must 'exit' to get back to being yourself. >> -- >> Kevin Oberman, Part time kid herder and retired Network Engineer >> E-mail: rkober...@gmail.com >> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 >> > > Brain, meet fingers. Fingers, meet brain. It's 'sudo -s'. Don't know why I typed 'c'. And did it twice! Sorry! -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: misc/mc, diff and compare two files
On Sun, May 14, 2017 at 7:53 AM, Boris Samorodov wrote: > Hi All, > > FYI: For those who use FreeBSD-HEAD, misc/mc and it's awesome "compare > two files" feature: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219277 > > HTH > -- > WBR, bsam Or use the "compare [two|three] [buffers|files]" tool in emacs. Being able to deal with three files can be surprisingly handy. emacs is a great tool for many things and I even find it has a pretty good editor, though most vim? users seem to disagree. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: svn commit: r316977 - head/sys/dev/syscons
On Sat, Apr 15, 2017 at 10:55 PM, O. Hartmann wrote: > Am Sat, 15 Apr 2017 18:00:18 -0700 > Conrad Meyer schrieb: > > > On Sat, Apr 15, 2017 at 1:21 PM, O. Hartmann > wrote: > > > Am Sat, 15 Apr 2017 20:03:50 + (UTC) > > > Bruce Evans schrieb: > > > > > >> Author: bde > > >> Date: Sat Apr 15 20:03:50 2017 > > >> New Revision: 316977 > > >> URL: https://svnweb.freebsd.org/changeset/base/316977 > > > > > > There is a lot of development going on theses days for syscons. What's > about vt()? > > > vt() is considered broken for x11/nvidia-driver and vt() is considered > a requirement > > > when UEFI is boot scheme, isn't it? > > > > > > I'm just curious. > > > > Hi O., > > > > Bruce uses syscons and cares enough to improve it. He likely does not > > care about UEFI and definitely does not care about vt. I don't think > > there's anything wrong with that. We can't force volunteers to work > > on things they are not interested in. > > > > Best, > > Conrad > > Hello Conrad, happy easter. > > There is and was never intention to apply "force", it is a question as I'm > curious about > what's going on with vt() - no personally bound to B. Evans or anybody > else - I just took > the chance to comment/ask on that subject when I saw postings. > > Maybe not the right place to spread some thinkings. > > Regards, > > Oliver Hartmann > vt(4) is not a pleasant thing to look at. I am not implying that it is bad code or badly done. I am just saying that it is pretty gnarly and is not the sort of thing most enjoy dealing with. I got the distinct feeling that ray@ found the job much uglier than he anticipated when he took the Foundation commission to write it. Since then it has been widely disparaged for the things that it does not do, but I am not aware that anyone has gotten further than looking at what is needed and then running far away.Some day someone (or some company) will get sufficiently inspired to either re-write if or add the missing features. I have no idea when that might happen, though. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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 kernel build breakage (after r314283?)
On Mon, Mar 6, 2017 at 9:18 AM, Lev Serebryakov wrote: > On 06.03.2017 20:10, Lev Serebryakov wrote: > > > I've got this error when tried to update my -CURRENT VM to r314772: > > > > /data/src/sys/cam/cam_xpt.c:84:1: error: static_assert failed > > "XPT_PRINT_LEN is too large" > > _Static_assert(XPT_PRINT_LEN <= XPT_PRINT_MAXLEN, "XPT_PRINT_LEN is too > > large"); > > ^ ~ > > > > I didn't define any XPT_ macro by hands, but I have > > > > options PRINTF_BUFR_SIZE=1024 > > > > in my kernel config. > Yep, removing this option helps, but it is surprising and not obvious > at all! > > -- > // Lev Serebryakov > If my memory is good (and it may not be), this option was recommended to prevent garbled syslog and console entries, but that was back in v8 days, long, long ago. I have not had his problem for a long time and I think that the option is no longer required and even they, 1024 was a LOT bigger than was recommended at the time. 128 or 256 seems tike the value recommended. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: vt(4) chops off the leftmost three columns
On Sat, Jan 14, 2017 at 2:11 PM, Adrian Chadd wrote: > It depends(tm). I think the VT code just does "640x480x4bpp" and lets > the BIOS sort it out. A lot of things don't cope well with 640x480 > these days - they try autodetecting picture edges, but a black border > makes that very difficult. > > > -adrian > Can you use vidcontrol(1) to change to something better? 1600x900, maybe? (Note, I have not tried this and I know that vt does not support a lot of vidcontrol functionality, but starting X sets the display to 200x56 characters on my laptop.) -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > On 14 January 2017 at 08:57, Matthias Andree > wrote: > > Am 14.01.2017 um 00:11 schrieb Alan Somers: > >> I take it back. The first three columns _are_ rendered, but they > >> don't show up on some monitiors. It's as if those monitors require a > >> minimum amount of overscan on the left side of the screen, and vt(4) > >> doesn't provide enough. Can that be tuned? > > > > Once upon a time, I've seen similar things on Linux, but with fewer > > pixels offset, when switching framebuffer drivers - back then, the > > scanning-VGA-timing was an issue. Is there any way to tweak the row and > > column timings, with blank periods, viewport offsets and thereabouts? > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ > 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" > ___ 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: drm-next update and longer term plans
On Thu, Dec 1, 2016 at 2:25 PM, Matthew Macy wrote: > I imagine that for most users the state of graphics support for > post-Haswell hardware is a bit of a black box so I'm sending out this note > to let users know what they can and cannot expect. > > Wayland has actually become a reality for some. Talk to Johannes Lundberg > if you're interested in tracking that. > > The i915 (Intel integrated GPUs) driver is currently best supported by the > drm-next-4.7 branch. Broadwell and Skylake support is complete and some > support came in late in the cycle for Kaby Lake. I can still consistently > lock up the kernel in the later stages of the piglit test suite, there is > no backlight support, and suspend/resume do not work on Skylake. The > drm-next branch is integrated with upstream up through Linux 4.8-rc5 and > thus has complete support for Kaby Lake, but there is a lockup in i915 that > occurs some time within an hour of startx. This takes too long for it to > have shown up in my limited integration smoke testing. > > The amdgpu driver is, in terms of KPI dependencies - as far as I can tell > - a strict superset of the radeon driver. For example, when I tested my one > older card that uses the radeon driver it manifested the same ttm bugs as > amdgpu did at that time. Thus, when amdgpu reaches a complete working state > I expect radeon to largely "just" work. As of this past Sunday amdgpu with > the amdgpu DDX works with 2D, supports external monitors - selecting the > appropriate resolution on a per display basis, and backlight works. It will > also typically panic in ttm within ~90 minutes of startx. Although this is > huge progress over panicking within 30s of startx (which was the case as of > Saturday) or not starting at all due to bugs in the libdrm port a few weeks > prior, it's obviously not something I encourage anyone to use. > > My primary motivation for starting with the work is being able to to train > DNNs/RNNs and other model types using Theano/Caffe/Tensorflow/BidMach etc > GPU accelerated whilst still running FreeBSD. The Radeon Open Compute stack > holds out the promise of doing that without using the closed source CUDA > stack on top of the Linux ABI emulation - which would inevitably be opaque > and fragile. My plan is to keep on fixing bugs and tracking upstream until > the first long term branch after ROC support has been integrated in to > Linux mainline. I have no exact knowledge of when exactly that will be (AMD > doesn't have sufficient developer resources to make any concrete > guarantees) but think it should happen by the summer of 2017. I would like > to think that by that time the i915, amdgpu, and radeon will be feature > complete and at least as stable as the drm2 support currently in tree. > > I need to weigh my soft commitment to make long-term DRM support happen > with paid work and other activities which are much more important to me > long term. Thus I've currently committed to spending every Sunday fixing > bugs in the drm-next branches. Amdgpu is both more important to me and has > gotten much less attention than i915. Thus I will be devoting my efforts to > it in the near term. I'd very much welcome efforts by others to triage the > issues in i915. > > Many people ask when drm-next will be available on 11. I am not a > committer and thus have no direct say in that. However, if you are a > motivated individual with kernel knowledge you should contact Adrian Chadd. > There are a few places where I was not able to provide proper linuxkpi > semantics without making (mostly quite modest) changes to sys/kern. There > is a general reluctance by some core developers to make changes to > accommodate Linux. It is possible that, with additional effort, the > linuxkpi can both be complete enough to avoid needing to port the graphics > drivers to FreeBSD (something clearly shown by past efforts to be > unsustainable) and not need to make any kernel changes. If you would like > to help with that, let Adrian know. In the meantime, TrueOS will continue > to use my development branches for the benefit of users with newer hardware. > > -M > Matt, Thanks for your and your teams work on this. While I am still running on Sandy Bridge hardware, I am hoping that my next system will be able to run real X or Wayland without being stuck with VESA formonths, as I was when my Sandy Bridge system was new. While I understand that this is really a by-product of you goal, thanks for it. I really hope that Core understands that unless FreeBSD can run drivers developed for Linux or required only trivial patches, FreeBSD will always lag at least months and probably years behind for both graphics and GPU compute. While Linux does compete with FreeBSD, it is not an ene
Re: Lenovo X1 Carbon or T460s
On Fri, Nov 11, 2016 at 8:08 AM, Mark Heily wrote: > On Fri, Nov 11, 2016 at 6:25 AM, Jeremie Le Hen wrote: > > > Hi guys, > > > > I'm about to purchase a new laptop, one of the two mentioned in the > > subject. > > > > I'm looking for reports of hardware support for both of them under > FreeBSD. > > What are the goods and bads? > > > > > I just purchased a brand new Gen 4 X1 Carbon last week and tried a recent > TrueOS build on it. I'm triple booting it with Windows and Linux for > comparison purposes. Here's what I have seen so far regarding FreeBSD: > > - Wifi and the touchpad work fine. > > - The latest gen HiDPI screens (aka Retina display) have extremely high > resolution relative to the size of the screen, which makes the console > fonts extremely tiny. Even the TrueOS graphical installer was barely usable > due to small fonts. If you want a graphical desktop environment, you'll > have to figure out how to scale applications to look right under HiDPI. > Lumina and the TrueOS display manager did a decent job of it, but didn't > give me enough control over the scaling factor. With the latest Gnome on > Linux, it gives you a lot of control over how applications are scaled. I've > heard KDE5 also has support for HiDPI. > > - Skylake integrated video isn't accelerated. and feels a little slow. > Video playback is choppy and disappointing. > > - Suspend/resume is reported not to work (I have not confirmed this) > > At this point, FreeBSD is still unusable due to display issues (IMHO) and I > spend most of my time booting into Linux :( > > The hardware itself is great, other than the black finish seems to attract > smudges and fingerprints. It's super lightweight, quiet, fast, and the > keyboard and trackpad feel very comfortable In regard to video, have you installed and are you using vaapi? It provides Intel GPU video acceleration sand, on my old Sandy Bridge it made a huge difference in video, at least with software that supports it. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: FreeBSD 11.x grinds to a halt after about 48h of uptime
50 dtbuf prcfr94 >> hdac1 266 >> Namei Name-cache Dir-cache349167 desvn totfr >> ahci0 270 >>Callshits %hits %349155 numvn react 5 >> cpu1:timer >> 121 121 100253501 frevn pdwak 1 >> cpu2:timer >> pdpgs29 >> cpu7:timer >> Disks md0 ada0 ada1 pass0 pass1 pass2 intrn12 >> cpu3:timer >> KB/t 0.00 0.00 0.00 0.00 0.00 0.00 5318892 wire 41 >> cpu6:timer >> tps 0 0 0 0 0 0 9261404 act 12 >> cpu5:timer >> MB/s 0.00 0.00 0.00 0.00 0.00 0.00 1598184 inact 6 >> cpu4:timer >> %busy 0 0 0 0 0 0 cache >> vgapci0 >> 61840 free >>712304 buf >> >> >> Why do I have a Chrome tab using about 6G? What other sort of debugging >> output can be helpful to get to the bottom of this? The machine still >> responds to pings just fine, TCP connections get set up but the SSH >> handshake never completes. >> >> This always happens between 30-50h and is super annoying and has been >> going on for >1year. Help? >> >> Note, I cut the power to the monitor overnight to save electricity, can >> this mess up something in the Radeon card or X server? What combinations >> would be most useful to try next? >> >> > Hi, > > Sounds like a memory leak. Can you track the memory use over time? > > Did you look at the output from: > > vmstat -m ? > > --HPS I have noted significant memory leakage in chromium for some time. If I leave it running overnight, my system is essentially frozen. If I terminate the chromium process, it slowly comes back to life. I always keep a gkrellm session on-screen where the memory and swap utilization is continuously displayed and that clearly shows resources declining. Try closing your chromium at night and see if that fixes the problem. If you have never tried gkrellm (sysutils/gkrellm2), it is a the best system monitor I have found. though pulls in a lot of dependencies. It also can run as a server with remote systems displaying the data. Handy to monitor servers. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: FreeBSD12-RC2 and bluetooth?
On Thu, Sep 15, 2016 at 10:07 PM, Takanori Watanabe wrote: > On Thu, Sep 15, 2016 at 07:20:39PM -0700, Steven G. Kargl wrote: > > On Thu, Sep 15, 2016 at 06:20:06PM -0700, Adrian Chadd wrote: > > > hi, > > > > > > bluetooth uses netgraph. > > > > > > > Yeah, I figured that much out. I do not > > need bluetooth nor netgraph. How does > > one explicitly disable this (other than > > through the BIOS)? > > > devd(8) automatically load them. > Remove /etc/devd/usb.conf . > (I really hate the behavior .:-P) > Rather than removing all devd support for USB devices, look at the device probe in dmesg or in the output of usbconfig and find the matching entry in /etc/devd/usb.conf and remove it. Look for matching product and vendor codes. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: PORTS_MODULES breakage on HEAD
On Sun, Aug 7, 2016 at 5:44 PM, Don Lewis wrote:
> Adding PORTS_MODULES=emulators/virtualbox-ose-kmod recently broke on
> HEAD. When I do that I get this failure:
>
> ===> Ports module emulators/virtualbox-ose-kmod (all)
> cd ${PORTSDIR:-/usr/ports}/emulators/virtualbox-ose-kmod;
> PATH=/usr/obj/usr/src/
> tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/
> usr/obj/usr/src/tmp/leg
> acy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/
> usr/bin:/sbin:/bin:/u
> sr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin SRC_BASE=/usr/src
> OSVERSION=12
> 0 WRKDIRPREFIX=/usr/obj/usr/src/sys/ make -B clean all
> ===> Cleaning for virtualbox-ose-kmod-5.0.26_1
> ===> License GPLv2 accepted by the user
> ===> Found saved configuration for virtualbox-ose-kmod-4.3.34
> ===> virtualbox-ose-kmod-5.0.26_1 depends on file: /usr/local/sbin/pkg -
> found
> ===> Fetching all distfiles required by virtualbox-ose-kmod-5.0.26_1 for
> buildin
> g
> ===> Extracting for virtualbox-ose-kmod-5.0.26_1
> => SHA256 Checksum OK for VirtualBox-5.0.26.tar.bz2.
> ===> Patching for virtualbox-ose-kmod-5.0.26_1
> ===> Applying FreeBSD patches for virtualbox-ose-kmod-5.0.26_1
> ===> virtualbox-ose-kmod-5.0.26_1 depends on executable: kmk - found
> ===> Configuring for virtualbox-ose-kmod-5.0.26_1
> Checking for environment: Determined build machine: freebsd.amd64, target
> machin
> e: freebsd.amd64, OK.
> Checking for kBuild: found, OK.
> Checking for gcc:
> ** cc -target x86_64-unknown-freebsd12.0 --sysroot (variable CC) not
> found!
> Check /usr/obj/usr/src/sys/usr/ports/emulators/virtualbox-
> ose-kmod/work/VirtualB
> ox-5.0.26/configure.log for details
> ===> Script "configure" failed unexpectedly.
> Please report the problem to v...@freebsd.org [maintainer] and attach the
> "/usr/obj/usr/src/sys//usr/ports/emulators/virtualbox-
> ose-kmod/work/VirtualBox-5
> .0.26/config.log"
>
>
> It appears that the problem is due to CC being set to:
> cc -target x86_64-unknown-freebsd12.0 --sysroot
> and the Makefile for the port passes this:
> --with-gcc="${CC}"
> to configure. The configure script passes $CC to check_avail, which
> does a -z test on it.
>
> I think that CC should just be set to "cc" and the rest should get added
> to CFLAGS. I suspect this got broken by the recent crossbuild changes.
>
> ___
> 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"
>
Same issue on 11.0-BETA4 (and at least BETA3). It's not just HEAD.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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: Xen networking problems in -current with xn driver?
On Tue, Aug 2, 2016 at 11:12 AM, Julian Elischer wrote: > I upgraded my VPS machine to today's current, and on reboot I couldn't get > into it by network. > > A quick switch to the VNC console showed that it was up but that it > couldn't get out. > > > The xn interfaces said they were UP but attempts to get out were met with > "network is down". > > if I did 'tcpdump -n -i xn0' (and xn1) hten all was fine again. > > tcpdump saw packets, and in fact ipfw saw some packets coming in even > before that but it was not possible to send. > > > Has anyone seen similar? > > some relevant parts of the dmesg output.: > > [...] A bit of a guess, but the obvious thing that I see is that when you start tcpdump you are placing the interface in promiscuous mode. Looks like the "device" fails to properly see packet addressed to it. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: Digi Watchport/T temperature sensor as /dev/ttyU
1 interfaces. > > > > root@thor: [src] man ugensa > > > > No manual entry for ugensa > > > > root@localhost: [src] ll /dev/cuaU0* > > > > 203 crw-rw 1 uucp dialer - 0xcb Jul 24 07:51 /dev/cuaU0 > > > > 204 crw-rw 1 uucp dialer - 0xcc Jul 24 07:51 > > > > /dev/cuaU0.init > > > > 205 crw-rw 1 uucp dialer - 0xcd Jul 24 07:51 > > > > /dev/cuaU0.lock > > > > > > > > > > > > I'll try now to get informations out of the device, I let you > > > > know whether that is a > > > > success. But anyway, again, thank you for helping making the > > > > device visible and > > > > available. > > > > > > > > > I had no luck with retrieving informations out of the device by the > > Perl5 script provided > > by Nagios.org. A prerequisite for the Perl script is the FreeBSD port > > > > comms/p5-Device-SerialPort > > > > Patching the script is trivial, but I do not know whether the > > backend, > > comms/p5-Device-SerialPort, works a sexpected. So the first, dirty, > > trial ended up in > > nothing - since the information gained from the sensor is an empty > > string/nothing. > > > > I'm not familiar with serial devices, so far, so probably there is > > something trivial > > missing. > > I looked around for some info on these Watchport devices. Their manual > indicates that they use both serial comms to send commands and receive > data, and they use serial-comms modem control signals (RTS/CTS, DTR, > etc). Some googling makes it look like they use a TI 5052 USB serial > chip. On linux, that would be handled by the io_ti USB serial driver. > > All of that adds up to the freebsd ugensa driver (which is "generic > serial IO") probably not working. The ugensa driver has nothing chip > -specific in it, it's for accessing devices which can do bulk > read/write without needing to configure any of the other serial comms > parameters. The ugensa driver works with things like gps receivers > that have simple text-only interfaces. > > I think these watchport devices will likely need real serial comms > configuration -- baud rate at least, to even be able to talk to them. > In other words, freebsd needs a real driver for TI 5052 chips. It > looks like a fairly complete datasheet for the chip is available (but I > don't have time to write a driver myself). > > -- Ian > There are several different USB serial drivers. Off-hand I see ubser, ubsa, uchcom, ucom, ucycom, uftdi, ubgensa, umcs, umct, umoscom, uplcom, usb_serial, uslcom, and uvscom. Whether any of these will support the TI chip, I can't say. Most have man pages, but a few, as has been noted, are lacking one. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: GOST in OPENSSL_BASE
On Tue, Jul 12, 2016 at 5:33 AM, Daniel Kalchev wrote: > > > On 12.07.2016 г., at 13:26, Franco Fichtner > wrote: > > > > > >> On 12 Jul 2016, at 11:59 AM, Daniel Kalchev wrote: > >> > >> It is trivial to play MTIM with this protocol and in fact, there are > commercially available “solutions” for “securing one’s corporate network” > that doe exactly that. Some believe this is with the knowledge and approval > of the corporation, but who is to say what the black box actually does and > whose interests it serves? > > > > It's also trivial to ignore that pinning certificates and using client > > certificates can actually help a great deal to prevent all of what you > > just said. ;) > > I don’t know many users who even know that they can do this — much less > actually using it. Pinning the browser vendor’s certificates does not > protect you from being spied while visiting someone else’s site. This is > also non-trivial to support. > In the early days of DANE, Google even had a version of Chrome that > supported DANE, just to kill it a bit later: > https://www.ietf.org/mail-archive/web/dane/current/msg06980.html > > > > > The bottom line is not having GOST support readily available could > alienate > > a whole lot of businesses. Not wanting those downstream use cases will > make > > those shift elsewhere and the decision will be seen as an overly > political > > move that in no possible way reflects the motivation of community growth. > > > Exactly — especially as long as there is no demonstrable proof that GOST > is actually broken. I may have been misunderstood, possibly because I was unclear. I do not object to GOST being readily available as it is legally required in some places. I do object on its being enabled by default and I do object to standards endorsing it use, though I do not object to standards for GOST, itself. Making the method for enabling GOST simple and clearly documented is a reasonable thing and, as long as its use is mandated it is really essential. And, thinks, Andrey, for clarifying the Russian law. I don't know the language and have depended on others for the details. In areas of tine points of laws, this is often inadequate. (As it is when you read the language fluently. I read and speak American English quite well, but that does not mean that legalese is covered.) Reality is that the law is what those charges with formal interpretation of it say it is. In the US, that is the Supreme Court. Not sure who is in Russia, but it's not me!) -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: GOST in OPENSSL_BASE
On Mon, Jul 11, 2016 at 3:51 PM, Andrey Chernov wrote:
> On 12.07.2016 1:44, Andrey Chernov wrote:
> > On 11.07.2016 21:41, Slawa Olhovchenkov wrote:
> >> On Mon, Jul 11, 2016 at 02:28:45PM -0400, Jung-uk Kim wrote:
> >>
> >>> On 07/10/16 10:10 AM, Andrey Chernov wrote:
> >>>> On 10.07.2016 16:30, Slawa Olhovchenkov wrote:
> >>>>> I am surprised lack of support GOST in openssl-base.
> >>>>> Can be this enabled before 11.0 released?
> >>>>
> >>>> AFAIK openssl maintainers says something like they can't support this
> >>>> code and it will become rotten shortly with new changes, so they drop
> it.
> >>>
> >>> [OpenSSL-maintainer-for-the-base hat on]
> >>>
> >>> GOST is supported on FreeBSD 10.x and 11.x. We will not drop it on
> >>> these branches unless secteam explicitly ask us to do so. However, we
> >>> *may* drop it from 12.0 *iff* we import OpenSSL 1.1.0 branch.
> >>>
> >>> [OpenSSL-maintainer-for-the-base hat off]
> >>>
> >>> Jung-uk Kim
> >>>
> >>
> >> Thanks!
> >>
> >> May be need file PR for dns/bind910?
> >>
> >> # grep -3 BROK /poudriere/ports/default/dns/bind910/Makefile
> >> .include
> >>
> >> .if ( ${PORT_OPTIONS:MGOST} || ${PORT_OPTIONS:MGOST_ASN1} ) &&
> ${SSL_DEFAULT} == base
> >> BROKEN= OpenSSL from the base system does not support GOST, add \
> >> DEFAULT_VERSIONS+=ssl=openssl to your /etc/make.conf and
> rebuild everything \
> >> that needs SSL.
> >> .endif
> >>
> >
> > I dislike idea to use GOST in the bind, it is unneeded there, DNSSEC
> > don't use GOST, so I vote for removing GOST option from there.
> >
>
> I need to note that RFC exists, proposing GOST (old version) for DNSSEC:
> https://tools.ietf.org/html/rfc5933
> but nobody really use it.
In case people are not aware of it, Russian law now requires ALL encrypted
traffic must either be accessible by the FSB or that the private keys must
be available to the FSB. I have always assumed that GOST has a hidden
vulnerability/backdoor that the FSB is already using, but this makes it
mandatory. Putin gave the FSB 2 weeks to implement the law, which is
clearly impossible, but I suspect that there will be a huge effort to pick
all low-hanging fruit. As a result, I suspect no one outside of Russia will
touch GOST. (Not that they do now, either.) I'd hate to see its support
required for any protocol except in Russia as someone will be silly enough
to use it.
(It's not possible because it requires the 6 month storage of all Internet
data and voice communications which will require the immediate installation
of massive amounts of storage, not to mention the floor space, cooling, and
power to support those disks.)
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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: console in 11.0-ALPHA4
On Mon, Jun 20, 2016 at 6:01 PM, Ernie Luzar wrote: > John Baldwin wrote: > >> On Monday, June 20, 2016 04:54:11 PM Ernie Luzar wrote: >> >>> Ed Maste wrote: >>> >>>> On 20 June 2016 at 14:29, Ernie Luzar wrote: >>>> >>>>> I found the cause of this boot time message >>>>> "vicontrol: setting cursor type: Inappropriate ioctl for device" >>>>> >>>>> In my rc.conf I had this statement >>>>> vidcontrol -c blink -h 250 >>>>> From testing it seems that vt does not handle the "blink" option for >>>>> causing >>>>> the cursor to blink. Is there a vt option to enable cursor blinking >>>>> >>>> I've submitted two PRs for the issues you reported here: >>>> Bug 210413 - vidcontrol -c does not work >>>> with vt(4) >>>> Bug 210415 - vidcontrol -h does not work with vt(4) >>>> (edit) >>>> >>>> There is currently no option to enable cursor blinking. >>>> >>> >>> Further testing shows that: >>> >>> 1. The rc.conf option screen saver "saver= " and the "blanktime= " >>> options work in vt for both text and graph modes. >>> >>> 2. The cursor copy/paste does not work in vt text mode. It only works in >>> vt graph mode. vt needs to be fixed so copy/paste function also works in >>> text mode. >>> >>> 3. Boot time splash screen does not work in vt at all no matter which >>> mode is enabled. Using this in loader.conf >>> splash_bmp_load="YES" >>> bitmap_name="/boot/splash.bmp" >>> bitload_load="YES" >>> >>> This works in 10.x. The splash screen function can not be allowed to be >>> removed from the base system just because vt can not handle it. This also >>> means any vt changes need to updated in the handbook section on splash >>> screen. >>> >>> In conclusion, vt is not ready to replace the sc console driver yet. vt >>> needs to be fixed before becoming the default in 11.0. Using vt as the >>> default console driver effects every user. It completely changes the >>> FreeBSD experience. It's detrimental to the public relations and the >>> professional image of FreeBSD to publish the 11.0-RELEASE using vt in its >>> current condition. If time doesn't permit to get these vt things fixed >>> before publishing 11.0 then vt should not become the default console driver. >>> >> >> OTOH, if you use EFI, then you can't use sc(4). You get no working >> console >> with EFI (which is becoming more popular) if you use sc(4). You also do >> not get non-ASCII characters with sc(4), so you don't have a UTF-8 capable >> console if you use sc(4). You also do not have a working console after >> loading the KMS drivers (either by starting X or via explicit kldload) >> when >> using sc(4). This affects just about every modern Intel system using an >> Intel GPU (so more widespread than EFI even). >> >> There are trade offs in both directions. Neither console is a subset of >> the >> other. However, sc(4) is not really expendable to support the things it >> is >> missing. vt(4) is actively worked on, and patches for the features it >> lacks >> that you need are certainly welcomed. >> >> > This sounds like a integration design error. From your description of the > hardware that vt is designed for and sc is designed for indicates the need > for some code to be added to the boot process that inspects the hardware > and decides whether vt or sc is to be launched. Or maybe bsdinstall should > inspect the hardware and give the installer the option to select what > console is best for his hardware. Just forcing this version of vt that > lacks long time functions as the default console driver is not the > professional way to handle such conflicts. > > I am at a lost to understand how any development administrator would > approve making vt the default console driver in light of the standard > functions missing from it. And furthermore what kind of vt testing was done > that these problems were missed. Any one of these problems is enough cause > to reverse the decision to make vt the default console driver for 11.0. > This would give time for these problems to be address and correctly tested > and when ready then be paced in some other 11.x release. There is really no choice. vt(4) will work as a basic console on all platforms. sc(4) works
Re: Virtualbox kernel module on 11-CURRENT
On Tue, Jun 7, 2016 at 1:04 AM, Guido Falsi wrote: > On 06/07/16 02:23, Rafael Rodrigues Nakano wrote: > > Hello, > > > > I tried installing virtualbox from packages, building it from sources, > > trying the GENERIC kernel but everytime I can't start the kernel module > > 'vboxdrv', it says: > > "KLD vboxdrv.ko: depends on kernel - not available or version mismatch. > > linker_load_file: Unsupported file type" > > > > The virtualbox module needs to be in full sync with the kernel. Most > probably the sources being used by the cluster for building packages on > head are a little different from yours, so the kernel module is not in > sync. > > You will need to build the kernel module yourself to actually match your > kernel sources. > > It's not really a problem or a bug, it's how it works. On head there is > no warranty about the KBI. This cannot happen on releases and stable > because the KBI is not going to change there. > > -- > Guido Falsi > I don't think this is true. While shareable libraries have fixed ABIs, I believe the KBI can change even in STABLE branches. If a security fix requires it, it might even change in a RELEASE. I my be wrong about this, but I recall having to re-build the VB kmod port even withing a minor version (i.e. STABLE). In any case, I do strongly recommend the use of PORTS_MODULES in /etc/src.conf to assure that the kernel modules always get re-built when the kernel is re-built. so that the sources, the kernel, and the module are in sync. The PORTS_MODULES are re-installed as a part of the "make installkernel", so things are almost safe, but beware of "make reinstallkernel" as it does not do the right thing. (See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201779) -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: Suddenly poweroff in 11-Current r300097
On Thu, Jun 2, 2016 at 10:29 PM, RayCherng Yu wrote: > OK, thanks. > I will load coretemp to monitor the cpu temperature. > I have enabled powerd to have cpu frequency adjustment automatically. And > it won't happen when AC power supply connected. > This is why I suspect the power profile or Cx-states are involved as they are, by default, different for AC and battery power. But, also by default, they should make things worse when on AC, so I may be quite wrong. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: Suddenly poweroff in 11-Current r300097
On Thu, Jun 2, 2016 at 1:46 PM, O. Hartmann wrote: > Am Thu, 2 Jun 2016 10:26:22 -0700 > Kevin Oberman schrieb: > > > On Thu, Jun 2, 2016 at 7:41 AM, Hans Petter Selasky > wrote: > > > > > On 06/02/16 03:07, RayCherng Yu wrote: > > > > > >> I got a suddenly poweroff in r300097 (and previous revision in April > and > > >> May) when I built textproc/docproj. > > >> My machine is Macbook Pro 13 2011 early. I have checked the Apple > website. > > >> My bios is the latest version. > > >> Actually it also happened in 10.3-STABLE. > > >> It happened when the machine load was heavy. Before it shutdown, the > fan > > >> started to run very loudly. After several seconds (20 or 30 seconds), > my > > >> laptop shutdown (poweroff directly) suddenly. It seems not happen > with the > > >> AC power supply connected. > > >> > > >> I installed both Mac OSX and FreeBSD (dual boot). It never happened > in Mac > > >> OSX. > > >> > > >> My dmesg: > > >> http://pastebin.com/QjZmbGCB > > >> > > >> My sysctl hw.acpi: > > >> > > >> hw.acpi.acline: 0 > > >> hw.acpi.battery.info_expire: 5 > > >> hw.acpi.battery.units: 1 > > >> hw.acpi.battery.state: 1 > > >> hw.acpi.battery.time: 87 > > >> hw.acpi.battery.life: 59 > > >> hw.acpi.cpu.cx_lowest: C8 > > >> hw.acpi.reset_video: 0 > > >> hw.acpi.handle_reboot: 1 > > >> hw.acpi.disable_on_reboot: 0 > > >> hw.acpi.verbose: 0 > > >> hw.acpi.s4bios: 0 > > >> hw.acpi.sleep_delay: 1 > > >> hw.acpi.suspend_state: S3 > > >> hw.acpi.standby_state: NONE > > >> hw.acpi.lid_switch_state: NONE > > >> hw.acpi.sleep_button_state: S3 > > >> hw.acpi.power_button_state: S5 > > >> hw.acpi.supported_sleep_state: S3 S4 S5 > > >> > > >> > > > Hi, > > > > > > Do you have a temperature sysctl? Usually FreeBSD will shutdown the > system > > > if the ACPI temperature exceeds some value. Maybe it would be better to > > > reduce the CPU load when the temperature goes up instead of facing a > > > shutdown? > > > > > > --HPS > > > > > > The relevant information is probably found in dev.cpu. That is where all > > temperature information is located as it is per-CPU, not per-system. Of > > particular interest is dev.cpu.0.cx_lowest, dev.cpu.0.cx_supported, and > > dev.cpu.0.freq_levels. A snapshot of dev.cpu.0 when the fan has cranked > up, > > but before shutdown would be nice, too. > > > > I see no hw.acpi.thermal information. This is very odd. These values > > indicate what the system will do and is doing if it starts getting too > hot. > > > > Is coretemp loaded? It is required to see the core temperatures and those > > are almost certainly significant. It may account for the lack of thermal > > information. Finally, a dmesg might be useful as it will tell us more > about > > just what thermal control techniques are enabled. > > > > Just to explain a bit on how this should work: when the temperature > exceeds > > some BIOS defined point, the system should "throttle" by pausing one of > > every 8 clock cycles. If that does not fix the problem, the it rests for > > two of every 8 and so on until the temperature is reduced. If it > continues > > to rise and reaches another BIOS set point, it will initiate an emergency > > shutdown. If it reaches a CPU defined temperature, the power will shut > off > > immediately. Note that this is entirely a hardware function with no BIOS > or > > OS involvement. It should NEVER happen in normal operation as it is > > triggered by a significant overtemp that threatens to destroy the CPU. > I've > > only seen it once when the CPU heat sink came loose on an old P4 system > > several years ago. > > > > I should mention that I have zero experience with Apple hardware and it > is > > possible that they do some things differently than I have seen on other > > hardware. > > -- > > Kevin Oberman, Part time kid herder and retired Network Engineer > > E-mail: rkober...@gmail.com > > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > I have had such problems many times with older hardware. In most cases > "dried out" > thermal conductive pad or grease was the reason overheating the CPU du to > a ineffective >
