From owner-freebsd-threads@FreeBSD.ORG Sat May 31 00:23:00 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD93137B401 for ; Sat, 31 May 2003 00:23:00 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC0A343F85 for ; Sat, 31 May 2003 00:22:59 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h4V7Mxwk081518 for ; Sat, 31 May 2003 00:22:59 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h4V7MxvS002447 for ; Sat, 31 May 2003 00:22:59 -0700 (PDT) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h4V7MxKc002446 for threads@FreeBSD.org; Sat, 31 May 2003 00:22:59 -0700 (PDT) Date: Sat, 31 May 2003 00:22:59 -0700 From: Marcel Moolenaar To: threads@FreeBSD.org Message-ID: <20030531072259.GA2408@athlon.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: libthr: thr_create(2): no kernel stack? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2003 07:23:01 -0000 Gang, I'm porting libthr to ia64 and reached a point where I can actually do initial testing. I immediately hit upon a snafu in thr_create(2). The second bcopy (ie sys/kern/kern_thr.c:159) is panicing because the new thread (td0) does not have a frame (ie td_frame == NULL). Creating a frame is obviously the thing to do, but there's no kernel stack created for the new thread AFAICT. Without kernel thread. cpu_set_upcall() will also fail if we ever reach that point. Am I missing something here? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net