ipmi_close can panic trying to free invalid dev_t
We've experienced panics in ipmi_close calling id_free which bottoms out in a vmem_hash_delete with a NULL address. This is due to an invalid id_t present at the time the pseudo device is allocated in ipmi_open. It comes from id_alloc_nosleep which is allowed to return -1 if no memory is available without sleeping. id_ts are translated from vmem arena addresses by decrementing by 1, so this is a NULL address internally. ipmi_open incorrectly handles the id_alloc_nosleep error case as 0 instead of -1. It should just use id_alloc() as it also performs other sleeping allocations already.