The collected works of pip

pentium wrote:

If you are looking for pure-power in a Mac , go for an Intel

Those two words should NEVER be in the same sentence.

Dr. Dave wrote: So, I tried the AUA-3020 on a Fuel, no dice - but it apparently works on an O2. So of course that got me to thinking...

I had a QLA2212 here (which also does not work on a Fuel), the reason being that the AUA3020 and the QLA2212 (basically 2 QLA2200's-on-a-card) both use PCI bridge chips to map two devices into a single PCI slot, and apparently PCI bridge chips do not play well with XIO-based systems .

Guy you drive me nuts with your silly hack it up on irix and
glue it into linux strategy!

+ * Fairly generic PCI-PCI Bridge (PPB) driver module.
+ *
+ * This driver implements provider-independent PPB support for Irix.
+ *
+ * Goals
+ * =====
+ * Transparantly provide pciio services to PCI devices downstream of a PPB
+ * hierarchy.
+ *
+ * Implement as a provider-independent module.
+ *
+ * Design
+ * ======
+ *
+ *
+ * For the most part, devices behind a PPB are used in the same way as devices
+ * directly connected to a host bus. Drivers are written using the guidelines
+ * set forth in the device drivers programming guide. The most notable
+ * exception is that some providers might not allow config space pio maps to
+ * devices residing on secondary busses because of shared address space when
+ * accessing these devices.
+ *
+ * Other restrictions might come into play if devices behind a PPB request
+ * resources or mappings which are not compatable with each other when you
+ * consider that all subordinate devices originate at a common host slot. An
+ * example might be interrupt routing using DEVICE_ADMIN statements.
+ *
+ * All subordinate bus numbers in the system come from a shared pool, at start
+ * at 16. Bus numbers < 16 are left to the providers. A future modification to
+ * this code might move bus number allocation to be a per-provider function.
+ *
+ * While this code should be provider-independent, no attempt was made to
+ * retrofit this to O2. The O2 already had PPB support, and it did not seem
+ * worth the risk to break customer code that might relay on how O2 works.
+ *
+ * No attempt was made to restrict the configuration for the well-known
+ * bridge/xbridge issue of RRB thrashing when there are multiple PCI masters
+ * doing reads from a single bridge. The reasoning is that there is no easy way
+ * to tell if downstream PCI masters intend to do host DMA or not. It is
+ * perfectly ok to allow multiple masters doing device-to-device traffic.
+ *
+ * Provider implementations must make the following accomodations for this
+ * driver to work correctly:
+ *
+ * When accessing config space (pciio_config_get()/pciio_config_set())
+ * the provider should examine the pciio_info_t of the passed vhdl
+ * to determine if TYPE1 addressing should be used. This can be checked
+ * by pciio_info_type1_get() returning non-zero. This means that
+ * the bus/slot/function to be used are encoded in the address
+ * to be read/written, and the macros PCI_TYPE1_BUS,
+ * PCI_TYPE1_SLOT, and PCI_TYPE1_FUNC should be used to extract
+ * the correct values.
+ *
+ * In addition, if the provider stores non-zero bus numbers for the host
+ * PCI bus in a device's pciio_info_t->c_bus (as bridge/xbridge do), the
+ * provider code must determine if the register to be read resides on the
+ * host bus (actually PCI bus 0), or a subordinate bus (PCI bus != 0).
+ * pcibr accomplishes this by checking the pciio_info c_vertex against
+ * c_hostvertex. If they are the same, the device is on the host bus, and
+ * this is PCI bus 0. If not, the device is on a subordinate bus, and the
+ * bus number can be taken from c_bus.
+ *
+ * Providers must decide if it is appropriate for pio maps to be
+ * constructed for config space of devices on subordinate busses. For
+ * bridge/xbridge, this should not be allowed because all devices on
+ * subordinate busses share the same address space (the bus/slot to use is
+ * programmed in a bridge/xbridge register).
+ *
+ */

kramlq wrote: For SunOS/Solaris, there were some versions of SimICS that could emulate a SPARCstation. It might be only for SPARC hosts though.

japes wrote: I installed 10.6 on my old mini (1.66 Core Duo) and MacPro. They both seem fine, except, the Mini studders while playing video in the hulu Player. This is big deal for us since the Mini is connected to our TV and without cable, we use hulu to watch a couple television programs. So far we have been able to watch video from the network websites (cbs.com, fox.com). Certainly a US problem with those sites, but could be indicative of performance or video issues that could affect others. I don't have the hulu player on my MacPro.

NCommander wrote: Another headache is that the garbage collector wants access to a threads stack and stacksize. On most platforms, this is handled by a non-POSIX pthread extension that can grab a running threads attributes, and report the base/stacksize. I couldn't find an equivelent function on IRIX that worked*, so I modified NSPR to include such information in the PRThread structure, and then added a function that I could pull it on the fly; my implementation is not 100% correct as it doesn't account properly for the NSPR thread wrapper function and stack size its using, but its "good enough" for the time being; fixing it is pretty trivial, I just haven't done it yet.

*- IRIX's getcontext() suggests it works in threads, but only returned the stack of the base thread as far as I could tell. The same function is used on AIX in jsnativestack.cpp; I suspect it is broken on that platform as well