From owner-freebsd-ia64 Thu Feb 22 8: 7:17 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by hub.freebsd.org (Postfix) with ESMTP id 9464137B4EC; Thu, 22 Feb 2001 08:07:14 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1) id 14VyGt-000HuM-0Y; Thu, 22 Feb 2001 16:07:11 +0000 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f1MG7B732920; Thu, 22 Feb 2001 16:07:11 GMT (envelope-from dfr@nlsystems.com) Date: Thu, 22 Feb 2001 16:07:11 +0000 (GMT) From: Doug Rabson To: John Baldwin Cc: Subject: Re: Oh what the heck.. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 22 Feb 2001, John Baldwin wrote: > > On 22-Feb-01 Doug Rabson wrote: > > On Thu, 22 Feb 2001, John Baldwin wrote: > > > >> Well, I figured that I'd try to fix switch_trampoline anyway. I also needed > >> to > >> remove all traces of sched_lock setting from cpu_switch() since that is now > >> done in mi_switch(). The end result is this patch. I have no idea if it is > >> correct or not. Comments? (I still need to fix userret() to take a pointer > >> to > >> a trapframe). > > > > I haven't tested it but it looks correct to me. > > Hmmmm, ok. I guess I'll be a little daring and commit it. I guess I need to > sit down and finish getting a compile environment (and possibly ski) setup so I > can test this stuff, and so I can keep the ia64 from falling too far behind the > other architectures. Its pretty painless. I have a toolchain sitting around in http://people.freebsd.org/~dfr/ia64-toolchain.tar.gz and a sample filesystem in ia64-fs.tar.gz. Ski runs quite well on -current with the one problem that it sets vmin and vtime for the console pty to 255 instead of zero. If you can work out which pty its using (just look for bogus vmin values with stty), you can use something like: $ stty min 0 time 0 < /dev/ttypXX as a workaround. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message