daily CVS update output

[NetBSD source update]

Updating src tree:
P src/external/cddl/osnet/dist/tools/ctf/cvt/ctf.c
P src/lib/libedit/vi.c
P src/sys/arch/arm/nvidia/files.tegra
P src/sys/arch/arm/nvidia/tegra_ehci.c
cvs update: `src/sys/arch/arm/nvidia/tegra_ehcireg.h' is no longer in the 
repository
P src/sys/arch/arm/nvidia/tegra_io.c
U src/sys/arch/arm/nvidia/tegra_usbphy.c
U src/sys/arch/arm/nvidia/tegra_usbreg.h
P src/sys/arch/evbarm/awin/awin_machdep.c
P src/sys/arch/evbarm/conf/JETSONTK1
P src/sys/arch/evbarm/tegra/tegra_machdep.c
P src/sys/arch/mips/mips/bus_space_alignstride_chipdep.c
P src/sys/dev/dksubr.c
P src/sys/dev/i2c/files.i2c
P src/sys/dev/pci/agp_i810.c
P src/sys/dev/pci/pci_subr.c
P src/sys/dev/pci/pcidevs
P src/sys/dev/pci/pcidevs.h
P src/sys/dev/pci/pcidevs_data.h
P src/sys/dev/pci/pcireg.h
P src/usr.bin/kdump/mkioctls

Updating xsrc tree:


Killing core files:

Running the SUP scanner:
SUP Scan for current starting at Thu Oct 22 04:46:36 2015
SUP Scan for current completed at Thu Oct 22 05:17:56 2015
SUP Scan for mirror starting at Thu Oct 22 05:17:56 2015
SUP Scan for mirror completed at Thu Oct 22 07:19:34 2015




Updating file list:
-rw-rw-r--  1 srcmastr  netbsd  55419074 Oct 22 08:02 ls-lRA.gz

Re: Hanging at shutdown with mystery "file system full" error

[Robert Elz]

Date:Thu, 22 Oct 2015 07:52:06 +0200
From:"Ian D. Leroux" 
Message-ID:  <20151022075206.995f2caa63b153174b7f7...@fastmail.fm>

  | That last part I don't understand, or rather I don't understand
  | why /etc/rc.d/swap1 should worry about that case.

I'll explain what I think the issue is, and then others can correct it...

  | I would have
  | thought that any subsidiary mount point, tmpfs or not, would prevent an
  | unmount of (say) /var.

It would.

  | If the rc system is meant to unmount all
  | filesystems at shutdown time, then it already needs some logic to do so
  | in the right order.

It does (reverse order of mounts).

  | How are tmpfs filesystems special in this regard?

Well

The problem is that it is permitted to swap onto files.   If we did away
with that, there would be no problems to solve.

But since we allow swapping to files (as distinct from disc partitions)
that swapping has to be disabled, before the filesystems on which the
files live can be unmounted.

When that swapping is disabled, anything that was swapped out there needs
to be swapped in again (at this stage, during rc.shutdown processing, the
kernel is not aware that the system is about to terminate, this is all just
using the same facility as any other removal of a swap file/device).

One of the (potentially) big users of space on swap, is files on a tmpfs.
In fact, during shutdown, it is probably the only significant user.

On systems with limited ram, reading all those files into mem can cause
memory exhaustion, and hangs...   That's kind of unfortunate, especially when
you're in a situation where all you are really wanting to do is trash
everything.

So, to avoid that, tmpfs filesystems are forcibly unmounted first, before
swap is disabled, then that user of swap space is gone - if we are really
in the process of shutting down, most user processes should have already been
terminated, so there should be very limited (if any) process consumption of
swap space, so disabling swap should then function normally.

Once swap is disabled (at least swap on files) the filesystems can all be
unmounted (the question of swap on a file on a tmpfs and what would happen to
that I have no idea about, but it is such an absurd concept that I doubt
anyone cares ... it should just be prohibited, and perhaps is.)

At least that's the idea, but /dev on tmpfs kind of screws with this model...

  | My understanding of the not-so-recent change to /etc/rc.d/swap1 is that
  | it is meant to ensure that there is swap space left for swapctl to
  | function.  That seems to me to be orthogonal to the question of
  | ensuring that all filesystems can be unmounted.

It it perhaps a little clearer now (assuming my perceptions about the
problem are correct.)

  | That sounds to me like there are several possibly-unrelated shutdown
  | hangs,

Could be ... or it is also possible that the /dev problem and no space
message you're seeing are co-incidental. and while annoying, not actually
related to the hang you're seeing.

And, please treat my report of a hang as no more than a rumour .. I know
a hang happened to me (once) but I have not investigated at all, and almost
anything might have been the cause.

  | To the extent that read-only-/ with tmpfs-/dev is a reasonable
  | configuration (and at least Joerg and I seem to think so),

Yes, so do I (though devfs would be better) - I didn't mean to suggest 
otherwise, just that tmpfs /dev is not mandatory for a read only root.
(and that since /dev consists of just the directory, and a whole bunch
of inodes, and needs nothing that actually consumes space - or more
than the directory itself, mfs would actually work for it, perhaps
petter than tmpfs ... but that is a whole separate discussion.)

  | then /etc/rc.d/swap1 needs a more precise notion of which filesystems
  | it can safely unmount to make space on swap.

One notion I had was to perhaps add an "permanent" flag to mount.
If set, no umount would ever be able to remove it (with or without -f).
(Of course, kernel shutdown still happens, syncing and marking the
filesystem clean - just as happens with root, the one current filesystem
that cannot be unmounted.)   That would avoid embedding magic into weird
places about what can, and cannot, safely be unmounted.

  | On systems like mine, which have way more swap than they need, it seems
  | practical just to omit the 'umount -aft tmpfs' from swap1_stop(), but
  | that doesn't address the problem that the change was initially meant to
  | solve.

You could certainly do that.   Perhaps replace it with a "rm -rf /tmp/*"
(repeated for each tmpfs that you have - other than /dev, though even
it could probably be cleaned safely that way at shutdown time.)

The rm should be enough to remove anything consuming space (probably needs
to also deal with . files, since rm -fr /tmp itself is probably not safe,
just in case /tmp was not mounted) - there should be no 

Re: Hanging at shutdown with mystery "file system full" error

[Ian D. Leroux]

On Thu, 22 Oct 2015 13:57:25 +0700 Robert Elz  wrote:

> Date:Thu, 22 Oct 2015 07:52:06 +0200
> From:"Ian D. Leroux" 
> Message-ID:  <20151022075206.995f2caa63b153174b7f7...@fastmail.fm>
>   | How are tmpfs filesystems special in this regard?
> 
> Well
> 
> The problem is that it is permitted to swap onto files.   If we did
> away with that, there would be no problems to solve.
>
> [detailed and patient explanation of the interaction between tmpfs
> filesystems and file-backed swap]

Thanks!  That helped a lot.

>   | That sounds to me like there are several possibly-unrelated
>   | shutdown hangs,
> 
> Could be ... or it is also possible that the /dev problem and no space
> message you're seeing are co-incidental. and while annoying, not
> actually related to the hang you're seeing.

Ok, so let's separate the issues.

1- With tmpfs-mounted /dev, /etc/rc.d/swap1 attempts to umount -f /dev
before userland is finished at shutdown time.  Whether or not this
causes the hang and error message I see, this is clearly not a desirable
outcome.  I think we understand what the problem is, and there are
workarounds for my case and most others I can think of, although it's
not clear what the right general fix is.  I'll file a PR for this, and
further discussion can go there or in another thread.

2- The system will sometimes hang after printing a kernel error message
of the general form "on /var: file system full", despite the fact
that /var is not full and that the immediate trigger for the hang, at
least in my case and apparently also in the case of Robert Swindells,
is unmounting a tmpfs filesystem that has nothing to do with /var.

To investigate the second  issue we need a way of triggering the hang
that is not as manifestly crazy as removing /dev, which seems to be the
only way I've ever triggered it (Robert Swindells seems to have found
another way, though it's not clear what).  I'll try populating an
on-disk /dev and then seeing if I still get a hang at shutdown.

--
IDL

Re: Hanging at shutdown with mystery "file system full" error

[D'Arcy J.M. Cain]

On Thu, 22 Oct 2015 01:12:51 +0200
Joerg Sonnenberger  wrote:
> > Have you considered the possibility that having your devices on a
> > mounted FS is just asking for trouble?  I'm not sure but I think
> > that I would be surprised if I made all my devices suddenly
> > disappear and it didn't hang.  Why do you have it on a mounted FS
> > anyway?
> 
> As written, that's done automatically by init if /dev is not populated
> with devices. That is a common setup for ramdisks and read-only root
> installations. It must not be broken.

I see.  So how does the system deal with devices suddenly disappearing
during shutdown?  Also, the OP is not using a R/O system (it's a
laptop) so if /dev is on a tmpfs then he must be doing it manually in
his fstab, right?  That's not the same as init doing it automatically.

-- 
D'Arcy J.M. Cain 
http://www.NetBSD.org/ IM:da...@vex.net

Re: NFS related panic? (was: Re: Killing a zombie process?)

[Rhialto]

This problem is very repeatable, usually within a few hours, just now it
happened within half an hour.

It seems to me that somehow the nfs_reqq list gets corrupted. Then
either there is a crash when traversing it in nfs_timer() (occurring in
nfs_sigintr() due to being called with a bogus pointer), or there is a
hang when one of the NFS requests gets lost and never retried.

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert  -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl-- 'this bath is too hot.'


signature.asc
Description: PGP signature

Possible error in kern_sysctl.c

[Paul Goyette]

In the routine sysctl_create(), when we're adding a new child to an
existing node, we may have to move some existing entries.  If so, we
than have to update the parent pointers of any children whose parent
was moved.  The code to accomplish this is at line 1142

/*
 * insert new node data
 */
if (at < pnode->sysctl_clen) {
int t;

/*
 * move the nodes that should come after the new one
 */
memmove([at + 1], [at],
(pnode->sysctl_clen - at) * sizeof(struct sysctlnode));
memset([at], 0, sizeof(struct sysctlnode));
node[at].sysctl_parent = pnode;
/*
 * and...reparent any children of any moved nodes
 */

for (ni = at; ni <= pnode->sysctl_clen; ni++)

if (node[ni].sysctl_child != NULL)
for (t = 0; t < node[ni].sysctl_csize; t++)
node[ni].sysctl_child[t].sysctl_parent =
[ni];
}


At the tagged >>> line, we start processing at the entry at which we
just inserted the new node, and NOT at the first possibly-moved entry!

If the new entry has a non-NULL sysctl_child pointer we might update
some stuff that shouldn't be touched.  (Note that the new entry's
sysctl_child pointer is not set to NULL until we get to line 1196 in
the same function.)

It seems to me that the for loop on the tagged line should start with
ni = at + 1

This could potentially be the bug I've been tracking where the values
added to a sysctllog contain the wrong mib-name values, preventing
proper operation of sysctl_teardown().


Comments?



+--+--+-+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:   |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org  |
+--+--+-+

Re: Hanging at shutdown with mystery "file system full" error

[Robert Swindells]

"D'Arcy J.M. Cain"  wrote:
>On Thu, 22 Oct 2015 01:12:51 +0200
>Joerg Sonnenberger  wrote:
>> > Have you considered the possibility that having your devices on a
>> > mounted FS is just asking for trouble?  I'm not sure but I think
>> > that I would be surprised if I made all my devices suddenly
>> > disappear and it didn't hang.  Why do you have it on a mounted FS
>> > anyway?
>> 
>> As written, that's done automatically by init if /dev is not populated
>> with devices. That is a common setup for ramdisks and read-only root
>> installations. It must not be broken.
>
>I see.  So how does the system deal with devices suddenly disappearing
>during shutdown?  Also, the OP is not using a R/O system (it's a
>laptop) so if /dev is on a tmpfs then he must be doing it manually in
>his fstab, right?  That's not the same as init doing it automatically.

The OP did state that the root filesystem is read-only.

It should be easy enough to mount root writable, populate /dev on this
filesystem then switch back to mounting it read-only.

There must be more than one way that a tmpfs can be active at the point
where it is forceably unmounted though. I don't have /dev on tmpfs and
get exactly the same error message at shutdown.

Robert Swindells