Garrett D'Amore wrote: >I was definitely using a 32-bit card. I didn't expect cfgadm to notice >a 16-bit card. Under older releases, 16-bit card removal/insertion are >"transparent" (similar to USB), which works well because the controllers >can detect removal/insertion and the pcmcia framework was designed with >this in mind (unlike the cardbus framework which mostly follows hot plug >PCI.) > > > In the current release, 16-bit cards works as usual. The old framework haven't been changed. I've sent you the latest source, you may help fix the bugs if you have time.
>I didn't get around to testing your patch today, but I will definitely >do so first thing tomorrow morning. > > > >>Snv_44 does not support surprise removal of 32bit cards well, you may >>occasionally encounter panics. This is fixed in snv_46. I'll send you >>the latest >>bits and source so you can help try them out. >> >> > >Wow. Well, we (Tadpole) have never supported surprise removal of >Cardbus 32 devices. Heck, I'd expect bad things to happen in drivers, >since a lot of cardbus cards want to do DMA, etc. where surprise removal >could leave things like descriptor rings in an inconsistent state. > >I'd strongly recommend that users working with cardbus be educated to >use cfgadm to manage insertion and removal. > > I meant, surprise removal can (and should) be _handled_, so that a panic does not happen. True there can be problems in the leaf drivers. Using cfgadm to unconfigure the node is still the offically supported way for 32bit PC Cards and hotplug-PCI devices. To fully support surprise removal, there needs some change in the DDI framework and the leaf drivers involved. We're not there yet. But it's still possible. Vincent.
