Re: svn commit: r326809 - head/sys/dev/cardbus

[Eugene Grosbein]

On Thu, Dec 14, 2017 at 2:36 PM, Eugene Grosbein > wrote:
> 
> - zfsloader(8) failing to find any ZFS pool after zfsboot(8) successfully
> loaded and started zfsload(8) from zpool (PR pending, need to collect 
> more info)

I've discovered the source of the problem. Here is scenario:

1. Take disk prevously used for FreeBSD. Erase its first and last megabytes
with dd to start from scratch: dd if=/dev/zero bs=1m count=1 of=... etc.

2. Create MBR with gpart, add two "freebsd" slices: first one for 8GB swap,
second one for ZFS (rest of space), make second slice active.

3. Install boot-loaders: /boot/boot0 (or /boot/mbr, it does not matter)
with gpart to the MBR and zfsboot with dd to second second slice just
as zfsboot(8) manual page instructs. Note that this does NOT change contents
of *second* 512-bytes block of this slice.

4. Create zpool using whole second slice, install FreeBSD 11.1/amd64 there and 
try to boot it.

MBR loader successfully uses second slice to load and run zfsboot.
zfsboot does its job just fine running zfsloader from ZFS
and passes needed ZFS it to zfsloader.

zfsloader uses libstand(3) trying to find its pool: zfs_probe_partition()
successfully calls libstand's version of open("disk0s1:", O_RDONLY) and skips it
as there is no ZFS. Then, it tries to open("disk0s2:", O_RDONLY) and it fails
returning -1 with errno==2 (ENOENT), so zfsloader fails.

src/tools/tools/bootparttest shows that libstand looks at *second* sector of 
the slice
and sees leftover of (now non-existing) BSD label there.
And for some reason it prevents zfsloader from using such slice.

I "fixed" this by booting from USB flash drive and dd-ing second sector with 
zeroes
and now zfsloader runs just fine and starts installed FreeBSD 11 from the pool.

This seems to me as bug in libstand, isn't it?


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326809 - head/sys/dev/cardbus

[Eugene Grosbein]

On 15.12.2017 13:42, Warner Losh wrote:
> 
> 
> On Thu, Dec 14, 2017 at 11:02 PM, Eugene Grosbein  > wrote:
> 
> 15.12.2017 6:50, Warner Losh wrote:
> >
> >
> > On Thu, Dec 14, 2017 at 5:00 PM, Eugene Grosbein    >> wrote:
> >
> > 14.12.2017 23:27, Warner Losh wrote:
> >
> > > - zfsloader(8) failing to find any ZFS pool after zfsboot(8) 
> successfully
> > > loaded and started zfsload(8) from zpool (PR pending, need to 
> collect more info)
> > >
> > >
> > > GPT or MBR?
> >
> > MBR, no GELI used.
> > when you update, you're updating both halves of the loader, right?
> 
> I do not get it, what are "halves of the loader"?
> I know zfsboot should be installed in parts but it finds boot pool just 
> fine
> and I do not update it. As for zfsloader, I install it with to 
> /boot/zfsloader
> with simple "make install" command.
> 
> 
> So you are using the old zfsboot then?
> 
> And if you didn't do something like:
> 
> dd if=${dst}/boot/zfsboot of=/tmp/zfsboot1 count=1
> gpart bootcode -b /tmp/zfsboo1 ${dev}s${s}
> sysctl kern.geom.debugflags=0x10
> dd if=${dst}/boot/zfsboot iseek=1 seek=1024 of=/dev/${dev}s${s}
> sysctl kern.geom.debugflags=0x0
> 
> then you're using the new zfsloader with old zfsboot blocks. Which should 
> work just fine, but is apparently failing.

In fact, I'v just started using ZFS recently and I've not updates my working 
tree since then,
so zfsboot and zfsloader were built using same sources, amd64 stable/11 r322531.

My previous debugging (using added printf's) shows that's zio_checksum_verify()
from src/sys/cddl/boot/zfs/zfssubr.c always fails when zfsloader reads ZFS.
Meantime, zpool scrub finds no errors on this pool when I boot using USB 
flash/UFS.

I've just added LOADER_NO_GELI_SUPPORT= to my /etc/src.conf, reverted all local
(debugging) changes to /usr/src/sys/boot, did "make clean all install" there
and tried to boot using rebuilt zfsloader again (it it 44KB less now than 
zfsloader.old).
No changes, still fails same way. And I do not have r326583.

___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326809 - head/sys/dev/cardbus

[Warner Losh]

On Thu, Dec 14, 2017 at 11:02 PM, Eugene Grosbein 
wrote:

> 15.12.2017 6:50, Warner Losh wrote:
> >
> >
> > On Thu, Dec 14, 2017 at 5:00 PM, Eugene Grosbein  > wrote:
> >
> > 14.12.2017 23:27, Warner Losh wrote:
> >
> > > - zfsloader(8) failing to find any ZFS pool after zfsboot(8)
> successfully
> > > loaded and started zfsload(8) from zpool (PR pending, need to
> collect more info)
> > >
> > >
> > > GPT or MBR?
> >
> > MBR, no GELI used.
> > when you update, you're updating both halves of the loader, right?
>
> I do not get it, what are "halves of the loader"?
> I know zfsboot should be installed in parts but it finds boot pool just
> fine
> and I do not update it. As for zfsloader, I install it with to
> /boot/zfsloader
> with simple "make install" command.


So you are using the old zfsboot then?

And if you didn't do something like:

dd if=${dst}/boot/zfsboot of=/tmp/zfsboot1 count=1
gpart bootcode -b /tmp/zfsboo1 ${dev}s${s}
sysctl kern.geom.debugflags=0x10
dd if=${dst}/boot/zfsboot iseek=1 seek=1024 of=/dev/${dev}s${s}
sysctl kern.geom.debugflags=0x0

then you're using the new zfsloader with old zfsboot blocks. Which should
work just fine, but is apparently failing.

Warner
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326809 - head/sys/dev/cardbus

[Eugene Grosbein]

15.12.2017 6:50, Warner Losh wrote:
> 
> 
> On Thu, Dec 14, 2017 at 5:00 PM, Eugene Grosbein  > wrote:
> 
> 14.12.2017 23:27, Warner Losh wrote:
> 
> > - zfsloader(8) failing to find any ZFS pool after zfsboot(8) 
> successfully
> > loaded and started zfsload(8) from zpool (PR pending, need to 
> collect more info)
> >
> >
> > GPT or MBR?
> 
> MBR, no GELI used.
> when you update, you're updating both halves of the loader, right?

I do not get it, what are "halves of the loader"?
I know zfsboot should be installed in parts but it finds boot pool just fine
and I do not update it. As for zfsloader, I install it with to /boot/zfsloader
with simple "make install" command.

___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326809 - head/sys/dev/cardbus

[Warner Losh]

On Thu, Dec 14, 2017 at 5:00 PM, Eugene Grosbein  wrote:

> 14.12.2017 23:27, Warner Losh wrote:
>
> > - zfsloader(8) failing to find any ZFS pool after zfsboot(8)
> successfully
> > loaded and started zfsload(8) from zpool (PR pending, need to
> collect more info)
> >
> >
> > GPT or MBR?
>
> MBR, no GELI used.


when you update, you're updating both halves of the loader, right?


>
> > If you disable GELI support, it will work. If you roll back to r326583
> it will work.
> >
> > I'm tracking down the breakage related to my efforts to get the loader
> in shape for a gentle transition to lua. It's either GELI related or size
> related.
>
> I'll check it out next day, thanks!
>

It should be better soon...

Warner
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326809 - head/sys/dev/cardbus

[Eugene Grosbein]

14.12.2017 23:27, Warner Losh wrote:

> - zfsloader(8) failing to find any ZFS pool after zfsboot(8) successfully
> loaded and started zfsload(8) from zpool (PR pending, need to collect 
> more info)
> 
> 
> GPT or MBR?

MBR, no GELI used.
 
> If you disable GELI support, it will work. If you roll back to r326583 it 
> will work.
> 
> I'm tracking down the breakage related to my efforts to get the loader in 
> shape for a gentle transition to lua. It's either GELI related or size 
> related.

I'll check it out next day, thanks!

___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326809 - head/sys/dev/cardbus

[Warner Losh]

On Thu, Dec 14, 2017 at 2:36 PM, Eugene Grosbein  wrote:

> - zfsloader(8) failing to find any ZFS pool after zfsboot(8) successfully
> loaded and started zfsload(8) from zpool (PR pending, need to collect more
> info)
>

GPT or MBR?

If you disable GELI support, it will work. If you roll back to r326583 it
will work.

I'm tracking down the breakage related to my efforts to get the loader in
shape for a gentle transition to lua. It's either GELI related or size
related.

Warner
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326809 - head/sys/dev/cardbus

[Eugene Grosbein]

On 14.12.2017 20:38, Alexey Dokuchaev wrote:
> On Thu, Dec 14, 2017 at 02:36:48AM +0700, Eugene Grosbein wrote:
>> 14.12.2017 1:24, Alexey Dokuchaev wrote:
>> ...
>>> One does not tweak FreeBSD, it just works. (tm)
>>
>> Hmm. Do you really think so?
> 
> I do.
> 
>> I can assure you this is not true.  There are numerous ways to take
>> down untweaked FreeBSD system.
> 
> This means that there are bugs that should be fixed.

Sure.

> Do you have PR numbers?

To start with:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223824
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223803
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204700

Etc., but I should not recite our Bugzilla here.

And that hilaroius "75-frames" NFS-related panic requiring tweaks:
https://lists.freebsd.org/pipermail/freebsd-stable/2017-July/087477.html

There are problems other kinds of problems, that is:

- a need to increase kern.cam.boot_delay/kern.cam.scsi_delay (or similar newer 
tweaks)
to make boot happen;

- firewall_nat_enable="YES" with GENERIC kernel requires manual loading of 
modules
like alias_ftp.ko or alias_pptp.ko or else NAT would be useless for such 
transit traffic;

- net.isr.maxthreads may be erronously set to 1 by default affecting performance
and requiring manual tweak;

- zfsloader(8) failing to find any ZFS pool after zfsboot(8) successfully
loaded and started zfsload(8) from zpool (PR pending, need to collect more info)

- net.graph.maxdata/net.graph.maxalloc do not auto-scale resulting in DoS
and lots of other problems within NETGRAPH...

I use FreeBSD in many diverse environments and if I strain my memory, I can 
remember more.
(NFS itself is full of surprises...)

___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326809 - head/sys/dev/cardbus

[Alexey Dokuchaev]

On Thu, Dec 14, 2017 at 02:36:48AM +0700, Eugene Grosbein wrote:
> 14.12.2017 1:24, Alexey Dokuchaev wrote:
> ...
> > One does not tweak FreeBSD, it just works. (tm)
> 
> Hmm. Do you really think so?

I do.

> I can assure you this is not true.  There are numerous ways to take
> down untweaked FreeBSD system.

This means that there are bugs that should be fixed.  Do you have PR
numbers?

./danfe
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326809 - head/sys/dev/cardbus

[Eugene Grosbein]

14.12.2017 1:24, Alexey Dokuchaev wrote:

>>> I'm a plain workstation user with X11+browser+torrent+quake2+you-name-it
>>> apps, PAE-less, ZFS-less, and I don't want to get troubles due to r326758.
>>
>> Add kern.kstack_size=2 to /boot/loader.conf of your workstation now
>> and you will notice no difference.
> 
> FreeBSD is largely known for its sane defaults.  Users should not touch
> those config files, especially if things worked for years without any
> /boot/loader.conf tweaking.  If there are cases of kernel stack pressure
> like your script had revealed, they should be fixed, and defaults stay
> as they are now.

I agree they should be fixed. I don't see they fixed soon (have not for years 
and there too many)
and until then FreeBSD/i386 should panic due to incoming SCTP/IPV6 packet?

> One does not tweak FreeBSD, it just works. (tm)

Hmm. Do you really think so? I can assure you this is not true.
There are numerous ways to take down untweaked FreeBSD system.

___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326809 - head/sys/dev/cardbus

[Alexey Dokuchaev]

On Thu, Dec 14, 2017 at 01:16:27AM +0700, Eugene Grosbein wrote:
> 14.12.2017 1:08, Alexey Dokuchaev пишет:
> > On Thu, Dec 14, 2017 at 12:48:17AM +0700, Eugene Grosbein wrote:
> >> ...
> >> I don't understand why you want to backout that. It changed nothing for
> >> amd64.  An i386 is still vulnerable to double faults just because of a
> >> network packet processing path can overflow kstack for the GENERIC kernel.
> > 
> > The reason (or shall I say concern) was raised by kib@, as quoted:
> > 
> >> Plain workstation use, like X11+browser+editor+some other programs easily
> >> allocates 1000+ threads.  It was still possible to use 32bit x86 for that,
> >> of course in max memory config without PAE, and without ZFS.  Add some
> >> load that involves network, for instance torrent client, to establish the
> >> pressure on KVA.
> >> I am almost sure that users would get troubles now.
> > 
> > I'm a plain workstation user with X11+browser+torrent+quake2+you-name-it
> > apps, PAE-less, ZFS-less, and I don't want to get troubles due to r326758.
> 
> Add kern.kstack_size=2 to /boot/loader.conf of your workstation now
> and you will notice no difference.

FreeBSD is largely known for its sane defaults.  Users should not touch
those config files, especially if things worked for years without any
/boot/loader.conf tweaking.  If there are cases of kernel stack pressure
like your script had revealed, they should be fixed, and defaults stay
as they are now.

One does not tweak FreeBSD, it just works. (tm)

./danfe
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326809 - head/sys/dev/cardbus

[Eugene Grosbein]

14.12.2017 1:08, Alexey Dokuchaev пишет:
> On Thu, Dec 14, 2017 at 12:48:17AM +0700, Eugene Grosbein wrote:
>> ...
>> I don't understand why you want to backout that. It changed nothing for
>> amd64.  An i386 is still vulnerable to double faults just because of a
>> network packet processing path can overflow kstack for the GENERIC kernel.
> 
> The reason (or shall I say concern) was raised by kib@, as quoted:
> 
>> Plain workstation use, like X11+browser+editor+some other programs easily
>> allocates 1000+ threads.  It was still possible to use 32bit x86 for that,
>> of course in max memory config without PAE, and without ZFS.  Add some
>> load that involves network, for instance torrent client, to establish the
>> pressure on KVA.
>> I am almost sure that users would get troubles now.
> 
> I'm a plain workstation user with X11+browser+torrent+quake2+you-name-it
> apps, PAE-less, ZFS-less, and I don't want to get troubles due to r326758.

Add kern.kstack_size=2 to /boot/loader.conf of your workstation now
and you will notice no difference.


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326809 - head/sys/dev/cardbus

[Alexey Dokuchaev]

On Thu, Dec 14, 2017 at 12:48:17AM +0700, Eugene Grosbein wrote:
> ...
> I don't understand why you want to backout that. It changed nothing for
> amd64.  An i386 is still vulnerable to double faults just because of a
> network packet processing path can overflow kstack for the GENERIC kernel.

The reason (or shall I say concern) was raised by kib@, as quoted:

> Plain workstation use, like X11+browser+editor+some other programs easily
> allocates 1000+ threads.  It was still possible to use 32bit x86 for that,
> of course in max memory config without PAE, and without ZFS.  Add some
> load that involves network, for instance torrent client, to establish the
> pressure on KVA.
> I am almost sure that users would get troubles now.

I'm a plain workstation user with X11+browser+torrent+quake2+you-name-it
apps, PAE-less, ZFS-less, and I don't want to get troubles due to r326758.

./danfe
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326809 - head/sys/dev/cardbus

[Eugene Grosbein]

13.12.2017 20:38, Rodney W. Grimes wrote:

> That I can not answer, but I can say I have just found the problem
> is NOT limited to i386, we can rather quickly blow up an amd64 system
> running a dozen or so VM's.
> 
> My bhyve host tossed a stack of these out last night:
> vm_thread_new: kstack allocation failed
> vm_thread_new: kstack allocation failed
> vm_thread_new: kstack allocation failed
> vm_thread_new: kstack allocation failed
> vm_thread_new: kstack allocation failed
> vm_thread_new: kstack allocation failed
> vm_thread_new: kstack allocation failed
> vm_thread_new: kstack allocation failed
> vm_thread_new: kstack allocation failed
> vm_thread_new: kstack allocation failed
> 
> ZFS has been tuned to leave 1.2* my total VM allocations free space
> of memory and I only had 10 out of 16 vm's running last night, so
> there is tons of free memory.  This is probalby KVA space starvation,
> though I thought that was pretty much a non issue on amd64.
> 
> I do think we should back out r326758 sooner rather than later,
> and if it got MFC'd or flagged for MFC kill that right now.

I don't understand why you want to backout that. It changed nothing for amd64.
An i386 is still vulnerable to double faults just because of a network packet
processing path can overflow kstack for the GENERIC kernel.

If one has stripped-down kernel or just uses FreeBSD within safe environment
preventing it from such packets, there is still loader.conf to change 
kstack_pages
to any desired value for such special appliances that need lots of threads for 
i386.

And I don't think someone should expect to run dozen of VMs within i386 kernel
without some tuning. So please leave r326758 alone as it hardens FreeBSD in 
default setup
and this is more important.


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326809 - head/sys/dev/cardbus

[Rodney W. Grimes]

> > On Tue, Dec 12, 2017 at 12:39:38PM -0800, Rodney W. Grimes wrote:
> > > > New Revision: 326809
> > > > URL: https://svnweb.freebsd.org/changeset/base/326809
> > > > 
> > > > Log:
> > > >   1k objects on the stack are a bad idea. While it's likely safe in this
> > > >   context, it's also safe to allocate the memory and free it instead.
> > > >   
> > > >   Noticed by: Eugene Grosbein's script
> > > 
> > > YEA!!!  One down, 20 to go and then see how the kstack issue does?
> > > 
> > > And thank you for quickly fixing this.
> > 
> > It's very promising to see debloat-type of work having started.  On the
> > related note, what is current consensus with r326758, is it going to be
> > backed out and stack issues investigated and fixed?  I am worried since
> > kib@ had mentioned that he's "almost sure that [32-bit x86 workstation]
> > users would get troubles now" [*] and I'm one of them.
> 
> That I can not answer, but I can say I have just found the problem
> is NOT limited to i386, we can rather quickly blow up an amd64 system
> running a dozen or so VM's.
> 
> My bhyve host tossed a stack of these out last night:
> vm_thread_new: kstack allocation failed
> vm_thread_new: kstack allocation failed
> vm_thread_new: kstack allocation failed
> vm_thread_new: kstack allocation failed
> vm_thread_new: kstack allocation failed
> vm_thread_new: kstack allocation failed
> vm_thread_new: kstack allocation failed
> vm_thread_new: kstack allocation failed
> vm_thread_new: kstack allocation failed
> vm_thread_new: kstack allocation failed

Ok, ignore this, the console was connected to a vm, these
messages are infact from a vm running i386 11.1, just upgraded
from 11.0 to 11.1 so even between that step there is a regression
as I did not have these on the 11.0 system.

> ZFS has been tuned to leave 1.2* my total VM allocations free space
> of memory and I only had 10 out of 16 vm's running last night, so
> there is tons of free memory.  This is probalby KVA space starvation,
> though I thought that was pretty much a non issue on amd64.
> 
> I do think we should back out r326758 sooner rather than later,
> and if it got MFC'd or flagged for MFC kill that right now.
> 
> A regression test would also be nice that can push the system
> close to what the usable limit is, and that test should be run
> in a CI situtaion to make sure we keep it running.  This is a
> non trivial to do though as there are many work load patterns
> that can push the kernel towards stack space limits.
> 
> -- 
> Rod Grimes rgri...@freebsd.org
-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326809 - head/sys/dev/cardbus

[Rodney W. Grimes]

> On Tue, Dec 12, 2017 at 12:39:38PM -0800, Rodney W. Grimes wrote:
> > > New Revision: 326809
> > > URL: https://svnweb.freebsd.org/changeset/base/326809
> > > 
> > > Log:
> > >   1k objects on the stack are a bad idea. While it's likely safe in this
> > >   context, it's also safe to allocate the memory and free it instead.
> > >   
> > >   Noticed by: Eugene Grosbein's script
> > 
> > YEA!!!  One down, 20 to go and then see how the kstack issue does?
> > 
> > And thank you for quickly fixing this.
> 
> It's very promising to see debloat-type of work having started.  On the
> related note, what is current consensus with r326758, is it going to be
> backed out and stack issues investigated and fixed?  I am worried since
> kib@ had mentioned that he's "almost sure that [32-bit x86 workstation]
> users would get troubles now" [*] and I'm one of them.

That I can not answer, but I can say I have just found the problem
is NOT limited to i386, we can rather quickly blow up an amd64 system
running a dozen or so VM's.

My bhyve host tossed a stack of these out last night:
vm_thread_new: kstack allocation failed
vm_thread_new: kstack allocation failed
vm_thread_new: kstack allocation failed
vm_thread_new: kstack allocation failed
vm_thread_new: kstack allocation failed
vm_thread_new: kstack allocation failed
vm_thread_new: kstack allocation failed
vm_thread_new: kstack allocation failed
vm_thread_new: kstack allocation failed
vm_thread_new: kstack allocation failed

ZFS has been tuned to leave 1.2* my total VM allocations free space
of memory and I only had 10 out of 16 vm's running last night, so
there is tons of free memory.  This is probalby KVA space starvation,
though I thought that was pretty much a non issue on amd64.

I do think we should back out r326758 sooner rather than later,
and if it got MFC'd or flagged for MFC kill that right now.

A regression test would also be nice that can push the system
close to what the usable limit is, and that test should be run
in a CI situtaion to make sure we keep it running.  This is a
non trivial to do though as there are many work load patterns
that can push the kernel towards stack space limits.

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326809 - head/sys/dev/cardbus

[Warner Losh]

On Wed, Dec 13, 2017 at 6:54 AM, Alexey Dokuchaev  wrote:

> On Tue, Dec 12, 2017 at 12:39:38PM -0800, Rodney W. Grimes wrote:
> > > New Revision: 326809
> > > URL: https://svnweb.freebsd.org/changeset/base/326809
> > >
> > > Log:
> > >   1k objects on the stack are a bad idea. While it's likely safe in
> this
> > >   context, it's also safe to allocate the memory and free it instead.
> > >
> > >   Noticed by: Eugene Grosbein's script
> >
> > YEA!!!  One down, 20 to go and then see how the kstack issue does?
> >
> > And thank you for quickly fixing this.
>
> It's very promising to see debloat-type of work having started.  On the
> related note, what is current consensus with r326758, is it going to be
> backed out and stack issues investigated and fixed?  I am worried since
> kib@ had mentioned that he's "almost sure that [32-bit x86 workstation]
> users would get troubles now" [*] and I'm one of them.
>

I have fixes for 2 or 3 cam ones, and plans to fix another 3 or 4 of the
remaining ones which are easy.

Warner
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326809 - head/sys/dev/cardbus

[Alexey Dokuchaev]

On Tue, Dec 12, 2017 at 12:39:38PM -0800, Rodney W. Grimes wrote:
> > New Revision: 326809
> > URL: https://svnweb.freebsd.org/changeset/base/326809
> > 
> > Log:
> >   1k objects on the stack are a bad idea. While it's likely safe in this
> >   context, it's also safe to allocate the memory and free it instead.
> >   
> >   Noticed by: Eugene Grosbein's script
> 
> YEA!!!  One down, 20 to go and then see how the kstack issue does?
> 
> And thank you for quickly fixing this.

It's very promising to see debloat-type of work having started.  On the
related note, what is current consensus with r326758, is it going to be
backed out and stack issues investigated and fixed?  I am worried since
kib@ had mentioned that he's "almost sure that [32-bit x86 workstation]
users would get troubles now" [*] and I'm one of them.

./danfe

[*] https://lists.freebsd.org/pipermail/svn-src-head/2017-December/107237.html
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326809 - head/sys/dev/cardbus

[Rodney W. Grimes]

> Author: imp
> Date: Tue Dec 12 20:22:09 2017
> New Revision: 326809
> URL: https://svnweb.freebsd.org/changeset/base/326809
> 
> Log:
>   1k objects on the stack are a bad idea. While it's likely safe in this
>   context, it's also safe to allocate the memory and free it instead.
>   
>   Noticed by: Eugene Grosbein's script

YEA!!!  One down, 20 to go and then see how the kstack issue does?

And thank you for quickly fixing this.

> Modified:
>   head/sys/dev/cardbus/cardbus_cis.c
> 
> Modified: head/sys/dev/cardbus/cardbus_cis.c
> ==
> --- head/sys/dev/cardbus/cardbus_cis.cTue Dec 12 20:15:57 2017
> (r326808)
> +++ head/sys/dev/cardbus/cardbus_cis.cTue Dec 12 20:22:09 2017
> (r326809)
> @@ -583,7 +583,7 @@ int
>  cardbus_parse_cis(device_t cbdev, device_t child,
...

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"