NFS

[Greg A. Woods-3]

At Wed, 3 Jun 2009 17:32:09 +0300, Jukka Marin <jmarin@...> wrote:
Subject: Re: NFS
>
> Sure, if the network dies, you will no longer be able to access the remote
> disks, but you should still be able to kill off the processes trying to
> do so.  You should still be able to unmount the remote disk (you may lose
> some unwritten data, sure).  And you should still be able to shutdown and
> reboot the client system.

Indeed.  And with mounts using "-i" you should be able to interrupt any
process no matter what operation it is doing, including "df" and related.

On that note though, is there any chance that '-C' could actually be
causing some problems for you?  The suggestion in the manual page is
that an errant ICMP Port Unreachable packet could cause a mount to hang
when this option is used.

--
                                                Greg A. Woods
                                                Planix, Inc.

<woods@...>       [phone]        http://www.planix.com/

[Michael van Elst]

jmarin@... (Jukka Marin) writes:

>Sure, if the network dies, you will no longer be able to access the remote
>disks, but you should still be able to kill off the processes trying to
>do so.

That usually depends on wether the mount is 'interruptible'.

> You should still be able to unmount the remote disk (you may lose
>some unwritten data, sure).

That doesn't work on almost every UNIX system.

>And you should still be able to shutdown and
>reboot the client system.

True.

--
--
                                Michael van Elst
Internet: mlelstv@...
                                "A potential Snark may lurk in every tree."

[Michael van Elst]

tron@... (Matthias Scheler) writes:

>> I'm using -i but it doesn't seem to help (too much).

>I personally don't think that this is a good idea. I e.g. don't want an
>editor to get an error if the NFS server is unreachable and throw away
>an hours worth of changes as result.

-i doesn't make your editor see errors unless it traps interrupting
signals.

--
--
                                Michael van Elst
Internet: mlelstv@...
                                "A potential Snark may lurk in every tree."

[Jukka Marin]

On Wed, Jun 03, 2009 at 08:26:59PM +0000, Michael van Elst wrote:
> >Sure, if the network dies, you will no longer be able to access the remote
> >disks, but you should still be able to kill off the processes trying to
> >do so.
>
> That usually depends on wether the mount is 'interruptible'.

I'm using -i, but I still couldn't kill any of the processes that got stuck
accessing /home. :-(

> > You should still be able to unmount the remote disk (you may lose
> >some unwritten data, sure).
>
> That doesn't work on almost every UNIX system.

Then they're all broken ;-)  What if ssh client did the same - or ftp
and the web browsers?  If you could not disconnect from the server when
the server or network dies?  (Dead NFS is worse as can affect almost any
process on the client.)

  -jm

[Hauke Fath-2]

At 15:15 Uhr -0400 03.06.2009, Greg A. Woods wrote:
>>  Amd just works here on > 50 machines, and has so for years. YMMV, obviously.
>
>I'll admit to having a relatively poor understanding of where AMD can
>actually provide some of the benefits its proponents claim for it.  I
>have an even poorer understanding of how it can interact badly with
>various situations and cause problems.

Erez Zadok's amd book <isbn://0782127398> is a big help with serious
amd installations, shedding light on both concepts and configuration
fine print.

You are of course right that amd cannot undo shortcomings of the
file-systems it uses.

        hauke

--
      The ASCII Ribbon Campaign                    Hauke Fath
()     No HTML/RTF in email            Institut für Nachrichtentechnik
/\     No Word docs in email                     TU Darmstadt
      Respect for open standards              Ruf [phone]

[Greg A. Woods-3]

At Wed, 3 Jun 2009 20:54:16 +0000 (UTC), mlelstv@... (Michael van Elst) wrote:
Subject: Re: NFS

>
> tron@... (Matthias Scheler) writes:
>
> >> I'm using -i but it doesn't seem to help (too much).
>
> >I personally don't think that this is a good idea. I e.g. don't want an
> >editor to get an error if the NFS server is unreachable and throw away
> >an hours worth of changes as result.
>
> -i doesn't make your editor see errors unless it traps interrupting
> signals.

Based on the documentation I thought it was the other way around (indeed
probably most editors do trap all or most interrupting signals, eg. vi
does, though it does try to make sure to do so in a way such that
interruptable system calls will return EINTR, IIUC).

From the "NFS Implementation" section of "The 4.4BSD NFS Implementation":

    An interruptible mount (-i option) checks to see if a termination
    signal is pending for the process when waiting for server response
    and if it is, the I/O system call posts an EINTR.  Normally this
    results in the process being terminated by the signal when returning
    from the system call.  This feature allows you to ``^C'' out of
    processes that are hung due to unresponsive servers.  The problem
    with this approach is that signals that are caught by a process are
    not recognized as termination signals and the process will remain
    hung.

    * Unfortunately, there are also some resource allocation situations
    in the BSD kernel where the termination signal will be ignored and
    the process will not terminate.

(the footnote I think may explain the unkillable "df" issue)

It all sounds like a cop-out though -- the NFS client code shouldn't
really be trying to figure out whether a signal is a termination signal
or not.

--
                                                Greg A. Woods
                                                Planix, Inc.

<woods@...>       [phone]        http://www.planix.com/

[Greg A. Woods-3]

At Wed, 3 Jun 2009 20:54:16 +0000 (UTC), mlelstv@... (Michael van Elst) wrote:
Subject: Re: NFS

>
> tron@... (Matthias Scheler) writes:
>
> >> I'm using -i but it doesn't seem to help (too much).
>
> >I personally don't think that this is a good idea. I e.g. don't want an
> >editor to get an error if the NFS server is unreachable and throw away
> >an hours worth of changes as result.
>
> -i doesn't make your editor see errors unless it traps interrupting
> signals.

Based on the documentation I thought it was the other way around (indeed
probably most editors do trap all or most interrupting signals, eg. vi
does, though it does try to make sure to do so in a way such that
interruptable system calls will return EINTR, IIUC).

From the "NFS Implementation" section of "The 4.4BSD NFS Implementation":

    An interruptible mount (-i option) checks to see if a termination
    signal is pending for the process when waiting for server response
    and if it is, the I/O system call posts an EINTR.  Normally this
    results in the process being terminated by the signal when returning
    from the system call.  This feature allows you to ``^C'' out of
    processes that are hung due to unresponsive servers.  The problem
    with this approach is that signals that are caught by a process are
    not recognized as termination signals and the process will remain
    hung.

    * Unfortunately, there are also some resource allocation situations
    in the BSD kernel where the termination signal will be ignored and
    the process will not terminate.

(the footnote I think may explain the unkillable "df" issue)

It all sounds like a cop-out though -- the NFS client code shouldn't
really be trying to figure out whether a signal is a termination signal
or not.

--
                                                Greg A. Woods
                                                Planix, Inc.

<woods@...>       [phone]        http://www.planix.com/

[Rhialto]

On Sat 06 Jun 2009 at 13:58:58 -0400, Greg A. Woods wrote:
> It all sounds like a cop-out though -- the NFS client code shouldn't
> really be trying to figure out whether a signal is a termination signal
> or not.

In general, it would be nice to have different kinds of interrupt
signals. When running a make, or some script: do you want to terminate
the currently running program only and continue with the next, or stop
the entire script? Or do you want to continue the current program but
abort the script after it finishes? All these situations occur.
(AmigaDOS had ^C, ^D, ^E and ^F, which processes could distinguish,
although they hardly ever did. I think the script processor used ^D to
terminate the script in between programs).

> Greg A. Woods
-Olaf.
--
___ Olaf 'Rhialto' Seibert    -- You author it, and I'll reader it.
\X/ rhialto/at/xs4all.nl      -- Cetero censeo "authored" delendum esse.

[Michael van Elst]

rhialto@... (Rhialto) writes:

>(AmigaDOS had ^C, ^D, ^E and ^F, which processes could distinguish,
>although they hardly ever did. I think the script processor used ^D to
>terminate the script in between programs).

Well, this was necessary, because the script processor and the
program were run by the same process. In UNIX you can send signals
to the specific processes for the shell or the commands it
runs (unless it is a builtin... har har).

--
--
                                Michael van Elst
Internet: mlelstv@...
                                "A potential Snark may lurk in every tree."

[Jukka Marin]

On Tue, Jun 02, 2009 at 02:10:06PM +0300, Jukka Marin wrote:
> I have been using a setup where my $HOME is located on a NetBSD NFS server
> (for 10+ years).  Every now and then something goes wrong with NFS and
> all accesses to /home cause the process enter disk wait (D in ps listing).
> No matter how long I wait, the disk wait never completes.  I can't even
> shutdown and reboot the client system properly because shutdown fails
> to unmount the NFS partition(s).  At the same time, all other NFS mounts
> from the same server work just fine.

It happened again.

After the last discussion, I changed /home to use NFS over TCP and it has
been working well so far.  Yesterday, another UDP mounted partition died
in the middle of a compilation process.  I couldn't umount the partition,
not even with umount -f.  When I ran shutdown -r, it killed a bunch of
processes and then - nothing.  I tried sync, it hang.  I tried reboot,
it didn't.  Even halt didn't do anything useful.

The only way to "fix" the dead NFS mount was hitting the reset button
(which forced a parity rewrite of a 1 TB raidframe disk and fsck of
several largish partitions).

I'm using TCP for all NFS mounts now.. we'll see if that helps.  It would
be great if one could get over an NFS problem without the reset button,
though....

  -jm

[Sverre Froyen]

On Wed July 8 2009 23:49:53 Jukka Marin wrote:
<...>
> After the last discussion, I changed /home to use NFS over TCP and it has
> been working well so far.  Yesterday, another UDP mounted partition died
> in the middle of a compilation process.  I couldn't umount the partition,
> not even with umount -f.  When I ran shutdown -r, it killed a bunch of
> processes and then - nothing.  I tried sync, it hang.  I tried reboot,
> it didn't.  Even halt didn't do anything useful.

It would be nice if reboot could be made to force a reboot.  Perhaps using a
flag.  I have a NetBSD 5.0 Web server where any process accessing the Web
content partition would get stuck in state D (disk wait) waiting on "tstile".  
(I suspect this is a wapbl issue since I have not seen the problem since
remounting the file system without -o log.)   Reboot hung after printing
"syncing disks", requiring physical access to restore the server.

Regards,
Sverre

[Antti Kantee]

On Thu Jul 09 2009 at 08:49:53 +0300, Jukka Marin wrote:

> On Tue, Jun 02, 2009 at 02:10:06PM +0300, Jukka Marin wrote:
> > I have been using a setup where my $HOME is located on a NetBSD NFS server
> > (for 10+ years).  Every now and then something goes wrong with NFS and
> > all accesses to /home cause the process enter disk wait (D in ps listing).
> > No matter how long I wait, the disk wait never completes.  I can't even
> > shutdown and reboot the client system properly because shutdown fails
> > to unmount the NFS partition(s).  At the same time, all other NFS mounts
> > from the same server work just fine.
>
> It happened again.
>
> After the last discussion, I changed /home to use NFS over TCP and it has
> been working well so far.  Yesterday, another UDP mounted partition died
> in the middle of a compilation process.  I couldn't umount the partition,
> not even with umount -f.  When I ran shutdown -r, it killed a bunch of
> processes and then - nothing.  I tried sync, it hang.  I tried reboot,
> it didn't.  Even halt didn't do anything useful.
>
> The only way to "fix" the dead NFS mount was hitting the reset button
> (which forced a parity rewrite of a 1 TB raidframe disk and fsck of
> several largish partitions).
>
> I'm using TCP for all NFS mounts now.. we'll see if that helps.  It would
> be great if one could get over an NFS problem without the reset button,
> though....

I've pretty much stopped using the in-kernel nfs client on my desktop
(laptop) and use either rump_nfs or sshfs.  I don't use them for /home,
though, and you will have issues at least with sshfs in a multiuser
environment.

[Greg A. Woods-3]

At Thu, 9 Jul 2009 09:54:48 -0600, Sverre Froyen <sverre@...> wrote:
Subject: reboot fails to reboot -- was Re: NFS
>
> It would be nice if reboot could be made to force a reboot.  Perhaps using a
> flag.

There already is such a flag, IIUC:  "RB_NOSYNC", aka 0x0004.

I don't think that's what you want though -- it will still require a
full RAIDframe parity check and possibly fsck on the next boot.

A safer mode could probably be done fairly easily too by setting some
kind of watchdog timer before the unmounting of filesystems and other
sundry cleanup, and then forcing the system to reboot if the timer
expires.

(FYI, I have some changes, against netbsd-4, which much more reliably
reboot i386 machines using much more standard methods of rebooting too.)

--
                                                Greg A. Woods
                                                Planix, Inc.

<woods@...>       [phone]        http://www.planix.com/

[David Brownlee]

On Thu, 9 Jul 2009, Antti Kantee wrote:

> I've pretty much stopped using the in-kernel nfs client on my desktop
> (laptop) and use either rump_nfs or sshfs.  I don't use them for /home,
> though, and you will have issues at least with sshfs in a multiuser
> environment.

  Could I ask if there is an obvious trick to using sshfs
  that I'm missing? - I tried playing with it and it seems
  to mount and let me read and rename files fine, but I can't
  create any new files... :/

--
  David/absolute       -- www.NetBSD.org: No hype required --

[Antti Kantee]

On Fri Jul 10 2009 at 18:38:16 +0100, David Brownlee wrote:

> On Thu, 9 Jul 2009, Antti Kantee wrote:
>
> >I've pretty much stopped using the in-kernel nfs client on my desktop
> >(laptop) and use either rump_nfs or sshfs.  I don't use them for /home,
> >though, and you will have issues at least with sshfs in a multiuser
> >environment.
>
> Could I ask if there is an obvious trick to using sshfs
> that I'm missing? - I tried playing with it and it seems
> to mount and let me read and rename files fine, but I can't
> create any new files... :/

There are no tricks that I am aware of.  What command are you executing
and what's the error message?

[Sverre Froyen]

On Thu July 9 2009 11:05:11 Greg A. Woods wrote:
> At Thu, 9 Jul 2009 09:54:48 -0600, Sverre Froyen <sverre@...>
> wrote: Subject: reboot fails to reboot -- was Re: NFS
>
> > It would be nice if reboot could be made to force a reboot.  Perhaps
> > using a flag.
>
> There already is such a flag, IIUC:  "RB_NOSYNC", aka 0x0004.

You're right.  Looks like "reboot -n" invokes that flag.

> I don't think that's what you want though -- it will still require a
> full RAIDframe parity check and possibly fsck on the next boot.

In my case, that would have been preferable to jumping in a car and driving
for 30 mins.   Fsck was skipped anyway because of the "log" option -- perhaps
unsafely, considering the state the file system was in.

> A safer mode could probably be done fairly easily too by setting some
> kind of watchdog timer before the unmounting of filesystems and other
> sundry cleanup, and then forcing the system to reboot if the timer
> expires.

Agreed.  This would all have to go into the kernel, correct?

> (FYI, I have some changes, against netbsd-4, which much more reliably
> reboot i386 machines using much more standard methods of rebooting too.)

Could they be added to 5 and current?

Thanks,
Sverre

[David Brownlee]

On Fri, 10 Jul 2009, Antti Kantee wrote:

>> Could I ask if there is an obvious trick to using sshfs
>> that I'm missing? - I tried playing with it and it seems
>> to mount and let me read and rename files fine, but I can't
>> create any new files... :/
>
> There are no tricks that I am aware of.  What command are you executing
> and what's the error message?

  I've tried the mount as:
     sshfs ${user}@${host}:/files/netbsd /mnt
  and
     sshfs -o workaround=all -o sshfs_debug -o idmap=user ${user}@${host}:/files/netbsd /mnt

  Client and server are both NetBSD/i386 5.0_STABLE from within
  the last week.

  I'm using fuse-sshfs-1.4nb1 from pkgsrc but with the
  bluez-libs/buildlink3.mk removed and pkg-config added to USE_TOOLS

  'mv' of an existing file works fine, but 'touch /mnt/moo' fails with:

  26361      1 touch    CALL  __stat30(0xbfbff96e,0xbfbfe790)
  26361      1 touch    NAMI  "/mnt/moo"
  26361      1 touch    RET   __stat30 -1 errno 2 No such file or directory
  26361      1 touch    CALL  open(0xbfbff96e,0x201,0x1b6)
  26361      1 touch    NAMI  "/mnt/moo"
  26361      1 touch    RET   open -1 errno 2 No such file or directory
  26361      1 touch    CALL  write(2,0xbfbfdf40,7)


--
  David/absolute       -- www.NetBSD.org: No hype required --

[Antti Kantee]

On Fri Jul 10 2009 at 20:44:58 +0100, David Brownlee wrote:

> On Fri, 10 Jul 2009, Antti Kantee wrote:
>
> >> Could I ask if there is an obvious trick to using sshfs
> >> that I'm missing? - I tried playing with it and it seems
> >> to mount and let me read and rename files fine, but I can't
> >> create any new files... :/
> >
> >There are no tricks that I am aware of.  What command are you executing
> >and what's the error message?
>
> I've tried the mount as:
>    sshfs ${user}@${host}:/files/netbsd /mnt
> and
>    sshfs -o workaround=all -o sshfs_debug -o idmap=user
>    ${user}@${host}:/files/netbsd /mnt
>
> Client and server are both NetBSD/i386 5.0_STABLE from within
> the last week.
>
> I'm using fuse-sshfs-1.4nb1 from pkgsrc but with the
> bluez-libs/buildlink3.mk removed and pkg-config added to USE_TOOLS

Oh.  I've never used sshfs from pkgsrc.  I'm talking about the
NetBSD-optimized psshfs found as mount_psshfs from base.

[Greg A. Woods-3]

At Fri, 10 Jul 2009 11:55:22 -0600, Sverre Froyen <sverre@...> wrote:
Subject: Re: reboot fails to reboot -- was Re: NFS
>
> You're right.  Looks like "reboot -n" invokes that flag.

Ah yes, indeed -- I almost forgot about that, I was only thinking about
kernel stuff anyway...  :-)

> In my case, that would have been preferable to jumping in a car and driving
> for 30 mins.   Fsck was skipped anyway because of the "log" option -- perhaps
> unsafely, considering the state the file system was in.

I really hate PCs, especially PC "servers".

I want a modern system with real, and simple, lights-out remote
management, just like the old AlphaServers and their RMC, or the ILOM or
ALOM that Sun servers, have.  And something without a bass-ackwards
compatible BIOS, and of course all that means it will have real serial
console support in the firmware too.  I guess I should just shut up and
shell out the bucks for a new(er) Sun server, but sadly I think I'd
still be stuck with their x86 or maybe AMD platforms if I wanted to run
NetBSD.

Of course I'm assuming you at least have a serial console connected for
remote management and that you didn't just drive to the machine to
"press any key".  Proper firmware would not directly avoid that problem,
but it would at least make it easier to use a serial console properly.


> > A safer mode could probably be done fairly easily too by setting some
> > kind of watchdog timer before the unmounting of filesystems and other
> > sundry cleanup, and then forcing the system to reboot if the timer
> > expires.
>
> Agreed.  This would all have to go into the kernel, correct?

Yes, indeed, it would have to be a kernel feature.  I haven't looked
closely at the kernel shutdown sequences since the 1.6.x days but I
think it should be easy enough to establish a timeout around the file


> > (FYI, I have some changes, against netbsd-4, which much more reliably
> > reboot i386 machines using much more standard methods of rebooting too.)
>
> Could they be added to 5 and current?

I would imagine....  They're at the bottom of this diff (note some are
still #if-0'ed out because I haven't had time to figure out how to do
them properly in the NetBSD context):


Index: sys/arch/i386/i386/machdep.c
===================================================================
RCS file: /cvs/master/m-NetBSD/main/src/sys/arch/i386/i386/machdep.c,v
retrieving revision 1.586.2.5
diff -u -r1.586.2.5 machdep.c
--- sys/arch/i386/i386/machdep.c 28 Aug 2007 11:46:26 -0000 1.586.2.5
+++ sys/arch/i386/i386/machdep.c 3 Jul 2009 20:10:12 -0000
@@ -278,6 +278,14 @@
 phys_ram_seg_t mem_clusters[VM_PHYSSEG_MAX];
 int mem_cluster_cnt;
 
+#ifdef VGA_APERTURE
+# ifdef INSECURE
+int allow_vga_aperture = 1;
+# else
+int allow_vga_aperture = 0;
+# endif
+#endif
+
 int cpu_dump(void);
 int cpu_dumpsize(void);
 u_long cpu_dump_mempagecnt(void);
@@ -416,6 +424,12 @@
  char pbuf[9];
 
  /*
+ * For console drivers that require uvm and pmap to be initialized,
+ * we'll give them one more chance here...
+ */
+ consinit();
+
+ /*
  * Initialize error message buffer (et end of core).
  */
  if (msgbuf_p_cnt == 0)
@@ -635,6 +649,13 @@
        NULL, 0, NULL, 0,
        CTL_MACHDEP, CTL_EOL);
 
+#ifdef VGA_APERTURE
+ sysctl_createv(clog, 0, NULL, NULL,
+       CTLFLAG_PERMANENT|CTLFLAG_READWRITE, /* XXX was using CTLFLAG_READONLY1 */
+       CTLTYPE_INT, "allow_vga_aperture", NULL,
+       NULL, 0, &allow_vga_aperture, 0,
+       CTL_MACHDEP, CPU_ALLOW_VGA_APERTURE, CTL_EOL);
+#endif
  sysctl_createv(clog, 0, NULL, NULL,
        CTLFLAG_PERMANENT,
        CTLTYPE_STRUCT, "console_device", NULL,
@@ -870,6 +891,7 @@
 void
 cpu_reboot(int howto, char *bootstr)
 {
+ int keyval = 0;
 
  if (cold) {
  howto |= RB_HALT;
@@ -877,6 +899,10 @@
  }
 
  boothowto = howto;
+ /*
+ * XXX this bit, except for the "cold" check above, should be MI --
+ * i.e. back in kern/kern_xxx.c:sys_reboot()
+ */
  if ((howto & RB_NOSYNC) == 0 && waittime < 0) {
  waittime = 0;
  vfs_shutdown();
@@ -888,7 +914,7 @@
  resettodr();
  }
 
- /* Disable interrupts. */
+ /* block interrupts. */
  splhigh();
 
  /* Do a dump if requested. */
@@ -921,17 +947,16 @@
  apm_set_powstate(NULL, APM_DEV_ALLDEVS, APM_SYS_OFF);
  printf("WARNING: APM powerdown failed!\n");
  /*
- * RB_POWERDOWN implies RB_HALT... fall into it...
+ * RB_POWERDOWN includes RB_HALT... fall into it...
  */
 #endif
  }
 
  if (howto & RB_HALT) {
- printf("\n");
- printf("The operating system has halted.\n");
- printf("Please press any key to reboot.\n\n");
+ printf("\nThe operating system has halted.\n"
+       "Please press any key to reboot.\n\n");
 
-#ifdef BEEP_ONHALT
+#ifdef BEEP_ONHALT /* XXX could be:  defined(BEEP_ONHALT_COUNT) && (BEEP_ONHALT_COUNT > 0) */
  {
  int c;
  for (c = BEEP_ONHALT_COUNT; c > 0; c--) {
@@ -944,21 +969,61 @@
  }
 #endif
 
- cnpollc(1); /* for proper keyboard command handling */
- if (cngetc() == 0) {
- /* no console attached, so just hlt */
- for(;;) {
- __asm volatile("hlt");
+ cnpollc(1); /* for proper keyboard command handling without
+ * interrupts */
+ /*
+ * ACK!!!  The line discipline does _NOT_ get used from within
+ * the kernel for console I/O (though it probably should be).
+ *
+ * If any output above went out too fast for the device
+ * connected to a serial console then we'll read a <CTRL-S>
+ * here, and/or perhaps a <CTRL-Q>, and we'll just have to
+ * ignore them.
+ */
+#define ASCII_XON 0x11
+#define ASCII_XOFF 0x13
+ do {
+ if ((keyval = cngetc()) == 0) {
+ /*
+ * no console attached, or perhaps a BREAK
+ * condition caused a read error, so just
+ * invoke the HLT instruction and wait for the
+ * operator to push the reset (or power)
+ * button.
+ */
+ printf("\nCannot read from the console, calling the HLT instruction.\n\n");
+ printf("RESET or power cycle the system to reboot.\n\n");
+
+ goto cpu_halt;
  }
- }
+#ifdef DEBUG
+ else if (keyval == ASCII_XOFF || keyval == ASCII_XON) {
+ printf("(ignoring flow control char (0x%x)\n", keyval);
+ /* XXX even this could trigger another XOFF, sigh... */
+ }
+#endif
+ } while (keyval == ASCII_XOFF || keyval == ASCII_XON);
+
  cnpollc(0);
+#ifdef DEBUG /* XXX if booted with '-v' perhaps? */
+ if (keyval)
+ printf("(read key value 0x%x)\n\n", keyval);
+#endif
  }
 
  printf("rebooting...\n");
  if (cpureset_delay > 0)
  delay(cpureset_delay * 1000);
  cpu_reset();
- for(;;) ;
+ printf("cpu_reset() returned, waiting for hardware to reset or be reset...\n\n");
+
+  cpu_halt:
+ /*
+ * XXX to halt or not to halt -- is one halt good enough?
+ */
+ for (;;) {
+ __asm volatile("hlt");
+ }
  /*NOTREACHED*/
 }
 
@@ -1435,7 +1500,7 @@
 
  /* XXX XXX XXX */
  if (mem_cluster_cnt >= VM_PHYSSEG_MAX)
- panic("init386: too many memory segments "
+ panic("init386: add_mem_cluster(): too many memory segments "
     "(increase VM_PHYSSEG_MAX)");
 
  seg_start = round_page(seg_start);
@@ -1577,16 +1642,10 @@
  }
 
 #ifdef DEBUG_MEMLOAD
- printf("mem_cluster_count: %d\n", mem_cluster_cnt);
+ printf("initial mem_cluster_cnt: %d\n", mem_cluster_cnt); /* XXX won't this always be zero here? */
 #endif
 
  /*
- * Call pmap initialization to make new kernel address space.
- * We must do this before loading pages into the VM system.
- */
- pmap_bootstrap((vaddr_t)atdevbase + IOM_SIZE);
-
- /*
  * Check to see if we have a memory map from the BIOS (passed
  * to us by the boot program.
  */
@@ -1712,6 +1771,17 @@
 
  avail_end = IOM_END + trunc_page(KBTOB(biosextmem));
  }
+
+#ifdef DEBUG_MEMLOAD
+ printf("final mem_cluster_cnt: %d\n", mem_cluster_cnt);
+#endif
+
+ /*
+ * Call pmap initialization to make new kernel address space.
+ * We must do this before loading pages into the VM system.
+ */
+ pmap_bootstrap((vaddr_t)atdevbase + IOM_SIZE);
+
  /*
  * If we have 16M of RAM or less, just put it all on
  * the default free list.  Otherwise, put the first
@@ -2191,10 +2261,48 @@
 #include <dev/ic/mc146818reg.h> /* for NVRAM POST */
 #include <i386/isa/nvram.h> /* for NVRAM POST */
 
+/* XXX some copied from sys/arch/x86/pci/pci_machdep.c, should be in <x86/include/pci_machdep.h> */
+/* XXX they're also used in sys/arch/i386/stand/lib/test/pci_user.c */
+#define PCI_MODE1_ENABLE 0x80000000UL
+#define PCI_MODE1_ADDRESS_REG 0x0cf8
+
+#define PCI_MODE1_RESET_CTL_REG 0x0cf9
+#define PCI_MODE1_DATA_REG 0x0cfc
+
+/*
+ * From Radisys 82600 High Integration Dual PCI System Controller Data Book:
+ *
+ * Bits 1 and 2 in this register are used by the 82600 to generate a hard reset
+ * or a soft reset.  During a hard reset, the 82600 asserts CPURST# and LPRST#
+ * and resets its own core logic.  BPRST# is also asserted if the 82600 is
+ * configured as the BPCI Central Resource.  During a soft reset, the 82600
+ * only asserts INIT#.
+ *
+ * Bit Description
+ *
+ * 7:3 Reserved.
+ *
+ * 2 Reset CPU (RCPU) ­ R/W. A transition of this bit from a 0 to a 1
+ * initiates a reset. The type of reset is determined by bit 1.  This bit
+ * cannot be read as a 1.
+ *
+ * 1 System Reset (SRST) ­ R/W.  This bit is used to select the type of
+ * reset generated when bit 2 in this register transitions to a 1.  A
+ * value of 1 selects a hard reset and 0 selects a soft reset
+ *
+ * 0 Reserved.
+ */
+#define PCI_RESET_RCPU (1 << 2)
+#define PCI_RESET_SRST (1 << 1)
+
+#define PCAT_SYS_CTL_A 0x92 /* AT System Control Port A */
+#define PCAT_SYS_CTL_A_FRST 0x01 /* Fast Reset, aka Fast Init */
+
 void
 cpu_reset()
 {
  struct region_descriptor region;
+ u_int8_t reg8;
 
  disable_intr();
 
@@ -2220,40 +2328,104 @@
  * See AMD Geode SC1100 Processor Data Book, Revision 2.0,
  * sections 6.3.1, 6.3.2, and 6.4.1.
  */
- if (cpu_info_primary.ci_signature == 0x540) {
- outl(0xcf8, 0x80009044ul);
- outl(0xcfc, 0xf);
+ /* XXX OpenBSD puts this in sys/arch/i386/pci/geodesc.c:sc1100_sysreset() */
+ if (cpu_info_primary.ci_signature == 0x540) { /* CPU_GEODE1100??? */
+#ifdef DEBUG
+ printf("cpu_reset(): trying AMD Geode SC1100 PCI-bus system reset...\n");
+#endif
+ outl(PCI_MODE1_ADDRESS_REG, PCI_MODE1_ENABLE | 0x9044);
+ outl(PCI_MODE1_DATA_REG, 0xf);
+ }
+
+ /* XXX OpenBSD has ACPI reset stuff in sys/dev/acpi/acpi.c:acpi_reset() */
+
+ /*
+ * Try the PCI system & cpu reset _first_ (from FreeBSD and GNU/Linux)
+ *
+ * Write 0x6 to PCI Reset Control Register (0xcf9) to reset the CPU,
+ * the PCI controller itself, and to trigger a system-wide reset.
+ *
+ * This is the best method for all recent and modern systems that
+ * include any form of PCI controller.
+ */
+#ifdef DEBUG
+ printf("cpu_reset(): trying generic PCI-bus system & CPU reset...\n");
+#endif
+ reg8 = inb(PCI_MODE1_RESET_CTL_REG);
+ reg8 |= PCI_RESET_RCPU | PCI_RESET_SRST;
+ outb(PCI_MODE1_RESET_CTL_REG, reg8);
+ delay(500000);       /* wait 0.5 sec to see if that did it */
+
+ /*
+ * Try reset by setting the 0x01 bit of the System Control Port A
+ * (0x92) (also from FreeBSD)
+ *
+ * This is the second-best way to reset any i386 system, and should
+ * work on everything back to the PC/AT.
+ *
+ * Note this doesn't work (or didn't) in VMware.
+ */
+ reg8 = inb(PCAT_SYS_CTL_A);
+ /* Check the the hardware actually has the port in question */
+ if (reg8 != 0xff) {
+#ifdef DEBUG
+ printf("cpu_reset(): trying PC/AT System Control Port A reset...\n");
+#endif
+ /* FAST_INIT must be zero before a one can be written */
+ if ((reg8 & PCAT_SYS_CTL_A_FRST) != 0)
+ outb(PCAT_SYS_CTL_A, reg8 & ~PCAT_SYS_CTL_A_FRST);
+ outb(PCAT_SYS_CTL_A, reg8 | PCAT_SYS_CTL_A_FRST);
+ delay(500000); /* wait 0.5 sec to see if that did it */
  }
 
  /*
- * The keyboard controller has 4 random output pins, one of which is
- * connected to the RESET pin on the CPU in many PCs.  We tell the
- * keyboard controller to pulse this line a couple of times.
+ * The keyboard controller has 4 output pins, one of which is connected
+ * to the CPU RESET line in many PCs.  We tell the keyboard controller
+ * to pulse this line a couple of times.
+ *
+ * XXX FreeBSD only does it once, then waits for 0.5 sec
  */
+#ifdef DEBUG
+ printf("cpu_reset(): trying keyboard controller reset...\n");
+#endif
  outb(IO_KBD + KBCMDP, KBC_PULSE0);
  delay(100000);
  outb(IO_KBD + KBCMDP, KBC_PULSE0);
- delay(100000);
+ delay(500000);
 
  /*
  * Try to cause a triple fault and watchdog reset by making the IDT
  * invalid and causing a fault.
  */
+#ifdef DEBUG
+ printf("cpu_reset(): trying IDT invalid with divide-by-zero fault reset...\n");
+#endif
  memset((caddr_t)idt, 0, NIDT * sizeof(idt[0]));
  setregion(®ion, idt, NIDT * sizeof(idt[0]) - 1);
  lidt(®ion);
  __asm volatile("divl %0,%1" : : "q" (0), "a" (0));
 
-#if 0
+#if 0 /* XXX FreeBSD and OpenBSD actually do resort to this as a last go */
+ /* XXX unfortunately PTD is no longer defined in NetBSD's sys/arch/i386/include/pmap.h.... */
  /*
  * Try to cause a triple fault and watchdog reset by unmapping the
  * entire address space and doing a TLB flush.
  */
+#ifdef DEBUG
+ printf("cpu_reset(): trying TLB flush watchdog reset...\n");
+#endif
  memset((caddr_t)PTD, 0, PAGE_SIZE);
  tlbflush();
 #endif
 
- for (;;);
+#if 0
+ /*
+ * XXX we could also try the BIOS cold boot, but do we have to be in
+ * real mode first?....
+ */
+ __asm("movw $0x0000, $0x472;
+      ljmp $0xffff, $0x0000");
+#endif
 }
 
 void


--
                                                Greg A. Woods

[phone]                VE3TCP          RoboHack <woods@...>
Planix, Inc. <woods@...>      Secrets of the Weird <woods@...>

[Alistair Crooks]

On Fri, Jul 10, 2009 at 08:44:58PM +0100, David Brownlee wrote:

> On Fri, 10 Jul 2009, Antti Kantee wrote:
>
> >> Could I ask if there is an obvious trick to using sshfs
> >> that I'm missing? - I tried playing with it and it seems
> >> to mount and let me read and rename files fine, but I can't
> >> create any new files... :/
> >
> >There are no tricks that I am aware of.  What command are you executing
> >and what's the error message?
>
> I've tried the mount as:
>    sshfs ${user}@${host}:/files/netbsd /mnt
> and
>    sshfs -o workaround=all -o sshfs_debug -o idmap=user
>    ${user}@${host}:/files/netbsd /mnt
>
> Client and server are both NetBSD/i386 5.0_STABLE from within
> the last week.
>
> I'm using fuse-sshfs-1.4nb1 from pkgsrc but with the
> bluez-libs/buildlink3.mk removed and pkg-config added to USE_TOOLS

OK, I have to ask - what is "fuse-sshfs-1.4nb1 from pkgsrc"?
 
Up until you said that, I'd been thinking you were using mount_psshfs(8).

Regards,
Al