Re: r351589 ses no longer attaches
Hi Alexander, thank you for quick response. I confirm that r354923 fixes this issue in 12-STABLE. # dmesg | grep ^ses ses0 at ahciem0 bus 0 scbus6 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device ses0: pass0,ada0 in 'Slot 00', SATA Slot: scbus0 target 0 ses0: pass1,ada1 in 'Slot 01', SATA Slot: scbus1 target 0 ses0: pass2,ada2 in 'Slot 02', SATA Slot: scbus2 target 0 ses0: pass3,ada3 in 'Slot 03', SATA Slot: scbus3 target 0 ses0: pass4,ada4 in 'Slot 04', SATA Slot: scbus4 target 0 ses0: pass5,ada5 in 'Slot 05', SATA Slot: scbus5 target 0 regards Michal > On 21 Nov 2019, at 00:58, Alexander Motin wrote: > > Hi Michael, > > I'm sorry, I've forgot to merge it after Warner merged his r351356. > Please try the fresh stable/12 and tell if you still have a problem. > > On 20.11.2019 17:34, Michal Vančo wrote: >> Hi, >> >> I have an issue with SES not working with AHCI. After some digging I found a >> thread on freebsd-current >> (https://lists.freebsd.org/pipermail/freebsd-current/2019-August/074176.html) >> where exactly the same issue was described and finally fixed in r351589. My >> question is, will this fix be merged into 12-STABLE? I tried manually >> patching 12-STABLE src tree and after rebuilding the kernel SES started to >> work as expected. I don’t want to run CURRENT just for this simple fix. > > -- > Alexander Motin > ___ > 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: breakage at usr.sbin/jail/Makefile
On Wed, Nov 20, 2019 at 08:18:52PM -0800, Pete Wright wrote:
>
>
> On 11/20/19 8:13 PM, Glen Barber wrote:
> > On Wed, Nov 20, 2019 at 07:57:57PM -0800, Pete Wright wrote:
> > > Hello,
> > > looks like some of the recent commits to usr.sbin/jail/Makefile has broken
> > > CURRENT. I am getting this error when attempting a buildworld:
> > >
> > > ===> usr.sbin/jail (cleandir)
> > > make[4]: "/usr/home/pete/git/freebsd/usr.sbin/jail/Makefile" line 21:
> > > Malformed conditional (${LINKER_TYPE} == "bfd" && ${MACHINE} == "riscv")
> > > make[4]: Fatal errors encountered -- cannot continue
> > > make[4]: stopped in /usr/home/pete/git/freebsd/usr.sbin/jail
> > > *** [cleandir_subdir_usr.sbin/jail] Error code 1
> > >
> > >
> > > here's the code in question:
> > > 18 # workaround for GNU ld (GNU Binutils) 2.33.1:
> > > 19 # relocation truncated to fit: R_RISCV_GPREL_I against `.LANCHOR2'
> > > 20 # https://bugs.freebsd.org/242109
> > > 21 .if ${LINKER_TYPE} == "bfd" && ${MACHINE} == "riscv"
> > > 22 CFLAGS+=-Wl,--no-relax
> > > 23 .endif
> > >
> > >
> > > looks like Ed Maste caught this already in the
> > > https://bugs.freebsd.org/242109 but wanted to flag it here as well in case
> > > anyone else runs into this in the hopes it saves some debugging time :)
> > >
> > Reverted out of frustration in r354935.
>
> thanks!
>
> the issue seems to be on my amd64 system ${LINKER_TYPE} is not defined. i was
> contemplating suggesting updating the .if clause in the Makefile like so:
>
> .if defined($LINKER_TYPE}) && ${LINKER_TYPE} == "bfd" && ${MACHINE} ==
> "riscv"
>
>
> it allows things to compile on my end, but i'm not sure this is best way to
> resolve this issue.
>
Not necessarily, there were followups to the original commit that leaned
in different directions. But, nonetheless, I reverted the offending
commits because allowing head to be broken for hours is absurd, and
I personally do not tolerate it when I can resolve it.
Glen
signature.asc
Description: PGP signature
Re: breakage at usr.sbin/jail/Makefile
On 11/20/19 8:13 PM, Glen Barber wrote:
On Wed, Nov 20, 2019 at 07:57:57PM -0800, Pete Wright wrote:
Hello,
looks like some of the recent commits to usr.sbin/jail/Makefile has broken
CURRENT. I am getting this error when attempting a buildworld:
===> usr.sbin/jail (cleandir)
make[4]: "/usr/home/pete/git/freebsd/usr.sbin/jail/Makefile" line 21:
Malformed conditional (${LINKER_TYPE} == "bfd" && ${MACHINE} == "riscv")
make[4]: Fatal errors encountered -- cannot continue
make[4]: stopped in /usr/home/pete/git/freebsd/usr.sbin/jail
*** [cleandir_subdir_usr.sbin/jail] Error code 1
here's the code in question:
18 # workaround for GNU ld (GNU Binutils) 2.33.1:
19 # relocation truncated to fit: R_RISCV_GPREL_I against `.LANCHOR2'
20 # https://bugs.freebsd.org/242109
21 .if ${LINKER_TYPE} == "bfd" && ${MACHINE} == "riscv"
22 CFLAGS+=-Wl,--no-relax
23 .endif
looks like Ed Maste caught this already in the
https://bugs.freebsd.org/242109 but wanted to flag it here as well in case
anyone else runs into this in the hopes it saves some debugging time :)
Reverted out of frustration in r354935.
thanks!
the issue seems to be on my amd64 system ${LINKER_TYPE} is not defined.
i was contemplating suggesting updating the .if clause in the Makefile
like so:
.if defined($LINKER_TYPE}) && ${LINKER_TYPE} == "bfd" && ${MACHINE} ==
"riscv"
it allows things to compile on my end, but i'm not sure this is best way
to resolve this issue.
-p
--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA
___
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: breakage at usr.sbin/jail/Makefile
On Wed, Nov 20, 2019 at 07:57:57PM -0800, Pete Wright wrote:
> Hello,
> looks like some of the recent commits to usr.sbin/jail/Makefile has broken
> CURRENT. I am getting this error when attempting a buildworld:
>
> ===> usr.sbin/jail (cleandir)
> make[4]: "/usr/home/pete/git/freebsd/usr.sbin/jail/Makefile" line 21:
> Malformed conditional (${LINKER_TYPE} == "bfd" && ${MACHINE} == "riscv")
> make[4]: Fatal errors encountered -- cannot continue
> make[4]: stopped in /usr/home/pete/git/freebsd/usr.sbin/jail
> *** [cleandir_subdir_usr.sbin/jail] Error code 1
>
>
> here's the code in question:
> 18 # workaround for GNU ld (GNU Binutils) 2.33.1:
> 19 # relocation truncated to fit: R_RISCV_GPREL_I against `.LANCHOR2'
> 20 # https://bugs.freebsd.org/242109
> 21 .if ${LINKER_TYPE} == "bfd" && ${MACHINE} == "riscv"
> 22 CFLAGS+=-Wl,--no-relax
> 23 .endif
>
>
> looks like Ed Maste caught this already in the
> https://bugs.freebsd.org/242109 but wanted to flag it here as well in case
> anyone else runs into this in the hopes it saves some debugging time :)
>
Reverted out of frustration in r354935.
Glen
signature.asc
Description: PGP signature
breakage at usr.sbin/jail/Makefile
Hello,
looks like some of the recent commits to usr.sbin/jail/Makefile has
broken CURRENT. I am getting this error when attempting a buildworld:
===> usr.sbin/jail (cleandir)
make[4]: "/usr/home/pete/git/freebsd/usr.sbin/jail/Makefile" line 21:
Malformed conditional (${LINKER_TYPE} == "bfd" && ${MACHINE} == "riscv")
make[4]: Fatal errors encountered -- cannot continue
make[4]: stopped in /usr/home/pete/git/freebsd/usr.sbin/jail
*** [cleandir_subdir_usr.sbin/jail] Error code 1
here's the code in question:
18 # workaround for GNU ld (GNU Binutils) 2.33.1:
19 # relocation truncated to fit: R_RISCV_GPREL_I against `.LANCHOR2'
20 # https://bugs.freebsd.org/242109
21 .if ${LINKER_TYPE} == "bfd" && ${MACHINE} == "riscv"
22 CFLAGS+=-Wl,--no-relax
23 .endif
looks like Ed Maste caught this already in the
https://bugs.freebsd.org/242109 but wanted to flag it here as well in
case anyone else runs into this in the hopes it saves some debugging time :)
-p
--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA
___
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: r351589 ses no longer attaches
Hi Michael, I'm sorry, I've forgot to merge it after Warner merged his r351356. Please try the fresh stable/12 and tell if you still have a problem. On 20.11.2019 17:34, Michal Vančo wrote: > Hi, > > I have an issue with SES not working with AHCI. After some digging I found a > thread on freebsd-current > (https://lists.freebsd.org/pipermail/freebsd-current/2019-August/074176.html) > where exactly the same issue was described and finally fixed in r351589. My > question is, will this fix be merged into 12-STABLE? I tried manually > patching 12-STABLE src tree and after rebuilding the kernel SES started to > work as expected. I don’t want to run CURRENT just for this simple fix. -- Alexander Motin ___ 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: Reverting -current by date.
On Wed, Nov 20, 2019 at 02:52:22PM -0800, Mark Millard wrote: > > Unfortunately for Bob P., no suggestion can meet his full criteria. So > he has several suggestions to potentially pick from or to use in > combination. > This is a most gracious way of saying my expectations are unreasonable. Sad but not surprising. At least now I know. Thanks to everyone for enlightening me, bob prohaska > >> > >> . . . > > > > === > 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: g_vfs_done():ufs/rootfs[WRITE flood on rpi3
On Wed, Nov 20, 2019 at 04:41:46PM -0600, Kyle Evans wrote: > > The revisions noted are a good data point, thanks! Can you try > upgrading the kernel past r354875 before I revert the most likely > candidate up to that point? Perhaps with this patch applied, to make > sure you're not hitting an interrupt race that's hard to deduce from > logs: https://reviews.freebsd.org/D22430.diff > The r354909 kernel is running now, doing a test compile of www/chromium. so far no problems are apparent. > More than willing to build a kernel as described and put up for you to > download, as well, if you'd accept that. > If I understand correctly there's no need, if I'm mistaken please let me know. Thanks for your attention! bob prohaska > Thanks, > > Kyle Evans ___ 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: Reverting -current by date.
On 11/20/19 12:02 PM, bob prohaska wrote: On Wed, Nov 20, 2019 at 11:18:41AM -0700, Warner Losh wrote: On Wed, Nov 20, 2019 at 10:39 AM bob prohaska wrote: From time to time it would be handy to revert freebsd-current to an older, well-behaved revision. Is there a mechanism for identifying revision numbers that will at least compile and boot, by date? Almost all of them will compile. Almost all of those will boot. While some build breakage sneaks through, the default assumption is that it's good. That's certainly been my experience randomly updating to -current. There's some that are more or less performant, mind you, and some that are more or less stable, it is true. But the overwhelming vast majority will compile and boot, at least for amd64. I have issues less than 1% of the time when updating to whatever is current at the moment I fancy an update. Are commits that depend on one another somehow grouped in a single revision? Unlike in the old CVS days, yes, our commit rules require any single commit to not break the build or system, which, as a corollary means that people should commit all changes required to do so in a single commit. There's some hardware that gets broken from time to time, but we don't track that specifically. And non-amd64 architectures takes more care and planning as any build breakage for those platforms lasts longer, in direct proportion to how popular the platform is Point taken. I'm interested in aarch64, which puts me somewhat in the weeds. It's all in the commit logs. If you run -current you need to read them. They will also tell you almost always if you pick revision X if there was a subsequent fix that made things compile you should go with. I take it the strategy would be go back in the log to a rough date, then browse forward in time looking for signs of major trouble. When the commits turn minor/benign, select a revision from that timeframe. basically yes. I usually do a (more or less) binary search, informed by examination of the sources and commit history. Study the commit logs? I know I'm harping on that, but when things go wrong, that's what I do. I hoped for a more mechanical approach. For example, snapshots are generated from time to time. Presumably, they're vetted in some way and knowing what revisions made it to the snapshot stage might be a starting point. The snapshot server does not appear to contain that information for earlier offerings. yes there are snapshots but they are more likely to be vetted for compiling than for running successfully on your hardware. Also -DNO_CLEAN builds help a lot if you're worried about it not even building, though from time to time you run into issues with a NO_CLEAN build due to a recent commit that wasn't appreciated at the time of the commit, but was later and fixed. Does -DNO_CLEAN behave sanely (and usefully) when going backwards in time? I commonly use it for small forward steps, but time reversal is tricky 8-) Good question.. that would depend on whether the source control program you use updates the timestamps of the files to be the time of commit or time of update.. I am pretty sure svn just uses the time that you ran the command. However SOMETIMES there are changes that are made to support forward migration that may not work well with backwards migration.. I tend to do several NO_CLEAN builds but every now and then I'll do a full build if I've gone too far or if things seem a bit odd. Thanks for replying! bob prohaska ___ 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: g_vfs_done():ufs/rootfs[WRITE flood on rpi3
On 11/20/19 2:37 PM, bob prohaska wrote: While compiling a kernel at r354909 using a system at r354845 the serial console flooded with messages of the form g_vfs_done():ufs/rootfs[WRITE(offset=266534912, length=32768)]error = 5 occasionally interspersed with mmcsd0: Error indicated: 1 Timeout g_vfs_done():ufs/rootfs[WRITE(offset=268697600, length=32768)]emmcsd0: Error indicated: 1 Timeout It looked like the microSD card had finally failed, but breaking to the debugger and rebooting seems to have recovered normally: The kernel build picked up where it left off and the new kernel appears to boot and run. There are a few explanations as to how this succeeded. One thing to note is that during builds, there is a large chance that any given write does not to be persisted as it is a temporary write of some kind. As long as the next reader of the file can get it from cache, things will succeed. There is also of course the chance that the write actually succeeded but that it happened later or that the response was bad rather than the write.. This can happen due to bugs in the firmware of the card. And finally, potentially when you rebuilt, the failed steps were redone. UFS Soft updates would help that result as it will not allow the metadata to be written until the data for the file was successfully written.. It will however be worth keeping an eye on that device.. ___ 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: Reverting -current by date.
On 2019-Nov-20, at 14:28, Julian Elischer wrote: > On 11/20/19 1:51 PM, Mark Millard wrote: >> Bob P. wrote for an aarch64 context: >> >>> From time to time it would be handy to revert freebsd-current to >>> an older, well-behaved revision. >>> >>> Is there a mechanism for identifying revision numbers that >>> will at least compile and boot, by date? >>> >>> In my case buildworld seems to be markedly slower than, say, >>> six months ago. Maybe it's hardware, maybe something else. Is >>> there a way to pick a revision number to revert to, that's >>> better than merely guessing? >> You can explore the history of installable world/kernel materials >> at places matching the pattern: >> >> https://artifact.ci.freebsd.org/snapshot/head/r*/arm64/aarch64/* > > I find that https://svnweb.freebsd.org/base/ is good enough to allow > exploration of revisions. If you add a revision in the given field you will > only see revs show up that are older than that. > The difference is my suggestion shows examples of builds that completed and produced world and kernel materials. (But looking around is messier. At least https://artifact.ci.freebsd.org/snapshot/head/ shows dates too.) Plus, he might at times be able to avoid building by using the *.txz files to advantage. I use https://svnweb.freebsd.org/base/ as well, but not to directly find examples that built or materials that avoid my needing to build. It can help decide what to explore under https://artifact.ci.freebsd.org/snapshot/head/ when such material are relevant. Unfortunately for Bob P., no suggestion can meet his full criteria. So he has several suggestions to potentially pick from or to use in combination. >> >> . . . > === 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: g_vfs_done():ufs/rootfs[WRITE flood on rpi3
On Wed, Nov 20, 2019 at 4:37 PM bob prohaska wrote: > > While compiling a kernel at r354909 using a system at > r354845 the serial console flooded with messages of the > form > g_vfs_done():ufs/rootfs[WRITE(offset=266534912, length=32768)]error = 5 > > occasionally interspersed with > > mmcsd0: Error indicated: 1 Timeout > g_vfs_done():ufs/rootfs[WRITE(offset=268697600, length=32768)]emmcsd0: Error > indicated: 1 Timeout > > It looked like the microSD card had finally failed, but breaking to > the debugger and rebooting seems to have recovered normally: The kernel > build picked up where it left off and the new kernel appears to boot > and run. > > The console output follows, the "Timeout poll on interrupt endpoint" > messages are an artifact of an old Dell keyboard. : > Hi, The revisions noted are a good data point, thanks! Can you try upgrading the kernel past r354875 before I revert the most likely candidate up to that point? Perhaps with this patch applied, to make sure you're not hitting an interrupt race that's hard to deduce from logs: https://reviews.freebsd.org/D22430.diff More than willing to build a kernel as described and put up for you to download, as well, if you'd accept that. Thanks, Kyle Evans ___ 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"
g_vfs_done():ufs/rootfs[WRITE flood on rpi3
While compiling a kernel at r354909 using a system at r354845 the serial console flooded with messages of the form g_vfs_done():ufs/rootfs[WRITE(offset=266534912, length=32768)]error = 5 occasionally interspersed with mmcsd0: Error indicated: 1 Timeout g_vfs_done():ufs/rootfs[WRITE(offset=268697600, length=32768)]emmcsd0: Error indicated: 1 Timeout It looked like the microSD card had finally failed, but breaking to the debugger and rebooting seems to have recovered normally: The kernel build picked up where it left off and the new kernel appears to boot and run. The console output follows, the "Timeout poll on interrupt endpoint" messages are an artifact of an old Dell keyboard. : g_vfs_done():ufs/rootfs[WRITE(offset=10178002944, length=32768)]error = 5 g_vfs_done():ufs/rootfs[WRITE(offset=185663488, length=131072)]error = 5 g_vfs_done():ufs/rootfs[WRITE(offset=185794560, length=65536)]error = 5 g_vfs_done():ufs/rootfs[WRITE(offset=185958400, length=131072)]error = 5 g_vfs_done():ufs/rootfs[WRITE(offset=186089472, length=65536)]error = 5 g_vfs_done():ufs/rootfs[WRITE(offset=186286080, length=32768)]error = 5 g_vfs_done():ufs/rootfs[WRITE(offset=186384384, length=98304)]error = 5 g_vfs_done():ufs/rootfs[WRITE(offset=186515456, length=65536)]error = 5 g_vfs_done():ufs/rootfs[WRITE(offset=186908672, length=32768)]error = 5 KDB: enter: Break to debugger g_vfs_done():ufs/rootfs[WRITE(offset=188809216, length=65536)]e[ thread pid 12 tid 100015 ] Stopped at 0 db> bt Tracing pid 12 tid 100015 td 0xfd9b9000 db_trace_self() at db_stack_trace+0xf8 pc = 0x0072953c lr = 0x0010398c sp = 0x4f14dce0 fp = 0x4f14dd10 db_stack_trace() at db_command+0x228 pc = 0x0010398c lr = 0x00103604 sp = 0x4f14dd20 fp = 0x4f14de00 db_command() at db_command_loop+0x58 pc = 0x00103604 lr = 0x001033ac sp = 0x4f14de10 fp = 0x4f14de30 db_command_loop() at db_trap+0xf4 pc = 0x001033ac lr = 0x001066b0 sp = 0x4f14de40 fp = 0x4f14e060 db_trap() at kdb_trap+0x1d8 pc = 0x001066b0 lr = 0x004491dc sp = 0x4f14e070 fp = 0x4f14e120 kdb_trap() at do_el1h_sync+0xf4 pc = 0x004491dc lr = 0x00746400 sp = 0x4f14e130 fp = 0x4f14e160 do_el1h_sync() at handle_el1h_sync+0x78 pc = 0x00746400 lr = 0x0072b878 sp = 0x4f14e170 fp = 0x4f14e280 handle_el1h_sync() at kdb_alt_break_internal+0x130 pc = 0x0072b878 lr = 0x00448994 sp = 0x4f14e290 fp = 0x4f14e330 kdb_alt_break_internal() at kdb_alt_break+0xc pc = 0x00448994 lr = 0x00448854 sp = 0x4f14e340 fp = 0x4f14e340 kdb_alt_break() at uart_intr_rxready+0x88 pc = 0x00448854 lr = 0x002623f0 sp = 0x4f14e350 fp = 0x4f14e370 uart_intr_rxready() at uart_intr+0xec pc = 0x002623f0 lr = 0x002630d8 sp = 0x4f14e380 fp = 0x4f14e3b0 uart_intr() at intr_event_handle+0xc8 pc = 0x002630d8 lr = 0x003c3df0 sp = 0x4f14e3c0 fp = 0x4f14e400 intr_event_handle() at intr_isrc_dispatch+0x34 pc = 0x003c3df0 lr = 0x0077c624 sp = 0x4f14e410 fp = 0x4f14e420 intr_isrc_dispatch() at bcm2835_intc_intr+0xa8 pc = 0x0077c624 lr = 0x00718658 sp = 0x4f14e430 fp = 0x4f14e470 bcm2835_intc_intr() at intr_event_handle+0xc8 pc = 0x00718658 lr = 0x003c3df0 sp = 0x4f14e480 fp = 0x4f14e4c0 intr_event_handle() at intr_isrc_dispatch+0x34 pc = 0x003c3df0 lr = 0x0077c624 sp = 0x4f14e4d0 fp = 0x4f14e4e0 intr_isrc_dispatch() at bcm_lintc_intr+0x1e8 pc = 0x0077c624 lr = 0x0071e5ac sp = 0x4f14e4f0 fp = 0x4f14e570 bcm_lintc_intr() at intr_irq_handler+0x74 pc = 0x0071e5ac lr = 0x0077c484 sp = 0x4f14e580 fp = 0x4f14e5a0 intr_irq_handler() at handle_el1h_irq+0x74 pc = 0x0077c484 lr = 0x0072b938 sp = 0x4f14e5b0 fp = 0x4f14e6c0 handle_el1h_irq() at vt_flush+0x3a0 pc = 0x0072b938 lr = 0x002cb310 sp = 0x4f14e6d0 fp = 0x4f14e760 vt_flush() at vt_flush+0x3a0 pc = 0x002cb310 lr = 0x002cb310 sp = 0x4f14e770 fp = 0x4f14e7b0 vt_flush() at vt_timer+0x10 pc = 0x002cb310 lr = 0x002ca788 sp = 0x4f14e7c0
r351589 ses no longer attaches
Hi, I have an issue with SES not working with AHCI. After some digging I found a thread on freebsd-current (https://lists.freebsd.org/pipermail/freebsd-current/2019-August/074176.html) where exactly the same issue was described and finally fixed in r351589. My question is, will this fix be merged into 12-STABLE? I tried manually patching 12-STABLE src tree and after rebuilding the kernel SES started to work as expected. I don’t want to run CURRENT just for this simple fix. regards Michal ___ 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: Reverting -current by date.
On 11/20/19 1:51 PM, Mark Millard wrote: Bob P. wrote for an aarch64 context: From time to time it would be handy to revert freebsd-current to an older, well-behaved revision. Is there a mechanism for identifying revision numbers that will at least compile and boot, by date? In my case buildworld seems to be markedly slower than, say, six months ago. Maybe it's hardware, maybe something else. Is there a way to pick a revision number to revert to, that's better than merely guessing? You can explore the history of installable world/kernel materials at places matching the pattern: https://artifact.ci.freebsd.org/snapshot/head/r*/arm64/aarch64/* I find that https://svnweb.freebsd.org/base/ is good enough to allow exploration of revisions. If you add a revision in the given field you will only see revs show up that are older than that. Some r* will exist without having arm64/aarch64 material but having mateirals for other platforms. The * matches a svn revision number. These are from ci.freebsd.org builds, not the announced/released snaphots. These go back a long ways. ci.freebsd.org does not try to build every svn revision. (It does not build that fast relative to svn updating.) I sometimes use these for approximate bisection without building. The https://artifact.ci.freebsd.org/snapshot/head/r*/arm64/aarch64/* materials are compressed tar archives (*.txz) and a MANIFEST file. bsdinstall uses these files, although I've at times done basic testing activities based on just manually expanding the tars. (The materials do not span u-boot or other such and need to have file system(s) to expand into.) (From a different message:) I hoped for a more mechanical approach. For example, snapshots are generated from time to time. Presumably, they're vetted in some way and knowing what revisions made it to the snapshot stage might be a starting point. The snapshot server does not appear to contain that information for earlier offerings. Snapshots are not vetted as far as I know --and sometimes do not boot in contexts that I've tried. This applies both to artifact.ci.freebsd.org materials and the announced snapshots put under https://download.freebsd.org/ftp/snapshots/ . === 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" ___ 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: Reverting -current by date.
Bob P. wrote for an aarch64 context: > From time to time it would be handy to revert freebsd-current to > an older, well-behaved revision. > > Is there a mechanism for identifying revision numbers that > will at least compile and boot, by date? > > In my case buildworld seems to be markedly slower than, say, > six months ago. Maybe it's hardware, maybe something else. Is > there a way to pick a revision number to revert to, that's > better than merely guessing? You can explore the history of installable world/kernel materials at places matching the pattern: https://artifact.ci.freebsd.org/snapshot/head/r*/arm64/aarch64/* Some r* will exist without having arm64/aarch64 material but having mateirals for other platforms. The * matches a svn revision number. These are from ci.freebsd.org builds, not the announced/released snaphots. These go back a long ways. ci.freebsd.org does not try to build every svn revision. (It does not build that fast relative to svn updating.) I sometimes use these for approximate bisection without building. The https://artifact.ci.freebsd.org/snapshot/head/r*/arm64/aarch64/* materials are compressed tar archives (*.txz) and a MANIFEST file. bsdinstall uses these files, although I've at times done basic testing activities based on just manually expanding the tars. (The materials do not span u-boot or other such and need to have file system(s) to expand into.) (From a different message:) > I hoped for a more mechanical approach. For example, snapshots are > generated from time to time. Presumably, they're vetted in some way > and knowing what revisions made it to the snapshot stage might be a > starting point. The snapshot server does not appear to contain that > information for earlier offerings. Snapshots are not vetted as far as I know --and sometimes do not boot in contexts that I've tried. This applies both to artifact.ci.freebsd.org materials and the announced snapshots put under https://download.freebsd.org/ftp/snapshots/ . === 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: Reverting -current by date.
On Wed, Nov 20, 2019 at 11:18:41AM -0700, Warner Losh wrote: > On Wed, Nov 20, 2019 at 10:39 AM bob prohaska wrote: > > > From time to time it would be handy to revert freebsd-current to > > an older, well-behaved revision. > > > > Is there a mechanism for identifying revision numbers that > > will at least compile and boot, by date? > > > > Almost all of them will compile. Almost all of those will boot. While some > build breakage sneaks through, the default assumption is that it's good. > That's certainly been my experience randomly updating to -current. There's > some that are more or less performant, mind you, and some that are more or > less stable, it is true. But the overwhelming vast majority will compile > and boot, at least for amd64. I have issues less than 1% of the time when > updating to whatever is current at the moment I fancy an update. > Are commits that depend on one another somehow grouped in a single revision? > There's some hardware that gets broken from time to time, but we don't > track that specifically. And non-amd64 architectures takes more care and > planning as any build breakage for those platforms lasts longer, in direct > proportion to how popular the platform is > Point taken. I'm interested in aarch64, which puts me somewhat in the weeds. > It's all in the commit logs. If you run -current you need to read them. > They will also tell you almost always if you pick revision X if there was a > subsequent fix that made things compile you should go with. > I take it the strategy would be go back in the log to a rough date, then browse forward in time looking for signs of major trouble. When the commits turn minor/benign, select a revision from that timeframe. > > Study the commit logs? I know I'm harping on that, but when things go > wrong, that's what I do. > I hoped for a more mechanical approach. For example, snapshots are generated from time to time. Presumably, they're vetted in some way and knowing what revisions made it to the snapshot stage might be a starting point. The snapshot server does not appear to contain that information for earlier offerings. > Also -DNO_CLEAN builds help a lot if you're worried about it not even > building, though from time to time you run into issues with a NO_CLEAN > build due to a recent commit that wasn't appreciated at the time of the > commit, but was later and fixed. > Does -DNO_CLEAN behave sanely (and usefully) when going backwards in time? I commonly use it for small forward steps, but time reversal is tricky 8-) Thanks for replying! bob prohaska ___ 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: Reverting -current by date.
On Wed, Nov 20, 2019 at 10:39 AM bob prohaska wrote: > From time to time it would be handy to revert freebsd-current to > an older, well-behaved revision. > > Is there a mechanism for identifying revision numbers that > will at least compile and boot, by date? > Almost all of them will compile. Almost all of those will boot. While some build breakage sneaks through, the default assumption is that it's good. That's certainly been my experience randomly updating to -current. There's some that are more or less performant, mind you, and some that are more or less stable, it is true. But the overwhelming vast majority will compile and boot, at least for amd64. I have issues less than 1% of the time when updating to whatever is current at the moment I fancy an update. There's some hardware that gets broken from time to time, but we don't track that specifically. And non-amd64 architectures takes more care and planning as any build breakage for those platforms lasts longer, in direct proportion to how popular the platform is It's all in the commit logs. If you run -current you need to read them. They will also tell you almost always if you pick revision X if there was a subsequent fix that made things compile you should go with. > In my case buildworld seems to be markedly slower than, say, > six months ago. Maybe it's hardware, maybe something else. Is > there a way to pick a revision number to revert to, that's > better than merely guessing? > Study the commit logs? I know I'm harping on that, but when things go wrong, that's what I do. Also -DNO_CLEAN builds help a lot if you're worried about it not even building, though from time to time you run into issues with a NO_CLEAN build due to a recent commit that wasn't appreciated at the time of the commit, but was later and fixed. Warner ___ 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: Reverting -current by date.
On Wed, 2019-11-20 at 09:38 -0800, bob prohaska wrote:
> From time to time it would be handy to revert freebsd-current to
> an older, well-behaved revision.
>
> Is there a mechanism for identifying revision numbers that
> will at least compile and boot, by date?
>
> In my case buildworld seems to be markedly slower than, say,
> six months ago. Maybe it's hardware, maybe something else. Is
> there a way to pick a revision number to revert to, that's
> better than merely guessing?
>
> Thanks for reading,
>
> bob prohaska
>
svn update -r "{date}"
The curly braces indicate you're specifying a date, which can be in a
large variety of typical formats, details here:
http://svnbook.red-bean.com/en/1.7/svn.tour.revs.specifiers.html
Curly braces are significant in some shells, so the quotes may be
required.
-- 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"
Re: Reverting -current by date.
On Wed, Nov 20, 2019 at 09:38:53AM -0800, bob prohaska wrote: > >From time to time it would be handy to revert freebsd-current to > an older, well-behaved revision. > > Is there a mechanism for identifying revision numbers that > will at least compile and boot, by date? > > In my case buildworld seems to be markedly slower than, say, > six months ago. Maybe it's hardware, maybe something else. Is > there a way to pick a revision number to revert to, that's > better than merely guessing? > > Thanks for reading, > This is not anything "official," but for whatever it may be worth, I have been in the habit of tracking head and recent stable branches on a couple of machines on a daily basis, and part of that process for the last few years has been to update some files that may be found at http://www.catwhisker.org/~david/FreeBSD/history/ In particular, http://www.catwhisker.org/~david/FreeBSD/history/laptop_uname_amd64.13.txt shows the revisions that worked for me on my laptop; http://www.catwhisker.org/~david/FreeBSD/history/freebeast_uname_amd64.13.txt shows the same for a headless "build machine." Peace, david -- David H. Wolfskill da...@catwhisker.org Why is Trump trying to keep salient information from House investigators? See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Reverting -current by date.
On Thu, Nov 21, 2019 at 1:39 AM bob prohaska wrote: > > From time to time it would be handy to revert freebsd-current to > an older, well-behaved revision. > > Is there a mechanism for identifying revision numbers that > will at least compile and boot, by date? > > In my case buildworld seems to be markedly slower than, say, > six months ago. Maybe it's hardware, maybe something else. Is > there a way to pick a revision number to revert to, that's > better than merely guessing? > > Thanks for reading, I suggest checking the build history in our CI system, for example, head-amd64: https://ci.freebsd.org/job/FreeBSD-head-amd64-build/ Li-Wen ___ 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"
Reverting -current by date.
>From time to time it would be handy to revert freebsd-current to an older, well-behaved revision. Is there a mechanism for identifying revision numbers that will at least compile and boot, by date? In my case buildworld seems to be markedly slower than, say, six months ago. Maybe it's hardware, maybe something else. Is there a way to pick a revision number to revert to, that's better than merely guessing? Thanks for reading, bob prohaska ___ 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: SVN r354896 breaks build
On Thu, Nov 21, 2019 at 12:39 AM Michael Butler wrote: > > The no-relax flag can't be used on all architectures .. > > Building /usr/obj/usr/src/amd64.amd64/usr.sbin/jail/jail > --- jail --- > ld: error: unknown argument '--no-relax' > cc: error: linker command failed with exit code 1 (use -v to see invocation) > --- all_subdir_usr.sbin/portsnap --- > --- all_subdir_usr.sbin/portsnap/make_index --- > ===> usr.sbin/portsnap/make_index (all) > --- all_subdir_usr.sbin/jail --- > *** [jail] Error code 1 My bad, should be fixed in r354899. Li-Wen ___ 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"
SVN r354896 breaks build
The no-relax flag can't be used on all architectures .. Building /usr/obj/usr/src/amd64.amd64/usr.sbin/jail/jail --- jail --- ld: error: unknown argument '--no-relax' cc: error: linker command failed with exit code 1 (use -v to see invocation) --- all_subdir_usr.sbin/portsnap --- --- all_subdir_usr.sbin/portsnap/make_index --- ===> usr.sbin/portsnap/make_index (all) --- all_subdir_usr.sbin/jail --- *** [jail] Error code 1 imb ___ 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"
Brickyard 4439 Runaway Trim from 6 Nov 2019
Claude: Another video from Juan Brown about an issue with an flight from Atlanta to New York. It is another 'fly by wire' type of aircraft and Juan goes into great detail on the hardware and software issue. Not quite a 737-Max issue, but similar. https://www.youtube.com/watch?v=vV_o9kTRXUY Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ 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"
