places into the CIS reading code.
The card in question has IO8 only enabled in its CIS info and is apparently
not able to keep up with quick reads. It words fine in a pcmcia slot but
panics(!) the kernel in a TI 1250 cardbus slot. This may be a failure of
the pci cardbus code when initializing this bridge. When finding (and
fixing) that, we should back this change out.
The card I am testing with is not broken, I have multiple versions of it
(AVM Fritz! pcmcia ISDN card), all work fine on windows and all cause
us to panic because of bogus CIS info read.
XXX - panicing because of bogus CIS data is probably another error.
errno otherwise). Actually use that return value to avoid installing an
interrupt handler (possibly sharing an interrupt with other cards!) and
initialising the softc with bogus/half baked values.
happens fairly commonly if e.g. some files are still opened
then the unmount is attempted
* if the second vflush() (including system vnodes) fails, we should
probably panic, it's too serious; for now, just add a comment
space is already torn down in uvmspace_free() when the vmspace
refrence count reaches 0. Move the shmexit() call into uvmspace_free().
Note that there is a beneficial side-effect of deferring the unmap
to uvmspace_free() -- on systems where TLB invalidations are
particularly expensive, the unmapping of the address space won't
have to cause TLB invalidations; uvmspace_free() is going to be
run in a context other than the exiting process's, so the "pmap is
active" test will evaluate to FALSE in the pmap module.
configuration (assignment of bus numbers, BARs, timer values,
interrupt lines, etc.).
The interface must be called from m.d. code prior to probing the bus.
It is meant to be called once for each primary (bus == 0) PCI bus in
the system. It will configure any busses behind PCI-PCI bridges.
Section 9 man page for pci_configure_bus() will come soon.
In the meantime, sample usage is in arch/sandpoint/sandpoint/mainbus.c.
[ Reviewed by thorpej ]
eeh