Gary Mills wrote: > 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. > >
I was trying to use a KVM switch the other day, and I suppose this issue is why I had to force a shutdown(power btn) of OI every time I had switched to another machine and back again. Mouse and keyboard were unresponsive but powered up. Potentially this is a lot worse than automounting of usb devices not working IMO. /tony -- Tony Albers - Systems Architect - Data Department, Royal Danish Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark Tel: +45 2566 2383 - CVR/SE: 2898 8842 - EAN: 5798000792142 _______________________________________________ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev