> > >: unknown: <PNP0303> can't assign resources
> > >: unknown: <PNP0501> can't assign resources
> > >: unknown: <PNP0501> can't assign resources
> > >: unknown: <PNP0401> can't assign resources
> > >: unknown: <PNP0700> can't assign resources
> > >: unknown: <PNP0f13> can't assign resources
> > >
> > >Don't worry about these.
> > 
> > Shouldn't we just suppress the message?  It just confuses users.
> 
> Shouldn't we just take the Linux/NetBSD information, and
> actually identify the things instead of saying "Unknown",
> instead, and leave them printing to encourage someone the
> messages annoy to do the work?

We don't need to "take" the information from anywhere; I've had most of 
the comprehensive databases for a while now.

The problem with simply stuffing them into the kernel is that they're 
big, and I tend to agree with folk that we don't really want large 
single-use string tables in the kernel.

This is why the PCI code that identifies unattached drivers reads the 
strings from a loadable file; once we can safely throw away loaded files, 
we can load the file at boot/install/whenever time and then throw it away 
once we're not interested anymore.

However, the real reason that most of these strings are being printed is 
that the ISA probe order is bass-ackwards.  The strings are printed 
because we have good PnP information that tells us a device is present, 
but we've already gone and believed the ISA hints and stuck a driver in 
that's claiming some or all of these resources.  The messages should be 
silenced for 4.4, but the deeper problem needs to be addressed as well.

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
           V I C T O R Y   N O T   V E N G E A N C E



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to