From owner-freebsd-alpha Sat Sep 30 14:35:24 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id 1CB3537B502 for ; Sat, 30 Sep 2000 14:35:21 -0700 (PDT) Received: from mail.cicely.de (cicely.de [194.231.9.142]) by mail.du.gtn.com (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id e8ULZGa26699 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Sat, 30 Sep 2000 23:35:19 +0200 (MET DST) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.11.0.Beta1/8.11.0.Beta1) with ESMTP id e8ULZg545747 for ; Sat, 30 Sep 2000 23:35:42 +0200 (CEST) Received: (from ticso@localhost) by cicely8.cicely.de (8.11.0/8.9.2) id e8ULZbF84100 for freebsd-alpha@freebsd.org; Sat, 30 Sep 2000 23:35:37 +0200 (CEST) (envelope-from ticso) Date: Sat, 30 Sep 2000 23:35:37 +0200 From: Bernd Walter To: freebsd-alpha@freebsd.org Subject: I still have problems booting into su-mode with ithread patches Message-ID: <20000930233536.A83846@cicely8.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Since the first version I tested current with the ithread patches on my PC164 I can see it hanging during boot and if I press the halt button I catch it always with the pointer after the call pal operation of alpha_pal_swpipl(). First it was an spl call now that they are removed I catch it within mtx_exit of the sched_lock resource. I even set it explicitly to ALPHA_PSL_IPL_0 when releasing a mutex. I asume that I catch it always at these point because it's spending most time there and not because the call pal itself is hanging. During the boot process the hanging is always during scsi-bus probing. With an earlier version of the patches it sometime made it to adding the devices to the kernel tables. Is anyone who got it running using a system with multiple scsi channels and/or multiple devices and/or seriel console? As I'm catching it in releasing sched_lock after calling mi_switch the scheduler still seems to work. The only debugging functionality I know of is the objdump -S output from the kernel and the halt-button. Does anyone know more I can try - I can't enter ddb with a break. Is there any way to look into the witness output using SRM? -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message