[10] in arla-drinkers
Re: arla problems under Solaris 2.6
daemon@ATHENA.MIT.EDU (John Hawkinson)
Thu Jun 18 21:43:57 1998
From arla-drinkers-request@sundance.stacken.kth.se Fri Jun 19 01:43:56 1998
Return-Path: <arla-drinkers-request@sundance.stacken.kth.se>
Delivered-To: arla-drinkers-mtg@bloom-picayune.mit.edu
Received: (qmail 11949 invoked from network); 19 Jun 1998 01:43:54 -0000
Received: from unknown (HELO sundance.stacken.kth.se) (130.237.234.41)
by bloom-picayune.mit.edu with SMTP; 19 Jun 1998 01:43:54 -0000
Received: from all-purpose-gunk.near.net (all-purpose-gunk.near.net [199.94.208.184])
by sundance.stacken.kth.se (8.8.8/8.8.8) with ESMTP id DAA11041
for <arla-drinkers@stacken.kth.se>; Fri, 19 Jun 1998 03:39:14 +0200 (MET DST)
Received: (from jhawk@localhost)
by all-purpose-gunk.near.net (8.8.8/8.8.8) id VAA17933;
Thu, 18 Jun 1998 21:39:07 -0400 (EDT)
From: John Hawkinson <jhawk@bbnplanet.com>
Message-Id: <199806190139.VAA17933@all-purpose-gunk.near.net>
Subject: Re: arla problems under Solaris 2.6
To: assar@sics.se (Assar Westerlund)
Date: Thu, 18 Jun 1998 21:39:06 -0400 (EDT)
Cc: arla-drinkers@stacken.kth.se
In-Reply-To: <5liulycypb.fsf@dhcp217.conference.usenix.org> from "Assar Westerlund" at Jun 18, 98 09:11:12 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
> > I'm not sure what to conclude here. It looks like the pointers
> > in the struct mounta are not accessible in kernel space.
> > I don't understand why that might be.
>
> It seems to me that you need to copy in the `spec' and the `dir', but
> they are only used in that debug output anyway, so try removing them
> from there and see if it makes any difference.
Well, I'm pretty sure removing them works.
I hadn't thought about copyin(), but in retrospect that makes
obvious sense. Unfortunately it doesn't work:
*** /tmp/T00KOPwy Thu Jun 18 21:34:00 1998
--- xfs_vfsops.c Thu Jun 18 21:28:32 1998
***************
*** 68,76 ****
struct vnode *devvp;
dev_t dev;
int error;
XFSDEB(XDEBVFOPS, ("xfs_mount vfsp = 0x%x path = %s args = '%s'\n",
! (u_int) vfsp, uap->dir, uap->spec));
/*
* This is something that should be done before calling this
--- 68,84 ----
struct vnode *devvp;
dev_t dev;
int error;
+ #ifdef DEBUG
+ char dir[MAXPATHLEN], spec[MAXPATHLEN];
+ #endif
+ #ifdef DEBUG
+ if (copyin(uap->dir, dir, MAXPATHLEN) ||
+ copyin(uap->spec, spec, MAXPATHLEN))
+ return EFAULT;
XFSDEB(XDEBVFOPS, ("xfs_mount vfsp = 0x%x path = %s args = '%s'\n",
! (u_int) vfsp, dir, spec));
! #endif
/*
* This is something that should be done before calling this
But I just get EFAULT back:
# truss bin/mount_xfs /dev/xfs0 /afs | & grep 'mount('
mount("/dev/xfs0", "/afs", MS_DATA, "xfs", 0x00000000, 0) Err#14 EFAULT
# bin/mount_xfs /dev/xfs0 /afs
mount: Bad address
#
> > {Writing Device Drivers} instructs one not to use
> > printf(), but instead to use cmn_err(). I didn't think
> > this was the problem, but I replaced all printf()s with
> > cmn_err()s, but that paniced in the same place.
>
> Yeah, I know you _should_ use cmn_err but when I found a printf I
> didn't bother changing all the calls to printf. :)
:-)
Incidently, I noticed that my Solaris 2.6 machines weren't rebooting
automatically after panics. It looks like this is a bug in
debug_enter() which reverses the check for 0x40 in boothowto, and
always takes you to the monitor *unless* it is set. Setting
boothowto to 0x40 instead of 0x0 (but only after the machine is in
multiuser, otherwise things get fucked up), appears to make it
reboot properly in the event of a panic.
--jhawk
