similar to: getent not displaying builtin groups or users

> > OK, lets start with a DC, if you run getent straight after the > provision of the DC, you will only get the local Unix users. To > get anything in AD, you will need to ensure that the libnss_winbind > links exist, see here: > > https://wiki.samba.org/index.php/Libnss_winbind_Links > > Once the links exist and 'winbind' is added to 'passwd' &

hi Roland > On Tue, 1 Nov 2016 11:00:15 +0000 > niya levi via samba <samba at lists.samba.org> wrote: > >> hi everyone >> >> i have configured 2 domain controllers and a domain member >> >> the domain member is joined to the domain and >> >> ad and rfc2307 is configured for idmap backend, >> >> wbinfo returns domain builtins for

Hi everyone my sssd log shows the nsupdate command failing, how do i test ddns separately from sssd to see if the problem is in sssd or samba. shadrock /etc/sssd/sssd.conf ------------------------------------------------- (Fri Aug 1 12:18:30 2014) [sssd[be[tissisat.co.uk]]] [be_nsupdate_timer_schedule] (0x0200): Timer already scheduled (Fri Aug 1 12:18:30 2014) [sssd[be[tissisat.co.uk]]]

hi everyone i'm having trouble figuring out why i'm getting NT_STATUS_NO_LOGON_SERVERS errors, i have two samba ad domain controllers running on raspberry pi's i think it a recent problem since an upgrade because i was able to list domain users on a joined member server but now getent only lists local users, i've read that the problem might be due to avahi which i stop with

On Thu, Dec 13, 2018 at 08:25:31PM -0500, Lyude Paul wrote: > There should be no functional changes here Would be good to explain what you did refactor here, instead of me trying to reconstruct it from the patch. Especially pre-coffee that helps :-) > > Signed-off-by: Lyude Paul <lyude at redhat.com> > Cc: Juston Li <juston.li at intel.com> > --- >

On Tue, Sep 03, 2019 at 04:45:41PM -0400, Lyude Paul wrote: > When reprobing an MST topology during resume, we have to account for the > fact that while we were suspended it's possible that mstbs may have been > removed from any ports in the topology. Since iterating downwards in the > topology requires that we hold &mgr->lock, destroying MSTBs from this > context would

On Wed, Sep 25, 2019 at 04:08:22PM -0400, Lyude Paul wrote: > On Wed, 2019-09-25 at 14:16 -0400, Sean Paul wrote: > > On Tue, Sep 03, 2019 at 04:45:41PM -0400, Lyude Paul wrote: > > > When reprobing an MST topology during resume, we have to account for the > > > fact that while we were suspended it's possible that mstbs may have been > > > removed from any

hi everyone i am trying setup point n print for canon ip7250, i have downloaded the windows driver which comes as an exe file, to retrieve all the setup files from the exe i started the installation then copied the installation files from the tmp folder, then cancelled the installation, i searched through the install files and cab files for drivers and was unable to recognise them, has anyone

> On Mon, 21 Nov 2016 13:42:57 +0100 > "L.P.H. van Belle via samba" <samba at lists.samba.org> wrote: > >> Hi, >> >> Yes thats correct. >> But try the following. >> Make sure you use the usermapping. >> >> username map = /etc/samba/samba_usermapping >> containing: >> !root = NTDOM\Administrator NTDOM\administrator

Mesa (http://www.mesa3d.org/) uses LLVM to compile shaders. These are typically small bits of code (~10KB) and one application can use many of them. Mesa creates an ExecutionEngine with a default JIT memory manager for each shader it compiles, and keeps the engine around as long as the shader code is needed. This results in memory waste of ~1MB for each shader. Half the overhead is in the

On Tue, Sep 03, 2019 at 04:46:03PM -0400, Lyude Paul wrote: > Finally! For a very long time, our MST helpers have had one very > annoying issue: They don't know how to reprobe the topology state when > coming out of suspend. This means that if a user has a machine connected > to an MST topology and decides to suspend their machine, we lose all > topology changes that happened

Hi Frank, The project really needs to be looking to move away from the old JIT and to MCJIT. LLVM is actively working to kill the old JIT. It’s already unmaintained. MCJIT is the way forward. Can you elaborate on what’s blocking its adoption for Mesa? -Jim On Oct 1, 2013, at 10:44 AM, Frank Henigman <fjhenigman at google.com> wrote: > Mesa (http://www.mesa3d.org/) uses LLVM to compile

On Tue, Sep 03, 2019 at 04:45:54PM -0400, Lyude Paul wrote: > Since we're going to be implementing suspend/resume reprobing very soon, > we need to make sure we are extra careful to ensure that our locking > actually protects the topology state where we expect it to. Turns out > this isn't the case with drm_dp_port_setup_pdt() and > drm_dp_port_teardown_pdt(), both of which

On Thu, Dec 13, 2018 at 08:25:34PM -0500, Lyude Paul wrote: > Up until now, freeing payloads on remote MST hubs that just had ports > removed has almost never worked because we've been relying on port > validation in order to stop us from accessing ports that have already > been freed from memory, but ports which need their payloads released due > to being removed will never be

I'll try to find out, or get someone to explain, why Mesa selects MCJIT with LLVM 3.1 only and JIT for other LLVM versions. I'm not keen to code a fourth attempt (1: copy JIT code, 2: delegating manger, 3: derive from DefaultJITMemoryManager, 4: copy MCJIT code) but I'll try copying code with MCJIT. Is that the usual route for people who want to delete all LLVM engines, etc. while

On Tue, Dec 18, 2018 at 04:27:58PM -0500, Lyude Paul wrote: > On Fri, 2018-12-14 at 10:29 +0100, Daniel Vetter wrote: > > On Thu, Dec 13, 2018 at 08:25:32PM -0500, Lyude Paul wrote: > > > The current way of handling refcounting in the DP MST helpers is really > > > confusing and probably just plain wrong because it's been hacked up many > > > times over the

On Thu, Dec 13, 2018 at 08:25:32PM -0500, Lyude Paul wrote: > The current way of handling refcounting in the DP MST helpers is really > confusing and probably just plain wrong because it's been hacked up many > times over the years without anyone actually going over the code and > seeing if things could be simplified. > > To the best of my understanding, the current scheme

On Fri, Nov 16, 2018 at 07:21:15PM -0500, Lyude Paul wrote: > Some hardware (nvidia hardware in particular) needs to be notified of > the exact VCPI and payload settings that the topology manager decided on > for each mstb port. Since there isn't currently any way to get this > information without going through port (which drivers are very much not > supposed to do by

On Tue, Sep 03, 2019 at 04:45:58PM -0400, Lyude Paul wrote: > Yes-you read that right. Currently there is literally no locking in > place for any of the drm_dp_mst_port struct members that can be modified > in response to a link address response, or a connection status response. > Which literally means if we're unlucky enough to have any sort of > hotplugging event happen before

Add infrastructure to keep track of GPU virtual address (VA) mappings with a decicated VA space manager implementation. New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers start implementing, allow userspace applications to request multiple and arbitrary GPU VA mappings of buffer objects. The DRM GPU VA manager is intended to serve the following purposes in this context. 1)