arla problems under Solaris 2.6

[John Hawkinson]

> > 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