Re: ntpd(8) adds time since epoch to system clock

2020-08-07 Thread Scott Cheloha 
> On Aug 7, 2020, at 11:28 AM, Otto Moerbeek  wrote:
> 
> On Fri, Aug 07, 2020 at 11:17:18AM -0500, Scott Cheloha wrote:
> 
>> On Mon, Aug 05, 2069 at 09:33:05AM +, Toby Betts wrote:
 Synopsis:  ntpd(8) adds time since epoch to system clock
 Category:  system
 Environment:
>>> System  : OpenBSD 6.6
>>> Details : OpenBSD 6.6 (GENERIC.MP) #372: Sat Oct 12 10:56:27 MDT 
>>> 2019
>>>  
>>> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>>> 
>>> Architecture: OpenBSD.amd64
>>> Machine : amd64
 Description:
>>> After rebooting a VM, ntpd(8) adjusted the system clock to 2069-08-04.
>>> The reboot command was given at approximately 2019-10-18 23:34:49 UTC,
>>> which is about 1571441689 seconds since the UNIX epoch, 1970-01-01.
>>> According to /var/log/daemon, stepping the clock from 2019-10-18 to
>>> 2069-08-04 is 1571441749.182430 seconds, which is approximately the
>>> same number of seconds as the system time on the VM when ntpd(8) was
>>> started again after the reboot.
>>> 
>>> In other words when ntpd(8) started, it set the system clock to double the
>>> current time in seconds since 1970.
>>> 
>>> Output of /var/log/daemon:
>>> 
>>> Oct 18 22:53:06 obsd ntpd[96201]: creating new /var/db/ntpd.drift
>>> Oct 18 22:53:06 obsd ntpd[3505]: ntp engine ready
>>> Oct 18 22:53:08 obsd ntpd[96201]: set local clock to Fri Oct 18 22:53:08 
>>> UTC 2019 (offset 1.652045s)
>>> Oct 18 22:53:08 obsd savecore: no core dump
>>> Oct 18 22:53:09 obsd ntpd[3505]: constraint reply from 172.217.3.196: 
>>> offset -0.075150
>>> Oct 18 22:53:28 obsd ntpd[3505]: peer 47.190.36.230 now valid
>>> Oct 18 22:53:29 obsd ntpd[3505]: peer 3.15.245.6 now valid
>>> Oct 18 22:53:30 obsd ntpd[3505]: peer 162.159.200.1 now valid
>>> Oct 18 22:53:30 obsd ntpd[3505]: peer 184.105.182.16 now valid
>>> Oct 18 22:53:31 obsd ntpd[3505]: peer 198.50.238.163 now valid
>>> Oct 18 22:58:41 obsd ntpd[3505]: clock is now synced
>>> Oct 18 22:58:41 obsd ntpd[3505]: constraint reply from 172.217.3.196: 
>>> offset -0.924238
>>> Oct 18 23:03:44 obsd ntpd[3505]: peer 3.15.245.6 now invalid
>>> Oct 18 23:04:04 obsd ntpd[3505]: peer 104.131.139.195 now valid
>>> Oct 18 23:19:12 obsd ntpd[39106]: adjusting clock frequency by -20.378477 
>>> to -20.378477ppm
>>> 
>>> [ reboot issued approximately here ]
>>> 
>>> Oct 18 23:35:12 obsd ntpd[39106]: adjusting clock frequency by -0.737827 to 
>>> -21.116304ppm
>>> Oct 18 23:35:53 obsd ntpd[35750]: ntp engine ready
>>> Aug  4 23:11:42 obsd ntpd[79447]: set local clock to Sun Aug  4 23:11:42 
>>> UTC 2069 (offset 1571441749.182430s)
>>> Aug  4 23:11:42 obsd savecore: no core dump
>>> Aug  4 23:11:43 obsd ntpd[35750]: constraint reply from 172.217.3.196: 
>>> offset -1571441748.432712
>>> Aug  4 23:12:02 obsd ntpd[35750]: peer 45.79.36.123 now valid
>>> Aug  4 23:12:03 obsd ntpd[35750]: peer 162.159.200.1 now valid
>>> Aug  4 23:12:03 obsd ntpd[35750]: peer 162.159.200.1 now valid
>>> Aug  4 23:12:04 obsd ntpd[35750]: peer 103.105.51.156 now valid
>>> Aug  4 23:12:08 obsd ntpd[35750]: peer 199.101.100.221 now valid
>>> Aug  4 23:13:02 obsd ntpd[23365]: adjusting local clock by 
>>> -1571441747.612037s
>>> Aug  4 23:16:16 obsd ntpd[23365]: adjusting local clock by 
>>> -1571441746.642918s
>>> Aug  4 23:17:19 obsd ntpd[23365]: adjusting local clock by 
>>> -1571441746.326408s
>>> Aug  4 23:21:43 obsd ntpd[23365]: adjusting local clock by 
>>> -1571441744.999186s
>>> Aug  4 23:22:14 obsd ntpd[23365]: adjusting local clock by 
>>> -1571441744.843526s
>>> Aug  4 23:26:29 obsd ntpd[23365]: adjusting local clock by 
>>> -1571441743.563666s
>>> Aug  4 23:27:35 obsd ntpd[23365]: adjusting local clock by 
>>> -1571441743.233665s
>>> Aug  4 23:28:05 obsd ntpd[23365]: adjusting local clock by 
>>> -1571441743.082044s
>>> Aug  4 23:32:22 obsd ntpd[23365]: adjusting local clock by 
>>> -1571441741.788132s
>>> Aug  4 23:33:23 obsd ntpd[35750]: peer 45.79.36.123 now invalid
>>> Aug  4 23:33:46 obsd ntpd[35750]: peer 72.87.88.202 now valid
>>> Aug  4 23:34:43 obsd ntpd[23365]: adjusting local clock by 
>>> -1571441741.077493s
>>> Aug  4 23:37:26 obsd ntpd[23365]: adjusting local clock by 
>>> -1571441740.260640s
>>> Aug  4 23:40:41 obsd ntpd[23365]: adjusting local clock by 
>>> -1571441739.281630s
>>> Aug  4 23:42:49 obsd ntpd[23365]: adjusting local clock by 
>>> -1571441738.634681s
>>> Aug  4 23:43:55 obsd ntpd[23365]: adjusting local clock by 
>>> -1571441738.304680s
>>> Aug  4 23:44:28 obsd ntpd[23365]: adjusting local clock by 
>>> -1571441738.139680s
>>> Aug  4 23:45:35 obsd ntpd[23365]: adjusting local clock by 
>>> -1571441737.800824s
>>> Aug  4 23:47:07 obsd ntpd[23365]: adjusting local clock by 
>>> -1571441737.340824s
>>> Aug  4 23:47:41 obsd ntpd[23365]: adjusting local clock by 
>>> -1571441737.170823s
>>> Aug  4 23:49:20 obsd ntpd[23365]: adjusting local clock by 
>>> -1571441736.675189s
>>> Aug  4 23:52:29

Re: uaudio device works on usb2 port; fails on usb3 port

2020-08-07 Thread Jason McIntyre 
On Fri, Aug 07, 2020 at 01:08:17PM +0200, Marcus Glocker wrote:
> On Fri, 7 Aug 2020 12:31:39 +0200
> Alexandre Ratchov  wrote:
> 
> > On Fri, Aug 07, 2020 at 10:08:25AM +0100, Patrick Harper wrote:
> > > I think asynchronous transfers don't work with xhci right now,
> > > which appears to be how your DAC works. If you can disable USB 3.0
> > > in the BIOS/UEFI setup program it should work. 
> 
> xhci(4) does support isochronous transfers.
> 
> > This device is usb1.1, it uses control and isochronous transfers that
> > xhci supports. Strangely, even certain control transfers fail with
> > this particular device.
> 
> Hmm weired.  I'm still puzzled by the lsusb output which seem to miss
> most of the uaudio device descritpor.  Could that be the reason?
> 
> jmc:
> Can you please provide usbdevs -v output and then only output of lsusb
> for that specific uaudio device from the ehci and from the xhci machine?
> 
>   # usbdevs -v
>   ...
>   # lsusb
>   ...
>   # lsusb -d : -vvv
>   ...
> 
> I would like compare if the lsusb output differs between ehci and xhci.
> 

hi.

details below. first the machine that the device works on:

# usbdevs -v
Controller /dev/usb0:
addr 01: 8086: Intel, EHCI root hub
 high speed, self powered, config 1, rev 1.00
 driver: uhub0
addr 02: 8087:0024 Intel, Rate Matching Hub
 high speed, self powered, config 1, rev 0.00
 driver: uhub2
Controller /dev/usb1:
addr 01: 8086: Intel, EHCI root hub
 high speed, self powered, config 1, rev 1.00
 driver: uhub1
addr 02: 8087:0024 Intel, Rate Matching Hub
 high speed, self powered, config 1, rev 0.00
 driver: uhub3
addr 03: 0a5c:5800 Broadcom Corp, 5880
 full speed, power 100 mA, unconfigured, rev 1.01, iSerial 
0123456789ABCD
 driver: ugen0
addr 04: 04d8:f0bf Cyrus Audio, Cyrus soundKey
 full speed, power 50 mA, config 1, rev 1.00, iSerial 001116
 driver: uaudio0
 driver: uhidev0
# lsusb
Bus 000 Device 001: ID 8086: Intel Corp. 
Bus 000 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 8086: Intel Corp. 
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 003: ID 0a5c:5800 Broadcom Corp. BCM5880 Secure Applications 
Processor
Bus 001 Device 004: ID 04d8:f0bf Microchip Technology, Inc. 
Bus 001 Device 004: ID 04d8:f0bf Microchip Technology, Inc. 
Bus 000 Device 001: ID 8086: Intel Corp. 
Bus 000 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 8086: Intel Corp. 
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 003: ID 0a5c:5800 Broadcom Corp. BCM5880 Secure Applications 
Processor
Bus 001 Device 004: ID 04d8:f0bf Microchip Technology, Inc. 
# lsusb -d 04d8:f0bf -vvv
Bus 001 Device 004: ID 04d8:f0bf Microchip Technology, Inc. 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x04d8 Microchip Technology, Inc.
  idProduct  0xf0bf 
  bcdDevice1.00
  iManufacturer   1 Cyrus Audio
  iProduct2 Cyrus soundKey
  iSerial 4 001116
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength  221
bNumInterfaces  3
bConfigurationValue 1
iConfiguration  3 Main Configuration
bmAttributes 0x80
  (Bus Powered)
MaxPower   50mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   0
  bInterfaceClass 1 Audio
  bInterfaceSubClass  1 Control Device
  bInterfaceProtocol  0 
  iInterface  0 
  AudioControl Interface Descriptor:
bLength 9
bDescriptorType36
bDescriptorSubtype  1 (HEADER)
bcdADC   1.00
wTotalLength   40
bInCollection   1
baInterfaceNr( 0)   1
  AudioControl Interface Descriptor:
bLength12
bDescriptorType36
bDescriptorSubtype  2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType  0x0101 USB Streaming
bAssocTerminal  0
bNrChannels 2
wChannelConfig 0x0003
  Left Front (L)
  Right Front (R)
iChannelNames   0 
iTerminal   0 
  AudioControl Interface Descriptor:
bLength10
bDescriptorType36
bDescriptorSubtype  6

Re: ntpd(8) adds time since epoch to system clock

2020-08-07 Thread Otto Moerbeek 
On Fri, Aug 07, 2020 at 11:17:18AM -0500, Scott Cheloha wrote:

> On Mon, Aug 05, 2069 at 09:33:05AM +, Toby Betts wrote:
> > >Synopsis:  ntpd(8) adds time since epoch to system clock
> > >Category:  system
> > >Environment:
> > System  : OpenBSD 6.6
> > Details : OpenBSD 6.6 (GENERIC.MP) #372: Sat Oct 12 10:56:27 MDT 
> > 2019
> >  
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > 
> > Architecture: OpenBSD.amd64
> > Machine : amd64
> > >Description:
> > After rebooting a VM, ntpd(8) adjusted the system clock to 2069-08-04.
> > The reboot command was given at approximately 2019-10-18 23:34:49 UTC,
> > which is about 1571441689 seconds since the UNIX epoch, 1970-01-01.
> > According to /var/log/daemon, stepping the clock from 2019-10-18 to
> > 2069-08-04 is 1571441749.182430 seconds, which is approximately the
> > same number of seconds as the system time on the VM when ntpd(8) was
> > started again after the reboot.
> > 
> > In other words when ntpd(8) started, it set the system clock to double the
> > current time in seconds since 1970.
> > 
> > Output of /var/log/daemon:
> > 
> > Oct 18 22:53:06 obsd ntpd[96201]: creating new /var/db/ntpd.drift
> > Oct 18 22:53:06 obsd ntpd[3505]: ntp engine ready
> > Oct 18 22:53:08 obsd ntpd[96201]: set local clock to Fri Oct 18 22:53:08 
> > UTC 2019 (offset 1.652045s)
> > Oct 18 22:53:08 obsd savecore: no core dump
> > Oct 18 22:53:09 obsd ntpd[3505]: constraint reply from 172.217.3.196: 
> > offset -0.075150
> > Oct 18 22:53:28 obsd ntpd[3505]: peer 47.190.36.230 now valid
> > Oct 18 22:53:29 obsd ntpd[3505]: peer 3.15.245.6 now valid
> > Oct 18 22:53:30 obsd ntpd[3505]: peer 162.159.200.1 now valid
> > Oct 18 22:53:30 obsd ntpd[3505]: peer 184.105.182.16 now valid
> > Oct 18 22:53:31 obsd ntpd[3505]: peer 198.50.238.163 now valid
> > Oct 18 22:58:41 obsd ntpd[3505]: clock is now synced
> > Oct 18 22:58:41 obsd ntpd[3505]: constraint reply from 172.217.3.196: 
> > offset -0.924238
> > Oct 18 23:03:44 obsd ntpd[3505]: peer 3.15.245.6 now invalid
> > Oct 18 23:04:04 obsd ntpd[3505]: peer 104.131.139.195 now valid
> > Oct 18 23:19:12 obsd ntpd[39106]: adjusting clock frequency by -20.378477 
> > to -20.378477ppm
> > 
> > [ reboot issued approximately here ]
> > 
> > Oct 18 23:35:12 obsd ntpd[39106]: adjusting clock frequency by -0.737827 to 
> > -21.116304ppm
> > Oct 18 23:35:53 obsd ntpd[35750]: ntp engine ready
> > Aug  4 23:11:42 obsd ntpd[79447]: set local clock to Sun Aug  4 23:11:42 
> > UTC 2069 (offset 1571441749.182430s)
> > Aug  4 23:11:42 obsd savecore: no core dump
> > Aug  4 23:11:43 obsd ntpd[35750]: constraint reply from 172.217.3.196: 
> > offset -1571441748.432712
> > Aug  4 23:12:02 obsd ntpd[35750]: peer 45.79.36.123 now valid
> > Aug  4 23:12:03 obsd ntpd[35750]: peer 162.159.200.1 now valid
> > Aug  4 23:12:03 obsd ntpd[35750]: peer 162.159.200.1 now valid
> > Aug  4 23:12:04 obsd ntpd[35750]: peer 103.105.51.156 now valid
> > Aug  4 23:12:08 obsd ntpd[35750]: peer 199.101.100.221 now valid
> > Aug  4 23:13:02 obsd ntpd[23365]: adjusting local clock by 
> > -1571441747.612037s
> > Aug  4 23:16:16 obsd ntpd[23365]: adjusting local clock by 
> > -1571441746.642918s
> > Aug  4 23:17:19 obsd ntpd[23365]: adjusting local clock by 
> > -1571441746.326408s
> > Aug  4 23:21:43 obsd ntpd[23365]: adjusting local clock by 
> > -1571441744.999186s
> > Aug  4 23:22:14 obsd ntpd[23365]: adjusting local clock by 
> > -1571441744.843526s
> > Aug  4 23:26:29 obsd ntpd[23365]: adjusting local clock by 
> > -1571441743.563666s
> > Aug  4 23:27:35 obsd ntpd[23365]: adjusting local clock by 
> > -1571441743.233665s
> > Aug  4 23:28:05 obsd ntpd[23365]: adjusting local clock by 
> > -1571441743.082044s
> > Aug  4 23:32:22 obsd ntpd[23365]: adjusting local clock by 
> > -1571441741.788132s
> > Aug  4 23:33:23 obsd ntpd[35750]: peer 45.79.36.123 now invalid
> > Aug  4 23:33:46 obsd ntpd[35750]: peer 72.87.88.202 now valid
> > Aug  4 23:34:43 obsd ntpd[23365]: adjusting local clock by 
> > -1571441741.077493s
> > Aug  4 23:37:26 obsd ntpd[23365]: adjusting local clock by 
> > -1571441740.260640s
> > Aug  4 23:40:41 obsd ntpd[23365]: adjusting local clock by 
> > -1571441739.281630s
> > Aug  4 23:42:49 obsd ntpd[23365]: adjusting local clock by 
> > -1571441738.634681s
> > Aug  4 23:43:55 obsd ntpd[23365]: adjusting local clock by 
> > -1571441738.304680s
> > Aug  4 23:44:28 obsd ntpd[23365]: adjusting local clock by 
> > -1571441738.139680s
> > Aug  4 23:45:35 obsd ntpd[23365]: adjusting local clock by 
> > -1571441737.800824s
> > Aug  4 23:47:07 obsd ntpd[23365]: adjusting local clock by 
> > -1571441737.340824s
> > Aug  4 23:47:41 obsd ntpd[23365]: adjusting local clock by 
> > -1571441737.170823s
> > Aug  4 23:49:20 obsd ntpd[23365]: adjusting local clock by 
> > -1571441736.675189s
> > Aug  4 23:52:29 obsd ntpd[23365]: adjusting local clock by 
> >

Re: ntpd(8) adds time since epoch to system clock

2020-08-07 Thread Scott Cheloha 
On Mon, Aug 05, 2069 at 09:33:05AM +, Toby Betts wrote:
> >Synopsis:ntpd(8) adds time since epoch to system clock
> >Category:system
> >Environment:
>   System  : OpenBSD 6.6
>   Details : OpenBSD 6.6 (GENERIC.MP) #372: Sat Oct 12 10:56:27 MDT 
> 2019
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   After rebooting a VM, ntpd(8) adjusted the system clock to 2069-08-04.
>   The reboot command was given at approximately 2019-10-18 23:34:49 UTC,
>   which is about 1571441689 seconds since the UNIX epoch, 1970-01-01.
>   According to /var/log/daemon, stepping the clock from 2019-10-18 to
>   2069-08-04 is 1571441749.182430 seconds, which is approximately the
>   same number of seconds as the system time on the VM when ntpd(8) was
>   started again after the reboot.
> 
> In other words when ntpd(8) started, it set the system clock to double the
> current time in seconds since 1970.
> 
> Output of /var/log/daemon:
> 
> Oct 18 22:53:06 obsd ntpd[96201]: creating new /var/db/ntpd.drift
> Oct 18 22:53:06 obsd ntpd[3505]: ntp engine ready
> Oct 18 22:53:08 obsd ntpd[96201]: set local clock to Fri Oct 18 22:53:08 UTC 
> 2019 (offset 1.652045s)
> Oct 18 22:53:08 obsd savecore: no core dump
> Oct 18 22:53:09 obsd ntpd[3505]: constraint reply from 172.217.3.196: offset 
> -0.075150
> Oct 18 22:53:28 obsd ntpd[3505]: peer 47.190.36.230 now valid
> Oct 18 22:53:29 obsd ntpd[3505]: peer 3.15.245.6 now valid
> Oct 18 22:53:30 obsd ntpd[3505]: peer 162.159.200.1 now valid
> Oct 18 22:53:30 obsd ntpd[3505]: peer 184.105.182.16 now valid
> Oct 18 22:53:31 obsd ntpd[3505]: peer 198.50.238.163 now valid
> Oct 18 22:58:41 obsd ntpd[3505]: clock is now synced
> Oct 18 22:58:41 obsd ntpd[3505]: constraint reply from 172.217.3.196: offset 
> -0.924238
> Oct 18 23:03:44 obsd ntpd[3505]: peer 3.15.245.6 now invalid
> Oct 18 23:04:04 obsd ntpd[3505]: peer 104.131.139.195 now valid
> Oct 18 23:19:12 obsd ntpd[39106]: adjusting clock frequency by -20.378477 to 
> -20.378477ppm
> 
> [ reboot issued approximately here ]
> 
> Oct 18 23:35:12 obsd ntpd[39106]: adjusting clock frequency by -0.737827 to 
> -21.116304ppm
> Oct 18 23:35:53 obsd ntpd[35750]: ntp engine ready
> Aug  4 23:11:42 obsd ntpd[79447]: set local clock to Sun Aug  4 23:11:42 UTC 
> 2069 (offset 1571441749.182430s)
> Aug  4 23:11:42 obsd savecore: no core dump
> Aug  4 23:11:43 obsd ntpd[35750]: constraint reply from 172.217.3.196: offset 
> -1571441748.432712
> Aug  4 23:12:02 obsd ntpd[35750]: peer 45.79.36.123 now valid
> Aug  4 23:12:03 obsd ntpd[35750]: peer 162.159.200.1 now valid
> Aug  4 23:12:03 obsd ntpd[35750]: peer 162.159.200.1 now valid
> Aug  4 23:12:04 obsd ntpd[35750]: peer 103.105.51.156 now valid
> Aug  4 23:12:08 obsd ntpd[35750]: peer 199.101.100.221 now valid
> Aug  4 23:13:02 obsd ntpd[23365]: adjusting local clock by -1571441747.612037s
> Aug  4 23:16:16 obsd ntpd[23365]: adjusting local clock by -1571441746.642918s
> Aug  4 23:17:19 obsd ntpd[23365]: adjusting local clock by -1571441746.326408s
> Aug  4 23:21:43 obsd ntpd[23365]: adjusting local clock by -1571441744.999186s
> Aug  4 23:22:14 obsd ntpd[23365]: adjusting local clock by -1571441744.843526s
> Aug  4 23:26:29 obsd ntpd[23365]: adjusting local clock by -1571441743.563666s
> Aug  4 23:27:35 obsd ntpd[23365]: adjusting local clock by -1571441743.233665s
> Aug  4 23:28:05 obsd ntpd[23365]: adjusting local clock by -1571441743.082044s
> Aug  4 23:32:22 obsd ntpd[23365]: adjusting local clock by -1571441741.788132s
> Aug  4 23:33:23 obsd ntpd[35750]: peer 45.79.36.123 now invalid
> Aug  4 23:33:46 obsd ntpd[35750]: peer 72.87.88.202 now valid
> Aug  4 23:34:43 obsd ntpd[23365]: adjusting local clock by -1571441741.077493s
> Aug  4 23:37:26 obsd ntpd[23365]: adjusting local clock by -1571441740.260640s
> Aug  4 23:40:41 obsd ntpd[23365]: adjusting local clock by -1571441739.281630s
> Aug  4 23:42:49 obsd ntpd[23365]: adjusting local clock by -1571441738.634681s
> Aug  4 23:43:55 obsd ntpd[23365]: adjusting local clock by -1571441738.304680s
> Aug  4 23:44:28 obsd ntpd[23365]: adjusting local clock by -1571441738.139680s
> Aug  4 23:45:35 obsd ntpd[23365]: adjusting local clock by -1571441737.800824s
> Aug  4 23:47:07 obsd ntpd[23365]: adjusting local clock by -1571441737.340824s
> Aug  4 23:47:41 obsd ntpd[23365]: adjusting local clock by -1571441737.170823s
> Aug  4 23:49:20 obsd ntpd[23365]: adjusting local clock by -1571441736.675189s
> Aug  4 23:52:29 obsd ntpd[23365]: adjusting local clock by -1571441735.717282s
> Aug  4 23:56:39 obsd ntpd[23365]: adjusting local clock by -1571441734.467036s
> Aug  4 23:58:16 obsd ntpd[23365]: adjusting local clock by -1571441733.977244s
> Aug  5 00:01:30 obsd ntpd[23365]: adjusting local clock by -1571441733.007243s
> Aug  5 00:02:36 obsd ntpd[23365]: adjusting local

cpio -p doesn't update older files

2020-08-07 Thread Mark Willson 
On a recent -current system, cpio(1), using the -p option, does
not update the target directory with newer files. For example,
when copying a file from ~/tmp/a to ~/tmp/b:

[mark@green:~/tmp/a]$ ls -l
total 4
-rw-r--r--  1 mark  mark  3 Aug  7 09:39 x
[mark@green:~/tmp/a]$ ls -l ../b
total 4
-rw-r--r--  1 mark  mark  3 Aug  7 09:39 x
[mark@green:~/tmp/a]$ echo i am not a duck >x
[mark@green:~/tmp/a]$ ls -l
total 4
-rw-r--r--  1 mark  mark  16 Aug  7 13:54 x
[mark@green:~/tmp/a]$ find . |cpio -pd ../b
[mark@green:~/tmp/a]$ ls -l ../b
total 4
-rw-r--r--  1 mark  mark  3 Aug  7 09:39 x

On other BSDs (well, FreeBSD), the older file in ~/tmp/b is updated.
The documentation for the -u option implies this is the
correct behaviour:

 -u  Overwrite files even when the original file being copied
 is older than the one that will be overwritten.

The following patch appears to fix the issue:

[mark@green:~/dev/pax] diff -u /usr/src/bin/pax/options.c options.c
--- /usr/src/bin/pax/options.c  Fri Nov 15 20:34:17 2019
+++ options.c   Tue Aug  4 16:38:29 2020
@@ -1156,7 +1156,7 @@
char *str;
FILE *fp;

-   kflag = 1;
+   uflag = 1;
pids = 1;
pmode = 1;
pmtime = 0;
@@ -1256,7 +1256,7 @@
/*
 * replace newer files
 */
-   kflag = 0;
+   uflag = 0;
break;
case 'v':
/*

cpio doesn't offer a -k option, so this seems the simplest change.

With this patch applied to pax/options.c:

[mark@green:~/tmp/a]$ find . |~/dev/pax/cpio -pd ../b
[mark@green:~/tmp/a]$ ls -l ../b
total 4
-rw-r--r--  1 mark  mark  16 Aug  7 14:00 x

Dmesg follows:

OpenBSD 6.7-current (GENERIC) #9: Thu Aug  6 15:31:02 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 1056899072 (1007MB)
avail mem = 1009991680 (963MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xf93d0 (338 entries)
bios0: vendor American Megatrends Inc. version "090008" date 12/07/2018
bios0: Microsoft Corporation Virtual Machine
acpi0 at bios0: ACPI 2.0
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP WAET SLIC OEM0 SRAT APIC OEMB
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihve0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins, remapped
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Ryzen 7 1700 Eight-Core Processor, 2602.83 MHz, 17-01-01
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLU
SH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,
AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,
AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SM
AP,CLFLUSHOPT,SHA,IBPB,VIRTSSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache
cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully
associative
cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully
associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 173MHz
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!)
acpipci0 at acpi0 PCI0
extent `acpipci0 pcibus' (0x0 - 0xff), flags=0
extent `pciio' (0x0 - 0x), flags=0
 0x1 - 0x
extent `pcimem' (0x0 - 0x), flags=0
 0x0 - 0x3fff
 0x400 - 0x
acpicmos0 at acpi0
"VMBus" at acpi0 not configured
"Hyper_V_Gen_Counter_V1" at acpi0 not configured
pvbus0 at mainbus0: Hyper-V 10.0
hyperv0 at pvbus0: protocol 4.0, features 0x2e7f
hyperv0: heartbeat, kvp, shutdown, timesync
hvs0 at hyperv0 channel 2: ide, protocol 6.2
scsibus1 at hvs0: 2 targets
sd0 at scsibus1 targ 0 lun 0: 
naa.60022480e357104f5b7149127201f778
sd0: 25600MB, 512 bytes/sector, 52428800 sectors, thin
hvs1 at hyperv0 channel 15: scsi, protocol 6.2
scsibus2 at hvs1: 2 targets
hvn0 at hyperv0 channel 14: NVS 5.0 NDIS 6.30, address 00:15:5d:00:10:06
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82443BX" rev 0x03
pcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x01
pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel
0 wired to compatibility, channel 1 wired to compatibility
pciide0: channel 0 disabled (no drives)
atapiscsi0 at pciide0 channel 1 drive 0
scsibus3 at atapiscsi0: 2 targets
cd0 at scsibus3 targ 0 lun 0:  removable
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
piixpm0 at pci0 dev 7 function 3 "Intel 82371AB Power" rev 0x02: SMBus
disabled
vga1 at pci0 dev 8 function 0

Re: uaudio device works on usb2 port; fails on usb3 port

2020-08-07 Thread Mark Kettenis 
> Date: Fri, 7 Aug 2020 12:31:39 +0200
> From: Alexandre Ratchov 
> 
> On Fri, Aug 07, 2020 at 10:08:25AM +0100, Patrick Harper wrote:
> > I think asynchronous transfers don't work with xhci right now, which 
> > appears to be how your DAC works. If you can disable USB 3.0 in the 
> > BIOS/UEFI setup program it should work.
> > 
> 
> This device is usb1.1, it uses control and isochronous transfers that
> xhci supports. Strangely, even certain control transfers fail with
> this particular device.

I believe there are (still) issues with using USB 1.x devices on
xhci(4).  Inserting a USB 2.0 hub in the chain typically helps because
in that case xhci(4) "speaks" USB 2.0 to the hub and the hub does the
transaction translation.

Re: su + unveil("/etc/nologin") - acct(2) part

2020-08-07 Thread Sebastien Marie 
On Fri, Aug 07, 2020 at 01:43:52PM +0200, Sebastien Marie wrote:
> Hi,
> 
> I recently added a new step in my ansible playbook to ran sysupgrade on batch 
> of
> hosts: it install a temporary /etc/nologin to prevent users to log-in while
> sysupgrade is fetching sets.
> 
> Now, I am seeing unveil(2) violation in acct(2) log file:
> 
> sh -U  _syspatch__ 0.00 secs Thu 
> Aug  6 16:01 (0:01:32.50)
> 
> [...] 
>
> The first one is the offender reported in acct subsystem is "sh", whereas the
> real offender is "su". I am suspecting a race, but I will look at it later.
> 

Now that I know how acct(2) works, here the explain.

Accounting informations are recorded during the lifetime of the process as flags
in pr->ps_acflag, and the reporting is done *on process exit* by calling
acct_process() function, which will collect process information and write them
to accounting file.

It means that the command name reported (pr->ps_comm) is the one at the time of
process exit.

Here, su(1) is making a violation, and next call execve(2) to "/bin/sh". So the
command name reported at process exit will be "sh".

As it is properly documented in acct(2), I will just disregard it as a bug.

 For every process initiated which terminates under normal conditions or
 misbehaves in very specific ways (e.g. file access prevented by unveil), an
 accounting record is appended to file.

Thanks.
-- 
Sebastien Marie

Re: uaudio device works on usb2 port; fails on usb3 port

2020-08-07 Thread Alexandre Ratchov 
On Fri, Aug 07, 2020 at 12:22:17PM +0100, Patrick Harper wrote:
> This is the relevant section of the dmesg that was posted:
> 
> uaudio0 at uhub3 port 2 configuration 1 interface 1 "Cyrus Audio Cyrus 
> soundKey" rev 2.00/1.00 addr 4
> uaudio0: class v1, full-speed, async, channels: 2 play, 0 rec, 2 ctls
> audio1 at uaudio0
> uhidev0 at uhub3 port 2 configuration 1 interface 2 "Cyrus Audio Cyrus 
> soundKey" rev 2.00/1.00 addr 4
> uhidev0: iclass 3/0
> uhid0 at uhidev0: input=64, output=64, feature=0
> 
> Judging by the second line, it's a class 1 async device? By comparison, this 
> is the UAC1 DAC (Behringer UCA200) I use on an xhci bus with no problems, 
> except no recording support:
> 
> xhci3 at pci7 dev 0 function 0 "Renesas uPD720202 xHCI" rev 0x02: msi, xHCI 
> 1.0
> usb3 at xhci3: USB revision 3.0
> uhub3 at usb3 configuration 1 interface 0 "Renesas xHCI root hub" rev 
> 3.00/1.00 addr 1
> ..
> uaudio1 at uhub3 port 3 configuration 1 interface 1 "Burr-Brown from TI USB 
> Audio CODEC" rev 1.10/1.00 addr 2
> uaudio1: class v1, full-speed, sync, channels: 2 play, 2 rec, 3 ctls
> audio1 at uaudio1
> uhidev1 at uhub3 port 3 configuration 1 interface 3 "Burr-Brown from TI USB 
> Audio CODEC" rev 1.10/1.00 addr 2
> uhidev1: iclass 3/0
> uhid1 at uhidev1: input=1, output=0, feature=0
> 

This is about whether the DAC/ADC has it's own clock (async) or is
clocked by the bus clock (sync).

In the "sync" case, the DAC/ADC operates at host's (thus constant)
data rate. In the "async" case, the DAC/ADC has it's own clock source
and the host must constantly adjust its data rate to match device data
rate.

The data rate is controlled using standard isoc transfers and doesn't
need extra HC capability.

su + unveil("/etc/nologin")

2020-08-07 Thread Sebastien Marie 
Hi,

I recently added a new step in my ansible playbook to ran sysupgrade on batch of
hosts: it install a temporary /etc/nologin to prevent users to log-in while
sysupgrade is fetching sets.

Now, I am seeing unveil(2) violation in acct(2) log file:

sh -U  _syspatch__ 0.00 secs Thu 
Aug  6 16:01 (0:01:32.50)
sh -U  _syspatch__ 0.00 secs Thu 
Aug  6 16:01 (0:00:00.48)
sh -U  _syspatch__ 0.00 secs Thu 
Aug  6 16:01 (0:00:01.75)
sh -U  _syspatch__ 0.00 secs Thu 
Aug  6 16:01 (0:00:03.75)
sh -U  _syspatch__ 0.00 secs Thu 
Aug  6 16:01 (0:00:02.17)
sh -U  _syspatch__ 0.00 secs Thu 
Aug  6 16:01 (0:00:00.88)
sh -U  _syspatch__ 0.00 secs Thu 
Aug  6 16:01 (0:00:00.34)
sh -U  _syspatch__ 0.00 secs Thu 
Aug  6 16:01 (0:00:06.67)
sh -U  _syspatch__ 0.00 secs Thu 
Aug  6 16:01 (0:00:01.03)
sh -U  _syspatch__ 0.00 secs Thu 
Aug  6 16:01 (0:00:02.16)
sh -U  _syspatch__ 0.00 secs Thu 
Aug  6 16:01 (0:00:01.94)
sh -U  _syspatch__ 0.00 secs Thu 
Aug  6 16:00 (0:01:31.27)
sh -U  _syspatch__ 0.00 secs Thu 
Aug  6 16:00 (0:00:00.05)
sh -U  _syspatch__ 0.00 secs Thu 
Aug  6 16:00 (0:00:00.06)
sh -U  _syspatch__ 0.00 secs Thu 
Aug  6 16:00 (0:00:00.14)

For now, I think there is several bugs.

The first one is the offender reported in acct subsystem is "sh", whereas the
real offender is "su". I am suspecting a race, but I will look at it later.

Regarding the unveil(2) violation, su(1) needs to unveil("/etc/nologin") in
order to know that users without ignorelogin knob (see login.conf(5)) shouldn't
be allowed to log-in.

The following diff do that:

diff a17537c08dc233ec23b087c648b5643d2f8e5eb3 /home/semarie/repos/openbsd/src
blob - a4cd0e0a77ab6bff8e358aa575b50f2a42199d92
file + usr.bin/su/su.c
--- usr.bin/su/su.c
+++ usr.bin/su/su.c
@@ -170,6 +170,8 @@ main(int argc, char **argv)
err(1, "unveil");
if (unveil(_PATH_DEVDB, "r") == -1)
err(1, "unveil");
+   if (unveil(_PATH_NOLOGIN, "r") == -1)
+   err(1, "unveil");
 
for (;;) {
char *pw_class = class;

Please note that with that, /etc/nologin is respected, but sysupgrade(8) or
syspatch(8) will fail if /etc/nologin is present:

# su -s /bin/sh _syspatch -c 'id'
uid=112(_syspatch) gid=112(_syspatch) groups=112(_syspatch)
# echo test >/etc/nologin
# su -s /bin/sh _syspatch -c 'id'
su: approval failure: Undefined error: 0

It fails because _syspatch user belongs to 'default' class, and 'default' has
ignorenologin set to false by default.

So I wonder if _syspatch user should be in 'daemon' class (or something new for
system user without the need of lot of ressources).

Thanks.
-- 
Sebastien Marie

Re: uaudio device works on usb2 port; fails on usb3 port

2020-08-07 Thread Patrick Harper 
This is the relevant section of the dmesg that was posted:

uaudio0 at uhub3 port 2 configuration 1 interface 1 "Cyrus Audio Cyrus 
soundKey" rev 2.00/1.00 addr 4
uaudio0: class v1, full-speed, async, channels: 2 play, 0 rec, 2 ctls
audio1 at uaudio0
uhidev0 at uhub3 port 2 configuration 1 interface 2 "Cyrus Audio Cyrus 
soundKey" rev 2.00/1.00 addr 4
uhidev0: iclass 3/0
uhid0 at uhidev0: input=64, output=64, feature=0

Judging by the second line, it's a class 1 async device? By comparison, this is 
the UAC1 DAC (Behringer UCA200) I use on an xhci bus with no problems, except 
no recording support:

xhci3 at pci7 dev 0 function 0 "Renesas uPD720202 xHCI" rev 0x02: msi, xHCI 1.0
usb3 at xhci3: USB revision 3.0
uhub3 at usb3 configuration 1 interface 0 "Renesas xHCI root hub" rev 3.00/1.00 
addr 1
..
uaudio1 at uhub3 port 3 configuration 1 interface 1 "Burr-Brown from TI USB 
Audio CODEC" rev 1.10/1.00 addr 2
uaudio1: class v1, full-speed, sync, channels: 2 play, 2 rec, 3 ctls
audio1 at uaudio1
uhidev1 at uhub3 port 3 configuration 1 interface 3 "Burr-Brown from TI USB 
Audio CODEC" rev 1.10/1.00 addr 2
uhidev1: iclass 3/0
uhid1 at uhidev1: input=1, output=0, feature=0

-- 
  Patrick Harper
  paia...@fastmail.com

On Fri, 7 Aug 2020, at 11:31, Alexandre Ratchov wrote:
> On Fri, Aug 07, 2020 at 10:08:25AM +0100, Patrick Harper wrote:
> > I think asynchronous transfers don't work with xhci right now, which 
> > appears to be how your DAC works. If you can disable USB 3.0 in the 
> > BIOS/UEFI setup program it should work.
> > 
> 
> This device is usb1.1, it uses control and isochronous transfers that
> xhci supports. Strangely, even certain control transfers fail with
> this particular device.
>

Re: uaudio device works on usb2 port; fails on usb3 port

2020-08-07 Thread Marcus Glocker 
On Fri, 7 Aug 2020 12:31:39 +0200
Alexandre Ratchov  wrote:

> On Fri, Aug 07, 2020 at 10:08:25AM +0100, Patrick Harper wrote:
> > I think asynchronous transfers don't work with xhci right now,
> > which appears to be how your DAC works. If you can disable USB 3.0
> > in the BIOS/UEFI setup program it should work. 

xhci(4) does support isochronous transfers.

> This device is usb1.1, it uses control and isochronous transfers that
> xhci supports. Strangely, even certain control transfers fail with
> this particular device.

Hmm weired.  I'm still puzzled by the lsusb output which seem to miss
most of the uaudio device descritpor.  Could that be the reason?

jmc:
Can you please provide usbdevs -v output and then only output of lsusb
for that specific uaudio device from the ehci and from the xhci machine?

# usbdevs -v
...
# lsusb
...
# lsusb -d : -vvv
...

I would like compare if the lsusb output differs between ehci and xhci.

Re: uaudio device works on usb2 port; fails on usb3 port

2020-08-07 Thread Alexandre Ratchov 
On Fri, Aug 07, 2020 at 10:08:25AM +0100, Patrick Harper wrote:
> I think asynchronous transfers don't work with xhci right now, which appears 
> to be how your DAC works. If you can disable USB 3.0 in the BIOS/UEFI setup 
> program it should work.
> 

This device is usb1.1, it uses control and isochronous transfers that
xhci supports. Strangely, even certain control transfers fail with
this particular device.

Re: uaudio device works on usb2 port; fails on usb3 port

2020-08-07 Thread Patrick Harper 
I think asynchronous transfers don't work with xhci right now, which appears to 
be how your DAC works. If you can disable USB 3.0 in the BIOS/UEFI setup 
program it should work.

-- 
  Patrick Harper
  paia...@fastmail.com

On Wed, 5 Aug 2020, at 15:35, Jason McIntyre wrote:
> hi.
> 
> i have a usb hardware dac which shows up as uaudio.  i've discovered
> that it works when plugged into a usb2 port, but not usb3. i've
> verified it fails to work on two different machines with usb3 ports.
> all machines are running current amd64.
> 
> the soundcard is recognised, but i get this on a usb2 port (which
> works):
> 
>   uhidev0: iclass 3/0
>   uhid0 at uhidev0: input=64, output=64, feature=0
> 
> and this on a usb3 port:
> 
>   uhidev0: no report descriptor
> 
> i've inlined below dmesg and "lsusb -vvv" for the working machine and
> one of the ones that doesn;t work (with the device plugged in).
> 
> ratchov examined the audio device (from afar) and concluded nothing
> looked amiss with it. mpi suggested it may be "a timing issue related
> to the sequence to probe new devices".
> 
> jmc
> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 
> working machine:
> 
> Couldn't get configuration descriptor 0, some information will be missing
> Couldn't get configuration descriptor 0, some information will be missing
> 
> Bus 000 Device 001: ID 8086: Intel Corp. 
> Device Descriptor:
>   bLength18
>   bDescriptorType 1
>   bcdUSB   2.00
>   bDeviceClass9 Hub
>   bDeviceSubClass 0 Unused
>   bDeviceProtocol 1 Single TT
>   bMaxPacketSize064
>   idVendor   0x8086 Intel Corp.
>   idProduct  0x 
>   bcdDevice1.00
>   iManufacturer   1 Intel
>   iProduct2 EHCI root hub
>   iSerial 0 
>   bNumConfigurations  1
>   Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength   25
> bNumInterfaces  1
> bConfigurationValue 1
> iConfiguration  0 
> bmAttributes 0xc0
>   Self Powered
> MaxPower0mA
> Interface Descriptor:
>   bLength 9
>   bDescriptorType 4
>   bInterfaceNumber0
>   bAlternateSetting   0
>   bNumEndpoints   1
>   bInterfaceClass 9 Hub
>   bInterfaceSubClass  0 Unused
>   bInterfaceProtocol  0 Full speed (or root) hub
>   iInterface  0 
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81  EP 1 IN
> bmAttributes3
>   Transfer TypeInterrupt
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0008  1x 8 bytes
> bInterval  12
> Hub Descriptor:
>   bLength  10
>   bDescriptorType  41
>   nNbrPorts 2
>   wHubCharacteristic 0x0002
> No power switching (usb 1.0)
> Ganged overcurrent protection
> TT think time 8 FS bits
>   bPwrOn2PwrGood  200 * 2 milli seconds
>   bHubContrCurrent  0 milli Ampere
>   DeviceRemovable0x00
>   PortPwrCtrlMask0x00
>  Hub Port Status:
>Port 1: .0503 highspeed power enable connect
>Port 2: .0500 highspeed power
> Device Status: 0x0001
>   Self Powered
> 
> Bus 000 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
> Device Descriptor:
>   bLength18
>   bDescriptorType 1
>   bcdUSB   2.00
>   bDeviceClass9 Hub
>   bDeviceSubClass 0 Unused
>   bDeviceProtocol 1 Single TT
>   bMaxPacketSize064
>   idVendor   0x8087 Intel Corp.
>   idProduct  0x0024 Integrated Rate Matching Hub
>   bcdDevice0.00
>   iManufacturer   0 
>   iProduct0 
>   iSerial 0 
>   bNumConfigurations  1
>   Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength   25
> bNumInterfaces  1
> bConfigurationValue 1
> iConfiguration  0 
> bmAttributes 0xe0
>   Self Powered
>   Remote Wakeup
> MaxPower0mA
> Interface Descriptor:
>   bLength 9
>   bDescriptorType 4
>   bInterfaceNumber0
>   bAlternateSetting   0
>   bNumEndpoints   1
>   bInterfaceClass 9 Hub
>   bInterfaceSubClass  0 Unused
>   bInterfaceProtocol  0 Full speed (or root) hub
>   iInterface  0 
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81  EP 1 IN
> bmAttributes