Re: CVS commit: src/sys/sys
On Dec 23, 3:06pm, Warner Losh wrote: } On Mon, Dec 23, 2019, 2:37 PM Kamil Rytarowski wrote: } > On 23.12.2019 18:14, Greg Troxel wrote: } > > Warner Losh writes: } > > } > >> Just a quick note: when FreeBSD when from 9 to 10, we had to play 'hunt } > the } > >> wumpus' for all the autoconfig scripts that suddenly thought they were } > >> configuring for FreeBSD 1.0. } > >> } > >> If you can arrange it, it might make sense to do a pkgsrc run on an } > >> experimental system that has the version as 10.0 rather than 9.9.xx } > before } > >> committing to a schedule given the experience of your sister BSD } > project. } > > } > > Thanks, that's a really good point. } > } > This issue is well known. Once we will branch -10 we will test it in } > HEAD and -10 concurrently. } > } > On the other hand, clang10 broke only a single piece of software that I } > build (nodejs). } } FreeBSD 10 broke dozens of config scripts that all derived from a common } ancestor back in the 90s... though 1.0 FreeBSD needed special treatment for } things like a.out and such and the scripts used 1* to match. It would be I was going to say that we could just skip 10 and go direct to 11, but 1* would catch 11 as well. So much for the shortcut. } easy enough to grep for that pattern in gnu software to see if it will trip } you up. NetBSDs release version history may be such this isn't an issue, } but it broke a heck of a lot than I'd expected at the time... } }-- End of excerpt from Warner Losh
Re: CVS commit: src/sys/arch/amd64
Sorry for confusing. My attached patch does not improve my situation. My mail is mistake. Sorry. Reverting linker script fixes the kernel boot. Thank you. On December 26, 2019 1:23:34 AM GMT+09:00, Emmanuel Dreyfus wrote: >On Wed, Dec 25, 2019 at 07:42:47PM +0900, Ryo ONODERA wrote: >> The attached patch works for me. >> However I have no idea about the meaning. > >It changes the multiboot section from DATA to CODE, which is >odd but perfectly fine. I cannot understand how it can change >the situation, though. Did it really fix the problem? Your >next message about reverted kern.ldscript confuses me. -- Ryo ONODERA // r...@tetera.org PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
Re: CVS commit: src/share/tmac
Robert Elz wrote in <11416.1577299...@jinx.noi.kre.to>: |Date:Wed, 25 Dec 2019 18:06:39 +0100 |From:Steffen Nurpmeso |Message-ID: <20191225170639.ddhqn%stef...@sdaoden.eu> | || Maybe the warning should really simply be removed, or only occur || if explicitly requested, i.e., remove the "el" warning bit from || the "all" level, just as is already done for some others; i guess || that would be the best. | |Not really, a truly unmatched .el (the common cause is | | .if ... | .el ... | |) truly is an error, and a warning for that case is entirely |reasonable. What's broken is generating it because of a chain |of .ie / .el .ie / .el .ie / .el | |Each .ie needs a matching .el whether or not the .ie is actually |executed. The warning occurs on "if stack is empty" condition. This was my impression after doing a grep and having a short completely context free look at the code, of course. Other than that you are of course right. |kre --End of <11416.1577299...@jinx.noi.kre.to> --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: CVS commit: src/share/tmac
Date:Wed, 25 Dec 2019 18:06:39 +0100 From:Steffen Nurpmeso Message-ID: <20191225170639.ddhqn%stef...@sdaoden.eu> | Maybe the warning should really simply be removed, or only occur | if explicitly requested, i.e., remove the "el" warning bit from | the "all" level, just as is already done for some others; i guess | that would be the best. Not really, a truly unmatched .el (the common cause is .if ... .el ... ) truly is an error, and a warning for that case is entirely reasonable. What's broken is generating it because of a chain of .ie / .el .ie / .el .ie / .el Each .ie needs a matching .el whether or not the .ie is actually executed. kre
Re: CVS commit: src/share/tmac
Robert Elz wrote in <18872.1577152...@jinx.noi.kre.to>:
|Date:Mon, 23 Dec 2019 23:45:34 +0100
|From:Steffen Nurpmeso
|Message-ID: <20191223224534.8ufgy%stef...@sdaoden.eu>
|
|
|||Troff reads .ie and checks the condition. The condition is true and
|||so the rest of the line is executed. Then troff reads .el that
|||matches successful .ie, so the .el is discarded.
|||
|||Then it reads .el which is not matched with any .ie that troff has
|||seen. It's usually silently discarded,
|
|That is what is (always was) intended to happen.
|
|||but since we run with -ww we
|||get the warning about an unbalanced .el
|
|That's a broken warning. The code in a "discarded" .el needs to be
|examined anyway (if it weren't, the \{ \} block to group the code
|together wouldn't work, and when doing that, it can easily notice an
|embedded .ie (it must be immediately after the .el so looking for it is
|not hard) which will require another matching .el, and make sure that
|things are correctly balanced. That would be a useful wraning.
|
|The
| .ie
| .el .ie
| .el .ie
| .el
|
|idiom has been used in troff (including by troff's authors) forever.
Forever, me too. It is the very first groff commit of James Clark
which added that behaviour (1991-06-02 04:20:34 -0500). Other
than that i do not think it is a broken warning, my mailer for
example simply bails with error if the if conditional stack is
empty, so broken is possibly that the warning only happens with
-w, and not by default.
|Deciding to make that improper now, just because someone who doesn't
|understand, or cannot work out how to handle it correctly, is absurd.
|
|Perhaps (originally) the ".el .ie" combination could have been made
|a macro of its own, it should really be treated as if it were (like
|the "elif" word in sh), but adding more code to process another macro,
|just to save (what would be) 3 input bytes per use wouldn't really
|have been justifiable.
Maybe the warning should really simply be removed, or only occur
if explicitly requested, i.e., remove the "el" warning bit from
the "all" level, just as is already done for some others; i guess
that would be the best.
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: CVS commit: src/sys/arch/amd64
On Wed, Dec 25, 2019 at 07:42:47PM +0900, Ryo ONODERA wrote: > The attached patch works for me. > However I have no idea about the meaning. It changes the multiboot section from DATA to CODE, which is odd but perfectly fine. I cannot understand how it can change the situation, though. Did it really fix the problem? Your next message about reverted kern.ldscript confuses me. -- Emmanuel Dreyfus m...@netbsd.org
Re: CVS commit: src/sys/arch/amd64
Hi, Sorry I have accidentally reverted kern.ldscript. With current kern.ldscript, it stalls after cpu0. Thank you. Ryo ONODERA writes: > Hi, > > Emmanuel Dreyfus writes: > >> On Tue, Dec 24, 2019 at 05:50:00PM +0900, Ryo ONODERA wrote: >>> After this change, amd64 kernel does not boot on my HP Spectre x360 >>> 13-inch ae019TU laptop with pure UEFI boot mode. >> >> Hello >> >> Does the attached patch (crafted for port-amd64/54775) fix the >> problem? > > Without your patch, the kernel does not boot at all, > so after the kernel is loaded, only "_" character is displayed. > > And your patch still does not work properly, so the kernel hangs > after cpu0 (as same as msaitoh@'s however it hits 100% for my > laptop). > > The attached patch works for me. > However I have no idea about the meaning. > > Index: sys/arch/amd64/amd64/locore.S > === > RCS file: /cvsroot/src/sys/arch/amd64/amd64/locore.S,v > retrieving revision 1.195 > diff -u -r1.195 locore.S > --- sys/arch/amd64/amd64/locore.S 15 Dec 2019 02:58:21 - 1.195 > +++ sys/arch/amd64/amd64/locore.S 25 Dec 2019 10:36:18 - > @@ -1,4 +1,4 @@ > -/* $NetBSD: locore.S,v 1.195 2019/12/15 02:58:21 manu Exp $*/ > +/* $NetBSD: locore.S,v 1.193 2019/12/10 02:06:07 manu Exp $*/ > > /* > * Copyright-o-rama! > @@ -432,9 +432,9 @@ > .space 512 > tmpstk: > > -.section multiboot,"a" > -#if defined(MULTIBOOT) > +.section multiboot,"ax",@progbits > .align 8 > +#if defined(MULTIBOOT) > .globl Multiboot2_Header > _C_LABEL(Multiboot2_Header): > .intMULTIBOOT2_HEADER_MAGIC > @@ -474,6 +474,9 @@ > .align 8 > .globl Multiboot2_Header_end > _C_LABEL(Multiboot2_Header_end): > +#else /* MULTIBOOT */ > + .int0xdeadbeef /* have some non empty content */ > + .align 8 > #endif /* MULTIBOOT */ > > /* > > Thank you. > >> -- >> Emmanuel Dreyfus >> m...@netbsd.org >> Index: sys/arch/amd64/amd64/locore.S >> === >> RCS file: /cvsroot/src/sys/arch/amd64/amd64/locore.S,v >> retrieving revision 1.195 >> diff -U4 -r1.195 locore.S >> --- sys/arch/amd64/amd64/locore.S15 Dec 2019 02:58:21 - 1.195 >> +++ sys/arch/amd64/amd64/locore.S22 Dec 2019 02:23:11 - >> @@ -432,10 +432,10 @@ >> .space 512 >> tmpstk: >> >> .section multiboot,"a" >> -#if defined(MULTIBOOT) >> .align 8 >> +#if defined(MULTIBOOT) >> .globl Multiboot2_Header >> _C_LABEL(Multiboot2_Header): >> .intMULTIBOOT2_HEADER_MAGIC >> .intMULTIBOOT2_ARCHITECTURE_I386 >> @@ -473,8 +473,11 @@ >> .int8 /* sizeof(struct multiboot_tag) */ >> .align 8 >> .globl Multiboot2_Header_end >> _C_LABEL(Multiboot2_Header_end): >> +#else /* MULTIBOOT */ >> +.int0xdeadbeef /* have some non empty content */ >> +.align 8 >> #endif /* MULTIBOOT */ >> >> /* >> * Some hackage to deal with 64bit symbols in 32 bit mode. > > -- > Ryo ONODERA // r...@tetera.org > PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3 -- Ryo ONODERA // r...@tetera.org PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
Re: CVS commit: src/sys/arch/amd64
Hi, Emmanuel Dreyfus writes: > On Tue, Dec 24, 2019 at 05:50:00PM +0900, Ryo ONODERA wrote: >> After this change, amd64 kernel does not boot on my HP Spectre x360 >> 13-inch ae019TU laptop with pure UEFI boot mode. > > Hello > > Does the attached patch (crafted for port-amd64/54775) fix the > problem? Without your patch, the kernel does not boot at all, so after the kernel is loaded, only "_" character is displayed. And your patch still does not work properly, so the kernel hangs after cpu0 (as same as msaitoh@'s however it hits 100% for my laptop). The attached patch works for me. However I have no idea about the meaning. Index: sys/arch/amd64/amd64/locore.S === RCS file: /cvsroot/src/sys/arch/amd64/amd64/locore.S,v retrieving revision 1.195 diff -u -r1.195 locore.S --- sys/arch/amd64/amd64/locore.S 15 Dec 2019 02:58:21 - 1.195 +++ sys/arch/amd64/amd64/locore.S 25 Dec 2019 10:36:18 - @@ -1,4 +1,4 @@ -/* $NetBSD: locore.S,v 1.195 2019/12/15 02:58:21 manu Exp $ */ +/* $NetBSD: locore.S,v 1.193 2019/12/10 02:06:07 manu Exp $ */ /* * Copyright-o-rama! @@ -432,9 +432,9 @@ .space 512 tmpstk: -.section multiboot,"a" -#if defined(MULTIBOOT) +.section multiboot,"ax",@progbits .align 8 +#if defined(MULTIBOOT) .globl Multiboot2_Header _C_LABEL(Multiboot2_Header): .int MULTIBOOT2_HEADER_MAGIC @@ -474,6 +474,9 @@ .align 8 .globl Multiboot2_Header_end _C_LABEL(Multiboot2_Header_end): +#else /* MULTIBOOT */ + .int 0xdeadbeef /* have some non empty content */ + .align 8 #endif /* MULTIBOOT */ /* Thank you. > -- > Emmanuel Dreyfus > m...@netbsd.org > Index: sys/arch/amd64/amd64/locore.S > === > RCS file: /cvsroot/src/sys/arch/amd64/amd64/locore.S,v > retrieving revision 1.195 > diff -U4 -r1.195 locore.S > --- sys/arch/amd64/amd64/locore.S 15 Dec 2019 02:58:21 - 1.195 > +++ sys/arch/amd64/amd64/locore.S 22 Dec 2019 02:23:11 - > @@ -432,10 +432,10 @@ > .space 512 > tmpstk: > > .section multiboot,"a" > -#if defined(MULTIBOOT) > .align 8 > +#if defined(MULTIBOOT) > .globl Multiboot2_Header > _C_LABEL(Multiboot2_Header): > .intMULTIBOOT2_HEADER_MAGIC > .intMULTIBOOT2_ARCHITECTURE_I386 > @@ -473,8 +473,11 @@ > .int8 /* sizeof(struct multiboot_tag) */ > .align 8 > .globl Multiboot2_Header_end > _C_LABEL(Multiboot2_Header_end): > +#else /* MULTIBOOT */ > + .int0xdeadbeef /* have some non empty content */ > + .align 8 > #endif /* MULTIBOOT */ > > /* > * Some hackage to deal with 64bit symbols in 32 bit mode. -- Ryo ONODERA // r...@tetera.org PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
Re: CVS commit: src/sys/arch/amd64
On 2019/12/25 17:05, Masanobu SAITOH wrote: > On 2019/12/24 23:47, Emmanuel Dreyfus wrote: >> On Tue, Dec 24, 2019 at 05:50:00PM +0900, Ryo ONODERA wrote: >>> After this change, amd64 kernel does not boot on my HP Spectre x360 >>> 13-inch ae019TU laptop with pure UEFI boot mode. > > I have a UEFI boot machine and it also doesn't boot well. > > - It hangs after attaching ioapic0, cpu0 or acpi0 (or something else). >The possibility is about 65% > - It sometimes panic in acpi_attach(), acpimcfg_probe or something else. >The possibility is about 10% > - It sometimes boot up. >The possibility is about 25% > >> Hello >> >> Does the attached patch (crafted for port-amd64/54775) fix the >> problem? > > I tried your patch(It can't apply cleanly, so a applied it by hand). > I can't see any improvement. > > It seems for me that ACPI table can't decode correctly when it couldn't > boot up. > Boot: http://mail-index.netbsd.org/source-changes/2019/12/15/msg111926.html Hang or panic: http://mail-index.netbsd.org/source-changes/2019/12/15/msg111928.html -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: CVS commit: src/sys/arch/amd64
On 2019/12/24 23:47, Emmanuel Dreyfus wrote: > On Tue, Dec 24, 2019 at 05:50:00PM +0900, Ryo ONODERA wrote: >> After this change, amd64 kernel does not boot on my HP Spectre x360 >> 13-inch ae019TU laptop with pure UEFI boot mode. I have a UEFI boot machine and it also doesn't boot well. - It hangs after attaching ioapic0, cpu0 or acpi0 (or something else). The possibility is about 65% - It sometimes panic in acpi_attach(), acpimcfg_probe or something else. The possibility is about 10% - It sometimes boot up. The possibility is about 25% > Hello > > Does the attached patch (crafted for port-amd64/54775) fix the > problem? I tried your patch(It can't apply cleanly, so a applied it by hand). I can't see any improvement. It seems for me that ACPI table can't decode correctly when it couldn't boot up. -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
