FreeBSD 11.0-BETA2 Now Available

[Glen Barber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The second BETA build of the 11.0-RELEASE release cycle is now
available.

Installation images are available for:

o 11.0-BETA2 amd64 GENERIC
o 11.0-BETA2 i386 GENERIC
o 11.0-BETA2 powerpc GENERIC
o 11.0-BETA2 powerpc64 GENERIC64
o 11.0-BETA2 sparc64 GENERIC
o 11.0-BETA2 armv6 BANANAPI
o 11.0-BETA2 armv6 BEAGLEBONE
o 11.0-BETA2 armv6 CUBIEBOARD
o 11.0-BETA2 armv6 CUBIEBOARD2
o 11.0-BETA2 armv6 CUBOX-HUMMINGBOARD
o 11.0-BETA2 armv6 GUMSTIX
o 11.0-BETA2 armv6 RPI-B
o 11.0-BETA2 armv6 RPI2
o 11.0-BETA2 armv6 PANDABOARD
o 11.0-BETA2 armv6 WANDBOARD
o 11.0-BETA2 aarch64 GENERIC

Note regarding arm/armv6 images: For convenience for those without
console access to the system, a freebsd user with a password of
freebsd is available by default for ssh(1) access.  Additionally,
the root user password is set to root, which it is strongly
recommended to change the password for both users after gaining
access to the system.

Installer images and memory stick images are available here:

ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/11.0/

The image checksums follow at the end of this e-mail.

If you notice problems you can report them through the Bugzilla PR
system or on the -stable mailing list.

If you would like to use SVN to do a source based update of an existing
system, use the "stable/11" branch.

A summary of changes since 11.0-BETA1 includes:

o Several build-/toolchain-related fixes.

o WITNESS and INVARIANTS have been disabled on powerpc/powerpc64 and
  arm/armv6 architectures.

o freebsd-update(8) has been updated to allow '*-dbg' distribution sets.

o ctld(8) no longer exits when reloading the configuration with invalid
  initiator-portal clauses.

o GENERIC-NODEBUG kernel configurations have been removed.

o The callout code has been updated to avoid a system panic with TCP
  timers.

o Several other changes.

A list of changes since 10.0-RELEASE are available on the stable/11
release notes:

https://www.freebsd.org/relnotes/11-STABLE/relnotes/article.html

Please note, the release notes page is not yet complete, and will be
updated on an ongoing basis as the 11.0-RELEASE cycle progresses.

=== Virtual Machine Disk Images ===

VM disk images are available for the amd64 and i386 architectures.
Disk images may be downloaded from the following URL (or any of the
FreeBSD FTP mirrors):

ftp://ftp.freebsd.org/pub/FreeBSD/releases/VM-IMAGES/11.0-BETA2/

The partition layout is:

~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label)
~ 1 GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label)

The disk images are available in QCOW2, VHD, VMDK, and raw disk image
formats.  The image download size is approximately 135 MB and 165 MB
respectively (amd64/i386), decompressing to a 21 GB sparse image.

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  See this page for more information:

https://wiki.freebsd.org/arm64/QEMU

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
-bios QEMU_EFI.fd -serial telnet::,server -nographic \
-drive if=none,file=VMDISK,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-device virtio-net-device,netdev=net0 \
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

=== Amazon EC2 AMI Images ===

FreeBSD/amd64 EC2 AMIs are available in the following regions:

 us-east-1 region: ami-684bc37f
 us-west-1 region: ami-2592d345
 us-west-2 region: ami-210cc041
 sa-east-1 region: ami-511b8f3d
 eu-west-1 region: ami-3d12704e
 eu-central-1 region: ami-92f80cfd
 ap-northeast-1 region: ami-355ba354
 ap-northeast-2 region: ami-edef2583
 ap-southeast-1 region: ami-789d421b
 ap-southeast-2 region: ami-1a81ab79

=== Vagrant Images ===

FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can
be installed by running:

% vagrant init freebsd/FreeBSD-11.0-BETA2
% vagrant up

Note to freebsd-update(8) consumers: An EN for earlier FreeBSD releases
is required before upgrading to 11.0-BETA2 will work properly, so it is
advised to wait until the ENs are published before attempting an upgrade
via freebsd-update(8).

== ISO CHECKSUMS ==

o 11.0-BETA2 amd64 GENERIC:
  SHA512 (FreeBSD-11.0-BETA2-amd64-bootonly.iso) = 
a9bb4b98001e783c71b7d1f046a5dacf2cf992f5d3baa7dcba0ea0fdb126421f43509757a794562661200ed6abb8a72c671d7968c2b9f64c660e10f9a094
  SHA512 (FreeBSD-11.0-BETA2-amd64-bootonly.iso.xz) = 
92d6faa8b1c3c19fae79d42c3c39e01b9e0a41bf726c6c8218c545f057a26b18440dcae530326881781918165f0197f28a1c634bee00352627fd0e0ad6c6f497
  SHA512 (FreeBSD-11.0-BETA2-amd64-disc1.iso) = 
f0287f3062ecf22d88f2d24e7093009a6036165d1b05bc6824407494d4452b4868635874b4c921f9f62621b797e11876348c29d9f3be21bec800145d5250e7dc
  SHA512 

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

[Ian Lepore]

On Sun, 2016-07-24 at 12:52 -0600, Warner Losh wrote:
> On Sun, Jul 24, 2016 at 12:42 PM, Kevin Oberman 
> wrote:
> > There are several different USB serial drivers. Off-hand I see
> > ubser, ubsa,
> > uchcom, ucom, ucycom, uftdi, ubgensa, umcs, umct, umoscom, uplcom,
> > usb_serial, uslcom, and uvscom. Whether any of these will support
> > the TI
> > chip, I can't say. Most have man pages, but a few, as has been
> > noted, are
> > lacking one.
> 
> I tried to automate discovery of these things. However, the only way
> you can really know for sure about the TI chip is to read it's
> datasheet
> and compare that with extant drivers. It's actually easier than it
> sounds.
> 
> I've often thought of unification of the TTY USB drivers, since they
> are
> most (but not all) based on the standard plus extra bits.
> 
> Warner

To reiterate:  we do not have a driver for TI 5052 chips.

It's not much like other usb-serial chips.  In fact it's not strictly a
usb-serial chip, it's a multifunction chip that includes a software
-controllable usb hub, 2 serial ports, gpio, an i2c bus master, an MCU
interface, a multichannel DMA controller, and apparently even has the
ability to download your own 8052-compatible microcontroller code into
the 5052 and have it take over from the built-in rom code.

It would be reasonable enough to write a driver that initially
supported only the uart part of the chip.

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

[Warner Losh]

On Sun, Jul 24, 2016 at 12:42 PM, Kevin Oberman  wrote:
> There are several different USB serial drivers. Off-hand I see ubser, ubsa,
> uchcom, ucom, ucycom, uftdi, ubgensa, umcs, umct, umoscom, uplcom,
> usb_serial, uslcom, and uvscom. Whether any of these will support the TI
> chip, I can't say. Most have man pages, but a few, as has been noted, are
> lacking one.

I tried to automate discovery of these things. However, the only way
you can really know for sure about the TI chip is to read it's datasheet
and compare that with extant drivers. It's actually easier than it sounds.

I've often thought of unification of the TTY USB drivers, since they are
most (but not all) based on the standard plus extra bits.

Warner
___
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

[Kevin Oberman]

On Sun, Jul 24, 2016 at 9:55 AM, Ian Lepore  wrote:

> On Sun, 2016-07-24 at 10:51 +0200, O. Hartmann wrote:
> > Am Sun, 24 Jul 2016 08:38:59 +0200
> > Gary Jennejohn  schrieb:
> >
> > > On Sun, 24 Jul 2016 08:03:30 +0200
> > > "O. Hartmann"  wrote:
> > >
> > > > Am Sat, 23 Jul 2016 14:49:11 -0600
> > > > Ian Lepore  schrieb:
> > > >
> > > > > 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
> > > > man ugensa doesn't exist! As I wrote earlier, I tried everything
> > > > to load what I could
> > > > find. It seems, the patch and the hint about ugensa.ko did the
> > > > magic ;-) Thank you
> > > > very much! Could the patch be made permanent to FreeBSD CURRENT?
> > > >
> > > > And also important: where is the man page for ugensa? Can the the
> > > > module be compiled
> > > > staitcally into the kernel or are there pitfalls?
> > > >
> > >
> > > Even the most complete man page found in the internet, the one from
> > > Dragonfly, doesn't list your Digi International device as being one
> > > of those supported.
> >
> > Yes. That is a pity. But Linux seems to operate this serial device. I
> > have to check next
> > time I get hands on a Linux box, what driver is attached to the
> > sensor.
> >
> > >
> > > Still, having the man page under FreeBSD would at least provide a
> > > hint
> > > that the driver even exists.
> >
> > Agreed.
> >
> > >
> > > I added device ugensa to my config file and the kernel was
> > > generated
> > > without an error.
> >
> > Me, too.
> >
> > >
> > > > root@localhost: [src] kldload ugensa
> > > >
> > > > ugen2.7:  at usbus2
> > > > ugensa0: 
> > > > on usbus2
> > > > ugensa0: Found 1 interfaces.
> > > > root@thor: [src] man ugensa
> > > > No manual entry for ugensa
> > > > root@localhost: [src] ll /dev/cuaU0*
> > > > 203 crw-rw  1 uucp  dialer  -  0xcb Jul 24 07:51 /dev/cuaU0
> > > > 204 crw-rw  1 uucp  dialer  -  0xcc Jul 24 07:51
> > > > /dev/cuaU0.init
> > > > 205 crw-rw  1 uucp  dialer  -  0xcd Jul 24 07:51
> > > > /dev/cuaU0.lock
> > > >
> > > >
> > > > I'll try now to get informations out of the device, I let you
> > > > know whether that is a
> > > > success. But anyway, again, thank you for helping making the
> > > > device visible and
> > > > available.
> > >
> >
> >
> > I had no luck with retrieving informations out of the device by the
> > Perl5 script provided
> > by Nagios.org. A prerequisite for the Perl script is the FreeBSD port
> >
> > comms/p5-Device-SerialPort
> >
> > Patching the script is trivial, but I do not know whether the
> > backend,
> > comms/p5-Device-SerialPort, works a sexpected. So the first, dirty,
> > trial ended up in
> > nothing - since the information gained from the sensor is an empty
> > string/nothing.
> >
> > I'm not familiar with serial devices, so far, so probably there is
> > something trivial
> > missing.
>
> I looked around for some info on these Watchport devices.  Their manual
> indicates that they use both serial comms to send commands and receive
> data, and they use serial-comms modem control signals (RTS/CTS, DTR,
> etc).  Some googling makes it look like 

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

[Ian Lepore]

On Sun, 2016-07-24 at 10:51 +0200, O. Hartmann wrote:
> Am Sun, 24 Jul 2016 08:38:59 +0200
> Gary Jennejohn  schrieb:
> 
> > On Sun, 24 Jul 2016 08:03:30 +0200
> > "O. Hartmann"  wrote:
> > 
> > > Am Sat, 23 Jul 2016 14:49:11 -0600
> > > Ian Lepore  schrieb:
> > >   
> > > > 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
> > > man ugensa doesn't exist! As I wrote earlier, I tried everything
> > > to load what I could
> > > find. It seems, the patch and the hint about ugensa.ko did the
> > > magic ;-) Thank you
> > > very much! Could the patch be made permanent to FreeBSD CURRENT?
> > > 
> > > And also important: where is the man page for ugensa? Can the the
> > > module be compiled
> > > staitcally into the kernel or are there pitfalls?
> > >   
> > 
> > Even the most complete man page found in the internet, the one from
> > Dragonfly, doesn't list your Digi International device as being one
> > of those supported.
> 
> Yes. That is a pity. But Linux seems to operate this serial device. I
> have to check next
> time I get hands on a Linux box, what driver is attached to the
> sensor.
> 
> > 
> > Still, having the man page under FreeBSD would at least provide a
> > hint
> > that the driver even exists.
> 
> Agreed.
> 
> > 
> > I added device ugensa to my config file and the kernel was
> > generated
> > without an error.
> 
> Me, too.
> 
> > 
> > > root@localhost: [src] kldload ugensa
> > > 
> > > ugen2.7:  at usbus2
> > > ugensa0: 
> > > on usbus2
> > > ugensa0: Found 1 interfaces.
> > > root@thor: [src] man ugensa
> > > No manual entry for ugensa
> > > root@localhost: [src] ll /dev/cuaU0*
> > > 203 crw-rw  1 uucp  dialer  -  0xcb Jul 24 07:51 /dev/cuaU0
> > > 204 crw-rw  1 uucp  dialer  -  0xcc Jul 24 07:51
> > > /dev/cuaU0.init
> > > 205 crw-rw  1 uucp  dialer  -  0xcd Jul 24 07:51
> > > /dev/cuaU0.lock
> > > 
> > > 
> > > I'll try now to get informations out of the device, I let you
> > > know whether that is a
> > > success. But anyway, again, thank you for helping making the
> > > device visible and
> > > available. 
> > 
> 
> 
> I had no luck with retrieving informations out of the device by the
> Perl5 script provided
> by Nagios.org. A prerequisite for the Perl script is the FreeBSD port
> 
> comms/p5-Device-SerialPort
> 
> Patching the script is trivial, but I do not know whether the
> backend,
> comms/p5-Device-SerialPort, works a sexpected. So the first, dirty,
> trial ended up in
> nothing - since the information gained from the sensor is an empty
> string/nothing.
> 
> I'm not familiar with serial devices, so far, so probably there is
> something trivial
> missing.

I looked around for some info on these Watchport devices.  Their manual
indicates that they use both serial comms to send commands and receive
data, and they use serial-comms modem control signals (RTS/CTS, DTR,
etc).  Some googling makes it look like they use a TI 5052 USB serial
chip.  On linux, that would be handled by the io_ti USB serial driver.

All of that adds up to the freebsd ugensa driver (which is "generic
serial IO") probably not working.  The ugensa driver has nothing chip
-specific in it, it's for accessing 

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

[David Chisnall]

Thanks,

On 19 Jul 2016, at 20:49, Emmanuel Vadot  wrote:
> 
> 
> Hello,
> 
> I've just tried bsd dtc on all arm dts that we have.
> It doesn't seems to handle multiple include directories.
> Here is how to reproduce :
> 
> $ export SRCROOT=/path/to/fbsd/src
> $ export MACHINE=arm
> $ cd $SRCROOT/sys/boot/fdt/dts/arm
> $ $SRCROOT/sys/tools/fdt/make_dtb.sh $SRCROOT/sys
> beaglebone-black.dts . converting beaglebone-black.dts
> -> ./beaglebone-black.dtb Unable to open file
> '/home/elbarto/Work/freebsd/freebsd.git//sys/boot/fdt/dts/arm/am33xx-clocks.dtsi'.
> No such file or directory Unable to open file
> '/home/elbarto/Work/freebsd/freebsd.git//sys/boot/fdt/dts/arm/tps65217.dtsi'.
> No such file or directory
> 
> Both dtsi files are include with /include/ (i.e. not handled by cpp).
> make_dtb.sh specify : -i $S/boot/fdt/dts/${MACHINE} -i
> $S/gnu/dts/${MACHINE}, it looks like the second one isn't added to the
> list.

It actually is added to the list and found.  The bug here is in error reporting 
- it was reporting an error for each file that it tried to open but couldn’t, 
even when it subsequently found the correct file.

> 
> Trying tegra124-jetson-tk1-fbsd.dts give this :
> converting tegra124-jetson-tk1-fbsd.dts
> -> /tmp/bsd_dtb//tegra124-jetson-tk1-fbsd.dtb Error on line 1214:
> Expected node name interrupt-affinity = <&{/cpus/cpu@0}>,
> ^
> Error on line 1214: Expected ; at end of property
>  interrupt-affinity = <&{/cpus/cpu@0}>,
> ^
> Failed to parse tree.  Unhappy face!

There was a FIXME relating to this in the code.  

I’ve now fixed both of these in the version here:

https://github.com/davidchisnall/dtc

I’ll push the changes to FreeBSD svn soon, but in the meantime anyone wanting 
to test can just clone that repo over the dtc directory in their src checkout.

David



smime.p7s
Description: S/MIME cryptographic signature

Re: kernel options

[Ngie Cooper (yaneurabeya)]

> On Jul 24, 2016, at 01:51, tech-lists  wrote:
> 
> Hi,
> 
> In -HEAD there is a generic kernel GENERIC-NODEBUG. The syntax of
> OPTIONS appears to be NOOPTIONS. Is there an inverse for DEVICE ?
> 
> For example, there is a line
> 
> device  fdc
> 
> in GENERIC. Would NODEVICE negate it?
> 
> I didn't see anything in NOTES to confirm.

`nodevice` works. See `man 5 config` for more details.
Cheers,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

kernel options

[tech-lists]

Hi,

In -HEAD there is a generic kernel GENERIC-NODEBUG. The syntax of
OPTIONS appears to be NOOPTIONS. Is there an inverse for DEVICE ?

For example, there is a line

device  fdc

in GENERIC. Would NODEVICE negate it?

I didn't see anything in NOTES to confirm.

thanks,
-- 
J.
___
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 Sun, 24 Jul 2016 08:38:59 +0200
Gary Jennejohn  schrieb:

> On Sun, 24 Jul 2016 08:03:30 +0200
> "O. Hartmann"  wrote:
> 
> > Am Sat, 23 Jul 2016 14:49:11 -0600
> > Ian Lepore  schrieb:
> >   
> > > 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
> > man ugensa doesn't exist! As I wrote earlier, I tried everything to load 
> > what I could
> > find. It seems, the patch and the hint about ugensa.ko did the magic ;-) 
> > Thank you
> > very much! Could the patch be made permanent to FreeBSD CURRENT?
> > 
> > And also important: where is the man page for ugensa? Can the the module be 
> > compiled
> > staitcally into the kernel or are there pitfalls?
> >   
> 
> Even the most complete man page found in the internet, the one from
> Dragonfly, doesn't list your Digi International device as being one
> of those supported.

Yes. That is a pity. But Linux seems to operate this serial device. I have to 
check next
time I get hands on a Linux box, what driver is attached to the sensor.

> 
> Still, having the man page under FreeBSD would at least provide a hint
> that the driver even exists.

Agreed.

> 
> I added device ugensa to my config file and the kernel was generated
> without an error.

Me, too.

> 
> > root@localhost: [src] kldload ugensa
> > 
> > ugen2.7:  at usbus2
> > ugensa0:  on usbus2
> > ugensa0: Found 1 interfaces.
> > root@thor: [src] man ugensa
> > No manual entry for ugensa
> > root@localhost: [src] ll /dev/cuaU0*
> > 203 crw-rw  1 uucp  dialer  -  0xcb Jul 24 07:51 /dev/cuaU0
> > 204 crw-rw  1 uucp  dialer  -  0xcc Jul 24 07:51 /dev/cuaU0.init
> > 205 crw-rw  1 uucp  dialer  -  0xcd Jul 24 07:51 /dev/cuaU0.lock
> > 
> > 
> > I'll try now to get informations out of the device, I let you know whether 
> > that is a
> > success. But anyway, again, thank you for helping making the device visible 
> > and
> > available. 
> 


I had no luck with retrieving informations out of the device by the Perl5 
script provided
by Nagios.org. A prerequisite for the Perl script is the FreeBSD port

comms/p5-Device-SerialPort

Patching the script is trivial, but I do not know whether the backend,
comms/p5-Device-SerialPort, works a sexpected. So the first, dirty, trial ended 
up in
nothing - since the information gained from the sensor is an empty 
string/nothing.

I'm not familiar with serial devices, so far, so probably there is something 
trivial
missing.


pgp5bZ_sMLGT7.pgp
Description: OpenPGP digital signature

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

[Gary Jennejohn]

On Sun, 24 Jul 2016 08:03:30 +0200
"O. Hartmann"  wrote:

> Am Sat, 23 Jul 2016 14:49:11 -0600
> Ian Lepore  schrieb:
> 
> > 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  
> man ugensa doesn't exist! As I wrote earlier, I tried everything to load what 
> I could
> find. It seems, the patch and the hint about ugensa.ko did the magic ;-) 
> Thank you very
> much! Could the patch be made permanent to FreeBSD CURRENT?
> 
> And also important: where is the man page for ugensa? Can the the module be 
> compiled
> staitcally into the kernel or are there pitfalls?
> 

Even the most complete man page found in the internet, the one from
Dragonfly, doesn't list your Digi International device as being one
of those supported.

Still, having the man page under FreeBSD would at least provide a hint
that the driver even exists.

I added device ugensa to my config file and the kernel was generated
without an error.

> root@localhost: [src] kldload ugensa
> 
> ugen2.7:  at usbus2
> ugensa0:  on usbus2
> ugensa0: Found 1 interfaces.
> root@thor: [src] man ugensa
> No manual entry for ugensa
> root@localhost: [src] ll /dev/cuaU0*
> 203 crw-rw  1 uucp  dialer  -  0xcb Jul 24 07:51 /dev/cuaU0
> 204 crw-rw  1 uucp  dialer  -  0xcc Jul 24 07:51 /dev/cuaU0.init
> 205 crw-rw  1 uucp  dialer  -  0xcd Jul 24 07:51 /dev/cuaU0.lock
> 
> 
> I'll try now to get informations out of the device, I let you know whether 
> that is a
> success. But anyway, again, thank you for helping making the device visible 
> and available.
> 

-- 
Gary Jennejohn
___
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 Sat, 23 Jul 2016 14:49:11 -0600
Ian Lepore  schrieb:

> 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
man ugensa doesn't exist! As I wrote earlier, I tried everything to load what I 
could
find. It seems, the patch and the hint about ugensa.ko did the magic ;-) Thank 
you very
much! Could the patch be made permanent to FreeBSD CURRENT?

And also important: where is the man page for ugensa? Can the the module be 
compiled
staitcally into the kernel or are there pitfalls?

root@localhost: [src] kldload ugensa

ugen2.7:  at usbus2
ugensa0:  on usbus2
ugensa0: Found 1 interfaces.
root@thor: [src] man ugensa
No manual entry for ugensa
root@localhost: [src] ll /dev/cuaU0*
203 crw-rw  1 uucp  dialer  -  0xcb Jul 24 07:51 /dev/cuaU0
204 crw-rw  1 uucp  dialer  -  0xcc Jul 24 07:51 /dev/cuaU0.init
205 crw-rw  1 uucp  dialer  -  0xcd Jul 24 07:51 /dev/cuaU0.lock


I'll try now to get informations out of the device, I let you know whether that 
is a
success. But anyway, again, thank you for helping making the device visible and 
available.

Kind regards,

Oliver Hartmann


pgpHw4rHeTvK9.pgp
Description: OpenPGP digital signature