> The first argument of ndi_devi_enter() is a dev_info > structure. It has > a devi_busy_thread member showing the thread that > blocks the caller of > ndi_devi_enter().
I don't understand. Is this some sort of cooperative synchronization? Do you mean that one thread can "see" another thread that is blocking it? I thought all synchronization was handled in a very low level (even lower than device drivers and I/O) and was thus transparent to any code except the scheduler and maybe a few other very privileged bits... > mt_config_thread() and config_grand_children() are > deadlocking each other. I am not familiar with the code, so forgive me for this stupid question: If this deadlock is being caused by power management code, can we simply disable power management (I mean by commenting out the power management driver entry points) for the cardbus-related drivers? Could that provide a temporary workaround? By the way, I just downloaded and installed SXCR b51 and it deadlocks right on the first reboot after installation (while doing the "Configuring devices"). I also found out that my Toshiba BIOS has a PC Card configuration setting that can be set to "Automatic", "PCIC compatible" or "Cardbus/16-bit". On automatic, the b51 hangs on boot. On "Cardbus/16-bit" it panics on some dev configuration routine. I haven't tested "PCIC compatible" because I think it is not what we want. I wish I could understand what is going on and investigate the code myself. -- Douglas This message posted from opensolaris.org
