Re: _lwp_setprivate and _lwp_makecontext
hi, > Hi all, > I'm working on Thread Locale Storage support for NetBSD and I am facing > an interesting issue with the libpthread integration. On i386 and AMD64, > TLS support uses the segment register %gs or %fs to load the thread > pointer. The location used as segment base is thread specific and stored > in the PCB. It is not part of ucontext_t and therefore _lwp_makecontext > can't store private in it. To work around this, I can think of three > options: > > (1) Break ucontext_t and allow the private pointer as separate field > > Pro: Integrates nicely with the other platforms and debugger > Contra: Lots of nasty interfaces to deal with in terms of compat. > > (2) Add private as argument for _lwp_create as well. > > Pro: logically fits well too, minimal amount of changes for libc and > libpthread. > > (3) Defer calling _lwp_setprivate into the newly created thread. > > Pro: no kernel / libc changes needed > Contra: might create complications with signal handlers etc > > > I'm personally favoring (2), but looking for input. > > Joerg when i looked at this, i abused _REG_ESP for i386. http://mail-index.netbsd.org/tech-kern/2009/09/27/msg006146.html i have no idea if other ports have unused members like this, tho. YAMAMOTO Takashi
UVM / pmap assertion under load
Trying to get a stress test consisting of a bunch of fsx, fsstress and dbench running this combination leads within minutes to a failed assertion "(npte & PG_RW) != 0" in file x86/x86/pmap.c. With some tracing I always get the same pattern: - fsx gets a trap(), user memory, write. -> the uobj is a vnode with VI_WRMAPDIRTY set. - uvm_fault_lower() has to call uvm_fault_lower_io() as uobjpage is zero. - short before uvm_fault_lower_io() has a chance to re-lock uobj another thread comes through genfs_do_putpages() and clears VI_WRMAPDIRTY. - uvm_fault_lower_direct() sees UVM_OBJ_NEEDS_WRITEFAULT() and clears VM_PROT_WRITE. - pmap_enter_ma() fires the assertion "(npte & PG_RW) != 0". ~ one of ten times I get the assertion "(uobj == NULL || !UVM_OBJ_IS_CLEAN(uobjpage->uobject) || (uobjpage->flags & PG_CLEAN) != 0);" which may be related. Any ideas? -- Juergen Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
_lwp_setprivate and _lwp_makecontext
Hi all, I'm working on Thread Locale Storage support for NetBSD and I am facing an interesting issue with the libpthread integration. On i386 and AMD64, TLS support uses the segment register %gs or %fs to load the thread pointer. The location used as segment base is thread specific and stored in the PCB. It is not part of ucontext_t and therefore _lwp_makecontext can't store private in it. To work around this, I can think of three options: (1) Break ucontext_t and allow the private pointer as separate field Pro: Integrates nicely with the other platforms and debugger Contra: Lots of nasty interfaces to deal with in terms of compat. (2) Add private as argument for _lwp_create as well. Pro: logically fits well too, minimal amount of changes for libc and libpthread. (3) Defer calling _lwp_setprivate into the newly created thread. Pro: no kernel / libc changes needed Contra: might create complications with signal handlers etc I'm personally favoring (2), but looking for input. Joerg
Re: Modules loading modules?
On Wed, 28 Jul 2010, Andrew Doran wrote: If modload-from-modcmd is found necessary, sounds more like a case for the infamous recursive lock. Recursive lock is the way to go. I think the same lock should also cover all device configuration activites (i.e. autoconf) and any other heavy lifting where we have chunks of the system coming and going. OK, I'm willing to make an attempt to implement the recursive_lock if noone else wants to give it a try! It will probably take some time... - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: RFC: device flavours
On Wed, Jul 28, 2010 at 11:00:58AM -0500, David Young wrote: > On Wed, Jul 28, 2010 at 03:09:36PM +, Quentin Garnier wrote: > > On Tue, Jul 27, 2010 at 09:23:04AM +0200, Martin Husemann wrote: > > And after that, the > > pcib driver will have to know that it might be on an ACPI system and > > thus can fetch information there. Think what you want, but to me it is > > nonsense and that's exactly what I am trying to find a solution to here. > > The pcib(4) driver only needs to attach its isa(4). isa(4) need not know > anything about ACPI, it just walks its MI device properties list to see > what is directly configurable. A small note: focusing on isa(4), legacy drivers, and their configuration hides the real issue, which is that we need a 1:1 mapping between the normal and the ACPI device tree. This is not optional if we ever want to make any advances for instance in PCI power management. Another example: we have pending device drivers on the ACPI side that need to know about vga(4). What will be there for isa(4), should be there also for pci(4). - Jukka.
