Re: [oi-dev] OI no longer automounts USB sticks

[Joshua M. Clulow via oi-dev]

On Fri, 25 Jun 2021 at 18:52, Gary Mills  wrote:
> On Fri, Jun 25, 2021 at 12:24:52PM -0700, Joshua M. Clulow via oi-dev wrote:
> > It seems like it would be good to figure out, on the systems that _do_
> > work, what exactly is performing the mount.  Then we can work
> > backwards to why that is no longer happening.
>
> Good idea.  I have a system running an older BE where the automount
> does work.  I did exactly what you suggested.
> # dtrace -w -n '
> > syscall::*mount*:entry {
> > raise(SIGSTOP);
> > system("pargs %d; ptree %d; prun %d", pid, pid, pid);
> > }'
> dtrace: description '
> syscall::*mount*:entry ' matched 2 probes
> dtrace: allowing destructive actions
> CPU IDFUNCTION:NAME
>  10   8968umount2:entry 3951:   
> /usr/lib/hal/hald-addon-storage
> argv[0]: /usr/lib/hal/hald-addon-storage
> 1994   /usr/lib/hal/hald --daemon=yes
>   1995   hald-runner
> 3951   /usr/lib/hal/hald-addon-storage
>
>  11   8532  mount:entry 3955:   mount -o nosuid 
> /dev/dsk/c4t0d0p0:1 /media/STORE N GO
> argv[0]: pcfs_mount
> argv[1]: -o
> argv[2]: nosuid
> argv[3]: /dev/dsk/c4t0d0p0:1
> argv[4]: /media/STORE N GO
> 1994   /usr/lib/hal/hald --daemon=yes
>   1995   hald-runner
> 3954   /usr/lib/hal/hal-storage-mount
>   3955   mount -o nosuid /dev/dsk/c4t0d0p0:1 /media/STORE N GO
>
>   2   8532  mount:entry 3951:   
> /usr/lib/hal/hald-addon-storage
> argv[0]: /usr/lib/hal/hald-addon-storage
> 1994   /usr/lib/hal/hald --daemon=yes
>   1995   hald-runner
> 3951   /usr/lib/hal/hald-addon-storage

Thanks for that!

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.

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.
We get as far as the sysevent_dev_handler() routine:


https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/hal/hald/solaris/sysevent.c#L157-L191

In particular, on my system, I see three write(2) calls that look like this:

   EC_devfs ESC_devfs_devi_add /pci@0,0/pci8086,2064@14/storage@2

   EC_devfs ESC_devfs_devi_add /pci@0,0/pci8086,2064@14/storage@2/disk@0,0

   EC_dev_add disk /pci@0,0/pci8086,2064@14/storage@2/disk@0,0
/dev/rdsk/c4t0d0 0

This seems about right.  These writes are into a self-pipe (i.e., both
ends of the pipe are held open within this single hald process) that
is established in the sysevent_init() routine, and stored in the
"sysevent_pipe_fds" global where I was able to confirm with pfiles
that the pipe is still open.

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.

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).

One imagines this may also have an impact on the X11 keyboard/mouse
situation as those changes are presumably communicated via sysevents
to HAL, and HAL is similarly dropping the ball there.

Cheers.

-- 
Joshua M. Clulow
http://blog.sysmgr.org

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI no longer automounts USB sticks

[Andreas Wacknitz]

Am 27.06.21 um 10:00 schrieb Joshua M. Clulow via oi-dev:

On Fri, 25 Jun 2021 at 18:52, Gary Mills  wrote:

On Fri, Jun 25, 2021 at 12:24:52PM -0700, Joshua M. Clulow via oi-dev wrote:

It seems like it would be good to figure out, on the systems that _do_
work, what exactly is performing the mount.  Then we can work
backwards to why that is no longer happening.

Good idea.  I have a system running an older BE where the automount
does work.  I did exactly what you suggested.
 # dtrace -w -n '
 > syscall::*mount*:entry {
 > raise(SIGSTOP);
 > system("pargs %d; ptree %d; prun %d", pid, pid, pid);
 > }'
 dtrace: description '
 syscall::*mount*:entry ' matched 2 probes
 dtrace: allowing destructive actions
 CPU IDFUNCTION:NAME
  10   8968umount2:entry 3951:   
/usr/lib/hal/hald-addon-storage
 argv[0]: /usr/lib/hal/hald-addon-storage
 1994   /usr/lib/hal/hald --daemon=yes
   1995   hald-runner
 3951   /usr/lib/hal/hald-addon-storage

  11   8532  mount:entry 3955:   mount -o nosuid 
/dev/dsk/c4t0d0p0:1 /media/STORE N GO
 argv[0]: pcfs_mount
 argv[1]: -o
 argv[2]: nosuid
 argv[3]: /dev/dsk/c4t0d0p0:1
 argv[4]: /media/STORE N GO
 1994   /usr/lib/hal/hald --daemon=yes
   1995   hald-runner
 3954   /usr/lib/hal/hal-storage-mount
   3955   mount -o nosuid /dev/dsk/c4t0d0p0:1 /media/STORE N GO

   2   8532  mount:entry 3951:   
/usr/lib/hal/hald-addon-storage
 argv[0]: /usr/lib/hal/hald-addon-storage
 1994   /usr/lib/hal/hald --daemon=yes
   1995   hald-runner
 3951   /usr/lib/hal/hald-addon-storage

Thanks for that!

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.

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.
We get as far as the sysevent_dev_handler() routine:

 
https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/hal/hald/solaris/sysevent.c#L157-L191

In particular, on my system, I see three write(2) calls that look like this:

EC_devfs ESC_devfs_devi_add /pci@0,0/pci8086,2064@14/storage@2

EC_devfs ESC_devfs_devi_add /pci@0,0/pci8086,2064@14/storage@2/disk@0,0

EC_dev_add disk /pci@0,0/pci8086,2064@14/storage@2/disk@0,0
/dev/rdsk/c4t0d0 0

This seems about right.  These writes are into a self-pipe (i.e., both
ends of the pipe are held open within this single hald process) that
is established in the sysevent_init() routine, and stored in the
"sysevent_pipe_fds" global where I was able to confirm with pfiles
that the pipe is still open.

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.

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).

One imagines this may also have an impact on the X11 keyboard/mouse
situation as those changes are presumably communicated via sysevents
to HAL, and HAL is similarly dropping the ball there.

Cheers.


Thanks a lot for your analysis, Josh.

In fact we had some minor glib updates in the past. Alas we have neither
automatic tests nor official testers at all.
So, the main test burden is left to me. And I am only able to do limited
manual tests, because I have lots of other things I want to do.
I only use USB sticks very rarely and while I do change my mouse or
keyboard from time to time, it hasn't been on my test scenarios in the past.
So problems like this will only be detected long after they have been
introduced.

I'd appreciate if we could find some volunteers for tests and would even
more appreciate if you could find somebody starting to create automatic
tests.

Regards

Re: [oi-dev] OI no longer automounts USB sticks

[s...@pandora.be]

- Op 27 jun 2021 om 10:55 schreef Andreas Wacknitz a.wackn...@gmx.de:

> And I am only able to do limited
> manual tests, because I have lots of other things I want to do.
> I only use USB sticks very rarely and while I do change my mouse or
> keyboard from time to time, it hasn't been on my test scenarios in the past.
> So problems like this will only be detected long after they have been
> introduced.
> 
> I'd appreciate if we could find some volunteers for tests and would even
> more appreciate if you could find somebody starting to create automatic
> tests.


The best testing is desktop users of OpenIndiana.

I like the 2021.04 release of OI, this is a great piece of work, and this 
release works well on my PC
(thanks for the work on it).

Regarding the USB automount, I can personally live with the workaround of 
manual mount.
Automount would be nice so if it gets fixed all the better.

David Stes

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI no longer automounts USB sticks

[Andreas Wacknitz]

Am 27.06.21 um 11:50 schrieb s...@pandora.be:

- Op 27 jun 2021 om 10:55 schreef Andreas Wacknitz a.wackn...@gmx.de:


And I am only able to do limited
manual tests, because I have lots of other things I want to do.
I only use USB sticks very rarely and while I do change my mouse or
keyboard from time to time, it hasn't been on my test scenarios in the past.
So problems like this will only be detected long after they have been
introduced.

I'd appreciate if we could find some volunteers for tests and would even
more appreciate if you could find somebody starting to create automatic
tests.


The best testing is desktop users of OpenIndiana.

I like the 2021.04 release of OI, this is a great piece of work, and this 
release works well on my PC
(thanks for the work on it).

Regarding the USB automount, I can personally live with the workaround of 
manual mount.
Automount would be nice so if it gets fixed all the better.

David Stes


While I understand your point of view you should be aware that if I
continue to update things without proper testing more and more things
will break.
At some point in time I will break things you rely on and then your
unhappiness will begin.

We are a very small community and if I cannot convince more people to
help out, OI will either become outdated in more and more areas
or it will be more and more buggy. And probably both.

I didn't find the problem earlier because of how I use OI. I don't use
many things that I have been working on in the past. I will probably
stop that,
because I am running out of time. If I have to care for everything I
will not be able to do anything in the end.

Regards

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI no longer automounts USB sticks

[s...@pandora.be]

Although that OI 2020.04 and 2021.04 install both on this Dell Precision 3640 
system,
 I have noticed:

reboot: Not all drivers have implemented quiesce(9E)
Please see /var/adm/messages for drivers that haven't
implemented quiesce(9E).

The driver that is indicated there is

Jun 27 14:18:24 wapper genunix: [ID 884581 kern.warning] WARNING: xhci has no 
quiesce()

It would be interesting to compare to an older system which uses the ehci or 
ohci USB driver.


Maybe OpenIndiana running on a PC without the xHCI behaves differently.

David Stes

- Op 27 jun 2021 om 13:14 schreef Andreas Wacknitz a.wackn...@gmx.de:

> Am 27.06.21 um 11:50 schrieb s...@pandora.be:
>> - Op 27 jun 2021 om 10:55 schreef Andreas Wacknitz a.wackn...@gmx.de:
>>
>>> And I am only able to do limited
>>> manual tests, because I have lots of other things I want to do.
>>> I only use USB sticks very rarely and while I do change my mouse or
>>> keyboard from time to time, it hasn't been on my test scenarios in the past.
>>> So problems like this will only be detected long after they have been
>>> introduced.
>>>
>>> I'd appreciate if we could find some volunteers for tests and would even
>>> more appreciate if you could find somebody starting to create automatic
>>> tests.
>>
>> The best testing is desktop users of OpenIndiana.
>>
>> I like the 2021.04 release of OI, this is a great piece of work, and this
>> release works well on my PC
>> (thanks for the work on it).
>>
>> Regarding the USB automount, I can personally live with the workaround of 
>> manual
>> mount.
>> Automount would be nice so if it gets fixed all the better.
>>
>> David Stes
>>
> While I understand your point of view you should be aware that if I
> continue to update things without proper testing more and more things
> will break.
> At some point in time I will break things you rely on and then your
> unhappiness will begin.
> 
> We are a very small community and if I cannot convince more people to
> help out, OI will either become outdated in more and more areas
> or it will be more and more buggy. And probably both.
> 
> I didn't find the problem earlier because of how I use OI. I don't use
> many things that I have been working on in the past. I will probably
> stop that,
> because I am running out of time. If I have to care for everything I
> will not be able to do anything in the end.
> 
> Regards
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI no longer automounts USB sticks

[Toomas Soome via oi-dev]

Quiesce is to support fast reboot, it does not interfere with device 
connectivity.

Sent from my iPhone

> On 27. Jun 2021, at 15:27, s...@telenet.be wrote:
> 
> 
> Although that OI 2020.04 and 2021.04 install both on this Dell Precision 3640 
> system,
> I have noticed:
> 
> reboot: Not all drivers have implemented quiesce(9E)
>Please see /var/adm/messages for drivers that haven't
>implemented quiesce(9E).
> 
> The driver that is indicated there is
> 
> Jun 27 14:18:24 wapper genunix: [ID 884581 kern.warning] WARNING: xhci has no 
> quiesce()
> 
> It would be interesting to compare to an older system which uses the ehci or 
> ohci USB driver.
> 
> 
> Maybe OpenIndiana running on a PC without the xHCI behaves differently.
> 
> David Stes
> 
> - Op 27 jun 2021 om 13:14 schreef Andreas Wacknitz a.wackn...@gmx.de:
> 
>>> Am 27.06.21 um 11:50 schrieb s...@pandora.be:
>>> - Op 27 jun 2021 om 10:55 schreef Andreas Wacknitz a.wackn...@gmx.de:
>>> 
 And I am only able to do limited
 manual tests, because I have lots of other things I want to do.
 I only use USB sticks very rarely and while I do change my mouse or
 keyboard from time to time, it hasn't been on my test scenarios in the 
 past.
 So problems like this will only be detected long after they have been
 introduced.
 
 I'd appreciate if we could find some volunteers for tests and would even
 more appreciate if you could find somebody starting to create automatic
 tests.
>>> 
>>> The best testing is desktop users of OpenIndiana.
>>> 
>>> I like the 2021.04 release of OI, this is a great piece of work, and this
>>> release works well on my PC
>>> (thanks for the work on it).
>>> 
>>> Regarding the USB automount, I can personally live with the workaround of 
>>> manual
>>> mount.
>>> Automount would be nice so if it gets fixed all the better.
>>> 
>>> David Stes
>>> 
>> While I understand your point of view you should be aware that if I
>> continue to update things without proper testing more and more things
>> will break.
>> At some point in time I will break things you rely on and then your
>> unhappiness will begin.
>> 
>> We are a very small community and if I cannot convince more people to
>> help out, OI will either become outdated in more and more areas
>> or it will be more and more buggy. And probably both.
>> 
>> I didn't find the problem earlier because of how I use OI. I don't use
>> many things that I have been working on in the past. I will probably
>> stop that,
>> because I am running out of time. If I have to care for everything I
>> will not be able to do anything in the end.
>> 
>> Regards
>> 
>> ___
>> oi-dev mailing list
>> oi-dev@openindiana.org
>> https://openindiana.org/mailman/listinfo/oi-dev
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI no longer automounts USB sticks

[Gary Mills]

On Sun, Jun 27, 2021 at 11:50:31AM +0200, s...@pandora.be wrote:

> I like the 2021.04 release of OI, this is a great piece of work,
> and this release works well on my PC (thanks for the work on it).

I like it too, especially the new Firefox.  So far, I've only found
one anomaly with it, and I have a workaround.  It does work with web
pages where previous versions would not.

> Regarding the USB automount, I can personally live with the
> workaround of manual mount.  Automount would be nice so if it gets
> fixed all the better.

I use it periodically to transfer files from my main Unix system to
another system that runs Windows 10.  I know there are alternatives to
USB sticks, but they are convenient.  USB automount is useful to me.

In both cases, it has taken me some time to notice problems with OI.
Automated testing would not help much, because you have to know what
a problem is, before you can design a test for it.


-- 
-Gary Mills--refurb--Winnipeg, Manitoba, Canada-

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

[oi-dev] ddu dmi_info

[s...@pandora.be]

I'm impressed by OpenIndiana installing and running fine on this Dell Precision.

However the  "ddu" (device detection utility) is not reporting some info.

The underlying problem seems to be :

# /usr/ddu/bin/i386/dmi_info -C
error open smbios

Usage: dmi_info [BCDMmPS]
   -B: print BIOS information 
   -C: print Processor number and core number
   -D: print PCI Controllers information
   -M: print Motherboard information
   -m: print memory subsystem information
   -P: print Processor informationIn the UEFI Shell, the SmbiosView command 
can retrieve and display the SMBIOS data
   -S: print System information
   -h: for help

So basically this tool (used to 'probe') seems not be working for me.

I'm no expert in this, but I guess this is related to UEFI and,
the tool must be updated to access this DMI info from UEFI

https://en.wikipedia.org/wiki/System_Management_BIOS#From_UEFI


David Stes

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI no longer automounts USB sticks

[Gary Mills]

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

Re: [oi-dev] OI no longer automounts USB sticks

[Tony Brian Albers]

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

Re: [oi-dev] help needed to test tem on nvidia system

[Tony Brian Albers]

Toomas Soome via oi-dev wrote:
> 
> 
>> On 23. Jun 2021, at 10:20, Stephan Althaus 
>>  wrote:
>>
>> On 6/22/21 11:09 PM, Toomas Soome via oi-dev wrote:
>>>
>>> hi!
>>>
>>> as I do not have nvidia gfx myself, some help is needed to test 
>>> https://code.illumos.org/c/illumos-gate/+/1550 
>>> .
>>>
>>> thanks,
>>> toomas
>>>
>>>
>>> ___
>>> oi-dev mailing list
>>> oi-dev@openindiana.org 
>>> https://openindiana.org/mailman/listinfo/oi-dev 
>>> 
>> Hi Toomas!
>>
>> Would it be as easy as exchange a binary, or do i have to build illumos-gate 
>> with the PR-changes applied ?
>>
>> Greetings,
>>
>> Stephan
>>
>>
>>
> 
> I’ll provide binaries and instructions (we will create BE for test, so we 
> wont disturb your current environment).
> 
> thanks,
> toomas
> 
>> ___
>> oi-dev mailing list
>> oi-dev@openindiana.org
>> https://openindiana.org/mailman/listinfo/oi-dev
> 
> 
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev
> 

I've got a NVS 510 and a quadro k2200 that I can test it with.

/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

Re: [oi-dev] OI no longer automounts USB sticks

[Stephan Althaus]

On 6/27/21 10:55 AM, Andreas Wacknitz wrote:
> Am 27.06.21 um 10:00 schrieb Joshua M. Clulow via oi-dev:
>> On Fri, 25 Jun 2021 at 18:52, Gary Mills  wrote:
>>> On Fri, Jun 25, 2021 at 12:24:52PM -0700, Joshua M. Clulow via
>>> oi-dev wrote:
 It seems like it would be good to figure out, on the systems that _do_
 work, what exactly is performing the mount.  Then we can work
 backwards to why that is no longer happening.
>>> Good idea.  I have a system running an older BE where the automount
>>> does work.  I did exactly what you suggested.
>>>  # dtrace -w -n '
>>>  > syscall::*mount*:entry {
>>>  > raise(SIGSTOP);
>>>  > system("pargs %d; ptree %d; prun %d", pid, pid, pid);
>>>  > }'
>>>  dtrace: description '
>>>  syscall::*mount*:entry ' matched 2 probes
>>>  dtrace: allowing destructive actions
>>>  CPU ID    FUNCTION:NAME
>>>   10   8968    umount2:entry 3951:  
>>> /usr/lib/hal/hald-addon-storage
>>>  argv[0]: /usr/lib/hal/hald-addon-storage
>>>  1994   /usr/lib/hal/hald --daemon=yes
>>>    1995   hald-runner
>>>  3951   /usr/lib/hal/hald-addon-storage
>>>
>>>   11   8532  mount:entry 3955:   mount
>>> -o nosuid /dev/dsk/c4t0d0p0:1 /media/STORE N GO
>>>  argv[0]: pcfs_mount
>>>  argv[1]: -o
>>>  argv[2]: nosuid
>>>  argv[3]: /dev/dsk/c4t0d0p0:1
>>>  argv[4]: /media/STORE N GO
>>>  1994   /usr/lib/hal/hald --daemon=yes
>>>    1995   hald-runner
>>>  3954   /usr/lib/hal/hal-storage-mount
>>>    3955   mount -o nosuid /dev/dsk/c4t0d0p0:1 /media/STORE N GO
>>>
>>>    2   8532  mount:entry 3951:  
>>> /usr/lib/hal/hald-addon-storage
>>>  argv[0]: /usr/lib/hal/hald-addon-storage
>>>  1994   /usr/lib/hal/hald --daemon=yes
>>>    1995   hald-runner
>>>  3951   /usr/lib/hal/hald-addon-storage
>> Thanks for that!
>>
>> 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.
>>
>> 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.
>> We get as far as the sysevent_dev_handler() routine:
>>
>> 
>> https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/hal/hald/solaris/sysevent.c#L157-L191
>>
>> In particular, on my system, I see three write(2) calls that look
>> like this:
>>
>>     EC_devfs ESC_devfs_devi_add /pci@0,0/pci8086,2064@14/storage@2
>>
>>     EC_devfs ESC_devfs_devi_add
>> /pci@0,0/pci8086,2064@14/storage@2/disk@0,0
>>
>>     EC_dev_add disk /pci@0,0/pci8086,2064@14/storage@2/disk@0,0
>> /dev/rdsk/c4t0d0 0
>>
>> This seems about right.  These writes are into a self-pipe (i.e., both
>> ends of the pipe are held open within this single hald process) that
>> is established in the sysevent_init() routine, and stored in the
>> "sysevent_pipe_fds" global where I was able to confirm with pfiles
>> that the pipe is still open.
>>
>> 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.
>>
>> 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).
>>
>> One imagines this may also have an impact on the X11 keyboard/mouse
>> situation as those changes are presumably communicated via sysevents
>> to HAL, and HAL is similarly dropping the ball there.
>>
>> Cheers.
>>
> Thanks a lot for your analysis, Josh.
>
> In fact we had some minor glib updates in the past. Alas we have neither
> automatic tests nor official testers at all.
> So, the main test burden is left to me. And I am only able to do limited
> manual tests, because I have lots of other things I want to do.
> I only use 

Re: [oi-dev] OI no longer automounts USB sticks

[Joshua M. Clulow via oi-dev]

On Sun, 27 Jun 2021 at 21:30, Tony Brian Albers  wrote:
> 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.

At a cursory glance, it appears to be the same problem.  I plugged a
keyboard in to the machine while doing the same tracing as before, and
I see these sysevents:

EC_devfs ESC_devfs_devi_add /pci@0,0/pci8086,2064@14/device@1

EC_devfs ESC_devfs_devi_add /pci@0,0/pci8086,2064@14/device@1/keyboard@0

EC_devfs ESC_devfs_devi_add /pci@0,0/pci8086,2064@14/device@1/input@1

I believe, if these were correctly received through the glib
GIOChannel, these would end up calling into devinfo_usb_add() which
would look at the driver, find that it was "hid", and then call
devinfo_usb_input_add() to notify HAL consumers that there are new
input devices.

If someone fixes the glib channel issue, I would imagine keyboard and
mouse hotplug under X11 would also start working again.


Cheers.

-- 
Joshua M. Clulow
http://blog.sysmgr.org

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI no longer automounts USB sticks

[Tony Brian Albers]

Stephan Althaus wrote:

> Hi!
> 
> i would be happy to test something.
> 
> I would have a use case for the usb automount feature,
> and the issue with the mouse/keyboard not changeable in X as it seems,
> is related and something i am not happy with.
> 
> Stephan
> 
> 
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev
> 

I'd also like to lend a hand.

/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

Re: [oi-dev] help needed to test tem on nvidia system

[Toomas Soome via oi-dev]

Thanks!

We already got needed tests done, and now the console can handle CSI 38;2;R;G;B 
m and CSI 48;2;R;G;B m sequences.

Toomas

> On 28. Jun 2021, at 07:33, Tony Brian Albers  wrote:
> 
> Toomas Soome via oi-dev wrote:
>> 
>> 
 On 23. Jun 2021, at 10:20, Stephan Althaus 
  wrote:
>>> 
>>> On 6/22/21 11:09 PM, Toomas Soome via oi-dev wrote:
 
 hi!
 
 as I do not have nvidia gfx myself, some help is needed to test 
 https://code.illumos.org/c/illumos-gate/+/1550 
 .
 
 thanks,
 toomas
 
 
 ___
 oi-dev mailing list
 oi-dev@openindiana.org 
 https://openindiana.org/mailman/listinfo/oi-dev 
 
>>> Hi Toomas!
>>> 
>>> Would it be as easy as exchange a binary, or do i have to build 
>>> illumos-gate with the PR-changes applied ?
>>> 
>>> Greetings,
>>> 
>>> Stephan
>>> 
>>> 
>>> 
>> 
>> I’ll provide binaries and instructions (we will create BE for test, so we 
>> wont disturb your current environment).
>> 
>> thanks,
>> toomas
>> 
>>> ___
>>> oi-dev mailing list
>>> oi-dev@openindiana.org
>>> https://openindiana.org/mailman/listinfo/oi-dev
>> 
>> 
>> 
>> ___
>> oi-dev mailing list
>> oi-dev@openindiana.org
>> https://openindiana.org/mailman/listinfo/oi-dev
>> 
> 
> I've got a NVS 510 and a quadro k2200 that I can test it with.
> 
> /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