Re: rfc: should extant TLS connections be closed when a CRL is updated?

[Rick Macklem]

John-Mark Gurney wrote:
>Rick Macklem wrote this message on Fri, Sep 04, 2020 at 01:20 +:
>> The server side NFS over TLS daemon (rpc.tlsservd) can reload an updated
>> CRL (Certificate Revocation List) when a SIGHUP is posted to it.
>> However, it does not SSL_shutdown()/close() extant TCP connections using TLS.
>> (Those would only be closed if the daemon is restarted.)
>>
>> I am now thinking that, maybe, an SSL_shutdown()/close() should be done on
>> all extant TCP connections using NFS over TLS when an updated CRL is loaded,
>> since a connection might have used a revoked certificate for its handshake.
>>
>> What do others think?
>
>IMO, this should scan the existing connections, and only shut them
>down if they are using a revoked Cert.  This is the correct way to
>do things.
>
>I do realize that this is likely not possible, and in reality, the
>ssl library in use should do this automatically, but likely does not.
Well, not exactly "automatically, but X509_CRL_get0_by_ccert() checks
to see if a certificate is revoked, so all the code needed to do was
read the CRL file and then loop through the certificates, checking
each one.

>As the library likely does not, we should probably make this an
>option to close all connections upon CRL reload, with it being well
>documented.
>
>Now that option should likely be set to default on, but documented
>such that if you do regular/often CRL reloads, that a user may want
>to turn that off if it's disruptive to their server.
Not necessary, since doing just the revoked ones seems to work.

If you are curious, you can look at the recent commits or code
under head/projects/nfs-over-tls.

If anyone is interested in testing it, you can look at:
https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt

Thanks for the useful suggestion, rick

--
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."

___
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: Deprecating ftpd in the FreeBSD base system?

[Ed Maste]

On Wed, 16 Sep 2020 at 16:51, Allan Jude  wrote:
>
> Is the [ftpd] version we have in base unique? That is to say, does it need
> to be preserved somehow.

I'm not sure if we have functionality that doesn't exist elsewhere,
although we definitely have some changes that do not exist in other
BSDs.
___
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: Deprecating ftpd in the FreeBSD base system?

[Michael Gmelin]

> On 16. Sep 2020, at 22:53, Michael Gmelin  wrote:
> 
> 
> 
>>> On 16. Sep 2020, at 22:45, mike tancsa  wrote:
>>> 
>>> On 9/16/2020 2:07 PM, sth...@nethelp.no wrote:
>>> # override default of no subsystems
>>> -Subsystemsftp/usr/libexec/sftp-server
>>> +Subsystemsftpinternal-sftp -l INFO
>> 
>> Hi,
>> 
>> What is the difference between these two ?  Is it not all OpenSSH ?
> 
> Yes, but one is an external binary, while internal doesn’t rely on that. 
> Which means that your chroot setup won’t require bin and lib dirs. For most 
> scenarios, internal is the way to go.
> 
> The man page has more details.
> 
> -m

p.s. this is a good write-up:

https://serverfault.com/questions/660160/openssh-difference-between-internal-sftp-and-sftp-server


> 
> 
>>---Mike
>> 
>> 
>> ___
>> 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: Deprecating ftpd in the FreeBSD base system?

[Michael Gmelin]

> On 16. Sep 2020, at 22:45, mike tancsa  wrote:
> 
> On 9/16/2020 2:07 PM, sth...@nethelp.no wrote:
>> # override default of no subsystems
>> -Subsystemsftp/usr/libexec/sftp-server
>> +Subsystemsftpinternal-sftp -l INFO
> 
> Hi,
> 
> What is the difference between these two ?  Is it not all OpenSSH ?

Yes, but one is an external binary, while internal doesn’t rely on that. Which 
means that your chroot setup won’t require bin and lib dirs. For most 
scenarios, internal is the way to go.

The man page has more details.

-m


> ---Mike
> 
> 
> ___
> 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: Deprecating ftpd in the FreeBSD base system?

[Allan Jude]

On 2020-09-16 13:34, Ed Maste wrote:
> FTP is (becoming?) a legacy protocol, and I think it may be time to
> remove the ftp server from the FreeBSD base system - with the recent
> security advisory for ftpd serving as a reminder.
> 
> I've proposed adding a deprecation notice to the man page in
> https://reviews.freebsd.org/D26447 to start this off. There are a
> number of ftp servers in ports, and if we're going to remove the base
> system one we can create a port for it first, as well.
> 
> Any comments or concerns, please follow up in the code review or in email 
> here.
> ___
> 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"
> 

Is the version we have in base unique? That is to say, does it need to
be preserved somehow.

I know it is based on on the original 4.2BSD ftpd, but did we pull in
code from anywhere else at some point?

Or maybe a better question is: Which ftpd is the most similar, and would
allow people to migrate most easily (tnftpd from netbsd?)

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: Deprecating ftpd in the FreeBSD base system?

[mike tancsa]

On 9/16/2020 2:07 PM, sth...@nethelp.no wrote:
>  # override default of no subsystems
> -Subsystemsftp/usr/libexec/sftp-server
> +Subsystemsftpinternal-sftp -l INFO

Hi,

What is the difference between these two ?  Is it not all OpenSSH ?

    ---Mike


___
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: Deprecating ftpd in the FreeBSD base system?

[Michael Gmelin]

> On 16. Sep 2020, at 20:08, sth...@nethelp.no wrote:
> 
> 
>> 
>> FTP is (becoming?) a legacy protocol, and I think it may be time to
>> remove the ftp server from the FreeBSD base system - with the recent
>> security advisory for ftpd serving as a reminder.
>> 
>> I've proposed adding a deprecation notice to the man page in
>> https://reviews.freebsd.org/D26447 to start this off. There are a
>> number of ftp servers in ports, and if we're going to remove the base
>> system one we can create a port for it first, as well.
>> 
>> Any comments or concerns, please follow up in the code review or in email 
>> here.
> 
> Could we, at the same time, improve the documentation for sftp? I had
> to move an FTP server (with one chrooted user) from FTP to sftp today.
> I did:
> 
> 1. Add sftp user to /etc/passwd, with /usr/sbin/nologin as the shell.
> 2. Patch sshd config as follows:
> 
> --- etc/ssh/sshd_config.orig2018-06-16 22:04:20.868762000 +0200
> +++ etc/ssh/sshd_config2020-09-16 10:10:53.133211000 +0200
> @@ -112,7 +112,7 @@
> #Banner none
> 
> # override default of no subsystems
> -Subsystemsftp/usr/libexec/sftp-server
> +Subsystemsftpinternal-sftp -l INFO
> 
> # Example of overriding settings on a per-user basis
> #Match User anoncvs
> @@ -120,3 +120,8 @@
> #AllowTcpForwarding no
> #PermitTTY no
> #ForceCommand cvs server
> +Match User sftp
> +ChrootDirectory/usr/local/ftp/sftp
> +ForceCommand internal-sftp -l INFO
> +X11Forwarding no
> +AllowTcpForwarding no
> 
> 3. Ensure all levels of /usr/local/ftp/sftp are owned by root.
> 4. Create /usr/local/ftp/sftp/dev and add the following line to
> /etc/rc.conf:
> 
> syslogd_flags="-s -l /usr/local/ftp/sftp/dev/log"
> 
> Btw, I could not get /usr/libexec/sftp-server to work. Cryptic error
> message: "Received message too long 1416128883". Googling that one
> eventually led me to the internal-sftp subsystem and the rest of the
> sshd_config changes. The sshd_config man page is good, but I couldn't
> find anything about arguments (e.g. -l) for internal-sftp.

In case it helps, I documented an example sftp setup as part of the paperless 
port's man page last year:

https://svnweb.freebsd.org/ports/head/deskutils/py-paperless/files/paperless.7.in?revision=521891=co

-m

> 
> Steinar Haug, Nethelp consulting, sth...@nethelp.no
> ___
> 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: Deprecating ftpd in the FreeBSD base system?

[sthaug]

> FTP is (becoming?) a legacy protocol, and I think it may be time to
> remove the ftp server from the FreeBSD base system - with the recent
> security advisory for ftpd serving as a reminder.
> 
> I've proposed adding a deprecation notice to the man page in
> https://reviews.freebsd.org/D26447 to start this off. There are a
> number of ftp servers in ports, and if we're going to remove the base
> system one we can create a port for it first, as well.
> 
> Any comments or concerns, please follow up in the code review or in email 
> here.

Could we, at the same time, improve the documentation for sftp? I had
to move an FTP server (with one chrooted user) from FTP to sftp today.
I did:

1. Add sftp user to /etc/passwd, with /usr/sbin/nologin as the shell.
2. Patch sshd config as follows:

--- etc/ssh/sshd_config.orig2018-06-16 22:04:20.868762000 +0200
+++ etc/ssh/sshd_config 2020-09-16 10:10:53.133211000 +0200
@@ -112,7 +112,7 @@
 #Banner none
 
 # override default of no subsystems
-Subsystem  sftp/usr/libexec/sftp-server
+Subsystem  sftpinternal-sftp -l INFO
 
 # Example of overriding settings on a per-user basis
 #Match User anoncvs
@@ -120,3 +120,8 @@
 #  AllowTcpForwarding no
 #  PermitTTY no
 #  ForceCommand cvs server
+Match User sftp
+ChrootDirectory/usr/local/ftp/sftp
+ForceCommand internal-sftp -l INFO
+X11Forwarding no
+AllowTcpForwarding no

3. Ensure all levels of /usr/local/ftp/sftp are owned by root.
4. Create /usr/local/ftp/sftp/dev and add the following line to
/etc/rc.conf:

syslogd_flags="-s -l /usr/local/ftp/sftp/dev/log"

Btw, I could not get /usr/libexec/sftp-server to work. Cryptic error
message: "Received message too long 1416128883". Googling that one
eventually led me to the internal-sftp subsystem and the rest of the
sshd_config changes. The sshd_config man page is good, but I couldn't
find anything about arguments (e.g. -l) for internal-sftp.

Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
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: Deprecating ftpd in the FreeBSD base system?

[Warner Losh]

On Wed, Sep 16, 2020 at 11:34 AM Ed Maste  wrote:

> FTP is (becoming?) a legacy protocol, and I think it may be time to
> remove the ftp server from the FreeBSD base system - with the recent
> security advisory for ftpd serving as a reminder.
>
> I've proposed adding a deprecation notice to the man page in
> https://reviews.freebsd.org/D26447 to start this off. There are a
> number of ftp servers in ports, and if we're going to remove the base
> system one we can create a port for it first, as well.
>
> Any comments or concerns, please follow up in the code review or in email
> here.
>

While I may quibble over the 'legacy' tag to FTP, I do agree that ftpd
isn't important enough to risk the security exposure for it (even if we
don't enable it by default). There are several ftpd ports one could use. I
know I'll be installing it on my systems here, but I have some special
needs due to a video camera that uploads snapshots via ftp (and yes, I know
that's not super secure which is why it's on it's own VLAN, jail insulated,
etc).

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Deprecating ftpd in the FreeBSD base system?

[Ed Maste]

FTP is (becoming?) a legacy protocol, and I think it may be time to
remove the ftp server from the FreeBSD base system - with the recent
security advisory for ftpd serving as a reminder.

I've proposed adding a deprecation notice to the man page in
https://reviews.freebsd.org/D26447 to start this off. There are a
number of ftp servers in ports, and if we're going to remove the base
system one we can create a port for it first, as well.

Any comments or concerns, please follow up in the code review or in email here.
___
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: Panic with wifi + usb in latest FreeBSD-current

[Graham Perrin]

On 14/09/2020 06:29, Adrian Chadd wrote:

Yeah, this was also reported in #freebsd-wireless today.


FWIW  
through bisection, recent r365488 is identified as panicking with vboxdrv


___
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: Core Team Office Hours

[Sean Chittenden]

The 23rd.  Sorry for the confusion - there were some scheduling conflicts
that caused this to be pushed back.  Cheers.  -sc

On Wed, Sep 16, 2020 at 1:05 AM Jakob Alvermark  wrote:

> On 2020-09-15 16:12, FreeBSD Core Team Secretary wrote:
> > Based on the continuity of our last CORE Office Hours The FreeBSD CORE
> Team would like to invite you all to a virtual town hall meeting. The
> session is timed at 1800 UTC on 16th September, 2020. See
> https://wiki.freebsd.org/OfficeHours for details on how to join either a
> live stream to watch, or an interactive meeting to participate. A link to
> this agenda (and any updates) will be there as well.
> >
> > We’ll be discussing the following topics and taking general questions at
> the end. We’ll have a moderator who will help call on people in the meeting
> to ask questions (or to offer comments) as well as relay relevant questions
> from IRC.
> >
> > a. Git Transition -- To raise awareness, Ed Maste and Warner Losh will
> be giving a brief presentation about the state of the project’s planned
> transition to git. They can answer a few questions here, but are also
> planning an entire office hours on the git transition (tentatively
> scheduled in two weeks).
> >
> > b. Recruiting for project teams -- When a new core team takes over, it’s
> a good time to assess the needs of each of the teams that we have running
> different aspects of the project, such as administering our machines and
> helping keep FreeBSD secure. One common theme is the need for more help.
> We’ll discuss what teams there are, and make a recruiting pitch and answer
> any questions.
> >
> > c. Core TODO List publishing -- To continue the openness initiative, the
> core team will start publishing out TODO list. This will be in addition to
> the normal meeting minutes and other openness ideas. The new core team
> would love to hear from the community how to improve our communications.
> >
> > d. General Questions -- Time permitting, the core team can answer any
> other questions or concerns the community might have.
> >
> > Thanks! We look forward to meeting you.
> >
> > Regards,
> > Moin (bofh), with core-secretary@ hat on
> >
> The above says 16th, the wiki page says 23rd, which one is it?
>
>
> Thanks,
>
> Jakob
>
> ___
> 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: Wake from sleep kinda broken-ish? (ThinkPad Carbon X1 6th gen)

[Eirik Øverby]

On 9/16/20 11:05 AM, Hans Petter Selasky wrote:


To make sure suspend/resume is not blocked by USB you can try setting:

sysctl hw.usb.no_suspend_wait=1


Thanks, that is useful - it's a separate problem with my USB DAC. Not sure if 
it's relevant to the resume issue, though?

/Eirik
___
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: Wake from sleep kinda broken-ish? (ThinkPad Carbon X1 6th gen)

[Hans Petter Selasky]

On 2020-09-16 10:51, Eirik Øverby wrote:

On 9/16/20 9:07 AM, Li-Wen Hsu wrote:

On Wed, Sep 16, 2020 at 2:30 PM Andriy Gapon  wrote:


On 15/09/2020 23:13, Eirik Øverby wrote:

On 9/15/20 9:50 PM, Andriy Gapon wrote:

On 15/09/2020 22:36, Eirik Øverby wrote:

Now, since I updated from r365358 to r365688, I have not once been able to wake 
from sleep.


Is that the only thing that changed?
Any port / package upgrades?


There have been updates to packages, yes - but it didn't even occur to me that 
these could impact the resume process at such an early stage. Not sure which 
that would be; obviously the drm module has been rebuilt each time I upgraded, 
but I don't have any other kernel modules installed from packages.


Which version of drm module are you using?


13.0-CURRENT FreeBSD 13.0-CURRENT #7 r365688
drm-devel-kmod-5.4.62.g20200905_1

Built against the running kernel sources, of course.



Yes, I specifically had drm modules in mind.


I also use X1C 6th and it was working perfectly after updating BIOS to
1.30 (which I'm currently using) in Sep. 2018 [1]. I don't remember
any suspend/resume failures. But since late 2019, it has exactly the
same symptom as yours. Suspending is fine, but upon resuming, there is
about a 50% probability that the power LDE continues pulsating with
all other LDEs like FnLock and CapsLock are on like the machine is
awake.


Right-o.


To make sure suspend/resume is not blocked by USB you can try setting:

sysctl hw.usb.no_suspend_wait=1

--HPS


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

USB drives & OpenZFS

[Dustin Marquess]

There seems to be a problem with OpenZFS when shutting down a machine
that boots from USB.

My machine has two SD cards in an adapter board that plugs into an
internal USB port on the motherboard.  On these two cards I have the
UEFI loader and a mirror zpool containing just the bare minimum to
boot.  Once the machine boots, it mounts the "big" SAS tank containing
everything else.

This worked perfectly and still works mostly after the OpenZFS merge.
The only problem now is shutting down/rebooting.  if I try to reboot,
it hangs:

Freed UMA keg (rtentry) was not empty (1 items).  Lost 1 pages of memory.
Waiting (max 60 seconds) for system process `vnlru' to stop... done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining... 0 0 0 0 0 0 0 0 done
Waiting (max 60 seconds) for system thread `bufdaemon' to stop... done
Waiting (max 60 seconds) for system thread `bufspacedaemon-0' to stop... done
Waiting (max 60 seconds) for system thread `bufspacedaemon-1' to stop... done
Waiting (max 60 seconds) for system thread `bufspacedaemon-2' to stop... done
Waiting (max 60 seconds) for system thread `bufspacedaemon-3' to stop... done
Waiting (max 60 seconds) for system thread `bufspacedaemon-4' to stop... done
Waiting (max 60 seconds) for system thread `bufspacedaemon-5' to stop... done
Waiting (max 60 seconds) for system thread `bufspacedaemon-6' to stop... done
All buffers synced.
Uptime: 1h52m34s
uhub4: detached
uhub2: detached
uhub3: detached
uhub1: detached
uplcom0: detached
umass0: detached
Solaris: WARNING: Pool 'zroot' has encountered an uncorrectable I/O
failure and has been suspended.

I'm guessing it's because it appears that the USB subsystem shuts down
before the pool itself?  Once this happens I have to reset the machine
via IPMI to get everything to boot back up.

Has anybody else seen this?

Thanks!
-Dustin
___
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: Wake from sleep kinda broken-ish? (ThinkPad Carbon X1 6th gen)

[Eirik Øverby]

On 9/16/20 9:07 AM, Li-Wen Hsu wrote:
> On Wed, Sep 16, 2020 at 2:30 PM Andriy Gapon  wrote:
>>
>> On 15/09/2020 23:13, Eirik Øverby wrote:
>>> On 9/15/20 9:50 PM, Andriy Gapon wrote:
 On 15/09/2020 22:36, Eirik Øverby wrote:
> Now, since I updated from r365358 to r365688, I have not once been able 
> to wake from sleep.

 Is that the only thing that changed?
 Any port / package upgrades?
>>>
>>> There have been updates to packages, yes - but it didn't even occur to me 
>>> that these could impact the resume process at such an early stage. Not sure 
>>> which that would be; obviously the drm module has been rebuilt each time I 
>>> upgraded, but I don't have any other kernel modules installed from packages.
> 
> Which version of drm module are you using?

13.0-CURRENT FreeBSD 13.0-CURRENT #7 r365688
drm-devel-kmod-5.4.62.g20200905_1

Built against the running kernel sources, of course.


>> Yes, I specifically had drm modules in mind.
> 
> I also use X1C 6th and it was working perfectly after updating BIOS to
> 1.30 (which I'm currently using) in Sep. 2018 [1]. I don't remember
> any suspend/resume failures. But since late 2019, it has exactly the
> same symptom as yours. Suspending is fine, but upon resuming, there is
> about a 50% probability that the power LDE continues pulsating with
> all other LDEs like FnLock and CapsLock are on like the machine is
> awake.

Right-o.

/Eirik
___
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: Wake from sleep kinda broken-ish? (ThinkPad Carbon X1 6th gen)

[Andriy Gapon]

On 16/09/2020 10:05, Warner Losh wrote:
> 
> 
> On Wed, Sep 16, 2020 at 12:31 AM Andriy Gapon  > wrote:
> 
> On 15/09/2020 23:13, Eirik Øverby wrote:
> > On 9/15/20 9:50 PM, Andriy Gapon wrote:
> >> On 15/09/2020 22:36, Eirik Øverby wrote:
> >>> Now, since I updated from r365358 to r365688, I have not once been 
> able
> to wake from sleep.
> >>
> >> Is that the only thing that changed?
> >> Any port / package upgrades?
> >
> > There have been updates to packages, yes - but it didn't even occur to 
> me
> that these could impact the resume process at such an early stage. Not 
> sure
> which that would be; obviously the drm module has been rebuilt each time I
> upgraded, but I don't have any other kernel modules installed from 
> packages.
> 
> Yes, I specifically had drm modules in mind.
> 
> 
> I too can report this for my Lenovo Yoga running code as of September 13, but
> with manu's latest drm...  It used to work fine, but my last build on the 
> system
> was from May. Most likely a new panic in that code path, but I've not chased
> down further...

One thing to check is to set debug.acpi.suspend_bounce=1 before suspending.
This will run suspend (and then resume) methods of all drivers just like for a
normal suspend, but will skip the actual ACPI suspend.

-- 
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: Core Team Office Hours

[Jakob Alvermark]

On 2020-09-15 16:12, FreeBSD Core Team Secretary wrote:

Based on the continuity of our last CORE Office Hours The FreeBSD CORE Team 
would like to invite you all to a virtual town hall meeting. The session is 
timed at 1800 UTC on 16th September, 2020. See 
https://wiki.freebsd.org/OfficeHours for details on how to join either a live 
stream to watch, or an interactive meeting to participate. A link to this 
agenda (and any updates) will be there as well.

We’ll be discussing the following topics and taking general questions at the 
end. We’ll have a moderator who will help call on people in the meeting to ask 
questions (or to offer comments) as well as relay relevant questions from IRC.

a. Git Transition -- To raise awareness, Ed Maste and Warner Losh will be 
giving a brief presentation about the state of the project’s planned transition 
to git. They can answer a few questions here, but are also planning an entire 
office hours on the git transition (tentatively scheduled in two weeks).

b. Recruiting for project teams -- When a new core team takes over, it’s a good 
time to assess the needs of each of the teams that we have running different 
aspects of the project, such as administering our machines and helping keep 
FreeBSD secure. One common theme is the need for more help. We’ll discuss what 
teams there are, and make a recruiting pitch and answer any questions.

c. Core TODO List publishing -- To continue the openness initiative, the core 
team will start publishing out TODO list. This will be in addition to the 
normal meeting minutes and other openness ideas. The new core team would love 
to hear from the community how to improve our communications.

d. General Questions -- Time permitting, the core team can answer any other 
questions or concerns the community might have.

Thanks! We look forward to meeting you.

Regards,
Moin (bofh), with core-secretary@ hat on


The above says 16th, the wiki page says 23rd, which one is it?


Thanks,

Jakob

___
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: Wake from sleep kinda broken-ish? (ThinkPad Carbon X1 6th gen)

[Poul-Henning Kamp]

Warner Losh writes:

> I too can report this for my Lenovo Yoga running code as of September 13,
> but with manu's latest drm...  It used to work fine, but my last build on
> the system was from May. Most likely a new panic in that code path, but
> I've not chased down further...

My T480 runs:

FreeBSD 13.0-CURRENT #1 r364533M: Mon Aug 24 00:02:01 UTC 2020

and

drm-devel-kmod-5.3.g20200724

And I have not seen any suspend/resume problems.


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
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: Wake from sleep kinda broken-ish? (ThinkPad Carbon X1 6th gen)

[Li-Wen Hsu]

On Wed, Sep 16, 2020 at 2:30 PM Andriy Gapon  wrote:
>
> On 15/09/2020 23:13, Eirik Øverby wrote:
> > On 9/15/20 9:50 PM, Andriy Gapon wrote:
> >> On 15/09/2020 22:36, Eirik Øverby wrote:
> >>> Now, since I updated from r365358 to r365688, I have not once been able 
> >>> to wake from sleep.
> >>
> >> Is that the only thing that changed?
> >> Any port / package upgrades?
> >
> > There have been updates to packages, yes - but it didn't even occur to me 
> > that these could impact the resume process at such an early stage. Not sure 
> > which that would be; obviously the drm module has been rebuilt each time I 
> > upgraded, but I don't have any other kernel modules installed from packages.

Which version of drm module are you using?

> Yes, I specifically had drm modules in mind.

I also use X1C 6th and it was working perfectly after updating BIOS to
1.30 (which I'm currently using) in Sep. 2018 [1]. I don't remember
any suspend/resume failures. But since late 2019, it has exactly the
same symptom as yours. Suspending is fine, but upon resuming, there is
about a 50% probability that the power LDE continues pulsating with
all other LDEs like FnLock and CapsLock are on like the machine is
awake.

I still doubt if this is related to drm. I have tried to
suspend/resume without drm module loads, all successed, but the number
of the experiments are too small (< 10) so I can't tell if this is the
conclusion.

Currently I'm on r363470 with drm-devel-kmod-5.3.g20200724. While
reporting issue [2], I found that setting hw.i915kms.enable_psr=0 in
/boot/loader.conf helps. Before that it has about a 30% probability of
failing to resume (yes one of the few things getting better in 2020),
after that, I still see some failures, but the failure rate reduces to
about 5~10%.

I haven't upgraded to newer kernel/world and drm-devel-kmod yet.

[1] https://twitter.com/lwhsu/status/1039711710913945601
[2] https://github.com/freebsd/drm-kmod/issues/14

Best,
Li-Wen
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Wake from sleep kinda broken-ish? (ThinkPad Carbon X1 6th gen)

[Warner Losh]

On Wed, Sep 16, 2020 at 12:31 AM Andriy Gapon  wrote:

> On 15/09/2020 23:13, Eirik Øverby wrote:
> > On 9/15/20 9:50 PM, Andriy Gapon wrote:
> >> On 15/09/2020 22:36, Eirik Øverby wrote:
> >>> Now, since I updated from r365358 to r365688, I have not once been
> able to wake from sleep.
> >>
> >> Is that the only thing that changed?
> >> Any port / package upgrades?
> >
> > There have been updates to packages, yes - but it didn't even occur to
> me that these could impact the resume process at such an early stage. Not
> sure which that would be; obviously the drm module has been rebuilt each
> time I upgraded, but I don't have any other kernel modules installed from
> packages.
>
> Yes, I specifically had drm modules in mind.
>

I too can report this for my Lenovo Yoga running code as of September 13,
but with manu's latest drm...  It used to work fine, but my last build on
the system was from May. Most likely a new panic in that code path, but
I've not chased down further...

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Wake from sleep kinda broken-ish? (ThinkPad Carbon X1 6th gen)

[Andriy Gapon]

On 15/09/2020 23:13, Eirik Øverby wrote:
> On 9/15/20 9:50 PM, Andriy Gapon wrote:
>> On 15/09/2020 22:36, Eirik Øverby wrote:
>>> Now, since I updated from r365358 to r365688, I have not once been able to 
>>> wake from sleep.
>>
>> Is that the only thing that changed?
>> Any port / package upgrades?
> 
> There have been updates to packages, yes - but it didn't even occur to me 
> that these could impact the resume process at such an early stage. Not sure 
> which that would be; obviously the drm module has been rebuilt each time I 
> upgraded, but I don't have any other kernel modules installed from packages.

Yes, I specifically had drm modules in mind.


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