pcidevs for AMD 17h and Raven Ridge APUs (Ryzen)
Hi, This is a diff to add a bunch of AMD Summit Ridge (17h) and Raven Ridge PCI devices. It's in preparation of an upcoming diff for these that I've worked on in collaboration with brynet@. The link to http://www.pcidatabase.com/ in the comments for pcidevs isn't retrievable anymore. I have found device ids here instead: https://pci-ids.ucw.cz/read/PC/1022 This includes all that I could find in my dmesg on Raven Ridge Ryzen 3 2200G, as well as dmesg of the Summit Ridge Ryzen 5 1400 that I owned previously (see https://marc.info/?l=openbsd-bugs=151648196215922=2). ok? Index: pcidevs === RCS file: /cvs/src/sys/dev/pci/pcidevs,v retrieving revision 1.1853 diff -u -p -r1.1853 pcidevs --- pcidevs 6 Jul 2018 01:37:00 - 1.1853 +++ pcidevs 7 Jul 2018 18:28:47 - @@ -730,7 +730,22 @@ product AMD AMD64_15_3X_PCIE_1 0x1424 AM product AMD AMD64_15_3X_PCIE_2 0x1425 AMD64 15h PCIE product AMD AMD64_15_3X_PCIE_3 0x1426 AMD64 15h PCIE product AMD AMD64_16_PCIE 0x1439 AMD64 16h PCIE +product AMD AMD64_17_RC0x1450 AMD64 17h Root Complex +product AMD AMD64_17_IOMMU 0x1451 AMD64 17h IOMMU +product AMD AMD64_17_PCIE_10x1452 AMD64 17h PCIE +product AMD AMD64_17_PCIE_20x1453 AMD64 17h PCIE +product AMD AMD64_17_PCIE_30x1454 AMD64 17h PCIE product AMD CCPV5A 0x1456 Cryptographic Co-processor v5a +product AMD AMD64_17_HDA 0x1457 AMD64 17h HD Audio +product AMD AMD64_17_XHCI 0x145c AMD64 17h USB xHCI +product AMD AMD64_17_DF_1 0x1460 AMD64 17h Data Fabric +product AMD AMD64_17_DF_2 0x1461 AMD64 17h Data Fabric +product AMD AMD64_17_DF_3 0x1462 AMD64 17h Data Fabric +product AMD AMD64_17_DF_4 0x1463 AMD64 17h Data Fabric +product AMD AMD64_17_DF_5 0x1464 AMD64 17h Data Fabric +product AMD AMD64_17_DF_6 0x1465 AMD64 17h Data Fabric +product AMD AMD64_17_DF_7 0x1466 AMD64 17h Data Fabric +product AMD AMD64_17_DF_8 0x1467 AMD64 17h Data Fabric product AMD CCPV5B 0x1468 Cryptographic Co-processor v5b product AMD AMD64_14_HB0x1510 AMD64 14h Host product AMD AMD64_14_PCIE_10x1512 AMD64 14h PCIE @@ -766,6 +781,7 @@ product AMD AMD64_16_3X_DRAM0x1582 AMD6 product AMD AMD64_16_3X_MISC 0x1583 AMD64 16h Misc Cfg product AMD AMD64_16_3X_CPU_PM 0x1584 AMD64 16h CPU Power product AMD AMD64_16_3X_MISC_2 0x1585 AMD64 16h Misc Cfg +product AMD RAVENRIDGE_HDA 0x15e3 Raven Ridge HD Audio product AMD AMD64_15_0x_LINK 0x1600 AMD64 15/0xh Link Cfg product AMD AMD64_15_0x_ADDR 0x1601 AMD64 15/0xh Address Map product AMD AMD64_15_0x_DRAM 0x1602 AMD64 15/0xh DRAM Cfg @@ -809,6 +825,9 @@ product AMD HUDSON2_PCIE_1 0x43a0 Hudson product AMD HUDSON2_PCIE_2 0x43a1 Hudson-2 PCIE product AMD HUDSON2_PCIE_3 0x43a2 Hudson-2 PCIE product AMD HUDSON2_PCIE_4 0x43a3 Hudson-2 PCIE +product AMD 300SERIES_PCIE 0x43b4 300 Series PCIe Port +product AMD 300SERIES_SATA 0x43b7 300 Series SATA +product AMD 300SERIES_XHCI 0x43bb 300 Series xHCI /* http://www.amd.com/products/cpg/athlon/techdocs/pdf/21910.pdf */ product AMD SC751_SC 0x7006 751 System product AMD SC751_PPB 0x7007 751
Re: systat(1) iostat vs. iostat(1)
On Sat, Jul 07, 2018 at 08:28:52AM +0200, Marcus MERIGHI wrote: > Hello, > > when I run 'iostat(1) sd1 1' I get the transfer speed in MB/s. Running > 'systat(1) iostat 1' in parallel I get the transfer speed in bytes, as > calculations show. Therefore adjust the manual of systat(1): > kilobytes -> bytes. > > Marcus > someone (obsd dev) commit this or give me an ok, please. jmc > Index: systat.1 > === > RCS file: /cvs/src/usr.bin/systat/systat.1,v > retrieving revision 1.106 > diff -u -p -u -r1.106 systat.1 > --- systat.1 30 May 2018 13:53:09 - 1.106 > +++ systat.1 7 Jul 2018 06:20:03 - > @@ -293,7 +293,7 @@ this is the default. > .It Ic iostat > Display statistics about disk throughput. > Statistics > -on disk throughput show, for each drive, data transferred in kilobytes, > +on disk throughput show, for each drive, data transferred in bytes, > number of disk transactions performed, and time spent in disk accesses > (in fractions of a second). > .It Ic malloc >
Re: uaudio: fix detection of a bunch of logitech webcams
Now, i'm pretty sure i managed to properly test the device some days ago and record sound with it, but now i only manage to produce 68-bytes empty wav files, using 'aucat -f rsnd/1 -o /tmp/test.wav' after having ensured kern.audio.record was 1. Something is fishy Oks, testing & feedback welcome, so that i can move forward and get more testing/debugging done. Landry So far I'm getting the same result you describe here. The device appears to be detected properly, but it doesn't produce an audio stream. I also tested using: aucat -f rsnd/1 -o - | aucat -i - which produces silence, again the audio stream appears to be missing. I don't see any errors in dmesg. Another, different make, webcam works, so I'm fairly confident my audio/sndio settings are correct.
Re: uaudio: fix detection of a bunch of logitech webcams
On Fri, Jul 06, 2018 at 02:56:37PM +0200, Landry Breuil wrote: > > > > To test: > > > > sysctl kern.audio.record=1 > > aucat -f rsnd/1 -o /tmp/foo.wav (if the uaudio device attaches as audio1) > > > > If this actually records sound (mplayer /tmp/foo.wav to check), you've > > won. if foo.wav is 68 bytes long, then recording doesnt work, interrupts > > are triggered but no transfers happen.. > > I should add to this testing part that you should 'revert' to usb2 for > proper uaudio(4) testing, usb3/xhci doesnt really work in this usecase > and will trigger 'error creating pipe: err=INVAL endpt=0x86' errors in > dmesg. > > If you can, ensure that you use usb2 by disabling usb3 in the bios or > xhci in the kernel config. if you're using usb2, you've to connect the audio device to the root hub, so if you get the "error creating pipe ... " message, try another port.
Re: uaudio: fix detection of a bunch of logitech webcams
On Fri, Jul 06, 2018 at 01:52:57PM +0200, Landry Breuil wrote: > > New diff adding the C250 which also exhibits the same issue. I have an > okay from mpi@ on the previous diff, but i'd like actual reports that it > makes the audio device actually working (mine doesnt now, i'm digging > into it, but i'm pretty sure at some point i had it working...) > ok ratchov@ > To test: > > sysctl kern.audio.record=1 > aucat -f rsnd/1 -o /tmp/foo.wav (if the uaudio device attaches as audio1) > > If this actually records sound (mplayer /tmp/foo.wav to check), you've > won. if foo.wav is 68 bytes long, then recording doesnt work, interrupts > are triggered but no transfers happen.. > afaics, this is a unrelated problem
Re: uaudio: fix detection of a bunch of logitech webcams
On Fri, Jul 06, 2018 at 03:38:00PM +0200, Remco wrote:
> > @@ -1814,6 +1827,10 @@
> > sc->sc_audio_rev = UGETW(acdp->bcdADC);
> > DPRINTFN(2,("%s: found AC header, vers=%03x, len=%d\n",
> > __func__, sc->sc_audio_rev, aclen));
> > +
> > + /* Some webcams descriptors advertise an off-by-one wTotalLength */
> > + if (sc->sc_quirks & UAUDIO_FLAG_BAD_ADC_LEN)
> > + aclen++;
> > sc->sc_nullalt = -1;
> >
> >
>
> I'm not in a position to test yet, but I have a comment on the aclen usage.
> AFAICS aclen is used in two places with the fix in between:
>
> aclen = UGETW(acdp->wTotalLength);
> if (offs + aclen > size)
> return (USBD_INVAL);
> ...
> if (sc->sc_quirks & UAUDIO_FLAG_BAD_ADC_LEN)
> aclen++;
> ...
> ibufend = ibuf + aclen;
>
> It looks more correct to fix aclen first, but does that still work ?
> e.g.:
> aclen = UGETW(acdp->wTotalLength);
> if (sc->sc_quirks & UAUDIO_FLAG_BAD_ADC_LEN)
> aclen++;
> if (offs + aclen > size)
> return (USBD_INVAL);
> ...
> ibufend = ibuf + aclen;
>
It might be 'better' logically speaking, but i know the (offs + aclen >
size) check wasnt triggered, as the debug printf 'found AC header' is
reached.
The one triggering the 'descriptor make no sense' error codepath is the
one checking (ibuf + dp->bLength > ibufend), and ibufend is computed
with aclen>
Re: pthread_create: fix segfault when attr is NULL
Ingo Schwarze writes: > Hi Jason, > > Jason McIntyre wrote on Sat, Jul 07, 2018 at 07:17:29AM +0100: > > > the 2/3 pages should really reference the most recent standards too. > > it's just the work hasn;t been done. > > According to my understanding, the difference in policy is deliberate. > Some people may want to write C code according to specific language > standards, so knowing that a feature is available in -ansiC is > useful even if it is also available in -p1003.1-2008. In contrast, > writing shell scripts according to historic POSIX versions wouldn't > really make sense. My memory of the last time we had this discussion (documenting the multibyte functions if I recall correctly) is the same as jmc's, that it would be preferable to target a single standard but nobody has sat down and done the work.
Re: pthread_create: fix segfault when attr is NULL
On Sat, Jul 07, 2018 at 08:25:07AM +0200, Ingo Schwarze wrote: > Hi Jason, > > Jason McIntyre wrote on Sat, Jul 07, 2018 at 07:17:29AM +0100: > > > the 2/3 pages should really reference the most recent standards too. > > it's just the work hasn;t been done. > > According to my understanding, the difference in policy is deliberate. > Some people may want to write C code according to specific language > standards, so knowing that a feature is available in -ansiC is > useful even if it is also available in -p1003.1-2008. In contrast, > writing shell scripts according to historic POSIX versions wouldn't > really make sense. > > Yours, > Ingo > oh, i didn;t know that. jmc
systat(1) iostat vs. iostat(1)
Hello, when I run 'iostat(1) sd1 1' I get the transfer speed in MB/s. Running 'systat(1) iostat 1' in parallel I get the transfer speed in bytes, as calculations show. Therefore adjust the manual of systat(1): kilobytes -> bytes. Marcus Index: systat.1 === RCS file: /cvs/src/usr.bin/systat/systat.1,v retrieving revision 1.106 diff -u -p -u -r1.106 systat.1 --- systat.130 May 2018 13:53:09 - 1.106 +++ systat.17 Jul 2018 06:20:03 - @@ -293,7 +293,7 @@ this is the default. .It Ic iostat Display statistics about disk throughput. Statistics -on disk throughput show, for each drive, data transferred in kilobytes, +on disk throughput show, for each drive, data transferred in bytes, number of disk transactions performed, and time spent in disk accesses (in fractions of a second). .It Ic malloc
Re: pthread_create: fix segfault when attr is NULL
Hi Jason, Jason McIntyre wrote on Sat, Jul 07, 2018 at 07:17:29AM +0100: > the 2/3 pages should really reference the most recent standards too. > it's just the work hasn;t been done. According to my understanding, the difference in policy is deliberate. Some people may want to write C code according to specific language standards, so knowing that a feature is available in -ansiC is useful even if it is also available in -p1003.1-2008. In contrast, writing shell scripts according to historic POSIX versions wouldn't really make sense. Yours, Ingo
Re: pthread_create: fix segfault when attr is NULL
On Sat, Jul 07, 2018 at 07:42:44AM +0200, Ingo Schwarze wrote:
> Hi,
>
> Scott Cheloha wrote on Fri, Jul 06, 2018 at 07:31:36PM -0500:
> > On Fri, Jul 06, 2018 at 03:07:12PM +0200, Mark Kettenis wrote:
> >> Paul Irofti wrote on Fri, 6 Jul 2018 15:36:07 +0300:
> >>> somebody wrote:
>
> POSIX currently says:
>
> The behavior is undefined if the value specified by the attr
> argument to pthread_create() does not refer to an initialized thread
> attributes object.
>
> >>> I don't see that bit:
> >>>
> >>> http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_create.html
>
> That is -p1003.1-2004, an old version of the standard.
>
> >>> On the contrary, I see what our manual states:
> >>>
> >>> [EINVAL]
> >>> The attributes specified by attr are invalid.
>
> >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_create.html
>
> That is -p1003.1-2008, the current version of the standard.
>
> > If we're gonna adhere to the latest behavior we ought to update the cited
> > standard from ISO/IEC 9945-1:1996 ("POSIX.1") to... something more recent.
> >
> > ISO/IEC 9945-1:2009 contains the behavior you're describing, but most
> > of our manpages cite revisions of IEEE 1003.1. Most of *those* cite
> > 2008, but judging from your link the 2017 revision is the new hotness.
> >
> > The distinction between ISO/IEC 9945-1 and IEEE 1003.1 is pretty
> > fuzzy to me.
> >
> > So, which standard/revision is the preferred citation target, if any?
>
> For library functions, we tend to cite the oldest revision of POSIX
> that our implementation conforms to, that is, the first that matches
> from the following list:
>
> -ansiC \" 1989
> -isoC-99 \" 1990
> -isoC-2011 \" 2011
>
> -p1003.1 \" 1988
> -p1003.1-90\" 1990
> -p1003.1-96\" 1996
>
> -xpg3 \" 1989
> -xpg4 \" 1992
> -xpg4.2\" 1994
> -susv2 \" 1997
>
> -p1003.1-2001 \" 2001
> -p1003.1-2004 \" 2004
> -p1003.1-2008 \" 2008
>
> This approximate rule probably isn't followed completely consistently;
> for example, instead of -xpg* and -susv2, some pages might directly
> reference the later -p1003.1-2001 or -p1003.1-2004 that incorporated
> them. Some pages might also be more specific and reference e.g.
> -p1003.1c-95 instead of -p1003.1-96. Neither of that would seem
> wrong to me.
>
> Note that we will not introduce a new -p1003.1-20xx for the 2016
> edition, which is merely incorporated technical corrigenda, not a
> new revision of the standard. It has proven very rare in practice
> that the behaviour required by the 2016 edition differs from the
> behaviour required by the 2008 edition. In the odd case where it
> does, that is such a bad trap that it ought to be decribed explictly
> rather than merely with an .St argument that is easy to overlook.
>
> > And should we update all of the pthread manpages in one sweep?
>
> Any required corrections are welcome.
>
agreed.
> > cc jmc
> > PS and by "we" I totally mean "I". How hard could it be? :)
>
> The reason such sweeps are rarely done for sections 2/3 is that jmc@
> isn't comfortable doing them on his own in those sections. Where
> needed, such sweeps are certainly welcome.
>
> He did the sweep in sections 1/8. There, the policy is somewhat
> different: There, we tend to reference the *newest* standard we
> conform to from the above list.
>
the 2/3 pages should really reference the most recent standards too.
it's just the work hasn;t been done.
jmc
> Yours,
> Ingo
