Re: Digi Watchport/T temperature sensor as /dev/ttyU

[Ian Lepore]

On Sat, 2016-07-23 at 22:04 +0200, O. Hartmann wrote:
> Am Fri, 22 Jul 2016 10:52:54 -0600
> Ian Lepore  schrieb:
> 
> > On Fri, 2016-07-22 at 18:35 +0200, O. Hartmann wrote:
> > > For temperature monitoring, we have a bunch of Digi Watchport/T
> > > sensors: 
> > > 
> > > http://ftp1.digi.com/support/documentation/9406_H.pdf
> > > 
> > >   
> > [...]
> > 
> > I think the attached patch will make it show up as a ttyU*/cuaU*
> > device
> > for you.  (You should probably use the /dev/cuaU* flavor, to avoid
> > problems with tty layer and modem control signals).
> > 
> > I keep wishing we had a mechanism, like a sysctl that could be set
> > or
> > something, that would let you supply a vendor/product pair and have
> > the
> > ugensa driver attach to that device, for quick testing of this sort
> > of
> > thing.
> > 
> > -- Ian
> 
> No, it doesn't change anything. I applied the patch to most recent
> CURRENT and it is
> still the same. But thanks anyway.
> 
> Kind regards,
> 
> oh

Oh, my bad, I forgot to mention:  You'll have to manually "kldload
ugensa" before plugging in the device (or load it from your
loader.conf).

When the change gets committed (assuming it works), the devd usb
scripts will get regenerated, and that's what handles the auto-load of
the driver.

-- Ian

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Digi Watchport/T temperature sensor as /dev/ttyU

[O. Hartmann]

Am Fri, 22 Jul 2016 10:52:54 -0600
Ian Lepore  schrieb:

> On Fri, 2016-07-22 at 18:35 +0200, O. Hartmann wrote:
> > For temperature monitoring, we have a bunch of Digi Watchport/T
> > sensors: 
> > 
> > http://ftp1.digi.com/support/documentation/9406_H.pdf
> > 
> >   
> [...]
> 
> I think the attached patch will make it show up as a ttyU*/cuaU* device
> for you.  (You should probably use the /dev/cuaU* flavor, to avoid
> problems with tty layer and modem control signals).
> 
> I keep wishing we had a mechanism, like a sysctl that could be set or
> something, that would let you supply a vendor/product pair and have the
> ugensa driver attach to that device, for quick testing of this sort of
> thing.
> 
> -- Ian

No, it doesn't change anything. I applied the patch to most recent CURRENT and 
it is
still the same. But thanks anyway.

Kind regards,

oh


pgp_1keQyLyVS.pgp
Description: OpenPGP digital signature

Re: FreeBSD 11 - BETA-1 Xen DOMU loses network when jail (VIMAGE) starts

[Miguel C]

Just as a note using netgraph (with jng script as a workaround) works

Also manually creating a bridge in the domu and adding xn0 as a member
makes this fail so the issue is indeed related to the bridge.

I'll open a PR later in case someone want to look into it, but I'm happy it
works with netgraph.


Melhores Cumprimentos // Best Regards
---
*Miguel Clara*
*IT - Sys Admin & Developer*

On Sat, Jul 23, 2016 at 8:16 PM, Miguel C  wrote:

> I had a freebsd 10 DOMU running with VIMAGE support but since there were
> some fixes in 11 I decided to give it a go...
>
> I made a clean install  and just migrated some backup config and adapted
> as needed (I only have one jail running on this box for plex and all media
> is in zfs)
> After the clean install I ofc rebuilded the kernel with VIMAGE support and
> that's the only change from GENERIC
>
> I noticed the vif interface was disappearing on the Dom0 a bit after this
> machine boot and I was able to track the issue... if I don't start the jail
> at boot I have network, so then I tried to do it manually (jail -c plex in
> this case) and although I still see "xn0" in the Dom0 (netbsd) the vif
> interface is now gone.
>
> Since I use vnet for the jail and the "jib" script provided in
> src/share/examples/jails I suspect its when the bridging occurred that
> network fails.
>
> All the scrip does is create a bridge and add both xn0 and the newly
> created epair.
>
> Thanks
>
> Melhores Cumprimentos // Best Regards
> ---
> *Miguel Clara*
> *IT - Sys Admin & Developer*
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD 11 - BETA-1 Xen DOMU loses network when jail (VIMAGE) starts

[Miguel C]

I had a freebsd 10 DOMU running with VIMAGE support but since there were
some fixes in 11 I decided to give it a go...

I made a clean install  and just migrated some backup config and adapted as
needed (I only have one jail running on this box for plex and all media is
in zfs)
After the clean install I ofc rebuilded the kernel with VIMAGE support and
that's the only change from GENERIC

I noticed the vif interface was disappearing on the Dom0 a bit after this
machine boot and I was able to track the issue... if I don't start the jail
at boot I have network, so then I tried to do it manually (jail -c plex in
this case) and although I still see "xn0" in the Dom0 (netbsd) the vif
interface is now gone.

Since I use vnet for the jail and the "jib" script provided in
src/share/examples/jails I suspect its when the bridging occurred that
network fails.

All the scrip does is create a bridge and add both xn0 and the newly
created epair.

Thanks

Melhores Cumprimentos // Best Regards
---
*Miguel Clara*
*IT - Sys Admin & Developer*
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

r303219 make kernel compile failure: cxgbe

[Kim Culhan]

cc  -c -O2 -pipe -fno-strict-aliasing  -g -nostdinc  -I. -I/usr/src/sys
-I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS
-include opt_global.h  -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
-MD  -MF.depend.t4_iov.o -MTt4_iov.o -mcmodel=kernel -mno-red-zone -mno-mmx
-mno-sse -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding
-fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign
-D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs
-fdiagnostics-show-option  -Wno-unknown-pragmas
-Wno-error-tautological-compare -Wno-error-empty-body
-Wno-error-parentheses-equality -Wno-error-unused-function
-Wno-error-pointer-sign -Wno-error-shift-negative-value  -mno-aes -mno-avx
-std=iso9899:1999 -Werror  /usr/src/sys/dev/cxgbe/t4_iov.c
-I/usr/src/sys/dev/cxgbe
/usr/src/sys/dev/cxgbe/t4_iov.c:44:10: fatal error: 't4_if.h' file not found
#include "t4_if.h"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Call for Testing: Switching back to our BSD licensed dtc(1)

[Emmanuel Vadot]

On Fri, 22 Jul 2016 22:16:41 -0600
Warner Losh  wrote:

> On Fri, Jul 22, 2016 at 1:03 AM, David Chisnall  wrote:
> > On 22 Jul 2016, at 03:40, Warner Losh  wrote:
> >>
> >> On Wed, Jul 20, 2016 at 9:51 AM, David Chisnall  
> >> wrote:
> >>> On 20 Jul 2016, at 16:46, Warner Losh  wrote:
> 
>  I've been trying to get the final spec for it. Right now it's a
>  disorganized series
>  of patches, some of which have been merge some that haven't. I'll send 
>  you a
>  copy when I can find something better than "here's the code."
> >>>
> >>> Thanks.  From the information I can find, it looks as if most of the 
> >>> machinery required to implement it is already in dtc, so it should 
> >>> (hopefully) just be a matter of adding a new keyword to detect plugins, a 
> >>> scan to find the cross-references (or possibly reusing the existing one) 
> >>> and then a little bit of extra logic.
> >>
> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/overlay-notes.txt
> >> has the specs.
> >
> > Hmm, that?s even less complete than the docs that I?d found.
> 
> Can you share that then?
> 
> >From that, it seems as if the only thing that dtc needs to do is support the 
> >/plugin/ syntax and emit a section describing unresolved references?
> 
> I believe so, yes.
> 
> >Or is dtc also expected to be able to do the merging?
> 
> I think that's TBD. We'll need, at the very least, an update libfdt
> from upstream that knows how to do the merging, as well as changes to
> /boot/loader to be able to pick and choose which plugins to add to the
> base. If we can do all that with the BSDL DTC and it passes all the
> other GPL test cases, then we may have a winner and we can get started
> integrating plugin support to /boot/loader. I know my RPi would be
> happier if it had a 'standard' DTB with a plugin for whatever 1-wire
> stuff I'm playing with today.
> 
> Warner

 ubldr already support dtb overlays as of r298821.
 Also support might come to uboot directly soon.

-- 
Emmanuel Vadot
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Hdwe UEFI upgrade report...some ??? to maybe ignore

[Jeffrey Bouquet]

I had the main desktop DDR2 mysteriously lose video ( still don't know if it is 
just needing reseating
memory or if the onboard video no longer works or if one of the four bad 
capacitors went too var
awry to still work... lack of time to test..)

Sorry for the formatting

newddr3 msi board FX-8320E..old ddr2 gigabyte ? amd
newusb mouse, had to use usm0  .oldusb mouse > legacy 
mouse adaptor, used psm0
newvt so can exit X (not tested yet)  oldsc
newvidcontrol to set resolution NOT   .   old vidcontrol 
MODE_276 brown black
newonboard EUFI/LEGACY mode  disabled sound   ...   oldgame 
theatre sound card again working
newno parallel port, card on order, ALL SLOTS FULL probably   . 
   oldparallel port onboard
newtwo pcie so Areca and Video card work ..  old
Areca, OR video, used the former
newcost $99 motherboard 
 .oldsecond hand board, probably more than $99
newnfe0 not working, none is WINDOWS strange "gaming" ...  old nfe0
  E2205   fixed with a axe/ue0 usb to ethernet box which I had
  sometimes problems with as to the novice one would try axe0 in wpa_  
etc
  ignoring the instead ue0...
new   msi nvidia 750ti 2gb no PCIE adaptor necc  old  onboard 
video
new  nvidia-driver, had to build from ports.   old  
 nvidia-driver-304   
new  8g 
.   old   2g ddr2

If one prefers DDR2 for a two-cpu-on-lan setup, anyone knows of a very reliable 
source for a pair of mobo/CPU  ?
Not important that anyone answers

Might-be-working-if-reassembled-enough-times-with-legacy-parts pentium 4  and 
DDR2 ( gigabyte amd) motherboards,
... e-waste or send to a FreeBSD developer for test and reuse somewhere?  (each 
run but no video though, amd board
is disassembled... ) 

The only question here I feel the need to address sooner not later is whether 
to duplicate the DDR3 amd system for
in-case-Xorg-crashes-at-dawn backup, or discard the DDR2 board and build/buy 
two DDR2 systems to recreate what
was working about twenty days ago flawlessly... bad capacitors on the 
motherboard notwithstanding.  ( DDR2 amd,
main was gigabyte, backup was msi...  although each without a full range of 
slots vs ATX full size and costlier) 

At any rate is is cathartic to have a fully working v11 vt desktop with sound 
that I had no clue if would work without
RMA, assistance, ... 

One or two items may be omitted from the list above... a 3x5 card has gone 
missing here since yesterday... too much
paperwork in progress. 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD_HEAD_amd64_gcc - Build #1448 - Fixed

[jenkins-admin]

FreeBSD_HEAD_amd64_gcc - Build #1448 - Fixed:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1448/
Full change log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1448/changes
Full build log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1448/console

Change summaries:

303217 by bapt:
Do not try to delete the home of the user if is is not a directory for example
"/dev/null"

PR: 211195
Submitted by:   rday 
Reported by:eniorm 
MFC after:  1 day

303213 by kib:
Addm missed required call to xo_finish() when only header is printed.

Reported by:pho
Sponsored by:   The FreeBSD Foundation
MFC after:  1 week

303212 by bdrewery:
Move chown tests to proper path

Sponsored by:   EMC / Isilon Storage Division

303211 by kib:
Implement mtx_trylock_spin(9).

Discussed with: bde
Reviewed by:jhb
Sponsored by:   The FreeBSD Foundation
MFC after:  1 week
Differential revision:  https://reviews.freebsd.org/D7192

303210 by ache:
1) POSIX defines well when GLOB_NOMATCH or original pattern
(instead) should be returned, so we can't return GLOB_NOMATCH blindly
just because we dislike something in the pattern.

2) Remove extra condition.

303209 by jhibbits:
Use label math instead of hard-coding offsets for return addresses.

Though the chances of the code in these sections changing are low, future-proof
the sections and use label math.

Renumber the surrounding areas to avoid duplicate label numbers.

303208 by ache:
1) We need the original pattern (in the next round of changes) not only in
case it fully constructed, but for half-constructed too, so have no
other choice to pass original pattern from glob() down to globextend()
instead of attempt to reconstruct I implement previously.

2) Instead of copy the same big enough code, make function for it:
globfinal().

303205 by jhb:
Add a driver to create VF devices on Chelsio T4/T5 NICs.

Chelsio NICs are a bit unique compared to some other NICs in that they
expose different functionality on different physical functions.  In
particular, PF4 is used to manage the NIC interfaces ('t4nex' and 't5nex').
However, PF4 is not able to create VF devices.  Instead, VFs are only
supported by physical functions 0 through 3.  This commit adds 't4iov'
and 't5iov' drivers that attach to PF0-3.

One extra wrinkle is that the iov devices cannot enable SR-IOV until the
firwmare has been initialized by the main PF4 driver.  To handle this
case, a new t4_if kobj interface has been added to permit cross-calls
between the PF drivers.  The PF4 driver notifies sibling drivers when it
is fully attached.  It also requests sibling drivers to detach before it
detaches.  Sibling drivers query the PF4 driver during their attach
routine to see if it is attached.  If not, the sibling drivers defer
their attach actions until the PF4 driver informs them it is attached.

VF devices are associated with a single port on the NIC.  VF devices
created from PF0 are associated with the first port on the NIC, VFs
from PF1 are associated with the second port, etc.  VF devices can
only be created from a PF device that has an associated port.  Thus,
on a 2-port card, VFs are only supported on PF0 and PF1.

Reviewed by:np (earlier versions)
MFC after:  1 month
Sponsored by:   Chelsio Communications

303204 by jhb:
Install a handler for firmware work request error messages.

If a driver sends an malformed or disallowed work request, the firmware
responds with a work request error.  Previously the driver treated this is
as an unexpected message and panicked.  Now it decodes the error message
to aid in debugging.

Reviewed by:np (older version)
MFC after:  1 month
Sponsored by:   Chelsio Communications
Differential Revision:  https://reviews.freebsd.org/D6950

303203 by mizhka:
[new-committer:mizhka] add committer into graph

Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D7288

303202 by jhb:
Update after r303154 to note that operations on local files are safe.

303199 by np:
ctld(8): Fix MaxBurstLength negotiation.

The target must reply with the selected value of MaxBurstSize instead of
just echoing back the initiator's offered value.

Reviewed by:mav@
Sponsored by:   Chelsio Communications
Differential Revision:  https://reviews.freebsd.org/D7278

303195 by bdrewery:
Don't run find(1) for __MPATH with NO_MODULES set.

It's a waste of time when it won't be used.

Submitted by:   bde
MFC after:  3 days

303190 by br:
Add GCC 6.1 warn flags for kernel as well.

Sponsored by:   DARPA, AFRL

303189 by br:
Set the soft-float flag for assembly code as well.
This fixes compilation with GCC 6.1.

Sponsored by:   DARPA, AFRL

303188 by br:
Add warn flags for GCC 6.1 compiler.

Sponsored by:   DARPA, AFRL

303187 by br:
Set real values for context/cursor sizes for RISC-V to prevent static
assertions.

Reviewed by:emaste
Sponsored by:   DARPA, AFRL

303186 

Re: Weekday missing in date(1) output

[Baptiste Daroussin]

On Mon, Jul 04, 2016 at 01:45:11PM +0200, Trond Endrestøl wrote:
> On Mon, 4 Jul 2016 08:34+0200, Baptiste Daroussin wrote:
> 
> > On Sun, Jul 03, 2016 at 10:17:54PM +0200, Thomas Eberhardt wrote:
> > > % uname -a
> > > FreeBSD clarence.ocp.lan 11.0-ALPHA6 FreeBSD 11.0-ALPHA6 #0 r302324: Sun 
> > > Jul  3 21:27:41 CEST 2016 
> > > tho...@clarence.ocp.lan:/usr/obj/usr/src/sys/GENERIC-NODEBUG  amd64
> > > % env LANG=en_US.UTF-8 date
> > > Sunday, July  3, 2016 at 10:14:21 PM CEST
> > > % env LANG=de_DE.UTF-8 date
> > >  3. Juli 2016 um 22:14:22 CEST
> > > 
> > > stable10 gives:
> > > % env LANG=de_DE.UTF-8 date
> > > So  3 Jul 2016 19:34:18 CEST
> > > 
> > > Is this intentional?
> > > 
> > I have readded the weekday in most locales, I will recheck all of them to 
> > ensure
> > the weekday is readded everywhere it was expected
> 
> nb_NO.UTF-8 and nb_NO.ISO8859-1 are also affected.
> 
Sorry it took long, but done: r303219

I will merge it on 11 tomorrow

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Call for Testing: Switching back to our BSD licensed dtc(1)

[David Chisnall]

On 23 Jul 2016, at 05:16, Warner Losh  wrote:
> 
> On Fri, Jul 22, 2016 at 1:03 AM, David Chisnall  wrote:
>> On 22 Jul 2016, at 03:40, Warner Losh  wrote:
>>> 
>>> On Wed, Jul 20, 2016 at 9:51 AM, David Chisnall  
>>> wrote:
 On 20 Jul 2016, at 16:46, Warner Losh  wrote:
> 
> I've been trying to get the final spec for it. Right now it's a
> disorganized series
> of patches, some of which have been merge some that haven't. I'll send 
> you a
> copy when I can find something better than "here's the code."
 
 Thanks.  From the information I can find, it looks as if most of the 
 machinery required to implement it is already in dtc, so it should 
 (hopefully) just be a matter of adding a new keyword to detect plugins, a 
 scan to find the cross-references (or possibly reusing the existing one) 
 and then a little bit of extra logic.
>>> 
>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/overlay-notes.txt
>>> has the specs.
>> 
>> Hmm, that’s even less complete than the docs that I’d found.
> 
> Can you share that then?

I only found tutorial-style things:

https://www.raspberrypi.org/documentation/configuration/device-tree.md

https://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/device-tree-overlays

I was hoping for something a bit more like a spec.


>> From that, it seems as if the only thing that dtc needs to do is support the 
>> /plugin/ syntax and emit a section describing unresolved references?
> 
> I believe so, yes.

That sounds like it should be easy.

> 
>> Or is dtc also expected to be able to do the merging?
> 
> I think that's TBD. We'll need, at the very least, an update libfdt
> from upstream that knows how to do the merging, as well as changes to
> /boot/loader to be able to pick and choose which plugins to add to the
> base. If we can do all that with the BSDL DTC and it passes all the
> other GPL test cases, then we may have a winner and we can get started
> integrating plugin support to /boot/loader. I know my RPi would be
> happier if it had a 'standard' DTB with a plugin for whatever 1-wire
> stuff I'm playing with today.

Patrick Wildt was running the GPL’d dtc test suite and I fixed all of the 
things that he reported broken.  We’re now using a less-efficient algorithm for 
calculating the cross-references so that we resolve things in the same order, 
which makes doing a diff on the dts produced by the two tools easier.

David



smime.p7s
Description: S/MIME cryptographic signature

seldom crashes on Dell E6330 with 12-CURRENT

[Matthias Apitz]

Hello,

I own since July 15 a new laptop and faced 3 crashes, details see below.
What can I do to gather more information? Thanks


notes in general:
- hardware: Dell E6330, amd64, 4 cores i5-3360M, 8 GByte RAM, 250 GByte SSD w/ 
TRIM
- WLAN: urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R
- kernel: GENERIC r302904 (July 15)
- poudriere 3.2-pre: compiling ~1800 ports in 4 builders
- swap as plain file in /usr/swap01, 8 GByte
- apart of the crashes below, no crash during buildworld, buildkernel and
  ~48 hours of poudriere fetching distfiles and making ~1800 ports
- no errors on 'memtest 1G'

crashes/observations:

16.07.2016 07:12 
- on shutdown swap device (plain file in /usr) could not be detached
- drop to kdb
- nothing in /var/log/messages

17.07.2016 19:41
- hard locked, had to power-off
- last command issued on console (no X11): cp -p * /usr/PKGDIR (around 1700 
files, 2 GByte)
- nothing in /var/log/messages

20.07.2016 19:27
- hard locked, had to power-off
- last command issued in xterm: fgrep mra... ~/*
- nothing in /var/log/messages

-- 
Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/  ☎ 
+49-176-38902045
"Wer übersieht, dass wir uns den anderen weggenommen haben und sie uns 
wiederhaben wollen,
kann von den Kämpfen der letzten Tage keinen verstehen. Und kann natürlich auch 
keinen
dieser Kämpfe bestehen." Hermann Kant in jW 1.10.1989
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"