Re: What is evdev and autoloading?
On 02/18/19 10:50, Rodney W. Grimes wrote: >> On Mon, Feb 18, 2019 at 9:12 AM Rodney W. Grimes < >> freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: >> >>>> On Mon, Feb 18, 2019 at 07:12:24AM -0800, Rodney W. Grimes wrote: >>>>>> On 2/18/19 12:06 PM, Stefan Blachmann wrote: >>>>>>> On 2/18/19, Vladimir Kondratyev wrote: >>>>>>>> On 2019-02-17 21:03, Steve Kargl wrote: >>>>>>>>> Anyone have insight into what evdev is? >>>>>>>> evdev.ko is a small in-kernel library that makes all your input >>> events >>>>>>>> like keyboard presses libinput-compatible. That's... wrong. evdev has nothing to do with libinput. Rather, it can be used by libinput, but I never once used libinput on FreeBSD/X11. I used xf86-input-evdev. evdev is a generic event device subsystem originated in the Linux kernel. > But it DOES work, I am pretty sure we have 1000's of users on that 5 year > old hardware that are totally happy with the intree DRM2 that is in stable/12, > and some of whom have ventured into head/13 are having issues with the > "new" model (ie kmod broken by a base commit). > > I think one serious problem here is the summary dismissal of things > simply on the "5 year old" basis. Not everyone, and infact few now > a days other than corporate buyers, can afford new hardware, > giving the minimal performance increase in systems over the last 5 > years the cost/benifit factor of a new computer is just too low. That's the primary reason I don't focus on FreeBSD any more, and the primary reason when I have sudden time crunches, FreeBSD stuff is the first to go out the window. It's not that I don't like FreeBSD any more, it's that it just doesn't fit in with my ideas on how a system project should be run, or how it should prioritise. And that isn't really a comment on FreeBSD, nor me, it's just a statement. Everyone's different. Perhaps all the people who are upset at FreeBSD becoming the next OS X (you must have hardware *this* *new* to run!) should start putting more effort in to keeping the old hardware alive and working in the processes defined by FreeBSD. Make proposals, participate and communicate on MLs (instead of just complain), etc. This is all just observations I've made over the last few months of reading -current and not really contributing much. Apologies if I'm off the mark on any of this. Best to you and yours, --arw -- A. Wilcox (awilfox) Open-source programmer (C, C++, Python) https://code.foxkit.us/u/awilfox/ signature.asc Description: OpenPGP digital signature
Re: FreeBSD 12 PowerPC won’t boot at all.
On 10/04/18 06:34, Alex McKeever wrote: > Subject says it all, that and it inverts the boot selector when > selected. Tested it on my eMac G4 1.25 GHz (Retail). Last version of > FreeBSD that works for me is 11.1, as 11.2 doesn’t boot all the way > (hangs on cryptosoft0) Is this beta8 or an earlier revision? There's been some (small, but good) work on powerpc[,64] in the 12 release cycle so I'm just wondering if hopefully it might work better on a more recent snapshot. --arw -- A. Wilcox (awilfox) Open-source programmer (C, C++, Python) https://code.foxkit.us/u/awilfox/ signature.asc Description: OpenPGP digital signature
Re: [RFC] Deprecation and removal of the drm2 driver
>>>>> I just ask.
>>>>> Or why not include drm-next to base svn repo and add some
>>>>> option to make.conf to swith drm2/dem-next ?
>>>>
>>>> Even if it's not being built on amd64 we're still responsible for
>>>> keeping it building on !amd64 so long as it's in base. This makes
>>>> changing APIs and universe runs more burdensome. The graphics
>>>> developers have given you notice that it will now be your collective
>>>> responsibility to keep it up to date.
>>>>
>>>
>>> Not quite. One graphics developer has indicated a desire
>>> to remove working code, because it interferes with the
>>> graphics developers' port on a single architecture. There
>>> is no indication by that graphics developer that drm2 will
>>> be available in ports. You can go read the original post
>>> here:
>>>
>>> https://lists.freebsd.org/pipermail/freebsd-current/2018-May/069401.html
>>>
>>> The last paragraph is
>>>
>>>What does the community think? Is there anyone still using
>>>the drm2 driver on 12-CURRENT? If so, what is preventing
>>>you from switching to the port?
>>>
>>> The answer to the last two questions are "yes" and "the port
>>> does not work on i386".
>>>
>>> Yes, I recognize that you're clever enough to purposefully
>>> break the API so that you can thumb your nose at those of
>>> us who have older hardware.
>>>
>>> What is wrong with using
>>>
>>> .if ${MACHINE_ARCH} != amd64
>>> ...
>>> .endif
>>>
>>> to enable/disable drm2?
>
> With such long-time support offered by 11- branch, why hamper development
> of 12 by lugging around old, hard to maintain code that is relevant for
> only legacy hardware?
>
it makes me giggle that people still think non-amd64 is "legacy".
i386 is alive and well - new chips are being fabbed based on the 586
design with pci-e slots; not to mention things like the Talos and
AmigaOne for PowerPC.
--arw
--
A. Wilcox (awilfox)
Open-source programmer (C, C++, Python)
https://code.foxkit.us/u/awilfox/
signature.asc
Description: OpenPGP digital signature
Re: From LLVM: I got a note that LLVM plans to remove PPC64's V1 abi support; I'm asked about what support there is for the PPC64 little-endian/V2 abi (see forwarded message)
On 03/28/18 13:38, Nathan Whitehorn wrote: > Is this big-endian support or V1 support being removed? We support > the V2 ABI fully on FreeBSD, but not (yet) little-endian. Like on > Linux, the default ABI on big-endian will likely remain V1 for the > indefinite future, This is an important distinction to make (big-endian != ELFv1, and ELFv1 != big-endian). But do note that on Linux, the musl libc (in use by distros like Alpine, Adélie, postmarketOS) only supports ELFv2, even in big-endian mode. And as the maintainer of Adélie using it as a daily-driver on an iMac G5, it's definitely something you can use (the only breakage I've seen so far on Linux is the PCRE JIT ignoring __CALL_ELF and inserting function descriptors anyway). So I wouldn't discount moving to ELFv2 ABI on BE if that is necessary to keep LLVM happy. It'd be some effort but it should work. If this is really something FreeBSD is interested in, you might even manage to convince me to put on my ports hat again, to help get the JIT patches in that are needed for upstreams that went comatose. Best, --arw > however, and it would be good if it were at least simple to re-add > support at some later date. -Nathan > -- A. Wilcox (awilfox) Open-source programmer (C, C++, Python) https://code.foxkit.us/u/awilfox/ signature.asc Description: OpenPGP digital signature
Re: Skylake/Kabylake Intel Bug?
On 25/06/17 12:56, Pete Wright wrote: > Came across this post today via HN regarding a issue with Hyperthreading > causing unpredictable behavior on these CPU's > > https://lists.debian.org/debian-devel/2017/06/msg00308.html > > I really wish there was more info on this in the email, for example > examples of programs being effected by this bug. Anywho - was wondering > if any devs here had more info on this issue and could provide better > context? > > Cheers, > > -pete > The linked OCaml issue goes quite in-depth with the mechanisms behind this bug and the risks behind not patching the microcode: https://caml.inria.fr/mantis/view.php?id=7452 Basically, if a HyperThreaded core is running a tight loop accessing %rax and %ah (or %rbx and %bh, etc) in quick succession, on both threads of the same physical core, it can corrupt/poison L1d cache. AIUI, OCaml manages to generate this code by manipulating tagged memory addresses and the corresponding tag (the address is in %rax, and the tag is at %ah). I'd really love to see if this affects write-through-no-allocate cache or only write-behind, but I haven't seen any program besides OCaml actually manage to get GCC to generate the insn pattern that is needed, and I don't have a Skylake or Kaby Lake CPU to test with anyway. Fun little hardware bug. Hope this helps you, --arw -- A. Wilcox (awilfox) Open-source programmer (C, C++, Python) https://code.foxkit.us/u/awilfox/ signature.asc Description: OpenPGP digital signature
Re: PowerMac G5 and KMS
On 02/03/17 11:37, Justin Hibbits wrote: > On Thu, Mar 2, 2017 at 5:42 AM, Hiroo Ono (小野寛生) > wrote: >> kernel: drmn0: on vgapci0 >> kernel: info: [drm] RADEON_IS_AGP >> kernel: info: [drm] initializing kernel modesetting (RV350 0x1002:0x4150 >> 0x1002:0x4150). > > Congratulations (?) you are quite possibly the first person to report > even attempting to use radeonkms on powerpc64. It works fine on Debian Jessie for me, so I would assume that it should be at least possible to do the same on FreeBSD with some tweaking. The only FreeBSD install I have on a PPC is serial console only so I haven't really used graphics on it. > Do you know what card this is? It looks like a Radeon 9600 RV350 from the pasted kernel log, which is consistent with the Radeons that Apple shipped with the early G5 DPs. Note to OP: if you can manage to get it to work, the framebuffer works great, but Mesa still has some endianness issues. There are a few of us in the Linux and BSD world that are doing what we can to fix it, but there's not a whole lot of us, so progress is slow going. You'll have a lot more luck with NV30/NV40/NV50 cards if you want OpenGL for now. As I have a PowerBook G4 with a RV350, which obviously cannot be replaced as it is a laptop, that should change soon hopefully. Best, --arw -- A. Wilcox (awilfox) Open-source programmer (C, C++, Python) https://code.foxkit.us/u/awilfox/ signature.asc Description: OpenPGP digital signature
Re: ISO image: where is the CLANG compiler?
On 19/01/17 03:16, O. Hartmann wrote: > I created images on CURRENT of my own - they all lack in the ability of having > the necessary tools aboard. So I consider every image useless for rescue > operations except, maybe, the DVD image - but this one is not provided > anymore. > For what reason? Time? Accepted. Space/disk usage? Well, welcome back in the > stoneage of computer technology ... > > I remember faintly that there was a small discussion on the @CURRENT list, but > I didn't realize that the result would be the extraction of the compiler. > > Just for the record: most servers delivered to us do not have CD/DVD drives > anymore - they are outdated and considered an extra these days. Purchasing 1 > GB > USB thumbdrives is getting even harder, smallest size my employer provides now > is 2 GB. And most optical drives are DVD. From my point of view - and this is > a > personal view - the "standard" is > 1GB so there is no need to break down by > force the FreeBSD image (if size is the reason) down to < 800 MB or < 1 GB. > I'd > consider having < 2GB the line of standards (2 GB USB mem drive). > And for those, with need of very small images, smaller images could be > provided > as the extra. Installation media is not rescue media. Perhaps there should be a dedicated rescue disc that does not contain bsdinstall and the sets (we used to have "fixit" media until at least 8.x days). Everything else I have to say, I have said before: Forwarded Message Received: (qmail 20810 invoked from network); 12 Jul 2016 21:08:51 - Subject: Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r To: freebsd-current@freebsd.org From: A. Wilcox Message-ID: <5785692e.8090...@wilcox-tech.com> Date: Tue, 12 Jul 2016 17:03:26 -0500 In-Reply-To: <51734d0a-60da-6439-b5c1-1af14e740...@multiplay.co.uk> On 12/07/16 15:58, Steven Hartland wrote: > On 12/07/2016 21:50, Slawa Olhovchenkov wrote: >> On Tue, Jul 12, 2016 at 01:39:34PM -0700, Conrad Meyer wrote: >> >>> Maybe Tier 2 can deal with just bootonly.iso. Or your machines should >>> be dropped from Tier 2 if they don't support USB and we aren't okay >>> with dropping disc1 support for all of Tier 2. That is pretty much all SPARC hardware and a lot of POWER hardware. Not to mention newer rack-mount servers that have no USB on front (IBM). And what of the servers that already have functional CD drives? Do we really now have to recommending buying SCSI/SATA slimline or USB DVD drives just to boot installation media? That's a heavy cost when you can fit nearly all other BSDs on a single regular 650 (84 MB for NetBSD 7.0.1 + 223 MB for OpenBSD 5.9 + 385 MB for "TrueOS"/PC-BSD Server 10.3 = 692 MB, all sizes amd64 install iso including sets). >> Not all BIOS can be boot from USB. >> I am have Fujitsu notebook not support USB boot. > From a USB Pen drive I can understand but from a USB DVD Drive that > would be some seriously antiquated hardware! I have a Core 2-era Xeon board (Wolfdale-DP, Intel 5000 based) that cannot under any circumstances boot from a connected USB device. It won't boot from a USB DVD, USB CD, USB pen, or USB hard disk (USBMSC). I hardly consider a server that is 7 years old "antiquated" though I concede it is not the newest. Beyond that, there are security issues with allowing servers to boot off of any random USB device that an admin has lying around. Most will be configured by good admins to not do such a thing. In summary: NAK NAK NAK. USB is not a solution. Bringing down the bloat on disc1 or returning to miniinst is the proper solution. ~arw -- A. Wilcox (awilfox) Open-source programmer (C, C++, Python) https://code.foxkit.us/u/awilfox/ signature.asc Description: OpenPGP digital signature
Re: Enabling NUMA in BIOS stop booting FreeBSD
On 14/12/16 13:48, Slawa Olhovchenkov wrote: > On Wed, Dec 14, 2016 at 09:43:24PM +0200, Konstantin Belousov wrote: > >> On Wed, Dec 14, 2016 at 10:29:43PM +0300, Slawa Olhovchenkov wrote: >>> On Wed, Dec 14, 2016 at 09:03:49PM +0200, Konstantin Belousov wrote: >>> >>>> On Wed, Dec 14, 2016 at 06:26:27PM +0300, Slawa Olhovchenkov wrote: >>>>> For test hardware setup (NUMA+interleave), what ISO I can try to boot? >>>> Didn't you already tried ? >>> >>> Different from FreeBSD. >> Can you reformulate the statement ? >> Did you booted some other (non-FreeBSD) OS and it hung with that options >> as well ? > > No, I don't try now, can you advice some OS for test? Ugh, Supermicro is big pain. Try CentOS, also try Debian. Just to see. Maybe you get lucky, and one of them hangs too... Debian usually runs older kernels, so more likely to not have a workaround. Best solution: new mainboard vendor, until Supermicro works out their dumb firmware and makes it less dumb. :( --arw -- A. Wilcox (awilfox) Open-source programmer (C, C++, Python) https://code.foxkit.us/u/awilfox/ signature.asc Description: OpenPGP digital signature
Re: Enabling NUMA in BIOS stop booting FreeBSD
>>>> Try the debugging patch below, which unconditionally disables import of >>>> previous buffer. To test, you would need to boot, then frob options in >>>> BIOS, reboot, again frob etc. >>> >>> still need test patch? if yes, with BIOS options? >> Yes, please test the patch. I explained the procedure above. > > sorry, i don't know 'frob'. > what exactly options combination I need test and what about memory test? > The idea is that when rebooting, stale memory contents remain, but are corrupted due to interleave. "Frob" basically means "mess with". So apply patch, test kernel, reboot, change NUMA option, reboot again, see if it works, and so on. Basically repeat your test with the NUMA=on interleave=on, NUMA=off interleave=on, etc etc. hth, --arw -- A. Wilcox (awilfox) Open-source programmer (C, C++, Python) https://code.foxkit.us/u/awilfox/ signature.asc Description: OpenPGP digital signature
Re: Mac OS X on bhyve
On 09/12/16 02:16, Matthias Gamsjager wrote: > On 9 December 2016 at 04:16, A. Wilcox wrote: >> If you do have the proper type of Mac OS X that can be virtualised >> legally on PC hardware, you still need the SMC to be emulated. That >> will need to be added to bhyve before you could boot Mac OS X natively, >> i.e. without hacks. >> >> > The hacktingtosh community did quite a lot of work in that aspect. Eg. the > Clover bootloader which most use to start OSX on normal PC hardware And VirtualBox can boot Mac OS X without any bootloader or hacking, so it is much more stable, and resilient to automatic updates (which you need much experience to disable on newer releases, including macOS Sierra). Note that if you have an AMD CPU, your options will be limited. I'm unaware of any bhyve option to customise the CPUID presented to the guest (it may be undocumented, but I doubt it - the team is very good at docs). If you have an AMD CPU, you will need Clover and likely a patched mach_kernel for AMD support. I thought all this knowledge would be useless, three years after I retired my last full-time OS X box... Who knew... --arw -- A. Wilcox (awilfox) Open-source programmer (C, C++, Python) https://code.foxkit.us/u/awilfox/ signature.asc Description: OpenPGP digital signature
Re: Mac OS X on bhyve (was: Is there possible run a MacOS X binary)
On 08/12/16 20:34, Shane Ambler wrote: > Now that bhyve has gui support can OSX be started as a bhyve guest? Depending on version and edition of Mac OS X, this may or may not be a legal suggestion; Apple has made various terms in their license that you can only virtualise Mac OS X on Apple-branded hardware. (Some creative types from a virtualisation forum once suggested taking the Apple stickers from the iPhone box and placing them on your PC, making it Apple branded. Not sure that would stand up in court.) If you do have the proper type of Mac OS X that can be virtualised legally on PC hardware, you still need the SMC to be emulated. That will need to be added to bhyve before you could boot Mac OS X natively, i.e. without hacks. > Has anyone tried to get an openfirmware loader running? Do current macs > still use openfirmware? OpenFirmware is used primarily on PowerPC, MIPS, and SPARC (via OpenBoot). I've also seen it running on a few ARM SoCs. I don't think I've ever seen a conformant implementation for x86. All Intel Macs use EFI 1.10 with Apple extensions. hth, --arw -- A. Wilcox (awilfox) Open-source programmer (C, C++, Python) https://code.foxkit.us/u/awilfox/ signature.asc Description: OpenPGP digital signature
Re: Optimising generated rules for SAT solving (5/12 are duplicates)
On 23/11/16 10:47, Ed Schouten wrote: > 2016-11-23 17:41 GMT+01:00 Hans Petter Selasky : >> GitHub wouldn't allow me to make a .diff attachment. > > But there's absolutely no need for doing that in the first place! :-) > > 1. Go to https://github.com/freebsd/pkg > 2. Click 'Fork' on the top right. This will probably create a > https://github.com/hselasky/pkg > 3. Check out that repository using git(1), create a separate branch > and commit the changes to the SAT solver. > 4. Go to https://github.com/hselasky/pkg and click on 'New pull request'. > 5. Fill in the form. > Or you could just, I don't know, email the diff as a patch using git send-email like normal people instead of using GitHub's walled garden. That way, people without GitHub accounts can still comment on it. Just my 2¢. --arw -- A. Wilcox (awilfox) Open-source programmer (C, C++, Python) https://code.foxkit.us/u/awilfox/ signature.asc Description: OpenPGP digital signature
Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r
On 12/07/16 15:58, Steven Hartland wrote: > On 12/07/2016 21:50, Slawa Olhovchenkov wrote: >> On Tue, Jul 12, 2016 at 01:39:34PM -0700, Conrad Meyer wrote: >> >>> Maybe Tier 2 can deal with just bootonly.iso. Or your machines should >>> be dropped from Tier 2 if they don't support USB and we aren't okay >>> with dropping disc1 support for all of Tier 2. That is pretty much all SPARC hardware and a lot of POWER hardware. Not to mention newer rack-mount servers that have no USB on front (IBM). And what of the servers that already have functional CD drives? Do we really now have to recommending buying SCSI/SATA slimline or USB DVD drives just to boot installation media? That's a heavy cost when you can fit nearly all other BSDs on a single regular 650 (84 MB for NetBSD 7.0.1 + 223 MB for OpenBSD 5.9 + 385 MB for "TrueOS"/PC-BSD Server 10.3 = 692 MB, all sizes amd64 install iso including sets). >> Not all BIOS can be boot from USB. >> I am have Fujitsu notebook not support USB boot. > From a USB Pen drive I can understand but from a USB DVD Drive that > would be some seriously antiquated hardware! I have a Core 2-era Xeon board (Wolfdale-DP, Intel 5000 based) that cannot under any circumstances boot from a connected USB device. It won't boot from a USB DVD, USB CD, USB pen, or USB hard disk (USBMSC). I hardly consider a server that is 7 years old "antiquated" though I concede it is not the newest. Beyond that, there are security issues with allowing servers to boot off of any random USB device that an admin has lying around. Most will be configured by good admins to not do such a thing. In summary: NAK NAK NAK. USB is not a solution. Bringing down the bloat on disc1 or returning to miniinst is the proper solution. ~arw -- A. Wilcox (awilfox) Open-source programmer (C, C++, Python) https://code.foxkit.us/u/awilfox/ signature.asc Description: OpenPGP digital signature
