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. >: A great many sound >: chips of various register demands are in this list. (Admittedly older >: devices, but I ran into serious breakage of an isa pnp device driver >: because of interactions with the related non-pnp probe routine that >: supported earlier chipsets in the same family that were largely register >: compatible with the pnp versions). > >I just took a look at mss. I'm not at all sure what you are talking >about. mss.c specifically doesn't probe devices that aren't PNP for >its identify the device case. pnpmss does only pnp devices. The >mss_probe routine won't look anywhere other than it has been >specifically instructed to look by the hints mechanism. > >Can you be more specific about the exact breakage? Vague statements >like the above don't convey the information that I need to help you >solve your problem. 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.... 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 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. In message: <4.3.2.7.2.20050716114020.01f0fcb8_at_mail.qconline.com> Harry Coin <harrycoin_at_qconline.com> writes: : 1) Document a way or make an OS change to make certain non-pnp isa probe : routines are never called any time while pnp isa resources haven't been put : to sleep. They arne't. The CARDS are put to sleep. However, PNPBIOS devices can't be put to sleep, in general. PCI resources aren't put to sleep. Your probe routine should, in the non-pnp case, only be looking at the hinted resources for that device. Thank you. I should have been more clear. I'm aware of this. The driver in question is the mss.c which indeed has a mss_probe non pnp routine called, and which succeeds, with acpi as a parent -- which when the following attach call is made fails. Extensive documentation is upstream. : So that these probe routines will only be called after the : field is clear and they can rummage around the register space looking for probe routines aren't supposed to do that. Probe routines are supposed to answer the question 'Is this hardware at the specified location.' identify routines are allowed to go looking, but even they are supposed to only look at 'alternative enumeration techniques' rather than 'probing through the address space'. Such probing was banished in FreeBSD 3.0. mss.c's non pnp probe routine seems to rather crowd the above. It isn't my routine per se. I am adding support for CS4236B to work as an audio source (the included code fails to adjust the mixer properly. While I'm at it I'm exposing the various resources of the chip in mode 3, allowing for different record and playback rates and formats, and clearly knowable amplification settings throughout the audio path in and out.) : their chips -- and they don't accidentally find compatible PCI versions : previously or yet to be found by their PCI probe modern driver cousins. The : isa part of the architecture manual ought to be updated to reflect how : properly to do this. Where is this manual of which you speak? I'd sure like to change it to be right. Certainly: 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.... : (Are there cases where the non-pnp routines being : called in the acpi context pass the currently iffy pnp-gate and find and : enable operations of pnp chips that the pnp-routines don't have in their : 'acceptable id' list? My hunch in the sound chip world is 'yes'. So this : fix might break audio on systems that don't have the pnp ids in the pnp : soundchip ISA_PROBE roster as yet.) I don't understand what you are suggesting here. My thought is, if the current roster of non pnp isa drivers is not to be touched, then the OS ought to avoid to call their probe routines unless the pnp cards are all sleeping whether by acpi or whatever. Also it is my experience that there are quite a good many sound chips out there that are pnp but are not in the roster of pnp devices in the pnp mss detect driver. The current setup will allow these devices to be probed and to operate (maybe not as pcm0) via the non-pnp detect routine called from the acpi. A lucky side effect that helps some folk but which will go away if this issue is cleaned up I fear. : 2) change non-pnp isa drivers to do as the architecture manual currently : suggests, with inelegance that John noted (ISA_PNP_PROBE with the null list : then continue only if no pnp id for the device). I don't understand this either. Please be more specific. I'm coming to the conversation late. Never fear, there is extensive dmesg and dialogue on freebsd-current , this subject line upstream. : 3) make a device_is_pnp OS call that does 2 and avoids the inelegance, then : update the architecture manual for isa drivers and also the isa drivers : themselves. I've already said that this isn't needed, and likely indicates some abuse of the model. I suspect that the abuse is that the probe routine bogusly goes and looks for resources not assigned to it in the hopes of finding hardware. Warner That is part of the problem, yes. Hope this helps HarryReceived on Sat Jul 16 2005 - 16:04:59 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:39 UTC