Re: Dragonfly Mail Agent (dma) in the base system
Ed Maste writes: > I am interested in determining whether dma is a viable minimal base > system MTA, and if not what gaps remain. It cannot. Ask bapt@ who was the one to import it, and later abandon the idea of making it our default MTA. The reason was that it does not have a default domain setting, so it cannot handle email from cron, periodic etc. where the recipient is just a user name (usually “root”), and the devs were not willing to add that feature. I have email as far back as 2015 on the subject. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: Kernel changes causing AMDGPU / DRM to fail? i2c related?
Am 30.01.22 um 19:23 schrieb Vladimir Kondratyev: > On 30.01.2022 00:25, Stefan Esser wrote: >> After rebooting with freshly built world, kernel and the amdgpu driver >> my console stopped working. It goes blank and the display goes into a >> power save mode, as soon as the amdgpu driver is loaded. >> >> The GPU (a Radeon R7 250E) is correctly detected as before, but there >> is an error message "drmn0: [drm] Cannot find any crtc or sizes". >> [...] >> [drm] AMDGPU Display Connectors >> [drm] Connector 0: >> [drm] DP-1 >> [drm] HPD4 >> [drm] DDC: 0x1950 0x1950 0x1951 0x1951 0x1952 0x1952 0x1953 0x1953 >> [drm] Encoders: >> [drm] DFP1: INTERNAL_UNIPHY2 >> [drm] Connector 1: >> [drm] HDMI-A-1 >> [drm] HPD1 >> [drm] DDC: 0x195c 0x195c 0x195d 0x195d 0x195e 0x195e 0x195f 0x195f >> [drm] Encoders: >> [drm] DFP2: INTERNAL_UNIPHY2 >> [drm] Connector 2: >> [drm] DVI-I-1 >> [drm] HPD2 >> [drm] DDC: 0x1958 0x1958 0x1959 0x1959 0x195a 0x195a 0x195b 0x195b >> [drm] Encoders: >> [drm] DFP3: INTERNAL_UNIPHY >> [drm] CRT1: INTERNAL_KLDSCP_DAC1 >> drmn0: [drm] Cannot find any crtc or sizes >> drmn0: [drm] Cannot find any crtc or sizes >> drmn0: [drm] Cannot find any crtc or sizes >> [drm] Initialized amdgpu 3.37.0 20150101 for drmn0 on minor 0 >> >> A successful driver attach from a reboot a few days ago had ended in: >> >> [drm] CRT1: INTERNAL_KLDSCP_DAC1 >> [drm] fb mappable at 0xE0503000 >> [drm] vram apper at 0xE000 >> [drm] size 33177600 >> [drm] fb depth is 24 >> [drm] pitch is 15360 >> [drm] Initialized amdgpu 3.36.0 20150101 for drmn0 on minor 0 >> >> Regards, STefan > > drm-kmod commit 534aa199c10d forced it to use i2c from base. Hi Vladimir, thank you for the information! I'm using drm-devel-kmod, and in fact found that 5.5.19.g20211230 works, while 5.7.19.g20220126 (committed as 0c38674b389ad on 2022-01-26) causes the failure. > You may try to checkout previous revision (444dc58f0247) to find out if > in-base > i2c is guilty or not. Assuming that the same change to use the system i2c code has been in the latest commit to the drm-devel-kmod port, this should be proven, now. ;-) These is the list of in-kernel i2c modules on my system (a Ryzen 9 5950 on an ASUS mainboard with B550 chip-set): $ kldstat -v | grep iic 68 iicsmb/smbus 67 iicbus/iicsmb 66 iichb/iicbus 65 iicbb/iicbus 64 iicbus/iic 63 iicbus/ic 213 lkpi_iicbb/iicbb 212 lkpi_iic/lkpi_iicbb 211 lkpi_iic/iicbus 210 drmn/lkpi_iic 56 iichid/hidbus Can I help debug this issue? I could re-install the latest version and boot with hw.dri.drm_debug or dev.drm.drm_debug set? Or are there other settings to get a debug log from the i2c side? Regards, STefan PS: I'm keeping the CC to current@, since this might be an issue in the i2c kernel code ... OpenPGP_signature Description: OpenPGP digital signature
Re: Kernel changes causing AMDGPU / DRM to fail? i2c related?
On 30.01.2022 00:25, Stefan Esser wrote: After rebooting with freshly built world, kernel and the amdgpu driver my console stopped working. It goes blank and the display goes into a power save mode, as soon as the amdgpu driver is loaded. The GPU (a Radeon R7 250E) is correctly detected as before, but there is an error message "drmn0: [drm] Cannot find any crtc or sizes". I'm asking here and not on the ports list, since the AMDGPU driver has not been updated for half a year. But to be sure that there is no mismatch between kernel and user land, I have rebuilt all X11 server and library ports. There have been changes affecting the i2c driver, IIRC, and the error message seems to point at an issue obtaining information from the LCD display. The output of "grep drm /var/run/dmesg.boot" follows: [drm] amdgpu kernel modesetting enabled. drmn0: on vgapci0 vgapci0: child drmn0 requested pci_enable_io vgapci0: child drmn0 requested pci_enable_io [drm] initializing kernel modesetting (VERDE 0x1002:0x683F 0x174B:0xA001 0x00). [drm] register mmio base: 0xFCE0 [drm] register mmio size: 262144 [drm] add ip block number 0 [drm] add ip block number 1 [drm] add ip block number 2 [drm] add ip block number 3 [drm] add ip block number 4 [drm] add ip block number 5 [drm] add ip block number 6 [drm] BIOS signature incorrect 0 0 [drm] vm size is 512 GB, 2 levels, block size is 10-bit, fragment size is 9-bit drmn0: successfully loaded firmware image 'amdgpu/verde_mc.bin' drmn0: VRAM: 1024M 0x00F4 - 0x00F43FFF (1024M used) drmn0: GART: 1024M 0x00FF - 0x00FF3FFF [drm] Detected VRAM RAM=1024M, BAR=256M [drm] RAM width 128bits GDDR5 [drm] amdgpu: 1024M of VRAM memory ready [drm] amdgpu: 3072M of GTT memory ready. [drm] GART: num cpu pages 262144, num gpu pages 262144 drmn0: PCIE GART of 1024M enabled (table at 0x00F40050). [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). drmn0: successfully loaded firmware image 'amdgpu/verde_pfp.bin' drmn0: successfully loaded firmware image 'amdgpu/verde_me.bin' drmn0: successfully loaded firmware image 'amdgpu/verde_ce.bin' drmn0: successfully loaded firmware image 'amdgpu/verde_rlc.bin' drmn0: successfully loaded firmware image 'amdgpu/verde_smc.bin' [drm] Internal thermal controller without fan control [drm] amdgpu: dpm initialized [drm] Connector DP-1: get mode from tunables: [drm] - kern.vt.fb.modes.DP-1 [drm] - kern.vt.fb.default_mode [drm] Connector HDMI-A-1: get mode from tunables: [drm] - kern.vt.fb.modes.HDMI-A-1 [drm] - kern.vt.fb.default_mode [drm] Connector DVI-I-1: get mode from tunables: [drm] - kern.vt.fb.modes.DVI-I-1 [drm] - kern.vt.fb.default_mode [drm] AMDGPU Display Connectors [drm] Connector 0: [drm] DP-1 [drm] HPD4 [drm] DDC: 0x1950 0x1950 0x1951 0x1951 0x1952 0x1952 0x1953 0x1953 [drm] Encoders: [drm] DFP1: INTERNAL_UNIPHY2 [drm] Connector 1: [drm] HDMI-A-1 [drm] HPD1 [drm] DDC: 0x195c 0x195c 0x195d 0x195d 0x195e 0x195e 0x195f 0x195f [drm] Encoders: [drm] DFP2: INTERNAL_UNIPHY2 [drm] Connector 2: [drm] DVI-I-1 [drm] HPD2 [drm] DDC: 0x1958 0x1958 0x1959 0x1959 0x195a 0x195a 0x195b 0x195b [drm] Encoders: [drm] DFP3: INTERNAL_UNIPHY [drm] CRT1: INTERNAL_KLDSCP_DAC1 drmn0: [drm] Cannot find any crtc or sizes drmn0: [drm] Cannot find any crtc or sizes drmn0: [drm] Cannot find any crtc or sizes [drm] Initialized amdgpu 3.37.0 20150101 for drmn0 on minor 0 A successful driver attach from a reboot a few days ago had ended in: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] fb mappable at 0xE0503000 [drm] vram apper at 0xE000 [drm] size 33177600 [drm] fb depth is 24 [drm]pitch is 15360 [drm] Initialized amdgpu 3.36.0 20150101 for drmn0 on minor 0 Regards, STefan drm-kmod commit 534aa199c10d forced it to use i2c from base. You may try to checkout previous revision (444dc58f0247) to find out if in-base i2c is guilty or not. -- WBR Vladimir Kondratyev
Re: HEADS-UP: PIE enabled by default on stable/13
Hi, pon., 24 sty 2022 o 20:48 Marek Zarychta napisał(a): > > Hello Marcin > W dniu 24.01.2022 o 19:43, Marcin Wojtas pisze: > > Hi Marek, > > > > pon., 24 sty 2022 o 08:17 Marek Zarychta > > napisał(a): > >> > >> W dniu 24.01.2022 o 07:42, Marcin Wojtas pisze: > >>> +freebsd-stable@ > >>> > >>> niedz., 23 sty 2022 o 11:36 Marcin Wojtas napisał(a): > > Hi, > > As of 396e9f259d962 the base system binaries are now built as > position-independent executable (PIE) by default, for 64-bit > architectures. Thanks to that enabling ASLR can be done simply > by sysctls knobs when booting the kernel. > > If you track stable/13 and normally build WITHOUT_CLEAN you'll need to > do one initial clean build -- either run `make cleanworld` or set > WITH_CLEAN=yes. > > The change is a pure MFC of the changes integrated to -CURRENT early > 2021 and no issues are expected, but in case any problems are observed, > please issue a PR and/or let me know in this thread. > > Best regards, > Marcin > >>> > >> > >> Thanks for enabling this. If I understand it correctly we got some > >> improvements mentioned here[1] and it doesn't imply that ASLR has to be > >> enabled, especially kern.elf64.aslr.pie_enable can be still set to 0 ? > >> > > > > Currently it still remains opt-in on stable/13 and is disabled by default. > > > > Best regards, > > Marcin > > Thanks for the answer. I am not willing to turn ASLR on at this point, > but rather asking if my world, already built with PIE, will bring any > other enhancements or improvements? > If your world is already built with PIE, the MFC'ed patches should make no difference at all. Best regards, Marcin > > > >> > >> [1] https://www.mail-archive.com/freebsd-current@freebsd.org/msg183605.html > >> > > > With kind regards, > > -- > Marek Zarychta
Re: Dragonfly Mail Agent (dma) in the base system
Am 2022-01-30 um 15:01 schrieb michael.osi...@siemens.com: Requirements for a simplistic MTA with a relay host: * Support TLS or STARTTLS through OpenSSL in base * Verify server's certificate chain against default certstore (/etc/ssl/certs) and log success/failure, e.g, sendmail does this after config * Properly rewrite FROM for local users user@localhost or even <> when delivered with sendmail executable * Accept messages on localhost:25 or a configurable loopback address in general (e.g., multihomed with cloned interface and jails) for those applications which only support SMTP (e.g., Java Mail or other programming libraries) Another feature I have forgot: * .forward support. All mails received on a Unix account shall be redirected to the user's email address. Michael
Re: Dragonfly Mail Agent (dma) in the base system
Hi Ed, thanks for raising, this is just on time for us. I'd like to describe what both cover and not cover and I would expect from a minimal MTA. I am on 12-STABLE/12.3-RELEASE. We solely use sendmail with relay via sendmail invocation or SMTP on localhost:25. Minimal configuration for scripts and applications running on hosts and jails. Our current corporate messaging service is being phased out for a new one which requires authentication via LOGIN or PLAIN and mandatory STARTTLS, previous was anonymous and unencrypted. Sendmail: The biggest problem is that authentication strictly requires Cyrus SASL, even for stupid ones like PLAIN/LOGIN, accourding to the handbook you must recompile sendmail from base with Cyrus SASL from ports to make this possible. A showstopper actually, for two reasons: 1. I don't like mixing base and ports, it just creates a messy system. 2. While this may work with hosts, when you have jails running off a RELEASE in Bastille this obviously will not work. Not going to work with sendmail easily. DMA: Disclaimer: I haven't tried, but read documentation and source code. Although it supports TLS, I don't see any of these [1], I fail to see how it verifies the peer. I have never seen something to provide the server's fingerprint to verification. It very much feels like an SSH-like approach. It does not listen, as documented, on localhost, so applications supporting SMTP only will need extra configuration to reach out to the relay host directly. Central config at MTA side not possible anymore. Although, I don't need certificate-based authentication against the relay and DMA supports it, it does not support of using a passphrase for the certificate key file like HTTPd supports through mod_ssl. Should be a no-brainer these days. Requirements for a simplistic MTA with a relay host: * Support TLS or STARTTLS through OpenSSL in base * Verify server's certificate chain against default certstore (/etc/ssl/certs) and log success/failure, e.g, sendmail does this after config * Properly rewrite FROM for local users user@localhost or even <> when delivered with sendmail executable * Accept messages on localhost:25 or a configurable loopback address in general (e.g., multihomed with cloned interface and jails) for those applications which only support SMTP (e.g., Java Mail or other programming libraries) The issues with certificates and OpenSSL in the base system I have already extensively dicussed with kevans@ [2]. I hope this can be put into consideration. Regards, Michael [1] https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_default_verify_paths.html [2] https://reviews.freebsd.org/D31487#710650
