mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up

[M. Warner Losh]

In message: <4.3.2.7.2.20050716124022.01f08460 at mail.qconline.com>
            Harry Coin <harrycoin at qconline.com> writes:
: Warner,
: 
: Thanks for engaging. Responses within.
: 
: At 11:30 AM 7/16/2005 -0600, M. Warner Losh wrote:
: >In message: <4.3.2.7.2.20050716114020.01f0fcb8 at mail.qconline.com>
: >             Harry Coin <harrycoin at qconline.com> writes:
: >: I think all that's needed to wrap this up is for the powers that be to
: >: offer clarity about one thing, final decision about the case of arbitrary
: >: (beyond com1, etc.) non-pnp ISA devices probe routines.
: >
: >As far as I kow, there's nothing wrong with them.  Please state the
: >problem.  They work and work well today.  Without a clear problem
: >statement, it is hard to know what you are complaining about.
: 
: There is significant comment upstream, and certainly a significant issue 
: that didn't work at all today, nor in the past (many unanswered bugs 
: relating to 'attach returned 6' and soundcards in the freebsd 
: history).  The issue arose in mss.c that has both a pnp and a non pnp probe 
: routine for drives that share other routines.

???

: There is extensive comment upstream, I hesitate to repeat it all.  The 
: short story is that  from the freebsd architecture manual on the subect we 
: have: 
: http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/isa-driver-config.html
: ...That means that absolutely every driver, even the ones not supporting 
: any PnP devices must call ISA_PNP_PROBE(), at least with an empty PnP ID 
: table to return failure on unknown PnP devices....

No.  That's not true.  They can call isa_get_logicalid() and return if
it is not zero.  For example, sn:

static int
sn_isa_probe (device_t dev)
{
	if (isa_get_logicalid(dev))		/* skip PnP probes */
		return (ENXIO);
	if (sn_probe(dev) != 0)
		return (ENXIO);
	return (0);
}

This has always been the way.  The isa-driver-config.html is mistaken
if it says otherwise.  This has been the recommended way to avoid pnp
probes since 3.0 (I know I've added it to a bunch of drivers).

: is violated in mss_probe, which uses another way to detect whether a device 
: is pnp and so avoid the non pnp probe.   That alternate call fails in the 
: case the bus parent is acpi, causing mss_probe to succeed, mss_attach to 
: fail, the pcmx count to ratchet up x, and then, depending, you get a pcm3 
: without a pcm0, pcm1 or pcm2 if the isa bus probes eventually find 
: it.   John was dismayed by this because the alternate way is employed in 
: many isa drivers.

John's misremembering things.  This has always been the case.  ACPI
should return non-zero always (since it has no non-pnp devices).  ACPI
is at fault here, for not returning PNP information that it has.  If
it is trying to 'cheat' by using the 'isa' attachments, then it has to
follow the old isa rules.

Looking at mss.c, mss_probe shouldn't be called in the acpi case.
There's no 'acpi' attachment for it  Why is it being called at all?

: John Baldwin has offered that the architecture manuals suggestion is not a 
: good course to follow for elegance reasons.  However if mss_probe is 
: changed to employ that the problem goes away.  John discovered a tension in 
: the OS calls related to the various detection alternatives and ACPI.  He 
: also suggested removing the mss routines from the acpi class, which too 
: avoided the problem on the system that I have, but may or may not cause 
: breakage with other systems.

I think this points out a fundamental problem.  Can you send me
devinfo -v for your machine and/or a dmesg (or a pointer to the
message that has it in it)?  mss_probe should only be called for isa
bus, and it should only make it pass its resource allocation if you
have mss hints in your /boot/device.hints.  If acpi is behaving
otherwise, then that's an acpi bug.

Warner