No battery detected due to _STA method removal
Hello, I hope the fix for the bug below will be committed before FreeBSD 12 is released. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191 Cheers, Ali ___ 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: Graphics open-source-friendliness, AMD Ryzen vs. Intel
>> On Nov 11, 2018, at 9:03 PM, Johannes Dieterich
>> wrote:
>>
>> On Sun, Nov 11, 2018 at 4:48 PM Johannes Lundberg wrote:
>>
>> I have an AMD Ryzen 3 2200G (with Vega graphics) and it panics all the time
>> with references to various memory access errors (use after free among
>> other).
>>
>> Ubuntu is also unstable on this machine but Windows 10 works well after a
>> windows update (I had to reinstall the previous motherboard with older cpu
>> to be able to run Windows update without crash...)
>>
>> From my experience, stay away from this CPU.
> To put this a little into perspective: the R3 2200G is part of the
> most recent AMD APU generation and contains the most recent Vega
> graphics IP ("Vega 8"). It was officially released only in February of
> this year. The most recent DRM in ports is 4.16, which itself was
> released only in April. Problems with the 2200G on "older" Linux
> releases are unfortunately well known. However, kernel 4.18 with
> latest firmwares and BIOSs is documented to be stable on this platform
> (see phoronix, Ubuntu 18.10 "benchmark").
>
> Johannes
Even the 2400G (Ryzen 5) released around the same time as the 2200G is
extremely stable for me (13-current), except for DRM (for which I have to use
the VESA radeonkms driver as the amdgpu doesn't yet seem to support the 2400G
graphics). I've done several buildworlds and more than a few poudriere runs
building 1100+ ports, it never seems to break a sweat, the CPU and heat sink
are still cool to the touch.
--
DE
___
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: Graphics open-source-friendliness, AMD Ryzen vs. Intel
On Sun, Nov 11, 2018 at 4:48 PM Johannes Lundberg wrote:
>
> I have an AMD Ryzen 3 2200G (with Vega graphics) and it panics all the time
> with references to various memory access errors (use after free among
> other).
>
> Ubuntu is also unstable on this machine but Windows 10 works well after a
> windows update (I had to reinstall the previous motherboard with older cpu
> to be able to run Windows update without crash...)
>
> From my experience, stay away from this CPU.
To put this a little into perspective: the R3 2200G is part of the
most recent AMD APU generation and contains the most recent Vega
graphics IP ("Vega 8"). It was officially released only in February of
this year. The most recent DRM in ports is 4.16, which itself was
released only in April. Problems with the 2200G on "older" Linux
releases are unfortunately well known. However, kernel 4.18 with
latest firmwares and BIOSs is documented to be stable on this platform
(see phoronix, Ubuntu 18.10 "benchmark").
Johannes
> On Sun, Nov 11, 2018 at 18:57 Allan Jude wrote:
>
> > On 2018-11-11 12:54, Greg V wrote:
> > >
> > >
> > > On Sun, Nov 11, 2018 at 3:42 PM, Thomas Mueller
> > > wrote:
> > >> I may need to buy parts for a new computer because of malfunctions on
> > >> current motherboard and CPU (Intel Sandy Bridge dating to May 2011).
> > >>
> > >> Question is whether I am better off, regarding
> > >> open-source-friendliness of graphics chips for running Xorg, with AMD
> > >> Ryzen or the newer Intel chipsets. I know to avoid NVIDIA.
> > >
> >
> > My FreeBSD workstation use an nVidia Quadro K1200 and it works very well
> > under FreeBSD with the nVidia kernel driver from ports.
> >
> > > Both are great for open source friendliness in general.
> > >
> > > Onboard Vega GPUs on the Ryzen APUs should work fine on FreeBSD with
> > > kms-drm 4.16.
> > >
> > > If you're looking for high performance though, don't get an APU, get an
> > > 8-core (R7 2700X/2700/1700X/1700) and a discrete GPU (Radeon RX
> > > 550/560/570/580 depending on how much you care about graphics
> > performance).
> > >
> > >> I am inclined to run FreeBSD-current and build Xorg from FreeBSD ports.
> > >>
> > >> When I boot into UEFI setup, I see the CPU temperature is or quickly
> > >> goes to 97 C and stays there.
> > >>
> > >> I tried replacing the thermal paste and installing a new case fan to
> > >> replace one that had quit, but CPU temperature still shows and stays
> > >> at 97 C.
> > >>
> > >> Now I have a replacement Arctic Cooler heatsink and fan on order to
> > >> replace the original Intel heatsink and fan whose connectors were
> > >> damaged in taking out and struggling to get back in.
> > >>
> > >> Currently, I boot into UEFI Setup, but after a couple minutes, the
> > >> computer powers off and then tries to power back on, then off again a
> > >> few seconds later, until I end the loop by turning off the power
> > >> supply switch. I can guess CPU overheating.
> > >
> > > Yeah, a new CPU cooler should help.
> > >
> > >> I could transplant the current hard drive (Seagate NAS 4 TB) to get a
> > >> quicker start software-wise.
> > >
> > > An SSD might provide a quicker start too ;)
> > >
> > > ___
> > > 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"
> >
> >
> > --
> > Allan Jude
> >
> >
> ___
> 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: Graphics open-source-friendliness, AMD Ryzen vs. Intel
I have an AMD Ryzen 3 2200G (with Vega graphics) and it panics all the time with references to various memory access errors (use after free among other). Ubuntu is also unstable on this machine but Windows 10 works well after a windows update (I had to reinstall the previous motherboard with older cpu to be able to run Windows update without crash...) >From my experience, stay away from this CPU. On Sun, Nov 11, 2018 at 18:57 Allan Jude wrote: > On 2018-11-11 12:54, Greg V wrote: > > > > > > On Sun, Nov 11, 2018 at 3:42 PM, Thomas Mueller > > wrote: > >> I may need to buy parts for a new computer because of malfunctions on > >> current motherboard and CPU (Intel Sandy Bridge dating to May 2011). > >> > >> Question is whether I am better off, regarding > >> open-source-friendliness of graphics chips for running Xorg, with AMD > >> Ryzen or the newer Intel chipsets. I know to avoid NVIDIA. > > > > My FreeBSD workstation use an nVidia Quadro K1200 and it works very well > under FreeBSD with the nVidia kernel driver from ports. > > > Both are great for open source friendliness in general. > > > > Onboard Vega GPUs on the Ryzen APUs should work fine on FreeBSD with > > kms-drm 4.16. > > > > If you're looking for high performance though, don't get an APU, get an > > 8-core (R7 2700X/2700/1700X/1700) and a discrete GPU (Radeon RX > > 550/560/570/580 depending on how much you care about graphics > performance). > > > >> I am inclined to run FreeBSD-current and build Xorg from FreeBSD ports. > >> > >> When I boot into UEFI setup, I see the CPU temperature is or quickly > >> goes to 97 C and stays there. > >> > >> I tried replacing the thermal paste and installing a new case fan to > >> replace one that had quit, but CPU temperature still shows and stays > >> at 97 C. > >> > >> Now I have a replacement Arctic Cooler heatsink and fan on order to > >> replace the original Intel heatsink and fan whose connectors were > >> damaged in taking out and struggling to get back in. > >> > >> Currently, I boot into UEFI Setup, but after a couple minutes, the > >> computer powers off and then tries to power back on, then off again a > >> few seconds later, until I end the loop by turning off the power > >> supply switch. I can guess CPU overheating. > > > > Yeah, a new CPU cooler should help. > > > >> I could transplant the current hard drive (Seagate NAS 4 TB) to get a > >> quicker start software-wise. > > > > An SSD might provide a quicker start too ;) > > > > ___ > > 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" > > > -- > Allan Jude > > ___ 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 failing to boot multiuser on one PC due to system utilities crashing during rc scipt
On Sun, Nov 11, 2018 at 08:44:24PM +0100, Guido Falsi wrote:
> On 11/11/18 11:10, Guido Falsi wrote:
> > On 11/11/18 00:07, Konstantin Belousov wrote:
> >> On Sat, Nov 10, 2018 at 05:27:09PM +0100, Guido Falsi wrote:
> >>> On 10/11/18 13:08, Guido Falsi wrote:
> I'll to bisect things, but it will be a slow process.
> >>>
> >>> I narrowed it down to r339895.
> >> I somehow doubt that this is the case.
> >>
> >
> > I did not mean to accuse you. Instead thanks for this reply and the
> > suggestions. Really appreciated.
> >
> > I simply found out that removing that commit from my sources gives me a
> > stable system and reported such finding.
> >
> > I understand that the actual cause could be an interaction with other
> > code and am ready to review my findings.
> >
> >> If you take post-r339895 kernel and start e.g. 11.2-RELEASE userspace
> >> (untar the installation into jail to avoid reinstallation), does it
> >> still demonstrate the behaviour ?
> >>
> >> Also try to run pre-r339895 with the 12.0 userspace from e.g. 12.0-BETA4
> >> builds.
> >
> > I'll perform such tests. Please allow me some time to report back what I
> > get.
>
> I performed these tests. I downloaded the 12.0-BETA4 and 11.2
> installation images and replaced the kernels in there. This was faster
> than working with jails on a crippled system.
>
> r339895 kernel on 11.2-RELEASE causes fsck (launched by rc) to dump core
> and this stops the boot procedure.
>
> r339894 kernel on 12.0-BETA4 works fine.
Ok, let try to find some reason.
- When you build your kernels, you do not use any cpu-specific optimization
flags, do you ? More, you follow the standard build procedure and your
make.conf and src.conf are empty, right ?
- Do you preload a microcode update from the loader ?
- Show the output of sysctl vm.pmap.
- Show verbose dmesg from the boot of the problematic kernel.
You posted non-verbose dmesg for 12.0-BETA4.
- Enter ddb, when booted the problematic kernel. Do
db> x/x cpu_stdext_feature
db> x/x cpu_stdext_feature+4
- From the same ddb session, disassemble e.g. cpu_set_user_tls().
You could paste me whole disassembling, but really I want to know
the single line with the call to set_pcb_flags, it should be
either set_pcb_flags_raw or set_pcb_flags_fsgsbase. To disassemble
in ddb, do
db> x/i cpu_set_user_tls
and then press more to get next and next instructions.
(I want the disassembly from ddb and not from gdb/kgdb).
- Try the following patch.
diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
index 6e36ae97523..8dafd4b4756 100644
--- a/sys/amd64/amd64/machdep.c
+++ b/sys/amd64/amd64/machdep.c
@@ -2627,8 +2627,8 @@ set_pcb_flags_raw(struct pcb *pcb, const u_int flags)
* the PCB_FULL_IRET flag is set. We disable interrupts to sync with
* context switches.
*/
-static void
-set_pcb_flags_fsgsbase(struct pcb *pcb, const u_int flags)
+void
+set_pcb_flags(struct pcb *pcb, const u_int flags)
{
register_t r;
@@ -2649,13 +2649,6 @@ set_pcb_flags_fsgsbase(struct pcb *pcb, const u_int
flags)
}
}
-DEFINE_IFUNC(, void, set_pcb_flags, (struct pcb *, const u_int), static)
-{
-
- return ((cpu_stdext_feature & CPUID_STDEXT_FSGSBASE) != 0 ?
- set_pcb_flags_fsgsbase : set_pcb_flags_raw);
-}
-
void
clear_pcb_flags(struct pcb *pcb, const u_int flags)
{
___
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 failing to boot multiuser on one PC due to system utilities crashing during rc scipt
On 11/11/18 11:10, Guido Falsi wrote: > On 11/11/18 00:07, Konstantin Belousov wrote: >> On Sat, Nov 10, 2018 at 05:27:09PM +0100, Guido Falsi wrote: >>> On 10/11/18 13:08, Guido Falsi wrote: I'll to bisect things, but it will be a slow process. >>> >>> I narrowed it down to r339895. >> I somehow doubt that this is the case. >> > > I did not mean to accuse you. Instead thanks for this reply and the > suggestions. Really appreciated. > > I simply found out that removing that commit from my sources gives me a > stable system and reported such finding. > > I understand that the actual cause could be an interaction with other > code and am ready to review my findings. > >> If you take post-r339895 kernel and start e.g. 11.2-RELEASE userspace >> (untar the installation into jail to avoid reinstallation), does it >> still demonstrate the behaviour ? >> >> Also try to run pre-r339895 with the 12.0 userspace from e.g. 12.0-BETA4 >> builds. > > I'll perform such tests. Please allow me some time to report back what I > get. I performed these tests. I downloaded the 12.0-BETA4 and 11.2 installation images and replaced the kernels in there. This was faster than working with jails on a crippled system. r339895 kernel on 11.2-RELEASE causes fsck (launched by rc) to dump core and this stops the boot procedure. r339894 kernel on 12.0-BETA4 works fine. -- Guido Falsi ___ 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: Graphics open-source-friendliness, AMD Ryzen vs. Intel
On 2018-11-11 12:54, Greg V wrote: > > > On Sun, Nov 11, 2018 at 3:42 PM, Thomas Mueller > wrote: >> I may need to buy parts for a new computer because of malfunctions on >> current motherboard and CPU (Intel Sandy Bridge dating to May 2011). >> >> Question is whether I am better off, regarding >> open-source-friendliness of graphics chips for running Xorg, with AMD >> Ryzen or the newer Intel chipsets. I know to avoid NVIDIA. > My FreeBSD workstation use an nVidia Quadro K1200 and it works very well under FreeBSD with the nVidia kernel driver from ports. > Both are great for open source friendliness in general. > > Onboard Vega GPUs on the Ryzen APUs should work fine on FreeBSD with > kms-drm 4.16. > > If you're looking for high performance though, don't get an APU, get an > 8-core (R7 2700X/2700/1700X/1700) and a discrete GPU (Radeon RX > 550/560/570/580 depending on how much you care about graphics performance). > >> I am inclined to run FreeBSD-current and build Xorg from FreeBSD ports. >> >> When I boot into UEFI setup, I see the CPU temperature is or quickly >> goes to 97 C and stays there. >> >> I tried replacing the thermal paste and installing a new case fan to >> replace one that had quit, but CPU temperature still shows and stays >> at 97 C. >> >> Now I have a replacement Arctic Cooler heatsink and fan on order to >> replace the original Intel heatsink and fan whose connectors were >> damaged in taking out and struggling to get back in. >> >> Currently, I boot into UEFI Setup, but after a couple minutes, the >> computer powers off and then tries to power back on, then off again a >> few seconds later, until I end the loop by turning off the power >> supply switch. I can guess CPU overheating. > > Yeah, a new CPU cooler should help. > >> I could transplant the current hard drive (Seagate NAS 4 TB) to get a >> quicker start software-wise. > > An SSD might provide a quicker start too ;) > > ___ > 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" -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Graphics open-source-friendliness, AMD Ryzen vs. Intel
On Sun, Nov 11, 2018 at 3:42 PM, Thomas Mueller wrote: I may need to buy parts for a new computer because of malfunctions on current motherboard and CPU (Intel Sandy Bridge dating to May 2011). Question is whether I am better off, regarding open-source-friendliness of graphics chips for running Xorg, with AMD Ryzen or the newer Intel chipsets. I know to avoid NVIDIA. Both are great for open source friendliness in general. Onboard Vega GPUs on the Ryzen APUs should work fine on FreeBSD with kms-drm 4.16. If you're looking for high performance though, don't get an APU, get an 8-core (R7 2700X/2700/1700X/1700) and a discrete GPU (Radeon RX 550/560/570/580 depending on how much you care about graphics performance). I am inclined to run FreeBSD-current and build Xorg from FreeBSD ports. When I boot into UEFI setup, I see the CPU temperature is or quickly goes to 97 C and stays there. I tried replacing the thermal paste and installing a new case fan to replace one that had quit, but CPU temperature still shows and stays at 97 C. Now I have a replacement Arctic Cooler heatsink and fan on order to replace the original Intel heatsink and fan whose connectors were damaged in taking out and struggling to get back in. Currently, I boot into UEFI Setup, but after a couple minutes, the computer powers off and then tries to power back on, then off again a few seconds later, until I end the loop by turning off the power supply switch. I can guess CPU overheating. Yeah, a new CPU cooler should help. I could transplant the current hard drive (Seagate NAS 4 TB) to get a quicker start software-wise. An SSD might provide a quicker start too ;) ___ 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"
Graphics open-source-friendliness, AMD Ryzen vs. Intel
I may need to buy parts for a new computer because of malfunctions on current motherboard and CPU (Intel Sandy Bridge dating to May 2011). Question is whether I am better off, regarding open-source-friendliness of graphics chips for running Xorg, with AMD Ryzen or the newer Intel chipsets. I know to avoid NVIDIA. I am inclined to run FreeBSD-current and build Xorg from FreeBSD ports. When I boot into UEFI setup, I see the CPU temperature is or quickly goes to 97 C and stays there. I tried replacing the thermal paste and installing a new case fan to replace one that had quit, but CPU temperature still shows and stays at 97 C. Now I have a replacement Arctic Cooler heatsink and fan on order to replace the original Intel heatsink and fan whose connectors were damaged in taking out and struggling to get back in. Currently, I boot into UEFI Setup, but after a couple minutes, the computer powers off and then tries to power back on, then off again a few seconds later, until I end the loop by turning off the power supply switch. I can guess CPU overheating. I could transplant the current hard drive (Seagate NAS 4 TB) to get a quicker start software-wise. Tom ___ 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: ctm(1) deprecation in the FreeBSD base system?
Am 23.10.18 um 22:21 schrieb Warner Losh: > On Tue, Oct 23, 2018 at 2:13 PM Rodney W. Grimes> At the most/least we > should not go very far, > the only thing that needs done soon is a gonein(13) commited > to head and MFC'ed to stable/12 by thursday. > > All the other details should wait until a depreication policy > revision is completed that includes how to deal with this. > > There's no reason at all to wait. We can create the port. We can create the > github repo. We can move the history there. We won't be removing it before we > have a chance to socialize the removal and give people a chance to cut over. > None of this requires a new policy. Everybody agrees we should do it. We > shouldn't let some perceived policy get in the way of just moving forward. I have created a review for the removal of CTM on phabricator: https://reviews.freebsd.org/D17935 The goal of this review is not to get approval for the removal within a few days, but to have all relevant changes documented and open for review. Since the removal affects ObsoleteFiles, there is some churn if another entry is added before approval, but it is easy enough to deal with it ... I'd still appreciate comments and a suggestion when to perform the removal. I could add a gonein(13) now, to give further attention to the depreciation of CTM, in the mean-time. Regards, STefan ___ 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 failing to boot multiuser on one PC due to system utilities crashing during rc scipt
On 11/11/18 00:07, Konstantin Belousov wrote: > On Sat, Nov 10, 2018 at 05:27:09PM +0100, Guido Falsi wrote: >> On 10/11/18 13:08, Guido Falsi wrote: >>> I'll to bisect things, but it will be a slow process. >> >> I narrowed it down to r339895. > I somehow doubt that this is the case. > I did not mean to accuse you. Instead thanks for this reply and the suggestions. Really appreciated. I simply found out that removing that commit from my sources gives me a stable system and reported such finding. I understand that the actual cause could be an interaction with other code and am ready to review my findings. > If you take post-r339895 kernel and start e.g. 11.2-RELEASE userspace > (untar the installation into jail to avoid reinstallation), does it > still demonstrate the behaviour ? > > Also try to run pre-r339895 with the 12.0 userspace from e.g. 12.0-BETA4 > builds. I'll perform such tests. Please allow me some time to report back what I get. > >> >> My impression is that the other conditions not moved inside the ifunc >> also play a role so such optimization is not possible on all systems. >> >>> >>> I have put dmesg and pciconf output here in case it could be useful: >>> >>> https://people.freebsd.org/~madpilot/boot_fail/ > This is haswell, right ? It is exactly the same micro-arch as the machine > where I tested this series of changes. According to Intel website and Wikipedia this is an Ivy Bridge: https://ark.intel.com/products/65509 I don't know if this makes any difference at all, though. -- Guido Falsi ___ 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"
