svn commit: r327379 - head/sys/isa
Warner Losh
imp at bsdimp.com
Sat Dec 30 21:27:43 UTC 2017
On Sat, Dec 30, 2017 at 1:56 PM, Rodney W. Grimes <
freebsd at pdx.rh.cn85.dnsmgr.net> wrote:
> > On Sat, Dec 30, 2017 at 10:09 AM, Rodney W. Grimes <
> > freebsd at pdx.rh.cn85.dnsmgr.net> wrote:
> >
> > > [ Charset UTF-8 unsupported, converting... ]
> > > > On Sat, Dec 30, 2017 at 8:27 AM, Rodney W. Grimes <
> > > > freebsd at pdx.rh.cn85.dnsmgr.net> wrote:
> > > >
> > > > > [ Charset UTF-8 unsupported, converting... ]
> > > > > > Author: imp
> > > > > > Date: Sat Dec 30 08:16:31 2017
> > > > > > New Revision: 327379
> > > > > > URL: https://svnweb.freebsd.org/changeset/base/327379
> > > > > >
> > > > > > Log:
> > > > > > On further testing on actual machines with this hardware, we
> should
> > > > > > only warn for devices that are attached. Add missing \n.
> > > > > >
> > > > > > Modified:
> > > > > > head/sys/isa/isa_common.c
> > > > > >
> > > > > > Modified: head/sys/isa/isa_common.c
> > > > > > ============================================================
> > > > > ==================
> > > > > > --- head/sys/isa/isa_common.c Sat Dec 30 07:59:32 2017
> > > (r327378)
> > > > > > +++ head/sys/isa/isa_common.c Sat Dec 30 08:16:31 2017
> > > (r327379)
> > > > > > @@ -573,9 +573,10 @@ isa_probe_children(device_t dev)
> > > > > >
> > > > > > err = device_probe_and_attach(child);
> > > > > > if (err == 0 && idev->id_vendorid == 0 &&
> > > > > > - strcmp(kern_ident, "GENERIC") == 0)
> > > > > > + strcmp(kern_ident, "GENERIC") == 0 &&
> > > > > > + device_is_attached(child))
> > > > > > device_printf(child,
> > > > > > - "non-PNP ISA device will be removed
> from
> > > > > GENERIC in FreeBSD 12.");
> > > > > > + "non-PNP ISA device will be removed
> from
> > > > > GENERIC in FreeBSD 12.\n");
> > > > >
> > > > > Hat: RE
> > > > >
> > > > > Do you plan to give this notice in 11.x? (Technically a bit late,
> > > > > it should of been in 11.0).
> > > > >
> > > >
> > > > Yes. It will be MFC'd soon. Of course it should have happened in
> 11.0,
> > > but
> > > > it didn't. But this notice is just about things in GENERIC. Not their
> > > > actual removal (though most of them will be removed). The notice is
> here
> > > > because GENERIC is going to be cut to the bone once the PNP stuff I'm
> > > > working on makes it viable to have all drivers (well, most) kld
> loaded.
> > > The
> > > > only ones that will affect users, though, are the ones that are for
> > > hinted
> > > > devices which will have no autoloading. Hence this warning.
> > >
> > > Thanks for claifying.
> > >
> > > >
> > > > > As giving it in 12.0 wont happen if you remove it in 12. Ie, as
> you
> > > > > have stated you want to remove this before we branch 12.0, if you
> do
> > > > > that this notice well never be seen by the users. Or well, they
> might
> > > > > get the notice, but the drivers well have already been removed.
> > > > >
> > > > > Or do you want to give notice in 12.* that it is being removed in
> 13.0.
> > > > > And that is not supporting these for 10 years, as 12.x should be
> EOL
> > > > > in a bit over 5 years from now if we cut in early 2018 which I
> believe
> > > > > to be the current target.
> > > > >
> > > >
> > > > No. All non-PNP ISA devices will be removed from GENERIC in 12. That
> is,
> > > if
> > > > they are still in the tree. A number will simply be gone, however.
> I'll
> > > be
> > > > putting warnings in those drivers soon. It would have been ideal had
> we
> > > > done so earlier, but we didn't. Simple lack of notice, however, isn't
> > > going
> > > > to keep things in the tree. The following drivers will be removed in
> 12:
> > > > aha, adv, adw, bt, aic, ct, dpt, ncv, nsp, stg, mse, joy, cm and
> likely
> > > cx
> > > > and rx. arcnet too will be removed. Still need to check on dangling
> > > > references old TTY code as well that hasn't built in FreeBSD 8. This
> list
> > > > has circulated before, and I'll be codifying a run-time warning into
> all
> > > > these drivers on attach, plus getting a head-start on what to remove
> in
> > > 13.
> > >
> > > Many of those listed devices, though they have an ISA device, they also
> > > support pci variants. I didnt check all of them, but I know from usage
> > > that the bt and dpt drivers support PCI pnp cards just fine.
> > > So is this more than just ISA axeing?
> >
> >
> > adv, adw, bt, ncv and stg did have PCI variants. They are all old
> parallel
> ^^^ do?
>
> > scsi cards that are no longer relevant. All but adw only supported SCSI 1
> > speeds and an 8-bit width. adw did support wide SCSI (aka 16-bit), but
> it's
> > still a fairly low-level device, but was an unpopular card back in the
> day.
>
> Um, this is what bothers me when this stuff comes up, claims that are
> simply false are often made:
> Adapter Bus Commands Description
> BT-948 PCI 192 Ultra SCSI-3
> BT-958 PCI 192 Wide Ultra SCSI-3
> BT-958D PCI 192 Wide Differential Ultra SCSI-3
>
> I am almost certain that the dpt family also has similiar
> capabitlites.
I stand corrected. I know I cloned the buslogic driver to make the aha
driver, which is definitely isa only.
I just wonder how many of these units we have actually deployed still...
> This was the list that jhb circulated about a year ago. I'm just trying to
> > formalize it in case something that's on it that shouldn't be.
>
> I am fine with axeing the ISA portions of these drivers, but for at
> least the bt and dpt famility I believe that the PCI pnp driver should
> continue to live.
Fair enough, I guess. I'll remove them from the list to make it go down
more easily.
> > FreeBSD has grown large. While you can still boot it on that old 32MB
> > > > machine, you really want 128MB or more to do anything useful. You
> need at
> > > > least 2GB or a heck of a lot of swap to self-host. We should simply
> be
> > > > removing the really old stuff that wouldn't be on a machine that
> size.
> > > > Expect more announcements like this to be coming soon from the people
> > > that
> > > > have been taking are of and feeding this old stuff for too long. If
> we
> > > cut
> > > > with the 128MB criteria, the list would be much, much longer, and the
> > > cuts
> > > > much deeper.
> > >
> > > I have a large pile of VM's running in 64MB, and only have to bump to
> 128MB
> > > when I load a GENERIC, which that only became an issue with 11.x.
> These
> > > 64MB vm's are running with out swap and 12MB of free memory.
> > >
> > > We get really fun failures trying to boot GENERIC on a 12 snapshot with
> > > even 128MB due to the WITNESS/DEBUG bloat.
> > >
> >
> > And a bazillion drivers you don't need taking up 20MB in GENERIC!
> Yes, I really do like your devmatch thing that allows us to remove
> many of these from GENERIC and just load them. And I think more is
> loadable than some realize. Technically since loader can load a
> device driver and a filesystem that code doesnt need to be there
> either. As a case in point the default ZFS install does not have
> ZFS in the kernel, it is loaded at boot time. The same -could-
> be done with UFS.
>
> > PLEASE again, do not dismiss "32MB" as old machines, this is a VERY real
> > > and ideal situation for those deploying mass VM instances.
> >
> >
> > 32MB is a very different experience than 64MB. Even with a kernel that's
> > stripped to the bone, you're doing good to have 18MB free in single user
> > and I've not been able to make it to a login prompt yet.... But a VM is
> > quite different than actual hardware.... Please don't get the two
> confused.
>
> -r-xr-xr-x 1 root wheel 6148944 Nov 10 02:01 /boot/kernel/kernel
> # uname -a
> FreeBSD ns1.rh.CN85.dnsmgr.net 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1
> #0: Fri Nov 10 02:01:56 UTC 2017 root at bld-11.0-p1-i386.dnsmgr.
> net:/A/src/sys/i386/compile/CUSTOMVB i386
> And this is just stripped, not stripped to the bone.
>
Right. I have similar (size says 5.6MB), and have 18MB free on my real P150
hardware with 32MB.
> Hypervisor: Origin = "bhyve bhyve "
> real memory = 67108864 (64 MB)
> avail memory = 55230464 (52 MB)
> Event timer "LAPIC" quality 600
>
> And up multiuser it still has 15MB of free memory, let me boot single
> user....
>
So that's similar to what I'm seeing. But this is for a 64MB machine. 15 -
32 is a very small number.
> Mem: 1156K Active, 2948K Inact, 6964K Wired, 530K Buf, 43M Free
>
> So, um, 64 - 43M == 21MB need to come up with that kernel single user,
> mount ufs file systems, and exec top.
>
Right. Again, my point: 32M is possible with lots of work. 64MB is possible
with some work. 128MB isn't too bad. 256MB is easy. Unless you want to self
host, then you need 1-2GB or a boatload of swap and a lot of patience.
When I say 128MB is a good 'minimum' I guess it's more a guideline. What
machines, as in actual, physical hardware, are out there that can support
at least 128MB of RAM. Now what machines don't. Is there a subset of those
machines that we can easily trim from the system. Like certain older MIPS
boards that can't do more than 32MB or 64MB. Or support for really old ISA
cards that only made sense in systems that maxed out at 32MB or 64MB. Or
some of the old armv4/5 hardware that can physically only address 64MB. I'm
not saying we can't run in less than that, but that our target for 12
should generally be systems that support at least 128MB. For 13, we should
double that again to 256MB (or maybe even 512MB): that would leave all the
embedded 486 elan class out (since they maxed out at 128MB), would leave
more armv4/5 boards out, if not all, more mips designs, etc. But that's not
for another 2-3 years (hopefully not 5, that's too long between major
releases).
Again, when I say 128MB, I'm using it as a design parameter, not trying to
take away your 64MB VMs, if they still work for you. I'm trying to narrow
the scope of what we have in the base in recognition that support for that
stuff buys us nothing, has a cost and is effectively maintainerless.
Warner
More information about the svn-src-head
mailing list