Re: head -r333974 fix-to-the-build exposes another breaks-the-build problem in top (at least for gcc based builds)

[Eitan Adler]

On 21 May 2018 at 18:06, Mark Millard  wrote:
> On 2018-May-21, at 5:46 PM, Mark Millard  wrote:

> I should have been explicit that the material is from
> ci.freebsd.org .

Your email seems to always be marked as spam by my MUA even though
SPF, DKIM, and DMARC pass. Apologies if you've sent me other mail I've
missed.

> For reference, the gcc based builds seem to be:
> (all but the last being gcc 4.2.1 based if I
> undertand right)

FWIW believe these are fixed now. At least, they do not fail locally
on "make universe" on top(1).



-- 
Eitan Adler
Source, Ports, Doc committer
Bugmeister, Ports Security teams
___
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: [RFC] Deprecation and removal of the drm2 driver

[Nathan Whitehorn]

On 05/22/18 18:12, Rodney W. Grimes wrote:


it makes me giggle that people still think non-amd64 is "legacy".

i386 is alive and well - new chips are being fabbed based on the 586
design with pci-e slots; not to mention things like the Talos and
AmigaOne for PowerPC.

Yes, some how we need to shake off the idea that all the world
is going to be 64 bit, and stop talking about EOL for 32 bit
x86,   IMHO that would be a serious mistake.  For one any VM
that does not need >4G of address space is a waste to run
in 64 bit mode.


DRM2 doesn't support anything later than mid-Haswell. The chips in
question all pre-date 2007. Users of low-volume hardware on chips from

Um, haswell announced in 2011, started shipping in mid 2013, and last
product started to ship in 2015, so if "mid-haswell" is the supported
chip arrena that would be pre date 2012?

Also as the Moore's law curve flattens expect the life of these
older, but not so old, machines to live quiet some time.  I
believe we are talking sandy bridge and earlier?  If that is
corret Sandy bridge is still a very viable system.


that period are welcome to continue to sustain themselves on the drm2
port just as the other 95+% of the user base will use what is now
referred to as drm-next. Even by powerpc maintainers' admission DRM2
also only barely works there. I've promised Justin that I'll make
drm-next work on Talos once POWER9 support is solid enough.

I think the original RFC has been answer, yes there are people still
using DRM2, and they wish to continue to use it into the 12.x time
frame.

Lets find a technically agreeable solution to that, and move forward.

I am concerned about just disabling the compile on amd64,
that typically leads to bit rot of the i386 code.

I am concerned about just shoving it out to ports, as that makes
it rot even faster.

I am still very concerned that our in base i9xx code is like 4
years old and everyone is told to go to kmod-next from ports
as well.

No, I do not have a solution, but I have not tried hard to find
one.  I am sure if we try hard to find one it can be done.

Regards,


The real question in this thread is, I think: Do we want to co-version 
the drm kernel modules with kernel/OS releases or with the graphics 
drivers that use them (which are in ports)? I use the base modules (on 
2014-era amd64 hardware), but would be perfectly happy with modules in 
ports and it seems like there is a compelling argument for co-versioning 
the things in x11-drivers with the kernel modules.


I would like to make a proposal here:
- Rename drm-next to drm-kmod
- Move sys/dev/drm2 to a new port drm-kmod-legacy
- Have one of the two, by default drm-kmod (amd64) or drm-kmod-legacy 
(i386), pulled in as a dependency by the relevant X11 drivers
- Garbage-collect dev/drm, which supports 3DFX and Rage 128 and such 
archaic things


I think this keeps the user experience intact and lets the graphics 
developers update in the way that works best for them.

-Nathan
___
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: [RFC] Deprecation and removal of the drm2 driver

[Steve Kargl]

On Tue, May 22, 2018 at 04:32:39PM -0700, K. Macy wrote:
> Why are you running i386 on that?
> 

I'm not.  Just pointing out that drm2 runs on amd64 as
well as i386.  Also need to correct the dis-information
that drm2 only applies to mid-Haswell and older.

In the end, src committers will do what they want, so
this is my last post.

-- 
Steve
___
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: [RFC] Deprecation and removal of the drm2 driver

[Steve Kargl]

On Tue, May 22, 2018 at 07:50:39AM +0100, Johannes Lundberg wrote:
> On Mon, May 21, 2018 at 23:50 Steve Kargl 
> wrote:
> 
> > On Mon, May 21, 2018 at 03:20:49PM -0700, K. Macy wrote:
> > > >
> > > > I just ask.
> > > > Or why not include drm-next to base svn repo and add some
> > > > option to make.conf to swith drm2/dem-next ?
> > >
> > > Even if it's not being built on amd64 we're still responsible for
> > > keeping it building on !amd64 so long as it's in base. This makes
> > > changing APIs and universe runs more burdensome. The graphics
> > > developers have given you notice that it will now be your collective
> > > responsibility to keep it up to date.
> > >
> >
> > Not quite.  One graphics developer has indicated a desire
> > to remove working code, because it interferes with the
> > graphics developers' port on a single architecture.  There
> > is no indication by that graphics developer that drm2 will
> > be available in ports.  You can go read the original post
> > here:
> >
> > https://lists.freebsd.org/pipermail/freebsd-current/2018-May/069401.html
> >
> > The last paragraph is
> >
> >What does the community think?  Is there anyone still using
> >the drm2 driver on 12-CURRENT?  If so, what is preventing
> >you from switching to the port?
> >
> > The answer to the last two questions are "yes" and "the port
> > does not work on i386".
> >
> > What is wrong with using
> >
> > .if ${MACHINE_ARCH} != amd64
> > ...
> > .endif
> >
> > to enable/disable drm2?
> 
> The answer to the first question is that the consensus seem to be that
> moving to a port is best for the _majority_.

Best for amd64.  For the majority, if one starts X, it
automatically loads drm2 if one allows X to configure
itself and drm2 applies.  It's automatically loaded
on both by i386 laptop and amd64 desktop. 

> Let me ask you, what’s wrong with this one-liner after base install
> pkg install drm2
> ?

1) The original email did not indicate the code would be
   moved to a port.  It simply said removed.

2) Nothing wrong if you know where to go looking for drm2.
   FreeBSD goes from having drm2 automatically loaded for
   a user to hoping that a user knows about a port.

3) I've already posted a 2-line patch for amd64 (twice actually).
   How many lines are needed to make the port?

-- 
Steve
___
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: [RFC] Deprecation and removal of the drm2 driver

[K. Macy]

Why are you running i386 on that?

On Tue, May 22, 2018 at 4:26 PM, Steve Kargl
 wrote:
> On Tue, May 22, 2018 at 02:56:55PM -0700, K. Macy wrote:
>> >
>> >
>> > it makes me giggle that people still think non-amd64 is "legacy".
>> >
>> > i386 is alive and well - new chips are being fabbed based on the 586
>> > design with pci-e slots; not to mention things like the Talos and
>> > AmigaOne for PowerPC.
>>
>>
>> DRM2 doesn't support anything later than mid-Haswell. The chips in
>> question all pre-date 2007. Users of low-volume hardware on chips from
>> that period are welcome to continue to sustain themselves on the drm2
>> port just as the other 95+% of the user base will use what is now
>> referred to as drm-next. Even by powerpc maintainers' admission DRM2
>> also only barely works there. I've promised Justin that I'll make
>> drm-next work on Talos once POWER9 support is solid enough.
>
> % dmesg | CPU
> CPU: AMD FX(tm)-8350 Eight-Core Processor(4018.34-MHz K8-class 
> CPU)
> % kldstat
> troutmask:sgk[205] kldstat
> Id Refs AddressSize Name
>  91 0x8141e000 db148radeonkms.ko
> 101 0x814fa000 3f7d0drm2.ko
> 112 0x8153a000 acf8 agp.ko
> 121 0x81545000 12f9 radeonkmsfw_CAICOS_pfp.ko
> 131 0x81547000 16f7 radeonkmsfw_CAICOS_me.ko
> 141 0x81549000 d73  radeonkmsfw_BTC_rlc.ko
> 151 0x8154a000 5f97 radeonkmsfw_CAICOS_mc.ko
>
> Mid-Haswell?
>
> --
> Steve
___
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: [RFC] Deprecation and removal of the drm2 driver

[Steve Kargl]

On Tue, May 22, 2018 at 02:56:55PM -0700, K. Macy wrote:
> >
> >
> > it makes me giggle that people still think non-amd64 is "legacy".
> >
> > i386 is alive and well - new chips are being fabbed based on the 586
> > design with pci-e slots; not to mention things like the Talos and
> > AmigaOne for PowerPC.
> 
> 
> DRM2 doesn't support anything later than mid-Haswell. The chips in
> question all pre-date 2007. Users of low-volume hardware on chips from
> that period are welcome to continue to sustain themselves on the drm2
> port just as the other 95+% of the user base will use what is now
> referred to as drm-next. Even by powerpc maintainers' admission DRM2
> also only barely works there. I've promised Justin that I'll make
> drm-next work on Talos once POWER9 support is solid enough.

% dmesg | CPU
CPU: AMD FX(tm)-8350 Eight-Core Processor(4018.34-MHz K8-class CPU)
% kldstat
troutmask:sgk[205] kldstat
Id Refs AddressSize Name
 91 0x8141e000 db148radeonkms.ko
101 0x814fa000 3f7d0drm2.ko
112 0x8153a000 acf8 agp.ko
121 0x81545000 12f9 radeonkmsfw_CAICOS_pfp.ko
131 0x81547000 16f7 radeonkmsfw_CAICOS_me.ko
141 0x81549000 d73  radeonkmsfw_BTC_rlc.ko
151 0x8154a000 5f97 radeonkmsfw_CAICOS_mc.ko

Mid-Haswell?

-- 
Steve
___
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: [RFC] Deprecation and removal of the drm2 driver

[Rodney W. Grimes]

> > I am concerned about just shoving it out to ports, as that makes
> > it rot even faster.
> >
> > I am still very concerned that our in base i9xx code is like 4
> > years old and everyone is told to go to kmod-next from ports
> > as well.
> >
> > No, I do not have a solution, but I have not tried hard to find
> > one.  I am sure if we try hard to find one it can be done.
> 
> drm-next is a port and it's what most everyone will be using going
> forward. You're asking us to make a special case for a small vocal
> group of i386 users. If i386 is sufficiently important, its user base
> can support it.

Are you saying there is only one way forward?


-- 
Rod Grimes rgri...@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: [RFC] Deprecation and removal of the drm2 driver

[K. Macy]

> I am concerned about just shoving it out to ports, as that makes
> it rot even faster.
>
> I am still very concerned that our in base i9xx code is like 4
> years old and everyone is told to go to kmod-next from ports
> as well.
>
> No, I do not have a solution, but I have not tried hard to find
> one.  I am sure if we try hard to find one it can be done.

drm-next is a port and it's what most everyone will be using going
forward. You're asking us to make a special case for a small vocal
group of i386 users. If i386 is sufficiently important, its user base
can support it.

Cheers.
-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: [RFC] Deprecation and removal of the drm2 driver

[Rodney W. Grimes]

> >
> >
> > it makes me giggle that people still think non-amd64 is "legacy".
> >
> > i386 is alive and well - new chips are being fabbed based on the 586
> > design with pci-e slots; not to mention things like the Talos and
> > AmigaOne for PowerPC.

Yes, some how we need to shake off the idea that all the world
is going to be 64 bit, and stop talking about EOL for 32 bit
x86,   IMHO that would be a serious mistake.  For one any VM
that does not need >4G of address space is a waste to run
in 64 bit mode.

> DRM2 doesn't support anything later than mid-Haswell. The chips in
> question all pre-date 2007. Users of low-volume hardware on chips from

Um, haswell announced in 2011, started shipping in mid 2013, and last
product started to ship in 2015, so if "mid-haswell" is the supported
chip arrena that would be pre date 2012?

Also as the Moore's law curve flattens expect the life of these
older, but not so old, machines to live quiet some time.  I
believe we are talking sandy bridge and earlier?  If that is
corret Sandy bridge is still a very viable system.

> that period are welcome to continue to sustain themselves on the drm2
> port just as the other 95+% of the user base will use what is now
> referred to as drm-next. Even by powerpc maintainers' admission DRM2
> also only barely works there. I've promised Justin that I'll make
> drm-next work on Talos once POWER9 support is solid enough.

I think the original RFC has been answer, yes there are people still
using DRM2, and they wish to continue to use it into the 12.x time
frame.

Lets find a technically agreeable solution to that, and move forward.

I am concerned about just disabling the compile on amd64,
that typically leads to bit rot of the i386 code.

I am concerned about just shoving it out to ports, as that makes
it rot even faster.

I am still very concerned that our in base i9xx code is like 4
years old and everyone is told to go to kmod-next from ports
as well.

No, I do not have a solution, but I have not tried hard to find
one.  I am sure if we try hard to find one it can be done.

Regards,
-- 
Rod Grimes rgri...@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: [RFC] Deprecation and removal of the drm2 driver

[K. Macy]

>
>
> it makes me giggle that people still think non-amd64 is "legacy".
>
> i386 is alive and well - new chips are being fabbed based on the 586
> design with pci-e slots; not to mention things like the Talos and
> AmigaOne for PowerPC.


DRM2 doesn't support anything later than mid-Haswell. The chips in
question all pre-date 2007. Users of low-volume hardware on chips from
that period are welcome to continue to sustain themselves on the drm2
port just as the other 95+% of the user base will use what is now
referred to as drm-next. Even by powerpc maintainers' admission DRM2
also only barely works there. I've promised Justin that I'll make
drm-next work on Talos once POWER9 support is solid enough.

Cheers.

-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: [RFC] Deprecation and removal of the drm2 driver

[A. Wilcox]

> I just ask.
> Or why not include drm-next to base svn repo and add some
> option to make.conf to swith drm2/dem-next ?

 Even if it's not being built on amd64 we're still responsible for
 keeping it building on !amd64 so long as it's in base. This makes
 changing APIs and universe runs more burdensome. The graphics
 developers have given you notice that it will now be your collective
 responsibility to keep it up to date.

>>>
>>> Not quite.  One graphics developer has indicated a desire
>>> to remove working code, because it interferes with the
>>> graphics developers' port on a single architecture.  There
>>> is no indication by that graphics developer that drm2 will
>>> be available in ports.  You can go read the original post
>>> here:
>>>
>>> https://lists.freebsd.org/pipermail/freebsd-current/2018-May/069401.html
>>>
>>> The last paragraph is
>>>
>>>What does the community think?  Is there anyone still using
>>>the drm2 driver on 12-CURRENT?  If so, what is preventing
>>>you from switching to the port?
>>>
>>> The answer to the last two questions are "yes" and "the port
>>> does not work on i386".
>>>
>>> Yes, I recognize that you're clever enough to purposefully
>>> break the API so that you can thumb your nose at those of
>>> us who have older hardware.
>>>
>>> What is wrong with using
>>>
>>> .if ${MACHINE_ARCH} != amd64
>>> ...
>>> .endif
>>>
>>> to enable/disable drm2?



> 
> With such long-time support offered by 11- branch, why hamper development
> of 12 by lugging around old, hard to maintain code that is relevant for
> only legacy hardware?
> 


it makes me giggle that people still think non-amd64 is "legacy".

i386 is alive and well - new chips are being fabbed based on the 586
design with pci-e slots; not to mention things like the Talos and
AmigaOne for PowerPC.


--arw

-- 
A. Wilcox (awilfox)
Open-source programmer (C, C++, Python)
https://code.foxkit.us/u/awilfox/



signature.asc
Description: OpenPGP digital signature

Re: Recent changes in routing or IPv6 related parts?

[Chris H]

On Tue, 22 May 2018 10:12:22 +0200 "Alexander Leidinger" 
 said


Hi,

I've updated 2 machines to r333966 and I see a change in the behavior  
in the network area on one of the systems.


To begin with, the "original" behavior was not OK either, the em NIC  
fails to "do proper network communication"  
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220997). A  
workaround for me was so far to do an IPv4 ping to the router from  
time to time, and if it fails do some ifconfig down/up. If the ping  
doesn't work afterwards, reboot. Most of the time this worked.


Now I see a change in behavior, the scripts kicks in, all is ok for  
the script afterwards, but internally (inside the machine) I can't  
reach ipv6 jails. The system is reachable externally (only tested so  
far is the main host-IP).


The setup is vimage based, several jails (via iocage) on epairs  
connected via bridge to the NIC. One bridge for IPv6, one for IPv4.  
rc.conf has prefer IPv4 setting after encountering another issue.


One IPv4 address (/32) for the host where a nginx is running to proxy  
port 80 and 443 requests on IPv4 to the IPv6 addresses of the jails  
(IPv6 access is going directly to the jails).


After a reboot, the nginx on the main IPv4 address delivers data from  
the ipv6 addresses of the jails (rev-proxy setup). After a while this  
stops working. The workaround-script mentioned above doesn't change  
this behavior. Restarting nginx doesn't help. A reboot helps.


Has someone an idea of recent changes in a related area which may be  
able to cause such an issue? Any rev I could try to revert to check if  
it is related?

Hello, Alexander.
I'm not sure if this landed in -CURRENT. I only know it landed in 11.
But your trouble might be related to pr #224247 :

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224247

Hope this helps.

--Chris


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF



___
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: [RFC] Deprecation and removal of the drm2 driver

[Niclas Zeising]

On 05/22/18 13:47, dpolyg wrote:

I have one comment regarding usage of the drm2 on a "legacy" hardware.
Excuse me in advance if I misunderstand something.
For the last 2-3 years I'm playing with devices such as small form 
factor PCs from Shuttle:

http://global.shuttle.com/products/productsList?categoryId=69
or from Gigabyte:
https://www.gigabyte.com/us/Mini-PcBarebone
or Intel "NUC"s.
To my experience drm-next doesn't work on lower price (Celeron/Atom) 
models. Do I missing something?

Here is concrete example:
I have a Shuttle DS47: 
http://global.shuttle.com/main/productsDetail?productId=1718

running FreeBSD 11.1-RELEASE and drm2.ko loaded + Xorg + compton.
Having that I made a box with a voice control and ability to make a SIP 
video call to it from a smartphone (WebRTC) (imagine "Amazon Show" 
powered by stock FeeBSD) but I never install any drm-next on it. Stock 
amd64 kernel used. No ports compiled. Only "pkg install ..." + custom 
code as the most front end.

After reading this thread I tried to compile drm-next on my DS47 box:

root@ShuttleD47:/usr/ports/graphics/drm-next-kmod # uname -a
FreeBSD ShuttleD47 11.1-RELEASE-p10 FreeBSD 11.1-RELEASE-p10 #0: Tue May 
  8 05:21:56 UTC 2018 
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

root@ShuttleD47:/usr/ports/graphics/drm-next-kmod # make
===>  drm-next-kmod-4.11.g20180505_1 not supported on 10.x or older, no 
kernel

support.
*** Error code 1

Stop.
make: stopped in /usr/ports/graphics/drm-next-kmod

Why drm-next thinks it lives on a 10.x kernel or older?
Is such usage case already considered as legacy?
Is this hardware supported by drm-next?
https://www.amazon.com/Best-Sellers-Electronics-Mini-Computers/zgbs/electronics/13896591011 




That is most likely a typo, or at least not as good as it should be. 
drm-stable-kmod and drm-next-kmod are supported on CURRENT and will be 
supported on FreeBSD 11.2 (it's supported in stable right now).  Older 
releases will, however, not be supported.  But they still have drm2, I 
will not remove any drivers from releases or from STABLE.

Regards
--
Niclas
___
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: How to check if not clean shutdown?

[Rodney W. Grimes]

> On Tue, May 22, 2018 at 3:30 PM, Warner Losh  wrote:
> 
> > You can't, in general. By the time the boot loader starts, all knowledge
> > of past boots is gone, unless specific counter-measures were put in place.
> >
> > However, if root is UFS and read/write in your box, it will be unclean on
> > anything but a clean shutdown/reboot. If it's read-only, ZFS or NFS
> > mounted, then you can't use this method.
> >
> > If you have UEFI, you can set a UEFI variable on shutdown and clear it on
> > boot. If it's not there on boot, you had an unclean shutdown. You could do
> > the same with a file in a r/w filesystem that doesn't record clean/unclean
> > (like ZFS or NFS).
> >
> > Locally, we have hacks to IPMI to record kernel crashes in the IPMI log,
> > but that's kinda specific to the BMC we have on our boards...
> >
> > Warner
> >
> 
> I see. Thanks for the quick reply.
> I guess I can add a dummy file somewhere that I delete in a shutdown hook.

utmp has one attempt at keeping track of this by recording a shutdown record.


> > On Tue, May 22, 2018 at 7:57 AM, Johannes Lundberg 
> > wrote:
> >
> >> Hi
> >>
> >> In the boot process on my test machines I'd like to do different things
> >> depending on the last run was a clean shutdown or kernel panic. Where/How
> >> can I get this information?
> >>
> >> Thanks!
> >> ___
> >> 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"
> 

-- 
Rod Grimes rgri...@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: Deadlocks / hangs in ZFS

[Slawa Olhovchenkov]

On Tue, May 22, 2018 at 04:16:32PM +0200, Alexander Leidinger wrote:

> 
> Quoting Slawa Olhovchenkov  (from Tue, 22 May 2018  
> 15:29:24 +0300):
> 
> > On Tue, May 22, 2018 at 08:17:00AM -0400, Steve Wills wrote:
> >
> >> I may be seeing similar issues. Have you tried leaving top -SHa running
> >> and seeing what threads are using CPU when it hangs? I did and saw pid
> >> 17 [zfskern{txg_thread_enter}] using lots of CPU but no disk activity
> >> happening. Do you see similar?
> 
> I will try and report back.
> 
> > Can you try https://reviews.freebsd.org/D7538 and report?
> 
> The patch tells it is against -STABLE, we're talking -current here.

ZFS don't changes this.

> It has been a while since I tried Karl's patch the last time, and I  
> stopped because it didn't apply to -current anymore at some point.
> Will what is provided right now in the patch work on -current?

I am mean yes, after s/vm_cnt.v_free_count/vm_free_count()/g
I am don't know how to have two distinct patch (for stable and current) in one 
review.

> As a data point, the system I talk about in the start of the thread  
> has 64 GB RAM and the ARC is not limited via sysctl.

Currently vanlia ARC poorly limited via sysctl. After abd extra.
May be interesting test

./sys/cddl/contrib/opensolaris/uts/common/fs/zfs/abd.c:boolean_t 
zfs_abd_scatter_enabled = B_FALSE;

(no sysctl for change this exist)
___
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: How to check if not clean shutdown?

[Johannes Lundberg]

On Tue, May 22, 2018 at 3:30 PM, Warner Losh  wrote:

> You can't, in general. By the time the boot loader starts, all knowledge
> of past boots is gone, unless specific counter-measures were put in place.
>
> However, if root is UFS and read/write in your box, it will be unclean on
> anything but a clean shutdown/reboot. If it's read-only, ZFS or NFS
> mounted, then you can't use this method.
>
> If you have UEFI, you can set a UEFI variable on shutdown and clear it on
> boot. If it's not there on boot, you had an unclean shutdown. You could do
> the same with a file in a r/w filesystem that doesn't record clean/unclean
> (like ZFS or NFS).
>
> Locally, we have hacks to IPMI to record kernel crashes in the IPMI log,
> but that's kinda specific to the BMC we have on our boards...
>
> Warner
>

I see. Thanks for the quick reply.
I guess I can add a dummy file somewhere that I delete in a shutdown hook.


>
>
> On Tue, May 22, 2018 at 7:57 AM, Johannes Lundberg 
> wrote:
>
>> Hi
>>
>> In the boot process on my test machines I'd like to do different things
>> depending on the last run was a clean shutdown or kernel panic. Where/How
>> can I get this information?
>>
>> Thanks!
>> ___
>> 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: How to check if not clean shutdown?

[Warner Losh]

You can't, in general. By the time the boot loader starts, all knowledge of
past boots is gone, unless specific counter-measures were put in place.

However, if root is UFS and read/write in your box, it will be unclean on
anything but a clean shutdown/reboot. If it's read-only, ZFS or NFS
mounted, then you can't use this method.

If you have UEFI, you can set a UEFI variable on shutdown and clear it on
boot. If it's not there on boot, you had an unclean shutdown. You could do
the same with a file in a r/w filesystem that doesn't record clean/unclean
(like ZFS or NFS).

Locally, we have hacks to IPMI to record kernel crashes in the IPMI log,
but that's kinda specific to the BMC we have on our boards...

Warner


On Tue, May 22, 2018 at 7:57 AM, Johannes Lundberg 
wrote:

> Hi
>
> In the boot process on my test machines I'd like to do different things
> depending on the last run was a clean shutdown or kernel panic. Where/How
> can I get this information?
>
> Thanks!
> ___
> 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: Deadlocks / hangs in ZFS

[Alexander Leidinger]

Quoting Slawa Olhovchenkov  (from Tue, 22 May 2018  
15:29:24 +0300):



On Tue, May 22, 2018 at 08:17:00AM -0400, Steve Wills wrote:


I may be seeing similar issues. Have you tried leaving top -SHa running
and seeing what threads are using CPU when it hangs? I did and saw pid
17 [zfskern{txg_thread_enter}] using lots of CPU but no disk activity
happening. Do you see similar?


I will try and report back.


Can you try https://reviews.freebsd.org/D7538 and report?


The patch tells it is against -STABLE, we're talking -current here.
It has been a while since I tried Karl's patch the last time, and I  
stopped because it didn't apply to -current anymore at some point.

Will what is provided right now in the patch work on -current?

As a data point, the system I talk about in the start of the thread  
has 64 GB RAM and the ARC is not limited via sysctl.




Bye,
Alexander.
--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpJhsT1lSPKB.pgp
Description: Digitale PGP-Signatur

Re: Deadlocks / hangs in ZFS

[Andrea Venturoli]

On 05/22/18 10:17, Alexander Leidinger wrote:

Hi,

does someone else experience deadlocks / hangs in ZFS?


Yes, in conjunction with Poudriere, probably when it builds/activates jails.
Not sure this is the same problem you are seeing.

 bye
av.
___
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"

How to check if not clean shutdown?

[Johannes Lundberg]

Hi

In the boot process on my test machines I'd like to do different things
depending on the last run was a clean shutdown or kernel panic. Where/How
can I get this information?

Thanks!
___
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"

uchcom update

[Andriy Gapon]

Yesterday I committed some changes to uchcom (so far, only in CURRENT).
Commits are r333997 - r334002.

If you have a CH340/341 based USB<->RS232 adapter and it works for you, could
you please test that it still does?
If you tried your adapter in the past and it did not work, there is a chance it
might start working now.  Could you please test that as well?

Thanks!
-- 
Andriy Gapon
___
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: Deadlocks / hangs in ZFS

[Luciano Mannucci]

On Tue, 22 May 2018 10:17:49 +0200
Alexander Leidinger  wrote:

> does someone else experience deadlocks / hangs in ZFS?
I did experience ZFS hangs on heavy load on relatively big iron (using
rsync, in my case). Theh was cured by reducing the amount of available
RAM to the zfs caching mechanism. Parameters in /boot/loader.conf
vfs.zfs.vdev.cache.size and vfs.zfs.arc_max may be your friends.
On a 16G machine not showing the syptoms anymore I have set:

kern.maxusers="4096"
vfs.zfs.vdev.cache.size="5G"
vfs.zfs.arc_min="122880"
vfs.zfs.arc_max="983040"

hope it helps,

Luciano.
-- 
 /"\ /Via A. Salaino, 7 - 20144 Milano (Italy)
 \ /  ASCII RIBBON CAMPAIGN / PHONE : +39 2 485781 FAX: +39 2 48578250
  X   AGAINST HTML MAIL/  E-MAIL: posthams...@sublink.sublink.org
 / \  AND POSTINGS/   WWW: http://www.lesassaie.IT/
___
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: Deadlocks / hangs in ZFS

[Slawa Olhovchenkov]

On Tue, May 22, 2018 at 08:17:00AM -0400, Steve Wills wrote:

> I may be seeing similar issues. Have you tried leaving top -SHa running 
> and seeing what threads are using CPU when it hangs? I did and saw pid 
> 17 [zfskern{txg_thread_enter}] using lots of CPU but no disk activity 
> happening. Do you see similar?

Can you try https://reviews.freebsd.org/D7538 and report?

> On 05/22/18 04:17, Alexander Leidinger wrote:
> > Hi,
> > 
> > does someone else experience deadlocks / hangs in ZFS?
> > 
> > What I see is that if on a 2 socket / 4 cores -> 16 threads system I do 
> > a lot in parallel (e.g. updating ports in several jails), then the 
> > system may get into a state were I can login, but any exit (e.g. from 
> > top) or logout of shell blocks somewhere. Sometimes it helps to CTRL-C 
> > all updates to get the system into a good shape again, but most of the 
> > times it doesn't.
> > 
> > On another system at the same rev (333966) with a lot less CPUs (and AMD 
> > instead of Intel), I don't see such a behavior.
> > 
> > Bye,
> > Alexander.
> > 
> ___
> 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: Deadlocks / hangs in ZFS

[Steve Wills]

I may be seeing similar issues. Have you tried leaving top -SHa running 
and seeing what threads are using CPU when it hangs? I did and saw pid 
17 [zfskern{txg_thread_enter}] using lots of CPU but no disk activity 
happening. Do you see similar?


Steve

On 05/22/18 04:17, Alexander Leidinger wrote:

Hi,

does someone else experience deadlocks / hangs in ZFS?

What I see is that if on a 2 socket / 4 cores -> 16 threads system I do 
a lot in parallel (e.g. updating ports in several jails), then the 
system may get into a state were I can login, but any exit (e.g. from 
top) or logout of shell blocks somewhere. Sometimes it helps to CTRL-C 
all updates to get the system into a good shape again, but most of the 
times it doesn't.


On another system at the same rev (333966) with a lot less CPUs (and AMD 
instead of Intel), I don't see such a behavior.


Bye,
Alexander.


___
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"

Deadlocks / hangs in ZFS

[Alexander Leidinger]

Hi,

does someone else experience deadlocks / hangs in ZFS?

What I see is that if on a 2 socket / 4 cores -> 16 threads system I  
do a lot in parallel (e.g. updating ports in several jails), then the  
system may get into a state were I can login, but any exit (e.g. from  
top) or logout of shell blocks somewhere. Sometimes it helps to CTRL-C  
all updates to get the system into a good shape again, but most of the  
times it doesn't.


On another system at the same rev (333966) with a lot less CPUs (and  
AMD instead of Intel), I don't see such a behavior.


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgp2EjECMweOa.pgp
Description: Digitale PGP-Signatur

Recent changes in routing or IPv6 related parts?

[Alexander Leidinger]

Hi,

I've updated 2 machines to r333966 and I see a change in the behavior  
in the network area on one of the systems.


To begin with, the "original" behavior was not OK either, the em NIC  
fails to "do proper network communication"  
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220997). A  
workaround for me was so far to do an IPv4 ping to the router from  
time to time, and if it fails do some ifconfig down/up. If the ping  
doesn't work afterwards, reboot. Most of the time this worked.


Now I see a change in behavior, the scripts kicks in, all is ok for  
the script afterwards, but internally (inside the machine) I can't  
reach ipv6 jails. The system is reachable externally (only tested so  
far is the main host-IP).


The setup is vimage based, several jails (via iocage) on epairs  
connected via bridge to the NIC. One bridge for IPv6, one for IPv4.  
rc.conf has prefer IPv4 setting after encountering another issue.


One IPv4 address (/32) for the host where a nginx is running to proxy  
port 80 and 443 requests on IPv4 to the IPv6 addresses of the jails  
(IPv6 access is going directly to the jails).


After a reboot, the nginx on the main IPv4 address delivers data from  
the ipv6 addresses of the jails (rev-proxy setup). After a while this  
stops working. The workaround-script mentioned above doesn't change  
this behavior. Restarting nginx doesn't help. A reboot helps.


Has someone an idea of recent changes in a related area which may be  
able to cause such an issue? Any rev I could try to revert to check if  
it is related?


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpQrNOHByQWY.pgp
Description: Digitale PGP-Signatur

Re: [RFC] Deprecation and removal of the drm2 driver

[Andreas Nilsson]

On Tue, May 22, 2018 at 8:50 AM, Johannes Lundberg 
wrote:

> On Mon, May 21, 2018 at 23:50 Steve Kargl  edu>
> wrote:
>
> > On Mon, May 21, 2018 at 03:20:49PM -0700, K. Macy wrote:
> > > >
> > > > I just ask.
> > > > Or why not include drm-next to base svn repo and add some
> > > > option to make.conf to swith drm2/dem-next ?
> > >
> > > Even if it's not being built on amd64 we're still responsible for
> > > keeping it building on !amd64 so long as it's in base. This makes
> > > changing APIs and universe runs more burdensome. The graphics
> > > developers have given you notice that it will now be your collective
> > > responsibility to keep it up to date.
> > >
> >
> > Not quite.  One graphics developer has indicated a desire
> > to remove working code, because it interferes with the
> > graphics developers' port on a single architecture.  There
> > is no indication by that graphics developer that drm2 will
> > be available in ports.  You can go read the original post
> > here:
> >
> > https://lists.freebsd.org/pipermail/freebsd-current/2018-May/069401.html
> >
> > The last paragraph is
> >
> >What does the community think?  Is there anyone still using
> >the drm2 driver on 12-CURRENT?  If so, what is preventing
> >you from switching to the port?
> >
> > The answer to the last two questions are "yes" and "the port
> > does not work on i386".
> >
> > Yes, I recognize that you're clever enough to purposefully
> > break the API so that you can thumb your nose at those of
> > us who have older hardware.
> >
> > What is wrong with using
> >
> > .if ${MACHINE_ARCH} != amd64
> > ...
> > .endif
> >
> > to enable/disable drm2?
>
>
>
> The answer to the first question is that the consensus seem to be that
> moving to a port is best for the _majority_.
>
> Let me ask you, what’s wrong with this one-liner after base install
> pkg install drm2
> ?
>
>
> >
> > --
> > Steve


Hello,

If you were running GNU/Linux, you would be using the equivalent of
drm-stable-kmod or drm-next-kmod. Why do you want to run older code on
FreeBSD?

Hardware and software moves on. One does not expect to run the latest
hardware with old software, old hardware and new software might work, if
someone is willing to maintain old code.

Since the proposal was to keep drm2 in 11, you're looking at support until
2021, will you still run that old hardware then?

With such long-time support offered by 11- branch, why hamper development
of 12 by lugging around old, hard to maintain code that is relevant for
only legacy hardware?

Best regards
Andreas
___
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: [RFC] Deprecation and removal of the drm2 driver

[Johannes Lundberg]

On Mon, May 21, 2018 at 23:50 Steve Kargl 
wrote:

> On Mon, May 21, 2018 at 03:20:49PM -0700, K. Macy wrote:
> > >
> > > I just ask.
> > > Or why not include drm-next to base svn repo and add some
> > > option to make.conf to swith drm2/dem-next ?
> >
> > Even if it's not being built on amd64 we're still responsible for
> > keeping it building on !amd64 so long as it's in base. This makes
> > changing APIs and universe runs more burdensome. The graphics
> > developers have given you notice that it will now be your collective
> > responsibility to keep it up to date.
> >
>
> Not quite.  One graphics developer has indicated a desire
> to remove working code, because it interferes with the
> graphics developers' port on a single architecture.  There
> is no indication by that graphics developer that drm2 will
> be available in ports.  You can go read the original post
> here:
>
> https://lists.freebsd.org/pipermail/freebsd-current/2018-May/069401.html
>
> The last paragraph is
>
>What does the community think?  Is there anyone still using
>the drm2 driver on 12-CURRENT?  If so, what is preventing
>you from switching to the port?
>
> The answer to the last two questions are "yes" and "the port
> does not work on i386".
>
> Yes, I recognize that you're clever enough to purposefully
> break the API so that you can thumb your nose at those of
> us who have older hardware.
>
> What is wrong with using
>
> .if ${MACHINE_ARCH} != amd64
> ...
> .endif
>
> to enable/disable drm2?



The answer to the first question is that the consensus seem to be that
moving to a port is best for the _majority_.

Let me ask you, what’s wrong with this one-liner after base install
pkg install drm2
?


>
> --
> Steve
> ___
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "freebsd-x11-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"