Re: r308432: Capsicumized `basename` make zsh prompt broken
On Mon, Nov 28, 2016 at 02:05:49AM -0500, Allan Jude wrote:
> On 2016-11-27 23:55, Conrad Meyer wrote:
> > Hi Iblis,
> >
> > I see no such problem running 'basename $HOME' in a normal shell
> > environment:
> >
> >> $ basename $HOME
> >> cmeyer
> >
> > I suppose in your use, perhaps stdin is already closed? I think this
> > is a limitation of caph_limit_stdio() in general.
> >
> > Can you try instead:
> >
> > function set_prompt {
> > prompt="$(basename $HOME < /dev/null) >"
> > }
> >
> > And see if it resolves the issue?
> >
> > Thanks,
> > Conrad
> >
> > On Sun, Nov 27, 2016 at 8:33 PM, iblis wrote:
> >> Hi,
> >> Here is a minimal config of zsh prompt invoking `basename`:
> >> ```
> >> └─[iblis@abeing]% cat /home/ib-test/.zshenv
> >>
> >> function set_prompt {
> >> prompt="$(basename $HOME) >"
> >> }
> >>
> >> function zle-line-init zle-keymap-select {
> >> set_prompt
> >> zle reset-prompt
> >> }
> >>
> >> zle -N zle-line-init
> >> zle -N zle-keymap-select
> >>
> >> set_prompt
> >> ```
> >>
> >> and launching zsh will get something like this:
> >>
> >> ```
> >> └─[iblis@abeing]% sudo su ib-test
> >>
> >> ib-test >basename: capsicum: Bad file descriptor
> >>>
> >>> basename: capsicum: Bad file descriptor
> >>>
> >> ```
> >>
> >>
> >> To be honest, I have no idea about what casper/caspicum is. I just changed
> >> the `basename.c` and zsh work again.
> >>
> >> Index: basename.c
> >> ===
> >> --- basename.c (revision 309213)
> >> +++ basename.c (working copy)
> >> @@ -65,7 +65,7 @@
> >>
> >> setlocale(LC_ALL, "");
> >>
> >> - if (caph_limit_stdio() < 0 || (cap_enter() < 0 && errno != ENOSYS))
> >> + if (cap_enter() < 0 && errno != ENOSYS)
> >> err(1, "capsicum");
> >>
> >> aflag = 0;
> >>
> >>
> >> Any idea?
> >>
> >> --
> >> Iblis Lin
> >> ___
> >> 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"
> >
>
> IIRC, bapt@ specifically mentioned this case in the review for
> caph_limit_stdio() or one of the reviews that lead to the creation of
> the helpers.
I mention this is the review of the cap_helpers themselves. I still think
caph_limit_stdio should grow a flag for testing that. I figured out the issue
based on one of the conversion to capsicum by Conrad on I don't remember which
tool.
Bapt
signature.asc
Description: PGP signature
Re: r308432: Capsicumized `basename` make zsh prompt broken
On 2016-11-27 23:55, Conrad Meyer wrote:
> Hi Iblis,
>
> I see no such problem running 'basename $HOME' in a normal shell environment:
>
>> $ basename $HOME
>> cmeyer
>
> I suppose in your use, perhaps stdin is already closed? I think this
> is a limitation of caph_limit_stdio() in general.
>
> Can you try instead:
>
> function set_prompt {
> prompt="$(basename $HOME < /dev/null) >"
> }
>
> And see if it resolves the issue?
>
> Thanks,
> Conrad
>
> On Sun, Nov 27, 2016 at 8:33 PM, iblis wrote:
>> Hi,
>> Here is a minimal config of zsh prompt invoking `basename`:
>> ```
>> └─[iblis@abeing]% cat /home/ib-test/.zshenv
>>
>> function set_prompt {
>> prompt="$(basename $HOME) >"
>> }
>>
>> function zle-line-init zle-keymap-select {
>> set_prompt
>> zle reset-prompt
>> }
>>
>> zle -N zle-line-init
>> zle -N zle-keymap-select
>>
>> set_prompt
>> ```
>>
>> and launching zsh will get something like this:
>>
>> ```
>> └─[iblis@abeing]% sudo su ib-test
>>
>> ib-test >basename: capsicum: Bad file descriptor
>>>
>>> basename: capsicum: Bad file descriptor
>>>
>> ```
>>
>>
>> To be honest, I have no idea about what casper/caspicum is. I just changed
>> the `basename.c` and zsh work again.
>>
>> Index: basename.c
>> ===
>> --- basename.c (revision 309213)
>> +++ basename.c (working copy)
>> @@ -65,7 +65,7 @@
>>
>> setlocale(LC_ALL, "");
>>
>> - if (caph_limit_stdio() < 0 || (cap_enter() < 0 && errno != ENOSYS))
>> + if (cap_enter() < 0 && errno != ENOSYS)
>> err(1, "capsicum");
>>
>> aflag = 0;
>>
>>
>> Any idea?
>>
>> --
>> Iblis Lin
>> ___
>> 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"
>
IIRC, bapt@ specifically mentioned this case in the review for
caph_limit_stdio() or one of the reviews that lead to the creation of
the helpers.
--
Allan Jude
signature.asc
Description: OpenPGP digital signature
Re: r308432: Capsicumized `basename` make zsh prompt broken
Hi Iblis,
Yes, I think caph_limit_stdio will break many similar programs in
similar use. I think we'll need to change that behavior. Something
like this:
https://reviews.freebsd.org/D8657
Best,
Conrad
On Sun, Nov 27, 2016 at 10:40 PM, iblis wrote:
> Hi Conrad,
>Thanks for your reply.
>
>I revert the basename.c and `< /dev/null` do the trick!
>I'm also curious that will `caph_limit_stdio` break lots of program work
> with some shell scripts?
>
> --
> Iblis Lin
>
>
> On 11/28/2016 12:55, Conrad Meyer wrote:
>>
>> Hi Iblis,
>>
>> I see no such problem running 'basename $HOME' in a normal shell
>> environment:
>>
>>> $ basename $HOME
>>> cmeyer
>>
>>
>> I suppose in your use, perhaps stdin is already closed? I think this
>> is a limitation of caph_limit_stdio() in general.
>>
>> Can you try instead:
>>
>> function set_prompt {
>> prompt="$(basename $HOME < /dev/null) >"
>> }
>>
>> And see if it resolves the issue?
>>
>> Thanks,
>> Conrad
>>
>> On Sun, Nov 27, 2016 at 8:33 PM, iblis wrote:
>>>
>>> Hi,
>>> Here is a minimal config of zsh prompt invoking `basename`:
>>> ```
>>> └─[iblis@abeing]% cat /home/ib-test/.zshenv
>>>
>>> function set_prompt {
>>> prompt="$(basename $HOME) >"
>>> }
>>>
>>> function zle-line-init zle-keymap-select {
>>> set_prompt
>>> zle reset-prompt
>>> }
>>>
>>> zle -N zle-line-init
>>> zle -N zle-keymap-select
>>>
>>> set_prompt
>>> ```
>>>
>>> and launching zsh will get something like this:
>>>
>>> ```
>>> └─[iblis@abeing]% sudo su ib-test
>>>
>>> ib-test >basename: capsicum: Bad file descriptor
basename: capsicum: Bad file descriptor
>>> ```
>>>
>>>
>>> To be honest, I have no idea about what casper/caspicum is. I just
>>> changed
>>> the `basename.c` and zsh work again.
>>>
>>> Index: basename.c
>>> ===
>>> --- basename.c (revision 309213)
>>> +++ basename.c (working copy)
>>> @@ -65,7 +65,7 @@
>>>
>>> setlocale(LC_ALL, "");
>>>
>>> - if (caph_limit_stdio() < 0 || (cap_enter() < 0 && errno != ENOSYS))
>>> + if (cap_enter() < 0 && errno != ENOSYS)
>>> err(1, "capsicum");
>>>
>>> aflag = 0;
>>>
>>>
>>> Any idea?
>>>
>>> --
>>> Iblis Lin
>>> ___
>>> 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"
>>
>
___
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: r308432: Capsicumized `basename` make zsh prompt broken
Hi Conrad,
Thanks for your reply.
I revert the basename.c and `< /dev/null` do the trick!
I'm also curious that will `caph_limit_stdio` break lots of program
work with some shell scripts?
--
Iblis Lin
On 11/28/2016 12:55, Conrad Meyer wrote:
Hi Iblis,
I see no such problem running 'basename $HOME' in a normal shell environment:
$ basename $HOME
cmeyer
I suppose in your use, perhaps stdin is already closed? I think this
is a limitation of caph_limit_stdio() in general.
Can you try instead:
function set_prompt {
prompt="$(basename $HOME < /dev/null) >"
}
And see if it resolves the issue?
Thanks,
Conrad
On Sun, Nov 27, 2016 at 8:33 PM, iblis wrote:
Hi,
Here is a minimal config of zsh prompt invoking `basename`:
```
└─[iblis@abeing]% cat /home/ib-test/.zshenv
function set_prompt {
prompt="$(basename $HOME) >"
}
function zle-line-init zle-keymap-select {
set_prompt
zle reset-prompt
}
zle -N zle-line-init
zle -N zle-keymap-select
set_prompt
```
and launching zsh will get something like this:
```
└─[iblis@abeing]% sudo su ib-test
ib-test >basename: capsicum: Bad file descriptor
basename: capsicum: Bad file descriptor
```
To be honest, I have no idea about what casper/caspicum is. I just changed
the `basename.c` and zsh work again.
Index: basename.c
===
--- basename.c (revision 309213)
+++ basename.c (working copy)
@@ -65,7 +65,7 @@
setlocale(LC_ALL, "");
- if (caph_limit_stdio() < 0 || (cap_enter() < 0 && errno != ENOSYS))
+ if (cap_enter() < 0 && errno != ENOSYS)
err(1, "capsicum");
aflag = 0;
Any idea?
--
Iblis Lin
___
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"
___
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: Please test EARLY_AP_STARTUP
Hi John, fdc seems to cause panic on Hyper-V: https://people.freebsd.org/~sephe/fdc_panic.png I then commented out device fdc, and I fixed one panic on Hyper-V here: https://reviews.freebsd.org/D8656 After fdc is disabled and hyperv/storvsc is fixed, it seems to boot fine, except a long delay (28~30seconds) here: Timecounters tick every 1.000 msec - 28 ~ 30 seconds delay - vlan: initialized, using hash tables with chaining I have the bootverbose dmesg here: https://people.freebsd.org/~sephe/dmesg_earlyap.txt I booted 10 times, only one boot does not suffer this 30 seconds delay. It sounds like some races to me. Any hints? Thanks, sephe On Sat, Nov 26, 2016 at 2:20 AM, John Baldwin wrote: > I plan to enable EARLY_AP_STARTUP on x86 in a week on HEAD. Some folks > have been testing it for the last week or so which has exposed some > additional things to fix. I think I've resolved most of those in one > way or another, but it will make things smoother if other folks can > start testing this over the next few days before it is enabled by default. > > (To enable, add 'options EARLY_AP_STARTUP' to your kernel config.) > > Note that non-x86 platforms should eventually adopt this, but I don't > think any of them are ready yet. > > -- > John Baldwin > ___ > 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" -- Tomorrow Will Never Die ___ 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: r308432: Capsicumized `basename` make zsh prompt broken
Hi Iblis,
I see no such problem running 'basename $HOME' in a normal shell environment:
> $ basename $HOME
> cmeyer
I suppose in your use, perhaps stdin is already closed? I think this
is a limitation of caph_limit_stdio() in general.
Can you try instead:
function set_prompt {
prompt="$(basename $HOME < /dev/null) >"
}
And see if it resolves the issue?
Thanks,
Conrad
On Sun, Nov 27, 2016 at 8:33 PM, iblis wrote:
> Hi,
> Here is a minimal config of zsh prompt invoking `basename`:
> ```
> └─[iblis@abeing]% cat /home/ib-test/.zshenv
>
> function set_prompt {
> prompt="$(basename $HOME) >"
> }
>
> function zle-line-init zle-keymap-select {
> set_prompt
> zle reset-prompt
> }
>
> zle -N zle-line-init
> zle -N zle-keymap-select
>
> set_prompt
> ```
>
> and launching zsh will get something like this:
>
> ```
> └─[iblis@abeing]% sudo su ib-test
>
> ib-test >basename: capsicum: Bad file descriptor
>>
>>basename: capsicum: Bad file descriptor
>>
> ```
>
>
> To be honest, I have no idea about what casper/caspicum is. I just changed
> the `basename.c` and zsh work again.
>
> Index: basename.c
> ===
> --- basename.c (revision 309213)
> +++ basename.c (working copy)
> @@ -65,7 +65,7 @@
>
> setlocale(LC_ALL, "");
>
> - if (caph_limit_stdio() < 0 || (cap_enter() < 0 && errno != ENOSYS))
> + if (cap_enter() < 0 && errno != ENOSYS)
> err(1, "capsicum");
>
> aflag = 0;
>
>
> Any idea?
>
> --
> Iblis Lin
> ___
> 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"
r308432: Capsicumized `basename` make zsh prompt broken
Hi,
Here is a minimal config of zsh prompt invoking `basename`:
```
└─[iblis@abeing]% cat /home/ib-test/.zshenv
function set_prompt {
prompt="$(basename $HOME) >"
}
function zle-line-init zle-keymap-select {
set_prompt
zle reset-prompt
}
zle -N zle-line-init
zle -N zle-keymap-select
set_prompt
```
and launching zsh will get something like this:
```
└─[iblis@abeing]% sudo su ib-test
ib-test >basename: capsicum: Bad file descriptor
>
>basename: capsicum: Bad file descriptor
>
```
To be honest, I have no idea about what casper/caspicum is. I just
changed the `basename.c` and zsh work again.
Index: basename.c
===
--- basename.c (revision 309213)
+++ basename.c (working copy)
@@ -65,7 +65,7 @@
setlocale(LC_ALL, "");
- if (caph_limit_stdio() < 0 || (cap_enter() < 0 && errno != ENOSYS))
+ if (cap_enter() < 0 && errno != ENOSYS)
err(1, "capsicum");
aflag = 0;
Any idea?
--
Iblis Lin
___
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 commit: r309144 - in head: lib/libipsec sys/net sys/netipsec [-r309174 does not fix everything]
Hi Mark, I believe this was addressed by Scott Long in r309201. r309174 (an incomplete fix for the same problem) can probably be reverted. Best, Conrad On Sun, Nov 27, 2016 at 6:34 PM, Mark Millard wrote: > key_debug.c is not the only place with problems : The below is > based on my experience with head -r309179. First what someone > else reported: > >> On Fri, Nov 25, 2016 at 05:34:51PM +0100, O. Hartmann wrote: >> > Recent sources do not build kernel due to: >> > >> > [...] >> > Building /usr/obj/usr/src/sys/SB21X1/ipsec_mbuf.o >> > In file included from /usr/src/sys/netipsec/ipsec_mbuf.c:43: >> > In file included from /usr/src/sys/netipsec/ipsec.h:46: >> > In file included from /usr/src/sys/netipsec/keydb.h:38: >> > /usr/src/sys/sys/mutex.h:367:2: error: LOCK_DEBUG not defined, include >> > >> > before #error LOCK_DEBUG not defined, include >> > before >> > ^ >> > /usr/src/sys/sys/mutex.h:369:5: error: 'LOCK_DEBUG' is not defined, >> > evaluates to 0 >> > [-Werror,-Wundef] #if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) >> > ^ >> > 2 errors generated. >> > *** Error code 1 > (From: > https://lists.freebsd.org/pipermail/freebsd-current/2016-November/063920.html > ) > > I ran into the same thing in the same place. > > Like O. Hartmann I followed the compiler's advice to work around > the problem. That allowed my buildworld buildkernel to complete. > > > === > Mark Millard > markmi at dsl-only.net > > ___ > 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: svn commit: r309144 - in head: lib/libipsec sys/net sys/netipsec [-r309174 does not fix everything]
key_debug.c is not the only place with problems : The below is based on my experience with head -r309179. First what someone else reported: > On Fri, Nov 25, 2016 at 05:34:51PM +0100, O. Hartmann wrote: > > Recent sources do not build kernel due to: > > > > [...] > > Building /usr/obj/usr/src/sys/SB21X1/ipsec_mbuf.o > > In file included from /usr/src/sys/netipsec/ipsec_mbuf.c:43: > > In file included from /usr/src/sys/netipsec/ipsec.h:46: > > In file included from /usr/src/sys/netipsec/keydb.h:38: > > /usr/src/sys/sys/mutex.h:367:2: error: LOCK_DEBUG not defined, include > > > > before #error LOCK_DEBUG not defined, include > > before > > ^ > > /usr/src/sys/sys/mutex.h:369:5: error: 'LOCK_DEBUG' is not defined, > > evaluates to 0 > > [-Werror,-Wundef] #if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) > > ^ > > 2 errors generated. > > *** Error code 1 (From: https://lists.freebsd.org/pipermail/freebsd-current/2016-November/063920.html ) I ran into the same thing in the same place. Like O. Hartmann I followed the compiler's advice to work around the problem. That allowed my buildworld buildkernel to complete. === Mark Millard markmi at dsl-only.net ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
On 26 November 2016 at 13:59, Slawa Olhovchenkov wrote: > On Sat, Nov 26, 2016 at 01:55:14PM -0800, Adrian Chadd wrote: > >> ok, hm. then i don' know offhand, not without putting in printf debugging. :) > > I am not expert in this code, I am need you patches for printf debugging. heh, sorry, I'm too busy atm to help out more with this. My day job doesn't involve FreeBSD at all and I have 802.11ac to get off the ground. Someone else will have to help figure this out :( -adrian ___ 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: Please test EARLY_AP_STARTUP
On Sunday, November 27, 2016 12:46:31 PM O. Hartmann wrote: > Am Fri, 25 Nov 2016 10:20:36 -0800 > John Baldwin schrieb: > > > I plan to enable EARLY_AP_STARTUP on x86 in a week on HEAD. Some folks > > have been testing it for the last week or so which has exposed some > > additional things to fix. I think I've resolved most of those in one > > way or another, but it will make things smoother if other folks can > > start testing this over the next few days before it is enabled by default. > > > > (To enable, add 'options EARLY_AP_STARTUP' to your kernel config.) > > > > Note that non-x86 platforms should eventually adopt this, but I don't > > think any of them are ready yet. > > > > I tried. I use three boxes, all running most recent CURRENT. Only one box > does work and > boot with the option mentioned above in the kernel. The other two don't, they > stop at > printing something about HPET timer initialisation and stop - forever. > > I did not digg deeper into it, but there is something strange: > > Both failing boxes have CPUs with two cores, four threads. One is a notebook > with an > Haswell 4200M, the other is a i3-3220. > > The i3-3220 box has a motherboard ASROCK Z77-Pro4 (UEFI on this crap is not > working), 8 > GB RAM (2x 4GB), lates firmware from 2013. > > The working box has an ASROCK Z77-Pro4 M (mini ATX size mobo), 16 GB RAM (2x > 8GB), but a > 4 core/8 thread XEON IvyBridge E3-1245 V2. The firmare is the latest, from > 2013. The box > is running well with the option EARLY_AP_STARTUP set. > > At a first glance it looks like the failure is dependend on the CPU count ;-) > I have also > a small PCengine APU 2C4, AMD Jaguar CPU with 4 core/4 threads which is about > to be tested > also with the most recent CURRENT and the option in question set - but it > takes time. > > Just for the record, my apologizes if someone feels disturbed from naive > observations. Some things to help debug: - See if you can break into the debugger via Ctrl-Alt-Esc. If so, please grab the output of 'ps' and 'tr 0' from DDB. - Boot with SMP disabled (kern.smp.disabled=1). This isn't a permament solution but can help narrow down the issue. - Compile a kernel with KTR, KTR_COMPILE=KTR_PROC, KTR_VERBOSE, and KTR_MASK=KTR_PROC (all are options) and boot. Hopefully it stops printing lines when it hangs rather than spinning forever. If so, grab a screen shot (or console serial log) when it hangs. -- John Baldwin ___ 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: boot fails on Table SSDT at 0x...
"Julian H. Stacey" wrote: > "Julian H. Stacey" wrote: > > Hi curr...@freebsd.org > > I was running > > FreeBSD lapr.js.berklix.net 12.0-CURRENT FreeBSD 12.0-CURRENT > > #12753: Tue Nov 22 23:31:24 CET 2016 > > > > j...@lapr.js.berklix.net:/data/release/12.0-CURRENT/usr/src/sys/amd64/compile/LAPR.small > > amd64 > > I updated to > > .ctm_status src-cur 12757 > > .svn_revision 309126 > > did a make world, built a new custom kernel with same config as before & now > > laptop boot fails after > > Table SSDT at 0x... > > ACPI: No SRAT table found > > > > I took a pic of frozen screen, & I have svn here, I need to research > > & provide more info to whoever ? so this just initial info to whoever's > > working in the area. Debug suggestions & syntax welcome. I'll build > > a generic kernel next. > > > > If I may be slow responding, sorry, DSL modem problems here too, hence > > getting an initial error report out while I can. > > A generic kernel boots OK. > A 2nd build of custom config fails to boot. > Table 'ASPT' at 0x937e2000 > Table 'SSDT' at 0x937e1000 > Table 'SSDT' at 0x937e > Table 'SSDT' at 0x937df000 > ACPI: No SRAT table found > > cd /sys/amd64/conf ; diff -c JENERIC.small LAPR.small > *** JENERIC.small Sun Nov 27 15:09:47 2016 > --- LAPR.smallSun Nov 27 15:09:48 2016 > *** > *** 1,15 > cpu HAMMER > ! ident JHS_Generic > makeoptions DEBUG=-g > makeoptions WITH_CTF=1 > options SCHED_ULE > options PREEMPTION > options INET > - options INET6 > - options IPSEC > options TCP_OFFLOAD > options TCP_HHOOK > - options SCTP > options FFS > options SOFTUPDATES > options UFS_ACL > --- 1,12 > cpu HAMMER > ! ident JHS_Lapr > makeoptions DEBUG=-g > makeoptions WITH_CTF=1 > options SCHED_ULE > options PREEMPTION > options INET > options TCP_OFFLOAD > options TCP_HHOOK > options FFS > options SOFTUPDATES > options UFS_ACL > *** > *** 23,33 > --- 20,32 > options NFS_ROOT > options MSDOSFS > options CD9660 > + options UDF > options PROCFS > options PSEUDOFS > options GEOM_PART_GPT > options GEOM_RAID > options GEOM_LABEL > + options GEOM_BDE > options COMPAT_FREEBSD32 > options COMPAT_FREEBSD4 > options COMPAT_FREEBSD5 > *** > *** 71,76 > --- 70,78 > options SMP > options DEVICE_NUMA > device cpufreq > + options IPFIREWALL > + options IPFIREWALL_VERBOSE > + options IPDIVERT > device acpi > options ACPI_DMAR > device pci > *** > *** 81,134 > device ata > device mvs > device siis > - device ahc > - options AHC_REG_PRETTY_PRINT > - device ahd > - options AHD_REG_PRETTY_PRINT > - device esp > - device hptiop > - device isp > - device mpt > - device mps > - device mpr > - device sym > - device trm > - device adv > - device adw > - device aic > - device bt > - device isci > device scbus > - device ch > device da > - device sa > device cd > device pass > device ses > - device amr > - device arcmsr > - device ciss > - device dpt > - device hptmv > - device hptnr > - device hptrr > - device hpt27xx > - device iir > - device ips > - device mly > - device twa > - device tws > - device aac > - device aacp > - device aacraid > - device ida > - device mfi > - device mlx > - device mrsas > - device pmspcv > - device twe > - device nvme > - device nvd > device atkbdc > device atkbd > device psm > --- 83,93 > *** > *** 150,202 > device ppbus > device lpt > device ppi > - device puc > device bxe > - device de > - device em > - device igb > - device ix > - device ixv > - device ixl > - device ixlv > - device le > - device ti > - device txp > - device vx > device miibus > - device ae > - device age > - device alc > - device ale > - device bce > - device bfe > - device bge > - device cas > - device dc > - device et > - device fxp > - device gem > - device hme > - device jme > - device lge > - device msk > - device nfe > - device nge > - device pcn > - device re > - device rl > - device sf > - device sge > - device sis > - device sk > - device ste > - device stge > - device tl > - device tx > - device vge > - device vr > - device wb > - device xl > device wlan > options IEEE80211_DEBUG > options IEEE80211_AMPDU_AGE > --- 109,116 > *** > *** 221,226 > --- 135,143 > device ral > device wi > device wpi > + device bge > + device sound > + device "snd_hda" > device loop > device random > device padlock_rng > *** > *** 234,253 > device bpf > options USB_DEBUG > device uhci > - device ohci > device ehci > device xhci > device usb > device ukbd > device umass > - device sound > - device snd_cmi > - device snd_csa > - device snd_emu10kx > - device snd_es137x > - device snd_hda > - device snd_ich > - device snd_via8233 > device mmc > device mmcsd > device sdhci > --- 1
Re: boot fails on Table SSDT at 0x...
"Julian H. Stacey" wrote: > Hi curr...@freebsd.org > I was running > FreeBSD lapr.js.berklix.net 12.0-CURRENT FreeBSD 12.0-CURRENT > #12753: Tue Nov 22 23:31:24 CET 2016 > > j...@lapr.js.berklix.net:/data/release/12.0-CURRENT/usr/src/sys/amd64/compile/LAPR.small > amd64 > I updated to > .ctm_status src-cur 12757 > .svn_revision 309126 > did a make world, built a new custom kernel with same config as before & now > laptop boot fails after > Table SSDT at 0x... > ACPI: No SRAT table found > > I took a pic of frozen screen, & I have svn here, I need to research > & provide more info to whoever ? so this just initial info to whoever's > working in the area. Debug suggestions & syntax welcome. I'll build > a generic kernel next. > > If I may be slow responding, sorry, DSL modem problems here too, hence > getting an initial error report out while I can. A generic kernel boots OK. A 2nd build of custom config fails to boot. Table 'ASPT' at 0x937e2000 Table 'SSDT' at 0x937e1000 Table 'SSDT' at 0x937e Table 'SSDT' at 0x937df000 ACPI: No SRAT table found cd /sys/amd64/conf ; diff -c JENERIC.small LAPR.small *** JENERIC.small Sun Nov 27 15:09:47 2016 --- LAPR.small Sun Nov 27 15:09:48 2016 *** *** 1,15 cpu HAMMER ! ident JHS_Generic makeoptions DEBUG=-g makeoptions WITH_CTF=1 options SCHED_ULE options PREEMPTION options INET - options INET6 - options IPSEC options TCP_OFFLOAD options TCP_HHOOK - options SCTP options FFS options SOFTUPDATES options UFS_ACL --- 1,12 cpu HAMMER ! ident JHS_Lapr makeoptions DEBUG=-g makeoptions WITH_CTF=1 options SCHED_ULE options PREEMPTION options INET options TCP_OFFLOAD options TCP_HHOOK options FFS options SOFTUPDATES options UFS_ACL *** *** 23,33 --- 20,32 options NFS_ROOT options MSDOSFS options CD9660 + options UDF options PROCFS options PSEUDOFS options GEOM_PART_GPT options GEOM_RAID options GEOM_LABEL + options GEOM_BDE options COMPAT_FREEBSD32 options COMPAT_FREEBSD4 options COMPAT_FREEBSD5 *** *** 71,76 --- 70,78 options SMP options DEVICE_NUMA device cpufreq + options IPFIREWALL + options IPFIREWALL_VERBOSE + options IPDIVERT device acpi options ACPI_DMAR device pci *** *** 81,134 device ata device mvs device siis - device ahc - options AHC_REG_PRETTY_PRINT - device ahd - options AHD_REG_PRETTY_PRINT - device esp - device hptiop - device isp - device mpt - device mps - device mpr - device sym - device trm - device adv - device adw - device aic - device bt - device isci device scbus - device ch device da - device sa device cd device pass device ses - device amr - device arcmsr - device ciss - device dpt - device hptmv - device hptnr - device hptrr - device hpt27xx - device iir - device ips - device mly - device twa - device tws - device aac - device aacp - device aacraid - device ida - device mfi - device mlx - device mrsas - device pmspcv - device twe - device nvme - device nvd device atkbdc device atkbd device psm --- 83,93 *** *** 150,202 device ppbus device lpt device ppi - device puc device bxe - device de - device em - device igb - device ix - device ixv - device ixl - device ixlv - device le - device ti - device txp - device vx device miibus - device ae - device age - device alc - device ale - device bce - device bfe - device bge - device cas - device dc - device et - device fxp - device gem - device hme - device jme - device lge - device msk - device nfe - device nge - device pcn - device re - device rl - device sf - device sge - device sis - device sk - device ste - device stge - device tl - device tx - device vge - device vr - device wb - device xl device wlan options IEEE80211_DEBUG options IEEE80211_AMPDU_AGE --- 109,116 *** *** 221,226 --- 135,143 device ral device wi device wpi + device bge + device sound + device "snd_hda" device loop device random device padlock_rng *** *** 234,253 device bpf options USB_DEBUG device uhci - device ohci device ehci device xhci device usb device ukbd device umass - device sound - device snd_cmi - device snd_csa - device snd_emu10kx - device snd_es137x - device snd_hda - device snd_ich - device snd_via8233 device mmc device mmcsd device sdhci --- 151,162 device bpf options USB_DEBUG device uhci device ehci device xhci device usb + device urndis device ukbd device umass device mmc device mmcsd device sdhci *** *** 261,265 options XENHVM device xenpci device vmx - device netmap device crypto --- 170,175 options XENHVM device xenpci device vmx device crypto + device coretemp + options EXT2FS Cheers, Julian -- Julian Stacey, BSD Linux Unix Sys Eng Consultant Munic
Re: NFSv4 performance degradation with 12.0-CURRENT client
On Sat, Nov 26, 2016 at 11:19:19PM +, Rick Macklem wrote:
> Konstantin Belousov wrote:
> [stuff snipped]
> >I thought that the issue was in tracking any opens and mmaps, but from this
> >reply it is not that clear. Do you need callback when all opens and mmaps
> >have ended, or only opens and mmaps for write ? If later, we already have
> >a suitable mechanism VOP_ADD_WRITECOUNT().
>
> Not quite. The NFSv4 client needs to Close the NFSv4 Open after all I/O on
> the file has been done. This applies to both reads and writes.
> Since mmap'd files can generate I/O after the VOP_CLOSE(), the NFSv4 client
> can't do the NFSv4 Close in VOP_CLOSE().
> Since it can't do it then, it waits until VOP_INACTIVE() to do the NFSv4
> Close.
>
> This might be improved by:
> - A flag that indicates that an open file descriptor has been mmap()d, which
> VOP_CLOSE() could check to decide if it can do the NFSv4 Close.
> (ie. It could do the NFSv4 Close if the file descriptor hasn't been
> mmap()d.)
> - If the system knows when mmap()d I/O is done (the process has terminated?),
> it could do a VOP_MMAP_IO_DONE() and the NFSv4 client would do the NFSv4
> Close
> in it.
> --> I don't know if this is feasible and I suspect if it could be done,
> that it would
> usually happen just before VOP_INACTIVE(). { This case of nullfs
> caching was an
> exception, I think? }
>
> Does this clarify it? rick
Thank you, yes, it clarifies the things, and makes it clear that my idea
is not feasible.
It is not hard to count number of mappings for the vnode object, but I
do not want to do this by straight-forward addition of the counter to
the vnode or vm object, since that would significantly increase amount
of memory used by VFS.
___
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: Please test EARLY_AP_STARTUP
Am Fri, 25 Nov 2016 10:20:36 -0800 John Baldwin schrieb: > I plan to enable EARLY_AP_STARTUP on x86 in a week on HEAD. Some folks > have been testing it for the last week or so which has exposed some > additional things to fix. I think I've resolved most of those in one > way or another, but it will make things smoother if other folks can > start testing this over the next few days before it is enabled by default. > > (To enable, add 'options EARLY_AP_STARTUP' to your kernel config.) > > Note that non-x86 platforms should eventually adopt this, but I don't > think any of them are ready yet. > I tried. I use three boxes, all running most recent CURRENT. Only one box does work and boot with the option mentioned above in the kernel. The other two don't, they stop at printing something about HPET timer initialisation and stop - forever. I did not digg deeper into it, but there is something strange: Both failing boxes have CPUs with two cores, four threads. One is a notebook with an Haswell 4200M, the other is a i3-3220. The i3-3220 box has a motherboard ASROCK Z77-Pro4 (UEFI on this crap is not working), 8 GB RAM (2x 4GB), lates firmware from 2013. The working box has an ASROCK Z77-Pro4 M (mini ATX size mobo), 16 GB RAM (2x 8GB), but a 4 core/8 thread XEON IvyBridge E3-1245 V2. The firmare is the latest, from 2013. The box is running well with the option EARLY_AP_STARTUP set. At a first glance it looks like the failure is dependend on the CPU count ;-) I have also a small PCengine APU 2C4, AMD Jaguar CPU with 4 core/4 threads which is about to be tested also with the most recent CURRENT and the option in question set - but it takes time. Just for the record, my apologizes if someone feels disturbed from naive observations. Kind regards, oh -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). pgpuldC2fbRob.pgp Description: OpenPGP digital signature
