pucdata.c addition
Can someone please add the following definition to pucdata.c?
{ 0x1415, 0x950a, 0x131f, 0x2032,
"SIIG Cyber Serial Dual PCI 16C850 (20x family)",
DEFAULT_RCLK * 10,
PUC_PORT_4S, 0x10, 0, 8,
},
The card is identified as a SIIG CyberSerial Dual (2 ports) is expandable to
4 ports and registers four uart devices with FreeBSD (even without the
expansion chip). The chipset is by Oxford Semicondutor (OX16PCI954). The
card has a non-standard clock.
Thanks.
David Boyd
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
current status of digi driver
While attempting to upgrade our comm servers from 7.4-RELEASE to 8.2-RELEASE, I discovered that the digi driver didn't make the grade. I searched the archives and found discussions in August 2008 concerning drivers that were disconnected for lack of MPSAFEness. The threads continued right up to the point where it was agreed that the drivers shouldn't be allowed to halt/delay the MPSAFE switch in 8.0-RELEASE. It appears that there was also agreement that (at least) some of the drivers, digi included, would be converted soon after 8.0-RELEASE. The pre-MPSAFE code appears to be included in the most recent -STABLE and -CURRENT, but doesn't get built. The HARDWARE.TXT still includes digi among supported multiport serial device drivers. Is there any plan to bring digi forward? We have about 55 modem ports over ten 8-port Xr cards (PCI) that connect remote sites via dial-up. These work perfectly with 7.4-RELEASE. We would like to see them work perfectly with 8.x-RELEASE or 9.x-RELEASE. I have time and hardware to test with and can help as needed. Thoughts? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
missing perl module (p5-Sys-Filesystem) for amd64
This appears to be a problem only in 9.0-current and 9.0-beta1. The perl module p5-Sys-Filesystem appears in i386 but not in amd64. It is part of our automated installation. Thanks in advance for any information you can provide, for assisting with the proper resolution of this problem or for simply forwarding this message to the correct individual or group. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
new dialog/libdialog testing
Having some time to test 9.0-CURRENT with the new dialog command has uncovered only one major omission (for us): prgbox/dialog_prgbox. This is used in most (if not all) of our installation/management scripts. Was prgbox omitted for any particular reason? I realize that change is inevitable. Is there a better approach to running a program in a window? We like many of the new features presented, but are wary of problems down the road due to the omission of prgrbox. I notice that sysinstall uses dialog_prgbox in 8.1-RELEASE. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
pc-sysinstall and pxeboot
Has anyone noodled through the details of pxeboot and pc-sysinstall for automated installs? I have working configurations for pxeboot and sysinstall for 8.1-RELEASE and prior. What are the gotchas for 9.0-CURRENT? I have lots of testing time available. Thanks. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
12.0-CURRENT VM image won't mount USB flash drive
Beginning with 12.0-CURRENT VM image: FreeBSD-12.0-CURRENT-amd64-20180118-r328126.vmdk.xz and continuing with 12.0-CURRENT VM image: FreeBSD-12.0-CURRENT-amd64-20180125-r328383.vmdk.xz when a USB flash drive is present via the attached USB 3.0 controller the console hangs for 10-12 minutes during boot and then emits the error messages seen in the attachment. The UFS filesystem on the USB flash drive cannot be mounted. If the USB flash drive is connected via the attached USB 2.0 controller, everything is good. This problem is not manifested in any 10.4-STABLE or 11.1-STABLE VM images. The host system is CentOS EL7 7.1708. VirtualBox version is 5.2.6. The USB 3.0 controller uses a VIA chipset. System is for test purposes only, so it is easy to try anything that might help resolve this problem. Thanks. David Boyd ___ 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"
VM images for 12.0-CURRENT have problem with USB 3.0 flash drives
Beginning with 12.0-CURRENT VM image: FreeBSD-12.0-CURRENT-amd64-20180118-r328126.vmdk.xz and continuing with 12.0-CURRENT VM image: FreeBSD-12.0-CURRENT-amd64-20180125-r328383.vmdk.xz when a USB flash drive is present via the attached USB 3.0 controller the console hangs for 10-12 minutes during boot and then emits the error messages seen in the attachment. The UFS filesystem on the USB flash drive cannot be mounted. If the USB flash drive is connected via the attached USB 2.0 controller, everything is good. This problem is not manifested in any 10.4-STABLE or 11.1-STABLE VM images. The host system is CentOS EL7 7.1708. VirtualBox version is 5.2.6. The USB 3.0 controller uses a VIA chipset. System is for test purposes only, so it is easy to try anything that might help resolve this problem. Thanks. David Boyd ___ 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"
12.0-CURRENT missing timezones
In the most recent images for 12.0-CURRENT FreeBSD-12.0-CURRENT-amd64-20180208-r329009.vmdk.xz FreeBSD-12.0-CURRENT-amd64-20180208-r329009-disc1.iso FreeBSD-12.0-CURRENT-amd64-20180131-r328637-memstick.img the /usr/share/zoneinfo directory is sparsely populated with directories. The only file present is "zone.tab". Thanks for looking into this. David Boyd ___ 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: 12.0-CURRENT missing timezones
On Fri, 2018-02-09 at 10:16 -0700, Warner Losh wrote: > On Fri, Feb 9, 2018 at 10:13 AM, Warner Losh wrote: > > On Fri, Feb 9, 2018 at 9:56 AM, David Boyd > > wrote: > > > In the most recent images for 12.0-CURRENT > > > > > > > > > > > > FreeBSD-12.0-CURRENT-amd64-20180208-r329009.vmdk.xz > > > > > > > > > > > > FreeBSD-12.0-CURRENT-amd64-20180208-r329009-disc1.iso > > > > > > > > > > > > FreeBSD-12.0-CURRENT-amd64-20180131-r328637-memstick.img > > > > > > > > > > > > the /usr/share/zoneinfo directory is sparsely populated with > > > > > > directories. The only file present is "zone.tab". > > > > I think that may be my fault for changing find -s to find | sort, > > but I think I neglected to add sort to ITOOLS to fix it. Building a > > test now. > > I am surprised the 0131 is empty, though My change was after > that. > > Warner Oops. My mistake (cut and paste error). All dates should be 20180208. ___ 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"
13.0-CURRENT drops to debugger on shutdown with IPNAT enabled
13.0-CURRENT drops to debugger on shutdown with IPNAT enabled. Running in VirtualBox 6.0.2. The identical configuration running 12.0-RELEASE-p2, 12.0-STABLE, 11.2- RELEASE-p8 and 11.2-STABLE do not exhibit this behavior. This (VM) is a test machine and I can do anything that will help identify the root of this problem. I have included screenshots of the debug output and a backtrace. Thanks. David Boyd. ___ 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: 13.0-CURRENT drops to debugger on shutdown with IPNAT enabled
On Mon, 2019-01-21 at 10:37 +0100, Trond Endrestøl wrote: > On Sun, 20 Jan 2019 13:09-0500, David Boyd wrote: > > > 13.0-CURRENT drops to debugger on shutdown with IPNAT enabled. > > > > Running in VirtualBox 6.0.2. > > > > The identical configuration running 12.0-RELEASE-p2, 12.0-STABLE, > > 11.2- > > RELEASE-p8 and 11.2-STABLE do not exhibit this behavior. > > > > This (VM) is a test machine and I can do anything that will help > > identify the root of this problem. > > Is the VM configured to use UEFI as the boot firmware? > > I've noticed 13.0-CURRENT fails to poweroff, be it by way of > shutdown > -p now or halt -p, when using UEFI on VBox 5.2.x and 6.0.y. shutdown > -h and plain halt works as intended. Maybe this is completely > unrelated to your issue. > > > I have included screenshots of the debug output and a backtrace. > > The screenshots got stripped off by the mailman list software. Can > you > reupload them somewhere else, or transcribe the relevant details? Okay, I will submit a PR with the attachments. David. ___ 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: 13.0-CURRENT drops to debugger on shutdown with IPNAT enabled
On Mon, 2019-01-21 at 10:17 -0500, David Boyd wrote: > On Mon, 2019-01-21 at 10:37 +0100, Trond Endrestøl wrote: > > On Sun, 20 Jan 2019 13:09-0500, David Boyd wrote: > > > > > 13.0-CURRENT drops to debugger on shutdown with IPNAT enabled. > > > > > > Running in VirtualBox 6.0.2. > > > > > > The identical configuration running 12.0-RELEASE-p2, 12.0-STABLE, > > > 11.2- > > > RELEASE-p8 and 11.2-STABLE do not exhibit this behavior. > > > > > > This (VM) is a test machine and I can do anything that will help > > > identify the root of this problem. > > > > Is the VM configured to use UEFI as the boot firmware? > > > > I've noticed 13.0-CURRENT fails to poweroff, be it by way of > > shutdown > > -p now or halt -p, when using UEFI on VBox 5.2.x and 6.0.y. > > shutdown > > -h and plain halt works as intended. Maybe this is completely > > unrelated to your issue. > > > > > I have included screenshots of the debug output and a backtrace. > > > > The screenshots got stripped off by the mailman list software. Can > > you > > reupload them somewhere else, or transcribe the relevant details? > > Okay, I will submit a PR with the attachments. > > David. > > ___ > 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" PR number is 235110. Thanks. David. ___ 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"
13.0-CURRENT oddity in output of dialog(1)
In 13.0-CURRENT, dialog(1) fills lines shorter than the box width with something other than the background color. In an xterm session, the fill is white. In a console session, the fill is black. This appears to be a regression in the dialog(1) utility not seen in previous (11.2-RELEASE and 12.0-RELEASE) releases. To recreate: cat /etc/rc.conf | dialog --programbox 23 76 No other problems have been observed in the dialog(1) utility. Thanks. David Boyd. ___ 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"
lsof hangs with latest 13.0-CURRENT snapshot
After upgrading from FreeBSD-13.0-CURRENT-amd64-20190328-r345620 to FreeBSD-13.0-CURRENT-amd64-20190404-r345863, lsof (4.92 from packages) hangs. This is true for bare metal installs and virtual machine installs. How to recreate: Install FreeBSD-13.0-CURRENT-amd64-20190404-r345863 snapshot. as root: lsof /sbin/init By running command with -b option, this error is displayed: lsof: status error on /sbin/init: Resource temporarily unavailable The return code is 1. This probably requires adjustment to lsof, but only the FreeBSD snapshot changed, so I'll start here. Thanks. David Boyd. ___ 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: lsof hangs with latest 13.0-CURRENT snapshot
On Tue, 2019-04-09 at 12:20 -0700, Rodney W. Grimes wrote: > > After upgrading from FreeBSD-13.0-CURRENT-amd64-20190328-r345620 to > > FreeBSD-13.0-CURRENT-amd64-20190404-r345863, lsof (4.92 from > > packages) > > hangs. > > > > This is true for bare metal installs and virtual machine installs. > > > > How to recreate: > > > > Install FreeBSD-13.0-CURRENT-amd64-20190404-r345863 snapshot. > > > > as root: lsof /sbin/init > > > > By running command with -b option, this error is displayed: > > > > lsof: status error on /sbin/init: Resource temporarily unavailable > > > > The return code is 1. > > > > This probably requires adjustment to lsof, but only the FreeBSD > > snapshot changed, so I'll start here. > > Where did you get your lsof binary from? > > lsof has internal knowledge of kernel data structures > and must be compiled to match the running system. > > > > Thanks. > > David Boyd. lsof was installed via pkg install from pkg.freebsd.org. ___ 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"
New vm-image size is much smaller than previos
The vm-image for 13.0-CURRENT FreeBSD-13.0-CURRENT-amd64-20190503-r347033.vmdk is only 4.0 GB in size. Previous images were about 31.0 GB. This smaller image doesn't leave much room to add packages and other customizations. Thanks. David Boyd. ___ 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"
AUTOFS and NFS not playing together nicely
At the risk of being dubbed insane, here goes: On five FreeBSD 10.1-RELEASE-p9 production servers autofs(5) is enabled and working as advertised. On the same servers nfs v3 clients are also fat, dumb and happy. On a test server where autofs(5) is also enabled and working well, I am testing nfs v3 (later v4) server. Strange things are happening. When nfs mountd(8) is running, the autofs(5) auto-mount (via automountd) function seems to work, but the autofs(5) auto-unmount (via autounmountd) never occurs. Without nfs mountd(8), when the filesystem /disc is auto-mounted (via autoumountd), the mount(8) command shows status of (ufs, local, journaled soft-updates, auto-mounted) for the auto-mounted filesystem and after the autofs(5) timeout period (600 seconds) the filesystem is auto-unmounted (via autounmountd). No problem. With nfs mountd(8) the mount(8) command shows (ufs, local, journaled soft-updates). The auto-mounted filesystem is never (a long, long time) unmounted. Big problem. Without nfs mountd(8) running, the mount(8) command "mount -o automounted /dev/ada0p8 /disc" mounts the filesystem and the mount(8) command shows (ufs, local, journaled soft-updates, automounted) for the manually mounted filesystem and after the autofs(5) timeout period (600 seconds) the filesystem is auto-unmounted even though it was not mounted automatically. No problem. With nfs mountd(8), the mount(8) command "mount -o automounted /dev/ada0p8 /disc" mounts the filesystem but the mount(8) command shows (ufs, local, journaled soft-updates) and after the timeout period (600 seconds) the filesystem is remains mounted. Big problem. It appears that nfs mountd(8) is interferring with the mount(8) command's -o option processing but admittedly that is just a very weak SWAG. I have adequate hardware (real and virtual) to do any testing that may be suggested. Most days there is no time constraint either. The /etc/auto_master file is two lines: 1:/net -hosts -nobrowse,nosuid(original) 2:/-/etc/autofs/auto_disc The /etc/autofs/auto_disc file is one line: 1:/disc -fstype=ufs :/dev/ada0p8 Once again, everything works well when nfs mountd(8) is not present in the system. Thanks for any assistance that you may be able to supply. David Boyd. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: nmount, mountd drops high order MNT_xx flags during a mount update
On Sun, 2015-05-10 at 09:07 -0400, Rick Macklem wrote: > Oops, I did my usual and forgot to attach the patch. > > Here it is, rick > > - Original Message - > > Doug Rabson wrote: > > > You could add a single integer-valued vfsopt which holds the > > > high-order > > > bits of f_flags? > > > > > I have created a patch that does this. It is on > > https://reviews.freebsd.org/D2506 > > (I have also attached it here, for those who don't use Phabricator.) > > > > Please review/comment on this. (Feel free to add yourself as a > > reviewer, etc.) > > > > Also, David, if you can test this patch, it would be appreciated. > > > > Thanks for the suggestion Doug, rick > > > > > On 7 May 2015 at 02:10, Rick Macklem wrote: > > > > > > > David Boyd reported a problem to freebsd-current@ w.r.t. the > > > > MNT_AUTOMOUNTED > > > > flag getting cleared by mountd. > > > > http://docs.FreeBSD.org/cgi/mid.cgi?1429477202.29812.38.camel > > > > I just took a look at this and it's kinda ugly... > > > > > > > > mountd acquires a list of mounts via getmntinfo() and then does > > > > an > > > > nmount() for each of them to get rid of any exports. It uses > > > > f_flags from the statfs returned by getmntinfo() as the 3rd > > > > argument to nmount(). > > > > --> Since nmount()s 3rd argument is a "int", it silently drops > > > > any > > > > MNT_xx flag in the high order 32bits of f_flags. At this > > > > time, > > > > it happens that MNT_AUTOMOUNTED is the only one, but... > > > > > > > > I can think of a couple of ways to fix this, but I don't like any > > > > of > > > > them;-) > > > > > > > > 1) I suppose mountd could check for each flag set in f_flags and > > > > generate > > > > a vfsopts string for it, but that means that every time a new > > > > flag > > > > that > > > > can be updated is added to MNT_xx, this mountd.c code would have > > > > to > > > > updated. > > > > --> Ugly!! > > > > > > > > 2) Require that all flags in MNT_UPDATEMASK be in the low order > > > > 32bits. > > > >I wouldn`t mind this except in means that the MNT_xx flags > > > >must > > > >be > > > > redefined > > > >and I don`t think that could get MFC`d. > > > > > > > > 3) Add a new newernmount(2) which has a 64bit flags argument > > > > instead of > > > > int. > > > > > > > > Hopefully someone can think of a nice way to fix this, rick > > > > ___ > > > > freebsd-current@freebsd.org mailing list > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > To unsubscribe, send any mail to > > > > "freebsd-current-unsubscr...@freebsd.org" > > > > > > > ___ > > > freebsd-current@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to > > > "freebsd-current-unsubscr...@freebsd.org" > > > > > ___ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to > > "freebsd-current-unsubscr...@freebsd.org" > > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" Rick, Edward, et al, I have applied your patches to several (four) servers and have not noticed any more instances of the errant behavior. I think (hope) that this is the correct fix and wonder if this fix might make it's way into an errata. Thanks for the quick responses. David Boyd. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
VM images for 12.0-CURRENT showing checksum failed messages
The FreeBSD-12.0-CURRENT-amd64-20171012-r324542.vmdk image displays many checksum failed messages when booted. (see attachment). I think this started about 20170925. I have VirtualBox VM's running 10.4-STABLE, 11.1-STABLE and 12.0- CURRENT. Only the 12.0-CURRENT image exhibits this behavior. This is easily fixed by "fsck -y /" in single-user mode during the boot process. I can test any updates at almost any time. Thanks. David Boyd. ___ 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 4.9-RC4 vs 5.1-CURRENT-20031021-JPSNAP
Hardware: Soekris Net4801 (ComBIOS 1.21), SanDisk 512MB Ultra Compact Flash Software: 5.1-CURRENT Symptom:ad0: FAILURE - SET_MULTI status=51 error=4 GEOM: create disk ad0 dp=0xc47ffb70 ad0: 488MB [993/16/63] at ata0-master PIO4 Result: system boots normally and runs without problems Hardware: Soekris Net4801 (ComBIOS 1.21), SanDisk 512MB Ultra Compact Flash Software: 4.9-RC4 Symptom:Read error (BIOS? initiated) Result: hung Note: Hardware in scenario #1 and scenario #2 are the same pieces of equipment (not just similar). Analysis(feeble): This Compact Flash card does not support multi-sector transfers required to boot. 5.1-CURRENT is compensating for this effect and continues. 4.9-RC4 punts (returning an error to the BIOS?). The recent delay of 4.9-RELEASE may indicate that there is some small window in which to obtain a fix for this problem in a "STABLE" release (before 5.2). I hope. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
