On Sun, Jun 27, 2021 at 01:00:46AM -0700, Joshua M. Clulow wrote: > > OK, so I have looked into this a little bit. It seems like there is a > bug in the HAL code we ship, or in the glib that OI is now using, or > somewhere inbetween.
You've gone much farther than I have. With some help from you, I've determined, with a current OI BE, that: Something failed to notify hald of new USB devices. Hald failed to notify the process spawner: hald-runner. The mount was never done. In general, we agree. > With DTrace, I am able to see (in the "hald --daemon=yes" process at > the top of the HAL process tree) that it receives the appropriate > sysevents from the kernel when a USB disk is plugged in or removed. It's good to know that that bit of IPC works as intended. [...] > Where things appear to fall down is once we get into the glib area. > The strings that are written into one end of the pipe by the sysevent > consumer, as described above, are meant to then be read through a glib > GIOChannel object in sysevent_iochannel_data(): > > > https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/hal/hald/solaris/sysevent.c#L244-L272 > > Though we do enter sysevent_iochannel_data() on schedule for each > sysevent, it seems like the call to g_io_channel_read_line() always > returns a value of 3 on my system -- which seems like an EOF? Because > the value is not G_IO_STATUS_NORMAL, we don't even try to call > sscanf() to parse the lines we wrote above. This means we never call > into sysevent_dev_add() and thus we never pass the hotplug event on to > the rest of HAL. That sounds like the "temporarily unavailable" or the "interrupted system call" errors for the read() system call in glib. > I have run out of steam on this for now, but I hope this is enough for > someone to keep digging. In particular, it seems like it is worth > investigating whether glib has been updated in OI at some point > between when this was last working and now. Perhaps there is a build > issue or a bug there. It doesn't seem like there has been a lot of > change in the HAL daemon itself (which is in the gate, as linked > above). The hal package is rebuilt for OI. There have been many changes, with different revision numbers. For example, in the BE from 2020-11-27 where mounts work, the package is service/hal@0.5.11-2020.0.1.20171 . In the BE from 2021-05-14 where mounts do not work, the package is service/hal@0.5.11-2020.0.1.20514 . I assume the revision numbers do not indicate actual changes. -- -Gary Mills- -refurb- -Winnipeg, Manitoba, Canada- _______________________________________________ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev