Re: drm-next update and longer term plans

2016-12-01 Thread Adrian Chadd 
Hi,

The challenge right now is figuring out how to implement / commit the
linux-y bits that the linux layer really wants. Kip has done a pretty
great job at figuring out the minimum set of hilarity that needs to go
into base versus linuxkpi.

But the "challenge" is figuring out some comprimise between what's
done and what we can do in FreeBSD land. Those changes are small but
unfortunately change the expectations we have. If someone's willing to
step up and help out with the linuxkpi side of things and the base
system bits (the new lock, some UMA changes, some VM changes, the
interrupt model that we have versus linux and what we're allowed to
do, etc, etc) then that'll really help.

I can help try to get stuff reviewed and help people know where some
of the quirky controversial bits are, but I don't have the cycles to
modify/rewrite any of it all to land in -HEAD. I need some help with
that.

If you're interested in helping out and can take some direction then
sign up and we'll figure the bits out.

Thanks!


-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

2016-12-01 Thread Sepherosa Ziehau 
On Fri, Dec 2, 2016 at 12:53 PM, Sepherosa Ziehau  wrote:
> On Fri, Dec 2, 2016 at 1:49 AM, John Baldwin  wrote:
>> On Thursday, December 01, 2016 01:53:29 PM Sepherosa Ziehau wrote:
>>> On Wed, Nov 30, 2016 at 9:59 AM, Sepherosa Ziehau  
>>> wrote:
>>> >>> 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?
>>> >>
>>> >> It is likely a race as we start running things sooner now, yes.  Can you
>>> >> break into DDB during the hang and see what thread0 is waiting on?  If
>>> >> it is in the interrupt hooks you can use 'show conifhk' in DDB to see the
>>> >> list of pending interrupt hooks.  That provides a list of candidate 
>>> >> drivers
>>> >> to inspect (e.g. stack traces of relevant kthreads) for what is actually
>>> >> waiting (and what it is waiting on)
>>> >
>>> > Just tried, but I failed to break into DDB during the 30 seconds
>>> > delay.  DDB was entered after the 30 seconds delay, though I press the
>>> > break key when the delay started.
>>>
>>> I tried add VERBOSE_SYSINIT option in order to get a rough location of
>>> this delay, but the system boots just fine w/ VERBOSE_SYSINIT option,
>>> sigh.
>>
>> You could add KTR_PROC tracing and use 'show ktr' in DDB when you break in 
>> after the
>> 30 second delay to see what it was doing during the delay perhaps?
>
> I have narrowed it down by patching the VERBOSE_SYSINIT: the
> kthread_start(_kd) introduces the 30 seconds delay, i.e.
> SYSINIT(deadlkres, SI_SUB_CLOCKS, SI_ORDER_ANY, kthread_start,
> _kd) blocks for 30 seconds.

I commented out the DEADLKRES option, now the delay happens randomly,
sometimes even before a VERBOSE_SYSINIT entry logging.  But the delay
always happens after inittimecounter(0), and before the
SI_SUB_INT_CONFIG_HOOKS.

I didn't notice useful information from DDB 'show ktr', once it
thawed.  Anything I should be aware of in the KTR_PROC ktrlog?

Thanks,
sephe

-- 
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: Please test EARLY_AP_STARTUP

2016-12-01 Thread Sepherosa Ziehau 
On Fri, Dec 2, 2016 at 1:49 AM, John Baldwin  wrote:
> On Thursday, December 01, 2016 01:53:29 PM Sepherosa Ziehau wrote:
>> On Wed, Nov 30, 2016 at 9:59 AM, Sepherosa Ziehau  
>> wrote:
>> >>> 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?
>> >>
>> >> It is likely a race as we start running things sooner now, yes.  Can you
>> >> break into DDB during the hang and see what thread0 is waiting on?  If
>> >> it is in the interrupt hooks you can use 'show conifhk' in DDB to see the
>> >> list of pending interrupt hooks.  That provides a list of candidate 
>> >> drivers
>> >> to inspect (e.g. stack traces of relevant kthreads) for what is actually
>> >> waiting (and what it is waiting on)
>> >
>> > Just tried, but I failed to break into DDB during the 30 seconds
>> > delay.  DDB was entered after the 30 seconds delay, though I press the
>> > break key when the delay started.
>>
>> I tried add VERBOSE_SYSINIT option in order to get a rough location of
>> this delay, but the system boots just fine w/ VERBOSE_SYSINIT option,
>> sigh.
>
> You could add KTR_PROC tracing and use 'show ktr' in DDB when you break in 
> after the
> 30 second delay to see what it was doing during the delay perhaps?

I have narrowed it down by patching the VERBOSE_SYSINIT: the
kthread_start(_kd) introduces the 30 seconds delay, i.e.
SYSINIT(deadlkres, SI_SUB_CLOCKS, SI_ORDER_ANY, kthread_start,
_kd) blocks for 30 seconds.

Thanks,
sephe

-- 
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: drm-next update and longer term plans

2016-12-01 Thread Kevin Oberman 
On Thu, Dec 1, 2016 at 2:25 PM, Matthew Macy  wrote:

> I imagine that for most users the state of graphics support for
> post-Haswell hardware is a bit of a black box so I'm sending out this note
> to let users know what they can and cannot expect.
>
> Wayland has actually become a reality for some. Talk to Johannes Lundberg
> if you're interested in tracking that.
>
> The i915 (Intel integrated GPUs) driver is currently best supported by the
> drm-next-4.7 branch. Broadwell and Skylake support is complete and some
> support came in late in the cycle for Kaby Lake. I can still consistently
> lock up the kernel in the later stages of the piglit test suite, there is
> no backlight support, and suspend/resume do not work on Skylake. The
> drm-next branch is integrated with upstream up through Linux 4.8-rc5 and
> thus has complete support for Kaby Lake, but there is a lockup in i915 that
> occurs some time within an hour of startx. This takes too long for it to
> have shown up in my limited integration smoke testing.
>
> The amdgpu driver is, in terms of KPI dependencies - as far as I can tell
> - a strict superset of the radeon driver. For example, when I tested my one
> older card that uses the radeon driver it manifested the same ttm bugs as
> amdgpu did at that time. Thus, when amdgpu reaches a complete working state
> I expect radeon to largely "just" work. As of this past Sunday amdgpu with
> the amdgpu DDX works with 2D, supports external monitors - selecting the
> appropriate resolution on a per display basis, and backlight works. It will
> also typically panic in ttm within ~90 minutes of startx. Although this is
> huge progress over panicking within 30s of startx (which was the case as of
> Saturday) or not starting at all due to bugs in the libdrm port a few weeks
> prior, it's obviously not something I encourage anyone to use.
>
> My primary motivation for starting with the work is being able to to train
> DNNs/RNNs and other model types using Theano/Caffe/Tensorflow/BidMach etc
> GPU accelerated whilst still running FreeBSD. The Radeon Open Compute stack
> holds out the promise of doing that without using the closed source CUDA
> stack on top of the Linux ABI emulation - which would inevitably be opaque
> and fragile. My plan is to keep on fixing bugs and tracking upstream until
> the first long term branch after ROC support has been integrated in to
> Linux mainline. I have no exact knowledge of when exactly that will be (AMD
> doesn't have sufficient developer resources to make any concrete
> guarantees) but think it should happen by the summer of 2017. I would like
> to think that by that time the i915, amdgpu, and radeon will be feature
> complete and at least as stable as the drm2 support currently in tree.
>
> I need to weigh my soft commitment to make long-term DRM support happen
> with paid work and other activities which are much more important to me
> long term. Thus I've currently committed to spending every Sunday fixing
> bugs in the drm-next branches. Amdgpu is both more important to me and has
> gotten much less attention than i915. Thus I will be devoting my efforts to
> it in the near term. I'd very much welcome efforts by others to triage the
> issues in i915.
>
> Many people ask when drm-next will be available on 11. I am not a
> committer and thus have no direct say in that. However, if you are a
> motivated individual with kernel knowledge you should contact Adrian Chadd.
> There are a few places where I was not able to provide proper linuxkpi
> semantics without making (mostly quite modest) changes to sys/kern. There
> is a general reluctance by some core developers to make changes to
> accommodate Linux. It is possible that, with additional effort, the
> linuxkpi can both be complete enough to avoid needing to port the graphics
> drivers to FreeBSD (something clearly shown by past efforts to be
> unsustainable) and not need to make any kernel changes. If you would like
> to help with that, let Adrian know. In the meantime, TrueOS will continue
> to use my development branches for the benefit of users with newer hardware.
>
> -M
>

Matt,

Thanks for your and your teams work on this. While I am still running on
Sandy Bridge hardware, I am hoping that my next system will be able to run
real X or Wayland without being stuck with VESA formonths, as I was when my
Sandy Bridge system was new. While I understand that this is really a
by-product of you goal, thanks for it.

I really hope that Core understands that unless FreeBSD can run drivers
developed for Linux or required only trivial patches, FreeBSD will always
lag at least months and probably years behind for both graphics and GPU
compute. While Linux does compete with FreeBSD, it is not an enemy. It is
fellow traveler and, when there is no legal reason that Linux code support
can't be accommodated, it should not be dismissed.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail:

Re: drm-next update and longer term plans

2016-12-01 Thread Ben Woods 
On Fri., 2 Dec. 2016 at 6:25 am, Matthew Macy  wrote:

> I imagine that for most users the state of graphics support for
> post-Haswell hardware is a bit of a black box so I'm sending out this note
> to let users know what they can and cannot expect.
>
> Wayland has actually become a reality for some. Talk to Johannes Lundberg
> if you're interested in tracking that.
>
> The i915 (Intel integrated GPUs) driver is currently best supported by the
> drm-next-4.7 branch. Broadwell and Skylake support is complete and some
> support came in late in the cycle for Kaby Lake. I can still consistently
> lock up the kernel in the later stages of the piglit test suite, there is
> no backlight support, and suspend/resume do not work on Skylake. The
> drm-next branch is integrated with upstream up through Linux 4.8-rc5 and
> thus has complete support for Kaby Lake, but there is a lockup in i915 that
> occurs some time within an hour of startx. This takes too long for it to
> have shown up in my limited integration smoke testing.
>
> The amdgpu driver is, in terms of KPI dependencies - as far as I can tell
> - a strict superset of the radeon driver. For example, when I tested my one
> older card that uses the radeon driver it manifested the same ttm bugs as
> amdgpu did at that time. Thus, when amdgpu reaches a complete working state
> I expect radeon to largely "just" work. As of this past Sunday amdgpu with
> the amdgpu DDX works with 2D, supports external monitors - selecting the
> appropriate resolution on a per display basis, and backlight works. It will
> also typically panic in ttm within ~90 minutes of startx. Although this is
> huge progress over panicking within 30s of startx (which was the case as of
> Saturday) or not starting at all due to bugs in the libdrm port a few weeks
> prior, it's obviously not something I encourage anyone to use.
>
> My primary motivation for starting with the work is being able to to train
> DNNs/RNNs and other model types using Theano/Caffe/Tensorflow/BidMach etc
> GPU accelerated whilst still running FreeBSD. The Radeon Open Compute stack
> holds out the promise of doing that without using the closed source CUDA
> stack on top of the Linux ABI emulation - which would inevitably be opaque
> and fragile. My plan is to keep on fixing bugs and tracking upstream until
> the first long term branch after ROC support has been integrated in to
> Linux mainline. I have no exact knowledge of when exactly that will be (AMD
> doesn't have sufficient developer resources to make any concrete
> guarantees) but think it should happen by the summer of 2017. I would like
> to think that by that time the i915, amdgpu, and radeon will be feature
> complete and at least as stable as the drm2 support currently in tree.
>
> I need to weigh my soft commitment to make long-term DRM support happen
> with paid work and other activities which are much more important to me
> long term. Thus I've currently committed to spending every Sunday fixing
> bugs in the drm-next branches. Amdgpu is both more important to me and has
> gotten much less attention than i915. Thus I will be devoting my efforts to
> it in the near term. I'd very much welcome efforts by others to triage the
> issues in i915.
>
> Many people ask when drm-next will be available on 11. I am not a
> committer and thus have no direct say in that. However, if you are a
> motivated individual with kernel knowledge you should contact Adrian Chadd.
> There are a few places where I was not able to provide proper linuxkpi
> semantics without making (mostly quite modest) changes to sys/kern. There
> is a general reluctance by some core developers to make changes to
> accommodate Linux. It is possible that, with additional effort, the
> linuxkpi can both be complete enough to avoid needing to port the graphics
> drivers to FreeBSD (something clearly shown by past efforts to be
> unsustainable) and not need to make any kernel changes. If you would like
> to help with that, let Adrian know. In the meantime, TrueOS will continue
> to use my development branches for the benefit of users with newer hardware.
>
> -M
>
> ___
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "freebsd-x11-unsubscr...@freebsd.org"
>

Hi Matthew / others,

Thanks for your work - I sincerely appreciate every minute of your personal
time spent on this.

What are your thoughts on whether this is ready for committing to
12-current, with plenty of time for polishing before it makes it into a
release?

Regards,
Ben
___
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: drm-next update and longer term plans

2016-12-01 Thread Shawn Webb 
On Thu, Dec 01, 2016 at 02:25:05PM -0800, Matthew Macy wrote:
> I imagine that for most users the state of graphics support for post-Haswell 
> hardware is a bit of a black box so I'm sending out this note to let users 
> know what they can and cannot expect. 
> 
> Wayland has actually become a reality for some. Talk to Johannes Lundberg if 
> you're interested in tracking that. 
> 
> The i915 (Intel integrated GPUs) driver is currently best supported by the 
> drm-next-4.7 branch. Broadwell and Skylake support is complete and some 
> support came in late in the cycle for Kaby Lake. I can still consistently 
> lock up the kernel in the later stages of the piglit test suite, there is no 
> backlight support, and suspend/resume do not work on Skylake. The drm-next 
> branch is integrated with upstream up through Linux 4.8-rc5 and thus has 
> complete support for Kaby Lake, but there is a lockup in i915 that occurs 
> some time within an hour of startx. This takes too long for it to have shown 
> up in my limited integration smoke testing. 
> 
> The amdgpu driver is, in terms of KPI dependencies - as far as I can tell - a 
> strict superset of the radeon driver. For example, when I tested my one older 
> card that uses the radeon driver it manifested the same ttm bugs as amdgpu 
> did at that time. Thus, when amdgpu reaches a complete working state I expect 
> radeon to largely "just" work. As of this past Sunday amdgpu with the amdgpu 
> DDX works with 2D, supports external monitors - selecting the appropriate 
> resolution on a per display basis, and backlight works. It will also 
> typically panic in ttm within ~90 minutes of startx. Although this is huge 
> progress over panicking within 30s of startx (which was the case as of 
> Saturday) or not starting at all due to bugs in the libdrm port a few weeks 
> prior, it's obviously not something I encourage anyone to use. 
> 
> My primary motivation for starting with the work is being able to to train 
> DNNs/RNNs and other model types using Theano/Caffe/Tensorflow/BidMach etc GPU 
> accelerated whilst still running FreeBSD. The Radeon Open Compute stack holds 
> out the promise of doing that without using the closed source CUDA stack on 
> top of the Linux ABI emulation - which would inevitably be opaque and 
> fragile. My plan is to keep on fixing bugs and tracking upstream until the 
> first long term branch after ROC support has been integrated in to Linux 
> mainline. I have no exact knowledge of when exactly that will be (AMD doesn't 
> have sufficient developer resources to make any concrete guarantees) but 
> think it should happen by the summer of 2017. I would like to think that by 
> that time the i915, amdgpu, and radeon will be feature complete and at least 
> as stable as the drm2 support currently in tree. 
> 
> I need to weigh my soft commitment to make long-term DRM support happen with 
> paid work and other activities which are much more important to me long term. 
> Thus I've currently committed to spending every Sunday fixing bugs in the 
> drm-next branches. Amdgpu is both more important to me and has gotten much 
> less attention than i915. Thus I will be devoting my efforts to it in the 
> near term. I'd very much welcome efforts by others to triage the issues in 
> i915. 
> 
> Many people ask when drm-next will be available on 11. I am not a committer 
> and thus have no direct say in that. However, if you are a motivated 
> individual with kernel knowledge you should contact Adrian Chadd. There are a 
> few places where I was not able to provide proper linuxkpi semantics without 
> making (mostly quite modest) changes to sys/kern. There is a general 
> reluctance by some core developers to make changes to accommodate Linux. It 
> is possible that, with additional effort, the linuxkpi can both be complete 
> enough to avoid needing to port the graphics drivers to FreeBSD (something 
> clearly shown by past efforts to be unsustainable) and not need to make any 
> kernel changes. If you would like to help with that, let Adrian know. In the 
> meantime, TrueOS will continue to use my development branches for the benefit 
> of users with newer hardware. 

Hey Matt,

Thank you so much for your hard work. It's very much appreciated.
Everyone would be stuck on the VESA driver with all its crappiness if it
weren't for the efforts you and your team have put in.

Since I make it a point to eat my own dogfood, it has been a pleasure
running a HardenedBSD-flavored version of your drm-next-4.7 bits. I'm
able to run HardenedBSD on my work-issued laptop instead of CentOS.
Thank you for saving me from that.

Thanks,

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE


signature.asc
Description: PGP signature

drm-next update and longer term plans

2016-12-01 Thread Matthew Macy 
I imagine that for most users the state of graphics support for post-Haswell 
hardware is a bit of a black box so I'm sending out this note to let users know 
what they can and cannot expect. 

Wayland has actually become a reality for some. Talk to Johannes Lundberg if 
you're interested in tracking that. 

The i915 (Intel integrated GPUs) driver is currently best supported by the 
drm-next-4.7 branch. Broadwell and Skylake support is complete and some support 
came in late in the cycle for Kaby Lake. I can still consistently lock up the 
kernel in the later stages of the piglit test suite, there is no backlight 
support, and suspend/resume do not work on Skylake. The drm-next branch is 
integrated with upstream up through Linux 4.8-rc5 and thus has complete support 
for Kaby Lake, but there is a lockup in i915 that occurs some time within an 
hour of startx. This takes too long for it to have shown up in my limited 
integration smoke testing. 

The amdgpu driver is, in terms of KPI dependencies - as far as I can tell - a 
strict superset of the radeon driver. For example, when I tested my one older 
card that uses the radeon driver it manifested the same ttm bugs as amdgpu did 
at that time. Thus, when amdgpu reaches a complete working state I expect 
radeon to largely "just" work. As of this past Sunday amdgpu with the amdgpu 
DDX works with 2D, supports external monitors - selecting the appropriate 
resolution on a per display basis, and backlight works. It will also typically 
panic in ttm within ~90 minutes of startx. Although this is huge progress over 
panicking within 30s of startx (which was the case as of Saturday) or not 
starting at all due to bugs in the libdrm port a few weeks prior, it's 
obviously not something I encourage anyone to use. 

My primary motivation for starting with the work is being able to to train 
DNNs/RNNs and other model types using Theano/Caffe/Tensorflow/BidMach etc GPU 
accelerated whilst still running FreeBSD. The Radeon Open Compute stack holds 
out the promise of doing that without using the closed source CUDA stack on top 
of the Linux ABI emulation - which would inevitably be opaque and fragile. My 
plan is to keep on fixing bugs and tracking upstream until the first long term 
branch after ROC support has been integrated in to Linux mainline. I have no 
exact knowledge of when exactly that will be (AMD doesn't have sufficient 
developer resources to make any concrete guarantees) but think it should happen 
by the summer of 2017. I would like to think that by that time the i915, 
amdgpu, and radeon will be feature complete and at least as stable as the drm2 
support currently in tree. 

I need to weigh my soft commitment to make long-term DRM support happen with 
paid work and other activities which are much more important to me long term. 
Thus I've currently committed to spending every Sunday fixing bugs in the 
drm-next branches. Amdgpu is both more important to me and has gotten much less 
attention than i915. Thus I will be devoting my efforts to it in the near term. 
I'd very much welcome efforts by others to triage the issues in i915. 

Many people ask when drm-next will be available on 11. I am not a committer and 
thus have no direct say in that. However, if you are a motivated individual 
with kernel knowledge you should contact Adrian Chadd. There are a few places 
where I was not able to provide proper linuxkpi semantics without making 
(mostly quite modest) changes to sys/kern. There is a general reluctance by 
some core developers to make changes to accommodate Linux. It is possible that, 
with additional effort, the linuxkpi can both be complete enough to avoid 
needing to port the graphics drivers to FreeBSD (something clearly shown by 
past efforts to be unsustainable) and not need to make any kernel changes. If 
you would like to help with that, let Adrian know. In the meantime, TrueOS will 
continue to use my development branches for the benefit of users with newer 
hardware. 

-M

___
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

2016-12-01 Thread John Baldwin 
On Thursday, December 01, 2016 01:53:29 PM Sepherosa Ziehau wrote:
> On Wed, Nov 30, 2016 at 9:59 AM, Sepherosa Ziehau  wrote:
> >>> 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?
> >>
> >> It is likely a race as we start running things sooner now, yes.  Can you
> >> break into DDB during the hang and see what thread0 is waiting on?  If
> >> it is in the interrupt hooks you can use 'show conifhk' in DDB to see the
> >> list of pending interrupt hooks.  That provides a list of candidate drivers
> >> to inspect (e.g. stack traces of relevant kthreads) for what is actually
> >> waiting (and what it is waiting on)
> >
> > Just tried, but I failed to break into DDB during the 30 seconds
> > delay.  DDB was entered after the 30 seconds delay, though I press the
> > break key when the delay started.
> 
> I tried add VERBOSE_SYSINIT option in order to get a rough location of
> this delay, but the system boots just fine w/ VERBOSE_SYSINIT option,
> sigh.

You could add KTR_PROC tracing and use 'show ktr' in DDB when you break in 
after the
30 second delay to see what it was doing during the delay perhaps?

-- 
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: r308432: Capsicumized `basename` make zsh prompt broken

2016-12-01 Thread Iblis Lin 

Tnx a lot!

The new `basename` works fine now.

---

Iblis Lin

Conrad Meyer 於 2016-12-02 01:30 寫到:


Hello Iblis,

Please try reinstalling libcapsicum after r309366, rebuilding
basename, and then removing the stdout kludge from your shell script.
Let me know if there's still a problem!

Thanks,
Conrad

On Sun, Nov 27, 2016 at 11:08 PM, Conrad Meyer  wrote: 
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

2016-12-01 Thread Conrad Meyer 
Hello Iblis,

Please try reinstalling libcapsicum after r309366, rebuilding
basename, and then removing the stdout kludge from your shell script.
Let me know if there's still a problem!

Thanks,
Conrad

On Sun, Nov 27, 2016 at 11:08 PM, Conrad Meyer  wrote:
> 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: CURRENT: pkg broken on r309320

2016-12-01 Thread O. Hartmann 
Am Wed, 30 Nov 2016 12:18:14 +
Matthew Seaman  schrieb:

> On 2016/11/30 12:14, Baptiste Daroussin wrote:
> > On Wed, Nov 30, 2016 at 12:10:31PM +, Matthew Seaman wrote:  
> >> On 2016/11/30 10:14, Baptiste Daroussin wrote:  
> >>> revert r309314 the issue is there:
> >>>
> >>> The ports tree defines PKG_CMD as pkg register but now bsd.own.mk 
> >>> predefines it
> >>> to simply pkg.
> >>>
> >>> There is a collision there.
> >>>  
> >>
> >> Pointy hat to me.  I'll revert that commit.
> >>
> >>Matthew
> >>  
> > 
> > I have proposed https://reviews.freebsd.org/D8677 instead which make sense 
> > and
> > does not require your to modify bsd.own.mk  
> 
> OK, I'll wait and see what the outcome of D8677 is.
> 
>   Cheers,
> 
>   Matthew
> 
> 
> 


Hello.

It seems to be fixed - or do I err?

Anyway, thank you. most recent CURRENT and most recent ports seem to cooperate 
again.

Kind regards,

Oliver

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgp7HvF8mZrbG.pgp
Description: OpenPGP digital signature