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 (小野寛生) > <hiroo.ono+free...@gmail.com> 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 <awil...@wilcox-tech.com> 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 <awil...@wilcox-tech.com> 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 <h...@selasky.org>: >> 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
Re: FreeBsd MCA Panic Crash !!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/01/16 04:34, shahzaibcb wrote: > Hi, > > We've switched to FreeBSD recently to accomodate large video storage as we > are running video streaming website. So the job of the FreeBSD is to > transcode the uploaded videos using ffmpeg and serve them to users via nginx > webserver but so far our experience is not very good with it. It crashes > every 2-3 days and we're unable to track down the problem. The server specs > are pretty high : > > > Supermicro X5690 (12 cores, 24 threads - 2u) > 96GB RAM > 12x3TB RAID-10 (HBA-LSI9211) > > Here is the screenshot of recent crash : > > http://prntscr.com/9er3pk > > One thing worth mentioning is, before going down there's no load on server, > more or less free RAM usually is around 12GB. We've tried following > solutions so far : > > > - Updated FreeBSD OS > - Replaced 800W PS with 900W > - We've reduced CMOS from MAX(26x) to 18x as suggested in this post > http://unix.stackexchange.com/questions/60574/determining-cause-of-linux-kernel-panic > > The solution we've not performed so far is : > > - Disable mca using (hw.mca.enabled: 0) - As we're getting MCA panics. > > Here is the crash dump : > > [root@cw001 /var/crash]# mcelog --no-dmi --ascii --file core.txt.1 > HARDWARE ERROR. This is *NOT* a software problem! > Please contact your hardware vendor > CPU 3 BANK 5 > MISC 0 ADDR 802bf6a69 > MCG status:MCIP > MCi status: > Uncorrected error > Error enabled > MCi_MISC register valid > MCi_ADDR register valid > Processor context corrupt > MCA: Internal Timer error > STATUS be800400 MCGSTATUS 4 > MCGCAP 1c09 APICID 3 SOCKETID 0 > CPUID Vendor Intel Family 6 Model 44 > HARDWARE ERROR. This is *NOT* a software problem! > Please contact your hardware vendor > CPU 2 BANK 5 > MISC 0 ADDR 802bf6a69 > MCG status:MCIP > MCi status: > Uncorrected error > Error enabled > MCi_MISC register valid > MCi_ADDR register valid > Processor context corrupt > MCA: Internal Timer error > STATUS be800400 MCGSTATUS 4 > MCGCAP 1c09 APICID 2 SOCKETID 0 > CPUID Vendor Intel Family 6 Model 44 > HARDWARE ERROR. This is *NOT* a software problem! > Please contact your hardware vendor > CPU 3 BANK 5 > MISC 0 ADDR 802bf6a69 > MCG status:MCIP > MCi status: > Uncorrected error > Error enabled > MCi_MISC register valid > MCi_ADDR register valid > Processor context corrupt > MCA: Internal Timer error > STATUS be800400 MCGSTATUS 4 > MCGCAP 1c09 APICID 3 SOCKETID 0 > CPUID Vendor Intel Family 6 Model 44 > HARDWARE ERROR. This is *NOT* a software problem! > Please contact your hardware vendor > CPU 2 BANK 5 > MISC 0 ADDR 802bf6a69 > MCG status:MCIP > MCi status: > Uncorrected error > Error enabled > MCi_MISC register valid > MCi_ADDR register valid > Processor context corrupt > MCA: Internal Timer error > STATUS be800400 MCGSTATUS 4 > MCGCAP 1c09 APICID 2 SOCKETID 0 > CPUID Vendor Intel Family 6 Model 44 > > --- > > I showed those Hardware errors to Vendor from whom we purchased Supermicro > servers . This is what he has to say : > > --- > Why do you not made one test environment with CentOS or one other Linux that > you know to use, and see if you have same errors ??? if not than you know > that the errors come from OS not from hardware. ( CentOS, RedHead….work > diferend like FreeBSD – work direct on hardware if you don’t have the right > kernel settings can the server crashed. CentOS , RedHead…. don’t work direct > on hardware and distribute the resource load better and you have better > control and you can better debug one situation) > --- > > Now we're on a black hole and unable to find that either issue with FreeBSD > or Hardware. We're thinking to disable mca in loader.conf but ppl are not > suggesting it. If you guys can help us, it'd be very kind. > Hello there, This seems to me like it would be a CPU failure. Can you try replacing the CPU itself? I've seen this exact message on a different board, and the cause was a failing CPU. Please do note that as the message says, this is not a software error. It is a failure of the hardware. Your vendor can try to blame FreeBSD all they want, but it is extremely improbable as to be almost impossible that that is the problem. You might also note to your vendor that it is "Red Hat" Linux, not Red Head. Hope this helps. - --arw -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWinw5AAoJEMspy1GSK50UXI8QANH5y9c36q8uX2xtQtjQ79DR ENN5O0cuxfiCn3mo7Kn+R0wD4Ahf1Qn6uR70WXwKDtdpre6VqsBxpZak7GVpHR9j x0C0jJJQLU3qs3XREzs6DjWCOge8j7zDZG0i9gZt3NT3WnEUxrqI+dLm/1I1Cy3f nSSHb3V3Sf9SxbB132NhCfiHfQNIVNGZsnrLCCIEWN0gI5vvEe2Av1e4PYoa1TJF 7B0qTmQ+nBb0zX/mccAbTXtMCAO7PBOrVkyxrwZN/J9kGYaPe2UEpsdHjXp76sui fFzb7voaKYXvqu3XJEYU0Pxulape5cUGSuQWmWBmDZhnFmn7YYRlfRr+5anwwhxu /EVDvOrdPNm4LpR3DCwR+FtHQb+fs9rfMEGIQ9EiLLF/rXXbs0Pfq+FzjHwk6RsX
i386 port no longer bootable on non-SSE CPUs
Hello, The i386 port, both 10-STABLE and 11-CURRENT, will not boot on systems without SSE support. This is caused by r273995, as using `svn merge -c -273995` (and hacking-and-sloshing through the few compiler errors afterwards) makes it once again bootable. This crash happens very early on in boot, before even mi_startup (as the author line is never even printed): http://i.imgur.com/SAty1mT.jpg This breaks support for all i486, Pentium, Pentium Pro, and Pentium II-based CPUs and computers. These are not only found in older computers that are useful as routers and file servers, but there are some new SoCs still using these chips: Intel Galileo board http://www.frys.com/product/8080584 Pentium core, no MMX/SSE whatsoever. Released late 2014. AMD Elan SC520, Geode series http://www.eurotech.com/en/products/CPU-1421 http://www.amd.com/en-us/products/embedded/processors/lx While the Elan is no longer manufactured, it still remains popular. The new Geode LX series of processors only implement MMX (so are roughly equivalent to a Pentium Pro in terms of instruction set). Backing out r273995 allows boot to proceed normally, as shown here: http://imgur.com/a/WWsa5 I attempted to revert locore.S to see if it was related to the stack setup changes found in that commit and it made no difference; the panic was the same. I would be willing to test any patches/diffs on any or all of the systems I have, but unfortunately I'm in a bit over my head trying to figure out which part of this commit is causing it. Best, Andrew -- Andrew Wilcox, C/C++/Python developer, kernel hacker Blog: http://blog.foxkit.us/ WWW: http://foxkit.us/ GitHub: https://github.com/awilfox ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: drm2 regression: backlight adjustment on ivybridge no longer works
Lars Engels sent: 01 February 2015 03:18: With acpi_video I get some interesting sysctl: hw.acpi.video.lcd0.levels: 100 100 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 I guess it should not be 100 100 0 ... 100? Actually, the standard internal ACPI brightness level struct (BRTN in the DSDT) is laid out as: * Full power value (one byte, the value at which the brightness should be set on AC by default) * Economy value (one byte, the value at which the brightness should be set on battery by default) * Actual values (N bytes, up to Max but frequently not) So, no, that value indeed sounds correct. On my laptop the value is: 80 47 0 7 13 20 27 33 40 47 53 60 67 73 80 87 93 100 What revision of -CURRENT are you running? What is the outcome of trying the patch posted Saturday morning (UTC) from Elizabeth Myers (message ID 54cc5311.9070...@interlinked.me)? Andrew -- Andrew Wilcox, C/C++/Python developer, kernel hacker Blog: http://blog.foxkit.us/ WWW: http://foxkit.us/ GitHub: https://github.com/awilfox ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: drm2 regression: backlight adjustment on ivybridge no longer works
Ranjan1018 . sent: 27 January 2015 23:42: The regression was introduced in r277487. Looking closer at this revision, I believe I may see the issue. Most of the new tunables introduced in dev/drm2/i915/i915_drv.c are uninitialised and thus probably contain junk. It likely works for me because the firmware of my laptop 0s memory on EFI boot. I have uploaded a diff here that I believe may fix this. Please test and let me know: http://foxkit.us/FreeBSD/i915-uninitialised-var-fix.diff Best, Andrew -- Andrew Wilcox, C/C++/Python developer, kernel hacker Blog: http://blog.foxkit.us/ WWW: http://foxkit.us/ GitHub: https://github.com/awilfox ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: drm2 regression: backlight adjustment on ivybridge no longer works
Ranjan1018 . sent: 27 January 2015 23:42: my Samsung laptop has an Intel IvyBridge: [snip] The regression was introduced in r277487. The backlight adjustment works in FreeBSD 11.0-CURRENT r277395, r277486 but not in r277487, r277534 and r277639. Hrm. That is interesting. A few questions I have then. - What happens if you set drm.i915.invert_brightness to -1 in kenv(1) or /boot/loader.conf? - What happens if you set drm.i915.invert_brightness to 1 in kenv(1) or /boot/loader.conf? - What version of graphics/libdrm do you have installed? Did you rebuild it after installing the new kernel? (This shouldn't be necessary, but I am trying to gather all details.) Let's start there and see if we can pin down a cause. Best, Andrew -- Andrew Wilcox, C/C++/Python developer, kernel hacker Blog: http://blog.foxkit.us/ WWW: http://foxkit.us/ GitHub: https://github.com/awilfox ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: drm2 regression: backlight adjustment on ivybridge no longer works
Ranjan1018 . sent: 26 January 2015 06:19: 2015-01-24 23:25 GMT+01:00 Adrian Chadd adr...@freebsd.org: The backlight adjustment doesn't work on my ivybridge mobile laptop (Lenovo X230) after the dri update. I have the same issue on my Samsung Ativ 2 laptop. I have a Sandy Bridge laptop (Apple MacBook Pro 8,2) - HD 3000: vgapci0@pci0:0:2:0: class=0x03 card=0x00db106b chip=0x01268086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '2nd Generation Core Processor Family Integrated Graphics Controller' class = display subclass = VGA It is running: FreeBSD pwyll.foxkit.us 11.0-CURRENT #1 r277781M: Mon Jan 26 18:41:15 CST 2015 r...@pwyll.foxkit.us:/usr/obj/usr/src/sys/GENERIC amd64 I have no issues using acpi_video's sysctls (hw.acpi.video.lcd0.brightness) to adjust backlight, though it does not have good granularity. The stepping is about 7, so it goes as 13%..20%..27%..35%..etc. The intel_backlight program from intel-gpu-tools also no longer changes the backlight value. This program works fine for me on both an older kernel (r277523) and this kernel (r277781), after applying some patches to allow the library to build on FreeBSD. It also has better granularity (the stepping is 2-3). If there is anything I can do/run to aide in debugging why it works for me but not others, let me know. Best, Andrew -- Andrew Wilcox, C/C++/Python developer, kernel hacker Blog: http://blog.foxkit.us/ WWW: http://foxkit.us/ GitHub: https://github.com/awilfox ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Upgrading FreeBSD to use the NEW pf syntax.
On Nov 20, 2012 9:44 AM, Mark Martinec mark.martinec+free...@ijs.si wrote: Paul Webster wrote: I am aware this is a much discussed subject since the upgrade of PF, I believe the final decision was that too many users are used to the old style pf and an upgrade to the new syntax would cause too much confusion. I don't buy that. Think of a confusion in a year of two when OpenBSD PF rules and the PF documentation won't match the legacy syntax in FreeBSD's PF. Their documentation already doesn't match the legacy syntax, you have to look for older pf documentation to match that in use by FreeBSD. This has been the case since at least OpenBSD 4.7: http://www.openbsd.org/faq/upgrade47.html To get documentation for FreeBSD pf, you generally need to look for OpenBSD documentation for 4.2 or 4.3 as there were minute changes in the mid-4.x range. kmw ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
