Re: FYI: artifact-based head bisect and OPi+2e (an armv7): -r359311 fails to boot but -r359309 boots (kernel substitutions)
On 2020-Mar-29, at 10:58, Ian Lepore wrote: > On Sun, 2020-03-29 at 09:44 -0700, Thomas Skibo wrote: >> On Sun, Mar 29, 2020 at 12:29:00AM -0700, Mark Millard via freebsd- >> arm wrote: >>> While trying to update the head version >>> in use I ran into boot hangups on the >>> OrangePi+ 2e and did an approximate >>> bisect of artificact.freebsd.org kernels >>> to find approximately which kernel >>> version the issue started at. >>> >>> I found that head -r359309 boots and >>> -r359311 fails (shown later below). >>> The original update attempt was from >>> -r359966 to -r359376 and -r359376 >>> stopped there as well. (I kept world >>> there and varied the kernel version >>> for the approximate bisect activity.) >>> >>> It seems that at least one of the >>> "MI-namespace" atomics added do not work >>> in all its usage-contexts on the cortexA7 >>> (armv7) involved. >> >> It looks like my previous reply didn't go to the mailing lists. I'm >> new to >> mutt. >> >> Anyway, I looked at this problem yesterday and it seems r359311 >> enables >> using some atomic operations that were not being used until now. In >> particular, atomic_fcmpset_8() seems broken and hangs up >> in vm_page_bits_swap(). I think I have a fix but I want to run it >> by Ian. >> >> --Thomas >> >> Index: sys/arm/include/atomic-v6.h >> === >> --- sys/arm/include/atomic-v6.h (revision 359412) >> +++ sys/arm/include/atomic-v6.h (working copy) >> @@ -196,7 +196,7 @@ >> \ >> __asm __volatile( \ >> "1: ldrex" SUF " %[tmp], [%[ptr]] \n" \ >> -" ldr%[ret], [%[oldv]] \n" \ >> +" ldr" SUF " %[ret], [%[oldv]] \n" \ >> " teq%[tmp], %[ret]\n" \ >> " ittee ne\n" \ >> " str" SUF "ne %[tmp], [%[oldv]] \n" \ >> > > > I've committed this fix as r359423, thanks! Thanks to both of you: the OPi+2e boots just fine now and has been operating like it used to (head -r359427 in use). === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ 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: FYI: artifact-based head bisect and OPi+2e (an armv7): -r359311 fails to boot but -r359309 boots (kernel substitutions)
On Sun, 2020-03-29 at 09:44 -0700, Thomas Skibo wrote: > On Sun, Mar 29, 2020 at 12:29:00AM -0700, Mark Millard via freebsd- > arm wrote: > > While trying to update the head version > > in use I ran into boot hangups on the > > OrangePi+ 2e and did an approximate > > bisect of artificact.freebsd.org kernels > > to find approximately which kernel > > version the issue started at. > > > > I found that head -r359309 boots and > > -r359311 fails (shown later below). > > The original update attempt was from > > -r359966 to -r359376 and -r359376 > > stopped there as well. (I kept world > > there and varied the kernel version > > for the approximate bisect activity.) > > > > It seems that at least one of the > > "MI-namespace" atomics added do not work > > in all its usage-contexts on the cortexA7 > > (armv7) involved. > > It looks like my previous reply didn't go to the mailing lists. I'm > new to > mutt. > > Anyway, I looked at this problem yesterday and it seems r359311 > enables > using some atomic operations that were not being used until now. In > particular, atomic_fcmpset_8() seems broken and hangs up > in vm_page_bits_swap(). I think I have a fix but I want to run it > by Ian. > > --Thomas > > Index: sys/arm/include/atomic-v6.h > === > --- sys/arm/include/atomic-v6.h (revision 359412) > +++ sys/arm/include/atomic-v6.h (working copy) > @@ -196,7 +196,7 @@ >\ > __asm __volatile( \ > "1: ldrex" SUF " %[tmp], [%[ptr]] \n" \ > - " ldr%[ret], [%[oldv]] \n" \ > + " ldr" SUF " %[ret], [%[oldv]] \n" \ > " teq%[tmp], %[ret]\n" \ > " ittee ne\n" \ > " str" SUF "ne %[tmp], [%[oldv]] \n" \ > I've committed this fix as r359423, thanks! -- Ian ___ 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: artifact-based head bisect and OPi+2e (an armv7): -r359311 fails to boot but -r359309 boots (kernel substitutions)
While trying to update the head version in use I ran into boot hangups on the OrangePi+ 2e and did an approximate bisect of artificact.freebsd.org kernels to find approximately which kernel version the issue started at. I found that head -r359309 boots and -r359311 fails (shown later below). The original update attempt was from -r359966 to -r359376 and -r359376 stopped there as well. (I kept world there and varied the kernel version for the approximate bisect activity.) It seems that at least one of the "MI-namespace" atomics added do not work in all its usage-contexts on the cortexA7 (armv7) involved. [I also ran into boot problems on the RPi4 (arch64 CortexA72) for the original upgrade in that context. But the RPi4 is incomplete and is not a long-established FreeBSD context. I've not tested it specifically against -r359309 and -r359311 . I'll otherwise ignore the RPi4 here, at least for now.] The OPi+2e hangups look like (a boot -v example): . . . Release APs CPU(1) applied BP hardening: not necessary CPU(3) applied BP hardening: not necessary CPU(2) applied BP hardening: not necessary regulator: shutting down unused regulators regulator: shutting down vcc3v0... Trying to mount root from ufs:/dev/gpt/BPIM3root []... ok Root mount waiting for:regulator: shutting down vcc3v3... usbus0busy usbus2regulator: shutting down vcc5v0... usbus4ok usbus6regulator: shutting down gmac-3v3... CAMbusy uhub1: 1 port with 1 removable, self powered uhub3: 1 port with 1 removable, self powered uhub4: 1 port with 1 removable, self powered uhub6: 1 port with 1 removable, self powered Root mount waiting for: usbus6 CAM ugen6.2: at usbus6 umass0 on uhub6 umass0: on usbus6 umass0:0:0: Attached to scbus0 Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM GEOM: new disk da0 pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 pass0: Fixed Direct Access SPC-4 SCSI device pass0: Serial Number REPLACED pass0: 40.000MB/s transfers da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SPC-4 SCSI device da0: Serial Number REPLACED da0: 40.000MB/s transfers da0: 228936MB (468862128 512 byte sectors) da0: quirks=0x2 da0: Delete methods: mountroot: waiting for device /dev/gpt/BPIM3root... random: unblocking device. rtc0: providing initial system time start_init: trying /sbin/init (And that is as far as it gets. I can break into the debugger on the console.) Notes: vfs.root.mountfrom= is used in /boot/loader.conf to direct the root file system to be from the USB SSD. The original kernel and world were non-debug builds. But the artifact kernels are debug builds. They did not report anything odd. (The /dev/gpt/BPIM3* based naming is from repurposing media without bothering to rename things.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ 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"
