Re: Kernel changes causing AMDGPU / DRM to fail? i2c related?
On Mon, 31 Jan 2022 17:02:30 +0100 Tijl Coosemans wrote: > On Sun, 30 Jan 2022 21:23:49 +0300 Vladimir Kondratyev > wrote: >> 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. >> >> 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. > > I found that since base dbc920bd9a9b (linuxkpi interval_tree) > linuxkpi.ko now exports some rb_* functions (from rbtree.h). These are > declared static inline but the compiler may decide not to inline them. > These functions conflict with the ones in linuxkpi_gplv2.ko from > drm-kmod, because both implementations use a different order for the > fields in struct rb_node. Here's a list of functions that linuxkpi.ko and linuxkpi_gplv2.ko have in common in my case. Some are probably ok. device_register i2c_transfer linux_compat_init lkpi_arch_phys_wc_add lkpi_arch_phys_wc_del rb_erase_cached rb_insert_color_cached sysctl_handle_attr
Re: Kernel changes causing AMDGPU / DRM to fail? i2c related?
On Sun, 30 Jan 2022 21:23:49 +0300 Vladimir Kondratyev wrote: > 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. > > 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. I found that since base dbc920bd9a9b (linuxkpi interval_tree) linuxkpi.ko now exports some rb_* functions (from rbtree.h). These are declared static inline but the compiler may decide not to inline them. These functions conflict with the ones in linuxkpi_gplv2.ko from drm-kmod, because both implementations use a different order for the fields in struct rb_node.
Re: i386 kernel modules unusable due to .plt sections
On Fri, 27 Aug 2021 11:32:43 -0400 Mark Johnston
wrote:
> On Fri, Aug 27, 2021 at 05:29:34PM +0200, Tijl Coosemans wrote:
>> On Fri, 27 Aug 2021 17:24:58 +0300 Konstantin Belousov
>> wrote:
>>> On Fri, Aug 27, 2021 at 03:41:30PM +0200, Tijl Coosemans wrote:
>>>> I use devel/llvm* to build base and just switched to llvm12. It seems
>>>> that on i386 clang12 uses R_386_PLT32 relocations for some calls to at
>>>> least memset, memcpy and __stack_chk_fail (clang11 uses R_386_PC32).
>>>> These are converted to R_386_JMP_SLOT relocations by the linker which
>>>> aren't supported by the kernel, e.g. loading linux.ko gives "kldload:
>>>> unexpected relocation type" from sys/i386/i386/elf_machdep.c. The PLT
>>>> entries also depend on a base pointer in %ebx but kernel modules aren't
>>>> compiled with -fPIC, so this can't work and I suspect this is a
>>>> regression in clang12.
>>>>
>>>> The following code shows the difference between clang11 and clang12:
>>>>
>>>>
>>>> #include
>>>>
>>>> void *
>>>> test_memset(void *p, int c, size_t len) {
>>>> return (memset(p, c, len));
>>>> }
>>>>
>>>> void *
>>>> test_memcpy(void *dst, const void *src, size_t len) {
>>>> return (memcpy(dst, src, len));
>>>> }
>>>>
>>>> void *
>>>> test_memmove(void *dst, const void *src, size_t len) {
>>>> return (memmove(dst, src, len));
>>>> }
>>>>
>>>>
>>>> Output of "readelf -r test.o" when compiled with "clang12 -c test.c -m32":
>>>> r_offset r_info r_type st_value st_name
>>>> 002c 0504 R_386_PLT32 memset
>>>> 0067 0304 R_386_PLT32 memcpy
>>>> 00a7 0402 R_386_PC32 memmove
>>>>
>>>> With clang11:
>>>> r_offset r_info r_type st_value st_name
>>>> 0036 0502 R_386_PC32 memset
>>>> 0083 0302 R_386_PC32 memcpy
>>>> 00d2 0402 R_386_PC32 memmove
>>>
>>> Are you asking (for somebody) to add R_386_JMP_SLOT to i386/elf_machdep.c?
>>> Like this, not even built.
>>>
>>> diff --git a/sys/i386/i386/elf_machdep.c b/sys/i386/i386/elf_machdep.c
>>> index 3754b36d9e33..a26a4189e0ee 100644
>>> --- a/sys/i386/i386/elf_machdep.c
>>> +++ b/sys/i386/i386/elf_machdep.c
>>> @@ -245,6 +245,7 @@ elf_reloc_internal(linker_file_t lf, Elf_Addr
>>> relocbase, const void *data,
>>> break;
>>>
>>> case R_386_GLOB_DAT:/* S */
>>> + case R_386_JMP_SLOT:
>>> error = lookup(lf, symidx, 1, &addr);
>>> if (error != 0)
>>> return (-1);
>>
>> No, I've tried that. It handles the relocation but callers still don't
>> setup %ebx as PIC register. I'm looking for someone to confirm it's a
>> compiler bug and not a missing flag or something. I tried -fno-plt and
>> that has no effect.
>
> Does disabling -zifunc-noplt fix the problem? I believe it's set by
> default for i386.
Removing it from sys/conf/kern.pre.mk didn't help.
Re: i386 kernel modules unusable due to .plt sections
On Fri, 27 Aug 2021 17:24:58 +0300 Konstantin Belousov
wrote:
> On Fri, Aug 27, 2021 at 03:41:30PM +0200, Tijl Coosemans wrote:
>> I use devel/llvm* to build base and just switched to llvm12. It seems
>> that on i386 clang12 uses R_386_PLT32 relocations for some calls to at
>> least memset, memcpy and __stack_chk_fail (clang11 uses R_386_PC32).
>> These are converted to R_386_JMP_SLOT relocations by the linker which
>> aren't supported by the kernel, e.g. loading linux.ko gives "kldload:
>> unexpected relocation type" from sys/i386/i386/elf_machdep.c. The PLT
>> entries also depend on a base pointer in %ebx but kernel modules aren't
>> compiled with -fPIC, so this can't work and I suspect this is a
>> regression in clang12.
>>
>> The following code shows the difference between clang11 and clang12:
>>
>>
>> #include
>>
>> void *
>> test_memset(void *p, int c, size_t len) {
>> return (memset(p, c, len));
>> }
>>
>> void *
>> test_memcpy(void *dst, const void *src, size_t len) {
>> return (memcpy(dst, src, len));
>> }
>>
>> void *
>> test_memmove(void *dst, const void *src, size_t len) {
>> return (memmove(dst, src, len));
>> }
>>
>>
>> Output of "readelf -r test.o" when compiled with "clang12 -c test.c -m32":
>> r_offset r_info r_type st_value st_name
>> 002c 0504 R_386_PLT32 memset
>> 0067 0304 R_386_PLT32 memcpy
>> 00a7 0402 R_386_PC32 memmove
>>
>> With clang11:
>> r_offset r_info r_type st_value st_name
>> 0036 0502 R_386_PC32 memset
>> 0083 0302 R_386_PC32 memcpy
>> 00d2 0402 R_386_PC32 memmove
>
> Are you asking (for somebody) to add R_386_JMP_SLOT to i386/elf_machdep.c?
> Like this, not even built.
>
> diff --git a/sys/i386/i386/elf_machdep.c b/sys/i386/i386/elf_machdep.c
> index 3754b36d9e33..a26a4189e0ee 100644
> --- a/sys/i386/i386/elf_machdep.c
> +++ b/sys/i386/i386/elf_machdep.c
> @@ -245,6 +245,7 @@ elf_reloc_internal(linker_file_t lf, Elf_Addr relocbase,
> const void *data,
> break;
>
> case R_386_GLOB_DAT:/* S */
> + case R_386_JMP_SLOT:
> error = lookup(lf, symidx, 1, &addr);
> if (error != 0)
> return (-1);
No, I've tried that. It handles the relocation but callers still don't
setup %ebx as PIC register. I'm looking for someone to confirm it's a
compiler bug and not a missing flag or something. I tried -fno-plt and
that has no effect.
i386 kernel modules unusable due to .plt sections
Hi,
I use devel/llvm* to build base and just switched to llvm12. It seems
that on i386 clang12 uses R_386_PLT32 relocations for some calls to at
least memset, memcpy and __stack_chk_fail (clang11 uses R_386_PC32).
These are converted to R_386_JMP_SLOT relocations by the linker which
aren't supported by the kernel, e.g. loading linux.ko gives "kldload:
unexpected relocation type" from sys/i386/i386/elf_machdep.c. The PLT
entries also depend on a base pointer in %ebx but kernel modules aren't
compiled with -fPIC, so this can't work and I suspect this is a
regression in clang12.
The following code shows the difference between clang11 and clang12:
#include
void *
test_memset(void *p, int c, size_t len) {
return (memset(p, c, len));
}
void *
test_memcpy(void *dst, const void *src, size_t len) {
return (memcpy(dst, src, len));
}
void *
test_memmove(void *dst, const void *src, size_t len) {
return (memmove(dst, src, len));
}
Output of "readelf -r test.o" when compiled with "clang12 -c test.c -m32":
r_offset r_info r_type st_value st_name
002c 0504 R_386_PLT32 memset
0067 0304 R_386_PLT32 memcpy
00a7 0402 R_386_PC32 memmove
With clang11:
r_offset r_info r_type st_value st_name
0036 0502 R_386_PC32 memset
0083 0302 R_386_PC32 memcpy
00d2 0402 R_386_PC32 memmove
Re: loading drm crashes system
On Mon, 25 Jan 2021 22:21:16 -0500 Robert Huff wrote: > Niclas Zeising asks: > > > Which version of drm-current-kmod? > > 5.4.62.g20210118 > > > Can you try to remove it and build it directly from an updated ports > > tree, without using PORTS_MODULES=, and see if that helps? > > It does not. > > > > The GPU is a Radeon HD 3300, and at one point this used to > > work. > > > > When did it stop working? > > September ... I _think_. > After the switch from sc to vt+drm, things worked for a while > ... then they didn't for several months ... then - September??? - they > worked for about two weeks ... then they didn't again. September 10 is when drm-current-kmod was updated from 4.16 to 5.4: https://svnweb.freebsd.org/ports/head/graphics/drm-current-kmod/Makefile There haven't been that many updates since then so you could test ports r548210 with base system from the same date. If that works try r548601, r551266 and r554720. ___ 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: loading drm crashes system
On Tue, 26 Jan 2021 13:42:45 +0100 Emmanuel Vadot wrote: > On Tue, 26 Jan 2021 07:02:11 + > Alexey Dokuchaev wrote: >> On Mon, Jan 25, 2021 at 10:21:16PM -0500, Robert Huff wrote: >>> Niclas Zeising asks: When did it stop working? >>> >>> September ... I _think_. >> >> Yeah, that sounds about right. >> >> There are known issues with Radeon cards, they were quite well supported >> a year ago, then something got broken. I've promised to bisect this and >> find the cause, but there were several syscall-related changes in -CURRENT >> though the course of the last year, so bisecting just the kernel is not >> enough (machine won't get to login prompt if the userland does not match), >> which cripples the process. >> >> I still intend to take this quest, just not sure when. :( > > So back in November I applied a few commits from tijl@ related to > radeon and i386 (added to cc) : > https://github.com/freebsd/drm-kmod/commits/5.4-lts?author=t...@coosemans.org > > For me this fixed radeon so that gives some timeline if someone with > non working hardware wants to bisect. > I know that bisecting drm-kmod is somewhat hard as you always need > matching kernel code when we update it to use some new functionality in > base linuxkpi but there is nothing that I can do about it. > It might work and be quicker to only bisect the kernel with a > stable/12 userland (no need to recompile) so I would start by testing a > kernel from early november and same date for drm-kmod. > > Tijl since you also reported a build failure a few days/weeks ago for > radeon can you report if your radeon card works ? (And which one it is). My card works (14.0-CURRENT from last Sunday) but it is an old radeon 9700 from 2004 so it doesn't have any fancy modern features and uses only a small part of the radeon driver. ___ 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: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On Sat, 23 Feb 2019 17:28:51 -0800 Steve Kargl wrote: > On Sat, Feb 23, 2019 at 12:03:58PM -0700, Warner Losh wrote: >> On Sat, Feb 23, 2019 at 10:57 AM Steve Kargl >> wrote: >>> Supposely, the laptop only has 4 GB of memory. Not sure how >>> it finds memory above 4 GB. >> >> Some older chipsets had a 'hole' in memory that they mapped the PCI bus >> into and then remapped RAM in that range up above the 4GB boundary. That's >> how it can find memory above 4GB when you have only 4GB of RAM. I hit it >> with the PC Card stuff I did back in the day since it broke certain >> heuristics I had in the code that turned out to be unwise for many reasons >> (not just this one). I don't recall all the details, since it's been so >> long ago. >> >> So I think kib@ is right when he highlights >>> +0x0001 - 0x00011ffe7fff, 536772608 bytes (131048 pages) >> >> as the memory, since this is indeed above the 4GB limit. It's about 128k >> of 4k pages (just shy of the 131072 I'd expect), which is a surprisingly >> round number. Also one that's easy to implement in hardware. So it >> certainly "smells" the same... >> >> That's why I agree with others that hw.above4g_allow=0 is worth a shot, for >> at least diagnostic purposes. This memory wasn't used before and if it's >> used now by the drm drivers, and those aren't PAE safe (meaning they cope >> with allocations beyond 4GB), then that's quite useful to know. Or maybe >> it's a different driver hating things and stomping on video memory due to >> wrap around. > > Thanks for the explanation. Here's an update. TL;DR: xorg is > up and running; drm-legacy-kmod seems to be unsafe/unaware of > PAE. > > Build world/kernel, drm-legacy-kmod, minimum needed ports for xorg. > Kernel is unmodified GENERIC. > > Reboot without setting anything in /boot/loader.conf > > % sysctl -a | grep above > % sysctl -a | grep pae > vm.pmap.pae_mode: 1 > % kldload /boot/modules/i915kms.ko > > Black screen of death. Did not even get to running xinit. > > Hard reset to single user mode. > > # fsck -y > # mount -a > # vi /boot/loader.conf. > (Add hw.above4g_allow=0) > # sync > # shutdown -r now > > % sysctl -a | grep above > % sysctl -a | grep pae > vm.pmap.pae_mode: 1 > % cat /boot/loader.conf > if_ath_load="YES" > if_ath_pci_load="YES" > cpuctl_load="YES" > hw.above4g_allow=0 > % kldload /boot/modules/i915kms.ko > > Switch to vt3, login as normal user. > > % startx -- -depth 24 >& ~/tmp/.x.out > > Xorg is up and running. Not sure why my first attempt at using > hw.above4g_allow=0 did not work. Perhaps, mismatch between the xorg > bits and kernel/world bits. > > % sysctl -a | grep mem > vm.lowmem_period: 10 > vm.kmem_map_free: 1669365760 > vm.kmem_map_size: 41910272 > vm.kmem_size_scale: 1 > vm.kmem_size_max: 1711276032 > vm.kmem_size_min: 12582912 > vm.kmem_zmax: 65536 > vm.kmem_size: 1711276032 > hw.physmem: 3715489792 > hw.usermem: 3592175616 > hw.realmem: 4294963200 > > % dmesg | grep memory > real memory = 4294967296 (4096 MB) > avail memory = 3637673984 (3469 MB) > agp0: aperture size is 256M, detected 7676k stolen memory > > The pre-r343567 dmesg has > > real memory = 4294967296 (4096 MB) > avail memory = 3639914496 (3471 MB) > > I can live with 2 MB loss. > > Conclusion, drm-legacy-kmod is not PAE safe/aware. > > Probably want to put something in /usr/src about possible > problems with new pmap.h on i386 FreeBSD. Now it would be interesting to do the same tests with drm-current-kmod. ___ 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: What is evdev and autoloading?
On Tue, 19 Feb 2019 11:18:07 -0800 Steve Kargl wrote: > On Tue, Feb 19, 2019 at 06:59:26PM +, Johannes Lundberg wrote: >> On 2/19/19 5:35 PM, Steve Kargl wrote: >>> My Dell Latitude D530 running i386 freebsd, which used the >>> i915kms.ko now locks up solid with drm-legacy-kmod. The PAE vs >>> non-PAE i386/conf/pmap.h merger in r342567 broke drm-legacy-kmod. >>> It seems that Niclas has provided a patch that fixes the building >>> of drm-legacy-kmod. >>> >>> Doing a bisection on /usr/src commits is fairly slow as it >>> takes a day to build world/kernel and the minimum set of ports >>> need to fire up Xorg. r343543 and earlier appear to work fine >>> with drm-legacy-kmod. >> >> So it's not only a build error, it's also a runtime bug that would have >> happened even with drm2 in base? Hmm.. > > It appears that that's the case. The likely candidates > are r343564(+65 for missing header), r343566, and r343567. That last commit added hw.above4g_allow tunable. Does it help if you set this to 0 in /boot/loader.conf? Also, it's worth trying drm-current-kmod if you haven't done so recently. If you did try already what were the problems? ___ 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: CUPS: [Client 1] Unable to encrypt connection: An illegal parameter has been received.
On Mon, 21 Jan 2019 21:00:39 +0100 "O. Hartmann" wrote: > Am Wed, 16 Jan 2019 18:33:36 +0100 > Tijl Coosemans schrieb: >> On Wed, 16 Jan 2019 15:23:40 +0100 "O. Hartmann" >> wrote: >>> We have an experimental IPV6 network and within this network, FreebSD >>> CURRENT >>> (r343087) is acting as a CUPS print server, while a bunch FreeBSD 12-STABLE >>> boxes are CUPS clients. >>> >>> The setup, so far, worked with IPv4. Introducing IPv6 addresses on both >>> server >>> and host results in the error >>> >>> [Client 1] Unable to encrypt connection: An illegal parameter has been >>> received. >>> >>> In file cups/client.conf we address the appropriate printer via >>> >>> ipps://xxx.xxx.xxx.xxx/printers/printer_name (IPv4 of the CUPS server host) >>> >>> This works fine. >>> >>> But ipps://[::::]/printers/printer_name (IPv6 of the CUPS >>> server host) doesn't work and results in the error on the server as shown >>> above. >>> >>> I fiddled also around with the SSLOption parameter in client.conf and >>> parallel, >>> to match requiremets, in cups/cupsd.conf of the server host - with no >>> effect. >>> >>> On the server side, it seems that all the documents I could pick up from >>> cups.org or Apple do not specify any IPv6 address in an "Allow from" >>> statement: >>> everything seems to be stuck with IPv4. While the cupsd.conf SSLListen >>> option >>> is for IPv6 >>> >>> SSLListen [fd01:dead:beef::affe]:631 >>> >>> which works, I get an error when trying to put anything IPv6-similar with >>> the >>> convention with the brackets "[" and "]" in a "Allow from" option in the >>> sections where I need to restrict access. An IPv6 without "[" and "]" seems >>> to >>> be accepted - but when coemmnting out ANY IPv4 address and leaving only >>> IPV6 in >>> the "Allow from " statement, no remote connection is allowed. >>> >>> This drives me nuts. Since the aim will be to have a printing facility >>> within a >>> IPv6 only network, I feel a bit lost. >>> >>> Does anyone have had similar problems? >> >> What you're supposed to do instead is run a cupsd on the client and add >> the print server as a network printer (using your ipps URI). When you >> have to choose the make of the printer choose Raw so you don't need a >> PPD and cupsd will forward the job to the server without doing any >> filtering. You can set this up on one client and then copy the cups >> configuration in /usr/local/etc/cups to the other clients. Running a >> local cupsd allows clients to queue print jobs when the print server is >> down. > > I had those settings on the client system, too: reference printer is > ipps://host.name/printers/print_queue_name, but not with "RAW" filter. I > changed that. > > While I'm able to print CUPS testpages via the web interface on the CUPS > server system > itself, I still receive > > [Client 1] Unable to encrypt connection: An illegal parameter has been > received. > > in the log file on the CUPS server, when the satellite/client system tries to > connect to > the CUPS print queue. I've just committed WITH_DEBUG support to print/cups (r490938) so please update your ports tree and rebuild and reinstall cups on the print server using "make WITH_DEBUG=yes install". Then run cupsd like this: env CUPS_DEBUG_LOG="/tmp/cups.debug" CUPS_DEBUG_LEVEL="9" cupsd Then try to connect from the client. /tmp/cups.debug should now contain "An illegal parameter has been received" but with more context. ___ 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: CUPS: [Client 1] Unable to encrypt connection: An illegal parameter has been received.
On Wed, 16 Jan 2019 15:23:40 +0100 "O. Hartmann" wrote: > We have an experimental IPV6 network and within this network, FreebSD CURRENT > (r343087) is acting as a CUPS print server, while a bunch FreeBSD 12-STABLE > boxes are CUPS clients. > > The setup, so far, worked with IPv4. Introducing IPv6 addresses on both server > and host results in the error > > [Client 1] Unable to encrypt connection: An illegal parameter has been > received. > > In file cups/client.conf we address the appropriate printer via > > ipps://xxx.xxx.xxx.xxx/printers/printer_name (IPv4 of the CUPS server host) > > This works fine. > > But ipps://[::::]/printers/printer_name (IPv6 of the CUPS > server host) doesn't work and results in the error on the server as shown > above. > > I fiddled also around with the SSLOption parameter in client.conf and > parallel, > to match requiremets, in cups/cupsd.conf of the server host - with no effect. > > On the server side, it seems that all the documents I could pick up from > cups.org or Apple do not specify any IPv6 address in an "Allow from" > statement: > everything seems to be stuck with IPv4. While the cupsd.conf SSLListen option > is for IPv6 > > SSLListen [fd01:dead:beef::affe]:631 > > which works, I get an error when trying to put anything IPv6-similar with the > convention with the brackets "[" and "]" in a "Allow from" option in the > sections where I need to restrict access. An IPv6 without "[" and "]" seems to > be accepted - but when coemmnting out ANY IPv4 address and leaving only IPV6 > in > the "Allow from " statement, no remote connection is allowed. > > This drives me nuts. Since the aim will be to have a printing facility within > a > IPv6 only network, I feel a bit lost. > > Does anyone have had similar problems? cupsd.conf(5) does mention "Allow [ipv6-address]" in the section: DIRECTIVES VALID WITHIN LOCATION AND LIMIT SECTIONS With client.conf you can configure libcups so it talks to a remote CUPS server instead of the local one. This has been deprecated for years so I suspect there hasn't been any development on it and that it simply doesn't support IPv6. What you're supposed to do instead is run a cupsd on the client and add the print server as a network printer (using your ipps URI). When you have to choose the make of the printer choose Raw so you don't need a PPD and cupsd will forward the job to the server without doing any filtering. You can set this up on one client and then copy the cups configuration in /usr/local/etc/cups to the other clients. Running a local cupsd allows clients to queue print jobs when the print server is down. Alternatively you can let the print server announce the printer via Bonjour/Avahi (Browsing on in cupsd.conf) and run cups-browsed from print/cups-filters on the clients which will then detect the print server and add a raw print queue automatically. This can be convenient for laptops that move between networks. ___ 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: maxswzone NOT used correctly and defaults incorrect?
On Sat, 24 Nov 2018 01:04:29 -0800 John-Mark Gurney wrote: > I have an BeagleBoard Black. I'm running a recent snapshot: > FreeBSD generic 13.0-CURRENT FreeBSD 13.0-CURRENT r340239 GENERIC arm > > aka: > FreeBSD-13.0-CURRENT-arm-armv7-BEAGLEBONE-20181107-r340239.img.xz > > It has 512MB of memory on board. I created a 4GB swap file. According > to loader(8), this should be the default capable: >in bytes of KVA space. If no value is provided, the system >allocates enough memory to handle an amount of swap that >corresponds to eight times the amount of physical memory >present in the system. > > avail memory = 505909248 (482 MB) > > but I get this: > warning: total configured swap (1048576 pages) exceeds maximum recommended > amount (248160 pages). > warning: increase kern.maxswzone or reduce amount of swap. > > So, this appears that it's only 2x amount of memory, NOT 8x like the > documentation says. > > When running make in sbin/ggate/ggated, make consumes a large amount > of memory. Before the OOM killer just kicked in, top showed: > Mem: 224M Active, 4096 Inact, 141M Laundry, 121M Wired, 57M Buf, 2688K Free > Swap: 1939M Total, 249M Used, 1689M Free, 12% Inuse, 1196K Out > > PIDUID THR PRI NICE SIZERES STATETIMEWCPU COMMAND > 1029 10011 440 594M 3848K RUN 2:03 38.12% make > > swapinfo -k showed: > /dev/md99 4194304 254392 3939912 6% > > sysctl: > vm.swzone: 4466880 > vm.swap_maxpages: 496320 > kern.maxswzone: 0 > > dmesg when OOM strikes: > swap blk zone exhausted, increase kern.maxswzone > pid 1029 (make), uid 1001, was killed: out of swap space > pid 984 (bash), uid 1001, was killed: out of swap space > pid 956 (bash), uid 1001, was killed: out of swap space > pid 952 (sshd), uid 0, was killed: out of swap space > pid 1043 (bash), uid 1001, was killed: out of swap space > pid 626 (dhclient), uid 65, was killed: out of swap space > pid 955 (sshd), uid 1001, was killed: out of swap space > pid 1025 (bash), uid 1001, was killed: out of swap space > swblk zone ok > lock order reversal: > 1st 0xd374d028 filedesc structure (filedesc structure) @ > /usr/src/sys/kern/sys_generic.c:1451 > 2nd 0xd41a5bc4 devfs (devfs) @ /usr/src/sys/kern/vfs_vnops.c:1513 > stack backtrace: > swap blk zone exhausted, increase kern.maxswzone > pid 981 (tmux), uid 1001, was killed: out of swap space > pid 983 (tmux), uid 1001, was killed: out of swap space > pid 1031 (bash), uid 1001, was killed: out of swap space > pid 580 (dhclient), uid 0, was killed: out of swap space > swblk zone ok > swap blk zone exhausted, increase kern.maxswzone > pid 577 (dhclient), uid 0, was killed: out of swap space > pid 627 (devd), uid 0, was killed: out of swap space > swblk zone ok > swap blk zone exhausted, increase kern.maxswzone > pid 942 (getty), uid 0, was killed: out of swap space > swblk zone ok > swap blk zone exhausted, increase kern.maxswzone > pid 1205 (init), uid 0, was killed: out of swap space > swblk zone ok > swap blk zone exhausted, increase kern.maxswzone > pid 1206 (init), uid 0, was killed: out of swap space > swblk zone ok > swap blk zone exhausted, increase kern.maxswzone > swblk zone ok > swap blk zone exhausted, increase kern.maxswzone > swblk zone ok > > So, as you can see, despite having plenty of swap, and swap usage being > well below any of the maximums, the OOM killer kicked in, and killed off > a bunch of processes. > > It also looks like the algorithm for calculating kern.maxswzone is not > correct. > > I just tried to run the system w/: > kern.maxswzone: 21474836 > > and it again died w/ plenty of swap free: > /dev/md99 4194304 238148 3956156 6% > > This time I had vmstat -z | grep sw running, and saw: > swpctrie:48, 62084, 145, 270, 203, 0, 0 > swblk: 72, 62040, 56357, 18, 56587, 0, 0 > > after the system died, I logged back in as see: > swpctrie:48, 62084, 28, 387, 240, 0, 0 > swblk: 72, 62040, 175, 61865, 62957, 16, 0 > > so, it clearly ran out of swblk space VERY early, when only consuming > around 232MB of swap... > > Hmm... it looks like swblk and swpctrie are not affected by the setting > of kern.maxswzone... I just set it to: > kern.maxswzone: 85899344 > > and the limits for the zones did not increase at ALL: > swpctrie:48, 62084, 0, 0, 0, 0, 0 > swblk: 72, 62040, 0, 0, 0, 0, 0 Can you try this patch? I've been running with it for a few months now and no longer observe weird OOM kills. IIUC in shortfall mode when nfreed equals zero, this change makes it stay in shortfall mode instead of going to background mode. I don't know enough about VM internals to know if this is the correct fix though. Index: sys/vm/vm_pa
Re: Kernel Panic - Sublime Text - 12.0-PRERELEASE r340650M
On Sat, 24 Nov 2018 02:05:51 + James Wright wrote: > When trying to run sublime text via the linuxulator my system panics > and reboots. Unfortunately I do not have much extra info as it crashes > immediately and seems to corrupt the UFS filesystem in the process > (which has to be fixed with a few runs of fsck on next boot). I've > tried enabling "dumpdev=AUTO" in rc.conf but don't find anything in > /var/crash/ afterwards. > > $ uname > FreeBSD macbook 12.0-PRERELEASE FreeBSD 12.0-PRERELEASE #0 r340650M: > Mon Nov 19 23:09:39 GMT 2018 > root@macbook:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 > > $ pkg info | grep sublime > linux-sublime-2.0.2_6 > > Happy to provide any extra info required to help diagnose the issue! Try upgrading to at least r340762. ___ 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: 13.0-CURRENT: Linux syscall inotify_init regression?
On Wed, 21 Nov 2018 10:22:27 +0100 mat...@pizarro.net wrote: > Hi Tijl and all, > > Thanks for r340631 and r340674. I am currently running r340703 and I > thought this might be of interest to you: I get the following error when > trying to run Sublime Text 3 on X: > > kernel: linux: pid 104 (io_worker): syscall inotify_init not implemented > > I understand there should be a stub in place, even though the inotify > syscall is not supported, shouldn't there be? Yes, there is a stub that prints the message you see. What exactly is the problem? Does the kernel still panic? Can you provide the core.txt file in that case? ___ 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: linux-c7 and opengl apps?
On Wed, 3 Oct 2018 10:36:51 +0100 Johannes Lundberg wrote: > Have anyone successfully run opengl apps with linux-c7? > > Linux opengl apps works great with linux-c6 on gpu < kabylake but > linux-c6-dri does not include support for kabylake gpus. > Linux glxinfo in c7 show support for hardware rendering on kabylake but any > attempt to run an opengl app results in application seg fault or other > crash (I believe this is also the case with skylake gpus on linux-c7). The only non-nvidia hardware I have is an old r300 card and that works under linux c7 emulation. Do you have linsysfs mounted on /compat/linux/sys? ___ 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"
