daily CVS update output
Updating src tree: P src/sbin/fsck_msdos/dir.c P src/sbin/nvmectl/Makefile P src/sbin/nvmectl/firmware.c P src/sbin/nvmectl/logpage.c P src/sbin/nvmectl/nvme.h P src/sbin/nvmectl/nvmectl.8 P src/sbin/nvmectl/nvmectl.c P src/sbin/nvmectl/nvmectl.h U src/sbin/nvmectl/wdc.c P src/sys/arch/arm/nvidia/files.tegra P src/sys/arch/arm/nvidia/tegra_xusb.c P src/sys/arch/i386/stand/efiboot/Makefile.efiboot P src/sys/arch/i386/stand/efiboot/bootia32/efibootia32.c P src/sys/arch/i386/stand/efiboot/bootia32/start.S P src/sys/arch/i386/stand/efiboot/bootx64/efibootx64.c P src/sys/arch/i386/stand/efiboot/bootx64/start.S P src/sys/arch/sparc/stand/boot/Makefile P src/sys/compat/common/vm_43.c P src/sys/compat/netbsd32/netbsd32_netbsd.c P src/sys/compat/sys/mman.h P src/sys/dev/audio.c P src/sys/dev/fdt/fdtbus.c P src/sys/dev/pci/ixgbe/ixgbe.c P src/sys/netinet/in.c P src/sys/netinet6/in6.c P src/sys/sys/bootblock.h P src/sys/sys/mman.h P src/sys/uvm/uvm_mmap.c P src/sys/uvm/pmap/pmap.c P src/tests/lib/libc/stdlib/t_strtoi.c Updating xsrc tree: Killing core files: Updating tar files: src/top-level: collecting... replacing... done src/bin: collecting... replacing... done src/common: collecting... replacing... done src/compat: collecting... replacing... done src/crypto: collecting... replacing... done src/dist: collecting... replacing... done src/distrib: collecting... replacing... done src/doc: collecting... replacing... done src/etc: collecting... replacing... done src/external: collecting... replacing... done src/extsrc: collecting... replacing... done src/games: collecting... replacing... done src/gnu: collecting...pax: Unable to access src/gnu (No such file or directory) pax: WARNING! These file names were not selected: src/gnu done src/include: collecting... replacing... done src/lib: collecting... replacing... done src/libexec: collecting... replacing... done src/regress: collecting... replacing... done src/rescue: collecting... replacing... done src/sbin: collecting... replacing... done src/share: collecting... replacing... done src/sys: collecting... replacing... done src/tests: collecting... replacing... done src/tools: collecting... replacing... done src/usr.bin: collecting... replacing... done src/usr.sbin: collecting... replacing... done src/config: collecting... replacing... done src: collecting... replacing... done xsrc/top-level: collecting... replacing... done xsrc/external: collecting... replacing... done xsrc/local: collecting... replacing... done xsrc: collecting... replacing... done Running the SUP scanner: SUP Scan for current starting at Sat Apr 29 03:08:22 2017 SUP Scan for current completed at Sat Apr 29 03:08:37 2017 SUP Scan for mirror starting at Sat Apr 29 03:08:37 2017 SUP Scan for mirror completed at Sat Apr 29 03:11:11 2017 Updating release-6 src tree (netbsd-6): Updating release-6 xsrc tree (netbsd-6): Updating release-6 tar files: src/top-level: collecting... replacing... done src/bin: collecting... replacing... done src/common: collecting... replacing... done src/compat: collecting... replacing... done src/crypto: collecting... replacing... done src/dist: collecting... replacing... done src/distrib: collecting... replacing... done src/doc: collecting... replacing... done src/etc: collecting... replacing... done src/external: collecting... replacing... done src/extsrc: collecting... replacing... done src/games: collecting... replacing... done src/gnu: collecting... replacing... done src/include: collecting... replacing... done src/lib: collecting... replacing... done src/libexec: collecting... replacing... done src/regress: collecting... replacing... done src/rescue: collecting... replacing... done src/sbin: collecting... replacing... done src/share: collecting... replacing... done src/sys: collecting... replacing... done src/tests: collecting... replacing... done src/tools: collecting... replacing... done src/usr.bin: collecting... replacing... done src/usr.sbin: collecting... replacing... done src/config: collecting... replacing... done src/x11: collecting... replacing... done xsrc/top-level: collecting... replacing... done xsrc/external: collecting... replacing... done xsrc/local: collecting... replacing... done xsrc/xfree: collecting... replacing... done Running the SUP scanner: SUP Scan for release-6 starting at Sat Apr 29 03:16:37 2017 SUP Scan for release-6 completed at Sat Apr 29 03:16:46 2017 Updating release-7 src tree (netbsd-7): U doc/CHANGES-7.2 P sys/arch/amd64/amd64/locore.S P sys/arch/amd64/amd64/machdep.c P sys/arch/amd64/amd64/trap.c Updating release-7 xsrc tree (netbsd-7): Updating release-7 tar files: src/top-level: collecting... replacing... done src/bin: collecting... replacing... done src/common: collecting... replacing... done src/compat: collecting... replacing... done src/crypto: collecting... replacing... done src/dist: collecting... replacing... done src/distrib: collecting... replacing... done src/doc: collecting... replacing... done src/etc:
Re: HDMI audio attach help wanted
Date:Fri, 28 Apr 2017 21:51:36 + (UTC) From:Jared McNeill Message-ID: Thanks for the reply, | For HDMI audio to work correctly, you need to use a drm display driver, That much is OK. | and that driver needs to ensure that (1) the HDMI TX is setup in "HDMI" | mode (as opposed to "DVI" mode which works fine for video but not much | else), and (2) the HDMI TX is setup for audio and is transmitting HDMI | audio infoframes to the display. Yeah - OK - beats me... | See if you can get any debug info out of inteldrm, and/or if the version | of inteldrm in tree supports audio on your embedded intel graphics | chipset. It is i915 ... i915drmkms0 at pci0 dev 2 function 0: vendor 8086 product 0102 (rev. 0x09) drm: Memory usable by graphics device = 2048M drm: Supports vblank timestamp caching Rev 2 (21.10.2013). drm: Driver supports precise vblank timestamp query. [...] I can try turning on more debug in there (there appears to be lots) but I'm not sure I can ever figure out what any of it means, or which debug in particular might be relevant. This isn't really important (to me), so don't waste any time on it. When I get time I'll play a little and see if anything drops out of the woodwork. kre
Re: HDMI audio attach help wanted
Hi Robert --
The ELD parsing code is incomplete and not really used in the driver for
anything other than (apparently doing a poor job) at printing information
about the connected display.
It has been a while since I last looked at this, but if I remember
correctly, ELD stands for "EDID-like data" and is a block of data shared
between the HDMI transmitter and the HD audio device that can be used to
help negotiate audio parameters.
For HDMI audio to work correctly, you need to use a drm display driver,
and that driver needs to ensure that (1) the HDMI TX is setup in "HDMI"
mode (as opposed to "DVI" mode which works fine for video but not much
else), and (2) the HDMI TX is setup for audio and is transmitting HDMI
audio infoframes to the display.
See if you can get any debug info out of inteldrm, and/or if the version
of inteldrm in tree supports audio on your embedded intel graphics
chipset.
Cheers,
Jared
On Fri, 28 Apr 2017, Robert Elz wrote:
Hi all,
I have a system (core i3 processor, embedded intel graphics, old asus
motherboard) which I mostly use to run my living room clock (display a
large dclock on a smallish display...) (it also serves over the network
for some development work, but that's irrelevant.)
That stuff all works fine ... but then I thought I could multi-task a
little, and connected its HDMI output to the TV set that is just nearby.
The graphics output from that is fine, but audio does not work.
I have configured a kernel with
options HDAUDIO_ENABLE_HDMI
in it, but that just results in
hdafg1 at hdaudio0: vendor 8086 product 2805
hdafg1: DP00 8ch: Digital Out [Jack]
hdafg_dd_parse_info: datalen=83
datalen 13 sadcount 2 sizeof sad 3
hdafg1: failed to parse ELD data
hdafg1: 8ch/0ch 48000Hz PCM16*
I also noticed a very similar config output in the dmesg posted by another
user (who was actually seeking help with a quite different problem I
believe - output similar to this, but with different values - it just
happened to be there and I saw it...)
I added some extra debug in src/sys/dev/hdaudio/hdafg_dd.c and it now says...
hdafg1 at hdaudio0: vendor 8086 product 2805
hdafg1: DP00 8ch: Digital Out [Jack]
hdafg_dd_parse_info: datalen=83
ELD header block: flags=10 r1=0 eld_len=9 r2=0
baseline_eld_len=9 (*4 = 36 -> datalen)
ELD Baseline Block: flags: 67 22 0 1 port_id 0 (0) vendor d94d product 3002
hdafg monitor="SONY TV"
Bad lengths: datalen 13 sadcount 2 sizeof sad 3
0: 9 7 7 15 7 50 0 0 0 0 0 0 0
hdafg1: failed to parse ELD data
hdafg1: 8ch/0ch 48000Hz PCM16*
The "9 7 7 15 7 50 0 0 0 0 0 0 0" are the (hex) data in the 13
bytes where only 6 were actually wanted. (the extra 7 are the 0's on the
end I presume). (The "0:" is just the offset into that data, for use in
case there happen to be more than 16 bytes of it .. kind of like hexdump
output.)
Does anyone have any idea what might be happening there? Or what any of
that data (aside from the monitor name .. which is kind of obvious, and
correct...) really means? (Note that for the monitor name, the output
shown is the complete data block - any non ascii chars would have been
printed as \xXX if any had existed, so ELD_MNL(block) for that data must
have been 7 (strlen("SONY TV")) even though the debug did not print that.
Is it possible that 7 is related to the extraneous 7 bytes ?
I can supply the code that produced that debug output if it is needed
but I hope most of it is obvious - values are decimal (%d) where that
makes sense, or hex (%x) for flags, and random stray values - the port_id
is in both hex & decimal (I had no idea which would be best) which is why
the two 0's after it...
Oh, I assume it is obvious, but when this happens, no audio device attaches.
kre
ps: I note that the stray printf's (no ifdef's or anything) left in this
routine (hdafg_dd_parse_info() in hdafg_dd.c) tend to suggest that this
might all be just work in progress... Provided it is understood that I know
nothing at all about anything related, I'm willing to perform whatever tests
would be useful to assist with debugging this. Note that "nothing at all"
means I doubt I can work out know how to persuade apps to use this audio if
it does configure correctly, rather than the normal hdafg0 (audio0) on the
sound card (or however modern PCs implement this) which has nothing at all
connected to it (no speakers, headphones, or anything like that.)
Re: Proposal: new libc/libutil functions to map SIGXXXX <-> "XXXX"
On 28.04.2017 22:26, Robert Elz wrote: > Date:Fri, 28 Apr 2017 15:49:52 -0400 > From:chris...@zoulas.com (Christos Zoulas) > Message-ID: <20170428194952.6fdc217f...@rebar.astron.com> > > | | I noted that "kill -l" does not return SIGRTMIN-SIGRTMAX ones. > | > | You must be using ksh :-) > > Or bash or zsh (and dash on NetBSD anyway, is even stranger) > > /bin/kill lists them all, as does /bin/sh (and even csh). > > kre > ksh from base... I still have local patches to drop support for k&r/c89 unices from circa 1992 and in general refresh the code. I wanted to drop bourne build variation (/bin/sh) from ksh too as this code is dead, we already ship ash for this. The domain for retro-unices is already covered by mksh. Last time I discussed it with mirbsd korn shell upstream, they noted that mksh is developed for gcc1-gcc3. signature.asc Description: OpenPGP digital signature
Re: Proposal: new libc/libutil functions to map SIGXXXX <-> "XXXX"
Date:Fri, 28 Apr 2017 15:49:52 -0400 From:chris...@zoulas.com (Christos Zoulas) Message-ID: <20170428194952.6fdc217f...@rebar.astron.com> | | I noted that "kill -l" does not return SIGRTMIN-SIGRTMAX ones. | | You must be using ksh :-) Or bash or zsh (and dash on NetBSD anyway, is even stranger) /bin/kill lists them all, as does /bin/sh (and even csh). kre
Re: file corruption
On 28 April 2017 at 13:36, Patrick Welche wrote:
>
> On Wed, Apr 26, 2017 at 10:35:09AM +0100, Patrick Welche wrote:
> > On Tue, Apr 25, 2017 at 04:04:25PM +0100, Patrick Welche wrote:
> > > On Mon, Apr 24, 2017 at 05:47:50PM +0100, Patrick Welche wrote:
> > > > On Mon, Apr 24, 2017 at 05:13:45PM +0100, Robert Swindells wrote:
> > > > >
> > > > > Patrick Welche wrote:
> > > > > >The "file corruption" problem seems to be a problem with re(4):
> > > > >
> > > > > [snip]
> > > > >
> > > > > >Instead of using
> > > > > >
> > > > > >re0 at pci3 dev 0 function 0: RealTek 8168/8111 PCIe Gigabit
> > > > > >Ethernet (rev. 0x07)
> > > > > >re0: interrupting at msi3 vec 0
> > > > > >rgephy0 at re0 phy 7: RTL8169S/8110S/8211 1000BASE-T media
> > > > > >interface, rev. 5
> > > > > >
> > > > > >(with ip4csum etc enabled)
> > > > > >
> > > > > >I tried a USB wireless dongle, and the same cvs checkout over urtwm0
> > > > > >appears to be fine. (No change of kernel, no reboot.)
> > > > >
> > > > > Are you using IPv4 or IPv6 ?
> > > > >
> > > > > I don't have any suggestions on a fix, just that re(4) only seems to
> > > > > have hardware acceleration for IPv4 so you will get a different path
> > > > > through the network stack for the two protocols.
> > > >
> > > > IPv4
> > > >
> > > > I'll try -current next, given that Jared added a RTKQ_IM_HW quirk for
> > > > precisely this model...
> > >
> > > Switching off {ip,tcp,udp}4csum with the previously described setup didn't
> > > help and neither did nyftp's 20170430Z with the quirk.
> >
> > Tried iwm(4) with the nyftp 20170430Z generic kernel and also see
> > bits of cvs protocol:
> >
> > src/crypto/external/bsd/openssl/lib/libcrypto/arch/x86_64/sha1-x86_64.S:
> >
> > addl%edx,%ebx
> > rorxl $27,%ecx,%r12d
> > rorxl $2,%ecx,%edx
> > andl%esi,Mod-time 27 Jan 2017 23:00:50 -
> > MT +updated
> > MT text U
> > MT fname
> > src/crypto/external/bsd/openssl/lib/libcrypto/man/openssl_ui_compat.3
> >
> >
> > re and iwm are way faster than urtwn... Userland is all from the nyftp
> > 20170430Z.
>
> Netbooting 7.1, a cvs co through re(4) appears to be clean.
> Unfortunately I can't run 7.1, as it's a new computer which only
> has USB3 ports, so no keyboard on 7.1.
In case it helps the latest netbsd-7 branch builds from
http://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-7/ should have the
USB-3 code pulled up from -current.
David
Re: Proposal: new libc/libutil functions to map SIGXXXX <-> "XXXX"
On Apr 28, 9:32pm, n...@gmx.com (Kamil Rytarowski) wrote: -- Subject: Re: Proposal: new libc/libutil functions to map SIG <-> " | I noted that "kill -l" does not return SIGRTMIN-SIGRTMAX ones. You must be using ksh :-) christos
Re: Proposal: new libc/libutil functions to map SIGXXXX <-> "XXXX"
On 28.04.2017 21:23, Robert Elz wrote: > And all this is why it is a good value to return to indicate "not a signal". > I agree that signal 0 should be skipped. I noted that "kill -l" does not return SIGRTMIN-SIGRTMAX ones. signature.asc Description: OpenPGP digital signature
Re: Proposal: new libc/libutil functions to map SIGXXXX <-> "XXXX"
Date:Fri, 28 Apr 2017 18:59:08 + (UTC) From:chris...@astron.com (Christos Zoulas) Message-ID: | Signal 0 is special -- unfortunately it does not have a name... Perhaps | "0" <-> 0? No, 0 is not a signal, special or otherwise - rather it can be used instead of a signal (sometimes, like in kill(2)) to achieve a different result (which is more co-incidence than planned I believe - it was not initially documented to be possible). To count as a signal it needs to affect (or at least be noticed, or noticeable, by) the affected process(es). Giving it any kind of signal name would be a mistake. And all this is why it is a good value to return to indicate "not a signal". kre
Re: Proposal: new libc/libutil functions to map SIGXXXX <-> "XXXX"
In article <3385.1493397...@andromeda.noi.kre.to>, Robert Elz wrote: >Date:Fri, 28 Apr 2017 15:31:10 + (UTC) >From:chris...@astron.com (Christos Zoulas) >Message-ID: > > | Fine, return NULL for no signal number / and -1 for no such signal name. > >I think 0 for no name is better, we know there is not (and cannot be) a >signal 0, but -1 ? Unlikely, but... (and besides, people often assume >that funcs that return -1 to indicate error also set errno, and this does not.) Signal 0 is special -- unfortunately it does not have a name... Perhaps "0" <-> 0? christos
Re: Proposal: new libc/libutil functions to map SIGXXXX <-> "XXXX"
Date:Fri, 28 Apr 2017 15:31:10 + (UTC) From:chris...@astron.com (Christos Zoulas) Message-ID: | Fine, return NULL for no signal number / and -1 for no such signal name. I think 0 for no name is better, we know there is not (and cannot be) a signal 0, but -1 ? Unlikely, but... (and besides, people often assume that funcs that return -1 to indicate error also set errno, and this does not.) | I would just leave __pure out of the man page for now. Yes, that's what I have done The proposal is now to put ... const char *signalname(int) __pure; int signalnumber(const char *); in (somewhere in a _NETBSD_SOURCE proctected area), and the man page will be as below. The tgz file at ftp://munnari.oz.au/kre/signame.tgz has been updated to reflect all of this. More comments/suggestions ? kre SIGNALNAME(3) Library Functions Manual SIGNALNAME(3) NAME signalname signalnumber -- convert between signal numbers and names LIBRARY Standard C Library (libc, -lc) SYNOPSIS #include const char * signalname(int sig); int signalnumber(const char *name); DESCRIPTION The signalname() function takes a signal number sig, and returns the name of that signal. Signal names returned do not contain a leading ``SIG'' prefix. The return value of signalname() is NULL if sig does not represent a valid signal number. The signalnumber() function converts the signal name name to the number corresponding to that signal. The name is handled in a case-insensitive manner. Any leading ``SIG'' prefix in name is ignored. The signalnumber() function returns the signal number, or zero (0) if the name given does not represent a valid signal. SEE ALSO intro(2), psignal(3), strsignal(3) HISTORY The signalname() and signalnumber() functions first appeared in NetBSD 8.0.
Re: Proposal: new libc/libutil functions to map SIGXXXX <-> "XXXX"
In article <26015.1493391...@andromeda.noi.kre.to>, Robert Elz wrote: > >No, none of those, people who want that kind of output waht strsignal() >instead. The return value is just something like "EMT" or "HUP", the >only reasonable return value for an error here is "nothing" (ie: NULL). Fine, return NULL for no signal number / and -1 for no such signal name. >Now the next question is just what goes in the man page, for that __pure >stuff, and if it goes there, how to produce that using -mdoc I would just leave __pure out of the man page for now. christos
Re: Proposal: new libc/libutil functions to map SIGXXXX <-> "XXXX"
Date:Fri, 28 Apr 2017 14:39:00 + (UTC)
From:chris...@astron.com (Christos Zoulas)
Message-ID:
| Well, I am sure that whatever we pick that is reasonable at this point
| will bound to conflict with something else so I prefer to pick the
| best names for the job instead :-)
Agreed, but if we can avoid conflicting with *everything* that would be
better (provided the name picked is reasonable) - it is not as if there
aren't multiple possible choices.
| >Joerg Sonnenberger said:
| > | I'd call it signalnumber and signalname,
|
| sure, those work too.
For now, let's assume those will be what we use...
| Pure means that it will return the same value given the same argument,
OK, thanks... (Somewhere I kind of knew that...)
| I am not sure about making it pure though; how about if you pass a signal
| number that does not exist? Should it return "Unknown signal", or
| "Unknown signal %d".
No, none of those, people who want that kind of output waht strsignal()
instead. The return value is just something like "EMT" or "HUP", the
only reasonable return value for an error here is "nothing" (ie: NULL).
The version I proposed returned 0, and left the name buffer unchanged in
this case, but using Joerg's suggestion (which I am liking more and more)
it would just be a NULL return. Then if the application happens to
want "Unknown signal %d" it can just *printf("Unknown signal %d", ...);
Now the next question is just what goes in the man page, for that __pure
stuff, and if it goes there, how to produce that using -mdoc
kre
Re: Proposal: new libc/libutil functions to map SIGXXXX <-> "XXXX"
In article <19292.1493388...@andromeda.noi.kre.to>, Robert Elz wrote: >Date:Fri, 28 Apr 2017 11:38:38 + (UTC) >From:chris...@astron.com (Christos Zoulas) >Message-ID: > > | Perhaps signame() -> strsignal_r()? > >Uh, no, strsignal() (while it could probably do with an _r variant) >is something quite different - it returns "emulator trap" (or something) >in a locale dependent way, where the new function returns "EMT", given >that SIGEMT is the signal number handed to both. Ah ok. >I'm not sure I'm competent to deal with locale using functions, >or I'd probably have suggested a thread safe version of strsignal() >as well. (Or rather, I'm sure I'm not competent...) Yes, leave it. >However, in an off-list message (which I asked him to repeat on list, >but which has not happened yet) Kamil did indicate that the names I >picked conflict (badly for signame) with names used (presumably for >other things) in other software, so we do probably need something >different... perhaps signal_name() and signal_number() ? Well, I am sure that whatever we pick that is reasonable at this point will bound to conflict with something else so I prefer to pick the best names for the job instead :-) >Joerg Sonnenberger said: > > | I'd call it signalnumber and signalname, > >those names would be fine too (assuming they're not in wide use elsewhere...) sure, those work too. > | I'd just make it > | const char *signame(int sig) __pure > >That would certainly simplify it a bit (but what does __pure mean? And >if there, would that be in the man page, or just the code? (.c & .h) .. and >if in the man page, does anyone know the markup method to accomplish that?) Pure means that it will return the same value given the same argument, for example sqrt() is pure. Pure functions can be cached. I am not sure about making it pure though; how about if you pass a signal number that does not exist? Should it return "Unknown signal", or "Unknown signal %d". Certainly the second is better but it needs a static buffer... I think I prefer orthogonality here; make it like strerror() and strerror_r()? strsigname() and strsigname_r()? christos
Re: Proposal: new libc/libutil functions to map SIGXXXX <-> "XXXX"
Date:Fri, 28 Apr 2017 11:38:38 + (UTC) From:chris...@astron.com (Christos Zoulas) Message-ID: | Perhaps signame() -> strsignal_r()? Uh, no, strsignal() (while it could probably do with an _r variant) is something quite different - it returns "emulator trap" (or something) in a locale dependent way, where the new function returns "EMT", given that SIGEMT is the signal number handed to both. I'm not sure I'm competent to deal with locale using functions, or I'd probably have suggested a thread safe version of strsignal() as well. (Or rather, I'm sure I'm not competent...) However, in an off-list message (which I asked him to repeat on list, but which has not happened yet) Kamil did indicate that the names I picked conflict (badly for signame) with names used (presumably for other things) in other software, so we do probably need something different... perhaps signal_name() and signal_number() ? Joerg Sonnenberger said: | I'd call it signalnumber and signalname, those names would be fine too (assuming they're not in wide use elsewhere...) | I'd just make it | const char *signame(int sig) __pure That would certainly simplify it a bit (but what does __pure mean? And if there, would that be in the man page, or just the code? (.c & .h) .. and if in the man page, does anyone know the markup method to accomplish that?) kre ps: in another off-list message, Paul Goyette sent a correction to the man page ... that got made, I also added a little to the test prog (but neither of those are in the ftp:// file yet) - most of the test prog will vanish if we adopt Joerg's suggestion.
Re: file corruption
On Wed, Apr 26, 2017 at 10:35:09AM +0100, Patrick Welche wrote:
> On Tue, Apr 25, 2017 at 04:04:25PM +0100, Patrick Welche wrote:
> > On Mon, Apr 24, 2017 at 05:47:50PM +0100, Patrick Welche wrote:
> > > On Mon, Apr 24, 2017 at 05:13:45PM +0100, Robert Swindells wrote:
> > > >
> > > > Patrick Welche wrote:
> > > > >The "file corruption" problem seems to be a problem with re(4):
> > > >
> > > > [snip]
> > > >
> > > > >Instead of using
> > > > >
> > > > >re0 at pci3 dev 0 function 0: RealTek 8168/8111 PCIe Gigabit Ethernet
> > > > >(rev. 0x07)
> > > > >re0: interrupting at msi3 vec 0
> > > > >rgephy0 at re0 phy 7: RTL8169S/8110S/8211 1000BASE-T media interface,
> > > > >rev. 5
> > > > >
> > > > >(with ip4csum etc enabled)
> > > > >
> > > > >I tried a USB wireless dongle, and the same cvs checkout over urtwm0
> > > > >appears to be fine. (No change of kernel, no reboot.)
> > > >
> > > > Are you using IPv4 or IPv6 ?
> > > >
> > > > I don't have any suggestions on a fix, just that re(4) only seems to
> > > > have hardware acceleration for IPv4 so you will get a different path
> > > > through the network stack for the two protocols.
> > >
> > > IPv4
> > >
> > > I'll try -current next, given that Jared added a RTKQ_IM_HW quirk for
> > > precisely this model...
> >
> > Switching off {ip,tcp,udp}4csum with the previously described setup didn't
> > help and neither did nyftp's 20170430Z with the quirk.
>
> Tried iwm(4) with the nyftp 20170430Z generic kernel and also see
> bits of cvs protocol:
>
> src/crypto/external/bsd/openssl/lib/libcrypto/arch/x86_64/sha1-x86_64.S:
>
> addl%edx,%ebx
> rorxl $27,%ecx,%r12d
> rorxl $2,%ecx,%edx
> andl%esi,Mod-time 27 Jan 2017 23:00:50 -
> MT +updated
> MT text U
> MT fname src/crypto/external/bsd/openssl/lib/libcrypto/man/openssl_ui_compat.3
>
>
> re and iwm are way faster than urtwn... Userland is all from the nyftp
> 20170430Z.
Netbooting 7.1, a cvs co through re(4) appears to be clean.
Unfortunately I can't run 7.1, as it's a new computer which only
has USB3 ports, so no keyboard on 7.1.
HDMI audio attach help wanted
Hi all,
I have a system (core i3 processor, embedded intel graphics, old asus
motherboard) which I mostly use to run my living room clock (display a
large dclock on a smallish display...) (it also serves over the network
for some development work, but that's irrelevant.)
That stuff all works fine ... but then I thought I could multi-task a
little, and connected its HDMI output to the TV set that is just nearby.
The graphics output from that is fine, but audio does not work.
I have configured a kernel with
options HDAUDIO_ENABLE_HDMI
in it, but that just results in
hdafg1 at hdaudio0: vendor 8086 product 2805
hdafg1: DP00 8ch: Digital Out [Jack]
hdafg_dd_parse_info: datalen=83
datalen 13 sadcount 2 sizeof sad 3
hdafg1: failed to parse ELD data
hdafg1: 8ch/0ch 48000Hz PCM16*
I also noticed a very similar config output in the dmesg posted by another
user (who was actually seeking help with a quite different problem I
believe - output similar to this, but with different values - it just
happened to be there and I saw it...)
I added some extra debug in src/sys/dev/hdaudio/hdafg_dd.c and it now says...
hdafg1 at hdaudio0: vendor 8086 product 2805
hdafg1: DP00 8ch: Digital Out [Jack]
hdafg_dd_parse_info: datalen=83
ELD header block: flags=10 r1=0 eld_len=9 r2=0
baseline_eld_len=9 (*4 = 36 -> datalen)
ELD Baseline Block: flags: 67 22 0 1 port_id 0 (0) vendor d94d product 3002
hdafg monitor="SONY TV"
Bad lengths: datalen 13 sadcount 2 sizeof sad 3
0: 9 7 7 15 7 50 0 0 0 0 0 0 0
hdafg1: failed to parse ELD data
hdafg1: 8ch/0ch 48000Hz PCM16*
The "9 7 7 15 7 50 0 0 0 0 0 0 0" are the (hex) data in the 13
bytes where only 6 were actually wanted. (the extra 7 are the 0's on the
end I presume). (The "0:" is just the offset into that data, for use in
case there happen to be more than 16 bytes of it .. kind of like hexdump
output.)
Does anyone have any idea what might be happening there? Or what any of
that data (aside from the monitor name .. which is kind of obvious, and
correct...) really means? (Note that for the monitor name, the output
shown is the complete data block - any non ascii chars would have been
printed as \xXX if any had existed, so ELD_MNL(block) for that data must
have been 7 (strlen("SONY TV")) even though the debug did not print that.
Is it possible that 7 is related to the extraneous 7 bytes ?
I can supply the code that produced that debug output if it is needed
but I hope most of it is obvious - values are decimal (%d) where that
makes sense, or hex (%x) for flags, and random stray values - the port_id
is in both hex & decimal (I had no idea which would be best) which is why
the two 0's after it...
Oh, I assume it is obvious, but when this happens, no audio device attaches.
kre
ps: I note that the stray printf's (no ifdef's or anything) left in this
routine (hdafg_dd_parse_info() in hdafg_dd.c) tend to suggest that this
might all be just work in progress... Provided it is understood that I know
nothing at all about anything related, I'm willing to perform whatever tests
would be useful to assist with debugging this. Note that "nothing at all"
means I doubt I can work out know how to persuade apps to use this audio if
it does configure correctly, rather than the normal hdafg0 (audio0) on the
sound card (or however modern PCs implement this) which has nothing at all
connected to it (no speakers, headphones, or anything like that.)
bad counter for ixg* interfaces
Hello, ifconfig -v ixg0 shows: ixg0: flags=8843 mtu 1500 capabilities=fff80 capabilities=fff80 capabilities=fff80 enabled=0 ec_capabilities=7 ec_enabled=7 address: a0:36:9f:d4:3c:08 media: Ethernet autoselect (10GbaseSR full-duplex,rxpause,txpause) status: active input: 22429456 packets, 12404771626 bytes, 132266 multicasts output: 10573554 packets, 0 bytes ... The outgoing packets are counted correctly. The outgoing bytes remain at 0. Kernel version: NetBSD 7.99.70. Older Versions have the same problem. Programs like the snmpd which the counter evaluate provide wrong data. Maybe someone can take a look at the code. Thank you for your efforts Regards Uwe
Re: Proposal: new libc/libutil functions to map SIGXXXX <-> "XXXX"
On Fri, Apr 28, 2017 at 09:01:59AM +0700, Robert Elz wrote: > LIBRARY > Standard C Library (libc, -lc) > > SYNOPSIS > #include > > int > signame(int sig, char *name, size_t namelen); > > int > signumber(const char *name); libc is fine. I'd call it signalnumber and signalname, but ok. Do we really need to deal with dynamic signal numbers? I'd just make it const char *signame(int sig) __pure and if the application wants to use its own buffer, it can then str(l)cpy or strdup it. Joerg
Re: Proposal: new libc/libutil functions to map SIGXXXX <-> "XXXX"
In article <4777.1493344...@andromeda.noi.kre.to>,
Robert Elz wrote:
>Currently on NetBSD (and most other BSDs I believe) the only way to
>map between signal numbers (SIGHUP etc) and their string names ("HUP"
>or "SIGHUP") is via use of the sys_signame[] array provided from libc.
>
>That's crude and ugly, and requires building in the size of that array
>(so the signal number can be bounds checked before use as an index, even
>if for no other reason) - and relies upon the same NSIG being defined in
>the current libc as was used when the application was compiled.
>
>There was a proposal on the austin (POSIX standards maintainers) list to
>add new functions to fill the gap (not all systems even have sys_signame.)
>That group do not invent new interfaces (or should not, and usually don't)
>but it turns out that recent Solaris (and Illuminos) has functions called
>str2sig() and sig2str() with somewhat ugly interfaces (sig2str stores into
>a buffer passed in with no accompanying length for example.)
>
>I'd like to see something better than that, so I am proposing adding to
>NetBSD functions as described in the following man page. This is written
>as if the functions are to go in libc, but that's just because I had to
>pick somewhere to make the man page complete, we could also put them in
>libutil if that is preferred.
>
>These functions would be used in programs like the shell, kill, ...
>which allow users to specify signal names (they currently roll their own.)
>
>I enclose the cat (formated man) page below. The entire current sources
>(which includes the man page source, sources for the two functions, and a
>fairly dumb test prog) are available at:
> ftp://munnari.oz.au/kre/signame.tgz
>That does not contain the diffs which will be needed to add prototypes
>and a new #define to however (those are trivial...)
>For now all this is _NETBSD_SOURCE of course. (The tgz file is just 2410
>bytes long, so don't assume when you fetch something that short that it
>somehow got truncated!)
>
>There is no makefile - just "cc *.c" works (on NetBSD -- this code depends
>upon sys_signame[] so is not expected to be particularly portable.)
>Eventually these would be added to the appropriate lib*/Makefile of course.
>
>Comments (particularly upon the interface API, names, etc, but also upon
>the actual implementation, such as it is -- this stuff is trivial, it took
>me 10 times as long to write the manual as the code...) are welcome.
>
>kre
>
>ps: this cat page (output from mandoc) has been piped through col -b
>so formatting additions (underlining, ...) have been removed for the
>purposes of this e-mail. These is no real need to comment on wording (etc)
>of this manual page, that can be fixed later if we keep this. None of
>this has been spell checked (yet.)
>
>SIGNAME(3)Library Functions Manual SIGNAME(3)
>
>NAME
> signame signumber -- convert between signal numbers and names
>
>LIBRARY
> Standard C Library (libc, -lc)
>
>SYNOPSIS
> #include
>
> int
> signame(int sig, char *name, size_t namelen);
>
> int
> signumber(const char *name);
>
>DESCRIPTION
> The signame() function takes a signal number sig, places the name of that
> signal in the buffer given by name (which contains namelen bytes) or as
> much of the signal name as will fit in that buffer, and still allow it to
> be nul (`\0') terminated. Signal names returned do not contain a leading
> ``SIG'' prefix.
>
> The return value of signame() is zero (0) if sig does not represent a
> valid signal number, otherwise it is the length of the name of the signal
> corresponding to that number. Note: this can be longer than namelen,
> which allows applications to determine whether the buffer provided was
> large enough. If the return value is greater than 0, and less than
> namelen then the complete signal name has been returned in name.
> Otherise if the return value is namelen or larger, a truncated name has
> been returned. If the return value is 0, sig was not a valid signal
> number, and the buffer at name is unchanged.
>
> The signumber() function converts the signal name name to the number
> corresponding to that signal. Any leading ``SIG'' prefix in name is
> ignored. The name is compared in a case independent manner. The
> signumber() function returns the signal number, or zero (0) if the name
> given does not represent a valid signal.
>
> The file defines the constant MAX_SIG_NAME_LEN which may be
> used by applications to size the buffer for use by the signame()
> function. However, applications should be aware that this information is
> valid only in relation to the particular system upon which, and at the
> particular time at which, compilation is performed. When signame() is
> actually invoked, signals with longer names may exist. signame() may be
> invoked with a namelen of zero
