09:11:38 vetal: Is this a system with multiple paths to each SAS disk? 09:12:15 It looks suspiciously like you're getting one of several potential paths to the same disk at random each boot? 09:18:58 I have some software that's trying to use both c++11 thread_local and tss(3C), and the thread_local define in threads.h is conflicting with C++ - I don't really understand what "_Thread_local" is, it doesn't appear in any public headers, and should probably be !cplusplus'd? 09:26:27 _Thread_local is the standard C11 keyword for thread local storage. In C++11 it's thread_local, so it does seem like there's a missing guard there. 09:28:03 Oh, and _Thread_local is deprecated in C23 09:28:19 > _Thread_local (until C23) thread_local (since C23) - thread storage duration (since C11) 14:49:59 jclulow: I think you are right) 17:54:41 vetal: The thing that's supposed to happen is that scsi_vhci should sit on top of both of those paths, and you should get one virtual disk with the correct WWN 17:55:26 I'm not sure why that's not happening for you here 17:56:28 (but it seems like a bug!) 17:57:32 What do you see in diskinfo? 18:56:59 are the controllers set for jbod mode and not raid? 19:06:36 vetal: another thing to look at is what value of mpxio_disable is set in the disk controller's .conf file. 19:07:54 mpxio_disable="no" reparents disk devices to the scsi_vhci virtual controller number so the /dev/dsk filename doesn't change when the disk is moved or if a different path is used. 19:08:32 excuse me, mpxio-disable, not mpxio_disable. 19:53:44 andyf: the _Thread_local situation seems tedious at best 19:53:54 but yeah, it seems like someone has to go work out the soup of ifdefs :\ 19:55:35 jclulow: my ancient memory says "shouldn't mpxio by default have fixed this?" and seems like a bug sounds right? 22:04:19 jbk: jbod 22:04:31 sommerfeld: Thank you. Will try it. 22:05:56 jclulow: Did you ask about case where cN is changed or case when WWN and device name differs ?