Re: Cannot set CPU frequency for 8th gen CPU
Hello all, I'm having the same problem here with a GIGABYTE H370M DS3H, very similar to Dave's. Does anyone have a solution to the issue? Cheers, -Elliott -- Sent from: http://freebsd.1045724.x6.nabble.com/freebsd-stable-f3932046.html ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Upgrading via source build, 10.4->11.2
On Tue, Dec 4, 2018, 7:25 PM George Mitchell /usr/src/UPDATING says: > > To build a kernel > - > If you are updating from a prior version of FreeBSD (even one just > a few days old), you should follow this procedure. It is the most > failsafe as it uses a /usr/obj tree with a fresh mini-buildworld, > > make kernel-toolchain > make -DALWAYS_CHECK_MAKE buildkernel KERNCONF=YOUR_KERNEL_HERE > make -DALWAYS_CHECK_MAKE installkernel KERNCONF=YOUR_KERNEL_HERE > > But at the very end of this procedure, I get: > > [...] > ===> zlib (install) > install -T release -o root -g wheel -m 555 zlib.ko /boot/kernel/ > install -T debug -o root -g wheel -m 555 zlib.ko.debug > /usr/lib/debug/boot/kernel/ > kldxref /boot/kernel > kldxref: unknown metadata record 4 in file atacard.ko > kldxref: unknown metadata record 4 in file atp.ko > kldxref: unknown metadata record 4 in file atp.ko > [...etc...] > > Should I have started with "make buildworld," or would that have > bombed out even worse? Do I reboot and "make buildworld"? Or do > I "make buildworld" now, while still running 10.4? -- George > Just ignore the warnings. They are harmless. Warner > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Upgrading via source build, 10.4->11.2
/usr/src/UPDATING says: To build a kernel - If you are updating from a prior version of FreeBSD (even one just a few days old), you should follow this procedure. It is the most failsafe as it uses a /usr/obj tree with a fresh mini-buildworld, make kernel-toolchain make -DALWAYS_CHECK_MAKE buildkernel KERNCONF=YOUR_KERNEL_HERE make -DALWAYS_CHECK_MAKE installkernel KERNCONF=YOUR_KERNEL_HERE But at the very end of this procedure, I get: [...] ===> zlib (install) install -T release -o root -g wheel -m 555 zlib.ko /boot/kernel/ install -T debug -o root -g wheel -m 555 zlib.ko.debug /usr/lib/debug/boot/kernel/ kldxref /boot/kernel kldxref: unknown metadata record 4 in file atacard.ko kldxref: unknown metadata record 4 in file atp.ko kldxref: unknown metadata record 4 in file atp.ko [...etc...] Should I have started with "make buildworld," or would that have bombed out even worse? Do I reboot and "make buildworld"? Or do I "make buildworld" now, while still running 10.4? -- George signature.asc Description: OpenPGP digital signature
Re: Boot loader stuck after first stage upgrading 11.2 to 12.0-RC2
Yes, that must be true but it does not hurt to get checked. And of course, lsdev -v from 11.x loader would be good too. Anyhow, I am afraid we have reached to point where more specific debug info is needed (printed out), with lack of output about disks at all, it must be related to floppy device checks. Rgds, Toomas Sent from my iPhone > On 4 Dec 2018, at 22:19, Ian Lepore wrote: > > On Tue, 2018-12-04 at 21:51 +0200, Toomas Soome via freebsd-stable > wrote: >> >>> >>> On 4 Dec 2018, at 19:59, Mark Martinec >> i> wrote: >>> > > 2018-11-29 18:43, Toomas Soome wrote: >> >> I just did push biosdisk updates to stable/12, I wonder if >> you could >> test those bits… >>> Myself wrote: > > Thank you! I haven't tried it yet, but I wonder whether this > fix was > already incorporated into 12.0-RC3, which would make my rescue > easier. > Otherwise I can build a stable/12 on another host and > transplant > the problematic file(s) to the affected host - if I knew which > files > to copy. >>> 2018-12-02 18:59, Toomas wrote: The files are /boot/loader* binaries - to be exact, check which one is linked to /boot/loader. I can provide binaries if needed. [...] rgds, toomas >>> I got a maintenance window today so I tried with the new loader, >>> and it did not help. >>> >>> More specifically: >>> >>> As it comes with 12-RC2, the /boot/loader was hard linked with >>> loader_lua. >>> Its size is 421888 bytes. So I concentrated on this loader. >>> >>> I build a fresh stable/12 on another host, and copied the newly >>> built loader_lua (425984 bytes) to the /boot directory of the >>> affected >>> host, deleted the file 'loader', and hard-linked loader_lua to >>> loader. >>> >>> The situation has not changed: the BTX loader lists all BIOS drives >>> C..J (disk0..disk7), then a spinner starts and gets stuck forever. >>> It never reaches the 'BIOS 635kB/3537856kB available memory' line. >>> >>> While trying to restore the old /boot from 11.2, I tried booting >>> a live image from a 12.0-RC3 memory stick - and the loader got >>> stuck again, same as when booting from a disk. >>> >>> So I had to boot from an 11.2 memstick to be able to regain >>> control. >>> >>> Mark >>> >>> >> ok, if you could perform 2 tests: >> >> 1. from loader prompt enter 0x413 0xa000 - @w . cr >> >> 2. on first spinner, press space and type on boot: prompt: >> /boot/loader_4th and see if that will do better >> thanks, >> toomas >> > > I don't think that will be an option. If it hasn't gotten to the point > of saying how much BIOS available memory there is, it's only halfway > through loader main() and has hung before getting to interact(). > > In fact, if that line hasn't printed, but some disk drives have been > listed, it pretty much has to be hung in the "March through the device > switch probing for things" loop. If all the disks are listed, then it > got through that entry in the devsw, and is likely hanging in the > dv_init calls for either the pxedisk or zfsdev devices. > > -- Ian > >> >>> >>> > >> >>> >>> On 29 Nov 2018, at 17:01, Mark Martinec >> b...@ijs.si> wrote: >>> After successfully upgraded three hosts from 11.2-p4 to >>> 12.0-RC2 (amd64, >>> zfs, bios), I tried my luck with one of our production >>> hosts, and ended up >>> with a stuck loader after rebooting with a new kernel >>> (after the first >>> stage of upgrade). >>> These were the steps, and all went smoothly and normally >>> until a reboot: >>> freebsd-update upgrade -r 12.0-RC2 >>> freebsd-update install >>> shutdown -r now >>> While booting, the 'BTX loader' comes up, lists the BIOS >>> drives, >>> then the spinner below the list comes up and begins >>> turning, >>> stuttering, and after a couple of seconds it grinds to a >>> standstill >>> and nothing happens afterwards. >>> At this point the ZFS and the bootstrap loader is supposed >>> to >>> come up, but it doesn't. >>> This host has too zfs pools, the system pool consists of >>> two SSDs >>> in a zfs mirror (also holding a freebsd-boot partition >>> each), the >>> other pool is a raidz2 with six JBOD disks on an LSI >>> controller. >>> The gptzfsboot in both freebsd-boot partitions is fresh >>> from 11.2, >>> both zpool versions are up-to-date with 11.2. The 'zpool >>> status -v' >>> is happy with both pools. >>> After rebooting from an USB drive and reverting the /boot >>> directory >>> to a previous version, the machine comes up normally again >>> with the 11.2-RELEASE-p4. >>> I found a file init.core in the / directory, slightly >>> predating the >>> last reboot with a salvaged system - although it was >>> probably not >>> a cause of the problem, but a consequence of the rescue
Re: Boot loader stuck after first stage upgrading 11.2 to 12.0-RC2
On Tue, 2018-12-04 at 21:51 +0200, Toomas Soome via freebsd-stable wrote: > > > > > On 4 Dec 2018, at 19:59, Mark Martinec > i> wrote: > > > > > > > > > > > > > 2018-11-29 18:43, Toomas Soome wrote: > > > > > > > > > > I just did push biosdisk updates to stable/12, I wonder if > > > > > you could > > > > > test those bits… > > Myself wrote: > > > > > > > > > > > Thank you! I haven't tried it yet, but I wonder whether this > > > > fix was > > > > already incorporated into 12.0-RC3, which would make my rescue > > > > easier. > > > > Otherwise I can build a stable/12 on another host and > > > > transplant > > > > the problematic file(s) to the affected host - if I knew which > > > > files > > > > to copy. > > 2018-12-02 18:59, Toomas wrote: > > > > > > The files are /boot/loader* binaries - to be exact, check which > > > one is > > > linked to /boot/loader. I can provide binaries if needed. > > > [...] > > > rgds, > > > toomas > > I got a maintenance window today so I tried with the new loader, > > and it did not help. > > > > More specifically: > > > > As it comes with 12-RC2, the /boot/loader was hard linked with > > loader_lua. > > Its size is 421888 bytes. So I concentrated on this loader. > > > > I build a fresh stable/12 on another host, and copied the newly > > built loader_lua (425984 bytes) to the /boot directory of the > > affected > > host, deleted the file 'loader', and hard-linked loader_lua to > > loader. > > > > The situation has not changed: the BTX loader lists all BIOS drives > > C..J (disk0..disk7), then a spinner starts and gets stuck forever. > > It never reaches the 'BIOS 635kB/3537856kB available memory' line. > > > > While trying to restore the old /boot from 11.2, I tried booting > > a live image from a 12.0-RC3 memory stick - and the loader got > > stuck again, same as when booting from a disk. > > > > So I had to boot from an 11.2 memstick to be able to regain > > control. > > > > Mark > > > > > ok, if you could perform 2 tests: > > 1. from loader prompt enter 0x413 0xa000 - @w . cr > > 2. on first spinner, press space and type on boot: prompt: > /boot/loader_4th and see if that will do better > thanks, > toomas > I don't think that will be an option. If it hasn't gotten to the point of saying how much BIOS available memory there is, it's only halfway through loader main() and has hung before getting to interact(). In fact, if that line hasn't printed, but some disk drives have been listed, it pretty much has to be hung in the "March through the device switch probing for things" loop. If all the disks are listed, then it got through that entry in the devsw, and is likely hanging in the dv_init calls for either the pxedisk or zfsdev devices. -- Ian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 29 Nov 2018, at 17:01, Mark Martinec > > > > > b...@ijs.si> wrote: > > > > > > After successfully upgraded three hosts from 11.2-p4 to > > > > > > 12.0-RC2 (amd64, > > > > > > zfs, bios), I tried my luck with one of our production > > > > > > hosts, and ended up > > > > > > with a stuck loader after rebooting with a new kernel > > > > > > (after the first > > > > > > stage of upgrade). > > > > > > These were the steps, and all went smoothly and normally > > > > > > until a reboot: > > > > > > freebsd-update upgrade -r 12.0-RC2 > > > > > > freebsd-update install > > > > > > shutdown -r now > > > > > > While booting, the 'BTX loader' comes up, lists the BIOS > > > > > > drives, > > > > > > then the spinner below the list comes up and begins > > > > > > turning, > > > > > > stuttering, and after a couple of seconds it grinds to a > > > > > > standstill > > > > > > and nothing happens afterwards. > > > > > > At this point the ZFS and the bootstrap loader is supposed > > > > > > to > > > > > > come up, but it doesn't. > > > > > > This host has too zfs pools, the system pool consists of > > > > > > two SSDs > > > > > > in a zfs mirror (also holding a freebsd-boot partition > > > > > > each), the > > > > > > other pool is a raidz2 with six JBOD disks on an LSI > > > > > > controller. > > > > > > The gptzfsboot in both freebsd-boot partitions is fresh > > > > > > from 11.2, > > > > > > both zpool versions are up-to-date with 11.2. The 'zpool > > > > > > status -v' > > > > > > is happy with both pools. > > > > > > After rebooting from an USB drive and reverting the /boot > > > > > > directory > > > > > > to a previous version, the machine comes up normally again > > > > > > with the 11.2-RELEASE-p4. > > > > > > I found a file init.core in the / directory, slightly > > > > > > predating the > > > > > > last reboot with a salvaged system - although it was > > > > > > probably not > > > > > > a cause of the problem, but a consequence of the rescue > > > > > > operation. > > > > > > It is unfortunate that this is a production host, so I > > > > > > can't play > > > > > > much with it. One or two more quick experiments I can > > > > > > probably > > > > >
Re: Ryzen issues on FreeBSD ? (with sort of workaround)
Hi! > Well, another lockup. This time after ~ 10 days of uptime. Box was idle > at the time and just a solid freeze. Here's another datapoint: No lockups/problems with: AMD Ryzen Threadripper 2950X Board: PRIME X399-A (not the -PRO) BIOS from 10/12/2018 running: 13.0-CURRENT r340445 up 19 days, running as a package builder -- p...@freebsd.org +49 171 3101372 2 years to go ! ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Boot loader stuck after first stage upgrading 11.2 to 12.0-RC2
> On 4 Dec 2018, at 19:59, Mark Martinec wrote: > >>> 2018-11-29 18:43, Toomas Soome wrote: I just did push biosdisk updates to stable/12, I wonder if you could test those bits… > > Myself wrote: >>> Thank you! I haven't tried it yet, but I wonder whether this fix was >>> already incorporated into 12.0-RC3, which would make my rescue easier. >>> Otherwise I can build a stable/12 on another host and transplant >>> the problematic file(s) to the affected host - if I knew which files >>> to copy. > > 2018-12-02 18:59, Toomas wrote: >> The files are /boot/loader* binaries - to be exact, check which one is >> linked to /boot/loader. I can provide binaries if needed. >> [...] >> rgds, >> toomas > > I got a maintenance window today so I tried with the new loader, > and it did not help. > > More specifically: > > As it comes with 12-RC2, the /boot/loader was hard linked with loader_lua. > Its size is 421888 bytes. So I concentrated on this loader. > > I build a fresh stable/12 on another host, and copied the newly > built loader_lua (425984 bytes) to the /boot directory of the affected > host, deleted the file 'loader', and hard-linked loader_lua to loader. > > The situation has not changed: the BTX loader lists all BIOS drives > C..J (disk0..disk7), then a spinner starts and gets stuck forever. > It never reaches the 'BIOS 635kB/3537856kB available memory' line. > > While trying to restore the old /boot from 11.2, I tried booting > a live image from a 12.0-RC3 memory stick - and the loader got > stuck again, same as when booting from a disk. > > So I had to boot from an 11.2 memstick to be able to regain control. > > Mark > > ok, if you could perform 2 tests: 1. from loader prompt enter 0x413 0xa000 - @w . cr 2. on first spinner, press space and type on boot: prompt: /boot/loader_4th and see if that will do better thanks, toomas > > On 29 Nov 2018, at 17:01, Mark Martinec > wrote: > After successfully upgraded three hosts from 11.2-p4 to 12.0-RC2 (amd64, > zfs, bios), I tried my luck with one of our production hosts, and ended up > with a stuck loader after rebooting with a new kernel (after the first > stage of upgrade). > These were the steps, and all went smoothly and normally until a reboot: > freebsd-update upgrade -r 12.0-RC2 > freebsd-update install > shutdown -r now > While booting, the 'BTX loader' comes up, lists the BIOS drives, > then the spinner below the list comes up and begins turning, > stuttering, and after a couple of seconds it grinds to a standstill > and nothing happens afterwards. > At this point the ZFS and the bootstrap loader is supposed to > come up, but it doesn't. > This host has too zfs pools, the system pool consists of two SSDs > in a zfs mirror (also holding a freebsd-boot partition each), the > other pool is a raidz2 with six JBOD disks on an LSI controller. > The gptzfsboot in both freebsd-boot partitions is fresh from 11.2, > both zpool versions are up-to-date with 11.2. The 'zpool status -v' > is happy with both pools. > After rebooting from an USB drive and reverting the /boot directory > to a previous version, the machine comes up normally again > with the 11.2-RELEASE-p4. > I found a file init.core in the / directory, slightly predating the > last reboot with a salvaged system - although it was probably not > a cause of the problem, but a consequence of the rescue operation. > It is unfortunate that this is a production host, so I can't play > much with it. One or two more quick experiments I can probably > afford, but not much more. Should I just first wait for the > official 12.0 release? Should I try booting with a 12.0 on USB > and try to import pools? Suggestions welcome. > Now that the /boot has been manually restored to the 11.2 state, > A SECOND QUESTION is about freebsd-update, which still thinks we are > in the middle of an upgrade procedure. Trying now to just update > the 11.2-RELEASE-p4 to 11.2-RELEASE-p5, the fetch complains: > # uname -a > FreeBSD xxx 11.2-RELEASE-p4 FreeBSD 11.2-RELEASE-p4 > # > # freebsd-version > 11.2-RELEASE-p4 > # > # freebsd-update fetch > src component not installed, skipped > You have a partially completed upgrade pending > Run '/usr/sbin/freebsd-update install' first. > Run '/usr/sbin/freebsd-update fetch -F' to proceed anyway. > So what is the right way to get rid of all traces of the > unsuccessful upgrade, and let freebsd-update believe we are cleanly > at 11.2-p4 ? Removing /var/db/freebsd-update did not help. > Mark ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Ryzen issues on FreeBSD ? (with sort of workaround)
On 04/12/2018 18:26, Mike Tancsa wrote: I think I will downgrade the box that was having issues to RELENG11 to see if the problem is there too. Unfortunately, the issue took ~ 10 days to show itself My issues showed up on releng 11 as well as releng 12 - I didnt ry the last 11 stable for long though. will see how the new BIOS goes, and then underclock the RAM if that locks up. -pete. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Ryzen issues on FreeBSD ? (with sort of workaround)
On 12/4/2018 12:39 PM, Nimrod Levy wrote: > Just to throw another datapoint out there, I've been running on my > Asus prime b350+ ryzen 5 and I've been stable since the microcode > updates over the summer. I believe I returned all the bios settings > (cstates, memory timing, etc..) back to stock. I've had to shutdown > and relocate (and reconfigure some networks bits) since then. I've > also shifted to RELENG 11.2 from the STABLE code that I'd been > running. It's been very stable for me with a current uptime of 60 days > and before that, it was rebooted for an update. So whatever was going > on seems to be fixed for me. I think I will downgrade the box that was having issues to RELENG11 to see if the problem is there too. Unfortunately, the issue took ~ 10 days to show itself ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Boot loader stuck after first stage upgrading 11.2 to 12.0-RC2
2018-11-29 18:43, Toomas Soome wrote: I just did push biosdisk updates to stable/12, I wonder if you could test those bits… Myself wrote: Thank you! I haven't tried it yet, but I wonder whether this fix was already incorporated into 12.0-RC3, which would make my rescue easier. Otherwise I can build a stable/12 on another host and transplant the problematic file(s) to the affected host - if I knew which files to copy. 2018-12-02 18:59, Toomas wrote: The files are /boot/loader* binaries - to be exact, check which one is linked to /boot/loader. I can provide binaries if needed. [...] rgds, toomas I got a maintenance window today so I tried with the new loader, and it did not help. More specifically: As it comes with 12-RC2, the /boot/loader was hard linked with loader_lua. Its size is 421888 bytes. So I concentrated on this loader. I build a fresh stable/12 on another host, and copied the newly built loader_lua (425984 bytes) to the /boot directory of the affected host, deleted the file 'loader', and hard-linked loader_lua to loader. The situation has not changed: the BTX loader lists all BIOS drives C..J (disk0..disk7), then a spinner starts and gets stuck forever. It never reaches the 'BIOS 635kB/3537856kB available memory' line. While trying to restore the old /boot from 11.2, I tried booting a live image from a 12.0-RC3 memory stick - and the loader got stuck again, same as when booting from a disk. So I had to boot from an 11.2 memstick to be able to regain control. Mark On 29 Nov 2018, at 17:01, Mark Martinec wrote: After successfully upgraded three hosts from 11.2-p4 to 12.0-RC2 (amd64, zfs, bios), I tried my luck with one of our production hosts, and ended up with a stuck loader after rebooting with a new kernel (after the first stage of upgrade). These were the steps, and all went smoothly and normally until a reboot: freebsd-update upgrade -r 12.0-RC2 freebsd-update install shutdown -r now While booting, the 'BTX loader' comes up, lists the BIOS drives, then the spinner below the list comes up and begins turning, stuttering, and after a couple of seconds it grinds to a standstill and nothing happens afterwards. At this point the ZFS and the bootstrap loader is supposed to come up, but it doesn't. This host has too zfs pools, the system pool consists of two SSDs in a zfs mirror (also holding a freebsd-boot partition each), the other pool is a raidz2 with six JBOD disks on an LSI controller. The gptzfsboot in both freebsd-boot partitions is fresh from 11.2, both zpool versions are up-to-date with 11.2. The 'zpool status -v' is happy with both pools. After rebooting from an USB drive and reverting the /boot directory to a previous version, the machine comes up normally again with the 11.2-RELEASE-p4. I found a file init.core in the / directory, slightly predating the last reboot with a salvaged system - although it was probably not a cause of the problem, but a consequence of the rescue operation. It is unfortunate that this is a production host, so I can't play much with it. One or two more quick experiments I can probably afford, but not much more. Should I just first wait for the official 12.0 release? Should I try booting with a 12.0 on USB and try to import pools? Suggestions welcome. Now that the /boot has been manually restored to the 11.2 state, A SECOND QUESTION is about freebsd-update, which still thinks we are in the middle of an upgrade procedure. Trying now to just update the 11.2-RELEASE-p4 to 11.2-RELEASE-p5, the fetch complains: # uname -a FreeBSD xxx 11.2-RELEASE-p4 FreeBSD 11.2-RELEASE-p4 # # freebsd-version 11.2-RELEASE-p4 # # freebsd-update fetch src component not installed, skipped You have a partially completed upgrade pending Run '/usr/sbin/freebsd-update install' first. Run '/usr/sbin/freebsd-update fetch -F' to proceed anyway. So what is the right way to get rid of all traces of the unsuccessful upgrade, and let freebsd-update believe we are cleanly at 11.2-p4 ? Removing /var/db/freebsd-update did not help. Mark ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Ryzen issues on FreeBSD ? (with sort of workaround)
Just to throw another datapoint out there, I've been running on my Asus prime b350+ ryzen 5 and I've been stable since the microcode updates over the summer. I believe I returned all the bios settings (cstates, memory timing, etc..) back to stock. I've had to shutdown and relocate (and reconfigure some networks bits) since then. I've also shifted to RELENG 11.2 from the STABLE code that I'd been running. It's been very stable for me with a current uptime of 60 days and before that, it was rebooted for an update. So whatever was going on seems to be fixed for me. On Tue, Dec 4, 2018 at 10:44 AM Pete French wrote: > > > On 04/12/2018 15:04, Mike Tancsa wrote: > > Well, another lockup. This time after ~ 10 days of uptime. Box was idle > > at the time and just a solid freeze. This is an ASUS PRIME X370-PRO > > running BIOS from 09/07/2018 (latest). Not sure if BIOS related or OS > > related. I have another motherboard (MSI) that I will install 12.0 on > > and see if its any different. There is also a micro code update from > > AMD last week. However, there are no release notes as to what it > > changes. I will hold off on that for now and see if I can get lockups on > > the MSI in the next week or two. > > I did the opposite yesterday - I updated my microcode to the latest one > from MSI (though the AMD update it contains is from the summer I belive, > depsite the BIOS only comming out a couple of weeks ago). Am running > 12-STABLE on there, and will see how long it lasts. > > Only got to do this yesterday as havent been near the machine for weeks. > I didnt adjust any RAM timings and left everything at the default after > the BIOS update. > > but until yesterday it has locked up about every couple of days :-( > > -pete. > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Ryzen issues on FreeBSD ? (with sort of workaround)
On 04/12/2018 15:04, Mike Tancsa wrote: Well, another lockup. This time after ~ 10 days of uptime. Box was idle at the time and just a solid freeze. This is an ASUS PRIME X370-PRO running BIOS from 09/07/2018 (latest). Not sure if BIOS related or OS related. I have another motherboard (MSI) that I will install 12.0 on and see if its any different. There is also a micro code update from AMD last week. However, there are no release notes as to what it changes. I will hold off on that for now and see if I can get lockups on the MSI in the next week or two. I did the opposite yesterday - I updated my microcode to the latest one from MSI (though the AMD update it contains is from the summer I belive, depsite the BIOS only comming out a couple of weeks ago). Am running 12-STABLE on there, and will see how long it lasts. Only got to do this yesterday as havent been near the machine for weeks. I didnt adjust any RAM timings and left everything at the default after the BIOS update. but until yesterday it has locked up about every couple of days :-( -pete. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Ryzen issues on FreeBSD ? (with sort of workaround)
On 11/26/2018 11:30 AM, Mike Tancsa wrote: > On 11/26/2018 11:25 AM, Pete French wrote: >> Foolwing up an old thread I know, but my ssystem ahs been pretty >> stable until recently, when it started locking up about one a week at >> least. This co-incided with me doing two things to it: >> > Interesting, I too have noticed my one test box have the odd lockup. I > think it started around the BETA series. Is it possible something > "undid" one of the fixes ? I brought the box in question upto > 12.0-PRERELEASE FreeBSD 12.0-PRERELEASE r340724 and its been fine for 5 > days. Sadly, when it was locking up (no panic, just a solid lockup) it > took some random amount of time and generally did not matter if the box > was loaded or not. Well, another lockup. This time after ~ 10 days of uptime. Box was idle at the time and just a solid freeze. This is an ASUS PRIME X370-PRO running BIOS from 09/07/2018 (latest). Not sure if BIOS related or OS related. I have another motherboard (MSI) that I will install 12.0 on and see if its any different. There is also a micro code update from AMD last week. However, there are no release notes as to what it changes. I will hold off on that for now and see if I can get lockups on the MSI in the next week or two. ---Mike > -- > --- > Mike Tancsa, tel +1 519 651 3400 x203 > Sentex Communications, m...@sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
using wifi usbkey and ethernet on rpi3-b
Hi, context: freebsd-12-rc3, raspberry pi3-b, external usb-connected hd, 2.5A PSU Has anyone tried using a wifi interface (usb key format) and ethernet at the same time? There is also a usb connected hard drive. I was wondering if the wifi might interrupt the ethernet or the hard drive. Aren't they all the same interface electronically? ie the usb/ethernet is more like a usb bus. (originally asked in freebsd-arm but it's very quiet there) thanks, -- J. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
