Asus E45M1-M PRO no longer booting since BIOS update
Hello, Recently I wanted to resurrect and old AMD Bobcat (14h) for use with kgdb over dconschat. The system booted a FreeBSD-13.0-ALPHA2-amd64-20210122 without a problem. I noticed the BIOS was ~9 years old, so I updated the to most recent version, which is ~5 years old. After the BIOS update, Any FreeBSD boot image I have tried as far back as 11, no longer boots past the printed EFI framebuffer information. NetBSD-9 and Kunubtu-20.10 all boot OK. I am not having success with remote debugging via Firewire (I recall it used to be far easier), even WITH_LOADER_FIREWIRE, I can still not attach a remote gdb process. My other host which is connected to the E45M1 via Firewire reports when the E45M1 is booting: fwohci0: fwohci_intr_core: BUS reset fwohci0: PhysicalUpperBound register is not implemented. Physical memory access is limited to the first 4GB fwohci0: PhysicalUpperBound = 0x fwohci0: fwohci_intr_core: node_id=0x0001, SelfID Count=2, CYCLEMASTER mode firewire0: 2 nodes, maxhop <= 1 cable IRM irm(1) (me) firewire0: bus manager 1 fwohci0: fwohci_intr_core: BUS reset fwohci0: PhysicalUpperBound register is not implemented. Physical memory access is limited to the first 4GB fwohci0: PhysicalUpperBound = 0x fwohci0: fwohci_intr_core: node_id=0x0001, SelfID Count=3, CYCLEMASTER mode firewire0: 2 nodes, maxhop <= 1 cable IRM irm(1) (me) firewire0: bus manager 1 firewire0: split transaction timeout: tl=0x14 flag=0x04 send: dst=0x00 tl=0x14 rt=0 tcode=0x4 pri=0x0 src=0x000 $ fwcontrol 2 devices (info_len=2) node EUI64 statushostname 1 00-0f-2e-01-00-00-67-4b 0 -1 00-0f-2e-01-00-00-67-42 0 $ dmesg -a | grep -A3 Tex fwohci0: mem 0xfc904000-0xfc9047ff,0xfc90-0xfc903fff at device 4.0 on pci10 fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:0f:2e:01:00:00:67:4b Any ideas on how I can restore FreeBSD on the hardware? To good health, Alastair ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic in drm or vt or deadlock on mutex or ...
Sorry, please ignore previous reply, the modified sysctl is still running, the output earlier, was from the stock binary. On 2021-02-09 14:25, Alastair Hogge wrote: > On 2021-02-08 21:01, Hans Petter Selasky wrote: >> On 2/8/21 1:53 PM, Alastair Hogge wrote: >>> Boot to multi-user; login (getty): >>> $ doas kldload /boot/modules/amdgpu.ko >>> $ sysctl >>> [panic] >>> >>> ..is a guaranteed way to panic my system. >> >> Hi, >> >> Maybe you could do a hack and edit the sysctl source code: >> >> 1) print the sysctl before it is queried. >> 2) sleep 1 second between print and query. >> >> Should be easy to nail this down! > > This is all I am able to catch via the ssh session: > vm.uma.sackhole.size: 32 > vm.uma.hostcache.stats.xdomain: 0 > vm.uma.hostcache.stats.fails: 0 > vm.uma.hostcache.stats.frees: 0 > vm.uma.hostcache.stats.allocs: 0 > vm.uma.hostcache.stats.current: 0 > vm.uma.hostcache.domain.0.wss: 0 > vm.uma.hostcache.domain.0.imin: 0 > vm.uma.hostcache.domain.0.imax: 0 > vm.uma.hostcache.domain.0.nitems: 0 > vm.uma.hostcache.limit.bucket_max: 7680 > vm.uma.hostcache.limit.sleeps: 0 > vm.uma.hostcache.limit.sleepers: 0 > vm.uma.hostcache.limit.max_items: 15360 > vm.uma.hostcache.limit.items: 0 > vm.uma.hostcache.keg.domain.0.free_items: 0 > vm.uma.hostcache.keg.domain.0.pages: 0 > vm.uma.hostcache.keg.efficiency: 98 > vm.uma.hostcache.keg.reserve: 0 > vm.uma.hostcache.keg.align: 7 > vm.uma.hostcache.keg.ipers: 42 > vm.uma.hostcache.keg.ppera: 1 > vm.uma.hostcache.keg.rsize: 96 > vm.uma.hostcache.keg.name: hostcache > vm.uma.hostcache.bucket_size_max: 120 > vm.uma.hostcache.bucket_size: 120 > vm.uma.hostcache.flags: 0x4301 > vm.uma.hostcache.size: 96 > vm.uma.syncache.stats.xdomain: 0 > vm.uma.syncache.stats.fails: 0 > vm.uma.syncache.stats.frees: 1 > vm.uma.syncache.stats.allocs: 1 > vm.uma.syncache.stats.current: 0 > vm.uma.syncache.domain.0.wss: 3 > vm.uma.syncache.domain.0.imin: 0 > vm.uma.syncache.domain.0.imax: 0 > vm.uma.syncache.domain.0.nitems: 0 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic in drm or vt or deadlock on mutex or ...
On 2021-02-08 21:01, Hans Petter Selasky wrote: > On 2/8/21 1:53 PM, Alastair Hogge wrote: >> Boot to multi-user; login (getty): >> $ doas kldload /boot/modules/amdgpu.ko >> $ sysctl >> [panic] >> >> ..is a guaranteed way to panic my system. > > Hi, > > Maybe you could do a hack and edit the sysctl source code: > > 1) print the sysctl before it is queried. > 2) sleep 1 second between print and query. > > Should be easy to nail this down! This is all I am able to catch via the ssh session: vm.uma.sackhole.size: 32 vm.uma.hostcache.stats.xdomain: 0 vm.uma.hostcache.stats.fails: 0 vm.uma.hostcache.stats.frees: 0 vm.uma.hostcache.stats.allocs: 0 vm.uma.hostcache.stats.current: 0 vm.uma.hostcache.domain.0.wss: 0 vm.uma.hostcache.domain.0.imin: 0 vm.uma.hostcache.domain.0.imax: 0 vm.uma.hostcache.domain.0.nitems: 0 vm.uma.hostcache.limit.bucket_max: 7680 vm.uma.hostcache.limit.sleeps: 0 vm.uma.hostcache.limit.sleepers: 0 vm.uma.hostcache.limit.max_items: 15360 vm.uma.hostcache.limit.items: 0 vm.uma.hostcache.keg.domain.0.free_items: 0 vm.uma.hostcache.keg.domain.0.pages: 0 vm.uma.hostcache.keg.efficiency: 98 vm.uma.hostcache.keg.reserve: 0 vm.uma.hostcache.keg.align: 7 vm.uma.hostcache.keg.ipers: 42 vm.uma.hostcache.keg.ppera: 1 vm.uma.hostcache.keg.rsize: 96 vm.uma.hostcache.keg.name: hostcache vm.uma.hostcache.bucket_size_max: 120 vm.uma.hostcache.bucket_size: 120 vm.uma.hostcache.flags: 0x4301 vm.uma.hostcache.size: 96 vm.uma.syncache.stats.xdomain: 0 vm.uma.syncache.stats.fails: 0 vm.uma.syncache.stats.frees: 1 vm.uma.syncache.stats.allocs: 1 vm.uma.syncache.stats.current: 0 vm.uma.syncache.domain.0.wss: 3 vm.uma.syncache.domain.0.imin: 0 vm.uma.syncache.domain.0.imax: 0 vm.uma.syncache.domain.0.nitems: 0 ___ 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"
FYI for main (14: 847dfd2803f6 based) on arm64 (cortex-a72): 2 odd g_vfs_done failures happened
The following happened while doing: chflags -R noschg / It has not been repeatable. I've never gotten such before. The offset values look odd to me. chflags: g_vfs_done():gpt/FBSDmacchroot[READ(offset=-4154898212347031552, length=32768)]error = 5 /usr/fbsd/main-sg_vfs_done():gpt/FBSDmacchroot[READ(offset=-3164620936913141760, length=32768)]error = 5 rc/contrib/pjdfstest/tests/mkdir/05.t: Invalid argument chflags: /usr/fbsd/main-src/contrib/pjdfstest/tests/mkdir/06.t: Invalid argument chflags: /usr/fbsd/main-src/contrib/pjdfstest/tests/mkdir/07.t: Operation not supported chflags: /usr/fbsd/main-src/contrib/pjdfstest/tests/mkdir/08.t: Operation not supported chflags: /usr/fbsd/main-src/contrib/pjdfstest/tests/mkdir/09.t: Operation not supported chflags: /usr/fbsd/main-src/contrib/pjdfstest/tests/mkdir/11.t: Operation not supported chflags: /usr/fbsd/main-src/contrib/pjdfstest/tests/mkdir/12.t: Invalid argument chflags: /usr/fbsd/main-src/contrib/pjdfstest/tests/mkfifo/00.t: Operation not supported chflags: /usr/fbsd/main-src/contrib/pjdfstest/tests/mkfifo/05.t: Invalid argument The fsck_ffs after shutdown now and mount -r / got . . . # fsck_ffs -y / ** /dev/gpt/FBSDmacchroot ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes UNKNOWN FILE TYPE I=80660704 UNEXPECTED SOFT UPDATE INCONSISTENCY CLEAR? yes UNKNOWN FILE TYPE I=80660705 UNEXPECTED SOFT UPDATE INCONSISTENCY CLEAR? yes UNKNOWN FILE TYPE I=80660706 UNEXPECTED SOFT UPDATE INCONSISTENCY CLEAR? yes UNKNOWN FILE TYPE I=80660707 UNEXPECTED SOFT UPDATE INCONSISTENCY CLEAR? yes UNKNOWN FILE TYPE I=80660708 UNEXPECTED SOFT UPDATE INCONSISTENCY CLEAR? yes UNKNOWN FILE TYPE I=80660709 UNEXPECTED SOFT UPDATE INCONSISTENCY CLEAR? yes UNKNOWN FILE TYPE I=80660710 UNEXPECTED SOFT UPDATE INCONSISTENCY CLEAR? yes UNKNOWN FILE TYPE I=80660711 UNEXPECTED SOFT UPDATE INCONSISTENCY CLEAR? yes UNKNOWN FILE TYPE I=80660712 UNEXPECTED SOFT UPDATE INCONSISTENCY CLEAR? yes UNKNOWN FILE TYPE I=80660713 UNEXPECTED SOFT UPDATE INCONSISTENCY CLEAR? yes UNKNOWN FILE TYPE I=80660714 UNEXPECTED SOFT UPDATE INCONSISTENCY CLEAR? yes UNKNOWN FILE TYPE I=80660715 UNEXPECTED SOFT UPDATE INCONSISTENCY CLEAR? yes UNKNOWN FILE TYPE I=80660716 UNEXPECTED SOFT UPDATE INCONSISTENCY CLEAR? yes UNKNOWN FILE TYPE I=80660717 UNEXPECTED SOFT UPDATE INCONSISTENCY CLEAR? yes UNKNOWN FILE TYPE I=80660718 UNEXPECTED SOFT UPDATE INCONSISTENCY CLEAR? yes UNKNOWN FILE TYPE I=80660719 UNEXPECTED SOFT UPDATE INCONSISTENCY CLEAR? yes ** Phase 2 - Check Pathnames UNALLOCATED I=80660704 OWNER=root MODE=0 SIZE=0 MTIME=Dec 31 16:00 1969 NAME=/usr/fbsd/main-src/contrib/pjdfstest/tests/mkdir/04.t UNEXPECTED SOFT UPDATE INCONSISTENCY REMOVE? yes UNALLOCATED I=80660705 OWNER=root MODE=0 SIZE=0 MTIME=Dec 31 16:00 1969 NAME=/usr/fbsd/main-src/contrib/pjdfstest/tests/mkdir/05.t UNEXPECTED SOFT UPDATE INCONSISTENCY REMOVE? yes UNALLOCATED I=80660706 OWNER=root MODE=0 SIZE=0 MTIME=Dec 31 16:00 1969 NAME=/usr/fbsd/main-src/contrib/pjdfstest/tests/mkdir/06.t UNEXPECTED SOFT UPDATE INCONSISTENCY REMOVE? yes UNALLOCATED I=80660707 OWNER=root MODE=0 SIZE=0 MTIME=Dec 31 16:00 1969 NAME=/usr/fbsd/main-src/contrib/pjdfstest/tests/mkdir/07.t UNEXPECTED SOFT UPDATE INCONSISTENCY REMOVE? yes UNALLOCATED I=80660708 OWNER=root MODE=0 SIZE=0 MTIME=Dec 31 16:00 1969 NAME=/usr/fbsd/main-src/contrib/pjdfstest/tests/mkdir/08.t UNEXPECTED SOFT UPDATE INCONSISTENCY REMOVE? yes UNALLOCATED I=80660709 OWNER=root MODE=0 SIZE=0 MTIME=Dec 31 16:00 1969 NAME=/usr/fbsd/main-src/contrib/pjdfstest/tests/mkdir/09.t UNEXPECTED SOFT UPDATE INCONSISTENCY REMOVE? yes UNALLOCATED I=80660710 OWNER=root MODE=0 SIZE=0 MTIME=Dec 31 16:00 1969 NAME=/usr/fbsd/main-src/contrib/pjdfstest/tests/mkdir/10.t UNEXPECTED SOFT UPDATE INCONSISTENCY REMOVE? yes UNALLOCATED I=80660711 OWNER=root MODE=0 SIZE=0 MTIME=Dec 31 16:00 1969 NAME=/usr/fbsd/main-src/contrib/pjdfstest/tests/mkdir/11.t UNEXPECTED SOFT UPDATE INCONSISTENCY REMOVE? yes UNALLOCATED I=80660712 OWNER=root MODE=0 SIZE=0 MTIME=Dec 31 16:00 1969 NAME=/usr/fbsd/main-src/contrib/pjdfstest/tests/mkdir/12.t UNEXPECTED SOFT UPDATE INCONSISTENCY REMOVE? yes UNALLOCATED I=80660713 OWNER=root MODE=0 SIZE=0 MTIME=Dec 31 16:00 1969 NAME=/usr/fbsd/main-src/contrib/pjdfstest/tests/mkfifo/00.t UNEXPECTED SOFT UPDATE INCONSISTENCY REMOVE? yes UNALLOCATED I=80660714 OWNER=root MODE=0 SIZE=0 MTIME=Dec 31 16:00 1969 NAME=/usr/fbsd/main-src/contrib/pjdfstest/tests/mkfifo/01.t UNEXPECTED SOFT UPDATE INCONSISTENCY REMOVE? yes UNALLOCATED I=80660715 OWNER=root MODE=0 SIZE=0 MTIME=Dec 31 16:00 1969 NAME=/usr/fbsd/main-src/contrib/pjdfstest/tests/mkfifo/02.t UNEXPECTED SOFT UPDATE INCONSISTENCY REMOVE? yes UNALLOCATED I=80660716 OWNER=root MODE=0 SIZE=0 MTIME=Dec 31 16:00 1969 NAME=/usr/fbsd/main-src/contrib/pjdfstest/tests/mkfifo/03.t UNEXPECTED SOFT UPDATE INCONSISTENCY REMOVE? yes
Re: [PATCH, LIBM] powf is wrong with x near 1 and |y| >> 1
On 7 Feb 2021, at 23:53, Steve Kargl wrote: > > See the last few comments here: > > https://github.com/JuliaMath/openlibm/issues/211 Thanks Steve. Committed here: https://cgit.freebsd.org/src/commit/?id=93fc67896550548f91b307dbe3053f11db5d4a8a -Dimitry signature.asc Description: Message signed with OpenPGP
Re: panic in drm or vt or deadlock on mutex or ...
On Mon, 08 Feb 2021 21:05:24 +0300 Greg V wrote: > > > On Mon, Feb 8, 2021 at 04:53, Alastair Hogge wrote: > > On 2021-02-04 17:50, Emmanuel Vadot wrote: > > > > [...] > > > >> Only happens with drm when you do what ? > > > > Boot to multi-user; login (getty): > > $ doas kldload /boot/modules/amdgpu.ko > > $ sysctl > > [panic] > > > > ..is a guaranteed way to panic my system. > > > https://github.com/freebsd/drm-kmod/issues/15 ? > https://github.com/freebsd/drm-kmod/pull/37 ? Yeah I was about to link that. To my knowledge this should be fixed but maybe something else is needed for some different gpu. Alastair: Can you report a bug there : https://github.com/freebsd/drm-kmod/issues Cheers, -- Emmanuel Vadot ___ 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: When is 'zpool offline' required?
On Mon, Feb 8, 2021 at 10:10 AM joe mcguckin wrote: > I was just playing around with a test ZFS system and was running through > replacing a bad drive and I forgot to issue a ‘zpool offline’ command. > Everything seemed to go ok anyway. The system started resilvering, etc. > When is ‘zpool required’? Under what conditions can I omit it? > If the drive is dying but still working, then using "zpool offline" is recommended, to tell the pool to stop using the drive. This is also handy if there's going to be a delay between "noticed the drive is dying" and "have a replacement drive available". If the drive is completely dead, then most likely it will be dropped from the pool automatically by ZFS, so "zpool offline" isn't needed. While it's generally "better" to offline drives, ZFS is designed to withstand drives dropping off without warning. > Is there a dedicated mailing list for ZFS user questions? > There's a zfs-discuss mailing list run by the OpenZFS project. There isn't a FreeBSD ZFS-specific mailing list, but there is a freebsd-fs@ mailing list for everything filesystem related (UFS, ZFS, mfs, NFS, etc). Cheers, Freddie ___ 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"
When is 'zpool offline' required?
I was just playing around with a test ZFS system and was running through replacing a bad drive and I forgot to issue a ‘zpool offline’ command. Everything seemed to go ok anyway. The system started resilvering, etc. When is ‘zpool required’? Under what conditions can I omit it? Is there a dedicated mailing list for ZFS user questions? Thanks, Joe Joe McGuckin ViaNet Communications j...@via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax > On Jan 12, 2021, at 10:35 AM, Kurt Jaeger wrote: > > Hi! > >> How should I label and prepare the drives for ZFS? Someone ought to write a >> ???cookbook??? on that! > > Basically, what I once did, was this: > > zpool create bck raidz2 ada2 ada3 ada4 ada5 ada6 ada7 ada8 ada9 > > Therefore: raw disks, nothing else. > >> Do I need to start the volume on a particular sector boundary? >> >> Are the 4096 byte sector drives usable? > > I think the default is now 4096 anyway. > > https://charsiurice.wordpress.com/2016/05/30/checking-ashift-on-existing-pools/ > > describes the command to check for 4096 blocks: > > zdb -C | grep ashift > > If it displays > > ashift: 9 > > the blocks are 512 bytes. > > If it displays > > ashift: 12 > > the block size is 4096. > > -- > p...@opsec.eu+49 171 3101372Now what ? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic in drm or vt or deadlock on mutex or ...
On Mon, Feb 8, 2021 at 04:53, Alastair Hogge wrote: On 2021-02-04 17:50, Emmanuel Vadot wrote: [...] Only happens with drm when you do what ? Boot to multi-user; login (getty): $ doas kldload /boot/modules/amdgpu.ko $ sysctl [panic] ..is a guaranteed way to panic my system. https://github.com/freebsd/drm-kmod/issues/15 → https://github.com/freebsd/drm-kmod/pull/37 ? ___ 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"
Upgrade 13.0 base OpenSSH to 8.4?
Hi there, I wonder if it's too late to ask if it's possible to bump openssh in base to version 8.4 for 13.0, which enables nist-p256-capable keys and fido/u2f support. Despite the fido/u2f capabilities requires libfido2, iirc it is possible to compile openssh without libfido2 but to enable it in sshd_config, therefore it is not necessary to add libfido2 as a dependency to base. Michael ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic in drm or vt or deadlock on mutex or ...
On 2/8/21 1:53 PM, Alastair Hogge wrote:
Boot to multi-user; login (getty):
$ doas kldload /boot/modules/amdgpu.ko
$ sysctl
[panic]
..is a guaranteed way to panic my system.
Hi,
Maybe you could do a hack and edit the sysctl source code:
1) print the sysctl before it is queried.
2) sleep 1 second between print and query.
Should be easy to nail this down!
--HPS
diff --git a/sbin/sysctl/sysctl.c b/sbin/sysctl/sysctl.c
index 30d6d94723f..4b45bb2f967 100644
--- a/sbin/sysctl/sysctl.c
+++ b/sbin/sysctl/sysctl.c
@@ -336,6 +336,10 @@ parse_numeric(const char *newvalstr, const char *fmt, u_int kind,
return (true);
}
+#define sysctl(...) ({ \
+ usleep(100); \
+ sysctl(__VA_ARGS__); })
+
/*
* Parse a name into a MIB entry.
* Lookup and print out the MIB entry if it exists.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic in drm or vt or deadlock on mutex or ...
On 2021-02-04 17:50, Emmanuel Vadot wrote: [...] > Only happens with drm when you do what ? Boot to multi-user; login (getty): $ doas kldload /boot/modules/amdgpu.ko $ sysctl [panic] ..is a guaranteed way to panic my system. ___ 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"
